长文本多轮对话最折磨人的地方不是模型能力不够而是每轮请求都在为前几轮已经算过的东西重复买单。我接手过一个文档问答项目用的是一套Flash系列轻量模型通过DMXAPI统一网关接上游每次对话把一份几十万字的物料文档全量塞进请求然后模型就要从头到尾对这份文档做一遍prefill。用户问三句话模型就把同一篇文档读三遍。首字延迟从2秒一路涨到15秒账单也跟着涨。后来切到CC缓存机制情况才彻底改观。这篇就把CC缓存的原理、DMXAPI上的配置方式以及我踩过的命中率骤降的坑一次说清楚。1. 长文本多轮对话的卡点算力消耗与延迟的真实账本1.1 一次普通多轮调用到底做了什么要理解CC缓存的价值先得看清一次普通调用在模型侧干了多少活。以大语言模型的推理流程来说一次请求进入后所有输入token都要先经过prefill阶段就是模型对整段输入做一次全量的自注意力计算生成每个token对应的Key和Value向量也就是常说的KV Cache。之后再进入decode阶段也就是逐token生成回答。问题就藏在这个prefill阶段。多轮对话里系统指令、背景物料、历史消息这三部分占了请求体的绝大多数真正新增的往往只有用户最后一句问题。但模型不这么看它把整段输入当作全新文本处理所以你上一轮传过的10万token物料这一轮还得原封不动再算一遍prefill。整个过程里真正新增的计算量可能只占2%剩余98%都是重复劳动。Flash模型本身的特点是单token解码速度快轻量高效但prefill阶段绕不开它跟模型大小没有绝对关系而是跟输入长度强相关。我实测过一份2万token的文档Flash系列模型的prefill耗时大约在3到6秒之间波动换成长文本模型会更快但成本更高。多轮对话一旦把历史消息叠加上去请求体越长每轮重复计算的绝对时间就越长整体延迟呈线性恶化的趋势。1.2 Flash模型接入DMXAPI后的典型延迟画像在DMXAPI这类统一网关之上请求会经过鉴权、路由、限流、上游转发几条链路正常的网关转发开销通常控制在几十到几百毫秒级别。但这个数值相比prefill阶段的大头来说几乎可以忽略。我拉过当时生产环境的真实数据一份45万字符的招标文件按中文大约1.5字对应1个token来估折算下来约30万token。去掉一次性的文档预处理和分段逻辑后每轮用户提问实际发送到上游的输入token数约为32万。在Flash模型上这个量级的prefill耗时在45秒到70秒之间浮动。首字延迟超过一分钟基本没人愿意等。更麻烦的是处理这种大请求时上游偶尔会报超时或限流DMXAPI网关侧就会自动重试而重试等于又做一遍全量prefill。那个阶段服务端的计算资源消耗和费用都飚得很高投诉率也涨了一波。我们一度以为是Flash模型不适合长文本场景后来才发现问题根本不在模型本身而在于请求设计完全没有利用缓存能力。1.3 read_text物料长文本的真实量级顺带说下read_text物料长文本这个词它来自我们内部的工具调用链。在做文档问答时前端先调用read_text接口把PDF、Word等文件内容抽取成纯文本作为物料的原始长文本传给对话接口。这种read_text取出的文本有个特点就是长度特别不稳定。我遇到过几种典型的情况产品说明书10万到20万字符token折算约8万到15万招投标文件40万到80万字符token折算约30万到55万年度财报加附注20万到30万字符token折算约15万到22万多份合同合并投喂30万到50万字符token折算约25万到40万当物料上了30万token之后不做缓存优化的调用基本处于不可用状态不论用的是多快的Flash模型。这也是我认定CC缓存不是锦上添花而是长文本多轮对话刚需的根本原因。2. CC缓存机制的工作原理前缀匹配与Token级复用2.1 自注意力计算中的重复劳动CC缓存全称是Context Cache上下文缓存核心思想非常朴素既然模型在prefill阶段对相同前缀文本算出来的KV向量是确定的那直接把上次计算的结果存下来下次再用到相同前缀时跳过计算从缓存里取就行了。打个比方普通调用相当于每次客人点单厨师都把一锅高汤从洗菜切菜开始重新熬一遍开了CC缓存之后底汤提前熬好放在那儿客人点单时只需要往汤里加当天的新菜炒完出锅。高汤是前缀新菜才是这个请求里真正变化的部分。放到技术层面缓存的粒度不是请求级而是token级。一个请求的输入可以被看成前缀增量的结构。比如多轮对话第5轮时输入是[系统指令] [物料长文本] [第1轮问答] [第2轮问答] [第3轮问答] [第4轮问答] [用户当前的问题]其中从系统指令到第4轮问答的完整片段在第5轮请求前已经被计算过至少4次。把这些token的KV向量缓存起来第5轮就只需要对新问题那几百个token做prefill计算量从32万token直接降到几百token差距是按数量级算的。2.2 缓存条目的生成、命中与淘汰CC缓存的运作绕不开几个核心机制缓存写入、缓存命中、缓存淘汰。写入阶段网关或上游服务会对请求的输入前缀做哈希处理生成一个缓存键。同一个前缀在有效期内再次出现时直接判定命中把缓存的KV向量送入decode阶段而不需要重新prefill。缓存命中判定有一个关键前提前缀必须完全一致。注意是token级别的一致性不是语义近似。哪怕只是多了一个空格、改了一个标点、换了一行换行符都会导致前缀不匹配缓存失效。这是最容易踩坑的地方后面我会专门讲。缓存淘汰通常会有一个TTL机制也就是缓存条目保留多长时间。常见的设计是从几分钟到几小时不等TTL越长命中率越高但存储成本也越高。部分平台还支持缓存到期后手动续期或者通过API调整缓存保留策略。这里涉及一个容易被忽略的点既然只要前缀一致就能命中那么缓存并不区分来自哪个用户、哪个会话。只要前缀相同不同会话之间也能共享同一份缓存。这个特性对于多用户问同一份文档的场景非常有用不过要注意做好权限隔离避免越权读取物料内容。2.3 系统指令与物料文档的顺序设计对缓存的影响理解了前缀匹配机制就会发现请求体里的文本顺序不是随便排的它直接决定缓存能覆盖多少内容。把不变的放前面把变化多的放后面这是缓存友好的基本设计原则。具体到多轮对话场景最前面放固定版本号的系统指令保证完全不变其次放长物料文本也就是read_text读出来的那份文档再放多轮历史问答越早的越靠前最后放当前轮用户的新问题这个顺序下系统指令和物料文本在每一轮都是完全相同的能够稳定命中缓存。历史问答是逐步增长的但前面几轮的文本也是确定的所以也能命中缓存的大部分。唯一新增的量只有当前轮问题。我见过有人把用户问题塞到请求体最前面把物料放最后结果每轮请求前缀都不一样缓存基本全废命中率不到5%。这不是模型的问题也不是网关的问题纯粹是请求结构设计不对。3. DMXAPI上的CC缓存配置实践参数、策略与成本模型3.1 网关侧如何确认缓存是否命中在DMXAPI这类聚合网关上CC缓存不一定要在网关层单独实现有相当一部分缓存能力是上游模型服务自带的。网关要做的就是把请求原样转发并把上游响应里的缓存相关字段透传回来方便调用方判断。不同平台上常见的信息字段包括字段含义典型值cached_content_token_count本次请求命中缓存的token数比如317000prompt_token_count请求总token数比如318000cache_creation本次请求触发了缓存写入比如true/falsecache_read_input_token_count读取缓存的token数计入成本cache_creation_token_count / cache_write_input_token_count写入缓存的token数计入成本我自己的习惯是在DMXAPI的转发日志里额外打一条结构化日志把上面几个字段都记下来。观察命中率时直接看cached_content_token_count占prompt_token_count的比例。如果占比长期低于70%说明请求结构或TTL设置有问题需要排查。注意缓存命中不改变业务返回内容所以不能用回答内容对不对来判断缓存是否生效必须看token计量字段。3.2 请求结构设计与缓存键规划缓存键通常由输入前缀的哈希决定但前缀怎么拼、顺序怎么排由调用方控制。所以要拿到高命中率得在调用侧设计好模板。我当时在项目里维护了一套请求组装模块核心逻辑是把请求体按固定模板拼接代码大致长这样CC_PREFIX_VERSION doc-qa-v3 def build_messages(system_prompt: str, document_text: str, history: list, new_query: str) - list: # 关键每一层都用固定分隔符分隔保证前缀完全稳定 messages [] messages.append({role: system, content: f[{CC_PREFIX_VERSION}]\n{system_prompt}}) messages.append({role: user, content: f[物料文档]\n{document_text}}) history_part [] for item in history: history_part.append(f[对话历史]\n用户{item[user]}\n助手{item[assistant]}\n) messages.append({role: user, content: .join(history_part)}) # 最后放当前轮提问这一部分不会命中缓存但也是必要的 messages.append({role: user, content: f[当前问题]\n{new_query}}) return messages这里有个经验物料文档一旦接进来就尽量以原始文本形式稳定复用不要在每一轮都重复走一遍read_text再重新拼接。因为read_text的输出有可能因为源文件重解析而出现细微差异哪怕是一个不可见字符变了前缀就变了缓存直接失效。另一种做法是利用一些平台提供的CachedContent或缓存API先显式创建一个缓存条目把系统指令和文档内容写进去后续请求直接引用这个缓存条目而不需要每次把整段文本都放进请求体。这个方案在高并发场景下更省流量但需要调用方和网关都支持对应的API形态。3.3 成本模型缓存写入、读取与TTL的平衡CC缓存不是免费的它的成本结构跟传统缓存不太一样。需要关注三类费用缓存写入费用、缓存读取费用、无缓存时的全量prefill费用。我以当时的实际价格模型举例假设每百万token的常规输入处理费用是X缓存读取费用通常在X的25%左右缓存写入费用通常是常规输入处理的100%到125%也就是说写入一次和全量处理一次差不多贵。这里有个反直觉的点缓存写入并不省钱它只是为后续的读取省钱。所以缓存值不值取决于一份物料会被复用多少次。场景缓存行为成本对比同一文档只问1个问题写入1次读取0次比无缓存还贵同一文档问10个问题写入1次读取9次约为无缓存的30%左右同一文档被10个用户各问5个问题写入1次读取49次约为无缓存的10%左右文档频繁更新反复写入读取少建议关闭缓存所以我的建议是不要对所有请求无脑开缓存。判断标准很简单这份物料在TTL内有没有可能被复用。典型的复用场景包括多轮追问、多个用户同时查询同一份文档、同一文档在不同会话里做对比分析。如果只是单次一次性问答开缓存反而增加成本。TTL的设置也要权衡。TTL设得太短用户思考一会儿再问下一轮缓存就过期了命中率下跌TTL设得太长写入成本虽然平摊下来不心疼但存储费用会持续累积。我当时按产品行为习惯设置了一个默认值面向交互式问答的会话TTL设为1到2小时面向批处理任务TTL设为5到10分钟。命中率稳定保持在85%以上。4. 多轮对话场景下的缓存失效问题与排查链路4.1 命中率骤降的三种典型根因缓存机制不算复杂但实际跑起来命中率很难做到100%。我遇到过最严重的几次命中率暴跌根因基本都集中在这三类上第一类是前缀漂移。系统指令或物料文本在请求组装时出现了不可见变化。比如有人在system prompt末尾加了一个换行符或者把版本号从v2改成了v2.1整个前缀的哈希就变了。最恶心的是这种变化在代码review里根本看不出来只有看token计量字段才会发现命中率掉了。第二类是请求顺序错乱。多轮历史消息的拼接顺序没有严格按时间递增或者把某轮失败的请求记录过滤掉了导致历史序列出现空洞前后两个请求的文本对不上前缀自然也对不上。第三类是TTL过短。用户阅读长文档本身就慢思考时间经常超过TTL等用户发出下一轮问题时上一轮的缓存条目已经被淘汰模型只能重新做全量prefill。这种情况在日志里的表现是cached_content_token_count突然归零。4.2 一次缓存命中率从92%跌到40%的排查过程我把一次真实的排查过程完整拆开讲给大家一个可复现的排查思路。某天下午监控面板显示CC缓存命中率从平稳的92%突然跌到40%出头但上游服务没有发布变更DMXAPI网关也没有重启。我当时第一反应是前缀漂移但查了最近一次发布记录系统指令没有任何改动。接着我拉出响应日志里的usage字段挑了几条请求做对比。发现一个规律命中率下跌并不是所有请求都跌只有包含特定物料的请求在跌其他物料一切正常。这个物料是一份刚更新过的产品手册。顺着物料更新这条线查下去发现read_text接口在物料更新后会重新解析PDF文件。新的解析结果里原本的两页内容合并成了一页文本中间少了一个分页符。虽然内容在语义上完全一致token序列却发生了变化。字符串匹配层面相同的文本tokenize之后可能完全不同。我之前提到过固定前缀里有一层版本号标识doc-qa-v3但这层标识只保护了system prompt部分。物料文本本身是紧跟system prompt的一旦物料文本的开头部分变化就会导致从物料开头到结尾的整段前缀不匹配后面接的所有历史对话都跟着失效。所以修复方案有两步第一步把物料文档的解析版本号加进缓存前缀里物料更新时显式让缓存整体失效而不是装作前缀没变第二步修改请求模板在物料文本的前面加一个文档级指纹字段任何解析结果的变化都反映在新的指纹里避免上下游对文本是否相同的理解不一致。修复之后命中率在一个小时左右恢复到88%以上没有完全恢复到92%原因是物料更新本身导致缓存写入了一次全量内容这部分token计入了缓存写入而不是命中。这属于正常损耗。4.3 大文档更新与缓存策略的取舍长物料还有一个绕不开的场景文档本身会更新。招标文件有补充澄清产品手册有新版本合同有修订条款。文档一更新整个缓存前缀就废了之前积累的命中全部归零。关于大文档更新我试过两种策略。第一种是文档整体重建缓存更新后第一次请求触发全量缓存写入后续请求继续命中。优点是实现简单缺点是第一次请求很慢通常要等跟全量prefill差不多的时间。第二种是文档拆成多个语义块分别作为独立段落放进请求体每个块有自己的内容指纹更新时只影响对应的块。这种做法的好处是更新影响面小代价是请求体需要维护块级结构且不同块的边界切割本身可能影响模型对上下文的整体理解。我在实际项目中只在文档非常大且更新频繁的场景比如周报问答用过分块方案对普通的长文档问答整体重建完全够了。核心结论缓存失效不是故障是机制。重要的是失效是否可控、可观测、可恢复。日志里一定要保留缓存token计量字段这是唯一可靠的观测入口。5. 实测优化效果与进阶应用思路5.1 加入CC缓存后的性能对比数据项目接入CC缓存并稳定运行之后我记录过一组对比数据放在同一份32万token物料的文档问答场景下指标未启用CC缓存启用CC缓存后首字平均延迟50秒2.1秒第2轮以后首字平均延迟55秒1.3秒单轮token成本全量32万token缓存读取约31.8万新增约200月成本估算约100%约25%到30%超时重试率6.5%0.4%印象最深的是首字延迟的降幅。在未开缓存的情况下用户每多问一轮就要重新等待一次一分钟级别的prefill整个对话流程基本是断裂的。开了缓存之后从第二轮开始用户体感跟问普通短文本问题几乎没有区别。延迟下降的同时DMXAPI网关侧的流量占用也大幅下降。毕竟请求体里那32万token的文本不再每轮都完整传输只有第一轮需要传输一次后续请求传输的新增token只有几百到几千网络开销几乎可以忽略。5.2 基于CC缓存的进阶玩法把缓存机制理顺之后能做的就不只是文档问答了。我尝试过几个扩展方向都取得了不错的效果。方向一是多用户共享物料缓存。企业内部同一份制度文档可能同时被几十个员工提问每个人进来时文档内容对应的前缀已经在缓存里了。配合DMXAPI网关的统一路由多个会话共享同一份缓存条目成本进一步摊薄。方向二是把CC缓存用作多Agent系统的公共上下文。在Agent协作场景里多个子Agent需要读取同一份长材料比如代码库结构说明、数据库Schema文档、运营活动规则。各子Agent如果各自全量prefill一遍成本是成倍增长的。把这些公共物料做成稳定前缀各子Agent只带自己的任务指令进入请求既省成本又提速。方向三是缓存预热。预判到某个高流量事件到来前先用一次带缓存写入的请求把所有公共物料打热让缓存条目提前生成。这样真实用户访问时第一个请求就能命中缓存。我做过一次活动预热预热后高峰期的首字延迟从8秒降到1.5秒效果很明显。5.3 一个压测缓存命中率的实用脚本思路最后分享一个很实用的压测脚本思路。我每次调整请求模板或TTL后都会用一个简单的脚本确认命中率是否符合预期核心逻辑就是用同一份物料连续发两轮请求对比第二轮响应里的缓存命中token数是否为全量减新增。import requests # 第一轮写入缓存 resp1 requests.post(DMXAPI_ENDPOINT, jsonbuild_request(doc_text, history[], query第一问)) usage1 resp1.json()[usage] # 第二轮读取缓存 resp2 requests.post(DMXAPI_ENDPOINT, jsonbuild_request(doc_text, history[], query第二问)) usage2 resp2.json()[usage] cached_in_second usage2.get(cached_content_token_count, 0) new_input_in_second usage2.get(prompt_token_count, 0) - cached_in_second print(第二轮命中token数:, cached_in_second) print(第二轮新增token数:, new_input_in_second) print(命中率:, round(cached_in_second / usage2.get(prompt_token_count, 1) * 100, 2))如果第二轮的命中率低于预期优先检查两轮请求的system prompt和物料文本的原始字节是否完全一致可以用hash对比。我在实际使用中还有一个习惯把缓存命中率作为一个独立的业务指标单独拉曲线而不是只盯着延迟和成本。原因很简单延迟和成本指标虽然直观但它们是缓存命中率的结果变量。命中率一旦跌了延迟和成本往往要过一段时间才体现出来而且中间还可能夹杂其他干扰因素。盯着命中率这个根因指标问题能早发现好几个小时。如果你正在做长文本多轮对话类的应用我建议先从一份日志里的token计量字段下手命中率上去了体验和账单都会跟着好转。