1.2 核心指标与 SLO：把“高并发”翻译成可度量的标尺

1.2 核心指标与 SLO：把“高并发”翻译成可度量的标尺

我接手过一个上线半年的大模型对话产品，问他们的 SLO 是什么，答曰"可用性 99.9%，延迟尽量低"。再问 TTFT 的 P99 是多少、错误预算还剩多少、单请求成本环比是涨是跌，三方一脸茫然。结果就是每次出故障，复盘会上吵成一团——有人说"今天延迟很高"，有人说"我看监控挺正常啊"，根本原因是谁都不知道"正常"到底该是多少。没有可度量的指标，所谓稳定性就是一笔糊涂账。

这一节要把"高并发""体验好""成本低"这些模糊词，拆成一组可观测、可告警、可复盘的指标。后面每一个架构方案——限流、缓存、路由——的好坏，都要回到这套标尺来丈量。没有标尺，方案评审就沦为口水战。

为什么不能只盯 QPS

很多团队把 QPS 当唯一北极星，在大模型对话里频繁翻车。原因很简单：QPS 只刻画了"量"，刻画不了"质"。一个高并发但 TTFT 高达 8 秒的平台，用户体验是灾难；一个 50 万 QPS 但首字 300ms 的平台，反而口碑更好。所以必须建立一组多维互补的指标，分别盯住量、快、稳、省四个维度。少任何一个维度，都会在某些场景下瞎眼。

四个维度的核心指标

维度一：量（Capacity）

量的指标回答"系统能扛多少"。

业务 QPS，每秒用户发起的对话请求数（1.1 节定义的业务层口径），这是产品承诺给用户的容量上限。并发连接数，同时挂着的活跃长连接数，在流式场景下它比 QPS 更能反映网关真实压力——同样是 10 万业务 QPS，每条连接平均驻留 1 秒还是 30 秒，网关承压完全不同。推理吞吐，推理集群每秒产出的 token 数或完成的请求数，这是 GPU 成本和调度效率的真实写照，也是采购 GPU 时唯一该参考的口径。还有一个常被忽略但极关键的——峰值倍数，峰值 QPS 与日均 QPS 的比值。大模型对话有明显早晚高峰，峰值倍数经常到 5 到 10，直接决定要不要为峰值预留大量闲置算力。一个日均 10 万 QPS、峰值倍数 8 的产品，得按 80 万 QPS 配容量，其中 7/8 大部分时间闲置——这是成本测算的关键变量。

维度二：快（Latency）

快的指标回答"用户等多久"，是体验的生命线。大模型对话的延迟必须分阶段度量，笼统的"平均延迟"会掩盖所有问题。

TTFT（Time To First Token，首字延迟），从用户发送到看到第一个字的时间。这是体验的分水岭，我自己的经验阈值是：TTFT 超过 1.5 秒，用户开始觉得"卡"；超过 3 秒，开始流失；超过 5 秒，基本等同于不可用。TTFT 主要由两部分决定——请求在推理队列里排队等了多久（Queue Time），以及 prefill 阶段把上下文过一遍花了多久。所以 TTFT 异常升高时，第一嫌疑犯永远是队列堆积，其次才是 prefill 慢。

TPOT（Time Per Output Token，每 token 延迟），流式输出过程中相邻两个 token 之间的平均间隔。它决定了"打字机效果"顺不顺滑，通常要控制在 50ms 以内，超过 100ms 用户会明显感觉一卡一卡。

E2E Latency（端到端延迟），从发送到完整响应结束的总时间，与生成长度强相关，单独看意义不大，但和 TTFT、TPOT 配合能算出"这次回答生成了多少 token"，是成本核算的依据。

实际排障时，我会用时间分解把一次请求拆成几段：网关与编排耗时（应该 < 100ms）、排队等待（健康时 < 200ms，恶化时能到数秒）、prefill（与上下文长度正相关）、decode 流式（TPOT × 生成长度）。哪一段异常一目了然，而不是笼统地说"今天慢了"。

维度三：稳（Availability）

稳的指标回答"会不会断、会不会错"。

可用性 SLO，比如 99.9%（三个九，全年宕机不超过 8.76 小时）、99.95%。大模型对话链路长、依赖多（网关、编排、推理、缓存、模型），达到三个九已经不容易，很多团队实际只敢承诺 99.5%。

错误率，要分类统计，不能笼统看一个数字。5xx 是真故障；429（限流）和 503（过载降级）是主动保护，性质完全不同。把 429/503 和 500 混在一起算"错误率"，会让"主动降级保命"被误判成"系统不稳定"，反过来逼迫团队不敢做必要的降级。

流式中断率，大模型对话特有的稳定性指标——流式响应中途断开的比例。这比直接报错更伤体验，因为用户已经看到一半内容了。网关超时配置不当、上游连接池耗尽、客户端网络抖动都会导致。健康值应该控制在 0.1% 以下。

降级服务比例，触发小模型兜底、缓存命中、关闭高阶功能等降级策略的请求占比。高可用的目标不是"永不降级"，而是"降级了用户也几乎无感"——比如一个请求本来要走旗舰模型，过载时降级到小模型，只要小模型质量够用，用户根本感知不到。这个比例监控好了，反而是系统能力的体现。

维度四：省（Cost）

省的指标回答"每服务一个请求烧多少钱"，这是高并发平台能不能商业可持续的关键，也是很多技术团队最不擅长的一面。

单请求成本，摊到每次对话的 GPU + 带宽 + 存储成本。每千次对话成本，更稳定的口径，便于跨周期对比（单请求成本波动大）。GPU 利用率，GPU 实际计算时间占比，利用率低意味着花了钱没干活，是成本浪费的首要信号——一个 GPU 利用率只有 30% 的集群，本质上你在为 70% 的闲置买单。缓存命中率，语义缓存、KV Cache 复用的命中比例，这是降本最直接的杠杆，第三章会详述。

这里有个反直觉的点：很多团队盯着"GPU 数量"做成本优化，觉得卡少就是省钱。但真正该盯的是"每千次对话成本"——如果你通过缓存和分流让单卡能服务更多请求，那么即使 GPU 总数没变，单请求成本也在下降。反之，业务量涨了 3 倍你加了 3 倍的卡，看似"按需扩容"，实际上单请求成本一点没降，你只是把低效放大了 3 倍。

SLO：把指标变成承诺

光有指标还不够，要把它们固化成 SLO——对外或对内的量化承诺。一个典型的高并发大模型对话平台 SLO 长这样：

• 业务 QPS 峰值 100 万，可持续 30 分钟；
• 并发连接 500 万（长连接驻留）；
• TTFT P99 ≤ 1.5s（含排队）；
• TPOT P99 ≤ 80ms；
• 可用性 ≥ 99.9%（月度）；
• 流式中断率 ≤ 0.1%；
• 单请求成本季度环比下降。

这里有个关键原则：SLO 要分用户视角和系统视角两层。 用户视角的 SLO（TTFT、可用性、中断率）是真正影响体验的，必须硬守，破了就是事故；系统视角的指标（GPU 利用率、缓存命中率）是手段，是帮助达成用户 SLO 的杠杆，不要本末倒置地把手段当目标。我见过团队为了"提升 GPU 利用率"这个系统指标，强行把 batch 开到很大，结果 TTFT P99 飙到 4 秒——利用率上去了，用户体验崩了，这是典型的本末倒置。

错误预算：SLO 的运营抓手

SLO 设定之后，会衍生出一个强大的运营工具——错误预算。逻辑很简单：

错误预算 = (1 − SLO 目标) × 总请求量
​

比如 SLO 99.9%、月度 100 亿请求，错误预算就是 0.1% × 100 亿 = 1000 万次"可以不达标"的额度。这个预算怎么用？

预算没耗尽时，可以放心做发布、上新功能、做一些有风险但收益大的变更（比如切新模型、调激进的路由策略），因为你有余量兜底。预算将耗尽时，进入保守模式，冻结高风险变更，优先稳定性。预算耗尽时，触发紧急止损，必要时主动降级保命，宁可牺牲部分功能也要守住核心 SLO。

错误预算把"稳定性 vs 迭代速度"这个永恒的拉锯，从口水战变成了可量化的权衡——这是百万级平台能持续演进而不崩盘的关键纪律。没有错误预算的团队，要么过度保守（不敢做任何变更，业务跑不动），要么过度激进（一个发布带崩全线），很难找到平衡点。

指标体系落地的顺序：可观测先行

最后强调一个容易被忽视的顺序问题：这套指标体系不是写在 wiki 里就完了，必须先有可观测能力，SLO 才不是空话。一个常见反模式是"先上架构、后补监控"，结果第一次大故障时两眼一抹黑，连 TTFT 是多少都不知道，复盘时只能靠猜。

正确的顺序是：接入层先埋点，网关记录每条请求的 TTFT、错误码、是否中断；推理层接 metrics，vLLM/TGI 的 /metrics 端点接进 Prometheus，拿到队列长度、tokens/s、显存占用；成本层单独建账，按会话、按模型把 GPU 时分摊到请求，形成单请求成本曲线；最后才是 SLO 看板与告警，把上述指标聚合成 SLO 看板，并对错误预算消耗速率设告警。

关于监控体系的深度搭建，本系列有一本专门的《Prometheus+Grafana 大模型推理监控体系》，本书只在这里强调"指标先行"的原则——架构可以慢慢迭代，但可观测必须第一天就有，否则你连自己做得好不好都不知道。

读完这一节，你应该能回答：为什么不能只盯 QPS？TTFT 和 TPOT 分别衡量什么、异常时第一嫌疑犯是谁？错误预算怎么用来平衡稳定和迭代？带着这些问题，下一节我们看三个真实的架构反模式，看传统 Web 套路具体怎么在大模型对话上翻车——那正是这套指标体系要防止的失败现场。