分析：オープンウェイトモデルのセルフホスティング——導入を左右する採算計算と、誰も予算に織り込まないコスト

自前ホスティング（セルフホスティング）をめぐる議論は、両陣営とも粗雑な主張に陥りやすいという点で厄介だ。一方の陣営は、重みが無料である以上、自前でインフラを持つ方が安上がりだと当然のように考える。もう一方の陣営は、ハイパースケーラーの方が稼働率で自分たちより優れているのだから、自前でアクセラレータを運用すべきではないと当然のように考える。

両者は同じ曲線を両端から眺めているにすぎない。ホスティング型の推論は変動費であり、自前ホスティングは固定費である。実際の意思決定はすべて、特定のワークロードがその損益分岐点に対してどこに位置するかという問いに帰着する。

比較の構図

両者を同じ単位で書き出してみよう。

ホスティング型のAPIはトークン単位で課金される。1日あたり入力1000万トークン、出力200万トークンであれば、料金は予測可能な額になり、利用量に比例して線形に増減する。静かな週末には請求額も下がる。

自前ホスティングはアクセラレータの稼働時間単位で課金され、リクエストが来ようが来まいが料金は発生する。最新世代のデータセンター向けGPUのレンタル価格は、多くのプロバイダで1枚あたりの時間単価が1桁台前半のドルに収まるが、地域やコミットメント、プロバイダの階層によって大きく変動する。自社保有のハードウェアであれば、これが設備投資に加えて電力、冷却、減価償却というかたちに置き換わり、償却後で見ればおおむね同程度のレンジに落ち着く。要は、どちらも「時間単位」であって「トークン単位」ではないという点が肝心なのだ。

したがって、計算式はこうなる。

多くのチームが見落として痛い目に遭うのは2行目だ。ピーク負荷に合わせてサイジングされたクラスタが、平均稼働率15%で運用されているとすれば、バースト的にしか来ないトラフィックのために、24時間ずっとピーク容量分の料金を払い続けていることになる。フル稼働時には有利に見えたトークン単価の比較は、実際の平均稼働率で見れば6倍もずれていることになる。

スループットはソフトウェアの性質である

最もよくある分析上の誤りは、スループットがハードウェアによって決まると考えることだ。実際には、少なくとも同じ程度にサービング（提供）スタックによって決まる。

バッチ処理が支配的な要因だ。大型アクセラレータでリクエストを1件ずつ処理すれば、その能力の大半は無駄になる。処理中のバッチが空くのを待たず、新しいリクエストを随時合流させる連続バッチ処理（continuous batching）を使えば、同じカードでもスループットを何倍にも引き上げられる。単一リクエストのベンチマークをもとに組み立てた自前ホスティングのコストモデルは、その倍率の分だけ誤っていることになる。

量子化は、何が収まるかを変える。重みを8ビットや4ビットの精度で提供すればメモリ要件は大幅に減り、モデルを2枚のカードから1枚に収められる場合がある。しかも1枚は2枚の半額というだけではなく、半額であると同時にインターコネクトの複雑さという厄介事も丸ごと取り除いてくれる。最近の学習後量子化（post-training quantisation）手法は、多くのタスクでほぼ無劣化と言えることが多いが、この「多くの」「ことが多い」という留保こそが重要だ。劣化の出方はタスクごとに異なり、平均スコアではそれが隠れてしまうため、自分自身の評価セットで確認する必要がある。

モデルサイズは、最も効果の大きいレバーだ。自前ホスティングの経済的な妥当性は、その大部分が、1台のアクセラレータで多数の同時リクエストを処理できるほど小さいモデルを運用できるかどうかにかかっている。オープンウェイトのエコシステムが小規模モデルの領域で着実に改善を続けてきたことこそが、ごく普通のプロダクトにとって自前ホスティングを現実的な選択肢にした要因である。逆に、本当にフロンティア級の大規模モデルを必要とするタスクであれば、ハードウェアの請求額はまるで違うものになり、自前ホスティングの根拠はかなり弱くなる。

最初の見積もりに抜け落ちがちな4つの項目

これまで見てきた自前ホスティングの初期見積もりは、どれも同じ抜け落ちを共有している。

冗長性。 ノード1台はデモに過ぎない。本番環境では、異なる障害ドメインに最低でも2台、さらにローリング再起動のための余裕分が必要になる。これは10%程度の調整では済まない。トラフィックの増加を考慮する前の段階で、ハードウェア費用の項目がしばしば倍になる。

エンジニアリング時間。 誰かがサービングスタックを構成し、バッチパラメータを調整し、オートスケーリングを設定し、ヘルスチェックを書き、カーネルを壊すドライバのアップグレードに対処し、深夜2時にスループットが崩壊すればポケベルで叩き起こされる。その人物にかかる現実的な人件費（フルロード人件費）で計算すれば、エンジニア1人の年間稼働のごく一部だけで、中規模ワークロードのGPU費用全体を上回ることも珍しくない。これは最も見落とされがちな項目でありながら、しばしば最終的な結論を左右する項目でもある。

評価。 自前ホスティングとは、たいていの場合、より小さなモデルへの移行を意味する。それは品質の変化であり、それが許容範囲かどうかを確認するには、評価セット、比較実験、そして結果を解釈する判断力が必要になる。これは正真正銘の作業であり、コスト削減効果が現れるより前に発生し、しかもモデルをアップグレードするたびに繰り返される。

アップグレードのトレッドミル。 ホスティング型APIは、こちらが何もしなくても足元で改善されていく。一方、自前ホスティングのスタックが改善されるのは、誰かがその作業をしたときだけだ。新しいオープンリリースを評価し、サービングパラメータを再調整し、評価セットを再実行し、移行を計画する。この作業は繰り返し発生するものとして予算を組んでおくべきだ。実際にそうなのだから。

自前ホスティングが明確に有利になるとき

ここまでの話は、自前ホスティングに反対する論拠ではない。自前ホスティングが素直に正解となる、特定の条件がある。

安定して大量、かつ予測可能な処理量。 バッチ分類、文書処理パイプライン、埋め込み生成、モデレーションのキューといった、絶えず稼働し続けアクセラレータを常時働かせておけるワークロード。これらは自前ホスティングの候補として最良の部類であり、その多くが小型モデルで済むという事実が、その根拠をさらに強めている。

小型モデルで十分に対応できるほど狭いタスク。 分類、抽出、ルーティング、構造化タグ付け、特定分野に限定した翻訳など。適切に選ばれた小型モデルが許容できる品質で仕事をこなせるなら、フロンティア級APIとのリクエスト単価の経済性には、勝負にならないほどの差がつく。

オフライン運用、またはエアギャップ環境。 どんな価格でもAPIを利用できない状況。この場合、意思決定はそもそも別の次元で下される。

コストとは関係のない理由

自前ホスティングを支持する最も強力な根拠のなかには、計算とは無縁のものもある。

データの所在地と規制上の制約。 データが特定の法域やネットワーク境界の外に出せない場合、自前ホスティングがコンプライアンス上唯一許される構成であることが多く、たとえコストが高くついてもそれが正しい選択であり続ける。

厳格なレイテンシの下限。 ホスティング型エンドポイントへのネットワーク往復には、ローカル推論にはない下限が存在する。音声、リアルタイム支援、エディタ内補完のように、許容時間が厳しいインタラクティブな体験では、その下限が最適化の対象ではなく、そもそもの要件そのものになりうる。

挙動の安定性。 ホスティング型モデルは、こちらの知らぬ間に挙動が変わりうるが、バージョンを固定したローカルのチェックポイントは変わらない。特定のモデルの挙動に合わせて綿密にチューニングされたシステムにとって、この安定性には、どんな請求書にも載らない価値がある。

ベンダーのロードマップからの独立。 廃止スケジュール、レート制限、地域ごとの提供状況、利用規約は、いずれも他者が下す決定だ。重みを自ら保有すれば、その依存関係からは解放されるが、その代わりに他のすべてを自分で背負うことになる。

多くのチームが行き着く答え

実務上、本番環境でよく見られる結末はどちらの極端でもない。それはルーティング方式だ。小型の自前ホスティングモデルが、量が多く内容もよく理解されているトラフィックの大部分を処理し、ホスティング型のフロンティアモデルが、難しい末尾部分——曖昧なケース、長文の文書、コストよりも品質が優先されるリクエスト——を処理する。

これによって、コスト削減効果の大部分を取り込める。なぜなら、費用がかさむのは高頻度の部分だからだ。しかも同時に、小型モデル単体では到達できない品質の上限を維持できる。障害への耐性も高い。ローカルクラスタが停止しても、トラフィックはサービス停止ではなく、コストは上がるもののAPIへとフォールバックするだけで済む。

一つだけ譲れないのは、この意思決定を実際の数字に基づいて下すべきだということだ。自分たちの稼働率曲線を測定し、バッチ処理を有効にした状態でスループットをベンチマークし、エンジニアリングの項目を実際の給与水準で算定し、評価作業もそこに含めること。 それをやれば、答えはたいてい自ずと明らかになる。それを省けば、データを手にする前に採った立場を、後からひたすら正当化し続けるはめになるだろう。