一、项目背景

某集团多个业务线共用一套大模型底座，但谁调了多少、花了多少钱没人说得清。月底算力账单是一笔糊涂账，业务线之间为分摊吵架，财务也没法核算到部门。我们进场时，底座团队自己都算不出上个月的真实调用成本，只能按人头粗分，业务线当然不认，觉得凭什么我用的少却摊这么多。

更糟的是没有配额约束，某条业务线半夜跑批任务把整池算力占满，白天其他业务线的实时推理直接被拖垮。这种互相踩踏发生过好几次，关系都搞僵了。我们意识到，问题不是算力不够，是没人管。

二、落地场景

我们围绕网关做了配额和计量两层治理。多租户配额管理是第一层，每个业务线、每个应用分配独立配额和限额，超限走降级或拒绝，避免一家猛调拖垮全场。按应用计量账单是第二层，每次调用都记录 token、耗时、费用，按部门、应用、用户三层沉淀，谁调的、调了什么、花多少一目了然。成本分摊规则放在计量之上，把底座总账按各租户的实际用量拆开，生成可核对的分摊单，业务线自己能验算。额度预警和闲置回收兜底，快超限时提前告警，长期闲置的配额回收复用，不让坑位空占。

案例片段（已脱敏）： 多租户配额与计量账单配置片段（示意）：gateway_quota:  tenant: [bizA, bizB, bizC]  limit_per_tenant: 5000000_tokens_day  meter:    dimensions: [dept, app, user]    record: [tokens, latency, cost]  cost_split: by_usage上线后计量准确率约 99.5%，成本分摊从粗分改为按用量，争议工单降了约七成。某业务线发现自己占了约四成调用却只认两成账，主动优化了闲置任务，整体算力成本约降了 18%。

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

第一个难点是计量准确性。网关每跳都要记，但异步链路容易漏。我们在网关入口统一埋点，任何一次模型调用都生成一条带 trace 的计量记录，落库前做幂等，重复上报不重复计费。这里踩过的亏是早期只在出口记，重试的请求被算成两次，账单虚高，业务线更不认了。自那以后我们定了个规矩：计量只在唯一入口记一次。

第二个难点是分摊规则的公平性。纯按 token 分对某些重推理业务不公平，我们引入权重，把延迟敏感型任务的资源占用也算进去，规则透明可查。规则得让各方能验算，否则还是吵架。我们把分摊公式直接开放给各业务线的技术负责人，他们自己拿调用记录一算就对得上，信任才建立起来。

第三个点是闲置回收。有些业务线申请了大配额但实际不用，占着坑。我们设了连续七天低水位自动回收，回收前发通知，避免误杀。这个阈值我们调过两次，太短会误收正在起量的业务，太长又回收不动，七天是折中。

四、效果数据

上线后计量准确率约 99.5%，成本分摊争议工单降约七成，整体算力成本约降 18%，闲置算力回收率约 25%。财务第一次能拿出各部门认可的分摊单，月底对账从扯皮变成走流程。我们复盘时发现，降本那 18% 里有一大半不是真省了算力，而是把闲置和浪费挤掉了，底座实际产出并没降。（数据均为脱敏示意值）

实践里还有个细节：配额不是设死就完事，要留弹性。我们给每个租户设了基础配额加突发配额，日常用基础，大促前临时提突发，活动结束自动回收，既保住公平又不耽误业务冲刺。计量数据我们也做了实时看板，各业务线的技术负责人每天能看见自己这边的消耗趋势，谁在浪费用量一眼就暴露，这种透明本身就是一种约束力。财务那侧拿到了可追溯的分摊明细，审计来查时直接导出就能对上，省了大量对账扯皮。把算力和钱当成同一件事管之后，团队对调用的态度明显谨慎了。

我们还在配额体系里加了一层优先级调度。核心业务的实时推理永远排在批处理任务前面，批处理任务看到核心业务有压力就自动让路或者排队。这个调度逻辑避免了半夜批任务把白天实时链路挤垮的老问题。我们也因此把算力看成一种需要编排的资源，而不是各业务线随便抢的池子。编排之后，整体算力的实际利用率反而比之前大家各用各的时候更高，约束带来了更好的全局效率。

把算力当钱管这件事，最难的不是技术实现，而是让所有使用方都接受这套透明的规则，这一点比写代码本身费劲得多，也是治理能不能落地的关键。

五、可复用经验总结

算力要当钱管，不把计量和分摊做细，业务线只会无脑猛调，月底账单出来谁都不认。计量埋点要在入口统一做且幂等，出口记容易算重。分摊规则要透明可验算，各方能自己核对才服气。闲置配额该收就收，设低水位自动回收加通知，别让坑位空占。我后来觉得，网关的配额治理本质是一道财务题，不是技术题。技术不难，难的是把规则定得让各方都认。