A GPU Power Cap Is Not a Server Input Budget: Compare the Controlled Boundary

Identify the authority behind the GPU limit

A supplier's statement that a GPU is capped leaves two questions open: who establishes the limit, and which policy takes effect when several limits apply?

NVIDIA's DGX B200 guide, updated October 17, 2026, names three GPU-limit sources: VBIOS defines maximum possible Total Graphics Power; nvidia-smi supplies a host-side user limit; SMBPBI supplies an out-of-band limit. The GPU's Performance Monitoring Unit selects the most conservative policy. A host setting alone therefore does not describe every applicable authority.

For an offer comparison, ask the supplier to identify the governing mechanism for the exact delivered system and the evidence of its effective policy. Retain the applicable firmware, driver and documentation versions. This B200 example explains the comparison; it does not establish the same implementation in every OEM server.

References: [N1]

Why two host requests can produce the same effective policy

Consider three invented alternative policy records for the same unnamed illustrative GPU. The model takes the minimum of three applicable ceilings for that GPU: a VBIOS maximum, a host request and an out-of-band ceiling. The watt figures are stipulated mathematics, not DGX readings, supported or recommended product settings, or a sequence of equipment adjustments.

Proposal A stipulates a VBIOS maximum of 400 W, a host request of 300 W and an out-of-band ceiling of 280 W. The minimum of 400 W, 300 W and 280 W is 280 W, so that is the effective policy in this model. The out-of-band authority is binding because its ceiling is the lowest. The 300 W host request does not govern while the lower 280 W ceiling applies.

Proposal B differs only in its host request: 320 W. The VBIOS maximum remains 400 W and the out-of-band ceiling remains 280 W. The minimum is still 280 W. The requested value is 20 W higher than in A, but the governing policy has not changed: the same out-of-band constraint still binds. A different request is therefore insufficient evidence of a different effective ceiling.

Proposal C instead stipulates a 260 W host request, with the other two ceilings unchanged at 400 W and 280 W. The minimum is now 260 W. The host authority becomes binding because its request is below both competing ceilings. This alternative establishes a governing GPU policy 20 W lower than A or B under the stipulated model; it does not establish a 20 W reduction in observed draw.

For an offer comparison, retain both the requested value and the effective policy, together with the competing authorities and their controlled scope. A supplier showing only the 300 W and 320 W host requests has not substantiated an increase in the governing ceiling. The complete invented records explain why A and B select the same policy and C selects a different one. For an actual offer, the missing authority evidence must come from the exact platform rather than an assumption that this three-ceiling model applies.

These policy comparisons establish no complete-server input, throughput, energy saving or facility allocation. Equal effective GPU ceilings also do not establish equivalent system performance; workload and system evidence answer that separate question.

References: [N1]

A CPU/GPU module is still a different boundary from a server

The nvidia-smi documentation retrieved on October 20, 2026 distinguishes GPU-only scope from module scope. Its module definition includes a GPU, a supported NVIDIA CPU and other power-consuming components; the module-reading feature is described for Hopper and newer datacenter products.

That broader component grouping matters when reading an offer. A module limit must not be relabeled as a GPU-only setting, while the word module does not establish coverage of every component or the input of the complete server. Ask which components the offered platform actually groups under its supported control.

Keep three identities in the comparison: the object controlled, the complete system being purchased and the boundary at which input is claimed or measured. A supplier should name all three. A CPU/GPU architecture label cannot supply the missing server-input definition, and a software scope option cannot establish that an unspecified product supports it.

References: [N2]

Separate the requested setting, effective policy and observation

In the module-reading section, NVIDIA defines Requested Power Limit as the software request and Enforced Power Limit as the minimum of applicable limits. Draw readings are separate observations. The retrieved GPU Ceiling Power Limit subsection uses different labels: Current Power Limit denotes the software request, while Requested Power Limit denotes the enforced ceiling.

Preserve the subsection and original field labels with the actual version. Do not apply the module definitions to a GPU report merely because both contain the word requested. If a supplier's export omits that context, obtain it before deciding what the number proves.

The B200 guide separately identifies Reading as current usage and SetPoint as the current GPU limit. It also warns that reported GPU draw can exceed a stated low cap, including at idle. Retain that qualification when assessing what a reported limit proves.

For the buyer, these distinctions change the evidence request. A proposed value describes an intention; evidence of the applicable effective policy addresses what control governs; a draw record describes an observation at its stated boundary and time. One cannot stand in for the other two.

References: [N1][N2]

Four settings of 250 W establish a sum of settings

Consider a wholly fictional offer for an unnamed server containing four GPUs. Each GPU line lists a proposed 250 W setting, and the offer's summary calls the server a 1,000 W system. These are invented offer entries, not supported or recommended values for a named product.

Four times 250 W equals 1,000 W. That arithmetic sums the stipulated GPU settings. It neither measures server input nor proves that the requested settings are the effective policies. Even the controlled GPU boundaries remain to be established from the actual platform documentation.

Host CPUs, host memory, networking, fans and power conversion are not accounted for by that sum. The buyer cannot correct the missing boundary by adding a guessed allowance. The useful response is to retain the four proposed entries and return the complete-system claim to the supplier for evidence.

No completed-work evidence accompanies the settings, so the offer establishes neither a fixed performance reduction nor an energy saving. The companion GPU benchmark guide explains how to compare workload results and measured system energy.

A system-level cap needs its own supported basis

If the supplier instead proposes a complete-system limit, ask for the exact server model and configuration, the applicable manufacturer policy and the boundary that policy controls. Identify whether the stated quantity concerns an internal component grouping or the server's input, and which included equipment it covers. A summary headed system power does not close those questions.

The supporting material should distinguish the proposed setting from evidence of the effective policy. Ask the supplier to explain the applicable conditions, competing authorities and documented behavior after relevant lifecycle events such as a restart or maintenance. These are questions for the system owner to answer from the actual implementation, not assumptions about persistence or instructions to change settings.

Keep any measurement evidence identifiable by equipment configuration, workload or operating state, measurement boundary, time and method. A supplied observation can support a claim under those conditions; the responsible reviewer still needs to decide whether it addresses the offered limit and intended use. A GPU dashboard screenshot alone does not establish complete-server input.

Carry the system evidence to the facility decision

A supported system policy can become an input to the facility review. It does not itself revise the customer's allocation. The facility's responsible reviewer must determine whether the exact proposed equipment and operating basis are acceptable under the site's requirements.

Keep the supplier's system evidence and the facility's disposition linked to the same configuration. If the only returned information is the four GPU entries in the example, leave the server-input claim unresolved. If a documented system policy is returned, assess that policy on its own terms rather than presenting the component-setting sum as its proof.

The related rack-PDU guide covers measurement boundaries and allocation, while the GH200 guide explains why component and supply ratings cannot be promoted into complete-server input. Use those comparisons for their respective decisions; this article's additional question is which limit authority controls which object.

Bring the defined system to physical planning

Once the system and facility owners return their decisions, carry the exact equipment identity, supplied interface requirements and remaining dependencies into the physical installation package. Keep unresolved power evidence visible alongside rack locations and connection records instead of replacing it with an unsupported watt figure.

Leviathan's Physical Infrastructure Planning & CAD service can discuss engagement-defined layouts, cable routing, connection schedules and planning records, with capability and outputs confirmed for the project. Power-control configuration and facility electrical decisions remain with the appointed specialists.

For a project inquiry, share the selected server configuration, customer-approved physical plans, relevant supplier and facility inputs, and the documentation you need prepared. That gives the scope discussion a concrete physical purpose without turning a GPU setting into a capacity commitment.