# 32GB 内存跑 105GB 模型：第二块 SSD 真能提速吗？ Canonical: https://growthyoung.com/blog/moe-ssd-mirror-reads Author: 策略研究室（个人独立研究） Published: 2026-10-07 Updated: 2026-10-07 复核六次双盘读取实验、原始输出和文件哈希，分清吞吐提升与等待缩短；结合 Qwen、Apple、Sandisk 和 OWC 的公开资料，判断内存、SSD 与读取软件各自解决什么问题。 ---

32GB 内存的 Mac 运行一份约 105GB 的模型文件，听起来像是 SSD 替内存完成了一次升级。真正发生的事情更具体：软件把常用权重留在内存，在需要时读取其他权重。再接一块盘有没有用，取决于这条读取路径。我们复核了一份公开的双盘实验，把六次运行、输出一致性和硬件规格放在一起，看看哪些钱值得花，哪些结论还需要等。

## 一、先弄清楚，模型究竟放在哪里 {#capacity} 讨论本地模型时，一个常见问题是：文件超过电脑内存，为什么还能够输出文字？另一个紧接着出现的问题是：既然硬盘能参与运行，购买更大或更快的 SSD，能不能少买一点内存？ 这篇文章从一场关于双盘读取的社区讨论出发，检查 Slotstream 的公开实验。这里的“复核”指下载公开记录、检查文件哈希、比较六次输出并重算指标。本站没有在同款 Mac 上重新运行模型，没有把他人的电脑和测量写成自己的体验。证据截点为 2026 年 10 月 7 日。 模型文件通常包含大量权重。运行时，计算单元需要访问其中的部分或全部数据，同时还要保存上下文状态、临时计算结果和程序本身。磁盘空间解决文件保存的问题；运行内存容纳正在使用的数据。软件可以安排它们之间的搬运，但搬运有时间成本。 混合专家模型（MoE）给这种安排留下了空间。每一步只激活部分专家网络，其他专家仍然保存在模型里。若常用专家有一定重复性，软件便能把它们留在内存，让暂时用不到的专家继续待在磁盘上。下一步需要一位尚未缓存的专家时，再把对应权重读进来。 这也说明“激活参数少”与“模型文件小”回答的是不同问题。前者描述一步计算参与了多少参数，后者影响下载和存放。切换到新内容后，使用到的专家集合可能发生变化；不能因为某一步只用一小部分，就永久删除其他专家并假定模型能力不变。 Qwen 官方模型卡将 Qwen3.8-Flash-Next 列为 125B 主模型、6B 激活参数，另有 51B 的 n-gram embedding 和 4B MTP；每层有 512 个专家，选择 10 个路由专家和 1 个共享专家。这些是架构口径，不是这台电脑的实时内存占用。[Qwen 模型卡](https://huggingface.co/Qwen/Qwen3.8-Flash-Next) | 看到的数字 | 实际描述的对象 | 容易遗漏的部分 | | --- | --- | --- | | 125B 参数 | 主模型参数规模 | 模型卡另外列出的 n-gram embedding 与 MTP | | 6B 激活参数 | 一步推理的激活规模 | 未激活权重仍需保存，下一步可能被选择 | | 约 105.3GB 校验文件 | 此实验记录的固定文件集合 | 与其他版本、其他量化仓库的下载大小不一定相同 | | 32GB 统一内存 | 作者电脑的标称配置 | 系统、其他应用、工作区和上下文也要占用空间 | | 20.923GB 峰值 footprint | 六次短测中的最大进程物理占用记录 | 不能当作长上下文、多请求或完整系统的峰值 | 前三项分别取自模型卡和作者的文件校验记录；最后一项由六次原始统计复算，GB 使用十进制。作者的机器说明还区分了 Apple 标称容量和规划器使用的十进制容量。[机器与副本记录](https://github.com/spikezz/slotstream/blob/mirror-reads/db/records/machines/mac-mini-m4-32gb.md) 可以做一个简单的容量练习：1250 亿个参数如果每个恰好占 4 bit，净权重相当于 62.5GB。这个乘法没有计算额外模块、量化比例因子、元数据和未使用 4 bit 保存的张量。下载文件大于这个结果并不矛盾；它提醒我们，不该把参数标签乘一个系数就当作完整采购预算。 量化版本也要对上。Pipe Network 当前模型卡写的是 103.8GB，并说明各组权重采用的精度以及 MTP 文件范围；本文实验的校验集合约为 105.3GB。本文保留两个口径，不用差额推断文件“丢失”，也不拿今天仓库主页的容量替换历史实验的固定集合。[量化模型说明](https://huggingface.co/pipenetwork/Qwen3.8-Flash-Next-MLX-4bit) ## 二、双盘读取需要软件参与 {#mirror} 把模型放在外置 SSD 上，最简单的作用是节省内置空间。若软件每次仍然只从这个目录读取，桌上多接一块闲置盘不会让模型更快。程序必须知道第二份数据在哪里，并且真的安排了另一条读取路径。 这次讨论中的实现叫 mirror reads。两块物理盘各放一份相同的 checkpoint，程序根据读取吞吐和排队情况，选择预计更早完成请求的副本。它复制的是数据，让读请求有第二个去处。它没有把内存条的容量相加，也不等同于把前半部权重放 A 盘、后半部权重放 B 盘。[实现与审查状态](https://github.com/carloslfu/slotstream/pull/24)
两个 SSD 保存相同权重副本，读取调度选择一侧，将缺少的专家送入内存缓存，再供计算使用。相同权重副本通过读取调度进入内存缓存；内存中已有权重可直接用于计算。
图 1｜按公开实现绘制的数据路径示意。箭头表示数据流；这张图不包含速度承诺，第二块盘也不会自动增加运行内存。
| 方案 | 数据怎样摆放 | 需要什么条件 | 主要代价 | | --- | --- | --- | --- | | 单盘模型目录 | 一份文件在一块盘 | 引擎能读取该格式 | 容量和性能受这条路径约束 | | 镜像读取 | 两盘各有完整相同副本 | 引擎支持副本选择和并行读取 | 多占一份空间，需要验证副本一致 | | 文件拆分 | 不同文件在不同盘 | 引擎或存储层能按布局访问 | 热点可能集中在一侧，不能照搬镜像结果 | | 增加专家缓存 | 更多已加载专家留在 RAM | 内存余量和缓存策略允许 | 挤占上下文、其他应用和工作区空间 | | 更改量化精度 | 每个权重的表示改变 | 模型格式和引擎支持 | 必须另外检查输出质量 | 对镜像方案，正确性首先是文件问题。只有文件名相同、大小相同，仍然可能装着不同的字节。实验作者记录了两份副本的固定文件校验；PR 也说明启动时的头部与大小检查不能替代完整内容验证。读请求在副本之间切换时，版本混用可能造成很难定位的错误。 日常使用时，两份文件也要有人管理。为了速度保留的镜像，适合按固定版本清单更新；为了恢复误删保留的备份，需要独立的保留和恢复规则。同一台正在运行的机器上有两份相同模型，并不能覆盖项目文件误删、同步覆盖和整机损坏等风险。购买第二块盘之前，先写清楚它承担哪项工作。 ## 三、六次运行，提供了多大的证据 {#experiment} 作者使用一台 Mac mini M4、32GB 统一内存和 macOS 15.7.4。单盘组读外置 SSD；镜像组再使用内置 SSD 上的相同副本。外置设备记录为 2TB WD_BLACK SN8100，装在 OWC Express 1M2 中，通过 Thunderbolt 4 连接。内置盘记录为约 251GB 的 Apple SSD。 测试使用同一个中文提示，共 47 个 prompt token，输出固定 200 个 token。两组均设每层缓存 118 个专家、最大上下文 8192、MTP 开启、GPU keepalive 关闭，并采用固定种子的贪心生成。运行顺序为单盘/镜像、镜像/单盘、单盘/镜像。完整条件在[实验协议](https://github.com/spikezz/slotstream/blob/mirror-reads/db/sources/artifacts/mirror-qualified-20261004/pairs/protocol.json)中。 | 配对与顺序 | 模式 | 生成吞吐，token/s | 生成时间，秒 | 预填充时间，秒 | 请求时间，秒 | | --- | --- | ---: | ---: | ---: | ---: | | 第 1 对，先 | 单盘 | 5.983 | 33.425 | 10.459 | 43.966 | | 第 1 对，后 | 镜像 | 7.059 | 28.332 | 4.870 | 33.238 | | 第 2 对，先 | 镜像 | 7.012 | 28.524 | 4.878 | 33.437 | | 第 2 对，后 | 单盘 | 6.138 | 32.582 | 6.938 | 39.555 | | 第 3 对，先 | 单盘 | 6.132 | 32.618 | 6.930 | 39.584 | | 第 3 对，后 | 镜像 | 7.089 | 28.212 | 4.941 | 33.190 | 数据来自作者发布的六份 stats.json，与 [rows.json](https://github.com/spikezz/slotstream/blob/mirror-reads/db/sources/artifacts/mirror-qualified-20261004/pairs/rows.json)逐项核对。吞吐由 200÷decodeSeconds 重算，时间按字段原义保留；requestSeconds 不包含另列的 load_seconds，不能当作从点击启动到完成任务的全部时间。 我们还下载了六份输出文本，核对各自 SHA256 与作者清单一致；六组 output_ids 和 prompt_ids 也分别完全相同。原始记录的全局 swap-in、swap-out 计数在每次运行前后没有增加。上述检查支持“这六次比较没有更换输出”，不构成独立硬件复现，也不能证明所有任务都没有质量退化。 实际测量代码标记为 f37412f，协议保留了更完整的代码与构建身份。PR 后续有 rebase 和证据整理，因此阅读者需要区分测量时的代码与今天页面的最新提交。截至核对时，该 PR 仍为 Draft；不能把这组结果描述成已经发布、经过维护者正式验收的产品能力。 ## 四、吞吐增加 15.6%，等待缩短多少 {#metrics} 先看最稳妥的计算：每一对里，用镜像吞吐除以单盘吞吐，再减去 1。三对结果分别为 17.98%、14.23%、15.62%，中位数是 15.62%。若先分别求两组吞吐的中位数，再做相除，得到的是 15.13%。两个算法回答的统计问题不同，写成同一个精确数字会混淆口径。 吞吐与耗时也不能直接交换百分比。速度从 1 提高到 1.1562，完成相同数量工作的时间变为约 1÷1.1562。按这三组成对数据计算，生成时间下降的中位数为 13.51%。读者真正等待的是秒数；如果标题只突出较大的那个百分比，实际感受很容易落空。
三组单盘与镜像配对生成速度，镜像均更快，成对提升分别为17.98%、14.23%和15.62%。六次生成速度按配对展示，单盘约6 token每秒，镜像约7 token每秒。
图 2｜本站根据作者六次原始记录计算并绘图。每次固定输出 200 token；三对来自同一台机器、同一条提示，不能当作三个独立硬件样本。
更有用的做法是保留整段等待的各个阶段。预填充处理已有输入，生成逐步产生后续 token，程序还可能加载文件、排队或准备状态。一个处理长资料的任务可能主要等在预填充；一个短问题、长回答的任务，生成阶段可能更突出。平均 token/s 只覆盖其中一段。 此处请求时间的成对下降中位数为 16.15%，而生成时间下降中位数为 13.51%。这不是谁算错了，而是分母包含的工作不同。第一对单盘预填充为 10.459 秒，后两次单盘约 6.93 秒，也提醒我们：有些阶段的波动，明显大于生成阶段的波动。 不要据此反推出每个环节的精确因果贡献。日志中的 decodeIOSeconds 是软件统计的 I/O 时间，预取与计算可能重叠，多个计时范围也可能包含彼此。把它与生成总时间相加，或者将两者相减后统称“纯 GPU 时间”，都需要实现层面的额外证明。本文只在相同字段之间作比较。 ## 五、重新启动进程，没有清空所有缓存 {#cache} 实验每次启动新进程，应用内部缓存重新建立；操作系统文件缓存与 SSD 内部状态没有受控清空。作者明确写出了这个限制。因此，本文称它为固定配置的成对实验，不把它包装成严格冷盘测试。 这个区别影响我们怎样理解第一次等待。模型文件已经读过、代码路径已经执行过、机器此前进行了其他任务，都可能改变后续运行的状态。第一对单盘预填充偏慢，是值得调查的现象；没有同步记录证明之前，我们不能指定某一种缓存就是原因。 交替 AB/BA 顺序有帮助，因为它避免所有单盘永远在前、所有镜像永远在后。但三对样本仍然很少。第一对出现的额外等待不会因为使用中位数就从实验历史中消失；完整表格应当留下它，让读者看见数据分布。 上下文长度也不能偷换。配置上限 8192，并不等于本次真处理了 8192 个 token。实际输入只有 47 个 token。若读者日常把一份长报告、几十轮工具输出和图片一起交给模型，工作区、状态保存与专家访问模式都可能改变。这份记录没有回答那种任务会等待多久。 同样，固定生成 200 个 token 能建立一个小而清楚的对照，却没有证明任务已经完成。六份文本内容一致，意味着比较过程中没有通过缩短或更换回答来取得速度优势；答案是否正确、能否按要求形成三张表格、是否需要继续追问，仍要另作检查。 对工具调用型助手，还应记录失败后的来回。假设一次生成只快了几秒，但助手把同一工具错误重复执行十次，任务时间仍会很长。我们在[本地 AI 升级账本](/blog/usb-c-hub-display-compatibility)中讨论过完整任务成本；这里的新增证据，是把磁盘参与的那一小段单独量出来，放回整个任务看。 ## 六、14,900MB/s 的盘，为什么没有跑出同样的读盘速度 {#hardware} 这台电脑的外置盘型号很容易让人产生期待。Sandisk 对 SN8100 2TB 的公开规格列出最高 14,900MB/s 顺序读取，接口是 PCIe Gen 5 x4。那是厂商定义条件下的产品能力，需要合适的连接环境。装进外置盒后，数据还必须经过盒内桥接、线缆、主机端口和文件系统。[SN8100 产品规格](https://www.sandisk.com/en-ie/products/ssd/internal-ssd/wd-black-sn8100-ssd?sku=WDS200T1XHM-00CMT0) Apple 对 2024 款 Mac mini M4 标注的统一内存带宽是 120GB/s，后部 Thunderbolt 4/USB4 接口最高 40Gb/s，前部 USB-C 为最高 10Gb/s。注意大小写：40Gb/s 的理论字节换算是 5GB/s，尚未扣除协议等开销；它和 120GB/s 的内存规格不是同一条数据通道。[Apple 技术规格](https://support.apple.com/en-au/121555) | 公司及资料口径 | 数字与适用对象 | 与这次实验的关系 | | --- | --- | --- | | Apple，Mac mini 2024 技术规格 | M4 统一内存带宽 120GB/s | 内存通路规格，不能拿来当外置盘速度 | | Apple，同一机型后部接口 | Thunderbolt 4/USB4 最高 40Gb/s | 外置连接存在主机侧边界，实际吞吐更低 | | Sandisk，SN8100 2TB 产品规格 | 顺序读取最高 14,900MB/s，PCIe Gen 5 x4 | 裸盘规格；不能完整穿过更慢的外置连接 | | OWC，Express 1M2 当前产品页 | 最高 3836MB/s，脚注使用 Dell 与指定 OWC SSD 测试 | 厂商另一组合的结果，不是本次 Mac 与 SN8100 的实测 | | 作者另做的文件读取试验 | QD4 中位数：外置 3.434GB/s，内置 2.223GB/s | 另一套受记录的读取协议，不能相加当作模型 token/s | OWC 的数字附有测试组合；它与 2023 年发布时宣传的 3151MB/s 使用不同平台。本文仅把它们视作特定条件下的厂商数据，不从两份宣传页计算同一设备的“升级幅度”。[OWC 产品页与测试脚注](https://www.owc.com/solutions/express-1m2) 作者另做了文件读取试验，用设备计数器检查确实产生了磁盘读取，记录不同队列深度。本文引用其 QD4 汇总，只用于描述那个测试条件。模型推理会改变读取大小、依赖顺序和命中情况，无法把外置与内置两个 GB/s 数字直接相加，预测生成速度。[文件读取协议及汇总](https://github.com/spikezz/slotstream/blob/mirror-reads/db/sources/artifacts/mirror-qualified-20261004/disk/summary.json) 因此，购买判断要沿着实际连接走。先确认模型真的从哪块盘读、连到哪个端口、使用哪条线，再考虑更高档的闪存或控制器。若瓶颈在连接链路，上调裸盘顺序读取规格未必换来相同幅度的收益。这仍然是待测判断；没有相同主机下的配对结果，就不要宣布某个型号一定“浪费性能”或一定值得更换。 ## 七、缓存命中率高，为什么还是读了很多数据 原始统计中的 expertHitRate 约为 80.9%。如果只看百分比，似乎硬盘已经很少参与。但同一记录的 decodeReadBytes 约为 23.5–23.6GB；生成仅 200 个 token，未命中的少数访问也可能搬运不少数据。命中次数的比例与总字节量需要一起看。 根据字段做一个描述性除法，23.6GB÷200 约为每个输出 token 0.118GB。这是该计数器在该任务下的平均值，不是所有 MoE 模型的固定需求，更不是每生成一个 token 就写入这么多闪存。读取与写入对工作负载和耐久度的含义不同。 预取还会让记录更复杂。软件可以在计算当前部分时，猜测接下来要用的专家并提前读取。猜中能缩短等待；没有用上的读取仍占用路径资源。公开统计分别记录 issuedBytes、adoptedBytes 和 wastedBytes。本文不把它们同 decodeReadBytes 简单累加，因为不同计数范围可能重叠。 内存缓存的价值，正是在有机会直接省掉搬运。可是留给专家的空间增加后，上下文和并发也可能需要更多空间；规划器的预计峰值，与某次短输入的实测峰值不能互换。将这六次约 20.9GB 的 footprint 当作“32GB 电脑还可以随意运行其他应用”的保证，会忽略负载变化。 这里的工程选择也有商业含义：同样一块 SSD，在不同缓存与预取实现里可能产生不同任务吞吐。软件更新能改变硬件的边际价值。对用户而言，先保留当前版本与任务的基线，再比较升级，往往比只追逐硬件排行榜更省钱。 ## 八、为什么读盘快一倍，整件事通常不会快一倍 先建立一个明确的假设模型：原任务总时间中，比例 f 是必须等待的存储时间，其他时间不变；将这部分速度提升到原来的 s 倍。新旧总时间比为 (1−f)+f÷s，整体加速比为其倒数。这是串行分解的算术示例，不是对 Slotstream 日志重叠计时的拟合。
假设存储等待占原时间20%、40%或60%，将存储速度翻倍，整体速度分别约为1.11、1.25或1.43倍。假设模型展示只加快存储部分时，整项任务的加速取决于原先有多少时间花在存储等待。
图 3｜本站计算的敏感性示例，非硬件实测。公式为 1÷[(1−f)+f÷s]；假设其他工作、输出质量和重叠关系保持不变。
| 原时间中的存储等待占比 f | 存储速度 2 倍，整体加速 | 存储速度 4 倍，整体加速 | 理想地消除该等待，整体上限 | | --- | ---: | ---: | ---: | | 20% | 1.11 倍 | 1.18 倍 | 1.25 倍 | | 40% | 1.25 倍 | 1.43 倍 | 1.67 倍 | | 60% | 1.43 倍 | 1.82 倍 | 2.50 倍 | 例如 f=40%、s=2，新任务用时为原来的 80%，时间减少 20%，速度则是 1.25 倍。这个练习没有预测某块盘会达到什么速度，它只把预算问题写清楚：如果目标环节占比很小，购买再强的设备也只能影响有限的一段。 实际引擎更复杂。预取可能把读盘藏在计算后面，队列也可能改变别的阶段；缓存扩大以后，原先的 f 本身就会变。于是，同一个理论公式适合帮助我们提出测量问题，却不适合替代测量。不能从一个计时字段除以总时间，未经检查就宣称找到了 f。 ## 九、第二块盘值不值得，放进自己的任务预算 {#budget} 最便宜的实验，通常来自已经拥有的设备。如果内置盘有足够空间、外置盘已经在用，软件又有可用且经过验证的镜像实现，可以先对一个固定任务作配对比较。此时要计算的是占用空间、维护副本和测试时间；不要先为尚未确认的功能购买硬件。 如果准备专门购买第二块 SSD 和外置盒，就需要看完整成本。下面的数字全部是人为设定的预算情境，既不是当前报价，也不是本站观测的收益。假设额外支出 900 元，每天运行 40 次可比任务，每次真正少等 6 秒，工作 22 天，一个月节省 88 分钟。若只有四分之一的等待能转成可利用时间，就剩 22 分钟。 这个比例因人而异。盯着屏幕等待第一次输出的人，可能很在意两秒；后台批量处理、晚上才检查结果的人，未必因此多完成工作。把所有机器节省的秒数都按工时定价，会高估价值。更稳妥的是记录一周：延迟减少后，自己究竟多做了什么，或者少受了什么打断。 | 使用情境 | 优先观察的证据 | 下一步较合理的投入 | | --- | --- | --- | | 小模型已全放进内存，响应正常 | 生成时是否持续读权重 | 先保留基线，额外 SSD 可能主要解决容量 | | 大模型经常等待读取，已有两块盘 | 固定任务配对时间与输出一致性 | 先验证软件支持，再试副本调度 | | 经常处理长报告，首字很慢 | 实际输入长度、预填充、复用效果 | 先检查上下文与复用策略，再定硬件预算 | | 工具助手长时间没有交付 | 工具报错、重试次数、结果是否可用 | 先处理失败环节，记录完整完成时间 | | 准备为尚未合并的功能买盘 | 发布状态、兼容范围、失败回退 | 等稳定支持，或明确接受实验维护成本 | 还有一种更直接的选择：对当前任务使用较小的模型。它需要单独比较输出质量和人工修正量，但不该仅因参数数目较小就被排除。若一种配置更快却总需要重写答案，节省的生成时间可能在复核时全部花回去。我们需要的是可用结果，参数标签只提供部分线索。 内置空间也有机会成本。一份完整模型副本，会与工作文档、缓存和恢复文件争用容量。如果为了维持这点提速，经常需要手工清理文件，日常使用未必划算。即使硬盘早已买好，也应把维护成本记进预算，不能因为没有新订单就把第二个目录当成免费。 ## 十、产业中真正值得跟踪的变化 这份小实验提示了一个采购关系：软件把权重读取纳入推理过程后，存储设备能影响响应时间的场景扩大了。但影响有多大，取决于模型稀疏性、缓存、连接链路和任务，不适合直接写成所有消费 SSD 都将迎来固定比例的需求增长。 对芯片与整机厂商，内存容量和带宽仍然影响能保留多少工作数据。对 SSD 与外置盒厂商，端口协商、持续读取和延迟稳定性会成为更有用的展示项目。对引擎开发者，同一套模型文件在不同预算下如何安排读取，是可以通过软件改善的部分。这些是根据数据路径作出的分析，本文没有估算任何公司的收入增量。 评价产品时也可以换一组问题。与其只问最高顺序读取有多快，不如要求测试报告说明：模型版本是什么、输入多长、专家缓存多少、第一次和重复运行各等多久、输出有没有变化。这些条件把厂商规格和用户结果连起来，也更容易发现一个提升究竟来自新硬件还是新软件。 本站此前的[AI 存储需求与购买决策](/blog/portable-ssd-interface-capacity-workflow)讨论供应商财报和价格传导。本篇关注单个工作负载里的读取路径。两个层次需要各自的证据：一次模型提速不能替代市场需求统计，一份行业收入增长也不能证明你的外置盘应当升级。 ## 十一、怎样复测，什么结果会改变判断 {#verification} 先选择自己确实要完成的任务，再固定比较条件。保存输入、模型文件版本、量化、引擎版本和配置；若输出被截断，要明确标记。提前写下要比较的指标，避免测完后只挑最漂亮的一项。 一个起步方案是保持同一机器与任务，交替测试单盘和镜像，保留每次运行的全部结果。既记录请求计时，也记录从启动到可用输出的时间，检查内存压力和系统 swap。重复次数要服务于看清波动；三对只能提供有限线索，不能替所有设备作结论。 对首次与重复任务分开记录。没有控制操作系统和设备缓存时，就如实标为“缓存未受控”，不用“冷启动”替代细节。不要通过反复筛掉慢记录来得到漂亮平均值。若发生后台任务干扰，写下原因与原始结果，按照事先确定的规则决定是否需要另一轮完整比较。 正确性检查也分层。文件哈希核对版本，token ID 或文本哈希核对这次输出有没有变化；实际业务任务还要检查内容是否正确、工具动作是否成功。三者任何一项通过，都不自动覆盖其他两项。自动化生成了相同的错误答案，同样能够拥有相同的哈希。 如果在相同配置下多次出现结果不一致、额外副本无法通过校验、收益在重复实验中消失，或者完整任务没有变快，就应收回“这项升级值得”的判断。如果长会话内存压力明显上升，也需要重新选择缓存预算；短测没有 swap 不能保证整个下午都不会发生。 这次复核留下的结论很具体：在作者公开的单台 M4、固定短提示、固定输出与手动配置下，双副本读取的三对生成吞吐均有提高；成对中位提升约 15.6%。我们能核对这份记录的内部一致性，还不能把它变成所有 Mac、所有 MoE 或所有 SSD 的性能承诺。准备花钱的人，最有价值的下一步，是保留自己的任务基线，让额外的设备证明它节省了什么。 ## 数据与计算说明 本文使用 AI 辅助整理资料、计算与文字编辑。实验来自 Slotstream 贡献者的公开记录；本站工作为文件一致性检查、公式复算、原创图表和分析，没有独立运行这些硬件测试。 原始材料包括[测量记录](https://github.com/spikezz/slotstream/blob/mirror-reads/db/sources/runs/2026/10/2026-10-04-mirror-current-baseline-paired.md)、[校验清单](https://github.com/spikezz/slotstream/blob/mirror-reads/db/sources/artifacts/mirror-qualified-20261004/SHA256SUMS)、[逐次数据](https://github.com/spikezz/slotstream/blob/mirror-reads/db/sources/artifacts/mirror-qualified-20261004/pairs/rows.json)及各轮 stats.json、stdout.txt。取数时 rows.json 的 SHA256 为 `5e4b82d997a23db6f2d6e21b4dcb805a308b1a88043d56a61234ffe1b0eab928`。来源分支可能继续更新，复算时应先核对版本。 表格显示值按列取小数，百分比使用未舍入值计算。数据字节采用十进制 GB；厂商的标称容量和带宽按原定义列示。敏感性图及预算情境为假设计算，未混入实测表格。本文没有商品返佣链接，也没有根据这组数据给任何 SSD 排购买名次。 需要自己计算时，可以下载[本站整理的六次运行数据 CSV](/static/data/moe-mirror-read-audit.csv)。文件保留原字段、未舍入值和来源数据哈希；生成吞吐一列由固定 200 token 除以生成时间得到。