四卡讓螞蟻Ling-3.0-flash快2.1倍

SGLang團隊與螞蟻集團Ling Infra團隊在8月21日公開了一份聯合調校紀錄:在4張Blackwell顯示卡上執行Ling-3.0-flash,把併發數為1時單一token的輸出耗時(TPOT)從3.33毫秒降到1.53毫秒,降幅54%,吞吐量從每秒288個token提升到606個。換上他們訓練的DSpark草稿模型之後,平均TPOT進一步壓到0.78毫秒,吞吐量來到每秒1120個token,平均每次能接受9.95個草稿token。

Ling-3.0-flash是一個混合線性注意力的MoE模型,42層裡有35層採用KDA線性注意力、7層採用MLA全注意力,路由專家數512個,隱藏層寬度2560,詞表約15.7萬,在bf16精度下每張卡要載入約63GB權重。測試以張量平行切成4份,精度為bf16。

閒著的其實是顯示卡

這次優化鎖定的是batch size等於1的情境。絕大多數公開的推理優化成果都在衝高併發下的整體吞吐量,因為那正是雲端業者的計費結構所在。但另一種負載的體感更直接,就是併發數為1的情況:在本機跑模型、程式碼自動完成、Agent循序執行一條長任務鏈——同一時刻只有一個請求在跑,使用者盯著螢幕等文字一個個跳出來。

併發數一低,顯示卡就閒下來了。每一步解碼的運算量小到微不足道,顯示卡做完工作後就在等下一批指令,而下指令的是CPU。只要主機端有一處需要把顯示記憶體裡的數值讀回去、才能決定下一步怎麼做,整條流水線就得停下來等這次同步完成。

"at batch 1, look for blocking reads of device values on the host path before anything else, because each one converts the entire host loop from hidden work into a GPU bubble."

併發數為1時,要優先找出主機端路徑上對顯示記憶體數值的阻塞式讀取——每一處都會把原本藏在背景裡的主機端負擔,變成一個看得見的GPU空泡。

逐一拆掉等待

第一類是主機端空轉。做法是把每一步的顯示卡同步點拿掉:在KDA注意力後端裡宣告不必把序列長度讀回CPU,讓相關索引全程留在顯示記憶體裡。這樣一來,第k+1步的指令可以在還不知道第k步接受了幾個草稿token的情況下就先發出去,主機端不必再排隊等結果。

第二類是縮短顯示卡關鍵路徑上的工作。用「程式化相依啟動」(PDL)把不依賴前一個核函式(kernel)產出的權重載入提前發出;把路由與MoE運算從原本兩次核函式啟動合併成一次,以512個專家這種規模來說,光是啟動開銷就相當可觀;把router gate與lm_head的運算精度從fp32換成bf16,單這一項就拿到約10%的提升。KDA在推測性解碼(speculative decoding)下的迴圈狀態改成分階段更新,驗證通過之後才提交。

這些改動都已併入SGLang:合併中繼資料的圖形擷取(graph capture)、融合後的KDA驗證核函式、由主機端直接下發的FlashInfer執行計畫(省掉阻塞式的顯示記憶體回讀),以及把草稿、驗證、擴展三個步驟合併的排程順序。

換算成人能感受到的時間

拿一個5000個token的長回覆概算一下。3.33毫秒一個token,寫完要16.6秒;1.53毫秒是7.7秒;0.78毫秒是3.9秒。同一台機器、同一個模型、同一個人在等待,體感從「泡杯茶回來剛好」變成「話還沒說完就寫完了」。這個差距不是靠換顯示卡換來的,而是把主機端的等待清乾淨換來的。

DSpark那一檔的關鍵數字是平均接受長度9.95。推測性解碼的邏輯是讓小模型先猜一串,大模型一次驗證完,猜中多少就白賺多少步。接受長度接近10,代表大模型每驗證一次,就能抵將近十次一般解碼。這個數字跟草稿模型的訓練方式直接相關——DSpark的草稿模型是照著Ling-3.0-flash後訓練之後的輸出分布蒸餾出來的,損失函數裡還特別加了針對接受長度的優化項,猜得準這件事是訓練出來的,跟運氣無關。

一次上游的合作

這份紀錄背後掛了三方名字:SGLang這邊的RadixArk、螞蟻的Ling Infra團隊,以及螞蟻的inclusionAI。模型權重與重現指令一併公開,包括DSpark變體。

中國的開源模型這幾年在排行榜上有一席之地已經不稀奇,稀奇的是在推理堆疊這一層有話語權——這次優化沒有停在等上游框架適配,而是自己帶著硬體成本與真實負載去改上游程式碼,改完再合併回去。對下游用同一套框架部署的人來說,這批開關打開就能用,跟模型出自哪家關係不大。

參考來源:SGLang官方技術部落格、CocoLoop、螞蟻inclusionAI公開的模型卡;比對部落格提供的重現指令與基準測試結果,確認TPOT、吞吐量、接受長度三項數據皆在併發數1、4卡張量平行、bf16的條件下測得。