大規模推論におけるコーディングエージェントのベンチマーク評価

要約

本番環境でのコーディングエージェントのワークロードにおいて、Together Inference Engine は同一ハードウェア上で次点となる最速 OSS エンジンよりも31% 多い TPS（秒間トランザクション数）を提供し、飽和状態でも TTFT（最初のトークンまでの時間）が 2 倍改善されています。これらの向上は、ThunderMLA、カスタムカーネルの書き換え、実トラフィックに基づくエンドツーエンドのプロファイリングというフルスタック最適化によるものです。

多くの推論ベンチマークは、専用エンドポイントに単一のユーザーがアクセスする状況を測定します。数値は素晴らしいように見えますが、本番環境を分析するには役に立ちません。

本番環境では、数十から数百の並行リクエストを実行することになります。これらは同じ KV キャッシュ（Key-Value Cache）、同じメモリ帯域幅、同じ GPU サイクルを競合します。重要なのは、システムに負荷がかかった際に各ユーザーに何が起こるかです。

私たちはこのベンチマークをコーディングエージェントの課題に答えるために構築しました。これは推論に厳しいワークロードです：長い入力、高い並行性、そして負荷下でのレイテンシ劣化に対する許容度のなさがあります。

これはバージョン 1 です。開発が進むにつれて更新していきます。

コーディングエージェントのワークロードの特徴

コーディングエージェントのリクエストには多くのコンテキストが含まれます。編集中のファイル、周囲のコード、会話履歴、取得されたスニペットなどです。入力は長く、出力は意味のあるものですが範囲が限定されています。関数を生成しているのであり、エッセイを書いているわけではありません。

より困難な課題は並行処理です。多くのユーザーが同時にエンドポイントにアクセスし、これらのリクエストは単一ユーザーのベンチマークでは決して捉えられない方法で相互作用します。トラフィックが増加すると KV キャッシュ（Key-Value Cache）が満杯になり、スケジューリングの負荷が高まります。ユーザーごとのスループットが低下し、最初のトークンまでの時間（TTFT: Time To First Token）が上昇します。ある時点でシステムは実用性を失います。異なるエンジンがその限界に達するトラフィックレベルは非常に異なります。

私たちはこれをストレステストするために、大規模な生産環境におけるコーディングエージェントのトラフィックで観測されるリクエスト分布をモデル化した高トラフィックベンチマークを設計しました。プロンプト長は約 45k から 200k トークンの範囲で、現実的なコーディングセッションの成長をシミュレートし、生成長は平均して約 450 トークンです。主要な指標は TPM（1 分あたりの入力トークン数）、ユーザーごとの TPS（1 秒あたりのトークン数）、および p50 TTFT です。

インファレンスで正しく行うべきこと

コーディングエージェントにとって、TTFT はツールが高速に感じられるか壊れているかを決定する指標です。開発者がリクエストを送信すると、最初のトークンが届くまで何も表示されません。送信とストリーミング開始の間のこのギャップこそが、信頼を獲得するか失うかの分かれ道です。出力速度も重要ですが、二次的な要素です：一度トークンのストリーミングが始まれば、生成レートが中程度であっても体験は滑らかに感じられます。

2 つ目の制約は、長いコンテキスト下での並行処理です。コーディングエージェントの要求は単に長いだけでなく、同時に発生します。数十人の開発者が同じエンドポイントに同時にアクセスし、それぞれが 80k トークン以上のコンテキストを保持すると、シングルユーザーベンチマークでは表面化しない KV キャッシュ（Key-Value Cache）への負荷が生じます。キャッシュが埋まると、スケジューラーの動作余地が狭まります。プリフィルレイテンシが増加し、TTFT（Time To First Token）が悪化します。十分な高いトラフィック下では、システムは正式に失敗する前に実用上使い物にならなくなります。

3 つ目の制約は出力形状です。あなたはエッセイではなく関数を生成しています。生成長さは制限されており、平均して約 450 トークン程度です。つまり、サマライゼーションやドキュメント生成ワークロードとは異なり、飽和状態でのスループット特性が異なります。システムは持続的なデコード圧力下にあるのではなく、持続的なプリフィル（Prefill）圧力下にあり、頻繁な短いデコードバーストが発生します。長いデコード実行に最適化されたエンジンが必ずしもここで勝つわけではありません。

これら 3 つの制約 — TTFT への感度、並行する長文コンテキスト負荷、そしてプリフィル中心の出力形状 — が、このベンチマークがストレステストを意図して設計した要素です。

方法論

ハードウェア: エンジンあたり NVIDIA B200 を 4 基（SGLang: B200 を 8 基 — 以下の注記参照）。

ワークロード: 長いプロンプト、高い並行処理、現実的なセッションの入れ替わり。プロンプト長は約45kトークンから200kトークンの範囲で、現実的なコーディングセッションの成長をシミュレートしています。生成長の平均は450トークン（p50: 293, p99: 2,230）です。難易度はトラフィックに応じて変化します：QPSが高い場合、長いプロンプトと増大するKVキャッシュ（Key-Value Cache）によりプレフィル（Prefill）負荷が増加し、維持すべきコンテキストが膨らみ、セッションの入れ替わりが進むにつれてKVキャッシュのスラッシング（Thrashing）も激しくなります。

EAGLE 推測デコーディング: ドラフトトークン3個。受容率（約70%）は、現実的な合成プロンプトデータから自然に現れるものであり、無理やり設定しているわけではありません。

エンジン構成: TensorRT-LLM はこのワークロードに対して十分にチューニングされており、強力なベースラインとなっています。SGLang も可能な限り同等の構成で設定しました。徹底的なチューニング実験は行っていないため、わずかな改善余地があるかもしれません。すべてのエンジンは低レイテンシを目的に構成されています。これはスループット最適化構成とは異なります。後者の場合、最大デコードバッチサイズを増やし、プレフィルとデコーディングの分離（Disaggregation）を採用して、出力TPS（Tokens Per Second）を犠牲にして入力TPM（Tokens Per Minute）を高める設定になります。

最適化した点

私たちのパフォーマンス向上は、推論をフルスタックの問題として扱った結果得られました。つまり、エンドツーエンドのプロファイリングを行い、最もコストのかかる操作を特定し、一つずつ排除していったのです。

ThunderMLA。 Kimi K2.5 は、DeepSeek の Multi-head Latent Attention (MLA) アーキテクチャを採用しています。標準的な実装では、デコードステップごとに 2 つの別々のカーネル起動が行われますが、私たちの ThunderMLA（ThunderKittens カーネルライブラリの一部）はこれらを単一のメガカーネルに融合させ、起動オーバーヘッドとそれらの間のテール効果を排除しました。代表的なデコードワークロードにおいて、ThunderMLA は DeepSeek 自身の FlashMLA よりも 20–35% 高速です。

ThunderMLA の他にも、ドライバーの動作、メモリアウトプット、カーネル実行など、フルスタックのプロファイリングを行い、発見したボトルネックをすべて解消しました。一部には設定変更が必要でしたし、他にはゼロからカーネルを書く必要もありました。私たちが作成したカーネルは、このワークロードにおいて TensorRT-LLM のオープンソース版よりも優れたパフォーマンスを発揮します。

これが負荷下でのフルシステムにどう反映されるかを見てみましょう。

結果

Together Inference Engine を、EAGLE スペキュレーティブデコーディングを適用した Kimi K2.5 に対して、2 つのベースラインと比較しました：

• TensorRT-LLM — NVIDIA B200 GPU 4 枚
• SGLang — NVIDIA B200 GPU 8 枚

SGLang に関する注釈： SGLang で EAGLE を使用して Kimi K2.5 を実行する場合、TP4（Tensor Parallelism 4）ではメモリ不足になりました。このモデルにおいて、SGLang の EAGLE 実装は TensorRT-LLM のものよりも多くのメモリを必要とするためです。そのため、実行には TP8（GPU 8 枚）を使用しました。一方、TensorRT-LLM と Together Inference Engine は GPU 4 枚で動作させました。

GPU あたり 625 TPM（合計 2.5M TPM）において、Together Inference Engine は TensorRT-LLM よりも TPS が 31% 多く、かつ 1 秒未満の TTFT を維持できる唯一のエンジンです。

The degradation curve

曲線の形状は、単一のデータポイントよりも重要です。すべての推論エンジンはいずれ飽和します：KV キャッシュが満杯になり、スケジューリング負圧が増加し、TTFT が上昇します。エンジン間で異なるのは、それがいつ起こるか、そしてどの程度の速度で起こるかです。

2.5M TPM の場合、すべてのエンジンは快適な範囲を超えています：

Engine | GPUs | p50 TTFT

---|---|---

Together IE | 4 | 0.71s

TensorRT-LLM | 4 | 1.1s

SGLang | 8 | 5.1s

2.5M TPM で測定。

すべてのエンジンが劣化し始めているトラフィックレベルにおいて、Together IE の TTFT は TensorRT-LLM よりも 2 倍良く、SGLang よりも 3 倍良いです。システムにはより多くの余裕があり、他のエンジンでは機能しない負荷でも動作可能です。

Cost and quality

本記事のパフォーマンスベンチマークは Kimi K2.5 を対象としています。Kimi K2.6 は現在 Together で利用可能であり、コーディングベンチマークにおいては Claude Opus 4.6 と比較して全体的に同等かそれ以上の性能を発揮します。

Benchmark | Kimi K2.6 | Claude Opus 4.6

---|---|---

SWE-Bench Verified | 80.2 | 80.8

SWE-Bench Pro | 58.6 | 53.4

LiveCodeBench v6 | 89.6 | 88.8

Terminal-Bench 2.0

66.7

65.4

この品質レベルにおいて、コスト差は顕著です。このワークロードにおける典型的なリクエスト（入力トークン約 8 万〜10 万、出力トークン約 450）の場合：

モデル

リクエストあたりのコスト

Together 上の Kimi K2.6

$0.108

Claude Opus 4.6

$0.451

リクエストあたりのコストが 76% 安くなります。 30 人のエンジニアチームが、Claude Opus 4.6 と比較して、1 日 5 時間（年間 250 営業日）、TPM 150 万でコーディングエージェントを実行した場合、推論コストで年間約 44 万ドルの節約になります。

これはバージョン 1 です

これらの結果は、Together Inference Engine が今日、このワークロードにおいて、このハードウェア構成でどこに位置しているかを反映したものです。私たちはベンチマークが意味を持つべきだと考えています：実際のワークロード形状に基づき、方法論について透明性があり、何が破綻し始めるかについても正直であるべきです。

各アップデートは累積的なものとなります。目標は、推論可能なワークロードにおいて、最適化が実際に何をもたらすのかを記録し続けることです。次のバージョンがリリースされたら、どこが変わり、なぜ数値が変動したのかを正確にお見せします。

大規模でコーディングエージェントを実行中で、これが自分のワークロードに何を意味するかを理解したい場合は、お問い合わせください。