模型网关

做数据平台这些年，我的核心判断是：限流降级从来不是中间件团队一个人的技术活，它是业务优先级被翻译成代码之后的样子。七个案例我前后跟了六年，从主数据分发被打穿，到 AI 问数在经营分析会上排队超时，真正把系统放倒的原因，很少是\”流量太大\”这么笼统的说法。更多时候是某条没人盯的接口被下游轮询、某个报表任

我做过几个数据中台落地的项目，限流降级这件事，基本都不是在架构评审会上定下来的，而是在某次大促或者月底报表集中跑批的时候，被系统抖出来的。数据库连接池打满、数据服务接口 RT 从 200 毫秒飙到 8 秒、下游十几个系统连锁超时，这时候大家才开始问：到底该在哪一层限流，降级之后返回什么，谁来兜底。

我在数据平台这条线上摸爬了十来年，做过的故障复盘会少说也有上百场。一个很扎眼的规律是：限流降级这件事，栽跟头的团队犯的错高度重合——预案写在文档里，开关藏在代码里，演练排进\”明年再说\”。真出事那一刻，链路一崩到底，复盘会上大家把责任分一分，凑出十条整改项，三个月后同一个位置再崩一次。
所以我对这件事

做了十几年企业级系统的架构评审，我越来越确信一件事：限流降级不是\”加个开关\”，而是一整套贯穿流量入口、服务调用、数据访问的资源调度能力。很多团队在立项时把注意力全放在业务功能上，等到大促或者月末结算那天系统雪崩，才回头补这套机制，代价往往是几周的紧急重构加上一轮客户信任的损耗。我参与过的项目里，真正

我做过最小的数据项目，服务器一台，跑批脚本四个，谁也没提过限流这回事。后来团队从八个人涨到六十个，再到集团下辖二十多个业务单元，这件事就从不做也行，变成了不做就等着半夜被电话叫醒。规模一变，限流降级要解决的矛盾就换了：小团队防的是单点被压垮，大集团防的是资源被某个业务单元悄悄吃干净。很多团队把这事当

限流降级这件事，我前后跟过十几次大促保障，也帮不少团队做过事后复盘。真正让我意外的从来不是组件选型，而是同一个限流组件，在不同团队手里能跑出完全不同的结果。有的团队接的是同一套开源方案，配置项也差不多，一边全年没出过故障，另一边大促当天刚开始十分钟流量就冲穿了阈值，降级开关按下去以后业务直接不可用。

我粗略算过，过去几年接触过的限流降级项目里，能把第一轮流程完整走完、半年后阈值还在被修订的，不到一半。剩下的那些没死在技术上——熔断组件、网关限流这一套组件谁都会装，卡住的地方全在技术之外：没人能给接口分等级，没人说得出\”降到什么程度算可接受\”，也没人愿意在业务低峰期做一次真实的故障注入。
我的判断

做数据服务这些年，我处理过太多次和限流降级有关的告警。凌晨两点电话响，值班同学说订单查询接口超时率冲到三成，网关已经自动降级，让我赶紧定个阈值。我把链路翻一遍，会发现真正的问题往往不在网关：慢查询来自一个没走索引的宽表关联，而这个表的口径上个月刚被改过两次，改的人已经调岗。这事我踩过坑，所以现在接到

聊这个话题之前，我先给个判断：Token 统计本身是个技术活，但它跟现有系统对接，八成的坑不在技术，而在口径和归属。我做过几个把大模型调用量接进企业数据体系的项目，真正让项目卡住的，从来不是\”怎么把数字捞出来\”，而是\”这个数字算给谁、按什么规则算、谁来认这个账\”。
很多人一上来就问我用什么工具埋点、

做 AI 应用的人，迟早要面对一张账单。调用量上来之后，账单里最容易被质疑的就是 Token 那一行。我帮企业搭过几轮 AI 应用的数据底座，见过财务拿着账单来问技术负责人\”这三十万是怎么算出来的\”，也见过业务线反问\”凭什么这块算在我头上\”。多数时候问题不在模型，也不在单价，而在统计这件事从第一天就