FP64 (CPU) vs FP32 (GPU) on a quadratic heat rate curve.
Three parameters. High school algebra. $545,000/yr of consequence.
The Augmented Willan's Line is the industry standard model for how a gas turbine's fuel efficiency varies with power output, temperature, and equipment wear.
HR(P, T, d) = (a + bP + cP²) · (1 + α·ΔT) · (1 + β·d)
Three main parameters (a, b, c) define the U-shaped curve. P* = −b/2c is the economic optimum — the power level where the plant burns fuel most efficiently. The model is fit to 350 simulated plant operating observations with realistic measurement noise.
The only variable between the two runs was arithmetic precision. The optimizer, loss function, data, and random seeds were identical.
Neither platform chose this tradeoff. The arithmetic made it for them. FP32 fits the observed data more closely. FP64 satisfies the physical and regulatory constraints more tightly. These are two different models of the same plant.
200 bootstrap samples per platform, each refit from scratch. FP32 is consistently less certain about where the economic optimum is — a 52% wider uncertainty band on the number that determines dispatch bids.
By sweeping the weight on statistical fit vs physics penalty, we trace a Pareto frontier for each platform. Same loss function, same sweep. The two frontiers diverge — hardware is constituting which tradeoffs are reachable.
FERC requires submitted heat rate curves to be non-decreasing above the economic minimum (dHR/dP ≥ 0). Both models satisfy this rule. But FP64 has —x less margin than FP32 at rated load.
If you fit on a CPU workstation and deploy on an embedded FP32 energy management system — the standard plant configuration — that FP64 margin shrinks further on the way out the door. You could cross into a violation without changing a single line of code. The hardware changed.
| Metric | FP64 | FP32 | |Δ| |
|---|
This is not a deep learning phenomenon. No neural networks, no stochastic gradient descent, no random initialization. A quadratic equation fit to 350 points with a deterministic optimizer — and the hardware still constitutes the model.
The desktop era of energy and transportation modeling kept this invisible: same machine builds it, same machine runs it, hardware is constant. That era is ending. Models now cross hardware boundaries at every step — trained on cloud GPUs, deployed on embedded ARM controllers, audited from laptops.
Each crossing is a silent reset of this implicit hyperparameter. The practical fix: validate on the hardware the model will actually run on, before you report results or submit a regulatory curve. Add the hardware platform to the model card alongside the software version and the data version.
The computer isn't just where your model runs. It's part of what your model is.