gpu_stack.exe

gpu_stack/readme/frontdoor.txt

gpu_stack

A symbolic map of AI training infrastructure, from datacenter economics and GPU kernels down toward the physics the numbers keep borrowing from.

Read article Open layers Try CLI

read_graph.exe

Read it like a receipt, not a magic answer.

Start with a human question, then follow the named dependencies upstream. Every hop should tell you whether you are looking at an equation, a scenario value, or an unresolved root input.

The registry currently names 1517 variables and 959 equations.
Root debt means the 619 unresolved inputs stay visible instead of being smoothed over.

target cost.per_token The number a human asks about.

equations run cost, tokens, power The graph walks the ancestry.

root debt 619 named inputs Unknowns stay inspectable.

scenario explicit assignments Fixtures are anchors, not market claims.

Target selected: start with the question. The page keeps the output attached to the labels underneath it.

1517registered variables

959equations connecting them

619root inputs, named instead of hidden

799equations with unit checks

Not a bounded simulator

The point is to expose what each number is standing on.

Most training-cost talk jumps straight to a satisfying number. `gpu_stack` keeps the ancestry attached: equations, units, references, constraints, scenario assumptions, and the exact places where the graph has not decomposed reality yet.

Only universal physics constants belong in `Constant`.
Everything else stays a `Variable`: clocks, voltages, tariffs, GPU counts, batch sizes, and facility assumptions.
A root input is visible modeling debt. That is much better than hidden modeling debt with a haircut.

Dependency cone showing cost per token expanding into upstream equations and root inputs.

One output, many upstream obligations. The useful part is that the obligations stay inspectable.

layers.sys

Click a layer. Watch the dependency chain move.

The visible machine is a building, but the model treats it as a constraint bundle: grid interconnect, substations, cooling loops, water, occupancy, capex, operations, and uptime.

Inputs include power envelope, PUE, utilization, cooling load, and build cost.
Outputs feed cluster capacity, cost allocation, emissions, and schedule pressure.

trace_target.exe

Choose a question and follow what it depends on.

Cost per token is not a lone price. It depends on run cost, token count, facility power, throughput, utilization, hardware choices, and root assumptions that still need better evidence.

Use this as a mental model for the resolver, not as a live numerical solver.
The moving gold segment marks the direction of dependency pressure.

The graph is useful because each hop keeps its label. If a hop cannot be resolved from equations or scenario assignments, it comes back as a named missing boundary.

synthetic fixture resolves 4 of 4 targets

scenario-report status: ok

root_debt.dat

Root inputs are the visible unpaid invoices.

`root-debt` ranks unresolved root inputs by downstream blast radius. The point is not to pretend the largest family is bad. The point is to know which unknowns are currently expensive.

Total roots in the observed summary: 619.
Grouped root families in the observed summary: 151.
The heaviest shown family is `physical.lithography.medium` with total weight 3014.

physical.lithography.medium
weight 3014, roots 15

physical.lithography
weight 2185, roots 11

physical.lithography.source_plasma_drive
weight 1943, roots 8

physical.mosfet
weight 1866, roots 18

physical.process
weight 1293, roots 8

These bars normalize the five README weights against the top family. No new metric is being invented here.

CLI.exe

Use the command line as a microscope.

The package is still closer to a research instrument than a polished app. That is useful right now. Ask it what exists, what is unresolved, and where a claim bottoms out.

python -m gpu_stack.cli stats
python -m gpu_stack.cli verify --profile fast
python -m gpu_stack.cli resolve econ.cost.per_token --preset scenarios.dense_training_cost_fixture --trace --missing
python -m gpu_stack.cli root-debt --families --limit 5
python -m gpu_stack.cli scenario-report scenarios.dense_training_cost_fixture --json

Root input

A variable with no defining value relation yet. It might be a real scenario boundary, or it might be physics that still needs decomposition.

Dependency cone

The upstream set of variables, equations, assumptions, and constants needed to explain one target.

Scenario fixture

A named set of explicit assignments used to resolve targets reproducibly. Synthetic fixtures are test anchors, not market claims.

MFU

Model FLOPs Utilization: how much of the theoretical model compute is actually useful during training.

HBM

High Bandwidth Memory: the fast memory sitting close to the accelerator package, often a ceiling for throughput.

PUE

Power Usage Effectiveness: total facility power divided by IT equipment power. Cooling and overhead show up here.

Good for now

Teaching the stack without flattening it into vibes. Auditing which numbers are constants, equations, measured values, or scenario inputs. Tracing an output from economics into infrastructure, performance, manufacturing, and physics.

Not finished yet

It does not solve simultaneous systems. It is not a full digital twin of a datacenter. It still contains root inputs that deserve deeper decomposition, sourcing, or an explicit scenario boundary.

next_work.exe

Where the page wants to go next.

1. Cone viewerA browser view where any variable expands into dependencies, equations, references, unit checks, and unresolved root inputs.

2. Stack atlasA visual atlas from campus power to accelerator kernels, with toggles that reveal what a number is made of.

3. Scenario labChange assumptions and watch costs, emissions, latency, manufacturing limits, and utilization move together.

4. Physical floorPush roots toward material properties, thermal limits, geometry, nuclei, and quarks where the model can justify that move.