Skip to content

Self-healing infrastructure for GPU-native data centers

ARAM detects faults in under a second, finds the root cause in seconds, and remediates within the policies you set, across every vendor in the rack.

ARAMOOB managementmgmt switchRack managerappliance where ARAM runsPower shelves6 PSUs each, shared busbarCompute traysaccelerators + host CPUsScale-up fabricswitch traysCompute traysliquid-cooledPower shelvesany vendor, hot-swapCoolant distributionin-rack CDU, pumps and HXcoolant supplycoolant return
Any vendor: compute, fabric, power and cooling as separate shelves

At frontier scale, failures outpace the people diagnosing them

In a GPU rack, one small fault tips the next. ARAM stops the chain where it starts.

ARAMcdu pumpgpu5 tempthrottlexid 79node drainnccl hangjob stall1,024 GPUs
aram events · examplewithout ARAM
okwaiting for telemetry…
 
Example scenario.
18.7%1
of GPU time is lost to failures
14 min2
mean time to failure on a 131,072-GPU cluster
90 min3
to diagnose a single fault by hand
1 day+4
to resolve over a third of Azure GPU failures
  1. Meta FAIR, 150M A100 GPU-hours study (arXiv:2410.21680)
  2. Meta FAIR, 131,072-GPU cluster MTTF (arXiv:2410.21680)
  3. ByteDance, Robust LLM Training Infrastructure (arXiv:2509.16293)
  4. Microsoft, SuperBench: Improving Cloud AI Infrastructure Reliability (arXiv:2402.06194)

The autonomous brain for GPU racks

ARAM senses, reasons, acts and keeps improving across every vendor component in the rack.

Detect

Sub-second detection

Faults and anomalies from real-time telemetry, as they start.

Diagnose

Root cause in seconds

Traced across GPU, cooling, power and network, not just the symptom.

Heal

Remediate within policy

Isolate, fix and verify, automatically where your policies allow.

Predict

Prevent the next one

Learn failure patterns and act before costly disruption.

What ARAM sees across the fleet

ARAM compares every node with its own history and its peers, so quiet failures stand out.

Example dataOver 30 days, b03-11 interrupted 6 training jobs and c01-04 interrupted 5, while most nodes interrupted none. Each failure looked random on its own. Counted per node, the lemons stand out, and ARAM flags them for drain and repair.

Today’s tools weren’t built for AI fleets

Operators stitch together vendor tools and human judgment. ARAM replaces the stitching.

Today
With ARAM
A console per vendor: iDRAC, iLO, DCGM, the CDU’s own panel
One semantic layer and one API for the whole rack
Remediation tools that cover only Kubernetes GPU nodes
GPU, power, cooling and network, covered together
Alerts that wait for someone to read them
Sub-second fault and anomaly detection
Manual runbooks, run by whoever is on call
Runbooks that act within your policies, then verify the fix

The whole is greater than the sum of its parts

ARAM discovers every component in the rack and maps how they relate. When one misbehaves, it follows those links to the cause.

CoolingCompute and fabricPower and networksuppliesmonitorsflows toflows tocoolscoolscoolscoolshostshostshostshostslinkslinkslinkslinksfeedspowerspowersconnectsconnectscdu-1CDUsymptomroot causeleak-1Leak sensorsymptomroot causeloop-aCoolant loopsymptomroot causeplate-1Cold platesymptomroot causeplate-2Cold platesymptomroot causegpu1GPUsymptomroot causegpu2GPUsymptomroot causegpu5GPUsymptomroot causegpu6GPUsymptomroot causetray-1Compute traysymptomroot causefab-1Fabric switchsymptomroot causetray-2Compute traysymptomroot causepdu-aPDUsymptomroot causeshelf-1Power shelfsymptomroot causetor-1Switchsymptomroot causesuppliesmonitorsflows toflows tocoolscoolscoolscoolshostshostshostshostslinkslinkslinkslinksfeedspowerspowersconnectsconnectscdu-1CDUsymptomroot causeleak-1Leak sensorsymptomroot causeloop-aCoolant loopsymptomroot causeplate-1Cold platesymptomroot causeplate-2Cold platesymptomroot causegpu1GPUsymptomroot causegpu2GPUsymptomroot causegpu5GPUsymptomroot causegpu6GPUsymptomroot causetray-1Compute traysymptomroot causefab-1Fabric switchsymptomroot causetray-2Compute traysymptomroot causepdu-aPDUsymptomroot causeshelf-1Power shelfsymptomroot causetor-1Switchsymptomroot cause
Example: rack-a14gpu5 is throttling. ARAM follows the edges back through its cold plate and the coolant loop to cdu-1, whose pump is slowing. The fix starts at the CDU, not the GPU.

Hot-swap parts, hot-reload adapters

Component hot-swap and adapter hot-reload are native to ARAM.

  1. psu-3 pulled
  2. Marked removed, not failed
  3. New psu-3 found
  4. Verified, back in service
Example: rack-a14A technician pulls psu-3 from shelf-1. The other five carry the load, and ARAM marks it removed, not failed, so nobody is paged. When the replacement goes in, ARAM finds it and checks it before it takes load.

See connectors and deployment

Cooling is part of the rack

On a liquid-cooled rack, a coolant problem shows up first as a GPU problem. ARAM reads the CDU over Modbus or Redfish alongside the GPUs it cools, so it traces throttling back to the loop and acts on the cause.

Modbus and Redfish CDUs, coolant loops, leak detection, pump stop and power cap

Example: rack-a14, liquid-cooled
  1. Flow dropscdu-2 falls from 38 to 29 L/min in 90 s
  2. GPUs run hotgpu3 starts thermal throttling
  3. Cause foundcdu-2 flow loss, not the GPU
  4. Policy actsPower cap on rack-a14
  5. VerifiedTemperatures stable, 3 of 3 clean

Works under your DCIM, not instead of it

DCIM plans and tracks the data hall. ARAM runs each rack and reports up to it.

  • Your DCIM
  • ARAM
  • Your racks, from any OEM
  • Redfish API between them
DCIM: data hall
  • Floor space
  • Facility power
  • Facility cooling
  • Assets
  • Capacity planning

Rack health and every action ARAM takes

  • ARAM

    Dell rack-a14

    • NVIDIA GPUs, rack-scale NVLink
    • iDRAC over Redfish
    • Liquid, in-row Vertiv CDU
  • ARAM

    HPE rack-a15

    • AMD GPUs, UALink
    • iLO over Redfish
    • Liquid, in-rack CoolIT CDU
  • ARAM

    Supermicro rack-b02

    • NVIDIA GPUs, 8-GPU servers
    • Supermicro BMC over Redfish
    • Air and liquid, Schneider CDU
  • ARAM

    ODM build rack-b03

    • AMD GPUs, SONiC fabric
    • OpenBMC over Redfish
    • Liquid, in-rack Vertiv CDU
  • + every other rack in the hall, whoever built it

Example fleet

DCIM: Plans and tracks space, power, assets and capacity across the data hall.ARAM: Runs every rack, whoever built it, and fixes faults within your policies.Between them: A Redfish-compliant API reporting rack health and every action ARAM takes.

For the teams running GPU fleets

Direct to GPU operators, and through partners who already own the rack.

NeoCloudsSovereign cloudsEnterprisesSystem integratorsDCIM vendorsSilicon vendorsODMs
Recover lost GPU time
More of the fleet doing the work you bought it for.
Hours become seconds
A 90-minute diagnosis becomes a root cause in seconds.
Autonomy at your pace
Recommend first, then approve, then let trusted policies run.

See what ARAM does on your racks

  • Racks you choose, vendors you already run
  • Deploys as one container image
  • Your policies decide what ARAM may fix on its own
  • Planned with an ARAM engineer, not a sales sequence

We use these details only to reply about your pilot. See our Privacy Policy.

Request a pilot

Run ARAM on racks you choose, under policies you set. An engineer will plan the pilot with your team.

All fields are required unless marked optional.

No sales sequence. An engineer replies.