推理服务Token消耗追踪与监控

可视化演示

1. Token消耗基础：备料与成菜，分开记账

在AI食堂里，一道菜的成本从来不是铁板一块。客人点一份“智能问答”，后厨先要备料——把菜谱上的食材清单过一遍，这是输入Token；接着师傅动手炒菜，端上桌的成品菜才是输出Token。老王从不把备料和成菜的价钱混在一起算，因为两者的“工夫”不一样贵。

大模型推理服务的Token计量也是同样的道理。一次请求的输入Token由Prompt经过分词器切分而来，输出Token则是模型逐字生成的回复长度。这两类Token不仅来源不同，在计费时单价也往往相差数倍——输出Token通常更贵。因此，任何不做区分、只记一个“总Token数”的监控方案，都会让成本账面失真。

Token的计量粒度由分词器决定，同一个中文词在不同分词器下可能被切成1个或多个Token；更关键的是计量位置。应用层统计会因为缓存命中、请求重试、流式中断等原因和真实推理用量产生偏差，而网关层位于所有请求的必经之路上，在这里计量才能拿到“最接近账单”的数字。

老王把这套规则刻在前台的记账系统里：每一道菜，备料多少、成菜多少，分得清清楚楚。正是拜这种“分开记账”的执念所赐，月底他才能一眼看出哪位师傅的手艺最费食材——接下来的章节，我们就跟着老王的账本，看每一笔Token流水是怎么被记录、汇总和变成钱的。

2. 网关层日志采集：每道菜都要过前台

前台的点餐系统是AI食堂的咽喉。不管客人是搜索组还是客服部，不管点的是大厨的招牌菜还是街坊师傅的快手菜，订单都必须经过前台登记。小票上写着桌号、师傅编号、备料用量、成菜份量、出菜时刻——这就是一份元数据完整的“交易流水”。

在推理服务架构里，这个“前台”就是服务网关。实践中我们在网关的中间件里埋点，拦截每一次HTTP请求与响应，把租户ID、模型版本、输入Token数、输出Token数、响应耗时、时间戳等字段拼成一行结构化日志。相比在业务代码里打点，网关埋点不侵入应用、覆盖所有流量，是天然的计量点。

日志质量决定报表可信度。高并发下要防止日志丢失和写入抖动，通常先经内存队列缓冲再异步落盘；同时要监控日志完整率——如果丢了一部分请求的记录，统计出的成本就会偏低。完整率指标本身也要纳入告警，就像食堂绝不允许小票丢失。

老王给前台定了一条规矩：小票一张都不能少，哪怕是打烊前最后一桌客人。因为账本缺了一张小票，月底盘库存就会少算一份食材。日志完整率，就是AI食堂的“小票抽查”。

3. 用量统计方法：关店后的盘账功夫

每天打烊后，老王开始盘账：今天一共做了多少道菜？平均每桌吃多少食材？上周五为什么食材消耗突然翻倍？这些问题的答案藏在不同的统计口径里。

对应到推理服务，Token用量的统计至少有三个视角。累计视角：按时间窗口（小时/天）累加所有请求的Token，得到总量曲线；分布视角：计算单请求Token的均值、P50/P95/P99，捕捉“少数大请求吃掉多数Token”的长尾现象；异常视角：对窗口总量做同比、环比，突增或骤降都值得排查——突增可能是有泄漏流量的调用方，骤降可能代表服务故障。

窗口的选择也很讲究。窗口太短（秒级）噪声大，太长（月度）又会掩盖峰值。实践中常用多级窗口：原始明细保留7天，小时级聚合保留30天，天级聚合长期保存，既控制存储成本，又能随时下钻。

老王的盘账口诀是“先总量、再分布、后异常”。总量告诉他生意规模，分布告诉他谁是大胃王，异常告诉他哪天出了岔子。三招用全，账本才有灵魂。

4. 性能指标关联：光看用量不够，还要看病灶

老王渐渐发现，光盯食材消耗还不够。同样的食材，隔壁酒楼翻台快、上菜快，利润就高；自家后厨如果高峰期灶台全满、出菜龟速，再省食材也白搭。于是他把账本和前厅的出菜记录、后厨的忙碌状态贴在了一起。

推理服务的“翻台率”就是吞吐量，衡量指标是每秒处理的Token数（TPT）和每秒请求数（QPS）；“上菜速度”是时延——首次Token时延（TTFT）和总生成时延；“后厨忙碌程度”是GPU等资源利用率。把这些指标与Token消耗按时间对齐，就能回答三个问题：吞吐上去了，Token消耗是否同步增长？时延变高时，是不是某些超长输出请求在拖累？资源打满时，哪个模型的Token产出效率最差？

关联分析最常见的做法是将网关日志与性能指标按时间戳对齐到同一张宽表，然后做分组对比。例如按模型版本统计“每千Token耗时时延”和“每卡每秒产出Token”，这两个比值直接反映钱花得值不值。

老王在吧台挂了块白板，左边是食材消耗曲线，右边是翻台率和出菜速度，中间用线连起来。哪个环节堵了、哪道菜拖慢了全店，一眼便知。性能指标与Token消耗的关联，就是这块“连起来”的白板。

5. 成本报表生成：月底的算账时刻

月底是老王最紧张也最期待的时刻。他把全月的食材账本翻出来，乘以各自的单价，算出每位师傅、每个包间各花了多少钱。菜价不是一刀切——备料便宜、成菜贵，不同师傅的工时费也不同。

Token计费同理，需要给输入和输出Token分别设定单价（供应商通常按百万Token计价）。单次请求成本 = 输入Token×输入单价 + 输出Token×输出单价。以此为基础，按租户分组得到“哪个部门烧钱”，按模型分组得到“哪个模型烧钱”，再叠加时间维度就是成本趋势。报表还要做环比和预算对比，超出预算线的租户要自动标红。

生成报表时要注意“计价口径”的一致性：是网关记录的用量还是应用上报的数量？是否扣除缓存命中的部分？口径不一致的报表会让财务部门抓狂，所以报表血缘要清晰：每一分钱都能追溯到具体请求ID。

老王把账本摊在桌上，每一行都给包间和师傅标了价。老板只看一眼就知道：翻译业务用大厨纯属杀鸡用牛刀，客服业务该让街坊师傅多接单。成本报表的终极价值，不是算出花了多少钱，而是决定明天怎么省钱。

6. 模型版本分析：给师傅们排座次

食堂里三位师傅各怀绝技：大厨用料猛但翻台快，街坊师傅便宜但点的人多，快手师傅胜在稳定。老王想搞清楚到底谁在大量消耗食材、谁在创造利润，于是给每位师傅单独立了一本账。

推理平台做模型版本分析时，同样要为每个模型版本单独核算：累计Token消耗、累计成本、平均单请求成本、P99请求成本。再结合请求来源（租户×场景），生成“场景画像”——哪个业务在用大模型处理短文本？哪个业务在生成长文档？画像清晰后，成本热点无所遁形：可能5%的调用方消耗了80%的Token。

版本成本占比是最直观的排座次指标，分子是该版本成本，分母是全部版本成本之和。配合单位成本（每千Token成本、每请求成本）和性能指标（每千Token时延），就能评估一个版本的“性价比”。新版模型上线前，先跑一遍成本对比试验，用数据决定是否全量替换。

三个月后，老王终于敢在股东面前拍胸脯：大厨虽然贵，但招牌菜撑起了门面；街坊师傅是利润奶牛；快手师傅可以考虑换成更便宜的学徒。给模型版本排座次，就是用数据把“感觉”变成“决策”。

7. 容量规划优化：备菜的艺术

AI食堂最怕的不是客人多，而是高峰期灶台不够、食材备少了。老王慢慢学会了备菜的艺术：根据上周客流量预测下周备货量，给每种食材设一道红线，快烧到红线就提前采购、调整窗口安排。

推理平台的容量规划同理：基于历史Token消耗趋势，预测未来周期（下周/下月）的用量与成本。预测值逼近预算上限时触发预警，运营同学据此决定：是否扩容GPU集群、是否把部分流量降级到更便宜的模型、是否开启上下文缓存复用。Token消耗追踪为这些决策提供了唯一的依据——没有准确的账本，扩容就是拍脑袋。

预测模型不必复杂，按天粒度回归日平均消耗、乘以未来天数即可得到粗略预算；更精细的做法是按小时×星期做季节性预测。预测结果要与实际对比，持续回填校准，误差收敛后再用于自动化扩缩容。

老王把食材红线贴在后厨门口，每周一更新。红线亮红灯的那周，他会提前加订食材、把部分菜单的份量调小。推理平台的预算预警，就是这盏红灯——让成本从“事后心疼”变成“事前规划”。

AI 应用场景

Python 演示

#!/usr/bin/env python3"""推理网关 Token 消耗追踪与成本报表示例"""import jsonfrom collections import defaultdict INPUT_PRICE = 2e-6     # 每输入 token 单价（元）OUTPUT_PRICE = 8e-6    # 每输出 token 单价（元） SAMPLE_LOGS = [    {"req_id": "a01", "tenant": "搜索组", "model": "gpt-4o", "prompt_tokens": 320, "completion_tokens": 180},    {"req_id": "a02", "tenant": "客服组", "model": "deepseek-v3", "prompt_tokens": 150, "completion_tokens": 90},    {"req_id": "a03", "tenant": "搜索组", "model": "gpt-4o", "prompt_tokens": 600, "completion_tokens": 420},    {"req_id": "a04", "tenant": "推荐组", "model": "qwen-max", "prompt_tokens": 80, "completion_tokens": 40},    {"req_id": "a05", "tenant": "客服组", "model": "deepseek-v3", "prompt_tokens": 220, "completion_tokens": 310},]  def load_logs(path=None):    if path:        with open(path, encoding="utf-8") as f:            return [json.loads(line) for line in f if line.strip()]    return SAMPLE_LOGS  def request_cost(record, in_price=INPUT_PRICE, out_price=OUTPUT_PRICE):    return record["prompt_tokens"] * in_price + record["completion_tokens"] * out_price  def build_report(logs):    by_model = defaultdict(lambda: {"requests": 0, "in_tok": 0, "out_tok": 0, "cost": 0.0})    by_tenant = defaultdict(lambda: {"requests": 0, "in_tok": 0, "out_tok": 0, "cost": 0.0})    for rec in logs:        cost = request_cost(rec)        for bucket in (by_model[rec["model"]], by_tenant[rec["tenant"]]):            bucket["requests"] += 1            bucket["in_tok"] += rec["prompt_tokens"]            bucket["out_tok"] += rec["completion_tokens"]            bucket["cost"] += cost    return by_model, by_tenant  def print_report(buckets, title):    print("== " + title + " ==")    total_cost = 0.0    for key, v in sorted(buckets.items(), key=lambda kv: -kv[1]["cost"]):        total_cost += v["cost"]        print(f"{key:<12} 请求{v['requests']:>3} | 输入{v['in_tok']:>6} | "              f"输出{v['out_tok']:>6} | 成本{v['cost']:.4f}元")    print(f"{'合计':<12} 成本{total_cost:.4f}元")    print()  if __name__ == "__main__":    logs = load_logs()    by_model, by_tenant = build_report(logs)    print_report(by_model, "按模型版本")    print_report(by_tenant, "按租户")

1. from collections import defaultdict给统计桶“自动初始化”的能力，首次访问某个模型或租户时无需判断键是否存在。
2. def request_cost(record, in_price=INPUT_PRICE, out_price=OUTPUT_PRICE):把“输入×输入单价+输出×输出单价”封装成唯一的计费函数，保证全局口径一致。
3. for bucket in (by_model[rec["model"]], by_tenant[rec["tenant"]]):一行代码让同一条日志同时进入模型和租户两个账本，避免重复遍历。
4. bucket["cost"] += cost累计成本，所有聚合字段都在这里增长。
5. sorted(buckets.items(), key=lambda kv: -kv[1]["cost"])按成本从高到低排序，最烧钱的模型或租户排在最前面。
6. if __name__ == "__main__":脚本既可独立运行，也可以被其他模块导入复用。

常见误区

面试题