部署AI服务器后，显卡利用率高不等于业务做得好：它可能处理了更多请求，也可能只是排队变长。判断推理效率和业务收益，需要把用户体验、实际处理能力、资源消耗和业务结果放在一起看，并在相同模型、输入和负载条件下比较。
先看用户是否等得更久
对生成式应用，首Token时延（TTFT）衡量请求发出后，用户等到第一个输出字符的时间；生成速度则可用 tokens/s 表示。两者要分开看：首字快但后续生成慢，仍可能让长回答显得迟缓。对分类、抽取等一次性任务，可直接记录端到端响应时延。
除了平均值，还要统计 p50、p95 和 p99：p95 表示95%的请求不超过该时延，p99更能暴露少量极慢请求。平均值正常而 p99 很高，可能意味着突发流量、长输入或排队带来尾部延迟。应按短请求、长上下文和不同输出长度分组，避免一种请求掩盖另一种的表现。
把处理能力与排队分开
并发吞吐要同时记录每秒完成的请求数、每秒生成的 tokens 数，以及正在处理的请求数。请求数适合输入输出长度相近的任务；tokens/s 更适合文本生成，但不能代替响应时延。并发提高时，吞吐可能先增长、随后趋于平稳，而排队时延继续上升。实际可从低并发逐级增加，直到达到业务设定的时延上限，找出可持续工作区间。
测试时固定模型版本、提示词、输入长度、输出上限和采样参数，再逐步改变并发；记录请求失败、超时、队列长度和时延分位数。若启用了动态批处理，也要记录批次大小和等待时间：合批通常有助于提高设备处理效率，但等待合批可能增加短请求的首字时延。
检查资源是否花在有效工作上
利用率要与显存、功耗一起读
GPU利用率反映设备忙碌程度，不直接代表每瓦产出或服务质量。利用率偏低，可能是请求不足、CPU预处理或数据传输成为瓶颈；利用率长期很高，也可能伴随显存紧张、排队增加。同步观察显存占用、内存带宽相关指标、CPU使用率、功耗和温度，并按请求量或生成 tokens 数归一化，才便于比较。
还应记录模型加载时间、服务可用率和错误率。模型切换、显存不足导致的任务失败，或频繁重启，都会抵消峰值吞吐带来的好处。若部署多个模型，分别统计各模型的请求量与资源占用，避免总平均数掩盖个别服务的问题。
用成本和业务指标核算收益
可计算单位推理成本，例如一个统计周期内的服务器、能源及运维成本，除以成功处理的请求数或生成的百万 tokens 数。比较不同配置时，必须使用相同负载与质量要求；否则，便宜但回答变差、失败增多的方案并不一定划算。硬件折旧和电费的核算周期也应一致。
业务收益要对应具体流程。客服问答可看自助解决率、转人工比例和处理时长；文档抽取可看人工复核比例、字段准确率和单份处理成本。这些指标需与上线前基线比较，并控制流量规模、任务难度等变化。模型生成内容还应抽样检查质量；吞吐提升若换来更多错误，不能算作有效收益。
一套可执行的上线评估流程
- 定义目标：写明响应时延上限、允许错误率、目标请求量和业务质量指标，按任务类型分别设定。
- 建立基线：保存上线前的响应时间、人工耗时、处理量和成本口径；没有历史记录时，先用代表性流量做对照。
- 固定测试条件：选取经脱敏且有代表性的输入，固定模型、输入长度、输出限制和软件配置，记录测试时段与并发。
- 逐级施压：从低并发增加到预计峰值及以上，观察 p95、p99、吞吐、排队、资源占用、超时和质量变化。
- 核算实际结果：按成功任务计算单位成本，并在稳定运行一段时间后与基线比较；区分硬件效果和业务流程调整带来的变化。
常见问题
GPU利用率越高越好吗？
不是。要同时满足时延、质量和稳定性目标，并看每单位成本完成了多少有效任务。
应该优先优化时延还是吞吐？
交互场景通常关注首Token时延和尾部时延；批量处理更重视总吞吐与单位成本。按业务目标取舍。
多久评估一次？
上线初期可持续观察；模型、流量或配置变更后重新压测。日常则按业务周期比较趋势与基线。
归根结底，AI服务器的推理效率要由时延、吞吐与资源成本共同说明，业务收益则要由真实任务质量和流程指标验证。把两组数据放在同一统计周期内复核，才能判断部署是否值得持续扩容或优化。
