The storage-focused outlet Blocks & Files reported on November 4, 2026 that the storage capacity of xAI's AI computing infrastructure, "Colossus 2," could exceed 5.2EB (exabytes). However, this is not a newly published equipment specification. It is an estimate based on the initial storage capacity and the year-end target for GPU expansion. AI training requires more than the ability to store large volumes of data: the system must also feed the necessary data to GPUs quickly and efficiently save the state of training in progress. If storage reads and writes are slow, GPUs spend time waiting for data and cannot make full use of their computing power. To evaluate Colossus's expansion, total storage capacity and the actual I/O performance that supports training need to be considered separately.
The 5.2EB-plus figure is an estimate based on GPU counts
The estimate by Blocks & Files reporter Chris Mellor takes as its baseline roughly 230,000 GPUs and more than 1EB of storage in the initial deployment. It assumes that if the GPU count grows to the year-end target of about 1.2 million, storage capacity will increase in the same proportion. The calculation is "1.2 million ÷ 230,000 × 1EB ≒ 5.217EB," and because the baseline capacity exceeds 1EB, the estimate is given as more than 5.2EB. Mellor himself notes that the figure is a very rough approximation.
What matters is that the GPU growth rate was simply applied to storage capacity; it was not calculated by adding up the amount of data actually stored. For example, when many GPUs share the same training data, the amount of unique data does not necessarily grow at the same rate as the GPU count. Required capacity also varies with how many generations of in-progress training state are kept and how much redundancy is built in to guard against failures. These conditions cannot be determined from the GPU count alone.
The definition of storage capacity also requires care. It is unclear whether the 5.2EB-plus figure refers to the total raw capacity of storage media, usable capacity after subtracting redundancy overhead, or effective capacity including the benefits of data reduction. It therefore cannot be treated as the total SSD capacity purchased or the capacity of equipment already in operation. The figure of about 1.2 million GPUs is likewise a year-end expansion target, not the number already installed.
DDN and VAST Data adoption in early Colossus is confirmed
On November 18, 2024, DDN announced that it would pair its storage product "EXAScaler" and its data platform "Infinia" with Colossus, which at that stage had 100,000 Hopper GPUs. This announcement confirms that DDN products were adopted in at least the early Colossus.
As for VAST Data, a public statement by Renen Hallak, shared by co-founder Alon Horev, explains that the VAST Data Platform supports Colossus's data processing and model training. However, the exact date of the statement cannot be determined from the post display that is visible.
These announcements and statements support the fact that DDN and VAST Data technologies were adopted in Colossus. But it remains unclear which products are deployed in which facilities and in what quantities as of 2026, how the two companies divide the processing, or in what proportions they supply storage capacity. The early adoption record for Colossus cannot simply be applied to the equipment configuration of Colossus 2.
Three kinds of waiting that keep GPUs from working
In AI model training, it is necessary not only to load training data but also to periodically save the state of training that has progressed partway. This process is called "checkpointing," and it is used to resume training from the saved point when a failure occurs. The official PyTorch documentation presents an example that saves not only the model parameters but also the state of the optimizer that updates them. In other words, it is not enough to reserve capacity for the final trained model.
When evaluating AI storage, in addition to storage capacity, you need to check the loading of training data, the writing of checkpoints, and recovery after failures. The table below organizes the roles required of storage in AI training, based on NVIDIA's certified storage technical documentation, a technical explanation of traffic during saving and recovery, and the PyTorch documentation mentioned above. It is not a set of measured results for Colossus, nor a comparison of the performance of specific products.
| Evaluation item | Main process | Performance and conditions to check | Impact if performance falls short |
|---|---|---|---|
| Storage capacity | Holds training data and in-progress state | Capacity to store the required amount of data, and retention conditions | Necessary data and state cannot be stored |
| Loading training data | Supplies GPUs with the data needed for computation | Sustained read performance and latency | GPUs wait for data to arrive |
| Checkpoint saving | Writes out the state of training in progress | Time required to save, and ability to handle bursts of writes concentrated in a short time | Waiting time due to saving increases |
| Recovery after failure | Reads back saved state and resumes training | Read performance and time required to resume | Resumption of computation is delayed |
Storage capacity determines whether the necessary data and training state can be held. The other three items, by contrast, relate directly to how long it takes before GPUs can proceed with computation. However, because these processes can run concurrently, the time each requires cannot simply be added up to calculate GPU utilization. For Colossus, effective read/write bandwidth, checkpoint-saving time, and recovery time after failures have not been confirmed.
There is also a trade-off in how often checkpoints are saved. Saving less often lightens the write load, but the point from which training can resume after a failure becomes older, potentially increasing the amount of computation that must be redone. Saving frequently, on the other hand, limits losses at the time of a failure but raises the load on storage. How quickly a save can be completed and how far back training can be resumed must be evaluated together. These conditions cannot be seen from total storage capacity alone.
Asynchronous saving and separating processing from capacity each require their own design
Asynchronous checkpointing provided by PyTorch is a mechanism that runs the saving process in parallel with model training. The official documentation explains a method of copying the state to an internal buffer on the CPU side, in order to separate the model state being updated during training from the data to be saved. This reduces the burden of making training wait until writes to storage are complete. However, additional CPU memory is needed to hold the copy, and managing cases where multiple saves run at the same time is also essential. The PyTorch documentation recommends, in principle, limiting asynchronous saves to one at a time.
In other words, asynchronous operation does not eliminate the saving process itself. To run training and saving in parallel, additional memory space and appropriate execution control are required. Whether Colossus uses this PyTorch approach has not been disclosed.
Meanwhile, VAST Data's DASE white paper describes an architecture that separates processing power from storage capacity on the storage side. The nodes responsible for processing are called "CNodes," and the devices that hold the storage media and system state are called "DBoxes." Each CNode can access the entire storage pool using "NVMe-oF," which accesses NVMe storage over a network. With this configuration, the nodes handling data processing and the storage capacity can be expanded independently.
VAST Data also describes a design in which written data is first received in a buffer of high-endurance SSDs and then moved to large-capacity flash storage. It separates the area that handles writes concentrated in a short time from the area that holds data over the long term. However, these are explanations of the general architecture of VAST Data products; the generation and settings of the products deployed in Colossus, and the actual buffer configuration, have not been confirmed.
PyTorch's asynchronous saving is a method for running computation and saving in parallel on the training software side, while VAST Data's DASE is a method for separating processing power from capacity on the storage side. Although they target different areas, both address challenges that cannot be solved simply by adding storage capacity. In large-scale AI infrastructure, expanding storage capacity and strengthening data-processing and network performance need to be considered separately.
95% network throughput does not indicate storage performance
On October 28, 2024, NVIDIA announced that its networking technology "Spectrum-X," which connects the 100,000 GPUs of the initial Colossus, maintained 95% data throughput during training. Throughput is a measure of the amount of data transferred per unit of time. However, this 95% relates to network communication; it does not mean that GPUs spent 95% of their running time on computation. Nor is it a measurement of storage read/write bandwidth.
That said, the network cannot be ignored when evaluating storage performance. A technical blog post published by NVIDIA on February 4, 2025 explains that checkpoint saving and recovery generate "burst traffic," in which large volumes of data transfer are concentrated in a short time. Even if the storage itself is fast, reading and writing data takes longer if the network connecting to it is congested. In large GPU clusters in particular, it is important whether sufficient communication performance can be maintained between storage and compute nodes.
The blog also describes a test run on NVIDIA's Israel-1 using HGX H100 servers, with 40 to 800 GPUs as clients. Using the I/O performance measurement tool "fio," it compared a standard RoCE v2 configuration with one that had adaptive routing and congestion control enabled. As a result, read bandwidth improved by 20–48% and write bandwidth by 9–41%. However, this was an I/O test conducted in an environment separate from Colossus, and it does not mean Colossus's training speed improved by the same proportions. Nor does it guarantee similar improvements in an EB-class storage environment.
NVIDIA's certified storage technical documentation also sets out a policy of evaluating not just momentary peak performance but also performance and latency under repeated load, and recoverability. This is a standard for evaluating AI storage, and it does not mean that Colossus has obtained this certification.
To judge how much Colossus's expansion will contribute to actual training performance, it is necessary to check the storage's effective read/write performance as well as the time required for checkpoint saving and recovery after failures. It is also important whether stable performance can be maintained even when loading training data and saving checkpoints occur at the same time. The 5.2EB-plus estimate offers a clue to the scale of the facilities, but to judge whether the added GPUs can be kept continuously fed with computation rather than left waiting for data, performance metrics separate from capacity are indispensable.