摘要
Together AI 平台上的专用模型推理由三部分组成：端点（您或您的客户端调用的稳定名称）、部署（其后运行副本的特定模型 + 硬件组合）和配置（模型运行方式的配方）。一个容量感知的流量分配将这三个实体联系在一起。这种架构支持各种其他功能，如滚动发布、A/B 测试、影子实验、零停机变更。下面我们将展示容量感知路由如何针对具有测量流量的实时端点工作。
资源模型如何工作
- 配置是一个配方，指定引擎、GPU 类型和数量以及并行度和优化配置文件（吞吐量、延迟、平衡）。配置是不可变的，每个配置都有一个像
cr_...这样的 ID。您的部署始终指向经过测试的确切配置。 - 部署将一个模型（在特定修订版）绑定到一个配置，为其提供自动缩放策略，并运行副本。部署是有意可丢弃的，创建和销毁应视为常规操作。
- 端点是一个固定标识：一个限定名称（
<project_slug>/<endpoint_name>），您的应用程序在普通推理 API 中将其作为model参数传递。端点有一个流量分配，用于确定其部署上的请求路由。
理解这一点的一个简单方法是参考 ID，系统中的每个 ID 都通过前缀告诉你它是什么，这使得日志和脚本自文档化：proj_（项目）、ml_（模型）、cr_（配置修订版）、endpoint_、dep_（部署）、rol_（滚动发布）。
平台上的每个高级操作都只是“添加一个部署，并为其分配流量路由权重” A/B 测试是带有队列分配的部署。影子实验是权重为零的部署接收镜像流量。停止部署是将最小和最大副本数限制为 0/0。
基于权重的流量分配
流量分配是一个 {deployment_id, weight} 条目列表，其中权重是每个就绪副本的。路由器计算每个部署的有效容量为 weight × ready_replicas，并按此容量比例路由。
浏览上图：两个部署的权重都是 1，但部署 A 有 1 个就绪副本（容量 1），部署 B 有 3 个（容量 3），因此流量遵循 25%/75% 分配。相等的权重意味着每个副本的负载相等，而不是流量份额相等。
我们这样设计是因为它使路由和缩放成为同一个话题：
自动缩放免费组合。当部署 A 从 1 个副本扩展到 3 个时，其容量增加三倍，并自动吸收相应更多的流量。使用简单的百分比，固定在“25%”的部署在缩小时会饱和，在扩大时会空闲。每个副本的负载是您控制的。权重 1 与权重 2 表示“B 的每个副本应该比 A 的每个副本工作两倍努力”未就绪的副本不计入。处于冷启动中或降级为 0 个就绪副本的部署贡献零容量，因此流量流向实际可以服务的部署。
权重是正数，没有总和约束，因此 0.7/0.3
和 700/300
描述相同的路由。如果你希望无论副本数量如何都保持固定的流量份额，可以设置 A/B 实验组，允许整数百分比且总和为 100%。
设置拆分是一个带有字段掩码的 PATCH 请求：
⚠️ 重要提示
全新部署在出现在端点的流量分配中之前不会获得任何流量。如果您创建了一个端点和部署，使其处于 `READY` 状态，发送请求后却收到 `routing_error`，这很可能是因为未指定流量分配，路由器尚未被告知该部署应接收流量。CLI 的 `together beta endpoints deploy` 命令会自动为您设置流量分配，这就是快速入门“开箱即用”的原因，但原始 API/SDK 路径需要手动设置此项。
内部机制：选择配置
您无需从头编写配置。支持模型目录中的每个模型都附带部署配置文件，这些是经过认证的模型+配置组合，我们对其进行了基准测试并持续改进：
从那里，您可以将模型和配置资源名称复制到部署创建中：
当您在配置之间进行选择时，选择器会告诉您每个方案优化了什么：
优化轴是您花费最多时间进行选择的方面。
- 延迟配置文件优化首令牌时间：较小的批次、急切调度，每个请求更快获得关注，但以每个GPU的总令牌/秒为代价。
- 吞吐量配置文件打包更大的批次：最大化每个GPU小时的聚合令牌，单个请求需要等待更长时间才能加入批次。如果您正在构建交互式聊天，您可能希望选择延迟，而离线管道和批量摘要可以使用吞吐量配置。
- 平衡是当您的流量同时具有两者时的一个良好默认选择。
配置是不可变的，因为cr_修订版本永远不会改变，即部署的行为不会因为有人在共享配置上“调整了一个标志”而漂移。更改是一个新的修订版本；旧版本仍然是一个有效的、经过测试的回滚目标。投机解码也可以从这里触发，因为草稿模型是配置的一个属性。
边缘情况
1. 部署在流量拆分中但具有0个就绪副本。
因为容量 = 权重 × 0 = 0，它不会接收流量；其他部署将吸收其份额。当副本恢复时，流量会自动按比例回流。
2. 我可以删除仍在流量拆分中的部署吗？
您应该先将其从拆分中移除，然后再删除。拆除顺序包括：排空流量 → 停止 → 删除，API会引导您按此顺序操作。
3. 流量拆分 vs. A/B成员百分比 vs. 金丝雀步骤百分比
流量拆分权重（容量相对，稳态路由），A/B成员百分比（整数队列份额，总和为100，且无论副本数量如何都固定），以及金丝雀步骤百分比（滚动的过渡计划）。这三个是用于三个不同任务的三种不同工具，它们以固定顺序组合：路由首先解析权重拆分（按容量采样的候选部署），然后A/B实验在候选部署是其对照组时重新采样（将对照组的份额细分给各个分支），然后活动滚动在候选部署是其源时重新采样（按当前步骤百分比在源和目标之间拆分），最后在获胜部署内选择一个集群。滚动会代表您操作其阶段。
4. 我的客户端使用的名称是什么？
类似于 <project_slug>/<endpoint_name> 的端点
可以作为标准推理API中的 model 字符串传递。即使您选择执行滚动、更换硬件或运行A/B测试，该名称也将保持不变。
展示容量感知路由的实验
我们针对一个实时端点运行了此测试，该端点有两个单 H100 部署，以展示权重模型流量拆分的效果。两个部署各有权重 1，且每个部署初始有一个就绪副本。我们发送了 599 个带标签的请求，并将每个请求归因于其服务的部署，然后将 A 从 1 个副本扩展到 2 个副本，再发送 599 个请求，部署端捕获的路由结果如下：
因为路由遵循容量，而容量又遵循副本数。在部署 A 内部，其两个 Pod 各承载约 30–40% 的总流量（39.6% 和 29.9%），路由器也在 Pod 之间进行负载均衡。
为了具体说明性能配置的权衡，我们使用演示端点中的两个认证配置进行了扫描，每个配置一个副本，60 秒闭环测试，并发数分别为 4、8、16，生成 200 个 token，token 计数来自 API 自身的 usage 字段：
这张表充分说明了测量的意义：B 在低并发时胜出，然后急剧下降。 A 的批处理能力良好，从 c4 到 c16 吞吐量提升 4 倍，TTFT p95 仅上升约 17%。B 在并发 4 时比 A 更快，然后饱和：超过 c≈4 后，其有效请求率停止增长，总吞吐量减半，每分钟有少量请求开始完全停滞。如果你只在并发 4 时进行负载测试，你可能会为高并发工作负载选择 B，然后才在生产中发现这种行为。
两种配置都没有“错误”，它们只是服务前沿上的不同点，而你的模型的配置会有自己的曲线。起始配置为你提供了一种测试起点的方法；像这样一小时的扫描可以告诉你哪种配置适合你的流量。
自己试试吧！
整个模型，只需五个命令：
从这里开始，本系列的其他内容只需再部署一次即可。