Modal Auto Endpoints 发布：真正归你所有的优化推理

新闻

2026年6月23日·5分钟阅读

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，而无需担心容量管理。这是我们的名片，这一点不会改变。

我们还为系统新增并发布了 beta 版的一个基础组件，以支持低延迟推理的需求：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 部署完成，你可以一键测试，审查延迟和吞吐量的权衡，并查看整个自动扩缩容、多副本服务在负载下的表现。

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

引擎级可观测性

基准测试上的性能还不够。生产环境中的性能需要可观测。拥有你的推理意味着能够深入查看引擎内部，以便你改进性能并定位应用问题的根本原因。

Modal 提供指标（在仪表盘内和通过 OTEL 导出）来理解端点性能，分为两组：

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

服务器指标比任何推理服务提供商暴露的都要深入得多。但即使在推理指标方面，我们也提供了更多细节。这是一个示例仪表盘，显示了一个视觉语言模型 Endpoint 处理一个（相对于基线）较大的流量峰值。

让我们看看它展示了什么。

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

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

走向"全自动"：从优秀开始，持续改进

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

但我们并非向后看设计它。我们向前看，朝着推理端点工程完全自动化的未来设计它。

我们最初是手动编写 Endpoints 部署的代码——或者说，按照当今软件工程的方式"手动"编写。现在我们通过一个内部的自动研究风格的 agentic 系统来生成它们，该系统知道如何配置推理引擎，并在保持正确性和质量的同时优化性能。本周晚些时候会有更多相关内容。

目前，这个 agentic 系统仍由人类工程师监控，以确保我们只提供生产级的推理代码来驱动你的 Endpoints。但人工智能在软件工程方面的改进轨迹是清晰的，我们正朝着那个方向前进。

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

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

我们为 Auto Endpoints 设想的最终状态——如同其他适合优化的软件工程任务一样——包括所有这些自动化层级：

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

所有这些都建立在我们最初构建的 autoscaling 基础设施之上。这就是复合效应。

立即尝试

点击此处，通过 Modal Auto Endpoints 拥有你的推理。