自社構築か API か: アダルト画像生成を運用する本当のコスト

画像生成における自社構築と外部 API の議論は、たいてい GPU の時間単価から始まり、そこで終わってしまいます。その数字は確かに実在しますが、予算の中では最も小さい項目でもあります。自社構築パイプラインで高くつくものはすべて、レンタルの請求書には現れない部分です。

自社ホスティングが実際に伴うもの

動作するパイプラインは、モデル、カスタムノード、重みのグラフであり、そのどれもが足元で動きうるバージョンです。ノードパックが更新されればパラメーターの意味が変わります。ベースモデルが差し替われば、丁寧に調整したプリセットの傾向がずれます。これは特殊な出来事ではなく日常です。エンジニアリングコストはパイプラインを一度作ることではなく、その下のエコシステムが動き続けるなかで出力を安定させ続けることにあります。

次にキャパシティの問題があります。生成需要は本質的にバースト型で、夜と週末に跳ね上がり、平日の午前中は閑散とします。ピークに合わせて用意すれば、週の大半はアイドル状態のシリコンに支払うことになります。平均に合わせれば、ユーザーが最も使いたい時間帯にちょうど待たされます。GPU のオートスケールは可能ですが、コールドなワーカーは数十ギガバイトの重みを読み込むまで何も処理できないため、スケールアップは秒単位ではなく分単位になります。

見積表に決して載らないコスト

• オンコール。土曜の午前 3 時に落ちる GPU マシンは誰かの夜を奪いますし、画像生成はそもそも夜間と週末に集中するワークロードです。
• ストレージと保持。入力と出力はディスクに溜まり続け、誰も削除しないまま静かに負債になります。
• モデルの変化。アップグレードのたびにプリセットのリグレッションテストをやり直す、実体のある作業が発生します。
• キューの実装。バックプレッシャー、リトライ、重複排除、クラッシュ後の復旧は、GPU を借りるかどうかに関係なく同じ問題です。
• セキュリティ。推論ポートが開いた GPU ホストは格好の標的ですが、関連ソフトウェアは敵対的なインターネット公開を想定して書かれていません。

自社ホスティングが本当に有利な場合

これは一方的な議論ではありません。パイプラインそのものがプロダクトである場合、つまり自社でモデルを学習またはファインチューニングしている場合、グラフの構成そのものが差別化要因である場合、あるいは規制上、自社が管理するインフラ内で処理を完結させる義務がある場合は、自前で運用すべきです。安定して高く、予測可能な処理量も計算を変えます。24 時間フル稼働している GPU は、1 枚あたりでは従量課金より安くなります。

警戒すべきなのは中間の状況です。処理量は中程度、需要はバースト型、チームは小規模、そしてパイプラインは目的ではなく手段にすぎない。この組み合わせは自社ホスティングの運用コストを満額支払いながら、その利点をほとんど回収できません。

API が有利な場合

API はキャパシティの問題を単なる費用項目に変換します。アイドルのシリコンも、コールドスタート対策の実装も、アップグレードで潰れる週末も、ハードウェアのオンコール当番もありません。連携は HTTP の 4 回の呼び出しになり、処理量の問題は他社の運用課題になります。

市場投入までの時間も、数週間から半日程度に縮まります。まだ検証段階の機能であれば、これはユニットエコノミクスより重要です。1 日でリリースしてユーザーに求められていないと分かるほうが、GPU 群を調達したあとに同じことを知るよりはるかに安上がりです。

5 分で決められる判断基準

1. パイプラインそのものが自社のプロダクトですか。そうなら自社構築です。
2. GPU を本当に飽和させ続けられるほど、処理量が多く安定して予測可能ですか。そうなら自社構築が採算に乗り始めます。
3. GPU のオンコールを担当する人がいて、本人もそれを分かっていますか。いないなら API を使うべきです。
4. まだ機能を検証中ですか。まずは API で、需要曲線が見えてきたら再検討しましょう。

あまり語られないハイブリッド構成

この 2 つは排他的ではありません。よくある現実的な構成は、予測しにくい一般公開向けトラフィックを API に任せ、安定した社内のベースライン負荷を自社ハードウェアで吸収するやり方です。これは移行の断崖もなくします。連携を 1 つの HTTP 境界の内側に収めておけば、後から乗り換えるのは設定変更であって書き直しではありません。

よくある質問