SGLang原生支持昇腾，新模型一键拉起无需改代码

来源：市场资讯

（来源：量子位）

当Agent在应用侧不断加速，推理系统能否承受随之而来的真实负载，正在成为行业关注的焦点。

这是12月20日在杭州收官的SGLang AI 金融 π 对上，被反复提及的一个背景。

在这场聚焦大模型推理效率的“π对”上——

Agent的Vibe被暂时搁到一边，真正摆上桌面的，是推理系统在真实负载中的工程问题：高并发请求长上下文窗口多轮推理内存管理，以及在具体金融agent场景下的一致性生成问题。

同时，在活动讨论中，昇腾作为算力平台也被多次提及。

当前，昇腾已作为SGLang原生支持的后端之一进入主仓库，随着 SGLang推理引擎的更新，DeepSeek、Qwen、GLM等模型可以在不调整模型参数、不引入额外插件的情况下直接运行，HiCache、Mooncake等系统能力也在对应版本中引入。

可以说，这次SGLang AI金融π对呈现的，并非零散技术点，而是一条清晰的推理工程演进路径——从缓存与内存体系，到权重更新、强化学习效率，再到算力与模型生态的协同。

接下来，我们具体来看。

这次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在昇腾平台上的最新进展，覆盖模型适配、性能优化及系统加速能力模块化沉淀。

主要亮点如下：

在具体的模型上，昇腾此次实现了对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算力真正需要回答的问题，也将不再是“能不能跑”，而是“系统能不能长期跑、规模化、稳定地跑”。

因为说到底，高性能、易用性、开箱即用才是真道理。