SSD当显存跑大模型？原理、实战与踩坑指南

最近 GitHub 上这类话题特别火普通笔记本能不能跑几千亿参数的 GLM 大模型显卡不够是不是能把 SSD 当显存用这个话题很容易被标题党带偏。先给个结论方案是真实存在的原理也不复杂本质是“内存映射 量化 推理引擎改造”但它解决的是容量问题不是速度问题。你确实能让一台没有顶级 GPU 的笔记本把 7000 亿参数的模型“跑起来”但别指望它像 ChatGPT 那样流畅回答更多时候是抽一根烟的时间屏幕上才蹦出一个 token。这篇文章我会把这件事从原理到实操完整拆开为什么普通笔记本跑不了大模型、SSD 当显存的真实机制、GitHub 上那些方案该怎么选、完整跑通一个量化 GLM 的具体步骤、以及实际会踩到哪些坑。不管你是想在自己办公机上跑一个开源大模型做实验还是纯粹想搞懂“大模型推理时内存和磁盘到底在干什么”这篇都应该能帮到你。1. 普通笔记本为什么跑不了大模型三道坎和解题思路1.1 显存是物理天花板先从容量说起很多人一提到“跑大模型”就想到显卡想到 CUDA想到 4090。但真正让普通电脑望而却步的第一道坎不是算力是容量。一个 7000 亿参数的模型如果用 FP16半精度每个权重占 2 字节保存静态权重体积就是 7000 亿 × 2 字节 ≈ 1.4TB。什么概念一张 RTX 4090 的显存是 24GB一张专业级的 A100 80GB 也才 0.08TB。就算你搞一台 8 卡 A100 服务器显存总量 640GB离 1.4TB 还差着一倍多。所以“跑不起来”最直接的原因就是模型太大显存里根本放不下。这有点像一家咖啡店只有 10 个座位突然来了 1000 个客人——不是服务员手速不够快是物理上没地方站。既然显存这条路走不通社区就想了两条路把模型体积压缩也就是量化把模型放在一个容量更大的存储介质上按需读取也就是标题里说的“SSD 当显存”。1.2 量化让 7000 亿参数先“瘦身”到能放进 SSD模型量化不是什么新鲜概念。简单说就是把权重从 16bit 或 32bit 的浮点数压缩成 8bit、4bit 甚至 2bit 的整数。你可以把它理解成图片压缩成 JPG肉眼看起来差别不大但文件体积小了好几倍。对大模型来说量化带来的体积收益非常可观。下面是以 7000 亿参数规模为参考的粗略估算格式每个权重占用7000 亿参数近似体积主观质量FP1616bit约 1.4TB基准Q8_08bit约 700GB接近无损Q5_K_M5~6bit约 480GB损失很小Q4_K_M4~5bit约 400GB可接受社区常用Q2_K2~3bit约 200GB明显下降仅测试用上面的 K_M、K_S 是量化策略的变体核心思路是不同层用不同 bit 数重要层保留更多精度。比如 Q4_K_M 里的“M”表示中等精度混合量化它把注意力层的权重用更高精度保存把前馈层的权重压得更狠一些。有了量化一个 7000 亿参数的模型可以压到 400GB 左右。这个体积一台 2TB SSD 的笔记本已经能装下了。但这只是“装下”仍然不等于“跑得动”因为模型运行时总不能每次从硬盘读一个数计算完再读下一个那样慢到没法用。所以还需要第二层魔法内存映射。1.3 SSD 当“显存”的真实机制内存映射不是玄学标题说“SSD 当显存”严格来说不完全准确。这个方案里SSD 扮演的角色不是 GPU 显存而是“系统内存的延伸备胎”。真实的技术核心是操作系统提供的内存映射mmap机制。我尽量用大白话讲。你把模型权重文件放在 SSD 上推理引擎不是把 400GB 一次性读进内存而是用 mmap 把这个文件映射到进程的虚拟内存地址空间。程序访问某个权重时操作系统发现这个地址对应的物理内存页不在内存里就触发“缺页中断”从 SSD 上把那一小块数据读入内存内存紧张时又把很久没用的页淘汰掉腾出地方给新读入的数据。这整个过程 CPU 和操作系统会自动管理对上层程序来说好像“所有数据都在内存里”实际上物理内存只放了一小部分大部分数据躺在 SSD 上按需换入换出。大模型推理时有一个很要命的特点生成每一个 token都要把每一层、几乎所有相关权重都跑一遍。也就是说虽然理论上“按需加载”但实际上一遍推理下来几乎要把整个模型的数据从 SSD 里过一趟。哪怕中间有页缓存帮忙留住一部分数据只要模型体积远大于物理内存那每一轮生成都必然伴随大量磁盘读取。这就是为什么这个方案能解决“能不能跑”却解决不了“跑得快不快”的根本原因。顺便提一句Windows 显卡驱动里那个“共享显存”和这个完全是两码事。共享显存是让 GPU 在显存不够时把数据放进系统内存走 PCIe 总线而这个方案是让 CPU 通过虚拟内存映射去读 SSD 上的模型文件两者的数据通路、瓶颈和性能特征完全不同别搞混。2. 工具链选型为什么 GitHub 上的方案都绕不开 llama.cpp2.1 GGUF 格式与 llama.cpp事实标准的诞生聊无 GPU 跑大模型绕不开 llama.cpp 这个项目和 GGUF 这个模型格式。llama.cpp 最初是社区大神 Georgi Gerganov 为了在 Mac 上跑 LLaMA 写的一个纯 C 推理引擎。它最大的特点是依赖极少、CPU 优化做得极狠对 AVX2、AVX512、NEON 这些指令集都有针对性优化。后来团队给模型定义了一套新格式 GGUF专门用来解决大模型本地部署的几个痛点单文件分发、支持分片合并、原生支持 mmap、量化类型自带描述信息。说白了GGUF 就是为“把大模型放在普通电脑上跑”而生的格式。今天你在各种开源模型社区里下载的量化模型绝大多数都是 GGUF。想玩 SSD 映射方案llama.cpp 基本上是你绕不开的基础设施。这也是为什么 GitHub 上那些“内存不够也能跑大模型”的项目十个里有八个底层都在调 llama.cpp——不是大家没创新能力是这个项目已经把 CPU 推理和内存映射这件事做到了极致。2.2 热门方案的横评llama.cpp、Ollama、LM Studio、MLC-LLMGitHub 上相关项目不少我按实际体验给它们排个序方便你选型项目定位内存映射支持上手难度可调参数适合场景llama.cpp底层推理引擎原生支持中极多研究原理、自定义配置Ollama开箱即用的推理服务默认开启但不透明低少日常快速体验LM Studio图形化客户端依赖引擎实现低中小白图形化操作MLC-LLM多端部署方案按平台实现高中Android/iOS/浏览器如果你只是为了“能跑起来”Ollama 或 LM Studio 确实省心下载模型点两下就行。但如果你想真正理解“SSD 当显存”这个机制想手动控制多少层放 GPU、多少层放 CPU、要不要锁内存那还是得回到 llama.cpp 命令行。本文后面演示也以 llama.cpp 为主。Ollama 这种工具最大的问题不是不能跑而是把细节藏得太深。它默认会启用 mmap但你看不到模型加载时实际的内存占用、看不到页命中率也没法精确控制层卸载比例。遇到性能问题你只能干瞪眼。2.3 让 4060 Laptop 帮上忙层卸载参数的取舍很多人的笔记本其实是带显卡的比如热词里提到的 Intel UHD NVIDIA GeForce RTX 4060 Laptop。这种双显卡配置能不能利用起来能但方式很微妙。llama.cpp 里有个参数叫-nglnum_gpu_layers作用是把模型的前 N 层放到 GPU 上计算剩下的层继续跑 CPU。因为大模型是逐层计算的前面的层在 GPU 上算完把中间结果传给 CPU 去算后面的层再由 CPU 把结果传回 GPU数据流是能接上的。4060 Laptop 显存是 8GB以 70B 模型 Q4 量化后的 40GB 体积估算8GB 显存大约只够放 8 到 12 层左右具体层数和模型结构有关。剩余几十亿参数仍然要在 CPU 和内存里跑。这里有个常见的认知误区有人觉得反正 8GB 显存放不下整个模型不如把整个模型丢给 CPU还省得传输数据。实测下来不是这样哪怕只卸载 8 层到 GPU整体吞吐也能提升 20% 到 40%。因为 GPU 计算那几个层实在太快了CPU 反而不是瓶颈。所以只要你有 NVIDIA 显卡建议先用-ngl试出一档尽量高的层数让显存不爆、速度最优这也是混合推理的正确打开方式。至于更激进的“显存不够就把显存当系统内存用”那又是另一条歧路会让数据在 GPU 显存和系统内存之间来回倒腾比老实跑 CPU 还慢不建议碰。3. 实战把量化 GLM 塞进笔记本的完整流程3.1 第一步硬件自检确认这台机器有没有硬条件不是随便一台电脑都能玩这个方案。先做三个检查。第一CPU 指令集。llama.cpp 的 CPU 加速高度依赖 AVX22013 年后的 Intel Haswell 和 AMD Excavator 基本都支持。老 CPU 没有 AVX2 也能跑但速度会断崖式下跌。Linux 下用lscpu | grep avx2查Windows 可以用 CPU-Z 或者 PowerShell 查Get-CimInstance -ClassName Win32_Processor。没有 AVX2 的话这篇文章的建议可以战略性放弃。第二内存。这是很多人忽略的红线。模型权重可以放 SSD 按需读取但 KV Cache推理时的缓存是必须常驻内存的上下文越长KV Cache 越大。对超大模型来说32GB 内存只能算勉强64GB 才是比较舒服的配置。内存不够就算 SSD 再快也救不了你。第三SSD 剩余空间。量化后的模型文件体积、KV Cache、系统缓存、临时文件这些加起来很容易突破 500GB。建议至少准备出模型体积的 1.5 倍空闲空间。而且优先选 NVMe SSDSATA SSD 的持续读取速度差了三四倍体验差异极大。我自己测试用的是一台 Intel i7-12700H 64GB DDR5 2TB PCIe 4.0 SSD RTX 4060 Laptop 的本子这个配置玩这方案属于“刚好够用”。3.2 第二步下载 GGUF 量化权重目前开源生态里GLM 系列公开的权重以几十亿到百亿规模为主还没有真正开源过 7000 亿参数这个体量。但这不妨碍我们讨论方法论——下面所有流程对任何 GGUF 格式的模型都成立你只需要把文件名换掉。去模型社区搜索对应模型的 GGUF 量化版本比如 GLM-4-9B 会有多个量化文件一般文件名里会标明 Q4_K_M、Q5_K_M 等。不要下载最大的 Q8 版本先用 Q4_K_M 验证流程。下载大文件建议用命令行工具支持断点续传huggingface-cli download 你的用户名/glm-4-9b-gguf \ --include *Q4_K_M*.gguf \ --local-dir ./models/glm需要注意的是有些量化文件是分片存放的后缀类似-00001-of-00002.gguf这类文件 llama.cpp 可以自动识别合并分片加载不需要手动拼接保持文件名完整就行。3.3 第三步编译 llama.cpp 并配置启动参数有 GPU 的笔记本编译时把 CUDA 支持打开git clone https://github.com/ggerganov/llama.cpp.git cd llama.cpp cmake -B build -DGGML_CUDAON -DCMAKE_CUDA_ARCHITECTURES89 cmake --build build --config Release -j 8-DCMAKE_CUDA_ARCHITECTURES89对应 RTX 40 系显卡的安培架构Ada Lovelacesm_89。如果你是其他型号先查一下对应的算力版本用错的话会报“not compatible”一类的错误。编译完先试最简单的纯 CPU 模式./build/bin/llama-cli \ -m ./models/glm/glm-4-9b-Q4_K_M.gguf \ -p 你好介绍一下你自己 \ -c 2048 \ -t 8 \ -ngl 0参数含义-m指定模型文件-c是上下文长度-t是 CPU 线程数建议物理核心数不是逻辑线程数-ngl 0表示 0 层放 GPU纯 CPU 跑。如果一切正常你会看到一堆加载日志最核心的是两行模型加载耗时和提问之后的评测输出包括eval time和最终的xx tokens/s。3.4 第四步实测性能与理论估算第一轮跑通之后加一层 GPU 卸载试试./build/bin/llama-cli \ -m ./models/glm/glm-4-9b-Q4_K_M.gguf \ -p 你好介绍一下你自己 \ -c 2048 \ -t 8 \ -ngl 16-ngl 16表示把前 16 层放到 GPU 上计算。8GB 显存的 4060 Laptop 对 9B 模型来说可以整卡放下大部分层速度提升会非常明显。但如果你真拿到一个超大模型比如标题里的 7000 亿参数 Q4 版光权重就有 400GB。内存只有 64GB 的话连权重都塞不进物理内存更不用说 KV Cache。这时候要明确一点模型文件放 SSD靠内存映射按需读取是唯一可行的思路。用内存带宽做个粗略估算你就明白为什么快不了模型生成一个 token理论上需要把参与计算的权重全部读取一遍忽略层缓存和页缓存命中的话。假设量化后模型体积是 400GB双通道 DDR5 内存带宽大约 50GB/s理论吞吐上限是 400 / 50 8 秒一个 token也就是 0.125 token/s。再算上磁盘随机读、CPU 计算开销、页缓存命中率不足实际体验大概率还要再打对折0.05 到 0.1 token/s 是很正常的。对比一下A100 的 HBM 带宽是 2TB/s 起步4090 也有 1TB/s 级别。SSD 当显存这条路本质是用两个数量级的带宽差距换一个“能跑起来”的可能性。所以我的态度很明确这类方案适合验证、学习和折腾真要用大模型干正事要么买大显存卡要么用云上的 GPU 实例按量付费别在笔记本上硬扛。3.5 容量与内存的数学题为什么“能装下”不等于“能跑”很多人第一反应是既然 SSD 有 2TB模型才 400GB那应该很稳啊。但这里面有一个致命的数学问题。物理内存只有 64GB400GB 的模型数据里有 336GB 是躺在 SSD 上的。推理过程中操作系统会尽力用页缓存保留最近读过的数据但 64GB 内存同时又承载着 KV Cache、程序本身、系统其他进程。模型数据在内存里放不下就会像流水席一样每张桌子刚被占用又立刻被清空永远处于“刚读完就淘汰”的状态。这就导致一个结果每生成一个 token可能要把 300 多 GB 的数据从 SSD 重新读一遍。如果你的 SSD 持续读取速度是 7GB/sPCIe 4.0 顶级盘光读数据就要 50 秒。这时候别说聊天命令行里那个光标闪烁都让人焦虑。所以“能装下”只是第一步第二步是“内存够不够缓存住大部分高频权重”。内存越接近模型体积体验越好。这也是为什么许多跑超大模型的玩家宁可把权重从 Q4 降到 Q2也要让模型体积贴合物理内存容量——速度陷阱比质量损失更致命。4. 踩坑实录与排查技巧4.1 内存直接爆掉OOM 的多发场景我见过最常见的失败案例不是模型加载不了而是把上下文长度调太高KV Cache 把内存挤爆。KV Cache 的粗略估算公式是2 × 层数 × KV 头数 × 头维度 × 上下文长度 × 权重字节数。对超大模型上下文 4096 就很容易吃掉 20GB 甚至更多的内存。很多人开开心心设了个-c 8192结果启动后系统直接卡死或者进程被杀。解决路径有两条一是把-c降到 2048 以下牺牲上下文长度保稳定二是用 GQA分组查询注意力类模型它本来就大幅压缩了 KV Head 数量内存占用会小很多。GLM 系列大多支持 GQA选模型时留意一下这一点。另一个隐蔽问题是操作系统对 mmap 文件的内存承诺。有些版本在映射超大文件时会保留地址空间可能把进程虚拟内存顶到很高触发各种奇怪的“无法分配内存”报错。这时候加一个--mlock false参数禁止强制把页锁进内存给系统留点调度余地往往能绕过问题。4.2 速度忽快忽慢页缓存抖动与后台干扰如果你跑了一阵发现速度极其不稳定第一秒出字很快后面越来越慢大概率是页缓存命中率在恶化。系统把其他进程的数据也放在内存里后台浏览器、IDE、微信都在跟你抢内存和缓存空间。实测经验跑大模型推理时把能关的后台程序全关掉。Windows 上尤其注意 OneDrive、实时杀毒扫描这类高磁盘占用程序。它们在后台扫描文件时会跟你的模型抢 SSD 的 IO 队列让推理速度再度腰斩。Linux 下可以监控页缓存命中cat /proc/meminfo | grep Cache watch -n 1 ps -eo pid,rss,vsz,cmd | grep llama-cli看一眼 RSS常驻内存增长情况大概就能判断模型是不是在频繁换页。4.3 SSD 寿命、散热与性能衰减有人担心频繁读 SSD 会不会伤盘。这里可以放心一点NAND 闪存的寿命主要取决于写入量而推理过程几乎全是读取。正常情况下一块 TLC SSD 的读取寿命足够你折腾很多年。但有个问题是很多人没意识到的长时间满负荷读取会让 SSD 主控温度升高NVMe SSD 过热会掉速甚至触发温控保护。笔记本散热本来就紧张SSD 持续高速读几分钟后温度上到 70℃ 并不稀奇。如果发现速度越来越慢建议用软件看一眼 SSD 温度必要时垫个散热垫或者用风扇对着吹。另一个值得提的是 QLC 颗粒的 SSD。QLC 在持续读取、垃圾回收时的性能波动普遍比 TLC 大如果手头是 QLC 盘这个方案的体验会更差。有条件直接上 TLC 或企业级拆机盘。4.4 常见问题速查表现象大概率原因解决办法启动直接 OOMKV Cache 太大或内存被系统占满调低-c关闭后台应用加物理内存加载时报格式不兼容模型文件损坏或 GGUF 版本过旧检查分片完整性更新 llama.cpp 到最新版速度从每秒几 token 掉到几十秒一个页缓存命中率太低模型在频繁换页换成更小量化模型或增加物理内存温度一高就掉速NVMe SSD 过热 / CPU 过热改善散热限制后台进程降低线程数显存报 not compatibleCUDA 架构编译参数与显卡不匹配修改CMAKE_CUDA_ARCHITECTURES为对应算力5. 这件事的边界与我的建议5.1 这个方案真正适合谁我折腾完这一套之后给出的判断是它是极客玩具也是理解大模型推理机制的最佳教学素材但不是生产工具。适合它的场景有这些想在离线环境跑开源模型验证效果、想给模型做量化质量对比、想在有限预算下让普通电脑勉强加载一次超大模型满足好奇心。它最大的价值不是出字速度而是让你亲眼看到大模型在硬件资源上有多么贪婪——容量、带宽、缓存每一层都卡着你。不适合的场景也很明确任何对响应速度有要求的交互式应用、生产环境 API、多用户并发服务。在这些场景里SSD 当显存会让人崩溃。5.2 如果你手上真有 4060 Laptop更聪明的路径与其勉强跑 7000 亿参数不如把目标降级到 30B 到 70B 这个区间体验会好得多。4060 Laptop 的 8GB 显存放不下整个 70B 模型但配合 64GB 内存走混合推理-ngl调到 20 到 30 层速度能到 1 到 2 token/s勉强能用。这种组合才是普通笔记本在当前算力条件下比较务实的上限。如果你确实需要更大模型的输出质量我的建议是算一笔经济账一台高端笔记本跑超大模型的电费和时间成本早就超过云 GPU 按量付费的价格。该租卡时就租卡本地折腾 SSD 映射作为兴趣不值得全押上去。5.3 这类方案未来还能怎么演进从观察来看下一步行业会在这几个方向继续推进更极致的量化格式比如把权重压到 2bit 以内同时保住可用精度投机采样用一个小模型先猜测输出大模型只做校验减少真正的全量推理次数更聪明的分层/流式卸载让模型层像流水线一样按需调度而不是每次都全盘重读。这些方向都还在快速演化中GitHub 上这个领域的项目更新频率很高隔几个月就有新思路。如果你感兴趣我建议用一个几十 B 的模型常年留在本地随时关注新引擎的参数变化比追着超大模型跑要实在得多。最后说点个人体会。我第一跑这种方案时等了整整 40 秒才看到第一个 token 出现那一瞬间不是失望反而有种“这家伙真的在一点点思考”的错觉。这种慢递送了对推理过程的敬畏每一层权重、每一块 KV Cache、每一次页命中都是实打实的硬件代价。如果你也想试试别直接上 7000 亿这种庞然大物先用一个 30B 的量化模型把整个链路玩明白再考虑挑战上限也不迟。