AI推理服务如何做容量规划：从峰值请求到有效吞吐的测算方法

AI推理服务的容量规划，不应从芯片标称算力或一次压测的最高吞吐开始，而应从业务服务等级目标（SLO）倒推：在怎样的请求峰值、输入输出长度和并发形态下，系统仍能满足首字延迟、生成速度与可用性要求。只有把这些条件放进同一套测算和压测口径，得到的吞吐量才有采购和部署价值。

先把服务目标说清楚

容量不是一个孤立的“每秒处理多少请求”，而是系统在约定负载下能否持续满足体验和可用性要求。规划前，至少要明确：

• 负载范围：日常流量、业务峰值、突发流量分别有多大；峰值持续多久，是否存在集中到达。
• 请求特征：输入提示词与输出内容的长度分布，是否包含长文档、代码、工具调用或多轮上下文。
• 体验目标：首字延迟（TTFT）、生成过程中相邻令牌的间隔、完整请求耗时分别要求达到什么水平；关注平均值还是 p95、p99 等分位数。
• 可用性目标：能否接受排队、限流、降级或拒绝请求；单实例、单机或单个故障域不可用时，服务要保留多少能力。

这些目标需要落实到具体的请求类型和统计口径。比如，长输入、长输出的请求可能明显增加计算和显存压力，不能只用一个平均长度掩盖差异。

拆解容量测算变量

并发与请求速率不是一回事

并发描述某一时刻有多少请求正在处理；请求速率描述单位时间内有多少请求到达。二者会通过处理时间相互影响。稳定状态下，可用下式作初步估算：

平均在途请求数 ≈ 平均请求到达速率 × 平均请求处理时间

这是用于理解负载关系的近似，不代表系统一定能在该并发下满足延迟目标。若请求处理时间变长，即使到达速率不变，在途请求也会增加，排队和延迟可能随之上升。对突发业务，还要单独观察短时间窗口内的到达峰值，而不是只看整小时或全天平均值。

输入长度和输出长度决定不同压力

输入令牌主要影响提示词处理阶段，输出令牌则影响生成阶段。两者不能简单合并成一个“平均令牌数”：输入很长的请求可能拉高首字延迟，输出很长的请求会长时间占用生成资源，并增加 KV cache 等运行时内存需求。

容量测算应分别统计输入与输出长度的分布，至少识别常见请求、较长请求和极端长请求。对于多轮对话，还需计算上下文累积后的实际输入长度，而不能只按单轮新增内容估算。

首字延迟与生成速度要分开看

首字延迟（TTFT）通常包含请求排队、调度、输入处理和开始生成等环节。生成阶段则应观察令牌间延迟或每秒生成令牌数。首字很快不等于后续生成足够快；整体令牌吞吐高，也不等于每个用户都能及时拿到首个响应。

压测时应同时记录首字延迟、生成阶段速度、完整请求耗时和队列等待时间，并按请求类型与延迟分位数分析。这样才能判断瓶颈出现在排队、输入处理、生成还是服务链路的其他环节。

有效吞吐要带着服务等级一起定义

有效吞吐不是压测工具显示的最高数字，而是在指定请求分布、并发形态和服务等级目标下，系统能够稳定完成的工作量。对生成服务，可先用下式估算输出侧的基础需求：

输出令牌需求（令牌/秒）≈ 请求到达速率（请求/秒）× 平均输出长度（令牌/请求）

例如，若业务假设为每秒 10 个请求、平均每个请求生成 300 个令牌，则输出侧的基础需求约为每秒 3000 个令牌。这个结果只是需求估算，不是设备能力结论：输入处理、请求长度差异、批处理效率、延迟目标、显存限制和故障冗余都会影响实际可承载量。

采购或扩容时，应把“令牌/秒”与对应的并发、输入输出长度分布和延迟分位数一起记录。脱离这些条件比较不同配置的吞吐数字，容易得出错误结论。

批处理带来吞吐，也会影响延迟

批处理将多个请求组合起来执行，通常有助于提高硬件利用率，但批次等待和请求混合会改变延迟表现。请求到达稀疏时，为了凑批而等待可能拉长首字延迟；长短请求混在一起时，批次处理时间也可能受到较长请求影响。

评估批处理时，重点检查：

• 最大批次大小与等待策略如何设置，是否符合首字延迟目标。
• 高并发和低并发下的吞吐、首字延迟与生成速度是否都可接受。
• 长短请求混合时，短请求是否受到明显拖累。
• 请求调度是否支持按长度或优先级处理；采用此类策略后，是否改变不同用户间的公平性。
• 压测流量是否模拟真实到达过程，而不是只用固定并发持续灌入。

批次参数不是越大越好。容量规划应以目标负载下的服务表现为准，而不是只看最大批次时的峰值数字。

显存与故障冗余不能留到最后

模型权重只是显存占用的一部分。实际运行还需要为 KV cache、批次中的请求、运行时工作区和服务进程留出空间。上下文长度、并发请求数和输出长度都会影响运行时占用，因此仅按模型文件大小判断能否部署并不充分。

规划显存时，应在目标模型、精度或量化方式、推理引擎和实际请求分布下进行验证，并记录高水位占用。若长上下文或并发增长会压缩 KV cache 可用空间，系统可能需要限制上下文、减少并发、拆分实例或增加资源。所有调整都应重新压测，确认没有把显存问题转化为排队或延迟问题。

冗余也应纳入容量口径。若服务要求单台设备或单个故障域失效后仍满足业务目标，就不能把全部设备都按正常运行时的可用容量计算。应明确故障场景下哪些实例会退出、流量如何转移，以及剩余资源能否继续达到目标；否则，所谓“预留冗余”可能只是账面上的设备数量。

从需求到配置：一套可执行的估算流程

1. 建立业务负载模型

按业务类型整理峰值请求速率、突发持续时间、并发、输入长度、输出长度和请求优先级。不要只保留一个总平均数，至少划分主要请求类别，并说明各类别的占比与边界条件。

2. 定义验收用的服务目标

明确首字延迟、生成阶段速度、完整请求耗时及可用性要求，并指定统计周期和分位数。还要约定哪些情况属于排队、限流、超时或降级，避免压测完成后才发现双方使用了不同口径。

3. 用目标环境进行基准压测

使用拟上线的模型版本、推理框架、硬件配置、并行方式和服务参数。压测数据应包含与业务相近的输入输出长度、请求到达方式和并发变化。只测合成短提示词，或只测单一并发点，不能代表真实服务能力。

4. 找到满足目标的工作区间

逐步提高负载，观察有效吞吐、首字延迟、生成速度、队列长度、错误率、显存和设备利用情况。容量上限应取“仍满足服务目标”的负载点，而不是系统彻底过载前的最高点。随后用不同长度组合和突发流量复测，确认结果具有稳定性。

5. 加入冗余与增长假设

把故障切换、维护窗口和业务增长纳入配置方案。分别计算正常状态与约定故障状态下的可用能力，并明确哪些资源用于承载业务、哪些用于冗余或峰值缓冲。增长假设应写清楚依据和时间范围，避免把不确定的未来需求直接变成长期闲置采购。

6. 按有效能力核算成本

将硬件、托管或云资源、存储与网络、推理软件、监控运维等成本，与满足目标后的有效吞吐对应起来。可比较不同配置在同一负载和 SLO 下的单位有效吞吐成本，而不是简单比较单卡价格或理论算力。若不同方案的延迟、冗余或服务范围不一致，应先统一口径再比较。

压测与采购验收清单

• [ ] 模型、版本、精度或量化方式、推理引擎和硬件配置已记录。
• [ ] 输入与输出长度分布、并发和请求到达模式接近目标业务。
• [ ] 首字延迟、生成阶段速度、完整请求耗时和错误率均有明确统计口径。
• [ ] 结果包含 p95、p99 等关键分位数，而不只报告平均值和最高吞吐。
• [ ] 高并发、突发流量、长输入、长输出及长短请求混合场景均已测试。
• [ ] 批处理策略、队列行为、限流和超时处理已验证。
• [ ] 显存高水位、KV cache 相关压力和设备利用情况已记录。
• [ ] 故障或维护场景下的流量转移与剩余容量已验证。
• [ ] 验收结论明确给出满足目标的有效吞吐及其适用负载条件。
• [ ] 成本比较采用相同服务目标，并说明冗余与资源预留的计入方式。

【软盟资讯观察】

容量规划的关键价值，不是把设备压到更高利用率，而是把业务体验、资源消耗和故障承受能力放在同一张账上。对企业而言，机会在于通过请求分层、批处理和调度策略，提高既有资源的有效利用；风险则在于用单次峰值、单一请求样本或厂商标称数据替代真实负载验证。冷静看，模型、软件栈和业务请求都会变化，容量结论因此不是一次性的采购数字，而应成为持续监控、定期复测和按需调整的运行基线。尤其在预算决策中，需区分“可部署”“可压测”和“能在目标服务等级下长期运行”，三者并不等同。