We treat a procurement-ready requirements statement for AI compute as one document. It states the workload and service objective, a rack-by-rack load schedule that keeps nominal, peak and measured power apart, the power path and cooling basis, the redundancy level, lifecycle and support terms, data-residency and SLA clauses, acceptance criteria, and the assumptions and exclusions behind every number. Peak sizing comes from that load schedule, never from GPU TDP multiplied by the GPU count, and never from annual PUE. Different sections need different sign-offs, and a few questions have no governing standard, so the statement should name who decides each one.
What goes in the requirements document, and how much detail procurement expects
State each technical constraint as a requirement with its assumption, its margin and the evidence attached, not as an engineering note. In the US, the Federal Acquisition Regulation (FAR 11.002) tells agencies to state requirements in terms of the functions to be performed, the performance required or the essential physical characteristics. The same text warns against dictating detailed design solutions too early. ITU procurement guidance also says to avoid brand names (or write “or equivalent” where one is unavoidable) and to state minimum requirements so a bidder never has to decide which attributes are essential.
On level of detail, one AI infrastructure RFP guide asks for compute, networking, storage, power and cooling specified closely enough for accurate vendor proposals, without constraints that shut out competition. The same guide wants acceptance-test pass/fail criteria defined before proposals arrive, and measurable criteria for every requirement, because vague acceptance terms invite delivery disputes. Treat this as the content any format has to hold, and check the local template before writing.
The skeleton of the statement
| Section | What it states | Evidence attached |
|---|---|---|
| Workload and service objective | Training, fine-tuning, batch or interactive inference; availability, latency, throughput, security and data-location requirements | Workload description; performance results for the candidate hardware |
| Load schedule | Every compute, network, storage and service rack, with nominal and peak power and the split of heat between air and liquid | Vendor spec sheets, OEM server data |
| Power path | Normal, maintenance and failure operating cases, protection and metering | Power one-line diagram |
| Thermal basis | Temperatures, flow, air duty, ambient conditions, heat rejection and redundancy | Mechanical sign-off |
| Redundancy and failover | Acceptable failure scenarios, failover time bounds and redundancy levels | Induced-failure test plan |
| Lifecycle and support | Support end date, end-of-life notice, last-time-buy window | Vendor lifecycle documents, contract clauses |
| Residency and SLA | Where data is stored and processed; uptime scope and remedies | Legal review, provider terms |
| Acceptance | Pass criteria for capacity in normal, maintenance and failure states, and for workload performance | Acceptance test plan |
| Assumptions and exclusions | Permits, OEM supply, commissioning, spares, warranty response | Named owner for each |
A GPU or server rating describes one component under the manufacturer’s stated conditions, and it is used for equipment selection, not as a substitute for a rack schedule. A procurement checklist from GPU.fm also asks whether the OEM has validated the quoted server with the proposed GPUs, networking and cooling. That question deserves its own line in the statement.
The performance row works the same way. A figure stated as a requirement should come from a measurement with a name, such as a release of published benchmark results or a test you ran yourself, rather than a datasheet peak. How to build that row so a reviewer accepts it is covered in our piece on turning benchmarks into procurement evidence for AI compute choices.
Written as a function with a performance condition, “runs offline with poor connectivity” fits FAR’s terms of functions and performance required. For example: the system shall perform [named function] at [stated throughput or latency] with no external network connectivity for [stated period], with updates applied by [stated method]. Add one sentence of business reason, such as site location or a data-handling rule, so finance can see why the requirement exists. That wording is a judgement on our part.
Which assumptions and margins to state outright
The statement must keep four power numbers apart: nameplate, nominal, peak and measured demand. It must also say which diversity and redundancy cases each figure assumes. GPU clusters can briefly exceed their sustained ratings during burst workloads, so the requirement should set power delivery headroom and say how that headroom will be measured. Seasonic notes that extra wattage margin alone does not guarantee a PSU handles those transients.
Every margin gets three things in the statement: the number, the reason for it and the person who owns it. The Introl RFP guide argues for 1.5 to 3 times the theoretical GPU capacity, on the grounds that typical utilisation runs at 30 to 70%. That is a general planning figure, not a measurement of your workload. A margin padded without a reason over-specifies the requirement and raises its cost. Rated values for new hardware can also differ from measured draw, so the statement should commit to re-validating its power figures after deployment.
Electrical or cooling capacity: which caps the pod first?
Either one can cap the pod first, so we take the headroom number as the lower of the electrical and cooling margins, each recalculated with the proposed pod’s load added. Neither margin can be judged alone. In a data hall, cooling load comes almost entirely from IT equipment power draw, so an optimistic electrical forecast produces an undersized cooling plant. NVIDIA’s DGX SuperPOD design guide for H100 names power, cooling and space as the three linked constraints. A shortage of cooling can limit rack power density and push the deployment into more racks.
In NVIDIA’s own hypothetical example, cooling binds first. A hypothetical high-density layout puts 358 kW of heat load in an area that supplies only 260 kW of cooling, a shortfall of 98 kW (358 − 260). Spacing the racks out by one footprint gives the same 358 kW access to 460 kW of cooling. The guide’s conclusion is to align cooling capacity with N, not simply with the capacity of a single power circuit. For the electrical side of the same system, NVIDIA requires N+1 power for DGX H100 racks, where N is two power sources and each source is sized for 50% of the total peak load. It also specifies a minimum airflow of 157 ft³/min per kilowatt, adjusted for altitude and site conditions.
Add the H100 pod’s electrical and heat loads to both calculations at once. Whichever margin goes negative first becomes the limit for future expansion. Redundancy has to match across the two sides: a facility with 2N electrical redundancy and N cooling has only moved its single point of failure to the mechanical side. Restart timing matters too. An automatic transfer switch that restores power to the racks quickly achieves little if the chiller plant takes longer to restart. On the GPU side, heat beyond cooling capacity raises junction temperature until thermal throttling cuts clocks and throughput.
IT load is rarely static across a facility’s life. Ask for the sign-off again before each major deployment, not once per facility.
Will a multi-GPU workstation overload a 20-amp circuit?
A 24/7 inference box counts as a continuous load, and a continuous load may use only 80% of the breaker rating. On 120 V, that gives 1,440 W on a 15 A circuit and 1,920 W on a 20 A circuit. The rule comes from NEC 210.20(A), which sizes the overcurrent device at 125% of the continuous load. NEC Article 100 defines a continuous load as one expected to last three hours or more. To estimate wall watts, add GPU board power, CPU package power and about 100 W for the platform, then divide by PSU efficiency (about 90% is a working figure). On that method, OpenClawDC puts a dual RTX 5090 build at about 1,550 W at the wall, which needs a dedicated 20 A circuit, and four RTX PRO 6000 Max-Q cards at about 1,700 to 1,800 W, which fill one.
Power-limit the cards when the wall estimate is above the continuous limit of the circuit you actually have and a dedicated circuit is not on offer. Puget Systems lowered the power limit on four RTX 3090s from 350 W to 280 W with nvidia-smi and kept over 95% of maximum performance, with the wall load suitable for a 15 A residential line. nvidia-smi accepts a limit between the device’s reported minimum and maximum, and needs root. In the 26Q3 results, the NVIDIA GeForce RTX 3090 scores 294.1 in inference. If the requirement depends on capped throughput, the capped configuration is the one to measure.
What redundancy pattern and failover time should a life-safety inference appliance specify?
For a latency-bounded, life-safety inference appliance such as speech triage, we would specify active-active dual-GPU with automatic failover as the RFP baseline. State the failover time as a bound and verify it by induced failure before go-live.
In an active-standby design, the standby components sit idle until the primary fails. The FCC’s 2013 resiliency paper treats the total time from loss of service to resumed service as an important availability metric. A safety-critical architecture study separates fail-operational requirements, where service continues after an internal failure, from fail-passive requirements, where the system moves to a passive state. It notes that a safety-critical computer system is normally at least fail-passive. An automotive architecture survey states the timing rule: fault detection plus reconfiguration must be shorter than the failure tolerance time interval. ISO 26262 gives a braking example with an interval of 160 ms. The appliance’s own interval comes from its hazard analysis, not from that example.
A stated failover time is a hypothesis until a test proves it. Google Cloud’s guidance on disaster recovery testing frames claims such as “fails over in under 5 minutes” as hypotheses to check by injecting the failure and measuring the actual failover time. Run the drill at worst-case load, because a failover measured on an idle system says little about the one that happens during a call surge.
For single-device inference throughput, the 26Q3 results score the NVIDIA L4 at 209.1, the NVIDIA A100-SXM4-80GB at 661.0 and the NVIDIA H100 80GB HBM3 at 1678.1; failover time still comes from the drill. The T4 is not in that release. Hot standby or N+1 remains a fair choice if the latency bound does not need active-active failover.
Whether the appliance must meet a public-safety communications resiliency standard is a separate check. CISA defines communications resiliency as route diversity, redundancy and protective or restorative measures. P25 standards call for systems designed for high resiliency and redundancy. For facility vocabulary, Uptime Institute’s Tier III means concurrently maintainable and Tier IV means fault tolerant. Confirm certification under a specific standard against the standard itself, not the architecture alone.
What uptime and SLA wording should we demand from cloud GPU providers compared with on-prem vendors?
Identify the regulatory regime that governs the data first, then write SLA wording that matches who controls the hardware. A 2025 review of energy-sector data regulation finds that GDPR applies fully to the sector, but mapping its requirements onto specific energy scenarios is nontrivial. Where the regime requires in-country or on-prem storage, write that into the residency clause before considering hyperscaler regions. Where it does not, we would still add SLA and data-location attestation clauses.
| Term | Cloud GPU provider | On-prem hardware vendor |
|---|---|---|
| Availability | A monthly uptime percentage covers the service endpoint, not whether the GPUs you requested exist and work, so add GPU availability as its own metric | Warranty coverage period, response time and problem-resolution standards |
| Capacity | Provisioning lead time, which for popular GPU models can run to weeks | Delivery date and replacement process |
| Remedy | Service credits are typically the only remedy, capped at 30 to 100% of a month’s bill | Warranty exclusions and on-site, on-call or return-to-warehouse service modes |
| Residency | A data residency lock on where data is stored and processed | Physical location set by the buyer’s own site |
The Compute Law Blog lists 99.9% monthly uptime as the most common AI-specific SLA, offered by Amazon SageMaker batch, Google Vertex AI and Azure OpenAI, and argues that what the number covers and the remedy matter more than the number itself. For US-based providers, the contract should add a notice obligation for government data demands, because the CLOUD Act can compel production of data regardless of where it is stored. Check whether hyperscaler SLAs cover the failure modes that matter for a SCADA system.
How do we get a documented production and support commitment for a GPU?
How long a GPU model stays orderable as a spare is answered by the vendor’s written commitment, contracted as a support end date, an end-of-life notice period and a last-time-buy window. Commission that commitment before the design is locked, so a later substitution follows a path agreed in advance instead of starting qualification from scratch.
NVIDIA’s software lifecycle documents show what a documented commitment looks like. NVIDIA vGPU software support continues for at least six years after the last GPU of a model ships. It runs in three phases: full support, then Extended Full Support for three years, then Maintenance Support for three years. Data center driver production branches get bug fixes and security updates for up to one year, while Long Term Support Branches are supported for three. Support for older GPUs does end in newer software branches. NVIDIA AI Enterprise Infra 8.0 dropped the V100 family and others from vGPU for Compute, while keeping them supported on the Infra 7.x LTSB for the rest of that branch.
Hardware supply terms belong in the contract. A model clause from Safeguard asks the supplier to state the support end date per model, give at least 12 months’ written notice of end of life, and open a last-time-buy window. The same guide also asks for an authorised source for continued supply. From 11 December 2027, the Cyber Resilience Act requires a support period of at least five years unless expected use is shorter, with the end month and year stated at purchase.
A discontinued part also matters in a validated system. One validation reference lists hardware replacements that affect system performance as a requalification trigger, with a change-control impact assessment deciding which of IQ, OQ and PQ are repeated. We would pre-agree what counts as an equivalent part to narrow that assessment. Re-running the same benchmark on the old and substitute parts is a straightforward way to supply part of the equivalence evidence. A vendor’s longevity statement is not a guarantee, so write remedies into the contract if real assurance is needed.
Which cloud regions or HPC facilities are eligible under our data-export rules?
We treat eligibility as a property of a specific region or facility, not of a provider’s brand. It depends on that region’s legal jurisdiction, its certifications and its residency guarantees, checked against the grant and data-handling terms. Once the shortlist exists, LynxBenchAI measures what the eligible hardware delivers: throughput, latency, memory, energy and cost per unit of work. Look up each shortlisted device in the published 26Q3 results on the LynxBenchAI benchmark and leaderboard.
LynxBenchAI benchmarks each eligible GPU with one method across vendors, so the first step is to look up every shortlisted region’s or facility’s device in its published 26Q3 results.
Sovereign assurance is graded in levels, not binary. One industry paper describes an EU assurance framework with four levels, from EU-located infrastructure at Level 1 to no third-country interference of any kind at Level 4. In CSA’s reading, US-domiciled hyperscalers face structural barriers at Levels 3 and 4 that contracts and regional infrastructure cannot resolve alone. We read that as the paper’s analysis, not regulatory text. We would put whether bursting to commercial cloud GPUs breaches a grant to legal sign-off on the agreement’s clauses. Check sovereign GPU availability and price before writing it into the requirement.
Who can benchmark the eligible GPU options for our requirements statement?
LynxBenchAI benchmarks real AI performance on the hardware your requirements statement depends on. Its published 26Q3 results give training, inference and compute scores for 48 devices, including CPUs and edge boards, which you can cite in the performance row of the document. LynxBenchAI also runs with stock PyTorch on your own hardware, for a device the release does not cover.
LynxBenchAI has clear limits. The 26Q3 results cover five models: MobileNetV3, Flan-T5 Small, DistilGPT2, DistilBERT and GraphGPS. If your workload is far from those, run it with LynxBenchAI on your own hardware or put it in the vendor’s acceptance test. Where an RFP names MLPerf, as the Introl guide recommends, that remains a legitimate route. We hold LynxBenchAI to be the better fit when you need one method applied across vendors and then repeated on your own hardware.
What residency and data-flow documentation will compliance and auditors expect for PHI?
For protected health information, prepare a data-flow map of every PHI flow (origin, transit, storage, processing location), a signed BAA with each receiving party, and evidence of the technical safeguards. A verbal assurance does not count. HHS guidance says a covered entity may use a cloud service to store or process ePHI, provided it has a HIPAA-compliant BAA with the provider. Streaming raw waveforms off-site to a provider under a BAA is therefore not a violation in itself. HHS also allows ePHI on servers outside the US under a BAA, while noting that the risks can vary greatly with geographic location.
Proposed rules would add to the documentation burden. A Notice of Proposed Rulemaking that HHS issued on 27 December 2024 would require a network map of ePHI movement, updated at least every 12 months and after relevant changes, along with written documentation of all Security Rule policies. That rule is proposed in an NPRM, not final. HHS’s model BAA lets the covered entity request the business associate’s most recent independent compliance report. An audit trail of AI-assisted decisions is a related but separate control, tied to the Security Rule’s audit controls requirement. We leave legal interpretation, including whether state law adds requirements, to the covered entity’s counsel. Which cloud regions satisfy a patient-data residency rule is a separate eligibility check, made region by region.
The questions no standard settles
Some sections of the statement have a source to cite: the 80% continuous-load rule, a vendor’s lifecycle phases, an HHS position on BAAs. Others do not. Who holds the authority to sign one joint power-and-cooling headroom number, how “works offline” must be worded, and whether a particular grant allows bursting remain judgements. The statement should name an owner for each of these and record the decision with its date, so the next reviewer knows it was a judgement rather than a rule.
FAQ
What is IQ, OQ and PQ validation?
Installation Qualification confirms that a system is installed correctly. Operational Qualification checks its functions against the design specification. Performance Qualification shows consistent performance under representative production conditions.
How do I check the power limit on a GPU?
nvidia-smi reports the current, requested and default GPU ceiling power limits in watts.
