SGLang原生支持昇騰，新模型一鍵拉起無需改代碼

• henry 發自 凹非寺
  量子位 | 公眾號 QbitAI

當Agent在應用側不斷加速，推理系統能否承受隨之而來的真實負載，正在成為行業關注的焦點。

這是12月20日在杭州收官的SGLang AI 金融 π 對上，被反復提及的一個背景。

在這場聚焦大模型推理效率的“π對”上——

Agent的Vibe被暫時擱到一邊，真正擺上桌面的，是推理系統在真實負載中的工程問題：高并發請求長上下文窗口多輪推理內存管理，以及在具體金融agent場景下的一致性生成問題。

同時，在活動討論中，昇騰作為算力平臺也被多次提及。

當前，昇騰已作為SGLang原生支持的后端之一進入主倉庫，隨著 SGLang推理引擎的更新，DeepSeek、Qwen、GLM等模型可以在不調整模型參數、不引入額外插件的情況下直接運行，HiCache、Mooncake等系統能力也在對應版本中引入。

可以說，這次SGLang AI金融π對呈現的，并非零散技術點，而是一條清晰的推理工程演進路徑——從緩存與內存體系，到權重更新、強化學習效率，再到算力與模型生態的協同。

接下來，我們具體來看。

面向Agent的推理系統工程解法

這次SGLang活動由SGLangAtomGit社區聯合發起，于12月20日在杭州舉辦，活動圍繞大模型推理架構、Agent、強化學習及其在金融場景的落地展開討論。

在嘉賓方面，活動由來自推理系統、模型與算力一線的工程團隊共同參與，包括華為高級項目群總監薛曜，SGLang開發者黃章衡尚旭春，華為“小巧靈”突擊隊工程師荊升航，昇騰高級研發工程師鎮亮，以及GLM技術布道師張昱軒

整體來看，Agent相較于以往的問答式LLM，在深度研究、代碼生成、工具調用等應用以及強化學習訓練中，對高并發請求、長上下文窗口、多輪推理和內存管理的效率提出了更高要求。

而在特定的部署場景，如金融Agent中，則對低延遲、響應穩定性、一致性及成本控制的要求則更為嚴苛。

本次Meetup正是圍繞這些Agent原生的系統變化，給出了工程實踐層面的集中回應。

首先，針對高并發長上下文場景下KV cache重復計算、顯存需求大的問題。

SGlang通過最新引入的HiCache體系，將KV cache擴展到CPU和遠端存儲，由Cache Controller自動管理KV卸載填裝，并結合流水線化異步預取，顯著降低了顯存占用，提升了上下文推理的穩定性與吞吐。

此外，針對Qwen3-Next、Kimi Linear這類具備不同計算邏輯和內存管理方式的混合模型。

SGLang通過Mamba Radix Tree實現前綴統一管理，并借助Elastic Memory Pool彈性調度KV Cache與Mamba State，在長上下文、多并發場景下提供高效推理和顯存優化能力。

其次，為應對強化學習中策略權重頻繁更新導致GPU空轉、冷啟動耗時過長的瓶頸。

Mooncake基于Transfer Engine，采用異步預讀、pipeline并行設計，顯著壓縮權重加載和模型啟動時間，實現熱更新與彈性擴容。

實測效果顯示：Kimi K2萬億參數模型的權重更新準備時間被壓縮至20秒以內，63B模型的冷啟動時間更是從85秒降至9秒。

此外，由于強化學習rollout不再是一次性推理，而是異步、多階段、長度不可預測的過程。

換句話說，rollout中的長尾請求可能拖慢90%的訓練時間，甚至可能出現跑了一整夜仍未完成任何step的情況。

針對這一問題，SGLang通過Server化+全異步執行、oversample與 partial rollout機制控制長尾請求，大幅緩解Agentic RL中的長尾問題，提高了訓練效率。

最后，針對DeepSeek、GLM-4.5等MoE模型的fuse MoE、內存調度和負載均衡問題，SGLang持續重構執行路徑與內存管理機制。

同時，Slime強化學習系統針對大規模GRPO與多階段RL訓練定制，實現訓練系統與推理引擎的深度協同。

一個值得注意的細節是，這些推理系統級能力，并非只停留在某一類算力平臺上。這些實踐中的HiCache、Mooncake、GLM都均已能夠在昇騰平臺上直接運行，并進入實際推理流程。

而這些不約而同的支持，恰恰從側面印證了當前昇騰硬件在推理系統生態的角色轉變——

它已作為主流推理工作流中的后端之一，被自然納入系統設計與工程實現之中。

昇騰 × SGLang：大模型推理的高效實踐

在上述共性問題之下，活動中也展示了SGLang在昇騰平臺上的最新進展，覆蓋模型適配、性能優化及系統加速能力模塊化沉淀。

主要亮點如下：

• 模型優化：針對DeepSeek、Qwen系列等開源模型進行適配與性能提升，支持稠密、稀疏、多模態等架構，并支持Flux、Qwen-Image等多模態生成模型。
• 系統特性：HiCache L1/L2/L3直通緩存機制已落地，MTP完全適配昇騰平臺，兼容GPU與NPU后端。
• 量化能力：推進昇騰側量化與開源框架協同，支持壓縮張量等多種量化方案。
• 推理模式：完善圖模式支持，實現DeepSeek V3.2、Qwen-Next、Longcat等新模型的day0支持。
• 強化學習：支持SGLang VeRL等強化學習相關模型的推理與部署。

在具體的模型上，昇騰此次實現了對DeepSeek V3.2Day 0支持，在PD分離、64K輸入、3K輸出場景下，推理吞吐達15TPS / 卡，TTFT約4秒，PD傳輸（HCCS）< 8ms，TPOT ≈ 20毫秒。

為實現上述性能，團隊在系統層面進行了多項優化：負載均衡方面，通過重新分配計算任務，使各CP rank計算量均衡。

融合算子方面，減少計算過程中的內存訪問次數和Kernel啟動開銷。將多個連續的小算子合并為一個復合算子，使中間結果保留在高速緩存中，從而顯著提升計算效率。

多流并行方面，通過Cube與Vector計算單元并行執行算子，提升計算資源利用率。

同時，在Cube計算路徑中引入權重預取機制，實現數據搬運與計算階段的重疊，減少訪存等待帶來的性能損耗。

這些優化讓昇騰平臺在大規模、高復雜度推理場景中，實現了高吞吐、低延遲、資源高效利用的表現。

針對Qwen的優化則包括通用能力增強（圖模式、W8A8 量化、EAGLE3），為不同規模和形態等模型提供基礎性能支撐。

同時，引入昇騰親和性專項優化：利用多流并行，并在大EP（Expert Parallelism）場景中通過Dispatch/Combine流程將GMM計算融合處理，減少算子切換和中間調度開銷，提升整體執行效率。

除DeepSeek、Qwen外，SGLang在昇騰硬件上也已覆蓋KimiLongChat等模型，新模型可在不改代碼的前提下直接運行。

同時就像開頭所說的，這些模型的所有代碼均已合入SGLang主社區倉，開發者無需額外安裝插件，直接拉取主倉代碼即可使用。

昇騰表示這里的核心理念是盡量不動Models層，僅在底層完成硬件親和與性能提升

而這一系列進展背后，是昇騰與SGLang主倉的深度共建邏輯，也意味著AI算力與開源推理框架的融合進入新階段：

從架構層面看，昇騰相關優化已下沉到SGL-kernel-NPU算子庫，親和算子能力與代碼實現均在此集中維護演進。

Engine層作為核心優化區，支持EPLB、Graph Runner與MTP，覆蓋GPU與NPU等多硬件后端以實現統一推理能力。

緩存與通信則依托HiCache完成L1/L2及L3-L1直通優化，最底層的SGL-kernel-NPU則承載昇騰加速算子、量化算子及傳輸接口，實現開源能力與昇騰性能的雙向賦能。

整體來看，這些進展體現了昇騰與SGLang開源社區在推理系統層面的持續協同，也為后續更復雜推理與強化學習場景提供了穩定的工程基礎。

全面擁抱開源

在這次活動中，我們了解到，昇騰是今年七月份才正式啟動與SGLang的適配工作。薛曜表示，這一工作的目標很明確——全面擁抱開源、加速昇騰生態建設

在過去5個多月里，昇騰不僅補齊了多類主流模型的推理支持，還覆蓋了強化學習訓練、多模態理解與生成等關鍵場景，并在PD傳輸等系統層面持續優化，將SGLang on Ascend的整體性能推到了“可打”的水平

此外，據現場披露，昇騰已基于SGLang已在真實業務場景中，對DeepSeek V3.2完成了灰度測試。這意味著相關能力已不再停留在實驗或Demo階段，而是進入了真實生產環境的驗證周期。

從roadmap來看，昇騰接下來的演進方向也并非泛化擴展，而是明確圍繞“推理系統”展開的系統性工程投入

一方面，通過Zero Buffer、昇騰親和加速庫等機制，持續壓榨單機與多機推理吞吐，服務高并發、低時延的真實業務負載；

另一方面，在基礎軟件層構建昇騰版Triton生態，與SGLang、vllm等開源引擎保持接口與演進節奏對齊，使模型上線、算子開發與性能調優形成可復用路徑。

這些動作共同指向了一個清晰變化：昇騰不再只是“能否支持某個模型”的硬件選項，而是開始以推理系統為核心，被納入開源工程的主線討論與默認方案評估之中

當模型、推理引擎與算力平臺在工程層形成穩定協作，AI算力真正需要回答的問題，也將不再是“能不能跑”，而是“系統能不能長期跑、規模化、穩定地跑”。

因為說到底，高性能、易用性、開箱即用才是真道理。