自社サーバーでLLMを動かすといくらかかるのか。この根源的な問いに、ベンチマーク根拠付きで答えるツール「bindwidth」がGitHubで3日95スターを獲得した。金融・医療の情シスが導入検討で使い始めており、AI調達の意思決定プロセスそのものを変えつつある。エンジニア視点で、この動きの本質を読み解く。

何が起きたか

GitHubに公開された juxhinr/bindwidth が、公開から3日で95スターを集めた。これはオンプレミス環境でLLM推論を動かす際の、GPU台数・電力消費・総所有コスト（TCO）を自動見積もりするツールだ。特筆すべきは「Evidence-aware（根拠明示型）」を謳っている点で、単なる机上計算ではなく、実測ベンチマークデータを根拠として数字を提示する。ChatGPT型のAIをクラウド利用ではなく自社サーバーで動かしたいが、機密データを外に出せないため試算が難しい――そんな金融・医療業界の情シス部門が、導入検討の初期フェーズで使い始めているという。3日で95スターというペースは、GitHubのトレンド入りに十分な速度であり、同種のツールが不足していた市場のギャップを的確に突いたことを示す。

なぜこのニュースが重要か

オンプレLLMの議論はこれまで「動くか動かないか」の技術検証に偏っていた。しかし本当のボトルネックは、稟議を通すための数字を誰が出すかにあった。エンジニアがベンチマーク結果をエクセルに貼り付け、経理が電気代を別途試算し、調達がGPU価格を追う――このバラバラな作業が、PoC止まりの最大の要因だった。bindwidthのようなツールは、この分断を一枚のレポートに統合する。ここで重要なのは「Evidence-aware」というキーワードだ。GPT-4クラスのモデルなら70B相当パラメータで推論時にVRAM140GB前後、H100で2〜4枚、そこに冗長化を加えると初期投資は数千万円規模になる、といった数字は誰でも概算できる。しかし稟議を通すには、そのトークン/秒スループットがどのベンチマーク（MLPerf、vLLMの実測値など）に裏付けられているかまで示す必要がある。この「根拠のトレーサビリティ」を自動化できることが、LLM調達の意思決定サイクルを月単位から週単位に短縮する。

技術的な深掘り

TCO試算の難しさは、変数が非線形に絡み合う点にある。第一にバッチサイズと量子化の選択だ。INT8量子化でVRAM要求は約半分になるが、精度低下が業務要件を満たすかは別問題で、これを「同一モデル」として単純比較すると経営判断を誤る。第二にKVキャッシュのサイズだ。長文コンテキストを扱う法務・医療用途では、モデル本体より推論時のKVキャッシュがVRAMを圧迫し、実効スループットが公称値の半分以下になるケースがある。第三に電力単価とPUE（電力使用効率）だ。H100は1枚あたり最大700W、8枚構成のDGXなら5.6kW、24時間365日稼働で年間電力消費は約49MWh。日本の産業用電力単価20円/kWh換算で電気代だけで年98万円、PUE1.5のデータセンター込みなら約147万円に膨らむ。bindwidthがこれらの変数をどこまで正直にモデル化しているかが、実用ツールとして生き残るかの分水嶺だ。逆に言えば、変数を隠蔽して「クラウドより安い」と結論に誘導する設計にすれば、それは単なるマーケティング資料に堕する。95スターの背後にあるのは、「隠さない見積もり」への飢餓感だと解釈すべきだ。

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

第一に、自社の機密度マップを作ることだ。全業務をクラウドLLMに乗せるのは非現実的だが、逆に全てをオンプレ化するのも過剰投資になる。データ機密度と処理頻度でマトリクスを切り、オンプレ化する業務を上位20%に絞り込む作業を情シスに指示すべきだ。第二に、TCO試算を単一ベンダーの提案書に依存させないことだ。bindwidthのようなOSSツールを社内で回し、ベンダー見積もりと突き合わせる体制を作る。数字の根拠を検証できない稟議は、そもそも通してはならない。第三に、3年後の減価償却まで見据えたロードマップを描くことだ。GPU価格は2〜3年で半減する可能性が高く、初期に全額投資するより段階導入した方が総コストが下がる想定シナリオもある。今日の見積もりを、明日の設備投資計画にどう接続するか。ここに経営判断の本質がある。