2026 年 11 月 4 日，Together AI 在官方研究部落格發布了 〈Together Compiler: Continual Compilation for AI inference〉，作者為 Reyna Abhyankar、Dylan Lim 與 Simran Arora。Together Compiler 把 AI Agent 接進推論引擎的最佳化循環：模型、硬體或請求形狀改變，就重新尋找更合適的執行程式。值得追問的是，這次改善究竟來自更會寫程式，還是終於讓實驗跑得夠快？
先說判斷：這是有具體系統設計與測試資料的推論最佳化研究，但「最高 2.6 倍」仍是 Together 的特定工作負載結果。下面先讀懂原文的三個零件，再核對成績單的分母，最後回到部署者該如何驗收。本文依 2026 年 11 月 6 日查閱的公開原文與論文分析，未執行 GPU 基準測試。
一、Together Compiler 想解的，是最佳設定會過期
把推論服務想成一間廚房：同樣一套設備，中午大量短單、晚上少量長單，適合的分工可能不同。模型請求也有輸入長度、輸出長度、同時處理量與快取重用的差異。只替某種流量調過一次，並不代表換一批工作後仍然划算。
However, today’s agentic systems are bottlenecked by the speed of experimentation.
中文：然而，當前 Agent 系統的瓶頸，在於實驗的速度。
Together AI，原文導言
原文的重點可濃縮成三件事：保留已載入的引擎、分兩層量測、先挑值得搜尋的 GPU 分工。Agent 負責提出候選程式，量測系統負責提供回饋；兩者接得好，才有機會在有限時間內找到有效改善。這和只請聊天機器人「把程式寫快一點」，中間差了一整套實驗設施。
二、三個零件：讓每一次嘗試更便宜，也更接近真實工作
常駐引擎：少做重複開工的準備
依論文第 4 節，TKCC 讓模型權重先載入，再熱載入候選 forward pass，也就是模型一次前向計算的執行程式。這樣可以省去每個候選都重新建立整個引擎的準備。平行 Agent 持續提案，讓一個 Agent 思考時，其他候選仍可接受測量。
這個設計的價值，像是保留已備料的試驗廚房，而非每換一道配方就重搭廚房。它改善的是搜尋環境的效率；最終菜色好不好，仍須實際品評。把實驗變快與把服務變快分開，才不會把兩種倍率混為一談。
分層量測：先快篩，再看完整行為
快層使用較少的模型層，先篩掉差的候選；慢層用更多層，檢查接近實際資料分布的效果。MoE（混合專家模型）會按 token 選擇部分專家，輸入變了，工作如何分散也會變。孤立運算片段在隨機資料上跑得快，還要確認放回完整服務是否同樣有效。
成本模型：先選分工，再投入搜尋
第三個零件用硬體規格與實際測量，縮小 GPU 平行配置的候選範圍。Tensor Parallelism（TP）把張量運算分攤出去；Expert Parallelism（EP）則分散專家。多分幾張卡，可能減少單卡負擔，也會增加溝通成本。最佳分工取決於工作量，而非卡數越多越好。
這裡可與 vLLM 團隊 9 月 8 日的 AgentX 工程報告 對照。該報告也把模型專屬平行策略、快取與排程放在同一個服務問題裡討論，並以每位使用者的互動速度門檻比較吞吐量。它支持「服務效能取決於整個配置」這個背景，並不是對 TKCC 成績的獨立重跑。
原文另稱，與每次測量都重啟引擎的基準系統相比，TKCC 的 Agent 實驗吞吐量提高 252 倍。這個數字描述的是最佳化期間能試多少候選，不是對外服務的 token 速度提升 252 倍。作者也將方法試用於天氣、生物、時間序列與偏微分方程模型；各領域的評估工作不同，本文不把它們合成通用加速倍率。
三、Together Compiler 的 2.6 倍：先問 TPS 算了誰
Together 在原文報告：部分前沿模型工作負載，相對其採用的 InferenceX 基準配置，TPS 最高達 2.6 倍；Llama 1B、batch size 1 的 megakernel 比較則最高達 1.7 倍。這兩組對照的模型、引擎與條件不同，不能合成一個所有部署適用的倍率。
依論文第 5.2 節，這組主要吞吐量比較採用 2026 年 10 月 27 日的基準快照，各模型、硬體與並行度沿用當時領先配置的平行策略，每個設定安排 24 小時最佳化。下一節另談的低延遲案例，才讓成本模型改選平行策略；兩組實驗的解讀要分開。
這張圖要沿著相同的使用者速度要求，往上比較容量，而非只挑橘線最高的一點。依論文附錄 A.3，這組每 GPU 吞吐量把輸入與輸出 token 都算入，快取命中的輸入也完整計數；每位使用者的互動速度則採 P90 inter-token latency 的倒數。前者看服務量，後者看生成階段的等待節奏。
這個區分也能由獨立的基準制定者核對。AgentX 的指標文件 說明，decode 的每用戶速度不含等待第一個 token 的時間；把首字等待也算進來的端到端指標，是另一種量尺。於是，「每秒很多 token」仍需補問：第一個字多久出現、整段工作多久完成、多少請求失敗？
還有一個容易漏掉的註腳：原文將 Trainium2 的測試改為合成多輪資料，而非同一份 AgentX 工作負載。這不使那一格結果失去意義，但跨硬體下結論時，要先對齊輸入、快取與輸出條件。InferenceX 的方法說明 也要求保存語料、重播設定與測量條件；共用一個基準名稱，不能代替條件比對。
四、1,111 TPS 的低延遲案例，配置也一起換了
論文另報告 MiniMax M3.1 Flash 在 B200、batch size 1 下，每位使用者的 P90 TPS 從 633 到 1,111，約為 1.76 倍，作者四捨五入寫成 1.8 倍。第 5.2 節 同時說明：對照採 TP4，TKCC 的成本模型選 TP8。作者補做的同一 InferenceX 映像 TP8 測試，表現接近原 TP4 結果。
因此，這是整套搜尋、配置選擇與程式最佳化的結果，無法只憑這兩個柱狀值，分出 Agent 改碼單獨貢獻多少。更不能直接推出每張 GPU 都多做了 76% 的工作：每位使用者生成更快，與每卡產能增加，各有自己的分母。這是讀圖的邊界，不是宣稱配置變更就解釋了全部差距。
Together 的生產部署規模與測試增益，在本文仍保留為公司自述；目前取得的公開材料不足以把它們寫成 AlphaLab 或獨立機構已重現。最有價值的後續證據，是固定模型、映像、精度與 GPU 拓樸的可比紀錄，以及流量改變後重新搜尋的完整成本。
五、原文要推動什麼？從一次調參走向持續服務
The era of static inference is over.
中文：靜態推論的時代已經結束。
Together AI，論文第 6 節
這是作者的方向性宣言。同日的 Polymorphic Inference 公告 把 Together Compiler 放進更大的計畫：讓部署隨模型、硬體與工作負載調整。公司說部分 serverless 端點已使用 TKCC；截至本次查閱，客戶自行使用的入口則是 limited beta（有限測試），需聯絡申請。內部已用與所有客戶都能自助操作，應分開看。
最值得未來對帳的承諾，不是某次最高倍率，而是：當你的流量換了形狀，系統能否在可接受的時間與成本內，重新找到仍然正確、仍達延遲要求的配置？這才是「持續」二字的產品價值。
六、AlphaLab 的判讀：進步在回饋迴圈，界線也在回饋迴圈
1. 多試幾次有用，前提是量尺量對了
搜尋可以被拆成四個問題：候選是否多樣、一次測試多貴、回饋是否準確、改善是否能留到真實環境。TKCC 將後三項搬到系統設計裡處理，這比只比較哪個 Agent 產生的程式碼最多，更接近部署者真正的工作。
但如果快篩的流量過窄，搜尋也可能只是在那張考卷上越練越好。建議把真實流量留一部分作搜尋後驗收，並保留罕見長請求、快取失效及突發尖峰；這是採用時的評估要求，不是對 Together 現有測試覆蓋的推測。
2. 算得更省，還要扣掉找答案的成本
可以先寫一個簡單的損益式：淨節省＝採用後節省的運算成本－搜尋、驗收與切換成本。假設一次搜尋花 100 單位，日後每天省 10 單位，要維持約 10 天才剛好抵回搜尋支出；若流量第三天就大變，帳就得重算。這是自訂算例，沒有替 TKCC 填入未公開的價格。
對大型持續服務，小幅改善也可能累積成可觀節省；對低流量或頻繁改模型的專案，先減少不必要請求、改善快取，可能更容易驗收。決策應從自己的支出與瓶頸開始，無須先把平台換掉才知道有沒有問題。
3. 自我改進的名稱，需要對應到哪一層
這裡被修改的是推論執行程式與配置。服務變快，可以讓相同資源做更多計算；要再推成模型推理能力持續升級，仍需下一段證據：省下的資源如何改善研發、改進能否再次累積、人類與外部資源投入各占多少。降低服務成本是一個有價值的成果，本身就值得評估。
這類工作也有其他研究路線。Apple 的 RSI-Inference Bench 原始專案 讓 Agent 改真實推論引擎，再由獨立 verifier 建置、執行並評分。這個設計提醒我們：無論稱作最佳化還是自我改進，交出的執行產物都要回到正確性與效能檢查，而非以 Agent 的完成訊息結案。
4. 持續調校不等於持續冒險
論文描述搜尋後會做 KV cache 污染與品質等驗證。採用者還應問清楚自己的上線邊界：候選在哪裡試、哪些條件才可切換、失敗時回到哪個已知版本、調校對既有請求造成多少干擾。這些是變更控制問題，要和最佳化倍率一起驗收。
速度測試回答「跑得快不快」，答案品質回答「算得對不對」，模型來源則回答「用的是誰」。三個問題不能互相代答。若想進一步區分，可接著讀 FlashProve 的運算證明界線；同樣要避免把某一層驗證的綠燈，外推成整條服務都已受保證。
我同意什麼／我存疑什麼
我同意：讓 Agent 持續最佳化服務，需要高效率且有代表性的實驗回饋；引擎、快取與平行策略理應一起看。我存疑：最高倍率能代表多少客戶流量、扣除搜尋後的經濟收益，以及這些改進能否跨多輪工作負載改變而穩定保留。現有原文提供了可追問的機制，後三題仍應逐部署取得證據。
七、下一步：先向供應者要一張可比的驗收表
如果你負責 AI 系統，先固定一個現有部署，把模型版本、精度、引擎映像、GPU 數量與連接方式寫下來，再留一組可重播的非敏感流量。接著分欄記錄首字等待、生成速度、端到端完成時間、每卡吞吐量、錯誤率與品質；最後才加上搜尋耗用、切換與回復紀錄。驗收設計可參考 AI Evals 入門。
一般讀者則可以先做一件事：下次看到加速標題，在倍率旁補上「誰測、用什麼工作、哪個對照、誰的時間或資源」。想補上模型與執行層的分工，可讀 Agent Harness 是什麼；想區分少算、少存與整機成本，可讀 LSA 稀疏注意力與顯存分析。
Together Compiler 值得重視的，是把「部署完再人工追著調」改成一條可持續搜尋、測量與驗收的工程路徑。下一個有說服力的結果，應是你自己的流量改變後，系統仍能用較低總成本，交出符合延遲與品質要求的工作。
