工程

2026年6月24日·10分钟阅读

本周，我们推出了 Modal Auto Endpoints，它只需一键点击，就能将 Modal 基础设施的可扩展性和鲁棒性带入最先进的推理性能，同时不丧失对代码的控制。

我们是如何实现如此高性能的？是靠 顶尖的 kernel 编写团队？是我们的 GPU 集群 和 容器运行时？还是我们在 推理引擎中有什么独门秘方？或者我们是在 搞 agent 极致优化？

Kernel、计算能力、推理引擎和软件速度都很重要，但说到低延迟推理服务，粗略来说，投机解码就是一切。

具体来说，我们发现，如果你拥有 Blackwell GPU、像 SGLang 这样强大的开源引擎，以及像 Modal Servers 这样低开销的区域部署系统，那么只需在关键优化——投机解码（speculative decoding）上做得更好，就能在延迟敏感场景下匹配甚至超越专有推理提供商。

低延迟攻略

粗略来看，Transformer 推理服务大致是这样的：

也就是说，客户端向推理服务器发送请求，服务器处理请求中的输入 token（"prefill" 阶段），然后顺序处理输出 token（"decode" 阶段）。

这个模型指出了四个延迟来源：

1. 客户端-服务器通信延迟
2. prefill 之前、prefill 与 decode 之间、以及 decode 之间的主机/通信延迟
3. Prefill 延迟
4. Decode 延迟

Decode 阶段通常是延迟的主要来源。通常有多个 decode 步骤；每个 decode 步骤都需要一次完整的前向传播，这需要将模型权重 从 GPU RAM 加载到 SM SRAM。因此，对 decode 路径的优化效果最为显著。

针对每个延迟来源，我们都有对应的优化技术：

1. 将服务器靠近客户端放置，并 保持路由/服务开销最小化
2. 使用 主机开销低 的推理引擎，消除 你观察到的任何开销
3. 为最先进的 GPU 使用光速 kernel，例如用于 B200/B300 的 FA4
4. 使用高质量的 DFlash draft 模型 进行投机解码

由于 decode 通常对延迟贡献最大，因此投机解码对最终的端到端延迟数字影响最大。

为什么投机解码就是一切

默认情况下，解码是顺序的，每个输出 token 一次迭代。投机解码使其在多个 token 上并行——这有机会避免阿姆达尔定律的残酷限制，并更好地映射到底层硬件上。与处理器中的投机执行非常相似，你可以在不改变行为的情况下并行做更多工作，代价是偶尔会浪费一些工作。

在投机解码中，并行化来自于在由单独的 speculator 模型产生的多个猜测或"投机" token 上运行目标模型：

当这些猜测不正确时，工作就会被浪费，如上图中最后一个词所示。但对于小 batch size，没有投机解码的 Transformer 解码并未充分利用 GPU 的 算术带宽，因此即使浪费了大量工作，也不一定会减慢执行速度。

投机解码带来的加速不是像 kernel 优化 或 主机开销减少 那样的小 百分比 改进。它们是小的 乘法 改进，大致与平均接受 token 数（"acceptance length"）成线性关系：

我们在 这篇文章 中更详细地阐述了投机解码的重要性以及 acceptance length 的关键作用。

实现高 acceptance length 的最简单方法是针对特定应用定制 speculator 模型。我们将结合一个具体应用——Decagon Voice——来解释这个过程。

案例研究：Decagon Agent Operating Procedures

Decagon 是一个统一平台，用于构建、优化和扩展 AI agent，在每一个渠道上提供礼宾级别的客户体验。Voice 是这些渠道中最重要的之一。对人类来说，它是一种自然的沟通方式，但它给支持自动化带来了挑战：

1. 模糊的声波以及从中得出的语言模型推理需要转化为下游系统中清晰的操作
2. 为了感觉自然并避免让用户沮丧，响应需要快速端到端/从口到耳

解决 1) 是 Decagon AI 团队在构建 Decagon Agent Operating Procedures (AOP) 产品时的核心工作。从定制模型到新颖的推理技术，他们致力于将口语化的自然语言指令映射到系统操作，具有代码般的精确性和严谨性。

我们与他们合作解决 2)：以尽可能快的速度运行该系统的推理组件。每一毫秒都很重要——节省的每一毫秒都为增加智能、添加功能、增强鲁棒性或降低成本留出了空间。

专注于一个特定的推理子系统，我们将 Modal 上的基线实现从约 290ms（p50）削减了 100ms，比专有推理提供商针对相同工作负载提供的最佳延迟还要快 60ms 以上。

我们如何应用低延迟攻略取得胜利

减少通信延迟、主机开销和 prefill 延迟

为了保持客户端和主机之间的低通信延迟，我们使用了 Modal Servers。Modal 的 动态、全球计算集群 确保我们在 距离客户端毫秒级 的位置拥有 GPU 容量，无论他们在哪里。Modal Servers 将超轻量级的区域代理包裹在运行于该集群内的自动扩缩副本池周围，这样部署就不必为了低延迟而牺牲鲁棒性和可扩展性。本周晚些时候会有更多关于它们如何工作的内容！

当请求的输入 token 正在被 GPU 处理时，延迟主要由 GPU 执行 prefill kernel 的速度决定。关键操作（如 grouped query attention 或 mixture-of-experts multi-layer perceptrons）的高质量 kernel 是开源可用的。我们以此为基础，并 回馈 了我们的改进。

在 HTTP 请求和 kernel 启动之间是推理引擎。像 vLLM 和 SGLang 这样的高性能引擎是开源可用的。它们通常使用相同的 GPU kernel，因此改进的主要机会在于让 CPU 不干扰 GPU——避免主机开销。同样，我们从这些引擎开始，并 回馈 我们的改进，这些改进是通过分析工作负载、寻找 GPU 气泡，然后消除同步或 加速主机逻辑 得出的。

重大胜利：投机解码和"mid-training"

仅靠这些改进还不足以击败专有推理提供商。最终的胜利来自于使用高性能的定制 speculator 模型。与其他 ML 任务一样，我们现在不会从头开始。我们希望从预训练模型开始，然后进一步训练它们（"mid-training"），以将它们应用于我们的特定任务。

"预训练"——从通用 draft 模型开始

基于 DeepSeek 团队的工作，许多模型现在都发布了可用于投机解码的多 token 预测（MTP）头。这些头在训练中提高了质量，在推理中提高了性能，因此它们几乎是理所当然的选择。

但出于同样的原因，它们首先是训练时的优化。通过训练一个独立的 speculator 模型可以获得更好的推理性能。然而，MTP speculator 有一个很好的优势：它们重用了目标模型的表示，而目标模型当然"最了解"它接下来要说什么。

当代的投机解码技术都利用了目标模型的激活。我们发现 DFlash 技术 性能最佳，该技术由 Jian Chen 及其在 Z Lab 的合作者发明。该技术使用目标模型的 KV 投影，这减少了 draft 的冗余计算，并为解耦主机/设备和 draft/目标工作提供了更多机会。

我们必须添加一个自定义 op 和 Triton kernel 来保持该投影的快速（例如，跨层批处理）。它还并行生成 draft token（类似于 BERT 或单步扩散），这使其更适合具有高 ridge point 算术强度 的现代硬件。

我们与 Z Lab 和 SGLang 合作，发布了高性能的开源实现和预训练 speculator 模型，包括一个用于 Qwen 3.5 397B-A17B 的 speculator，其性能比 MTP 提升了 50% 以上。

你可以 在此处 阅读更多内容。

"Mid-training"——在任务特定合成数据上进行微调

定制 speculator 模型在目标模型所用于的特定任务上进行微调。通常，speculator 模型需要比目标模型更快，这也使它们不那么智能。因此，微调在这里甚至比在目标模型中更重要！

我们将此视为 speculator 的"mid-training"。Mid-training 是一个最近才被提出的术语，指的是在接触通用的、互联网规模的数据（"预训练"）之后的训练阶段。Mid-training 发生在"后训练"之前，后训练阶段通过强化学习改进模型。我们预见未来 speculator 将通过 RL（基于 acceptance length 甚至加速比）进行训练，这将完美地镜像这种后训练。

Mid-training 是一个机器学习问题。这很好，因为 ML 问题通常不依赖于算法上的聪明才智（这很难规模化），而是依赖于数据和计算（这 很容易规模化）。

但这也糟糕，因为 ML 很难，许多 ML 项目都失败了。

但我们认为，对定制 speculator 进行 mid-training 是"简单模式的 ML"。ML 中最难的问题——确保你的数据和目标反映现实世界和你的真实目标——基本上已经解决了。任何 ML 项目都旨在复制一个数据生成过程；在这里，数据生成过程已经是一个 ML 模型，即目标。它的数据生成 是可以理解的。

ML 中第二难的问题是基础设施，而 我们懂基础设施，这也没什么坏处。

但数据并不总是完全解决的。生产系统经常接触敏感数据——例如，考虑医院的客户支持热线。对投机解码模型进行侧信道攻击的可能性很小，但尚未充分探索。更具体地说，对用户数据的访问理所当然地受到限制，因此研究团队或像我们这样的外部供应商通常无法看到这些数据。

解决方案，就像其他数据稀缺的领域一样，是合成数据。特别是在具有强语法结构的任务中，例如代码生成、工具调用或结构化数据提取，合成数据可以捕捉到需要教给定制 speculator 的大部分内容。

例如，像

这样的输出对于训练 speculator 仍然有用，只要你用合理的内容填充 <redacted>。你可以使用任何和所有的公共数据集来获得大致对齐的 prompt，然后将它们传递给目标，以使用相同的语法获得结构化补全。这里的幻觉是一个特性，而不是一个 bug。然后，这些合成生成的数据可以用于微调通用 draft，而不会暴露任何用户数据。

ML 项目中复杂性的冰山一角在这里确实显现出来。由于你不再使用生产样本进行训练，你需要警惕过拟合。我们使用额外的数据来跟踪分布外性能，监控重大退化。我们发现这可以预测无法将高 acceptance length 泛化到生产系统。

我们训练的定制 DFlash speculator 模型能够从端到端延迟中再削减 100 ms。这大约占服务器端总 decode 延迟的 40%，而且是从一个已经包含投机解码的强基线中削减的。

有了定制 speculator，我们比最快的替代方案快了整整 60ms。

成果与下一步计划

我们在 Decagon 的朋友们 最兴奋的成果之一 是能够在 Modal 上自助部署——提高了开发速度，同时无需牺牲性能或控制。

优化推理所节省的额外几十毫秒，是他们可以在系统其他地方使用的货币，以改善结果。多一次工具调用或护栏，多几十个来自编排器或 agent 的 <thinking> token 以提高质量。

目前，speculator 训练相当手动。我们的一些客户自己进行训练，例如在 acceptance length 下降时在 Modal 上触发一次训练运行。我们与其他客户合作，提供我们的 训练和基础设施专业知识。但我们预计在不久的将来，speculator 系统将基于累积的数据和 agentic 推理不断改进——autospec 用于 Auto Endpoints。更多内容即将推出。

如果你想加入像 Decagon、DoorDash 和 Cognition 这样部署高度优化且可控推理的团队，请来 Modal Auto Endpoints 上构建。