LLM服务容量规划：QPS预测与弹性扩容

可视化演示

展示工作日QPS日周期预测曲线、水平与垂直弹性扩容对比，以及弹性伸缩将GPU利用率从30-40%提升到60%+。

QPS核心概念

老王面馆的第一次变革，是在门口挂了一个计数器。每位顾客进门他按一下，每小时清点一次，于是“晚 7 点来 300 人、下午 3 点来 20 人”这样的规律浮现出来。这个“每小时顾客数”，对应到 LLM 服务里就是 QPS——每秒有多少个请求打到你的模型上。它是容量规划最基本的一把尺子。

光看一个总数不够。老王很快发现客流有脾气：工作日晚上是高峰，周末下午也旺，下雨天没人来，商场搞活动时人潮翻倍。LLM 服务的流量同样如此——上班族白天调 AI 助手、深夜跑批任务、大促时客服机器人被挤爆。这种周期性加突发性的特征，决定了你不能按平均值备资源，必须按“波动曲线”来规划。

数据从哪来？靠采集。网关访问日志、负载均衡指标、业务埋点，把每分钟的请求数、来源、成功失败结果全部记下来。采集粒度决定了预测精度——只记“每天总客流”的老王，永远发现不了“晚 7 点高峰”这个规律；同样，只统计小时级 QPS 的团队，也扛不住分钟级的流量陡增。

$$\displaystyle QPS = \frac{N_{requests}}{T_{seconds}}$$

1. N_requests（分子）：统计窗口内进入系统的总请求数量。想象老王的计数器上，晚高峰两小时累计跳了 18000 次。

$$N_{requests} = 18000$$

2. T_seconds（分母）：统计窗口的时长，单位必须换算成秒。两小时就是 7200 秒。

$$T_{seconds} = 7200$$

3. 比值含义：总请求数除以总秒数，得到平均每秒查询数：18000 ÷ 7200 = 2.5 QPS。

$$\frac{18000}{7200} = 2.5$$

数清人头只是第一步。老王把计数器换成了带时间轴的电子本子，按分钟记录，这才看清了高峰的形状。对应到工程上，就是搭建请求级的埋点与日志链路。有了准确的历史流量，下一节才能谈“预测”。

流量预测算法

老王不再满足于“昨天来了多少人”，他想知道明天会来多少。最初的直觉是“上周三和这周三应该差不多”，后来他发现最近三天的客流比上周同一天更有参考价值——邻居新开的烧烤摊、天气变化、食客口碑都在缓慢改变生意。这种“更相信近期数据”的思路，就是指数平滑法的雏形。

指数平滑（EWMA）的数学表达极其简洁：新预测值 = 平滑系数 × 最新实测值 +（1 − 平滑系数）× 上一个预测值。它不需要保留全部历史数据，只要记住上一个预测值就能持续滚动更新，特别适合在线服务实时算流量。相比之下，移动平均法取最近 N 个点的算术平均，实现简单但反应迟钝；更精细的周期趋势分解则把时间序列拆成长期趋势、周期性分量和随机噪声三部分，先分别建模再叠加，能捕捉“每天晚 7 点必涨”这类周期规律，但计算复杂度也更高。

预测准不准，要用误差说话。常见指标有 MAPE（平均绝对百分比误差）和 RMSE（均方根误差），误差越小，后续扩容计划就越有底气。

$$\displaystyle S_{t} = \alpha \times X_{t} + (1-\alpha) \times S_{t-1}$$

1. X_t（当前实测值）：本时刻观察到的真实 QPS。好比老王今晚 7 点实到 100 位顾客。

$$X_{t} = 100$$

2. S_{t-1}（上轮预测值）：此前时刻预测出的值，比如昨天估计今天 7 点会来 80 位。

$$S_{t-1} = 80$$

3. α（平滑系数）：取值在 0 到 1 之间，决定新数据占多大权重。α = 0.3 表示 30% 相信实测、70% 沿用旧预测。

$$\alpha = 0.3$$

4. S_t（新预测值）：0.3 × 100 + 0.7 × 80 = 86，预测值向实测靠拢，既追变化又防抖动。

$$S_{t} = 0.3 \times 100 + 0.7 \times 80 = 86$$

老王后来发现，完全照搬上周客流（简单平均）往往被突发天气坑惨，而“七分老经验、三分新观察”的指数平滑反而稳。预测出明天的高峰人数后，下一个问题自然浮现：到底需要几个厨师、几口灶？

容量评估体系

知道明天高峰会来多少人，老王开始盘算：一个厨师一小时能出多少碗面？他做过实验——让一位师傅不停歇地煮面，记下极限是 40 碗/小时。对应到 LLM 服务，这就是“单实例 QPS 上限”：给一台 GPU 实例持续加压，直到它扛不住，记下它的吞吐天花板。这必须实测，不能拍脑袋，因为模型大小、显存带宽、输入输出长度都会显著影响这个数字。

光看吞吐还不够，还要看“顾客最长等多久”。面馆里最惨的那位顾客等了多少分钟，比平均等餐时间更能说明问题——这个“最惨顾客”的等待时间，对应 P99 延迟：99% 的请求延迟都小于该值，只有 1% 的请求比它更慢。平均延迟 200ms 的服务，P99 可能已经飙到 2 秒，体验天差地别。

还有一个反直觉的点：不能把灶烧到 100% 满负荷。万一来了个突发大单，炉子全忙，新客就只能干等。所以要设安全水位，比如只用单实例上限的 70%～80%，留出的余量用来吸收流量尖峰和故障转移。

$$\displaystyle N = \left\lceil \frac{QPS_{peak}}{QPS_{single} \times U_{safe}} \right\rceil$$

1. QPS_peak（峰值流量）：预测算法给出的未来高峰 QPS。老王预估明天晚高峰 600 位顾客。

$$QPS_{peak} = 600$$

2. QPS_single（单实例上限）：压测得到的单机吞吐上限，相当于一位厨师一小时最多 100 碗面。

$$QPS_{single} = 100$$

3. U_safe（安全水位）：允许使用的比例，0.8 表示只用到上限的八成，留两成余量。

$$U_{safe} = 0.8$$

4. 向上取整：600 ÷ (100 × 0.8) = 7.5，但灶不能开半口，所以备 8 个实例。

$$\left\lceil 7.5 \right\rceil = 8$$

老王算出来高峰需要 8 口灶，但他只常驻 5 口，剩下 3 口等高峰前再架上——机器和人一样，不用全天满编，关键是“该在的时候在”。这就引出了弹性扩缩容。

弹性扩缩容

弹性扩容的精髓，老王总结成一句话：“提前一小时叫人，而不是队伍排到 20 米才喊。” 他会在高峰前给帮厨打电话，让他们提前到店系上围裙；等客流回落，再让帮厨回家休息。对应到 Kubernetes，HPA（Horizontal Pod Autoscaler）就是这位调度员。

HPA 的工作方式是周期性采样：观察当前副本数下的指标平均值（可以是 CPU、QPS 或自定义业务指标），与目标阈值比较，按比例调整副本数。它的触发机制是“偏差比例”而非简单的开关——当前 QPS 超出目标越多，扩容的步子就越大。扩容不是瞬间完成的：新 Pod 要经历调度、拉镜像、加载模型权重、预热推理缓存（冷启动），动辄几分钟。所以老练的团队会做“预扩容”：预测模型说半小时后要涨，现在就先把实例加上去。线上还要配限流保护，像面馆满座时发号排队，先让请求在队列里等一下，也好过把系统冲垮。缩容则要格外谨慎：高峰一过立刻砍实例，流量稍微反弹就会再次扩容，一来一回“震荡”反而更费钱，所以要设冷却期和最小副本数。

$$\displaystyle R_{desired} = \left\lceil R_{current} \times \frac{M_{current}}{M_{target}} \right\rceil$$

1. R_current（当前副本数）：此刻集群里运行的 Pod 数量。面馆现在有 4 位厨师在岗。

$$R_{current} = 4$$

2. M_current（当前观测指标）：最近采样窗口内指标的平均值，比如平均 QPS 已经到 80。

$$M_{current} = 80$$

3. M_target（目标阈值）：希望指标维持的水平，比如目标就是 60 QPS，维持体验不排队。

$$M_{target} = 60$$

4. 取整与决策：4 × 80 ÷ 60 = 5.33，向上取整为 6，即需要新增 2 个实例。

$$\left\lceil 4 \times \frac{80}{60} \right\rceil = 6$$

老王的经验“提前叫人来、高峰后让人歇一会儿再走”，对应到系统里就是预扩容、冷却期和最小副本数。但扩容方案对不对，不能靠猜，得先做一场模拟考试——负载测试。

负载测试验证

老王不会等到中秋当晚才发现灶不够用。他会在节前请一群朋友来“试吃”，模拟高峰场景：同时进店、点单、催菜，看 8 口灶同时开火会不会排长队、出餐时间会不会爆表。这就是负载测试——用模拟流量检验系统的真实容量。

压测工具（k6、wrk、Locust 等）负责“造人”，但要造得逼真：请求频率、并发数、请求体大小、思考间隔都要贴近线上真实比例，这就是流量模型构造。压测中要盯住两个关键曲线：随着并发上升，QPS 先是稳步上升，到某个点后增速放缓甚至掉头向下，同时延迟开始急剧飙升——这个拐点就是系统真实容量。背后的理论支撑是 Little's Law：系统内平均并发请求数 L = 到达率 λ × 平均响应时间 W。测出平均响应时间 W 后，就能反推：想压到目标 QPS，需要模拟多少并发。压测还要固化为回归测试，每次模型版本升级或推理配置变更后重跑一遍，防止性能悄悄回退。

$$\displaystyle L = \lambda \times W$$

1. λ（到达率）：每秒进入系统的新请求数，也就是压测要模拟的目标 QPS，比如 200。

$$\lambda = 200$$

2. W（平均响应时间）：每个请求从进入系统到处理完成的平均耗时，比如 0.5 秒。

$$W = 0.5$$

3. L（系统内请求数）：任意时刻同时待在系统里（排队或处理中）的请求数：200 × 0.5 = 100 个并发。

$$L = 200 \times 0.5 = 100$$

老王请朋友试吃后才知道“8 口灶、每碗 3 分钟”的真实极限，从此备料、排班心里有底。压测拿到了真实容量，最后一步是把这套打法变成日常运营制度。

工程落地实践

老王把经验沉淀成一套“面馆运营系统”：门口装客流摄像头记录每一分钟进店人数；队尾超过 10 人自动给老板手机发提醒；墙上挂大屏实时显示客流曲线和出餐水位；月底对着账单复盘哪几天帮厨请多了、哪几天备料备少了。这套系统对应到 LLM 服务，就是监控、告警、看板和成本核算。

落地的起点是监控体系建设：埋点采集 QPS、P99 延迟、GPU 利用率、排队长度等核心指标，写入时序数据库统一存储。告警规则要分级别：水位超过 70% 提示观察、85% 触发预警、95% 拉响告急，并用预测值联动——预测明天 10 点有洪峰，今晚就自动提醒值班同学确认扩容计划。容量看板把“预测曲线、实际曲线、当前副本数”叠加在同一张图上，团队一眼就能看出预测准不准、扩容跟没跟得上。最后是成本优化：弹性缩容省下的 GPU 小时数乘以单价，就是容量规划最直观的功劳。用预测驱动预算制定，远比月底对着超额账单追认要优雅。

$$\displaystyle Cost = N \times T_{hours} \times P_{hour}$$

1. N（平均实例数）：统计周期内实际运行的实例数量均值。弹性做得好，N 就贴着需求走。

$$N = 12$$

2. T_hours（时长）：累计运行的小时数。一个月按 30 天算就是 720 小时。

$$T_{hours} = 720$$

3. P_hour（单价）：单台 GPU 实例每小时的价格，比如 30 元。

$$P_{hour} = 30$$

4. 成本合计：12 × 720 × 30 = 259,200 元。预测越准、水位越合理，N 就越接近真实需求，账就越省。

$$Cost = 12 \times 720 \times 30 = 259200$$

老王的面馆从此“看屏下菜”：客人多了自动加灶，客人少了关灶省气。LLM 服务团队也一样——QPS 预测是眼睛，弹性扩容是手脚，监控看板是神经，成本账本是成绩单。四者闭环，容量规划才算真正落地。

AI 应用场景

Python 演示

"""QPS预测与弹性扩容演示：指数平滑预测流量并计算所需实例数。"""import mathimport random  def exp_smooth(history, alpha=0.3):    """用指数平滑法预测下一个时刻的 QPS。"""    s = history[0]    for x in history:        s = alpha * x + (1 - alpha) * s    return s  def calc_replicas(qps_peak, qps_single, safe_ratio=0.7):    """根据峰值 QPS、单实例上限和安全水位计算所需实例数。"""    return math.ceil(qps_peak / (qps_single * safe_ratio))  def simulate(series, qps_single, safe_ratio):    """逐分钟滚动预测并生成扩容计划。"""    plan = []    for i in range(len(series)):        hist = series[:i + 1]        pred = exp_smooth(hist)        need = calc_replicas(max(pred, series[i]), qps_single, safe_ratio)        plan.append(need)    return plan  def main():    random.seed(42)    # 模拟 60 分钟流量：周期性高峰叠加随机抖动    series = []    for i in range(60):        wave = 40 + 30 * math.sin(i / 8.0)        noise = random.uniform(-5, 5)        series.append(max(1, wave + noise))    plan = simulate(series, qps_single=40, safe_ratio=0.7)    for i in (10, 20, 30, 40, 50):        pred = exp_smooth(series[:i + 1])        print("t=%2dmin 实测=%5.1f 预测=%5.1f 实例=%d"              % (i, series[i], pred, plan[i]))  if __name__ == "__main__":    main()

1. s = alpha * x + (1 - alpha) * s指数平滑的核心递推：每个新观测值都按 α 比例修正旧预测，相当于老王“七分经验、三分新观察”。
2. return math.ceil(qps_peak / (qps_single * safe_ratio))实例数计算公式：峰值除以“单机上限 × 安全水位”后向上取整，保证容量有余量。
3. max(pred, series[i])取预测值和当前实测值的较大者，宁可按眼前真实流量备资源，也不盲目乐观。
4. random.seed(42)固定随机种子，保证每次运行生成的流量数据一致，演示结果可复现。
5. wave = 40 + 30 * math.sin(i / 8.0)用正弦波模拟“晚高峰”的周期性规律，正如真实业务流量存在昼夜节律。

常见误区

面试题