上下文长度是什么？为什么长文本推理更慢、更贵？
上篇聊了KV Cache怎么给推理加速。
有个问题不知道你想过没有：KV Cache本来是个加速工具，可上下文越长，它要存的东西就越多。按理说存得多应该更快才对，但现实偏偏相反——上下文越长，AI跑得越慢，还越贵。
这背后是什么原理？往下看。
上下文长度——AI的"工作记忆"
先说基本概念：上下文长度，指的是AI模型一次能处理的最多字数。你可以理解为AI的"工作记忆"——就像你做数学题时，黑板上能写多少步推导。
黑板就那么大。写满了怎么办？擦掉旧的，写新的。
AI也一样。上下文窗口有多大，它同时能考虑的信息就有多少。超出这个窗口的内容，AI"看不见"了。
主流模型现在是什么水平？看这张图：
Claude能处理20万个Token，约等于一本《骆驼祥子》的长度。GPT-4 Turbo能吞下12.8万个Token，Kimi也差不多是这个量级。
窗口越大，能处理的信息越多，但计算量也跟着涨。这就像你的草稿纸从A5换成A3——能写的步骤多了，翻页找之前写的内容也更费劲了。
AI读和写的两个阶段
理解长文本处理为什么费劲，得先知道AI是怎么"读"和"写"的。
AI处理文本分两个阶段：
预填充：AI把你输入的Prompt全部读一遍。这个阶段高度并行，GPU全力运转，速度快。就像老师一口气批完全班的试卷。
解码：AI一个字一个字往外蹦输出内容。这个阶段是顺序的——先出第一个字，再出第二个，依此类推。就像老师批完试卷，一个一个给学生写评语。
看这张对比表：
预填充吃算力，解码吃内存带宽。两者消耗的资源类型完全不同。
解码还有个更要命的问题。
KV Cache的代价
KV Cache能加速推理，原理是把之前计算过的Key-Value矩阵存起来，下次直接用，不用重算。
问题来了：存多少？
生成第一个字，存一份KV。生成第二个字，存两份KV。生成第一百个字，存一百份KV。
文本越长，存的KV越多。每个生成的字，都需要"记住"之前所有字的上下文信息。存储量线性增长。
看这张图：
解码阶段，GPU算力用不上。每次只生成一个字，没什么好并行的。但内存要不断传输历史的所有KV。
这就像你读一本很长的书，每翻一页都得把之前所有页的内容在脑子里过一遍。费脑子不说，翻页也慢——内存带宽成了瓶颈，GPU在那干等着数据传过来。
所以长文本推理又慢又贵：慢在内存传输，贵在内存容量。
两个速度指标：TTFT和TPOT
说到速度，有两个指标你可能见过但不一定清楚区别。
TTFT，全称Time To First Token，就是从开始到输出第一个字的时间。主要被预填充阶段拖累。
TPOT，全称Time Per Output Token，就是每个字平均生成时间。主要被解码阶段拖累。
想象点外卖：预填充是骑手在取餐，时间长，但只发生一次。解码是骑手在路上跑，一趟一趟的，每趟都要背着一堆东西。
文本短的时候，取餐时间占比小，骑手跑得飞快。文本长的时候，取餐时间占比变大，而且骑手要背的东西也越来越多。
看这张时间轴对比：
短文本场景：TTFT占比小，主要时间花在TPOT上。长文本场景：TTFT占比变大，预填充成了主要瓶颈。
和直觉有点不一样对吧？通常觉得生成才是慢的。但上下文特别长的时候，读的阶段反而更拖后腿。
分离式推理：专人干专活
业界怎么解决这个问题？
答案是把预填充和解码分开处理。
预填充用计算型GPU，比如H100，算力强，适合处理密集计算。解码用带宽型GPU，比如H200，内存带宽大，适合频繁读写数据的场景。两套系统之间，用统一的KVCache存储连接，按需调用，避免重复计算。
把炒菜厨师和传菜员分开，厨师专心炒菜，传菜员专心跑腿。专人干专活，整体效率翻倍。
看这张架构图：
分离式架构有代价：系统复杂度高了，调度难度大了，硬件成本也上去了。不过大规模部署的场景下，这些代价值得花。
上下文缓存：避免重复计算
还有一个优化思路：缓存。
多轮对话的时候，系统提示词往往是固定的。比如"你是一个有帮助的助手"、"请用中文回答"——这些内容每次都传，浪费。
上下文缓存的思路是：把这些固定内容算好存起来，下次直接用。
创建缓存大约需要30-40秒，但长期使用能显著节省计算资源。适合那种反复调用相同系统提示的应用场景，比如客服机器人、代码助手这类产品。
律师打官司就是个好例子。案由可能每次不同，但法律条款库可以重复查，不用每次开庭都把整本法条重新背一遍。
更长的上下文意味着更强的能力，但也意味着更多的计算、更贵的硬件、更复杂的技术。
下次惊叹于AI能读完一整本书时，想想这背后有多少GPU在默默燃烧。
那AI是怎么把这些内容一点一点输出给你的？为什么你能看到字一个一个蹦出来？这就是下一篇要聊的了——流式输出。