1. 显卡跑模型这件事先把账算明白很多人拿到一张显卡第一反应是装环境、拉模型、跑起来再说。结果往往是模型加载到一半直接报CUDA out of memory或者勉强跑起来但生成速度慢到怀疑人生。折腾一整天最后发现根本问题是这张卡的显存压根跑不动这个模型。显存计算与模型选择说白了就是一道算术题。你得先搞清楚三件事模型本身占多少显存、推理过程中的中间激活值占多少、以及你用的精度格式会让显存需求翻几倍。把这三笔账算清楚再去选卡或者选模型就不会出现“装完才发现跑不了”的尴尬。这篇文章适合两类人看。一类是手里已经有显卡、想知道自己能跑多大模型的人另一类是准备入手显卡、想搞清楚“买多大显存才够用”的人。我会从显存占用的底层逻辑讲起把参数量、精度、量化、KV Cache 这些概念串起来给出可以直接套用的估算公式和实测数据最后再聊聊低显存环境下怎么把模型跑起来。核心关键词先摆出来显存、模型、显卡、CUDA、量化。这五个词贯穿全文你把这五个东西之间的关系搞明白了选卡和选模型就是水到渠成的事。2. 显存到底被谁吃掉了2.1 模型权重的显存占用参数量乘以精度字节数模型权重的显存占用是最容易算的部分。公式很简单权重显存 参数量 × 每个参数占用的字节数不同精度下每个参数的字节数不一样精度格式每参数字节数7B模型权重占用13B模型权重占用70B模型权重占用FP324 bytes28 GB52 GB280 GBFP16/BF162 bytes14 GB26 GB140 GBINT81 byte7 GB13 GB70 GBINT40.5 byte3.5 GB6.5 GB35 GB这张表你最好记在脑子里。举个例子一张 16G 显存的卡跑 FP16 精度的 7B 模型光权重就吃掉 14G剩下 2G 要留给 KV Cache 和中间激活值基本上刚够加载稍微长一点的对话就会 OOM。但如果你用 INT4 量化权重只占 3.5G剩下的 12.5G 可以支撑相当长的上下文。这里有个容易踩的坑量化后的模型并不是所有层都用同样的精度。很多量化方案比如 GPTQ、AWQ会对敏感层保留较高精度实际占用会比理论值略高一些。我实测过一个 7B 的 INT4 量化模型理论值 3.5G实际加载后显存占用在 4.2G 左右多出来的部分就是那些保留高精度的层和量化元数据。2.2 KV Cache长上下文真正的显存杀手很多人算显存只算模型权重忽略了 KV Cache结果一跑长文本就崩。KV Cache 是 Transformer 推理时缓存 Key 和 Value 矩阵用的它的显存占用跟上下文长度成正比。计算公式如下KV Cache 显存 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × 精度字节数简化一下对于大多数主流模型可以用这个经验公式KV Cache 显存 ≈ 序列长度 × 隐藏层维度 × 2 × 层数 × 精度字节数以 LLaMA-2 7B 为例32 层隐藏维度 4096FP16 精度序列长度 2048 时2048 × 4096 × 2 × 32 × 2 bytes ≈ 2.1 GB序列长度 8192 时约 8.6 GB序列长度 32768 时约 34 GB看到没有上下文拉到 32K光 KV Cache 就要 34G比模型权重本身还大。这就是为什么长上下文模型对显存的要求极其苛刻。注意上面算的是单条请求的 KV Cache。如果你要同时处理多个请求batch inferenceKV Cache 会成倍增长。实际部署时batch size 和上下文长度是两个需要权衡的变量。2.3 中间激活值容易被忽略的第三块开销除了权重和 KV Cache推理过程中还有中间激活值。这部分显存占用跟 batch size 和序列长度有关但在推理场景下通常比训练时小很多。对于单条推理请求中间激活值一般在几百 MB 到 1-2 GB 之间。不过有一个例外如果你用的是 HuggingFace Transformers 默认加载方式它会预分配一些额外的显存。我实测过同一个模型用device_mapauto加载和用 llama.cpp 加载显存占用能差出 1-2G。原因就是 Transformers 的加载策略比较“大方”会预留一些 buffer。2.4 显存占用的完整拼图把上面三块拼起来推理时的总显存占用大致是总显存 模型权重 KV Cache 中间激活值 CUDA 上下文开销CUDA 上下文本身也要占几百 MB这部分是固定开销跑什么模型都躲不掉。所以你在估算的时候最好在算出来的数字上再加 1-1.5G 的余量。一张 24G 显存的卡比如 RTX 3090/4090实际可用显存大概在 23G 左右。跑 FP16 的 13B 模型权重 26G 就已经超了必须量化。跑 INT8 的 13B 模型权重 13G剩下 10G 可以给 KV Cache 和激活值上下文能开到 8K 左右。跑 INT4 的 13B 模型权重 6.5G剩下 16G 多上下文可以拉到 16K 甚至更高。3. 量化小显存跑大模型的核心手段3.1 量化到底在做什么量化的本质是用更少的比特数来表示模型权重。FP16 用 16 位表示一个参数INT8 用 8 位INT4 用 4 位。比特数减半显存占用就减半这是最直接的收益。但量化不是免费的午餐。降低精度会带来信息损失表现为模型输出质量下降。关键在于损失多少、损失在哪里、能不能接受。目前主流的量化方案分两大类训练后量化PTQ模型训练完之后再做量化不需要重新训练。GPTQ、AWQ、GGUF 都属于这一类。量化感知训练QAT训练过程中就模拟量化误差让模型适应低精度。效果更好但成本高一般用在生产环境。对于个人用户来说PTQ 是唯一现实的选择。你下载一个已经量化好的模型直接加载就行不需要自己动手量化。3.2 GPTQ、AWQ、GGUF 怎么选这三个格式是目前最常见的量化模型格式各有各的适用场景格式适用场景优点缺点GPTQGPU 推理生态成熟vLLM/TGI 支持好量化过程较慢对校准集敏感AWQGPU 推理精度保持更好推理速度快生态相对 GPTQ 略少GGUFCPU/GPU 混合推理灵活支持 CPU 卸载GPU 纯推理速度不如 GPTQ/AWQ我个人的选择逻辑是这样的如果你有足够的显存把整个模型放进 GPU优先选 AWQ 或 GPTQ用 vLLM 部署吞吐量最高。如果显存不够需要把部分层卸载到 CPU那就选 GGUF用 llama.cpp 跑。实操心得AWQ 在 4-bit 下的精度保持普遍比 GPTQ 好一点尤其是在代码生成和数学推理任务上。但 GPTQ 的模型资源更多社区支持更广。如果你找不到某个模型的 AWQ 版本用 GPTQ 也完全没问题。3.3 量化等级的选择Q4、Q5 还是 Q8以 GGUF 格式为例常见的量化等级有 Q2_K、Q3_K、Q4_K_M、Q5_K_M、Q6_K、Q8_0 等。数字越大精度越高显存占用也越大。我的建议是7B 模型Q4_K_M 是甜点显存占用约 4.5G质量损失很小。追求更高质量可以上 Q5_K_M 或 Q6_K。13B 模型Q4_K_M 约 8GQ5_K_M 约 9.5G。24G 显存的卡跑 Q5_K_M 很舒服。70B 模型Q4_K_M 约 40G需要两张 24G 的卡或者一张 48G 的卡。Q2_K 约 26G但质量损失明显不太推荐。有一个常见的误区Q4 和 Q5 的质量差距在大多数任务上肉眼看不出来。我做过对比测试Q4_K_M 和 Q5_K_M 在对话、摘要、翻译任务上的输出几乎一致只有在复杂的数学推理和代码生成上Q5 会稍微稳一点。所以如果你的显存紧张果断上 Q4不要为了那一点点质量提升去牺牲上下文长度。4. 不同显存档位能跑什么模型4.1 8G 显存入门级7B 量化是极限8G 显存的卡比如 RTX 3060 Ti、RTX 2070能跑的模型非常有限。7B INT4 量化权重约 4G剩下 4G 给 KV Cache 和激活值。上下文能开到 4K 左右再长就 OOM。13B INT4 量化权重约 7G剩下 1G 不到基本跑不动。除非用 GGUF 把部分层卸载到 CPU但速度会慢很多。3B 或更小的模型FP16 精度可以跑质量嘛只能说凑合用。8G 卡的用户我建议直接上 7B 的 Q4 量化模型用 llama.cpp 或者 Ollama 跑上下文控制在 4K 以内。不要想着跑 13B体验会很差。4.2 12G 显存7B 舒适区13B 勉强12G 显存的卡比如 RTX 3060 12G、RTX 4070选择空间大一些。7B FP16权重 14G超了。必须量化。7B INT8权重 7G剩下 5G上下文可以开到 8K。7B INT4权重 4G剩下 8G上下文可以开到 16K 甚至 32K。13B INT4权重 7G剩下 5G上下文 4K 左右。12G 卡跑 7B 的 INT4 量化是最舒服的上下文可以拉得很长。13B 的 INT4 也能跑但上下文受限适合短对话场景。4.3 16G 显存13B 量化主场16G 显存的卡比如 RTX 4060 Ti 16G、RTX 4080是一个比较尴尬的档位。比上不足比下有余。13B INT4权重 7G剩下 9G上下文可以开到 8K-16K。13B INT8权重 13G剩下 3G上下文只能开 2K 左右。7B FP16权重 14G剩下 2G上下文很短。7B INT4权重 4G剩下 12G上下文可以拉到 32K 甚至 64K。16G 卡的最佳选择是 13B 的 INT4 量化或者 7B 的 INT4 量化拉长上下文。如果你主要做长文档处理7B INT4 加长上下文可能比 13B INT4 短上下文更实用。4.4 24G 显存13B 舒适区70B 量化可尝试24G 显存的卡比如 RTX 3090、RTX 4090是目前个人用户的主流选择。13B FP16权重 26G超了一点点。用 INT8 可以跑权重 13G剩下 11G上下文 8K-16K。13B INT4权重 7G剩下 17G上下文可以拉到 32K 以上。70B INT4权重 35G超了。需要两张 24G 的卡或者用 GGUF 卸载部分层到 CPU。34B INT4权重 17G剩下 7G上下文 4K-8K。24G 卡跑 13B 的 INT4 量化是最优解上下文和速度都很舒服。如果你想跑 70B要么上双卡要么接受 CPU 卸载带来的速度下降。4.5 48G 及以上70B 量化可以一战48G 显存的卡比如 A6000、双卡 4090可以比较舒服地跑 70B 的 INT4 量化模型。权重 35G剩下 13G 给 KV Cache 和激活值上下文能开到 8K 左右。如果显存再大一些比如 80G 的 A100可以跑 70B 的 INT8 量化或者 70B FP16 的多卡方案。注意多卡跑模型并不是简单的显存叠加。张量并行会带来通信开销实际可用显存和推理速度都会打折扣。两张 24G 的卡跑 70B INT4实际体验可能不如一张 48G 的单卡。5. 实操从零估算你的显卡能跑什么模型5.1 第一步确认显卡的实际可用显存很多人看显卡参数写着 16G就以为能用 16G。实际上操作系统和显示输出会占用一部分显存。在 Windows 下桌面环境可能吃掉 1-2G 显存。在 Linux 无桌面环境下占用会小很多。你可以用nvidia-smi命令查看实际可用显存nvidia-smi --query-gpumemory.total,memory.used,memory.free --formatcsv输出会显示总显存、已用显存和空闲显存。空闲显存才是你能用来跑模型的数字。实操心得在 Windows 下跑模型建议把显示输出接到核显上让独显完全空出来跑模型。这样能多出 1-2G 的可用显存对于 8G 或 12G 的卡来说这 1-2G 可能就是能不能跑起来的关键。5.2 第二步确定模型参数量和量化等级假设你要跑一个 13B 的模型选择 INT4 量化。权重占用约 6.5-7G。你的显卡有 12G 可用显存那么剩下 5G 给 KV Cache 和激活值。5.3 第三步反推最大上下文长度用 KV Cache 的公式反推最大序列长度 剩余显存 / (2 × 层数 × 隐藏维度 × 精度字节数)以 LLaMA-2 13B 为例40 层隐藏维度 5120INT4 量化后 KV Cache 的精度通常还是 FP16每 token 的 KV Cache 占用 2 × 40 × 5120 × 2 bytes 819,200 bytes ≈ 0.78 MB5G 剩余显存可以支撑5 × 1024 / 0.78 ≈ 6560 tokens所以 12G 卡跑 13B INT4上下文大概能开到 6K 左右。实际使用中留点余量设成 4K 比较稳妥。5.4 第四步实测验证理论算完之后一定要实测。用 llama.cpp 或 vLLM 加载模型逐步增加上下文长度观察显存变化。我一般会写一个简单的脚本循环发送不同长度的请求记录显存峰值import subprocess import time def get_gpu_memory(): result subprocess.run( [nvidia-smi, --query-gpumemory.used, --formatcsv,noheader,nounits], capture_outputTrue, textTrue ) return int(result.stdout.strip()) # 记录基线显存 baseline get_gpu_memory() print(f基线显存: {baseline} MB) # 加载模型后记录 # ... 加载模型代码 ... after_load get_gpu_memory() print(f加载后显存: {after_load} MB模型占用: {after_load - baseline} MB) # 发送长请求后记录 # ... 推理代码 ... after_inference get_gpu_memory() print(f推理后显存: {after_inference} MBKV Cache 占用: {after_inference - after_load} MB)这个脚本能帮你快速摸清模型的实际显存占用比纯理论计算靠谱得多。6. 低显存环境的生存技巧6.1 CPU 卸载用时间换空间llama.cpp 支持把部分层卸载到 CPU 内存只把关键层放在 GPU 上。这样可以用小显存跑大模型代价是推理速度下降。卸载策略很简单-ngl参数控制卸载到 GPU 的层数。层数越多GPU 占用越高速度越快。你需要找到一个平衡点让显存刚好不爆同时速度可以接受。我实测过一张 8G 的卡跑 13B Q4 模型-ngl设成 20总共 40 层显存占用约 7G推理速度大概 3-5 tokens/秒。虽然慢但能用。注意CPU 卸载对内存带宽要求很高。DDR4 和 DDR5 的速度差距在推理速度上体现得很明显。如果你打算用 CPU 卸载方案建议至少 32G 内存DDR5 更好。6.2 滑动窗口注意力Longformer 的思路标准 Transformer 的注意力复杂度是 O(n²)序列长度翻倍KV Cache 翻四倍。滑动窗口注意力把每个 token 的注意力范围限制在窗口内复杂度降到 O(n)。Longformer 是这方面的经典工作它用滑动窗口加全局注意力的方式把长文档处理的显存需求大幅降低。虽然现在主流大模型大多用 RoPE 加各种外推技巧但滑动窗口的思路在低显存场景下依然有参考价值。如果你要处理超长文档但显存有限可以考虑用支持滑动窗口注意力的模型或者用分块处理的方式把长文档切成小块分别推理再合并结果。6.3 批处理与流式输出批处理能提高吞吐量但会成倍增加 KV Cache 占用。低显存环境下建议 batch size 设为 1用流式输出逐 token 返回结果。这样显存占用最低用户体验也不差。vLLM 的--max-num-seqs参数控制并发序列数低显存环境下设成 1 或 2。llama.cpp 的-b参数控制 batch size同样设小一点。6.4 显存碎片与 CUDA 上下文优化长时间运行推理服务显存碎片会逐渐累积最终导致 OOM。解决方法有两个一是定期重启服务二是用PYTORCH_CUDA_ALLOC_CONF环境变量优化显存分配策略。export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True这个设置让 PyTorch 使用可扩展的显存段减少碎片。我实测下来开启后长时间运行的稳定性有明显提升。7. 常见问题与排查实录7.1 加载模型就 OOM但显存明明够这种情况通常是 CUDA 上下文开销和框架预分配导致的。Transformers 默认会预分配一些显存实际占用比理论值高。解决方法用device_mapauto让框架自动分配设置torch_dtypetorch.float16减少精度用low_cpu_mem_usageTrue减少 CPU 内存占用换用 llama.cpp 或 vLLM它们的显存管理更精细7.2 推理过程中 OOM但加载时正常这是 KV Cache 增长导致的。上下文越长KV Cache 越大最终撑爆显存。解决方法限制最大上下文长度使用滑动窗口注意力开启 KV Cache 量化INT8 KV Cache 能省一半显存减少 batch size7.3 多卡跑模型显存没有叠加多卡推理有张量并行和流水线并行两种模式。张量并行会把模型切分到多张卡上但每张卡还需要额外的通信 buffer。实际可用显存不是简单的 24G 24G 48G而是会打折扣。另外如果你用的是数据并行每张卡都会加载完整的模型显存并不会叠加。7.4 量化后模型质量下降明显量化等级太低比如 Q2_K会导致明显的质量下降。建议至少用 Q4_K_M条件允许上 Q5_K_M 或 Q6_K。另外校准集的选择也会影响量化质量。如果量化时用的校准集和你的实际任务差异很大量化后的模型在你的任务上表现会更差。尽量选择与任务领域匹配的量化版本。7.5 常见问题速查表问题现象可能原因解决方法加载时 OOM框架预分配过多换 llama.cpp设 low_cpu_mem_usage推理中 OOMKV Cache 增长限制上下文长度开 KV Cache 量化多卡显存不叠加并行模式不对确认用张量并行检查通信 buffer量化后质量差量化等级太低换 Q4_K_M 以上检查校准集速度慢CPU 卸载过多增加 -ngl 层数换 DDR5 内存显存碎片长时间运行定期重启开 expandable_segments8. 选卡与选模型的决策框架8.1 先定模型再定显卡很多人是先买卡再选模型结果发现卡跑不动想用的模型。正确的顺序应该是先确定你要跑什么模型、什么量化等级、多长上下文然后反推需要多少显存最后选卡。比如你要跑 13B INT4 模型上下文 8K那么显存需求大概是权重7GKV Cache8K × 0.78MB ≈ 6.2G激活值 CUDA 开销2G总计约 15.2G所以你需要一张 16G 以上的卡。24G 的卡会更从容可以留出更多余量。8.2 显存优先于算力对于大模型推理来说显存比算力更重要。一张 24G 的 3090 能跑的模型一张 12G 的 4070 Ti 跑不了哪怕后者算力更强。所以选卡的时候显存容量是第一优先级其次是显存带宽最后才是 CUDA 核心数。8.3 量化等级与上下文长度的权衡在显存固定的情况下量化等级和上下文长度是此消彼长的关系。降低量化等级可以省出显存给上下文反之亦然。我的建议是优先保证上下文长度够用再考虑提升量化等级。因为上下文不够用是硬伤模型直接没法处理你的任务而量化等级低一点质量损失在大多数任务上并不明显。8.4 不同预算的配置建议预算档位推荐显卡显存能跑的模型适用场景入门RTX 3060 12G12G7B INT4 长上下文个人学习、短对话主流RTX 4060 Ti 16G16G13B INT4 中上下文日常使用、文档处理进阶RTX 3090/4090 24G24G13B INT4 长上下文专业使用、长文档高端双卡 4090 / A600048G70B INT4 中上下文重度使用、多任务这张表只是参考具体选择还要看你的实际需求和预算。如果你只是偶尔跑跑对话12G 的卡完全够用。如果你要做长文档分析或者代码生成24G 的卡会更合适。9. 我踩过的坑和实测经验9.1 不要迷信理论值理论计算只是起点实际显存占用受框架、驱动、系统环境影响很大。同一个模型在 Windows 和 Linux 下的显存占用能差 1-2G。所以算完之后一定要实测以实测为准。9.2 显存监控要实时跑模型的时候开着nvidia-smi -l 1实时监控显存变化。这样能在 OOM 之前发现问题及时调整参数。我习惯用watch -n 1 nvidia-smi每秒刷新一次显存曲线一目了然。9.3 量化模型也有“体质”差异同样是 Q4_K_M不同人量化出来的模型质量可能不一样。校准集的选择、量化工具的参数设置都会影响最终效果。尽量选择社区口碑好的量化版本或者自己用高质量校准集重新量化。9.4 上下文长度不要设满理论最大上下文是 8K你就设 8K结果稍微长一点的输入就 OOM。留 20% 的余量设成 6K 或 6.5K稳定性会好很多。9.5 定期清理显存Python 进程退出后显存不一定立即释放。如果频繁加载卸载模型显存会逐渐泄漏。解决方法是在加载新模型前手动调用torch.cuda.empty_cache()或者直接重启 Python 进程。9.6 驱动和 CUDA 版本要匹配CUDA 版本和显卡驱动的兼容性问题会导致各种奇怪的报错。建议用nvidia-smi查看驱动支持的 CUDA 版本然后安装对应版本的 PyTorch。不要盲目装最新版稳定比新功能重要。最后分享一个小技巧如果你不确定一张卡能不能跑某个模型先去网上搜一下别人的实测数据。HuggingFace 的模型页面、Reddit 的 LocalLLaMA 板块、各种技术社区都有大量实测记录。别人的经验能帮你省下很多试错时间。这个内容后续还可以这样扩展针对特定模型比如 Qwen、LLaMA、Mistral做详细的显存实测或者针对特定任务代码生成、长文档摘要给出具体的配置建议。显存计算这件事理论是骨架实测是血肉两者结合才能真正把显卡的潜力榨干。