GPU Hotspot Delta Census: Core-to-Hotspot Readings by Model

GPU core temperature is easy to find. The hotspot, sometimes labelled junction temperature, is the highest reading among sensors on the GPU die. The difference between those two readings is the hotspot delta.

Forum posts usually show one card at one moment. They also mix simultaneous readings with session maxima, stock cards with repasted cards, and sensor tools whose Blackwell support arrived in different versions. This census keeps those distinctions in the row instead of flattening them into one threshold.

The data, definition, validator and report form live in github.com/iBlessi/techfuelhq-census. The CSV begins empty. Test fixtures exercise the validator and publication floors; they are never copied into the dataset.

What this census measures

One row is one card under one sustained load. It records core and hotspot temperatures from software die sensors, either as a simultaneous snapshot or as both maxima from the same session. It does not accept infrared-camera, thermocouple, PCB or backplate temperatures as the hotspot.

The delta is computed as hotspot minus core. A submitter never types that derived field. The validator rejects a negative result, a hotspot outside the documented 20-125 C range, a core outside its documented 20-100 C range, and a load shorter than ten minutes.

Why the sensor tool and version are required

NVIDIA’s nvidia-smi documentation exposes core temperature and a thermal-limit margin, but does not document a hotspot field. Third-party tools restored RTX 50 hotspot readings later: CPUID records an RTX 50 fix in HWMonitor 1.65.1. LACT’s v0.10.0 release notes say its Blackwell hotspot sensor now works through a Blackwell-specific path and list pull request 1122, which added that path.

For that reason, every row names its tool and version. An RTX 50 submission from HWMonitor below 1.65.1 or LACT below 0.10.0 is rejected. A report from another tool is retained with an unverified-tool flag, but it cannot move either publication floor until a primary changelog establishes a supported version.

The fixed delta bands

Exact-model distributions use five bands: 0-9 C, 10-19 C, 20-29 C, 30-39 C, and 40 C or higher. These edges are part of dataset version 0.1.0. Moving an edge would make earlier and later distributions incomparable, so any change requires a new major version.

What one row records

A row is one software sensor reading from one card under one sustained load. Of its 23 fields, you fill in 19, 2 are worked out from the row and the maintainer sets 2.

How to take a reading

1. Return the card to the power state you intend to report. Stock readings can count toward published baselines; undervolted, overclocked and raised-power-limit readings remain useful context but do not count toward them.
2. Open a sensor tool that shows both GPU core and hotspot. Record its exact version.
3. Run one game, FurMark, 3DMark stress test or another steady GPU load for at least ten minutes.
4. Record both temperatures at the same moment, or record both maximum values from that one session. Do not combine a core maximum from one run with a hotspot maximum from another.
5. Add the cooler state, months since the current paste was applied, and any room temperature, power draw, mounting or fan-control context you actually observed. Leave optional fields empty instead of estimating them.

If the temperatures are high and you want a diagnosis rather than a dataset form, use the GPU overheating guide. A fan controller reacting to a hidden sensor is covered in the GPU fans stuck at full speed guide.

Build a report

Sending opens the public GitHub issue form and requires an existing GitHub account. The builder runs locally in the browser and makes no request with the values. It puts the finished report in a new-window action only after the visitor chooses to open it.

What has been published

Current count: 0 reports. No group has rows yet, so nothing is published.

GPU family rollup: 0 reports. No group has rows yet, so nothing is published.

The primary table groups qualifying rows by exact card brand and model. A model publishes its fixed-band counts at five qualifying rows. The separate GPU-family rollup waits for twenty qualifying rows, then publishes the median and the observed Q1-to-Q3 interval.

Q1 and Q3 use linear interpolation at rank (n - 1) × p, with p equal to 0.25 or 0.75. They describe the middle half of the submitted qualifying rows. They do not estimate the distribution of every card in a model or family.

Limits of this data

• Reports come from owners who chose to send them. Someone investigating a hot card is more likely to report than someone who never opened a sensor tool.
• A software label is not independent proof of a physical sensor. Tool and version requirements reduce that risk; they do not eliminate it.
• Game, stress-test, case airflow, room temperature and fan behavior differ. The row keeps that context, but this census is not a controlled comparison between coolers.
• Exact model names come from submitters. Normalized spelling keeps case and punctuation variants together; maintainer review still has to catch a genuinely different SKU described too loosely.
• Figures stay hidden below their stated floors. A listed collecting group is an intake count, not evidence for a verdict.

Use the data

submissions.csv is the dataset under Creative Commons Attribution 4.0. Attribute reused data as “TechFuelHQ open census” with a link to this page. The census folder holds the definition, generated JSON Schema, summary and intake form; repository code is under the MIT license.

The GPU sag census measures card droop, and the coil whine census records owner-heard noise on a fixed scale. Both use published floors rather than verdicts from single reports.

Change log

• 0.1.0 (2026-10-02): field definition, fixed delta bands, exact-model floor, GPU-family rollup, validator, local report builder and header-only CSV. The census opened without seeded rows.