Really enjoyed this. I think your electricity analogy actually points toward a resolution though. The kWh didn't become fungible because NIST published a spec. It became fungible because ISOs like PJM Interconnection built the dispatch layer that made heterogeneous generation sources (gas, nuclear, wind) deliverable as a standardized output at a given node. The measurement standard followed the operational infrastructure, not the other way around.
The same path is available for compute. A scheduling and reliability layer that dispatches inference requests across heterogeneous GPU hardware (H100s, B200s, whatever ships next) while enforcing contractual latency, throughput, and availability targets would be the compute equivalent of grid dispatch. If the scheduler delivers identical SLO performance regardless of which silicon is underneath, the financial contract references the SLO, not the GPU model. The unit outlives the hardware because the delivery mechanism does.
Compute is harder than electricity here because the output isn't physically identical across hardware. Workloads have hardware-specific optimization dependencies that electrons don't. But for inference, which is the bulk of enterprise demand, the abstraction is feasible.
Lending against serialized GPU hardware is useful but it's still equipment finance, and the bond inherits the 2-3 year obsolescence cycle. Securitizing cash flows from hardware-agnostic performance SLAs instead, where the operator can rotate underlying GPUs across generations without breaking the contract, gets you something closer to PPA ABS.
So the sequencing may not be as stuck as you suggest. It might be that the missing step isn't metrology, it's the dispatch and reliability infrastructure that makes heterogeneous compute fungible at the delivery point. Right now you go to CoreWeave or Lambda the same way you bought power from Edison or Westinghouse in the early 1900s: incompatible systems, proprietary hardware, no interconnection, no grid. Whoever builds the compute equivalent of PJM defines the standard unit as a byproduct.
You're right about PJM. The ISO dispatch layer made heterogeneous generation fungible, and the standardized MWH was as much a byproduct of that operational infra as it was a top-down NIST exercise.
But I think the analogy breaks when it comes to compute. In electricity, the hardware is on the operator's side of the meter. Swapping one gas turbine for another is an operational decision invisible to the party that buys electricity. The customer sees identical electrons.
In compute, though, the hardware isn't on the operator's side of the meter. It is the meter. The specific GPU shapes behavior, memory access patterns, latency, and failure modes in ways the counterparty experiences even when top-line performance numbers hold. And the deeper problem: the obligation isn't defined against a static workload. Frontier models co-evolve with hardware. A B200 delivers more compute than an H100. But it also delivers compute shaped differently, optimized for architectural patterns that didn't exist when the H100 shipped. An operator who rotates hardware would likely find that the new silicon only delivers equivalent performance if the customer also upgrades their model. But the customer's model choice isn't inside the contract because model release cadence is something that neither the provider nor the customer control.
All this having been said, there probably is a real structured finance opportunity in the direction you're pointing. Think about securitizing SLO-backed cash flows rather than lending against serialized hardware. But it probably works for commodity inference on stable, widely-deployed models, not at the frontier where hardware-model coupling is tightest. And even there, the contract still needs a verification framework that doesn't exist yet.
Thanks for a clear and cogent explanation of the issue. I heard the same argument applied to strategic arms negotiations a few decades ago - the two sides had to agree what a I and a 0 were.
Really enjoyed this. I think your electricity analogy actually points toward a resolution though. The kWh didn't become fungible because NIST published a spec. It became fungible because ISOs like PJM Interconnection built the dispatch layer that made heterogeneous generation sources (gas, nuclear, wind) deliverable as a standardized output at a given node. The measurement standard followed the operational infrastructure, not the other way around.
The same path is available for compute. A scheduling and reliability layer that dispatches inference requests across heterogeneous GPU hardware (H100s, B200s, whatever ships next) while enforcing contractual latency, throughput, and availability targets would be the compute equivalent of grid dispatch. If the scheduler delivers identical SLO performance regardless of which silicon is underneath, the financial contract references the SLO, not the GPU model. The unit outlives the hardware because the delivery mechanism does.
Compute is harder than electricity here because the output isn't physically identical across hardware. Workloads have hardware-specific optimization dependencies that electrons don't. But for inference, which is the bulk of enterprise demand, the abstraction is feasible.
Lending against serialized GPU hardware is useful but it's still equipment finance, and the bond inherits the 2-3 year obsolescence cycle. Securitizing cash flows from hardware-agnostic performance SLAs instead, where the operator can rotate underlying GPUs across generations without breaking the contract, gets you something closer to PPA ABS.
So the sequencing may not be as stuck as you suggest. It might be that the missing step isn't metrology, it's the dispatch and reliability infrastructure that makes heterogeneous compute fungible at the delivery point. Right now you go to CoreWeave or Lambda the same way you bought power from Edison or Westinghouse in the early 1900s: incompatible systems, proprietary hardware, no interconnection, no grid. Whoever builds the compute equivalent of PJM defines the standard unit as a byproduct.
Thanks, you make a number of good points here.
You're right about PJM. The ISO dispatch layer made heterogeneous generation fungible, and the standardized MWH was as much a byproduct of that operational infra as it was a top-down NIST exercise.
But I think the analogy breaks when it comes to compute. In electricity, the hardware is on the operator's side of the meter. Swapping one gas turbine for another is an operational decision invisible to the party that buys electricity. The customer sees identical electrons.
In compute, though, the hardware isn't on the operator's side of the meter. It is the meter. The specific GPU shapes behavior, memory access patterns, latency, and failure modes in ways the counterparty experiences even when top-line performance numbers hold. And the deeper problem: the obligation isn't defined against a static workload. Frontier models co-evolve with hardware. A B200 delivers more compute than an H100. But it also delivers compute shaped differently, optimized for architectural patterns that didn't exist when the H100 shipped. An operator who rotates hardware would likely find that the new silicon only delivers equivalent performance if the customer also upgrades their model. But the customer's model choice isn't inside the contract because model release cadence is something that neither the provider nor the customer control.
All this having been said, there probably is a real structured finance opportunity in the direction you're pointing. Think about securitizing SLO-backed cash flows rather than lending against serialized hardware. But it probably works for commodity inference on stable, widely-deployed models, not at the frontier where hardware-model coupling is tightest. And even there, the contract still needs a verification framework that doesn't exist yet.
Thanks for a clear and cogent explanation of the issue. I heard the same argument applied to strategic arms negotiations a few decades ago - the two sides had to agree what a I and a 0 were.