結論｜止めておける時間が長いほど安い。常駐させると逆転する
記事のキービジュアル生成を Gemini API から RunPod へ移せるかを、2026 年 8 月 16 日に実測しました。数字を先に置きます。
| 項目 | Gemini 3.1 Flash Image | RunPod (既成ワーカー・RTX 4090) |
|---|---|---|
| 1 枚の所要時間 | 18.7 秒 (10 枚の中央値) | 50.3 秒 (コールドスタート込み) |
| 月 5,000 枚の費用 | $505 | $42 (実測 27.7 秒/枚から逆算) |
| 常時稼働にした場合の月額 | $505 (枚数課金なので変わらず) | $792 |
移せるかどうかを決めるのは枚数ではなく 稼働時間の置き方 でした。使った秒数だけ課金される設計なので、生成に必要な 38.5 時間ぶんだけ払えば済み、Gemini の 1/12 に収まります。逆にワーカーを常駐させると月 $792 になり、Gemini を 1.6 倍上回ります。
ただしこれは「即応が要る」前提での比較です。待てるなら Gemini 側もバッチ API が使えて月 $250 まで下がるので、差は 1/6 に縮みます。前提を揃えずに倍率だけ見ると判断を誤ります。
一方で、既成ワーカーをそのまま使うと出力サイズを制御できませんでした。README には指定できると書かれているのに、コードとワークフローがそうなっていなかったからです。結果として、自前でワーカーを作ることになりました。その顛末は ComfyUI ワーカーを自前で作るにまとめています。 本記事は「移せるかどうかの判断材料をどこまで実測できたか」までです。
なお、モデルの単価そのものを下げる話は LLM アプリのコスト最適化に整理しています。ここで扱うのは、API から自前 GPU へ寄せたときに何が変わるかです。
前提を先に固める — 枚数と応答性
セルフホストの損得は前提で反転します。先に 2 つを固めました。
- 規模は 月 5,000 枚
- 応答性は リアルタイム。ユーザー操作に対して返す
そのうえで、費用を最も大きく動かす変数がもう 1 つあります。何秒まで待てるか です。ここを何秒に置くかで、ワーカーを起こしたままにする必要があるかどうかが変わり、費用が桁で動きます。現行の実測は 18.7 秒なので、これを基準に許容値との差を見ることになります。
現行構成は gemini-3.1-flash-image の 2K 出力で、プロンプトは 1,700 文字です。
要点
先に決めるべきは「何秒まで待てるか」です。ここが数秒ならワーカーの常駐が必須になり、費用の前提が変わります。起動待ちを許容できるなら、止めておく設計を選べます。
Gemini 側のベースライン (実測 10 枚)
基準がないと速い遅いを判断できないので、同一プロンプトで 10 枚生成しました。
成功 10/10 (100%)
中央値 18.7 秒
平均 18.5 秒
最小 / 最大 17.3 / 19.3 秒
ファイルサイズ中央値 87 KBばらつきは 2 秒以内で、失敗はありませんでした。基準は 18.7 秒 です。
単価は公式の料金表に載っています。gemini-3.1-flash-image は 0.5K が $0.045、1K が $0.067、2K が $0.101、4K が $0.151。2K を使っているので $0.101/枚、月 5,000 枚で $505/月 です。なお、即応が要らない運用ならバッチ処理で 2K が $0.050 に下がり、月 $250 になります。後で RunPod と比べるときに、この 2 つの前提を混ぜないよう気をつけます。出典は Gemini API の料金ページです。
RunPod の料金 — Serverless の GPU 単価は Pod の 2〜3 倍
RunPod の料金は Pod と Serverless で別建てです。同じ GPU でも単価が違います。2026 年 8 月 16 日時点の公式料金ページの値を並べます。
| GPU | VRAM | Pod (community) | Serverless |
|---|---|---|---|
| RTX A5000 / 3090 / L4 | 24GB | $0.16〜0.44/h | $0.69/h |
| RTX 4090 | 24GB | $0.34/h | $1.10/h |
| A100 SXM | 80GB | $1.39/h | $2.72/h |
| H100 SXM | 80GB | $2.69/h | $4.79/h |
Serverless は Pod の 2〜3 倍です。ここを見落とすと試算が丸ごとずれます。秒単位の従量課金なので、稼働率が低いほど割高な単価を吸収できる構造になっています。逆に常時動かす前提なら Pod のほうが安く、Serverless を選ぶ理由がなくなります。
VRAM の差も無視できません。24GB クラスと 80GB クラスでは、Serverless で 4 倍近い開きがあります。モデルを 24GB に載せられるかどうかが、そのまま費用の分岐点になります。量子化で必要 VRAM を落とす考え方は Gemma 4 12B の解説でも触れています。
コールドスタート込みで 50.3 秒 (実測)
RunPod Hub にある既成の Qwen-Image-Edit ワーカーを RTX 4090 で動かし、FlashBoot を有効にしない状態で 1 枚生成しました。
{
"delayTime": 22555,
"executionTime": 27696
}delayTime がコンテナ起動とモデルのロード、executionTime が生成です。合計 50.3 秒。生成そのものは 27.7 秒なので、Gemini より 9 秒遅い計算になります。
注意
コールドスタートの 22.6 秒も課金対象です。公式ドキュメントには、初期化・処理・アイドル待機のすべてが課金対象で、ワーカーが起動してから停止するまで秒単位で切り上げて課金されると記載されています (Serverless の料金)。「起動は無料」という前提で試算すると合いません。
体感で効くのは、この 22.6 秒が何回発生するかです。1 日 1 回まとめて生成するバースト運用なら、コールドスタートは 1 日 1 回だけ。以降のリクエストは 27.7 秒で返ります。逆に問い合わせが散発的に来る用途では毎回 50.3 秒になり、印象が大きく変わります。
ただし、この数字は安定しません
同じエンドポイント・同じ GPU で 6 枚生成したときの内訳です。
| 回 | 起動 (delayTime) | 生成 (executionTime) | 合計 |
|---|---|---|---|
| 1 | 22.6 秒 | 27.7 秒 | 50.3 秒 |
| 2 | 159.5 秒 | 41.8 秒 | 201.4 秒 |
| 3 | 25.3 秒 | 32.8 秒 | 58.1 秒 |
| 4 | 18.5 秒 | 29.9 秒 | 48.5 秒 |
| 5 | 30.1 秒 | 35.5 秒 | 65.6 秒 |
| 6 | 23.0 秒 | 23.0 秒 | 46.0 秒 |
2 回目だけ 4 倍に伸びています。待っている間にワーカーの状態を見ると、こうなっていました。
{ "idle": 0, "initializing": 2, "running": 0, "throttled": 4, "total": 6 }throttled はホスト側が容量いっぱいで、ワーカーを起動できない状態です。GPU の在庫を問い合わせる API は同じ時間帯に「在庫あり (High)」を返していました。 在庫の表示は確保を保証しません。
6 回中 5 回は 46〜66 秒に収まり、残る 1 回だけ桁が違いました。頻度を言うには試行が足りませんが、外れ値が起こり得る前提で設計するのが安全です。費用への影響は軽微で、201.4 秒ぶんの課金は $0.06 にしかなりません。効くのは待たせる側です。平均の 50 秒を基準に UI を組むと、4 倍の遅延が想定外として現れます。
なお、上の表は各列を四捨五入しているため、行によっては内訳の和と合計が 0.1 秒ずれます。
RunPod と Gemini の月額料金を、前提を揃えて並べる
必要な GPU 時間を実測から逆算します。生成は 27.7 秒/枚なので、5,000 枚で 138,500 秒、約 38.5 時間です。Serverless は秒単位の課金なので、ワーカーを何台並べて待ち時間を縮めても、合計の GPU 秒は変わりません。コールドスタートも課金対象ですが、1 日 1 回起動する運用なら月 30 回で $0.21 にしかならず、丸めの範囲に収まります。
| GPU | 単価 | 月額 (38.5 時間) |
|---|---|---|
| 24GB クラス | $0.69/h | $27 |
| RTX 4090 | $1.10/h | $42 |
| A100 80GB | $2.72/h | $105 |
Gemini と比べるときは、待てるかどうかで相手の単価が変わることに注意が要ります。
| 前提 | Gemini | RunPod (RTX 4090) | 差 |
|---|---|---|---|
| 即応が要る (リアルタイム API) | $505 | $42 | 約 1/12 |
| 即応が要らない (バッチ API) | $250 | $42 | 約 1/6 |
どちらの前提でも RunPod のほうが安く収まりました。ただし 24 時間 365 日の常駐に切り替えると話が反転します。月 720 時間として、24GB クラスの $0.69/h でも $497 で Gemini の $505 とほぼ同額。RTX 4090 なら $792 で、逆に 1.6 倍かかります。
つまり セルフホストが安いのではなく、止めておける時間が長いから安い という関係です。ここを取り違えると、移した後に費用が下がらない結果になります。
FIXIT
Dodai止めている間だけです。動かしっぱなしにすると API とほぼ同じ額になります。
FIXITDodai起動に 22.6 秒かかります。そこを待てるかどうかが分かれ目です。
モデル選定 — 3.0 はセルフホストできない
名前が新しいほうを選びたくなりますが、Qwen-Image-3.0 は候補から外れました。重みの公開が確認できません。 Hugging Face の API では Qwen/Qwen-Image-3.0 を取得できず (401)、公開されたモデルカードもライセンス表記も技術レポートも見つかりませんでした。401 は「存在しない」と「非公開」を区別しないため、少なくとも一般に公開はされていない、というところまでが言えることです。いずれにせよ、自前の GPU には載せられません。
自前の GPU に載せられる系列で最新のものは Qwen-Image-Edit-2511 でした。ライセンスは Apache-2.0 です。公式ブログは改善点として character consistency の向上と、コミュニティ製 LoRA の本体統合を挙げています。同一キャラクターを繰り返し描かせる用途とは相性がよさそうに見えます。
| モデル | セルフホスト | 判断 |
|---|---|---|
Qwen-Image-3.0 | 不可 | 重みの公開を確認できず。API 経由のみ |
Qwen-Image-Edit-2511 | 可 | 本命。character consistency を改善 |
Qwen-Image-Edit-2509 | 可 | 前世代。2511 で置き換わった |
サイズは実測しました。公式リポジトリの safetensors を合計すると 53.74 GiB (約 57.7GB) です。bf16 のフル版をそのまま載せるなら 80GB クラスが要ります。24GB に載せるには FP8 などの量子化版が前提になります。前節の単価表と突き合わせると、ここが経済性の分岐点になっていることが分かります。Qwen 系列全体の位置づけは Qwen3.8-Max の解説にまとめています。
既成ワーカーの限界 — README とコードが食い違っていた
ここが今回いちばん時間を取られたところです。
RunPod Hub にある Qwen-Image-Edit のワーカー (デプロイ数 662) を使い、API に width と height を渡したところ、指定が無視され、出力が 1024×1024 の正方形になりました。16:9 が欲しい用途では使えません。
原因は ソースコードに書かれていました。handler.py の該当箇所です (コメントは原文ママ)。
_NODE_WIDTH = "128" # 현재 워크플로우에는 없음(선택 적용)
_NODE_HEIGHT = "129" # 현재 워크플로우에는 없음(선택 적용)
if _NODE_WIDTH in prompt and "width" in job_input: # ← 条件が成立しない
prompt[_NODE_WIDTH]["inputs"]["value"] = job_input["width"]韓国語のコメントは「現在のワークフローには存在しない (任意適用)」という意味です。ノード ID の 128 と 129 が同梱のワークフローに無いため、if の第 1 条件が常に偽になり、代入は一度も走りません。API は width を受け取りますが、どこにも反映されない構造でした。
実際にサイズを決めていたのは、ワークフロー側の ImageScaleToTotalPixels ノードです。
{
"class_type": "ImageScaleToTotalPixels",
"inputs": { "upscale_method": "lanczos", "megapixels": 1 }
}合計 1 メガピクセルへ正規化する設定で、出力の縦横比は入力画像の比率に従います。正方形の参照画像を渡していたので、出力も正方形になっていました。
そして README には、width と height が Required、型は integer と書かれています。ドキュメントと実装が食い違っている状態です。
注意
同じリポジトリはライセンスが明示されていません。GitHub API で確認しても
license
は空でした。ライセンス未記載は「自由に使える」ではなく「利用条件が示されていない」状態なので、商用利用の可否を判断できません。手を入れて使う前に、ここを見落とさないでください。
既成ワーカーが悪いという話ではありません。Hub のワーカーは有志が公開しているものが多く、今回のように README が実装に追いついていないことがあります。Required と書かれていても、handler を読むまでは信用しない。 ここが今回得た実務上の教訓です。
そのほか実測で分かったこと
コツ
Hub 経由のビルドは無料でした。ビルドを何度か回しても残高は $9.98
のまま変わりません。ただし tests.json に書いたテストはビルド時に実際の GPU
で実行されるため、テストの実行分は課金されます。
初回のビルドはレイヤー転送で失敗しました。
ERROR: error writing layer blob: failed commit on ref ...
unexpected commit digest ... failed preconditionDockerfile の記述ミスではなく、レイヤーをレジストリへ書き戻す段階で落ちています。19GB を超える単一レイヤーが関係している可能性はありますが、切り分けはできていません。ビルドの通し方は次回の主題なので、そこでまとめて扱います。
参照画像が決めるもの、プロンプトが決めるもの
素の Qwen-Image-Edit-2511 に参照画像を 1 枚渡しただけで、キャラクターの同一性は LoRA なしで再現されました。髪色・瞳の色・ヘッドセット・ジャケットの配色が一致します。公式が挙げている character consistency の改善は、少なくとも外見の属性については確認できます。
ただし、参照に渡す画像で結果が変わります。正方形のアイコン画像を渡すと、人物は一致しても線の太さや塗りが別物になりました。一方、既に公開している 16:9 のキービジュアルを参照にすると、画風ごと引き継がれます。参照画像は「人物の情報源」であると同時に「画風の情報源」でもある、ということです。
この性質は出力サイズにも効きます。前述のとおり ImageScaleToTotalPixels は入力の比率に従うので、16:9 の画像を参照にすれば、出力も 16:9 になります。 width が効かないワーカーでも、参照画像の側から比率を決められるという回避策です。
10 枚ほど生成する過程で、役割分担もはっきりしました。最初につまずいたのは手のポーズです。「開いた手」と書いても、3 案とも指差しになりました。原因はプロンプトではなく 参照画像が指差しだったこと でした。ポーズの違う別のキービジュアルを参照に差し替えると、プロンプトをほぼ変えないまま開いた手になります。
一方で背景は上書きできました。参照画像の背景 (別記事のダイアグラム) がそのまま残っていたので、「背景を全部消して無地の壁にする」と明示的に書いたところ、意図どおりに置き換わりました。柱の高さの比率も「左を右の約 2 倍に」と書けば反映されます。
| 決まるもの | 決めているのは | プロンプトで上書きできるか |
|---|---|---|
| 出力の縦横比 | 参照画像 | できない (width は無視) |
| 画風・線の太さ・塗り | 参照画像 | 部分的にできる |
| 人物のポーズ・手の数 | 参照画像 | ほぼできない |
| 背景の内容 | 参照画像 (初期値) | できる (明示的に書けば) |
| 物体の配置・相対サイズ | プロンプト | できる |
| 表情 | プロンプト | できる |
つまり 参照画像が人物とレイアウトの骨格を決め、プロンプトは環境を決める という分担です。狙ったポーズがあるなら、プロンプトを書き足すより、そのポーズの参照画像を用意するほうが早いという結論になりました。
なお、使ったワークフローは cfg が 1 に固定されており、プロンプトへの追従性を上げる余地がありません。この制約が上の表にどこまで影響しているかは、次回、自前のワーカーで設定を開けたうえで扱います。
この記事のキービジュアルも RunPod で作りました
実際に、本記事のキービジュアルは Gemini ではなく、ここで検証した RunPod 上の Qwen-Image-Edit-2511 で生成しています。手順は次のとおりです。
- 既に公開している 16:9 のキービジュアルを参照画像として渡す (人物・比率・ポーズをここから取る)
- プロンプトで画風と背景、置きたい物体を指定する
- 出力 1360×768 を、配信用に 1600×900 へ変換する
画風の方向性を変えた 3 案を同時に投げて、その中から選びました。1 枚あたり 1 セント程度なので、枚数を打って選ぶほうが、1 枚を作り込むより速くて安いというのが実感です。
FIXIT の運用 — 課金が絡む検証は本番から切り離す
GPU の検証は、判断を間違えたときの跳ね返りが課金という形で来ます。動かしっぱなしに気づくのが翌日、ということが起こり得ます。そのため、検証用のリソースは本番の構成管理から切り離した使い捨ての場所に置き、セッションが終わるたびに削除して、管理画面で残っていないことを目視で確かめる 手順にしています。状態ファイルを信用しません。
もう 1 つ決めているのは、測る対象を先に紙に書いてから触ることです。単価・起動時間・生成時間・失敗の内容。後から取り直せない値は、その場で記録しないと消えます。今回のように「README とコードが食い違っていた」という発見も、遭遇した時点で書き残さないと、解決した後には思い出せません。
今回も、料金と GPU の在庫を調べる担当と、ワーカーの中身を読む担当を分けて並行で進めました。この進め方は Claude Code のセッション間メッセージングにまとめています。
まとめ — 移せる見込みは立った。ただし自前で作る必要がある
判断材料としては揃いました。ワーカーを止めておける運用にできるなら、費用は Gemini の 1/12 まで下がります。生成そのものは 9 秒遅くなる程度です。モデルは Qwen-Image-Edit-2511 を 24GB に載せる前提で進められそうです。ただし前述のとおり、起動待ちの時間は安定しません。
一方で、既成ワーカーでは出力サイズを制御できませんでした。README を信用せずコードを読んだ結果、ワークフローごと作り直す必要があると分かった、というのが結論です。そこで、自前のワーカーを作ることになりました。
その顛末は ComfyUI ワーカーを自前で作るにまとめました。ワークフローをどう組み直したか、そして 30 分のビルド上限に 4 回はねられた記録です。
生成 AI の推論基盤をどこに置くか、API と自前 GPU のどちらに寄せるかは、枚数ではなく運用の形で決まります。同じ判断で迷っている場合は、AI 駆動開発やお問い合わせからご相談ください。
本記事の数値はすべて 2026 年 8 月 16 日の実測です。参照した一次情報は RunPod の料金ページ、RunPod Serverless の料金ドキュメント、RunPod Hub の概要、Gemini API の料金ページ、Qwen-Image-Edit-2511 のモデルページ、Qwen 公式ブログ、および検証に使った既成ワーカーです。