8月21日，螞蟻集團Ling基礎設施團隊聯合阿里巴巴與SGLang團隊，在LMSYS部落格發布了一個叫Weight Cache Daemon的元件：一個常駐GPU記憶體的處理程序，把量化並切片好的權重留在GPU裡，新啟動的推理引擎透過CUDA IPC零複製映射過去。團隊給出的數字是，Ling-2.6-1T FP8的權重載入時間從約495秒降到0.63秒，整體啟動時間從8.8分鐘壓縮到0.528分鐘。
八分半鐘裡有八分鐘在讀磁碟
團隊把一次完整的啟動流程拆開實測。Ling-2.6-1T FP8跑在8張H20-3e上，權重放在3.5T的NVMe SSD，從啟動到能接收請求需要約527秒。其中權重載入就佔了495秒，也就是93.9%；tokenizer初始化13秒，torch分散式初始化5秒，CUDA graph擷取7.7秒，其餘各項加起來不到6秒。
每張GPU要從磁碟讀取約120GB的safetensors，反序列化後按張量平行方式切片，再進行FP8量化與權重重新排列，總共161個切片。這套流程每次重啟都得從頭跑一遍，但它的輸出其實是確定的：同一個模型、同一套設定，最後落在GPU記憶體裡的張量每次都一樣，而且往往上一個處理程序才剛結束，這些張量還留在原地。
對生產環境來說，這幾分鐘意味著P99尾端延遲在重啟期間大幅飆升，處理中的請求全部失敗或無限排隊，滾動升級與故障復原也都被這個週期卡住。
把權重留在GPU記憶體裡
每張GPU跑一個daemon處理程序，對應一個TP rank。它先按完整流程從磁碟載入一次，接著把model.state_dict()裡所有參數與緩衝區匯出成CUDA IPC控制代碼，透過Unix socket交給連上來的引擎處理程序。引擎那端會先在meta device上把模型結構搭起來，不配置任何記憶體，再把每個參數的data指標指向映射過來的張量。兩個處理程序共享同一塊實體GPU記憶體，全程沒有任何複製動作。FP8量化過程中產生的weight_scale之類後處理參數也一併快取，省去重新量化的步驟。
安全機制設了兩道關卡。第一道是設定指紋，模型路徑、TP/PP/DP切分方式、量化方法與設定雜湊值、dtype都要對得上，另外還多記了GPU運算能力與torch版本這兩項環境資訊。不同架構或不同torch版本走的後處理分支不一樣，權重雖然能乾淨地映射過去，算出來的卻可能是垃圾值，把環境資訊寫進指紋裡，就能把這種不易察覺的錯誤轉成一次明確的不匹配，進而退回磁碟載入。
第二道是量化方法白名單。目前只驗證了不量化與block-wise FP8這兩種，per-tensor FP8、Marlin、AWQ/GPTQ都會直接報錯。原因是IPC只匯出原始張量資料，而這幾種方法會把部分效果留在Python端的中繼資料裡，或是對權重做了重新排列與轉置，直接映射過去數值就會出錯。團隊選擇讓它明確報錯，而不是悄悄給出錯誤的結果。
daemon當機不會影響已經在跑的引擎，CUDA的參照計數仍然有效，記憶體要等雙方都結束才會釋放；daemon重啟後會重新讀取磁碟、重新匯出控制代碼，新的引擎才能再次連上。
順帶解決了熱備援的成本問題
這個元件有三種模式：daemon（引擎自己拉起daemon，第一次啟動一樣慢）、client（連上已經在跑的daemon，可在一秒內完成重啟）、off（預設模式，走磁碟載入，Ling-2.6-1T需要405到411秒）。
比啟動加速更實際的是它帶來的幾種部署方式。同一張GPU上多個引擎實例映射同一份權重，磁碟只需讀一次、量化也只做一次。優先順序高的線上服務與優先順序低的離線批次處理共用同一張GPU，後者被搶占之後可以在一秒內重新拉起。在主備切換的場景裡，備援引擎以零複製方式掛上同一份權重並保持熱備狀態，主實例掛掉後能在1秒內接手。
最後這點是明擺著的成本項。粗略估算，一套Ling-2.6-1T實例佔用8張H20-3e，傳統熱備援意味著旁邊還要再壓8張卡空轉待命。換成共享權重的備援機，省下的就是這整組卡的常駐佔用。滾動升級也是同樣道理，若以8.8分鐘一次估算，每個實例每輪重啟就要燒掉約1.2個GPU小時的空轉時間，實例數上百的叢集跑一輪升級，累計下來就是三位數的GPU小時。
還沒到終點
Weight Cache Daemon只是Fast Engine Recovery Framework的第一階段，路線圖上寫著冷啟動要壓到10秒以內、熱備援切換要壓到1秒以內。接下來計劃處理CUDA graph序列化、kernel快取與分散式初始化最佳化。從前面那份拆解來看，這幾項加起來大約26秒，正是權重載入之後剩下的大頭。
Qwen3-235B FP8這一檔的數字也一併公布了：權重約235GB，磁碟載入要306到327秒，IPC映射則在1秒以內完成，大約快500倍。Ling-2.6-1T這一檔則大約快780倍。
部落格裡也順帶提了剛發布的2.8T參數Kimi K3。參數量愈往上翻，磁碟載入時間也跟著近乎線性往上翻，但IPC映射的時間幾乎維持常數，這條曲線的差距只會愈拉愈大。對已經在跑兆級參數模型的團隊來說，重啟一次的代價正從「等上幾分鐘」變成「幾乎不用等」，而這件事影響的不只是可用性數字，還有敢不敢頻繁改設定、敢不敢在同一張GPU上塞兩個服務。
參考來源：LMSYS Org技術部落格、CocoLoop、SGLang專案說明；啟動耗時拆解、權重載入與IPC映射的對比數字均取自團隊公布的單機基準測試表。