`system_power.json`¶

The provisioned-power descriptor for one system. One per system, not per point: provisioned power and node counts are the same for the whole frontier; a point can scale it with nodes_used in point.yaml. Why it exists and what it's used for: What is MLPerf Endpoints?.

Required, and authored by you

Every system needs one. A system without it, or with a file from which no total can be derived, fails the submission checker. Put it at the top level of at least one run folder of the system; the builder places it at results/<system>/system_power.json in the bundle. Authored in step 5.

Fields¶

The checker reads the shape below. Every field is optional on its own, but the file as a whole has to yield a total.

Field	Type	Description
`provisioned_power_w`	number	A declared total, in watts. If present it is used as-is and the component groups are ignored
`rack_power_w`, `rack_nodes`, `submitted_nodes`	number	Rack-level node scaling (§4.5.2.1): the published power of a full rack of `rack_nodes` nodes, scaled to the `submitted_nodes` you submit
`cpu`	group	Host CPUs
`accelerator`	group	GPUs, ASICs and similar
`compute`	group	Optional. CPU and accelerator as one figure, where the vendor publishes them that way. Replaces `cpu` and `accelerator`
`scale_up_network`	group	The high-bandwidth fabric between accelerators — NVLink switches, TPU ICI, UALink over Ethernet. Zero in a system with no switches
`scale_out_network`	group	Only for multi-node systems with a scale-out fabric. Rules §4.5.2 counts it in the total, in two parts (below); the rules' schema makes `scale_out` required (E.4)
`overhead_fraction`	number	Optional, and normally left out: the checker takes it from `cooling` in `system_desc.json` (below)

Each group has a count, a rated power per unit in watts, and a link to a public specification. The checker accepts the field names from rules §4.5.2, or a generic spelling on any group:

Group	Count	Power per unit
`cpu`	`num_cpu`	`tdp_per_cpu`
`accelerator`	`num_accelerator`	`tdp_per_accelerator`
`scale_up_network`, `scale_out_network`	`num_switches`	`tdp_per_switch`
Any group	`count`	`tdp_per_unit`

The rules also have the scale-out group declare its NICs and its cabling, passive or active optical. The checker shape has no field for either, so NIC counts and power are not read; the Appendix E shape has scale_out.nics and scale_out.cabling (E.4).

The link goes in link or public_specification. Count what's installed, as provisioned, not the chassis maximum.

Declare cooling in system_desc.json

The overhead fraction comes from the system description's cooling field, read at system level or from node_types: 0.30 if it says liquid (or water, or immersion), 0.50 if it says air. A system whose nodes are cooled differently gets 0.50. Without a fraction there is no total, so power-descriptor fails. Passive cooling matches neither value; in that case state overhead_fraction here.

Appendix E schema¶

Appendix E now defines a new shape for this file. The checker shape above predates it, and this page hasn't confirmed that the checker reads the new one. Two of its structural choices are open working-group items (E.7), so treat it as provisional. In outline: every power figure is a sourced value, with a public source or an MLCommons default, never a bare number (E.1); the top level names the system and its cooling (E.2); there is one entry per set of identical nodes, with its power method and components (E.3, E.3.1); a scale_out object is required, set to { "present": false } for a single node (E.4); and the checker derives the computed block (E.5). A declared_provisioned_power overrides the computed total (E.6.2). Default CPU and accelerator TDPs are in D.2 and D.3; worked examples in E.6.1 and E.6.2.

How the total is computed¶

What the checker computes from the fields above. The power model it implements is in §4.5.2, Power Model.

total_w  = provisioned_power_w                             if declared
         = rack_power_w × submitted_nodes / rack_nodes     else, if all three are given
         = major × (1 + overhead_fraction)                 otherwise

major    = cpu + accelerator + scale_up_network
           (compute replaces cpu + accelerator when given)

provisioned_power_kw = total_w / 1000

Each point's system_tps_per_kw divides by point_power_kw, which is provisioned_power_kw scaled by the nodes that point engages (§4.5.3).

The block above is the checker's behaviour, which this page hasn't confirmed against the rules' current scale-out terms. Rules §4.5.2 now adds scale-out NIC power to major, so the overhead is overhead_fraction × (CPU + Accelerator + Scale-up + Scale-out NICs). It also adds scale-out switch power to the total outside the overhead base. Both are zero for a single-node system. Whether the checker implements this is unconfirmed. Reference NIC and switch values are in Appendix D.4; default accelerator TDPs, where MLCommons has one, are in Appendix D.3.

Example¶

A liquid-cooled node with two CPUs, eight accelerators and one scale-up switch. Its system_desc.json says the node is liquid-cooled, so the fraction is 0.30:

{
  "cpu":              { "num_cpu": 2,         "tdp_per_cpu": 350,         "link": "https://vendor.example/cpu-spec" },
  "accelerator":      { "num_accelerator": 8, "tdp_per_accelerator": 700, "link": "https://vendor.example/accel-spec" },
  "scale_up_network": { "num_switches": 1,    "tdp_per_switch": 3500,     "link": "https://vendor.example/switch-spec" }
}

Evidence, partial systems and estimates¶

These are policy, and live in the rules:

Which sources count as evidence for a power figure, and what a component running below its rated TDP has to show: §4.5.2, Methodology.
How to state the power of a partially populated system, whether a partial rack, a node with empty accelerator slots, or a system under a TDP cap: §4.5.2.1. Linear scaling is allowed only at whole-node granularity, over identical nodes, with Y rounded up to a whole node. A rack of mixed node types is split into sets of identical nodes, scaled separately and summed.
What MLCommons does with values you leave out, and the "MLC Estimated Power" tag the result then carries: §4.5.2.

Where a published figure is a range, the rules use the upper bound. Every value needs a public source unless it is an MLCommons default, and a published rack or system rating is specific to the vendor and SKU that published it (Component Template).

If the MLCommons formula or a default diverges materially from your actual provisioned power, report it to MLCommons, whether it overstates or understates. Knowingly keeping an understated estimate is a misrepresentation (Component Template, Submission Rules §8.4).

The bundle build also fails if two runs of the same system carry different system_power.json contents.

Caveats

Scope. Rules §4.5 applies normalization to Standardized CoP and CoN, makes it optional for RDI, and defers Serviced. The same section says every submission must include the file, and the checker requires it for every system regardless of division. Until that's reconciled, include it whatever your division. Tracked as B11.
Pending ratification. Tier definitions, overhead fractions, reference components and the metric's name and units are all marked subject to change.

Last verified against: mlcommons/endpoints_policies@main (1818269) and mlcommons/endpoints-submission-cli@main (a42a056, v1.1.0.0), 2026-10-02.

system_power.json¶