1. 大模型 API 计费逻辑与成本焦虑的由来1.1 为什么大家都在盯着 Token 单价做 AI 应用开发的人最近一两年都有一个共同的体感模型能力越来越强但账单也越来越不敢看。尤其是把大模型接入到实际业务里之后很多人第一次收到月度账单时都会愣一下——明明只是做了个问答机器人怎么费用比服务器还贵。这背后的核心原因就是大模型的计费方式和我们熟悉的传统云服务完全不同。传统云服务按 CPU、内存、带宽、存储这些资源计费你大概能估算出一个月跑下来多少钱。但大模型 API 是按Token计费的而 Token 这个东西普通开发者一开始是没有直觉的。一段中文、一段英文、一段代码切出来的 Token 数量差异很大输入和输出的单价又不一样再加上上下文累积、多轮对话、系统提示词这些隐性消耗账单很容易失控。所以当听到Claude API 又降价了这类消息时很多人的第一反应不是兴奋而是想搞清楚到底降了多少我现在的用量换成新价格能省多少我该怎么算这篇文章就是围绕这个真实需求展开的我会把 Token 成本计算的完整逻辑、API 用量分析的实操方法以及一份可以直接跑的 Python 脚本全部讲清楚。不管你是刚接触大模型 API 的新手还是已经在跑生产环境的开发者都能从中拿到能直接用的东西。1.2 输入 Token 与输出 Token 的价差陷阱很多人算成本时最容易犯的一个错误就是把输入和输出当成一个价格来算。实际上几乎所有主流大模型 API 都对输入和输出分别定价而且输出通常比输入贵好几倍。以常见的定价结构为例输入可能是每百万 Token 几美元输出则可能是输入的 3 到 5 倍。这个差异在短对话里不明显但一旦你的应用涉及长文本生成、代码生成、报告撰写这类输出量大的场景输出成本就会成为账单的大头。我见过一个典型的案例有人做了个文章摘要扩写的工具输入是一篇 2000 字的文章输出是一篇 3000 字的扩写稿。他一开始只按输入字数估算成本结果实际账单是预估的三倍多。原因很简单输出的 3000 字 Token 数量本身就比输入多再加上输出单价更高双重叠加之下成本自然飙升。所以做成本计算的第一步必须把输入和输出拆开算分别乘以各自的单价最后再相加。这个逻辑听起来简单但真正落到脚本里需要你对 Token 的切分方式有基本理解。1.3 上下文累积带来的隐性开销还有一个更隐蔽的成本来源多轮对话中的上下文累积。大模型 API 本身是无状态的它不记得你上一句说了什么。所谓的多轮对话其实是每次请求都把之前所有的对话历史重新发一遍。这意味着第 10 轮对话的输入 Token包含了前 9 轮的全部内容。假设每轮对话平均 200 个 Token那么第 1 轮输入 200第 2 轮输入 400第 3 轮输入 600……到第 10 轮时输入已经累积到 2000。十轮下来总输入 Token 是 200400...2000等于 11000而不是简单以为的 2000。这就是为什么长对话应用的成本会呈平方级增长。理解了这一点你就能明白为什么控制上下文长度是成本优化的核心手段之一。很多团队会在对话轮数达到一定数量后主动做历史摘要或者截断把老的内容压缩成一段简短的摘要再带上这样既保留了上下文语义又大幅降低了 Token 消耗。2. Token 成本计算的核心原理与参数拆解2.1 Token 到底是什么从字符到子词的切分逻辑要算成本先得搞清楚 Token 是什么。简单说Token 是模型处理文本的最小单位但它不等于字符也不等于单词。主流模型使用的是子词切分算法比如 BPEByte Pair Encoding。它的思路是把常见的词或词根作为一个 Token把不常见的词拆成更小的片段。举个直观的例子英文单词 tokenization 可能会被切成 token 和 ization 两个 Token而 the 这种高频词就是一个 Token。中文的情况更特殊一个汉字通常对应 1 到 2 个 Token具体取决于模型的分词表。代码里的符号、空格、换行也都会占用 Token。这就解释了一个常见现象同样字数的中文和英文Token 数量可能差很多。一般来说英文大约 4 个字符对应 1 个 Token中文大约 1 到 1.5 个字符对应 1 个 Token。所以做成本预估时不能简单地按字数乘系数最好用真实的 Tokenizer 来数。提示不同模型的 Tokenizer 不一样同一个句子在不同模型下的 Token 数可能不同。做精确成本计算时一定要用目标模型对应的 Tokenizer而不是随便找个工具估算。2.2 单价结构输入、输出、缓存命中的三档定价现在主流 API 的定价通常分三档输入、输出、缓存命中。缓存命中是最近几年才普及的优化机制它的逻辑是如果你重复发送相同的前缀内容比如固定的系统提示词这部分内容可以被缓存再次使用时按更低的单价计费通常是正常输入价的十分之一左右。这个机制对成本优化的意义非常大。很多应用的系统提示词很长比如角色设定、输出格式要求、few-shot 示例动辄几千 Token。如果每次请求都全价计费成本会很高但如果这部分被缓存费用就能大幅下降。所以设计 API 调用时把固定不变的内容放在前面把变化的内容放在后面是一个很实用的技巧。下面这张表可以帮助你理解三档定价的典型关系计费类型相对单价适用场景优化手段输入未缓存1x每次请求的新内容精简提示词、控制上下文缓存命中约 0.1x重复的固定前缀固定内容前置、保持前缀稳定输出3x 到 5x模型生成的内容限制输出长度、明确格式要求需要说明的是具体倍数因模型和供应商而异这里给的是行业常见的量级关系实际以官方定价页为准。2.3 影响成本的五个关键变量把成本拆解到可操作的层面其实就五个变量在起作用输入 Token 数由提示词长度、上下文长度、附件内容决定输出 Token 数由任务类型和 max_tokens 设置决定输入单价由所选模型决定输出单价由所选模型决定缓存命中率由提示词结构和调用模式决定这五个变量里单价是你能选的换模型Token 数是你能控的改提示词、控上下文缓存命中率是你能优化的调结构。成本优化的所有手段本质上都是在动这几个变量。理解了这一点后面看脚本和实操就不会迷路。3. 用量分析实战从日志到成本报表3.1 数据来源API 返回的 usage 字段做用量分析第一步是拿到数据。好消息是主流大模型 API 的响应里都会带一个 usage 字段直接告诉你这次请求消耗了多少 Token。以常见的结构为例它通常包含输入 Token 数、输出 Token 数有些还会细分出缓存命中的 Token 数。这意味着你不需要自己去数 Token只要在每次调用后把 usage 记录下来就行。问题在于很多人的代码里根本没保存这个字段等想看账单时才发现无从下手。所以我的建议是从项目第一天起就把每次调用的 usage 连同时间戳、模型名、请求标识一起写进日志或数据库。这个习惯能帮你省下大量事后排查的时间。下面是一个典型的 usage 记录结构你可以照着设计自己的日志表{ timestamp: 2025-01-15T10:23:45Z, model: claude-sonnet, request_id: req_abc123, input_tokens: 1520, output_tokens: 380, cache_read_tokens: 1024, cache_write_tokens: 0, latency_ms: 2340 }有了这样的结构化记录后面做聚合分析、成本计算、异常排查都会非常方便。3.2 日志聚合按天、按模型、按业务线拆分拿到原始日志后下一步是聚合。聚合的维度取决于你想回答什么问题。常见的几个维度是按天看每日成本趋势发现异常波动按模型看不同模型的成本占比评估是否该换模型按业务线或功能看哪个功能最烧钱决定优化优先级按用户如果是多租户应用看哪些用户消耗最多我一般会先做按天和按模型的聚合这两个维度最能反映整体情况。如果发现某天成本突然翻倍再下钻到具体请求去查原因。常见的异常原因包括某个用户疯狂调用、某次请求上下文超长、某个功能输出了超长内容、或者代码里有个 bug 导致重复调用。聚合的实现用 Python 的 pandas 就很顺手几行代码就能把日志按维度分组求和。如果你不想引入 pandas用纯 Python 的字典累加也完全够用数据量不大的话性能没差别。3.3 成本换算把 Token 数变成真金白银聚合出 Token 数之后最后一步是换算成钱。这一步需要一张单价表把不同模型的输入、输出、缓存单价配置进去然后按公式计算成本 输入Token × 输入单价 输出Token × 输出单价 缓存Token × 缓存单价这里有个细节要注意单价通常是以每百万 Token为单位给出的所以计算时要除以 1,000,000。很多人第一次算的时候忘了这一步结果算出来的数字大得离谱还以为自己看错了。另外如果你的应用用了多个模型要分别计算再汇总。不同模型的单价差异可能很大混在一起算会掩盖问题。比如一个应用同时用了高配模型和轻量模型如果只看总成本你可能觉得还行但拆开一看发现高配模型占了 90% 的成本那优化方向就很明确了。4. 可运行脚本一份完整的 Token 成本分析工具4.1 脚本设计思路与目录结构说了这么多原理接下来上干货。我写了一份可以直接跑的 Python 脚本功能包括读取调用日志、按维度聚合、按单价表换算成本、输出报表。整个脚本不依赖任何第三方大模型 SDK只用标准库加 pandas方便你在任何环境里跑起来。脚本的设计思路是配置与逻辑分离单价表、日志路径、输出路径都放在配置区业务逻辑单独成函数。这样你换模型、换单价、换日志格式时只需要改配置不用动核心代码。目录结构建议这样组织token_cost_analyzer/ ├── config.py # 单价表与路径配置 ├── analyzer.py # 核心分析逻辑 ├── sample_log.jsonl # 示例日志 └── report_output.csv # 输出报表日志格式我用 JSONL每行一个 JSON 对象这是最通用的格式各种语言都能方便地写入。4.2 核心代码逐段解析先看配置部分。单价表用一个嵌套字典表示key 是模型名value 包含输入、输出、缓存三个单价单位是美元每百万 Token# config.py MODEL_PRICING { claude-sonnet: { input: 3.0, output: 15.0, cache_read: 0.3, cache_write: 3.75, }, claude-haiku: { input: 0.8, output: 4.0, cache_read: 0.08, cache_write: 1.0, }, } LOG_PATH sample_log.jsonl REPORT_PATH report_output.csv注意上面的单价是示例值实际使用时请替换成你所用模型的官方最新定价。单价会变动硬编码在代码里不是好习惯更好的做法是从配置文件或环境变量读取。接下来是读取日志和计算单条成本的函数# analyzer.py import json from collections import defaultdict from config import MODEL_PRICING, LOG_PATH, REPORT_PATH def load_logs(path): records [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue records.append(json.loads(line)) return records def calc_cost(record): model record[model] pricing MODEL_PRICING.get(model) if not pricing: return 0.0 input_cost record.get(input_tokens, 0) / 1_000_000 * pricing[input] output_cost record.get(output_tokens, 0) / 1_000_000 * pricing[output] cache_cost record.get(cache_read_tokens, 0) / 1_000_000 * pricing[cache_read] return input_cost output_cost cache_cost这段代码的关键点在于除以 1,000,000 这一步不能漏缓存 Token 要单独按缓存单价算遇到未知模型要返回 0 而不是报错避免一条脏数据让整个脚本崩掉。然后是聚合和输出报表的部分def aggregate_by_day(records): daily defaultdict(lambda: {input: 0, output: 0, cache: 0, cost: 0.0}) for r in records: day r[timestamp][:10] daily[day][input] r.get(input_tokens, 0) daily[day][output] r.get(output_tokens, 0) daily[day][cache] r.get(cache_read_tokens, 0) daily[day][cost] calc_cost(r) return daily def export_report(daily, path): with open(path, w, encodingutf-8) as f: f.write(date,input_tokens,output_tokens,cache_tokens,cost_usd\n) for day in sorted(daily.keys()): d daily[day] f.write(f{day},{d[input]},{d[output]},{d[cache]},{d[cost]:.4f}\n) if __name__ __main__: records load_logs(LOG_PATH) daily aggregate_by_day(records) export_report(daily, REPORT_PATH) total sum(d[cost] for d in daily.values()) print(f总记录数: {len(records)}) print(f总成本: ${total:.4f})跑起来之后你会得到一个按天汇总的 CSV 报表以及一个总成本数字。这个脚本虽然简单但已经覆盖了成本分析的核心流程。你可以在此基础上扩展按模型聚合、按用户聚合、加图表输出等功能。4.3 脚本运行与结果解读运行脚本只需要 Python 3.8 以上版本不需要额外安装依赖如果你用 pandas 版本的话需要装 pandas纯标准库版本则零依赖。把日志文件准备好改一下配置里的路径直接python analyzer.py就能跑。结果解读时有几个要点。第一看总成本是否符合预期如果远超预期先检查是不是有异常请求。第二看每日趋势如果某天突然飙升去查那天的日志。第三看输入输出比例如果输出占比特别高说明你的应用是生成密集型优化重点应该放在控制输出长度上。第四看缓存命中情况如果缓存 Token 占比很低说明你的提示词结构可能不利于缓存有优化空间。我实测下来一个中等规模的应用通过优化提示词结构和控制上下文成本能降 30% 到 50%。这个数字不是理论值是真实跑出来的。所以别小看这些分析它直接关系到你的项目能不能持续跑下去。5. 常见问题与排查技巧实录5.1 Token 数对不上为什么我数的和 API 报的不一样这是最常见的问题。你自己用某个工具数出来 1000 TokenAPI 返回却是 1200差在哪原因通常有三个一是你用的 Tokenizer 和模型实际用的不一致二是你漏算了系统提示词、格式标记这些隐藏内容三是多模态输入比如图片也会折算成 Token容易被忽略。解决办法很简单以 API 返回的 usage 为准不要自己数。自己数只能用于粗略预估精确计算一定要用真实返回值。如果你需要在调用前预估成本可以用官方提供的 Tokenizer 库但也要接受一定误差。5.2 成本突然飙升的五个排查方向账单突然变贵别慌按这个顺序排查排查方向具体表现排查方法调用量激增请求数翻倍看每日请求数趋势上下文变长输入 Token 暴涨看平均输入 Token 数输出失控输出 Token 暴涨检查 max_tokens 设置缓存失效缓存命中率骤降检查提示词是否被改动重复调用同一请求多次执行查日志里的重复 request_id我遇到过一次真实案例某天成本突然涨了三倍排查半天发现是代码里一个重试逻辑写错了请求失败后无限重试导致同一个请求被调了几十次。所以重试逻辑一定要设上限并且要区分哪些错误值得重试。5.3 缓存命中率上不去的三个原因缓存是个好东西但很多人用了之后发现命中率很低钱没省下来。常见原因有三个前缀不稳定提示词里混入了时间戳、随机 ID 这类每次都变的内容导致前缀无法匹配内容顺序不对把变化的内容放在了固定内容前面破坏了缓存前缀缓存过期缓存有有效期如果两次调用间隔太长缓存已经失效优化方法就是把固定不变的内容系统提示词、示例、格式要求放在最前面把变化的内容用户输入放在最后并且确保前缀部分完全一致。这样缓存命中率能大幅提升。5.4 多模型混用时的成本归因难题很多应用会同时用多个模型比如简单任务用轻量模型复杂任务用高配模型。这时候成本归因就成了问题到底哪个模型花了多少钱哪个功能最烧钱解决办法是在日志里记录足够的维度模型名、功能标识、用户标识。然后在聚合时按这些维度分组。如果日志里只有 Token 数没有这些标识那就只能看总数没法归因。所以还是那句话日志设计要从第一天就做好。提示如果你的应用有多个功能共用同一个模型建议在请求里加一个业务标签写日志时带上。这个小小的字段能让后续的成本分析轻松很多。6. 成本优化的实战经验与长期策略6.1 提示词精简砍掉每一个不必要的 Token成本优化最直接的手段就是精简提示词。我见过很多项目的系统提示词写得又长又啰嗦动辄两三千 Token其中一大半是重复的说明和冗余的示例。精简提示词的原则是能一句话说清的不写两句能用示例说明的不写大段描述能删的客套话全删掉。具体操作上我会把提示词拆成必须保留和可以精简两部分先砍可以精简的再看必须保留的能不能用更短的表达。一个实用的技巧是把提示词发给模型让它帮你精简然后人工审核。模型很擅长做这种压缩往往能砍掉 30% 以上的冗余内容而不损失效果。6.2 上下文管理滑动窗口与摘要压缩前面讲过上下文累积的问题解决办法主要有两个滑动窗口和摘要压缩。滑动窗口就是只保留最近 N 轮对话更早的直接丢掉。这个方法简单粗暴但会丢失早期信息。摘要压缩是把早期对话用模型总结成一段简短摘要然后带上摘要继续对话。这个方法保留了语义但需要额外调用一次模型做摘要有额外成本。实际选择要看场景。如果是客服机器人这种短期对话滑动窗口就够了。如果是长期陪伴类应用摘要压缩更合适。我一般会设置一个阈值比如对话超过 10 轮就触发摘要把前 8 轮压缩成一段话保留最近 2 轮原文。6.3 模型分级什么任务用什么模型不是所有任务都需要最强的模型。很多简单任务比如分类、抽取、格式转换用轻量模型完全够用成本可能只有高配模型的十分之一。所以做成本优化时一定要做模型分级把任务按复杂度分类简单任务走轻量模型复杂任务才走高配模型。判断任务复杂度可以从几个维度看需不需要推理、输出长不长、对准确性要求高不高。如果任务只是把一段文本转成 JSON那轻量模型绰绰有余。如果任务需要多步推理和长文生成那才需要上高配模型。这个分级策略落地后成本往往能降一半以上。6.4 建立成本监控与预警机制最后也是最重要的建立成本监控和预警。不要等到月底看账单才发现问题要实时监控。具体做法是每天定时跑一次成本分析脚本把结果推到你的监控面板或群里。设置一个阈值比如日成本超过某个数就报警。这个机制的价值在于它能把成本问题从事后发现变成事中控制。我自己的项目就设了三级预警日成本超过 50 美元提醒超过 100 美元警告超过 200 美元直接触发人工检查。有了这个机制之后再也没出现过账单失控的情况。我个人在实际操作中的体会是成本优化不是一次性的工作而是持续的过程。模型在更新单价在变化业务在演进你的优化策略也要跟着调整。把成本分析脚本当成项目的基础设施定期跑、定期看才能真正把成本控制住。最后再分享一个小技巧每次模型降价或者出新模型时别急着全量切换先拿一部分流量做 A/B 测试对比成本和效果确认没问题再逐步放量。这样既享受了降价红利又不会因为模型差异导致业务出问题。