长上下文（long context）为什么特别吃内存
长上下文（long context）为什么特别吃内存
KV Cache 随长度线性膨胀
推理时每生成一个 token 都要读回之前所有 token 的键值缓存。KV Cache 大小正比于层数×头数×头维度×序列长度×批大小。7B 模型每 1K 上下文约占 125MB，70B 约 1.25GB；到了 32K 上下文，70B 的 KV Cache 单独就要约 40GB，比权重以外的开销都大，模型越大这一项越吓人。
长上下文叠加并发，显存先爆
单条对话够呛，一旦多用户并发，KV Cache 再乘批大小，显存几乎被它吃光。这也是 H200 把显存从 80GB 提到 141GB、带宽拉到 4.8 TB/s 的原因，长上下文工作负载正是它的主战场，普通 80GB 卡会很吃力，常常被迫降批或截断。
更麻烦的是 KV Cache 是动态增长的，请求越长占用越大，没法在启动时就预留死。一旦峰值并发撞上超长文档，显存瞬间打满，要么拒绝请求要么 OOM，服务稳定性直接受影响，所以容量预算必须按最长上下文算。
- 短上下文（4K）：KV Cache 可忽略，看权重
- 长上下文（32K+）：KV Cache 反超权重成主角
- 分页注意力：把 KV 分块管理，缓解碎片
工程上常用两个办法兜底：一是分页注意力把 KV 切块复用，减少碎片；二是设最大上下文硬上限，超长请求截断或换更大显存机器。两者配合，才能把长文服务的显存峰值压在可控范围内。
所以模型能装下不等于长文能跑，上下文一长，显存账单里 KV Cache 才是大头，容量规划要按最长上下文和最高并发两条线同时预留。如果你的业务绕不开长文档，选型时就该直接奔着大显存加高带宽去，别指望靠技巧补回来。
长上下文把显存压力推到顶点，也倒逼 CPU 内存更可靠。HeroTEST 提供模组级 DDR5 RDIMM 宽温测试与可信分级，帮你在长文负载下确认模组真实稳定性，欢迎联系我们评估。