读盘块大小设错，475 GiB 权重多等 85 秒：16MB 是拐点，NAS 上怎么调都没用
同一份 475.25 GiB 真实生产权重（48 个分片、510,296,708,312 B），在三种介质上各读一遍完整全量：Spark #1 板载 NVMe 128MB 块 12.847 GB/s（39.7 秒）、本机 D: 盘 4478.6 MB/s（114 秒）、千兆 SMB 网络盘 115.5 MB/s（4420 秒），三档相差 112 倍。同一块盘只改每次读多少字节，125.1 秒变 39.7 秒（3.15 倍），16MB 就拿到 89% 的性能——16MB 是性价比拐点。跨架构（aarch64 ext4 / x86_64 NTFS）两套独立脚本跑出同形状曲线（3.15 倍 vs 3.16 倍），说明这是块设备本身的性质，不是某块盘的脾气。
本地部署IO优化块大小O_DIRECT读盘速度llama.cpp模型放哪分片合并NASSSD部署前置这条适用于
- 一块能跑 O_DIRECT（Linux）或 FILE_FLAG_NO_BUFFERING（Windows）的本地盘
- 一个真实模型权重文件，且知道它的确切字节数
- llama.cpp 已装好（只在最后一步用，前三步是纯读盘测量）
版本指纹
llama.cpp b12128 / ext4 + NTFS 双文件系统 / Linux aarch64 + Windows x86_64
具体做法
实测环境：
· Spark #1：aarch64 20 核 / GB10 / 122GB 统一内存 / 3.7T ext4，O_DIRECT
· 本机 5090D：x86_64 24 核 / 96G / D: 盘 INTEL SSDPF2KX019T1M 企业级 NVMe / NTFS，FILE_FLAG_NO_BUFFERING
· 网络盘：千兆 SMB 挂载，1G 链路
测试对象：48 个真实生产分片，合计 510,296,708,312 B = 475.25 GiB，最小分片 970,533,624 B、最大 101,537,926,640 B。
每个块大小都把 48 个分片完整读一遍，逐档核对读满 510,296,567,808 B。【三种介质，同一份权重，读一遍完整全量】
Spark #1 板载 NVMe · 128MB 块：12.847 GB/s，39.6 秒
本机 D: 盘 · 128MB 块：4478.6 MB/s，114 秒（1 分 54 秒）
千兆 SMB 网络盘 · 64MB 块：115.5 MB/s，4420 秒（1 小时 13 分 40 秒）
三档比 ≈ 1 : 2.9 : 112
【块大小阶梯 · Spark #1（ext4 + O_DIRECT，全量 4 档）】
1 MB：125.146 s，4.078 GB/s，相对 128MB 0.32×
4 MB：70.233 s，7.266 GB/s，0.57×
16 MB：44.600 s，11.442 GB/s，0.89×
128 MB：39.721 s，12.847 GB/s，1.00×
→ 1MB → 128MB 是 3.15 倍；1MB 到 4MB 这一档就吃掉一半差距；16MB 已拿到 89%。
【块大小阶梯 · 本机 D: 盘（NTFS，8 档）】
1MB 1416.2 / 2MB 2233.4 / 4MB 3316.2 / 8MB 3956.9 / 16MB 4170.7 / 32MB 4327.2 / 64MB 4425.5 / 128MB 4478.6 MB/s
→ 1MB → 128MB 是 3.16 倍，与 Spark 的 3.15 倍几乎完全一致。
【块大小阶梯 · 千兆 SMB 网络盘（4 档）】
1MB 92.9 / 4MB 106.0 / 16MB 111.7 / 64MB 115.5 MB/s
→ 1MB → 64MB 只有 1.24 倍。瓶颈不在块大小，在 1G 链路的天花板，块调到 1GB 也没用。
【分片要不要合并 · 本机 D: 盘（768MB 同一份数据，16MB 块）】
单文件：0.1924 s，4186.5 MB/s
96 个 8MB 分片：0.2500 s，3220.8 MB/s
单文件快 1.30 倍；open+close 开销 0.0097 ms/文件，96 个合计 0.93 毫秒，可忽略
→ 本机盘上合并只省 30%，且省的不是元数据。花几十分钟做 sha256 校验、拼文件、再校验一遍，不划算。
【分片要不要合并 · 千兆 SMB 网络盘（256MB，1 个文件 vs 64 个 4MB 分片）】
单文件：2.8671 s（中位），快 1.21 倍
open+close 开销：6.7854 ms/文件，64 个合计 0.434 秒，是本地盘的 700 倍
→ 434 个分片则元数据开销 2.9 秒，而且全是串行等待——不是一个一个并发握手，是排队。
【三步顺序为什么不能反】
盘在网络上：块大小调到极限也只有 1.24 倍，参数救不了链路。
盘选对了：块大小才发挥 3.15 倍（16MB 拿 89%）。
分片合并在本机盘是 30% 的收益、在 SMB 上是必须做的动作——同一个操作，两种介质下性质相反。
1MB 以下的块大小（512KB / 256KB / 4KB）未测，别拿其他介质的 4K 数字套到 NVMe 上。本机 C 盘（消费级 NVMe）未参与扫描，所以「消费级 NVMe 是否同样 3 倍」本文无数据。网络盘的硬件规格未知（无 SSH），115.5 MB/s 只能归因到「1G 链路」这一层，说不出是网卡还是交换机。「边下载边加载」的重叠场景未测，本文只测纯读。本机 8 档与网络盘 4 档为单次测量、无误差棒；Spark #1 四档同机同条件横向可比，但该机有生产容器常驻且未记 loadavg，绝对吞吐可能偏保守——所以只拿比值下结论，不拿绝对值跨机比较。