Compute
Where the tokens actually come from, and where they come from next.
Every hardware figure on this page is quoted from NVIDIA's own specification tables and linked. Anything we could not source is left out rather than estimated — the same rule the site applies to market data it cannot verify.
#The routing
The gateway is the constant. It already speaks one protocol to the editor and one protocol upstream, so moving from rented capacity to owned capacity changes a base URL in a serverless function and nothing a holder ever sees.
| Stage | What it is | What it buys | |
|---|---|---|---|
| Today | LIVE | One funded private workspace — aggregated capacity, 1060-model catalog, exact-string allowlist | Breadth. Every frontier model behind one credential, no procurement. |
| Next | PLANNED | RunPod dedicated — H200, B200 | Price per token, and capacity that doesn't queue behind someone else's job. |
| Rack-scale | PLANNED | GB200 NVL72 | The models that do not fit anywhere else. |
We are not pretending to own silicon today. Today is rented, aggregated capacity paid for out of a funded workspace, and the gateway's ceilings exist precisely because it is a shared wallet. Owning the machines is what changes that.
#Owned capacity is what makes PRIVATE real
The hardware roadmap on this page and the privacy ladder are the same project seen from two ends.
L1 · no-log is a contract: we route only to operators who agree to retain nothing. Auditable, and still someone else's machine and someone else's word.
L2 · dedicated is the rung that stops being a promise. On our own GPUs there is no second operator to have a policy about, no third-party fallback to fail over into, and nothing to audit — the prompt reaches hardware we run and no one else touches it.
That is the argument for buying machines rather than renting forever, and it is why frodo-private
lands at P2 rather than P1: the mode is only as private as the metal underneath it, and the
metal is the part that has to be bought. Rented capacity buys breadth; owned capacity buys a claim
we can actually stand behind.
#The hardware
| Memory | Bandwidth | Source | |
|---|---|---|---|
| H200 | 141 GB HBM3e | 4.8 TB/s | nvidia.com/data-center/h200 |
| B200 (DGX node) | 1,440 GB HBM3e across 8 GPUs | 64 TB/s | nvidia.com/data-center/dgx-b200 |
| GB200 NVL72 | 13.4 TB HBM3e | 576 TB/s · 130 TB/s NVLink | nvidia.com/data-center/gb200-nvl72 |
H200 was the first GPU to ship HBM3e — NVIDIA's phrasing is "the first GPU to offer 141 gigabytes (GB) of HBM3e memory at 4.8 terabytes per second (TB/s)."
#Why the rack, and not just more nodes
Seventy-two GPUs is seventy-two GPUs either way. The difference is what sits between them.
Split across nine 8-GPU nodes, a model too large for one node is sharded across the network. Every token pays that crossing, on every layer, every forward pass. Add GPUs and you add crossings.
GB200 NVL72 connects 36 Grace CPUs and 72 Blackwell GPUs in a rack-scale, liquid-cooled
design. NVIDIA describes the result as "a 72-GPU NVIDIA NVLink domain that acts as a single,
massive GPU", carrying 130 TB/s of GPU-to-GPU communication — "the largest NVIDIA NVLink domain
ever offered". Their headline claim for it is 30× faster real-time trillion-parameter LLM
inference versus H100.
What that means for a FRODO key: the largest models stop being a question of whether they fit and become a question of what they cost.
| GB200 NVL72 | |
|---|---|
| Configuration | 36 Grace CPU · 72 Blackwell GPU |
| GPU memory · bandwidth | 13.4 TB HBM3e · 576 TB/s |
| NVLink bandwidth | 130 TB/s |
| NVFP4 Tensor Core | 1,440 PFLOPS |
| CPU cores | 2,592 Arm Neoverse V2 |
| Cooling | Liquid, rack-scale |
All figures: NVIDIA GB200 NVL72 specifications.
#What this costs, and who pays
Compute is bought, not conjured. The loop that pays for it is the point of the whole design:
More GPUs on one side, more trading on the other.
Creator fees received by the project and inference revenue are designed to buy GPU hours; GPU hours serve keys; keys are worth holding; holding is what the market prices. See the ecosystem for how the tiers work and what opens at each one.
#Next
- Routing — what a request passes through before it reaches any of this
- Endpoint catalog — how to point an editor at it