24GB显存跑本地LLM？实际可用显存没那么多

为什么24GB显存不等于24GB可用

很多人在部署本地大语言模型（LLM）时，习惯直接把模型文件的大小和显卡包装盒上标注的显存数字做对比：模型文件12GB，显卡24GB，看起来绰绰有余。但这种朴素的算法忽略了显存中多个不可见的"内存桶"，导致实际运行时频繁遇到OOM（显存溢出）或性能骤降的问题。

一位Reddit用户（运营ResearchAudio项目）分享了他日常使用的一套显存规划方法论。核心观点很简单：你需要按照可用容量而非包装盒标签来规划。他提出的基础规划模型是：

可用容量 = 标称显存 × 0.90
总需求 = 模型权重 + KV缓存 + 运行时余量

这里的90%只是一个保守的起点值——真实系统运行后，你应该亲自测量属于自己环境的实际比例。之所以不是100%，是因为GPU驱动程序、CUDA运行时上下文、显示输出（如果不是无头服务器）以及操作系统的图形合成器都会预先占用一部分显存。在Windows系统上，这部分开销通常比Linux更大，桌面环境本身可能就消耗300MB-1GB的显存。

具体来说，NVIDIA的CUDA运行时在初始化时会创建一个设备上下文（context），这包括CUDA内核的JIT编译缓存、设备函数指针表、流（stream）和事件（event）管理结构等，通常占用150-300MB。此外，cuDNN和cuBLAS等加速库在首次调用时会分配workspace缓冲区用于算法选择（autotuning），这部分也可能消耗数十到数百MB。在Windows上，WDDM（Windows Display Driver Model）驱动模型还会维护额外的显存页表和DWM（Desktop Window Manager）合成所需的帧缓冲区，这就是Windows比Linux开销更大的技术原因。Linux上如果使用无头（headless）模式或仅加载nvidia-compute驱动而非完整的显示驱动，可以将系统级开销降到最低。

reddit原帖：24GB显存对本地LLM来说并不是真正的24GB

显存的三大消耗桶

桶一：模型权重的"地板价"

以四比特量化（4-bit）为例，纯参数的理论最小占用如下：

模型规模	权重地板
7B	3.26 GiB
13B	6.05 GiB
32B	14.90 GiB
70B	32.60 GiB

这里的计算逻辑很直观：每个参数用4bit存储，即0.5字节/参数，7B参数就是7×10⁹×0.5≈3.5GB，考虑到GiB与GB的换算（1GiB=1.073GB）以及部分层可能保留更高精度（如embedding层和输出层通常用FP16），实际的"地板值"会略有浮动。量化精度的选择本质上是模型质量与资源消耗之间的权衡——学术研究表明，从FP16到Q8量化通常几乎无损，Q6约有0.1-0.3%的困惑度（perplexity）增加，Q4_K_M通常增加1-3%，而Q2/Q3级别的量化则可能导致明显的输出质量退化，尤其在推理密集型任务（数学、编程）上表现显著。

作者特别强调，这只是干净的参数地板值。实际的GGUF、GPTQ、AWQ等格式文件往往更大，因为量化的缩放因子（scales）、元数据、混合精度张量以及格式本身的选择都会额外占用空间。换句话说，同样是"4-bit的7B"，不同格式和实现的实际体积可能有明显差异。

这里值得展开说明这几种主流量化格式的区别。GGUF（GPT-Generated Unified Format）是llama.cpp生态的标准格式，特点是单文件打包、支持多种量化精度混合——例如某些对模型质量影响较大的关键层可以保留更高精度（如Q6_K或Q8_0），而其他层使用更激进的低精度（如Q4_K_M）。GPTQ（GPT Quantization）是一种基于近似二阶信息的训练后量化方法，需要校准数据集来最小化量化误差，通常在纯GPU推理场景效率较高。AWQ（Activation-aware Weight Quantization）则通过分析激活值分布来识别"重要"权重通道并给予更高精度保护，在同等比特数下往往能获得更好的模型输出质量。这三种格式即使都标称4-bit量化，实际文件大小也会因为缩放因子的存储精度、分组粒度（group size，常见128或32，分组越小精度越高但额外开销越大）、是否包含额外元数据等因素而产生显著差异，差距可达10%-20%。

如果套用90%的规划规则，各档显卡的实际可用容量应该这样看：

标称显存	规划可用值
8 GB	7.2 GiB
12 GB	10.8 GiB
16 GB	14.4 GiB
24 GB	21.6 GiB
32 GB	28.8 GiB

桶二：KV缓存——容易被低估的隐形杀手

KV缓存（Key-Value Cache）是很多新手完全忽略的部分，但它的膨胀速度非常快。要理解为什么需要KV缓存，需要回到Transformer架构的自回归生成机制。在标准的自注意力计算中，每生成一个新token都需要与之前所有token的Key和Value向量做注意力运算。如果不缓存，每一步都要重新计算前面所有token的KV投影，计算复杂度是O(n²)级别的。KV缓存的做法是把已经算过的Key和Value张量存下来，新token只需计算自己的Q/K/V然后与缓存拼接，从而把每步的增量计算降为O(n)——这是用空间换时间的经典策略。

作者给出的估算公式为：

KV缓存 = 2 × 层数 × KV头数 × 头维度 × 缓存token数 × 每元素字节数 × 并发序列数

为了让这个公式更加直观，以Llama 3 8B为例进行具体计算：该模型有32层、8个KV头（使用GQA架构，查询头32个但KV头只有8个）、头维度128。假设上下文长度8192、FP16精度（2字节）、单序列，则KV缓存=2×32×8×128×8192×2×1≈1.07GB。如果上下文扩展到32K，缓存就膨胀到约4.3GB；如果同时处理4个32K上下文的请求，则需要约17.2GB仅用于KV缓存——这已经超过了很多模型权重本身的大小。对比之下，如果使用非GQA架构（如原始Llama 1，KV头数等于查询头数32个），同样条件下缓存会是4倍，即单序列8K上下文就需要约4.3GB。这就是GQA架构在长上下文场景下的巨大优势。

这个公式揭示了两个关键规律：上下文长度翻倍，缓存大致翻倍；并发的满上下文请求翻倍，缓存再翻倍。这意味着如果你想同时处理多个长上下文对话，KV缓存的占用可能轻松超过模型权重本身。这也解释了为什么很多人在小批量测试时一切正常，一旦上生产环境开并发就立刻爆显存。

值得注意的是，业界正在积极研发多种KV缓存压缩技术来缓解这一瓶颈。量化KV缓存（如用FP8甚至INT4精度存储KV向量而非默认的FP16）可以将缓存大小压缩到原来的1/2甚至1/4。vLLM率先引入的PagedAttention借鉴了操作系统虚拟内存的分页思想，将KV缓存切分为固定大小的"页"，按需分配而非预先分配，大幅减少了碎片化浪费。在模型架构层面，GQA（分组查询注意力，如Llama 2 70B和Llama 3系列采用）和MQA（多查询注意力，如Falcon系列采用）通过让多个查询头共享同一组KV头，从根本上减少了需要缓存的KV向量数量。这些技术可以显著降低KV缓存的实际占用，但对终端用户来说，关键是了解你使用的推理框架是否启用了这些优化。

桶三：运行时工作区与余量

除了权重和KV缓存，推理框架本身还需要工作区内存（activation、临时张量等）和安全余量。这包括注意力计算过程中的中间激活张量、层归一化和残差连接的临时缓冲区、采样阶段的logits向量（词汇表大小×batch size×FP32，对于128K词汇表的模型这就是约512KB每个序列）等。这部分正是90%规划系数所要覆盖的缓冲空间。

正确的显存规划操作顺序

作者总结了一套清晰的"运算顺序"，值得每个本地LLM玩家收藏：

从具体的checkpoint出发，而不是只看参数量——同样是32B，不同量化文件的实际大小差异很大。例如一个32B模型的Q4_K_M量化版本可能是18.5GB，而Q4_0版本可能是17.2GB，Q5_K_M版本则可能达到21GB。
叠加真实使用场景的KV缓存，按你真正会用到的上下文长度和并发数计算，而非理论峰值。
加上运行时工作区和余量。
用总需求对比"可用容量"，而不是包装盒标签。
实测峰值显存、首token延迟（TTFT）和每秒token数（TPS）。

这里的TTFT和TPS是评估LLM推理性能的两个核心指标，它们反映了推理过程中两个截然不同的阶段。TTFT衡量的是prefill（预填充）阶段的耗时——模型需要一次性处理整个输入提示词（prompt），这是一个计算密集型操作，涉及对所有输入token的并行注意力计算并填充KV缓存，输入越长TTFT越高。TPS衡量的则是decode（解码）阶段的速度——逐个自回归生成输出token，这个阶段主要受限于显存带宽（需要反复读取全部模型权重和不断增长的KV缓存），属于内存带宽密集型操作。对于交互式对话场景，TTFT直接决定了用户等待第一个字出现的时间（超过2-3秒就会感觉明显卡顿），而TPS决定了后续文字流出的速度（一般认为6-8 tokens/s以上接近人类阅读速度，体验较好）。显存紧张时，这两个指标都会显著恶化。

能装进显存 ≠ 跑得快

文章最后一个洞察尤其重要：模型能塞进显存，不代表它跑得快。当显存不够时，很多框架会自动启用CPU offload（把部分层卸载到内存/CPU），这确实能让模型"加载成功"，但生成速度会大幅下降。

CPU offload的工作机制是将模型的部分Transformer层放在系统主内存（RAM）中，由CPU负责这些层的前向计算，只有驻留在GPU显存中的层才能利用GPU的并行计算加速。推理时，数据在GPU和CPU之间通过PCIe总线来回传输（消费级平台通常是PCIe 4.0 x16，理论带宽约32GB/s，实际有效带宽更低），而GPU自身的显存带宽通常在数百GB/s到上千GB/s级别——这一个数量级以上的带宽差距就是性能瓶颈的根本原因。实际体验上，如果只有少量层被卸载到CPU，速度下降可能还在可接受范围（比如从30 tokens/s降到15-20 tokens/s），但如果大部分层都在CPU上，生成速度可能降至1-3 tokens/s，基本失去交互式使用的意义。在llama.cpp中，-ngl（number of GPU layers）参数可以精确控制多少层放在GPU上，用户可以通过逐步调整来找到速度和模型规模的最佳平衡点。

理解这一点还需要认识到显存带宽对推理速度的决定性影响。在LLM推理的decode阶段，每生成一个token都需要将整个模型的权重从显存读取一遍（因为每个token都要经过所有Transformer层的前向计算）。这意味着推理速度的理论上限≈显存带宽÷模型大小。以RTX 4090为例，其显存带宽约1008GB/s，如果模型权重占18GB（如32B模型Q4量化），则理论最大速度≈1008÷18≈56 tokens/s（实际还要考虑KV缓存读取和计算开销，真实值通常是理论值的50-70%）。相比之下，RTX 4060 Ti 16GB的显存带宽只有288GB/s，同样大小的模型理论上限仅约16 tokens/s。这揭示了一个反直觉的事实：对于decode阶段而言，显存带宽比显卡算力（TFLOPS）更重要，这也是为什么Apple M系列芯片（统一内存带宽可达200-800GB/s且容量大）在本地LLM推理中表现出色的原因。

因此仅仅追求"能不能装下"是不够的，还必须关注实际的推理吞吐。

作者为此开发了一个免费的浏览器端计算器（LLM GPU Memory Calculator），据其说明不会上传用户输入数据，可以在本地估算不同模型、量化、上下文和显卡组合下的显存需求。他也呼吁社区分享各自实测的峰值显存数据，用来校准这套规划表与真实环境的差距。

对本地LLM玩家的实操建议

综合来看，这套方法论的价值在于把"拍脑袋估算"变成了"结构化规划"。对于打算购买或已经在用消费级显卡跑本地模型的用户，几条务实的建议是：

买卡时预留20%以上余量：如果你的目标模型权重加KV缓存需要18GB，别指望20GB的卡能舒服运行。
优先算清KV缓存：长上下文和多并发场景下，它才是决定性因素。
一切以实测为准：90%只是起点，不同框架（llama.cpp、vLLM、Ollama等）的开销差异明显，跑起来测一次才靠谱。不同推理框架的定位和显存开销特征差异明显：llama.cpp是纯C/C++实现的轻量级推理引擎，以GGUF格式为核心，支持CPU+GPU混合推理，显存开销最小且可精细控制，适合消费级硬件上的单用户场景；vLLM是面向高吞吐服务化部署的Python框架，其核心创新PagedAttention大幅提升了批处理效率和显存利用率，但框架本身的CUDA上下文和调度器也会占用额外显存（通常数百MB到1GB以上），更适合多用户并发的服务器场景；Ollama本质上是llama.cpp的高层封装，提供了更友好的模型管理和API接口，但会引入少量额外的内存开销。此外还有ExLlamaV2（专注于EXL2格式的高性能推理）、TensorRT-LLM（NVIDIA官方深度优化框架，性能极致但配置复杂）等选择。选择不同框架意味着不同的显存overhead，这也是为什么必须实测的核心原因。

对于本地部署这件事，理解显存的真实构成，远比盯着包装盒上的数字更能帮你少踩坑。