推理：容量规划与推理优化

推理系统上线后，团队很快会遇到两个问题：现在还能撑多久，下一步该先优化哪里。这两个问题表面像“算资源”，本质是在做系统建模。大模型推理容量不是固定常数，而是请求分布、输入输出长度、模型结构、batch 策略、缓存命中、工具调用和 SLO 共同作用的结果。

这页把推理优化从零散技巧整理成容量规划和瓶颈归因框架。

初学者先抓住

容量规划先看请求画像，再看资源。平均输入长度、平均 QPS 都不够用；少量超长文档、长输出、工具 agent 或多模态请求，可能吃掉大部分 GPU 时间和 KV 显存。

难点解释：为什么优化要按请求桶做

短聊天的瓶颈可能是 queue 和 launch 开销，长文档的瓶颈可能是 prefill 和 KV，长输出的瓶颈可能是 decode，agent 的瓶颈可能在工具。把它们混成一个平均数，会让团队选择错误优化动作。

有趣例子：电梯容量规划

办公楼不能只按“平均每人坐 5 层”设计电梯。早高峰、搬家大件、会议散场和普通上下楼的负载完全不同。推理容量也一样，要按请求桶看，而不是按平均 token 看。

请求画像先于资源估算

设请求到达率为 $\lambda$，平均服务时间为 $S$，负载强度可粗略写成：

$\rho=\lambda S$

当 $\rho$ 接近系统有效处理能力时，排队时间和尾延迟会快速恶化。LLM/VLM 系统中 $S$ 不是常数，通常更接近：

$S\approx T_{\text{prefill}}(L_{\text{in}}) +T_{\text{decode}}(L_{\text{out}}) +T_{\text{tool}} +T_{\text{network}}$

因此容量规划必须先统计真实请求画像，包括输入长度和输出长度分布、长上下文和多模态占比、工具调用轮次和外部依赖耗时、模型路由分布、prefix / KV cache 命中率，以及峰值流量和多租户叠加。

不要只看平均 token。少量超长 PDF、代码仓库或多图请求，可能占掉大部分算力和显存。

Prefill、Decode 与 Queue

推理总延迟至少应拆成：

$T_{\text{total}} = T_{\text{queue}} +T_{\text{prefill}} +T_{\text{decode}} +T_{\text{overhead}}$

Prefill 一次性处理全部输入 token，长上下文时成本高；decode 每次只生成少量 token，但要重复很多轮，并持续访问 KV cache。Queue 则反映容量、调度和优先级是否健康。

很多“延迟高”不能笼统归因于模型太大，而要问它究竟来自 queue、prefill、decode、KV cache、工具/网络，还是调度和 batching 没组织好。不同瓶颈对应完全不同的优化动作。

分层优化清单

层级	关注点	常见动作
请求层	输入/输出长度、RAG 拼接、多模态大小	prompt 收缩、检索裁剪、输出限长、任务分流
调度层	queue、continuous batching、priority、routing	动态 batching、优先级、SLA 隔离、路由
模型层	参数量、量化、draft、early exit	量化、蒸馏、speculative、模型分层
缓存层	prefix、KV、工具结果	prefix cache、KV paging、eviction、结果缓存
Kernel 层	GEMM、attention、norm、decode kernel	FlashAttention、paged attention、fused kernels
系统层	多实例、网络、存储、外部工具	横向扩容、隔离、降级、异步化

优化顺序应由瓶颈决定，而不是由技术新不新决定。很多团队一上来做 speculative 或手写 kernel，但真正瓶颈可能只是 prompt 太长、RAG 拼接过量、路由不合理或 cache 命中低。

容量模型

容量规划至少要估计三类资源：计算容量看 prefill FLOPs、decode step 和 Tensor Core 利用率；显存容量看权重、KV cache、batch 中间状态和碎片；服务容量看 queue、batching、工具、网络和实例副本。

一个实用方法是按请求桶建模，而不是建一个全局平均模型：

请求桶	主要成本	典型优化
短问答	queue 和 launch 开销	batching、轻量模型、prefix cache
长文档	prefill 和 KV	检索裁剪、上下文压缩、prefill 分离
长输出	decode	speculative、draft model、输出策略
工具 agent	外部调用和多轮	工具缓存、状态压缩、异步执行
多模态	编码器和跨模态 token	图像裁剪、视觉缓存、模型路由

如果 10% 的长请求占据 60% 的 GPU 时间，优化策略就不能平均铺开。

SLO 驱动优化

容量规划必须和 SLO 绑定。常见指标包括 TTFT、TPOT、p50/p95/p99 请求延迟、tokens/s、requests/s、错误率、超时率、降级率、单请求成本、单 token 成本，以及任务成功率和质量指标。

不同业务的 SLO 不同。企业问答可以接受更高延迟但要求证据可靠；屏幕 agent 更看重每步交互延迟；批处理文档分析更看重吞吐和成本。没有 SLO，优化会变成无限追求更快，却不清楚哪些改动值得做。

降级与扩容策略

当资源紧张时，系统不应只有“一起变慢”。应提前设计降级：低优先级请求切到小模型，长上下文请求限制最大输入，关闭多样本采样、二次重排或高成本工具，批处理任务延后执行，高风险任务保留强模型和人工审核，p99 恶化时关闭 speculative 或降低 batch。

扩容也要按瓶颈扩。若瓶颈是 KV 显存，单纯增加计算实例未必有效；若瓶颈是外部工具，增加 GPU 也不会改善端到端延迟。

验收清单

做推理优化前后，至少回答这些问题：瓶颈属于 queue、prefill、decode、KV、tool、network 还是 kernel；优化收益在哪些请求桶成立；p95/p99 是否改善，是否牺牲 TTFT；质量、错误率和降级率是否变化；cache 命中、KV 占用和 batch 形态是否改变；峰值流量下收益是否还成立；回退路径是否稳定；单请求成本是否真的下降。

推理优化的核心不是收集技巧，而是建立请求画像、瓶颈分解、容量模型和 SLO 之间的闭环。

真实排查案例：扩 GPU 没救 P99

输入症状：峰值时段 P99 超时，团队先把 GPU 实例翻倍，但 P99 只从 13s 降到 11s，成本几乎翻倍。

关键指标：GPU util 不高但 queue time 高；外部检索和工具调用 P95 接近 4s；长上下文请求触发更多 prefill；失败重试率在高峰时上升，进一步放大流量。

Nsight / trace 观察：GPU trace 没有长时间饱和，反而存在空洞；系统 trace 显示请求大部分时间卡在检索、重排、工具 I/O 和重试队列，进入 GPU 时已经接近超时预算。

判断：容量瓶颈不在 GPU compute，而在请求链路和重试放大。单纯扩 GPU 只能改善局部阶段，无法缩短端到端关键路径。

修复：按阶段拆 SLO：检索、重排、prefill、decode、工具、后处理分别限时；高峰关闭二次重排和低价值工具；对超时请求禁止盲目重试，改为降级模型或返回部分结果；成本账改成“每成功任务成本”。

反例：如果 trace 显示 GPU queue 和 prefill/decode 阶段长期饱和，且外部工具时间很小，扩 GPU 或分池才是正确方向。容量规划必须先定位瓶颈层。