AI服务器PoC与验收指标怎么定？性能、稳定性与验收指南
AI服务器PoC不应只跑一次模型或只看GPU峰值性能。本文给出从业务任务、TTFT/TPOT、吞吐、并发、稳定性到软件环境和故障恢复的可复用验收框架。
- Slug
ai-server-poc-acceptance-metrics- 更新
- 2026-08-06
- 来源
- 3
- 关系
- 4
先给结论
AI服务器 PoC 的核心不是证明“模型能跑起来”，而是验证目标业务在指定软硬件环境中，能否以可重复的方式达到约定的质量、性能、稳定性与运维要求。
- 先固定测试合同：模型版本、精度/量化、框架、输入/输出长度、并发模型、GPU拓扑和测试时长必须记录。
- 分层验收：硬件健康与拓扑 → 软件与模型功能 → 单请求性能 → 并发容量 → 长稳与恢复。
- 阈值来自业务：TTFT、TPOT、吞吐、P95/P99、并发和可用性没有适用于所有模型的统一合格线，应在PoC开始前由业务目标反推。
- 基准不替代真实负载：MLPerf等标准化基准适合建立可重复的比较方法，但项目验收仍应加入客户自己的模型、请求长度分布和真实任务集。
第一步：先定义PoC测试合同，避免最后无法比较
同一台服务器，仅改变模型精度、上下文、并发或推理框架，测试结果就可能明显不同。因此PoC开始前应先冻结一份“测试合同”。
| 维度 | 至少记录什么 | 为什么必须固定 |
|---|---|---|
| 业务任务 | 问答、RAG、Coding、视觉、训练/微调等 | 决定真正需要验证的质量与响应目标 |
| 模型 | 模型名称、版本/commit、Dense或MoE | 模型结构与版本会改变资源和算子路径 |
| 精度 | BF16/FP16/FP8/INT8/INT4及具体量化方案 | 影响显存、性能与输出质量 |
| 输入/输出 | 典型、P95、最大输入长度和输出长度 | Prefill与Decode负载不同，不能只写“128K上下文” |
| 并发模型 | 闭环并发、到达率/QPS或真实流量回放 | 不同压测模型得到的排队与尾延迟不可直接混比 |
| 软硬件 | GPU/CPU/内存、拓扑、驱动、框架、容器、通信库 | 保证测试可复现并能解释差异 |
| 测试窗口 | 预热方式、正式测试时长、重复次数 | 排除冷启动和过短采样造成的偶然结果 |
如果两个候选方案的上述条件不同，单个 tokens/s 或吞吐数字不具备直接可比性。
AI服务器PoC建议按五层验收
| 层级 | 验收重点 | 典型检查项 |
|---|---|---|
| 1. 硬件与拓扑 | 设备是否健康、互联是否按设计工作 | GPU/NIC/NVMe枚举，PCIe链路，GPU拓扑，温度/功耗，错误计数 |
| 2. 软件与功能 | 模型和目标能力是否正确 | 驱动/运行时、模型加载、所需算子、结构化输出、工具调用、训练或推理流程 |
| 3. 单请求性能 | 建立无排队基线 | TTFT、TPOT/ITL、端到端时延、显存峰值、GPU活动度 |
| 4. 并发与容量 | 找到SLA约束下的容量边界 | 请求/秒、输入/输出tokens/s、P95/P99、队列、OOM和拒绝率 |
| 5. 长稳与恢复 | 确认生产可运维性 | 持续压力、内存漂移、错误率、进程/节点异常、重启与恢复、日志和监控 |
TTFT、TPOT、吞吐和并发应该怎么进入验收
NVIDIA当前LLM基准文档将TTFT定义为从提交请求到收到首个输出token的时间；TPOT用于描述生成阶段每个输出token的平均耗时。实际项目还应同时记录端到端请求时延、吞吐与高分位尾延迟。
| 指标 | 回答的问题 | 验收注意点 |
|---|---|---|
| TTFT | 用户多久能看到第一个token | 长输入通常更受Prefill和排队影响；建议按输入长度分桶 |
| TPOT / ITL | 开始输出后生成是否流畅 | 与Decode、Batch、GPU利用及跨卡通信有关 |
| 输出吞吐 | 系统单位时间能生成多少token | 必须同时给出并发、输入/输出长度和测试方式 |
| 请求吞吐 | 单位时间完成多少请求 | 更接近业务容量，但请求长度差异会影响结果 |
| P95 / P99 | 高分位用户体验是否恶化 | 不能只看平均值；应在目标负载下观察 |
| 并发容量 | 在SLA内能同时服务多少任务 | 并发不是越高越好，应和延迟/吞吐曲线一起判断 |
建议做法：先在低并发下建立单请求基线，再逐级提升并发，直到TTFT、TPOT、P95/P99或错误率触达业务约束，从而得到“在目标SLA下的最大稳定容量”，而不是只寻找最高吞吐点。
稳定性与故障恢复怎么测
- 持续压力：用能代表生产流量的请求长度和并发持续运行，观察OOM、进程退出、错误率、温度、功耗、显存与主机内存是否出现异常漂移。
- 资源边界：分别覆盖短上下文高并发、长上下文低并发、大Batch或训练Checkpoint等最可能触及容量边界的场景。
- 恢复能力：根据架构测试服务进程重启、健康检查、模型重新加载、节点摘除/恢复等操作，并记录恢复时间和业务影响。
- 可观测性：验收时确认GPU、CPU、内存、网络、存储和模型服务指标能被持续采集，并能关联到请求层错误和时延。
“长稳测试必须运行多少小时”没有通用标准。测试时长应覆盖计划中的故障场景、负载周期和热稳态，并在项目验收协议中提前写明。
AI服务器PoC验收记录表
| 项目 | 验收口径示例 | 结果记录 |
|---|---|---|
| 硬件健康 | 设备、链路、温度/功耗和错误状态符合平台设计 | 实测/日志 |
| 模型功能 | 目标模型成功加载；关键业务样例通过 | 通过率 + 失败样例 |
| 质量回归 | 与约定参考环境在同一任务集比较 | 指标 + 差异说明 |
| TTFT | 在指定输入长度、并发与分位数下评估 | P50/P95/P99 |
| TPOT/ITL | 在指定输出长度、并发与分位数下评估 | P50/P95/P99 |
| 吞吐 | 明确输入/输出tokens/s或requests/s的统计口径 | 结果 + 负载条件 |
| 并发容量 | 满足SLA时的稳定并发/到达率 | 容量边界 |
| 长稳 | 按约定时长与负载运行，无不可接受错误 | 时长 + 错误/告警 |
| 恢复 | 完成约定故障注入和恢复流程 | 恢复时间 + 数据/业务影响 |
| 复现性 | 保存版本、配置、测试脚本与关键日志 | 归档位置/版本号 |
PoC最常见的5个失真点
- 只证明模型能启动，没有把业务质量、性能和长稳写进验收。
- 只看平均吞吐，不记录TTFT、TPOT和P95/P99，无法判断真实交互体验。
- 两个方案使用不同量化、上下文或并发，却直接比较单个性能数字。
- 使用厂商公开峰值或一次微基准替代目标模型端到端测试。
- PoC结束后没有保存容器、驱动、框架、模型版本和配置，生产环境无法复现。
赋创可以在项目中提供哪些支持
赋创可结合客户的目标模型、业务任务、现有软硬件环境和机房条件，协助梳理需求、形成候选AI服务器/集群方案，并在目标环境中完成软硬件适配、PoC基线、容量与稳定性验证。涉及性能与资源数量时，以明确测试条件和实测结果为依据，不把单一理论峰值或厂商公开样例直接等同于客户生产配置。
FAQ｜常见问题
AI服务器PoC最重要的指标是什么？
没有单一最重要指标。交互式推理通常需要同时看业务质量、TTFT、TPOT、吞吐、P95/P99、并发容量和稳定性；训练类任务则更关注目标质量下的训练时间、扩展效率、Checkpoint和稳定性。
PoC可以直接用MLPerf成绩验收吗？
MLPerf适合提供标准化、可重复的比较方法，但企业PoC仍应加入真实模型、业务数据、输入/输出长度和服务SLA。公开基准不能替代项目端到端验收。
并发越高代表服务器越好吗？
不是。提高并发通常会改变排队、Batch和显存占用。更有意义的是“在约定TTFT/TPOT或尾延迟SLA下能稳定承载多少负载”。
PoC必须跑72小时或7天吗？
没有适用于所有AI项目的统一时长。应根据负载周期、故障场景和项目风险确定，并提前写入验收协议。
不同GPU方案能直接比较tokens/s吗？
只有在模型、精度、框架、请求长度、并发、测试方法等关键条件一致时才具备直接参考意义；否则应先统一测试合同。
方案咨询
需要把方案落到实际配置？
联系赋创获取算力、软件栈和交付路径建议。