指标一：有效吞吐
吞吐按单位时间完成的任务数测，不用显卡标称算力。为什么强调有效：批调度、并发争抢与长上下文都会压低实际值，必须用真实提示词和真实输出长度跑，得到的数字才有复现价值，也才敢写进容量规划。
指标二：并发承载
并发要区分在线峰值与会话总量。怎么测：逐档加压，记录任务完成率与排队时长，找到完成率开始下滑的拐点；这个拐点才是可承诺容量，厂商标称的并发数只能当参考，不能作为验收依据。
指标三：首字与尾字延迟
交互场景看首字延迟，批处理场景看整体完成时间。怎么测：在生产同款上下文档位下取分位值，只报平均值会被少数长请求掩盖，上线后一线反馈卡顿，排查又要从头再来，时间成本更高。
指标四：单位任务成本
用一段时间内的资源总投入除以合格任务数，分子含硬件折旧、电力、许可与运维人力。边界在分母：只能计通过验收的任务，把失败与重试也算进去，成本会被压得虚低，后续预算必然失控。
指标五：故障恢复时间
这项最容易被漏掉。怎么做：列出单点，逐个假设失效并测量恢复到可用的时间；没有演练过的恢复时间只能算猜测，不应写进合同承诺，也不该作为选型依据，否则故障时会很被动。
适用与不适用
适合谁
- 有数据不出内网硬性要求的规上企业
- 推理量相对稳定、峰值可以预估的业务
- 有基础运维团队能承接日常值班与变更
不适合谁
- 调用量很小、场景尚未验证的探索期团队
- 既无机房电力条件、也不考虑租用专属资源
典型场景
某设计院要把图纸说明与规范条文做成内部检索问答。信息中心先用两周搭小规模环境，抽取真实问题跑吞吐与首字延迟基线，记录单机故障后的恢复耗时，形成一页指标表交技术委员会复核，再决定采购规模。
可执行步骤
- 先做数据分级，逐类确认哪些内容按合同、法规或监管要求不得出网
- 取真实业务问题与真实输出长度，编一组不少于百条、可复用的测试集，覆盖长短请求
- 按并发分档逐级加压，记录完成率拐点、分位延迟与长上下文表现，形成基线表
- 把硬件折旧、电力、许可与运维人力折进单位任务成本，形成三年口径
- 逐项做单点故障演练，把恢复步骤写成值班人员可直接执行的清单
常见坑
- 用厂商演示里的短提示词测吞吐，上线后长上下文一压就崩，返工代价远高于前期多测一轮。
- 只报平均值不报分位，尾部延迟被掩盖，报表好看而一线照旧卡顿，问题往往拖到投诉才暴露。
- 恢复时间写进承诺却没做过演练，真出故障时没人知道先启哪一步，停机时间成倍放大，事后很难补。
自检与验收清单
- 五项指标都有测法、原始记录，他人可照记录复现
- 测试集来自真实业务，并覆盖长上下文与边界样例
- 并发拐点留有安全余量，报告中写明理由与假设
- 单点故障演练做过、留档，并有责任人签字确认
常见问题
没有测试集能先评估吗
可以先做定性判断，但结论只够用来排除明显不合适的方案。要形成可承诺的容量与成本，仍需一组来自真实业务的问题与输出样本，否则指标无法复核，验收时也没有对照物。
五项指标里哪项最容易失真
单位任务成本。分母若剔除失败请求与重试，结果会明显偏低；分子若只算显卡采购、漏掉电力与运维人力，同样偏低。两项都要按同一口径连续统计一段时间再下结论。
评估通常要花多久
有现成测试环境时，两到三周可跑完五项；需要新采购硬件则受供货周期影响。建议把评估与采购拆成两个决策点，避免边评估边下单，最后用结论去迁就已经签下的订单。