Kimi K3のセルフホスティング：ハードウェアコスト20%増で、タスク解決率20%向上

更新（2026年7月29日）：GLM-5.2に使用された8x B200ノード（合計1.5TBのHBMでKVキャッシュの余裕がない1.4TBのウェイトを持つK3はメモリ予算に収まらない）と同じセットアップで、SGLangで提供されるKimi K3を実行しました。そのため、この実行では8x B300ノードを使用しました。これは、GPUあたり192GBではなく288GBのHBM、ノードあたり2.3TBをもたらします。これは、レンタルプロバイダーによりますが、8x B200セットアップよりも平均で約20%高いハードウェアコストになります。 私たちの実行では、K3は16の同時セッションを処理しました（GLM-5.2は24を処理）。集計トークン処理能力は約30%低く（16ユーザーで122 vs 170 tok/s）、中央値タスク時間は約50%長くなりました（38 vs 26分）。これにより、K3はClaude Codeベースラインよりも約8倍遅くなります。しかし、K3は品質でそれを補い、タスクの86.4%を解決しました。これはGLM-5.2とOpus 4.8の両方（両方で62.5%）よりも24パーセンテージポイント高くなっています。注意点として、SWEBench Proからの私たちのベンチマークタスクがK3の学習データに含まれている可能性があるため、その解決率は注意して扱う必要があります。この記事のグラフのみが新しいK3データで更新されています。 01 なぜ今年のトークン請求額が急増したのか 今年の前半には、警告の兆候があちこちにありました。GitHub Copilotはトークンベースの請求に切り替えました[1]。Uberは年間のAIツール予算をわずか4ヶ月で使い果たしました[2][3]。開発者は月額29ドルから750ドルへのコスト増を予測していると報告しました[4]。私たちはそれに"tokenmaxxing"、"token panic"、"token budgets"といった言葉さえ発明しました。 現在、平均的な従業員はAI APIの使用に年間約140ドルを費やしています。無害に聞こえますが、テールエンドを見ると、90パーセンタイルは年間約7,300ドルに近く、99パーセンタイルは年間約90,000ドルに近づきます。多くの組織にとって、エージェンティックAIの採用は始まったばかりなので、今後数年間でこれらの数字が変化すると予想されます。 請求額がこれほど変動しやすいのはなぜでしょうか？それはAIエージェントの使用方法によるものです。現在、主要なモデルプロバイダーのARRの70%以上[4]はコーディングユースケースから来ています。ワークフローのより多くの部分をエージェントに任せるほど、トークン請求額は高くなります。 多くの組織は、OpenAIやAnthropicのような主要なフロンティアモデルプロバイダーのAPIアクセスを通じて、AIコーディングエージェントの採用を開始します。数ヶ月後、多くの組織が、トークン価格モデルが高価になる、ユーザーがより新しく高価なAIモデルにアップグレードする、組織内のエージェント採用がブームになるなど、さまざまな理由で代替案を少なくとも検討しています。 そこには検討する価値のある賢明な代替案があります。APIルーターに切り替えること、日常的な作業にはより安価なモデルティアを使用し、困難な20%のみをフロンティアモデルにエスカレートさせることなどです。しかし、トークン消費量が大幅に増加した場合、または機密データを扱っている場合は、APIアプローチを完全に放棄し、独自の推論スタックをセットアップすることを検討したいかもしれません。 ハードウェアの所有権が問題になる場合、GPUのレンタルまたは購入が実際に何をもたらすかを理解する必要があります。いつ切り替えを検討すべきでしょうか？自分で判断するためのツールを提供しますので、読み進めてください。 02 プールは24時間年中無休で利用しますが、チームは1日8時間しか使用しません したがって、GPUの購入またはリースが理にかなっているかどうかを調査することにしたとします。正しく設定されると、Anthropic、OpenAI、その他のモデルプロバイダーが提供するものと同様に、コーディングツールに接続できるAPIエンドポイントが得られます。 フロンティアAPIとは対照的に、独自のAPIエンドポイントには1秒あたりの出力トークンに上限がありますが、システムが完全にロードされている場合にのみそれに達します。一人で作業している開発者は、その上限のほとんどを使用しませんが、同じハードウェアが48の同時エージェントセッションを処理する場合は話が異なります。上限は、モデル、GPU、およびサービング構成によって決まります。 Fig. 01 同時ユーザー数に対する総トークン/秒 モデルAをハードウェアセットアップBで実行する例です。トークン消費量ごとに課金されるAPI使用モデルとは異なり、独自のセットアップを実行することは、基盤となるインフラストラクチャとそれを実行し続けるコストを支払うことを意味します。ごく一部の例外を除き、トークンを生成していない場合でも、そのための支払いが発生します。そのトレードオフがあなたにとって有効かどうかは、2つの質問で決まります。1つ目は、プールのどれだけを使用しているかです。まず、それに対処しましょう。 ピーク時にサイズを決定し、24時間年中無休で支払います。ヘッドカウントではなく、利用率がコストケースを成功させるか失敗させるかの鍵となります。実際の需要は一定ではなく、スパイク状です。多くの組織にとって、コーディングタスクのトークンは夜間はほぼゼロになり、午前中に増加し、昼食時に目に見えて減少し、午後に再びピークに達します。これは、ピーク負荷のためにハードウェアを購入しますが、24時間年中無休で支払うことを意味します（GPUスポットインスタンスをレンタルしない限り、これらはこのケースでは信頼性が低くなります）。ピークの形状は、ボリュームと同じくらい重要です。単一タイムゾーンのチームは、タイムゾーン全体に分散された同じヘッドカウントよりも、トークン需要を狭いスパイクに集中させます。同じトークンでも、ピーク使用量は高くなりますが、より長く分散されます。 内部開発者ツールを提供するエンタープライズ推論ワークロードに関する公開データによると、平均GPU使用率は15〜22%[6][7]ですが、適切に管理されたデプロイメントでも通常25〜35%を超えることはめったにありません（これは寛大に見積もった場合です）。下のグラフは、数週間前のTechWolf[14]の友人からの2日間の実際のトークン使用量を示しており、私たちが説明したことを正確に反映しています。 Fig. 02 実生活のトークン使用量はスパイク状で、組織ごとに異なります ここで有利に働く可能性のある新たなトレンドが1つあります。エージェント駆動型ワークフローで組織が成熟するにつれて、人々からのセッションよりも自動化されたエージェントからのセッションが増えています（スケジュールされたジョブ、午前3時にバグレポートを自律的に引き受けるエージェントなど）。これにより、オフィス時間に従わない作業が可能になります。意図的にスケジュールされた場合、これらの自動化されたセッションは、すでに支払っている夜間の容量を吸収できます。 次に、2番目の質問、何人の開発者がボックスを共有すると遅く感じるか、に対処しましょう。 03 48人の開発者が1台のボックスを共有するとどうなるか 1人の開発者しかいないトークンプールは素晴らしいです。トークンは、あなたが読み取るよりも速くストリーミングされます。問題は、5人、10人、または20人の同時開発者セッションで何が起こるかです。AIコーディングエージェントは、トークンを消費するだけでなく、Webを閲覧したり、ファイルを実行したり、コードをコンパイルしたりする、貪欲でバースト的なクライアントだからです。 フロンティアモデルプロバイダーAPIから移行する際に、主な懸念事項の1つは開発者エクスペリエンスです。ベンチマーク結果を見ると、モデルが特定のGPUセットアップでどの程度うまく機能するかを測定するために、トークン/秒がよく使用されます。理解しやすい指標ですが、この文脈ではそれほど有用ではありません。結局のところ、満足のいく結果なしに何千ものトークンを消費することもできますし、より小さいモデルに切り替えて最終的に10倍のトークンを使用することもできます。 より良い価値提供の単位は、タスクが正常に完了することです。これは一般的に定量化するのが難しいですが、以下での分析でよく参照することになります。タスクが最初から最後までどのくらいの時間がかかるか、そしてエージェントがモデルを待っている間にトークンがどれだけ速くストリーミングするかを理解したいはずです。 より良い価値提供の単位は、タスクが正常に完了することです。タスク完了を測定可能にするために、ScaleLabsのSWEBench Proのタスクサブセットを使用しています。これは、長期間にわたる一般的なコードエンジニアリングタスクのセットです。個々のモデルを比較するために最もよく使用されますが、私たちのチームは、組織にとって意味のある実際のユースケースで、さまざまなモデルとハードウェアの組み合わせのコストとパフォーマンスを比較するために、より現実的で十分に挑戦的なワークロードを作成するためにこれを使用しています。 いくつかのグラフが、選択したモデルとハードウェアの組み合わせのパフォーマンスをさらに評価するのに役立ちます。まず、コーディングタスクのサブセットを実行します。