Kimi K3とGLM-5.2のセルフホスティング：GPUハードウェアコスト vs タスク解決率
エグゼクティブ・サマリー
AIコーディングエージェント向けにKimi K3やGLM-5.2のようなフロンティア級のオープンウェイトモデルをセルフホスティングする場合、ハードウェア支出、並行実行数、およびタスク解決の品質との間に直接的なトレードオフが生じます。Kimi K3はGLM-5.2よりも約20%多くのハードウェア投資を必要とし（8×B200ノードではなく8×B300ノードが必要）、SWEBench Proタスクにおいて86.4%の解決率を達成しています。これはGLM-5.2およびAnthropic Opus 4.8（ともに62.5%）の両方を上回る数値です。
Kimi K3 vs. GLM-5.2: パフォーマンスとハードウェア要件
Kimi K3の1.4TBという膨大なウェイト・フットプリントにより、KVキャッシュのための十分なヘッドルームがないため、8×B200ノード（合計1.5TB HBM）のメモリ予算内に収めることができません。その結果、K3には8×B300ノードが必要となり、これはGPUあたり288GBのHBM（ノードあたり2.3TB）を提供します。これにより、ハードウェアコストは約20%増加します。
スループットとレイテンシのトレードオフ
Kimi K3によるモデル品質の向上は、速度と並行実行数の犠牲の上に成り立っています：
- 並行実行数: GLM-5.2が24セッションをサポートするのに対し、K3は16セッションをサポートします。
- スループット: K3の総トークンスループットは、GLM-5.2よりも約30%低くなっています（16ユーザー時で122 vs 170 tok/s）。
- タスク完了時間: K3のタスク中央値時間は、GLM-5.2よりも約50%長くなっています（38分 vs 26分）。これは、Claude CodeのベースラインよりもK3が約8倍遅いことを意味します。
これらのパフォーマンス上のペナルティにもかかわらず、K3の優れた解決率（86.4%）は、組織がより高いレイテンシを許容できるのであれば、複雑なエンジニアリングタスクにおいてより効果的なツールとなります。
コーディングエージェント向けGPUインフラストラクチャの選択肢
適切なハードウェアの選択は、モデルの品質とシステムがサポートする必要のある開発者数のバランスに依存します。
ハードウェアティアとモデルの適合性
| ハードウェア構成 | 推奨モデル | 快適な並行実行数 | パフォーマンスに関する注記 |
|---|---|---|---|
| DGX Spark | Qwen3.6-35B-A3B | 1 ユーザー | 低速; Claude Codeより約3倍遅い |
| 1× H200 | Qwen3.6-35B-A3B | 32 ユーザー | 高スループット; 48ユーザー時でClaude Codeより2倍遅い |
| 4× H200 | DeepSeek-V4-Flash | 32 ユーザー | 品質と速度のバランスが良い |
| 8× B200 | GLM-5.2 | 8 ユーザー | フロンティア級の品質; 8ユーザーを超えると大幅に低下 |
| 8× B300 | Kimi K3 | 16 ユーザー | 最高レベルの解決率; 高いハードウェアコスト |
「崩壊（Collapse）」現象
vLLMを使用した高並行実行テストでは、Qwen3.6やDeepSeek-V4-Flashのようなモデルのスループットは、48〜64ユーザーを超えると徐々に低下するのではなく、急激にクラッシュすることがよくあります。これは、推論エンジンのデフォルトパラメータ、prefillとdecodeリクエストのバランス、およびKVキャッシュのサイズ制限に起因します。
コスト分析：購入 vs レンタル vs API
セルフホスティングの財務的な実現可能性は、GPUの利用率によって決まります。ハードウェアは24時間365日稼働していますが、開発者の需要はスパイク状（通常、平均利用率は15〜22%）であるため、「損益分岐点」はモデルによって異なります。
所有における利用率の閾値
- ハイエンドラック (B200): B200ラックは、フロンティア級の品質を求めるタスクにおいて、フロンティアAPIよりもコスト効率が良くなるには、わずか15%の利用率で済みます。
- ミドルレンジラック (4× H200): 4× H200構成は、DeepSeek-V4-Flash APIの価格に対抗するために89%の稼働率を維持する必要があります。これは主に、DeepSeekのAPIがキャッシュされた入力トークン（コーディングエージェントのトークンの最大98%）に対して高度に最適化されているためです。
中間策としてのレンタル
GPUのレンタルは、特定のモデル（例：Qwen3.6では35倍のコスト削減）においてAPIよりも大幅に安くなることがありますが、ワークロードが特別に最適化されていない場合、他のモデル（例：DeepSeek）ではAPIよりも高くなる可能性があります。
コミュニティの知見の統合
これらの調査結果に関する技術的な議論では、セルフホスティングにおけるいくつかの数値化できない利点と潜在的な最適化が強調されています：
- プライバシーと主権: セルフホスティングは、厳格なデータ居住要件（例：欧州やカナダの法律）を持つ組織や、機密性の高い医療データを扱う組織にとって極めて重要です。 | 制限のないユーティリティ: ローカルモデルは、レッドチーミングや情報セキュリティタスクを実行する際に、フロンティアAPIに関連する「拒否（refusals）」やアカウント停止を回避できます。
- 量子化: コミュニティのメンバーは、量子化バージョン（例：int4）を使用することで、フロンティア級のモデルをA6000のようなより小型で手頃なハードウェアで実行できる可能性があると示唆していますが、これには品質低下に関するさらなるベンチマークが必要です。
- 非同期ワークフロー: 非緊急の自動化タスク（例：夜間のバグ修正）をセルフホスティングGPUのアイドル容量を埋めるようにルーティングすることで、「利用率のギャップ」を埋めることができると主張する人もいます。