显存容量与模型参数规模匹配，不能只看参数量再对照显卡标称容量。模型权重会占一部分空间，运行时还要存放缓存和临时数据；精度、上下文长度以及同时处理的请求数，都会改变最终需求。估算时先拆分这些部分，比按“几 B 模型配几 GB 显存”的口诀选卡可靠。
先算权重，再留出运行空间
权重占用可粗略按“参数数量 × 每个参数所用字节数”估算。以公开配置中的 Qwen2.5-7B-Instruct 为例，参数量约 7.6B；若权重以 BF16 保存，原始权重约需 15.2GB（十进制），折合约 14.2GiB。这个数还不包括框架、缓存和临时张量，因此标称 16GB 的显卡不等于能舒适运行。
量化可以压缩权重：8 位权重的原始占用大约是同规模 16 位权重的一半，4 位约为四分之一。不过量化通常还带有比例参数等额外开销，推理软件也可能保留部分高精度数据。实际占用会高于按位数得出的理想值，且不同量化格式的速度和输出质量也可能不同。
上下文长度会推高缓存占用
生成式模型会把已处理 token 的注意力信息保存在 KV缓存中。上下文窗口越长、并发序列越多，缓存通常越大；即使模型权重不变，长文档问答和短提示词聊天也可能有明显不同的显存需求。
仍以 Qwen2.5-7B-Instruct 的常见配置作估算：28 层、4 个 KV 头、每头维度 128。按 BF16 缓存、单个序列计算，每个 token 的 KV 数据约 56KiB；上下文为 8192 token 时约 448MiB。这里仅是缓存理论估算，批量大小翻倍时缓存大致也会翻倍，框架实现与实际输入长度还会带来差异。上下文窗口上限不代表显存足以同时容纳上限长度的多个请求。
按用途判断容量是否合适
单人短文本推理
若只跑一个请求、上下文较短，权重往往是主要项目。可选择较低精度量化减少占用，但要确认推理工具支持对应格式，并为运行开销预留空间。
长文档或多用户服务
长上下文会增加 KV缓存，并发会进一步叠加缓存与临时工作区。这类场景除了看模型能否加载，还要看目标上下文和并发下是否会因显存不足而报错，或触发降低吞吐的内存管理策略。
训练与推理不能混算
训练通常还需保存梯度、优化器状态及反向传播中间数据，所需显存明显高于仅加载权重进行推理的情况。微调方式、批量大小、检查点策略和软件实现都会影响结果，不宜拿推理估算直接套用。
实用估算步骤
确认具体模型的参数量、权重精度和量化格式，不要只依据模型名称中的“7B”或“14B”。
按参数量估出权重占用，再核对模型卡或推理框架给出的加载需求；把缓存、运行时和临时空间另外考虑。
确定最大上下文窗口与并发请求数。若使用 KV缓存，优先按目标序列长度估算，而不是只看默认短提示词。
在目标软件中先用小批量试运行，观察峰值显存，再逐步增加上下文或并发。若频繁触顶，可依次尝试降低量化位数、缩短上下文或减少并发，并比较速度与输出质量。
选卡时应比较“权重＋缓存＋运行余量”，而非只比较参数量和显存标称值。显存容量与模型参数规模匹配的关键，是把精度、上下文和并发放进同一张预算表，再用目标环境验证。
常见问题
显卡显存刚好等于权重估算值，可以运行吗？
不一定。推理框架和缓存还要占空间，权重估算只能作为下限参考。
上下文窗口越长，显存一定越多吗？
通常会增加 KV缓存占用；实际增幅取决于模型结构、精度、并发和软件实现。
降低精度会不会影响回答质量？
可能会。量化格式、任务类型和模型本身都会影响差异，建议用实际提示词对比质量与速度。
能否只按参数量买显卡？
不建议。显存容量与模型参数规模匹配还需纳入目标上下文、并发和推理框架的额外占用。
