日期:2026-08-03
平台内部多个部门共用一套 AI 网关,起初大家其乐融融。半年后问题来了:GPU 账单是一张总额,谁用了多少、哪个业务线在烧钱全靠拍脑袋;某部门上线了个"问答机器人"把预算吃光,别的部门推理被限速,互相甩锅。财务要分摊成本,运维要定位浪费,业务要证明自己"值"。但网关调用链路是黑盒,一笔 token 消耗根本追不到人。
我们落地了"调用血缘加租户成本分摊"。网关在每次调用时打上全链路 trace(请求 ID、租户、应用、用户、调用的模型、token 数、耗时、费用),汇成调用血缘图谱;按租户、应用、用户多维计量,月底自动出分摊账单并支持预算回收;同时把成本归因到具体场景,帮业务找到"贵在哪"。
第一个挑战是调用血缘的零丢失采集。我们在网关入口埋点,每请求生成 trace_id 并贯穿鉴权、路由、模型调用、计量全链路,异步落盘到时序库,不阻塞主流程。
案例片段(已脱敏): 计量与分摊配置(示意): metering: dimensions: [tenant, app, user, model] sample_rate: 1.0 cost_model: {model_a: 0.012/1k_tokens, model_b: 0.03/1k_tokens} billing: cycle: "monthly" allocate_by: "token_weighted" budget_reclaim: true
结果:某部门"闲聊机器人"占全月算力 38%,据此收缩后月省约 26%
第二个挑战是租户级计量的准确。多模型单价不同,我们按 token 加权加模型单价双维度计费,避免"便宜模型被滥用也算便宜"的失真。
第三个挑战是成本归因分摊的公平。我们按 token 加权分摊共享成本(如网关自身开销),并允许业务打"项目标签",把一笔大额调用归到具体项目而非笼统部门。
第四个挑战是账单回收闭环。出了账单还要能回收——超预算的租户自动限速并通知负责人,形成"用了要付、超了要限"的闭环。
调用血缘覆盖率达到约 99%;租户级计量准确率对账误差小于 0.5%;成本回收率(超预算回收或预警)从几乎为零提升到约 83%;归因时效从"月底人工两三天"降到实时看板。一次归因发现某机器人占全月算力 38%,收缩后月度算力开支下降约 26%。
第一,AI 成本治理先建调用血缘再谈分摊,没有 trace 一切都是估算。
第二,计量按"token 加权加模型单价"双维度,单维度会失真。
第三,账单要能回收才算闭环,超预算限速比事后催款有效得多。
第四,归因要落到项目标签而非笼统部门,业务才服气也才好优化。
调用血缘建起来之后,最意外的收获是治好了甩锅文化。过去某部门推理慢,第一反应是网关不行,现在打开看板,谁家哪个应用吃了多少 token、花了多少钱一目了然,优化责任自然落回业务自己头上。成本可视化本身就是一种治理。
第二个细节是计量准确性的对账。我们一开始按调用次数计费,结果发现同样次数下,有人跑长文本有人跑短文本,成本差好几倍,计费严重失真。改成 token 加权加模型单价双维度后,账单和财务的实际算力开支对账误差降到零点五个百分点以内,财务才认这套账。
第三是共享成本的分摊。网关自身开销、公共模型池这些共享部分,如果全摊给某一个部门不公平。我们按各租户的 token 占比做加权分摊,并允许业务给大额调用打项目标签,把成本归到具体项目,负责人一看就知道贵在哪、该砍哪。
再说预算回收闭环。出了账单如果不能回收,治理就停在知道了。我们设了超预算自动限速加通知负责人,某机器人占全月算力三成八就是被这个机制拦下来收缩的,当月算力开支直接降了两成六。用了要付、超了要限,这句话才算落地。
最后补充一个数据治理点:trace 的采样率看似小事,实则影响归因可信度。我们一开始为了省存储把采样率降到一成,结果小流量应用的成本被低估、分摊失真。后来关键维度全采、聚合指标降采样,既保了准确又控了成本,血缘的完整性是分摊公平的前提。
回顾网关调用血缘与成本分摊这个项目,最容易被低估的是最后一公里。技术方案跑通只是开头,真正决定成败的是上线后那几周:调用链采样率有没有保住关键维度、分摊有没有落到项目标签、超预算限速有没有真回收。我们见过太多项目栽在上线即交付的心态上,三个月后指标悄悄回潮。所以我们的做法一直是把上线当运营起点:血缘覆盖率看板、账单对账、预算回收演练、自动化巡检,四件套缺一不可。另一个体会是,成本治理先建血缘再谈分摊,没有调用链一切都是估算,可视化本身就是一种治理。以上是我们的一点体会,供同样做算力成本治理的团队参考。
成本治理跑起来后,最怕的是看板没人看。我们把它接进月度经营会,超预算的部门当场要说法,分摊才真正有约束力。可视化只是工具,让数据进决策流程才是目的。算力账单从一笔糊涂账变成可问责的账,靠的是这条闭环一直转。