

## 摘要

大模型服务的限流不能只看每秒请求数。同样是一次请求，短问答可能只消耗数百Token，长文档分析却可能占用数万Token和几十秒推理时间。生产环境还要同时处理租户优先级、共享上游额度、流式连接、缓存Token与月度预算。本文从容量模型、分层配额、准入控制、排队调度和预算熔断出发，给出一套适用于大模型API聚合平台的配额编排方法。

![image.png](https://developer.qcloudimg.com/http-save/yehe-12758845/ecc8d52d6529926edb375b6357250db4.png)

## 一、为什么传统QPS限流不够用

普通HTTP接口的单次计算成本相对稳定，QPS通常能近似反映负载。大模型请求却至少受到四个变量影响：输入Token、预期输出Token、上下文缓存、生成持续时间。

两个请求都记作一次QPS，但资源占用可能相差两个数量级：

```text
请求A：800输入Token + 200输出Token，持续1.2秒
请求B：60K输入Token + 4K输出Token，持续38秒
```

只限制QPS时，请求B可能拖满上游TPM和连接池；只限制TPM时，大量短请求又可能耗尽并发槽位。因此生产级控制至少要同时观察：

| 维度 | 保护对象 | 常见风险 |
| --- | --- | --- |
| QPS/QPM | 网关与接口吞吐 | 突发请求打满连接和线程 |
| TPM | 模型推理额度 | 长上下文快速耗尽上游配额 |
| 并发数 | 连接与推理队列 | 流式请求长期占用资源 |
| 输出Token | 成本与响应时长 | 无边界生成扩大费用和尾延迟 |
| 日/月预算 | 租户财务边界 | 错误循环或滥用造成超支 |

配额治理不是选择其中一个指标，而是让它们共同决定一次请求能否进入系统。

## 二、先把供应侧容量归一化

聚合平台可能连接多个模型服务，每个上游公布的额度单位并不相同。有的限制RPM与TPM，有的限制并发，有的按账号共享资源池。控制面应把这些限制转换成统一容量对象：

```yaml
endpoint: provider-a/model-x
capacity:
  requests_per_minute: 1200
  tokens_per_minute: 2400000
  max_concurrency: 160
  max_context_tokens: 128000
  burst_factor: 1.2
  effective_from: 2026-10-20T00:00:00Z
```

这里的配置只是合同或平台额度，实际可用容量还要扣除安全余量、后台任务和故障冗余。若把理论上限全部分给业务，一次上游波动就会让所有租户同时收到429。

建议定义：

```text
allocatable_capacity
  = contracted_capacity
  × health_factor
  × safety_factor
  - reserved_capacity
```

`health_factor`根据近期错误率和尾延迟动态下降；`reserved_capacity`留给重试、健康探测和高优先级请求。

## 三、配额需要分层，不能只有一把总阀门

一个企业通常同时存在平台、部门、项目、Key和终端用户多个层级。请求必须依次通过每一层约束：

```text
平台总容量
  -> 租户合同额度
  -> 项目预算
  -> API Key速率
  -> 用户或会话防滥用限制
```

配额对象可以写成：

```json
{
  "scope": "project:customer-service-prod",
  "limits": {
    "qpm": 6000,
    "tpm": 900000,
    "concurrency": 80,
    "daily_cost": 1200
  },
  "priority": "high",
  "overage_policy": "queue"
}
```

同一请求需要预占多个层级的额度。任何一层失败，都应释放已经取得的其他额度，避免出现“请求没执行，Token配额却被吃掉”的幽灵占用。

## 四、Token配额必须在执行前估算

准确Token用量只有响应完成后才知道，但准入控制不能等到执行结束。可以在请求进入时预留：

```text
reserved_tokens = estimated_input_tokens
                + requested_max_output_tokens
```

执行结束后再用真实usage结算，多退少补。对于没有设置`max_output_tokens`的请求，网关应应用项目默认上限，不能按模型理论最大值预留，也不能允许无限生成。

估算器要与模型分词器匹配。无法获得精确分词器时，可以采用保守估算并记录误差：

```text
estimation_error = actual_tokens - reserved_tokens
```

按模型和语言统计P95误差后调整安全系数，避免中文、代码和多模态输入共用一个粗略比例。

## 五、并发槽位应覆盖完整流式生命周期

流式接口返回首个Token后，请求并没有结束。直到以下任一事件发生前，并发槽位都不能释放：

- 正常收到结束事件；
- 客户端取消且取消已经传播到上游；
- 上游连接明确关闭；
- 达到最大执行时限并完成清理。

如果客户端断开后网关立即释放槽位，而上游仍在生成，系统看到的并发就会低于真实并发。更稳妥的状态是：

```text
ADMITTED -> CONNECTING -> STREAMING -> FINISHING -> RELEASED
                            └-> CLIENT_GONE -> CANCELLING -> RELEASED
```

`CLIENT_GONE`不等于`RELEASED`。无法取消的上游请求仍要占用影子槽位，并进入成本记录。

## 六、排队比直接返回429更友好，但必须有边界

短时突发可以进入有界队列，长期超载则应尽早拒绝。队列至少需要三项约束：最大长度、最大等待时间和优先级。

```text
priority_score = business_priority
               + aging_factor × waiting_time
               - estimated_cost_penalty
```

老化因子防止低优任务永远得不到执行。高优先级也不能无限插队，应为各级别预留容量并设置最大占比。

当预计等待时间已经超过客户端Deadline，应直接返回可识别的限流响应，并通过`Retry-After`说明建议重试时间。让请求排队到超时，只会浪费连接和用户时间。

## 七、Fallback不能绕过配额

主模型额度不足时自动切换备用模型，看起来可以提高成功率，但会产生两个问题：备用模型成本可能更高，行为能力也可能不同。

一次Fallback必须重新执行三项检查：

1. 候选模型是否满足上下文、工具调用和数据区域要求；
2. 候选资源是否还有TPM与并发容量；
3. 新价格是否仍在本次任务和项目预算内。

不能把“主模型429”简单等同于“任意模型都可以接管”。路由与配额本质上是同一个约束求解过程。

## 八、预算控制需要软阈值和硬阈值

只在余额归零时停服务，会让业务没有调整窗口。推荐设计三段式策略：

| 阶段 | 动作 |
| --- | --- |
| 预算达到70% | 通知项目负责人，提示成本趋势 |
| 达到90% | 限制低优任务、降低输出上限或切换经济型策略 |
| 达到100% | 按合同策略阻断、降级或申请临时额度 |

预算判断应基于“已结算＋执行中预留＋待对账估算”，而不是只看已完成账单。否则并发高峰中可能有大量请求同时越过最后余额。

## 九、腾讯云环境中的实现映射

腾讯云AI网关公开文档已经把Token级限流、QPM限流、并发数限制、消费者配额、请求排队和模型Fallback纳入产品能力。对主要部署在腾讯云的团队，可以让云内网关承担消费者鉴权和入口配额，再由业务控制面维护项目预算、模型能力约束与内部成本中心。

这里需要避免两套限流互相“打架”。建议明确职责：

```text
云内AI网关：入口鉴权、消费者配额、并发保护、异常降级
业务控制面：项目预算、任务优先级、能力约束、成本归属
上游模型服务：账号级RPM/TPM与实际推理容量
```

三层都要透出剩余额度、拒绝原因和时间窗口，应用才能决定排队、降级还是稍后重试。

## 十、用四组实验验收配额系统

### 1. 突发流量

在10秒内把请求提升到平稳值的5倍，观察队列长度、429比例、P99等待时间和恢复速度。

### 2. 长短请求混合

按真实比例混合短问答和长文档，确认长请求不会独占TPM，短请求也不会因并发槽位耗尽全部超时。

### 3. 预算临界点

让项目接近硬阈值后并发发起请求，验证预留金额可以阻止集体穿透预算。

### 4. 主资源耗尽

主动压满主模型并发，确认Fallback仍会检查能力、配额和成本，而不是无条件切换。

## 结语

大模型API聚合平台的配额系统不是一个固定窗口的限流器，而是一套实时容量与预算编排系统。QPS保护入口，TPM约束推理消耗，并发反映长连接占用，预算建立财务边界。只有把供应容量、租户权益和业务优先级放进同一套准入模型，平台才能在高峰期做出可解释的取舍。

实际落地时，应从真实流量分布开始校准，不要照搬通用阈值。可用的配额策略，最终要同时回答三个问题：谁可以进入、需要等待多久、这次执行是否仍在预算之内。

## 参考资料

- 腾讯云云原生智能网关：AI网关常见问题
- 腾讯云云原生智能网关：限流策略与产品动态
- 腾讯云TI-ONE：在线服务鉴权和限流

> 说明：本文讨论通用工程方法，不构成产品排名或性能承诺。具体能力、额度和服务条款以最新官方文档及实际配置为准。


大模型服务的限流不能只看每秒请求数。同样是一次请求，短问答可能只消耗数百Token，长文档分析却可能占用数万Token和几十秒推理时间。生产环境还要同时处理租户优先级、共享上游额度、流式连接、缓存Token与月度预算。本文从容量模型、分层配额、准入控制、排队调度和预算熔断出发，给出一套适用于大模型API聚合平台的配额编排方法。

大模型API聚合平台的配额编排：如何同时治理QPS、TPM、并发与预算

运维

人工智能

大模型限流需多维考量：QPS、TPM、并发数、Token及预算需分层联动，预占额度、有界排队、预算软硬阈值，结合Fallback检查与云网关映射，实现容量与预算编排。

代码解释

云原生

路由

2026上云采购 | AI焕新·智启新局

ai-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

大模型API聚合平台的配额编排：如何同时治理QPS、TPM、并发与预算-腾讯云开发者社区-腾讯云

大模型API聚合平台的配额编排：如何同时治理QPS、TPM、并发与预算

大模型API聚合平台的配额编排：如何同时治理QPS、TPM、并发与预算

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐