大規模推論ベンチマーク：コーディングエージェント
本番コーディングエージェントワークロードにおいて、Together Inference Engine は同一ハードウェア上で次に高速なOSSエンジンより31%高いTPSを実現し、飽和状態では2倍優れたTTFTを維持します。この改善は、ThunderMLA、カスタムカーネル書き換え、実トラフィックでのエンドツーエンドプロファイリングに基づくフルスタック最適化によるものです。
ほとんどの推論ベンチマークは、単一ユーザーが専用エンドポイントにアクセスする状況を測定します。数値は良く見えますが、本番環境での評価には役立ちません。本番環境では、数十から数百の同時リクエストが実行され、同じKVキャッシュ、メモリ帯域幅、GPUサイクルを競合します。重要なのは、システムが負荷下にあるときの各ユーザーの体験です。
Together AIチームは、コーディングエージェント向けのベンチマークを構築しました。このワークロードは推論に厳しい条件を課します。長い入力、高い同時実行性、負荷下でのレイテンシ劣化が許されない点です。コーディングエージェントのリクエストは大量のコンテキストを運びます。編集中のファイル、周辺コード、会話履歴、検索されたスニペットなどです。入力は長く、出力は有意義ですが制限されています。関数を生成するのであって、エッセイではありません。より難しい課題は同時実行性です。多くのユーザーが同時にエンドポイントにアクセスし、それらのリクエストはシングルユーザーベンチマークでは決して捉えられない方法で相互作用します。
これをテストするために、彼らは本番のコーディングエージェントトラフィックのリクエスト分布をモデルにした高トラフィックベンチマークを設計しました。プロンプト長は約45kから200kトークンで、実際のコーディングセッションの成長をシミュレートし、生成長は平均約450トークンです。主要な指標は、1分あたりの入力トークン数（TPM）、ユーザーあたりの1秒あたりトークン数（TPS）、およびp50初回トークン到着時間（TTFT）です。
コーディングエージェントにとって、TTFTはツールが高速か壊れているかを決定する指標です。開発者がリクエストを送信すると、最初のトークンが到着するまで何も表示されません。そのギャップ（送信からストリーム開始まで）が信頼を勝ち取るか失うかのポイントです。出力速度も重要ですが、二次的です。トークンがストリーミングされると、生成速度が中程度でも体験は流動的に感じられます。2つ目の制約は、長いコンテキスト下での同時実行性です。コーディングエージェントのリクエストは長いだけでなく、同時に発生します。数十人の開発者が同時に同じエンドポイントにアクセスし、各自が80k+トークンのコンテキストを持つことで、シングルユーザーベンチマークでは決して表面化しないKVキャッシュプレッシャーが生じます。キャッシュが満杯になると、スケジューラの余裕が減り、プリフィルレイテンシが増加し、TTFTが悪化します。3つ目の制約は出力形状です。関数を生成するのであって、エッセイではありません。生成長は制限されています（平均約450トークン）。したがって、飽和時のスループットは、要約や文書生成ワークロードとは異なります。システムは持続的なデコードプレッシャーではなく、持続的なプリフィルプレッシャー下にあり、頻繁な短いデコードバーストが発生します。長いデコード実行に最適化されたエンジンは、ここでは必ずしも有利ではありません。
ベンチマーク方法：ハードウェアは各エンジンに4台のNVIDIA B200（SGLangは8台のB200、EAGLE実装に必要なメモリが多いため）。ワークロード：長いプロンプト、高同時実行性、現実的なチャーン。EAGLE投機的デコード：3つのドラフトトークン、受入率約70％。エンジン設定は低レイテンシ向けで、スループット最適化設定とは異なります。
Together Inference Engineのパフォーマンス向上は、推論をフルスタック問題として扱うことで達成されました。エンドツーエンドのプロファイリング、最も高コストな操作の特定、そしてそれらを一つずつ排除しました。ThunderMLAはThunderKittensカーネルライブラリの一部で、2つの独立したカーネル起動を単一のメガカーネルに融合し、起動オーバーヘッドとそれらの間のテール効果を排除します。代表的なデコードワークロードで、ThunderMLAはDeepSeekのFlashMLAより20～35％高速です。さらに、ドライバ動作、メモリレイアウト、カーネル実行などスタック全体をプロファイリングし、すべてのボトルネックを除去しました。
結果：625 TPM/GPU（合計2.5M TPM）で、Together Inference EngineはTensorRT-LLMより31％高いTPSを提供し、1秒未満のTTFTを維持する唯一のエンジンでした。2.5M TPMでは、すべてのエンジンが快適範囲を超えています：Together IEのp50 TTFTは0.71秒、TensorRT-LLMは1.1秒、SGLang（8 GPU使用）は5.1秒。すべてのエンジンが劣化するトラフィックレベルで、Together IEのTTFTはTensorRT-LLMの2倍、SGLangの3倍優れています。システムにはより多くの余裕があり、他のエンジンでは機能しない負荷でも動作します。
コストと品質：Kimi K2.6はコーディングベンチマークでClaude Opus 4.6に匹敵またはそれを上回ります。典型的なリクエスト（約80k～100k入力トークン、450出力トークン）では、Kimi K2.6 on Togetherのコストはリクエストあたり0.108ドル、Claude Opus 4.6は0.451ドルで、76％安価です。30人のエンジニアリングチームが1日5時間稼働する場合、年間約44万ドルの推論コスト削減になります。
これはバージョン1であり、今後のアップデートでは最適化の実際の効果と数値が変化した理由を示す予定です。