跑 MiniMax H3 会把 SSD 写坏吗？一次 32GB 内存实测

跑 MiniMax H3 会把 SSD 写坏吗？一次 32GB 内存实测#

最近看到不少说法：本地跑 MiniMax H3 这类视频大模型，只要系统调用了“虚拟内存”，就会把大量数据写进固态硬盘，很快把 SSD 跑坏。

这个担心并非完全没有依据。Windows 页面文件确实会产生磁盘写入，写入量最终也会计入 SSD 的耐用度消耗。问题在于，H3 运行时常见的两种现象经常被混在了一起：一种是 CUDA 锁页内存压力，另一种才是 Windows 把可分页内存写入页面文件。

我用自己的 32GB 内存主机完整跑了一轮 H3，并记录了固态硬盘任务前后的累计写入量。结果是：从 28851GB 变成 28853GB，整盘累计写入只增加约 2GB。

这次测试至少能说明一件事：在我这套配置和这次任务里，没有出现几十GB、上百GB级别的持续写盘。终端里即使频繁出现 pin-pressure fallback，也不能直接等同于“SSD 正在被虚拟内存疯狂写入”。

先把最容易混淆的两个概念分开#

第一种：CUDA 锁页内存压力#

运行 H3 时，终端可能反复打印：

TEXT

ArcTable pin-pressure fallback triggered
skipping active HostBuffer eviction

这里的 Pin Memory 指的是锁页主机内存，也就是被固定在物理内存中的一类内存。CUDA 常用它提高 CPU 与 GPU 之间的数据传输效率。因为页面被锁定，它本身不会被 Windows 换出到磁盘页面文件。

我进一步核对了当前 H3 环境中的这段保护逻辑。它会读取系统可用物理内存，在内存余量不足时触发 fallback：不再进行激进的 HostBuffer 淘汰，并尝试复用已经锁定的内存；无法复用时，则退回普通的非锁页传输。

因此，这条告警真正表达的是：

主机可用内存已经比较紧张；
新的锁页内存申请不适合继续扩张；
数据传输可能退回较慢的路径；
生成通常还能继续，但速度可能下降。

它是一个“内存压力与性能降级”信号，不是 Windows 页面文件的磁盘写入记录。

不过这里也要补一句边界：这条告警本身既不能证明正在写页面文件，也不能证明整个系统绝对没有分页。它只能说明 H3 的锁页内存保护被触发。Windows 是否另外把普通可分页内存写入 pagefile.sys，要看系统的分页计数器和实际磁盘写入。

第二种：Windows 页面文件写入#

Windows 页面文件是位于磁盘上的系统文件。内存压力上升时，系统可以把不常访问、但已经被修改的内存页转移到页面文件，为当前更需要物理内存的任务腾出空间。

这才是真正会增加 SSD 写入量的部分。

还要注意，“用了虚拟内存地址”和“正在把内存写到硬盘”不是同一个概念。现代 Windows 程序本来就在虚拟地址空间里运行；真正需要关心的是分页活动，也就是有多少内存页被写进页面文件。系统也不一定非要等到任务管理器显示内存 100% 才开始整理和换出不活跃页面。

这次实测到底测到了什么#

我的测试配置是：

32GB DDR5 双通道内存；
致态 TiPlus7100 4TB 固态硬盘；
Windows 本地 MiniMax H3 视频生成环境；
用 CrystalDiskInfo 记录整块硬盘任务前后的“主机写入量”。

测试结果：

时间点	主机写入量
运行 H3 前	28851GB
完整生成后	28853GB
差值	约 2GB

minimax-h3-ssd-pagefile-pin-memory-test--Pasted-image-20260904203913

这个结果说明，本轮生成没有出现大规模、持续性的 SSD 写入。如果发生了几十GB甚至上百GB的页面文件换出，整盘累计写入量通常会有更明显的变化。

但“只增加 2GB”仍然是一个整盘总量观察，而不是逐进程审计。操作系统、浏览器、日志、缓存、视频输出等都会在测试期间产生写入。因此更严谨的说法是：这 2GB 包含本轮测试期间全系统的新增写入；从总量上看，没有证据表明发生了大规模 Swap。在没有单独记录页面文件计数器之前，不能把这 2GB 精确归因到某一个文件或进程。

怎样判断机器是否真的在大量使用页面文件#

只看终端告警不够，建议把观察分成三层。

第一层：看任务前后的硬盘累计写入#

打开 CrystalDiskInfo，找到实际承载 Windows 页面文件和 H3 输出目录的硬盘，记录“主机写入量”或设备提供的对应累计写入字段。

完整跑一次任务后再次记录，两次相减，就能得到测试期间整块硬盘新增写入的大致规模。这种方法简单直观，但它统计的是整盘总量，不能区分页面文件、视频输出、缓存和其他程序。

第二层：看 Windows 的提交量和磁盘活动#

在任务管理器“性能—内存”中观察“已提交”数值，同时留意承载页面文件的磁盘是否出现持续写入。

“已提交”接近提交上限，说明系统内存承诺越来越紧；磁盘持续高写入则说明确实有大量数据落盘。但仅凭磁盘活动仍不能断定全部来自页面文件，因为生成文件和缓存也会写盘。

第三层：用性能监视器确认分页#

如果要得到更严格的证据，可以在 Windows 性能监视器里观察：

Memory\Pages Output/sec：每秒为了释放物理内存而写入页面文件的内存页；
Paging File(_Total)\% Usage：页面文件使用比例；
Memory\Committed Bytes 与 Memory\Commit Limit：当前提交量与系统提交上限；
PhysicalDisk(*)\Disk Write Bytes/sec：对应硬盘的实际写入速度。

其中 Pages Output/sec 比单纯看 Pages/sec 更有针对性。后者还包含其他分页行为，数值高并不一定代表内存不足导致的大量换出。

32GB 内存跑 H3，应当怎样理解风险#

结合这次结果，可以把常见情况分成三档：

只有 pin-pressure fallback，整盘写入增量很小。这通常是锁页内存预算吃紧、传输路径降级，主要影响速度，不等于 SSD 正在被大量写入。
内存提交量很高，页面输出计数持续升高，磁盘也持续写入。这才是明显的页面文件压力，长时间反复运行会增加 SSD 写入量。
任务直接内存不足、卡死或崩溃。这已经不只是硬盘寿命问题，而是当前分辨率、时长、并发或缓存策略超过了机器可承受范围。

32GB 内存能否稳定运行，取决于分辨率、帧数、时长、模型装载方式、缓存策略和同时运行的软件。不能把“32GB”本身写成对所有工作流都成立的安全线。

SSD 寿命需要担心到什么程度#

致态官方给 TiPlus7100 4TB 标注的耐用等级是 2400TBW，并采用“五年或最大 TBW，以先到者为准”的有限质保口径。

按十进制粗略换算，2400TBW 约等于 240万GB写入。即使把本次新增的 2GB 全部算作额外消耗，也约占 2400TBW 的 0.00008%。从这个量级看，偶尔一次少量写入不值得恐慌。

真正需要注意的，是页面文件长期、持续、反复地产生几十GB甚至上百GB额外写入，而且这已经成为日常工作流的一部分。那时更值得做的是降低分辨率或时长、减少并发、优化缓存策略，或者增加物理内存，而不是仅仅忍受磁盘持续换页。

另外，TBW 衡量的是写入耐用度。加载模型权重产生的大量读取不会计入 TBW 写入量；但这不代表硬盘完全没有其他老化因素，只是从 SSD 写入寿命这个问题来看，读取和写入应当分开讨论。

我的结论#

这次实测之后，我会把结论写得更准确一些：

所以，看到告警时不用立刻把它理解成“SSD 要报废了”。先看任务是否明显变慢，再看内存提交量和页面输出，最后用硬盘累计写入量做前后对照。把证据分层，才能知道当前真正的瓶颈是在显存、物理内存、锁页内存，还是磁盘页面文件。

CrystalDiskInfo 工具资源#

这次用于查看硬盘健康度和累计写入量的 CrystalDiskInfo 9.9.2，已独立整理为工具资源页：

进入 CrystalDiskInfo 9.9.2 工具资源页

工具版本、网盘领取地址、提取码、实际文件体积和后续更新统一在资源页维护，本文不再直接维护第三方网盘链接。使用时建议在运行 H3 前后分别记录一次“主机写入量”；如果机器有多块硬盘，记得确认 Windows 页面文件到底放在哪一块盘上，否则可能会看错对象。

参考资料#

更新记录#

2026-09-04：首次整理 32GB 内存运行 MiniMax H3 的写入量实测，区分锁页内存告警与 Windows 页面文件，并补充性能计数器判断方法。