UPS runtime for a GPU node: a recovery-time budget

Choose UPS runtime for a GPU node from the actual protected load and required action sequence. A VA rating alone does not determine backup duration. Separate brief ride-through, controlled shutdown, and later cold recovery. Use the particular UPS and battery condition without disconnecting production power for an approximate estimate or promising identical runtime during every phase of an inference workload.

Define the protected boundary

Include CPU, RAM, storage, and necessary networking where powered by the same UPS, not only GPUs. The Schneider UPS Selector relates runtime to load and the selected device’s characteristics. GPU-board power cannot stand in for AC consumption of the protected chain. Preserve equipment membership and observed load range. Matching UPS model names or VA ratings do not describe the complete scenario when the number and behavior of protected devices differ. The boundary determines which consumption belongs in the calculation.

Divide the time budget

Specify detection, stopping new work, finishing or canceling current work, and shutdown. Add a justified procedural margin. Cold startup after power returns belongs to recovery time and may occur outside the battery-backed window. Do not combine every stage into an undefined “UPS uptime” number. Define start and completion conditions for each. This reveals whether load-specific runtime covers the selected safe-shutdown procedure during active work rather than an abstract idle server with no requests or dependencies to drain.

Build a timing record

Create detection, drain, shutdown, margin, and restart rows. Record duration source, dependencies, and whether the stage occupies battery or recovery time. This is a measurement design without invented backup minutes. Unbounded drain cannot be assumed to fit the reserve; long requests require an explicit policy. Check availability of the control network too. Power for the GPU does not guarantee delivery of a shutdown signal if required networking lies beyond another, unprotected boundary. Preserve those dependencies in the recovery diagram.

Account for battery condition

Schneider’s VRLA-battery FAQ discusses operating conditions, load, and battery life. Preserve maintenance date, temperature, and available health evidence. A new-system result cannot be transferred to an older battery merely because part numbers match. Treat selector output as a planning estimate interpreted alongside current condition and manufacturer-supported validation. Frequent deep discharge is not a necessary acceptance method and can itself change the battery being evaluated. Keep test procedure and equipment condition visible with every runtime conclusion.

Accept the recovery plan

Record UPS model, battery configuration, load, runtime source, and shutdown/restart sequence. Exercise software transitions through an agreed test scenario without removing production power. A real fault exercise requires its own planned procedure and impact boundaries. The document should show what the battery covers and how long functional LLM recovery requires after power returns. It cannot promise unlimited continuity or derive runtime from VA alone. Revisit the budget when GPUs, networking, or workload change so older estimates cannot conceal higher demand or additional model-loading and warmup time.

GPU networking and availability: beyond internet speed; A GPU maintenance budget: planning beyond startup.