最近几个月不少做AI应用的朋友来找我问题基本一致手里就一张4090或3090想跑个稍微大点的模型一跑就OOM显存直接被撑爆。换A100/H100吧钱包先不答应上多卡吧CPU内存和主板插槽又未必跟得上。其实在显存和换卡之间有一个被不少人低估的中间路线——SSD卸载技术也就是常说的SSD offloading/NVMe offload。思路很直白把模型训练和推理中那些不常被访问的数据从GPU显存搬到固态硬盘上让显存始终只保存当前最热的数据从而用一张消费级显卡把可支撑的AI规模往上拉一截。这篇文章就围绕这条路线讲清楚原理、配置、选型和踩坑经验适合正在被显存卡住脖子的个人开发者、小团队以及刚接触AI infra的同学参考。1. 显存不够用之前先搞清楚显存到底花在哪了1.1 大模型训练和推理各自吃掉哪些显存很多人以为模型放不进显存只是因为“权重文件太大”但实际情况要复杂得多。训练阶段显存主要被四类东西瓜分模型参数、梯度、优化器状态和激活值。以70B模型为例FP16精度下光模型参数就是140GB单张卡根本塞不下。而用AdamW这类优化器训练时每个参数还要额外保存一阶动量、二阶动量和主权重副本算下来优化器状态大约是参数量的3倍也就是420GB。这还没算前向传播过程中保存下来的激活值快照——小batch下可能“只有”几十GB大batch下轻松突破一两百GB。所以大模型训练本质上是在和显存玩“四个人抢一张床”的游戏。推理阶段看起来更“轻”模型权重只需要一份但真正头疼的是KV cache。我们可以简单估算一下假设一个7B模型有32层每组查询对应32个KV头每个KV头维度128用FP16存储那么每个token的KV cache大约是512KB。上下文一长到4096 token单请求就是2GB并发一高显存直接被KV cache淹没。这也是为什么很多本地部署方案在长对话、多并发场景下表现非常差。了解这些分布之后你才能判断自己缺的到底是“放权重的空间”还是“放中间结果的空间”进而决定该用哪种卸载策略。这个判断是整个SSD卸载技术选型的起点做对了后面才不容易翻车。1.2 为什么换卡和多卡不是唯一解这几年AI硬件价格一路走高一张大显存专业卡够买好几台整机。对个人开发者和预算有限的小团队来说直接上A100/H100并不现实。多卡方案也有自己的麻烦主板的PCIe通道数有限插两张卡往往只能跑在x8甚至x4带宽CPU内存也要跟着升级否则数据搬运本身就会成为新瓶颈。更关键的是很多场景下你需要的其实不是“更大的显存”而是“更大的存储层”。SSD卸载技术的核心价值就是利用固态硬盘的大容量和相对可接受的顺序读写速度把显存和内存都放不下的数据临时落盘。它不能替代真正的显存但能让一个原本因为OOM而完全跑不了的任务变成一个“慢一点但能跑完”的任务。在训练长周期模型、推理长上下文这类场景里用速度换规模往往是划算的。提示SSD卸载本质上是“容量换速度”的思路但不是所有场景都适合后面我会专门分析什么情况下不要用它。2. SSD卸载的核心原理给数据分冷热把SSD当仓库2.1 访问频率决定数据放在哪一层你可以把训练和推理过程想象成做饭操作台上只放当前正在用的锅和铲手边柜子里放常用的调料和食材整箱囤的货则放到地窖。这里的核心思想就是“冷热分层”。显存里放热数据内存里放温数据SSD里放冷数据。数据越冷访问频率越低越适合放到容量大、速度慢但价格便宜的层级。在训练中哪些数据是冷的最典型的是优化器状态——它在参数更新时才会被读取更新完之后很长一段时间不会再碰。如果把优化器状态整体搬到SSD显存立刻腾出一大块。其次是部分历史梯度、很少使用的中间激活值、以及分布式训练中其他rank的参数副本这些都属于低访问频率数据。在推理中冷数据主要是历史KV cache。当前正在生成的token需要使用最近的上下文但前面已经处理完的旧token对应的KV cache短期内不会被重新访问。把它们卸到SSD就能在有限显存里塞进更长的上下文。这里要特别强调SSD的带宽比显存低两三个数量级所以不能一股脑全卸。真正成熟的实现是让框架根据数据访问频率和计算步长决定何时、以多大粒度把数据迁到SSD。DeepSpeed里专门有一个后台管理器做这种调度对上层用户基本是透明的不需要你手工去搬文件。2.2 显存、内存、SSD三层存储怎么协同目前主流实现普遍是这样一套层级架构层级典型容量典型带宽用途GPU显存24~80GB1~3TB/s当前计算所需的最热数据CPU内存64~512GB30~70GB/s次热数据、缓冲交换区NVMe SSD1~8TB3~14GB/s冷数据、超大规模参数和KV缓存框架会在显存、内存、SSD之间以异步方式做数据交换尽量让计算等待I/O的时间与数据搬运的时间重叠。比如计算下一个batch时后台先把下一个需要的参数块从SSD读入内存再从内存拷到显存。编排得好的话SSD的延迟就被“藏”起来了宏观上看到的只是吞吐轻微下降而不是一次等好几秒的死等。实测下来有一个经验性的边界如果被卸载的数据量只占全部数据的一小部分比如10%以内SSD卸载几乎不拖累整体吞吐超过30%传输开销会逐渐追平计算收益超过50%那基本就是传输主导训练速度会肉眼可见地慢下来。这个比例直接决定你把offload开关开到多深后面我会用具体配置说明怎么把握。3. 实操三套方案把模型和中间结果卸到SSD3.1 先选型Accelerate、DeepSpeed还是vLLM不同框架解决的问题不同不能混着用。我自己实际使用下来大致是这么区分的框架擅长场景主要卸载对象上手难度成熟度HuggingFace Accelerate快速加载大模型做推理/参数高效微调模型权重、临时缓存低很成熟DeepSpeed ZeRO-Infinity大规模训练、全参数微调优化器状态、模型参数中官方支持完善vLLM高性能推理服务KV cache、部分权重中磁盘卸载还在迭代CPU卸载较稳如果你是刚上手个人建议先从Accelerate开始跑通一条“单卡加载70B模型做推理”的链路再切到DeepSpeed去跑训练。这样比较容易建立直觉知道卸载之后到底发生了什么、瓶颈在哪里。3.2 用Accelerate把模型权重落到SSDAccelerate的用法其实很友好核心是device_map和max_memory。你可以把不同层分配到不同设备一旦显存和CPU内存都满就自动落到磁盘。下面是我在单张24GB显卡、64GB内存、1TB NVMe SSD的环境上加载70B模型的示例import torch from transformers import AutoConfig from accelerate import init_empty_weights, load_checkpoint_and_dispatch model_id your-70b-model with init_empty_weights(): config AutoConfig.from_pretrained(model_id) model AutoModelForCausalLM.from_config(config) device_map load_checkpoint_and_dispatch( model, model_id, device_mapauto, max_memory{gpu: 20GiB, cpu: 48GiB, disk: 200GiB}, offload_folderoffload, offload_state_dictTrue, dtypetorch.float16, )关键是max_memory里那个disk上限这就是SSD卸载的开关。实际执行时模型权重会被拆成多份一部分挂在GPU一部分挂在CPU剩下的放在磁盘上的offload目录里。跑推理时需要哪一层参数Accelerate会在后台按需加载进显存用完再释放。注意offload目录不能挂在内存文件系统比如/dev/shm上否则表面是SSD卸载实际还是在吃内存一样会OOM。3.3 用DeepSpeed ZeRO-Infinity做全参数训练训练场景下我更推荐DeepSpeed ZeRO-Infinity。它不像Accelerate那样只能卸载权重还能把优化器状态、梯度以及参数副本统统按需搬到NVMe。先写一个ds_config.json{ zero_optimization: { stage: 3, offload_optimizer: { device: nvme, nvme_path: /local_nvme/offload, pin_memory: true, buffer_count: 4, fast_read: true }, offload_param: { device: nvme, nvme_path: /local_nvme/offload, pin_memory: true, buffer_count: 5, buffer_size: 100000000 } }, train_batch_size: 4, gradient_accumulation_steps: 8, zero_force_ds_cpu_optimizer: false, fp16: { enabled: true } }每个字段都值得解释一下。offload_optimizer.device设成nvme表示优化器的状态一阶、二阶动量放SSDoffload_param.device设成nvme则进一步把参数副本也放SSD。nvme_path必须指向一块真正的本地NVMe盘上的目录最好是独立盘避免和系统盘、checkpoint目录争抢I/O。pin_memory打开后会使用锁页内存做中转虽然增加内存占用但能减少拷贝开销。buffer_count控制搬运缓冲区的数量SSD性能越好、容量越大这个值越可以调高更充分压满顺序读带宽。fast_read开启后会使用更激进的大块预读适合训练中反复读取同一批参数的场景。训练脚本不需要大改DeepSpeed的封装会替你管理这些卸载对象。如果你的模型实在太大可以把offload_param和offload_optimizer全部落到SSD显存只负责存放当前计算层和激活值这就是ZeRO-Infinity名字的由来显存有多少不再重要关键是存储层够大。3.4 推理场景把KV Cache卸出显存如果你想服务一段很长的对话或者想在本机跑出很长的生成上下文可以试试在vLLM里把KV cache从显存卸载到CPU内存。目前vLLM官方对CPU卸载的支持比较稳磁盘卸载还在快速迭代中。简单起见可以用CPU offload先顶着python -m vllm.entrypoints.openai.api_server \ --model your-model \ --gpu-memory-utilization 0.6 \ --cpu-offload-gb 40 \ --max-model-len 32768这样显存里会留出一部分空间专门放KV cache超出部分放到CPU内存。如果确实想玩NVMe版KV cache卸载需要密切跟踪vLLM仓库里kv_transfer相关功能的更新不同版本API变化很大生产环境要谨慎。我自己实测时发现把KV cache卸载到CPU内存对首token延迟的影响通常在10%以内长上下文吞吐反而因为并发能力提高而变好。一旦落到SSD延迟代价会明显增大但换来的是可以支撑超长上下文。这类“显存不够、硬盘来凑”的编排方式在大模型推理里越来越常见。4. 性能分析与SSD选型别让搬运成为新瓶颈4.1 先算一笔带宽账SSD卸载能不能用关键看带宽。底层链路决定了搬运速度PCIe 4.0 x4大约7GB/s顺序读PCIe 5.0 x4可以达到14GB/s而GPU显存带宽动辄1TB/s以上。两者相差几百倍。但问题是每次真正搬运的数据量并不大——DeepSpeed在训练时会把参数切成块再做搬运而不是一次搬整个模型。举个例子假设你有30GB优化器状态被卸载到SSD。一块PCIe 4.0 x4的NVMe SSD实测顺序读大概6GB/s那么把这30GB全部读一遍需要5秒。如果你的训练步耗时是20秒这5秒传输时间会被计算掩盖一部分整体影响大概在20%~30%之间。如果步耗时只有2秒那5秒搬运就是绝对瓶颈训练会被拖慢到无法接受。所以关键判断依据是offload数据量与有效带宽的比值必须远小于计算耗时。用简单公式说搬运耗时 需要跨层搬移的数据量 / 实际有效带宽。做任何offload前先拿这个公式估一下再决定要不要开能少走很多弯路。4.2 SSD选型不能随便买一块市面上SSD虽多但不是都适合做offload。我踩过几次坑之后总结了几条硬指标维度推荐不推荐原因接口NVMe M.2/U.2SATA SSDSATA顺序带宽只有600MB/sNVMe的十分之一介质TLC预算允许上企业级QLC要谨慎QLC缓存外写入掉速严重长时间高频读写会受影响耐久度TBW 600TB以上低TBW消费盘offload每天可能写入几TB寿命消耗很快散热带散热片/主动散热裸片无散热持续读写时SSD温度升高会触发降速可靠性支持掉电保护无掉电保护训练中断电容易损坏缓存内数据另外尽量把offload盘独立出来不要和系统盘共用。训练期间I/O压力非常大系统和offload抢盘会导致系统卡顿也会拖慢训练。容量方面建议至少留出模型大小1.5到2倍的空闲空间因为DeepSpeed会在NVMe路径下生成临时分片文件这些文件大小可以很可观。4.3 实测调优buffer和并发参数怎么设DeepSpeed的卸载效果和buffer_count、buffer_size强相关。我习惯先拿小模型跑基准再逐步调大buffer。buffer_count从4调到8顺序读取吞吐可能提升20%~30%但显存和内存的占用量也会增加需要在OOM边缘反复试探。推理场景里vLLM的--cpu-offload-gb不宜设得过高。如果CPU内存本身很紧张卸载操作会导致生成请求排队等待反而降低吞吐。我建议让显存、内存、SSD三层的占用率都不要超过85%给调度留一点余量这样系统在峰值流量下不会突然崩溃。5. 实测过程中踩过的坑与排查清单5.1 常见问题速查表现象可能原因处理方式训练卡死或超时nvme_path目录不可写或I/O被其他进程占满用nvme smart-log看盘健康状态换成独立目录显存看起来没降多少优化器状态没真正offload检查offload_optimizer.device配置用nvidia-smi连续观察吞吐极低SSD没跑在PCIe Gen4或缓冲区太少用lspci/nvme list确认链路速度调大buffer_count频繁OOMpin_memory和buffer占用内存太多减小buffer_count或关闭pin_memorycheckpoint保存特别慢与offload并发写同一块盘把checkpoint目录放到另一块物理盘上系统整体卡顿DataLoader和offload抢CPU/I/O资源降低DataLoader worker数量或给offload设置I/O优先级5.2 几个独门技巧避免重复踩坑先跑小模型验证链路。我第一次直接上70B模型折腾半天发现只是路径权限问题导致加载失败。后来学乖了先拿一个几百MB的模型把offload链路完整跑通再切到大模型排查效率高很多。用nvidia-smi dmon和iostat -x 1同时盯着显存和磁盘。这两个工具能清晰看到搬运发生的时间点。如果显存占用持续高位说明卸载没生效如果磁盘读利用率经常跑到100%说明搬运已经成为瓶颈需要调整buffer或考虑是否减少卸载深度。注意NUMA拓扑。如果你的NVMe盘挂在CPU0的PCIe控制器下GPU和CPU内存也都在CPU0侧数据交换会快很多跨NUMA节点的搬运可能会多走一道总线延迟明显增加。用lscpu看一下拓扑尽量把相关设备对齐到同一侧。5.3 什么时候不要碰SSD卸载SSD卸载不是万能的。如果你追求高吞吐的训练比如每天都在跑大规模预训练卸载带来的速度损失通常不可接受这种情况不如直接租卡或者缩小batch配合梯度累积。如果你做的是延迟敏感的在线推理服务首token必须在几百毫秒内返回那么任何涉及硬盘读写的路径都要尽量避免。KV cache卸载更适合离线批量生成或者对首token延迟不敏感的长文档处理。还有一个容易被忽略的约束offload临时文件在训练中断后不会自动清理。如果程序被killNVMe路径下会残留大量分片文件占据很大空间。一定要写一个清理脚本或者在每次启动前清空offload目录否则时间一长盘就满了。6. 从训练到推理SSD卸载还能怎么扩展6.1 长上下文和Agent场景里很实用最近Agent类应用越来越多Agent跑一趟往往要反复调用模型多次而且每次都要处理长对话历史。如果每条历史都完整塞进上下文重新计算KV cache的计算和显存开销会成倍增长。一个很自然的优化是把历史对话产生的KV cache保存下来卸载到SSD新的一轮交互只对新增内容做预填充。这样既能维持Agent对上下文的记忆又不至于让显存被历史包袱占满。我见过不少个人开发者用类似手法在单卡上跑起带几十万字上下文的本地Agent核心手段就是“旧KV上盘新KV进显存”。这类实现目前还没有一个特别统一的开源方案很多是在vLLM或SGLang底层上做定制属于比较有潜力的AI基础设施方向。6.2 单卡实验室参考配置给大家一个可以直接抄的参考组合一张24GB显存显卡、64GB以上CPU内存、一块1TB以上PCIe 4.0 NVMe SSD。在这个配置下你可以做到用4bit量化配合SSD卸载跑70B模型推理单token速度大概是每秒几到十几个token具体取决于batch和量化方式用DeepSpeed ZeRO-Infinity全参数微调7B模型把优化器状态放SSD显存压力明显下降能开更大的batch用vLLM CPU offload跑32K上下文的7B模型服务并发几十路基本不会OOM。这套配置的总成本远比一块48GB专业卡低但对折腾能力的要求更高。凡是涉及硬盘的路径速度响应都会比纯显存版本慢你需要对业务能接受的时延做到心里有数。6.3 后续可以往哪些方向扩展SSD卸载技术本身还在快速进化。一是卸载粒度越来越细从整层权重到按token切块的KV cache意味着能更精准控制冷热边界。二是跟量化结合更紧密4bit模型配合卸载能把原来塞不进显存的模型压到很小的显存空间里跑起来。三是分布式场景下可以配合分布式文件系统做远端卸载不过这时瓶颈会从本地PCIe转移到网络带宽需要谨慎评估。如果是个人开发者我建议先从本地单机的NVMe卸载开始把原理和调优手感建立起来再考虑往集群方向扩展。这个技术最大的魅力在于它并不要求你花更多钱买显存而是把计算机本来就有的存储资源重新用起来用工程手段换规模。我自己在实际操作中最深的体会是SSD卸载不是银弹但却是预算不足时最值得研究的“显存扩张术”。决定效果的往往不是“用不用SSD”而是你有没有把冷热分层做到位——哪些数据放显存、哪些放内存、哪些落盘边界划得越清楚性能损失越小。最后再分享一个小技巧装好环境后别急着跑大模型先用torch.cuda.memory_summary()和iostat看看显存与磁盘的真实压力再决定要开多深的卸载。这个动作能帮你省下大量试错时间比你盲调几十次参数都管用。