# Slow Model Loading From NFS: Ascend 910B Results

> On Huawei Ascend 910B × 8, moving model storage from NFS to an FX100 all-flash array: measured serving load times for DeepSeek-32B and 70B, and where they apply.

URL: https://vuke.top/en/insights/model-loading-nfs-bottleneck · Updated November 12, 2026

Published: 2026-11-12

**Question**: Loading large models from NFS is slow. How much faster is all-flash storage?

**Short answer**: On a Huawei Ascend 910B × 8 platform, moving model storage from NFS to FX100 cuts the serving load time of DeepSeek-32B from 691 s to 112 s (6.2×) and of DeepSeek-70B from 1399 s to 150 s (9.3×) [R9](https://vuke.top/en/evidence/R9).

## Why NFS becomes the bottleneck

Loading a large model is essentially reading tens to hundreds of gigabytes of weight files sequentially into RAM and GPU memory. How fast that goes depends on the throughput the storage can provide.

Many existing clusters keep models on NFS because it is simple to deploy and every node can reach it. But its throughput is capped by the file server and the network path, and several nodes loading at once compete with each other. The more accelerators and the larger the models, the more visible this bottleneck becomes.

## Measured results on Ascend 910B

The test platform is Huawei Atlas 910B × 8 (Kunpeng-920), the baseline is NFS and the device under test is FX100.

- DeepSeek-32B serving load on Ascend 910B: 691 s → 112 s, 6.2× [R9](https://vuke.top/en/evidence/R9).
- DeepSeek-70B serving load on Ascend 910B: 1399 s → 150 s, 9.3× [R9](https://vuke.top/en/evidence/R9).

## How this relates to the AMD MI308X data

There is no conversion between them. The figures above come from the Ascend 910B platform with NFS as the baseline; the loading test on MI308X uses a different baseline and concludes that with eight GPUs cold-reading models at once, wall-clock time is 16% shorter overall and each model loads 30% faster [R1](https://vuke.top/en/evidence/R1).

The two sets differ in both platform and baseline, so they cannot be added together and one cannot be used to estimate the other. Only the direction is certain: model loading is bound by storage throughput, and faster storage makes it faster.

## What faster loading is good for

The most direct effect is on model switching. When many models share a pool of accelerators, every switch waits for a load; on the MI308X platform, modeling from measured load times shows effective compute utilization rising from 46.7% to 62.8% at 20 switches per hour [R1](https://vuke.top/en/evidence/R1).

Next is recovery time. Service restarts, node failover and elastic scale-out all have to finish loading the model before taking traffic. Cutting a load from ten or twenty-odd minutes to two or three makes a real difference to availability.

## Related questions

### Do these figures apply to other domestic accelerators?

Not directly. R9 was measured on the Ascend 910B platform only [R9](https://vuke.top/en/evidence/R9). Other platforms need their own measurements and get their own reports; figures from different platforms are not mixed.

## Related test reports

- [R1](https://vuke.top/en/evidence/R1) · FX100 Comprehensive LLM Inference and Training Benchmark (8 × AMD MI308X) (8 × AMD Instinct MI308X · ROCm 7.2)
- [R9](https://vuke.top/en/evidence/R9) · FX100 on Huawei Ascend 910B: Inference and Training Benchmark (vs. NFS Baseline) (8 × Huawei Atlas 910B (Kunpeng-920))

## External references

- [NVM Express Specifications](https://nvmexpress.org/specifications/) · NVM Express, Inc.. The official specifications of NVMe and NVMe over Fabrics
- [RFC 5040: A Remote Direct Memory Access Protocol Specification](https://datatracker.ietf.org/doc/html/rfc5040) · IETF. The normative definition of the RDMA protocol