GPU 调度是一个排队问题，而不是资源配置问题

连续批处理 (Continuous batching)。LLM 服务的原罪是静态批处理：收集 N 个请求，一起运行，并等待最慢的一个完成后再开始下一个批次。由于输出长度差异巨大，批次以最长成员的速度运行，而完成的槽位则处于闲置状态。连续批处理通过以单个解码步骤为粒度运行来解决这个问题：一旦任何序列完成，等待中的请求就会立即注入到释放出的槽位中。据报道，仅凭这一调度改变，吞吐量就比幼稚的批处理提高了约 8 倍，在配合内存优化后，提高幅度更超过 20 倍。关键在于，这在提高吞吐量的同时也 改善 了中值延迟，因为新请求不再需要等待整个批次排空。这是在高负载下罕见的、没有权衡的优化。

作为绑定约束的 KV 缓存内存。只有当你能容纳足够的并发序列来保持槽位填满时，连续批处理才有效，而限制并发的不是 FLOPS，而是 KV 缓存内存。一个 13B 模型每个 token 消耗近 1MB 的缓存状态。在 40GB 的 A100 上，这大约是 28 个并发序列（每个 512 token），但在 2048 token 时仅为 7 个。你的有效批次大小，以及随之而来的吞吐量，是上下文长度的函数，而不是显卡数量的函数。PagedAttention 通过按需分配非连续块的缓存（而非预先预留每个请求的最坏情况上下文）来解决这个问题，这让更多的序列得以共存。当内存池填满时，调度器必须进行 抢占 (preempt)——通过在重新准入时重新计算预填充（在 PCIe 上成本低，在计算上成本高）或将其块交换到主机内存（在计算上成本低，但长上下文在 PCIe 上需要数百毫秒）来驱逐运行中的序列。这两者都是排队决策。购买更多显卡无法解决这些问题；它们需要通过管理现有内存来解决。

预填充/解码分离与分块。由于预填充和解码具有相反的资源特性，且在同处运行时会互相干扰，一个强力手段是停止在同一块 GPU 上运行它们。分离（Disaggregation）将集群分为预填充集群和解码集群，在它们之间传递 KV 缓存，并让每个集群根据自己的瓶颈进行扩展。已发布的基准测试显示，在同等硬件条件下，分离对（disaggregated pair）能提供约 2100 token/秒，而同处运行的显卡约为 1200 token/秒，且首字延迟（TTFT）从约 800 毫秒下降到约 350 毫秒。成本更低的单节点方案是分块预填充（chunked prefill）：将长提示词切成固定大小的块，并将其与正在进行的解码步骤交织进行，这样“巨鲸”请求就不会独占 GPU。同样的硬件，显著改善的尾部延迟，仅仅是因为排队规则改变了。

你无法调度无法预测的任务​

以下是让 LLM 调度变得真正困难的特性，这一点值得深思，因为它是大多数自研方案悄然失败的原因。经典的调度理论对于最小化平均等待时间有一个清晰的答案：短作业优先 (Shortest-Job-First, SJF)。先运行小请求再运行大请求，队头阻塞 (Head-of-line blocking) 现象就会在很大程度上消失。问题在于，在 LLM 推理服务中，你在任务完成之前无法知道任务的大小。 输出长度 —— 以及随之而来的执行时间和内存占用 —— 在生成结束之前都是未知的。精确的 SJF 不仅仅是难以实现；在请求进入系统的那一刻，它在信息论层面就是不可知的。

这就是为什么最近的一波推理服务研究实际上是在讨论如何通过足够准确地 预测 任务大小来近似实现 SJF。一些系统学习使用轻量级模型根据可能的输出长度对请求进行排序，然后按预测顺序进行调度；据报告，这在聊天机器人服务中实现了数倍的延迟降低，并在批量生成工作负载中获得了巨大的吞吐量提升。另一些系统则采用提示词感知 (Prompt-aware) 的方式，在生成第一个 token 之前就从输入中估算成本。诚实的说法是，这些都是赌注：你正在为你尚未运行的请求的持续时间下注，而一个错误的赌注意味着一个短请求会被困在一个被误分类的“巨型请求”之后。

而且，即使预测准确，纯粹的 SJF 也有其自身的失效模式。如果你总是偏向最短的任务，稳定的短请求流可能会让大任务无限期地处于饥饿状态；更糟糕的是，风险较低的短请求可能会抢占一个离错过截止日期仅剩几秒钟的请求。优化平均延迟可能会破坏有效吞吐量 (Goodput) —— 即真正满足 SLO 的请求比例 —— 因为平均值虽然提高了，但仍有相当一部分用户没能达到目标。真正的目标不是“最小化平均延迟”，而是“最大化在 SLO 内完成的请求数”，这迫使调度器必须权衡截止日期的紧迫性和剩余成本，而不仅仅是预测的大小。这是一个针对每个请求做出的排队策略决策，是任何硬件都无法直接体现的。

这对你的容量规划意味着什么​

务实的做法是停止询问“我需要多少个 GPU？”，转而开始询问“我的排队规则是什么，它在我的实际请求长度分布下表现如何？”这是两个完全不同的问题，由不同的负责人负责。第一个是采购清单项。第二个是工程设计，它决定了采购是物有所值还是在挥霍资金。

由此可以直接得出几点结论。衡量你工作负载的输入和输出长度的 分布，而不仅仅是平均值 —— 方差才是产生队头阻塞的原因，长尾分布会惩罚任何幼稚的调度器，无论你投入多少算力。在批准集群扩张之前，请确认你已经开启了连续批处理 (Continuous Batching)，根据 KV 缓存内存而非 FLOPS 来确定批处理大小，并决定了预填充 (Prefill) 和解码 (Decode) 如何共享（或不共享）显卡。将 SLO 达成率而非原始吞吐量或利用率作为触发扩容的指标 —— 一个有效吞吐量为 95% 但利用率为 50% 的集群不需要更多硬件，它需要的是调查。当你确实需要增加容量时，请非对称地增加，以匹配你分布中真正匮乏的阶段。

这并不意味着硬件永远不重要。在真正的饱和状态下，当队列已满且所有调度技巧都已部署时，增加显卡是唯一正确的答案。但那个时刻到来的时间远比大多数团队想象的要晚，而且在队列管理好之前，你甚至无法识别出那个时刻。配置扩容应该是最后一个拨动的杠杆，而不是第一个。优化延迟的捷径几乎总是通过调度器实现的，因为尾部延迟从来不在于你拥有多少算力，而在于你允许任务进门的顺序。