Training, Inference, and What Compute Earns
GPU-backed credit is underwritten against what compute capacity earns, and what it earns depends on which of two workloads is renting it. This primer defines both in credit terms — no machine-learning background assumed — and points to where the difference is already visible in published series: tenor, price by generation, and utilization.
01 Two Workloads
Training builds the model. It is a project-style compute campaign: thousands of the newest accelerators, wired together on one high-bandwidth fabric, run near flat-out by a single customer for months. The buyers are few — frontier labs and hyperscalers — and the procurement is characteristically a multi-year committed contract for a dedicated cluster. When the campaign ends, the demand ends with it until the next model generation begins.
Inference runs the model. Every chatbot query, application programming interface (API) call, coding assistant, and AI feature inside an application is inference: the trained model producing output for an end user. The demand is recurring and usage-driven — it scales with adoption and with the revenue of the applications on top, not with any one project's calendar. It is latency-sensitive, it follows end-user activity through the day, and it runs acceptably on a far wider range of hardware than training does, including older generations.
02 The Credit Translation
Training demand behaves like construction backlog: lumpy, concentrated in a handful of counterparties, and wrapped in multi-year contracts. Those contracts are the offtakes that appear in GPU-backed credit as collateral quality — the ledger's own spread history prices draws by the contract standing behind the compute (/credit).
Inference demand behaves like utility load: diffuse, recurring, diurnal, and transacted at shorter tenors. And because a GPU-hour is non-storable — an hour unsold is an hour gone — capacity coming off contract reprices at the prevailing curve immediately, the way power does, not the way a warehouse of inventory does.
03 Where the Mix Shift Shows Up — Three Observables
Tenor. Training procurement supplies the long committed contracts; inference demand transacts on-demand and at commitments of a year or less. As the workload mix shifts, the contract book behind a borrower shortens, and more of its revenue rolls to the prevailing market each year — rollover exposure priced off the published term curve (/research/od-vs-committed; worked rollover mechanics at /applications). Shorter books convert single-name offtake credit into portfolio and market risk — the kind monitored with published series rather than credit memos.
Price by generation. Inference consumes memory bandwidth more than peak arithmetic, and older datacenter GPUs still carry competitive bandwidth. In the current cross-section, rental rates per unit of memory bandwidth are flat from A100 to B300 while rates per unit of raw compute steepen with age — the pattern of a market already pricing inference at the margin, and the mechanism by which old silicon keeps earning (/research/gpu-age-curve).
Utilization. Inference load follows end-user activity through the day, so realized revenue per GPU-hour sits below posted rates even for contracted fleets. Posted price times full utilization is not a revenue forecast; the filed realized figures are tracked at /realized.
04 What This Does Not Say
This primer makes no forecast about the training-inference mix. The point is narrower: the two workloads leave different fingerprints in observable prices — tenor structure, per-generation pricing, realized-versus-posted gaps — and each fingerprint is published as a series that can be watched rather than assumed. The falsifiable markers for an inference-led repricing are listed in the age-curve note; the term structure and re-contracting history are in the on-demand-versus-committed note. Sources and series construction per the Methodology.