The bench · the game's own art on hardware a normal person owns
A Rig Your Friend Already Owns
exhibit twenty-six The bench
a small (human) team and a fleet of AI agents — the humans ran the harness and signed the numbers
Published 2026-08-26 (UTC)
We re-rendered our game's actual art — same prompts, same seeds, same checkpoint files — on a several-year-old consumer RTX 3090 and a gaming laptop, paired render-for-render against our 96 GB card's own archived output. Two of the three runs happened in the same physical computer. This page is the stopwatch, told honestly — including the one number we don't yet trust.
Four words this page leans on
- Diffusion model — the kind of AI that paints a picture from a text description, by starting with noise and refining it in steps.
- Steps — how many refinement passes the model makes. More steps, more seconds.
- Distilled / turbo — a model retrained to need very few steps (4–8 instead of 30+). The speed class our game actually ships.
- VRAM — the graphics card's own memory. A model must fit in it to run at full speed.
The moment this page is about
RealKeep is our living-world RPG — friends and family in one party on any mix of screens, a world that keeps living while you're gone, and an AI painting what happens as you play: scenes, foes, portraits, made up on the spot to match the story. All of it runs local — the mind, the art, the dice — on computers in our own home: no cloud AI service, no API meter, no model provider at the table. The price of that independence is simple and physical: the machines in the house have to be strong enough to carry the game. Whether they are — and how strong is strong enough — is a question you answer with a stopwatch, not a vibe. That's this page.
In the game, meeting a foe paints its portrait; walking into a cove scene sketches the shoreline. The player is waiting while that happens. On our 96 GB card those sketches feel instant. The question that kept us up: what happens on hardware a normal person owns? Not a flagship card — the RTX 3090 a friend bought for gaming back in 2021, or the laptop already on their desk.
What we ran, and the rule behind every number
Three runs, two computers — and the twist that makes the comparison unusually clean: the 96 GB card's baseline numbers (August 23rd) were measured while it lived in the same ordinary consumer tower that now holds the 3090 — a machine that is consumer-grade to the last screw, roughly five years old, ALL of it: the motherboard, the RAM, the disk, the case. There is not a single part in that box newer than about 2021. That matters more than it sounds: this is not a fresh build wearing one old card to look humble — it is a time capsule, the kind of machine already sitting under a desk in a million homes, and nothing in it was upgraded to flatter the bench. Between the two dates, the only hardware that changed in it was the graphics card, while the software provably did not change at all: the same render-engine checkout (cloned in May 2026 and never updated since — the install's own log shows one entry), the same torch 2.11 (cu128), and the same 595-series driver, with the system's package log showing zero driver changes across the window. The third run is an RTX 5090 Laptop GPU (24 GB — the laptop part, not the desktop card) in a gaming laptop, on its own cooling budget. So: card-vs-card in one attested box, plus a laptop.
What ran, exactly. All three rigs rendered from the same checkpoint files through the same engine — including the two fp8 entries, which are their vendors' standard releases, not a small-rig concession: the 96 GB card ran the identical fp8 files. Wherever this table says fp8, it is fp8-vs-fp8 on every rig.
| model | checkpoint file | precision | sampler / scheduler | cfg | step ladder |
|---|---|---|---|---|---|
| FLUX.2 klein-4B | flux-2-klein-4b | bf16 | euler / — | 1.0 | 2 · 4 · 6 |
| z-image-turbo | z_image_turbo_bf16 | bf16 | res_multistep / simple | 1.0 | 4 · 8 · 12 |
| krea2-turbo | krea2_turbo_fp8_scaled | fp8 (vendor release) | euler / simple | 1.0 | 4 · 8 · 12 |
| hidream-o1-dev | hidream_o1_image_dev_fp8_scaled | fp8 (vendor release) | model's own node / normal | 1.0 | 16 · 24 · 32 · 40 |
| kandinsky5-lite | kandinsky5lite_t2i | bf16 | euler / simple | 3.5 | 16 · 24 · 32 · 40 |
| z-image-base | z_image_bf16 | bf16 | res_multistep / simple | 4.0 | 16 · 24 · 32 · 40 |
Licences, enumerated — because "roughly permissive" is not a licence: klein, z-image-turbo, and z-image-base under Apache-2.0; kandinsky5-lite and hidream-o1-dev under MIT; and krea2-turbo under the Krea 2 Community License, which permits commercial use of outputs only while company-wide trailing-twelve-month revenue is below US $1 M — company-wide, not just the product; fine for us today, material if you're bigger. These are our readings of the licence texts we hold — hashed in the kit where the vendor ships a licence file (four of the six); the two Z-Image rows cite the vendor's licence by URL and opening date — they are not legal advice, and the full texts carry terms beyond the one clause we quote. Three candidates were dropped, with their real reasons: FLUX.1-dev is explicitly non-commercial; FLUX.2-dev is out twice over — non-commercial licence AND a 32 B-parameter body that doesn't board a 24 GB card in the first place; AlbedoBase-XL we dropped because we could not locate licence text in the copy we hold — if it exists and we missed it, point us at it and we'll run the model.
The shape of the run: 69 timed cells per rig — resolution ladders (512/768/1024), a step ladder (whose per-step economics a sibling page measured), and six real game subjects (two coastal scenes, two NPCs, a foe, an avatar — the game's own prompts, style-stripped). 48 cells were rendered with three different seeds, 21 with one — 165 timed renders plus six untimed warm-ups, 171 per rig, 342 in all. Each timed render pairs against its own archived baseline render of the identical cell. Models ran one at a time, in the same order on both rigs, each behind its own untimed warm-up, renders back-to-back — so sustained-load thermals are in the numbers, which is the state a player's machine would be in. One asterisk carried openly: z-image-base has no resolution ladder — its 12 renders are all 768×768, a quarter of the evidence the other models get. Timing is the engine's own execution window — denoising, image decode, and file save; not model load (that's what the warm-ups absorb: the 3090's klein warm-up paid 9.25 s against a 1.65 s timed median) and not network transport, which a player pays on top. The run logs — 165/165 completed on each rig, no errors — ride in the kit, because "zero failures" deserves an artifact, not an assertion.
One post-hoc reporting rule, adopted after seeing the data and disclosed as exactly that (not a pre-registration). The rule: keep every cell, report per-model medians, never a hand-picked render. Six archived baseline cells carry cold-load pollution — the archived render that happened to pay a model's load time — visible as absurd better-than-big-card ratios. We kept them; medians damp them almost entirely (dropping all six would move every model's baseline median by at most 0.005 s and no multiplier by 0.01).
The table that answers the question
Median seconds per render across all of a model's timed renders, identical mixed resolution-and-step sets on every rig; medians rounded half-up. The multiplier is the ratio of those medians — computing the median of per-render paired ratios instead agrees within 0.2× on every row (the largest gap: krea2 on the 3090, 4.7 paired vs 4.9 here). Because these medians mix resolutions, they deliberately won't match any single rung of the ladder table below:
| model | 96G card | RTX 3090 24G (same box) | RTX 5090 Laptop 24G | 3090 × slower | laptop × slower |
|---|---|---|---|---|---|
| FLUX.2 klein-4B (our sketch artist) | 0.48 s | 1.65 s | 1.39 s | 3.4× | 2.9× |
| z-image-turbo | 1.13 s | 4.44 s | 3.80 s | 3.9× | 3.4× |
| krea2-turbo | 1.97 s | 9.62 s | 5.86 s | 4.9× | 3.0× |
| hidream-o1-dev | 2.53 s | 7.34 s | 3.45 s | † | † |
| kandinsky5-lite | 6.17 s | 28.95 s | 24.46 s | 4.7× | 4.0× |
| z-image-base (undistilled, 768 only) | 7.84 s | 33.01 s | 28.88 s | 4.2× | 3.7× |
† hidream's seconds are real measurements and stand; its multipliers we withhold from the table because its baseline behaves anomalously — the section below reports them (2.9× and 1.4×) inside the argument for why we don't trust them.
The sketch ladder — the number the game lives on
Our in-game sketch artist is FLUX.2 klein-4B. Its job: a picture while the text is still being read. This table's rule: resolution-ladder cells only — steps held at 4 down the whole column, six renders per cell per rig, median with the cell's full min–max range beside it (the max in each cell is typically its first render — cache warm-up; the median is the steady state):
| sketch size | 96G card | RTX 3090 | RTX 5090 Laptop |
|---|---|---|---|
| 512×512 (the live default) | 0.26 s (0.26–0.40) | 0.88 s (0.88–1.19) | 0.71 s (0.69–1.27) |
| 768×768 | 0.48 s (0.47–0.61) | 1.65 s (1.64–1.96) | 1.37 s (1.36–2.02) |
| 1024×1024 | 0.82 s (0.80–0.96) | 2.86 s (2.84–3.17) | 2.40 s (2.35–2.98) |
Under one second for the live sketch size, on a 2021-vintage consumer card. Under three seconds for a full 1024 portrait. The big card is about 3.4× the 3090 and 2.7–2.9× the laptop down this ladder — and in our own playtests, below about a second a render simply reads as "the picture appeared." We state that as our reading, not a law of nature, and the engine clock is the render only: a player also pays their app's own overhead on top.
Three findings we didn't order
The finding we distrust, reported anyway. hidream-o1-dev looks like the laptop's triumph — 1.4× the big card's overall time, nearer the baseline than any other model manages. But split it by resolution and the story cracks: the 96 GB card's own hidream times are nearly flat — 2.49 s at 512, 2.50 s at 768, 2.60 s at 1024 — for a 4× increase in pixels. No other model's baseline behaves that way, and a card that paints four times the pixels for four percent more time is a measurement asking questions, not answering them. The consequence is real: at 512 the laptop beats the 96 GB card outright (1.90 s vs 2.49 s), while at 1024 the laptop is an unremarkable 2.2× behind. We first drafted a tidy mechanism story for the 1.4×; the per-resolution data contradicts it, so it's gone. What survives: the headline 1.4× is an artifact of the resolution mix sitting on an anomalous baseline — which is why those two multiplier cells are withheld from the table above. Either the big card carries a fixed per-render overhead that dominates hidream at small sizes — in which case the laptop's 512 win is genuinely real and worth its own controlled follow-up — or something in the archived baseline mismeasured. We're publishing the numbers, the anomaly, and the open question, and not the conclusion.
Speed class survives the hardware drop — across these three cards. Five of the six models hold their exact speed rank on all three rigs; the one mover is hidream, the anomaly above, drifting up the order as the rig shrinks. Fast stays fast and slow stays slow on cards of 24 GB and up — the scope of what we measured. Below that, where models stop fitting whole, category changes return; this page doesn't test 8–12 GB cards, and that's the honest next question, because that's the card most people actually have.
What 24 GB actually costs is the option, not the run. Every file in the table boards a 24 GB card and runs at full speed. But note what the roster already conceded: for krea2-turbo (12.8 B parameters) and hidream, the file everyone runs — our 96 GB card included — is the vendor's fp8 repack; native bf16 for that class would roughly double the weight bytes and stop fitting 24 GB. And the 30 B-class image models never made the roster at all: FLUX.2-dev's 32 B body doesn't board a 24 GB card without heavier surgery and its own quality questions — a different technique, and a different page. What the big card buys is the choice — native precision for everything, several models resident at once, headroom to serve other work while painting. What 24 GB keeps is everything this game actually ships.
What this means for the game
Our production art stack — the sketch artist at 512, the turbo scene painters, the portrait lane — runs at felt-instant to comfortable speeds on a single several-year-old consumer card, and on a gaming laptop. Scoped honestly: that's the render step alone, on an otherwise idle machine — and a 3090 is enthusiast hardware, not median hardware, second-hand for a small fraction of what a big workstation card costs, running here in a PC that has not seen a new part in five years. Still: "runs on a rig an enthusiast friend already owns" is a different product than "needs a server," and as of these measurements it is the true one. The game itself travels; the untested 8–12 GB question is the next page.
The kit
The published kit carries every render's manifest row — prompt, seed, steps, sampler, scheduler, cfg, checkpoint file, pixels, the engine's own render-seconds, and that render's paired baseline seconds in the same row — plus every image, the run logs behind the zero-failures claim, and per-model licence citations with file hashes. Every timing field is unchanged from our originals; only internal host labels were replaced. The two rigs ship as two separate manifests, and every row names its rig in its card field (the render-id prefix is the harness's tag, not a rig label). The workflow graphs land in the kit at release, so "same seeds, same graphs" becomes a download rather than a promise; until then the manifests, images, and logs are the receipts. 342 renders, 0 failures, medians as stated. (The 342 images themselves stay in the bench archive — no sibling kit ships images, and the manifests and logs are the receipts.)