前两天有个朋友发了张截图给我Ollama 里拉下来的模型文件 56GB他的显卡只有 32GB 显存居然真跑起来了还吭哧吭哧地吐 token。他问我这合理吗是不是模型偷偷被量化缩水了我的回答是就算不量化56GB 的权重也未必非得整包塞进 32GB 显存里。大模型推理引擎早就不是先装满再算那种玩法了。真正让这件事成立的是一整套从 Shared Memory 到 AI 异构内存架构的调度机制。这篇文章就把这层窗户纸捅破从显存里到底存了什么讲起一直聊到 mmap、layer offload、量化、KV Cache 这些实操里躲不开的东西最后给几套可以直接抄的配置。如果你手头显卡显存不大或者正打算用 16GB、32GB 显存去跑那些理论上装不下的开源模型这篇文章值得看完。1. 先对齐概念56GB 是仓库里的货32GB 是工作台1.1 56GB 这个数字是怎么来的很多人看到模型文件 56GB第一反应是我的显存只有 32GB所以这个模型我跑不了。这个直觉错在把模型文件体积和显存需求划了等号。先算一笔账。模型权重的体积取决于参数量和存储精度1B10亿参数用 FP324 字节存储约 4GB1B 参数用 BF16/FP162 字节存储约 2GB1B 参数用 INT81 字节存储约 1GB1B 参数用 INT40.5 字节存储约 0.5GB所以 56GB 的模型文件可能是大概 28B 参数的 FP16/BF16 原始权重也可能是一个 70B 甚至百亿级参数模型量化到 INT8 或 INT4 之后的产物。同样是 56GB背后的模型规模和算力要求完全不一样但它们在能不能用 32GB 显存跑这个问题上的答案逻辑是一致的文件体积大于显存不代表一定跑不了。还有个很多人忽略的点GGUF 格式的模型文件体积和加载进内存后的物理占用基本一致但和推理过程中显存的峰值占用是两码事。权重只是显存账单里的一项不是全部。1.2 显存里真正常驻的是哪三样东西大模型推理时显存里主要住着三类数据第一是模型权重。这是最大头56GB 的模型文件权重加载进显存后大概就是 56GB量化除外。但不是每一层权重在推理的每一刻都必须待在显存里。第二是 KV Cache。这是推理过程中不断增长的缓存存的是已经计算过的 Key 和 Value 向量用来避免每生成一个 token 就把前面所有历史重新算一遍。它的大小和上下文长度强相关后面专门说。第三是激活值activation和临时缓冲区。前向传播过程中每一层的中间输出还有 CUDA 内核的临时空间、CUDA Graph 的捕获空间都会占显存。这部分在小 batch 推理时通常几个 GB但你不能不给它留位置。这三样东西加起来才是真实的显存占用。很多人只盯着权重 56GB完全忘了 KV Cache 和激活值的存在结果设置上下文长度时贪大最后 OOM 了还在那骂我显存明明够。1.3 推理引擎的秘密权重可以用多少取多少关键点来了。transformer 模型的推理是逐层进行的输入先过第一层第一层的结果再进第二层一路串下去。也就是说第一层权重算完的时候理论上来讲它暂时没用了可以腾地方给后面的层。当然实际工程里没人蠢到每算一层就把权重挪一次那会慢到怀疑人生。但按需驻留的思路是成立的。现代推理引擎采用的是更聪明的做法把模型按层切成两份甚至多份一部分层放在显存里跑另一部分层放在系统内存里跑或者更激进一点直接放在 SSD 上按页调度。这就是后面要讲的 layer offload 和异构内存架构。一句话总结56GB 是仓库里囤的货32GB 是工作台。工作台放不下全部货不代表不能干活关键看你有没有一套好的取货-使用-清空的调度系统。2. Shared Memory 的三种身份很多人从第一步就搞混了标题里有Shared Memory这个词但我必须先把概念掰清楚因为业内至少有三个东西都叫 Shared Memory指向完全不同的机制。搞混了后面所有配置你都看不懂。2.1 GPU 片内 shared memory和本文没关系但常被搜到NVIDIA CUDA 里有个东西叫 shared memory它是 GPU 每个 SM流式多处理器内部的一小块高速缓存区通常几十 KB 到两百多 KB。它的用途是让一个线程块内的线程共享数据避免反复访问全局显存。这是纯 CUDA 编程层面的概念和用 32GB 显存跑 56GB 模型这件事没有任何直接关系。但因为名字一样搜索引擎经常把搜shared memory的人带偏。你要是去 NVIDIA 文档里查 shared memory查出来的是这块片内缓存那就完全走错方向了。本文讲的 Shared Memory是系统级的内存共享显存概念对应任务管理器里那块共享 GPU 内存以及芯片架构层面的 Unified Memory / 统一内存寻址。2.2 任务管理器里的共享 GPU 内存能吃但不好消化Windows 任务管理器里GPU 那一栏除了专用 GPU 内存还有个共享 GPU 内存。这个数字通常是你系统内存的一半左右比如 32GB 内存就显示 16GB 共享 GPU 内存。很多人以为这是额外的显存美滋滋地以为 8GB 显卡 16GB 共享内存 24GB 显存。这个理解大错特错。这个共享 GPU 内存其实是共享内存池本质上是借用系统内存给 GPU 用。数据要从系统内存传到 GPU必须走 PCIe 总线集成显卡除外。而 PCIe 4.0 x16 的带宽大概是 32GB/s和显存动辄 500GB/s 以上的带宽比差了一个数量级。程序确实可以吃这部分内存比如把纹理、缓冲区放进去但性能会非常难看。对大模型推理来说Windows 的共享 GPU 内存不能直接当成显存来规划。真正能利用这部分资源的是那些主动实现了 CPU offload 的推理引擎比如 llama.cpp 系列。它们不是靠 Windows 帮你共享内存而是自己有能力把一部分模型层放在系统内存里计算计算完了再把结果传回显存。这是主动 offload不是操作系统自动共享。2.3 UMA 与 CUDA Unified Memory真正让 56GB 能跑起来的弹药真正让小显存跑大模型这件事从不可能变成可能的是统一内存寻址Unified Memory。先看消费级/工作站级的两条路线第一条是 Apple Silicon 的 UMAUnified Memory Architecture。M 系列芯片把 CPU 和 GPU 放在同一块物理内存上没有独立的显存颗粒CPU 和 GPU 通过统一地址空间访问同一块内存。所以一台 64GB 内存的 MacBookGPU 理论上能用的内存就是接近 64GB大模型可以直接把权重都放在统一内存里省去了 PCIe 搬运。这也是为什么很多人在 Apple Silicon 上跑大模型的体验比同价位 Windows 笔记本还流畅。第二条是 NVIDIA 的 CUDA Unified Memorymanaged memory。它让 CPU 和 GPU 共享一个虚拟地址空间程序员可以分配一块内存再让 GPU kernel 访问它。背后的机制是内存页的按需迁移GPU 访问哪个页驱动就把那个页搬到显存GPU 不需要的部分可以被换出。这和操作系统的虚拟内存换页逻辑异曲同工。但在当前主流消费级 GPU 上CUDA Unified Memory 的自动按页迁移性能并不理想频繁跨 PCIe 搬页会让推理慢到没法用。所以实际落地方案里大家更多是绕过自动迁移直接手动控制哪些层放显存、哪些层放内存。这就是 llama.cpp 的-ngl参数在做的事。所以标题里从 Shared Memory 到 AI 异构内存架构这个演进本质上是说从过去数据必须常驻显存的朴素模型到现代显存-内存-存储分层调度、按需迁移的异构内存架构。3. AI 异构内存架构的完整调度显存-内存-硬盘三级联动3.1 layer offloadllama.cpp 的 ngl 到底在调什么llama.cpp 系列工具llama-cli、llama-server以及基于它的 Ollama是目前 CPU/GPU 混合推理的事实标准。它把 transformer 模型按层切分前 N 层放在 GPU 上计算剩余的层交给 CPU 用系统内存计算。这个 N 就是-ngln_gpu_layers多少层放到 GPU。比如一个 80 层的模型-ngl 40意味着前 40 层在显存里跑后 40 层在内存里跑。Ollama 里对应的环境变量历史上是OLLAMA_GPU_LAYERS新版也支持更细的OLLAMA_OFFLOAD系列配置。这里有一个非常重要的性能认知速度瓶颈不在显存和内存之间的拷贝而在 CPU 计算那部分层有多慢。模型推理是逐层串行的GPU 算完前 40 层得把中间结果传给 CPUCPU 用几十个核算后 40 层再传回 GPU 产出 token。CPU 处理大矩阵乘法的速度比 GPU 慢一到两个数量级所以哪怕你只留 10% 的层在 CPU 上生成速度也可能直接腰斩。这意味着-ngl不是一个随便调调的参数。它决定了你的 token/s 到底由 GPU 决定还是 CPU 拖后腿。我的经验是如果你的显存不够装全量权重优先保证 Embedding 层和输出层通常也在-ngl计算范围内在 GPU剩下的 transformer 层能塞多少塞多少但心里要有数——CPU 上的层数超过总层数 20% 之后速度会很难看。3.2 显存不够硬盘来凑的本质是 mmap 按需分页网络热词里那句显存不够硬盘来凑听起来像是搞笑段子但底层真的是靠硬盘把容量顶上去的。GGUF 格式的模型文件天然支持 mmap内存映射文件。加载模型时引擎不是把 56GB 一次性读进内存而是直接把文件映射到进程的虚拟地址空间。访问哪个页操作系统才从磁盘把那个页读进物理内存。配合前面说的 layer offload整套流程是这样的权重文件躺在 SSD 上这是第三级存储需要某一层的权重时操作系统把对应页从 SSD 读进系统内存这是第二级如果这一层被分配到了 GPU再从系统内存拷进显存这是第一级显存里的层算完后如果内存压力大后续页可能被直接换出这个链路看着很美好但有个吸收教训的点它是靠随机访问模型文件的。你每生成一个 token都要从磁盘/内存取权重。如果模型文件放在机械硬盘上随机读取速度只有几十 MB/s加载 56GB 文件可能要等十几分钟生成时也可能每个 token 都在等磁盘 I/O。所以硬盘来凑的前提是NVMe SSD最好顺序读取和随机读取都很强。顺带一提如果物理内存也不够大比如你只有 32GB 内存还想跑 56GB 文件mmap 会让操作系统疯狂换页到页面文件pagefile这时候 Windows 的虚拟内存设置就很重要了第 5 节再讲。3.3 量化是这套架构的杠杆精度、体积、速度的三角博弈异构内存架构解决的是装不装得下的问题但跑得快不快很大程度上取决于你选的量化等级。量化本质上是用更少的 bit 表示权重直接缩小文件体积让更多层能塞进显存。同一份模型常见的 GGUF 量化格式体积大约是这样的以 70B 模型为例原始 BF16 约 140GB量化格式体积约相对 BF16 的损失适用场景Q2_K约 30GB较大只求能跑不追求质量Q3_K_M约 36GB中等32GB 显存的极限边缘Q4_K_M约 41GB较小实用性/质量平衡点最推荐Q5_K_M约 48GB很小显存宽裕时的首选Q6_K约 55GB极小接近无损Q8_0约 70GB几乎无损显存大户专用回到标题的 56GB如果这个文件是个 70B 模型的 Q5/Q6 量化版那你用 32GB 显存跑它本质上是在量化省下来的空间 offload 策略双重作用下实现的。量化还有一个隐藏福利模型体积变小后加载时的内存带宽压力也变小。因为每一步推理要读取的权重字节数变少了。所以量化和异构内存架构是互相成就的——量化负责减肥异构调度负责安排床位。4. 拿 32GB 显存实战 56GB 模型配置模板与性能预期4.1 关键参数逐个拆解配置之前先把几个真正影响能不能跑、跑得快不快的参数说清楚。上下文长度ctx size上下文越长KV Cache 越大。KV Cache 的字节数大概可以这样估算KV Cache ≈ 2K 和 V 两份× 层数 × KV 头数 × 头维度 × 序列长度 × batch size × 每个元素字节数一个 32 层、8 个 KV 头的模型头维度 128跑 8192 上下文FP16 精度下大概要 1GB 左右上下文拉到 32768直接变 4GB。可能你觉得不多但别忘了这是在权重已经吃掉 30GB 的基础上再叠加上去的很容易变成压垮显存的最后一根稻草。batch sizebatch 越大吞吐越高但显存占用线性上涨。本地个人使用batch 1 就够了没必要贪。gpu_memory_utilization / kv cache 预留这是给服务端推理框架比如 vLLM、SGLang用的意思是你允许框架用到显存总量的大比例。默认 0.9在 offload 场景下要调低一些给 CPU 和 GPU 之间的交互留缓冲。并发数Ollama 的OLLAMA_NUM_PARALLEL默认值会随着版本变化可能在 1 到 4 之间。并发每加 1KV Cache 占用直接翻倍。个人使用保持 1 就好除非你有明确的多人同时访问需求。4.2 三套可以直接抄的部署模板场景假设你有一个 56GB 的 GGUF 模型文件一张 32GB 显存的显卡系统内存 64GBNVMe 硬盘。方案一Ollama最省事# 设置 offload 层数让尽量多的层进显存 # 如果你的 Ollama 版本支持 export OLLAMA_GPU_LAYERS99 # 或者更细的 offload 配置不同版本环境变量名不同以官方文档为准 export OLLAMA_OFFLOAD1 # KV Cache 量化能省不少显存 export OLLAMA_KV_CACHEq8_0 # 上下文长度别贪先跑 8192 export OLLAMA_CTX8192 # 禁止同时加载多个模型 export OLLAMA_MAX_LOADED_MODELS1 export OLLAMA_NUM_PARALLEL1 ollama run 你的模型名Ollama 的逻辑是自动探测显存决定 offload 多少层。但自动不等于最优很多时候你得手动试几组OLLAMA_GPU_LAYERS盯着显卡占用看找到显存刚好用完、但没爆的点。方案二llama.cpp 原版可控性最强llama-cli -m /path/to/model.gguf \ -ngl 60 \ # 前 60 层放 GPU其余放 CPU具体数字按模型总层数微调 --ctx-size 8192 \ # 上下文 --batch-size 512 \ # 批大小默认即可 -fa on \ # flash attention对长上下文友好 --no-mmap # 如果你内存足够关掉 mmap 可以避免磁盘 I/O 抖动这里有个反向直觉的配置如果系统内存足够比如 64GB我会建议关掉 mmap--no-mmap因为 mmap 虽然省内存但会导致推理过程中频繁触发磁盘读页最坏情况是生成一个 token 卡顿好几次。物理内存够的话一次性加载进内存更平滑。方案三Python HuggingFace Accelerate适合想二次开发的人from transformers import AutoModelForCausalLM, AutoTokenizer import torch model AutoModelForCausalLM.from_pretrained( your/model-name, device_mapauto, # 自动决定哪些层放 GPU、哪些层放 CPU max_memory{0: 30GiB, cpu: 60GiB}, # 0 是 GPU offload_folderoffload, # 内存还不够时往硬盘卸 torch_dtypetorch.float16, ) tokenizer AutoTokenizer.from_pretrained(your/model-name)device_mapauto会自动计算每一层该放哪。max_memory的cpu上限必须留出系统内存给操作系统本身别填满。这个方案的好处是可以和 transformers 生态无缝衔接坏处是 CPU 层和 GPU 层之间的数据传输受限于 PyTorch 的实现性能通常比 llama.cpp 原生慢一些。4.3 性能账本token/s 掉到多少才算正常聊配置不给性能预期等于耍流氓。直接说结论32GB 显存跑 56GB 模型必然要 offload 一部分层到 CPU所以别指望能跑出满血速度。我用自己的经验给个参考区间配置预期速度70B 级 Q4 模型全部层在 GPU需要 40GB 显存25~40 t/soffload 10%~20% 层到内存10~18 t/soffload 30%~40% 层到内存4~8 t/s全部层在 CPU纯内存跑1~3 t/s这只是个粗略区间实际还取决于 CPU 内存通道数、内核数、是否 AVX512、精度等因素。但可以得出一个判断标准如果 offload 后速度掉到 5 t/s 以下使用体验就很痛苦了这时候建议换个更小一点的量化版本或者直接选小一号的模型。另外首 token 延迟也要有心理准备。第一次加载/推理时操作系统要从 SSD 读大量页那个过程可能持续几十秒甚至几分钟这是正常的不代表卡死。5. 低显存跑大模型最容易翻车的五个坑5.1 虚拟内存没设够加载到一半直接崩我用 16GB 显存跑一个 40GB 模型的时候曾经连续崩溃了三次每次都是加载到一半进程直接消失。查了半天发现不是显存问题是系统内存 页面文件pagefile加一起都不够模型文件映射。mmap 机制下模型文件映射进虚拟地址空间物理内存不够时操作系统会把页换到 pagefile。如果 pagefile 上限设得太小比如很多人优化系统时直接关掉了虚拟内存映射 56GB 文件就一定会失败。Windows 上不要关页面文件最好让系统托管或者手动设为内存的 1.5~2 倍。Linux 下则要确保 swap 或物理内存足够否则 mmap 直接报Killed。这个坑极其隐蔽因为它报的错是进程被杀而不是显存不足。5.2 SSD 慢不是加载慢是每生成一个 token 都在等前面说了mmap 是按需读页的。如果物理内存不够撑起整个工作集那么生成过程中会反复从 SSD 读权重页。这时候模型就不是加载慢的问题了而是每个 token 都卡甚至卡到像死机。实测下来同一个 40GB 模型在 NVMe 和 SATA SSD 上的 offload体验差距非常明显。NVMe 随机读取延迟在几十微秒级SATA SSD 已经到百微秒甚至毫秒级机械硬盘更是灾难。所以如果你要走显存不够硬盘来凑路线首先确认硬盘是 NVMe其次给系统留足内存尽量避免让工作集落到磁盘。5.3 PCIe 带宽和显存位宽硬件账要这样算很多人以为显卡显存越大跑模型越快但实际推理速度的另一个天花板是显存带宽。RTX 4090 的显存带宽约 1008GB/s而一张 32GB 的 A100 是 HBM2e带宽超过 1.5TB/s。同样是 32GB 显存跑同一个模型4090 和 A100 的速度可能差 30% 以上这就是带宽的差距。如果你用两张显卡跑一个模型比如双卡各 16GB拼 32GB还要考虑卡间通信走 PCIe 还是 NVLink。RTX 40 系消费卡基本没有 NVLink两张卡之间通过 PCIe 传激活值带宽只有 32GB/s 左右多卡并行推理的效率通常不会好看。还有个细节很多人不知道显存颗粒的通道数或者说位宽决定了带宽上限。显卡维修圈说的显存颗粒通道排序就是指这个。GPU 和显存颗粒之间的通道是固定的如果某些通道对应的颗粒损坏或未正确识别显存位宽会掉带宽跟着掉推理速度直接受牵连。买二手卡或者矿卡回来跑模型烤机之前最好用显存测试工具确认所有通道都正常。5.4 KV Cache 偷显存32GB 显示满了模型还没放完这类场景我见过太多次-ngl调到很大显存占用看着已经满了但模型加载到中间就 OOM。原因就是前面说的——显存里不止有权重还有 KV Cache 和激活值。你设了个 32768 的长上下文KV Cache 可能直接吃掉 8GB留给权重的空间就不够了。解决办法有两条路一是调低上下文长度二是用 KV Cache 量化。Ollama 的OLLAMA_KV_CACHEq8_0可以把 KV Cache 压缩一半llama.cpp 的-ctk和-ctv参数同理。实测下来KV Cache 量化对质量的影响远小于权重量化对于 offload 场景非常值得开。还有一个思路先不开长上下文把模型完整加载进去确认能跑了再逐步增加--ctx-size找一个显存刚好用满的临界点。这比一次性设个很大的值然后反复 OOM 要高效得多。5.5 我的最终建议什么场景值得这样折腾写到最后说点实在话。32GB 显存跑 56GB 模型技术上可行但体验上要有预期管理。如果你是以下三种人这套方案非常值得想做技术验证看看某个大模型在自己硬件上到底能不能跑、效果怎么样数据敏感模型必须本地跑但对速度不敏感可以接受慢工出细活想折腾异构内存架构把硬件资源压榨到极致这本身就是在涨经验反过来说如果你要的是流畅的交互体验比如写代码、做 Agent、跑 RAG那我劝你优先选择显存能完整装下的模型。一个流畅的 14B Q4 模型约 9GB体验上远比一个卡成 PPT 的 70B 模型舒服。模型不是越大越好能在你的硬件上流畅跑起来的模型才是好模型。我在实际配置中最后留下的小技巧是固定一个排查顺序。先把-ngl拉满试跑OOM 就降 10 层再把上下文从 8192 开始往上加最后才考虑 KV Cache 量化和关闭 mmap。按这个顺序调参十分钟之内就能找到自己机器的甜点位比到处抄别人的配置靠谱得多。