月账单暴涨4倍后，我们把大模型调用成本砍了90%|token|上下文|向量|哈希|大模型|调用成本

上周财务在群里甩了张截图：本月大模型API账单5368元，环比涨4倍。"你们技术部门不花钱就难受？"那一刻，我突然理解了所有被砍过预算的算法团队。

我们做的是智能客服系统，对接三四家大客户。日活不算高，但对话极长。有些用户能跟机器人聊上百轮，每次请求都得把整段对话历史塞进上下文。模型每生成一个token，都要重新读一遍那座聊天记录大山。token像水一样流走。

必须上缓存了。不是Redis，不是CDN——是上下文缓存。核心思路是在语义层面对模型输入做去重：如果一段完整上下文已经算过一次，第二次就别傻乎乎重新算。上线后日耗token从约100万降到约10万，成本砍90%。API中位延迟从3.2秒降到0.4秒。以下是完整方案、代码，以及两个差点把我们炸飞的坑。

token到底浪费在哪

先交代背景。我们用Chat Completions API。每轮对话都要拼一个很长的messages列表发给模型。假设用户已经聊了30轮，当前请求长这样：

messages = [
{"role": "system", "content": "你是客服，请友好回答..."},
{"role": "user", "content": "你好"},
{"role": "assistant", "content": "您好，请问有什么可以帮您的？"},
{"role": "user", "content": "我的订单没收到"},
{"role": "assistant", "content": "请提供订单号..."},
...
{"role": "user", "content": "还是没收到，已经三天了"}
]

每个新请求90%内容和上一轮一模一样，模型却从头处理所有token，账单把每个都算作输入token。典型的"Redis缓存响应"套路在这里没用，因为messages列表每次都变（末尾多一轮），缓存key永远对不上。

根因很清楚：我们没有把"已经算过的前缀"从计费和计算里剥离。如果能识别前缀已被缓存，复用上次模型的中间状态，就能省大量token。但OpenAI的API不像Anthropic那样原生暴露Prompt Caching功能（2024年底部分模型才上线），只能自己模拟。

方案设计：为什么不用向量检索，为什么要自研KV缓存

面前三条路：

1. 全消息响应缓存：只有整个messages列表完全一致才返回缓存答案。命中率几乎为零，因为每个新请求都多一轮。

2. 向量数据库语义匹配：把历史消息向量化，找"语义相似"的问题复用答案。但这会引入语义漂移，且快速演变的对话里上下文微妙变化会被忽略。更致命的是，它缓存的是"答案"而非"计算过程"——用户换种问法，向量匹配上了，但对话历史完全不同，直接复用答案会穿帮。

3. 自研KV缓存（Prefix Caching）：在transformer的KV cache层面做文章。模型处理长序列时，每层的key和value矩阵可以缓存。如果新输入的前缀和缓存里的前缀完全一致，直接复用KV矩阵，只算新增的后缀部分。

第三条路才是正解。但实现上有两个硬骨头：

• 怎么快速判断"前缀是否命中缓存"——不能每次把整段文本哈希，太长
• 怎么存储和加载KV cache——OpenAI API不暴露内部状态

落地：用本地vLLM+前缀树实现

我们最终方案：弃用OpenAI API，切到本地部署的vLLM，利用其内置的Prefix Caching功能。