Modal 发布 Endpoint Candidates，可在生产流量上评估并晋升推理端点

延迟、吞吐量和成本优化是现代推理工程的核心。如果不进行测试和测量，这些指标就无法可靠地改进。

我们关注推理性能已经有一段时间了，并且正在构建几款新工具来帮助你优化自己的推理服务器——首先是Endpoint Candidates。

Endpoint Candidates 允许你为Dedicated Endpoints暂存替代部署，以便评估其对质量、延迟、吞吐量和成本的影响。每个 Candidate 都可以镜像生产环境，处理一部分生产流量，同时由 Modal 运行底层基础设施。当你准备好时，可以从仪表板将 Candidate 提升到生产环境。

借助 Candidates，你可以测试新的模型检查点——甚至完全不同的模型——而无需自行搭建流量镜像和部署基础设施。Endpoint Candidates 现已面向所有 Modal 工作区正式可用。

快速开始

要创建新的 Candidate，请从 Modal 环境中现有的 Dedicated Endpoint 开始。选择Create candidate，从 Modal 的模型目录中选择一个开放模型，或从 Hugging Face 仓库或 Modal Volume 中引入你自己的权重。

Candidate 准备就绪后，配置流量采样，开始将生产流量镜像到它。生产环境会继续处理每一个原始请求，并返回用户看到的响应。

使用仪表板检查 Candidate 的推理指标，包括延迟和吞吐量，并运行性能基准测试以了解其在负载下的行为。每个 Candidate 还有自己的 URL，因此你可以对其运行现有的评估来评估输出质量。

当你准备好时，从仪表板提升该 Candidate。Modal 会在现有 Endpoint URL 上启动生产发布。你的其他 Candidates 仍然可用，因此你可以继续独立测试它们。

Endpoint Candidates 使用标准 Modal 计算定价，包括用于镜像请求的计算。

保持生产持续运行

构建流量镜像的挑战之一，是避免缓慢的镜像拖慢生产环境。当多个 Candidates 收到大型请求的副本时，它们可能以不同的速度读取数据。代理可能会在等待较慢的 Candidates 时缓冲大量数据。

为了解决这个问题，我们扩展了基于 Pingora 的代理，将每个请求流分叉到为每个接收副本的 Candidate 单独设置的、有界缓冲区中。每个镜像独立读取：如果新数据块到达而某个缓冲区已满，代理会取消该镜像请求，而生产环境和其他镜像继续运行。

但是，为每个镜像设置一个有界缓冲区仍然存在一个问题：繁忙的代理可能同时镜像许多请求。因此，我们还限制了每个代理进程中镜像保留的正文数据量。它们共享请求正文数据块，因此每个数据块在此预算中只计算一次。

从缓冲区中移除一个数据块并不一定释放其内存，因为网络写入可能仍持有它。我们会继续计算该数据块，直到最后一个镜像释放它。如果添加下一个数据块会超出预算，代理会取消该请求的镜像，而原始请求继续运行。

镜像在设计上就是尽力而为：在压力下，镜像请求可能会被丢弃，因此生产环境不必等待缓慢或失败的 Candidate。

接下来是什么

我们正在扩展创建和评估 Candidate 的方式，从对计算放置和 serving recipes 的更多控制，到用于比较部署的更丰富的指标视图。

我们也在努力将更多此类实验自动化。当我们推出 Auto Endpoints 时，我们描述了在自动化推理优化方面的工作。Candidate 为这些优化提供了一个证明自身价值的地方：一种让 Modal 针对你的流量测试有前景的变更，然后呈现延迟、吞吐量或成本方面可衡量的改进的方式。