大模型1m上下文需要多少显存

很多人一上来就问「1M 上下文要多大显存」，其实答案不是固定数字，取决于模型规模、量化档位、并发数和批大小这几件事。这篇把显存开销拆成几块分别估，给你一套从参数量推卡数的顺序，也写明哪些情况下这套算法会偏得离谱。

很多人一上来就问「1M 上下文要多大显存」，其实这个问题没有固定答案。同一套模型，量化档位换一档、并发数翻一倍、部署框架的 KV 缓存实现换一套，占用的显存能差出一大截。所以与其找现成数字，不如先把显存花在哪几块搞清楚，再按顺序自己推一遍。

这篇给做硬件规划的同事一套可复算的估算顺序：先拆权重、KV 缓存、运行时开销和碎片余量四块，再按参数往上乘，最后落到张量并行和卡数选型。也会写清楚哪些情况下这套口径会偏得离谱，避免拿着推理的算法去套训练场景。

先把「显存花在哪」拆成四块

规划显存最怕的就是把不相干的部分混在一起估。权重、KV 缓存、运行时开销和碎片预留这几块的量级和影响因素完全不同，分开算再相加，出错了也能一眼看出是哪一项估歪了。

权重

跟参数量和量化档位挂钩，和上下文长度基本无关，这是固定底噪

KV 缓存

随上下文长度和并发数线性上涨的那一块，1M 场景的主要开销基本都在这

运行时与框架开销

激活值、显存池、CUDA 图、通信缓冲区，通常要留一成到两成余量

碎片与预留

长序列粗粒度分配容易碎，实际占用往往比理论值高一截

KV 缓存怎么估：四个乘数一个都别漏

KV 缓存可以近似的理解成：每个 token 都要存一份键和值。所以估算的关键是两件事——每个 token 存多大，以及一共要同时存多少个 token。前者由模型结构决定，后者由上下文长度乘并发数决定，两步都别偷懒。

1. 数清结构乘数层数、KV 头数、头维度、每元素字节数，四项相乘得到每个 token 的 KV 开销。注意多头变体里 KV 头数常小于注意力头数，按错这个数会整体偏大。
2. 乘上长度与并发上下文长度乘上并发数就是同时驻留的 token 总量。批处理是累加的，同样 1M 上下文，并发翻倍，KV 缓存基本也跟着翻倍。
3. 换成字节量级把每 token 开销乘以总 token 数，得到 KV 缓存的字节数，再和权重量级放一起比，看谁是大头。
4. 校准结构参数结构参数别凭记忆填，到 /models 查当时的规格，按实际层数和 KV 头数代入。

量化 KV 缓存能明显压低每 token 开销，代价是质量可能略有变化，是否可接受要按具体任务判断，没有一刀切答案。相关概念可以到 /ai-dict/category/tech 对照定义，确认自己用的口径和框架文档一致。

动手估一遍的排查顺序

下面是一条从参数量推到卡数的顺序，每一步都留了验证动作。照着走一遍，比直接问「要几张卡」靠谱得多，也方便事后复盘是哪一步估偏了。

1. 确认目标模型结构到 /models 查层数、KV 头数、头维度这些规格，别凭记忆填数。规格变了，后面全部要重算。
2. 按部署框架算每 token 开销不同框架的 KV 缓存实现方式差异不小，分页注意力、前缀共享这些机制会改变实占，按你实际要用的那套算。
3. 三块相加再乘余量权重加 KV 加运行时开销，再乘碎片余量，得到总需求。这一步只看结论：单卡放不放得下。
4. 放不下就上并行走张量并行或分层部署，卡数乘单卡显存要覆盖总需求，具体测算入口在 /models/deploy。
5. 核对候选卡规格到 /compute/gpus 核对候选卡的实际显存规格，别只信宣传口径，注意可用显存和标称值的差别。
6. 留出验证环节上线前用小规模真实请求压一遍，看实际占用与估算差多少，差得多就回头查是哪一项估歪了。

什么情况下这套算法不适用

上面这套是推理口径的估算，前提是权重加 KV 缓存是主要开销。一旦换场景或者业务形态不同，结论会明显偏。下面几种情况要么改口径，要么干脆别用这套数去规划。

• 跑训练或微调：激活值和优化器状态会占大头，参数量按几倍算，别用推理口径硬套
• 用分页注意力或前缀共享：多个请求共享系统提示，KV 实占低于简单线性累加
• 长上下文下命中率低：理论放得下不等于跑得动，吞吐和延迟要单独看，别只看显存能不能装
• 上下文没真正喂满：很多业务平均长度远低于上限，按峰值买卡容易买多，按 P95 长度规划更稳
• 多卡并行有通信开销：卡数增加并不等于可用显存线性叠加，并行度太高时通信缓冲区也会吃掉一部分

一个务实的做法是分两档规划：按峰值需求留一档给极端情况，按日常 P95 长度留一档做主力配置。具体到某个模型的规格和各家卡的实际显存参数，到站内对应页面核对当时的数字，别用本文的口径直接当结论。