上下文越长，显存压力越大

发布时间:2025-12-15 13:15

模型一次能读进多少文本，由上下文窗口（context window）决定，计量单位是 token，一个 token 粗略对应半个到一个汉字。窗口越长，能装下的对话历史和文档越多，但显存开销也随长度直线上升。 显存压力从哪来 除模型权重外，推理时还有一块随上下文增长的显存开销，叫 KV 缓存：注意力机制需要缓存每个 token 在每一层的键值向量，长度翻倍，缓存跟着翻倍。粗算一笔账：一个 32 层的 7B 模型，单条请求 32K 上下文，FP16（半精度）下 KV 缓存约 16GB，已经超过模型权重本身（约 14GB）。再乘以并发数才是真实消耗——同时处理 4 条 32K 请求，光缓存就要 60GB 上下。 这也解释了两个常见现象：服务方对长上下文请求的限流更严格；长对话聊到后半段，响应明显变慢。 时延是另一重代价 注意力计算量随长度按平方增长，32K 上下文的单步推理比 4K 慢数倍，用户等待时间同步拉长。工程上常见的折中是把"长读"与"长聊"分开：一次性的长文档分析走离线任务，慢慢算没关系；在线对话把窗口控制在 8K 到 16K，配合摘要滚动，响应速度和显存都稳得住。两类场景混在一条链路里，往往是长上下文服务不稳定的根源。 省显存的三个办法 截断与滑动窗口：只保留最近若干轮对话，更早的内容丢弃或压成一句摘要，适合客服聊天类场景。 摘要压缩：长文档先做结构化摘要，几万字压成几千字再进模型，用一点精度换大量显存。 检索增强：文档切块入库，提问时只把最相关的几段拼进上下文。这是企业知识库的标准做法，上下文只需容纳"问题加引用"，几十 K 的窗口就够，显存压力回落到普通水平。 选型建议 评估推理服务时别只看模型尺寸，把"上下文长度 × 并发数"一起问清，两个数乘出来的显存开销才决定你需要多大的卡。预算有限时，检索增强加短窗口的组合，性价比通常高于硬扛超长上下文。