南大那门《大模型应用开发》课第一节课老师就说了句让全班安静了半分钟的话作业和课程项目要调用大模型APIToken费用自理。我当时还觉得没什么学生作业嘛撑死跑几个Demo能烧多少钱。结果第一份RAG检索增强生成作业交掉之后我去看API用量明细账单上的数字直接让我重新审视了整个学期的预算。更让我意外的是同样一批作业如果调用方式不同费用能差出一大截关键就在账单里那个平时没人看的指标——缓存命中率。这篇文章不是来科普Token是什么的也不是教你写更好的提示词而是把我实际用缓存命中率拆解一学期账单、把自费成本尽量压下来的完整过程记录下来。内容适合三类人正在上需要使用大模型API课程、要自己掏钱跑模型的学生带学生做AI项目、想控制项目经费的老师以及所有用大模型API做个人开发、对Token账单没有清晰概念的开发者。1. 自费Token这门课钱到底烧在哪里1.1 课程作业里的三种典型高消耗场景大模型API按Token计费Token可以理解成模型眼里读到的字数。中文一个汉字通常对应1到2个Token英文单词也经常被拆成几个子词。你发送的提示词、模型生成的回复全部会计费。课程作业里最烧Token的是三类场景RAG问答每问一个问题系统先把检索出来的文档片段拼进上下文。一个文档块几千TokenTop-5拼下来每次都接近上万Token而且每个问题都可能要把这些文档重新发一遍。Agent工具调用模型要理解工具Schema还要逐步思考该调用哪个工具、传什么参数、返回结果怎么处理思考过程和中间结果会被一遍遍拼回上下文。多轮对话与长文本批改历史消息全部带着走轮数越多上下文越长后面几轮的请求体积会很夸张。我一开始对这几类场景完全没有成本概念觉得反正是自己的Key调用就是发个请求而已。直到我认真把累计用量拉出来看才发现一次RAG问答的输入Token量动辄是输出Token量的五六倍而输入部分里又有大几千Token是每次都在重复发的同一段内容。1.2 最大的浪费每次都把相同前缀完整发给模型很多AI课的示例代码写法非常简单粗暴把System Prompt、检索到的文档、历史消息一股脑塞进messages然后每次都完整发给模型。模型每收到一次请求就把前面这一大段从头到尾重新读一遍Token就一分一分重新计。这里面的问题在于如果两次请求之间的差异只是末尾的问题不一样那么前面那一大段重复内容就是可缓存却没缓存的浪费。打个比方相当于你每次去打印店印材料不是拿之前印好的那份直接复印而是要求店员把整个文档重新录入一遍。花出去的时间和钱有一大半跟核心任务没关系。我们小组三个人共用一把Key第一周跑完我拉账单看到输入Token总量的时候第一反应是是不是Key被人盗了。后来发现完全没有就是重复发送导致的。1.3 免费额度和教育优惠撑不过一整个学期很多平台会给新账号一些初始额度或者一段时间的免费期但大学课程是按学期算的这门课的作业节奏是每周都有任务中间还穿插期中项目和期末大作业。我最初注册的时候还盘算过靠免费额度混过去结果一周多就见底了。教育优惠有些平台提供但覆盖不了反复调试、跑失败重试、多人共享一个Key带来的消耗。所以对这门课来说自费是绕不过去的事。既然绕不过去那就得把账算清楚。2. 缓存命中率账单里最容易被忽略的省钱杠杆2.1 Prompt Caching到底在缓存什么大模型API里提到的Prompt Caching指的是服务商把请求里相同的那部分输入前缀临时缓存起来短时间内再次请求时直接复用这部分计算结果从而降低计算开销并且把省下来的成本以更低的Token单价反馈给用户。以某主流模型的公开计费为例未命中缓存的输入Token大约是3美元/百万缓存命中的输入Token只要0.3美元/百万差了整整10倍。输出Token反而更贵通常在15美元/百万这个级别。也就是说同样发送100万个输入Token如果全部缓存命中价格只有全部未命中的十分之一。这个价差正是用缓存命中率算账单这件事的底层逻辑。这里要区分一个概念缓存的是输入前缀不是整段输入也不是输出。模型每次计算的起点是第一条消息如果前面的System Prompt、文档块、历史记录在内容上完全一致服务商就可以复用中间计算结果。只要你在中间插入了一个新的、之前没出现过的东西后面的内容哪怕有一丁点变化缓存都只能命中到变化之前的位置。2.2 命中率在账单明细里是怎么呈现的不同平台的账单命名有差异但大体上会把输入部分分成两类Cached Input缓存命中输入和Uncached Input未命中缓存输入输出单独算一行。缓存命中率在专业口径上通常定义为缓存命中率 缓存命中输入Token ÷ 总输入Token注意这里的分母只算输入不算输出。因为输出Token是模型现场生成的不存在缓存命中这回事。有些控制台会把缓存命中率直接显示成一个百分比有的平台则只给原始Token数字需要自己算。顺带说一个容易混淆的细节有些平台为了简化计费会把Token折算成Credits或积分之类的单位。表面上看不用关心单价了但账单里依然会区分缓存命中和未命中的Credits数量。你看到的几千Credits本质上还是由输入输出、命中未命中按不同倍率折算出来的不搞清楚比例照样算不准。2.3 从账单逆推实际成本的计算公式有了分类数据后一学期账单可以套一个很简单的公式总费用 未命中输入Token量 × 未命中输入单价 缓存命中输入Token量 × 缓存命中输入单价 输出Token量 × 输出单价假设某次统计周期内总输入Token量是A缓存命中率是r那么命中部分是A×r未命中部分是A×(1-r)。把它代入单价×数量就能反推出当前周期的费用构成。我实际用下来发现如果只看总价格很难判断是哪里出了问题但一旦把三类Token拆开就能看出优化空间主要藏在输入侧的命中率上。这也是我做学期账单估算时的核心思路不关心模型总共读了多少字只关心这些字里有多少是白读的。3. 用命中率做一个学期的账单估算模型3.1 先记录一学期的用量基线别凭感觉估想用命中率算学期账单第一步不是算而是先记录。你至少需要记三类数据每周API调用次数、平均每次输入Token量、平均每次输出Token量以及账单里的实际缓存命中率。我以我们小组的实际情况举例。三个人共用一个Key每周完成课程作业加实验大约产生600次API调用平均每次输入6000Token其中大约4000Token是稳定可复用的前缀System Prompt、任务背景、工具定义、固定文档块剩下2000Token是每次请求变化的部分。平均每次输出1200Token。一学期按16周计算。这些数据是后面所有估算的基础。没有这个基线你看到的任何账单数字都只是一堆孤立的价格不知道怎么拆解。3.2 输入、输出必须分开计价别只盯总Token数很多同学习惯只看总Token消耗但这样做会掩盖一个关键问题输出Token单价通常是输入未命中单价的几倍。在我上面假设的计费模型里输出单价是15美元/百万未命中输入是3美元/百万差了5倍。也就是说虽然输出Token量只有输入量的五分之一左右但输出费用和输入费用基本持平。我们小组的基线每周大约是输入360万Token输出72万Token。如果缓存命中率是0每周输入费用是10.8美元输出费用也是10.8美元总费用21.6美元。如果把命中率提到60%输入费用降到约4.97美元输出费用仍然不变总共15.77美元。看到差距了吗输出费用是固定成本你唯一能通过调用方式优化的主要是输入侧那部分。3.3 一张表看明白不同命中率下的学期账单用每周输入360万Token、输出72万Token、学期16周的数据套上第三节的公式可以得到下面这张表缓存命中率未命中输入Token(百万)命中输入Token(百万)每周输入费用(美元)每周输出费用(美元)学期总费用(美元)0%3.60010.8010.80345.6020%2.880.728.8610.80314.5040%2.161.446.9110.80283.3960%1.442.164.9710.80252.2980%0.722.883.0210.80221.18这张表很直白同样的正文内容输出命中率从0%提到80%学期总费用从345.6美元降到221.18美元省下124.42美元。如果命中率稳定在60%一学期也能省将近100美元。为了让你可以随时按自己的用量算我把这段Python脚本贴在下面改掉几个变量就能跑M 1_000_000 p_miss 3.0 # 未命中输入单价美元/百万Token p_hit 0.3 # 缓存命中输入单价美元/百万Token p_out 15.0 # 输出单价美元/百万Token weeks 16 input_tokens 3.6 * M # 每周输入Token output_tokens 0.72 * M # 每周输出Token for hit_rate in [0.0, 0.2, 0.4, 0.6, 0.8]: hit input_tokens * hit_rate miss input_tokens * (1 - hit_rate) cost_per_week miss / M * p_miss hit / M * p_hit output_tokens / M * p_out cost_semester cost_per_week * weeks print(f命中率 {hit_rate:.0%}: 单周 {cost_per_week:.2f} 美元, 学期 {cost_semester:.2f} 美元)真到了学期末我再用实际账单跑一遍这个脚本数字大差不差。它最大的价值是让你提前知道花在重复输入上的钱有多少值不值得花时间优化。4. 提高命中率的手段把Token花在刀刃上4.1 System Prompt和工具定义要做成稳定前缀想让缓存命中率高最核心的原则是请求开头的内容要尽量保持稳定。System Prompt、任务说明、背景材料、工具定义这些静态内容应该放在messages数组的最前面并且绝对不要在运行中修改。我见过很多人的代码System Prompt里带着当前时间、当前用户ID、甚至某次的随机种子。这些变量会导致前缀每次都不一样缓存完全失效。正确做法是把这些易变信息放到系统提示词后面作为用户的附加输入而不是混进System Prompt内部。我们小组第一周命中率最低的时候只有个位数就是因为System Prompt里有动态变量。把动态内容全部挪到中间偏后的位置后命中率很快就过了20%。4.2 动态内容统一放后面保留公共前缀一个容易被忽略的细节是缓存命中的是前缀也就是从第一个字符开始的连续内容。就算同样的信息出现在不同位置只要中间插了不一样的东西后续缓存就会断掉。比如RAG场景里系统提示词后面接着放检索结果再接用户问题。如果每个问题的检索结果都不同那么这些文档块之后的内容基本不会被缓存。想提高命中率可以从两个方向下手第一把每个问题都会用到的固定说明、历史消息、工具定义放在最前面第二把最容易变化的内容比如本次检索到的特定文档块放在请求靠后的位置。实际操作中我会把消息顺序固定成System Prompt → 工具定义 → 固定知识库说明 → 对话历史摘要 → 本次检索文档 → 当前问题。这样能保证前面四块内容在大多数请求里完全一致缓存能一直命中到很靠后的位置。4.3 批量作业尽量压缩进同一个缓存窗口缓存不是永久有效的服务商通常会设置一个TTL比如5分钟、1小时或者24小时不同平台差异很大。在TTL窗口内相同前缀的请求可以持续命中窗口超过后缓存会被清掉重新开始。这个机制给我们的实操提示是如果同一批作业需要在同一个知识库上反复跑实验尽量把调用放在一个连续时间段内。我和队友的做法是每周安排一个下午集中跑RAG和Agent实验而不是把实验分散到一周的各个时段。集中调用后缓存命中窗口是连续的很多请求都在TTL内命中命中率直接从20%多提到了40%以上。4.4 反直觉操作不要为了缓存硬塞长上下文缓存命中率不是越高越好这可能是最反直觉的一点。有一部分平台对缓存写入单独计费也就是第一次把输入写入缓存时可能按未命中单价甚至更高的价格收一次费用。如果你的长输入只调用一次两次那么这笔缓存写入费用就摊不薄反而不如不开缓存直接按未命中价格算。课程作业里最容易踩这个坑的场景是一次性地把巨长的论文扔给模型做摘要。这种一次长输入根本不存在后续请求来复用缓存硬开缓存只会多掏一笔写入费用。真正的优化目标是把高频复用的内容做成稳定前缀而不是把低频长内容硬塞进上下文。所以我对一学期账单的目标从来不是缓存命中率冲到100%而是在真实成本里找一个平衡点高频静态内容尽量命中低频一次性内容别硬套缓存。5. 按这套方法跑了一学期账单长什么样5.1 第1周、第8周、第16周的费用走势我把自己作为案例给你看看一学期实测下来的变化。第1周完全没有缓存意识。System Prompt里带了动态变量RAG文档块拼在中间每次请求的输入几乎都是全新的。账单显示缓存命中率只有5%左右单周费用超过20美元接近我们组的预算上限。第5周左右我开始清理System Prompt里的动态变量把静态内容固定在开头单周命中率上升到35%费用降到17美元上下。第8周是一个分水岭。我把整个消息结构重构了一遍检索结果挪到偏后位置固定知识库说明放在前面。命中率突破45%单周费用降到16美元左右。第16周也就是期末阶段各种调用模式已经稳定下来命中率基本维持在60%峰值到过65%。如果把整个学期的实际费用加总最后大约在270美元比我用0%命中率估算出来的345.6美元省了大约75美元。这还是在中间几周没有完全优化的状态下拿到的结果。5.2 命中率从17%到61%学期总账单差了多少如果按16周总账来算假设前8周平均命中率只有17%后8周通过优化达到61%那整个学期的费用大约是前8周每周19.7美元合计157.6美元后8周每周15.7美元合计125.6美元总共283.2美元。而如果整个学期都保持17%的命中率总费用约315.2美元。也就是说仅仅后半学期的优化就给小组省下了约32美元。再极端一点如果从第一周就能稳定在60%命中率学期账单会降到252美元附近比完全不优化的345美元少93美元。这93美元的价值不仅仅是一顿饭它代表的是同样的课程目标通过工程手段省掉了三分之一的开销。5.3 给准备自费上AI课的同学几条实操建议如果你马上也要上这种需要自费的AI课我的建议是第一周不要急着跑大实验先记录自己的Token用量基线。至少要知道一次典型调用会消耗多少输入、多少输出。提前给账户设置消费上限或者余额预警不然半夜跑一个Agent循环第二天早上看到账单会很难受。大段静态内容必须做成固定前缀动态内容统一放后面这是性价比最高的优化手段。批量实验集中在一个时间段跑让缓存窗口充分发挥作用。不要盲目追求缓存命中率越高越好先看自己的请求结构里有多少内容是真的重复的。重复比例低命中率再高也没意义。充值建议小步多次不要一次性充太多方便随时根据账单调整实验方式。最后说一点个人体会。算Token账单这件事表面上看是在跟几美元几美元较劲实际上练的是一个非常值钱的工程能力成本意识。写代码的时候知道哪些资源是重复消耗的哪些逻辑可以复用这比省下几十美元重要得多。如果你也要自费跑整个学期的AI实验不妨认真把缓存命中率这件事搞明白它会让你的账单和代码结构都干净不少。