100万Token不等于模型全记住：从KV Cache看懂长上下文成本
内容提要
文章澄清上下文窗口与KV Cache的区别：前者是单次请求的容量上限，后者是自回归解码中缓存历史Key/Value、以空间换时间的计算账本。DeepSeek V4.1 Flash将全局KV Cache降至每Token约890字节，但整机显存还需计入权重、并发等。长上下文不等于召回准，也不等于长期记忆，部署需实测峰值显存与延迟。
延伸解读
上下文窗口与KV Cache：容量与账本的分工
文章明确区分两个常被混淆的概念：上下文窗口是单次请求允许处理的Token数量上限，决定“能放多少”；KV Cache是自回归解码中缓存历史Key/Value表示的计算账本，用空间换时间，避免每生成一个Token都重算前文。二者角色不同，不能把窗口大小直接等同于缓存开销或模型能力。理解这一分工，是评估长上下文部署成本的第一步。
890字节只是全局KV Cache，不是整机显存
DeepSeek V4.1 Flash将全局KV Cache降至每Token约890字节，100万Token约合890MB。但文章提醒，这仅是官方定义的全局KV Cache部分，模型权重、局部窗口缓存、视觉编码、批处理、激活值、框架开销和显存碎片仍需另算。因此，不能把890MB误读为完整运行显存，部署时必须以实测峰值显存为准。
并发会放大缓存成本，容量规划不能只看单请求
文章用估算程序说明：单个128K会话的全局KV Cache约0.114GB，20个并发约2.278GB，100个则超过11GB，且尚未计入权重与其他缓存。服务容量规划必须乘以并发数、保留安全余量，并区分预填充、解码和空闲会话。只按单请求峰值估算，容易低估真实显存压力。
长上下文不等于召回准，也不等于长期记忆
文章列出多个误区：上下文大不代表能准确找回细节，需用针在干草堆、跨段推理和真实任务评测；KV Cache请求结束后通常释放，跨会话记忆需数据库、摘要或检索系统；缓存命中只表示前缀可复用，不等于回答正确。此外，Token不等于汉字，容量规划应使用目标模型分词器实测。
Q&A
上下文窗口和KV Cache到底有什么区别？
上下文窗口是模型单次序列允许处理的Token数量上限，决定一次请求能放多少内容；KV Cache是在自回归解码中缓存各注意力层历史Token的Key与Value表示，用空间换取避免重复计算的时间。前者是容量上限，后者是生成过程中的计算账本。
DeepSeek V4.1 Flash的890字节每Token是什么意思？整机显存就只要890MB吗？
890字节每Token是官方定义的全局KV Cache部分，100万Token约合890MB。但这不表示完整运行只占890MB，模型权重、局部窗口缓存、视觉编码、批处理、激活值、框架开销和显存碎片仍需另算。
为什么长上下文不等于模型能准确记住所有内容？
上下文大不等于召回准，信息埋在长文中仍可能被忽略，需要用针在干草堆、跨段推理和真实任务评测来验证。KV Cache也不是长期记忆，请求结束后通常释放，跨会话记忆需要数据库、摘要或检索系统。
部署长上下文模型时，并发会话对显存影响有多大？
单个128K会话的全局KV Cache约0.114GB，20个同时生成就接近2.3GB，100个则超过11GB，且仍未计权重与其他缓存。服务容量不能只按单请求峰值规划，还要乘并发、保留安全余量，并区分正在预填充、正在解码和已经空闲的会话。
长上下文适合哪些场景，不适合哪些场景？
适合整库代码审阅、长合同对照、多轮Agent轨迹和需要保留原文细节的任务。不适合把所有历史无差别塞进请求：内容经常更新、只需少量相关片段或需要跨用户长期记忆时，检索增强生成（RAG）与外部存储通常更可控。
KV Cache压缩（如FP4、稀疏注意力）有什么潜在代价？
缓存压缩不是免费午餐，更低精度与稀疏索引可能改变数值误差、吞吐和不同长度下的表现。项目方报告的架构收益需要在目标框架中复现，并同时比较首Token延迟、每秒Token、长文召回与最终任务成功率，不能只看显存占用。
