大模型推理把SSD写入量打爆？从256GiB/天到2GiB的排查实战

跑大模型折腾硬盘这件事我以前总觉得是老黄历了。直到我自己把 Strix Halo 搬出来高高兴兴地把 qwen3.8 flash next 挂上跑了一整天第二天随手敲了行smartctl -a /dev/nvme0n1直接愣住了一天之内这块 NVMe 的写入量彪了 256GiB。没看错不是 25GiB是 256GiB。我当时第一反应是固件抽风了第二反应是模型在偷偷摸摸干什么坏事。这篇文章不绕弯子直接把我从看到写入量瑟瑟发抖到定位元凶、优化配置、最后把日写入压到 2GiB 以下的完整过程写出来。不管你是用笔记本跑 GGUF 推理还是服务器上面挂 vLLM只要模型一跑起来硬盘写入就异常飙升这篇应该能帮上忙。1. 跑个大模型怎么就把硬盘写穿了1.1 256GiB/天这个数字意味着什么先算一笔账免得你觉得 256GiB 不过是零头。一块常见的 1TB TLC 固态标称寿命通常在三四百 TBW也就是 300TB 到 600TB 的总写入能力。按 400TBW 算256GiB/天意味着约 1560 天、差不多四年出头就会把整块盘的寿命预算跑完。听着好像还行注意这是逻辑层写入量实际 NAND 写入量在随机小写场景下会被写放大放大好几倍甚至十几倍所以真实磨损可能更快。更扎心的是很多笔记本 Strix Halo 平台的盘是 512GB 甚至 1TB但系统、游戏、工作文件全在同一块盘上你不可能把全部寿命都贡献给一个模型。这里给还没反应过来的朋友一个直观对比正常轻度办公加看视频一天的磁盘写入量通常几十 GB 以内跑个 8B 级模型推理一次加载权重可能写掉几 GB 缓存但也就几 GB 到几十 GB。一天 256GiB说明一定有某个环节在持续、高频地写盘而不是偶尔碰一下。顺带一提qwen3.8 flash next 这个 tag 我是按社区常见的 Qwen 3 系优化版本来理解的它到底是不是严格意义上的 Qwen3-8B其实不重要。重要的是大模型推理本身不该带来这种量级的磁盘灾难。真凶往往藏在模型运行时的周边机制里而不是模型权重文件本身。1.2 一次写盘事件可能来自五个完全不同的源头我排查下来大模型相关任务把硬盘写爆基本逃不出这五个来源。第一是模型权重重复加载。很多推理框架每次启动进程都会把 8B 甚至更大模型的权重完整写入内存映射或临时文件如果你在一个脚本里频繁拉起新进程一次十几 GB 的写入很快就堆起来了。第二是系统 swap 和内存页溢出。明明机器有 128GB 统一内存但当模型、显存映射、页面缓存、其他服务一起把内存挤到临界线Linux 内核就会把匿名页换到 swap 分区。如果 swap 在 SSD 上每一次模型推理的内存抖动都会变成实打实的磁盘写入。第三是 KV Cache 的 spill。vLLM、llama.cpp 这类框架为了在显存或统一内存不够时继续跑长上下文会把计算过的 KV 块写到主机内存再从主机内存落盘。这部分属于模型要跑完所以替你做的临时存证写入量跟上下文长度和 batch 大小直接挂钩。第四个来源是日志和检查点。模型服务跑起来之后如果日志级别是 debug每个 token 的延迟、每次采样、每条异常都可能刷几行到几十行聚合起来就是每小时几 GB。微调或预训练场景更狠checkpoint 每几个 step 存一次一次几十 GB一天下来几百 GB 都算轻的。第五个是数据集和缓存目录。Hugging Face 缓存、tokenizer 缓存、TRITON 算子缓存、Ollama 模型缓存这些默认都在用户目录或临时目录。模型跑起来之后框架会自动下载或解压如果你反复清理缓存再启动写入量当然也好看不了。关键词是持续写。一次两次大写入不可怕可怕的是某种循环让盘根本停不下来。我后面做的所有优化都是围绕找出这个持续写而不是纠结单次写入。2. 为什么统一内存那么大还是会写盘2.1 统一内存不等于内存管够Strix Halo 是 AMD 把 CPU、RDNA 3.5 核显和 XDNA 2 NPU 塞进同一颗芯片的平台CPU 和 GPU 共享同一片 LPDDR5X 内存。听着很美好实际用起来有个盲区你看到的 128GB 可用内存有一部分要留给核显驱动、固件预留、IO 映射和 GTT 页表。BIOS 里通常还有 UMA frame buffer 的设置默认大小五花八门。在这样的架构下跑大模型最尴尬的场景是显存感知失灵。有些推理框架在 NVIDIA 上会老老实实认显存到了 AMD 核显统一内存上它既把它当显存又把它当系统内存结果就是内存明明还有 10GB框架却已经开始把 KV Cache 往磁盘上倒了。模型权重本身可能通过mmap映射进内存但如果页面压力上来映射页会被换出下次重新访问又变成读盘。读盘本身不可怕可怕的是随之而来的 swap 回写把曾经干净的页搞脏再写回分区。2.2 Flash Attention 救的是显存不是写盘qwen3.8 flash next 这个名字里的 flash多半和 Flash Attention 这类优化有关。Flash Attention 的分块计算确实大幅降低了显存峰值让同等显存能跑更长的上下文。但它解决的问题是算力换内存不是内存换磁盘。如果配套的 KV 管理器发现剩余显存装不下新 block它仍会执行 offload把旧 block 迁移到 CPU 内存CPU 内存再不够就去搞临时文件。我在排查时看到的现象就非常典型模型服务进程明明活着但/tmp里多了一大堆几十 GB 的文件进程退出后又被清理。这些临时文件本质上就是 KV spill 或数据缓存被磁盘化。换句话讲Flash Attention 把显存需求压下来了但如果你把上下文长度拉到 32K、64K、128K总 KV 量仍然可以轻松超过内存预算于是盘上见。2.3 固态没有磁道它的命门是写放大很多从机械硬盘时代过来的人会下意识用磁道、扇区这种概念理解固态。实际上 SSD 内部根本没有什么磁头要移动它的最小读写单位是页、擦除单位是块FTL 层会把你的每次逻辑写入转换成读、改、写一整块内的数据。随机小写是最伤的一次 4KB 的日志写入FTL 可能要迁移整块 4MB 的数据写放大 1000 倍都不夸张。这也解释了为什么同样的256GiB 逻辑写入在不同盘上产生的磨损不一样。有些盘 SLC Cache 写满后直接掉速、写入量反而少有些盘垃圾回收逻辑激进后台自动搬数据SMART 里的 NAND 写入量远超你看到的逻辑写入。热词列表里那些空硬盘写入顺序、固态硬盘量产工具、固态硬盘开卡之类的问题本质都是在讨论 FTL 和磨损。开卡量产是修复级手段普通用户千万别为了省寿命去折腾后面我再说为什么。3. 一次完整盘查我把写盘路径一条条揪出来3.1 先用 smartctl 给硬盘做个体检不要急着重装系统也不要急着删模型。先看看 SMART 数据把基准数字记下来。smartctl -a /dev/nvme0n1 | grep -E Data Units|NAND|Percentage Used|Power On Hours|Unsafe Shutdowns重点看几项Data Units Written代表逻辑层写入总量NAND Writes如果有代表实际闪存写入Percentage Used是主控按寿命损耗给出的百分比Unsafe Shutdowns是非正常断电次数。注意不同固件对 Data Units 的单位定义不一样不少是 512B、1000B 或 1000KB 一个 unit最稳的办法是直接看 smartctl 输出里方括号换算好的字节数或 KB 数别自己瞎乘。对 Linux 用户来说/dev/nvme0n1p5这种路径也要会读nvme0n1 是第一块 NVMe 盘p5 是它的第五个分区。如果是数据中心里做了 RAID6 的多盘系统每一块成员盘都要单独看 SMART因为 RAID 卡只负责组合不负责帮你擦屁股。我当时的记录是上午 9 点到第二天上午 9 点Data Units Written增加了约 537,000,000 个 512B 单位换算下来就是 256GiB。看到这个数字后我没有立刻杀进程而是先取了个快照再去抓实时写入。3.2 实时抓进程iotop、fatrace、lsof 三件套SMART 是事后账本实时抓现行还得靠进程级工具。sudo iotop -o -P-o只显示有 IO 的进程-P按进程而非线程聚合几秒内就能看到谁在写。我这次抓到的是几个 python 进程轮流写/tmp/tmpXXXX写入速率稳定在 8MB/s 左右非常典型。如果 iotop 不够细上fatrace它能把进程对文件的每次访问实时打出来sudo fatrace -t配合lsof L1还能找到那些已经被删除但还被进程占着的大文件这种文件在系统崩溃或进程退出前不会释放会一直拖着占用磁盘空间。你可以顺手看一下是不是有几十 GB 的 unlinked 文件。sudo lsof L1 | awk {print $7, $1, $2, $9} | sort -rh | head -20这一套组合拳下来方向基本明确了不是下载器在折腾是模型运行时在写临时文件。3.3 用 auditd 或 inotifywait 监控高频写入目标进程抓到了但你还需要知道它具体在写哪个目录。inotifywait 是好东西重放任务前先挂一个监控sudo inotifywait -m -r --timefmt %F %T --format %w%f %e %T /tmp /home/xxx/.cache 2/dev/null /tmp/inotify.log跑上十分钟再看日志写入热点一目了然。如果目录里文件太多inotifywait 会消耗大量内存所以我只挂了/tmp和模型缓存目录。auditd 也能干这事但它是系统级审计短时间开启还行长时间开着它本身也会写盘属于用毒药查毒源。我的建议是用 inotifywait 做定向监控auditd 只在你怀疑有隐藏进程偷偷写文件时才开几十秒。3.4 验证性实验把缓存全塞进 tmpfs看写入动不动光看还不够得做个对照实验。把模型运行的缓存目录全部指到内存盘/dev/shm这样即使进程疯狂写缓存也不会落到 SSD。export HF_HOME/dev/shm/hf export OLLAMA_MODELS/dev/shm/ollama export TRITON_CACHE_DIR/dev/shm/triton export TMPDIR/dev/shm/tmp然后重跑同样的推理任务再对比 SMART 的写入增量。我做完这步之后磁盘写入几乎停摆而 tmpfs 里以肉眼可见速度堆起了文件。结论水落石出根因是缓存和临时文件的落盘策略而不是模型本身在故意伤盘。注意tmpfs 本质是内存满了一样会报错或 OOM。验证实验只做短时间别把这个配置直接当生产方案用除非你能接受断电丢临时数据的风险。4. 治理方案把日写入从 256GiB 压到 2GiB 以内4.1 内核回收策略swap 可以留着但要让它退居二线先说结论不要在有大内存的机器上把 swap 彻底关掉尤其是跑大模型时。一旦内存真的不够没有 swap 会直接 OOM 杀进程模型加载到一半被杀更浪费时间。正确做法是让内核优先压缩、优先内存复用而不是一有压力就去碰 SSD。sudo sysctl -w vm.swappiness1 sudo sysctl -w vm.page-cluster0 sudo sysctl -w vm.vfs_cache_pressure50swappiness1让内核几乎不主动换出匿名页page-cluster0让 swap 按需读取单页而不是一次抓一大把vfs_cache_pressure50稍微多保留 dentry/inode 缓存减少重复加载文件时的元数据开销。这些参数写到/etc/sysctl.d/90-llm-tune.conf里重启自动生效。如果你必须保留 swap 功能我强烈建议把 SSD 上的 swap 分区换成 zram也就是把内存压缩成一块虚拟块设备当 swap 用。写入 zram 的数据会被压缩后再占用真实内存通常不落 SSD极端内存压力下反而还有交换空间兜底。sudo modprobe zram echo 16G /sys/block/zram0/disksize sudo mkswap /dev/zram0 sudo swapon /dev/zram0 -p 100我这边 128GB 的内存给 zram 划了 16GB 就够它优先级高于 SSD swap所以内核会先压内存而不是先磨盘。4.2 在 Strix Halo 上给模型推理减负不是降性能Strix Halo 的内存带宽和核显规模给了你很大的操作空间但前提是软件配置别拉满。以下这些修改我没有一个是以牺牲可用性为代价的全部治标又治本。第一上下文长度别无脑拉满。很多人看到 qwen 系模型支持长上下文就把--ctx-size设成 128K。但 KV Cache 的占用是线性的128K 上下文产生的临时数据量和一个 token 一个 token 递增的写入量非常可观。我实际跑任务只需要 8K 上下文设了 8K 之后spill 到盘的 KV block 瞬间消失了。第二量化 KV Cache。在 llama.cpp 系的推理里KV Cache 用q8_0或f16都有选项vLLM 里也有相关配置。量化 KV 之后缓存体积缩小一个量级内存不容易爆磁盘 spill 的概率也低。第三关掉不必要的 beam search 或拉小 batch。beam search 会展开多倍分支等于 KV 缓存翻倍甚至更多。我日常用 greedy 或单路采样写入量肉眼可见降下来。第四如果用的是 vLLM显式限制 swap 和 offloadpython -m vllm.entrypoints.openai.api_server \ --model /path/to/qwen3.8-flash-next \ --max-model-len 8192 \ --max-num-seqs 8 \ --swap-space 0 \ --gpu-memory-utilization 0.9--swap-space 0是让 vLLM 不要建立 CPU 侧 swap 文件--gpu-memory-utilization留一点余量但别小到把 KV 挤爆。LLaMA 系框架还有一个常见坑如果不用--mlockmmap 映射的权重页可能在内存压力下被换出下次再访问就跟读盘较劲。内存装得下模型的场景建议直接--mlock锁页如果内存本来就紧张再加锁反而可能逼迫其他页去 swap这个要看具体情况。4.3 日志和缓存藏得最深的写盘大户说句实话大部分人的写入暴涨根本不是 KV 或 swap而是日志。vLLM 默认的日志级别会打出每个请求的输入输出 token 数和耗时看起来不多但如果你开着 debugtoken 级事件会疯狂滚动。我抓到过一小时写 30GB 日志的真实案例。改法很简单把日志级别调到 warning 或 info且用轮转日志。LOG_LEVELwarning python -m vllm.entrypoints.openai.api_server ...缓存目录是第二隐藏大户。Hugging Face 每次下载模型都会在~/.cache/huggingface留下完整文件副本你清理一次再跑一次它就再下载一次。对这种明知会反复读的文件用 tmpfs 反而危险占内存正确做法是保留磁盘缓存但确保进程能复用不要反复清空。另外跑训练或微调时最容易忽视的是 checkpoint 保存策略。save_steps设 50、100 这种小步长每步存一次十几 GB一天下来几百 GB 很正常。如果模型权重不是特别珍贵可以把 checkpoint 存到 tmpfs等全部训练完再一次性同步到 SSD否则就加大 save 间隔用 PEFT 方式只保存增量 adapter。4.4 不得不大量写盘时怎么让 SSD 活得久一点有些场景下大量写盘避不开比如你确实在跑长上下文压测或者连续做多轮微调。这时候要拼的不是零写入而是把对盘的伤害降到最低。首先要保持足够的空闲空间。SSD 需要空闲块做垃圾回收和磨损均衡塞到 99% 的盘GC 会非常频繁写放大直线上升。我个人习惯是保留 10% 左右不分区尤其 Strix Halo 这种单盘机器别为了那几十 GB 空间把寿命牺牲掉。其次是打开并定期执行 TRIM。现代 Linux 发行版默认开启 fstrim.timer你可以确认一下。systemctl status fstrim.timer sudo fstrim -v /TRIM 让 SSD 知道哪些块已经无效GC 就不会搬那些垃圾数据写放大自然降下来。顺手一提别再用机械盘时代的习惯去对 SSD 做碎片整理那只会把数据越搬越碎、磨损越搬越大。第三如果单盘压力太大可以考虑把高写入负载放到第二块盘让系统盘和数据盘分离。Strix Halo 平台通常只能装一到两块 M.2预算允许的话一块盘跑系统另一块专门给模型缓存和 checkpoint谁写废了都不影响系统盘。4.5 我的日写入守护脚本排查完之后我写了个简单的监控脚本每天自动记录并计算增量超过阈值就告警。#!/bin/bash DEV/dev/nvme0n1 LOGFILE/var/log/ssd-daily-writes.log DATA$(smartctl -a $DEV | awk /Data Units Written/{print $7} | sed s/,//g) echo $(date %F) $DATA $LOGFILE PREV$(tail -2 $LOGFILE | head -1 | awk {print $2}) DELTA$((DATA - PREV)) # 单位按 512B 算 DELTA_GB$((DELTA * 512 / 1024 / 1024 / 1024)) echo 今日写入: ${DELTA_GB} GB if [ $DELTA_GB -gt 20 ]; then echo 写入量异常请检查模型日志和 swap | mail -s SSD high write alert adminlocalhost fi脚本配合 systemd timer 每天 23:00 跑一次。注意不同盘 Data Units Written 的单位不一样你用之前先在 shell 里手动跑一次smartctl -a /dev/nvme0n1 | grep Data Units确认它方括号里写的 KB/MB 形式再换算脚本里的乘数。我这边实测单位是 512B所以脚本里乘了 512。之后我又顺手优化了 zram 参数把 OLLAMA 的并发数限了一下当天峰值写入就从 256GiB 掉到了 4GiB再调整了两天稳定在 1.6GiB 左右。这个数字对 SSD 来说属于几乎无感。5. 常见问题速查以及那些容易绕路的坑5.1 一图速查跑模型后写入异常哪些参数先动现象最可能的元凶优先处置启动进程后一次性写入几十 GB模型权重反复被写到缓存/临时目录检查 HF_HOME、OLLAMA_MODELS、TMPDIR长时间稳定 5-20MB/s 写入日志刷屏或 KV spill调日志级别、限制上下文长度、关 debug跑完任务后磁盘空间减少unlinked 临时文件未释放lsof L1查找并重启进程内存看着还剩 20GBswap 还在涨内核回收策略或框架 offload调 swappiness、zram 兜底、限制 batch微调训练一天写几百 GBcheckpoint 存盘太频繁加大 save_steps、checkpoint 进 tmpfsWindows 杀毒软件场景疯狂读盘杀软扫描模型文件目录目录加入排除项或换 Linux 环境这个表是我自己排查时沉淀下来的顺序就是优先级。先查缓存和日志再查 swap最后才考虑是不是盘本身的问题。5.2 SMART 里的其他坑别只看健康度百分比很多朋友只看健康度 99%就松一口气其实不够。健康度是整个寿命模型的估算值厂商留了不少余量短期内不会因为一天 256GiB 立刻变红。你应该重点盯的是Media Wear、NAND Writes和Percentage Used三个值的趋势。还有一个坑是NVMe SSD 的Unsafe Shutdowns会被算进健康度有些盘固件对异常断电非常敏感一次掉电可能让健康度掉几个百分点。跑大模型长时间满载散热不好的笔记本很容易过热触发保护性掉盘这种物理层面的损伤比写入磨损更不可逆。Strix Halo 平台的机器如果压测建议同时盯着sensors里的温度别让 SSD 长时间待在 70℃ 以上。另外那些在 PVE/Proxmox 里直通硬盘跑虚拟机的朋友要注意虚拟机里看到的 SMART 一般是虚拟磁盘控制器的仿真数据除非整盘直通否则不能真实反映物理盘。你要看还是得回到宿主机上跑smartctl -a /dev/...。5.3 关于固态硬盘开卡这类终极手段我的态度热词里反复出现固态硬盘开卡量产工具我不建议你在日常维护中动这些。开卡本质是把主控和闪存重新初始化相当于给固态做一次工厂级重置流程复杂、固件匹配要求高一个参数选错就是整盘变砖。而且开卡之后所有数据全部抹掉SMART 计数也会重置这不仅解决不了写放大问题反而让你失去判断盘真实健康状况的依据。主流厂商的盘都有配套的 Dashboard 或 NVMe 管理工具先看官方工具官方工具查不出来的问题再考虑换盘而不是开卡。你需要的不是救活一块盘而是搞清楚写入为什么异常、怎么避免盘被写废。真要到了开卡那一步大概率是主控程序损坏或颗粒锁死普通用户直接售后换盘更省心。6. 跑了一周后我复盘出的几个反直觉体会6.1 大内存机器更容易让人忽视 swap因为你看不到内存不够Strix Halo 给你 128GB 统一内存确实很爽但也带来一种错觉这么多内存怎么可能不够实际上模型权重、KV Cache、系统页面缓存、驱动映射、其他服务加起来轻松就能吃掉大半。如果看到 SSD 写入飙高第一件事不是怀疑盘坏而是先看free -h和/proc/meminfo里的Swap字段甚至直接用sudo smem看进程真实内存占用。反直觉的地方在于内存还有富余时内核并不会闲着它可能为了未来可能的内存需求把部分匿名页预交换出去。所以光看当前剩余内存没有用要看 swap 的si/so统计量——只要so一直在涨就说明某个进程正在持续把内存页推给 swap。6.2 优化不是一锤子买卖改完参数要跑一轮完整对照我调试过程中犯过一个典型的错误只改了swappiness然后跑 5 分钟就觉得好了。实际上很多写盘行为是周期性或随上下文长度暴露的5 分钟的正态分布样本根本不够。正确做法是记录 SMART 基线改一项参数完整跑一遍昨天同样的任务再对比Data Units Written增量。我最后确定 zram 和上下文长度是核心影响变量就是因为这两个参数都经过了一整天的验证。我个人现在的流程是每周一早上看一次/var/log/ssd-daily-writes.log如果某天超过 20GB就翻一下那天的模型日志和系统日志看是不是有人在半夜偷偷跑了训练任务。前后折腾一周换来的是每天稳定 2GB 以下写入Strix Halo 这块盘终于不用以写满寿命的方式替我打工了。6.3 一个小技巧留给看到文章末尾的你如果你现在正被同样的写入量问题困扰先别急着抄我全部配置先跑这么一行把实时写入速率放在终端里看watch -n 10 smartctl -a /dev/nvme0n1 | grep -E Data Units (Read|Written)每次刷新对比一下两个数字如果 10 秒内Data Units Written跳了两位数那一定是某个进程在连续写。这时候再按我第 3 节的方法抓进程基本一抓一个准。大模型本身不伤盘伤盘的是我们让它跑在错误的内存和缓存策略里把临时数据全砸给了 SSD。把这块理顺了Strix Halo 跑 qwen3.8 flash next 这类模型才能真正是又快又稳。