上个月底的模型服务计费后台让我有点坐不住了——一个日活不到两百人的内部文档问答工具账单比上个月翻了将近四倍。翻完调用日志原因并不复杂大量请求在问相似的问题而每一次请求都在为完全相同的系统提示词和检索上下文全额买单。这不是孤立现象。企业团队内部的客服知识库、资料问答、代码辅助工具个人开发的写作助手、信息整理机器人只要业务形态是同一批资料回答有限类型的问题就必然存在大量可复用的中间结果。当时我们既没有做缓存策略平台选型也几乎是随手下单等于每一份重复劳动都在按原价付费。这篇文章把我实际梳理过的一整套大模型API成本优化路径完整写出来包含三层缓存设计、语义缓存的落地调参与完整代码以及企业团队和个人开发者两个视角下的平台选型框架。适合正在被接口账单困扰、又不想一上来就自建模型服务的团队和个人。我不会推荐任何具体供应商但会把评估平台的关键维度讲清楚你直接套用即可。1. 先看计费结构重复请求为什么在偷偷烧钱1.1 输入token才是账单里的隐形大头很多人盯模型API账单时第一反应是看输出价格贵不贵却忽略了一个事实在实际业务里输入token的总量通常远大于输出token。举一个典型的检索增强问答场景。一次请求的构成大概是系统提示词约300 token检索回来的知识片段约1800 token用户问题约50 token模型输出约400 token按一个主流商用模型的常见计费口径输入约0.012元/千token输出约0.036元/千token。那么单次调用成本是输入部分(300 1800 50) / 1000 × 0.012 0.0258元输出部分400 / 1000 × 0.036 0.0144元单次合计约0.04元如果每天1000次请求一个月就是约1200元。注意看输入token占了总成本的64%而输入里又有接近九成是重复的检索上下文和固定的系统提示词。这些内容只要稍微缓一缓成本立刻就能降一个量级。1.2 我在实际项目里观测到的重复请求占比光讲理论没用说一组我实际观测到的数据。某内部客服知识库项目巅峰期每天约2万次模型调用。我先把请求按规范化后的文本做精确去重去掉空格、标点差异再按原文比对发现有约25%的请求完全重复。接着引入语义相似度比对把如何修改手机号和怎么更换绑定的手机号码这类不同问法识别出来又能再覆盖约20%的请求。两项加起来大约有40%到45%的调用是可以被缓存直接挡掉的。这个比例在垂直领域知识库类应用里非常典型。当然如果业务是开放式闲聊或高频个性化生成重复比例会大幅下降但即便如此系统提示词和工具调用结果这类固定内容依然有缓存空间。1.3 从计费结构反推缓存切入点理解了成本构成缓存切入点就清晰了。大模型API账单由三部分组成输入token费用、输出token费用、调用次数带来的隐性成本限流重试、超时重试、并发扩容。缓存策略要同时照顾这三方面输入token重复靠检索结果缓存和服务端前缀缓存解决输出token重复靠响应级缓存解决调用次数下降自然降低限流概率和重试成本。这里有个关键认知缓存不是把成本从必花变不花而是把重复花变只花一次。你的资料不更新、业务规则不变化时完全相同的答案反复生成本身就是资源浪费。2. 三层缓存设计精确命中、语义命中和服务端自动缓存2.1 第一层精确缓存零风险先做精确缓存是所有方案里风险最小的它只在请求完全相同时才命中不会出现答非所问的情况。缓存键的设计是核心。不要只拿用户问题做key至少要把以下几个维度拼进去模型名称与版本号比如model:v3系统提示词版本建议单独维护版本号不要直接拼全文采样参数主要是temperature和top_p用户问题本身用一段简单的Redis代码就能实现import hashlib import json import redis r redis.Redis(hostlocalhost, port6379, db0) def exact_cache_key(model, system_version, temperature, user_query): raw f{model}|{system_version}|{temperature}|{user_query} return llm:exact: hashlib.sha1(raw.encode()).hexdigest() def get_exact(key): data r.get(key) return json.loads(data) if data else None def set_exact(key, answer, ttl3600): r.set(key, json.dumps({answer: answer}), exttl)注意一个容易踩的坑如果业务里temperature设成了0.7甚至更高同一个问题每次回答都不一样精确缓存反而会把一次随机的输出固化下来用户下次再问时拿到的是完全不同的内容体验会很怪。所以精确缓存通常配合低温度参数使用或者只对明确要求稳定答案的接口开缓存。2.2 第二层语义缓存省钱的真正大头精确缓存挡不掉换一种说法问同一个问题这类请求。自然语言的特点就是同一个意图有无数种表达方式中国人还特别习惯把一句话拆成前后两段补充。语义缓存的思路是把用户问题向量化和已经缓存过的问题向量做相似度比对相似度超过阈值就直接返回缓存答案。这样如何修改手机号和怎么更换绑定的手机号码虽然在文本上完全不同但在向量空间里距离很近可以被识别为同一个意图。语义缓存的收益我上面提过每天2万次调用的项目里精确缓存吃掉25%语义缓存又额外吃掉20%。这完全是净省下来的真金白银。但语义缓存也引入了新风险语义相似不等于意图相同后面第6章我会专门讲一起因为相似度误判导致的线上事故。2.3 第三层服务端自动缓存很多人没注意到的福利绝大多数人不知道的是部分模型服务商对重复的前缀token有自动缓存机制。同一段系统提示词和检索上下文反复提交时服务端会在内部保留这部分计算状态后续请求里这些token会按更低的缓存命中价计费而不是每次都重新全量计算。这一层不需要你写任何代码但它有一个硬性前提你的prompt前缀必须是稳定的。实际利用方式有几个把系统提示词固定放在最前面不要和动态上下文混排检索上下文尽量用固定的模板结构比如参考资料{content}\n问题{query}模板部分稳定只有content变化同一个业务的prompt模板不要频繁改版每次改版都会让前缀缓存失效需要注意的是这类缓存是按文本前缀匹配的不是按语义。只要prompt开头有一点动态变化整段前缀缓存就全部失效。所以设计prompt模板时把可变内容尽量往后放让不变的指令部分尽量长。3. 语义缓存落地实录技术选型、代码和阈值调参3.1 向量索引放哪里从小内存到专业向量库语义缓存需要一个能存问题向量的地方选型取决于数据规模。规模推荐方案理由缓存条目1万以内本地内存或SQLite实现简单零运维个人项目首选1万到几十万Redis本身就在常见技术栈里支持持久化性能和运维成本的平衡点百万级以上专业向量数据库或带向量索引的搜索引擎需要索引构建和分片能力一般团队用到这个规模时已经有专职基础设施我的建议是别一上来就上专业向量库。语义缓存刚落地时绝大多数团队连一万条缓存都不一定有用Redis甚至内存列表完全够用。等命中量真的涨上来了再迁移也不迟迁移的成本不过是把向量导出再灌进新库。3.2 完整代码一个可直接改用的语义缓存模块下面的实现基于Redis存向量适合中小规模项目我拿Python写了一个可直接改用的版本import hashlib import time import redis import numpy as np from sentence_transformers import SentenceTransformer r redis.Redis(hostlocalhost, port6379, db0) # 选择一个对中文支持较好、参数量适中的语义向量模型 model SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) CACHE_TTL 24 * 3600 SIMILARITY_THRESHOLD 0.92 def _embed(text: str) - np.ndarray: return model.encode(text).astype(float32) def _cosine_sim(a: np.ndarray, b: np.ndarray) - float: return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b) 1e-9)) def semantic_get(query: str): qv _embed(query) best_key None best_score 0.0 for key in r.scan_iter(sem:vec:*, count1000): stored np.frombuffer(r.get(key), dtypenp.float32) score _cosine_sim(qv, stored) if score best_score: best_score score best_key key if best_key is not None and best_score SIMILARITY_THRESHOLD: ans_key best_key.decode().replace(sem:vec:, sem:ans:) data r.hgetall(ans_key) if data: return { hit: True, score: round(best_score, 4), answer: data.get(banswer, b).decode(), cached_at: data.get(bcached_at, b).decode(), } return {hit: False, score: round(best_score, 4)} def semantic_set(query: str, answer: str): qv _embed(query) qhash hashlib.sha1(query.encode()).hexdigest()[:16] r.set(fsem:vec:{qhash}, qv.tobytes(), exCACHE_TTL) r.hset(fsem:ans:{qhash}, mapping{ answer: answer, cached_at: int(time.time()), }) r.expire(fsem:ans:{qhash}, CACHE_TTL)接入业务时的用法import requests def chat_with_semantic_cache(user_query: str) - str: cached semantic_get(user_query) if cached[hit]: return cached[answer] resp requests.post( https://api.example-llm-service.com/v1/chat/completions, headers{Authorization: Bearer sk-xxxx}, json{ model: model-a, messages: [{role: user, content: user_query}], temperature: 0.2, }, timeout30, ) answer resp.json()[choices][0][message][content] semantic_set(user_query, answer) return answer这个版本有两个明显的简化生产用之前要补scan_iter遍历在缓存条目多时很慢建议用Redis的向量搜索能力替代全量扫描上面只按问题文本做key忽略了模型版本、prompt模板版本等维度我建议把sem:vec:的key前缀带上业务标识比如sem:vec:v3:r1:这样升级模型后旧缓存自动隔离。3.3 相似度阈值校准不要直接抄网上的参数语义缓存最重要的参数就是相似度阈值。设高了命中率低缓存形同虚设设低了不同意图的问题会被错误匹配返回错答案。网上一搜教程很多人直接写0.90或者0.95这种做法风险很大。阈值和你的业务场景、问题集分布强相关必须拿自己的真实数据校准。我的校准方法是收集过去一个月用户真实问题挑出100条高频的和50条容易混淆的比如怎么退款和退款到账要多久先用0.95跑一轮看高频问题里能命中几条。如果命中率很低说明阈值偏高逐步降到0.93、0.92、0.90每一档都检查混淆问题集里有没有误命中找到高频问题命中率可接受且混淆集零误命中之间的最大阈值按我的经验在垂直领域知识库类业务里最终阈值通常落在0.90到0.93之间。金融、医疗、账号操作这类高风险场景我会再保守一点甚至对操作类问题直接旁路缓存。提示不同向量模型的相似度分布差异很大换模型后阈值必须重新校准原阈值不能平移。3.4 TTL与失效策略不同业务给不同寿命缓存不是存得越久越好TTL设计要跟着业务稳定性走。业务类型建议TTL说明事实型知识库问答24小时到7天资料更新时主动按文档ID失效客服话术2小时到24小时活动、政策信息变化快代码生成10分钟到1小时依赖库版本迭代频繁个性化推荐、私人助理不做缓存响应必须贴合用户个体上下文还有一个容易被忽略的点主动失效比等TTL过期更靠谱。知识库里的某个文档被编辑了所有引用了该文档的缓存都应该失效。简单的做法是在语义缓存的answer里额外存一个data_version字段请求时比对当前资料版本号不一致就直接当缓存未命中处理。4. 平台选型七个维度价格之外更值得较真的指标4.1 七个维度的评估框架平台选型不能只看单价很多团队选完才发现被限流、延迟和协议问题折磨得够呛。我评估一个模型API平台时固定看下面七个维度维度要问的问题为什么关键单位价格输入输出分别多少钱有没有缓存命中价决定单次调用的直接成本限流与配额RPM、TPM是多少超了是报错还是排队决定了你的业务天花板延迟与稳定性p50、p99延迟多少过去一个月有没有大面积故障直接影响用户体感和重试成本上下文长度最大支持多少token超长上下文怎么计费检索增强场景的硬约束数据协议请求数据是否用于训练是否允许缓存、存储关系到合规不能含糊生态兼容性是否兼容主流API协议格式能不能平滑换模型降低切换成本和供应商锁定风险计费透明度账单是否可按model、按日期、按标签拆开看没有透明账单就没法做成本治理这里多说一句缓存命中价。前文提到的服务端前缀缓存有些平台会直接体现在计费口径里——重复前缀的token按更低价格结算。选型时记得把这一项问清楚因为它直接决定第2章说的第三层缓存红利你能吃到多少。4.2 三类服务形态的适用边界现在的模型API服务大致分成三类各有各的适用场景官方直连服务质量最稳定上下文支持和计费最透明但价格最高适合生产环境核心链路。聚合转发平台把多家模型聚合到一个入口价格通常有折扣且支持模型间切换。但稳定性取决于平台自身数据协议需要仔细读适合个人开发者和原型验证阶段。开源自托管用自有算力部署开源模型一次性投入硬件成本调用量大时边际成本很低。适合有一定运维能力、且对数据隐私要求极高的团队。我的判断标准很简单核心业务用直连实验和爆量场景用聚合平台有稳定高调用量且数据敏感的自托管。三类不是互斥的完全可以混用。4.3 用几十行脚本做候选平台小压测选型的最终拍板不能只靠看文档要实际压一下。我每换一个平台候选都会先跑一个简单的并发脚本观察三个指标成功率、p99延迟、超限时的报错行为。下面是一个最小化的压测脚本用协程同时发200个请求import asyncio import time import aiohttp URL https://api.example-llm-service.com/v1/chat/completions HEADERS {Authorization: Bearer sk-xxxx} PAYLOAD { model: model-a, messages: [{role: user, content: 用一句话介绍你自己}], temperature: 0.2, } async def one_call(session, idx): t0 time.time() try: async with session.post(URL, jsonPAYLOAD, headersHEADERS, timeout30) as resp: latency time.time() - t0 return {idx: idx, ok: resp.status 200, latency: latency, status: resp.status} except Exception as exc: return {idx: idx, ok: False, latency: time.time() - t0, status: str(exc)} async def main(): async with aiohttp.ClientSession() as session: results await asyncio.gather(*[one_call(session, i) for i in range(200)]) ok [r for r in results if r[ok]] latencies sorted(r[latency] for r in ok) print(success:, len(ok), / 200) print(p50:, round(latencies[len(latencies) // 2], 3)) print(p99:, round(latencies[int(len(latencies) * 0.99) - 1], 3) if ok else N/A) errors [r[status] for r in results if not r[ok]] print(error samples:, errors[:5]) asyncio.run(main())这个脚本测出来的结果比看任何宣传文档都有用。特别是超限报错那一项有的平台超了直接返回429有的平台会悄悄排队这两种行为对你的重试逻辑影响天差地别。还有一点要提醒压测时顺手把同一个请求发两次对比两次的计费记录能看出来平台有没有隐藏的额外收费。口径不透明的平台后续做成本治理时会很痛苦。5. 企业团队和个人开发者的两条优化路线5.1 个人开发者先缓存、再分级、最后才谈并发个人开发者的资源有限没有专职运维成本优化路线应该按投入产出比排序先做精确缓存。改造成本最低两个晚上就能上线能吃掉25%左右的重复调用。再做语义缓存。引入向量化后能再省20%但需要维护一个向量模型和缓存存储。然后用轻量模型分流。简单任务摘要、分类、关键词提取优先走本地小模型或低单价模型只有复杂推理才调用大模型。最后设置预算硬上限。在模型服务后台把月度消费上限设好超了自动熔断避免某天循环调用失控。个人项目的另一个实用技巧是把缓存逻辑单独抽成一个模块不管后面换不换平台这层都能复用。我见过太多人换一次模型供应商缓存代码也跟着重写一遍完全是浪费。5.2 企业团队网关、路由、成本分摊一个都不能少企业团队的问题不是有没有缓存而是团队里每个项目各自接API账单混在一起根本没法治理。我建议的落地方案是搭一个统一模型网关所有业务线的请求都走这里缓存统一管理精确缓存和语义缓存收敛到网关层各业务线不用各自实现一遍模型路由网关根据请求的意图和复杂度自动分发给不同价位的模型多Key轮转和配额隔离不同的业务线用不同的API Key互不影响调用日志与成本分摊每条请求打上业务线、功能、请求来源等标签月底按标签出账单网关层多花两个月的开发时间但之后的每一次模型降价、换供应商、调整路由策略都只改网关一处全公司生效。这个投入非常值。5.3 组合拳混合架构的收益量化把上面所有手段组合起来是一个类似这样的链路客户端请求 → 统一网关 → 语义缓存查询 → 模型路由决策 → 调用外部平台或自托管模型 → 回写缓存这个架构里缓存命中率通常能到40%到50%路由分流又能把剩下请求里七成的简单任务导向轻量模型。最终账单里被大模型重计算的请求可能只剩原来的两成左右。这和二八法则很像业务里20%的复杂请求贡献了80%的核心成本剩下的80%普通请求完全可以用缓存加轻量模型覆盖掉。做成本优化的核心就是把这80%里能省的部分都省下来。6. 缓存踩坑实录击穿、误判和隐私边界6.1 缓存击穿活动开始的同一秒所有请求一起打向API语义缓存上线后容易遇到一种状况某个热点问题突然爆发比如产品发布公告、故障公告缓存里没有对应条目成千上万个请求在同一秒涌向模型API。后果是限流、超时、账单飙升三连击。这其实就是经典的缓存击穿问题一个热点key失效或未命中时所有并发请求都穿透到后端。解决思路有三个按成本从低到高单飞模式single-flight同一时刻同一个key只允许一个请求真正调用API其他请求等待这个请求的结果拿到后直接复用。单机场景用线程锁就能实现多机节点需要用Redis分布式锁。热点预加载运营已知的热点问题提前手工塞进缓存。TTL抖动给缓存TTL加上一个随机偏移量避免大量缓存条目在同一时刻集体过期。单飞模式的一段示意代码import threading call_locks {} def one_at_a_time(query, api_func): lock call_locks.setdefault(query, threading.Lock()) with lock: if (cached : semantic_get(query))[hit]: return cached[answer] answer api_func(query) semantic_set(query, answer) return answer注意这个锁要加在查缓存和调用API之间的整个临界区里否则两个请求先先后后通过检查又双双发起API调用就失去意义了。6.2 相似度误判一次关闭变开启的事故这是我踩过最疼的一个坑。某客服工单系统接入语义缓存后第一天就出了事故。用户甲问我要关闭自动续费系统生成了关闭流程的答复并写入了缓存。半小时后用户乙问我要开启自动续费两句文本在语义向量空间里的相似度高达0.94直接命中了缓存返回了已为您关闭自动续费。这事的教训是语义相似不等于意图一致在一些关键动作上相似反而可能是相反的。开启与关闭、删除与恢复、同意与拒绝这些操作词在向量空间里经常非常接近。修复方案我总结为三条对包含操作意图的query做意图预分类先判断属于查询类还是操作类。操作类请求一律旁路缓存在缓存key里加入领域标签比如续费管理账户安全物流查询各是一块独立的缓存空间跨领域的不允许匹配高风险场景涉及钱、账号、隐私的把语义阈值提高甚至直接关闭语义缓存只保留精确缓存6.3 隐私与合规缓存里不能放的东西缓存本质上是在存储用户的请求数据。如果业务涉及个人身份信息、健康数据、财务信息这个动作本身就可能有合规风险。我在实际项目里有一个底线原则请求文本里包含手机号、身份证号、银行卡号等敏感信息时不做语义缓存也不做精确缓存即使要做也必须先做脱敏处理比如把号码替换成掩码后再参与向量化某些企业内部的合规要求可能直接禁止把数据发给第三方向量化服务这种情况下只能用本地向量模型或者干脆只缓存服务端返回的非敏感摘要另外缓存的删除能力也要提前设计好。用户一旦要求删除数据你不仅是删自己的业务库还得能定位到缓存里对应的条目并删除。这正是为什么我建议缓存key里尽量带上业务标识和可追溯的标识字段而不是只存一句问题原文的哈希。6.4 什么时候应该放弃缓存把这篇文章读到这里可能会形成一个缓存万能的印象但它确实不是所有场景都适用。至少遇到下面这几种情况我会主动放弃单次调用成本已经极低。有些轻量模型的调用价格低到可以忽略再为它维护一套缓存和失效机制运维成本反而超过省下来的钱业务高度动态或强个性化。比如实时行情问答、个人写作助手每次输出都依赖新信息和用户上下文缓存命中率会低到没有意义请求量本身就很小。一天几十次调用就算全部重复也就省几块钱不值得引入一套语义缓存团队维护能力不足。缓存能省钱但也会引入新的故障点误判、数据过期、存储故障如果团队连基础监控都没有先别急着上最后分享一个我长期用的判断方式先看缓存命中率。命中率低于20%说明你的业务形态本身不适合缓存命中了但账单没降多少说明省下来的是本来就便宜的部分命中率超过40%且账单明显下降这套缓存策略才算真正立住了。监控别只盯着账单金额把命中率当作第一健康指标很多问题能在酿成事故之前被提前发现。