LLM服务容量规划：批处理与延迟权衡

可视化演示

核心矛盾：吞吐与延迟的拉锯

深夜食堂的店长发现，一锅只炒一份菜虽然快，但燃气大半时间空烧。他尝试把四份订单一起下锅，灶台利用率高了不少，可第一份菜要在锅边等另外三份凑齐。批处理越大，"每锅产出"越高，"第一口菜的等待"也越长。LLM 服务就是这个后厨：每来一个用户请求，就像一张订单，而 batch size 就是这口锅的容量。

把"一锅出多少份菜"翻译成系统指标：吞吐量是每秒完成多少个请求，延迟是一个请求从进入队列到返回结果的时间。两者不是独立的：batch size 变大时，单次推理同时照顾更多请求，但每一轮计算都要照顾到最慢的那份菜，所以平均延迟和尾延迟都会变长。这就是权衡的本质：你想让锅更满，就要接受更长的排队和更长的一轮。

在容量模型里，可以把一次批处理的时间拆成两部分：固定开销 \( t_{\mathrm{fixed}} \) 和随请求数增长的开销 \( r\cdot B \)。于是单个实例的吞吐量就是每锅菜数除以每锅总时间：

通俗说明：每多一锅的固定开销被摊薄，但每多一份请求也会增加总时间，所以吞吐不是无限增长。

批处理机制：从等满锅到流水线

旧后厨的习惯是等灶台上的锅位全部坐满才开火，这叫静态批处理。客流稀的时候，第一张订单要干等到天黑。后来改成"到点就开炒"：设一个最长等待窗口，窗口一到，哪怕只有两份菜也先下锅。再后来升级成流水线厨房：一份菜出锅后，空出的锅位立刻补进新订单，不用等整锅一起收工。

对应到 LLM 推理引擎，动态批处理就是"到点就开炒"，连续批处理相当于"出锅即补位"。动态批处理需要两个参数：目标批大小 \( B \) 和最大等待窗口 \( W \)；连续批处理则让 decode 阶段中已完成序列的槽位即时释放，新请求可以直接加入下一轮迭代。两者都能缓解静态批处理在流量波动时的空等与饥饿。

用排队模型看，一个请求在批处理开始前的等待时间，取决于还要凑多少个请求，以及请求到达速率 \( \lambda \)。如果窗口上限是 \( W_{\max} \)，那么实际等待时间可以写成：

通俗说明：这一批开始前要让客人等多久，取决于"最多等多久"和"客人来得快不快"两者取小。

数学建模：P99约束下的最优批大小

现在后厨立了规矩：99% 的订单必须在 20 分钟内出餐，否则平台要赔钱。店长要反推：锅最多能多大？这不再是感觉问题，而是一个可以写进容量规划书的数学题。

LLM 服务的 P99 延迟可以近似看成两段：排队等待批处理开始的时间（受窗口 \( W \) 限制）和批处理执行时间（固定开销加边际开销）。SLO（服务等级目标）就是产品承诺的 P99 时间上限，比如 \( L_{\mathrm{SLO}}=2.0 \) 秒。一旦有了这个关系式，就能在给定 SLO 的前提下解出最优批大小。

通俗说明：在满足"99% 请求延迟不超时"的前提下，挑最大的批大小，让吞吐尽量高。

动态调参：给厨房装调节阀

顾客流量会波动，店长不能把锅的大小焊死。他给厨房加了一个调节阀：如果出餐时间余量很充足，就试着把锅加大一档；如果快要超时，就立刻减小锅位。这个调节动作不是乱来的，而是根据当前 P99 与 SLO 的差距决定。

生产环境里的动态调参，通常控制三类旋钮：最大批大小 \( B \)、等待窗口 \( W \)、并发上限和限流阈值。它们互相牵制：窗口越长，凑到的批越大，但延迟预算被吃掉；并发越高，GPU 越忙，但排队越严重。因此调参要小步快跑，单次只动一个变量，观察 P99 和吞吐曲线。

一个简单的反馈式调参规则可以写成：

通俗说明：延迟余量充足就加码，贴着目标就稳住，超了就果断减锅。

监控告警：厨房仪表盘

后厨的控制室墙上有一块仪表盘：当前排队单数、灶台饱和度、最近 5 分钟出餐时间分布，以及红色闪烁的 P99 超时告警灯。没有这块表，店长根本不知道什么时候该调锅。

LLM 服务监控的核心指标有：吞吐量（req/s）、P99 延迟、排队请求数、批处理平均饱和度（实际批大小/最大批大小，反映批处理有没有被用满），以及请求成功率。告警规则通常针对 P99 连续 N 个窗口超过阈值，而不是看某个瞬时尖刺。

要理解 P99，不能只看平均延迟，而要看延迟的累积分布函数。P99 的定义是：

通俗说明：把所有请求延迟从小到大排，第 99 百分位那个值就是 P99；它不是平均延迟的 99%。

兼容迁移：换锅不换谱

后厨要开分店，老板发现分店的灶台是另一个品牌：同样一锅能放多少份菜、火力和受热均匀度都不一样。原来在总店的菜谱不能照搬，必须先在分店试菜。

云厂商迁移也一样。即使模型权重相同，不同厂商的推理引擎对最大批大小、动态/连续批处理支持程度、kernel 对 batch 形状的限制、GPU 显存大小都可能不同。直接把原环境的 batch_size 和等待窗口拷过去，轻则性能下降，重则 OOM 或启动失败。

迁移后的实际吞吐可以建模为：有效批大小是新引擎上限与配置的较小值，固定开销和边际开销要重新压测得到：

通俗说明：新锅的锅位上限和每份菜的耗时都要重新测量，迁移后必须重新标定。

工程落地：从压测到成本优化

最后是正式开业前的试菜和算账。店长要预估未来一小时来多少客人，单口锅一小时最多出多少份菜，从而决定开几个灶台、备多少料，以及每份菜的成本。

工程上这叫容量测试和压测：用预估值 \( \lambda \) 作为到达率压测，测出单实例在最优批大小下的吞吐 \( Q(B) \)，再算出需要多少实例。成本上，不能只看 GPU 单价，而要按"每个成功请求的成本"来比较不同批大小配置。

通俗说明：算出要开几个"灶台"，再算每个请求分摊的灶台租金。

AI 应用场景

Python 演示

import random SLO_P99 = 1.8N_REQ = 1000ARRIVE_INTERVAL = 0.05PROCESS_FIXED = 0.4PER_REQ_TIME = 0.02  def simulate(batch_size, seed=42):    random.seed(seed)    arrivals = []    t = 0.0    for _ in range(N_REQ):        t += random.expovariate(1.0 / ARRIVE_INTERVAL)        arrivals.append(t)     process_time = PROCESS_FIXED + batch_size * PER_REQ_TIME    latencies = []    last_finish = 0.0    for start in range(0, N_REQ, batch_size):        stop = min(start + batch_size, N_REQ)        batch_start = arrivals[stop - 1]        finish = batch_start + process_time        last_finish = finish        for i in range(start, stop):            latencies.append(finish - arrivals[i])     latencies.sort()    p99 = latencies[int(len(latencies) * 0.99) - 1]    throughput = N_REQ / last_finish    return throughput, p99  def find_optimal_batch_size():    best = 1    for b in range(1, 33):        throughput, p99 = simulate(b)        if p99 <= SLO_P99:            best = b        else:            break    return best  def main():    print("batch_size throughput p99")    for b in range(1, 13):        t, p = simulate(b)        print("%d %.2f %.3f" % (b, t, p))    opt = find_optimal_batch_size()    print("optimal batch size:", opt)    t, p = simulate(opt)    print("optimal throughput: %.2f req/s" % t)    print("optimal p99: %.3f s" % p)  if name == "main":    main()

常见误区

面试题