GPU & AI · GPU clouds and AI halls

The GPU is what you sell. SynapseDC runs everything it depends on.

SynapseDC runs the power, cooling and liquid racks around your GPUs and joins every GPU to its job, its customer and what it costs, on one estate model. A CDU alarm reads as GPU time lost; a failed GPU reads as revenue at risk.

Why GPU estates are different

Every fault is now a GPU fault.

Density

40–60 kW liquid racks on CDU loops. A cooling fault stops being a ticket and becomes lost GPU time within minutes.

Coupling

A training job spans hundreds of GPUs. One failed GPU or one flapping rail stops or slows all of them.

Cost

Power is the largest running cost, and it is billed whether the GPUs are earning or idle.

Blind spots

The GPU team sees a slow job. The facility team sees a CDU alarm. Nobody sees that it is the same event.

One chain

From the utility feed to the invoice.

What a GPU depends on and what it earns, on one estate model. One event reads the same way on both sides of the building.

What the GPU depends on
  1. Utility feedtariff · contract
  2. UPS · buswayA and B sides
  3. CDU loopflow · supply temp
  4. Liquid rack40–60 kW
What the GPU earns
  1. GPU node8 GPUs · NVLink
  2. GPUclocks · throttle · Xid
  3. Jobstep time · checkpoint
  4. Customerreserved · on-demand
  5. RevenueGPU-hours · credits
CDU flow at 62 %144 GPUs throttlejob 24 % slowerincident on the cooling fault, not the job

Use cases

Five situations every GPU cloud knows.

Each one names the modules that answer it.

GPU cloudUC-G1NeoCloud

One failed GPU stops a 152-GPU training job

An Xid error on one GPU stalls the whole allocation. The GPU team sees the error; nobody sees the job, the customer or the cost.

The job with the biggest blast radius is on the Command Center and GPU Fleet: the customer, GPU time lost per hour, minutes since the last checkpoint and work to redo, with a Critical incident opened on the node.

  • Per-GPU telemetry joined to the job and the customer
  • Blast radius, GPU time lost and work to redo
  • Critical incident within the polling interval
  • Revenue impact on the job's service
152GPUs stopped by one failure$625/hGPU time lost52 minsince the last checkpoint
GPU cloudUC-G2NeoCloud

A job is 24 % slower and the cause is in the plant room

CDU flow drops, GPUs throttle, the job slows. The facility team sees the CDU; the platform team sees a slow job.

Thermal slowdown is traced from the job to the GPUs to the rack to the CDU loop. The slowest job and its cause sit together, with the hardware-slowdown flags and the step-time share lost.

  • Throttle reasons and clocks per GPU
  • CDU loops and rack heat joined to the pod
  • Slowest job with step-time share lost
  • Incident on the cooling fault, not the job
24 %step time lost62 %CDU flow at the loop144GPUs slowed
GPU cloudUC-G3NeoCloud

Where should the next 256-GPU job go?

Placement is a guess between free GPUs, rack headroom, cooling state and power already paid for.

Pods are ranked for the job: free healthy GPUs, rack power headroom, cooling state (CDU for liquid), contracted headroom, kW already paid under the block or floor, and the marginal power cost per GPU-hour.

  • Fit per pod: good, tight or no
  • Power already paid for shown as free
  • Marginal power cost per GPU-hour
  • Model picker: B200, H200, H100, Gaudi 3…
8–256GPUs per placement query$0.19power per sold GPU-hourper podfit and headroom
GPU cloudUC-G4NeoCloud

GPUs are allocated, drawing power and doing nothing

Idle allocations are billed and powered, but invisible between the scheduler and the facility.

Idle jobs are listed with their GPUs, the power they draw and what that costs per day, next to the inference pods that could be capped in the peak tariff window.

  • Idle allocations by job, customer and pod
  • Energy and cost per job and per tenant
  • Power-cap savings against the GPU time it costs
  • Findings against the power contract
6 hidle allocation found in the demoper tenantenergy and cost4finding types against contracts
CommercialUC-C4Colocation · NeoCloud

We pay for power we don't use

Take-or-pay floors, demand ratchets and idle colocation blocks are found when the invoice arrives.

The bill is priced against the tariff and the contract: energy, demand charge on the floor or peak, idle kW, and findings when a block is nearly used, a new peak sets the ratchet, or draw rises with no change in progress.

  • Bill per site against real tariffs
  • Idle kW paid but not sold
  • Findings raised as alarms and incidents
  • Cost per sold MW and per sold GPU-hour
4contract finding typesper siteidle kW priced$/GPU-hpower against price

Plan & build

Plan and build the AI hall before the GPUs arrive.

Plan and build for AI density on the same estate model the GPUs will run on.

Plan the AI hall

Size a new hall by IT kW, rack density and cooling type, then price it, schedule it from lead times and route it for approval.

Know what you can sell

Capacity in GPUs: in a job, allocated to an idle job, free, or out of service, next to the rack power and cooling headroom behind them.

Build it as records

Liquid racks, CDUs, PDUs and the cabling to every node recorded in DCIM, each edit under a change request, commissioned L1 to L5.

Coverage

Accelerators, telemetry and fabric.

Vendor-aware labels per accelerator. One model per pod, read through the telemetry each vendor ships.

NVIDIA
B200H200H100A100L40ST4
Intel
Gaudi 3Data Center GPU Max 1550
Telemetry
NVIDIA DCGMIntel Gaudi hl-smiIntel XPU ManagerRedfish (node BMC)
Fabric & scheduler
InfiniBand NDR · UFMEthernet front-endSlurmKubernetes

GPU & AI

Questions GPU clouds ask.

Does SynapseDC cover liquid cooling as well as the GPUs?

Yes. CDU loops, liquid racks, the power path to the rack and the power bill are in the same estate model as the GPUs, the jobs and the customers, so a cooling fault is read as the GPU time it costs.

Do you read our customers' jobs or models?

No. SynapseDC reads GPU telemetry and the scheduler's job metadata (who, which GPUs, start, state). It never reads a job's data, model or code.

Which accelerators are covered?

NVIDIA B200, H200, H100, A100, L40S and T4, and Intel Gaudi 3 and Data Center GPU Max 1550, with vendor-aware telemetry labels. Other accelerators are to be discussed.

Do we need a scheduler integration?

It helps. GPU telemetry alone shows the GPUs; the scheduler's job metadata (Slurm or Kubernetes) is what joins a GPU to its job and its customer.

Bring one GPU cluster.

We map it onto a demo estate shaped like yours: its power path, its cooling loop, its jobs and its customers. Then we agree what a one-pod pilot should prove.