# NFS 加载大模型太慢？昇腾 910B 平台实测对比

> 在华为昇腾 910B × 8 的平台上，把模型存储从 NFS 换成 FX100 全闪阵列后，DeepSeek-32B 与 70B 的服务加载时间实测对比，以及这组数字的适用范围。

网页地址: https://vuke.top/insights/model-loading-nfs-bottleneck · 更新于 2026 年 11 月 12 日

发布于: 2026-11-12

**问题**: 大模型放在 NFS 上加载很慢，换成全闪存储能快多少？

**结论**: 在华为昇腾 910B × 8 的平台上，把模型存储从 NFS 换成 FX100 后，DeepSeek-32B 的服务加载时间从 691 s 降到 112 s（6.2×），DeepSeek-70B 从 1399 s 降到 150 s（9.3×） [R9](https://vuke.top/evidence/R9)。

## 为什么 NFS 会成为瓶颈

加载一个大模型，本质上是把几十到几百 GB 的权重文件顺序读进内存和显存。读得多快，取决于存储能给多少吞吐。

很多存量集群用 NFS 存放模型，优点是部署简单、所有节点都能访问。但它的吞吐受限于文件服务器和网络路径，多个节点同时加载时还会相互争抢。卡越多、模型越大，这个瓶颈越明显。

## 昇腾 910B 平台的实测结果

测试平台是华为 Atlas 910B × 8（Kunpeng-920），对照基线是 NFS，被测设备是 FX100。

- DeepSeek-32B 服务加载：昇腾 910B 平台上 691 s → 112 s，6.2× [R9](https://vuke.top/evidence/R9)。
- DeepSeek-70B 服务加载：昇腾 910B 平台上 1399 s → 150 s，9.3× [R9](https://vuke.top/evidence/R9)。

## 和 AMD MI308X 上的数据是什么关系

没有换算关系。上面的数字出自昇腾 910B 平台、对照的是 NFS；MI308X 平台上的加载测试对照的是另一个基线，结论是 8 张卡同时冷读模型时整体墙钟时间快 16%、单个模型加载快 30% [R1](https://vuke.top/evidence/R1)。

两组数字的平台和对照基线都不同，不能相加，也不能用一组去推算另一组。能确定的只有方向：模型加载是吃存储吞吐的操作，换更快的存储就会更快。

## 加载快了有什么用

最直接的是模型切换。多模型共用一批卡时，每次切换都要等加载；MI308X 平台按实测加载时间建模的结果是，每小时切换 20 次时算力有效利用率从 46.7% 提高到 62.8% [R1](https://vuke.top/evidence/R1)。

其次是恢复时间。服务重启、节点故障切换、弹性扩容，都要先把模型加载完才能接流量。加载从十几、二十几分钟缩到两三分钟，对可用性的影响是实在的。

## 相关问题

### 这组数字适用于其他国产算力卡吗？

不能直接套用。R9 只在昇腾 910B 平台上测过 [R9](https://vuke.top/evidence/R9)。其他平台需要单独实测，我们也会单独出报告，不同平台的数字不混用。

## 相关实测报告

- [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） (AMD Instinct MI308X × 8 · ROCm 7.2)
- [R9](https://vuke.top/evidence/R9) · FX100 与华为昇腾 910B 模型推理与训练性能测试（对照 NFS 基线） (华为 Atlas 910B × 8（Kunpeng-920）)

## 外部参考资料

- [NVM Express Specifications](https://nvmexpress.org/specifications/) · NVM Express, Inc.. NVMe 与 NVMe over Fabrics 的官方规范
- [RFC 5040: A Remote Direct Memory Access Protocol Specification](https://datatracker.ietf.org/doc/html/rfc5040) · IETF. RDMA 协议的规范定义