オンプレLLMの原価が、モデル名とリクエスト数を入れるだけで数分で試算できる時代が来た。GitHubトレンドに登場したbindwidthは、公開初日で55スターを獲得。GPU台数・メモリ・電気代・年間総コストを、根拠論文と実測値に紐づけて算出する。クラウドAPIと自社運用のどちらが安いか、稟議で数字を示せる武器になる。

何が起きたか

GitHub Trendingにjuxhinr/bindwidthという新顔が登場した。公開初日で55スターと、派手なバズではないが、テーマの筋がいい。売りは「Evidence-aware on-prem LLM inference sizing and TCO calculator」。つまり、自社サーバーでLLMを推論運用するときの、GPU台数・VRAM要件・電力コスト・年間総保有コスト(TCO)を、モデル名と想定リクエスト数(QPSやトークン量)を入力するだけで見積もれるツールだ。

特筆すべきは「Evidence-aware」の一語。試算値の裏に、根拠となる論文や実測ベンチマーク値をひも付ける設計になっている点だ。単なる電卓ではなく、情シスや技術部門が経営会議に持っていける「出典付きの数字」を出す。クラウドAPI課金とオンプレGPU運用のコスト比較を、稟議書に添付できる形で吐き出せる、というのがコア価値である。

なぜこのllmインフラ試算が重要か

LLMの自社運用は、これまで「やってみないとコストが読めない」ブラックボックスだった。NVIDIA H100を何枚積むのか、KVキャッシュでVRAMがどう膨れるのか、バッチサイズをどう設計するかで、必要GPU数は簡単に2〜3倍ぶれる。ベンダー見積もりに頼ると、安全側に倒された過剰スペック提案が返ってくるのが常だ。

ここに「出典付きの試算ツール」が入ると、意思決定の構造が変わる。OpenAI APIの従量課金と、自社H100クラスタの償却+電気代を、同じ土俵で比較できる。感覚値ではGPT-4クラスのAPIを月1億トークン以上叩く企業なら、オンプレのほうが2〜3年で回収できる、というのが業界の相場感だが、これを自社のワークロードで実数値化できる意味は大きい。

さらに医療・金融・防衛といった「データを外に出せない」業界にとっては、オンプレ一択の中で「いくらかかるか」だけが論点だった。その論点に、出典付きで即答するツールが無料で出てきた、というのがこのニュースの本質だ。

技術的な深掘り

コードと仕様書から読み解くと、この手のTCO計算機で本当に難しいのは3点ある。第一に、モデルサイズからVRAM要件を導く式だ。パラメータ数×量子化ビット数だけでは足りず、KVキャッシュ(コンテキスト長×バッチサイズ×レイヤ数×2×hidden_dim)が支配的になる。長文プロンプトを想定するなら、モデル本体より推論時メモリのほうが大きくなるケースが普通にある。

第二に、スループット推定。GPU 1枚あたりのtokens/secは、vLLMのcontinuous batchingを使うか否か、投機的デコーディングを入れるか否かで数倍変わる。ここを「実測値ベース」で持つのか「理論ピーク値」で持つのかで、必要台数は倍変わる。bindwidthが"Evidence-aware"を名乗るなら、この係数の出典管理がキモになる。

第三に、電力コスト。H100 1枚のTDPは700W、8枚構成のサーバーはPUE込みで実効10kW近い。日本の産業用電力単価30円/kWh前後で計算すると、1ノードあたり年間260万円強の電気代だ。GPU本体の償却より電気代のほうが早く効いてくる設計になっているかは、コード側の係数を見て検証すべきポイントである。

経営者として次に取るべき動き

第一に、自社の月間トークン消費量を計測する仕組みを今週中に入れる。APIログから入力・出力トークンを分けて集計するだけでいい。この数字がないと、オンプレとクラウドの比較はスタートラインにも立てない。

第二に、bindwidthのようなツールで、現行ワークロードの「オンプレ換算コスト」を試算し、クラウド請求書と並べる。目安として、月間5000万トークンを超えるあたりから、オンプレ検討の実利が出始める。稟議に必要なのは感覚ではなく、出典付きの数字だ。

第三に、機微データを扱う業務があるなら、コストが逆転しなくてもオンプレLLM導入のPoC予算を確保しておく。規制側の要求は今後厳しくなる方向にしかない。「安いから」ではなく「出せないから」で意思決定する日は必ず来る。原価が見える今のうちに、判断材料を揃えておくべきだ。