AI推理基础设施如何验收：企业别只看峰值算力，还要评估有效吞吐、时延与软件栈

采购 AI 推理基础设施时，真正需要验收的不是芯片标称峰值，而是在指定模型、并发量、输入输出长度和服务等级目标下，系统能否稳定地产出可用 Token，并把时延、资源利用率、能耗、软件兼容性和总拥有成本控制在业务可接受范围内。随着《先进计算暨算力发展指数蓝皮书（2025年）》所反映的智能算力增长和行业应用扩展，企业的算力采购重点应从“买多少峰值算力”转向“每单位成本能够交付多少有效业务产出”。

先定义“有效产出”，再比较芯片性能

同一款芯片在不同模型、不同上下文长度和不同并发策略下，结果可能完全不同。单看 TOPS、FLOPS、显存带宽或厂商提供的单项 Token/s，无法回答企业最关心的几个问题：

• 业务高峰期能同时服务多少用户？
• 用户等待首个有效响应的时间是否达标？
• 输出过程是否稳定，还是只有短时间峰值？
• 加速卡是否被显存容量、数据搬运或通信链路拖慢？
• 模型迁移和软件适配需要多少人月？
• 每百万 Token、每次请求或每个在线用户的成本是多少？

因此，验收对象应从“设备”扩大到完整推理系统：

模型与硬件适配度 + 推理运行时 + 调度策略 + 显存与存储 + 高速互联 + 业务流量模型 + 运维工具 + 能源与软件成本。

可以将有效吞吐定义为：在满足业务时延目标、错误率目标和输出质量要求的前提下，系统持续交付的有效 Token 数量。这里的“有效”很重要。超过时延服务等级目标的请求、因超时或错误被丢弃的请求，以及为了压测而使用但不代表真实业务的输入，都不应简单计入产出。

按业务场景拆分验收目标

训练、在线推理、批量推理和边缘推理使用的是不同的评价逻辑。把训练集群的峰值指标直接套用于在线服务，往往会得到错误结论。

场景	主要目标	关键指标	典型取舍
训练	缩短任务完成时间并提高加速器利用率	训练吞吐、扩展效率、检查点时间、通信效率、作业完成时间	可以牺牲部分单请求时延，换取整体任务效率
在线推理	在服务等级目标内服务更多请求	首 Token 时延、每输出 Token 时延、P95/P99 时延、并发用户数、有效 Token 吞吐	不能用高批量吞吐掩盖用户等待时间
批量推理	以最低成本完成大量任务	总处理时间、批量 Token 吞吐、任务失败率、单位任务成本	通常可以使用更大的批次和更长排队时间
边缘推理	在受限资源和网络条件下保持可用	端到端时延、功耗、内存占用、离线可用性、模型更新成本	需要在模型规模、精度和设备成本之间平衡

对于在线大语言模型服务，至少应把请求拆成两个阶段：输入处理阶段和输出生成阶段。前者与输入 Token 数、上下文长度、预填充并行度有关；后者与输出 Token 数、解码策略和并发用户数有关。只报告一个平均 Token/s，会掩盖两阶段之间的差异。

模型与硬件适配，先于芯片横向排名

关注模型的真实计算路径

模型架构决定了硬件能否发挥作用。验收前应明确以下信息：

1. 模型类型：密集模型、混合专家模型、视觉语言模型、语音模型或传统机器学习模型。
2. 精度方案：FP32、FP16、BF16、INT8、INT4，是否需要量化校准，是否允许混合精度。
3. 上下文长度：平均值、P95 值和最大值分别是多少。
4. 输入输出比例：短问短答、长文档问答、代码生成和多轮对话的 Token 分布不同。
5. 并行方式：单卡、张量并行、流水线并行或专家并行。
6. 算子覆盖情况：关键算子是否有高效内核，是否需要回退到通用实现。
7. 动态特性：是否使用 KV Cache、前缀缓存、投机解码或请求合并。

同一硬件平台可能适合某类模型，却不适合另一类模型。例如，显存容量不足会限制上下文长度和并发数；跨卡通信效率不足会影响大模型部署；某些量化格式如果没有成熟的算子支持，理论上减少的计算量并不会转化为实际吞吐。

把“可运行”与“高效运行”区分开

模型能够加载并返回结果，只能说明兼容性达到最低要求。企业还应验证：

• 模型精度是否与基准结果一致；
• 量化后关键任务质量是否下降；
• 所有关键算子是否使用目标加速器；
• 是否存在频繁的 CPU 回退或主机与设备之间的数据拷贝；
• 多卡通信是否稳定；
• 长上下文和高并发下是否发生显存碎片、频繁换入换出或请求失败。

最终验收不应只给出“支持某模型”的结论，而应形成一张模型—硬件—软件版本矩阵，记录每种配置下的可用精度、最大上下文、并发上限、吞吐和时延。

有效吞吐：不要只测峰值 Token/s

统一输入输出和并发条件

测试报告至少需要披露以下参数，否则不同方案之间不可比：

• 模型名称、参数规模和版本；
• 精度与量化方式；
• 输入 Token 长度分布；
• 输出 Token 长度分布；
• 并发请求数和到达方式；
• 是否启用动态批处理；
• 是否启用前缀缓存、KV Cache 或投机解码；
• 单卡、多卡或多节点拓扑；
• 软件栈版本和关键配置；
• 测试持续时间、预热时间和失败请求处理方式。

建议同时设置三类工作负载：

1. 典型负载：最接近当前生产流量。
2. 峰值负载：模拟业务高峰和突发流量。
3. 压力负载：持续增加并发，观察系统何时违反服务等级目标。

有效吞吐可以用一个简单的验收口径表达：

有效吞吐 =
在SLO内成功完成的请求所产生的有效输出Token总数
÷
测试持续时间

如果业务更关心用户容量，也可以把结果转换为：

满足目标时延的最大稳定并发用户数

这比单纯比较设备峰值更接近采购决策。对于批量推理，则应同时记录总任务完成时间、失败重试次数和单位任务成本，不能把在线服务的首 Token 指标作为唯一标准。

关注稳定区间，而不是瞬时最高点

压测中偶然出现的最高吞吐并不代表生产能力。验收时应观察连续运行一段时间后的稳定区间，包括：

• 吞吐是否随时间下降；
• 显存占用是否持续增长；
• 长请求是否导致短请求排队；
• 温度和功耗是否触发降频；
• 错误率是否随并发上升；
• 调度器是否出现批次抖动；
• P95、P99 时延是否明显恶化。

系统可以在较低并发下达到很高的单请求速度，但一旦并发增加，排队、显存和通信开销就可能使有效吞吐下降。因此，报告应同时给出吞吐—时延曲线，而不是只给一个“最佳成绩”。

首 Token 时延与持续输出时延要分开看

对于交互式生成服务，用户体验通常受两个指标影响：

• 首 Token 时延：从请求提交到返回第一个输出 Token 的时间，反映输入处理、排队和调度效率。
• 持续输出时延：首 Token 之后生成后续 Token 的间隔，常以每输出 Token 的时间或 Token/s 表示。

两者对应的优化方向并不完全相同。增加批量可能提高整体吞吐，却让请求排队更久；长上下文可能显著增加首 Token 时延；解码阶段则更容易受到显存带宽、KV Cache 访问和并发规模影响。

验收表可以采用如下结构：

指标	建议记录方式	需要回答的问题
首 Token 时延	平均值、P50、P95、P99	高峰期用户多久能看到第一段响应
持续输出时延	每输出 Token 时间、P50、P95、P99	输出是否连贯，是否出现明显停顿
端到端时延	从请求进入网关到生成结束	网络、排队、推理和后处理的总耗时是多少
完成时延	不同输入输出长度下分别记录	长回答是否拖垮系统
超时率	按请求类型和并发区间统计	有多少请求没有在SLO内完成
抖动	不同时间窗口的波动	服务是否稳定而非偶然达标

采购合同中应明确是“平均值达标”还是“P95/P99 达标”。对于面向用户的在线服务，后者通常更有决策价值。

显存和高速互联可能比计算核心更早成为瓶颈

显存容量决定可部署规模

大模型推理的显存需求不仅包括模型权重，还包括：

• KV Cache；
• 中间激活；
• 临时工作区；
• 批处理和调度缓存；
• 通信缓冲区；
• 运行时和框架本身的开销。

上下文越长、并发越高，KV Cache 占用越明显。验收时不能只测试“模型能否加载”，还要测试在目标上下文和并发条件下的显存余量。建议记录：

• 权重占用；
• 单请求 KV Cache 增长量；
• 稳态显存占用；
• 峰值显存占用；
• 显存碎片率或分配失败情况；
• 并发提升时的显存变化曲线。

如果系统需要频繁把数据移到主机内存或外部存储，表面上可能仍能返回结果，但时延和吞吐通常会明显恶化。这部分应单独标记为“容量扩展能力”，而不能与本地显存性能混为一谈。

多卡部署要测通信，而不是只加总单卡性能

当模型需要跨卡部署时，张量并行和流水线并行都会引入通信。需要核查：

• 卡间连接类型和拓扑；
• 实际可用带宽与理论带宽的差距；
• 集合通信效率；
• 跨节点通信是否经过额外交换层；
• 通信拥塞是否导致计算单元空闲；
• 节点故障或链路降级时的行为。

多卡数量增加不一定带来线性性能增长。应把单卡、单机多卡和多机多卡分别测试，计算扩展效率：

扩展效率 =
多卡有效吞吐
÷
（单卡有效吞吐 × 卡数）

该指标不能脱离具体模型和并行策略解读，但可以帮助企业识别“增加硬件却没有增加业务产出”的情况。

软件栈迁移成本必须纳入算力采购

推理基础设施不是只有芯片和服务器。驱动、编译器、运行时、算子库、推理服务器、调度器、监控系统和模型转换工具，都会影响最终结果。

以推理服务为例，动态批处理能够在一定条件下提高吞吐，但批量策略、排队时间和时延目标之间需要共同调优。Triton Inference Server 的公开资料也明确将动态批处理、并发执行和多框架模型部署作为服务能力的一部分；这说明推理服务器本身应被纳入性能测试，而不是只测试底层设备。

软件兼容性验收至少包括以下内容：

维度	验收问题
模型格式	现有模型能否直接加载，还是必须转换格式
算子支持	是否存在不支持算子、CPU回退或自定义开发
精度支持	目标精度是否有成熟内核和校准工具
框架兼容	PyTorch、TensorFlow、ONNX等现有链路是否需要改造
服务接口	是否兼容现有网关、鉴权、流式输出和日志系统
调度能力	是否支持动态批处理、优先级、限流和多模型共存
监控运维	是否能采集Token吞吐、显存、时延和错误原因
升级回滚	驱动、运行时和模型版本能否独立升级与回滚
生态迁移	开发者是否需要学习新的编译、调优和故障排查工具

软件迁移成本可拆为四部分：

软件迁移总成本 =
模型转换与算子适配
+ 性能调优与测试
+ 生产系统改造
+ 运维培训及长期维护

如果某平台在单项跑分上更快，但需要大量重写现有推理服务、缺少关键算子或升级风险较高，那么其全生命周期成本未必更低。企业还应要求供应方提供版本支持周期、问题响应机制、补丁策略和性能回退方案。

云、边、端的部署边界

云端或集中式数据中心

适合模型规模大、流量波动明显、需要统一运维和快速扩缩容的场景。优势是硬件利用率和资源池化能力较强，便于集中升级模型与软件；限制是网络往返、数据合规、跨区域访问和长期租用成本。

验收重点包括：

• 实例启动和扩容时间；
• 高峰期资源可获得性；
• 跨可用区或跨地域网络时延；
• 空闲资源是否计费；
• 按请求、按 Token 或按实例计费的真实成本；
• 数据隔离、日志留存和故障切换能力。

边缘侧

适合工厂、门店、园区、车辆和网络不稳定的现场。边缘部署通常更重视本地响应、离线可用和数据不出现场，而不是追求最大模型规模。

验收重点包括：

• 断网时是否仍能运行；
• 本地设备在高温、低带宽和有限电力条件下的稳定性；
• 模型更新和回滚时间；
• 多设备统一管理能力；
• 现场维护和备件成本；
• 设备功耗与散热条件。

端侧

适合对隐私、即时响应和离线能力要求较高的个人设备或专用终端。端侧资源有限，应重点评估量化模型质量、内存占用、启动时间、持续功耗和应用兼容性。

企业不应简单地把同一模型完整复制到云、边、端。更常见的做法是根据任务拆分：端侧处理隐私敏感或低复杂度任务，边缘侧承担本地实时任务，云端负责复杂推理、统一知识更新和离线批处理。

用总拥有成本替代单价比较

算力采购的成本不能只看服务器采购价或云实例单价。建议按单位业务产出计算：

单位有效Token成本 =
硬件折旧
+ 机房、电力与制冷
+ 云资源或托管费用
+ 软件许可与技术支持
+ 运维人力
+ 模型迁移和升级成本
+ 故障与闲置成本
÷
验收期内的有效Token总数

对于在线服务，还可以计算单位稳定并发成本：

单位稳定并发成本 =
月度基础设施总成本
÷
满足SLO的稳定并发用户数

对云资源，要把最低保障容量、弹性扩容、跨区域流量、存储、日志和出口流量一起计入。对自建集群，则要考虑利用率不足、设备折旧、备件、机房改造和电力容量。对边缘设备，还要加入现场安装、维护、远程管理和设备替换成本。

一份可执行的验收清单

测试前

• 明确模型版本、精度、上下文长度和输入输出分布；
• 明确在线、批量、边缘等业务场景；
• 定义P50、P95、P99时延和错误率目标；
• 规定并发模型、流量到达方式和测试持续时间；
• 固定驱动、运行时、推理服务和编译器版本；
• 确定是否允许量化、缓存、投机解码和动态批处理。

测试中

• 记录有效 Token 吞吐，而非只记录理论峰值；
• 同时记录首 Token 时延和持续输出时延；
• 观察显存、功耗、温度、频率和通信带宽；
• 分别测试典型负载、峰值负载和压力负载；
• 测试长上下文、高并发、混合请求和多模型共存；
• 记录错误、超时、重试和服务降级情况；
• 对单卡、多卡、单机和多机配置分别测量。

测试后

• 形成模型—硬件—软件版本矩阵；
• 输出吞吐—时延曲线和稳定运行曲线；
• 计算资源利用率、扩展效率和单位有效 Token 成本；
• 核算模型迁移、算子适配和运维培训成本；
• 明确版本升级、故障切换和性能回退方案；
• 将关键指标写入采购合同或验收条款；
• 为生产流量变化设置复测和重新验收条件。

结论：采购的是可持续交付能力

AI 推理基础设施的价值，不在于设备在理想条件下能达到多高峰值，而在于它能否围绕真实模型和真实业务，持续交付满足时延、质量和成本约束的有效产出。

企业可以把验收顺序固定为：先定义业务负载，再确认模型与硬件适配；先测有效吞吐和尾部时延，再看峰值性能；先核算显存、互联和软件迁移，再比较设备价格；最后用单位有效 Token 成本和稳定并发能力做采购决策。

只有把芯片、系统、软件栈和业务流量放在同一套测试框架中，算力采购才不会停留在参数表比较，而能真正转化为可核验、可运营、可持续的 AI 生产能力。