经常有朋友发一张配置截图问我“这套能不能跑本地大模型”“16G显存是不是就能无脑冲70B了”这类问题实在太多了。显存这东西决定了你的显卡到底能装下多大的模型、推理跑多快但它和“模型参数量”之间并不是简单的加减法关系。哪怕同一个模型用不同的加载精度、不同的上下文长度显存占用能差出一倍还多。我一直觉得与其到处问“能不能跑”不如自己学会那套显存估算和排查的方法。这篇文章就从载入、计算、推理三个阶段把显存怎么被吃掉的讲清楚再把“参数量-精度-KV Cache-显存”这条链路的计算公式拆开揉碎。中间会穿插我的实际测试数据以及踩过的各种坑比如OOM怎么办、为什么显卡占用率上不去、驱动层面常见报错怎么排查。看完你不仅能算出自己显卡的“模型承载力”还能在选卡、选模型、选量化档位时不那么纠结。1. 显存里到底装了什么东西很多人以为显存只用来放模型权重文件所以拿模型文件大小去对比显存大小够就万事大吉。这个理解只对了一小半。如果你的程序能被nvtop、任务管理器或nvidia-smi抓到一个稳定的显存占用数值那这个数值里其实装了好几类完全不同的数据。第一类是模型权重本身。这是最直观的部分也是很多人唯一想到的部分。权重在磁盘上占多少加载到显存里就差不多占多少只不过磁盘上是压缩存储格式显存里是运行格式两者存在细微差异。第二类是CUDA上下文和运行时环境。只要调用GPU做计算驱动和CUDA库就会在显存里开辟一块基础区域专门存kernel函数、线程调度、常量内存和上下文状态。我实测中这一块通常在300MB到800MB之间取决于CUDA版本和框架初始化方式。在只看大模型权重的人眼里这“凭空消失”的几百MB常常被忽略但对于8G、12G显存的用户来说它直接影响你能跑什么规模的模型。第三类是KV Cache也就是推理过程中缓存起来的中间计算结果。Transformer架构在生成每个token时需要反复读取之前所有token的Key和Value向量如果不把它们暂存在显存里就得每次重新计算性能直接崩溃。KV Cache的大小和上下文长度、层数、注意力头数呈线性关系后文我会给出计算公式。这也是为什么很多人跑同样的模型别人能跑自己一改参数就OOM多半是上下文长度设置不当。第四类是激活值activation也就是前向传播过程中每一层的临时中间输出。在训练、微调场景下激活值非常惊人但在纯推理场景只要不开启梯度计算激活值会逐层释放峰值占用不算太夸张。可一旦你在推理时开了gradient checkpointing或者做LoRA微调这部分显存会瞬间飙升好几个量级。清楚了这四类你就能理解为什么显存不够时降低上下文长度往往比切换更小模型更能立竿见影。我自己的习惯是先估算模型权重大头再留够KV Cache余量最后看一眼CUDA context那几百MB三层算完才是真正的显存需求。2. 模型参数量与显存占用的数学拆解大模型的参数量一般以BBillion十亿为单位比如7B、8B、13B、70B。将参数量换算成显存占用需要看加载精度。FP32格式每个参数占4字节FP16/BF16占2字节INT8占1字节INT4约0.5字节。计算公式是权重显存 ≈ 参数量B× 精度字节数 × 1.13最后乘的1.13是冗余系数包括layer normalization里的参数对齐、embedding表冗余、以及PyTorch/HF加载时额外的内存对齐开销。举几个跑过的例子7B模型用FP16加载约7 × 2 × 1.13 ≈ 15.8GB这解释了为什么8GB显卡原生FP16跑7B非常吃力就算勉强塞进去KV Cache一进去就爆。7B模型用INT4量化约7 × 0.5 × 1.13 ≈ 4GB加上KV Cache和context8GB显卡勉强能跑也能解释为什么社区里流行“8G显存跑7B量化”。70B模型用FP16加载约70 × 2 × 1.13 ≈ 158GB普通单卡根本没戏所以才需要多卡并行或者高压缩比量化。70B用INT4量化约70 × 0.5 × 1.13 ≈ 40GB这时一张48GB的L20或A6000就有机会跑起来这也是为什么专业计算卡在大模型时代突然变香。KV Cache的大小就没有权重那么“整齐”了它由模型结构和生成长度共同决定。计算公式是KV CacheGB ≈ 2 × 层数 × 注意力头维度 × 头数 × 序列长度 × 2字节 ÷ 1024³这里的×2是因为每个token要存Key和Value两份。以LLaMA 7B为例层数32、头数32、每头维度128那么每个token的KV Cache约为32 × 32 × 128 × 2 × 2 ÷ 1024³ ≈ 0.5MB。生成2K上下文就是约1GB16K上下文就是约8GB量级一下就上来了。这也是为什么长上下文推理的显存大头往往从“权重”转移到了“显存里的QA对”。所以一个完整的显存预算公式应该是总显存 ≈ 权重显存 KV Cache CUDA context 激活值余量我实测跑13B FP16模型、上下文4K时nvidia-smi显示23GB左右权重约29.4GB只是理论值说明KV Cache和context这些“杂项”至少多了几个GB。如果你计划跑32K上下文那KV Cache这么一算很多24GB显卡基本没戏。3. 量化精度看着省一半实际能省多少量化是当前消费级显卡跑大模型最核心的手段。模型量化理解起来不难FP16的权重储存在2字节里为了减小体积和显存把权重映射到更小的整数范围比如INT8的256级、INT4的16级。这样做确实省显存但代价是精度损失。一个常见误区是“4bit量化是不是比8bit省一半”理论上是但实际运行时有差异。量化的权重在加载后通常会反量化到FP16再进行矩阵乘法所以“显存占用减半”只在权重存储层面成立计算过程中依然要用FP16或BF16做矩阵乘法尤其某些推理引擎开不了真正的kernal融合时内存占用并没有想象中低那么多。另一个问题是量化不止是简单的“砍位宽”。实际落地到核心推理引擎里4bit和8bit往往采用group quantization的方式也就是将权重按小块比如64个数值一组做缩放因子每一组有一个scale和zero_point推理时要动态计算反量化。这种方案在显存中不仅要存量化后的整数权重还要额外存每个组的scale和zero_point。所以“7B模型INT4大约4GB”这种估算是近似值真实落地可能多出几百MB。我实测了一组数据供参考使用同一样本、同一设备RTX 3060 12GB加载Qwen2.5-7B加载模式权重文件大小推理时峰值显存占用生成速度tokens/s原生FP1613.9GB14.9GB加context无法运行OOM8bit量化7.4GB9.1GB8.54bit量化GPTQ4.3GB6.2GB12.14bit量化AWQ4.6GB6.5GB11.4能明显看到量化带来的显存收益很大但速度上因为反量化开销反而不一定更快4bit和8bit的速度差异主要由内存带宽和反量化算法决定。在选型时不要简单以为“量化级别越低越好”。4. 实操两条命令摸透你显卡的家底在聊选型对策之前强烈建议你先搞清楚自己手头显卡的几项硬性参数显存容量、显存类型和位宽、算力版本Compute Capability。三个参数决定了你的显卡在AI推理里的天花板。查看nvidia-smi的常规方式我就不赘述了重点说几个容易忽略的命令nvidia-smi -L只列出GPU信息简洁不刷屏。nvidia-smi --query-gpuname,memory.total,memory.free,memory.used,temperature.gpu,utilization.gpu --formatcsv一次性输出关键指标适合写脚本或定时监控。nvidia-smi dmon -s p实时看GPU利用率、温度、功耗观察推理瓶颈时非常有用。关于如何实时看CPU和显卡占用率的问题除了任务管理器Linux下我最常用的是nvtop它比任务管理器直观太多能把每个GPU的核心占用、显存占用、功耗、温度以及进程列表都展示出来还在同一个界面上对比观察。Windows下可以用MSI Afterburner的OSD叠加显示或者直接用PowerShell查Get-Counter \GPU Process Memory\Dedicated Usage。识别出的GPU架构信息可以直接影响推理依赖的扩展指令集。比如3090/4090支持SM80/SM89架构能用较新的FlashAttention优化而1660这类图灵架构虽然也有Tensor Core但功能受限部分优化跑不起来。如果核显或旧卡跑不了GPU版PyTorch常常就是算力兼容性问题。查看显存位置和PCB图一说其实也简单显存颗粒一般围绕核心呈环状排列12颗或24颗对称分布。如果你想要更细的颗粒信息Linux下可以运行sudo nvidia-smi -q | grep -A 20 Memory Usage不必拆卡。想深度诊断硬件故障的可以关注mats显卡检测这类工具但那是显存颗粒级诊断日常使用必要性不大。5. 显卡能驱动多大的模型——分档位的参考清单知道自己的显存后结合前文的公式就能“按图索骥”了。我根据实际经验按显存档位整理了一份可以参考的模型上限建议注意前提是使用量化加载和常规上下文4K到8K之间。显存容量适合推理的模型量级FP16含KV Cache适合的量化方案备注4GB0.5B-1B FP16或7B INT4低上下文7B INT4内存带宽或成瓶颈6GB3B-4B FP16或8B INT48B/14B INT4需要严格控制上下文长度8GB7B-8B INT47B/8B GPTQ或AWQ顺便说一句8GB显卡很适合跑轻量微调12GB7B-8B FP16或14B-34B INT414B/32B INT4目前社区最均衡容量16GB14B FP16或70B INT4低上下文70B AWQ需要放弃长上下文24GB32B-34B FP16或70B-110B INT470B INT4消费级旗舰甜点区48GB70B FP16或上百B INT470B FP16 / 130B INT4适合专攻服务部署注意这张表不是硬性标准因为同一个模型在不同推理框架下显存优化不同。比如vLLM在长并发场景下的KV Cache预分配方式与llama.cpp完全不同llama.cpp还支持部分层offload到CPU内存这虽然速度下降但把模型“塞进”低显存机器是可以的。消费级显卡里目前24GB的RTX 4090、16GB的RTX 4070 Ti SUPER、以及12GB的RTX 3060都算不同预算下比较有代表性的选择。专业卡里L20 48GB、A6000 48GB在服务场景很常见多卡并行时显存叠加NVLINK和PCIe带宽的区别决定了模型并行效率。如果在多卡异构环境下部署张量并行的负载分配逻辑又和同构卡不一样选型不能只看单卡容量。还有一个很多人会混淆的点游戏显卡和专业计算卡跑AI的本质区别。特斯拉P40 24GB目前二手价很便宜但它的计算架构是上古时代的Pascal没有BF16支持INT8速度也欠缺加上没有视频输出口想拿来游戏基本不现实。折腾它的时间和收益完全不成正比建议不碰。6. 常见崩溃场景与显存相关的排查路线显存OOM是跑模型遇到最多的异常但OOM和“运行速度慢到像死了”背后是完全不同的问题。下面几个场景基本覆盖了我被问过最多的疑难杂症。6.1 报OOM但显存看起来还有空余这种情况大概率是你没有区分“本机显存总量”和“单个CUDA process可分配的显存上限”。PyTorch在默认情况下会预留一部分显存作为缓存所以nvidia-smi里看到的used并不等于当前进程实际占用。如果你的代码里设置了torch.cuda.set_per_process_memory_fraction或容器限制了可用显存OOM即使在你看起来“还有3G”时依然出现。排查步骤也很固定先用nvidia-smi确认是不是其他进程也在占用显存再用lsof /dev/nvidia* | grep pythonLinux找出占显存的进程。现在还有更省事的办法nvidia-smi --query-compute-appspid,used_memory --formatcsv直接列出每个进程的显存占用比肉眼找要快很多。6.2 显卡驱动装不上或代码43这个问题在Windows平台上太典型了。代码43表示设备异常驱动无法正常驱动硬件如果你用的是N卡错误日志里往往还伴随着nvlddmkm事件。这种情况常见的原因有几个显卡是卡改版、驱动被组策略限制、PCIe供电不足甚至显卡是矿卡导致显存颗粒受损。mats显存检测在这个场景最有价值能直接定位到第几颗显存颗粒存在问题。如果只是驱动装不上强烈建议用DDUDisplay Driver Uninstaller在安全模式下去干净旧驱动再安装最新版。如果是装了新版驱动后才出现问题回退到两个月前的稳定版驱动也不失为一种办法。驱动这事情越新不一定越好。6.3 GPU利用率低但显存占满这往往意味着你的推理框架做了显存预分配但计算没有打满。真正原因通常是模型小、batch小、CPU预处理成为瓶颈或者推理时启用了CPU offload。如果是llama.cpp跑小模型默认线程数设置不合理时GPU核心利用率就是上不去。把--threads调低一点同时开--no-mmap有时性能差异很明显。另外框架层面的显存管理优化优先级其实高于硬件升级。llama.cpp、TransformersFlashAttention、vLLM都做了大量kernel融合和KV Cache页化管理同一个模型在这些框架下的显存占用可以差30%以上。如果某些框架跑不动换一个框架往往就解决了。6.4 AMD显卡跑不了CUDA生态这个话题在社区里其实已经很成熟了。通过社区适配层可以让大规模PyTorch程序在AMD显卡上调用CUDA API并翻译到ROCm后端或者直接使用原生ROCm版PyTorch不同显卡分支有对应支持的版本。我的建议是如果你已经拥有AMD显卡没有理由放弃试一下官方ROCm支持和社区方案很多常规推理已经可以跑起来。但如果你是全新采购短期内CUDA生态确实是更省心的路线——选择生态成熟的路线是技术选型中很重要的一环。7. 选完卡还不够推理框架和参数同样决定成败很多朋友问“显卡够大为什么跑得还是没有别人快”除了模型规模和显存推理框架选了谁、参数开了多少也会显著影响实际体验。我习惯把推理策略分为三个层次模型量化档位、KV Cache管理策略、以及batch和前缀共享策略。模型量化档位方面对于超过24GB显卡的用户来说优先尝试FP16或BF16因为这保留完整精度最大限度利用显存。显存紧张到临界点再考虑4bit量化。对于低显存用户AWQ和GPTQ是常用选择其中AWQ在Intel和NVIDIA新一代显卡上优化更好GPTQ则兼容性最广泛。如果你用llama.cpp这种环境下选项里有Q4_K_M、Q5_K_M、Q6_K等混合精度级别单看“K”这个字母背后其实藏着不同的层拆分策略Q4_K_M是多数业余玩家实际体验和显存占用最均衡的档位。KV Cache管理策略现在被叫得很高级其实核心逻辑就一句话让缓存复用起来。vLLM这类框架支持自动前缀缓存和paged KV Cache在多轮对话或多人共用并发推理时同样的前缀不需要重复计算能大幅降低显存占用和延迟。如果在单机跑长对话只是直观感觉越来越慢大概率也和KV Cache被打满、不断换页有关。batch大小也是显存位置的直接影响因素。在线服务场景下开了动态batching多用户请求拼在一个batch里同时推理显存占用会呈线性上升但总吞吐量提升远大于线性。所以服务化部署时显存预算要考虑的不是单用户场景而是自身设定的最大并发数。8. 选型之外还有两张“隐形”底牌很多时候显卡已经没法换了但显存焦虑还是能靠另外两条路缓解。第一条是CPU内存显存混合推理。llama.cpp、Transformers等框架都支持把一部分层放在GPU显存一部分放在内存。我拿一张8GB显卡实测跑14B模型GPU一半层数、CPU一半层数虽然速度慢了不少但至少模型能跑起来而且效果和完整显存推理没有差别。对于低显存玩家这种方法比“硬买显卡”更能解决燃眉之急。关键是层数分配比例怎么判断没有一个绝对标准。你可以反复试探也可以简单用“显存大小 ÷ 模型权重大小”粗估可offload的比例。我分享一个参考--n-gpu-layers 25这种写法表示GPU负责前25层如果OOM就逐步减少到22、20找到能稳定运行的上限即可。第二条是多卡并行。这里有个知识点多显卡跑同一个超大模型虽然单卡显存不够但多卡的显存可以聚合起来承载大模型。这里涉及张量并行、流水线并行等分配策略。我实际遇到最常见的问题是两张不同型号的显卡组异构并行时负载分配无法做到均匀速度会向慢卡对齐。如果准备长期跑大模型推理同型号同显存的两张卡比“一张大显存一张凑数卡”更靠谱。有人会问“既然显存能聚合那张24G不够插两张24G不就能跑70B”理论上成立但实际会卡在PCIe带宽和多卡通信效率上。跨卡通信每token都要同步数据如果走的PCIe通道带宽一般性能甚至不如单卡跑低阈值模型。真要玩多卡建议优先考虑支持高带宽互联的加速卡组合或者干脆咬牙上48G大显存卡。9. 最后再说两句经验显存和模型的关系说到底就是一道预算题。学会估算权重、KV Cache和context这三块开销明白量化精度怎么影响占用知道自己的卡在哪个档位剩下的事情就是多跑多测。我最常做的一件事是换模型前先看两张表——一张显存容量表一张模型参数量与量化规格表快速心算一下“装不装得下、留多少余量”再决定要不要下载权重。在这个基础上建议手上备一个标准测试流程用相同长度的输入、相同batch size跑一段固定内容记录显存峰值、生成速度和延迟。现在的框架版本迭代非常快同一模型不同版本、不同后端的表现差异很大用一套固定流程去测能帮你筛掉很多“看似快实则不稳”的方案。这张记录表比任何网上评测都更符合你自己的真实场景。你手里的显卡能跑多大模型不该靠别人一句“可以”或“不可以”来定义。把公式记住把流程走一遍答案自然就清楚了。 
长河君 · 2026/10/27 22:46:22 · 阅读 1.2k 显存估算与排查：从模型参数量、KV Cache到量化精度，算出显卡承载力
经常有朋友发一张配置截图问我“这套能不能跑本地大模型”“16G显存是不是就能无脑冲70B了”这类问题实在太多了。显存这东西决定了你的显卡到底能装下多大的模型、推理跑多快但它和“模型参数量”之间并不是简单的加减法关系。哪怕同一个模型用不同的加载精度、不同的上下文长度显存占用能差出一倍还多。我一直觉得与其到处问“能不能跑”不如自己学会那套显存估算和排查的方法。这篇文章就从载入、计算、推理三个阶段把显存怎么被吃掉的讲清楚再把“参数量-精度-KV Cache-显存”这条链路的计算公式拆开揉碎。中间会穿插我的实际测试数据以及踩过的各种坑比如OOM怎么办、为什么显卡占用率上不去、驱动层面常见报错怎么排查。看完你不仅能算出自己显卡的“模型承载力”还能在选卡、选模型、选量化档位时不那么纠结。1. 显存里到底装了什么东西很多人以为显存只用来放模型权重文件所以拿模型文件大小去对比显存大小够就万事大吉。这个理解只对了一小半。如果你的程序能被nvtop、任务管理器或nvidia-smi抓到一个稳定的显存占用数值那这个数值里其实装了好几类完全不同的数据。第一类是模型权重本身。这是最直观的部分也是很多人唯一想到的部分。权重在磁盘上占多少加载到显存里就差不多占多少只不过磁盘上是压缩存储格式显存里是运行格式两者存在细微差异。第二类是CUDA上下文和运行时环境。只要调用GPU做计算驱动和CUDA库就会在显存里开辟一块基础区域专门存kernel函数、线程调度、常量内存和上下文状态。我实测中这一块通常在300MB到800MB之间取决于CUDA版本和框架初始化方式。在只看大模型权重的人眼里这“凭空消失”的几百MB常常被忽略但对于8G、12G显存的用户来说它直接影响你能跑什么规模的模型。第三类是KV Cache也就是推理过程中缓存起来的中间计算结果。Transformer架构在生成每个token时需要反复读取之前所有token的Key和Value向量如果不把它们暂存在显存里就得每次重新计算性能直接崩溃。KV Cache的大小和上下文长度、层数、注意力头数呈线性关系后文我会给出计算公式。这也是为什么很多人跑同样的模型别人能跑自己一改参数就OOM多半是上下文长度设置不当。第四类是激活值activation也就是前向传播过程中每一层的临时中间输出。在训练、微调场景下激活值非常惊人但在纯推理场景只要不开启梯度计算激活值会逐层释放峰值占用不算太夸张。可一旦你在推理时开了gradient checkpointing或者做LoRA微调这部分显存会瞬间飙升好几个量级。清楚了这四类你就能理解为什么显存不够时降低上下文长度往往比切换更小模型更能立竿见影。我自己的习惯是先估算模型权重大头再留够KV Cache余量最后看一眼CUDA context那几百MB三层算完才是真正的显存需求。2. 模型参数量与显存占用的数学拆解大模型的参数量一般以BBillion十亿为单位比如7B、8B、13B、70B。将参数量换算成显存占用需要看加载精度。FP32格式每个参数占4字节FP16/BF16占2字节INT8占1字节INT4约0.5字节。计算公式是权重显存 ≈ 参数量B× 精度字节数 × 1.13最后乘的1.13是冗余系数包括layer normalization里的参数对齐、embedding表冗余、以及PyTorch/HF加载时额外的内存对齐开销。举几个跑过的例子7B模型用FP16加载约7 × 2 × 1.13 ≈ 15.8GB这解释了为什么8GB显卡原生FP16跑7B非常吃力就算勉强塞进去KV Cache一进去就爆。7B模型用INT4量化约7 × 0.5 × 1.13 ≈ 4GB加上KV Cache和context8GB显卡勉强能跑也能解释为什么社区里流行“8G显存跑7B量化”。70B模型用FP16加载约70 × 2 × 1.13 ≈ 158GB普通单卡根本没戏所以才需要多卡并行或者高压缩比量化。70B用INT4量化约70 × 0.5 × 1.13 ≈ 40GB这时一张48GB的L20或A6000就有机会跑起来这也是为什么专业计算卡在大模型时代突然变香。KV Cache的大小就没有权重那么“整齐”了它由模型结构和生成长度共同决定。计算公式是KV CacheGB ≈ 2 × 层数 × 注意力头维度 × 头数 × 序列长度 × 2字节 ÷ 1024³这里的×2是因为每个token要存Key和Value两份。以LLaMA 7B为例层数32、头数32、每头维度128那么每个token的KV Cache约为32 × 32 × 128 × 2 × 2 ÷ 1024³ ≈ 0.5MB。生成2K上下文就是约1GB16K上下文就是约8GB量级一下就上来了。这也是为什么长上下文推理的显存大头往往从“权重”转移到了“显存里的QA对”。所以一个完整的显存预算公式应该是总显存 ≈ 权重显存 KV Cache CUDA context 激活值余量我实测跑13B FP16模型、上下文4K时nvidia-smi显示23GB左右权重约29.4GB只是理论值说明KV Cache和context这些“杂项”至少多了几个GB。如果你计划跑32K上下文那KV Cache这么一算很多24GB显卡基本没戏。3. 量化精度看着省一半实际能省多少量化是当前消费级显卡跑大模型最核心的手段。模型量化理解起来不难FP16的权重储存在2字节里为了减小体积和显存把权重映射到更小的整数范围比如INT8的256级、INT4的16级。这样做确实省显存但代价是精度损失。一个常见误区是“4bit量化是不是比8bit省一半”理论上是但实际运行时有差异。量化的权重在加载后通常会反量化到FP16再进行矩阵乘法所以“显存占用减半”只在权重存储层面成立计算过程中依然要用FP16或BF16做矩阵乘法尤其某些推理引擎开不了真正的kernal融合时内存占用并没有想象中低那么多。另一个问题是量化不止是简单的“砍位宽”。实际落地到核心推理引擎里4bit和8bit往往采用group quantization的方式也就是将权重按小块比如64个数值一组做缩放因子每一组有一个scale和zero_point推理时要动态计算反量化。这种方案在显存中不仅要存量化后的整数权重还要额外存每个组的scale和zero_point。所以“7B模型INT4大约4GB”这种估算是近似值真实落地可能多出几百MB。我实测了一组数据供参考使用同一样本、同一设备RTX 3060 12GB加载Qwen2.5-7B加载模式权重文件大小推理时峰值显存占用生成速度tokens/s原生FP1613.9GB14.9GB加context无法运行OOM8bit量化7.4GB9.1GB8.54bit量化GPTQ4.3GB6.2GB12.14bit量化AWQ4.6GB6.5GB11.4能明显看到量化带来的显存收益很大但速度上因为反量化开销反而不一定更快4bit和8bit的速度差异主要由内存带宽和反量化算法决定。在选型时不要简单以为“量化级别越低越好”。4. 实操两条命令摸透你显卡的家底在聊选型对策之前强烈建议你先搞清楚自己手头显卡的几项硬性参数显存容量、显存类型和位宽、算力版本Compute Capability。三个参数决定了你的显卡在AI推理里的天花板。查看nvidia-smi的常规方式我就不赘述了重点说几个容易忽略的命令nvidia-smi -L只列出GPU信息简洁不刷屏。nvidia-smi --query-gpuname,memory.total,memory.free,memory.used,temperature.gpu,utilization.gpu --formatcsv一次性输出关键指标适合写脚本或定时监控。nvidia-smi dmon -s p实时看GPU利用率、温度、功耗观察推理瓶颈时非常有用。关于如何实时看CPU和显卡占用率的问题除了任务管理器Linux下我最常用的是nvtop它比任务管理器直观太多能把每个GPU的核心占用、显存占用、功耗、温度以及进程列表都展示出来还在同一个界面上对比观察。Windows下可以用MSI Afterburner的OSD叠加显示或者直接用PowerShell查Get-Counter \GPU Process Memory\Dedicated Usage。识别出的GPU架构信息可以直接影响推理依赖的扩展指令集。比如3090/4090支持SM80/SM89架构能用较新的FlashAttention优化而1660这类图灵架构虽然也有Tensor Core但功能受限部分优化跑不起来。如果核显或旧卡跑不了GPU版PyTorch常常就是算力兼容性问题。查看显存位置和PCB图一说其实也简单显存颗粒一般围绕核心呈环状排列12颗或24颗对称分布。如果你想要更细的颗粒信息Linux下可以运行sudo nvidia-smi -q | grep -A 20 Memory Usage不必拆卡。想深度诊断硬件故障的可以关注mats显卡检测这类工具但那是显存颗粒级诊断日常使用必要性不大。5. 显卡能驱动多大的模型——分档位的参考清单知道自己的显存后结合前文的公式就能“按图索骥”了。我根据实际经验按显存档位整理了一份可以参考的模型上限建议注意前提是使用量化加载和常规上下文4K到8K之间。显存容量适合推理的模型量级FP16含KV Cache适合的量化方案备注4GB0.5B-1B FP16或7B INT4低上下文7B INT4内存带宽或成瓶颈6GB3B-4B FP16或8B INT48B/14B INT4需要严格控制上下文长度8GB7B-8B INT47B/8B GPTQ或AWQ顺便说一句8GB显卡很适合跑轻量微调12GB7B-8B FP16或14B-34B INT414B/32B INT4目前社区最均衡容量16GB14B FP16或70B INT4低上下文70B AWQ需要放弃长上下文24GB32B-34B FP16或70B-110B INT470B INT4消费级旗舰甜点区48GB70B FP16或上百B INT470B FP16 / 130B INT4适合专攻服务部署注意这张表不是硬性标准因为同一个模型在不同推理框架下显存优化不同。比如vLLM在长并发场景下的KV Cache预分配方式与llama.cpp完全不同llama.cpp还支持部分层offload到CPU内存这虽然速度下降但把模型“塞进”低显存机器是可以的。消费级显卡里目前24GB的RTX 4090、16GB的RTX 4070 Ti SUPER、以及12GB的RTX 3060都算不同预算下比较有代表性的选择。专业卡里L20 48GB、A6000 48GB在服务场景很常见多卡并行时显存叠加NVLINK和PCIe带宽的区别决定了模型并行效率。如果在多卡异构环境下部署张量并行的负载分配逻辑又和同构卡不一样选型不能只看单卡容量。还有一个很多人会混淆的点游戏显卡和专业计算卡跑AI的本质区别。特斯拉P40 24GB目前二手价很便宜但它的计算架构是上古时代的Pascal没有BF16支持INT8速度也欠缺加上没有视频输出口想拿来游戏基本不现实。折腾它的时间和收益完全不成正比建议不碰。6. 常见崩溃场景与显存相关的排查路线显存OOM是跑模型遇到最多的异常但OOM和“运行速度慢到像死了”背后是完全不同的问题。下面几个场景基本覆盖了我被问过最多的疑难杂症。6.1 报OOM但显存看起来还有空余这种情况大概率是你没有区分“本机显存总量”和“单个CUDA process可分配的显存上限”。PyTorch在默认情况下会预留一部分显存作为缓存所以nvidia-smi里看到的used并不等于当前进程实际占用。如果你的代码里设置了torch.cuda.set_per_process_memory_fraction或容器限制了可用显存OOM即使在你看起来“还有3G”时依然出现。排查步骤也很固定先用nvidia-smi确认是不是其他进程也在占用显存再用lsof /dev/nvidia* | grep pythonLinux找出占显存的进程。现在还有更省事的办法nvidia-smi --query-compute-appspid,used_memory --formatcsv直接列出每个进程的显存占用比肉眼找要快很多。6.2 显卡驱动装不上或代码43这个问题在Windows平台上太典型了。代码43表示设备异常驱动无法正常驱动硬件如果你用的是N卡错误日志里往往还伴随着nvlddmkm事件。这种情况常见的原因有几个显卡是卡改版、驱动被组策略限制、PCIe供电不足甚至显卡是矿卡导致显存颗粒受损。mats显存检测在这个场景最有价值能直接定位到第几颗显存颗粒存在问题。如果只是驱动装不上强烈建议用DDUDisplay Driver Uninstaller在安全模式下去干净旧驱动再安装最新版。如果是装了新版驱动后才出现问题回退到两个月前的稳定版驱动也不失为一种办法。驱动这事情越新不一定越好。6.3 GPU利用率低但显存占满这往往意味着你的推理框架做了显存预分配但计算没有打满。真正原因通常是模型小、batch小、CPU预处理成为瓶颈或者推理时启用了CPU offload。如果是llama.cpp跑小模型默认线程数设置不合理时GPU核心利用率就是上不去。把--threads调低一点同时开--no-mmap有时性能差异很明显。另外框架层面的显存管理优化优先级其实高于硬件升级。llama.cpp、TransformersFlashAttention、vLLM都做了大量kernel融合和KV Cache页化管理同一个模型在这些框架下的显存占用可以差30%以上。如果某些框架跑不动换一个框架往往就解决了。6.4 AMD显卡跑不了CUDA生态这个话题在社区里其实已经很成熟了。通过社区适配层可以让大规模PyTorch程序在AMD显卡上调用CUDA API并翻译到ROCm后端或者直接使用原生ROCm版PyTorch不同显卡分支有对应支持的版本。我的建议是如果你已经拥有AMD显卡没有理由放弃试一下官方ROCm支持和社区方案很多常规推理已经可以跑起来。但如果你是全新采购短期内CUDA生态确实是更省心的路线——选择生态成熟的路线是技术选型中很重要的一环。7. 选完卡还不够推理框架和参数同样决定成败很多朋友问“显卡够大为什么跑得还是没有别人快”除了模型规模和显存推理框架选了谁、参数开了多少也会显著影响实际体验。我习惯把推理策略分为三个层次模型量化档位、KV Cache管理策略、以及batch和前缀共享策略。模型量化档位方面对于超过24GB显卡的用户来说优先尝试FP16或BF16因为这保留完整精度最大限度利用显存。显存紧张到临界点再考虑4bit量化。对于低显存用户AWQ和GPTQ是常用选择其中AWQ在Intel和NVIDIA新一代显卡上优化更好GPTQ则兼容性最广泛。如果你用llama.cpp这种环境下选项里有Q4_K_M、Q5_K_M、Q6_K等混合精度级别单看“K”这个字母背后其实藏着不同的层拆分策略Q4_K_M是多数业余玩家实际体验和显存占用最均衡的档位。KV Cache管理策略现在被叫得很高级其实核心逻辑就一句话让缓存复用起来。vLLM这类框架支持自动前缀缓存和paged KV Cache在多轮对话或多人共用并发推理时同样的前缀不需要重复计算能大幅降低显存占用和延迟。如果在单机跑长对话只是直观感觉越来越慢大概率也和KV Cache被打满、不断换页有关。batch大小也是显存位置的直接影响因素。在线服务场景下开了动态batching多用户请求拼在一个batch里同时推理显存占用会呈线性上升但总吞吐量提升远大于线性。所以服务化部署时显存预算要考虑的不是单用户场景而是自身设定的最大并发数。8. 选型之外还有两张“隐形”底牌很多时候显卡已经没法换了但显存焦虑还是能靠另外两条路缓解。第一条是CPU内存显存混合推理。llama.cpp、Transformers等框架都支持把一部分层放在GPU显存一部分放在内存。我拿一张8GB显卡实测跑14B模型GPU一半层数、CPU一半层数虽然速度慢了不少但至少模型能跑起来而且效果和完整显存推理没有差别。对于低显存玩家这种方法比“硬买显卡”更能解决燃眉之急。关键是层数分配比例怎么判断没有一个绝对标准。你可以反复试探也可以简单用“显存大小 ÷ 模型权重大小”粗估可offload的比例。我分享一个参考--n-gpu-layers 25这种写法表示GPU负责前25层如果OOM就逐步减少到22、20找到能稳定运行的上限即可。第二条是多卡并行。这里有个知识点多显卡跑同一个超大模型虽然单卡显存不够但多卡的显存可以聚合起来承载大模型。这里涉及张量并行、流水线并行等分配策略。我实际遇到最常见的问题是两张不同型号的显卡组异构并行时负载分配无法做到均匀速度会向慢卡对齐。如果准备长期跑大模型推理同型号同显存的两张卡比“一张大显存一张凑数卡”更靠谱。有人会问“既然显存能聚合那张24G不够插两张24G不就能跑70B”理论上成立但实际会卡在PCIe带宽和多卡通信效率上。跨卡通信每token都要同步数据如果走的PCIe通道带宽一般性能甚至不如单卡跑低阈值模型。真要玩多卡建议优先考虑支持高带宽互联的加速卡组合或者干脆咬牙上48G大显存卡。9. 最后再说两句经验显存和模型的关系说到底就是一道预算题。学会估算权重、KV Cache和context这三块开销明白量化精度怎么影响占用知道自己的卡在哪个档位剩下的事情就是多跑多测。我最常做的一件事是换模型前先看两张表——一张显存容量表一张模型参数量与量化规格表快速心算一下“装不装得下、留多少余量”再决定要不要下载权重。在这个基础上建议手上备一个标准测试流程用相同长度的输入、相同batch size跑一段固定内容记录显存峰值、生成速度和延迟。现在的框架版本迭代非常快同一模型不同版本、不同后端的表现差异很大用一套固定流程去测能帮你筛掉很多“看似快实则不稳”的方案。这张记录表比任何网上评测都更符合你自己的真实场景。你手里的显卡能跑多大模型不该靠别人一句“可以”或“不可以”来定义。把公式记住把流程走一遍答案自然就清楚了。