An AI training framework knows that 64 accelerators are saving one checkpoint. A conventional cloud storage service sees 64 clients writing files. That semantic gap is the central problem in AITURBO, a FAST 2026 system from Shanghai Jiao Tong University and Huawei Cloud[1]. The paper asks what storage can optimize once the application identifies an I/O group instead of presenting every transfer as an unrelated request.

The answer is broader than faster checkpointing. AITURBO uses host DRAM as a staging tier, the accelerator compute fabric as an additional data path, and a job controller to derive read and write plans. Across the evaluated training configurations, checkpoint writes are 3.9× to 58.8× faster than Huawei Cloud’s general-purpose SFSTURBO backend. AITURBO also outperforms the paper’s implementation of Gemini by up to 5.9× when duplicated checkpoint state can be removed. Those maxima are real, but they describe different models and parallel configurations. The architectural contribution is the interface that makes such plans possible without moving thousands of lines of storage logic into each framework.

The evaluated cloud separates compute servers from storage servers. A compute node combines eight accelerators with a 192-core CPU complex; its host-memory capacity is 1.5 TB. Accelerators communicate through a 200 Gb/s-per-XPU compute fabric, while all eight devices on a node share one 100 Gb/s storage-facing NIC. The backend can be provisioned with up to 30 GB/s of storage bandwidth. Buying more backend bandwidth does not remove the per-node frontend limit, and Huawei reports that raising one storage tier from 1.6 GB/s to 80 GB/s increases the per-GB price by 16×.

This topology creates two optimization opportunities. First, training jobs often leave host DRAM and parts of the compute fabric underused during storage operations. Second, many accelerators write or read identical state. Data-parallel ranks may hold the same parameters, several inference replicas may load the same model, and concurrent agent requests may need the same KV-cache prefix. A file API hides both the available path and the duplication pattern.

AITURBO therefore treats observable storage bandwidth as the minimum of the frontend and backend paths, then adds a third route. Data can enter host DRAM through the storage fabric and spread to accelerators through the compute fabric. On writes, the buffer can acknowledge a checkpoint before the remote flush finishes. This choice trades immediate remote durability for latency. It is acceptable only when replication or an earlier periodic checkpoint can recover the data.

Conceptual physical view of one AITURBO compute node. Eight XPUs share a 100 Gb/s storage-facing NIC, while a 192-core host with 1.5 TB of DRAM stages one copy and the 200 Gb/s-per-XPU compute fabric distributes or collects group data. The server rendering is a generic material plate, not a disclosed product photograph or board layout; all topology, labels, and measurements were drawn deterministically from the paper’s reported configuration. Original figure created for this article.

AITURBO turns an opaque collection of file calls into one planned group operation. a, Conventional storage receives duplicate reads and writes through a shared storage NIC and cannot infer which accelerators belong to the same job. b, The grouped I/O API exposes participants and operation intent to a job controller. c, The controller removes duplicate chunks, stages one copy in host DRAM, and uses the compute fabric for broadcast or balanced flushing. Original figure created for this article.

Group semantics move optimization into storage

Each grouped call identifies the participating clients as well as the file operation. Before a write, clients compute BLAKE3 checksums at file or 4 MB chunk granularity and send metadata to the job controller. The controller detects duplicate content, selects which node should stage each unique chunk, and balances the eventual flush across available storage paths. It solves the full placement problem with storage-oriented heuristics and caches the resulting plan for repeated checkpoints.

Reads reverse the path. Storage fetches one copy into host DRAM and broadcasts it through the compute fabric to the requesting accelerators. This is useful when a model must scale from one replica to many. With a cached copy, AITURBO loads a 135 GB Qwen-72B checkpoint onto 64 XPUs in 2.25 seconds. The SFSTURBO-based ServerlessLLM comparison needs 1,384 seconds because each instance remains dependent on the slower storage path. However, a cold read is still limited by purchased storage bandwidth: all evaluated systems need 173 seconds to read the same checkpoint onto eight XPUs when only 1 GB/s is provisioned.

That cold-read result defines the system honestly. AITURBO does not manufacture backend bandwidth. It converts duplicated transfers and unused local resources into effective bandwidth after the first copy arrives. An operator should therefore measure the share of I/O that is grouped, duplicated, and reusable before applying the headline improvement to a new workload.

The checkpoint maximum is not the application saving

The training evaluation covers 1.5B, 13B, and 38B models, each with and without ZeRO configurations, on clusters of up to 64 Ascend 910B NPUs or NVIDIA A800 GPUs. Checkpoint time falls most when in-memory staging, duplication, and a balanced plan all apply. Deduplication alone reduces checkpoint time by 4.3% to 47.2% in data-parallel cases, while the optimized write plan adds as much as a 76% reduction where duplicated files allow bandwidth to be redistributed.

The paper also computes wasted XPU time using a model with one XPU failure per hour and an optimal checkpoint interval. Under that broader denominator, AITURBO saves up to 6% of XPU hours against SFSTURBO, not 58.8×. Faster checkpoints permit more frequent protection, but checkpoint time is only one component of a long training run. This smaller percentage is the more useful planning number because it connects storage latency to paid accelerator time.

Inference shows a different operating point. The authors replay a 30-minute Qwen-Bailian KV-cache trace on Qwen-14B with eight XPUs. Replacing Mooncake’s storage fallback with AITURBO lowers mean time to first token from 0.85 to 0.65 seconds, a 23% reduction. The integration does not use grouped calls because synchronizing live inference instances is difficult. Even without the full API, the compute-fabric path raises effective storage throughput when evicted blocks must return.

The reported gains use different denominators. Checkpoint completion improves by 3.9× to 58.8× against SFSTURBO across six training configurations, Gemini is exceeded by up to 5.9× where duplication can be exploited, modeled wasted XPU time falls by up to 6%, and mean TTFT in the 30-minute Qwen-Bailian replay falls by 23%. These values should not be multiplied or treated as one benchmark. Original figure created for this article.

The API reduces framework work, but not coordination to zero

Megatron’s evaluated checkpoint implementation contains 2,228 lines devoted to coordination and file-system optimization. Integrating AITURBO requires another 286 lines while moving the planning responsibility into storage. Mooncake needs 44 changed lines for the evaluated fallback path. This reduction matters for a cloud provider because one storage implementation can support multiple frameworks and parallel layouts.

The group controller still adds a barrier and metadata exchange. At 64 XPUs, the measured coordination overhead reaches 45 ms, small beside the multi-second bulk I/O in this evaluation. Small operations may see no benefit. The system also relies on the compute fabric’s existing quality-of-service classes and assigns AITURBO traffic the lowest priority. More complex isolation, including jobs sharing one XPU, remains future work. A deployment that already saturates the compute fabric during checkpointing could shift rather than remove the bottleneck.

The procurement question changes from bandwidth to intent

AITURBO suggests a storage requirement that conventional throughput specifications omit. Operators should ask whether the service accepts a collective operation, whether it can identify duplicated state without framework-specific code, where acknowledgments become durable, and how storage traffic is isolated from training communication. Peak GB/s answers none of those questions.

The design is strongest for large, repeated, group-shaped transfers. It is weaker for small I/O, unique data, continuously saturated compute fabrics, or applications that require every acknowledgment to represent remote persistence. Those conditions should be profiled before buying a faster storage tier. When the workload does fit, the system shows why an API can recover more accelerator time than another storage server: the application already knows which bytes belong together, and the infrastructure finally has a way to use that knowledge.

Source and attribution

This article is an editorial summary prepared by Silicon & Systems. It restates the cited paper’s mechanisms, evaluation conditions, and limitations in our own words. No sentences, tables, or figures from the paper are reproduced; all three figures and the card image were created for this article from reported facts. Copyright (c) 2026 the authors. The paper is publicly available through the USENIX FAST 2026 page.