“无服务器”承诺的是客户可以把哪些事务交给平台管理，后台工作依然存在。一次 chat-completions 请求抵达后，服务平台仍要放置模型权重，保留或重建一段对话的 KV cache，协调多台加速器，发现停滞的 worker，并在流量激增造成排队前补充容量。接口可以呈现为无状态，背后的机器却始终有状态。

这层张力让 DeepServe: Serverless Large Language Model Serving at Scale 值得一看。DeepServe 是华为云与北京大学共同开发的系统，相关成果发表于 2025 USENIX Annual Technical Conference。演讲一开始，Junhao Hu 就说明，内容重点落在系统投产过程中积累的设计判断上，基准成绩退居其后。论文记录了系统在华为大型 Ascend NPU 集群上超过一年的运行情况，服务范围包括微调、智能体（agent）与模型推理 API。[1][2]

这段16分钟的英语录像由 USENIX 录制并上传。观看时可以留意四组相连的概念：request–job–task 抽象、模块化的 FlowServe 引擎、合置与分离式 prefill/decode worker 之间的路由，以及依靠预热就绪的软件环境和就近存放的模型权重完成弹性伸缩的办法。它们共同显出“无服务器”藏起了哪些工作，而这些工作依旧复杂。下列时间点只作观看路标，配文属于导读。[1]

0:18–3:20——架构图出现以前，状态已经到场

Hu 先把 DeepServe 放进一个更广的内部平台：推理、后训练与智能体服务共享同一资源池。随后，他点明底层硬件是华为 Ascend 加速器与 CloudMatrix384 SuperPod。一个 SuperPod 包含48个节点、384个 NPU，pod 内采用高速互连，速度远高于 pod 之间的横向扩展网络。[1][2] 这段介绍远不止硬件前言，它先划出了服务设计所受的物理约束：张量和权重要跨越多远的距离。

约在 2:36，演讲从这套底层硬件引出三个问题。模型已经从单节点程序变成分布式系统；复用 KV cache 会让推理带上状态；需求持续变化，系统需要伸缩，同时要避开新实例经历传统冷启动的漫长等待。这三项要求彼此牵扯：把请求发给最空闲的 worker 有助于均衡负载，发给保存有用前缀的 worker 可以保住既有计算，新建 worker 时，两项优势都有落空的风险。[1][2]

这里首先修正了人们对“无服务器”标签的理解。客户提交 HTTP 请求时可以不指定机器，供应方调度时仍须辨认机器之间的差异。调度器要在分散的局部优势之间权衡。例如，先前提示词的缓存张量留在某个任务执行器上，另一执行器附近的主机内存中预先驻留着模型权重，队列最短的又是第三个执行器。DeepServe 要在这些物理事实之间作出选择，同时让它们留在 API 契约之外。[2]

3:24–8:18——request、job 与 task 分开用户意图和伸缩单元

约在 3:24，Hu 提出演讲中最简洁、也最经得起时间的一套抽象。request 是外部触发；一个或多个 job 将请求解释为 chat、微调或其他服务；每个 job 再创建 task，也就是最小工作单元，而任务执行器是平台伸缩的最小单位。合置式 chat 引擎所需的 task 有时只有一个，同一项用户请求若采用 prefill/decode 分离，则会拆成独立的 prefill task 与 decode task。[1][2]

这套层级有意保持朴素，因为 Hu 解释说，系统的许多开发人员主要来自算法或数据领域。这种简明划分也划出了职责边界：job 执行器理解工作流并分派工作，task 执行器则专注于特定功能并横向扩展。一套关系型张量缓存横跨这些执行器，充当保存 KV 状态的共享数据平面。分布式现实仍然留在系统里，只是从此有了一套可供自动伸缩器与调度器操作的词汇。[1][2]

本节后段的两个运行细节，让图示落回真实系统。约在 7:39，Hu 谈到一类推理进程：它接受请求后挂起，进程本身仍然存活。健康检查因此要把迟迟没有输出视为故障信号，再主动终止卡住的组件。约在 8:00，他指出，为大型 decode 实例安排资源时，有时要用成组调度（gang scheduling），甚至需要驱逐其他实例，才能汇集足够的连续容量。[1] 按论文采用的故障模型，失效的 job 或 task 执行器会重启，流量会转到冗余对等节点；关系型缓存保存只追加、可重算的“软”状态，把复杂一致性协议的成本留在方案之外。[2]

调用者面对的是无服务器服务，运营方处理的则是状态。平台明确安排健康检查、组件替换、缓存丢失处置与协同分配，才得以藏起 worker 身份。

8:22–13:05——FlowServe 将其余工作移出 NPU 的时间线，让它保持忙碌

FlowServe 一节先列出三条设计原则：受微内核启发的模块化、以 NPU 为中心的执行，以及单程序多数据并行。FlowServe 借用的是操作系统微内核的模块思路，自身仍是一套服务引擎。token 化、调度、张量缓存管理、网络通信和执行彼此分开，各部分可以独立演进或扩展，整套服务引擎也保留可拆分性。[1][2]

约在 9:26，一项具体的工程选择很能说明问题。团队把变化较快的控制平面大多留在 Python 中，同时把影响性能的张量传输和缓存换入换出移到 C++。这里的衡量标准是迭代速度与延迟成本，编程语言的高下排除在外：一部分代码受益于快速迭代，另一部分代码稍有延迟，昂贵的加速器就会等待。独立运行的 tokenizer/detokenizer 进程遵循同样的思路；流式传输的捷径也会直接返回已完成的输出，省去逐层折返内部链路的时间。[1][2]

约在 11:04，关系型张量缓存来到设计中心。它为可复用的提示词前缀建立索引，并协调 NPU 高带宽内存、主机 DRAM、SSD 与其他服务引擎中的张量。一次缓存命中是否划算，还要交给成本模型判断。FlowServe 会比较取回保留张量与重新计算所需的时间；只有取回更省时，它才异步传输这些张量。一个批次运行时，调度器已经开始准备下一个批次，CPU 调度和数据移动便不会在 NPU 的时间线上留下空泡。[1][2]

约在 12:48，这项取舍露出代价。提前一步调度时，停止条件有时会在下一个 token 已经算完后才抵达；此时，系统可以丢弃额外的一个 token，让加速器免于等待前一项结果。这个细小例子浓缩了 FlowServe 更大的策略：只要偶尔作废控制工作的代价低于稀缺设备空转，系统就提前完成带有推测性的控制工作。[1][2]

论文中的性能图需要放在其评测范围内阅读。FlowServe 的离线对比采用一个参数量为340亿、张量并行度为4的模型，输入长度为 2K 或 4K token，decode 共256步。在线 prefill/decode 对比采用一份内部负载轨迹，输入约 2K token，输出约200 token。这些结果支持论文在所报告 Ascend 配置上的机制；换到其他模型、GPU、提示词组合或延迟目标时，倍率仍需重新验证。[2]

13:15–15:17——路由没有通吃的胜者，“冷”背后叠着一层层延迟

Hu 很快带过调度部分，其中包含整场演讲最重要的一项坦承：prefill 与 decode 合置或分离，没有通吃的胜者。更合适的选择会随提示词长度、预期输出长度、负载和干扰变化。DeepServe 先考虑 worker 类型；各 worker 负载接近时，再看缓存局部性；当负载失衡的代价超过复用收益时，最终选择负载最低的 worker。论文中的 decode 长度预测器先把问题收拢到以128个 token 为一档，准确率才达到84.9%；不确定性依然留在调度问题里。[1][2]

约在 14:08，演讲把横向扩容拆成环境准备、引擎初始化、模型加载、加载后设置与向集群通告就绪。Python 库、NPU 状态和跨设备通信组全从零开始时，仅前两个步骤就可带来超过10分钟的等待。DeepServe 借助预热 pod 和与模型无关的 task 执行器，把其中大部分工作提前完成。随后，它可以加载依据需求预测而预先放入主机 DRAM 的相应模型权重，也可以利用论文所称的 NPU-fork，经高速设备链路从运行中的 NPU 复制权重。[1][2]

这种弹性以库存为代价。预热 pod 在需求到达前就占用容量；DRAM 预加载要先预测下一次需要扩容的是哪个模型；NPU-fork 要有一个运行中的源实例和合适的互连。要做到“数秒内扩容”，系统会预先完成选定的昂贵步骤，并提前存放可复用状态。

15:19 以后——后续工作把软硬件协同设计写得更明确

最后一分钟超出了已投稿论文的范围。Hu 预告了一套面向大型混合专家模型、拆分得更深入的系统，以 DeepSeek-R1 为例，并指向专为 SuperPod 设计的通信层与服务方案。[1] 后续的 xDeepServe 报告把这条路线写得更具体：FlowServe 延伸到数百个 NPU，将注意力计算（attention）与前馈及专家计算（feed-forward/expert computation）分开，并在 CloudMatrix384 的共享内存互连上引入 XCCL 通信原语。[3]

华为后来的产品表述也延续了这个方向。2025年9月19日，在上海举行的 HUAWEI CONNECT 上，公司发布由 CloudMatrix384 驱动的 AI Token Service，并称这套超节点汇集计算、内存与存储资源，同时拆分不同类型的工作。[4] 这项发布可作为平台策略的商业证据，对各项性能主张的独立验证则在其证据范围之外。不过，它确实说明了这场研究演讲为何反复讨论放置、移动与模块化执行：华为把 token 级推理服务放在客户直接使用的一层，底层拓扑的复杂性由云平台处理。

DeepServe 最具迁移价值的经验落在一条分界上，Ascend 基准成绩居于其后。优秀的无服务器接口让用户可以忘掉实例，服务系统自身却必须记得：可变状态位于哪里，何时复用优于重算，一次请求的哪个阶段需要哪类 worker，以及多少预热容量才能让弹性成为现实。调用者看到的越少，供应方就越要有意识地看清底层。

来源

1. USENIX，“USENIX ATC ’25 — DEEPSERVE：大规模无服务器大语言模型服务”，Junhao Hu 演讲，2025年。
2. Junhao Hu 等，“DeepServe：大规模无服务器大语言模型服务”，2025 USENIX Annual Technical Conference，会议论文。
3. Ao Xiao 等，“xDeepServe：Huawei CloudMatrix384 上的模型即服务”，第一手后续技术报告，第1版，2025年8月4日。
4. 华为云，“华为云：培育算力沃土，助力行业 AI 先锋”，HUAWEI CONNECT 2025 报道，2025年9月19日。
5. 华为云，“华为云发布 CloudMatrix384 超节点，取得多项性能突破”，第一手中文发布报道及封面照片来源，2025年4月10日。