Modal 发布 Auto Endpoints，用推测解码实现 SOTA 推理延迟

本周，我们推出 Modal Auto Endpoints，将 Modal 基础设施的可扩展性和稳健性带给最先进的推理性能——只需一键点击，且不会失去对代码的控制。

我们如何实现如此高的性能？是因为有一支神级的内核编写团队？是因为我们的 GPU 集群和容器运行时？是因为我们在推理引擎里有什么独门秘方？还是因为我们把 agent 玩到了极致？

内核、算力、推理引擎和软件迭代速度都很重要，但就低延迟推理服务而言，粗略来说，你需要的只是推测。

具体来说，我们发现，如果你拥有 Blackwell GPU、像 SGLang 这样强大的开源引擎，以及像 Modal Servers 这样低开销的区域部署系统，那么只需在一项关键优化上做得更好，就能在延迟敏感的场景中追平甚至超越专有推理服务商：推测解码。

低延迟实战手册

如果你眯起眼睛看，transformer 推理服务大致是这样的：

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

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

客户端-服务器通信延迟
prefill 之前、prefill 与 decode 之间、以及各次 decode 之间的主机/通信延迟
Prefill 延迟
Decode 延迟

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

针对每一种延迟来源，我们都有对应的首选优化技术：

将服务器部署在靠近客户端的位置，并将路由/服务开销降到最低
使用主机开销低的推理引擎，消除你观察到的任何开销
为最先进的 GPU 使用光速内核，例如用于 B200/B300 的 FA4
使用高质量的 DFlash 草稿模型应用推测解码

由于 decode 通常对延迟贡献最大，推测解码对最终端到端延迟数字的影响也最大。

为什么你需要的只是推测

默认情况下，解码是串行的，每个输出 token 一次迭代。推测解码让多个 token 并行处理——这是一个避开 Amdahl 令人心碎定律、更好地映射到底层硬件的机会。就像处理器中的推测执行一样，你可以在不改变行为的情况下并行做更多工作，代价是有时会浪费一些工作。

在推测解码中，并行化来自让目标模型对由单独的推测器模型生成的一批猜测或“推测”token 进行运算：

当这些猜测不正确时，工作就被浪费了，如上图最后一个词所示。但在小批量下，不做推测的 transformer 解码并未用满 GPU 的算术带宽，因此即使浪费了大量工作，也不一定会拖慢执行。

投机解码带来的加速不是像内核优化或主机开销削减那样的小幅百分比提升，而是小幅倍数级提升，大致与平均接受 token 数（“接受长度”）呈线性关系：

我们在这篇文章中更详细地阐述了投机解码重要性的总体论证，以及接受长度的关键作用。

实现高接受长度最简单的方法是为特定应用定制推测模型。我们将结合一个具体应用来解释这一过程：Decagon Voice。

案例研究：Decagon Agent Operating Procedures

Decagon 是一个统一平台，用于构建、优化和扩展 AI 智能体，在各类渠道上提供礼宾级客户体验。语音是其中最重要的渠道之一。它是人类自然的沟通方式，但给支持自动化带来了挑战：

模糊的声波以及从中得出的语言模型推理结果，需要在下游系统中转化为明确的操作
为了感觉自然并避免让人类用户感到沮丧，响应需要端到端/嘴到耳地快速完成

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

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

我们特别聚焦于其中一个推理子系统，将 Modal 上约 290ms（p50）的基线实现缩短了 100ms，在同一工作负载上比专有推理提供商提供的最佳延迟还要快 60ms 以上。

我们如何应用低延迟打法取胜

降低通信延迟、主机开销和预填充延迟

为了保持客户端与主机之间的低通信延迟，我们使用了 Modal Servers。Modal 的动态全球计算集群确保无论你的客户端身在何处，都能在毫秒级内获得 GPU 容量。Modal Servers 在这个集群内运行的自动扩缩容副本池外包裹了超轻量级区域代理，因此部署无需在鲁棒性和可扩展性上妥协即可实现低延迟。关于它们的工作原理，我们将在本周晚些时候详细介绍！

当请求的输入 token 正由 GPU 处理时，延迟主要取决于 GPU 执行预填充内核的速度。分组查询注意力或专家混合多层感知机等关键操作的高质量内核已有开源实现。我们以这些为起点，并回馈了我们的改进。

在 HTTP 请求与内核启动之间，坐落着推理引擎。像 vLLM 和 SGLang 这样的高性能引擎已经开源可用。它们通常使用相同的 GPU 内核，因此主要的改进机会在于让 CPU 不要妨碍 GPU——避免主机开销。同样，我们从这些引擎出发，并回馈我们的改进，这些改进来自对工作负载进行性能分析、寻找 GPU 气泡，然后消除同步或加速主机逻辑。

最大的胜利：投机解码与“中期训练”

仅靠这些改进还不足以击败专有推理服务提供商。最终的胜利来自使用高性能的定制投机模型。与其他机器学习任务一样，如今我们不会从零开始。我们希望从预训练模型出发，然后进一步训练它们（“中期训练”），以将其应用于我们的特定任务。

“预训练”——从通用草稿模型出发

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

但正因如此，它们首先是训练时的优化。通过在推理时训练一个独立的投机模型，可以获得更好的性能。然而，MTP 投机器有一个很好的优势：它们复用了目标模型的表示，而目标模型当然“最清楚”自己接下来要说什么。

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

我们必须添加一个自定义算子和 Triton 内核来保持该投影的敏捷性（例如跨层批处理）。它还能并行生成草稿 token（类似 BERT 或单步扩散），这使其更适合具有高脊点算术强度的现代硬件。

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

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

“中期训练”——在任务特定的合成数据上微调

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

我们将其视为投机器的“中期训练”。中期训练是一个最近创造的术语，指的是在接触通用、互联网规模数据（“预训练”）之后的训练阶段。中期训练位于“后训练”之前，后训练阶段模型通过强化学习得到改进。我们预见未来投机器将通过 RL 进行训练（基于接受长度甚至加速比），这将与这种后训练完美对应。

Mid-training 是一个机器学习问题。这很好，因为 ML 问题通常不依赖于难以扩展的算法技巧，而是依赖于数据和算力，而这两者易于扩展。

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

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

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

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

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

例如，像这样的输出

对于训练 speculator 仍然有用，只要你为 <redacted> 填入合理的内容。你可以直接使用任何和所有公共数据集来获得大致对齐的提示，并通过目标传递它们，以使用相同的语法获得结构化补全。在这里，幻觉是一种特性，而不是缺陷。然后，这些合成生成的数据可以用来微调通用草稿，而不会暴露任何用户数据。

ML 项目中那团马蜂窝般复杂性的一小部分在这里确实显现出来了。由于你不再基于生产样本进行训练，你需要警惕过拟合。我们使用额外数据来跟踪分布外性能，观察是否有重大退化。我们发现这可以预测无法将高接受长度泛化到生产系统。

我们训练的自定义 DFlash speculator 模型能够将端到端延迟再减少 100 毫秒。这大约占服务器端解码总延迟的 40%，是在已经包含投机解码的强大基线上实现的。

有了自定义 speculator，我们比最快的替代方案快了整整 60 毫秒。

结果与下一步

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

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

目前，投机器训练相当依赖人工。我们的一些客户自行完成训练，也许会在接受长度下降时在 Modal 上触发一次训练运行。我们与其他客户合作，提供我们的训练和基础设施专业知识。但我们预计在不久的将来，投机器系统会基于积累的数据和智能体推理持续改进——autospec 用于 Auto Endpoints。更多内容即将推出。

如果你想加入 Decagon、DoorDash 和 Cognition 等团队，部署他们掌控的高度优化推理，就来Modal Auto Endpoints 上构建吧。