ParaStor: the Storage Layer of Sugon's AI Stack

Written and maintained by Haink's infrastructure team · Compiled from Sugon product documentation, 5 September 2026

In a conventional cluster, storage feeds the accelerators and stays out of the way. In an inference cluster it does something more interesting: it becomes an extension of accelerator memory. ParaStor is Sugon's distributed unified storage platform, and two of its features exist specifically because accelerator memory is finite and context lengths are not.

Published performance

Both headline figures are per device, which is the unit that matters for sizing: a cluster's aggregate is a function of how many you deploy, and 220 GB/s per device is the number to multiply.

For scale against the system it feeds: a scaleX40 superpod holds 5.62 TB of HBM. Filling that from storage at 220 GB/s takes about 26 seconds — which is the right order for model loading and checkpoint restore, and is a useful sanity check when someone proposes a smaller storage tier behind a pod.

XDS: taking the host out of the data path

The conventional path from storage to accelerator goes through the host: NVMe to system memory, system memory to accelerator memory, with the CPU orchestrating and a copy at each hop. At the data rates a superpod consumes, that path spends CPU cycles and system memory bandwidth on work that is pure movement.

XDS moves data directly between accelerator memory and NVMe storage using DMA, bypassing host CPU and system memory. Sugon publishes two figures for the result:

• 30–70% lower CPU utilisation
• 2–3× the peak bandwidth of the conventional path

The CPU figure is the one with the wider practical consequence. A host processor that is not moving data is available for tokenisation, scheduling, request handling and the collective communication that sits on the critical path of distributed inference. In a pod with one host CPU per four accelerators, host cycles are not abundant.

This is not a Sugon invention — the same idea appears elsewhere in the industry under other names, and the architectural argument for it is well established. What is specific here is that it is integrated with the vendor's own accelerator, driver stack and storage platform rather than assembled from three suppliers' implementations of the same idea.

KV cache offload: the feature that changes what fits

This is the one worth understanding properly, because it changes the arithmetic of what a machine can serve.

When a language model generates, it keeps a key/value cache of everything already in the context. That cache grows with context length and with the number of concurrent requests, and it lives in accelerator memory alongside the weights. Past a certain point the cache, not the model, is what fills the memory — and the machine stops accepting new requests or long ones.

ParaStor's KV cache offload extends that cache beyond HBM into a hierarchy: HBM first, then host DRAM, then local SSD, then ParaStor itself. Each tier is slower than the one above it, and the design bet is that cache entries are accessed unevenly enough that a well-managed hierarchy outperforms simply running out of room.

The practical consequence: a pod with a fixed amount of HBM can serve longer contexts or more concurrent requests than its memory alone allows. For a system Sugon positions around inference, that is arguably the most commercially significant thing in the storage layer.

Two honest caveats. Sugon publishes no figures for the throughput or latency penalty at each tier, so the cost of a cache miss into ParaStor is not quantified anywhere we have found. And the benefit depends entirely on access patterns — a workload that touches its whole cache uniformly will not behave like one with a hot working set. Both are proof-of-concept questions.

Against Lustre and GPFS

Anyone running HPC storage today is running one of these, and the comparison is architectural rather than numerical — we do not have measured results for ParaStor against either, and we do not invent them.

The honest summary: Lustre and GPFS are mature, portable and independently supportable, and an organisation that already runs one has a deep well of expertise that does not transfer. ParaStor's argument is integration with the rest of one vendor's stack — which is a real advantage inside that stack and worth nothing outside it.

What is not published

• Latency at any tier, including the KV cache hierarchy — the figure that determines whether offload helps or hurts a given workload
• Media and configuration behind the 220 GB/s and 10 million IOPS figures — all-NVMe, hybrid, what block size, what read/write mix
• Scaling behaviour — whether aggregate bandwidth is linear in device count and to what point
• Resilience details — erasure coding scheme, rebuild times, failure domain sizing
• Price

The first two matter most. A bandwidth figure without a stated block size and access mix is a headline rather than a specification, and this is true of every storage vendor, not only this one.

When ParaStor is not your choice

Where the accelerators are not Sugon's. Most of ParaStor's distinctive value is integration — XDS with the vendor's own driver stack, KV cache tiering with its own inference platform. Against a general-purpose storage platform in a mixed estate, that value largely disappears.

Where an HPC storage estate already exists. Lustre or GPFS expertise is expensive to acquire and does not transfer. Adding a second platform has an operational cost that a bandwidth comparison does not show.

Where independent support matters more than integration. Outside China, the ecosystem, the skill pool and the third-party support options are thin, and that is a procurement question rather than a technical one.

Where it deserves consideration: as the storage layer of a Sugon pod, where XDS and KV cache offload are integrated rather than assembled; and in inference deployments where context length or concurrency is limited by accelerator memory, which is exactly the constraint the KV cache hierarchy exists to relieve.

Frequently asked questions

What is ParaStor?

Sugon's distributed unified storage platform — file, object and block on one system — used as the storage layer of its AI clusters. Published performance is 220 GB/s of bandwidth and 10 million IOPS per device. Two features are specific to accelerator workloads: XDS, a direct data path between accelerator memory and NVMe, and KV cache offload, which extends a model's attention cache beyond accelerator memory.

What is XDS and what does it do?

XDS moves data directly between accelerator memory and NVMe storage by DMA, bypassing the host CPU and system memory that a conventional path goes through. Sugon reports 30–70% lower CPU utilisation and two to three times the peak bandwidth of the conventional path. The CPU saving matters most in pods with one host processor per four accelerators, where host cycles are scarce.

What is KV cache offload?

A language model keeps a key/value cache of its context while generating, and that cache grows with context length and concurrency until it fills accelerator memory. ParaStor extends the cache into a hierarchy — accelerator memory, then host DRAM, then local SSD, then ParaStor — so a system with fixed HBM can serve longer contexts or more concurrent requests than its memory alone allows. Sugon does not publish the latency penalty at each tier, which is what determines whether it helps a given workload.

How does ParaStor compare with Lustre or GPFS?

Architecturally rather than numerically, since no measured comparison is available. Lustre and GPFS are designed around large sequential HPC I/O and are mature, portable and independently supportable. ParaStor is designed around mixed AI I/O with integrated accelerator-direct paths and cache tiering. Its advantage is integration inside one vendor's stack; outside that stack the advantage largely disappears, and the established platforms have decades of tooling and expertise behind them.

What does 220 GB/s per device mean in practice?

It is the per-device figure to multiply by deployment size. For scale: filling the 5.62 TB of accelerator memory in a scaleX40 superpod at 220 GB/s takes roughly 26 seconds, which is the right order for model loading and checkpoint restore. As with any storage headline, the figure should be qualified by block size and read/write mix, which Sugon does not publish.

What has Sugon not published about ParaStor?

Latency at any tier including the KV cache hierarchy, the media and access-pattern configuration behind the headline bandwidth and IOPS figures, scaling behaviour with device count, resilience details such as erasure coding and rebuild times, and price.

Related

• Sugon scaleX40-3G — the pod ParaStor is designed to feed
• Sugon (中科曙光) — the company and the rest of the stack
• Building AI infrastructure without NVIDIA — where storage sits in the full stack
• Sugon scaleFabric — the cluster network alongside it
• AI cluster architecture · GPU server buying guide

Sources

• Sugon — scaleX40 solution manual, 45 pp. (ParaStor 220 GB/s and 10 million IOPS per device, XDS CPU utilisation and bandwidth figures, KV cache offload hierarchy)
• Sugon — scaleX40 product page (pod accelerator memory total, used for the load-time calculation)