周三下午，一位工程师在本地跑了个小模型测试。结果让他后背发凉——99%的请求都没达标，监控面板却一片祥和。
这不是什么边缘案例。NVIDIA新推出的AIPerf工具，正在暴露一个被大多数大模型部署忽略的性能黑洞。
他用的是Granite 4 350M，一个能在MacBook上跑的小模型。测试场景简单到近乎简陋：本地Ollama服务，HTTP端点，三轮递进式压测。但数据讲了一个所有性能工程师都该听的故事。
第一轮：单用户基线，完美的谎言
最经典的错误从这里开始——只测单并发。
50个请求，并发数1。结果漂亮得不像话：平均首Token延迟（TTFT）223毫秒，Token间延迟（ITL）稳定在10.67毫秒。生产就绪？完全可以签字。
问题就在这里：大多数人到此为止。
第二轮：50并发，幻觉破灭
他把并发拉到50，加了10个请求预热，跑满60秒。这是共享端点的真实场景。
TTFT从223毫秒飙到41,660毫秒——186倍膨胀。P99用户等首Token等了超过64秒。屏幕空白，光标闪烁，用户已经开始骂人了。
但你的仪表盘？大概率还是绿的。传统监控只看"系统有没有在干活"，不看"用户有没有被服务"。
第三轮：Goodput撕开遮羞布
AIPerf的真正杀招在这里。他加了--goodput参数，设定TTFT的SLO为500毫秒。Goodput只统计达标的请求，而不是无差别吞吞吐吐。
结果触目惊心：
- 请求吞吐：0.91 req/sec，看着还行
- Goodput：0.01 req/sec
99%的请求没通过500毫秒TTFT门槛。系统在忙，但用户没被服务。这是两个完全不同的概念。
更隐蔽的细节：ITL几乎没动。Token间延迟始终稳在10毫秒左右，连TTST（第二Token时间）也保持一致。模型生成Token的速度没变，变的是排队时间。
瓶颈不在推理本身，在调度层。请求堆积，队列膨胀，首Token被无限期推迟——但传统指标完全感知不到这种"结构性窒息"。
AIPerf的安装很简单：pip install aiperf。代码在GitHub开源。但工具本身不是重点。
重点是测试范式的转变：从"系统能跑吗"到"用户能等吗"，从"吞吐多少"到"有效吞吐多少"。Goodput这个概念，把SLO从文档里的废话变成了可测量的硬指标。
小模型的测试结论，直接映射到云端大模型部署。并发一高，队列一堵，用户体验断崖式下跌——而你的平均延迟指标可能还在微笑。
那位工程师最后说：别信基线，别信平均，别信绿色仪表盘。去测Goodput，去测P99 TTFT，去模拟真实并发。否则，用户会用脚投票，只是不会告诉你原因。
热门跟贴