这学期我们那门 AI 课作业全部跑在真实的大模型 API 上额度不包、自掏腰包用多少 Token 就扣多少钱。开学第一周群里就有人晒账单同样一道题有人花了几毛有人花了好几块差距最大的地方不在谁代码写得多而在谁的提示词Prompt缓存命中率高。我当了一学期助教帮同学看过不下几十份账单慢慢摸清楚了一件事AI 课的 Token 花费本质上是一场关于重复利用的博弈而缓存命中率就是这场博弈里最关键的那条隐藏曲线。这篇东西不聊虚的我把 Token 计费逻辑、缓存命中率怎么算、一学期账单怎么推、以及我踩过的坑全部摊开讲清楚。不管你是正在为 AI 课账单发愁的学生还是准备把大模型接进自己项目里的开发者看完都能自己动手把账算明白。1. 先把 AI 课自费 Token 这件事的账本逻辑理清很多同学第一次看到Token 自费这四个字是懵的——我写的是代码扣的是 Token这两者到底怎么换算搞不清楚计费单位后面所有省钱技巧都是空中楼阁。所以咱们先从最底层的账本逻辑入手把花的是什么钱这件事拆到不能再拆。1.1 Token 是计费的最小单位但它不等于字数大模型不按字数收费按 Token 收费。Token 是模型处理文本时切分出来的最小片段英文里一个常见单词往往就是一个 Token一个较长或生僻的词可能被切成两三个 Token中文更微妙一个汉字通常对应一到两个 Token标点、空格、换行也各有开销。这意味着同样一段中文在不同模型下的 Token 数可能差出两成。这件事为什么重要因为它决定了一个残酷的事实你在对话里粘贴的每一段上下文、你让模型读的每一行代码、你贴进去的每一条报错都会变成账单上的一行数字。很多同学写作业时习惯把整个项目文件一股脑贴进去觉得反正模型能读可模型读完是要按 Token 收费的。我见过最夸张的一份作业光是把一个 data 文件夹的日志全贴进去一次调用就烧掉了将近三万输入 Token。那 Token 到底怎么数最稳妥的办法是用官方提供的计数工具或者tiktoken这类编码库去数而不是靠大概几个字。这里有个反直觉的点代码的 Token 密度比自然语言高。因为代码里有大量缩进、符号、括号这些看起来不起眼的字符全是独立 Token。一段 100 行的 Python 代码Token 数常常比你想象的多出三到五成。你在心里默认代码没多少字的时候账单已经在悄悄往上爬了。1.2 一门 AI 课的真实调用画像要估算一学期账单光知道 Token 单价没用还得知道你一学期到底会调用多少次、每次调用长什么样。我按我们那门课的实际使用情况梳理出一份典型的调用画像你可以对照自己的课程做替换。一门典型的 AI 应用课调用模式大概是这样每周两到三次作业每次作业需要和模型来回交互若干轮直到跑通。每轮交互包括三部分——发给模型的输入系统提示词 上下文 你的问题、模型返回的输出、以及下一轮把历史重新带上。学期按 16 周算一周两次大作业每次作业平均调用八次一个学期下来大概两百多次调用。这个数量级听起来不大但每次调用的输入如果带着几千上万 Token 的上下文叠起来就很可观了。更关键的是上下文会滚雪球这个特性。多轮对话里第二轮要把第一轮的问题和回答都带上第三轮要带上前两轮以此类推。如果你的提示词设计得当前面这部分稳定内容能被缓存复用成本几乎可以忽略如果设计得不好每一轮都在为同样的内容重复付费。这就是为什么同一次作业有人花了八毛有人花了八块——差别不在模型在提示词的组织方式。提示在动手算账之前先花十分钟统计一下自己最近一周的调用次数和平均输入长度你会对钱花在哪有一个非常直观的认识。2. 缓存命中率决定账单高低的那条隐藏曲线搞清楚了钱是怎么花的接下来要请出这篇的主角——缓存命中率。这四个字在账单里几乎不显形却在悄悄决定你最终要付多少钱。想理解它得先明白大模型的缓存究竟缓存了什么。2.1 Prompt Cache 到底缓存了什么大模型的缓存机制官方通常叫 Prompt Caching提示词缓存。它的核心思想非常朴素如果你连续多次调用模型时开头有一大段完全相同的输入那么这段相同的前缀就不用每次重算模型可以直接复用之前的计算结果你也就只需要为复用付一个很便宜的价钱。打个生活化的比方。你去一家餐厅每次都点同样的套餐前菜固定、汤固定、主菜才换。餐厅老板发现你每次前菜和汤都一样于是提前把它们备好放保温柜里你一来直接端出来只现做那道变来变去的主菜。前菜和汤就是缓存命中的部分主菜就是每次都变的部分。缓存命中率衡量的就是保温柜里的菜占你整顿饭的比重。技术上讲缓存的最小粒度通常是前缀的一个固定长度不同服务商要求不一样有的要求前缀至少几百 Token 才有意义且按固定块对齐。只有当你的输入前缀逐字节、逐 Token 稳定时后面的内容才能吃到缓存。反过来只要你把一段会变的内容放进了前缀里它后面所有的缓存都会失效——这就是最容易踩的坑。2.2 三种 Token 的价格阶梯缓存机制之所以值钱是因为它把输入 Token 拆成了三条价格完全不同的通道。以目前主流服务商的普遍定价结构为例大致是这样一个阶梯Token 类型含义相对价格示例普通输入 Token没有被缓存命中的输入基准价记为 1 倍缓存写入 Token第一次把前缀写进缓存的输入约 1.25 倍缓存读取 Token命中缓存、复用已有前缀的输入约 0.1 倍输出 Token模型生成的内容约 5 倍注意上表是示例性的相对倍数用来解释机制具体单价以你所使用服务商的官方定价为准不同模型差异很大。这张表里藏着两个反直觉的点。第一缓存写入比普通输入还贵。你第一次建立缓存时是要额外付费的这就意味着缓存不是用得越多越省而是要跨调用复用才有价值。第二缓存读取便宜到几乎可以忽略——只有普通输入的一成左右。所以省钱的核心不是少发内容而是让更多内容落到缓存读取这条通道上。输出 Token 约等于输入的五倍这件事同样要重视。你在提示词里问一句请详细解释模型回你两千字这部分的钱比你贴进去两千字上下文还贵。这解释了为什么啰嗦的提问往往比啰嗦的上下文更烧钱。2.3 为什么课堂场景天生适合吃缓存缓存这套机制对 AI 课的作业场景来说简直是量身定做。原因有三个。第一系统提示词天然稳定。每门课通常会给一个固定的系统角色设定、固定的输出格式要求、固定的评分标准。这部分内容每次调用都一模一样是最理想的可缓存前缀。第二上下文高度重复。做同一道作业时你要反复和模型讨论同一份代码、同一份题目描述。这份材料在多次调用间几乎不变正好构成稳定前缀。第三交互轮数多。多轮对话里历史会不断累积而这些历史在后续轮次中完全不变——每多一轮可命中的历史就更长。轮数越多缓存的价值越明显。有意思的是很多同学恰恰在这三点的反面踩坑他们把当前时间戳、随机数、每次不同的问候语放在了提示词最前面或者每次调用都重新排列上下文顺序。这些看似无关紧要的小动作会让缓存前缀在第一个字符就分叉命中率直接归零。我在帮同学看账单时最常见的冤枉钱就是这么来的。3. 动手算一学期账单从哪几个参数推出来原理讲透了现在进入正题怎么用缓存命中率把一学期账单算出来。我会给出一套可以照搬的公式再代入一组实测参数把数字算给你看最后附一段脚本让你能直接读日志反推自己的账单。3.1 先立公式把账单拆成四个乘数一次调用的成本可以拆成四项相加单次成本 缓存写入Token × 写入单价 缓存读取Token × 读取单价 普通输入Token × 输入单价 输出Token × 输出单价这里的缓存命中率通常定义为命中率 缓存读取Token / (缓存读取Token 普通输入Token)也就是进入前缀缓存的输入占全部输入的比重。注意公式的分母是缓存读取加普通输入不含输出因为输出不参与缓存。搞清楚这个定义很重要有些同学把总 Token 当分母算出来的命中率会虚低进而低估了缓存的作用。有了这两个公式一学期账单就是学期账单 单次平均成本 × 学期总调用次数 首次建立缓存的额外成本其中首次建立缓存的额外成本就是缓存写入那部分溢价如果你整个学期复用同一套系统提示词这部分成本只在最开始发生一次摊到几百次调用上几乎可以忽略。3.2 代入一次作业的实测参数下面这套数字是我根据一个真实作业场景整理的量级示例单价用相对倍数表示方便你自己套用绝对价格。设定如下单次调用输入合计约 12000 Token其中稳定前缀系统提示词 题目 代码上下文约 8000 Token每轮新增的问题约 4000 Token单次输出约 1000 Token每道作业平均 8 次调用一学期 32 道作业共约 256 次调用相对单价普通输入 1 倍、缓存写入 1.25 倍、缓存读取 0.1 倍、输出 5 倍把1 倍记作 p。先算无缓存的情况。所有 12000 输入 Token 都走普通输入无缓存单次输入成本 12000 × 1p 12000p 无缓存单次输出成本 1000 × 5p 5000p 无缓存单次合计 17000p再算有缓存的情况。假设前缀全部命中即 8000 Token 走缓存读取4000 走普通输入有缓存单次输入成本 8000 × 0.1p 4000 × 1p 800p 4000p 4800p 有缓存单次输出成本 1000 × 5p 5000p 有缓存单次合计 9800p单次对比从 17000p 降到 9800p省了约 42%。把 p 换成你实际模型的输入单价就能得到绝对金额。整学期 256 次调用无缓存学期成本 17000p × 256 4,352,000p 有缓存学期成本 9800p × 256 2,508,800p 节省 ≈ 1,843,200p如果 p 取一个常见的量级这个节省额大约是一顿正经午餐和一周咖啡的差别——对一门课的作业量来说相当可观了。这里还要提一句缓存写入的账。第一次调用时那 8000 Token 的前缀要按 1.25 倍写入首次写入成本 8000 × 1.25p 10000p这 10000p 相比整学期几百万 p 的总量占比不到 1%。所以只要你的前缀能被复用超过两三次缓存就是稳赚的。真正的风险从来不是写入贵而是前缀不稳定导致写入之后根本读不到。3.3 用脚本从调用日志里反推命中率与账单光有公式还不够你得知道自己的真实命中率是多少。主流服务商的 API 返回里通常会带用量字段把每次调用的prompt_tokens、cached_tokens、completion_tokens记下来就能反推。下面这段脚本演示怎么从一份日志里统计命中率和估算账单import json from collections import defaultdict # 单价按每百万 Token 计这里用示例值请替换成你自己的官方定价 PRICE { input: 3.0, # 普通输入 cache_write: 3.75, # 缓存写入 cache_read: 0.3, # 缓存读取 output: 15.0, # 输出 } def estimate(log_path): total defaultdict(float) calls 0 with open(log_path, encodingutf-8) as f: for line in f: rec json.loads(line) usage rec.get(usage, {}) prompt usage.get(prompt_tokens, 0) cached usage.get(cached_tokens, 0) output usage.get(completion_tokens, 0) normal_input max(prompt - cached, 0) total[input] normal_input total[cache_read] cached total[output] output calls 1 # 命中率 缓存读取 / 全部输入 all_input total[input] total[cache_read] hit_rate total[cache_read] / all_input if all_input else 0 cost ( total[input] / 1e6 * PRICE[input] total[cache_read] / 1e6 * PRICE[cache_read] total[output] / 1e6 * PRICE[output] ) print(f调用次数: {calls}) print(f缓存命中率: {hit_rate:.2%}) print(f普通输入 Token: {int(total[input])}) print(f缓存读取 Token: {int(total[cache_read])}) print(f输出 Token: {int(total[output])}) print(f估算总成本: ${cost:.4f}) if __name__ __main__: estimate(usage_log.jsonl)这段脚本的关键点在于它把输入拆成了普通输入和缓存读取两部分用prompt_tokens - cached_tokens得到没命中的部分。跑完之后你会拿到两个最有用的数字——命中率和总成本。我强烈建议你在每次作业之后都跑一遍看命中率是不是稳定在高位。如果某次作业的命中率突然掉到 20% 以下那基本可以断定你的提示词前缀里混进了会变的内容。提示如果你用的服务商返回字段名不一样有的叫cache_read_input_tokens有的叫prompt_cache_hit_tokens把脚本里对应的键名改一下即可逻辑完全一致。4. 把命中率拉起来省钱的实操手法算清楚账之后真正能帮你省钱的是那些让前缀保持稳定的操作习惯。这些细节常规文档里通常不会写但它们在实操中的影响远比调参大。下面是我总结出来的几条。4.1 让提示词前缀稳定的几个习惯第一把不变的内容全部放到最前面把会变的内容全部放到最后。这是缓存机制的铁律。系统提示词、评分标准、固定示例、题目描述、代码上下文——这些稳定的东西按顺序排在前头当前轮的具体问题、要改的报错、你的第 n 次追问——全部放到末尾。这样每轮的差异只发生在尾部前面一长串前缀都能被缓存复用。第二不要在提示词开头放时间戳、随机 ID、会话编号。我见过很多人为了防止模型串会话习惯在系统提示词最前面加一行当前时间或者一个随机数。这个动作直接把整段前缀的哈希值改了缓存永远命中不了。正确做法是把这些动态信息放到最末尾或者干脆不放。第三保持上下文的顺序和格式逐字节一致。缓存是精确匹配差一个空格、换一个标点、调整一下 JSON 的键顺序都会导致前缀分叉。所以别在两次调用之间顺手优化一下排版那点美感不值得你多花好几倍的钱。第四减少重发全量历史的冲动。多轮对话里历史本身可以被缓存但如果你每轮都手动把整个代码库重新贴一遍那部分新增内容是要按普通输入付费的。更好的方式是让历史自然累积、依赖缓存复用而不是每轮重新粘贴。第五把输出也控制住。虽然输出不参与缓存但它单价最贵。在提示词里明确要求只返回修改后的函数、不要重复解释已经讲过的内容能直接砍掉一大块输出成本。4.2 常见问题与排查速查表下面这张表覆盖了我一学期里被问得最多的几个问题遇到症状可以直接对照排查。症状可能原因排查与解决命中率一直接近 0前缀里混入了动态内容检查系统提示词开头有没有时间戳、随机数把动态内容移到末尾命中率忽高忽低上下文顺序或格式不固定固定代码块的粘贴顺序和缩进避免随机排版单次成本突然翻倍贴了超长日志或整个目录只贴相关片段用tiktoken先数一下 Token 数输出费用占大头提问过于开放明确要求输出格式和篇幅要求只给差异部分首次调用特别贵缓存写入溢价属正常现象只要前缀能被复用三次以上就划算长对话越来越贵历史无限增长定期总结历史并压缩或开启会话截断策略注意不要为了追求高命中率而把本该变化的上下文也硬编码成固定内容那样会让模型拿到过时信息答非所问省下的钱还不够你重做作业的。命中率和回答质量之间要取一个平衡点。5. 我踩过的坑和几点私人心得最后分享几个我亲身踩过的坑都是那种文档里不会写、但真的会让你多花钱的类型。第一个坑是粘贴整个项目。刚开始做作业时我图省事把整个工程目录的内容打包贴进提示词结果一次调用输入三万多 Token其中真正用到的不到两千。后来改成只贴相关函数和报错行输入直接降到三千以内命中率也上去了因为剩下的部分短而稳定更容易被缓存覆盖。第二个坑是频繁调整提示词措辞。有段时间我总觉得模型不听话就反复微调系统提示词里的措辞改一个词就重新试一次。结果每改一次缓存前缀就重建一次写入溢价白白付了好几遍。后来我固定住系统提示词只在末尾追加问题命中率立刻稳在 80% 以上。第三个坑是忽略了输出的单价。我曾经让模型顺便把整个文件重写一遍并详细注释它一口气生成了四千多 Token 的输出那一次的成本比我前面十次调用的输入还贵。从那以后我在提示词里加了一句只输出改动的最小片段不要复述上下文输出成本降了一大截。说到底AI 课的 Token 账单并不是一笔算不清的糊涂账。它由调用次数、输入长度、命中率和输出长度这四个变量决定而其中唯一能通过使用习惯大幅优化的就是缓存命中率。你把稳定内容前置、把动态内容后置、保持格式一致命中率自然就上去了账单也就跟着下来了。我个人的经验是做好这几件事同样一门课的 Token 花费能轻松砍掉三到五成而且完全不牺牲回答质量。如果你现在还在为账单发愁不妨先从统计自己最近的调用日志开始把命中率这个数字摸出来——很多人第一次看到自己的真实命中率时都会有点意外。
大模型Token计费与缓存命中率：AI课作业省钱实战指南
这学期我们那门 AI 课作业全部跑在真实的大模型 API 上额度不包、自掏腰包用多少 Token 就扣多少钱。开学第一周群里就有人晒账单同样一道题有人花了几毛有人花了好几块差距最大的地方不在谁代码写得多而在谁的提示词Prompt缓存命中率高。我当了一学期助教帮同学看过不下几十份账单慢慢摸清楚了一件事AI 课的 Token 花费本质上是一场关于重复利用的博弈而缓存命中率就是这场博弈里最关键的那条隐藏曲线。这篇东西不聊虚的我把 Token 计费逻辑、缓存命中率怎么算、一学期账单怎么推、以及我踩过的坑全部摊开讲清楚。不管你是正在为 AI 课账单发愁的学生还是准备把大模型接进自己项目里的开发者看完都能自己动手把账算明白。1. 先把 AI 课自费 Token 这件事的账本逻辑理清很多同学第一次看到Token 自费这四个字是懵的——我写的是代码扣的是 Token这两者到底怎么换算搞不清楚计费单位后面所有省钱技巧都是空中楼阁。所以咱们先从最底层的账本逻辑入手把花的是什么钱这件事拆到不能再拆。1.1 Token 是计费的最小单位但它不等于字数大模型不按字数收费按 Token 收费。Token 是模型处理文本时切分出来的最小片段英文里一个常见单词往往就是一个 Token一个较长或生僻的词可能被切成两三个 Token中文更微妙一个汉字通常对应一到两个 Token标点、空格、换行也各有开销。这意味着同样一段中文在不同模型下的 Token 数可能差出两成。这件事为什么重要因为它决定了一个残酷的事实你在对话里粘贴的每一段上下文、你让模型读的每一行代码、你贴进去的每一条报错都会变成账单上的一行数字。很多同学写作业时习惯把整个项目文件一股脑贴进去觉得反正模型能读可模型读完是要按 Token 收费的。我见过最夸张的一份作业光是把一个 data 文件夹的日志全贴进去一次调用就烧掉了将近三万输入 Token。那 Token 到底怎么数最稳妥的办法是用官方提供的计数工具或者tiktoken这类编码库去数而不是靠大概几个字。这里有个反直觉的点代码的 Token 密度比自然语言高。因为代码里有大量缩进、符号、括号这些看起来不起眼的字符全是独立 Token。一段 100 行的 Python 代码Token 数常常比你想象的多出三到五成。你在心里默认代码没多少字的时候账单已经在悄悄往上爬了。1.2 一门 AI 课的真实调用画像要估算一学期账单光知道 Token 单价没用还得知道你一学期到底会调用多少次、每次调用长什么样。我按我们那门课的实际使用情况梳理出一份典型的调用画像你可以对照自己的课程做替换。一门典型的 AI 应用课调用模式大概是这样每周两到三次作业每次作业需要和模型来回交互若干轮直到跑通。每轮交互包括三部分——发给模型的输入系统提示词 上下文 你的问题、模型返回的输出、以及下一轮把历史重新带上。学期按 16 周算一周两次大作业每次作业平均调用八次一个学期下来大概两百多次调用。这个数量级听起来不大但每次调用的输入如果带着几千上万 Token 的上下文叠起来就很可观了。更关键的是上下文会滚雪球这个特性。多轮对话里第二轮要把第一轮的问题和回答都带上第三轮要带上前两轮以此类推。如果你的提示词设计得当前面这部分稳定内容能被缓存复用成本几乎可以忽略如果设计得不好每一轮都在为同样的内容重复付费。这就是为什么同一次作业有人花了八毛有人花了八块——差别不在模型在提示词的组织方式。提示在动手算账之前先花十分钟统计一下自己最近一周的调用次数和平均输入长度你会对钱花在哪有一个非常直观的认识。2. 缓存命中率决定账单高低的那条隐藏曲线搞清楚了钱是怎么花的接下来要请出这篇的主角——缓存命中率。这四个字在账单里几乎不显形却在悄悄决定你最终要付多少钱。想理解它得先明白大模型的缓存究竟缓存了什么。2.1 Prompt Cache 到底缓存了什么大模型的缓存机制官方通常叫 Prompt Caching提示词缓存。它的核心思想非常朴素如果你连续多次调用模型时开头有一大段完全相同的输入那么这段相同的前缀就不用每次重算模型可以直接复用之前的计算结果你也就只需要为复用付一个很便宜的价钱。打个生活化的比方。你去一家餐厅每次都点同样的套餐前菜固定、汤固定、主菜才换。餐厅老板发现你每次前菜和汤都一样于是提前把它们备好放保温柜里你一来直接端出来只现做那道变来变去的主菜。前菜和汤就是缓存命中的部分主菜就是每次都变的部分。缓存命中率衡量的就是保温柜里的菜占你整顿饭的比重。技术上讲缓存的最小粒度通常是前缀的一个固定长度不同服务商要求不一样有的要求前缀至少几百 Token 才有意义且按固定块对齐。只有当你的输入前缀逐字节、逐 Token 稳定时后面的内容才能吃到缓存。反过来只要你把一段会变的内容放进了前缀里它后面所有的缓存都会失效——这就是最容易踩的坑。2.2 三种 Token 的价格阶梯缓存机制之所以值钱是因为它把输入 Token 拆成了三条价格完全不同的通道。以目前主流服务商的普遍定价结构为例大致是这样一个阶梯Token 类型含义相对价格示例普通输入 Token没有被缓存命中的输入基准价记为 1 倍缓存写入 Token第一次把前缀写进缓存的输入约 1.25 倍缓存读取 Token命中缓存、复用已有前缀的输入约 0.1 倍输出 Token模型生成的内容约 5 倍注意上表是示例性的相对倍数用来解释机制具体单价以你所使用服务商的官方定价为准不同模型差异很大。这张表里藏着两个反直觉的点。第一缓存写入比普通输入还贵。你第一次建立缓存时是要额外付费的这就意味着缓存不是用得越多越省而是要跨调用复用才有价值。第二缓存读取便宜到几乎可以忽略——只有普通输入的一成左右。所以省钱的核心不是少发内容而是让更多内容落到缓存读取这条通道上。输出 Token 约等于输入的五倍这件事同样要重视。你在提示词里问一句请详细解释模型回你两千字这部分的钱比你贴进去两千字上下文还贵。这解释了为什么啰嗦的提问往往比啰嗦的上下文更烧钱。2.3 为什么课堂场景天生适合吃缓存缓存这套机制对 AI 课的作业场景来说简直是量身定做。原因有三个。第一系统提示词天然稳定。每门课通常会给一个固定的系统角色设定、固定的输出格式要求、固定的评分标准。这部分内容每次调用都一模一样是最理想的可缓存前缀。第二上下文高度重复。做同一道作业时你要反复和模型讨论同一份代码、同一份题目描述。这份材料在多次调用间几乎不变正好构成稳定前缀。第三交互轮数多。多轮对话里历史会不断累积而这些历史在后续轮次中完全不变——每多一轮可命中的历史就更长。轮数越多缓存的价值越明显。有意思的是很多同学恰恰在这三点的反面踩坑他们把当前时间戳、随机数、每次不同的问候语放在了提示词最前面或者每次调用都重新排列上下文顺序。这些看似无关紧要的小动作会让缓存前缀在第一个字符就分叉命中率直接归零。我在帮同学看账单时最常见的冤枉钱就是这么来的。3. 动手算一学期账单从哪几个参数推出来原理讲透了现在进入正题怎么用缓存命中率把一学期账单算出来。我会给出一套可以照搬的公式再代入一组实测参数把数字算给你看最后附一段脚本让你能直接读日志反推自己的账单。3.1 先立公式把账单拆成四个乘数一次调用的成本可以拆成四项相加单次成本 缓存写入Token × 写入单价 缓存读取Token × 读取单价 普通输入Token × 输入单价 输出Token × 输出单价这里的缓存命中率通常定义为命中率 缓存读取Token / (缓存读取Token 普通输入Token)也就是进入前缀缓存的输入占全部输入的比重。注意公式的分母是缓存读取加普通输入不含输出因为输出不参与缓存。搞清楚这个定义很重要有些同学把总 Token 当分母算出来的命中率会虚低进而低估了缓存的作用。有了这两个公式一学期账单就是学期账单 单次平均成本 × 学期总调用次数 首次建立缓存的额外成本其中首次建立缓存的额外成本就是缓存写入那部分溢价如果你整个学期复用同一套系统提示词这部分成本只在最开始发生一次摊到几百次调用上几乎可以忽略。3.2 代入一次作业的实测参数下面这套数字是我根据一个真实作业场景整理的量级示例单价用相对倍数表示方便你自己套用绝对价格。设定如下单次调用输入合计约 12000 Token其中稳定前缀系统提示词 题目 代码上下文约 8000 Token每轮新增的问题约 4000 Token单次输出约 1000 Token每道作业平均 8 次调用一学期 32 道作业共约 256 次调用相对单价普通输入 1 倍、缓存写入 1.25 倍、缓存读取 0.1 倍、输出 5 倍把1 倍记作 p。先算无缓存的情况。所有 12000 输入 Token 都走普通输入无缓存单次输入成本 12000 × 1p 12000p 无缓存单次输出成本 1000 × 5p 5000p 无缓存单次合计 17000p再算有缓存的情况。假设前缀全部命中即 8000 Token 走缓存读取4000 走普通输入有缓存单次输入成本 8000 × 0.1p 4000 × 1p 800p 4000p 4800p 有缓存单次输出成本 1000 × 5p 5000p 有缓存单次合计 9800p单次对比从 17000p 降到 9800p省了约 42%。把 p 换成你实际模型的输入单价就能得到绝对金额。整学期 256 次调用无缓存学期成本 17000p × 256 4,352,000p 有缓存学期成本 9800p × 256 2,508,800p 节省 ≈ 1,843,200p如果 p 取一个常见的量级这个节省额大约是一顿正经午餐和一周咖啡的差别——对一门课的作业量来说相当可观了。这里还要提一句缓存写入的账。第一次调用时那 8000 Token 的前缀要按 1.25 倍写入首次写入成本 8000 × 1.25p 10000p这 10000p 相比整学期几百万 p 的总量占比不到 1%。所以只要你的前缀能被复用超过两三次缓存就是稳赚的。真正的风险从来不是写入贵而是前缀不稳定导致写入之后根本读不到。3.3 用脚本从调用日志里反推命中率与账单光有公式还不够你得知道自己的真实命中率是多少。主流服务商的 API 返回里通常会带用量字段把每次调用的prompt_tokens、cached_tokens、completion_tokens记下来就能反推。下面这段脚本演示怎么从一份日志里统计命中率和估算账单import json from collections import defaultdict # 单价按每百万 Token 计这里用示例值请替换成你自己的官方定价 PRICE { input: 3.0, # 普通输入 cache_write: 3.75, # 缓存写入 cache_read: 0.3, # 缓存读取 output: 15.0, # 输出 } def estimate(log_path): total defaultdict(float) calls 0 with open(log_path, encodingutf-8) as f: for line in f: rec json.loads(line) usage rec.get(usage, {}) prompt usage.get(prompt_tokens, 0) cached usage.get(cached_tokens, 0) output usage.get(completion_tokens, 0) normal_input max(prompt - cached, 0) total[input] normal_input total[cache_read] cached total[output] output calls 1 # 命中率 缓存读取 / 全部输入 all_input total[input] total[cache_read] hit_rate total[cache_read] / all_input if all_input else 0 cost ( total[input] / 1e6 * PRICE[input] total[cache_read] / 1e6 * PRICE[cache_read] total[output] / 1e6 * PRICE[output] ) print(f调用次数: {calls}) print(f缓存命中率: {hit_rate:.2%}) print(f普通输入 Token: {int(total[input])}) print(f缓存读取 Token: {int(total[cache_read])}) print(f输出 Token: {int(total[output])}) print(f估算总成本: ${cost:.4f}) if __name__ __main__: estimate(usage_log.jsonl)这段脚本的关键点在于它把输入拆成了普通输入和缓存读取两部分用prompt_tokens - cached_tokens得到没命中的部分。跑完之后你会拿到两个最有用的数字——命中率和总成本。我强烈建议你在每次作业之后都跑一遍看命中率是不是稳定在高位。如果某次作业的命中率突然掉到 20% 以下那基本可以断定你的提示词前缀里混进了会变的内容。提示如果你用的服务商返回字段名不一样有的叫cache_read_input_tokens有的叫prompt_cache_hit_tokens把脚本里对应的键名改一下即可逻辑完全一致。4. 把命中率拉起来省钱的实操手法算清楚账之后真正能帮你省钱的是那些让前缀保持稳定的操作习惯。这些细节常规文档里通常不会写但它们在实操中的影响远比调参大。下面是我总结出来的几条。4.1 让提示词前缀稳定的几个习惯第一把不变的内容全部放到最前面把会变的内容全部放到最后。这是缓存机制的铁律。系统提示词、评分标准、固定示例、题目描述、代码上下文——这些稳定的东西按顺序排在前头当前轮的具体问题、要改的报错、你的第 n 次追问——全部放到末尾。这样每轮的差异只发生在尾部前面一长串前缀都能被缓存复用。第二不要在提示词开头放时间戳、随机 ID、会话编号。我见过很多人为了防止模型串会话习惯在系统提示词最前面加一行当前时间或者一个随机数。这个动作直接把整段前缀的哈希值改了缓存永远命中不了。正确做法是把这些动态信息放到最末尾或者干脆不放。第三保持上下文的顺序和格式逐字节一致。缓存是精确匹配差一个空格、换一个标点、调整一下 JSON 的键顺序都会导致前缀分叉。所以别在两次调用之间顺手优化一下排版那点美感不值得你多花好几倍的钱。第四减少重发全量历史的冲动。多轮对话里历史本身可以被缓存但如果你每轮都手动把整个代码库重新贴一遍那部分新增内容是要按普通输入付费的。更好的方式是让历史自然累积、依赖缓存复用而不是每轮重新粘贴。第五把输出也控制住。虽然输出不参与缓存但它单价最贵。在提示词里明确要求只返回修改后的函数、不要重复解释已经讲过的内容能直接砍掉一大块输出成本。4.2 常见问题与排查速查表下面这张表覆盖了我一学期里被问得最多的几个问题遇到症状可以直接对照排查。症状可能原因排查与解决命中率一直接近 0前缀里混入了动态内容检查系统提示词开头有没有时间戳、随机数把动态内容移到末尾命中率忽高忽低上下文顺序或格式不固定固定代码块的粘贴顺序和缩进避免随机排版单次成本突然翻倍贴了超长日志或整个目录只贴相关片段用tiktoken先数一下 Token 数输出费用占大头提问过于开放明确要求输出格式和篇幅要求只给差异部分首次调用特别贵缓存写入溢价属正常现象只要前缀能被复用三次以上就划算长对话越来越贵历史无限增长定期总结历史并压缩或开启会话截断策略注意不要为了追求高命中率而把本该变化的上下文也硬编码成固定内容那样会让模型拿到过时信息答非所问省下的钱还不够你重做作业的。命中率和回答质量之间要取一个平衡点。5. 我踩过的坑和几点私人心得最后分享几个我亲身踩过的坑都是那种文档里不会写、但真的会让你多花钱的类型。第一个坑是粘贴整个项目。刚开始做作业时我图省事把整个工程目录的内容打包贴进提示词结果一次调用输入三万多 Token其中真正用到的不到两千。后来改成只贴相关函数和报错行输入直接降到三千以内命中率也上去了因为剩下的部分短而稳定更容易被缓存覆盖。第二个坑是频繁调整提示词措辞。有段时间我总觉得模型不听话就反复微调系统提示词里的措辞改一个词就重新试一次。结果每改一次缓存前缀就重建一次写入溢价白白付了好几遍。后来我固定住系统提示词只在末尾追加问题命中率立刻稳在 80% 以上。第三个坑是忽略了输出的单价。我曾经让模型顺便把整个文件重写一遍并详细注释它一口气生成了四千多 Token 的输出那一次的成本比我前面十次调用的输入还贵。从那以后我在提示词里加了一句只输出改动的最小片段不要复述上下文输出成本降了一大截。说到底AI 课的 Token 账单并不是一笔算不清的糊涂账。它由调用次数、输入长度、命中率和输出长度这四个变量决定而其中唯一能通过使用习惯大幅优化的就是缓存命中率。你把稳定内容前置、把动态内容后置、保持格式一致命中率自然就上去了账单也就跟着下来了。我个人的经验是做好这几件事同样一门课的 Token 花费能轻松砍掉三到五成而且完全不牺牲回答质量。如果你现在还在为账单发愁不妨先从统计自己最近的调用日志开始把命中率这个数字摸出来——很多人第一次看到自己的真实命中率时都会有点意外。