Together AI 为 LLM 推理端点推出自动扩缩容

概述

借助 Together AI 平台上的专用模型推理，你可以让部署基于推理引擎真正理解的指标进行自动扩缩容，例如在途请求数、TTFT、GPU 利用率和 token 吞吐量。你可以设置副本数量上下限、选择指标和目标值，然后调整两个时间窗口，分别控制扩容的积极程度和缩容的耐心程度。理解并选择合适的指标很重要，因为它决定了你的部署在流量尖峰下的行为，并影响用户看到的延迟。下面我们将介绍如何选择合适的指标进行自动扩缩容，并展示一个实验：在三种不同的自动扩缩容策略下重放相同的负载。

过度配置和配置不足都很昂贵

使用专用推理时，你按副本-分钟付费，这使得容量规划成为两种失败模式之间的平衡：

• 过度配置 - 你花钱让 GPU 闲置在 15% 的利用率，只是为了在峰值流量到来时（如果到来）能够应对。这几乎从来都不可行，尤其是在当前 GPU 资源受限的环境下。
• 配置不足 - 一旦流量超过副本能够批处理的上限，你的 p95 就会急剧恶化。LLM 服务的性能退化是非线性的：一个达到并发上限的副本不会“稍微变慢”，而是开始排队，TTFT 可能从 200ms 飙升到 15s。

“直接自动扩缩容就行了”是显而易见的答案，对于无状态 Web 服务来说这基本可行。但 LLM 服务是另一回事，它打破了经典自动扩缩容所依赖的两个假设：

1. CPU 风格的指标会误报负载。 GPU 可能显示 60% 的利用率，而引擎的请求队列已经积压，利用率衡量的是计算强度，而不是压力。基于错误的信号扩缩容部署，意味着系统会对一个并不能描述实际问题的数字做出响应。
2. 冷启动可能需要几分钟。 新副本必须被调度到 GPU 节点上、拉取数十 GB 的权重、加载到显存并预热。这意味着你无法靠扩容来摆脱流量尖峰，因为等到尖峰到来时，扩容已经太晚了。因此，一个好的自动扩缩容器的职责是尽早对先行信号采取行动。

由于这些细微差别以及每位客户的不同需求，我们的平台为你提供了一套推理原生指标目录，并允许你选择部署的扩缩容方式。本文帮助你做出好的选择！

工作原理

每个部署都带有一个自动扩缩容策略：副本数量上下限、一个或多个带目标值的扩缩容指标，以及时间窗口。

控制循环如下：观测指标 → 期望副本数（ceil(N × observed/target)）→ 时间窗口抑制 → 限制在上下限内 → GPU 调度。观测到的负载会反馈回来，循环持续评估，流量分配自动跟随容量变化。

核心循环是比例式的，这意味着如果你将目标设为每个副本 8 个在途请求，而你观测到 16 个，系统就会想要两倍的副本数（假设 2 倍副本数在最小、最大限制范围内）。时间窗口可用于增加去抖动效果，使副本数不会来回振荡：

• scale_up_window：压力必须持续多久才会增加副本。保持较短；错误扩容的代价只是几个副本-分钟，而漏掉扩容的代价是用户侧延迟增加。
• scale_down_window（默认 5m）：在移除副本之前，系统必须保持平静多长时间。保持时间应长于流量的自然波动周期；错误缩容的代价可能是在下一个高峰到来时遭遇冷启动。

这种“积极扩容、耐心缩容”的非对称自动扩缩容窗口权衡非常重要，需要根据您特定流量分布进行直观理解并调整。扩容窗口的错误会带来金钱成本，而缩容窗口的错误则会带来延迟和金钱成本（因为您将不得不立即再次扩容，并在扩容过程中支付冷启动的代价）。

设置它只需一个 PATCH 请求：

    
tg beta endpoints update ""$DEPLOYMENT_ID" \
  --min-replicas 1 --max-replicas 6 \
  --scale-up-window 60s --scale-down-window 300s \
  --scaling-metric ttft --scaling-target 500 --scaling-percentile p95
    

需要记住的几个设置：

• min_replicas == max_replicas：这会导致固定大小的部署，自动扩缩容实际上被关闭。
• 将两者都设置为 min_replicas = max_replicas = 0 → 部署会停止（状态为 STOPPED，计费停止）。这可以用作暂停开发端点的一种方式。
• 设置范围即可开启扩缩容；如果设置了边界但没有设置指标，平台将应用默认值：inflight_requests，目标值为 8。

底层机制：用于自动扩缩容的指标

可用于自动扩缩容的八个指标。选择正确的指标取决于您试图保护部署免受何种问题的影响。

自动扩缩容指标包括并发驱动型（领先指标；安全的默认值）、SLO 驱动型（滞后指标；基于承诺进行扩缩容）、效率驱动型（成本优先）。如果附加多个指标，将使用列表中的第一个。

选择正确指标的三种思路：

1. 并发驱动型（inflight_requests）是安全的默认值。 进行中的请求数是一个领先指标：当需求超过服务能力时，它会在延迟明显下降之前上升。该指标不需要流式传输或选择百分位数，并且直接映射到引擎批量处理请求的方式。该指标的目标值为 8 表示“我希望每个副本处理大约八个并发请求”。对于批处理效果好的短提示聊天工作负载，您可以提高该值；对于预填充耗时较长的编码代理长上下文流量，您可以降低该值。
2. SLO 驱动型指标（ttft、e2e_latency）： 如果您与用户的约定是“首令牌在一秒内”，那么基于 ttft p95 进行扩缩容正是针对这一点。延迟是一个滞后信号，这意味着当 p95 突破设定阈值时，用户已经能够察觉到，因此您通常应将延迟指标与 min_replicas 中诚实的余量配对使用。
3. 另一点需要记住的是，每令牌指标需要流式流量。ttft、decoding_speed 和 throughput_per_replica 仅在流式路径上发出。如果您的客户端不使用流式传输，这些指标就没有数据，您不应基于它们构建自动扩缩容策略。（e2e_latency 是一个例外，因为它对流式和非流式工作负载都会进行测量）。
4. 效率驱动型（gpu_utilization、token_utilization）：最大限度地利用您的硬件。 这些指标以成本为优化目标：保持副本忙碌，仅在集群真正饱和时才增加容量。使用这些指标时，您需要了解“已利用”对您的工作负载真正意味着什么。GPU 可能很忙，但工作负载的延迟状况并不健康，而接近 100% 的利用率目标无法为突发流量留出余量。如果基于利用率进行扩缩容，您应密切关注 p95 的 Grafana 图表。

在选择用于扩缩容的指标时，这是一个值得牢记的表格：

空闲关停与冷启动

不存在自动唤醒的缩容到零。min_replicas: 0 只能与 max_replicas: 0 一起使用，后者是一种显式停止部署的方式。唤醒需要显式操作，向已停止的部署发送请求会返回错误，而不会触发启动。这意味着你应围绕自动停止加显式重启窗口来规划开发与预发布端点。

    
      tg beta endpoints update dep_abc123 --min-replicas 0 --max-replicas 0   # explicit stop
          

使用此自动停止功能时，理解冷启动预算很重要。你可以把冷启动看作由以下阶段组成：GPU 放置 → 权重下载 → 引擎加载 → 预热，部署的事件流会为每个阶段打上时间戳（pod.startup_phase_changed）：

更大的模型可能按比例需要更长的权重下载、引擎加载和预热时间。为更好地了解这些数字，下面给出我们在热集群上 1×H100 副本多次运行得到的结果：

注意这些窗口以分钟计，这意味着只有当使用间隔相对于重启时间足够长，且空闲期后的第一个用户愿意容忍显式启动（或先报错再重试的流程）时，自动停止才划算。这种权衡对开发与预发布端点没问题，但对于任何有 p95 SLO 或无人值守调用方的情况，通常应保持 min_replicas: 1。

边界情况

流量尖峰比冷启动来得更快。实际会发生什么？‍

请求会在现有副本上排队（inflight_requests 和引擎队列深度会增加），延迟会恶化，TTFT 首先上升，随后在新副本启动期间出现错误/超时风险。这意味着如果你的流量能在 90 秒内激增 10 倍，而冷启动需要 4 分钟，那么唯一的防御手段就是 min_replicas 余量或保持富余容量的更高目标策略。这更像是容量形态问题而非调优问题，最好在发布日之前解决。

我的自动扩缩器会与发布冲突吗？

不会。当发布进行中时，平台会固定两个部署的自动扩缩边界；否则发布过程中的副本数会被中途的缩容决策撤销。发布完成或中止后，你配置的边界会自动恢复。

扩缩容如何与流量拆分交互？

之所以能平滑处理，是因为流量拆分权重是按就绪副本计算的（容量 = 权重 × 就绪副本数），自动扩容的部署会按比例吸收更多流量，且无需更改路由。自动扩缩容和路由基于同一套容量视图工作。

为什么我的副本数看起来像锯齿？

这是缩容窗口短于流量自然节律的典型症状。突发流量 + 1 分钟缩容窗口 = 每个低谷缩容、每个高峰冷启动。要解决这个问题，你应该放宽 scale_down_window 直到锯齿变平。这样你可以用少量副本·分钟换取消除反复冷启动。

用不同策略对同一负载进行自动扩缩容

我们在 Qwen3.5-9B 部署上运行了这个实验（每个副本 1×H100，范围 1–3），每轮前重置为恰好 1 个副本，然后同一脚本化负载重放三次：在约 12 到约 48 RPS 之间的正弦波，带有两个 80 rps 的尖峰。这在三种不同的自动扩缩容策略下重复进行：

1. inflight_requests 目标 8
2. ttft p95 目标 300 ms
3. gpu_utilization 目标 75%

上述运行的三点经验：

1. 只有并发信号被触发。在此负载下，客户端 p95 运行在 3–5 秒，明显已饱和，但 ttft 策略从未扩缩容，因为引擎侧的首 token 时间保持较低：引擎的连续批处理将队列压力吸收到总延迟中，而非首 token 延迟。而 gpu_utilization 从未扩缩容，因为短促的突发请求使 GPU 低于其 75% 阈值。两种策略读取的信号在系统饱和时看起来都健康。inflight_requests，即直接的队列压力信号，是唯一看到问题的信号，这就是它成为默认值的原因。
2. 容量确实如承诺般有帮助。在 inflight 策略保持 2 个副本的时段（约第 6–11 分钟），其 p95 在相同负载下明显低于单副本策略，中间面板显示了这一差距。
3. 在选择策略之前，先了解你的副本饱和点。一个副本以 3–5 秒 p95 服务 12–48 rps 而未崩溃，但如果你有 500 ms 的 SLO，这将不可行。

自己试试！

从默认值开始，然后根据证据调整：

1. 设置真实边界（min = 你的基础负载所需，max = 你的预算可承受），并采用默认的 inflight_requests 目标 8。
2. 在指标 API 中观察一周流量：副本数、队列压力、p95。
3. 然后才调整：延迟 SLO → 添加 ttft 策略（如果你使用流式）；成本压力 → 尝试利用率并诚实监控 p95；锯齿 → 放宽缩容窗口。

📚 文档： 专用模型推理 → 自动扩缩容