推理负载的形状在变。过去一个请求进来，返回一段文本就结束了。现在的应用是多轮对话加技能调用，一次交互里模型可能被调用十几次，每次都要重新读取历史上下文。公开资料显示，随着 AI 编程助手、信贷助手、员工超级助手这类应用普及，多轮对话与技能调用带来的 Token 消耗出现百倍级增长。

这带来的直接后果是：按老方法估算的并发承载能力，上线后往往严重不够用。这篇文章讲的就是怎么把并发算准，以及在什么信号出现时该扩容。84.png

一、先分清三个延迟指标

TTFT（首字延迟）是从请求发出到收到第一个 Token 的时间，由预填充阶段决定，随输入长度增长。TPOT（单 Token 延迟）是后续每个 Token 的平均生成间隔，由解码阶段决定，几乎完全受显存带宽约束。吞吐是单位时间处理的 Token 总量，是并发能力的表现。

这三个指标存在明确的取舍关系。同一块卡上，并发数增加会提高吞吐，但 TTFT 与 TPOT 都会变长。工程上的目标不是把某一个指标做到极致，而是在满足延迟要求的前提下把吞吐提到最高。如果业务要求首字延迟低于某个阈值，那个阈值就决定了并发数的上限。

二、并发承载能力的估算步骤

估算的核心是回答一个问题：一块卡上能同时容纳多少个请求的中间态。步骤不复杂，但每一步都要按最坏情况取值。

步骤计算内容注意事项
1算可用显存标称显存减去权重占用与激活值余量，通常只剩六到八成
2算单请求 KV Cache按最大上下文长度取值，不能按平均值
3初算并发上限可用显存除以单请求 KV Cache，得到显存维度上限
4用延迟校验按该并发压测，看 TTFT 与 TPOT 是否仍在可接受区间
5留出调度余量实际按上限的七成配置，为突发流量与缓存碎片留空间

第三步得到的只是理论上限，第四步才是真正决定配置规模的环节。很多团队只做完第三步就上线，结果发现延迟达不到要求，回头再改架构，代价更大。

算例：一块 96G 显存的卡部署量化后约占用 20GB 权重的模型，标称显存留出激活值与框架开销后按八成计，可用约 57GB。若单请求在最大上下文下占用 KV Cache 约 3GB，显存维度上限约 19 路。实际配置按七成计，约 13 路。如果实测 13 路时首字延迟已超过业务要求，那么真正的瓶颈是显存带宽而不是容量，加卡才能解决。

三、什么时候该扩容：四个可观测信号

扩容时机不该凭感觉，也不该等到用户投诉。下面四个信号出现任意两个，就说明当前配置已经接近上限。

信号一：首字延迟持续上升。预填充阶段排队是最早出现的瓶颈。TTFT 从稳定的几百毫秒逐步爬升，说明请求到达速度已经超过预填充的处理速度。这个信号出现得最早，也最容易观测。

信号二：排队队列长度长期不归零。调度队列持续有请求等待，说明供给端已经饱和。偶发的队列峰值是正常的，长期不归零就需要处理。

信号三：GPU 利用率与吞吐不再同步增长。利用率已经接近饱和，但吞吐上不去，说明瓶颈从算力转移到了显存带宽或调度环节。这时候单纯加卡可能收益有限，需要先做批处理优化或者换更大的显存配置。

信号四：尾延迟突破业务容忍度。平均值正常但 P99 明显变差，说明少数长请求在抢占资源。长上下文请求与短请求混跑时特别容易出现这种情况，处理方式可以是分池部署，把长上下文请求单独放到大显存实例上。83.png

四、按推理形态选实例：官网价格对照

推理服务的选型逻辑与训练不同，更看重显存带宽与单卡成本，而不是算力峰值。下表为平台公开报价，采集日期 2026 年 10 月 10 日，按小时计费适合弹性扩缩的在线服务。

实例规格按小时按天适合的推理形态
RTX 4090 24G¥1.57¥36小模型高并发、图像生成类服务
RTX 4090 48G¥2.86¥67中等模型、兼顾成本与上下文长度
华为 910B 64G¥3.58¥85国产平台推理、多路并发
NVIDIA H20 96G¥6.20¥148大模型推理、高并发下的缓存余量
NVIDIA A800 80G¥7.15¥171中大模型推理与轻量训练共用
NVIDIA H100 80G¥12.98¥311对标机型验证、迁移前基准测试
NVIDIA H200 141G¥13.94¥334超长上下文、智能体长会话

从这张表可以看出一个实用的分派原则：短上下文高并发的服务用 24G 到 48G 档位做水平扩展，单卡成本低、复制容易；长上下文与智能体场景用 96G 以上档位做垂直扩展，避免因显存不足频繁爆缓存。两类负载混在同一实例上，是尾延迟恶化的常见原因。

需要按并发曲线做弹性扩缩时，可在算力租赁平台的实例列表按卡数选择规格，按止计费，关机不收费。

先把并发算准，再谈加机器
极智算平台提供 24G 到 288G 的完整显存梯度，容器实例按卡数伸缩、按量计费，适合推理服务的弹性扩容验证。
查看实时规格与价格

常见问题

并发上不去，是加卡还是优化？
先看信号三是哪种情况。如果 GPU 利用率已经饱和且吞吐随之提升，说明算力确实不够，可以加卡；如果利用率高但吞吐不涨，瓶颈在显存带宽或调度，此时加卡的边际收益很小，应该先做连续批处理与请求分池。
多轮对话场景为什么要按最大上下文估算？
因为 KV Cache 按实际历史长度占用显存，而多轮对话的历史会不断累积。按平均长度估算会导致部分会话在后期爆显存，触发请求失败或强制截断。按业务允许的最大上下文估算，再按并发上限配置，才能保证长会话不中断。
按小时计费和包月，推理服务选哪个？
取决于流量的日间波动幅度。推理流量通常白天高夜间低，如果夜间可以缩容到零，按小时计费更省；如果服务需要 7×24 小时常驻，包月单价更低。混合做法是保留一个包月底座应对基线流量，高峰用按需实例补足。
国产机型做推理需要注意什么？
主要看软件栈适配情况与算子覆盖度。主流推理框架与常用模型通常已有适配，但自研算子与特殊量化方案可能需要额外工作量。建议先拿真实业务流量做对比测试，不要只看跑分。
数据来源与时效
价格数据采集自极智算平台实例列表公开报价，采集日期 2026 年 10 月 10 日，实际价格以平台页面展示为准。行业背景数据来源：多轮对话与技能调用带来的 Token 消耗量级见华为中国政企业务 2026 年 10 月 8 日发布；移动云 MoMA 平台模型数量与单位使用成本、资源占用率变化见中国通信企业协会 2026 年 10 月 9 日报道。文中并发估算算例为演示性计算，参数取值需结合具体模型、量化方案与业务延迟要求实测确定，不作为任何业务的容量承诺。
算力租赁平台 GPU推理并发测算 推理算力扩容时机 GPU租赁 首字延迟 推理服务选型