延迟、吞吐量和成本优化是现代推理工程的核心。如果不进行测试和测量，这些指标就无法可靠地改进。
我们一直专注于推理性能已经 有一段 时间 了，现在我们正在构建几款新工具，帮助你优化自己的推理服务器——首先是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 上启动生产发布。你的其他 Candidate 仍然可用，因此你可以继续独立测试它们。
Endpoint Candidates 使用标准 Modal 计算定价，包括用于镜像请求的计算资源。
保持生产持续运转
构建流量镜像时，其中一个难点是避免慢速镜像拖住生产环境。当多个 Candidate 收到一个大请求的副本时，它们读取数据的速度可能不同。一个代理最终可能会缓冲大量数据同时等待较慢的 Candidate。
为了解决这个问题，我们扩展了基于 Pingora 的代理，将每个请求流分叉到为每个接收副本的 Candidate 单独设置的、有界缓冲区中。每个镜像独立读取：如果新数据块到达而某个缓冲区已满，代理会取消该镜像请求，而生产环境和其他镜像继续运行。
但为每个镜像设置一个有界缓冲区仍然留下一个问题：一个繁忙的代理可能同时镜像许多请求。因此我们还限制了每个代理进程中镜像保留的请求体数据总量。它们共享请求体数据块，因此每个数据块在这个预算中只计一次。
从缓冲区中移除一个数据块并不一定释放其内存，因为网络写入可能仍持有它。我们会继续计入该数据块，直到最后一个镜像释放它。如果加入下一个数据块会超出预算，代理会取消该请求的镜像，而原始请求继续运行。
镜像在设计上就是尽力而为的：镜像请求可能在压力下被丢弃，因此生产环境不必等待缓慢或失败的 Candidate。
下一步
我们正在扩展创建和评估 Candidate 的方式，从对计算放置和部署方案的更多控制，到用于比较部署的更丰富的指标视图。
我们也在努力将更多这类实验自动化。当我们推出 Auto Endpoints时，我们描述了在自动化推理优化方面的工作。Candidate 为这些优化提供了一个证明自己的场所：一种让 Modal 针对你的流量测试有前景的改动，然后展示在延迟、吞吐量或成本方面测得的改进的方式。