大規模推理基準測試：編碼智慧體

大多數推理基準測試測量的是單個使用者訪問專用端點的效能，這些數字看起來不錯，但對於生產環境毫無用處。在生產中，系統同時執行數十或數百個併發請求，它們競爭相同的 KV 快取、記憶體頻寬和 GPU 週期。真正重要的是系統在負載下每個使用者的體驗。

Together AI 團隊構建了針對編碼智慧體工作負載的基準測試，該工作負載對推理提出了嚴峻挑戰：長輸入、高併發，並且不能容忍負載下的延遲退化。編碼智慧體請求攜帶大量上下文：正在編輯的檔案、周圍程式碼、對話歷史、檢索到的片段。輸入很長，輸出有意義但有限——你是在生成一個函式，而不是一篇文章。更難的挑戰是併發性。許多使用者同時訪問端點，這些請求以單使用者基準測試永遠無法捕捉的方式相互作用。

為了測試這一點，他們設計了一個高流量基準測試，模擬生產環境中編碼智慧體流量的請求分佈。提示長度範圍從約 45k 到 200k 令牌，模擬真實的編碼會話增長，生成長度平均約 450 令牌。關鍵指標是每分鐘輸入令牌數 (TPM)、每使用者每秒令牌數 (TPS) 和 p50 首令牌延遲 (TTFT)。

對於編碼智慧體，TTFT 是決定工具感覺快速還是糟糕的指標。開發者提交請求後，直到第一個令牌到達之前什麼都看不到。這個間隙——從提交到流式輸出——是信任贏得或失去的地方。輸出速度很重要，但次之：一旦令牌開始流式傳輸，即使生成速率適中，體驗也會感覺流暢。第二個約束是長上下文下的併發性。程式設計智慧體請求不僅長，而且同時發生。數十名開發者同時訪問同一端點，每人攜帶 80k+ 令牌的上下文，會產生單使用者基準測試從未暴露的 KV 快取壓力。隨著快取填滿，排程器的迴旋餘地減少，預填充延遲增加，TTFT 惡化。第三個約束是輸出形狀。你生成的是一個函式，而不是一篇文章。生成長度有限——平均約 450 令牌——這意味著飽和時的吞吐量在這裡看起來不同於摘要或文件生成工作負載。系統不是處於持續的解碼壓力下，而是處於持續的預填充壓力下，伴隨著頻繁的短解碼突發。專門針對長解碼執行最佳化的引擎在這裡不一定勝出。

基準測試方法：硬體為每個引擎使用 4 塊 NVIDIA B200（SGLang 使用 8 塊 B200，因為其 EAGLE 實現需要更多記憶體）。工作負載包括長提示、高併發和真實的會話輪換。EAGLE 推測解碼使用 3 個草稿令牌，接受率約 70%。引擎配置針對低延遲最佳化，不同於吞吐量最佳化配置。

Together Inference Engine 的效能提升來自全棧最佳化：端到端效能分析，識別最昂貴的操作，並逐一消除。ThunderMLA 是 ThunderKittens 核心庫的一部分，將兩個獨立核心啟動融合為單個超級核心，消除了啟動開銷和尾效應。在代表性解碼工作負載上，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 在 Together 上的成本為每個請求 $0.108，而 Claude Opus 4.6 為 $0.451，便宜 76%。一個 30 人的工程團隊每天執行 5 小時，每年可節省約 44 萬美元的推理成本。

這是版本一，團隊計劃在更新時展示最佳化帶來的實際變化和數字變化原因。