EAGLE團隊、vLLM和TorchSpec聯合發布EAGLE 3.1,修復了推測解碼中一個真實的生產bug:隨著推測深度增加,drafter模型將注意力從sink token轉向自己生成的token,降低了接受長度和輸出穩定性。修復是兩個架構改動——在每個target hidden state之後、FC層之前應用FC正規化以約束hidden state幅度,加上post-norm hidden state回饋使drafter表現得像遞迴調用而非附加層。已合併入vLLM main,在v0.22.0中發布,向後相容現有EAGLE 3檢查點。
回報的收益是具體的。在長脈絡工作負載上,接受長度比EAGLE 3長達2倍。在Kimi K2.6-NVFP4 SPEED-Bench編碼上,每使用者吞吐量在並發1時提升2.03倍、並發4時1.71倍、並發16時1.66倍。模式——低並發時最大提升,隨並發上升而收窄——是建構者應該期待從任何推測解碼收益中得到的:推測解碼在模型每請求受限於記憶體頻寬時獲勝,這就是低並發的狀況。高並發時你受限於聚合吞吐量,推測的贏面更小。發布中沒有針對Medusa或vanilla draft-model基線的直接對比,這是要標記的方法論缺口。
生態系統解讀寓於整合路徑多於數字。EAGLE兩年來一直是生產級推測解碼家族;vLLM是自託管LLM的預設推理引擎;TorchSpec提供訓練端。當三者匯聚於一個用向後相容的演算法變化修復已知不穩定性的發布時,那是推理stack在減少其load-bearing變異數,而不是添加功能。Kimi K2.6開源的draft model在HuggingFace上意味著Kimi上的建構者已經有了製品;對其他基礎模型,訓練端的工作在TorchSpec上。帶有不斷增長脈絡視窗的agentic loops是注意力漂移傷害最大的地方——長agent痕跡、長檔案中的程式碼補全、文檔QA——而這些正是2倍接受長度轉化為使用者可見延遲勝出的工作負載。
如果你在生產中執行vLLM:安排0.22.0升級,並在能力所及時在TorchSpec上重新訓練你的draft模型。如果你建構推理SaaS:這是為所有使用你stack的人靜默改善長脈絡成本曲線的變化。