1. 为什么你的 token 账单总是超预期先说一个我踩过的坑有次帮朋友排查一个客服机器人单次对话看着不长账单却比预估高了四倍。翻日志才发现每轮请求都把前面十几轮的历史消息原样带上输入 token 像滚雪球一样涨。这就是 token 消耗失控最典型的样子——不是单价贵是结构浪费。Token 是大模型拆分文本的最小单位。中文大致 1 个汉字对应 1 到 1.3 个 token英文一个单词约 1 个 token标点、空格、换行、代码缩进同样计费。计费分输入和输出两部分输入是你发过去的提问、文档、历史上下文输出是模型生成的内容两边都单独算钱。很多人只盯着输出其实输入才是大头尤其是长上下文场景。开发者日常调用 API 时token 消耗过快通常来自三个角度请求结构层面system prompt 写得又长又啰嗦每次请求都重复发送few-shot 示例塞了七八条实际两条就够工具定义、JSON schema 描述冗长占掉大量输入额度。上下文长度层面多轮对话不做裁剪历史消息无限累积把整篇文档一次性投喂不做分段检索增强时召回一堆低相关片段模型被迫读一堆废话。缓存复用层面固定不变的 system prompt 和示例没有利用上下文缓存每次都按全价计费相同的前缀请求没有做去重重复付费。这三个角度对应三类可量化的节省手段。下面我会先讲怎么用统一 Key 把用量看清楚再给出可复制的统计脚本和接入配置最后演示优化前后的消耗差异。适合正在用大模型 API 做应用、被账单困扰、想建立可量化节省习惯的开发者。2. TaoToken 统一 Key 前置准备与用量可视化要省钱第一步是能看见钱花在哪。如果每个模型供应商一个 Key、一个后台你根本没法横向对比哪个环节在漏。TaoToken 的思路是用一个统一 Key 接入多家模型用量集中在一个控制台里方便做归因。先做前置准备。打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册账号然后进控制台创建 API Key。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。创建后把 Key 存到环境变量里别硬编码进代码。export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api注意 Base URL 是 https://taotoken.net/api 不带任何查询参数。这是 OpenAI 兼容协议的入口绝大多数 SDK 只要改 base_url 和 api_key 就能切换过来。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里面有各语言 SDK 的示例。我建议先跑通一个最小请求确认 Key 和网络都正常再去做用量统计。用量可视化这块TaoToken 控制台会按 Key、按模型、按时间维度展示 token 消耗。但控制台是宏观的真正要定位浪费得在应用侧埋点。我的做法是在每次请求返回后把 usage 字段落库字段包括 prompt_tokens、completion_tokens、total_tokens再打上业务标签比如客服问答代码补全文档摘要。这样一周后你就能看出哪个业务线在烧钱。这里有个关键点很多 SDK 默认不返回 usage或者流式响应里 usage 在最后一个 chunk。你要显式开启。以 OpenAI Python SDK 为例非流式请求默认带 usage流式请求需要加stream_options{include_usage: True}。这个细节不注意你的统计就是空的。统一 Key 的另一个好处是模型切换成本低。你可以在配置里维护一个模型映射表简单任务走轻量模型复杂任务走旗舰模型改一个字段就行不用改代码逻辑。这为后面按任务选型省钱打下基础。3. 可复制的接入配置与用量统计脚本这一节给可直接粘贴的配置和脚本。先看统一接入的配置片段。如果你用 OpenAI 兼容的 SDK配置长这样{ base_url: https://taotoken.net/api, api_key: ${TAOTOKEN_API_KEY}, default_model: claude-sonnet-4-20250514, model_map: { light: gpt-4o-mini, standard: claude-sonnet-4-20250514, heavy: claude-opus-4-20250514 }, request_defaults: { temperature: 0.3, max_tokens: 1024, stream_options: { include_usage: true } } }如果你用 TOML 管理配置等价写法[taotoken] base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY default_model claude-sonnet-4-20250514 [taotoken.models] light gpt-4o-mini standard claude-sonnet-4-20250514 heavy claude-opus-4-20250514 [taotoken.defaults] temperature 0.3 max_tokens 1024 include_usage true三件套记牢Base URL 是 https://taotoken.net/api Key 从环境变量读Model ID 按任务档位选。任何接入问题先核对这三项。接下来是 token 用量统计脚本。这个脚本做两件事包装请求、记录 usage、按业务标签聚合。用 Python 写依赖 openai 库。import os import json import time from collections import defaultdict from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY], ) USAGE_LOG usage.jsonl def chat_with_usage(messages, model, tagdefault, **kwargs): start time.time() resp client.chat.completions.create( modelmodel, messagesmessages, **kwargs, ) latency time.time() - start usage resp.usage record { ts: int(time.time()), tag: tag, model: model, prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens, total_tokens: usage.total_tokens, latency_ms: int(latency * 1000), } with open(USAGE_LOG, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) return resp.choices[0].message.content def summarize_usage(pathUSAGE_LOG): agg defaultdict(lambda: {calls: 0, prompt: 0, completion: 0, total: 0}) with open(path, encodingutf-8) as f: for line in f: r json.loads(line) key (r[tag], r[model]) agg[key][calls] 1 agg[key][prompt] r[prompt_tokens] agg[key][completion] r[completion_tokens] agg[key][total] r[total_tokens] for (tag, model), v in sorted(agg.items(), keylambda x: -x[1][total]): print(f{tag:12s} {model:32s} calls{v[calls]:4d} fprompt{v[prompt]:8d} completion{v[completion]:8d} total{v[total]:8d}) if __name__ __main__: summarize_usage()跑起来后每次调用都会往 usage.jsonl 追加一行。summarize_usage 按业务标签和模型聚合你一眼就能看出哪个 tag 的 prompt token 占比异常高。我实测下来光是把 system prompt 从 800 token 压到 200 token某个客服场景的输入成本就降了六成。再给一个上下文裁剪的辅助函数控制多轮对话的历史长度def trim_history(messages, max_tokens2000, keep_systemTrue): 保留 system 和最近若干轮粗略按字符数估算 token。 system [m for m in messages if m[role] system] if keep_system else [] rest [m for m in messages if m[role] ! system] budget max_tokens kept [] for m in reversed(rest): cost len(m[content]) # 中文近似 1 字符 1 token保守估计 if budget - cost 0: break kept.append(m) budget - cost return system list(reversed(kept))这个函数不精确但足够用来做滑动窗口。生产环境建议用 tiktoken 之类的库精确计数或者直接用模型返回的 usage 反推。4. 验证请求与优化前后消耗对比配置和脚本就绪后先发一个最小请求验证链路通不通。from openai import OpenAI import os client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY], ) resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 用一句话解释什么是 token}], max_tokens100, ) print(resp.choices[0].message.content) print(usage:, resp.usage)如果返回正常内容且 usage 里 prompt_tokens、completion_tokens 都有值说明接入成功。这一步失败的话先看第 5 节的排错。接下来做对比实验。我设计了一个文档摘要任务同一篇 3000 字的技术文档分别用原始方式和优化方式处理记录 token 消耗。原始方式system prompt 写 600 字角色设定把整篇文档一次性塞进 user 消息要求详细总结分五段每段不少于 200 字。优化方式system prompt 压到 80 字文档按章节拆成 3 段分别摘要再合并要求每段摘要不超过 80 字只保留结论。用第 3 节的脚本跑结果大致是这样方案prompt_tokenscompletion_tokenstotal_tokens原始482011806000优化16503201970优化后总消耗降到原来的约三分之一。拆开看prompt 降幅最大因为去掉了冗长 system prompt 和一次性超长输入completion 也降了因为限制了输出篇幅。这个对比不是让你照搬数字而是让你建立每次改动都量化的习惯。再演示上下文裁剪的效果。模拟一个 10 轮对话每轮用户输入 50 字、助手回复 100 字。不做裁剪时第 10 轮的输入 token 约等于前 9 轮全部累积接近 1350 token用 trim_history 保留最近 3 轮后第 10 轮输入稳定在 450 token 左右。轮次越多差距越大。验证阶段的关键是每次只改一个变量记录 usage对比。别一次改五处否则你不知道哪处起了作用。5. 本篇常见错误排查接入和统计过程中几个报错反复出现我按真实错误信息整理。401 Unauthorized。最常见的原因是 Key 没读到或写错。检查环境变量是否在当前 shell 生效echo $TAOTOKEN_API_KEY看有没有值。如果用了 .env 文件确认加载顺序在 client 初始化之前。还有一种情况是 Key 复制时带了空格或换行重新复制一遍。local proxy failed / connection error。这类报错通常是 base_url 写错比如漏了/api或者多加了斜杠。正确写法是 https://taotoken.net/api 不要写成 https://taotoken.net/api/v1 或带其他路径。另外检查本机网络和 DNS确认能正常访问该域名。reading choices 相关报错。典型信息是Cannot read properties of undefined (reading choices)。这通常意味着响应体不是预期的结构可能是请求被拦截返回了错误页或者 SDK 版本和接口不兼容。先打印完整响应体看内容再核对 SDK 版本。用 curl 直接打一次接口排除 SDK 干扰curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d {model:gpt-4o-mini,messages:[{role:user,content:hi}],max_tokens:20}OAuth / 认证方式不匹配。如果你用的是 Claude Code 这类工具它可能默认走 Anthropic 的认证流程。接入时需要在配置里显式指定 Base URL、Key 和 Model ID 三件套。Claude Code 的配置参考 https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里面说明了如何把请求指向统一入口。Cline 的 MCP 配置、Codex 的 auth.json 同理核心都是这三项要对齐。usage 字段为空。流式请求没开 include_usage或者 SDK 版本太老不解析 usage。升级 SDK并在请求参数里加上stream_options{include_usage: True}。token 统计和账单对不上。统计脚本只记了成功请求重试、超时、被限流的请求可能也计费。另外不同模型的 tokenizer 不同同一段文本在不同模型下 token 数有差异。对账时以控制台为准脚本用于定位趋势。排错时记住一个原则先用 curl 验证接口再验证 SDK最后验证业务代码。逐层排除别一上来就怀疑业务逻辑。6. 把节省习惯固化下来省 token 不是一次性优化是持续习惯。我的做法是每周跑一次 summarize_usage看哪个 tag 的 prompt token 占比超过 70%就去审查那个业务的 system prompt 和上下文策略。另外给每个业务设一个 token 预算告警超了就停下来看日志。模型选型上把任务分成三档格式转换、简单分类、短文本润色走轻量模型常规问答、代码补全走标准模型复杂推理、长文档分析才上旗舰模型。这个映射表放在配置里改起来不碰代码。上下文缓存要主动用。固定不变的 system prompt 和 few-shot 示例放在请求最前面很多平台对相同前缀有缓存折扣。TaoToken 的模型对话入口在 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 可以先用它手动测几组 prompt观察不同写法下的 token 差异再固化到代码里。如果你长期做编码类任务或 Agent 开发调用频次高可以考虑 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 按套餐走比按量计费更可控。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 管理。最后给一个实用技巧在代码里加一个装饰器自动记录每次调用的 tag、model、token超过阈值就打印警告。这样你不用等账单出来才发现问题请求发出时就知道这次贵了。把统计脚本和裁剪函数接进你的请求封装层省 token 就从事后心疼变成事前控制。