Modal 发布 Auto Endpoints，提供可自主掌控的 LLM 推理服务

Modal 让 Cognition、Decagon、Fathom 和 DoorDash 等领先团队能够拥有自己的推理能力，而无需在成本性能或开发者速度上妥协。

现在，你只需一条命令即可做到同样的事情：

隆重推出 Modal Auto Endpoints：一条顺畅、自助式的通道，通往生产级 LLM 推理。

立即体验，或继续阅读，了解我们如何构建它以及为什么这样做。

为真正拥有自己推理能力的时代而构建

专有模型提供商可能会悄悄降低模型质量或突然收回访问权限。如果你不拥有自己的推理能力，你就无法掌握自己的命运。

如果你使用由推理提供商服务的开放模型，你会获得一定的控制权。但我们认为，所有权比 API 更深入。要真正拥有你的推理能力，你需要拥有、理解并优化运行推理的代码。

托管推理提供商让你轻松获得 API，但服务栈是一个黑盒。因此直到现在，想要真正拥有自己推理能力的团队只有一个选择：自己搭建推理服务。这给了你控制权，但你现在拥有的远不止推理：引擎调优、端点基准测试、容器部署、副本自动扩缩容与路由，以及推理指标。

这就是我们构建 Modal Auto Endpoints 的原因，也是它们与传统推理提供商所提供的东西看起来非常不同的原因。

一个 Modal Endpoint 是一个兼容 OpenAI API、生产就绪的服务，背后由你可以查看和控制的 Modal App 支撑。

这种方法有三个关键区别：

• 我们不隐藏代码。从 GPU 选择和区域化，到推理引擎标志，再到偶尔的引擎补丁，一切都与你共享。
• 我们不隐藏指标。你调试推理问题真正需要的指标，比如投机解码接受长度和每个副本、引擎侧的 token 延迟分位数，都会自动显示在仪表盘中。门槛很低，但我们确实把它放在那里了！
• 我们不躲在“联系销售”按钮后面。你可以通过 CLI 命令或点击操作部署 GLM 5.2 等前沿开放模型，而不是通过 Zoom 通话。如果你想获得更多专业知识，我们随时欢迎。

为推理而构建的基础设施

我们能够提供这一切，是因为我们构建在坚实的基础之上：Modal 的AI 基础设施平台。

我们的用户在这个平台上折叠蛋白质、驱动机器人和创作音乐。在那里发挥作用的基本组件同样适用于 LLM 推理，无论是手工搭建还是通过 Auto Endpoints。

使用 Modal，你无需预留数月昂贵的 GPU 容量来应对无法估算的负载。相反，你按使用量付费，随用随付，并通过我们的高性能自动扩缩容系统和自定义容器运行时按需扩展。你可以使用世界各地的 GPU，或靠近用户的 GPU，而无需担心容量管理。这是我们的招牌，这一点不会改变。

我们还新增并发布了系统的一个新基础组件（已从测试版转为正式版），以支持低延迟推理的需求：用于超低延迟路由的 Modal Servers。

Modal Servers 保留了 Modal Web Functions 的弹性伸缩和深度计算能力。但它们去除了排队，并默认按区域划分，因此你可以在 Modal 上以仅 5ms 的开销服务 HTTP 请求——同时不牺牲可靠性和自动扩缩容。关于我们如何实现这一点，本周晚些时候会有更多介绍。

一键获得高性能推理代码，而非苦熬硬磨

推理引擎类似于数据库管理系统，比如 PostgreSQL：复杂、任务关键型软件，必须在硬件极限下运行。与数据库一样，这类软件有着复杂的内部结构，通过众多旋钮暴露出来，而要实现尽可能最佳的性能，就需要学会调校这些旋钮。

这是一项艰苦的苦差事。当一个团队希望自建推理，却习惯于基于专有模型 API 构建时，很容易倾向于保留 API 层抽象，并将推理性能问题外包给开源权重模型的专有封装。

Auto Endpoints 让你兼得两者之长：性能，且毫不费力。对于每个受支持的模型，我们都会提供一个起始部署方案，其依据是我们与构建世界上一些最严苛 AI 产品的团队合作的经验。你无需指定 GPU 类型，也无需摆弄像 --mamba-scheduler-strategy 或 --flashinfer-mxfp4-moe-precision 这样的引擎标志，直到你准备好为你的工作负载做定制优化。

我们是在与专有推理提供商的直接竞争中开发出这些方案的。我们靠押注开源而胜出——必要时对底层 SGLang 等推理引擎和 FlashAttention-4 等内核打补丁并向上游贡献改进——并且全力投入投机解码。

我们尤其喜欢来自 Z Lab 的 DFlash 块扩散草稿模型架构，并在每个兼容模型上使用它。我们与 Z Lab 和 SGLang 团队紧密合作，让 DFlash 在真实服务系统中快速且可靠，并且我们训练并发布了自己的 DFlash 草稿模型，以扩大支持范围并确保它们发挥最佳性能。

在你设置 Endpoint 时，我们会向你展示我们的基准测试结果：

Endpoint 部署完成后，你可以一键测试它，查看延迟与吞吐量之间的权衡，并了解整个自动扩缩容、多副本服务在负载下的表现。

当然，推理没有放之四海而皆准的配置。一个低延迟分类 Endpoint 和一个多轮智能体循环并不想要相同的服务设置。Modal Auto Endpoints 会从我们在拉取 trace 之前会采用的配置开始：干净、可检查、经过基准测试，并准备好针对工作负载进行调优。

引擎级可观测性

在基准测试上的性能还不够。生产环境中的性能需要是可观测的。拥有自己的推理意味着能够一直看到引擎内部，从而改进性能并定位应用问题的根因。

Modal 提供指标（在 Dashboard 中以及通过 OTEL 导出）来了解 Endpoint 性能，分为两组：

• 服务器指标：传统的 Modal App 指标，包括 GPU 温度、功耗和利用率
• 推理指标：推理引擎导出的标准指标，如首 token 时间（TTFT）、token 间延迟（ITL）、排队和投机解码接受长度

服务器指标远比任何推理服务提供商所公开的都要深入得多。但即便只是推理指标，我们提供的细节也要丰富得多。下面是一个示例仪表盘，展示了一个视觉语言模型 Endpoint 正在处理一次（相对于基线）较大的流量峰值。

让我们逐一解读它所展示的内容。

随着负载增加，处理基线负载的单个容器（容器图表中的绿色部分）表现出不断攀升的 TTFT（左上图；由 prefill 排队引起），随后是升高的 ITL（右上图；由 decode 排队引起）。结果是端到端延迟增加（左下图）。

Modal 的自动扩缩容系统自动启动了另外两个副本。队列缩短（右下图），延迟恢复到可接受的水平——没有 PagerDuty 告警，只有基础设施和自动化。

走向“全自动”：开局出色并持续改进

我们基于工作负载和 SLO，以声明式接口设计了 Auto Endpoints。该接口源自我们与客户一起、并为客户思考推理服务基准测试和优化的方式。这是我们从多年来与顶尖团队合作进行推理部署中学到的。

但我们设计它时并非着眼于过去，而是着眼于未来——一个推理端点工程完全自动化的未来。

我们最初是手写 Endpoints 部署代码的——或者说，是如今软件工程意义上的“手写”。现在我们通过一个内部的自动研究风格的智能体系统来生成它们，该系统知道如何配置推理引擎，并在保持正确性和质量的同时对性能进行爬山优化。本周晚些时候会有更多相关介绍。

目前，该智能体系统仍由人类工程师监控，以确保我们只交付生产级推理代码来为你的 Endpoints 提供支持。但人工智能进行软件工程的改进轨迹是清晰的，我们正滑向冰球将要到达的位置。

例如，我们的推测模型很出色（例如在多项基准测试中比基线快 4 倍以上，比其他推测模型快 1.5 倍以上）。但它们也是通用的——被训练来从处理广泛任务的目标模型中猜测输出。当推测模型在生产环境中它们（以及目标模型）将看到的数据上进行训练时，会变得好得多得多。

我们与一些最复杂、对延迟最敏感的用户一起训练定制推测模型。本周晚些时候也会有更多相关介绍。但我们不想让推理性能的改进受制于人类工程师来启动和照看训练运行。我们还在开发自动检测重新训练推测模型的机会，以及利用这些机会的自动化训练流水线。

我们所看到的 Auto Endpoints 的终态——正如其他适合优化的软件工程任务一样——包含所有这些自动化层级：

• autoinference：配置、修补和基准测试推理服务器
• autospec：基于合成数据和生产数据创建并更新推测模型
• autodistill：将已部署模型的能力蒸馏到更小、更快的模型中
• autoresearch：开发性能特性、推理引擎，甚至模型

所有这些都构建在我们最先构建的东西之上：autoscaling 基础设施。这就是复利效应的样子。

立即试用

点击此处，通过 Modal Auto Endpoints 掌控你的推理。