一、项目背景

限流这事，单看 QPS 是远远不够的。我们接的一家客户，网关最早只按 QPS 限流，配置简单、大家也习惯。但上了大模型后问题暴露了：有些调用方 QPS 不高，单个请求却带几万 token，把整张卡的算力悄悄吃满；另一些调用方 QPS 很高，可都是几 token 的小请求，按 QPS 限流反而把它们误伤。

结果就是，单维度限流要么压不住大请求、要么错杀小请求，运维天天在"限多了业务投诉、限少了资源爆"之间反复横跳。我们进场时，他们的限流规则已经改得七零八落，谁也说不清哪条在起作用，新来的同事更是不敢动。规则乱到连他们自己都怕，有次误删一条才让核心业务缓过劲，从此没人敢乱动。

我们要做的是把限流从单维度升级到 QPS 加 Token 双维度联合计量，让配额真正反映算力占用。这件事的本质，是把"算力代价"这个隐性指标显性化。

二、落地场景

场景分三层。计量层同时统计每个调用方的 QPS 和 Token 吞吐，两个指标都进配额账本。联合层按设定的权重把两者换算成一个综合占用，超过联合配额的请求进入排队或拒绝。

突发层给一定弹性余量，允许短时间的超额，避免正常尖峰被误杀。熔断层在综合占用持续超阈时分级触发，先降级非核心调用方，再保核心业务。

管控台把每个调用方的双维度占用可视化，让负责人一眼看到到底是 QPS 高还是 Token 高，不再拍脑袋。我们还按业务等级给调用方打了标签，熔断时据此排序，避免一刀切。标签这步看似多余，却在一次大促保核心时省了我们半小时的扯皮。

三、关键技术挑战与解决思路

首个难点是双维度的权重。QPS 和 Token 量纲不同，直接相加没意义。我们按历史算力占比把 Token 折算成等效请求数，再和 QPS 合并。早期权重是拍脑袋定的，结果大请求还是能钻空子，后来用真实算力回归才把权重调准。这一步是整个方案的地基，错了后面全偏，所以我们拿了一个月的真实推理数据做回归才定稿。

另一个难点是突发弹性的度。完全刚性会误杀正常尖峰，完全放开又会被打爆。我们设了一个短时弹性窗口，允许超额但累计回收，超窗口的部分才真正拒绝。调这个窗口我们看了好几天的真实流量曲线，还专门挑了大促回放验证，确保正常尖峰存活、异常洪峰被拦。

再一个难点是分级熔断不误伤核心。熔断触发时不能一刀切，我们按业务等级排序，先砍低优先级调用方，核心交易链路最后保。这里要和业务方对齐等级，否则谁都觉得自己是核心，规则落地时会处处受阻，我们为此开了两次对齐会才定下等级表。等级表定下来后，业务方反而比我们紧张，生怕自己被排到后面，主动把低优任务清理了一批。

第四个难点是可视化对齐。双维度出来后，如果负责人看不懂，规则还是会被乱改。我们做了占用拆解图，把每条超限原因标清楚是 QPS 还是 Token，沟通成本一下降了，超标的人自己就来沟通扩容。

案例片段（已脱敏）： QPS 与 Token 联合限流的配置（参数为示意值）：yaml rate_limit:  dimensions: ["qps", "token_throughput"]  token_to_qps_weight: 0.0008  quota: {per_client_qps: 200, per_client_token_per_min: 200000}  joint: {combined_cap: 1.0, burst_window_sec: 10, burst_allow_ratio: 0.2}  circuit_break:    trigger_joint_ratio: 1.3    degrade_order: ["low", "mid", "high"]

四、效果数据

上线后的数据（均为示意值，非审计口径）。算力占用均衡度明显改善，之前那种"小 QPS 大 Token 偷偷吃满卡"的情况基本消失，因为 Token 维度把它显性化了。限流命中准确率提升，误伤率从之前的约百分之八降到百分之二以内。

突发生存率保持在九成以上，正常尖峰不再被误杀。核心业务在熔断时始终在线，没有再出现一刀切把交易链路一起砍的事故。熔断降级那天正好撞上大促预热，我们盯着看板，核心链路纹丝不动，几个低优任务被悄悄砍了没人察觉。

最有价值的是治理话语权变了：以前限流是运维背锅，现在每个调用方能在看板上看到自己的双维度占用，超标的人自己就来沟通扩容，扯皮少了一大半，运维终于不用当坏人了。我们还把限流事件和调用方标签做了关联告警，谁触发熔断、占了多少联合配额，告警里写得明明白白，值班同学不用再翻三张表拼因果，平均定位时间从二十分钟压到了三分钟以内。

五、可复用经验总结

单维度限流在大模型场景天然失效，因为请求的算力代价差异太大。我们这个项目最核心的认知，就是把 Token 当成和 QPS 同等重要的计量维度，这一改让很多说不清的限流事故有了根因。

权重别拍脑袋，要用真实算力占比回归，否则大请求照样钻空子。突发弹性必须给，但要有回收机制，不能变成无限宽松，否则弹性就成了漏洞。

分级熔断要让业务方先对齐等级，否则谁都觉得自己核心，规则落地时会处处受阻。可视化不是锦上添花，而是让限流从"运维管制"变成"各方自省"的关键，因为看得见才愿意改。

后来新客户接入网关，双维度限流成了默认勾选项，直接套模板，只调权重和配额。治理类能力，往往赢在把隐性代价显性化，而不是在事故后救火。