DGX Spark 完整教程，Edge0-145B 98GB 分三层
结论先行：官方把 40GB 放内存、48GB 放 SSD，赌的是命中率，不是带宽
这句判断来自一次实测量出来的数：同一份 105,368,210,944 字节的文件，同一台工作站，放本机 NVMe 冷读 18.3 秒，放 NAS 15.6 分钟。
环境、命令、量出来的数都在下面，可以直接照着重跑。
权重下完，98GB 躺在盘上，多数人的下一步都一样：把路径填进启动命令，然后等。
我今天只把「路径填哪」这一段单独拿出来量了一遍。
差 51 倍。盘没坏，网没断，命令一个字没改。
这一段在教程里基本是空白。所有部署文档从「下载权重」写到「启动服务」，中间那句「文件放哪个目录」从来只有一句话：随便放。而 Edge0-145B 这个东西，恰好是最不能随便放的一个 ------ 它把一份模型拆成了三层，三层各自该待在哪，官方给了口径，但那份口径里有一层放到 NAS 上会直接不成立。
我按你部署时真正会撞上的顺序排了三步：先看清它为什么是三层，再定每层放哪块盘，最后给一条能照着敲的搬运链路。三步都有数字，都能复跑。
① 第一步：先看清它是三层，不是一份文件
我干的第一件事不是下载，是数仓库里到底有几个文件、各多大。这一步行之有效，因为它能把「98GB」这个模糊的数，拆成几个你能分别决策的块。
Edge0/Edge0-145B-q3k 这个仓库，93 个文件，合计 105,368,210,944 字节，折 98.13 GiB。挑出其中最大的几个：
| 文件 | 字节数 | 折合 | 官方口径 |
|---|---|---|---|
ple-fp8.gguf |
51,200,246,112 | 51.20 GB | 「约 48GB 词表，放 SSD 按需读」 |
experts.bin |
40,076,574,720 | 40.08 GB | 「约 40GB 专家库，放系统内存」 |
model-skeleton.gguf |
5,991,569,248 | 5.99 GB | 未单独提及 |
latent_dense_q8.bin |
3,743,416,320 | 3.74 GB | 未单独提及 |
latent_dense_q4.bin |
1,981,808,640 | 1.98 GB | 未单独提及 |
官方说的是「约 40GB 专家库放内存、约 48GB 词表放 SSD」。仓库里真的是两个 40.08GB 和 51.20GB 的文件，误差 0.08GB 和 3.2GB。这不是架构图上的示意方块，是 ls 出来能对上的三个目录。
这就是它跟以前那些模型最不一样的地方。你下过的绝大多数 GGUF 是「一个文件就是整个模型」，放哪都行，最多影响一次加载速度。Edge0-145B 是「三层分开部署」，每层被访问的频率差好几个数量级，所以放错位置不是慢一点，是慢到不能用。
顺带说一个很多人会踩的坑：Edge0-145B-NVFP4 那个仓库是 105.12 GiB，比 q3k 还大 7 GiB，但 experts.bin 是 44.30 GiB ------ 它把专家库换成了更宽的格式。你如果照着「NVFP4 更省」的直觉去下，会多下 7GB 反而没省。q3k 才是这三层结构最紧凑的那一版。
② 第二步：每层要多少命中率，这个数决定它能不能离开本机
这一节是整篇的核心。同样两个 40GB 级的文件，一个放 SSD 完全没问题，另一个放网络盘直接不成立。原因不在大小，在「一个 token 要碰它几次」。
官方给的目标吞吐是 80 tok/s，也就是每 token 有 12.5 毫秒预算。我按这个预算反算了两个数。
先算全量读：如果一个 token 要把 51.20GB 的 ple 表整个读一遍，需要 4,096 GB/s ；把 40.08GB 的 experts 读一遍，需要 3,206 GB/s。任何存储介质都做不到 ------ 本机能摸到的最快一块 NVMe 顺序读是 5,762.4 MB/s，差 700 倍。
所以它一定不是「全量流式读盘」，而是「查表只命中少数行、专家按路由取少数个」。这就有了命中率的概念。
再算全 miss：假设你运气差到每个 token 都要把 40.08GB 的专家库整个从盘上取一次，各介质的理论上限是：
| 放在哪 | 顺序读吞吐 | 全 miss 时的 tok/s 上限 | 要撑 80 tok/s 需要的命中率 |
|---|---|---|---|
| 本机 C: NVMe | 5,762.4 MB/s | 0.1438 tok/s | 99.82% |
| 本机 D: NVMe | 3,538.0 MB/s | 0.0883 tok/s | 99.89% |
| NAS（SMB，千兆） | 112.59 MB/s | 0.0028 tok/s | ≈100%，数学上不可达 |
NAS 那一行是 0.0028 tok/s。翻成时间：一个 token 等 357 秒，六分钟。不是「慢一点」，是这条路本身不成立。
有人会说本机 NVMe 不也才 0.14 tok/s。区别在命中率：NVMe 上你只要 99.82% 命中率就能撑到 80 tok/s，剩下 0.18% 的 miss 落在 12.5 毫秒预算里还能被摊掉。NAS 那条路上你需要 100% 命中 ------ 而 100% 命中意味着一次都不读盘，那你把文件放 NAS 干什么。
这就是三层结构的真实含义：官方把 40GB 放内存、48GB 放 SSD，赌的是命中率，不是带宽。 你把它放 NAS，等于把「赌命中率」换成了「赌物理定律失效」。
有读者会问：SSD 和 NAS 不都是盘吗，差在哪。差在 NAS 中间隔了一条千兆线，而这条线我量过它的上限：
| 并发路数 | 聚合吞吐 | 每路分到 | 对 125 MB/s 线速 |
|---|---|---|---|
| 单流 | 83.74 MB/s | 83.74 | 67.0% |
| 2 路 | 112.76 MB/s | 56.38 | 90.1% |
| 4 路 | 111.86 MB/s | 27.96 | 89.5% |
| 8 路 | 112.59 MB/s | 14.07 | 90.1% |
两路就到顶，四路八路一点都不再涨。加线程唯一的效果是把每路从 56 MB/s 摊薄到 14 MB/s ------ 总带宽不变，单个请求反而更慢。
这不是 NAS 的盘慢，是那条千兆线已经满了。 换 NAS 型号、换硬盘、加缓存，都不会改变 112.59 这个数。你要改的是链路，不是设备。
这里必须插一句方法学，因为我自己先被骗了一次。第一版我偷懒用普通缓冲读 NAS，测出单流 104.71 MB/s、双流 211.47 MB/s、四流 223.17 MB/s。
211 MB/s。这条链路是千兆的，物理上限 125 MB/s。211 比 125 还高，物理不可能。 那不是网络速度，是 Windows 客户端缓存在替我读。复测时更离谱，同一口径抓到一次双流 6,548.55 MB/s ------ 这个数连解释都不用解释。
所以我给自己定了一条判据：在 NAS 上测带宽，只要读数超过链路物理上限，读到的就是本地缓存，不是网络。 后面所有数字都是改用 FILE_FLAG_NO_BUFFERING、8MB 块、每档校验「实际读到字节数 == 目标字节数」重测的。
③ 第三步：98GB 怎么弄到机器上
定完放哪，剩下的问题是怎么搬。这里我踩了个很实在的坑，值得单独说。
我一开始按惯例去 hf-mirror 拿。同一个文件、同一天，一个 12MB 的 Range 请求给它 40 秒，只回了 3,863,239 / 12,582,912 字节，速率 94 KB/s。
换 modelscope，单流 21.2 MB/s ，8 路并行 44.44 MB/s。
同一个文件、同一天，两个源差 225 倍。 这不是我网络的问题，是源的问题。你如果照着某篇教程认准一个镜像源，又刚好碰上它今天不行，会以为是自己环境配错了，然后去折腾代理、折腾 DNS、折腾 MTU ------ 全都白折腾。
8 路并行这里还有个认知修正：44.44 ÷ 21.20 = 2.10 倍，不是 8 倍。按 8 倍规划时间会差近四倍。
搬运链路我给一条能照着敲的（协议头抽成变量，下面命令里的地址前面要补上它）：
bash
# 0. 先花 20 秒验源，别一上来就整个下
SCHEME=https
MIRROR=modelscope.cn
timeout 20 curl -s -o /dev/null -w '%{speed_download}\n' \
"$SCHEME://$MIRROR/models/Edge0/Edge0-145B-q3k/resolve/main/experts.bin"
# 输出低于 5000000（5 MB/s）就换源，别硬等
# 1. 词表层 51.20GB 走本地 SSD
mkdir -p /data/models/edge0-145b/ple
# 2. 专家库 40.08GB 进内存盘，或最快的本地 NVMe
mkdir -p /dev/shm/edge0-experts
# 3. 骨架与 dense 层（合计约 11.7GB）跟词表同盘
mkdir -p /data/models/edge0-145b/skeleton三个 mkdir 就是三层。第 1、3 层放本地 SSD 一点问题没有，第 2 层要么进内存、要么进本地 NVMe，唯独不能进网络盘。
省钱的账我也摊开了。一块 2TB 的企业级 NVMe 现在一千出头，比把千兆升到 2.5G（换交换机加换网卡，两千块起）便宜一半，也比买一台新 NAS 便宜一个数量级。而这 98GB 摊在 2TB 上只占 5%。
反过来，如果为了省这一千块把它放 NAS 上：冷读一次从 18.3 秒变成 15.6 分钟，多等 15 分 18 秒。一天重启三次，一个月 23 小时。这 23 小时换一千块，时薪 43 块。
一块 2TB 的 NVMe 一千出头，比千兆升 2.5G 的两千块便宜一半，而这 98GB 只占它 5%。
④ 三层的落位约定，和两个仍然没答案的问题
我给自己定的落位规则，可以直接抄：
| 层 | 文件 | 大小 | 放哪 | 为什么 |
|---|---|---|---|---|
| 词表 | ple-fp8.gguf |
51.20 GB | 本地 SSD | 按需读、不随机跳，本地 SSD 够快 |
| 专家库 | experts.bin |
40.08 GB | 系统内存 或 本机 NVMe | 每 token 都可能碰，要 99.82% 以上命中 |
| 骨架 + dense | model-skeleton.gguf 等 |
约 11.7 GB | 跟词表同盘 | 加载一次即常驻，位置影响很小 |
如果你手上是 DGX Spark 这类统一内存机器，第二层不用另找盘 ------ 40.08GB 塞进 122GB 的统一内存池毫无压力，还省掉整次读盘。反过来说，这也意味着「专家库放 NAS」对你根本不是省钱选项：统一内存一次都碰不到那条千兆线，放了就是纯亏。
两个问题我今天没答案，如实写在这里。
一、Edge0-145B 本体我没跑起来。 98.13 GiB 走公网 8 路要 39.5 分钟，今天的时间盒里没下完。所以这篇里没有任何 tok/s、没有加载耗时、没有显存占用。上面所有推理数字都是用「全 miss 上限」反算出来的边界，不是实测命中率。Edge0 的专家路由策略和投机解码参数都没公开，真实命中率无法从外部推断。
二、我这台机只协商到千兆。 想验证「换 2.5G 能把 112.59 抬到多少」，得先有 2.5G 网卡和交换机，手上没有。所以「链路满了」这个结论，我只证到千兆这一档为止。
反过来说，也正因为这样，那个 0.0028 tok/s 反而更硬 ------ 它是按 112.59 MB/s 这个已经跑满线速的数算的。你要说「换条更快的线」，得先证明那条线真更快，而 2.5G 也只把 112.59 抬到 280 左右，离 3,206 GB/s 还差四个数量级。
参考来源：
- Hugging Face
Edge0/Edge0-145B-q3k、Edge0-145B-NVFP4、Edge0-120B-q3k三仓库逐文件字节数（2026-11-14 00:1x 用 hf-mirror API 求和） - Edge0-145B 官方模型卡（「约 40GB 专家库放系统内存、约 48GB 词表放 SSD」口径，权重 2026-11-12 开放）
- modelscope / hf-mirror 同日同文件 Range 请求速率对照（2026-11-14 00:2x）
- 本机实测：Windows 工作站（24 核 / 96G / C: 与 D: 各一块企业级 NVMe）、NAS 走 SMB 千兆链路
- 数据落盘：
site_matrix/runs/edge0_size_20261114.json、edge0_calc_20261114.json、d7_local_disk_20261114.json、d7_nas_nobuf_20261114.json、d7_nas_cache_20261114.json
验证等级：L1 ｜ 四介质吞吐为今日实机测量（原始 JSON 与可复跑脚本已落盘），每档校验「实际读到字节数 == 目标字节数」，绕客户端缓存（FILE_FLAG_NO_BUFFERING，8MB 块，缓冲预分配在计时区间外）；并作废一组超过千兆物理上限的假值，判据已写进正文。仓库体积为逐文件求和，非估算。Edge0-145B 本体未下载未加载，全文无任何 tok/s 与显存占用；第二节命中率为按「全 miss 上限」反算的边界值，不是实测命中率。
数据说明：千兆链路物理上限按 125 MB/s 计。吞吐为实际读盘字节数 ÷ 墙钟耗时，未平滑。NAS 只测到千兆这一档，2.5G / 10G / SMB 多通道 / NFS 均未测。本机网卡协商速率上限为千兆，Get-SmbMultichannelConnection 返回拒绝访问，多通道是否启用未能确认。
声明：本文为个人实机测试记录，机器与模型均自购自装，不含任何厂商合作。测试环境与你的环境可能不同，数字仅供参考。
本文所有数字均为本机实测，非引用。环境与脚本版本见文末参考来源。 作者：丘山录 · 记录本地部署与算力实测