2. 限流核心指标：QPS、TPS、并发数、吞吐量、延迟、熔断与降级的关系
在模型服务API的限流设计中，理解核心指标之间的区别与联系是制定有效策略的前提。QPS、TPS、并发数、吞吐量、延迟、熔断与降级并非孤立概念，它们共同构成了限流系统的可观测性与控制边界。本节将逐一拆解这些指标的定义、计算方式，并揭示它们之间的联动关系。
2.1 核心指标定义与对比
以下表格从定义、典型场景、计量单位三个维度对六个核心指标进行横向对比：
| 指标 | 定义 | 典型场景 | 单位 |
|---|---|---|---|
| QPS | 每秒查询数（Queries Per Second），衡量API接口被调用的频率 | 读密集型模型推理、文本生成请求 | 次/秒 |
| TPS | 每秒事务数（Transactions Per Second），衡量完整业务事务的处理能力 | 包含多次API调用的端到端业务流程 | 笔/秒 |
| 并发数 | 系统在同一时刻正在处理的请求数量 | 长连接推理、流式输出、WebSocket服务 | 个 |
| 吞吐量 | 单位时间内系统成功处理的请求总量 | 批量推理、数据管道处理 | 请求/秒 或 MB/秒 |
| 延迟 | 从请求发出到收到完整响应所消耗的时间 | 实时对话、在线翻译、语音识别 | 毫秒(ms) |
| 熔断与降级 | 熔断：主动切断故障链路；降级：牺牲非核心功能保障核心功能 | 模型过载、下游服务超时、资源耗尽 | 状态机（关闭/打开/半开） |
实践提示： 在模型服务API中，QPS与TPS的差异常被忽略。例如，一次文本生成请求可能包含1次推理查询（QPS=1），但若该请求需要经过认证、上下文组装、推理、后处理四个子步骤，则TPS=4。限流时需明确是针对QPS还是TPS。
2.2 指标间的数学关系与限流公式
限流策略的数学基础建立在利特尔法则（Little's Law）之上，该法则揭示了并发数、吞吐量与延迟之间的确定性关系：
并发数 = 吞吐量 × 平均延迟
其中：
- 并发数：系统同时处理的请求数量（单位：个）
- 吞吐量：单位时间完成的请求数（单位：请求/秒）
- 平均延迟：每个请求的平均处理时间（单位：秒）基于此公式，可以推导出限流场景下的关键约束：
- 当延迟固定时：吞吐量上限由并发数决定。例如，若平均延迟为200ms，最大并发数为100，则最大吞吐量为 100 / 0.2 = 500 请求/秒。
- 当吞吐量固定时：延迟会随并发数增加而线性增长。这是模型服务过载时延迟飙升的根本原因。
- 限流阈值设定：通常以QPS或并发数为限流维度，但必须同时监控延迟，避免出现“高QPS低延迟”的假象。
常见误区： 很多团队只关注QPS而忽略并发数。对于模型推理这类长耗时操作（如GPT类模型单次推理可能耗时1-5秒），即使QPS很低，并发数也可能迅速堆积导致内存溢出。务必同时设置并发数上限。
2.3 熔断与降级：限流的保护性扩展
限流是主动预防，熔断与降级是被动保护。三者构成完整的流量治理闭环：
- 限流：在请求到达前或到达时，直接拒绝超出阈值的请求，防止系统进入过载状态。
- 熔断：当错误率或延迟超过阈值时，自动切断对下游服务的调用，避免故障级联扩散。熔断器状态包括：关闭（正常）、打开（拒绝请求）、半开（试探恢复）。
- 降级：在系统压力过大时，主动关闭非核心功能（如日志记录、详细错误信息），释放资源保障核心推理链路。
以下SVG图展示了限流、熔断、降级在模型服务调用链中的协作关系：
2.4 指标联动：一个完整的限流决策链
在实际的模型服务API中，各指标并非独立监控，而是形成一条决策链。以下SVG图展示了从请求入站到限流决策的完整数据流：
2.5 指标选择与限流策略匹配
不同的模型服务场景应选择不同的核心指标作为限流依据：
| 模型服务类型 | 推荐限流指标 | 原因 |
|---|---|---|
| 短文本推理（如分类、抽取） | QPS | 请求处理时间短（<100ms），QPS能准确反映负载 |
| 长文本生成（如GPT对话） | 并发数 + 延迟 | 单次请求耗时数秒，并发堆积比QPS更危险 |
| 流式输出（SSE/WebSocket） | 并发数 + 吞吐量 | 连接保持时间长，需限制同时建立的连接数 |
| 批量推理（Batch Inference） | 吞吐量 + 延迟 | 关注单位时间处理的总请求量，而非瞬时QPS |
| 多模型级联服务 | TPS + 熔断 | 事务跨多个模型，任一环节故障需快速熔断 |
核心结论： 限流不是单一维度的数字游戏。QPS决定入口流量，并发数决定系统压力，延迟反映服务质量，熔断与降级提供安全网。一个健壮的限流系统必须同时监控这六个指标，并基于利特尔法则建立它们之间的联动阈值。下一节将深入讲解如何基于这些指标设计具体的限流算法。