Skip to content

Commit 587d9f2

Browse files
committed
methodology: fix two contradictions found in final review
Line ~254 described the CO2/token bar chart as part of the frontier comparison with color-by-energy-ratio -- both wrong; that chart is a separate, always-rendered, absolute measurement, and the frontier comparison's color mechanic was removed earlier in this project. The worked example described fictional 8x-A100/24x-H100 hardware left over from the nrp-carbon-api fork (nimbus has one GB10) and its "both clusters are underutilized" framing directly contradicted the J/token section's own "not a utilization verdict" language elsewhere in this same file.
1 parent 7f9882c commit 587d9f2

1 file changed

Lines changed: 20 additions & 15 deletions

File tree

cmd/static/methodology.html

Lines changed: 20 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -250,29 +250,34 @@ <h3>Per-model comparison formula</h3>
250250
ratio = frontier_watts / nrp_measured_watts</code></pre>
251251
<p>
252252
This formula is applied to each nimbus model using its <strong>actual observed</strong>
253-
prompt and generation token rates. The comparison is shown as a watts bar on each model
254-
card and as a CO₂/token bar chart (colored by energy ratio) across all models.
253+
prompt and generation token rates. The comparison is shown as a plain-text watts bar on
254+
each model card, visible only while the model is actively generating (24h-avg combined
255+
tok/s above a small threshold) — not as a colored verdict, and not on the CO₂/token bar
256+
chart, which is a separate, unrelated, always-rendered absolute measurement.
255257
</p>
256258

257-
<h3>Example: Qwen3.5-397B at low traffic</h3>
258-
<pre><code>nimbus measured: 783 W (8× A100, real DCGM reading)
259-
Prompt rate: 3 tok/s
260-
Generation rate: 15 tok/s
259+
<h3>Example: nimbus at typical light traffic</h3>
260+
<pre><code>nimbus measured: 11 W (1× GB10, real DCGM reading)
261+
Prompt rate: 40 tok/s
262+
Generation rate: 1 tok/s
261263

262264
Commercial frontier equivalent:
263265
Idle floor: 24 × 225 = 5,400 W
264-
Prefill: 3 × 0.5 = 2 W
265-
Decode: 15 × 6.0 = 90 W
266-
Total: 5,492 W
266+
Prefill: 40 × 0.5 = 20 W
267+
Decode: 1 × 6.0 = 6 W
268+
Total: 5,426 W
267269

268-
Ratio: 5,492 / 783 = 7.0× — nimbus uses 7× less energy for the same tokens.</code></pre>
270+
Ratio: 5,426 / 11 = 493× — nimbus uses 493× less energy for the same tokens.</code></pre>
269271

270272
<div class="callout">
271-
<p><strong>Why this is fair:</strong> Both sides include hosting costs. The nimbus model
272-
draws ~783 W to keep 8× A100 GPUs powered; the commercial frontier would draw ~5,400 W just to
273-
keep 24× H100 GPUs powered. At low traffic, both clusters are underutilized — the
274-
comparison reflects the real energy cost of maintaining each capability, not an idealized
275-
marginal-only estimate for one side.</p>
273+
<p><strong>Why this is fair:</strong> Both sides include hosting costs. nimbus draws
274+
~11 W to keep its single GB10 powered; the commercial frontier would draw ~5,400 W just
275+
to keep 24× H100 GPUs powered and its models loaded in memory. The comparison reflects
276+
the real energy cost of maintaining each capability, not an idealized marginal-only
277+
estimate for one side — and it is not a judgment of "utilization" on either side: nimbus
278+
idling low is exactly what a well-designed single-user desktop-class chip should do, and
279+
a large commercial cluster's idle floor reflects it serving many concurrent users, not
280+
being poorly managed.</p>
276281
</div>
277282
<div class="callout">
278283
<p><strong>What this doesn't measure:</strong> nimbus figures are GPU power only (no CPU,

0 commit comments

Comments
 (0)