By RE:AI amd WEKA

HTX is building an AI-enabled, sovereign Home Team. Under the five-year Strategic Partnership for Innovation that HTX renewed with Singtel in February 2026, RE:AI, Singtel Digital InfraCo’s sovereign AI cloud business, provides the AI infrastructure behind HTX’s growing requirements, keeping latency-sensitive applications inside trusted local environments. RE:AI designs and runs the platform end to end, from facility and fabric through GPUs, Paragon platform powered orchestration, tenancy and managed service. NeuralMesh is the data layer inside it.

HTX’s NGINE platform is organised into purpose-built engines that run on RE:AI infrastructure: Physical AI tier, is where robotics and real-time vision models are trained and refined.

The Physical AI clusters are an initial build, designed to scale. Physical AI training streams large multimodal datasets, writes large checkpoints often, and exposes any part of the system that can’t keep up. So the cluster was engineered as a system, not a collection of parts: NVIDIA GB300 NVL72 compute, a ConnectX-8 InfiniBand fabric for GPU-to-GPU traffic, a separate BlueField-3 RoCE fabric for storage, and NeuralMesh as the data layer.

Validated together, that stack delivered 7.7 GB/s of read and 6.0 GB/s of write bandwidth to every GPU with the full fleet running, 155 µs read latency, 29.7 million random read IOPS and 99.49% accelerator utilisation.

GPUs are the most expensive and most constrained resource in any AI platform, and they only create value while they’re working. Every minute a GPU spends waiting on data is training that doesn’t happen, a model that ships later and an insight that arrives late. That is why the useful question isn’t what a storage system peaks at on a datasheet. It’s what storage delivers to every node, and every GPU in that node, when the whole fleet is busy at once. Utilisation is uptime, uptime is work completed, and work completed is the return on the platform. A data layer that keeps GPUs fed turns more of the same compute investment into results. One that stalls charges the cost to every GPU in the job.

The system under test was one of RE:AI’s clusters: multiple racks of NVIDIA GB300 NVL72, served by a single NeuralMesh cluster. Every run was made from inside a tenant network space with NeuralMesh native multitenancy enabled, which is the configuration the platform runs in production.

All runs are recorded in RE:AI’s HTX Cluster 1 GB300 NVL72 Handover Report v1.0, 17 August 2026.

Rack figures show the range across racks, each tested separately. Per-GPU figures are the full-cluster result divided by the cluster’s total GPU count. Backend ceiling at full load: 58.4 GB/s read and 45.5 GB/s write per NeuralMesh storage node.

Each result answers a practical question an operator has to get right when sizing such a platform.

1. Every GPU gets fed with the whole fleet running

• What we tested:  sequential read and write from every compute node at the same time.
• Result:  7.7 GB/s read and 6.0 GB/s write per GPU. NVIDIA’s DGX SuperPOD reference architecture sets 4 GB/s per GPU of read bandwidth for the most I/O-intensive training, with write at half of read (2 GB/s) or better where checkpoints matter. The cluster cleared the read guideline by almost 2x and the write guideline by 3x.
• What it means : headroom for data loading and checkpointing, and room for larger models and datasets without re-architecting storage.

2. Peak performance is available to any single node

• What we tested:  one node running alone, to see how much a single job can pull when it needs a burst.
• Result:  46.35 GB/s read, about 93% of the node’s 400 Gb/s storage port. (Note: the node’s two 400 Gb/s ports share a PCIe link, so ~400 Gb/s is the practical ceiling).
• What it means : storage isn’t the ceiling for an individual job. When a node needs to load a dataset or restore a checkpoint, it gets close to line rate, and time spent waiting is cut to the minimum the network allows.

3. Performance scales predictably 

• What we tested:  scaling from a single node to nearly the full cluster, and each rack on its own.
• Result:  throughput rose almost linearly with client count, then levelled off at the ceiling of the 19-node NeuralMesh backend: 58.4 GB/s read and 45.5 GB/s write per NeuralMesh node. Tested separately, the racks came within about 1% of each other (706 and 714 GB/s read).
• What it means:  fleet-wide throughput is set by the number of NeuralMesh nodes, not by how many clients mount the filesystem, so every new GPU rack comes with a clear number of storage nodes to match.

4.  Latency stays flat under load

• What we tested:  4 KB random reads from one rack up to the full cluster.
• Result:  read latency held between 155 and 157 µs from one rack up to the full cluster, with 29.7 million random read IOPS at full load.
• What it means : heavier shared use doesn’t turn into slower jobs. Adding clients doesn’t add latency, which matters for small-file and random-access work like data shuffles and metadata-heavy pipelines.

5. The GPUs stayed busy

• What we tested:  MLPerf Storage replayed the I/O of a Unet3D training job for four accelerators over five epochs on a single node.
• Result:  accelerator utilisation averaged 99.49% (standard deviation 0.13%) at a sustained 24 GB/s, well above the MLCommons pass threshold.
• What it means:  the accelerators never waited on storage. Nearly every GPU-hour the platform pays for goes to training, not to waiting on data.

Shared AI platforms usually force a trade-off. Isolate tenants with dedicated hardware and accept idle capacity, or share infrastructure and accept weaker boundaries and noisy neighbours. For a sovereign platform serving government workloads, neither is good enough.

NeuralMesh runs multitenancy natively inside the cluster. Each tenant is a first-class entity with its own lifecycle, capacity quota, security policies and administrator. Tenants share one elastic resource pool, so capacity one tenant isn’t using is available to others instead of sitting idle, and removing a tenant returns its resources to the pool immediately.

Tenant networks are built as network spaces on WEKA’s Virtualized RDMA Data Fabric (VRDF), which enforces isolation inside the RDMA data plane rather than relying on host-level segmentation alone. In practice, that gives each tenant:

• A private network context. Dedicated VLANs and IP ranges, including overlapping address spaces across tenants, so onboarding a new tenant doesn’t mean redesigning the network.
• Enforcement in the data path. The origin of every mount request is validated. Requests from outside a tenant’s network space are rejected, even with valid credentials, which limits the damage a misconfiguration can do.
• Independent security controls. Each tenant can use its own identity provider (LDAP) and encryption keys (KMS), with its own administrators who have no visibility into other tenants.
• Predictable performance. Per-tenant quality-of-service limits keep any one tenant from crowding out the others on the shared cluster.
• On the deployed 5.1 release, network-space isolation covers POSIX and S3.

For HTX, the key point is that every benchmark ran with multitenancy enabled. Isolation didn’t cost performance. NGINE Physical AI GPU platform is designed to add tenants over time, and each one can come online in the same cluster without a new storage silo and without sacrificing performance.

HTX’s NGINE platform is organised into purpose-built engines that run on RE:AI infrastructure: Physical AI tier, is where robotics and real-time vision models are trained and refined.

The Physical AI clusters are an initial build, designed to scale. Physical AI training streams large multimodal datasets, writes large checkpoints often, and exposes any part of the system that can’t keep up. So the cluster was engineered as a system, not a collection of parts: NVIDIA GB300 NVL72 compute, a ConnectX-8 InfiniBand fabric for GPU-to-GPU traffic, a separate BlueField-3 RoCE fabric for storage, and NeuralMesh as the data layer.

Validated together, that stack delivered 7.7 GB/s of read and 6.0 GB/s of write bandwidth to every GPU with the full fleet running, 155 µs read latency, 29.7 million random read IOPS and 99.49% accelerator utilisation.

AI I/O is bursty. Checkpoints, epoch boundaries, dataset shuffles and context loads all arrive as short bursts, synchronised across the fleet. A platform sized for the average handles the average, then stalls at every burst. That stall is paid in GPU time on every node in the job, not only the one that’s waiting.

So size for the burst. Calculate how much data the largest job writes at a checkpoint, and how long that job can afford to pause while it does. Here’s what that looks like for one rack. A full-rack job spans 18 nodes and 72 GPUs. Say it writes a 5 TB checkpoint, and every GPU in the job waits until the write finishes.

The difference is about 25 seconds for 72 GPUs, or roughly 30 GPU-minutes lost at every checkpoint. If the job checkpoints once an hour, that adds up to about 12 GPU-hours a day, per rack, spent waiting instead of training. Sizing for peak gets that time back.

Storage performance at this level is a property of the whole system. A data layer can’t deliver line rate into a node that isn’t set up to receive it, so the two teams divided the work clearly and agreed one approach from the start: design the storage path end to end for maximum throughput per node, then prove every part of it by measurement before handover.

RE:AI owned the compute side: host networking, fabric layout and the configuration of every GPU node. WEKA owned the data layer: deploying and configuring NeuralMesh, mapping its tenant network spaces onto RE:AI’s VLAN design, and running and diagnosing the benchmark programme. These were the decisions that made the difference.

Before the service went live, the teams also swept concurrency from 4 to 16 jobs per node, tested each rack separately and exercised failover.

RE:AI NGINE starts compact, and it’s built to grow. The results from this validation testing indicate how that growth will behave.

1. Adding tenants won’t cost performance. Every result here was measured with multitenancy on. Because tenants share one pool rather than reserving fixed slices, a new tenant adds demand without stranding capacity.
2. Adding load won’t slow existing work. Read latency held at 155–157 µs from one rack to the full cluster, so heavier shared use doesn’t become slower jobs.
3. Adding racks is simple math. Each NeuralMesh node contributed about 58 GB/s read and 45 GB/s write, so every new GPU cluster comes with a clear number of storage nodes to match.

For HTX, that means the Physical AI tier can scale on a platform that keeps its most valuable resource, the GPU, doing useful work. For RE:AI, it’s a repeatable blueprint for a regulated, multitenant sovereign AI zone: isolation enforced in the data plane rather than only at the host, a host configuration RE:AI owns and can reproduce on every node, and performance measured on the production configuration rather than by datasheets.

• HTX and Singtel Strategic Partnership for Innovation renewal, Feb. 2, 2026
• NGINE launch, HTX, August 2025
• Singtel RE:AI and WEKA sovereign AI infrastructure MOU, June 10, 2026
• NeuralMesh multitenancy technical brief
• NVIDIA DGX SuperPOD Reference Architecture (NVIDIA DGX™ GB200), Storage Architecture