“模型首 Token 延迟已经做到 800ms，为什么用户还说慢？”
因为很多系统把收到第一个 SSE 事件当成“首字”。那个事件可能只有 role、空白符，甚至只是心跳。用户真正需要的是“订单能否退款、要补什么材料、下一步点哪里”。如果答案到第 7 秒才出现，800ms 对体验没有解释力。
性能对象不是一个模型接口，而是一条业务链
以售后助手为例，一次请求可能经历：租户排队、意图路由、订单检索、权限校验、模型生成、退款规则工具、内容安全检查和前端渲染。任一环节的 P99 抬头，都会让用户觉得“AI 卡住了”。
因此，测试报告至少要拆出四个时间：
- queue_ms：请求进入到真正开始执行；
- first_text_ms：首个非空、可见字符出现；
- useful_ms：首次出现可行动结论，例如“可以退款”以及原因；
- complete_ms：结构化结果和全部文本完成。
下面的探针用 httpx 读取流式响应。关键点是过滤空事件，并由业务判定函数识别“有效答案”，而不是把 socket 收到字节当体验完成：
import json, time, httpx
ACTION_FIELDS = {
"decision", "reason", "next_step"}
async def probe(payload: dict) -> dict:
start = time.perf_counter()
first_text = useful = None
merged = ""
async with httpx.AsyncClient(timeout=30) as client:
async with client.stream("POST", "http://sut/chat", json=payload) as resp:
resp.raise_for_status()
async for line in resp.aiter_lines():
if not line.startswith("data:"):
continue
event = json.loads(line[5:])
text = event.get("delta", "")
if text.strip() and first_text is None:
first_text = time.perf_counter()
merged += text
state = event.get("business_state", {
})
if useful is None and ACTION_FIELDS <= state.keys():
useful = time.perf_counter()
end = time.perf_counter()
ms = lambda t: None if t is None else round((t - start) * 1000)
return {
"first_text_ms": ms(first_text),
"useful_ms": ms(useful), "complete_ms": ms(end)}
为什么常规并发脚本会把结果测得太乐观
很多压测脚本是“一个虚拟用户收到完整响应后，再发下一次”。当服务变慢，发压端也跟着变慢，于是进入系统的新请求反而减少。最危险的排队时刻被脚本自动回避，这就是协调遗漏。
对客服高峰这类明确到达率的业务，应采用开放到达模型。下面的调度器每秒固定发起请求，不因上一个请求变慢而停下：
import asyncio, time
async def open_loop(rate_per_sec: int, seconds: int, payload: dict):
tasks, loop = [], asyncio.get_running_loop()
begin = loop.time()
total = rate_per_sec * seconds
for i in range(total):
due = begin + i / rate_per_sec
await asyncio.sleep(max(0, due - loop.time()))
tasks.append(asyncio.create_task(probe(payload)))
return await asyncio.gather(*tasks, return_exceptions=True)
def percentile(values, p):
xs = sorted(v for v in values if v is not None)
return xs[min(len(xs) - 1, int((len(xs) - 1) * p))]
性能门禁必须与答案质量一起看
单纯压低延迟，可能诱导模型更早输出未经工具确认的答案。建议将样本按纯问答、检索、单工具、多工具、超时恢复分桶，分别统计 P50/P95/P99，并同时检查：业务字段完整率、工具成功率、降级正确率、单请求 Token 与外部调用成本。
一个可执行的门禁可以是：纯问答 useful P95 小于 2.5 秒；单工具场景小于 4 秒；工具超时后 1 秒内明确告知用户并提供人工入口；任何场景不得为了抢首字而先承诺后核验。
所以，TTFT 没有过时，只是它只能回答“流什么时候动了”。用户关心的是“什么时候拿到能做决定的信息”。把这两个问题分开，性能测试才真正站到了业务一侧。
