基准测试都是串行跑的——而你的用户，不是。
为什么 50 个并发用户是一道隐形的门槛
首 token 延迟（TTFT）是 LLM 产品中最直接影响用户感知的指标。单用户测试时，主流 API 的 TTFT 通常落在 300–800ms 之间，足以让早期演示看起来流畅。但当并发请求从 0 爬升到 50，这个数字往往膨胀至 2–5 秒，有时更高——原因不是网络，而是模型服务层的排队机制与 KV-cache 争抢。
供应商公布的 benchmark 几乎全部采用串行请求：一个请求完成后再发下一个，这在生产环境中几乎不存在。真实的 SaaS 场景里，用户同时打开页面、同时触发补全，请求在同一个 token-generation 队列里堆叠。这不是供应商隐瞒数据，而是行业惯例从未被挑战过。
对早期产品而言，这个落差的危险在于时机：它只在你开始增长时才会出现。内测阶段一切正常，公测第一天用户涌入，响应变慢，流失发生——而你的监控面板上，错误率依然是零。
你应该在 benchmark 里自己补上的测试
- 01 并发压力下的 TTFT 基线 — 用 50 / 100 并发分别跑 P50 与 P95，而非平均值。
- 02 冷池与热池的延迟差 — 部分供应商在低流量时会缩减实例，首个请求延迟可达 3–6 秒。
- 03 排队超时的用户可见行为 — API 超时不等于用户看到错误；更常见的是无声的白屏等待。
- 04 流式输出的感知优化空间 — Streaming 不能降低 TTFT，但能将「卡顿感」的感知阈值从 800ms 推到约 2s。
Top comments (0)