大模型推理为何疯狂写SSD？一天256GiB的元凶与优化指南

Strix Halo这台小主机跑 qwen3.8 flash next一天下来直接把我 SSD 写掉 256GiB——这是我玩本地大模型以来踩过最深的坑没有之一。最开始我还不信以为 smartctl 的数据有问题反复核对了两次才确认就是昨天一天之内产生的写入量。按一块 256GB 的盘算相当于一天把整盘写满一遍按 1TB 的 TLC 盘算一天就把可用寿命预算吃掉了四分之一。这篇文章我就从这次事故出发把大模型推理导致写盘激增的原因、怎么定位、怎么优化完整讲透。适合所有用迷你主机、AI PC 或者服务器本地跑大模型的朋友不管你是刚接触还是已经踩过类似坑应该都能从中找到对应的解决办法。1. 事件现场跑了一天 Qwen3SSD 被写掉 256GiB1.1 我的设备与运行场景先说下机器配置AMD Strix Halo 平台的迷你主机具体是 Ryzen AI Max 395 那一档16 核 Zen540CU RDNA 3.5 核显加上 XDNA2 NPU配了 128GB LPDDR5X 统一内存系统盘是一块 2TB 的 PCIe 4.0 NVMe SSD系统装的 Ubuntu 24.04。Strix Halo 这个平台最大的特点就是统一内存架构CPU 和 GPU 共享那 128GB 内存所以跑大模型特别方便不需要独立显卡8B 级别模型能轻松装进内存里跑。那天我做的事情不算复杂本地部署 qwen3.8 flash next先用 vLLM 起了 OpenAI 兼容 API 服务中间为了调参又换了 llama.cpp 加载同一份模型跑了几轮批量评测脚本让模型读了一批测试数据并生成结果输出重定向到 JSON 文件。整个过程大概持续了 16 小时模型服务没有一直开中间因为改参数重启过七八次每次启动都要重新加载模型。第二天早上我习惯性看了一眼 smartctl 的写入量统计结果直接傻眼了Data Units Written 从前一天的某个值暴涨换算下来正好 256GiB。我当时的反应是这不可能毕竟跑模型主要是读怎么会写这么多。但后来一步步查下来发现这个数字不仅可能而且背后是一连串被忽视的写入源叠加出来的。1.2 一天写 256GiB 到底是什么概念先普及一个基础概念NVMe SSD 的 smartctl 输出里Data Units Written 一般是按 512 字节为单位统计的有的盘会标注按 1000 字节算所以换算前先看盘自己的定义。256GiB 换算成字节是 274877906944如果是 512 字节单位对应的扇区数就是大概 5.37 亿个。从寿命角度算一笔账假设你的盘是 1TB TLC SSD标称 TBW 600TB那么每天写 256GiB 相当于一年写掉约 91TB也就是一年消耗约 15% 的设计寿命。如果盘是 QLCTBW 通常只有 400TB 左右一年就用掉近四分之一。这意味着硬盘短期内可能不会立刻报废但如果长期保持这个写入速率两三年后 smartctl 里的 Percentage Used 就会接近或超过 100%性能和稳定性都会开始出问题。更要命的是逻辑写入和物理写入不是一回事。如果文件系统层产生大量小文件写入、日志追加或者触发 SSD 垃圾回收主控实际写入 NAND 的数据量可能是逻辑写入的好几倍这就是经常说的写放大。所以 256GiB 只是我们看到的部分背地里 NAND 磨损可能更多。2. 大模型在电脑上到底往硬盘写了什么2.1 模型权重与缓存的反复加载很多人想当然觉得跑大模型就是把模型加载到内存/显存然后推理几乎不写盘。这个想法对了一半。推理过程本身确实很少写但推理之外的外围环节全都在写。第一个来源是模型文件的反复加载。qwen3.8 flash next 如果是 FP16 权重光模型文件就接近 16GB即使量化到 INT8 也要 8GB 以上。每次启动 vLLM 或 llama.cpp系统都要从 SSD 把这些文件读进内存一台 128GB 内存的 Strix Halo 确实装得下但问题是我一天重启了七八次服务等于把 16GB 权重重复读了上百 GB。虽然读操作不直接磨损 NAND但读取带来的干扰、主控的 GC 行为都会间接增加写放大。第二个来源是各种框架缓存。HuggingFace 的 HF Hub 会默认在 ~/.cache/huggingface/hub 下面保存模型文件的缓存副本并且每次启动还会检查云端是否有更新涉及 etag 校验和符号链接重写这些操作会写少量元数据。类似的还有 vLLM 首次加载时生成的 Triton kernel 缓存会写到 ~/.triton/cache重新编译的时候一次几百 MB 到几个 GB 都很正常。我那天多次重启服务等于反复触发部分缓存重建这些写入全部落在 SSD 上。2.2 KV Cache、内存压力与 swap 的雪崩第二个来源更加隐蔽也往往是写入量暴涨的元凶——内存换页也就是 swap。大模型推理时KV Cache 会随着生成 token 数量线性增长。一个 8B 模型在长上下文场景下KV Cache 轻松占掉几个 GB。Strix Halo 的 128GB 统一内存看起来很充裕但 GPU 侧默认会分走很大一部分作为显存池系统侧剩下的内存再被浏览器、容器、数据库、评测脚本一挤空闲内存其实没有想象中那么多。更关键的是 Linux 的内存回收策略。默认 swappiness60 的情况下内核在内存压力升高时会把不常用的匿名页换到交换分区或交换文件。如果 swap 文件放在 SSD 上那么每次换出都是实打实的 NAND 写入。我排查时发现系统根分区上挂了一个 32GB 的 swapfile跑模型期间因为内存紧张swap 使用量从 0 涨到了好几个 GB这些数据全是 SSD 写出来的。KV Cache 还有一个风险点如果用的是 vLLM并且给 GPU 显存池设置得过大系统内存会被压缩到很小一旦模型并发请求多、上下文变长内存压力会瞬间飙升。此时内核开始疯狂换页模型推理反而变慢然后更多请求排队更多内存被占用形成恶性循环。最终表现就是 SSD 写入量短时间暴涨温度升高任务卡顿。2.3 日志、监控与输出重定向第三个写入源最容易被忽略那就是日志。vLLM 默认日志级别是 info每处理一个请求都会打印时间、模型名称、prompt 长度、生成 token 数、耗时等一堆信息。如果服务由 systemd 托管journald 还会把这些 stdout 内容持久化到 /var/log/journal。跑十几个小时文件几十上百 MB 很正常。如果是自己写脚本调用模型脚本里如果有 print 刷屏输出或者把每次推理结果追加写到结果文件累积下来同样可观。还有一个隐藏点文件系统 atime。现代 Linux 默认用 relatime读操作不会每次都更新访问时间但如果你为了调试把某个目录挂在 strictatime 下或者工具频繁读取文件元数据就会产生额外的写操作。除此之外模型的 tokenizer 转换、临时文件的创建和删除虽然单次很小但在一天几万次操作下写放大效应会让真实写入远超预期。提示大模型推理进程本身并不会主动去写 SSD真正在写的是模型加载、框架缓存、日志和系统换页这些外围行为。理解这一点后续排查思路就清晰了。3. 如何定位这 256GiB 是被谁写掉的3.1 先用 smartctl 和 diskstats 做宏观判断排查写入问题第一步是确认总量和速率不要上来就猜。smartctl 是你最基础的依据smartctl -a /dev/nvme0n1 | grep -E Data Units Written|Power On Hours|Percentage Used记录下当前数值跑一段时间再看增量。比如我这次就是前一天记录了一个值跑完模型后看差值得到 256GiB。换算方法很简单如果单位是 512 字节就用增量乘以 512 再除以 1024^3。部分盘会在 smart 信息里直接标明 unit比如 1,000,000 bytes per unit这时要按 1000 进制换算别搞混了。如果要看实时速率可以用 iostat 监控每秒写入量判断是持续写入还是突发写入iostat -x /dev/nvme0n1 1持续写入十几 MB/s 没停基本可以确认是某种服务在后台不停写文件如果是每隔一段时间突然飙到几百 MB/s更像内存换页或缓存重建。另外还有一种方式直接读内核统计文件/sys/block/nvme0n1/stat第 7 列是写扇区数第 10 列是写入时间戳换算逻辑和 smartctl 类似。3.2 用 fatrace 和 iotop 锁定肇事进程宏观数据确认了写了很多接下来要把具体文件和进程揪出来。这里我推荐两个工具搭配使用。第一个是 iotop看进程维度的 IO 统计sudo iotop -a -P -o-a是累计模式-P只看进程不看线程-o只显示有 IO 的进程。这样能快速看到哪几个进程在写盘比如 vllm、llama.cpp、containerd 或者 bash 脚本。第二个是 fatrace直接记录哪个文件被打开和写入sudo fatrace -t 600 /tmp/write_trace.log跑十分钟左右日志里会不断刷新文件路径和操作类型。拿到结果后你会发现真正在频繁写的基本就几类路径swapfile、HuggingFace 缓存目录、Triton 缓存目录、journald 日志、评测输出文件。我当时还配合用了 lsof -p 查看模型进程打开的日志文件描述符确认了日志轮转情况。这里要特别强调的是不要只看进程名就下结论。比如模型进程看起来是主角但它可能只是把 stderr 输出交给 journald真正写盘的是 journald又比如内存压力导致的内核换页写入进程显示的可能是 kswapd0而不是你的模型程序。所以 fatrace 给出的文件路径远比进程名有说服力。3.3 检查内存压力和 swap 实际使用定位到 swapfile 有写入之后下一步就是确认内存是不是真的紧张。free -h cat /proc/pressure/memory sysctl vm.swappiness vm.vfs_cache_pressure如果跑模型期间 swap 使用量从 0 涨到好几 GB说明内存确实不够用或者回收策略太激进。/proc/pressure/memory里的 some 和 full 数值如果偏高说明系统确实在频繁经历内存回收。另外一个细节是查看 PSI 的 throttled 时间如果出现大量 throttle说明 cgroup 层面也在限制内存久了你不仅会看到写入猛增还会发现服务响应变慢。还有一种情况是内存充足但 swap 依然写入这就要检查代码里有没有主动调用 mlock 或者有没有进程设置了不可回收的标记。不过大多数场景下内存压力是主因调低 swappiness 是优先方案。4. 给硬盘减负的五板斧4.1 调整 swap 策略别让内存溢出变成 SSD 杀手第一个优化方向也最立竿见影让内核少用、慢用交换空间。Strix Halo 这种平台有 128GB 统一内存正常情况下完全不该指望 swap 兜底swap 只应该作为防止 OOM 的最后保险。做法是修改 sysctl 配置echo -e vm.swappiness10\nvm.vfs_cache_pressure50 | sudo tee /etc/sysctl.d/99-lowswap.conf sysctl --systemswappiness 从默认 60 降到 10内核会更倾向于回收 page cache 而不是把匿名页换到磁盘vfs_cache_pressure 从默认 100 降到 50是为了避免目录和 inode 缓存被过早回收防止频繁读盘。如果你确认内存足够大甚至可以直接把 swapfile 从 SSD 上移除或换到 zram让内存压缩替代磁盘换页。注意如果内存确实不够用强行把 swappiness 调低会导致内存回收效率下降甚至触发 OOM。正确做法是先搞清楚模型服务占用多少内存再决定是否调整而不是盲目取消 swap。4.2 模型服务常驻化避免反复加载第二个优化方向是减少模型加载频率。如果你一天要发起几十次模型调用每次都是启动一个新进程加载 16GB 权重跑完就退出那 SSD 上的读操作和缓存文件写入都会被成倍放大。最好的做法是把 vLLM 或 Ollama 做成 systemd 服务常驻只加载一次模型之后通过 HTTP 接口调用。vLLM 的--serve-load-format和 Ollama 的keep_alive参数都能控制模型驻留时间把 keep_alive 设成 -1 表示一直常驻。这样即使你后续有几十个任务模型权重也只是在内存里放着不会再从 SSD 反复加载。如果你习惯用脚本直接调用 Python API也建议改成向常驻服务发请求而不是每个脚本启动时重新初始化模型。这个改动对 SSD 寿命的贡献比我预想的还要明显我后来把七次重启改成一次常驻之后单日写入量直接降了一大截。4.3 把模型和缓存挪进 tmpfs第三个优化方向也是我非常推荐的一步给模型和各类缓存建一个内存盘。tmpfs 是 Linux 自带的内存文件系统会占用系统内存但是读写速度极快关键是它完全不碰 SSD。步骤很简单sudo mkdir -p /mnt/ramdisk sudo mount -t tmpfs -o size64G tmpfs /mnt/ramdisk cp -r /mnt/models/qwen3-8b /mnt/ramdisk/模型大概 16GB放到 64GB 的 tmpfs 里绰绰有余。然后把各种缓存目录也指到 tmpfsexport HF_HOME/mnt/ramdisk/hf_cache export XDG_CACHE_HOME/mnt/ramdisk/cache export TRITON_CACHE_DIR/mnt/ramdisk/triton_cache这样模型加载走的是内存HuggingFace 缓存和 Triton kernel 缓存也全在内存SSD 上连一点边都蹭不到。缺点是重启后 tmpfs 内容清空需要重新从 SSD 拷贝但拷贝一次只产生几 GB 的读操作不会损伤 NAND 写入寿命。Strix Halo 的内存带宽非常充裕模型放 tmpfs 里跑加载速度反而比 SSD 更快是一种完全可行的部署方式。4.4 日志与缓存目录瘦身第四步是管住日志。日志看似写入量不大但它胜在频繁且持续一天下来加上写放大相当可观。先改 journald让它别把日志持久化到 SSDsudo sed -i s/^#Storageauto/Storagevolatile/ /etc/systemd/journald.conf sudo systemctl restart systemd-journald如果还是想留一定量日志就把SystemMaxUse调小比如 200M 并开启轮转。然后是模型框架自身的日志级别vLLM 可以加--log-level warningllama.cpp 可以设置LLAMA_LOG_LEVELerror避免每个请求都打印一大串 info。批量脚本里也尽量少用 print 循环输出改成最终统一写汇总文件减少文件的频繁追加。Triton 缓存和 HuggingFace 缓存如果暂时不能放 tmpfs就至少保证版本稳定。同一个模型、同一个 torch 版本、同一个 ROCm 驱动版本Triton 缓存是可以复用的反复切换环境才会反复编译写入。4.5 文件系统参数与 SSD 健康管理最后一步是基础保养。检查根分区的挂载参数确认至少是 relatime有条件直接上 noatimesudo mount -o remount,noatime /在 /etc/fstab 里把 noatime 写入永久挂载选项。然后是 TRIM大多数发行版默认开 fstrim.timer但最好确认一下systemctl enable --now fstrim.timerTRIM 的作用是让 SSD 主控及时清理空闲块避免 GC 滞后导致写入放大。还有一点很多人忽略SSD 要留足 OP 空间。不要把盘塞到 95% 以上至少要保留 10%~20% 空闲主控才有空间做垃圾回收和磨损均衡。如果你长期跑大模型建议给系统盘单独分一个大分区别把模型、缓存、日志全堆在同一个盘上。5. 常见问题与排障实录5.1 一天写 256GiB硬盘会立刻挂掉吗这是被问得最多的问题直接算账。假设置盘是 1TB TLCTBW 600TB每天写 256GiB一年约 91TB两年也才 182TB不到寿命三分之一。所以单看数字硬盘可能两三年内不会马上报废。但要注意如果盘本身容量只有 256GBTBW 往往只有 150TB 左右那你一天写满一遍一年就是 91TB两年就接近寿命上限风险完全不同。另外smartctl 里的 Percentage Used 是厂商根据写入量算出的磨损估计值不代表实际物理死亡时间。很多 SSD 在超过 100% 之后依然能继续用但坏块率上升、掉速、突然掉盘的概率会明显增加。我的建议是如果发现长期每天有几十 GB 以上的写入立刻开启监控不要等盘挂了再追悔。5.2 怎么确认是模型框架在写还是系统在写最简单的方法是做对照实验。先停止所有模型服务记录 smartctl 写入值空跑一小时再查一次如果增量微乎其微说明问题出在模型侧如果空跑依然有大量写入那就要查系统后台服务了。更精细的做法是用 fatrace 记录具体文件路径我那次排查最快的方式就是看日志里出现最多的路径结果发现 swapfile 写着写着其他所有的分析都变得清晰了。注意跑模型时输出重定向到文件的行为也会导致大量顺序写入。如果你是在跑评测任务把结果文件放在 tmpfs 下结束后再拷回 SSD 归档能有效避免频繁 append 造成的小文件写入和写放大。5.3 SSD 出现坏块、掉盘甚至无法识别怎么办如果你因为长期高写入把盘搞到掉盘或文件系统损坏先别急着上什么量产工具、开卡工具。第一步是把盘断电冷却接到 USB 外置盒里看 smart 信息确认是过热、SMART 报错还是接口问题。如果盘在 UEFI/BIOS 下都无法识别可以尝试更新固件部分盘掉盘可以通过固件修复。数据没备份的话绝对不要反复通电尝试用 ddrescue 做镜像才是正确方向。网上流传的固态硬盘开卡和量产工具本质上是重新初始化主控的 NAND 管理信息和坏块表风险非常高需要匹配主控型号和颗粒规格操作失误可能直接让盘变砖。除非你明确知道自己在做什么否则我建议直接找专业数据恢复机构或者放弃这块盘别把大量精力和数据安全赌在一款来路不明的量产工具上。5.4 Strix Halo 平台跑本地模型的补充注意点最后聊几个 Strix Halo 特有的问题。这个平台本质上是 APUGPU 共享统一内存所以跑模型时要明确给 GPU 设置内存上限。如果 vLLM 的 gpu_memory_utilization 设置过高系统内存会被吃光进而触发 swap 风暴表现为模型首 token 延迟飙升同时 SSD 写入激增。建议把这个参数控制在 0.7 左右留足系统缓冲。ROCm 环境下跑 vLLM 或 llama.cpp还会生成 shader 缓存通常位于 ~/.cache/ROCm 或 ~/.cache/racc这部分同样建议重定向到 tmpfs。另外 Strix Halo 的 NPU 目前对 Qwen 这类模型的支持比较有限实测下来直接用 RDNA 3.5 核显跑更稳定别被 NPU 的 50 TOPS 宣传参数迷惑了工具链不成熟的时候兼容性优先。我个人现在养成的习惯是给每台跑大模型的机器建一个写入量日报脚本每天定时记录 smartctl 的 Data Units Written 和 Temperature输出到 CSV每周瞄一眼趋势。只要数据每天增量超过 20GB我就会去检查是不是有脚本在疯写日志、swap 是不是又起来了、缓存目录是不是没设到 tmpfs。这套流程帮我避免了好几次 SSD 寿命危机也让我对这些隐形写入始终有数。大模型部署不光是看能不能跑起来把存储、内存、日志这些底层细节管住才能真正长期稳定地用下去。