From Nominal Capacity to Deliverable Compute: Design, Calibration and Validation of the D-PIN SCU Dynamic Metering System

From Nominal Capacity to Deliverable Compute: Design, Calibration and Validation of the D-PIN SCU Dynamic Metering System D-PIN Standardized Compute Units for Distributed Heterogeneous AI Compute Networks Authors: Cheng Li, Jiexiong Liu, Shikun Wang, Feiyu Ren Affiliation: KunlunMeta Research, Shanghai, China

arXiv:2610.16374v1 [cs.DC] 12 Oct 2026

Abstract Context. Cross-architecture comparability of heterogeneous compute has become the central bottleneck for the market-oriented operation of computing power networks. Two largely disconnected technical routes exist today: (i) statistical and conversion conventions, represented by GB/T 47514— 2026 and YD/T 6693—2026, which serve national-scale aggregation and grid interconnection; and (ii) accounting and pricing units, represented by AWS ECU, Azure ACU, SLURM TRESBillingWeights, and the standardized compute unit (SCU) and “One-Degree Compute” (DCU), which serve quota management and contractual settlement. We note that the term SCU already carries several semantically distinct public uses in this field, whose work line dates back to 2024; our scope is therefore defined in layers (see the originality statement and Appendix C.3), and our own unit is named the D-PIN SCU to distinguish it from these homonyms (Sections 2.2 and C.3). Both rest on the same premise: what is measured is the nominal capacity promised by a chip’s datasheet. Problem. When compute networks shift from centralized datacenters to distributed physical infrastructure — building-level edge nodes, heterogeneous co-hosting, compute–electricity coscheduling — this premise breaks down. Three systematic gaps separate nominal capacity from deliverable compute: topology gaps (the communication ridge imposed by multi-chip interconnect), runtime gaps (thermal throttling, fault degradation, occupancy), and behavioural gaps (over-claiming, location spoofing). Static units cannot observe any of them, and therefore cannot support real-time scheduling or a verifiable, auditable distributed market. Method. We formalize the D-PIN SCU dynamic metering system (dynamic, topology-aware, runtime-corrected). (1) Compute resources are defined by a five-dimensional vector (𝐹, 𝑀, 𝐵, 𝐼, 𝐸); the normalization baseline is defined as a method rather than a specific hardware model — fixed by a specification of dimensional conventions, value-sourcing rules and re-anchoring rules — with H100 SXM serving only as its current realization. We prove origin invariance (uniform re-anchoring leaves all relative metering results unchanged), so the baseline instance is replaceable without loss of comparability. (2) A topology-aware factor 𝜂topo is derived from a cluster-scale Roofline model, with a closed-form communication ridge COI∗ and an empirical calibration procedure. (3) Runtime corrections 𝛿𝑇 (thermal), 𝛿𝐹 (fault) and 𝛿𝐿 (load) are modelled temporally; we prove that metering bias under nominal specifications is unobservable (Proposition 2). (4) A simplex-constrained weight calibration algorithm with exponentiated-gradient (entropy mirror-descent) updates is proposed, together with an identifiability analysis under dimensional collinearity. (5) D-PIN SCU declarations are coupled to a three-layer Proof-of-Physical-Work (PoPW), yielding a no-arbitrage condition for node over-claiming. (6) Unit price is coupled to electricity cost, green-energy ratio and reputation, closing the compute–electricity loop. Validation. An end-to-end recomputation is performed on the Zhangjiang Science Gate T1/T2 production nodes (ten heterogeneous 8-GPU servers — four imported: 2×NVIDIA H20, 1×AMD MI300X, 1×AMD MI308X; six domestic: 2×Muxi C500, 4×Ascend-910B — 59.5 D-PIN SCU in total, 180 kW supply-and-distribution design capacity, ≈54.5 kW measured at the IT boundary). The billed throughput of 33,000 D-PIN SCU·hours is self-consistent with the Physical Upper Bound Principle (59.5 × 720 × 78%), and two new recomputable metrics are derived: 3.02 kW/D-PIN SCU and 0.26 D-PIN SCU·h per kWh delivered. Appendix B discloses the chip baseline under two parallel conventions — the published value in an empirically calibrated convention (declared non-reproducible 1

D-PIN SCU: From Nominal Capacity to Deliverable Compute

from vendor datasheets) versus a datasheet-projected convention — which diverge materially (H200 +10.5%, MI300X +74.2%, Ascend-910B −31.1%, Muxi C500 −30.9%). Item-by-item verification in Appendix B.3 further confirms the key inputs for MI300X and H200 and closes the key inputs of Muxi C500 through vendor public channels, ruling out parameter error as the alternative explanation. We present this divergence as direct evidence that static conventions are insufficient to meter deliverable compute, and that an empirical calibration loop is a necessary rather than optional component; minimum reproducibility (A6) requirements are specified. Conclusion. Compute does not lack units; it lacks a measure of deliverable compute. The contribution of D-PIN SCU is not “yet another standardized compute unit”, but the advancement of the metering object from nominal capacity to deliverable compute, such that a single quantity is simultaneously schedulable, verifiable, and priceable — a metering-theoretic construction integrating metering, scheduling, verification and pricing. At the industry level, D-PIN SCU can serve as a scheduling-level metering middle layer between statistical and accounting conventions, supporting grid interconnection, distributed pricing, compute financialization, and compute–electricity co-scheduling (Section 10.1). We make no claim to priority over the term SCU, nor over the individual elements of normalized weighted metering; our originality claim is confined to the integrated system — runtime identifiability, closed-form topology ridge, and verification–pricing coupling — taken as a whole. Keywords: D-PIN standardized compute unit (D-PIN SCU); heterogeneous compute metering; topology-aware; runtime correction; proof of physical work; compute–electricity co-scheduling; computing power network

Statement on Data Conventions and Originality Writing discipline of this paper: 1. No fabrication of quantitative data. All capacity, power, latency and utilization data come from D-PIN Zhangjiang node trial-operation records (August 2026) and vendor specifications, with sources identified individually. 2. Derived values and illustrative calculations are labelled separately. Arithmetic results derived from existing data, such as kW/D-PIN SCU and D-PIN SCU·h/kWh, are labelled “derived values”. Calculations involving prices, costs or investment are labelled “illustrative calculations” and do not constitute commitments. 3. Unverified information is excluded. Parameters, standard identifiers and provisions without authoritative primary sources are not presented as facts through approximation. 4. Originality conventions (a layered statement revised on 2026-10-05). Originality is strictly distinguished at three levels, and claims must not extend beyond their level: (a) Terminology: no claim to priority. “Standard / Standardized Compute Unit” (SCU) has at least five publicly documented uses with different meanings in AI computing: the Standard Compute Unit of Symmetric Research for financial collateral valuation (normalizing heterogeneous GPU clusters and explicitly including workload mix, multi-GPU scaling overhead and energy draw; its specification is machine-verified in Lean and its calibration is anchored to public MLCommons benchmarks; the underlying mathematical line of work appeared in arXiv:2406.19261 in 2024-06, where the unit is Compute Hours (CH); the SCU term and four-part specification appear on the institutional research page, so 2024 denotes the start of the line of work) [33]; the CME / Silicon Data SCU for compute futures (1 SCU = 1×H100 FP16·h, with other chips converted using preset coefficients, 2026-05) [10][34]; Kohlenberg’s static SCU for contract clearing (a four-dimensional weighted dot product, H100 SXM5 = 1.00, 2026-05) [5]; and the “Standard Compute Unit (SCU)” of Tianyi Cloud (China Telecom) (1 SCU defined by the product of single-GPU compute capacity and bandwidth for a reference GPU, with task-dependent dynamic conversion) [49]. There are also two uses of the related term NCU (Normalized Compute Unit) (Revenue Model [50] and COIL [51]). This paper claims no priority for the concept or terminology, and recommends consistently using D-PIN SCU in external communication (Appendix C.3).

2

D-PIN SCU: From Nominal Capacity to Deliverable Compute

(b) Individual components: no claim to priority. Components including weighted normalization, energy-efficiency dimensions, scenario-dependent weights, runtime metering, topology-aware scheduling and metering-pricing coupling have precedents. The normalized “information-energytime” score of ZTE Communications 𝑆 = 𝑤1 (𝐼/𝐼max ) + 𝑤2 (𝜂/𝜂max ) + 𝑤3 (𝑇min /𝑇) already includes energy efficiency and scenario-dependent weights [35]. DataCanvas’s “one degree of compute” (DCU) uses 1 DCU = 312 TFLOPS(FP16) × 1 hour to convert heterogeneous chip inputs and charges for actual consumption [9]. Alibaba’s OSDI 2026 production study documents “high GPU demand does not imply high effective utilization” and GPU undeliverability (stranded GPUs, CPU bottlenecks and topology constraints) [36]. We claim no priority for any individual component. (c) Integrated system: a claim to the complete system and theoretical contribution. As of the search cutoff of 2026-10-05, no identified work jointly treats the closed-form derivation of topology efficiency (Eqs. (9)-(13)), stochastic modelling and identifiability of three runtime factors (Proposition 2), economic binding of metering and verification (the no-arbitrage condition, Eq. (25)), and coupling of metering to electricity-market pricing signals (Eq. (28)) as inseparable parts of one metering unit. An explicit qualification is necessary: the complete SLR in Appendix D newly identified two formally adjacent precedents, Tianyi Cloud’s SCU [49] (multidimensional weighting and task-dependent dynamic conversion) and Agora [44] (runtime metering of three-dimensional resources using hardware performance counters, with usage-based pricing). These precedents further narrow our claim. Novelty is based only on the integration of all four components, particularly the closed-form topology ridge and identifiability argument, rather than on the formal feature of multidimensional weighting with runtime or task-dependent conversion. The contribution is this complete dynamic metering system for distributed real-time scheduling, together with the theoretical identifiability proposition (Proposition 2): runtime deviations are unidentifiable from nominal specifications, making runtime metering necessary for identifiability rather than merely an engineering optimization. Discipline of expression: the manuscript and accompanying external materials must not use “first”, “original” or “the first” to qualify SCU or a metering system named SCU. Use “no corresponding work was identified as of the search cutoff ”, with the comparison table and search-scope statement in Appendix C. The originality claim is governed by the formal comparison in Appendix C. 5. Terminological consistency. Throughout the paper, use D-PIN SCU (D-PIN Standardized Compute Unit), PoPW (Proof of Physical Work), 𝜂topo (topology efficiency factor), KunlunKVS (heterogeneous distributed scheduling kernel), and GPT-Factory (AI Infra operating system). Do not mix abbreviated forms.

1 Introduction 1.1 Background: compute as a measurable and tradable factor of production Structural growth in AI compute demand has transformed computing from an internal IT cost into a factor of production with financial attributes. In May 2026, CME Group and Silicon Data announced compute futures settled against GPU rental-price indices, using the Standardized Compute Unit (SCU) for cross-chip conversion (1 SCU = one H100 running FP16 for one hour; other chips use preset coefficients). The final contract specifies 730 GPU-hours per contract, the average monthly fullload hours of one GPU (365/12 × 24 ≈ 730), listed under NYMEX GPU1 / GPU2 (H100 and B200 rental indices, respectively), cash-settled and pending regulatory approval [10]. On 2026-09-03, Nodal Exchange and Compute Desk announced a competing compute-futures plan based on Compute Desk’s IOSCO/BMR-compliant GPU rental index, covering Hopper and Blackwell, with cash settlement, Nodal Clear clearing and CFTC oversight [56]. In China, DataCanvas developed “one degree of compute” (DCU; 1 DCU = 312 TFLOPS(FP16) × 1 hour), selected among the Ministry of Industry and Information Technology’s 2025 exemplary cases of coordinated new-information-infrastructure development and already used for consumption-based billing in its own and managed AI compute centres [9]. Meanwhile, the compute network has been included among national strategic infrastructure for the 15th Five-Year Plan; compute-electricity coordination appears in the government work 3

D-PIN SCU: From Nominal Capacity to Deliverable Compute

report, establishing integration of compute and electricity dispatch as a policy direction. The technical prerequisite is that compute must be measurable. Without a common, recomputable and trustworthy unit, there is no basis for price discovery, risk hedging or settlement in distributed compute markets.

1.2 Problem: four discontinuities caused by a mismatch in the metering object Existing metering is sufficient in centralized clouds: a single operator manages resources, hardware models are relatively uniform, and scheduling and billing share trusted telemetry. With distributed physical infrastructure, where compute nodes occupy urban buildings, heterogeneous vendor hardware is co-hosted, and electricity is a first-class matching resource, four discontinuities change these assumptions: Discontinuity 1: statistical conventions ≠ scheduling conventions. Statistical conventions (FP32 theoretical peaks converted to EFLOPS, with random checks of electricity and traffic meters) serve aggregate-scale reporting. Quarterly reporting differs from millisecond-to-second scheduling by 7-10 orders of magnitude in update frequency and temporal granularity. Scheduling from such statistics is equivalent to managing live inventory with annual accounts. Discontinuity 2: accounting conventions ≠ delivery conventions. Accounting units (ECU, ACU, SLURM billing weights and standardized compute units) take nominal specifications as input and measure promised resources. Tasks consume actual deliverable compute: interconnect topology determines the multi-GPU communication ridge, thermal throttling and hardware degradation reduce available capacity, and multitenant competition changes instantaneous availability. These differences are systematic bias rather than noise. Discontinuity 3: capability declarations ≠ verifiable facts. In permissionless or weakly permissioned distributed environments, nodes have incentives to overstate resources. Without continuing spot checks, metering becomes self-reported data, whose credibility declines as network openness increases. Discontinuity 4: compute metering ≠ economic settlement. Electricity accounts for one-third to one-half of compute costs. A unit detached from real-time electricity prices, renewable-energy shares and load conditions cannot respond to electricity-market signals. Compute-electricity coordination then remains at the aggregate scheduling level and cannot close an economic loop for individual tasks.

1.3 Contributions We study the D-PIN SCU metering system of D-PIN (Distributed Physical Infrastructure Network for AI Compute) [28] and develop seven contributions (C1-C7) addressing these discontinuities. They form a progressive chain rather than a parallel list: determine what to meter, how to construct the measurement, how to establish trust, and how to interoperate. The four stages are foundation → accurate measurement → trust → integration. The table summarizes the claims, differences from precedents and verification anchors. Layer

Contribution

Foundation

C0 Baseline as Define normalization as a reCME/Silicon Data SCU [10][34], Proposition 3; a specification producible method rather than Kohlenberg SCU [5] and Tianyi Eqs. (6)(7); hardware, and prove origin in- Cloud SCU [49] anchor to specific Section 4.2 variance: replacement of the models, without separating specifibaseline instance preserves all cation from realization or establishrelative results ing re-anchoring invariance C1 Redefining Runtime deviations are uniden- Static SCU, DCU and ECU/ACU Proposition 2; the object tifiable from static specificaexpressions have no time-varying Eqs. (3)-(4); tions, making runtime meterterms and cannot in principle esti- Section 3.3 ing necessary for identifiability mate these deviations

Foundation

Central claim

Difference from precedents

4

Anchor

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Layer

Contribution

Measurement

C2 ClosedDerive topology efficiency from form topology the Roofline ridge in a form awareness that supports derivation, calibration and extrapolation

Measurement

C3 Runtime correction and separate conventions C4 Calibratable weights

Measurement

Trust

Trust

Integration

Central claim

Difference from precedents

Anchor

Symmetric Research SCU declares multi-GPU overhead but gives no public analytic form; scheduling research keeps corrections internal rather than defining them in the unit No identified precedent states the physical billing ceiling as a recomputable hard constraint

Eqs. (9)-(13); Section 4.3

The Physical Upper Bound Proposition 1; Principle constrains billed Eqs. (5)(16)quantities; multiplexing can(20) not exceed it Prior weights are generally emEqs. (21)Calibrate weights using (22); Algosimplex-constrained exponenti- pirical or have undisclosed, nonrithm 1; Secated gradient (entropy mirror reproducible calibration tion 5 descent), with mandatory uncertainty reporting Existing verification addresses cor- Eqs. (23)C5 Metering- Bind spot-check frequency rectness (ZK/TEE) or relies on (26); Section verification to the present value of over6 coupling claiming gains through no ar- trusted platform telemetry, withbitrage, decoupling verification out metering-level economic constraints overhead from scale C6 RecomEqs. (30)End-to-end recomputation, No identified comparable work putable endual-convention discrepancy jointly publishes minimum repro- (32); Section gineering disclosure and a delivered ducibility requirements and dual9; Appendix B validation energy-efficiency metric convention differences as evidence of static-metering insufficiency C7 Standards D-PIN SCU is a schedulingStandards specify what to measure, Appendix C interoperabil- level middle layer between but not how to connect measureity statistical and accounting con- ment to second-scale scheduling ventions

(I) Foundation: redefining the metering object (C1) C1 | Redefining the object. We formally distinguish nominal capacity from deliverable compute, decompose their difference into topology, runtime and behavioural terms (Eqs. (3)-(4)), and prove unidentifiability under nominal observations (Proposition 2). Difference from precedents: static contract-clearing SCU, financial-collateral SCU of Symmetric Research, input-based DCU and cloud ECU/ACU all take nominal specifications or one-off benchmarks as inputs and contain no time-varying terms. They therefore cannot estimate deviations varying with 𝑡. Runtime metering is necessary for identifiability, rather than an optional engineering optimization. This is the theoretical starting point for the other six contributions. (II) Accurate measurement: constructing the meter (C2-C4) C2 | Closed-form topology awareness. A cluster-scale Roofline model expresses multi-GPU interconnect constraints through the ratio between the communication ridge COI∗ = 𝑃peak /𝛽node and workload communication intensity. This replaces empirical efficiency tiers (0.95 / 0.88 / 0.75 / 0.50) with a derivable, calibratable and extrapolatable model (Eqs. (9)-(13)), anchored to NCCL AllReduce scaling measured on the Zhangjiang 8×H100 node (64 MB: 87%; 512 MB: 92%; 2 GB: 93%). Difference from precedents: Symmetric Research SCU “accounts for” multi-GPU scaling overhead in its specification, but does not disclose its analytic form or calibration. Other topology-aware work keeps corrections inside scheduling heuristics rather than incorporating them into the unit definition itself. The topology factor in our formula is externally recomputable. C3 | Runtime corrections and separate conventions. We provide definitions, prediction equations and identification methods for 𝛿𝑇 , 𝛿𝐹 and 𝛿𝐿 (Eqs. (16)-(20)), and the Physical Upper Bound Principle (Proposition 1, Eq. (5)): cumulative billed D-PIN SCU·hours cannot exceed a node’s physical delivery ceiling. Difference from precedents: no identified work states this billing ceiling as a recomputable hard constraint. It prevents the hidden distortion of exceeding physical limits by invoking spatial5

D-PIN SCU: From Nominal Capacity to Deliverable Compute

temporal slice multiplexing, a common weakness of static accounting under oversubscription. C4 | Calibratable weights. A simplex-constrained algorithm fits measured relative throughput using exponentiated-gradient updates (Eqs. (21)-(22), Algorithm 1). Identifiability analysis under dimensional collinearity and regularization guidance turn five-dimensional weights from empirical settings into data-reproducible estimators, with intervals required in published tables. Difference from precedents: previous work generally specifies weights or leaves calibration undisclosed. We include weight uncertainty itself in the disclosure obligations of A6 (recomputability). (III) Trust: verification and credibility (C5-C6) C5 | Coupling metering and verification. D-PIN SCU declarations are coupled to three-layer PoPW to derive a no-arbitrage condition for over-claiming (Eq. (25)), with engineering values for the minimum checking probability, maximum checking cost and proof-overhead bound. Difference from precedents: verification targets computational correctness through comprehensive cryptographic proofs or relies on trusted platform telemetry. Our target is negative expected profit from overclaiming, decoupling verification overhead from compute scale, a prerequisite for scaling to thousands of nodes. C6 | Recomputable engineering validation. End-to-end recomputation uses a Zhangjiang production node (59.5 D-PIN SCU, 10 heterogeneous servers, mixed conventions), yielding 3.02 kW/D-PIN SCU and 0.26 D-PIN SCU·h/kWh. We disclose differences between published empirically calibrated values and nominal-specification projections, minimum publication requirements for A6, and itemby-item verification findings (Appendix B). Difference from precedents: comparable work rarely discloses both minimum recomputability requirements and dual-convention differences as empirical evidence of static-metering insufficiency. (IV) Integration: standards interoperability (C7) C7 | Standards interoperability. Appendix C maps D-PIN SCU dimensions to YD/T 6693-2026 measurement indicators, GB/T 47514-2026 measurement methods and DCU inputs, supporting a scheduling-level middle layer between statistical and accounting conventions. Difference from precedents: standards, including YD/T 6693-2026, specify what to measure but not how to connect measurements to second-scale scheduling and real-time billing. We design this connection. Contribution dependencies: C0 and C1 establish the foundation. C0 defines the scale (the baseline is a method with a replaceable origin); C1 defines the object (deliverable compute rather than nominal capacity). C2-C4 establish accurate measurement, C5-C6 establish trust, and C7 provides interoperability. All four layers are necessary: without C1, construction lacks a foundation; without C2-C4, measurement is inaccurate; without C5-C6, values are untrustworthy; without C7, the system cannot integrate with existing industry structures. Originality boundary (read with item 4 of the preliminary statement): we claim no priority for SCU terminology or individual weighted-normalization components. Precedents include Symmetric Research SCU 2024, CME/Silicon Data SCU 2026, Kohlenberg static SCU 2026, Tianyi Cloud SCU, DataCanvas DCU, ZTE’s information-energy-time score, Agora’s three-dimensional usage pricing, Canonical unit, Setonix energy accounting and patent CN121255573A (Appendix D). Originality is restricted to the integrated system combining runtime identifiability (C1), closed-form topologyridge derivation (C2), and verification-pricing coupling (C5, C7) as inseparable parts of one unit. Tianyi Cloud [49] and Agora [44], newly identified in Appendix D, are formally adjacent through multidimensional weighting and runtime or task-dependent conversion. Our distinction therefore does not depend on these formal features, but on the three-part combination. No corresponding work was identified by 2026-10-05; Appendix C.3 provides the formal comparison.

1.4 Organization Section 2 reviews related work and gaps; Section 3 formalizes the problem and design axioms; Section 4 defines the D-PIN SCU model; Section 5 gives weight calibration; Section 6 develops verification and game-theoretic analysis; Section 7 links pricing; Section 8 describes implementation; Section 9 validates the case study; and Section 10 discusses industry implications for compute-network 6

D-PIN SCU: From Nominal Capacity to Deliverable Compute

integration, distributed pricing, trust and compute financialization, compute-electricity coordination and green compute, and domestic heterogeneous hardware, with their boundaries, conclusions and future work. Appendix A lists symbols; Appendix B discloses empirically calibrated chip baselines alongside nominal projections and verification checks; Appendix C compares standards and precedents; Appendix D provides the protocol and execution records of a PRISMA-style systematic literature search. Compute does not lack units; it lacks a measure of deliverable compute. We advance metering from bookkeeping to a schedulable, verifiable and priceable physical quantity.

2 Related Work 2.1 Statistical and conversion conventions: aggregate reporting National compute statistics use a common conversion method led by the Ministry of Industry and Information Technology and supported by the China Academy of Information and Communications Technology. Under the Action Plan for High-Quality Development of Computing Infrastructure and national standards, operating, under-construction and planned CPU, GPU, FPGA and ASIC capacity is converted to FP32 theoretical peaks, with EFLOPS as the sole dimension. Operators report quarterly; random field inspections cover at least one-tenth of machine rooms, and provincial communications authorities inspect electricity and traffic meters [1][2]. YD/T 6693-2026, Measurement Indicators for Computing Capability of Heterogeneous Resources in Computing Networks (China Communications Standards Association; issued 2026-03-11, effective 2026-06-01) further defines heterogeneous resources and metrics for equipment assessment, network integration and operation [3]. Assessment: these conventions support aggregation, verification and historical comparison. Stability and resistance to manipulation come at the cost of coarse temporal granularity (quarterly reporting), machine-room spatial granularity and a single peak-compute dimension. They answer “how much compute exists in a region”, not “where should this task run now”. They impose aggregate constraints above scheduling-level metering.

2.2 Accounting and pricing units: quotas and contracts Cloud-equivalent units. Early AWS EC2 Compute Units (ECU) defined 1 ECU as the CPU capability of a 2006/2007 1.0-1.2 GHz Opteron/Xeon to compare instance capacity. Rapid hardware changes have shifted AWS towards nominal vCPU conventions [6]. Microsoft Azure Compute Units (ACU) use Standard_A1 = 100 and relative SKU values (for example, Dv3: 160-190 ACU/vCPU), explicitly as guidance only [7]. Shared characteristics: one CPU dimension, nominal definitions, strong dependence on hardware generation, and no runtime state. HPC billing weights. SLURM TRESBillingWeights assigns resource-specific weights converting GPU hours and memory into CPU-hour equivalents (1 CPU core = 1 BU/h; 1 GB RAM = 0.25 BU/h; 1×A100-40GB = 5 BU/h) [8]. The motivation is fair billing in heterogeneous clusters, where GPU performance and costs differ substantially. Shared characteristics: administrator-configured static weights, independent of topology, runtime conditions and workload type. SCU and DCU. In May 2026, Kohlenberg’s A Compute Commodity Clearinghouse defined a static unit sharing the SCU name but with different semantics: a weighted normalized dot product of GPU matrix throughput (BF16), CPU floating-point throughput (FP64), addressable memory and peak memory bandwidth, with weights 0.50 / 0.10 / 0.20 / 0.20. Normalization constant 𝐾 sets NVIDIA H100 SXM5 = 1.00 (𝐾 = 0.50 × 989 + 0.10 × 120 + 0.20 × 80 + 0.20 × 3350 = 1192.5). A memory-architecture coefficient 𝐴 ∈ (0, 1] captures exclusive memory and interconnect topology, and 𝑃SCU = 𝑃raw /SCU produces comparable cross-hardware prices [5]. DataCanvas’s contemporaneous DCU explicitly measures compute inputs rather than a chip-performance scale: 1 DCU = 312 TFLOPS(FP16) × 1 hour. Workload-specific benchmarks calibrate conversion coefficients, outputs are independently measured in tokens, and scheduling and settlement logs support end-to-end au7

D-PIN SCU: From Nominal Capacity to Deliverable Compute

ditability [9]. Multiple meanings of SCU: a fact that must be clarified first. The abbreviation does not have one meaning. Besides contract-clearing SCU [5], at least two independent lines use it. Symmetric Research’s Standard Compute Unit normalizes heterogeneous GPU clusters for financial valuation of datacentre collateral. Its public specification (symres.ai/research) explicitly covers hardware differences, workload mix, multi-GPU scaling overhead and energy draw, with the core economic module verified in Lean and calibration anchored to MLCommons. Its relation to our citation must be specified: the mathematical foundations appear in arXiv:2406.19261 (Kristensen et al., 2024-06), whose unit is Compute Hours (CH) and whose text does not contain “SCU”. The name Standard Compute Unit and four-part specification occur on the institutional page as a subsequent specification within the same line of work. We therefore label 2024 as the start of that line, not the first public use of SCU [33]. The second is the compute-futures pricing unit announced by CME and Silicon Data in May 2026: 1 SCU is one NVIDIA H100’s FP16 capacity over one hour, with preset coefficients for other chips and Silicon Data’s daily GPU on-demand rental-price index as anchor [10][34]. ICE and Ornn also introduced OCPI-linked compute futures on 2026-05-19 [34]; although not named SCU, they represent a parallel standardized-pricing approach. Two related names beyond SCU (new findings from the systematic search that must also be disclosed). The full search in Appendix D identified further similar names with different semantics, included here for disambiguation. The first is the Tianyi Cloud (China Telecom) developer community discussion of cross-domain resource measurement, defining 1 SCU as the product of one reference GPU’s FP16 compute capacity and bandwidth and maintaining task-specific weight vectors to dynamically calculate equivalent SCU during matching instead of fixed conversion [49]. This is the closest formal precedent, sharing the SCU name, multidimensional weighting and task-dependent conversion. Differences are: (1) a two-dimensional multiplicative construction, without memory capacity, interconnect topology and energy efficiency; (2) no **closed-form topology-ridge (COI*) conversion; and (3) no identifiability argument** for runtime deviations under nominal observation or economic binding of checking frequency to over-claiming gains. This makes disciplined avoidance of component-level priority claims particularly necessary. The second comprises two uses of Normalized Compute Unit (NCU): a model-independent unit for AI cost governance based on FLOP-based FBM, emphasizing cross-hardware and cross-model comparability without disclosing normalization details [50]; and COIL, defining 1 NCU = 20 kWh of certified, delivered accelerated computing, normalizing by energy rather than time, requiring actual delivery and independent certification, and excluding idle consumption and cooling losses [51]. Assessment: energy normalization is adjacent to our approach because both reject units defined only by time or peak capacity. Its normalized quantity is energy consumption, however, rather than deliverable compute, without topology/runtime models or an identifiability argument. Existing weighted meters and input units. Weighted normalization already exists. Liu Chaoqing et al. proposed an information-energy-time resource score 𝑆 = 𝑤1 (𝐼/𝐼max ) + 𝑤2 (𝜂/𝜂max ) + 𝑤3 (𝑇min /𝑇) referenced to optimal hardware, normalizing compute, energy efficiency and time to [0, 1] with scenario-dependent weights prioritizing performance, energy saving or responsiveness; it was validated in a “computing-network brain” simulation [35]. DataCanvas DCU uses 1 DCU = 312 TFLOPS(FP16) × 1 hour to convert heterogeneous hardware into measurable, settleable inputs, independently measures token outputs, and bills virtual-container services by actual consumption [9]. Assessment and positioning: these approaches are closest to ours and require precise distinctions. They meter nominal capacity for contracts, quotas or billing: Kohlenberg SCU is a static scalar, DCU an input measure, and CME SCU a preset-coefficient conversion unit. Even DataCanvas CU, which collects runtime data, uses device-resource occupancy (CUDA use, memory use and temperature) rather than deliverable capability under task-topology coupling. Shared gaps are no closed-form topology ridge, no stochastic runtime-deviation model with identifiability, no verification coupling beyond trusted platform telemetry, and no electricity-market coupling. Tianyi Cloud’s Xirang plat8

D-PIN SCU: From Nominal Capacity to Deliverable Compute

form also discusses heterogeneous measurement, dynamic duration estimates, flexible pricing and scheduling [4], but its measurement layer targets common precision without a topology ridge or verification loop. Naming-disambiguation recommendation: at least five semantically different public uses of SCU exist, including Symmetric Research [33], CME/Silicon Data [10][34], Kohlenberg [5], Tianyi Cloud [49], and other static-unit uses, plus two NCU uses [50][51]. We do not recommend bare SCU as our external identifier. The formal name is D-PIN SCU (D-PIN Standardized Compute Unit), with distinctions from namesakes at first use (Proposition 2 in Section 3.3 and Appendix C.3).

2.3 Performance models and benchmarks: comparability The Roofline model, introduced by Williams, Waterman and Patterson (2009), defines attainable performance as the minimum of peak compute and bandwidth multiplied by arithmetic intensity [11]. Cluster-scale extensions add HBM, NVLink and InfiniBand bandwidth roofs and communication operational intensity (COI), total floating-point operations divided by total communication bytes, to represent distributed bottlenecks [12]. This directly supports our derivation of 𝜂topo . MLPerf benchmarks achieve industrial cross-hardware comparability by fixing models, datasets, precision targets and scenarios (Single-Stream / Multi-Stream / Server / Offline) within closed and open divisions [13]. MLPerf Power continuously samples system AC-input power with certified analyzers, reports joules per query and performance per watt, and binds energy to disclosed workloads [14]. Assessment: benchmarks measure relative task-specific capability. Execution and replication costs make them suitable for periodic assessment, not continuous metering. We use them as measurement sources for weight and topology calibration, rather than online meters. Heterogeneous scheduling and fairness. DRF (Dominant Resource Fairness) allocates multiple resource types fairly [15]; Gavel uses heterogeneity-aware scheduling for fair shares [16]; Gandiva_fair uses tickets for cross-user GPU-minute fairness and reclaiming unused quotas [17]; OEF jointly targets strategy-proofness, envy-freeness and efficiency [18]. Assessment: all require a compute measure as input, generally assuming given, trusted metering. We supply this layer: D-PIN SCU is a measurable input to heterogeneous schedulers, with PoPW establishing trust.

2.4 Distributed compute and verifiability: trust DePIN operates through task publication, contribution verification and reward settlement [52]. Examples include Filecoin, mapping actual storage to on-chain credentials through PoRep and PoSt [21], and Helium, mapping wireless coverage at a location through PoC [22]. The central difficulty is mapping off-chain physical facts, including GPU load, coverage and location, to trustworthy on-chain credentials. Three complementary approaches are used: (i) challenge-response, sending randomly seeded known-answer tasks with deadlines and penalizing failure; (ii) redundant computation, distributing a task to multiple workers and detecting dishonest disagreement; and (iii) cryptographic proofs, generating zero-knowledge correctness proofs (RISC Zero zkVM [40], SP1 zkVM [41]) verified on-chain without recomputation. High proof overhead for complex computations favours probabilistic spot checks over step-by-step proofs. TEE anchors (Intel TDX and AMD SEV-SNP [20]) counter hardware impersonation and idle “zombie nodes” reported online. Physical side channels provide another anchor: external GPU power traces classify training, inference and non-AI workloads on NVIDIA H200 with 97% accuracy and macro F1 0.955. Because they do not depend on forgeable or replayable NVML telemetry, this channel can in principle be observed without operator cooperation, independently supporting contribution verification [57]. Assessment: existing DePIN research asks whether computation occurred. PoPW must also ask how fast and whether declared D-PIN SCU agrees with measurements, introducing continuous metering consistency rather than binary task completion. Section 6 develops this contribution. Existing metering-verification-pricing coupling. Gensyn’s From Bundles to Time defines a twosided time-slice market using RepOps reproducibility, Verde verification and checkpointing, with feasibility determined by scheduling rather than budget bundles. It proves existence and uniqueness 9

D-PIN SCU: From Nominal Capacity to Deliverable Compute

of equilibrium prices and efficient greedy matching; pooling and slashing maintain provider honesty [37]. Earlier TEE-anchored metering with blockchain micropayments supported fair outsourcedcomputing markets because both parties have incentives to misreport resource measurements [38]. These meter time quotas or resource usage, not normalized deliverable compute, and do not bind checking frequency to the present value of over-claiming gains in a solvable economic constraint (our Eq. (25)). Large-scale production evidence. Alibaba’s OSDI 2026 ASI study [36] provides large-scale evidence for nominal capacity ≠ deliverable compute: six months of traces from 155,410 GPUs and 81 business units show high demand does not ensure high effective utilization. Idle GPUs are stranded across nodes, lack CPUs or violate network locality, while safety reserves further reduce allocation to 68% (raised to 93% with SpotGPU). Relation to our work: both distinguish allocatable/deliverable capability from nominal specifications and document unavailable GPU capacity. ASI yields cluster characterization and scheduling policies, however, rather than a cross-architecture metering unit coupled to verification and pricing, as indicated in Section 2.5.

2.5 Gap summary Approach

Representative work

Metering object

Topology sensitivity

Statistical conversion

GB/T 47514FP32 theoretical No 2026; T/TAF peak 292-2025; YD/T 6693-2026 [1][2][3][53] Cloud equiva- ECU / ACU Nominal CPU No lents [6][7] capacity HPC billing SLURM TRES Committed reNo weights [8] sources Static comKohlenberg SCU Normalized Partial (copute units [5] nominal capac- efficient ity 𝐴) Financial nor- Symmetric ReNormalized clus- Partial malization search SCU [33] ter capacity (workload mix and multi-GPU overhead) Futures pric- CME / SiliH100·h with pre- No ing con Data SCU set coefficients [10][34] Runtime DataCanvas CU Device occuNo weighted [9]; ZTE triplet pancy / normalunits score [35] ized score Input meaDCU [9] Theoretical peak No surement × time Production Alibaba ASI Effective utiliza- Yes (obcharacteriza- [36] tion served) tion Usage-based Agora [44] ThreeNo multidimendimensional sional pricing measured resource vector Multiresource Canonical unit Discrete thresh- No accounting (PEARC’23) olded combina[45] tions HeterogeSetonix energy Core-hours + No neous energy accounting [46] energy-weighted billing charging rate

10

Runtime correction

Verification Pricing loop linkage

Time scale

No

Spot inspections

No

Quarterly

No

Platforminternal Platforminternal Contract / clearing

No

Billing period Job

No No

No

Price nor- Contract malization term

No

Lean speci- Collateral fication valuation

—

No

Index anchoring

Price index

Contract month

Yes (device- Platform / Dynamic side) / par- simulation billing tial No Settlement- Scenario log audit pricing No — No

Minutes

Billing period Observation period Seconds

Yes (online) Platforminternal

Usage pricing

No

—

Fair billing Job

No

—

Charging rate

Job

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Approach Heterogeneous measurement standard Normalized metering patent Cross-domain measurement Energy normalization Performance benchmarks D-PIN SCU (this work)

Representative work

Metering object

Topology sensitivity

YD/T 60482024 [47]

FLOPS/OPS/ No Hash·s baselines

CN121255573A Normalized No [48] weighted coefficients (1 NCU) Tianyi Cloud Single-GPU com- No SCU [49] pute × bandwidth COIL / NCU 20 kWh of cerNo [51] tified delivered compute Throughput and Partial MLPerf / MLPerf Power energy efficiency [13][14] D-PIN [28] Deliverable com- Yes (𝜂topo ) pute

Runtime correction

Verification Pricing loop linkage

Time scale

No

Tiered No assessment

Assessment cycle

Partial (decay curve)

—

Yes (taskspecific weights) No

Platforminternal

Yes (𝛿𝑇 , 𝛿𝐹 , 𝛿𝐿 )

Yes (PoPW Yes (Unitchecks) Price)

Task Scheduling + billing Dynamic Minutes conversion

IndepenCommodi- — dent certifi- ty pricing cation No (one-off) Submission No Release review cycle Seconds

Gap conclusion: nominal-capacity measurement is mature and standardized. The gap is realtime, verifiable and priceable measurement of deliverable compute, particularly in distributed, heterogeneous and weakly permissioned environments. This is our positioning.

3 Problem Formalization 3.1 Notation and setting Consider a distributed compute network 𝒩 with node set 𝒱. Each node 𝑣 hosts 𝑛𝑣 accelerator chips sharing an interconnect configuration, occupies a defined physical location, and receives power from one or more suppliers. Symbol

Meaning

𝐹, 𝑀, 𝐵, 𝐼

Nominal floating-point capacity (FP16/BF16), memory TFLOPS, GB, GB/s, capacity, memory bandwidth, inter-chip bandwidth GB/s Energy-efficiency coefficient (performance per watt rela- Dimensionless tive to baseline) Five-dimensional weights (𝑑 ∈ {𝐹, 𝑀, 𝐵, 𝐼, 𝐸}), ∑𝑑 𝛼𝑑 = 1, Dimensionless 𝛼𝑑 ≥ 0 Topology efficiency factor Dimensionless Communication operational intensity (operations per FLOP/byte communicated byte) Effective node-level communication bandwidth GB/s Thermal, fault and load corrections Dimensionless Spatial resource fraction and temporal fraction of a slice Dimensionless Chip, node and available D-PIN SCU D-PIN SCU Total deviation (nominal-deliverable) and behavioural Dimensionless deviation (declared-deliverable) Spot-check probability Dimensionless Present value of the penalty for detected over-claiming CNY Over-claiming fraction (𝑆 ̂ = (1 + 𝜉)𝑆) Dimensionless Unit D-PIN SCU price coefficient CNY/(D-PIN SCU·h) Electricity intensity (node power per D-PIN SCU) kW/(D-PIN SCU)

𝐸 𝛼𝑑 𝜂topo COI 𝛽node 𝛿𝑇 , 𝛿𝐹 , 𝛿𝐿 𝜎𝑗 , 𝜔𝑗 𝑆chip , 𝑆node , 𝑆avail 𝜀, 𝜀beh 𝑝 Λ 𝜉 𝑢𝑡 𝜅

Unit

11

D-PIN SCU: From Nominal Capacity to Deliverable Compute

3.2 Six design axioms A compute metering system for distributed scheduling should satisfy the following axioms: A1 Cross-architecture comparability: hardware from different architectures and generations must be comparable on a common scale anchored to a publicly reproducible method. The baseline is a specification (dimension definitions, value-selection rules and re-anchoring rules), rather than a particular hardware model. The baseline instance can be replaced without changing any relative metering result (Proposition 3). A2 Topology sensitivity: the metered value must reflect the constraints that multi-accelerator interconnects impose on deliverable compute, rather than merely score single-chip specifications. A3 Time-varying deliverability: the metered value must vary with thermal, fault and load states, representing what can actually be delivered at the current moment rather than what is nominally attainable. A4 Verifiability against overstatement: claimed values must support independent, low-overhead and unpredictable spot checks, and overstatement must yield no economic benefit. A5 Economic coupling: the metered value must serve directly as a pricing basis and couple to external market signals such as electricity costs and the renewable electricity share. A6 Recomputability: all coefficients and raw inputs must be disclosed so that third parties can independently recompute the results. A6 is an axiom added in this paper beyond the five commonly used in industry. It is required for due diligence on the metering system: if external parties cannot recompute a result, it cannot be verified for contracting, auditing or regulatory purposes, and A4 cannot be fully satisfied.

3.3 Decomposing the deviation between nominal capacity and deliverable compute Define the nominal D-PIN SCU of a node as the metered value determined solely by nominal specifications: 𝑛𝑣

𝑆nom (𝑣) =  𝑆chip,𝑖

(1)

𝑖=1

Define its deliverable D-PIN SCU (during interval 𝑡) as: 𝑆deliv (𝑣, 𝑡) = 𝜂topo ⋅ 𝛿𝑇 (𝑣, 𝑡) ⋅ 𝛿𝐹 (𝑣, 𝑡) ⋅ ⒧1 − 𝛿𝐿 (𝑣, 𝑡)⒭ ⋅ 𝑆nom (𝑣)

(2)

The deviation can then be decomposed into three components: 𝑆nom − 𝑆deliv 𝑆nom  Total deviation 𝜀

= (1 − 𝜂topo ) + 𝜂 topo ⒧1 − 𝛿𝑇 𝛿𝐹 (1 − 𝛿𝐿 )⒭  

(3)

Runtime term

Topology term

The behavioural term is not expressed by equation (3); it is the difference between a node’s claimed value and its true deliverable value: 𝜀beh (𝑣, 𝑡) =

̂ 𝑡) − 𝑆 𝑆(𝑣, deliv (𝑣, 𝑡) 𝑆deliv (𝑣, 𝑡)

(4)

Here, 𝑆 ̂ is the value reported by the node. The topology and runtime terms are systematic errors that can be eliminated or compensated through design, whereas the behavioural term is a strategic error that must be suppressed through verification.

12

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Proposition 1 (physical upper-bound principle, also a billing design constraint): for any node 𝑣 and billing interval [0, 𝑇], the cumulative billed D-PIN SCU-hours satisfy 𝑇

̂ 𝑡) 𝟙 (𝑣, 𝑡) d𝑡 ≤ 𝑆 (𝑣) ⋅ 𝑇 Billed(𝑣, 𝑇) =  𝑆(𝑣, occ nom

(5)

0

Here, 𝟙occ (𝑣, 𝑡) ∈ {0, 1} is the occupancy indicator: it equals 1 when node 𝑣 is occupied by a task at time 𝑡, and 0 otherwise. The same space-time unit of a node cannot be allocated simultaneously to two tenants; the indicator therefore counts mutually exclusive occupancy sets. Clarification of the proposition’s status (important): this expression constrains the billed quantity Billed (the system’s reported and settled value), whereas physical laws constrain only the deliverable quantity 𝑆deliv ; they cannot constrain a reported value. Proposition 1 is therefore precisely a billing design rule: the system uses the available quantity 𝑆avail as the billing basis and does not bill the portion of a node’s claim exceeding 𝑆deliv . Its physical basis, the upper bound on 𝑆deliv ≤ 𝑆nom given by equation (2), justifies the rule. This designation is more rigorous than calling it a physical theorem. Proof outline: by equation (2), 𝑆deliv ≤ 𝜂topo 𝑆nom ≤ 𝑆nom (because 𝛿𝑇 , 𝛿𝐹 ≤ 1, 1 − 𝛿𝐿 ≤ 1 and 𝜂topo ≤ 1). Billing occurs only during occupancy, and occupancy sets are mutually exclusive: the same space-time unit cannot be allocated simultaneously to two tenants. Under the rule that the billing basis is 𝑆avail , the integral therefore does not exceed 𝑆nom ⋅ 𝑇. Significance of Proposition 1: fine-grained slicing and space-time multiplexing can only increase utilization, bringing the integral closer to its upper bound; they cannot exceed that bound. Any metering convention that allows billed quantities to exceed the physical upper bound on the grounds of multiplexing is distorted. This proposition imposes a hard constraint on the recomputation for the Zhangjiang node in Section 9 (equation 27). Formal definition of identifiability (a modelling assumption, to be read with Proposition 2): following the classical system-identification definition in the Bellman–Åström sense, a parameterization 𝜃 is identifiable on observation space 𝒪 if no two distinct parameterizations 𝜃1 ≠ 𝜃2 yield the same observation distribution 𝑃𝜃 (𝑜). Otherwise, 𝜃 is unidentifiable on that observation space. We use the nominal observation space 𝒪nom , whose observations comprise only nominal node specifications and static declarations, excluding time-varying telemetry. The following proposition is a modelling conclusion under this assumption, rather than a universal theorem: it formalizes the modelling fact that the nominal observation space contains insufficient information to represent time-varying deviations. Proposition 2 (unidentifiability of deviation under nominal metering): if 𝜂topo is treated as 1 and 𝛿𝑇 = 𝛿𝐹 = 1, 𝛿𝐿 = 0, so that metering depends only on nominal specifications {𝐹, 𝑀, 𝐵, 𝐼, 𝐸} (equivalently, substituting 𝑃 for 𝐸 in equation (8)), then, when a node experiences thermal throttling, hardware degradation or load occupancy, its metering deviation is 𝜀 ≥ 1 − 𝜂topo 𝛿𝑇 𝛿𝐹 (1 − 𝛿𝐿 ) > 0, and this deviation cannot be identified on 𝒪nom by any observation function of nominal parameters. Proof outline: the nominal parameters {𝐹, 𝑀, 𝐵, 𝐼, 𝐸} are time-invariant constants, whereas 𝛿𝑇 , 𝛿𝐹 , 𝛿𝐿 is a stochastic process. Any function 𝑔(𝐹, 𝑀, 𝐵, 𝐼, 𝐸) whose arguments are exclusively nominal parameters takes the same value at all times and therefore cannot produce a deviation estimate that varies with 𝑡. Consequently, the image of 𝜀 in nominal observation space 𝒪nom is constant, and the deviation is unidentifiable. Significance of Proposition 2: this is the theoretical starting point of the paper. It shows that introducing runtime metering is a necessary condition for identifiability, rather than an engineering optimization. Static compute units, including SCU in reference [5] and DCU in reference [9], are unidentifiable in this sense: they measure commitments rather than delivery.

13

D-PIN SCU: From Nominal Capacity to Deliverable Compute

4 D-PIN SCU metering model 4.1 Dimension vector D-PIN SCU characterizes compute resources with a five-dimensional vector: Dimension

Symbol

Floating-point compute 𝐹 Device memory capac- 𝑀 ity Device memory band𝐵 width Interconnect bandwidth 𝐼 Energy-efficiency coeffi- 𝐸 cient

Unit

Physical meaning

Initial weight 𝛼𝑖

TFLOPS (FP16/BF16) GB

Nominal peak tensor compute of the chip

0.35

Upper bound on supported model and batch sizes Attainable throughput of attention and decoding paths Efficiency of multi-accelerator parallelism and collective communication Relative compute per watt, directly linked to compute–electricity coordination

0.20

GB/s GB/s —

0.25 0.15 0.05

Differences from the existing four-dimensional system: the static SCU in reference [5] uses GPU throughput, CPU throughput, memory capacity and memory bandwidth. Our system removes CPU throughput, which rarely becomes the bottleneck in accelerator-dominated AI training and inference and whose weight of 0.10 is inconsistent with the meaning of AI compute. It adds interconnect bandwidth 𝐼, corresponding to A2 and constituting the most important additional dimension for distributed settings, and the energy-efficiency coefficient 𝐸, corresponding to A5 and coupling compute to electricity economics. The initial weights also differ (see Section 4.2 and the calibration in Section 5).

4.2 Single-chip baseline D-PIN SCU 𝑆chip = 𝛼1

𝐹 𝐹ref

+ 𝛼2

𝑀 𝑀ref

+ 𝛼3

𝐵 𝐵ref

+ 𝛼4

𝐼 𝐼ref

+ 𝛼5 𝐸

(6)

4.2.1 Baseline specification: a method rather than a hardware model The baseline vector r = (𝐹ref , 𝑀ref , 𝐵ref , 𝐼ref , 𝐸ref ) in equation (6) is not taken from any particular model. A reproducible normalization baseline that is not biased by vendor or generation must be defined by a specification comprising the following three rules: Baseline Specification (S1) Dimensions and conventions: the dimension set is fixed as the five-tuple (𝐹, 𝑀, 𝐵, 𝐼, 𝐸); the compute convention is fixed as FP16/BF16 dense peak performance (see the precision-convention normalization principle below). (S2) Valueselection rule: each baseline-vector component must come from a public primary source reproducible across vendors, either an official vendor specification or a reproducible independent measurement. Non-reproducible internal data must not be used. (S3) Reanchoring rule: given a scaling vector 𝜆 = (𝜆𝐹 , 𝜆𝑀 , 𝜆𝐵 , 𝜆𝐼 , 𝜆𝐸 ) > 0, the baseline can be −𝛼 changed to r → 𝜆 ⊙ r, with historical values converted using factor ∏𝑑 𝜆𝑑 𝑑 (Section 4.2.3). Under this specification, the baseline needs a realization of the origin to provide numerical values. We use NVIDIA H100 SXM as the current realization: 𝐹ref = 989 TFLOPS, 𝐼ref = 900 GB/s,

𝑀ref = 80 GB,

𝐵ref = 3350 GB/s,

𝐸ref = 1

Distinguishing the realization from the specification (important): H100 SXM only locates the origin, providing numerical values for equation (7). It is not part of the specification. 14

(7)

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Replacing the realization with a next-generation flagship or the rounded physical quantities in Sections 4.2.3 and 10.3 leaves S1–S3 unchanged and requires only re-anchoring under S3. The choice is motivated by engineering considerations: direct interoperability with existing H100-hour conventions [5][10][34] and independent confirmation of its five-dimensional parameters [23][24], satisfying A6 (recomputability). It is not a theoretical necessity. Proposition 3 in Section 4.2.2 establishes this distinction. Equations (6) and (7), together with the five weights summing to 1, immediately give 𝑆chip (H100) = 1.00, establishing origin consistency. Definition of the energy-efficiency coefficient: 𝐸=

𝐹/𝑃 𝐹ref /𝑃ref

,

𝑃ref = 700 W (H100 SXM TDP)

(8)

Precision-convention normalization principle (important): the convention for 𝐹 directly determines the metering scale. Vendor-rated Tensor Core peaks usually include 2:4 structured sparsity acceleration, whereas the vast majority of real training and inference workloads lack this structure and are bounded by dense peak performance. Using sparse values for sparsity-capable chips and dense values for other chips introduces systematic bias: H100 SXM has sparse and dense peaks of 1979 and 989 TFLOPS, respectively, a 2:1 ratio. We therefore establish the following principle: Convention-normalization principle: throughout the network, the 𝐹 dimension uses FP16/BF16 dense peak performance. If a vendor publishes only a sparse value, divide it by 2 and retain the original convention label in the metering record. This agrees with reference [5], which anchors H100 at the dense value of 989 TFLOPS, and with the FP16 dense convention for training in Chapter 11 of the D-PIN white paper. AMD’s official MI300X comparison page also states that NVIDIA published TF32 Tensor Core performance using sparsity and that AMD divided those values by 2 to obtain non-sparse/dense values for comparison [24]. Vendors thus also apply the divide-by-2 dense conversion, independently supporting our normalization principle from the supply side. Scale behaviour under a convention change (important note): because 𝐹ref and each chip’s 𝐹 occur in the same ratio 𝐹/𝐹ref , the effect on 𝑆chip depends on the scope of the change. Two cases must be distinguished, corresponding to a single-dimension special case of Proposition 3(a) in Section 4.2.2: 1. Synchronized change across the entire table (scale invariance): if the baseline and every chip’s 𝐹 are simultaneously divided by 2 to change from sparse to dense values, each 𝐹/𝐹ref is unchanged, and all 𝑆chip values remain unchanged. The choice of convention therefore changes only the representation of metering records, not the metering results. Dense and sparse conventions are equivalent rescalings when applied consistently across the table. 2. Partial change (mixed conventions and bias): changing only some chips, for example using dense values for domestic chips without sparsity support and sparse rated values for sparsity-capable chips, introduces systematic bias. Its magnitude can reach 100% of that dimension’s weight 𝛼1 . This is the actual risk associated with inconsistent conventions. An engineering consequence follows: aligning Chapter 5 of the white paper with this paper requires only consistency across the entire table, without recalibrating any measured values. Conversely, mixing a sparse H100 value with dense values for other chips systematically overstates H100’s relative value by a factor of 2 in the 𝐹 dimension. The comparisons in Appendix B and Section 9.3 assume consistency across the entire table.

15

D-PIN SCU: From Nominal Capacity to Deliverable Compute

4.2.2 Proposition 3: baseline independence The replaceability of the realization is guaranteed directly by the ratio structure of equation (6), rather than being a rhetorical claim. Proposition 3 (baseline independence / origin invariance) Let the baseline vector be r, the raw value of chip 𝑖 in dimension 𝑑 be 𝑥𝑖,𝑑 , and its normalized value be 𝑣𝑖,𝑑 = 𝑥𝑖,𝑑 /𝑥ref,𝑑 . (a) Convention shift (synchronized scaling of the baseline and entire table): if 𝑥𝑖,𝑑 → 𝜆𝑑 𝑥𝑖,𝑑 and 𝑥ref,𝑑 → 𝜆𝑑 𝑥ref,𝑑 with the same 𝜆, then 𝑣𝑖,𝑑 is unchanged, and 𝑆chip,𝑖 is strictly invariant. (b) Re-anchoring (scaling only the baseline): if only r → 𝜆 ⊙ r changes while chip values remain unchanged, then 𝛼𝑑 𝑆chip,𝑖 →  𝑣𝑖,𝑑 𝑑 𝜆𝑑 In particular, when 𝜆𝑑 ≡ 𝜆 (uniform re-anchoring), 𝑆chip,𝑖 → 𝑆chip,𝑖 /𝜆. All values scale proportionally, so the ratio 𝑆𝑖 /𝑆𝑗 between any two chips is independent of the baseline realization. Proof: (a) cancel 𝜆𝑑 directly. (b) substitute r → 𝜆 ⊙ r into equation (6) to obtain the first expression, and set 𝜆𝑑 ≡ 𝜆 to obtain 𝑆𝑖 → 𝜆1 ∑𝑑 𝛼𝑑 𝑣𝑖,𝑑 = 𝑆𝑖 /𝜆. Because this scaling is consistent across the entire table, ratio 𝑆𝑖 /𝑆𝑗 is unchanged. Corollary 3.1 (fairness): choosing which accelerator equals 1.00 is a unit convention that carries no fairness judgement. It changes no relative metering result and confers no numerical advantage on any vendor. This justifies elevating the baseline from a hardware model to a method. Corollary 3.2 (two costs of re-anchoring): whether re-anchoring changes relative results depends on whether 𝜆 is identical across dimensions: - Convention shift / uniform re-anchoring (all 𝜆𝑑 equal): cost-free. All values scale proportionally and relative results remain unchanged. The sparse-to-dense scale transformation in Section 4.2 is of this type. - Non-uniform re-anchoring (𝜆𝑑 differs across dimensions, for example when adopting rounded physical quantities): relative results change. The effective balance between dimension weights is redistributed, equivalent to changing the metering system. The entire table must be recomputed and 𝛼 redeclared; this change is not cost-free. 4.2.3 Baseline governance and re-anchoring protocol Baselines age: realization models eventually retire and parameters evolve across generations. Baseline governance specifies how this process can occur while preserving historical comparability: 1. Normal operation (unchanged realization): all metering values are directly comparable across periods. 2. Convention shift / uniform re-anchoring: change the convention or units synchronously by a common ratio. By Corollary 3.2, relative results remain unchanged; records need only identify the new unit convention and conversion factor 𝜆. 3. Non-uniform re-anchoring: treat this as a system-version upgrade, recompute the entire table, redeclare 𝛼 and publicly disclose a conversion matrix relating the old and new versions. Conclusion: retirement of the baseline realization does not invalidate the system, a direct benefit of separating specification from realization (Section 4.2.1). When a realization becomes unsuitable, only re-anchoring under S3 is required; the system itself need not be redesigned. Target state (Section 10.3): remove dependence on hardware models by defining r directly as rounded physical quantities expressed in SI units, giving 1 D-PIN SCU an absolute physical meaning that does not drift across generations. This path is structurally analogous to the 2019 SI reform and represents the target state after the standardization path matures; it is not implemented at this stage. 16

D-PIN SCU: From Nominal Capacity to Deliverable Compute

4.3 Topology-aware factor 𝜂topo 4.3.1 Derivation from Roofline The cluster-level Roofline model bounds attainable distributed-workload throughput by the smaller of compute and communication limits [11][12]: 𝑃att = min⒧𝑃peak , 𝛽node ⋅ COI⒭ Here, COI =

Total floating-point operations Total communication bytes

(9)

(FLOP/byte). Define the communication ridge as:

COI∗ =

𝑃peak

(10)

𝛽node

A workload is compute-bound when COI > COI∗ and communication-bound otherwise. The upper-bound form of the topology efficiency factor is therefore: bound 𝜂topo =

𝑃att 𝑃peak

= min ⒧1,

COI COI∗

⒭

(11)

4.3.2 Effective node-level bandwidth For an 𝑛-accelerator node using classical Ring AllReduce, the effective communication bandwidth borne by each accelerator is: ring

𝛽node =

𝑛

𝛽 2(𝑛 − 1) link

(12) ring

8 For example, with 𝑛 = 8 and 𝛽link = 900 GB/s (the order of NVLink 4 / HCCS), 𝛽node = 14 ×900 = ∗ 3 514.3 GB/s, corresponding to COI = 989 × 10 /514.3 ≈ 1923 FLOP/byte. Tree algorithms perform better for small messages, so actual 𝛽node should follow the algorithm-dependent upper envelope (see NCCL [27] for Ring/Tree collective primitives). This method supports extrapolation: interconnect patterns and message-size distributions predict COI∗ without relying on measured tiers for every model. For inter-node IP-routed Ethernet (RoCEv2), congestion control in a lossless network, including DCQCN rate control and ECN marking, substantially affects effective cross-rack bandwidth. The cross-rack component of 𝛽node must therefore be calibrated at the actual congestion-control operating point, rather than theoretical line rate [19].

4.3.3 Declared tiers and measured calibration 𝜂topo has two levels during the node lifecycle: (a) Declared tier (prior). On joining the network, a node declares its interconnect type for scheduling pre-screening and capacity estimation: Interconnect

0 Declared 𝜂topo

Typical 𝛽link

Full NVLink/HCCS interconnection (8 fully connected accelerators) Ring interconnect PCIe Gen5 x16 bridging Loosely connected over the public network

0.95

900 GB/s

0.88 0.75 0.50

400–600 GB/s 64 GB/s unidirectional ≤ 50 GB/s

(b) Runtime calibration. The node periodically runs collective-communication microbenchmarks (AllReduce/AllGather at multiple message sizes) and updates the factor using measured collectivecommunication efficiency 𝐿(𝑚):

17

D-PIN SCU: From Nominal Capacity to Deliverable Compute

𝐿 meas (𝑚∗ , 𝑡)

0 𝜂topo (𝑡) = min⒧1, 𝜂topo ⋅

𝐿 0 (𝑚∗ )

⒭

(13)

Here, 𝑚∗ is the characteristic message size of tasks served by the node: the gradient bucket size in training, with a 25 MB default in the platform training engine GPT-Factory [29]. 𝐿 0 (𝑚∗ ) is the declared tier’s expected linearity at 𝑚∗ , and 𝐿 meas (𝑚∗ , 𝑡) is its measured value (see the table for the definition of 𝐿 as the measured-to-theoretical latency ratio). Measurements from the Zhangjiang 8×H100 node provide a calibration anchor: Message size

Theoretical latency (400G)

Measured latency

Linearity 𝐿

1 MB 64 MB 512 MB 2 GB

0.02 ms 1.3 ms 10.2 ms 41.0 ms

0.05 ms 1.5 ms 11.1 ms 44.3 ms

40% 87% 92% 93%

For characteristic messages of 25–64 MB, measured linearity is 75–87%, increasing from 40% to 75% after gradient-bucket coalescing. The converted factor increases monotonically with message size within 𝜂topo ∈ [0.75, 0.87]. For large messages ≥512 MB, measured values of 92–93% differ from the declared tier of 0.95 by 2–3 percentage points, a reasonable conservative margin. This difference quantifies why declared tiers should be conservative: declared values support scheduling pre-screening, whereas calibrated values support billing and scheduling decisions. Engineering implication: 𝜂topo is a function of chip properties × workload characteristics × interconnect structure, rather than a chip property alone. This explains why static units cannot express it.

4.4 Node D-PIN SCU and slice D-PIN SCU 𝑛

𝑆node = 𝜂topo ⋅  𝑆chip,𝑖

(14)

𝑖=1

For example, a fully interconnected 8×H100 node has 𝑆node = 0.95 × 8 × 1.00 = 7.60 D-PIN SCU. With fine-grained slicing (minimum granularity: 1 GB of device memory + 1 compute unit), slice D-PIN SCU is allocated in proportion to the weighted resources received: 𝑆slice = 𝑆node ⋅



𝛼𝑑 ⋅

𝑑∈{𝐹,𝑀,𝐵,𝐼}

𝑟𝑑,slice 𝑟𝑑,node

,



𝛼𝑑 = 1 − 𝛼𝐸

(15)

𝑑∈{𝐹,𝑀,𝐵,𝐼}

Here, 𝑟𝑑 is the resource quantity in the corresponding dimension. Dimension 𝐸 is excluded from slicing because it is a node-level property; the four remaining weights sum to 1 − 𝛼𝐸 , rather than a preset constant. Equation (15) ensures that total slice D-PIN SCU does not exceed node D-PIN SCU (because ∑𝑑 𝛼𝑑 (𝑟𝑑,slice /𝑟𝑑,node ) ≤ ∑𝑑 𝛼𝑑 < 1), consistent with Proposition 1.

4.5 Runtime correction factors 𝑆avail = 𝑆node ⋅ 𝛿𝑇 ⋅ 𝛿𝐹 ⋅ (1 − 𝛿𝐿 )

(16)

(1) Thermal-throttling correction 𝛿𝑇 . Define it as the measured-to-nominal frequency ratio: 𝛿𝑇 (𝑡) =

𝑓meas (𝑡) 𝑓nom

,

18

𝛿𝑇 ∈ (0, 1]

(17)

D-PIN SCU: From Nominal Capacity to Deliverable Compute

A first-order thermal resistance–capacitance network gives a predictive expression for prescheduling estimation: 𝑇𝑗 (𝑡) = 𝑇amb + 𝑅th 𝑃 + 𝑇𝑗 (0) − 𝑇amb − 𝑅th 𝑃𝑒 −𝑡/𝜏 ,

𝜏 = 𝑅th 𝐶th

(18)

Here, 𝑃 is constant power applied from 𝑡 = 0; time-varying power requires numerical integration. 𝑅th is junction-to-ambient thermal resistance, 𝐶th is thermal capacitance, and 𝑇amb is ambient temperature. The steady-state solution is 𝑇𝑗 (∞) = 𝑇amb + 𝑅th 𝑃, and time constant 𝜏 is the time required to reach 63.2% of the steady-state temperature rise. When 𝑇𝑗 exceeds threshold 𝑇thr , SM frequency decreases according to the vendor DVFS curve, reducing 𝛿𝑇 . The Zhangjiang node uses hybrid liquid and air cooling, with the server hot side connected to the building cooling-water loop. Its power-distribution design capacity is 180 kW relative to a 200 kW specification ceiling, with sufficient thermal headroom and steady-state 𝛿𝑇 ≈ 1. This conclusion applies only to the measured operating conditions of this node and does not imply the same result for other sites. (2) Fault correction 𝛿𝐹 . Conservatively take the smaller of the available device-memory and compute-unit fractions: 𝛿𝐹 = min ⒧

𝑀avail 𝑁cu,avail , ⒭ 𝑀nom 𝑁cu,nom

(19)

Triggers include device-memory ECC row remapping, disabled SM/CU units and link-rate reduction, such as operation at 100G after an increased bit-error rate. Taking the minimum rather than a weighted mean is an unbiased conservative principle: degradation in any single dimension can become the bottleneck, whereas a weighted mean can overestimate deliverable compute. (3) Load correction 𝛿𝐿 . Define it as the fraction of occupied node resources: 𝛿𝐿 = min⒧1,  𝜔𝑗 ⋅ 𝜎𝑗 ⒭,

𝜔𝑗 , 𝜎𝑗 ∈ [0, 1]

(20)

𝑗∈slices

Here, 𝜎𝑗 is slice 𝑗’s resource share in the spatial dimension, relative to the same resource type on the node, and 𝜔𝑗 is its share in the temporal dimension within the metering window. Together they characterize space-time multiplexing. We take min(1, ⋅) because oversubscription may nominally yield ∑𝑗 𝜔𝑗 𝜎𝑗 above 1, whereas the same space-time unit cannot be occupied twice, consistent with ̄ . Proposition 1. Utilization is the time average of 𝜂util = 1 − 𝛿𝐿 , with window mean 𝜂util

4.6 Separating physical and billed D-PIN SCU-hours Following Proposition 1, we explicitly distinguish two quantities: 1. Physical D-PIN SCU-hours: ∫ 𝑆avail (𝑡) d𝑡 ≤ 𝑆nom ⋅ 𝑇, representing the maximum deliverable compute within the window, for capacity planning and scheduling-feasibility assessment. 2. Billed D-PIN SCU-hours: ∫ 𝑆avail (𝑡) ⋅ 𝟙{occupied} d𝑡 ≤ ∫ 𝑆avail (𝑡) d𝑡, representing compute actually consumed and settled. Their ratio is utilization. This separation is necessary: conflating them either treats the physical ceiling as expected revenue, causing overestimation, or bills nominal capacity × wall-clock time, causing overbilling in violation of Proposition 1.

19

D-PIN SCU: From Nominal Capacity to Deliverable Compute

5 Weight calibration and identifiability 5.1 Calibration problem The initial weights (0.35 / 0.20 / 0.25 / 0.15 / 0.05) are based on industry experience and lack a reproducible basis, violating A6. We propose calibration against measured relative throughput. Let the chip-model set be ℳ (|ℳ| = 𝑚) and the task set be 𝒦 (|𝒦| = 𝑘). Let 𝑣𝑖 ∈ ℝ5+ be chip 𝑖’s five-dimensional normalized vector, with each component divided by its reference value; 𝑠𝑖𝑗 be the measured throughput of chip 𝑖 on task 𝑗 normalized to H100; and 𝑤𝑗 be the task weight (∑𝑗 𝑤𝑗 = 1). Calibration minimizes the relative deviation between predicted D-PIN SCU and measured throughput: min  𝑤𝑗  ⒧log 𝑠𝑖𝑗 − log⒧𝑣𝑖 ⋅ 𝛼⒭⒭ 𝛼

𝑗∈𝒦

2

𝑖∈ℳ

(21)

5

s.t. 𝛼𝑑 ≥ 0 (𝑑 = 1, … , 5),

 𝛼𝑑 = 1 𝑑=1

Logarithmic error is used because compute units require scale invariance: relative D-PIN SCU error is the fundamental quantity, whereas absolute error is dominated by larger chips.

5.2 Update algorithm: why logarithmic loss cannot use NMF multiplicative updates First, clarify a common error. Multiplicative updates of the form 𝛼𝑑 ← 𝛼𝑑 ⋅ ⒧∑𝑗,𝑖 𝑤𝑗 𝑠𝑖𝑗 𝑣𝑖,𝑑 ⒭ ⒧∑𝑗,𝑖 𝑤𝑗 𝑣𝑖,𝑑 (𝑣𝑖 ⋅ 𝛼)⒭ are classical non-negative matrix factorization (NMF) rules [26]. They solve linear weighted least squares min𝛼≥0 ∑𝑗 𝑤𝑗 ∑𝑖 (𝑠𝑖𝑗 − 𝑣𝑖 ⋅ 𝛼)2 , which is the basis of their non-negativity and monotonic-descent properties. Objective (21), however, uses squared logarithmic loss, for which this rule does not apply: it neither guarantees descent nor qualifies as non-negative least squares, because logarithmic residuals are not NLS. Section 5.1 uses logarithms for scale invariance of the metering unit (A6), whereas linear loss is dominated by larger chips. Using the NMF rule would therefore contradict the stated rationale. Appropriate update: exponentiated gradient (entropic mirror descent). The standard approach to the logarithmic objective under simplex constraints is Exponentiated Gradient (EG), or mirror descent with entropy as the distance-generating function [42][43]. Let the gradient of objective log 𝑠𝑖𝑗 − log(𝑣𝑖 ⋅ 𝛼 (𝑡) ) (𝑡) (𝑡) (21) at 𝛼 be 𝑔𝑑 = −2 ∑𝑗∈𝒦 𝑤𝑗 ∑𝑖∈ℳ 𝑣𝑖,𝑑 . The update is 𝑣𝑖 ⋅ 𝛼 (𝑡) 𝛼𝑑(𝑡+1) =

𝛼𝑑(𝑡) exp⒧−𝜂𝑡 𝑔𝑑(𝑡) ⒭ (𝑡) ∑5𝑑 ′ =1 𝛼𝑑(𝑡) ′ exp⒧−𝜂𝑡 𝑔𝑑 ′ ⒭

,

𝜂𝑡 > 0

(22)

Equation (22) inherently preserves 𝛼 ≥ 0 and ∑𝑑 𝛼𝑑 = 1 through normalization by its denominator. With step size 𝜂𝑡 chosen by backtracking line search using the Armijo criterion, objective (21) is monotonically non-increasing and converges to a stationary point in the relative interior (𝛼𝑖 ≥ 𝛿 > 0, 𝑣𝑖 ⋅ 𝛼 ≥ 𝛿 min𝑑 𝑣𝑖,𝑑 > 0), where the objective is smooth. Difference from NMF multiplicative updates: NMF updates apply only to linear loss and are not used here; their proper attribution is the original NMF paper [26].

20

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Algorithm 1: D-PIN SCU weight calibration (exponentiated gradient / entropic mirror descent) Input: five-dimensional normalized vectors {v_i}, measured throughput matrix {s_ij}, task weights {w_j}, initial α^(0) (empirical values as the entropic mirror-descent starting point), initial step size η_0, convergence tolerance ε_tol, maximum iterations T_max Output: calibrated weights α* 1 for t = 0 … T_max: 2 Compute five-dimensional gradient g_d^(t) using the expression before (22), weighting log residuals 3

η_t ← backtracking line search (Armijo: halve η_0 until the objective decreases)

4

α_d^(t+1) ∝ α_d^(t) · exp(−η_t · g_d^(t)); normalize Σα = 1

5

if ‖α^(t+1) − α^(t)‖₁ < ε_tol: break

6 Bootstrap-resample {s_ij} to estimate confidence intervals for α* 7 return α*

Recommended task set: training (LLM pretraining-step and fine-tuning-step throughput), inference (Offline throughput and latency-constrained QPS in Server scenarios), and collective communication (effective AllReduce bandwidth). The first two can use public MLPerf-type submissions [13]; the last uses node microbenchmarks (equation 13).

5.3 Collinearity and identifiability The five-dimensional vectors exhibit substantial collinearity. 𝐹 and 𝐵 are strongly correlated on mainstream accelerators because higher tensor compute is accompanied by higher device-memory bandwidth. 𝐹 and 𝐸 are also positively correlated because new generations improve both compute and energy efficiency. Collinearity inflates the variance of least-squares estimates of 𝛼 and undermines the physical interpretation of individual weights. Mitigation measures: 1. Regularization: add 𝜆‖𝛼 − 𝛼 (0) ‖22 (ridge-type) to the objective, using the empirical initial values as a prior to suppress weight drift with small samples. 2. Dimension merging (when samples are insufficient): merge (𝐹, 𝐵) into a compute–bandwidth composite dimension, summing their weights, and separate them after more data accumulate. 3. Uncertainty reporting: report 𝛼̂ with Bootstrap confidence intervals or asymptotic variance, and include intervals in published tables. This is itself part of A6. 4. Sensitivity disclosure: report 𝜕𝑆chip /𝜕𝛼𝑑 so readers can assess dependence on an individual weight.

5.4 Calibration–recomputation loop: measured calibration versus nominal-specification projection Conventions in this section (consistent with Appendix B): our externally published values use measured calibration (Appendix B.2-a), namely 𝑆chip obtained from internal platform benchmarks and actual-workload weighting. They cannot be independently recomputed from public vendor specifications. A separate comparison set is projected from public nominal vendor parameters (Appendix B.2-b) to test whether static nominal specifications reproduce the published values: Chip NVIDIA H100 SXM NVIDIA H200 SXM

Published 𝑆chip (measured calibra- Projection (public nominal parametion) ters)

Relative difference

1.00 (defined value, selfconsistent) 1.14

1.00

0

1.26

+10.5%

21

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Chip AMD MI300X Ascend 910B Muxi Xiyun C500 (PCIe) Hygon K100 series

Published 𝑆chip (measured calibra- Projection (public nominal parametion) ters)

Relative difference

0.89 0.74 0.68

1.55 0.51 0.47

+74.2% −31.1% −30.9%

0.42

See Appendix B.3 (series convention; conflicting specifications)

—

Interpreting these differences: 1. The differences are themselves part of the argument. If a publicly recomputable nominal convention existed, they should be zero. Their presence shows that published values do not arise solely from nominal specifications but include internal measured calibration, potentially proprietary/measured throughput, workload-specific weighting or supply-chain conventions. This illustrates that public nominal parameters alone cannot reproduce deliverable-compute metering; measured calibration (Sections 5.1–5.2) and runtime correction (Section 4.5) are required. 2. The differences have opposite directions and are concentrated in domestic models: H200 and MI300X projections are above published values, whereas Ascend 910B and Xiyun C500 projections are below them. This indicates model-specific calibration information rather than a common scale error, requiring measured data for explanation. Xiyun C500’s key inputs have been settled through public vendor channels, comprising official product pages and a public third-party database. Recomputing equations (6)–(8) gives 0.47 (interval [0.42, 0.47]), −30.9% relative to 0.68. Ascend 910B differs by −31.1% (projected [0.50, 0.52] when 𝐹 has a ±6% range), a comparable gap. Both domestic projections are below published values, while both international projections are above them. This may reflect more conservative nominal tiers for domestic chips or platform calibration compensating for architectural differences. Internal calibration records must establish the cause; no causal claim is made here. 3. The differences cannot be attributed to erroneous parameter selection. Appendix B.3 provides critical supporting evidence: AMD’s official specifications fully confirm MI300X’s Infinity Fabric bandwidth of 896 GB/s and FP16 dense performance of 1,307 TFLOPS, and H200/H100 TDP consistency is confirmed. With correct inputs and a transparent algorithm, the remaining +74.2% difference must arise from calibration itself. This is the data-level manifestation of nominal unidentifiability (Proposition 2). 4. Published conventions must explicitly disclose that external recomputation is unavailable. To avoid due-diligence misunderstandings, every use of the published values must carry the statement that they are measured calibrations and cannot be recomputed from vendor specifications; this is included in the note to Appendix B.2-a. 5. Items to close before production: (a) archive internal calibration reports as A6 evidence (B-6); (b) calibrate each model using Algorithm 1 (exponentiated gradient) and publish 𝛼̂ with Bootstrap intervals (B-7); (c) define the power-measurement boundary for the case node’s 180 kW and confirm the implied PUE (B-8); (d) use Muxi Xiyun C500 (PCIe form factor) and Hygon K100 series, with public K100/K100-AI specification conflicts detailed in B-4; (e) Muxi Xiyun C500 key inputs have been settled through public vendor channels [39], including official Chinese/English pages and flopper.io: public values are 𝐹 = 240 TFLOPS, 𝑀 = 64 GB and 𝑃 = 350 W; 𝐵 takes the public upper bound of 1,800 GB/s, and 𝐼 uses 384 GB/s from a same-vendor generational reference. The nominal projection is 0.47 (interval [0.42, 0.47], taking the upper bound; see row B-4 in B.3). Conclusion: the published-versus-projected table is evidence for the methodology rather than a disclosure of defects. It quantitatively supports the central proposition that static nominal specifications are insufficient for metering deliverable compute.

22

D-PIN SCU: From Nominal Capacity to Deliverable Compute

6 Verification loop: coupling D-PIN SCU with PoPW 6.1 Declared–measured consistency protocol Each node declares its D-PIN SCU capacity 𝑆 ̂ on joining the network and undergoes continuous spot checks during operation. Define the metering consistency deviation as: 𝜀beh (𝑣, 𝑡) =

̂ 𝑡) − 𝑆 𝑆(𝑣, deliv (𝑣, 𝑡)

(23)

𝑆deliv (𝑣, 𝑡)

(Equations (23) and (4) define the same quantity 𝜀beh ; (𝑣, 𝑡) explicitly denotes its space-time dependence for use in this section.) Three-layer Proof of Physical Work (PoPW) provides spot checks [28]: Proof layer

Spot-check content

Criterion

Compute proof

Lightweight (4096² FP16 GEMM, returning result hash) / heavyweight (MobileNetV2 classification) / training (4-layer Transformer, 10 steps) UDP flow tests (multiple sources, cross-rack, through intermediate switches) RTT triangulation + Wi-Fi fingerprinting + TEE anchoring

Return within deadline with 5 min / 1 h / 1 matching result hash d

Bandwidth proof Location proof

Frequency

Measured throughput ≥ 6h declared bandwidth × 90% Deviation ≤ 50 km with 15 min matching fingerprint

Key design: compute proof verifies whether declared capacity is achievable, rather than merely whether computation is occurring. Challenge parameters are generated by the verification committee within 1 second before issuance using Commit-Reveal and threshold signatures, preventing precomputation. Verifiers are elected by VRF, with expected count ⌈√𝑁⌉ + 3 (at least 5) and geographic constraints: verifiers at one physical location cannot exceed 40% of the committee. Total proof overhead is kept within 0.5% of node capacity: lightweight challenges 0.3%, heavyweight 0.1%, training 0.06% and bandwidth proof 0.05%, far below the compute waste of conventional PoW consensus.

6.2 No-arbitrage condition for overstatement Let true deliverable capacity be 𝑆 and the overstated claim be 𝑆 ̂ = (1 + 𝜉)𝑆, with overstatement magnitude 𝜉 ≥ 0, unit D-PIN SCU price coefficient 𝑢 and billing-window length 𝑇. Undetected overstatement yields gross gain 𝜉𝑆𝑢𝑇. Let spot-check frequency 𝑝 denote the probability of selection per unit time, single-check detection probability 𝑞 depend on challenge randomness and verifier count, and punishment present value Λ include lost future earnings from reputation reset and blacklisting. The expected punishment is 𝑝𝑞Λ. The net expected gain is therefore: 𝐺(𝜉) = 𝜉 ⋅𝑆⋅𝑢⋅𝑇 −  Gross gain

𝑝 ⋅𝑞⋅Λ 

(24)

Expected punishment

The no-arbitrage condition requires non-positive net expected gain, 𝐺(𝜉) ≤ 0: 𝑝⋅𝑞⋅Λ ≥ 𝜉⋅𝑆⋅𝑢⋅𝑇

(25)

Equivalently, the minimum spot-check probability is: 𝑝 ≥

𝜉⋅𝑆⋅𝑢⋅𝑇 𝑞⋅Λ

23

(26)

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Discussion: 1. 𝑝 is proportional to 𝜉: larger overstatements require more frequent checks. This supports tiered spot checks, dynamically adjusting 𝑝 by reputation: fewer checks for highly reputable nodes and more for nodes under observation. 2. Λ should greatly exceed single-window revenue 𝑆𝑢𝑇 so that 𝜉 = 𝑂(1) is unprofitable even at small 𝑝. For Zhangjiang, 𝑆 = 59.5 D-PIN SCU, 𝑢 ≈ 1.5 CNY/(D-PIN SCU·h) (illustrative calculation, electricity component only; Section 7.1), and 𝑇 = 24 h give daily revenue of approximately 2.4 × 103 CNY. Taking Λ as annualized lost revenue from permanent exclusion (illustratively, approximately 8.8 × 105 CNY), 𝑝 ≳ 6 × 10−4 satisfies no-arbitrage for 𝜉 = 0.2 and 𝑞 = 0.9. This is far below the intensity of the current lightweight challenge every 5 minutes, indicating substantial economic deterrence. 3. Sensitivity to punishment conventions (added): the expression takes Λ as annualized revenue lost through permanent exclusion (∼ 8.8×105 CNY). With no stake and weak admission controls, if Λ includes only stake slashing (1–2 orders of magnitude lower, taking Λ ∼ 103−104 CNY), then for the same 𝜉 = 0.2 and 𝑞 = 0.9, the minimum 𝑝 rises to approximately 5×10−2 ∼ 5×10−1 . Checks must become about two orders of magnitude more intensive. Thus, enforceable punishment, through KYC identity-based admission and reputation commitment, is a prerequisite for low-cost verification, consistent with the candid qualification below. 4. This analysis assumes enforceable punishment, meaning the network can refuse node admission. In a fully permissionless network, Λ reduces to stake slashing and condition (25) must be rewritten using stake size. D-PIN combines no deposit, KYC identity-based admission and reputation mechanisms. Enforceability relies on binding identities during admission, an assumption requiring continued deployment validation.

6.3 Comparison with zero-knowledge approaches Full cryptographic proofs of computational correctness, such as zkVM toolchains RISC Zero [40] and SP1 [41], are theoretically strongest, but stepwise proofs of large-model training or inference impose unacceptable overhead. Industry therefore commonly combines probabilistic spot checks with TEE anchoring [20]. We take the same position while adding a metering argument: D-PIN SCU must verify the upper bound on deliverable capacity, rather than the correctness of every computation. Checks should therefore aim to make the expected gain from overstatement negative (equation 25), rather than cover all computation. Decoupling verification overhead from compute scale is a prerequisite for expansion to thousands of nodes.

7 Pricing linkage: UnitPrice and compute–electricity coordination 7.1 Pricing function Task compute costs follow the D-PIN pricing structure [28]: Cost = 𝑆required × Duration × 𝑢𝑡

(27)

We expand 𝑢𝑡 explicitly as a function of electricity cost, renewable electricity share, load and reputation: 𝑢𝑡 = ⒧𝜋 𝑡 ⋅ 𝜅 ⋅ (1 − 𝜌𝑡 𝛾)⒭ ⋅  Electricity cost

1

⋅ ⒧𝑐0 + 𝑐1 (1 − Rep)⒭ 𝜂util (𝑡)   Reputation/risk

(28)

Utilization

Here, 𝜋𝑡 is real-time electricity price (CNY/kWh); 𝜅 is electricity intensity (kW/D-PIN SCU, node power per D-PIN SCU); 𝜌𝑡 is the renewable electricity share; 𝛾 is its discount coefficient (default 0.3); 𝜂util is node utilization; Rep is normalized reputation; and 𝑐0 , 𝑐1 are base-price and risk-premium coefficients. 24

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Dimensional consistency: 𝜋𝑡 ⋅𝜅 has units (CNY/kWh) × (kW/D-PIN SCU) = CNY/(D-PIN SCU·h), consistent with 𝑢𝑡 . Without 𝜅, (CNY/kWh) × … cannot dimensionally yield CNY/(SCU·h). For Zhangjiang, 𝜅 = 180/59.5 = 3.02 kW/D-PIN SCU (Section 9.2 and equation (29)), so 𝜋𝑡 𝜅 is the electricity cost per D-PIN SCU-hour. Constraints: 𝑢𝑡 > 0 prohibits negative prices; 𝑢𝑡 is monotonically non-increasing in 𝜌𝑡 (renewable discount, 𝜌𝑡 ↑⇒ (1 − 𝜌𝑡 𝛾) ↓); and 𝑢𝑡 is non-increasing in 𝜂util because higher utilization spreads fixed costs. Signs and monotonicity: expressing the renewable term as 1/(1 − 𝜌𝑡 𝛾) and adding a separate renewable penalty (1 + 𝛽(1 − 𝜌𝑡 )) makes the composite factor increase with 𝜌𝑡 (𝜌 = 0/0.5/1 → 1.10/1.24/1.43 when 𝛾 = 0.3, 𝛽 = 0.1), directly contradicting the non-increasing constraint. We therefore use one renewable discount factor (1−𝜌𝑡 𝛾), consistent with Section 10.1(4), and avoid a renewable weight 𝛽 conflicting with bandwidth symbol 𝛽node /𝛽link (equations (9), (12)). Cross-document symbol synchronization: the renewable scheduling weight in white-paper §8.6 has been changed from 𝛽 to 𝛾, the same parameter with default 0.3. Only its functional form differs: scheduling uses bonus 𝑊green = 1 + 𝛾 ⋅ GreenRatio, and pricing uses discount 𝑢𝑡 ∝ (1 − 𝜌𝑡 𝛾). Both documents explain it as one renewable-incentive-intensity parameter, eliminating duplicate names and values. Dimensional check against electricity costs: the Zhangjiang data (59.5 D-PIN SCU, 180 kW and weighted electricity price 0.53 CNY/kWh) give the electricity-cost lower bound 180 kW

× 0.53 CNY/kWh 59.5 D-PIN SCU = 3.02 kW/(D-PIN SCU) × 0.53 CNY/kWh

𝑐𝐸 =

(29)

= 1.60 CNY/(D-PIN SCU·h) Allocation convention (required reading): equation (29) allocates costs over nominal capacity, using static 59.5 D-PIN SCU as the denominator. Allocating over actual delivery, 33,437 D-PIN SCU-hours in the first month (equation (32)), gives 180 × 720 × 0.53/33,437 = 2.05 CNY/(D-PIN SCU·h), 28% higher. We use 1.60 as the cost lower bound for 𝑢𝑡 under nominal capacity, answering the theoretical minimum at full-load delivery for pricing checks. Actual electricity cost per delivered unit should instead use 2.05 CNY/(D-PIN SCU·h). This includes only electricity, excluding depreciation, networking, operations, maintenance and taxes, and is a cost lower bound for 𝑢𝑡 and an anchor for pricing checks. Label: derived value, illustrative calculation, not a price commitment.

7.2 Separating input-side and output-side metering The system strictly distinguishes two metering categories: 1. Input side (D-PIN SCU): deliverable compute occupied, for scheduling, quotas and settlement. 2. Output side (tokens / completed tasks): useful output delivered, for service quality and valuebased pricing, such as tokens/s and tokens/J. These must not be conflated, consistent with reference [9]. Input metrics must be workloadindependent to remain comparable in heterogeneous scheduling; otherwise the same D-PIN SCU produces different outputs across tasks and fairness loses meaning. Output metrics must be workloaddependent to capture user value. Conflation leaves the scheduler with incomparable objectives, impairing both fairness and efficiency.

25

D-PIN SCU: From Nominal Capacity to Deliverable Compute

7.3 Constraints and manipulation risks Risk

Mechanism

Mitigation

Electricity-price manipulation

False node price declarations inflate charges

Use third-party electricity trading/metering data; nodes may only submit renewable certificates, verified against credentials Cap the utilization term in 𝑢𝑡 , for example ≤ 1.3; the platform absorbs the excess Weight reputation increments by task value, rather than count Price caps + regional benchmark prices + anomaly detection

Manufactured utiliza- Artificially reducing utilization tion increases 1/𝜂util Reputation farming Low-value tasks inflate success rates Cross-node price collu- Nodes coordinate price increases sion

8 System implementation 8.1 Architectural position Within D-PIN’s six-layer architecture, the metering system lies between the compute abstraction and scheduling layer and the protocol and verification layer. It supplies a comparable scale to the scheduler, depends on resource-layer telemetry, exchanges consistency credentials with protocollayer PoPW, and exchanges electricity-price and renewable signals with the economic layer. Its scheduling implementation is the two-level KunlunKVS architecture: GlobalScheduler (Python) parses cross-cluster intent and dispatches tasks, while Cluster Scheduler (Go) orchestrates node slices, with zero-overhead passthrough in a single cluster. D-PIN SCU provides a common cost-function input across five modes: vGPU, physical, distributed inference, distributed training and hybrid scheduling.

8.2 Metering timing and consistency 1. Telemetry collection: compute (SM frequency, utilization and device-memory occupancy), power, temperature and link state, sampled every 1–10 s. 2. Aggregation pipeline: Kafka streaming aggregation and ClickHouse real-time queries; dashboard latency < 5 s and 90-day historical access. 3. Metering window: configurable 1 min billing windows; 𝛿 factors use time-weighted means, and slice occupancy is aggregated over mutually exclusive sets, ensuring Proposition 1. 4. Consistency anchor: node declarations are written to the protocol layer and bound individually to PoPW check records. Any declaration change triggers a new heavyweight challenge.

8.3 Boundaries with ecosystem components In-house development covers four layers: metering, abstraction, topology conversion and verification coupling. Container orchestration (Kubernetes/Argo), inference engines (vLLM/SGLang/ TensorRT/ONNX) and training frameworks, including ms-swift, are ecosystem components. D-PIN SCU requires only standard telemetry interfaces, such as NVML/DCGM and NPU-SMI-type interfaces, and collective microbenchmarks; upper-layer frameworks require no modification, a prerequisite for heterogeneous deployment. The system runs on the GPT-Factory AI Infra operating system [29]. Platform model components, including the KunlunBaize model line [30], belong to the ecosystem/platform layer alongside orchestration and inference engines and are not metering objects in this paper.

26

D-PIN SCU: From Nominal Capacity to Deliverable Compute

9 Case validation: Zhangjiang Science Gate node 9.1 Configuration and conventions The Zhangjiang Science Gate T1/T2 sites are among D-PIN’s first production nodes; T1 is retrofitted and T2 newly built, and they are independent nodes. T2 occupies about 600 m² of reserved office space on floor 18. Commercial electrical capacity increased from 80 kW to 200 kW using the existing dual mains feeds, with approval taking 3 weeks. Hybrid liquid/air cooling connects server hot sides to the building water loop and reuses existing HVAC ducts on the cold side, without an industrial cooling tower. Vibration-damping mats are installed in the rack area, and floor loading was checked against 800 kg/m². The total interval from contract signing to first-node power-on was 6 weeks: 3 weeks for in-stock equipment procurement and 3 weeks for construction. Hardware configuration: 10 heterogeneous GPU servers: 4 imported (2 with 8×NVIDIA H20, 1 with 8×AMD MI300X and 1 with 8×AMD MI308X) and 6 domestic (2 with 8×Muxi Xiyun C500 and 4 with 8×Ascend 910B); 2 Leaf switches (32×400G ports); 2 Spine switches (64×400G ports); 2 storage nodes (100 TB all-flash NVMe); 200 kW UPS and 50 kWh lithium-battery storage. Operational data (trial operation, August 2026): Metric

Measured value

Node availability Mean GPU utilization Training-task P99 scheduling latency Inference P99 latency (Llama-3-70B) Weighted electricity price Node power

99.2% (excluding planned maintenance) 78% 14 ms 62 ms (including network transmission) 0.53 CNY/kWh (after peak/off-peak coordinated scheduling) Power-distribution design capacity 180 kW (specification ceiling 200 kW; IT-basis measurement ≈ 54.5 kW; see note) 59.5 D-PIN SCU (mixed conventions; see note)

Total node compute

Power-measurement boundary (explicit statement): 180 kW is power-distribution design capacity, the convention adopted here, at the mains entry point of T2’s compute area, including servers, switches, storage, cold-side cooling and distribution/UPS losses. Under this boundary, total accelerator TDP is 8 × (750 + 750 + 400 × 2 + 350 × 2 + 400 × 4) = 36.8 kW for 1×8×MI300X, 1×8×MI308X, 2×8×H20, 2×8×C500 and 4×8×910B. A whole-server factor of about ×1.4, including CPU, motherboard and fans, gives ≈ 51.5 kW; networking and storage bring IT power to ≈ 54.5 kW. The ≈125.5 kW difference from 180 kW is cooling and distribution-loss headroom, implying PUE ≈ 3.3 at this full configuration. National-standard check: mandatory GB 40879—2021 limits data-centre PUE to ≤ 1.5 (grade 2 ≤ 1.3). The Green and Low-Carbon Data Centre Development Action Plan (NDRC Environment and Resources [2024] No. 970) further requires newly built or expanded large/ultra-large centres to reach PUE ≤ 1.25 by the end of 2025 and national hub nodes ≤ 1.2 [54][55]. Implied PUE 3.3 exceeds every grade limit and cannot represent operating power under this project’s compliance conditions. Thus 180 kW denotes design capacity, 90% of the 200 kW ceiling with expansion headroom. IT power of 54.5 kW and PUE ≤ 1.25 imply site-level measured power of approximately 68 kW. Every use of 3.02 kW/D-PIN SCU and 0.26 D-PIN SCU·h/kWh retains this designcapacity convention; the former represents kilowatts of capacity per D-PIN SCU, rather than a kilowatt-hour energy intensity. On the IT basis (≈54.5 kW), the metrics become 0.92 kW/D-PIN SCU and 0.85 D-PIN SCU·h/kWh; on the standards-adjusted site basis (≈68 kW), 1.14 kW/D-PIN SCU and 0.68 D-PIN SCU·h/kWh. The boundary has been inferred from national standards (B-8: inferred under national standards). If internal records differ, all derived values here must be updated accordingly. Total-node-compute convention (required reading): 59.5 D-PIN SCU is a mixedconvention total: (1) measured calibration / published values: AMD MI300X 6.76, 27

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Muxi Xiyun C500 2×5.17 (upper bound), and Ascend 910B 4×5.62; (2) specification projections (‡ rows): NVIDIA H20 2×5.73 = 11.46 and AMD MI308X 8.50, neither yet having internal platform benchmark records. The consistent calibrated subset totals 39.58 D-PIN SCU. Important: MI308X belongs to the same silicon family as MI300X, yet its projected value (8.50) exceeds MI300X’s published value (6.76). This is a convention difference rather than a performance difference; rows cannot be compared across conventions. It directly exemplifies the partial-change bias warned of in Section 4.2 and reproduces nominal unidentifiability (Proposition 2) at node level. Before formal publication, H20 and MI308X require internal calibration, followed by recomputation of all derived values in this section.

9.2 End-to-end recomputation and consistency checks (1) Recomputing node D-PIN SCU. Apply equation (14) using the row-specific conventions of Appendix B.2-a, primarily published measured calibrations, with NVIDIA H20 and AMD MI308X as ‡ (𝑛×𝑋) specification projections. Let 𝑆node be the node value for an 𝑛-accelerator subnode of model 𝑋: (8×MI300X) (8×MI308X) (8×H20) 𝑆node (Zhangjiang) = 𝑆node + 𝑆node + 2 𝑆node (8×C500) (8×910B) + 2 𝑆node + 4 𝑆node

= 6.76 + 8.50 + 2 × 5.73 + 2 × 5.17 + 4 × 5.62

(30)

= 6.76 + 8.50 + 11.46 + 10.34 + 22.48 = 59.5 D-PIN SCU (2) Physical upper-bound check (application of Proposition 1). Use topology-adjusted node capacity 𝑆node (Zhangjiang) as the upper-bound base, a tighter bound than nominal capacity 𝑆nom ⋅ 𝑇 in equation (1). Using 𝑆nom = 8 × (0.89 + 1.12 + 2 × 0.75 + 2 × 0.68 + 4 × 0.74) = 62.6 gives upper bound 62.6 × 720 = 45,072 without changing the conclusion: Physical D-PIN SCU·hmax = 𝑆node (Zhangjiang) ⋅ 𝑇 = 59.5 × 720 = 42,868 D-PIN SCU·h

(31)

Here, 𝑇 = 720 h, a 30-day billing window. First-month billed throughput is approximately 33,000 D-PIN SCU-hours, and ̄ Billedfirst month = 𝑆node (Zhangjiang) ⋅ 𝑇 ⋅ 𝜂util = 59.5 × 720 × 0.78 = 33,437 ≈ 3.3 × 104 D-PIN SCU·h

(32)

̄ (𝜂util = 0.78 uses measured mean utilization from Section 9.1; sufficient thermal headroom and no fault degradation justify time means 1 − 0.78 for 𝛿𝑇 = 𝛿𝐹 = 1 and 𝛿𝐿 , consistent with equation (16).) Thus billed quantity = physical ceiling × measured utilization, satisfying Proposition 1 (33,000 < 42,900) and the utilization convention. This confirms that billing neither exceeds the physical ceiling nor counts nominal capacity × wall-clock time as delivered compute. (3) Metrics derived from equations (31) and (32). Derived metric

Calculation

Result

Status

Power per unit compute

180 kW/59.5 D-PIN SCU

3.02 kW/D-PIN SCU 0.26 D-PIN SCU·h/kWh 1.60 CNY/(D-PIN SCU·h) 2.2× ~ 3.1×

Derived value

Delivered energy efficiency 33,437 D-PIN SCU·h/(180 × 720 kWh) Electricity-cost component 3.02 × 0.53 Utilization improvement over industry

78%/35% ~ 78%/25%

28

Derived value Illustrative calculation Derived value (industry baseline 25–35%)

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Meaning of delivered energy efficiency (D-PIN SCU·h/kWh): this couples compute and electricity at the metering layer, making standardized compute delivered per kWh a comparable, recomputable and assessable operational metric. It can connect to macroeconomic conventions such as 3–4 CNY of economic output per 1 CNY invested in compute [1], but their dimensions and conventions differ entirely and must not be conflated. (4) Consistency of topology-factor calibration. From characteristic messages (25 MB gradient buckets, 75% linearity after coalescing) to large messages (512 MB–2 GB, 92–93%), measured collective efficiency on the 8×H100 node differs from the declared tier of 0.95 by 2–20 percentage points. Larger differences for smaller messages agree with NCCL startup overhead [27]. This supports the necessity of equation (13): declared tiers and calibrated values must be used separately, the former for conservative scheduling pre-screening and the latter for accurate billing and scheduling decisions.

9.3 Computational consistency audit: published values versus nominal projections The A6 self-audit is recorded in Section 5.4 and Appendix B. It juxtaposes two conventions: measured-calibration published values (Appendix B.2-a, the external disclosure baseline, explicitly not recomputable from vendor specifications) and projections from public nominal parameters (Appendix B.2-b). Audit findings: 1. H100 (defined baseline): fully self-consistent. 2. H200 / MI300X / Ascend 910B / Muxi Xiyun C500: projected-versus-published differences of +10.5% / +74.2% / −31.1% / −30.9%. 3. AMD MI308X (added; no published measured calibration): projected 𝑆chip = 1.12 (node 8.50) can only be compared consistently with MI300X’s projected 1.55, yielding −27.8%. Comparing it incorrectly with MI300X’s published 0.89 yields +25.7%. Cross-convention comparisons within one silicon family reverse the conclusion, directly reproducing Proposition 2 within the family. 4. Parameter evidence (Appendix B.3): AMD officially confirms MI300X 𝐼 (896 GB/s) and 𝐹 (1,307 TFLOPS dense), as well as H200/H100 TDP consistency (700 W). Ascend 910B key parameters agree with the third-party academic teardown by CSET Georgetown [31], except for a 6.0% difference in 𝐹, disclosed as a teardown estimate with a ±6% interval. The projected interval [0.50, 0.52] remains approximately −30% below the published value even at its upper bound. Muxi Xiyun C500 key inputs are settled through public vendor channels [39]: FP16/BF16 dense 240 TFLOPS, 64 GB HBM2E and maximum board power 350 W are public values. Public memorybandwidth values conflict at 1.2/1.8 TB/s; we take 1,800 GB/s. MetaXLink per-link bandwidth is unpublished; 384 GB/s uses a same-vendor generational reference. Equations (6)–(8) give 𝑆chip = 0.47 (interval [0.42, 0.47]), −30.9% relative to 0.68 (PCIe form factor). Hygon uses Hygon K100 series, because public K100/K100-AI specifications conflict; the exact series model must follow internal calibration records (B-4). Conclusions and requirements: external recomputability (A6) is partly established but incomplete: 1. Established: single-chip normalized vectors and weighted formulas are fully public, and the H100 baseline is self-consistent. Official specifications confirm MI300X/H200 key inputs. Public vendor channels and a third-party public database confirm Muxi Xiyun C500 key inputs [39]; its projected 0.47 is externally recomputable, with 𝐵 and 𝐼 disclosed through intervals/generational references and upper-bound selection. 2. Incomplete: published measured calibrations cannot be reproduced from public specifications, and weights remain empirical initial values. 3. Closure path: (a) archive internal calibration reports as A6 evidence; (b) run Algorithm 1 and publish 𝛼̂ with Bootstrap intervals; (c) model and parameter conventions have converged on 29

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Xiyun C500 (PCIe; public vendor inputs closed, with 𝐵 / 𝐼 disclosed as intervals and generational references) and Hygon K100 series. This section provides methodological evidence, rather than an admission of error: it quantitatively shows that static nominal parameters alone cannot reproduce deliverablecompute metering. This is the empirical basis for a measured-calibration loop. The evidence excludes erroneous parameter selection as an alternative explanation: officially confirmed inputs and transparent formulas still yield projections substantially different from published values, attributing the deviation to calibration and supporting Proposition 2 at the data level.

9.4 Comparison with benchmark and industry conventions Dimension

D-PIN SCU (Zhangjiang measurements)

Centralized-cloud baseline

GPU utilization

78%

25–35%

Scheduling P99 latency Billing convention

14 ms

Delivered energy efficiency Metering granularity

Explanation

Measured utilization × effective capacity 0.26 D-PIN SCU·h/kWh

Combined effect of fine-grained slicing and heterogeneous pooled scheduling — Measured intent-aware scheduling; target < 20 ms Instance specifications × The former satisfies Proposition 1; wall-clock time the latter does not Metric not established Added in this paper

≤ 1 min (telemetry 1–10 s)

Billing period (hour/month)

Difference of 2–5 orders of magnitude

Relationship to statistical conventions: D-PIN SCU and EFLOPS statistics are complementary. EFLOPS describes regional totals; D-PIN SCU describes current delivery. Appendix C maps between them, with D-PIN SCU as an intermediate layer between statistical and scheduling conventions.

9.5 Limitations 1. Single-node evidence and mixed conventions. The case covers one production node (59.5 D-PIN SCU, 10 heterogeneous servers), insufficient to validate the distributions of 𝜂topo and 𝛿 across thousands of nodes. Metering consistency in large cross-domain clusters with weak synchronization remains unverified. The total also mixes conventions: 3 servers (1×8×MI308X and 2×8×H20) lack internal calibration records and use vendor-specification projections, unlike the measured calibrations for the remaining 7 (Section 9.1 note). MI308X’s projected 8.50 exceeding same-family MI300X’s published 6.76 is a convention effect and cannot establish their relative actual performance. 2. Incomplete data-based weight calibration. The algorithm in Section 5 has not been run on a complete measured-throughput matrix; current 𝛼 remains the empirical initial value with a regularization prior. 3. Insufficient behavioural evidence. The expectation-based no-arbitrage analysis in equation (25) excludes risk preferences, collusion and punishment delays (arbitration periods). Enforceability assumes KYC admission. 4. Comparability boundary of the unit. D-PIN SCU measures inputs and promises no output rate. Different workloads yield substantially different outputs at the same D-PIN SCU. Hardware selection still requires task benchmarks, such as MLPerf submissions [13]; D-PIN SCU complements them at scheduling level and cannot replace them. 5. Compliance and data boundaries. Cross-domain distributed scheduling involves cross-border data and latency constraints, which are not examined here and should be addressed in a dedicated compliance chapter. 30

D-PIN SCU: From Nominal Capacity to Deliverable Compute

10 Industry implications, conclusions and outlook 10.1 Industry implications of D-PIN SCU A metering unit is both a technical convention and infrastructure for markets: it defines what can be traded, the delivery units and dispute resolution. D-PIN SCU therefore changes the metering basis on which compute enters markets, beyond simply establishing a unit. This section examines the industry consequences of the four gaps in Section 1.2, then discusses the domestic heterogeneous ecosystem and its boundaries. (1) Compute-network integration and scheduling: an intermediate layer between statistics and scheduling. National compute statistics convert theoretical peaks to EFLOPS and update quarterly, while scheduling operates in milliseconds to seconds, a 7–10-order-of-magnitude gap with no executable bridge (gap 1). D-PIN SCU’s minute-level granularity (telemetry 1–10 s) bridges them: Appendix C.2 maps to YD/T 6693—2026 indicators, and scheduling and billing share a real-time convention. Compute-network integration thus gains a common-source metering foundation for statistics, scheduling and billing, moving from capacity aggregation to operational networks. This corresponds to the inclusion of compute networks in national strategic infrastructure during the 15th Five-Year Plan. (2) Distributed-compute pricing and market formation: pricing deliverable capacity rather than nominal specifications. Building-level nodes, heterogeneous deployments and idle compute have been difficult to price because the metering object is misaligned (gap 2): buyers see nominal specifications but receive capacity reduced by topology, throttling and contention. D-PIN SCU explicitly decomposes deviations within the unit, tracing both nominal and delivered compute. Zhangjiang provides representative evidence: 78% utilization versus centralized-cloud 25%–35% (Section 9.4), and delivered energy efficiency of 0.26 D-PIN SCU·h/kWh. Deliverable-compute metering gives idle distributed resources credible units for market entry. (3) Trust and compute financialization: runtime correction for delivery units. Weakly permissioned markets require verifiable contributions (gap 3). Coupling D-PIN SCU with PoPW gives an executable economic constraint (equation (25)), decoupling verification overhead from compute scale and supporting open networks with thousands of nodes. Financially, CME and Silicon Data announced compute futures in May 2026 using standardized compute units (SCU) for cross-chip conversion: 1 SCU = 1×H100 FP16-hour, with preset factors for other chips [10][34]. Final contracts specify 730 GPU-hours per contract, average monthly full-load operation of one accelerator, listed under NYMEX codes GPU1 (H100) / GPU2 (B200), with cash settlement [10]. Preset factors are static, whereas D-PIN SCU supplies runtime-corrected delivery units, a more defensible metering basis for delivery standards of indices and forward contracts. Compute thereby moves from aggregated hardware specifications to standardized credentials of deliverable capacity. (4) Compute–electricity coordination and green compute: electricity signals at task level. Electricity accounts for 1/3 to 1/2 of compute costs. Decoupling units from prices and renewable shares leaves coordination at the macro-scheduling layer (gap 4). Equation (28) couples unit prices to electricity cost, renewable share, load and reputation, anchored by a dimensionally consistent electricitycost lower bound. Green compute can thus be priced and incentivized at the metering layer: renewable discounts and reputation incentives enter unit prices directly, without external subsidies. Coordination extends from scheduling to metering, consistent with national policy. (5) Domestic heterogeneous ecosystem: lowering metering barriers to a common market. Nominal-specification gaps between domestic accelerators and international flagships have long been equated with competitiveness gaps. D-PIN SCU’s normalization, measured calibration and standards mapping change this relationship: chips need fair conversion within a normalized system, rather than first matching flagship nominal specifications. Appendix B’s dual-convention disclosure applies the same five-dimensional normalization and calibration to H100, H200, MI300X and Ascend 910B within one comparable coordinate system. This is a metrological prerequisite for usable, comparable and tradable domestic compute and reduces multi-vendor pooling costs.

31

D-PIN SCU: From Nominal Capacity to Deliverable Compute

(6) Boundaries of these implications. These implications depend on two internal conditions: DPIN SCU measures inputs, promises no output rate and cannot replace task benchmarks (Section 9.5); and engineering evidence comes from one node (59.5 D-PIN SCU), with distributions across thousands of nodes unverified. Realization also depends on three external conditions: standardization, including adoption of Appendix C.2 by standards bodies; enforceable verification, through KYC admission and punishment; and a compliance framework for cross-domain scheduling. Until these mature, D-PIN SCU is more precisely a scheduling-level metering intermediate layer, rather than a replacement for statistical or accounting conventions. Industry implications in one sentence: D-PIN SCU transforms compute from hardware that can be counted into capacity that can be scheduled, verified and priced, providing a metrological prerequisite for compute as a production factor.

10.2 Conclusions We propose and formalize a dynamic D-PIN SCU metering system addressing a fundamental question in distributed heterogeneous networks: how to meter deliverable compute rather than nominal capacity alone. The main conclusions are: 1. Misalignment of the metering object concerns identifiability, rather than engineering precision. Proposition 2 proves that topology and runtime deviations are unidentifiable in an observation space limited to nominal specifications. Runtime metering is therefore a necessary condition for identifiability, rather than an optional optimization. 2. Topology awareness admits a closed-form Roofline construction. The communication ridge COI∗ = 𝑃peak /𝛽node (equation 10) turns engineering tier tables into a derivable, extrapolatable and calibratable model, anchored by measured AllReduce linearity on 8×H100. 3. The physical upper-bound principle imposes a hard billing constraint. Proposition 1 establishes that slicing and space-time multiplexing can only improve utilization; billing cannot exceed 𝑇 ̂ ∫0 𝑆(𝑣, 𝑡) 𝟙occ (𝑣, 𝑡) d𝑡 ≤ 𝑆nom (𝑣) ⋅ 𝑇, with the tighter 𝑆node ⋅ 𝑇 used in Section 9. This closes a class of billing distortions through recomputation (Zhangjiang: 59.5 × 720 × 0.78 ≈ 3.3 ×10,000 D-PIN SCU-hours). 4. Published-versus-projected differences provide empirical evidence of static-convention insufficiency. Appendix B reports +10.5%/+74.2%/−31.1%/−30.9% for H200/MI300X/Ascend 910B/Muxi Xiyun C500. Appendix B.3 confirms the key inputs, demonstrating the need for a measured-calibration loop. 5. Metering must couple to verification and pricing. The no-arbitrage condition (equation 25) links spot-check probability to overstatement and punishment present value. Pricing (equation 28) couples metering to electricity markets, with the illustrative lower bound of 1.60 CNY/(D-PIN SCU·h) as a dimensional-consistency anchor. 6. The baseline can be formalized as a method, with results independent of its realization. Proposition 3 proves origin invariance: convention shifts preserve values strictly, uniform re-anchoring scales the entire table proportionally, and every pairwise chip ratio remains invariant. Choosing the accelerator assigned 1.00 is thus a unit convention, rather than a fairness judgement. The system can migrate smoothly across hardware generations without breaking historical continuity (Sections 4.2.1–4.2.3). At industry level: the five conclusions above lead to one judgement: for compute to become a tradable production factor, its unit must extend beyond hardware specifications to deliverable capacity. D-PIN SCU offers distributed markets a common unit that supports scheduling, verification and pricing, and bridges statistical and accounting conventions at scheduling level (Section 10.1), rather than merely adding another unit name.

32

D-PIN SCU: From Nominal Capacity to Deliverable Compute

10.3 Outlook 1. Automatic data-driven weight calibration: integrate Algorithm 1 into a continuous benchmark pipeline for quarterly rolling calibration of 𝛼 and interval publication. 2. Online learning of topology factors: train a lightweight predictor of 𝜂topo (𝑚∗ , 𝑡) from production collective-communication measurements to replace tier tables. 3. Standards interoperability and standardization: use Appendix C to promote bidirectional mapping with YD/T 6693—2026 and establish a scheduling-level metering intermediate layer for network integration and trading. 4. Metering–finance interface: as a deliverable-compute measure, D-PIN SCU is suited to underlying units of compute indices and forward contracts. Future work should study weighted indices, regional price bases and futures-contract units. 5. Target baseline paradigm: from realization anchoring to unit anchoring (C0). H100 SXM currently realizes the origin, but will retire; each non-uniform replacement requires table-wide recomputation under Section 4.2.3. The target is independence from every hardware model, defining r as rounded SI-expressible physical quantities, such as 𝐹ref ≡ 103 TFLOPS, 𝑀ref ≡ 102 GB, 𝐵ref ≡ 3 × 103 GB/s, 𝐼ref ≡ 103 GB/s and 𝑃ref ≡ 103 W, giving 1 D-PIN SCU an absolute physical meaning independent of hardware generations. This parallels the 2019 SI reform, replacing the kilogram artefact with the Planck constant: modern baselines move from artefacts to constants. Because this is non-uniform re-anchoring (Corollary 3.2), it requires recomputation and redeclaration of 𝛼 and should be implemented by standards bodies after the standardization path matures, rather than at this stage. Closing statement: compute lacks a measure of deliverable capacity, rather than another unit. Only when metered values can be scheduled, verified and priced does compute become a production factor beyond aggregated hardware specifications.

Appendix A Symbols Symbol

Meaning

Unit

𝑆chip , 𝑆node , 𝑆slice , 𝑆avail

Chip / node / slice / available D-PIN SCU

D-PIN SCU

𝑆nom , 𝑆deliv 𝑆required , 𝑇

Nominal / deliverable D-PIN SCU Task compute demand / billing-window length Five-dimensional weights (𝑑 ∈ {𝐹, 𝑀, 𝐵, 𝐼, — 𝐸}, ∑𝑑 𝛼𝑑 = 1) Baseline vector 𝑥ref,𝑑 / re-anchoring vector Dimensiondependent 𝜆𝑑 Topology efficiency / declared tier / — Roofline upper bound Peak compute / attainable throughput FLOP/s Communication operational intensity / FLOP/byte communication ridge Effective node-level / link-level communica- GB/s tion bandwidth Expected linearity / measured linearity / — / — / byte characteristic message size Thermal / fault / load correction factors —

𝛼𝑑 r, 𝜆 0 bound 𝜂topo , 𝜂topo , 𝜂topo

𝑃peak , 𝑃att COI, COI∗ 𝛽node , 𝛽link 𝐿 0 (𝑚), 𝐿 meas (𝑚, 𝑡), 𝑚∗ 𝛿𝑇 , 𝛿𝐹 , 𝛿𝐿 𝜎𝑗 , 𝜔𝑗 ̄ 𝜂util , 𝜂util

Spatial resource share / temporal share of slice 𝑗 Instantaneous / window-mean utilization

33

First occurrence

Equations (6)(14)(15)(16) D-PIN SCU Equations (1)(2) D-PIN SCU / h Equations (27)(31)

— —

Equation (6) Equation (7); Sections 4.2.1–4.2.3 Equations (2)(13)(11) Equation (9) Equations (9)(10) Equations (9)(12) Equation (13) Equations (16)(17)(19)(20) Equation (20) Section 4.5, equation (32)

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Symbol

Meaning

Unit

First occurrence

𝜀, 𝜀beh , 𝜀tol

Total deviation / behavioural deviation / Algorithm 1 tolerance

—

𝑣𝑖 , 𝑠𝑖𝑗 , 𝑤𝑗

Equations (3)(4)(23), Algorithm 1 Equation (21)

Normalized five-dimensional vector / mea- — sured relative throughput / task weight Slice / node resource quantity in dimension DimensionEquation (15) 𝑑 dependent Weights at step 𝑡 / gradient component / — Equation (22) EG step size Spot-check frequency / detection probabil- — / — / CNY / Equations (24)(25) ity / punishment present value / overstate- — / CNY ment / net expected gain CNY/(D-PIN Equation (28) Unit price / electricity price / electricity SCU·h), etc. intensity / renewable share / renewable discount / base price / risk-premium coefficient / reputation Renewable-incentive intensity (default 0.3), Dimensionless Equation (28) the same parameter as 𝑊green in whitepaper §8.6, with a scheduling bonus and pricing discount Occupancy indicator — Equation (5)

𝑟𝑑,slice , 𝑟𝑑,node 𝛼 (𝑡) , 𝑔𝑑(𝑡) , 𝜂𝑡 𝑝, 𝑞, Λ, 𝜉, 𝐺(𝜉)

𝑢𝑡 , 𝜋𝑡 , 𝜅, 𝜌𝑡 , 𝛾, 𝑐0 , 𝑐1 , Rep

𝛾 (cross-document)

𝟙occ (𝑣, 𝑡)

Appendix B Five-dimensional parameters and substitutions (recomputability appendix) Status of this appendix: all inputs are disclosed as required by A6. Values labelled illustrative calculations are not commitments.

B.1 Normalization baseline: specification and current realization (H100 SXM) Parameter

Value

Source

𝐹ref

989 TFLOPS (FP16/BF16 dense)

𝑀ref 𝐵ref 𝐼ref 𝑃ref Initial 𝛼

80 GB 3,350 GB/s 900 GB/s 700 W (TDP) (0.35, 0.20, 0.25, 0.15, 0.05)

NVIDIA H100 SXM specifications; divide the vendor’s 2:4 sparse value, 1979 TFLOPS, by 2 under normalization [23]. Independent vendorside support: AMD explicitly converts NVIDIA sparse values to nonsparse/dense by dividing by 2 on its MI300X comparison page [24] Same source [23] Same source [23] Same source (NVLink 4) [23] Same source [23] Industry-experience values, pending Algorithm 1 calibration (see B-7)

Convention-consistency reminder: by the scale behaviour in Section 4.2, 𝐹ref and every chip’s 𝐹 must use the same convention. This section and the entire table use dense values. Sparse-only vendor values must first be divided by 2, with their original convention retained in records. Realization statement: the table gives the current realization of the origin. Under Section 4.2.1, it is one instance of S1–S3 and can be replaced through Section 4.2.3. Proposition 3 ensures that uniform re-anchoring, including convention shifts, preserves all relative results.

34

D-PIN SCU: From Nominal Capacity to Deliverable Compute

B.2 Chip baselines: published measured calibration and nominal projections The two conventions are disclosed separately; their relationship provides empirical support for the paper’s central proposition. B.2-a Published convention: measured calibrations (external disclosure baseline) These platform-measured calibrations come from node benchmarks and actual-workload weighting, corresponding to white-paper Section 5.6. They cannot be independently recomputed from public vendor specifications, the key property of this section (Section 5.4). 𝑆chip (measured calibration)

Chip

NVIDIA H100 1.00 (defined baseSXM line) NVIDIA H200 1.14 SXM NVIDIA H20 SXM 0.75 ‡

AMD MI300X AMD MI308X

0.89 1.12 ‡

Ascend 910B 0.74 Muxi Xiyun C500 0.68 (PCIe) Hygon K100 series

0.42

𝑆node (8 fully interconnected accelerators)

Calibration method and date

7.60

Defined value

8.66

Internal benchmarks

5.73 ‡

‡ Public vendor-specification projection, not measured calibration (B.2-b, B.3/B9) 6.76 Internal benchmarks 8.50 ‡ ‡ Official vendor-specification projection, not measured calibration (B.2-b, B.3/B10) 5.62 Internal benchmarks 5.17 (upper bound; requires Internal benchmarks (topology conven4-accelerator-domain calibra- tion in note [39]) tion; see note) 3.19 Internal benchmarks

Convention statement (mandatory for external disclosure): these measured calibrations describe actual deliverable compute under internal platform benchmark conditions and cannot be independently recomputed from nominal vendor specifications. Node values other than Xiyun C500 use 𝑆node = 0.95 × 8 × 𝑆chip . C500 must be listed separately (important): official Chinese and English pages state that MetaXLink supports only 2- or 4-accelerator high-speed interconnection [39]. Thus 4 fully interconnected accelerators are the hardware maximum; a fully interconnected 8-accelerator domain is physically unavailable. The listed 5.17, calculated using 0.95 × 8, is a theoretical cross-domain upper bound. Actual 𝑆node requires calibration for 4-accelerator domains and lies within [ 4×0.95×0.68, 5.17 ] = [ 2.58, 5.17 ]. Before formal publication, close B-6 (calibrationrecord archiving), B-7 (weight calibration) and B-8 (power boundary, added) (B.3). Two ‡ rows, NVIDIA H20 SXM and AMD MI308X, are not measured calibrations. Neither has internal benchmark records; 𝑆chip and 𝑆node are projections from vendor specifications via equations (6)–(8): public specifications for H20 (B.2-b, B-9) and official specifications for MI308X (B.2-b, B-10). Section 9 includes these projections with row-specific convention labels, making the Section 9.1 total mixed-convention. Until internally calibrated, these rows must neither serve independently as external disclosure baselines nor be conflated with other rows’ measured calibrations. B.2-b Comparison convention: independent public nominal projections (method validation, not published values) To test whether static nominal specifications reproduce production values, five-dimensional initial values are independently projected from vendor nominal parameters under B.1. Xiyun C500 uses official public pages and a third-party database [39]; MI308X uses the official specification sheet, 35

D-PIN SCU: From Nominal Capacity to Deliverable Compute

because public aggregator values are unusable (B-10). This table is not for external publication, but only for the comparisons in Sections 5.4 and 9.3. 𝐹 (TFLOPS, dense)

𝑀 (GB) 𝐵 (GB/s)

𝐼 (GB/s)

𝑃 (W)

𝐸 (equation Normalized 8) vector 𝑣

NVIDIA H100 SXM

989

80

3,350

900

700

1.000

NVIDIA H200 SXM

989

141

4,800

900

700

1.000

NVIDIA H20 SXM

148

96

4,000

900

400

0.262

AMD MI300X

1,307

192

5,300

896

750

1.233

AMD MI308X

233

192

5,300

896

750

0.220

376 ± 6% [third-party academic teardown estimate] Muxi Xiyun 240 [thirdC500 (PCIe, party public confirmed compilation] form factor)

64

1,600

392

400

0.665

64

(0.243, 0.800, 0.47 ([0.42, 0.537, 0.427, 0.47] when 𝐵 0.485) = 1,200)

—

≈384 [un- 350 published; samevendor generational reference] — —

0.485

Hygon Series convenK100 series tion; conflicts in B-4

1,200– 1,800 [conflicting third-party values; upper bound used] —

—

—

Chip

Ascend 910B

𝑆chip (projected)

(1.000, 1.000, 1.00 1.000, 1.000, 1.000) (1.000, 1.763, 1.26 1.433, 1.000, 1.000) (0.150, 1.200, 0.75 1.194, 1.000, 0.262) (1.322, 2.400, 1.55 1.582, 0.996, 1.233) (0.236, 2.400, 1.12 1.582, 0.996, 0.220) (0.380, 0.800, 0.51 ([0.50, 0.478, 0.436, 0.52] at 𝐹 0.665) interval endpoints)

—

Xiyun C500 substitution notes: official product pages confirm Xiyun C500, a full-height, full-length, dual-slot PCIe board, maximum power 350 W, and MetaXLink support for 2 or 4 accelerators [39]. 𝐹 = 240 TFLOPS (FP16/BF16 dense, third-party public compilation); the official 280 TFLOPS value applies to the OAM form factor, outside our PCIe convention. 𝑀 = 64 GB HBM2E is official. Public 𝐵 conflicts between 1.2 and 1.8 TB/s, absent from the official page; we take 1,800 GB/s. 𝐼 is unpublished: third-party records list 7 MetaXLink ports without per-link bandwidth. We use 384 GB/s, referencing the same vendor’s C600 generation. Substitution into equations (6)–(8) gives 𝑆chip = 0.35(0.243)+ 0.20(0.800)+0.25(0.537)+0.15(0.427)+0.05(0.485) = 0.085+0.160+0.134+0.064+ 0.024 = 0.468 ≈ 0.47, −30.9% relative to 0.68; at 𝐵 = 1,200 the lower bound is 0.42. An order-of-magnitude transcription error in public sources (caution): some third-party comparison tables print C500 memory bandwidth as 18 TB/s, an order of magnitude above the physical scale of 4096-bit HBM2E: 4096 bit × 3.6 Gbps ÷ 8 ≈ 1.84 TB/s. This likely misprints 1.8 TB/s. It is one reason for retaining the 1,200–1,800 GB/s interval in 𝐵 rather than using one third-party value [39]. Node-level topology constraint (direct evidence for C2): official Chinese/English pages state MetaXLink support for 2- or 4-accelerator high-speed interconnection, and the C500 server page specifies 4-accelerator fully interconnected topologies, with 16-GPU and standard 8-GPU server configurations [39]. Accordingly, flopper.io identifies an 8×C500 36

D-PIN SCU: From Nominal Capacity to Deliverable Compute

PCIe server whose MetaXLink connects pairs or groups of four, rather than one eightaccelerator domain, consistent with full-height, full-length PCIe boards [39]. Thus 4accelerator full interconnection is the hardware ceiling; full 8-accelerator interconnection is physically unavailable. Eight-accelerator nodes communicate across domains through PCIe/Host, with actual 𝜂topo substantially below 0.95. The final-column node value 3.58 is an upper bound, with 4-accelerator-domain lower bound 4 × 0.95 × 0.47 = 1.79 and interval [1.79, 3.58]. This illustrates Proposition 2: nominal chip specifications, including topology and per-link bandwidth, do not determine node-level deliverable compute. Node efficiency is a cluster property requiring Roofline derivation (equations 9–13) and measurement. By comparison, the same chip’s OAM form factor has 280 TFLOPS / 450 W and supports 8-accelerator full interconnection, outside our PCIe convention. Substitution example (H200 SXM): 𝑆chip = 0.35(1.000) + 0.20(1.763) + 0.25(1.433) + 0.15(1.000) + 0.05(1.000) = 0.350 + 0.353 + 0.358 + 0.150 + 0.050 = 1.26 Comparison of the two conventions: Chip

Projected 𝑆chip (public nominal)

Published 𝑆chip (measured calibration)

Relative difference

Node-value difference

H100 SXM H200 SXM H20 SXM ‡

1.00 1.26 0.75

0 +10.5% —

7.60 / 7.60 9.58 / 8.66 5.73 / —

MI300X MI308X ‡

1.55 1.12

1.00 1.14 — (no internal measured calibration) 0.89 — (no internal measured calibration) 0.74 0.68 0.42

+74.2% —

11.77 / 6.76 8.50 / —

−31.1% −30.9% Within projected interval

3.88 / 5.62 3.58 / 5.17 — / 3.19

Ascend 910B 0.51 Muxi Xiyun C500 (PCIe) 0.47 Hygon K100-AI (third0.32–0.47 party specification projection)

Percentage-difference convention: relative differences use the three-significant-digit projected values published in the table, with 0.47 for C500, namely 0.47/0.68−1 = −30.9%. Using unrounded 0.4675 gives −31.3%. The paper consistently uses tabulated values, reporting differences to one decimal place; hence C500 is −30.9% throughout. Meaning of projected values: systematic differences from published values support the central proposition rather than disclose defects. They show that static nominal parameters cannot reproduce production metering, making runtime identifiability and measured calibration necessary conditions, rather than optional optimizations (Sections 5.4, 9.3 and Proposition 2). Uncertainty and conclusions (two domestic models; disclose together): these projections use uncertain public inputs and must be read as intervals. (1) Ascend 910B: 𝐹 is an academic teardown estimate with ±6% interval [353, 399] TFLOPS, yielding 𝑆chip ∈ [0.50, 0.52] via equations (6)–(8). (2) Muxi Xiyun C500: public 𝐵 conflicts at 1.2/1.8 TB/s (upper 1,800 used); 𝐼 is unpublished (384 GB/s generational reference), yielding 𝑆chip ∈ [0.42, 0.47]. Both upper bounds remain far below published values (910B: 0.52 vs 0.74; C500: 0.47 vs 0.68), with gaps near −30%. Section 5.4 is therefore robust 37

D-PIN SCU: From Nominal Capacity to Deliverable Compute

to this uncertainty, directly illustrating mandatory joint uncertainty disclosure (A6).(3) Hygon K100-AI (opposite direction; list separately): third-party specifications are 64 GB HBM2, FP16/BF16 192 TFLOPS, bandwidth 896–1,200 GB/s and TDP 300–350 W for K100-AI, unlike general-purpose K100 at 32 GB / 24.5 TFLOPS. Equations (6)–(8) give four-dimensional weighted 𝐹/𝑀/𝐵/𝐸 total 0.318. Interconnect dimension 𝐼 is undisclosed; taking 𝐼 ∈ [0, 900] GB/s gives 𝑆chip ∈ [0.32, 0.47]. Published 0.42 lies within this interval, opposite to H200/MI300X: systematic positive deviations do not occur for every model. This supports the central argument that the direction and magnitude cannot be inferred a priori and require model-specific calibration (Proposition 2); otherwise standardized calibration could be omitted.

B.3 Verification checklist: evidence and closure status #

Item

B-1

Closed AMD specifies 128 GB/s peak per link and 7 scale-up links, giving 7 × 128 = MI300X 896 GB/s, exactly matching our input [24]. effective Infinity Fabric bandwidth MI300X Closed AMD specifies 1,307.4 TFLOPS dense (2,614.9 sparse), consistent with 1,307 FP16/BF16 here, explicitly obtained by dividing sparse performance by 2 [24]. Our 𝐸 dense peak (1.233 at 750 W TBP) also agrees with official specifications. Settled Huawei has never published chip-level 910B specifications, only CANN SOC Ascend 910B FP16 (third-party version identifiers. CSET Georgetown wafer-level teardown analysis, compiled by flopper.io, estimates FP16/BF16 ≈ 400 TFLOPS, 64 GB HBM2e, 1.6 TB/s, peak, HBM/ estimate HCCS 392 GB/s and TDP 400 W [25][31]. Our 𝐼=392, 𝑃=400, 𝐵=1,600 and HCCS band- + ±6% interval) 𝑀=64 agree; only 𝐹=376 differs from 400 by 6.0%. Disposition (settled): priwidth and oritize submission feasibility and stop awaiting a vendor sheet. Label 𝐹 as a TDP third-party academic teardown estimate with ±6% uncertainty (𝐹 ∈ [353, 399] TFLOPS), yielding projected 𝑆chip interval [0.50, 0.52] (B.2-b note). Robustness statement (disclose together): even the 𝐹 upper bound of 399 TFLOPS yields only 0.52, approximately −30% below published 0.74 and well outside the uncertainty band. Section 5.4 is therefore unaffected by the 6.0% difference. This satisfies A6 uncertainty disclosure without unpublished materials. Muxi and Settled (a) Muxi Xiyun C500 inputs are settled through public vendor channels [39]: Hygon mod- (Muxi, pub- official Chinese/English product and server pages plus flopper.io confirm PCIe, els/specifi- lic sources) full-height/full-length dual-slot, 350 W maximum board power. 𝐹 = 240 TFLOPS dense is a public third-party compilation; official 280 TFLOPS apcations / partly closed (Hy- plies to OAM, outside our PCIe convention. 𝑀 = 64 GB HBM2E is official; 𝐵 = gon, series 1,200–1,800 GB/s reflects conflicting public 1.2/1.8 TB/s values absent from convention) the official page, using upper 1,800. 𝐼 is unpublished: 7 MetaXLink ports are listed without per-link bandwidth; C600’s 384 GB/s is the same-vendor reference. Equations (6)–(8) yield 𝑆chip = 0.47 (interval [0.42, 0.47]), −30.9% relative to 0.68. Public-source finding supporting C2: MetaXLink supports only 2 or 4 accelerators, with 4-card full interconnection on the server page; flopper.io confirms pair/four grouping rather than one eight-card domain. Thus 4 is the hardware maximum, and 8-accelerator 𝜂topo must be substantially below 0.95. B.2-b/B.2-c node values are upper bounds, illustrating that chip specifications do not determine node deliverability (Proposition 2). (b) Public Hygon DCU sources describe markedly different K100 (32 GB HBM2 / FP16 24.5 TFLOPS / 280 W) and K100-AI (64 GB HBM2 / FP16 192 TFLOPS / 300 W), with conflicting bandwidth of 896/1,200 GB/s. Production 0.42 matches neither point projection. Use Hygon K100 series throughout. Supplementary evidence closing the Hygon part: public K100-AI specifications support 64 GB HBM2 / FP16 192 TFLOPS / bandwidth 896–1,200 GB/s / TDP 300–350 W / PCIe 4.0×16, giving 𝑆chip ∈ [0.32, 0.47] with 𝐼 undisclosed. Published 0.42 lies within the interval, opposite to H200/MI300X (B.2-b note 3). Exact series specifications still require internal calibration records.

B-2

B-3

B-4

Status

Evidence and disposition

38

D-PIN SCU: From Nominal Capacity to Deliverable Compute

#

Item

B-5

Whether Closed Both SXM models use 700 W. NVIDIA describes H200 as a drop-in replaceH200 and ment in H100-qualified systems with the same 700 W power envelope [23], H100 share corroborated by other sources [32]. Using 700 W in 𝐸 is correct. TDP Disclosure These are internal calibration records, unverifiable through public channels, Original as search rechecks confirm. External closure is therefore replaced with a fixed convention plan setdisclosure plan. Under A6, submit an Internal Calibration Report containing and source tled; at(1) original conditions for each model and dimension: workload, batch size, of produc- tachment concurrency and duration; (2) raw tables and dates; (3) reconciliation with pending tion referB.2-a. Section 5.6 now uses measured calibration, and B.2-a states that exterence values archiving nal recomputation is unavailable. (Section 5.6 table) Basis of ini- Disposition We do not claim these are calibrated results. Under A6, disclose both empirical initial and Algorithm 1 calibrated values at submission: publish 𝛼̂ and tial weights settled Bootstrap intervals in the text and appendix. Initial values are recorded only (0.35, 0.20, 0.25, 0.15, as algorithm starting points, not independent metering grounds. 0.05) Declare the site boundary at mains entry, including Inferred Power servers/network/storage/cooling/distribution/UPS, and provide decomboundary of under position plus IT-basis (≈54.5 kW) metrics of 0.92 kW/D-PIN SCU and 0.85 national case-node standards; D-PIN SCU·h/kWh (Section 9.1). Evidence check: GB 40879—2021 limits 180 kW convention PUE ≤ 1.5 and NDRC [2024] No. 970 requires large/ultra-large centres ≤ defined 1.25 by end-2025 [54][55]. Treating 180 kW as measured site power implies PUE ≈ 3.3, above every grade limit and inconsistent with project compliance. Thus 180 kW is inferred as distribution design capacity including expansion headroom, while site power should be ≈68 kW from IT 54.5 kW and PUE ≤ 1.25. Status: inferred under national standards. If internal records differ, update every derived Section 9.1 value. Settled H20 is NVIDIA’s China-market compliant Hopper model. Vendor and thirdNVIDIA party sources agree on FP16/BF16 dense ≈148 TFLOPS, about 41% fewer H20 specifi- (publicSMs than H100, 96 GB HBM3, 4.0 TB/s, NVLink 900 GB/s, TDP ≈400 W, cations and specification projec- 8-way HGX and L2 60 MB. Equations (6)–(8) give normalized 𝑣 = (0.150, projection tion) 1.200, 1.194, 1.000, 0.262), 𝑆chip = 0.75 and node value 5.73 at 0.95 × 8 (added) (B.2-b). Status and disposition (disclose together): public projection only, no internal benchmark record; B.2-a marks ‡, not measured calibration. Update after calibration and move to the published convention. Observation supporting Proposition 2: projected H20 0.75 exceeds projected Ascend 910B 0.51, although 𝐹 is only about 15% of H100 and 𝐸 is the table minimum at 0.262. Advantages in 𝑀 (1.200) and 𝐵 (1.194) reverse the weighted ranking. This illustrates that nominal-versus-measured direction/magnitude cannot be inferred a priori, consistent with Hygon’s opposite result in B-4. Settled AMD MI308X is AMD’s China-market compliant MI300X variant. Official specifiMI308X (officialcations give FP16/BF16 dense 233 TFLOPS (FP8 466), 192 GB HBM3, 5.3 specificaspecificaTB/s, aggregate bidirectional interconnect 896 GB/s (node ring 448, P2P 128), tions and tion projec- and TBP 750 W, all labelled theoretical peaks. MI308X and MI300X are not projection tion) merely similar: 𝑀 / 𝐵 / 𝐼 / 𝑃 are identical, while 𝐹 is reduced to 17.8% (233 (added) / 1,307), a typical compliant design retaining memory capacity/bandwidth while limiting compute. Three consistency checks: (1) claimed compute 1.57× H20 agrees with 233/148 = 1.574; (2) memory capacity 2× and bandwidth 1.4× agree with 192/96 and 5.3/3.9; (3) compute/bandwidth 233/5.3 = 44 FLOP/byte is near H20’s 37 and far below MI300X’s 247, consistent with compliance variants. Equations (6)–(8) give normalized 𝑣 = (0.236, 2.400, 1.582, 0.996, 0.220), 𝑆chip = 1.12 and node 8.50 at 0.95 × 8 (B.2-b). Unusable public aggregators (record this): major third-party sites list FP16 81.72 TFLOPS, a vector rather than matrix rate, while copying other MI300X fields verbatim. No reliable public aggregator source exists for 𝐹; official specifications are used. Status and disposition: projection only, no internal benchmark record, marked ‡ and not measured calibration. Update after calibration and move to the published convention.

B-6

B-7

B-8

B-9

B-10

Status

Evidence and disposition

39

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Closure summary (10 items): 3 closed through official vendor evidence (B-1, B-2, B-5); 6 settled: B-3, Ascend 910B teardown estimate with ±6%; B-4, public Muxi evidence and Hygon K100-AI interval [0.32, 0.47] containing 0.42; B-7, dual-track calibration disclosure under A6; B-8, GB 40879— 2021 and NDRC [2024] No. 970 identify 180 kW as design capacity and site power ≈68 kW; B-9, public H20 projection 𝑆chip = 0.75 / node 5.73; B-10, official MI308X projection 𝑆chip = 1.12 / node 8.50, both marked non-measured rows. 1 disclosure plan settled, evidence attachment pending archiving (B-6). All 10 therefore complete evidence gathering or convention definition; B-6 archiving is a submission-process item, not a content gap. B-1/B-2 fully support MI300X inputs of 896 GB/s and 1,307 TFLOPS, so +74.2% versus production cannot be attributed to erroneous inputs, strengthening Section 5.4. Hygon’s opposite result, with published values inside the projected interval, shows that deviation direction cannot be inferred a priori and requires model-specific calibration (Proposition 2).

B.4 Case-derived data (Section 9) Quantity

Calculation

Value

Total node compute

Equation (30)

59.5 D-PIN SCU

Physical ceiling First-month billed throughput Power per unit compute Delivered energy efficiency Electricity-cost lower bound

Status

Mixed-convention derivation (Section 9.1 note) Equation (31) 42,868 D-PIN SCU·h Derived Equation (32) ≈ 33,000 D-PIN SCU·h Measured (convention check passed) 180/59.5 3.02 kW/D-PIN SCU Derived 33,437/(180×720) 0.26 D-PIN SCU·h/kWh Derived 3.02 × 0.53 1.60 CNY/(D-PIN Illustrative calculation SCU·h)

Appendix C Comparison with current standards and precedents C.1 Positioning D-PIN SCU against major systems

System

Metering object

Dimensions

GB/T 47514— FP32 theoretical One: peak com2026 and peak (EFLOPS) pute national statistics [1][2] YD/T 6693— Indicators of Classification + 2026 [3] heterogeneous re- indicator system source compute capability AWS ECU / Nominal CPU One: CPU Azure ACU capability [6][7] SLURM TRES- Converted reMultiple reBillingWeights source commitsources, manual [8] ments weights Kohlenberg Normalized nom- Four: G/C/M/B SCU (static) inal capacity [5]

Normalization baseline

Time granularity

Relationship to D-PIN SCU

Absolute units Quarter- Aggregate upper-layer conwithout normal- ly straint; scheduling-level refineization ment possible No single base- Assessline specified ment cycle

Indicator interoperability: five dimensions map to its system (C.2)

Historical Billing model / period A1=100 CPU core-hours Per job

Equivalent-unit idea shared; CPU versus accelerator objects differ

H100 SXM5 = 1.00

40

Closest engineering practice; differs in calibration and absent topology Contract Same-name precedent requiring period explicit distinction: static scalar versus dynamic system (C.3)

D-PIN SCU: From Nominal Capacity to Deliverable Compute

System

Metering object

Dimensions

Normalization baseline

Symmetric Normalized clusResearch SCU ter capacity for [33] financial collateral

Best hardware Cluster dimensions, including workload mix, multi-GPU scaling overhead and energy draw CME / Silicon H100-hour con- One: preset con- 1 SCU = Data SCU verted capacity version factors 1×H100 [10][34] FP16·h Device-resource Multiple device Best hardware DataCanvas occupancy / nor- dimensions / custom baseCU / ZTE malized score lines triplet score [9][35]

Time granularity —

Relationship to D-PIN SCU Same-name precedent with broadest dimensions; static specification, no runtime correction or verification loop, formalized in Lean

Contract Same-name precedent for fumonth tures pricing; preset rather than runtime factors Minute- Runtime-weighting precedents level with dynamic calculations and scenario weights; deviceresource rather than task– topology delivery conventions Alibaba ASI Effective utiliza- Cluster-level pro- Absolute values Obser- Related argument: high demand [36] tion duction evidence vation does not imply effective utilizaperiod tion; GPUs can be undeliverable. Cluster characterization, without a metering unit Agora [44] Three3: tensor Absolute usage, Seconds Similar form (new search result): dimensional throughput, not normalized runtime multidimensional mememory bandtering and usage pricing; deviceresource vector measured by width, interconresource usage, rather than task– counters nect topology deliverable compute; no verification loop Canonical unit Discrete account- Multiple thresh- Custom, not Per job Accounting precedent (new (PEARC’23) ing unit combin- olded combina- preset search result): scheduling over[45] ing resources tions head for resources that cannot be metered independently; no topology/runtime correction Energy-based Core-hours and Multiple, includ- Core-hours Per job Energy precedent (new search Accounting energy-weighted ing efficiency result): carbon footprint in al(Setonix) [46] charging rate and purchase location, adjacent to Section 7; price static charging rates, no topology ridge or verification coupling YD/T 6048— General-purpose, Classification Three baselines: Assess- Standards interoperability (new FLOPS/OPS/ ment search result): indicator stan2024 [47] supercomputing + component and intelligentweights Hash·s cycle dard alongside YD/T 6693, incorporable in C.2 compute indicators Tianyi Cloud Single2: compute and A baseline GPU Minutes Closest same-name form (new Standard accelerator com- bandwidth model search result): multidimensional Compute Unit pute × bandweighting and task-dependent (SCU) [49] width conversion; differences in supplementary C.3 Patent CN Weighted normal- Multiple: perfor- Custom 1 NCU Per task Patent precedent (new search re121255573A ized compute mance, bandsult): normalization, decay-curve [48] width, core correction, scheduling/billing count linkage; no topology ridge or verification coupling COIL / NCU 20 kWh of cer1: energy kWh — Energy-normalization precedent [51] tified delivered (new search result): also rejects compute duration/peak definitions; normalizes energy, not deliverable compute

41

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Normalization baseline

Time granularity

System

Metering object

Dimensions

DCU, One Degree of Compute [9] MLPerf / MLPerf Power [13][14] D-PIN SCU (this paper)

Compute input

Theoretical peak No single public Billing × time value period

Measured throughput and energy efficiency Deliverable compute

Task-level

Relationship to D-PIN SCU Shared input-side metering; differs in topology, runtime correction and verification loop Calibration sources for Algorithm 1 and equation (13)

Cross-system Release comparison, no cycle baseline ≤ 1 min — Five: F/M/B/I/E Methodanchored specification S1–S3; current replaceable realization H100 SXM = 1.00 (Proposition 3)

C.2 Proposed mapping to YD/T 6693—2026 D-PIN SCU dimension

Possible corresponding indicator

Mapping explanation

𝐹 (floating-point compute)

Compute capability: peak floatingpoint performance Storage/memory resources

Direct correspondence; align precision convention (dense) Correspondence; distinguish available from nominal capacity Correspondence

𝑀 (device-memory capacity) 𝐵 (device-memory bandMemory-access capability width) 𝐼 (interconnect bandwidth) Network/interconnect capability 𝐸 (energy efficiency)

Energy-efficiency indicators

Should be an independent dimension rather than a subordinate indicator Compute–electricity coordination and efficiency assessment

This proposed mapping requires comparison with the full indicator definitions and classification granularity of YD/T 6693—2026 and GB/T 47514—2026 before finalization. Both were published in 2026, and full texts require standards-distribution channels. Purchasing and comparing them is an external dependency, not a content gap; their public abstracts and scope clauses already support the mapping direction.

C.3 Formal distinctions among SCU usages (disambiguating multiple naming claims) SCU has multiple meanings in this field. As of 2026-10-05, at least five semantically distinct public usages are identified: Symmetric Research, CME/Silicon Data, Kohlenberg, Tianyi Cloud Standard Compute Unit, and other same-name static compute units. Two near-name NCU usages also exist: Revenue Model and COIL. The first table compares three main usages across four dimensions, followed by supplementary comparisons for newly identified usages.

Symmetric Research SCU [33]

Aspect

Kohlenberg SCU [5]

Mathematical form

Normalized weighted Cluster normalization dot product (scalar) specification, formally verified in Lean

42

CME / Silicon Data SCU [10][34] Unit conversion factor

D-PIN SCU (this paper) Scalar baseline × topology factor × three runtime factors (stochastic process)

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Symmetric Research SCU [33]

CME / Silicon Data SCU [10][34]

Aspect

Kohlenberg SCU [5]

Dimensions

4: GPU/CPU through- Multiple, including work- 1: H100 anchor put, memory capacload mix, multi-GPU ity/bandwidth + 𝐴 scaling overhead, energy draw Static 𝐴 Static multi-accelerator None scaling overhead

Topology

Time variation Verification

Pricing Main purpose

None

None; static specification

Trusted clearinghouse/platform telemetry Price normalization (𝑃/SCU) Contracts and crosshardware prices

Machine-verified specification, not runtime verification Collateral valuation

Identifiabili- Runtime deviation ty unidentifiable under Proposition 2

Data-centre collateral valuation Not discussed

D-PIN SCU (this paper) 5: 𝐹/𝑀/𝐵/𝐼/𝐸

𝜂topo , equations (9)–(13), closed-form ridge + measured calibration Yes: 𝛿𝑇 , 𝛿𝐹 , 𝛿𝐿 , ≤ 1 min

None within contract Index anchoring PoPW checks, no-arbitrage equation 25 Futures index and settlement Compute futures trading/settlement Not discussed

Electricity, renewables, load and reputation (equation 28) Real-time distributed scheduling, billing, verification and electricity coordination Identifiable through runtime metering

Supplementary distinctions for newly identified usages: Aspect Mathematical form

Dimensions

Tianyi Cloud Standard Compute Unit (SCU) [49]

COIL / NCU [51]

Patent CN 121255573A [48]

D-PIN SCU (this paper)

Single-accelerator compute × bandwidth defines 1 SCU; other nodes use stress-test conversion × decay factor 2: compute, bandwidth

1 NCU = 20 kWh of delivered, certified accelerated compute

Multiparameter Scalar baseline × weighted normaliza- topology × three runtion defining 1 NCU + time factors (stochastic decay curves process)

1: energy

Multiple: FP32/FP64, 5: 𝐹/𝑀/𝐵/𝐼/𝐸 memory bandwidth, cores, etc. Weighted perforDeliverable compute mance None 𝜂topo , closed-form ridge + measured calibration Partial: task-specific Yes: Algorithm 1 calicoefficient calibration bration and collinearity/identifiability analysis — PoPW checks, noarbitrage equation 25

Normalized quantity Topology

Compute × bandwidth

Energy consumption

Not modelled

None

Task dependence

Yes: task-type weights and None dynamic equivalent SCU

Verification

Platform telemetry

Independent certification, excluding idle and undelivered compute Formal simi- Highest: multidimenModerate: rejects larity sional weighting and task- duration/peak definidependent conversion tions Distinctive Closed-form topology-ridge Same, plus normalclaims here conversion, identifiability ization of deliverable argument, verification– compute rather than pricing coupling energy

High: weighted nor— malization and correction curves Same, plus runtime — stochastic modelling rather than a one-off decay curve

Conclusions by level: 1. Shared principle: normalized units enable cross-hardware comparison, commonly anchored to 43

D-PIN SCU: From Nominal Capacity to Deliverable Compute

H100 or the best hardware. 2. Symmetric Research SCU covers the broadest dimensions, explicitly including workload mix, multi-accelerator scaling overhead and energy consumption, substantially overlapping our components. The substantive difference is its static specification for one-off collateral normalization, whereas our 𝜂topo and three 𝛿 factors are runtime stochastic processes, with an additional unidentifiability argument and verification–pricing coupling. 3. CME / Silicon Data SCU is the most financialized implementation, but uses preset factors without runtime states. 4. We claim neither conceptual nor naming priority. The claim concerns the combined system of runtime identifiability, closed-form topology-ridge derivation and verification–pricing coupling (C1–C7). 5. Naming conclusion: given multiple usages, the unit is formally named D-PIN SCU (D-PIN Standardized Compute Unit). Bare SCU is not used as its sole external identifier.

Appendix D Systematic literature search (PRISMA-style) D.1 Purpose and research questions The judgement that neither naming nor components are novel individually and that originality is limited to the complete system (prefatory statement 4; C.3) requires a reproducible, auditable search. This appendix discloses the protocol and execution record. ID

Research question (RQ)

RQ1

Do public literature and standards already define compute-metering units named Standard(ized) Compute Unit (SCU)? Does an integrated system already combine dynamic runtime correction, topology awareness, verification coupling and pricing linkage? Which dimensions and operational granularities are covered by existing heterogeneous-compute metering?

RQ2 RQ3

D.2 Search protocol Item

Setting

Databases and sources

Google Scholar, arXiv, IEEE Xplore, ACM DL, USENIX, CNKI, Wanfang, National Public Service Platform for Standards Information, SSRN and institutional publications; added in this search: patent databases (Google Patents/CNIPA) and industry-standard aggregators No starting-year limit, to include early equivalent-compute units; cutoff 2026-1005 Chinese and English (”standardized compute unit” OR ”standard compute unit” OR ”normalized compute unit” OR ”equivalent compute unit”) AND (metering OR normalization OR billing OR pricing OR scheduling) (”compute metering” OR ”compute unit” OR ”GPU normalization”) AND (heterogeneous OR topology-aware OR ”runtime correction” OR verifiable OR decentralized) (”proof of physical work” OR ”verifiable compute” OR DePIN) AND (metering OR pricing OR settlement) (”standardized compute unit” OR ”standard compute unit” OR ”compute unit” OR ”One-Degree Compute”) AND (metering OR conversion OR pricing OR scheduling) (”heterogeneous compute” OR ”compute measurement”) AND (normalization OR conversion factor OR measurement metric OR standard)

Time range Languages English query B1

English query B2

English query B3 Chinese query C1 (English gloss of original Chinese terms) Chinese query C2 (English gloss of original Chinese terms)

44

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Item

Setting

Standards search

National standards platform queries for compute metering and heterogeneous compute networks; full text of YD/T 6693—2026

For the Chinese-language searches, the query expressions shown are English glosses of the original Chinese terms, rather than literal executed queries.

D.3 Inclusion and exclusion criteria Include

Exclude

Definitions, conversion methods or normalization formulas for compute-metering units Normalization in heterogeneous-compute metering or scheduling Coupling verification to metering/payments

Hardware comparisons without unit definitions

Compute statistics in standards and policy documents

Pure chip-specification documents, except as parameter sources Blockchain/consensus work without direct computemetering relevance News and vendor marketing without methods

D.4 Execution record (two rounds, through 2026-10-05) D.4-a First round: targeted search establishing precedent boundaries #

Topic

Key hits

1

Standard compute units / heterogeneous conversion (Chinese/English)

2

Equivalent units: cloud-provider precedents Normalized compute scores

Symmetric Research Standard Compute Unit (institutional page; related arXiv:2406.19261 uses Compute Hours, CH); CME-Silicon Data SCU; Kohlenberg SCU; DataCanvas DCU (1 DCU = 312 TFLOPS(FP16)×1h) AWS ECU and Azure ACU (C.1)

3 4 5 6

7 8

ZTE Information–Energy–Time Triplet; Alibaba OSDI’26, effective utilization and undeliverable states Metering–verification–pricing couGensyn time-sliced market + Verde; arXiv:1808.09682, TEE meterpling ing + payment Compute financialization and deriva- CME/Silicon Data futures; ICE/Ornn OCPI; Shanghai Municipal tives Government Development Research Center report Domestic compute standards GB/T 47514—2026 Distributed Computing—Compute Metering Methods; YD/T 6693—2026; T/TAF 292—2025; Pangoal Institution report Topology awareness and multiRoofline; Slurm TRESBillingWeights; HeteroScale (OSDI’20) accelerator scaling Third-party chip-specification eviflopper.io / CSET / official AMD and NVIDIA data sheets dence

D.4-b Second round: protocol-based systematic search (each D.2 query executed) #

Query (D.2)

Target source

Candidates (𝑛)

Key new precedents included

B1′

”standard compute unit” OR ”normalized compute unit” + metering/definition ”compute unit” normalization heterogeneous GPU metering/billing/scheduling

General academic/institutional sources

5

Two independent NCU usages [50][51]; Symmetric Research specification recheck [33]

arXiv·IEEE Xplore·ACM DL·USENIX, domainrestricted

5

Agora, three-dimensional usage pricing [44]; Canonical unit, PEARC’23 [45]; Energy-based Accounting, Setonix [46]

B2′

45

D-PIN SCU: From Nominal Capacity to Deliverable Compute

D.4-b Protocol search results (continued) #

Query (D.2)

Target source

B3′

”proof of physical work” OR verifiable compute OR DePIN + metering/pricing/settlement

arXiv·ACM DL·USENIX·IEEE, 5 domain-restricted

C1′

Public Chinese sources standardized compute unit / compute unit / One-Degree Compute + metering / conversion / pricing / scheduling (English gloss of original Chinese terms) Public Chinese sources + heterogeneous compute / compute measurement standards/patent aggregators + normalization / conversion factor / measurement metric / standard (English gloss of original Chinese terms) Standards-specific: com- Standards aggregators; napute measurement / com- tional platform lacks a propute network heterogegrammable search interface, neous (English gloss of so locate through aggregaoriginal Chinese terms) tors and trace original standard IDs Patent-specific: heteroge- Google Patents neous compute normalization metering (English gloss of original Chinese terms)

C2′

S1

P1

Candidates (𝑛)

4

Key new precedents included DePIN review [52]; LooPIN (PinFi pricing), POKT Relay Mining (on-chain requests), excluded after full-text assessment (D.5) Popular-science/terminology reviews, excluded at title/abstract screening, lacking new unit definitions

5

Tianyi Cloud SCU [49], YD/T 6048—2024 [47], invention patent CN121255573A [48]

1

YD/T 6048—2024 [47]

1

CN121255573A [48]

Note. Candidates (n) denotes verifiable candidate records returned by each search before deduplication; these are interface-truncated records, not corpus-wide database hit totals.

Nine references [44]–[52] were added: 3 academic precedents (Agora, Canonical unit, Energybased Accounting); 2 domestic standards/patent precedents (YD/T 6048—2024, CN121255573A); and 4 naming/background sources (Tianyi Cloud SCU, two NCU usages, DePIN review). △ Substantive search implications (disclose with the paper): these results must reduce the strength of novelty claims. Tianyi Cloud SCU [49] also uses multidimensional weighting and task-dependent conversion, the closest same-name form. Agora [44] also uses runtime hardware counters for multidimensional usage pricing. Novelty therefore narrows further to constraints, rather than multidimensional weighting plus runtime operation, claiming only the combination of (i) closed-form topology-ridge COI∗ conversion; (ii) identifiability of runtime deviation under nominal observation (Proposition 2); and (iii) verification–pricing no-arbitrage coupling (equation 25). Sections 2.2, 2.5 and C.3 have been synchronized accordingly.

46

D-PIN SCU: From Nominal Capacity to Deliverable Compute

D.5 PRISMA flow diagram (executed; backfilling completed) Stage

Count

Details

Round 1: targeted search Round 2: protocol search Verifiable candidate records returned by sources After deduplication Title/abstract screening: excluded Full-text assessment Included in qualitative synthesis

— — 𝑛 = 24

8 topics, boundary setting B1′/B2′/B3′/C1′/C2′ + S1/P1 Interface-truncated

Excluded

𝑛=4

𝑛 = 21 𝑛=5 𝑛 = 16 𝑛 = 12

Popular reviews/counter glossaries without unit definitions Includes: Symmetric Research specification; CH (arXiv:2406.19261); Canonical unit; Energy-based Accounting (Setonix); Agora; Tianyi Cloud SCU; YD/T 6048—2024; CN121255573A; NCU×2 (Revenue Model, COIL); Silicon Data standardization; DePIN review LooPIN: pricing protocol, not metering unit; POKT Relay Mining: request rather than compute metering; metaverse/DT framework: no compute unit; ROCm glossary: performancecounter definitions

Methodological statement (required reading to avoid misinterpreting counts): these are individually verifiable candidates actually returned by search interfaces, not corpus-wide database hit totals. The available channels for arXiv, IEEE Xplore, ACM DL and CNKI do not return corpus-wide counts; results are relevance-ranked and truncated. Reporting total hits would therefore constitute methodological fabrication. We count verifiable candidates and disclose this restriction in D.6. No exhaustive-search claim is made; this limits the strength of the statement that no complete counterpart was identified by the search date.

D.6 Search sufficiency and limitations 1. Naming coverage: at least five public SCU usages are covered: Symmetric Research [33], CMESilicon Data [10][34], Kohlenberg [5], Tianyi Cloud [49] and other same-name static units, plus two near-name NCU usages [50][51]. All are aligned with H100 dense = 1.00 (C.1). 2. Limitation 1 (patent/industry-standard omission partly closed): Google Patents and standards aggregators were added, identifying YD/T 6048—2024 [47] and CN121255573A [48]. Remaining gaps: (1) no programmable interface for the national standards platform or enterprise standards, potentially missing enterprise designs; (2) CNKI/Wanfang full-text databases were inaccessible, leaving Chinese journal full-text search incomplete; (3) Chinese coverage is therefore lower than English coverage. 3. Limitation 2 (database hit totals unavailable): as D.5 explains, channels do not return corpus totals, so PRISMA stages count verifiable candidates. This is a reduced counting convention, not evidence of complete search coverage. 4. Limitation 3 (dynamic-system criterion): RQ2’s four-part integration is a constructive criterion, with no hit satisfying all four. Because we proposed it, it risks self-serving criteria. We claim only that no complete counterpart was identified, not that none exists. 5. Limitation 4 (deliberately narrowed novelty): [44][49] are adjacent in form, through multidimensional weighting and runtime/task-dependent conversion. Following D.4-b, novelty narrows to the three-element combination, rather than form alone. 6. Limitation 5 (timeliness): cutoff 2026-10-05. Compute metering is active; [44] v2 and new naming usages appeared within two months during the search. Conclusions are time-dependent; rechecking before submission is recommended.

47

D-PIN SCU: From Nominal Capacity to Deliverable Compute

References [1] Ministry of Industry and Information Technology; Office of the Central Cyberspace Affairs Commission; Ministry of Education; National Health Commission; People’s Bank of China; State-owned Assets Supervision and Administration Commission. Action Plan for High-Quality Development of Computing Infrastructure [Z]. MIIT Joint Communications [2023] No. 180, 2023-10-08. [2] GB/T 47514—2026. Distributed Computing—Compute Metering Methods [S]. State Administration for Market Regulation; Standardization Administration of China. Published 2026-04-30; effective 2026-1101. (National compute-metering standard defining parameter classifications, static and runtime/dynamic methods, and heterogeneous normalization; the direct C7 interoperability target.) [3] YD/T 6693—2026. Indicators for Measuring Computing Capability of Heterogeneous Resources in Computing Networks [S]. China Communications Standards Association. Published 2026-03-11; effective 2026-06-01. [4] Zhong Q, Hu J, Zhu S, He S. Key technologies for compute metering and transaction management and practice on the Tianyi Cloud Xirang platform [J]. Information and Communications Technology and Policy, 2026(2): 78–85. DOI: 10.12267/j.issn.2096-5931.2026.02.011. [5] Kohlenberg E. A Compute Commodity Clearinghouse[EB/OL]. 2026-05. https://erickohlenberg.com/acompute-commodity-clearinghouse/ [6] Amazon Web Services. Amazon EC2 Compute Unit (ECU)[EB/OL]. AWS EC2 FAQs. https://aws.amazon .com/ec2/faqs/ [7] Microsoft. Overview of the Azure Compute Unit (ACU)[EB/OL]. Microsoft Learn. https://learn.microsoft. com/azure/virtual-machines/acu [8] SchedMD. TRESBillingWeights[EB/OL]. Slurm Scheduler Documentation. https://slurm.schedmd.com/ tres.html [9] Beijing DataCanvas Technology Co., Ltd. (i) One Degree of Compute (DCU) standardized metering: 1 DCU = 312 TFLOPS(FP16) × 1 hour, converting heterogeneous chips into measurable and settleable computeinput units, with tokens metered separately as outputs, and usage-billed Virtual Kubernetes Service (VKS) and Dedicated Kubernetes Service (DKS). Included in MIIT’s 2025 Typical Cases of Coordinated Development of New Information Infrastructure [Z/OL]. 2025–2026. [10] CME Group, Silicon Data. Compute Futures (Silicon Data H100 Rental Index Futures / B200 Rental Index Futures) [EB/OL]. https://www.cmegroup.com/markets/energy/power/compute-futures.html. Announced 2026-05; contract details 2026-08-11. (Based on Silicon Data’s daily on-demand GPU rentalrate index, using SCU across chips: 1 SCU = 1×H100 FP16-hour, with preset factors for other chips. Final size: 730 GPU-hours per contract, average monthly full-load single-accelerator time (365/12 × 24 ≈ 730). NYMEX GPU1/H100 and GPU2/B200, cash-settled, 36 monthly listings, pending CFTC approval. Initial May disclosures included 1,000 SCU/day and 30,000 SCU versions; final specifications use 730 GPU-hours.) [11] Williams S, Waterman A, Patterson D. Roofline: An Insightful Visual Performance Model for Multicore Architectures[J]. Communications of the ACM, 2009, 52(4): 65–76. [12] Jiang Z, Wang L, Xiong X, et al. HPC AI500: The Methodology, Tools, Roofline Performance Models, and Metrics for Benchmarking HPC AI Systems [J/OL]. arXiv:2007.00279, 2020-07-01. (Single-node and distributed HPC-AI Roofline models define communication operational intensity COI = FLOPs/𝐶𝑇 and attainable performance = min(FLOPSPeak , ComBandPeak × COI); direct source for equations (9)–(11).) [13] MLCommons. MLPerf Inference: Benchmark Suite and Rules[EB/OL]. https://mlcommons.org/benchm arks/inference/ [14] MLCommons Power Working Group. MLPerf Power: Benchmarking the Energy Efficiency of Machine Learning Systems from µWatts to MWatts for Sustainable AI[J/OL]. arXiv:2410.12032, 2024. [15] Ghodsi A, Zaharia M, Hindman B, et al. Dominant Resource Fairness: Fair Allocation of Multiple Resource Types[C]//Proceedings of NSDI, 2011. [16] Narayanan D, Santhanam K, Kazhamiaka F, et al. Heterogeneity-Aware Cluster Scheduling Policies for Deep Learning Workloads[C]//Proceedings of OSDI, 2020. [17] Chaudhary S, Ramjee R, Sivathanu M, et al. Balancing Efficiency and Fairness in Heterogeneous GPU Clusters for Deep Learning[C]//Proceedings of EuroSys, 2020. [18] Mo Z, Xu H, Lau W C. Optimal Resource Efficiency with Fairness in Heterogeneous GPU Clusters [J/OL]. arXiv:2403.18545, 2024-03-27. (OEF combines optimal resource efficiency with multiple fairness guarantees, improving aggregate training throughput by up to 32%.) [19] Zhu Y, Eran H, Firestone D, et al. Congestion Control for Large-Scale RDMA Deployments [C]// Proceedings of ACM SIGCOMM, 2015: 523–536. DOI: 10.1145/2829988.2787484. (DCQCN end-toend RoCEv2 congestion control determines effective IP-routed Ethernet bandwidth; calibration premise for cross-rack 𝛽node in equation (12), Section 4.3.2.) [20] AMD. AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More [R/OL]. 2020. https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrityprotection- and- more.pdf; Cheng P-C, Ozga W, Valdez E, et al. Intel TDX Demystified: A Top-Down

48

D-PIN SCU: From Nominal Capacity to Deliverable Compute

Approach [J]. ACM Computing Surveys, 2024. arXiv:2303.15540. (AMD SEV-SNP/Intel TDX isolation and remote attestation provide TEE hardware roots of trust for distributed verification.) [21] Benet J. Filecoin: A Decentralized Storage Network [R/OL]. Protocol Labs, 2017. https://filecoin.i o/filecoin.pdf. (PoRep and PoSt map storage contributions to verifiable credentials; a classical DePIN task–verification–reward example.) [22] Haleem A, Allen A, Thompson A, et al. Helium: A Decentralized Wireless Network [R]. Helium Systems Inc., 2018. (Proof of Coverage maps wireless contributions to on-chain credentials.) [23] NVIDIA. NVIDIA H100 Tensor Core GPU Datasheet; NVIDIA H200 Tensor Core GPU Datasheet [Z]. (Both share the GH100 compute die, FP16/BF16 dense peak 989 TFLOPS and 700 W power envelope.) [24] AMD. AMD Instinct MI300X Datasheet [Z]; AMD Instinct MI300X product specifications [EB/OL]. https: //www.amd.com/en/products/accelerators/instinct/mi300/mi300x.html. (Official FP16/BF16 dense 1,307.4 TFLOPS, sparse 2,614.9 TFLOPS, peak Infinity Fabric link 128 GB/s and TBP 750 W. AMD explicitly converts NVIDIA sparse TF32 values to dense by dividing by 2, vendor-side support for normalization.) [25] Huawei Ascend Community. Ascend computing product documentation: accelerator cards and training servers [EB/OL]. https://www.hiascend.com/. (Public information reaches card/server level; only CANN SOC identifiers ascend910b1–b4 are given, without chip-level 910B specifications. This supports the evidence of absent vendor chip specifications; five-dimensional inputs use third-party teardown [31].) [26] Lee D D, Seung H S. Algorithms for Non-negative Matrix Factorization[C]//Proceedings of NIPS, 2000. [27] NVIDIA. NCCL: NVIDIA Collective Communications Library—Collective Operations [EB/OL]. https: / / d o c s . n v i d i a . c o m / d e e p l e a r n i n g / n c c l / u s er - g u i d e / d o c s / u s a g e / c o l l e c t i v e s . h t m l. (AllReduce/AllGather/ReduceScatter semantics and implementation; basis for equation (12) and measured linearity in Section 9.2.) [28] KunlunMeta Artificial Intelligence Technology (Shanghai) Co., Ltd. D-PIN White Paper V4.13: Distributed Physical Infrastructure Network for AI Computing [R]. 2026-10-05. [29] KunlunMeta Artificial Intelligence Technology (Shanghai) Co., Ltd. GPT-Factory V6.2 Technical Documentation [R]. 2026. [30] Li C, et al. KunlunBaize: LLM with Multi-Scale Convolution and Multi-Token Prediction Under TransformerX Framework[J/OL]. arXiv:2503.04784. [31] Center for Security and Emerging Technology (CSET), Georgetown University. Ascend 910B wafer-level teardown and specification estimates, compiled by flopper.io [R/OL]. 2024–2026. (FP16/BF16 ≈400 TFLOPS, 64 GB HBM2e, 1.6 TB/s, HCCS 392 GB/s and TDP 400 W; explicitly states Huawei has never published chip-level specifications, so all values are third-party analyses.) [32] Cross-validation of H200 SXM specifications and power consistency, compiled from GPU Smith / GPUaaS / Thunder Compute and other databases [EB/OL]. 2026. (700 W, same power envelope and drop-in compatibility as H100 SXM5.) [33] Symmetric Research. The Standard Compute Unit, institutional research page: The measurement problem [EB/OL]. https://symres.ai/research. (Actual source of the SCU name and specification: one comparable metric for heterogeneous GPU clusters, explicitly covering hardware differences, workload mix, multi-GPU scaling overhead and energy draw. Formally specified, with core economics machine-verified in Lean and calibration anchored to MLCommons. No publication date is given.)Related research line: Kristensen J, Wender D, Anthony C. Commodification of Compute [J/OL]. arXiv:2406.19261, 2024-0627 (v2 2024-07-03). (Global Compute Exchange and compute-hour trading; unit Compute Hours (CH) Performance (FLOPS) × Operational Hours. SCU never appears in the paper.)Citation disci= Reference Performance (FLOPS) pline: 2024 dates the research line, not public SCU usage. The naming source is the institutional page, not peer-reviewed and lacking a stable identifier; attach a retrieval snapshot for arXiv submission. This is the broadest-dimensional same-name precedent. [34] Shanghai Municipal Government Development Research Center. Accelerating Global Compute Financialization: How Shanghai Can Move First [EB/OL]. 2026-08-24. (Authoritative Chinese explanation: 1 SCU = 1 H100 FP16-hour, other chips use preset factors; comparison with ICE/Ornn OCPI.) [35] Liu C, Zhou D, Miao Z, Ding Y, Wu Z. Comprehensive measurement and optimization of compute resources based on an information–energy–time triplet [J]. ZTE Technology Journal, 2026, 32(2): 73–80. DOI: 10.12142/ZTETJ.202602011. [36] Li S, Yang L, Yu H, et al. Heterogeneity at Hyperscale: Characterization and Scheduling of Large Production AI Clusters at Alibaba[C]//20th USENIX Symposium on Operating Systems Design and Implementation (OSDI 26), 2026: 2187–2203. [37] Gensyn. From Bundles to Time: A Theory of Decentralised Compute Markets [EB/OL]. https://blog .gensyn.ai/from-bundles-to-time-a-theory-of-decentralised-compute-markets/. (Two-sided timeslice market; RepOps reproducibility, Verde verification, checkpointing, dynamic pricing and incentivecompatible pooling/slashing.) [38] Bagchi S, et al. Fair Marketplace for Secure Outsourced Computations [J/OL]. arXiv:1808.09682, 2018. (TEE-anchored trusted metering plus blockchain micropayments addresses both parties’ incentives to misreport outsourced-compute resources.)

49

D-PIN SCU: From Nominal Capacity to Deliverable Compute

[39] MetaX Integrated Circuits (Shanghai) Co., Ltd. Xiyun C500 product page (Chinese) [EB/OL]. https: //www.metax-tech.com/prod.html?cid=107&id=21 ; MetaX C500 Product Page (EN) [EB/OL]. https: //www.metax-tech.com/en/goods/prod.html?cid=107&id=21 ; C500 Server Product Page [EB/OL]. ht tps://www.metax-tech.com/en/goods/prod.html?cid=110&id=37 ; Xiyun General-Purpose Computing GPU User Guide [EB/OL]. https://developer.metax-tech.com/ . (Public vendor sources: 64 GB fullpath ECC memory, MetaXLink 2- or 4-accelerator interconnect, minimum 1% software-slicing granularity, full-height/full-length dual-slot PCIe, maximum 350 W. Server page specifies 4-card full interconnection, with high-capacity 16-GPU and standard 8-GPU configurations.) Flopper.io. MetaX C500 and C500 server specification pages [DB/OL]. https://flopper.io/gpu/metax-c500/spec-sheet ; https://flopper.io/sys tem/metax-c500-server/spec-sheet . (PCIe boards; MetaXLink pairs/fours, not one eight-card domain. Memory bandwidth omitted because sources conflict at 1.2/1.8 TB/s and it is absent from the vendor page. MetaXLink has 7 ports with unpublished per-link GB/s; listed 280 TFLOPS refers to OAM.) All sources here are public vendor channels or public third-party databases. [40] RISC Zero. RISC Zero zkVM: Proof System Overview (Receipt / ZK-STARK / Groth16 stack) [EB/OL]. https://dev.risczero.com/proof-system/. (General RISC-V zkVM with RISC-V Circuit, Recursion Circuit and STARK-to-SNARK stages; representative full cryptographic proof approach.) [41] Succinct Labs. SP1: A Zero-Knowledge Virtual Machine for RISC-V [EB/OL]. https://docs.succinct. xyz/docs/sp1/introduction. (Proves RISC-V execution for Rust/C/C++ programs; representative full cryptographic proof approach.) [42] Kivinen J, Warmuth M K. Exponentiated Gradient versus Gradient Descent for Linear Predictors [J]. Information and Computation, 1997, 132(1): 1–63. DOI: 10.1006/inco.1996.2612. (Classical EG source supporting entropic mirror-descent equation (22).) [43] Beck A, Teboulle M. Mirror Descent and Nonlinear Projected Gradient Methods for Convex Optimization [J]. Operations Research Letters, 2003, 31(3): 167–175. (General framework underlying convergence of equation (22).) [44] McDougall I, Scott N, Sankaralingam K. Agora: A System for Consumption-Based GPU Pricing [J/OL]. arXiv:2510.05111, 2025 (v1 2025-09-26; v2 2026-09-22). (Commodity performance counters meter three-dimensional resources, pricing usage rather than rental duration. Closest usage-based multidimensional precedent; device-resource use rather than task–topology deliverable compute.) [45] Andrijauskas F, Sfiligoi I, Würthwein F. Defining a canonical unit for accounting purposes [C]//Practice and Experience in Advanced Research Computing (PEARC ’23). New York: ACM, 2023: 288–291. arXiv:2305.10551. (Thresholded CPU/GPU/memory/scratch combinations form one discrete canonical unit, characterizing scheduling overhead and fairer billing; precedent for merged-resource accounting.) [46] Di Pietrantonio C, Harris C, Cytowski M. Energy-based Accounting Model for Heterogeneous Supercomputers [J/OL]. arXiv:2110.09987, 2021. (Setonix/Pawsey model retains core-hours, sets charging rates by performance, efficiency and purchase price, and bases GPU rates on energy, incorporating carbon footprints in allocation.) [47] YD/T 6048—2024. Technical Requirements and Assessment Methods for Data Centre Computing Power [S]. Beijing: Posts & Telecom Press, 2024. (Unified CPU/GPU/FPGA metering; general-purpose, supercomputing and intelligent-compute classes with indicators/weights; FLOPS/OPS/Hash·s units and scale conversion; admission, scheduling, operations and normalized assessment formulas.) [48] Method and Apparatus for Normalized Metering of Heterogeneous Compute in an Intelligent Computing Centre Cloud Platform [P]. Chinese invention patent, publication CN121255573A. (Weighted GPU FP32 0.3 / memory bandwidth 0.25 / CUDA cores 0.2 / FP64 0.15 / other 0.1 normalize chips to 1 NCU, with decay curves and scheduling/billing outputs. New SLR patent precedent addressing Appendix D.6 limitation 1.) [49] Tianyi Cloud Developer Community. Abstracting Cross-Domain Compute into Common Units: Multilevel Managed Topology and Dynamic Routing Convergence [EB/OL]. https://www.ctyun.cn/developer/a rticle/822922178261061 . (A baseline GPU’s FP16 compute × bandwidth defines 1 SCU; stress tests and decay factors convert other nodes. Task-specific weight vectors dynamically calculate equivalent SCU, rather than fixed rates. Closest same-name form identified here.) [50] Revenue Model. Normalized Compute Unit (NCU) [EB/OL]. https://www.revenuemodel.ai/normalizedcompute-unit . (Model-independent AI-cost normalization based on FLOP-based metering, FBM. Public descriptions are abstract and do not disclose the method; recorded only as a naming usage.) [51] Czech P (NativX). Building a Better Mousetrap: COIL and Normalized Compute Unit [EB/OL]. LinkedIn, 2026. (1 COIL = 1 NCU = 20 kWh of independently certified, delivered accelerated compute; energy rather than duration normalization. Idle consumption, cooling losses and uncertified claims generate no NCU.) [52] A Survey of Decentralized Physical Infrastructure Network: Research Directions, and Open Challenges [J/OL]. arXiv:2609.02125, 2026. (Physical-contribution proofs, cross-chain settlement and scalability; DePIN background for Sections 2.4 and 8.3.) [53] T/TAF 292—2025. Compute Resource Metering Indicators and Test Methods for Trading Scenarios [S]. Telecommunication Terminal Industry Forum (TAF), published 2025-07. (Trading-focused indicators, including compute fill rate; indicator-level standard alongside YD/T 6693—2026, compared in Section 2.5 50

D-PIN SCU: From Nominal Capacity to Deliverable Compute

and C.1.) [54] GB 40879—2021. Minimum Allowable Values of Energy Efficiency and Energy Efficiency Grades for Data Centres [S]. State Administration for Market Regulation; Standardization Administration of China, 2021. (Mandatory standard: grade 1 PUE ≤ 1.2, grade 2 ≤ 1.3, grade 3/minimum ≤ 1.5; basis for Section 9.1 and B-8 power boundaries and implied PUE.) [55] National Development and Reform Commission, et al. Green and Low-Carbon Data Centre Development Action Plan [Z]. NDRC Environment and Resources [2024] No. 970, 2024. (By end-2025, new/expanded large and ultra-large centres require PUE ≤ 1.25, and national hub projects ≤ 1.2; basis for site-power calibration.) [56] Nodal Exchange, Compute Desk. Nodal Exchange and Compute Desk to Launch Compute Futures Contracts [EB/OL]. 2026-09-03. https://www.nodalexchange.com/nodal-exchange-and-compute-desk-tolaunch-compute-futures-contracts . (IOSCO/BMR-compliant GPU rental indices for Hopper/Blackwell, cash settlement, Nodal Clear clearing, CFTC supervision and launch pending approval.) [57] Gargiulo S, Kulp G. Workload Identification with Physical Side Channels for AI Governance [J/OL]. arXiv:2609.00309, 2026-08-31. DOI: 10.48550/arXiv.2609.00309. (GPU power traces identify workloads: 930 traces of 5 s at about 10 MHz on H200, covering 17 open LLM families and 25 non-AI workloads. Training/inference/non-AI accuracy 97%, macro F1 0.955. Four evasion strategies tested; hardened detection ≥99% for 3, and LoRA rises from 48–88% to ≥98%. The physical channel differs from spoofable/replayable on-chip NVML telemetry and can in principle be observed without operator cooperation; supplementary contribution-verification approach for Sections 2.4 and 8.3.) KunlunMeta Research KunlunMeta Artificial Intelligence Technology (Shanghai) Co., Ltd. https://www. kunlunmeta.com

51

Related documents

• From Nominal Capacity to Deliverable Compute: Design, Calibration and Validation of the D-PIN SCU Dynamic Metering System#1327964
• Branch-Aware Quantum Constant Propagation for Dynamic Quantum Circuits#1123108
• AlchemQ: Proof-Carrying Quantum Circuit Optimization with Per-Result Equivalence Certificates#1013761
• Scalable Benchmarking Framework for Dynamic Quantum Circuits#1123062
• Maximizing the nondemolition nature of a quantum measurement via an adaptive readout protocol#1355946