Edge0-145B 的 98GB 分三层放：专家库进网络盘，一个 token 要等 6 分钟
Edge0-145B 的 98.13 GiB 不是一份文件，是三层：词表 ple-fp8.gguf 51.20 GB、专家库 experts.bin 40.08 GB、骨架 model-skeleton.gguf 5.99 GB（连同两个 dense 层约 11.7 GB）。官方口径「40GB 专家库放内存、48GB 词表放 SSD」不是架构图上的示意，仓库里真有两个 40.08GB 和 51.20GB 的文件。三层被访问的频率差几个数量级，所以放错位置不是慢一点：专家库放千兆 SMB 网络盘，全 miss 情况下上限 0.0028 tok/s——一个 token 等 357 秒。同样一份 105.37GB，本机 NVMe 冷读 18.3 秒，网络盘 15.6 分钟，差 51 倍。
本地部署模型放哪IO优化MoE三层存储命中率带宽NASSSD部署前置大模型这条适用于
- 拿到目标模型的仓库文件清单与逐文件字节数（镜像站 API 即可）
- 一块本地 SSD 或 NVMe，以及一台能测顺序读的工具
- 知道自家网络盘的链路速率（不知道就先按 1Gbps 上限 125 MB/s 假设）
版本指纹
Edge0-145B-q3k / 镜像站 API 逐文件字节 / 2026-11-14 实测
具体做法
实测环境：
· 本机 5090D 工作站：x86_64 24 核 / 96G / C: 与 D: 各一块企业级 NVMe / NTFS，FILE_FLAG_NO_BUFFERING
· 网络盘：千兆 SMB 挂载（1G 链路，物理上限 125 MB/s）
测试方法：8MB 块、缓冲区在计时区间外预分配、每档校验「实际读到字节数 == 目标字节数」，不等整档作废。【Edge0-145B 仓库三层（逐文件字节，镜像站 API 求和）】
Edge0-145B-q3k：93 个文件 / 105,368,210,944 B = 98.13 GiB
ple-fp8.gguf 51,200,246,112 B 51.20 GB ← 官方「约 48GB 词表放 SSD」
experts.bin 40,076,574,720 B 40.08 GB ← 官方「约 40GB 专家库放内存」
model-skeleton.gguf 5,991,569,248 B 5.99 GB
latent_dense_q8.bin 3,743,416,320 B 3.74 GB
latent_dense_q4.bin 1,981,808,640 B 1.98 GB
Edge0-145B-NVFP4：45 个文件 / 112,871,024,504 B = 105.12 GiB，experts.bin 44.30 GiB ——
比 q3k 大 7 GiB 且专家库更宽，下它不会更省，q3k 才是三层结构最紧凑的一版。
Edge0-120B-q3k：92 个文件 / 92,281,883,361 B = 85.94 GiB。【同一份 105.37GB，四种来源读一遍】
本机 C: NVMe 5,762.4 MB/s 18.3 秒
本机 D: NVMe 3,538.0 MB/s 29.8 秒
千兆 SMB 网络盘 112.59 MB/s 15.6 分钟（935.9 秒）
公网单流 21.2 MB/s 82.84 分钟
公网 8 路并行 44.44 MB/s 39.52 分钟
→ 最快与最慢差 51 倍。盘没坏、网没断、命令一个字没改，差的是「文件放哪」。
【命中率反算（80 tok/s = 每 token 12.5 毫秒预算）】
全量读需要多少带宽（物理上不可能的量级）：
ple 表 51,200 MB × 80 tok/s = 4,096 GB/s
experts 40,077 MB × 80 tok/s = 3,206 GB/s
→ 本机能摸到最快的 NVMe 是 5.76 GB/s，差 700 倍。所以它必然不是全量流式读，是查表命中。全 miss 时的 tok/s 上限，以及撑到 80 tok/s 所需的命中率：
本机 C: NVMe 0.1438 tok/s 需 99.82%
本机 D: NVMe 0.0883 tok/s 需 99.89%
千兆 SMB 网络盘 0.0028 tok/s 需 ≈100%（数学上不可达）
→ 网络盘那行翻成时间：一个 token 等 357 秒，六分钟。不是「慢一点」，是不成立。【千兆网络盘的并发上限（NO_BUFFERING，8MB 块）】
单流 83.74 MB/s per-stream 83.74 占 125 MB/s 线速 67.0%
2 路 112.76 MB/s per-stream 56.38 90.1%
4 路 111.86 MB/s per-stream 27.96 89.5%
8 路 112.59 MB/s per-stream 14.07 90.1%
→ 两路到顶。加线程唯一的效果是把每路摊薄，总带宽一点不涨。不是盘慢，是那条线满了。
【作废的假值（方法学，这次最值得记的一条）】
普通缓冲读同一块网络盘：单流 104.71 / 双流 211.47 / 四流 223.17 MB/s
复测又抓到一次：双流 6,548.55 MB/s（per-stream 3,274）
→ 千兆链路物理上限 125 MB/s，211 与 6,548 都超了，物理不可能。读到的是 Windows 客户端缓存，不是网络。
判据只有一条：拿实测值对链路物理上限做 sanity check，超了整组作废。
【三层落位约定】
词表 ple-fp8.gguf（51.20GB） → 本地 SSD（按需读、不随机跳）
专家库 experts.bin（40.08GB） → 系统内存，或最快的本地 NVMe
骨架 + dense（约 11.7GB） → 跟词表同盘（加载一次即常驻）
统一内存机器（如 DGX Spark 122GB）第二层不用另找盘，40.08GB 塞进内存池毫无压力；
也正因如此，「专家库放网络盘」对这类机器不是省钱选项——它一次都碰不到那条千兆线。Edge0-145B 本体未下载、未加载、未推理，零 tok/s、无加载耗时、无显存占用——本文所有 tok/s 都是按「全 miss 上限」反算的边界值，不是实测命中率。Edge0 的专家路由策略与投机解码参数未公开，真实命中率无法从外部推断。网络盘只测到千兆这一档；2.5G / 10G / SMB 多通道 / NFS 均未测，本机网卡协商速率上限为千兆、SMB 多通道状态因权限不足未能确认。网络盘硬件规格未知（无 SSH），112.59 MB/s 只能归因到「千兆链路已满」这一层，说不出是网卡还是交换机。四介质吞吐为单次测量、无误差棒；「边下载边加载」的重叠场景未测，本文只测纯读。公网速率为同日单次窗口观测，受当时源端状态影响，不代表长期均值。