最近有个在某创业公司做 AI 应用的朋友找我智能客服上线三个月用户没涨多少账单倒是涨得飞快。他把后台拉出来给我看一个月光模型调用费就好几万里面有接近一半的输入是每次都在重复的那套系统提示词。我问他平时有没有关注过提示缓存他愣了一下问我那是什么。这大概就是问题所在大多数团队在用大模型 API 做产品时把注意力全放在提示词效果和用户体验上完全忽略了成本结构里最容易优化的一环。提示缓存英文一般叫 Prompt Caching简单说就是把请求里重复出现的那部分内容在服务端存下来下次请求如果前缀一致直接复用中间计算结果而不是重新推理一遍。这件小事不改变你的产品逻辑不改变提示词的输出效果却能明显压低账单。这篇文章我会从成本账讲起把提示缓存的工作原理、配置方法、提示词优化策略以及我在真实项目里踩过的坑完整拆一遍。无论你做的是客服机器人、内容生成工具还是企业内部知识库问答只要你的应用在反复调用同一个模型接口这篇文章都值得你花十分钟看完。1. 先算一笔账你的AI应用到底贵在哪1.1 你每次调用到底在付什么钱主流大模型 API 基本都按 token 计费。token 可以粗略理解成被切碎的字或词英文一个单词可能被拆成几段中文的几个字也可能合并成一个 token。你发送给模型的全部内容包括系统提示词、历史聊天记录、用户当前输入一般按输入 token 计费模型生成返回的内容按输出 token 计费。两者的单价不一样输出 token 通常更贵这也是为什么很多人一让模型生成大段文字就肉疼。但真正容易被忽略的是输入这一块的结构。很多人以为模型请求的输入就等于用户打的那句话其实远不止。为了让 AI 像一个有角色、有规矩、有记忆的助手你往往要在每次请求里塞入一整套系统提示词里面包含角色设定、业务规则、工具说明、few-shot 示例、输出格式要求。做客服、知识库、自动化流程这类场景时这部分内容动辄几千 token非常常见。问题在于这些提示词在每次请求里几乎一字不改。你的用户换了、问题换了、会话换了那套系统提示词还是原封不动地再发一遍。模型服务商对每个请求都是独立处理的只要你把内容发过去它就按照输入 token 收一次钱。哪怕这个提示词昨天已经被同一个账号处理过一万次今天你发第一万零一次它不会认识你依然按全新输入收全价。1.2 重复计算才是账单刺客我经常用一句话概括这个问题你相当于雇了一个员工每天上班第一件事是把公司规章制度从头到尾朗读一遍读完才能开始干活。这个朗读过程不产生任何新价值但工资是照付的。模型推理也一样固定的系统提示词反复进入模型前向计算一遍遍重新执行算力被消耗费方买单。这就是重复计算带来的账单刺客。很多 AI 应用的功能并不复杂单次调用模型生成的内容也不长但成本却居高不下秘密就在于每次请求背负着一个巨大的、重复的输入包袱。在对话类应用里系统提示词加上多轮历史记录往往能达到几千甚至上万 token。用户问一句几十 token 的话你却要为几千 token 的上下文买单。换个角度算如果请求次数上来了比如一天几万次那固定提示词部分的输入 token 就是天文数字。这部分钱本可以通过缓存省掉大头却因为没做任何处理老老实实全额计费那账单自然就会吓人。所以我一直觉得AI 应用成本高很多时候不是模型定价的问题而是调用姿势的问题。1.3 一组数字直观感受我们编一个尽可能贴近实际的模型账号来估算。某智能客服机器人系统提示词 800 token工具说明和业务规则 200 token用户提问平均 100 token。每天被调用 1 万次。日输入 token 总数大概是(800 200 100) × 10000 1100 万 token/天其中真正不一样的动态输入只有 100 万 token剩下 1000 万 token 是每次重复发送的固定指示。假设这个模型平台的普通输入价格按 3 元每百万 token 估算缓存输入按 0.6 元每百万 token 估算账就很好算了。场景每天输入 token估算单价元/百万token每天输入费用完全不启用缓存1100 万333 元启用缓存固定提示命中1000 万按缓存价100 万按普通价0.6 / 39 元理想情况固定提示不收费仅作示意100 万33 元换算成月度就是 990 元对 270 元的差别一个月省下七百多块。这还只是一个中规中矩的客服机器人固定提示词只有 1000 token。如果系统提示词加到 3000 token日调用量到 5 万次能省的就不是几百而是每个月几万块。很多人没概念是因为从没见过模型服务商后台的缓存命中指标只知道欠的账单没变少。2. 提示缓存到底干了什么2.1 先从大模型的生成过程说起要把缓存机制讲清楚得简单看一下大模型是怎么回答问题的。现在主流的大模型基本都是 Transformer 架构输入内容会先经过分词、向量化然后进入数十层神经网络。在每一层里有一个关键操作叫自注意力机制简单理解就是每个词都要和其他所有词建立关联计算彼此之间的相关性权重才能理解整个句子和上下文。这个计算过程里每个位置的词都会产生一组键Key和值Value用来参与后续注意力分数的计算和加权。问题在于模型生成内容是一个词一个词蹦出来的生成第 10 个词时它需要回头结合前 9 个词的信息生成第 100 个词时又把前 99 个词的信息都调出来。如果不做缓存每一次生成都要把整个输入序列的 Key 和 Value 从头算一遍。序列越长重复计算的浪费就越严重。提示缓存的核心就是把这些 Key 和 Value 计算出来以后暂存在内存里。下次遇到完全相同的输入前缀不用再一次次前向计算直接把存好的结果取出来用。这就好比你是分析师第一次算季度数据时把所有中间步骤写在草稿纸上第二季度处理同一套底层数据时不需要从零开始重新计算直接抄草稿纸上的结果就行。2.2 缓存的命中条件提示缓存不是什么魔法它要求缓存系统能够精确判断这次请求和之前的某个请求有共同前缀。绝大多数服务商的实现方式都是按输入 token 序列的前缀去做匹配。也就是说你的请求开头部分必须和之前的某次请求完全相同完全相同到每一个 token、每一个空格、每一个标点都不能差。只要前缀一致缓存就能命中后面的 Key 和 Value 直接复用。哪怕用户消息一直在变只要变化的部分出现在请求尾部前面的大段静态提示词和工具说明就能稳稳命中。反过来如果你在提示词开头放了时间戳、随机数、用户 ID 这类每次都会变的内容整个前缀就漂移了缓存直接失效后面写再多的固定规则也救不回来。这里有一个很多人容易误解的点提示缓存不是只缓存你手动标记的某一段内容而是以整个请求前缀作为粒度去缓存。它的判断天然是从头开始能匹配多长就匹配多长。2.3 缓存省的不只是钱首先最直接的是省钱。缓存命中的输入部分计费价格远低于普通输入价格。有的服务商打折力度大差距可能接近十倍。对重读型应用输入占比高缓存带来的降本效果非常明显。其次是降延迟。第一次请求要完整计算整个模型前向过程生成首字的延迟会比较明显。缓存命中后重复前缀那部分计算直接跳过模型只需要处理末尾新增的动态内容首 token 延迟能明显下降有时从一秒级降到几百毫秒甚至更低。用户体感就是应用变快了这对对话类产品的交互体验是个不小的加分项。第三是提高后端吞吐稳定性。同样一台推理机器处理 5000 token 的输入和 50 token 的输入计算量完全不同。启用缓存后固定提示词不再反复占用算力你购买的并发套餐能支撑更多真实业务请求。换句话说同样的基础设施成本能扛住更大的调用量这在系统容量规划上也很有价值。3. 实操打开缓存并验证收益3.1 第一步确认你的模型服务是否支持不同模型服务商对提示缓存的开放程度不一样有的默认开启有的需要手动开启有的只在特定模型、特定接口上支持。你做的第一件事是去你对接的服务商控制台或者 API 文档里搜关键词提示缓存、上下文缓存、Prompt Caching、Context Caching都会有说明。先确认你的账号套餐、模型版本是否在这一功能的支持清单里。有些付费套餐和免费套餐在缓存能力上有差别有些模型的上下文窗口对缓存长度有限制。反正别想当然先在文档里确认清楚再动手。确认支持之后找到缓存开关的位置。一般在控制台的模型服务配置里或者在 API 请求参数里。如果控制台能找到开关优先打开如果只能在代码里传参控制看下一步。3.2 第二步在代码里正确传参这里我写一个演示用的 HTTP 请求示例具体字段名以你实际对接的服务商文档为准。实战中我见过很多开发者在框架里配了一个参数结果根本没传进请求体白忙活半天。正确做法是先抓包或者打日志确认请求体里真的带了缓存相关字段。import requests API_URL https://api.your-ai-service.example/v1/chat/completions HEADERS {Authorization: Bearer YOUR_API_KEY} SYSTEM_PROMPT 你是一名智能客服负责处理用户的售后问题。 规则 1. 用户问价格相关问题先引导查看订单详情。 2. 用户情绪激动时需要先安抚情绪。 3. 所有回答控制在200字以内。 def call_with_cache(user_input): payload { model: your-model-name, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input}, ], cache: { enable: True, prefix_id: customer-service-v2 } } resp requests.post(API_URL, headersHEADERS, jsonpayload) data resp.json() usage data.get(usage, {}) print(输入token:, usage.get(prompt_tokens)) print(缓存命中token:, usage.get(prompt_cache_hit_tokens)) print(缓存未命中token:, usage.get(prompt_cache_miss_tokens)) return data看到prompt_cache_hit_tokens这个字段了吗你只要打印请求返回的 usage 信息就能直观看到每一次请求里有多少 token 是从缓存里读出来的。如果这个字段一直为 0说明你的提示词前缀没有做到稳定命中一直失败需要回到提示词工程上去优化结构。3.3 第三步用日志和指标验证收益把代码改完不要急着上线先在测试环境发几条完全相同的请求确认第二次请求的命中字段有值。然后连续发几条前缀相同、后缀不同的请求观察命中情况。记录接口返回的首字响应时间对比第一次请求和后续请求的差距。上线之后在模型服务商的成本分析页面看缓存命中率趋势。我建议你至少监控这几个指标提示词 token 总量、缓存命中 token 数量、缓存未命中 token 数量、缓存节省金额。把这些值做成日报观察一天内不同时段的命中率波动。如果命中率稳定在一个比较高的水平账单曲线自然会往下掉。这个验证过程不需要很复杂但一定要做。我见过太多团队把缓存开关打开就以为万事大吉结果过了两周发现命中率只有 5%成本根本没什么变化。原因往往就藏在提示词结构里不验证是发现不了的。3.4 一个可以照抄的验证脚本给你一个简单的验证脚本把系统提示词固定一个常量循环发送几个不同的用户问题把每次返回的缓存命中字段打出来。这个脚本不一定适配你家服务商但结构可以参考。import requests import time SYSTEM_PROMPT 你是一个负责解答产品使用问题的助手。回答请简洁不超过两句话。 def send(user_input): payload { model: your-model-name, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input}, ], cache: {enable: True}, } resp requests.post( https://api.your-ai-service.example/v1/chat/completions, headers{Authorization: Bearer YOUR_API_KEY}, jsonpayload, ) data resp.json() usage data.get(usage, {}) return usage.get(prompt_tokens), usage.get(prompt_cache_hit_tokens) if __name__ __main__: for question in [你好, 怎么退款, 可以开发票吗]: hit send(question)[1] print(f问题: {question} | 缓存命中token: {hit}) time.sleep(1)如果你发现第一轮发送就出现大量命中那可能是之前的请求已经建立了缓存这是正常现象。如果三轮命中都很低你就该检查系统提示词是不是真的原样发送了。4. 提示词工程让缓存命中率翻倍4.1 把静态前缀和动态内容彻底拆开提示缓存对前缀的稳定性要求极高所以你的提示词结构必须刻意设计。我把提示词分成两类一类是静态内容包括系统角色、业务规则、工具说明、few-shot 示例、输出格式要求另一类是动态内容包括用户当前问题、当前时间、用户 ID、日志快照等。最佳实践是静态内容全部放在请求的最前面动态内容一律往尾部塞。拿一个客服机器人举例理想结构是messages [ {role: system, content: 你是客服助手规则如下...}, {role: assistant, content: 好的我明白了。}, # 固定示例 {role: user, content: f当前时间{now}\n用户ID{user_id}\n问题{question}} ]这里系统提示词和第一条助手示例都是静态的用户问题和各种动态信息被放到最后一条消息里。只要 system 部分一字不变缓存就能稳定命中前面那几百上千 token。如果你懒得区分直接写了一个 f-string 把当前时间放在 system 提示词第一行那缓存命中率基本归零。4.2 多轮会话里的缓存复用对话类应用会出现一个疑惑会话越聊越长历史消息不断追加缓存还能用吗答案是可以的。缓存匹配的是前缀只要你的消息列表前面部分不变后面多几条历史消息没关系。系统提示词在最前面前缀稳定整个历史对话作为后续内容一起参与匹配缓存命中会作用于那段已经稳定的部分。所以多轮会话的正确做法是保持消息列表按时间顺序稳定追加不要做任何花式重排。我见过有些团队为了优化上下文利用效率每次请求前把历史消息按某个规则重新排序或者把前面的 assistant 回复截断拼接结果导致前缀发生了细微变化缓存大规模失效。这属于典型的画蛇添足。如果你用了某个现成的编排框架要格外小心模板动态拼接。不要以为框架生成的提示词结构就是合理的很多模板默认把时间、用户信息放在开头你需要主动去改模板把静态内容前移、动态字段后置。4.3 一个改造示例某客服项目的前后对比我拿一个实际改过的模拟项目来演示。项目背景是某个内部客服问答系统面向公司员工解答行政制度问题。一开始开发同学图省事把所有信息揉进 system 提示词里messages [ {role: system, content: f当前时间是{now}你是行政助手。员工姓名是{user_name}。 你负责解答考勤、报销、休假等问题。规则如下...}, {role: user, content: question} ]这个写法的致命伤是当前时间和员工姓名放在开头每次请求的前缀都在变缓存命中率基本为 0。而且如果员工姓名在 system 里出现不同员工请求的开头还不一样服务商即便想缓存也无能为力。改造之后是这样messages [ {role: system, content: 你是行政助手负责解答考勤、报销、休假等问题。规则如下...}, {role: user, content: f员工姓名{user_name}\n当前时间{now}\n问题{question}} ]改动就几行效果是系统提示词变成完全静态的常量缓存命中率从接近 0 一路涨到 80% 以上。后台里那一大块重复输入的计费直接按缓存打折价结算了。这个案例里省下的具体金额不说了但你可以对照自己的输入 token 占比算一下这个改动的性价比高得离谱。4.4 提示词的版本管理也会影响缓存还有一个实操中的隐藏坑提示词迭代太频繁。你今天改一个字明天调一句话每次改动都会让缓存的旧前缀全部失效。改完之后线上请求会经历一段缓存冷启动期命中率突然掉下来然后慢慢恢复。这个成本也许不大但你要心里有数。我一般建议团队把系统提示词当作正式代码来管理放进版本控制每次改动走审批流程不要在线临时改。同时如果希望减少提示词变更带来的缓存爆炸尽量把可能经常变的规则放在靠后的位置把最稳定的角色定义放在最前。这样当你调整某条业务规则时影响到的只是缓存长度变短了一点点而不是整段前缀全部失效。5. 常见问题与避坑清单实录5.1 命中率很高为什么账单还是没降多少我遇到过这种情况后台显示缓存命中 token 数量不少但最终账单里费用变化不明显。排查下来原因可能是你的实际成本大头在输出 token。缓存只作用于输入侧模型生成的输出 token 该花多少钱还是花多少钱。如果你的应用每轮让模型生成大段文章、长报告输出成本远超输入成本那么优化输入缓存的收益就会显得有限这并不代表缓存没生效。另一个可能更麻烦你看到的命中指标是服务商某个统计维度不是真正的计费维度。有的平台在接口返回里会标注缓存 token但账单明细里对这部分是否打折、按什么折扣逻辑不一定对得上。我建议你直接对比启用缓存前后两周的账单而不是只看单一指标。如果输入成本曲线明显更平缓说明方向对了。5.2 前缀微小差异导致缓存全盘失效缓存失效最常见的原因是提示词里有不可见字符差异比如多一个空格、多一个换行、中文标点和英文标点混用。你眼睛看过去觉得一模一样但 token 化之后就是两个完全不同的序列。特别是从配置文件读取提示词时换行符在不同系统下的写法不同Windows 的 CRLF 和 Linux 的 LF 都会被当成不同内容。解决办法是把系统提示词统一放到配置中心或者独立文件里禁止在业务代码里用字符串拼接动态生成。如果实在要拼接也建议写一个统一的提示词构建函数内部集中处理格式。我在几个项目里都吃过这个亏排查了半天最后发现是某次部署时换行符被开发工具自动转了一遍缓存直接全部失效。5.3 系统提示词更新后命中率骤降怎么办如果你需要定期更新系统提示词比如每天换一套新闻热点规则那缓存命中率骤降几乎是必然的。但这不代表无解。一个做法是尽量把变化的部分压缩到最小粒度把稳定的角色定义放在前面变化的规则放在后面让缓存依然能命中前面那一段。另一个做法是错峰发布在业务低峰期更新提示词让缓存重建发生在流量小的时候降低对成本和延迟的影响。还有一点要提醒不要为了省成本而硬扛着不更新提示词。缓存省的只是重复计算的费用业务效果始终是第一位的。该调整规则就调整把缓存成本当成一次性的提示词刷新代价可控且值得。5.4 缓存不是万能监控和预算 buffer 必须有提示缓存的命中并不保证百分之百稳定。服务端可能因为内存压力淘汰缓存也可能因为模型版本升级导致缓存规则变化。业务高峰期大量请求同时打到模型侧也可能出现缓存尚未完全建立的阶段。所以不要把系统完全押注在缓存命中率上账单预算里留出 10%-20% 的缓冲余量比较稳妥。我的习惯是给成本监控配几条告警日消耗异常上涨、缓存命中率连续多日下跌、缓存命中 token 归零。这三条基本能覆盖掉绝大多数成本突变的情况。特别是命中率归零这种极端情况很可能说明服务商侧的缓存策略变了或者你的提示词模板被人改了一刀早发现早处理别等月底账单出来才傻眼。5.5 速查表常见问题与建议处理方式现象可能原因建议处理方式命中字段一直为 0前缀漂移、提示词每次变化把动态内容移到末尾固定前缀设为常量命中率很高但账单没降输出 token 成本占比高检查输出统计优化生成长度提示词一改命中率暴跌修改导致前缀整体失效规则后置版本控制提示词缓存命中忽高忽低服务端淘汰缓存、负载波动预留预算 buffer监控告警日志显示 token 数一样费用对不上计费逻辑与缓存折扣不透明对比前后账单核对文档我个人到现在的体会是提示缓存不是一个后期优化而应该在系统设计的第一天就写进约定。它和代码怎么写、提示词怎么组织强相关。把静态提示词当成公共接口来维护把动态内容永远放最后这两条规矩立住了缓存基本就是白拿的收益。尤其是现在很多模型平台的缓存价格低得惊人同样的骨干功能别人可能只是调整了一下提示词顺序成本就比你低了几个身位。谁先把这个细节做好谁就能在同等预算下跑更久的业务、支撑更多的用户。这不是什么高深的算法就是一个很朴素的事实别让模型每次都在重复劳动。