说个很多人不信的事实一台没有独立显卡、只有一块普通NVMe硬盘的笔记本在理论上是能把7000亿参数级别的大模型跑起来的。注意我说的是“能跑”不是“跑得飞起”。这个思路最近在GitHub上被讨论得很热核心就一句话显存不够内存凑内存不够SSD凑。GLM系列模型的GGUF量化版、llama.cpp这类推理框架、再加上MoE架构的稀疏激活让“笔记本无GPU跑大模型”从一个标题党的噱头变成了一次值得认真聊的技术尝试。这篇文章我会从底层原理讲到具体操作包括为什么SSD能插手显存的活、哪些模型适合这种玩法、需要改哪些系统参数、实测中会遇到什么问题。适合两类人看一是想在自己的老笔记本上把大模型跑起来做实验的同学二是想理解大模型推理存储瓶颈的开发者。无论你是哪一类建议从头看因为很多坑是连着的。1. 先算一笔账7000亿参数到底要吃多少空间1.1 一个参数在三种精度档位下的体积深度学习中模型参数的存储精度直接决定体积。FP16混合精度是训练和推理最常见的选择每个参数占2字节INT8量化后每个参数占1字节INT4量化后每个参数占0.5字节。把7000亿参数套进去结果如下FP16精度700B × 2B 1400GB也就是1.4TBINT8精度700B × 1B 700GBINT4精度700B × 0.5B 350GB很多人对“7000亿参数”没概念我用最直观的方式说一下一张24GB显存的RTX 4090如果直接加载FP16版本连零头都装不下大概只能装1.7%的权重。一台64GB内存的电脑装FP16版本依然差得远但装INT4量化后的350GB就有意思了——内存装不下SSD装得下。这就是整个“SSD当显存”玩法的底层动力量化把模型压到SSD能承载的体积推理框架再想办法让CPU和SSD把这个体量慢慢算完。1.2 笔记本的真实硬件条件拿一台典型的游戏本举例RTX 4060 Laptop GPU显存8GB系统内存32GBSSD是1TB的NVMe顺序读取速度大概5GB/s到7GB/s。这三层存储摆在那里情况一目了然。显存8GB连一个7B小模型的FP16版本都放不全内存32GB能放一些量化后的小模型但面对350GB的GLM 700B完全无能为力SSD 1TB装下350GB量化权重毫无压力所以问题的核心不是“装不装得下”而是“算的时候怎么把权重喂给计算单元”。GPU方案是一次性把权重放进显存靠HBM的超高带宽反复读取而SSD方案只能在每次计算前把当前需要的部分从硬盘读进内存用完就丢。这个差别听起来不大实际对速度的影响是数量级的。1.3 “能跑”和“跑得爽”的差距在哪如果说GPU推理是五星级后厨食材全部提前备好放在手边出餐速度以秒计那SSD当显存的方案就是“后厨现去仓库取食材”每做一道菜都要派人跑一趟仓库菜能上桌但出餐慢到你想摔菜单。具体来说现代LLM的推理分两个阶段预填充阶段prefill和解码阶段decode。prefill阶段要并行计算所有输入token对算力要求极高纯CPU加SSD在这个阶段会非常吃力。decode阶段每次只生成一个token算力要求相对低但每个token都要把参与计算的权重从存储搬运到计算单元对权重带宽的要求极高。SSD方案真正能碰的主要就是decode阶段——而且前提是模型已经量化、架构允许稀疏计算。我一直强调“能跑”和“跑得爽”是两回事。用SSD当显存速度基准不是token/s而是token/min。如果有人说“无GPU跑700B很流畅”那基本在吹牛。但如果你把预期放低把它当成一个能出结果的离线推理方案那它是成立的。2. SSD为什么能插足显存底层原理拆解2.1 显存、内存、硬盘的带宽金字塔要理解SSD为什么能当显存先看一组真实数据。GPU的HBM显存带宽在3TB/s到8TB/s之间CPU的DDR5双通道内存带宽在50GB/s到100GB/s之间而消费级NVMe SSD的顺序读取带宽只有5GB/s到8GB/s。三个数量级的差距这不是靠优化能跨过去的。但LLM推理有一个特性很重要解码阶段每生成一个token必须把模型权重完整过一遍除非是MoE稀疏激活这个过程本质上是“搬运权重”而不是“大量计算”。搬运权重的速度直接受限于存储介质的读带宽。如果我们把350GB的权重全放显存按5TB/s算过一遍需要0.07秒生成一个token就是70毫秒级别全放内存按60GB/s算需要5.8秒全放SSD按5GB/s算需要70秒。所以结论很残酷对于稠密架构的700B模型哪怕全放内存都算不上流畅更别说放SSD了。SSD方案能成立必须配合两个条件量化让体积变小、MoE让单次激活的权重远小于总参数量。2.2 操作系统自带的“磁盘当内存”机制很多人以为“SSD当显存”是什么黑科技其实操作系统几十年前就在做类似的事。虚拟内存、内存映射、页面缓存这些机制本质上就是把磁盘当作内存的溢出区。LLM推理框架最常用的是mmap机制。所谓mmap就是把一个文件映射到进程的地址空间当你访问文件中的某段数据时操作系统会先把这一段从磁盘读入page cache页面缓存。如果RAM空间不足OS就丢弃一些暂时不用的缓存页等下次需要时再从磁盘读回来。这个过程对应用层完全透明。用大白话讲模型文件350GB躺在SSD上内存只有32GB但你不需要一次性把350GB全部读进内存。推理的时候框架按层按块地访问文件OS只缓存当前正在用的几十GB其余部分留在SSD待命。Windows的虚拟内存、Linux的swap也是同样的思路——把SSD当作RAM的廉价延伸。llama.cpp加载GGUF格式模型时默认就走mmap这条路某种意义上你什么都不用配SSD已经在当显存用了。只不过默认机制和专门调优过的方案之间性能差距非常大。2.3 为什么过去不行现在又行了这个思路其实不新鲜十年前就有搞过“GPU显存不够内存来凑”的做法但当时基本不可用。原因有几个一是模型是稠密的不存在稀疏激活的说法权重必须全量过一遍二是量化技术不成熟INT8都费劲更别说INT4组量化三是消费级NVMe SSD的带宽还没有达到5GB/s以上四是开源推理框架没有把底层封装好让普通用户自己写调度代码门槛高到没朋友。现在情况变了。GGUF格式把INT4组量化变成了标准操作700B模型从1.4TB压到350GBllama.cpp、KTransformers、SGLang这些框架把mmap、预取、算子调度都封装好了一块中端NVMe SSD的顺序读取速度就能跑到5GB/s以上再加上MoE架构的流行让“单次只加载部分权重”从理想变成现实。四个条件凑齐SSD当显存的玩法才真正落地。2.4 MoE稀疏激活给SSD方案开了绿灯MoE混合专家是让SSD当显存真正具备实用价值的关键。稠密模型每个token都要激活全部700B参数这意味着SSD方案下每生成一个token就得把350GB全读一遍按5GB/s算就是70秒一个token直接劝退。MoE模型不一样。它内部有多个专家网络门控机制每个token只激活其中一小部分专家。假设总参数700B但单次激活的参数只有50B量化后对应25GB权重从SSD读取一次只需要5秒左右。这个速度虽然慢但已经处在“挂机跑任务能接受”的范围了。GLM、DeepSeek这些新一代大模型不少都采用了MoE架构绕了一圈“无GPU也能跑大模型”这个说法的隐含前提就是得是MoE架构、得是量化过的模型、还得接受慢速输出。三者缺一个整个方案就崩了。3. 实操在普通笔记本上把GLM模型跑起来3.1 动手前的硬件与系统检查别急着下载模型先花五分钟确认三件事。第一系统内存最好在32GB以上16GB会很痛苦但不是完全不行只是能用的上下文长度会被压得很短。第二SSD剩余空间需要比模型文件大至少50GB700B的Q4模型加临时文件、KV cache预留400GB以上比较稳。第三确认SSD是NVMe接口SATA SSD的顺序读速度只有500MB/s左右用SATA盘跑这个方案体验会差十倍。顺便说一句读写速度可以用CrystalDiskMark或者AS SSD Benchmark这种工具先测一下。重点看顺序读取那一项如果达不到标称的5GB/s以上说明可能过热降速或者驱动有问题后面排查的时候会用到这个基准值。3.2 给SSD划分交换空间这里很多人会误操作。如果你用llama.cpp的mmap方式加载模型模型文件本身就被操作系统当作页面缓存管理不一定要额外配swap。但如果你用KTransformers这类框架或者你希望系统有更多兜底余量给SSD划分交换空间会很有帮助。Linux下的做法创建一个大swap文件放在NVMe SSD上# 创建400GB的swap文件 sudo fallocate -l 400G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile # 查看是否生效 free -h如果想要重启后自动挂载还需要在/etc/fstab里加一行/swapfile none swap sw 0 0Windows下更简单设置→系统→关于→高级系统设置→性能设置→高级→虚拟内存把页面文件放到SSD所在分区自定义初始大小和最大值或者直接选“系统管理的大小”也行。关键是确保页面文件在NVMe盘上别放在机械硬盘。但注意一个核心原则swap是兜底不是主力。如果你发现系统在频繁读写swap意味着内存严重不够用这时候正确的做法是缩小上下文长度而不是加大swap。3.3 框架选型llama.cpp、KTransformers还是Ollama我建议新手直接用Ollama一行命令就能跑起来但它的封装比较黑盒可调参数有限。想深入理解SSD当显存这件事llama.cpp是首选参数开放、日志完整、GGUF格式支持最成熟。如果你跑的是MoE模型想追求极限速度KTransformers更合适它专门针对“GPUCPUSSD异构推理”做了优化官方对GLM和DeepSeek系列的支持都不错。3.4 启动命令与关键参数解读假设你已经下载好了GLM的GGUF量化模型比如glm-700b-q4_k_m.gguf用llama.cpp跑起来核心命令长这样./llama-cli -m /models/glm-700b-q4_k_m.gguf \ -c 2048 \ -t 8 \ -ngl 0 \ --temp 0.7逐个参数解释一下。-m指定模型路径-c是上下文长度这里设2048是为了控制KV cache大小这是内存杀手一开始别贪-t是CPU线程数建议设为物理核心数加几个超线程但不是越多越好后面会讲-ngl表示把多少层放到GPU上对于700B级别你的8GB显存无论放多少层都是杯水车薪直接设0反而稳定这句话对只有少量显存的笔记本尤其实用--temp是采样温度随便调。如果你用的是KTransformers命令风格不同类似这样python -m ktransformers.local_chat \ --model_path /models/glm-4.5-xx \ --cpu_infer \ --max_new_tokens 512KTransformers的--cpu_infer就是让非关键权重走CPU和SSD它内部会分析模型算子把密集型计算留在GPU如果有的话把稀疏大权重放SSD这个调度策略比llama.cpp的暴力方式更精细。不过KTransformers的安装依赖更多如果是新手建议先拿llama.cpp跑通再考虑换框架。3.5 调优观察怎么确认SSD真的在干活第一次运行时你大概率会被两个现象吓到一是内存占用看起来并不高二是磁盘活动特别频繁。这两个都是正常的。mmap机制下模型文件以页面缓存形式存在任务管理器看到的内存占用不是全部350GB只有当前活跃的部分磁盘活动频繁正是SSD在不断搬运权重。想验证SSD是否在满负荷工作Windows下直接看任务管理器“性能”标签里的磁盘活动百分比Linux下用iostat或者vmstat。如果磁盘读速度接近你测出来的峰值说明瓶颈在SSD如果磁盘没跑满但CPU占用已经打满说明瓶颈在CPU的解析和计算上。这两种情况对应的调优方向完全不同这个区别我在下一章展开说。有个土办法可以直接感知生成文字时把手放在笔记本的SSD位置附近能明显感觉到热度上升同时能听到轻微的读写声这就是SSD当显存在干活的直观证据。4. 踩坑实录常见问题与排查技巧4.1 速度慢到怀疑人生先分清瓶颈在哪这是所有人遇到的第一道坎。实际速度和你预期差距巨大但“慢”的原因可能完全不同。核心方法就是看资源占用打开任务管理器或iostat盯住CPU利用率和磁盘读速率两行。如果磁盘读速率已经接近SSD标称值比如5GB/s左右说明SSD确实在满负荷喂数据这已经是最佳状态了慢是物理规律。如果磁盘读写只有几百MB/sCPU却满载那问题是CPU的解量化dequantization和矩阵计算太慢。这时候可以考虑换一个针对你CPU优化的llama.cpp编译版本比如启用了AVX512或者特定指令集的版本通过加速解量化和矩阵运算把磁盘带宽的潜力释放出来。还有一种情况是线程数设置不当。设太多CPU线程反而导致缓存颠簸和调度开销实测中线程数设为物理核心数或略低于核心数往往更好速度不降反升。这块没有统一标准建议从- t 4开始往上调找到自己的甜点值。4.2 内存耗尽与OOM的应对32GB内存跑350GB的模型理论上靠mmap没问题但实际运行中还会叠加KV cache、推理框架自身的中间激活值、系统的其他进程内存分分钟告急。尤其在上下文设得比较大时KV cache会指数膨胀把页面缓存挤出去导致模型权重频繁重读SSD速度进一步恶化。应对分三步。第一步把上下文长度砍到2048甚至1024这是最有效的手段。第二步关掉浏览器、IDE这些吃内存大户给页面缓存腾房间。第三步不要随便用--mlock参数。很多人以为mlock能锁住内存让速度变快但如果你试图锁住的模型文件超过物理内存系统会直接崩给你看。对于这种超大模型老老实实让OS自动管理页面缓存才是正确做法。如果反复OOM还可以检查swap是否配置到位。虽然swap本身比SSD直接mmap还要慢但它能给系统一个缓冲避免进程被OOM killer误杀。4.3 SSD寿命与发热别把硬盘玩坏了SSD当显用每天连续读取几百GB数据很多人担心寿命问题。先说结论读多写少的情况下消费级SSD的寿命其实够用。顺序读取不消耗NAND的擦写次数真正的风险在于swap的频繁写入以及操作系统把页面缓存换出时产生的写入放大。温度是更需要关注的变量。NVMe SSD满载长时间运行温度分分钟突破70度一旦过热触发降速性能直接从5GB/s掉到2GB/s甚至更低整台笔记本还会变得烫手。建议跑长任务时留意一下SSD温度Linux下可以用smartctl查sudo smartctl -a /dev/nvme0 | grep TemperatureWindows下可以用CrystalDiskInfo看温度曲线。如果发现温度长期在65度以上可以考虑加一个散热贴或者把模型文件放在离散热模组更近的M.2插槽上但后者通常意味着拆机不推荐小白操作。4.4 什么任务适合SSD当显存什么任务别指望我的真实体会是SSD当显存适合“能接受延时”的离线批处理任务不适合任何需要实时交互的场景。整理了个速查表任务类型适合程度原因一次性长文本生成适合挂机跑慢点无所谓每日定时批量任务适合睡前排队早上出结果个人学习与原理验证非常适合理解推理瓶颈的最佳教材高频交互式对话不适合一个回复等几分钟体验崩塌模型微调与训练绝对不行反向传播要读写的权重倍数级增长生产环境高并发绝对不行一两个并发就把带宽吃满最后一列不需要解释都是实践得来的结论。特别是微调总有同学问“能不能在SSD上微调大模型”我只能说反向传播需要反复读取和更新全部权重SSD的写入带宽和寿命都顶不住这个方向连尝试的必要都没有。5. 最后说几句大实话我在一台只有16GB内存的老笔记本上实测过类似玩法选的是量化后的MoE模型。第一次看到终端里一个字一个字往外蹦的时候那种“居然真跑起来了”的感觉确实很微妙。但负责任地讲这个方案更适合作为理解大模型推理存储瓶颈的教材而不是GPU的替代品。它让你直观体会到LLM推理到底有多吃带宽、量化到底有多重要、MoE的稀疏激活到底解决了什么问题。如果你手边正好有一块读写快的NVMe SSD内存也不算太小我建议抽个周末按上面的步骤试一次。不需要买任何新硬件唯一要付出的是下载几百GB模型的时间。跑通之后你对“显存不够内存凑”这句话的理解会完全不一样。最后分享一个小技巧同样一个模型文件放在剩余空间大、没有碎片的分区上实测速度会比放在快满的盘上稳定不少这是文件分配策略带来的微妙差异临时遇到掉速时可以往这个方向排查。