FIELD NOTE / X
GPU telemetry is not an invoice ledger.
The complete written thought and the evidence behind it. The video edition will follow its public release.
The written argument is here.
This approved X edition is on the journal now. Its video player and original platform link will appear after each public release is verified.
GPU telemetry is not an invoice ledger.
Day 27 · Week 4 editorial group · X · no publication date or time assigned
Video caption
GPU telemetry is not an invoice ledger. Utilization and charged allocation are different facts. Preserve the gap instead of inventing precision. #EricFieldNotes
Full written post / accessibility read
DCGM can summarize a scheduler job, but its retained job record is not a durable accounting database. If the host engine restarts before export, the operator may lose the samples needed to explain a usage line.
Imagine a job waiting on checkpoint storage while its allocation remains held. The scheduler knows the reservation, DCGM has device observations, and the application knows progress. None alone says what the contract should charge.
Export DCGM job stats in the scheduler epilogue; persist allocation start, stop, interruptions, device UUIDs and sample gaps independently. Join application checkpoints and accepted output. Keep invoice adjustments as their own ledger entries, not a rewrite of raw usage.
If a watch was late or lost, mark the interval unknown and resolve it under the customer's agreement. Do this because a credible compute business needs replayable receipts, while a GPU counter by itself cannot decide a commercial obligation.
#EricFieldNotes
Four-beat scene transcript
1. GPU telemetry is not an invoice ledger.
DCGM can summarize a scheduler job, but its retained job record is not a durable accounting database. If the host engine restarts before export, the operator may lose the samples needed to explain a usage line.
Visual: A restarted host engine can lose the job window.
2. The customer disputes an unexplained interval.
Imagine a job waiting on checkpoint storage while its allocation remains held. The scheduler knows the reservation, DCGM has device observations, and the application knows progress. None alone says what the contract should charge.
Visual: Utilization and charged allocation are different facts.
3. Write a durable per-run receipt.
Export DCGM job stats in the scheduler epilogue; persist allocation start, stop, interruptions, device UUIDs and sample gaps independently. Join application checkpoints and accepted output. Keep invoice adjustments as their own ledger entries, not a rewrite of raw usage.
Visual: Join allocation events, telemetry, progress and contract version.
4. Make every charge explainable.
If a watch was late or lost, mark the interval unknown and resolve it under the customer's agreement. Do this because a credible compute business needs replayable receipts, while a GPU counter by itself cannot decide a commercial obligation.
Visual: Preserve the gap instead of inventing precision.
Research and claim limits
The examples identified as illustrative or simulated are design probes, not reported incidents. Vendor specifications do not establish workload performance.