AI网关

做数据平台和 AI 应用这么多年，我见过一个挺典型的现象：同一套限流降级配置，在银行跑得挺稳，搬到制造企业就天天误伤。问题不在技术选型，在于业务对\”停一下\”的容忍度完全不一样。限流降级从来不是一份通用参数，它是一次业务止损优先级的排序。银行的账务核心一旦被拖慢，代价会落到监管口径上，所以它宁可拒掉一

我在数据平台这条线上做交付和顾问十几年，见过太多\”功能清单很长、日活很低\”的项目。复盘的时候，团队大都会去查功能缺口、查培训覆盖率、查入口藏得深不深，很少有人去看另一件事：系统在最挤的那几分钟，是怎么对待员工的。限流和降级，在架构评审里通常被划到技术侧——网关加个令牌桶、接口加个并发数，评审就过了。

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

这行干了十来年，限流降级这类项目我评过的方案不下三十个，也亲手主导过两次迁移。有个现象一直没变：预算会上被反复讨论的那个数字，永远是软件许可加第一年服务费，而真正把项目拖到超支的支出，压根不在采购合同里。我按四年周期拆过账，采购价一般只占全周期支出的 15% 到 25%，剩下七成多散落在集成联调、规

限流降级这四个字，在方案 PPT 里永远只占一页纸，落到代码仓库里能长出三十几个待办。我做过十来个数据平台项目，从银行的数据中台到制造业的指标中心，每次上线前的压测评审，我都要把限流降级的方案从头翻一遍，翻完经常会发现同一个问题：大家把限流当算术题在解，把降级当框架题在做，唯独没人把它当业务题来想。

核心判断：限流降级的主战场，2026 年已经挪到数据侧2026 年我跟不少企业的技术负责人聊过同一个话题：限流降级这件事，十年前是网关上几行配置就能交差的活儿，现在变成了一条横跨接入层、服务层和数据层的工程问题。请求被放行，不代表系统扛得住，真正的压力最终都落在数据上。为什么变？因为流量的形状变了。

我干数据平台和系统稳定性这行有些年头了，限流降级这几个字听得多、写得多，真正做对的项目并不多。技术组件之间的差异其实很小，拉开差距的是判断力——什么时候该限、限谁、降到哪一步就收手。我见过不少团队一上来就堆中间件，网关挂个令牌桶，服务里塞个熔断器，架构图看着很稳，一到晚高峰该挂还是挂。问题不在工具，

限流降级这个词我最开始在交易系统里听，后来数据平台也开始讲，而且讲得比交易系统还热闹。热闹归热闹，账很少有人算。我接手过一个项目，平台上有六百多个数据接口，限流规则写了七百多条，我问团队这些规则怎么定出来的，回答是照着调用量排的。再问调用量前十的接口如果被限住，分别损失多少、影响谁，全场安静。这就是

这两年我接手过七八个跟大模型调用成本相关的活，最早一次是财务拿着供应商账单来问：这个月十万块的Token费，到底花在哪些部门、哪些应用上。技术团队给的回答是\”日志都在，就是没洗干净\”，财务要分摊，运维要稳定，两边对不上账。那一刻我就明白了，Token统计从来不是运维报表问题，而是数据治理问题。
我脑

我做大模型应用落地评估时，最常被问到的一句话是：“这个月 Token 到底花了多少，为什么和业务量对不上？”这个问题背后不是财务小题大做，而是企业开始把 AI 调用当作可计量、可归集、可治理的生产资源。Token 统计的概念，说白了就是把文本、代码、图片描述等输入，经过分词器切成词元，再按模型、应用