Every assumption behind the interactive explorer, in one place. The explorer states each figure; this page says where it comes from and how far to trust it.
A request that hits a warm session — one whose KV cache and recurrent state are still resident — prefills only its new turn, and is served well and comfortably. A cold request re-prefills its whole context on the compute roofline, briefly stealing bandwidth from every active user. Deployments are therefore sized by warm sessions, planning on p5: 95% of Monte-Carlo draws hold at least that many.
That hypothesis is no longer just an assertion. The Max cold req/s and Cold-spike tolerance readouts price it on prefill's own (compute) roofline, in a second pair of units — a work rate and a burst size — that the session count cannot express: a miss costs 18–19× the machine time of a hit, near-identically across the four architectures priced in docs/scenarios.md § 8 (DeepSeek-V4.1-Flash, Qwen3.8-Flash-Next and GLM-5.3-Flash postdate that table).
A transparent memory model, calibrated to a 1×H200 + 27B FP8 pool of 2.77M KV tokens — a figure projected from the baseline's measured FP16 pool (~1.337M tokens, ×2 for FP8 plus freed activation memory), not itself a direct measurement. The per-GPU activation reserve is solved from that anchor, so every other configuration falls out of the same arithmetic rather than being guessed.
A real 27B + FP16-KV + TP2 bring-up reported 3,233,564 KV tokens at startup (110.59 GiB per worker; 17.54× concurrency at 184,320 tokens) — within 0.3% of this model's 3.24M prediction, with nothing about TP2 or FP16 fitted. First non-circular validation of the reserve + TP arithmetic + FP16 doubling. Run backwards it pins the per-GPU reserve at 18.24 GiB against the anchor-solved 17.98 GiB, i.e. an equivalent 1×H200 FP8 anchor of 2.762M tokens against the projected 2.77M (the ~1.4% residual is left in the constants rather than re-anchored: it would move every published figure by under 0.5%). What it still does not settle: the recurrent-state dtype, the other six models, and — since a globally wrong anchor shifts prediction and measurement together — the FP8 path itself.
Retired 2026-07-29: the study used to carry a low calibration anchor as an adverse case — 2× the measured FP16 lower bound (2.278M tokens ⇒ a 33.0 GiB per-GPU reserve). The TP2 measurement refutes it outright: it predicts a 2.750M-token pool where 3,233,564 were reported (−14.9%), against −0.26% for the anchor in use. An adverse case has to be one the hardware has not already ruled out.
Capacity is estimated by simulation over a user+subagent prompt-length mixture, not solved in closed form; every resident session is also charged its constant recurrent state. Draws are seeded from the configuration (since 2026-08-03), so the same configuration always renders the same numbers, and the load/latency controls — which cannot affect capacity — leave every capacity figure untouched. Two things still move it legitimately: neighbouring slider positions draw a different sample (a few sessions of spread is sampling noise, not a real effect), and while a slider is being dragged the page renders a lower-iteration draft, which can land a session or two from the settled value. The Python sweeps in tables.py use fixed seeds throughout. Real non-linearities (the expert-union kink at n=32, the cap's tail-truncation, the prefix floor) are explained in docs/scenarios.md. Decode speed is per-step bandwidth ÷ (weights + live KV + per-sequence state read/write), sped up by MTP.
TP (tensor-parallel, any N) shares one weight copy across all GPUs, so the pooled KV cache grows faster than N×; effective decode bandwidth scales by N × 0.90^log₂N (the baseline's 0.90 haircut applied per doubling — beyond 2 GPUs this is a projection, not a measurement). Widening TP always raises total capacity, because every DP group re-pays for its own full copy of the weights.
DP (data-parallel, any N) keeps N per-replica caches. Aggregate throughput scales ~N×, but a returning user is only warm on their home replica (sticky routing), and a shared CPU-offload buffer splits N ways.
MoE decode reads only the active experts: weight bytes per step grow with the batch's expert union, from the shared block up to all routed experts. The explorer uses the conservative no-overlap union bound (the docs also show the optimistic expected-union bracket). Past the point where every routed expert is read each step — n = 32 on the 35B-A3B — the fixed weight read stops growing with the batch — the slope break the explorer's chart D shows.
All constants assume the FP8 KV cache (--kv-cache-dtype fp8_e4m3), as tested in the baseline. The FP16 switch doubles KV bytes/token (half the pool, heavier decode reads); weights and the recurrent state are unaffected, and the activation-reserve calibration stays pinned to the FP8 anchor. Sanity: FP16 + 27B + 1×H200 gives a 1.39M-token pool, inside the baseline's measured [1.14M, 1.40M]. GLM-5.3's sparse-MLA path and DeepSeek-V4-Flash-0731's V4 path both require a quantized (FP8) KV cache in vLLM, and DeepSeek-V4.1-Flash's main KV is FP4 by training (E2M1 with one E4M3 scale per 16 channels; its sliding windows stay FP8) — that native layout is what its FP8 arm prices — so the FP16 toggle is disabled on all three. On Qwen3.8-Flash-Next the switch also doubles the top-2048 sparse-decode read (main-KV bytes); its compressed indexer keys stay fp8. GLM-5.3-Flash inverts the constraint entirely: its fp8 KV cache is Blackwell-only — vLLM's recipe requires BF16 KV on Hopper — so on H200 the KV toggle locks to FP16 and the model itself refuses to price the fp8 arm there; the FP8 numbers are a Blackwell configuration.
A session offloaded to host RAM still counts as warm capacity, but only sessions whose KV is resident in GPU HBM can decode — an offloaded one must be restored over PCIe first (a latency the model does not price). Every decode-side readout (the per-user/aggregate stress tiles, the explorer's chart C capacity zone) is therefore computed over HBM-resident warm sessions only, so moving the offload slider never changes per-user decode speed. For DP the buffer splits across replicas.
Cold / invalidating requests occupy KV but never count as warm — they cap the reusable-hit ceiling at (1−f). Past ~25% invalidation about a third of the pool is paying for sessions that will never be reused.
Other projections carry their own flags where they appear; these three are memory-accounting assumptions with no measurement behind them at all, so they are separate, named controls rather than a bundle.
--tensor-parallel-size 8 stores eight copies. Sharded (the default, and the layout every number here has always assumed) prices vLLM's decode context parallelism, which splits those copies along the sequence; the deploy recipe emits --decode-context-parallel-size tp / kv_heads. Replicated prices plain TP: the pool divides by tp / kv_heads and per-step cache reads multiply by it (GLM-5.3 on 8×B300: 27.3M → 3.4M tokens). Disabled while the group is no wider than the heads (Mistral's 8 heads never replicate; the Qwens shard at TP ≤ 2 or 4). DCP's caveats as of 2026-08: speculative decoding under it is still in development in vLLM, so the MTP slider and this arm may not be available together; attention-DP + expert-EP, the other way to one copy, is not modelled. research/kv_tp_sharding.md.max_num_seqs rather than per-session. fp32 would double the charge and costs the Qwens ~10% of warm capacity — the largest un-measured structural knob on those models. Mistral-3.5 and GLM-5.3 hold no recurrent state (the control is disabled); DeepSeek-V4-Flash-0731 and V4.1-Flash pay a fixed 14.9 and 2.8 MiB/session of attention windows and fp32 compressor buffers whose precision is set by the serving stack, so they have no knob to turn either.w_resident figures are raw or on-disk checkpoint bytes, i.e. under-estimates by an unknown margin; the one calibrated data point is the 27B's as-deployed 28.8 GiB running ~15% above its raw params. Transferring that ratio to a different architecture and quantization recipe is an extrapolation — which is why it is a knob rather than a constant. The knob is disabled on the 27B itself, where the figure is already as-deployed and applying +15% would double-count.The slider sets the speculative-decode speedup (1.0× = off). The base quantity is the per-draft acceptance α: with 2 draft tokens, speedup = 1 + α + α², so 2.94× ⇔ α ≈ 97% — the accepted length measured on the production 27B deployment before the Qwen3.8-27B swap (research/decode_mbu.md) and carried over unmeasured on 3.8; 1.7× ⇔ α ≈ 47% was the pre-measurement fit. The inversion is exact only for the two 2-draft Qwen models (Qwen3.8-27B, Qwen3.6-35B-A3B): GLM-5.3's MTP drafts 5 tokens, DeepSeek-V4-Flash-0731 drafts 7 and DeepSeek-V4.1-Flash 5 (DSpark, the trained block size), Qwen3.8-Flash-Next drafts 3 and GLM-5.3-Flash 5 (their vLLM recipes), and Mistral-Medium-3.5 ships no MTP module at all (its slider models an external EAGLE-style draft, unmeasured). The slider applies to the selected configuration only — the frontier table prices every row at its own model's capability, so cross-model ranking is never moved by this control. MTP + hybrid-model prefix caching is an immature serving path, so the conservative purchasing view keeps it at 1.0×; the purchasing base likewise excludes CPU offload and N>2 TP. These controls exist so that headroom stays visible, not hidden.
Both request classes draw log-normal lengths. The user class is fitted by maximum likelihood on 1,850 real request lengths (median 31k, σ = 0.81): ~68% of prompts within ×/÷ e^σ ≈ 2.25 of the median, p95 ≈ 3.8× the median, mean ≈ 1.39× the median. The mean — not the median — drives warm capacity, so a fatter tail of huge pool-hogging sessions means fewer warm. The subagent class is assumed (median 8k, σ = 0.90; no subagent trace has been collected yet). Lengths above the max_seq_len cap are truncated to it — a lower cap trims the tail (smaller worst-case cold prefill, less pool hogging), and a median far past the cap degenerates toward all-sessions-at-cap.
The subagent ratio r is subagent requests per user request, so subagents are r/(1+r) of sampled sessions; they draw much shorter prompts behind their own lean 3k prefix (or reuse the user prefix, if that toggle is on — no extra reserved block, but each subagent then carries the bigger base). The system / shared prefix is the stable block every user request shares — system prompt, skills, rules, tool definitions. It is reserved once per cache and deduplicated across every session, so a bigger shared prefix costs the pool once and saves it on every session: raising it raises warm capacity. The reference workload uses 15k; the baseline's real agent already exceeded 30k. This only pays off while the prefix is byte-stable across users and turns — a per-tenant salt or an edited tool list turns it into per-session bytes, which is what the invalidation control prices.
The model prices concurrent sessions per replica group. The optional population layer derives the system total as headcount × peak_active_share × sessions_per_active_user, then divides it across DP groups. Headcount is the number of people with access. Peak active share is the fraction with a live session in the busiest sizing interval. Sessions per active person counts parallel agents. Leaving headcount empty keeps the direct Concurrent-users control and today's numbers. Both population shares are unmeasured inputs. Estimate them from gateway logs by counting distinct user IDs per 15-minute window and simultaneous active sessions per user ID. The tool takes the conservative reading that every parallel session runs a full request stream with its own think-time loop. A person holding several sessions but attending one at a time is the lower-load bound: cache use multiplies, but prefill load does not. Think time is the full inter-request interval. It includes the previous response's prefill and decode, not idle time on top. The open-loop arrival rate is sessions divided by think time, so response latency never changes the next arrival. A closed loop slows when responses do. The reference load remains 64 sessions at one turn per 30 s, or 2.13 main requests/s. Two readouts use a separate stress point: the ITL spike and tokens-lost figure price every GPU-resident p5-warm session decoding. Act 2's steady-state tiles read the selected load. A warm hit still prefills its turn size, 2,000 tokens by default. At low miss rates the hit leg dominates duty, so 500 to 8,000 tokens moves B* by about 3.5× on the 27B/TP2.
Act 1's per-user decode figure is a stress test: it prices the curve with every GPU-resident warm session decoding at once. That is the right worst case — a cache flush or a correlated burst really does put the whole population in the batch — and the wrong expectation. Because arrivals are open-loop, a user spends most of the think-time interval waiting on a tool or a human, so the number of sequences in the decode batch at any instant follows from Little's law on the decode phase alone (a request queueing for prefill, or being prefilled, is not yet decoding): E[n] = λ × out / v(n). Multiplied through, that is a flow balance with no inversion in it — n × v(n) = λ × out, delivered output tok/s against demanded. The left side is the aggregate decode curve (chart D), strictly increasing in n, so the crossing is unique and both charts C and D mark it.
The gap is large enough to change a purchase. On the 27B / 2×H200 at the reference load the batch holds ~7 sequences at ~137 tok/s, against ~195 warm sessions at ~18 tok/s if they all decoded at once — the same curve, read at two batch sizes, so the ~8× is the size of the reporting error, not a hardware result. The batch cannot outgrow the pool: a batch of n needs n contexts resident in HBM, so the search stops at the GPU-resident warm population, and a load that population cannot retire decoding at once is reported as saturated rather than priced at a batch the machine cannot hold (past it the engine is evicting, and every return is a cold prefill that the miss-rate control prices). Three caveats travel with the number, and the tiles state all three. Mean field: v is evaluated at the mean batch rather than averaged over the batch-size distribution; v is convex in n, so by Jensen E[v(N)] ≥ v(E[N]) and this is the conservative side. Decode only: prefill chunks sharing a forward pass are the ITL spike, priced separately — this is the clean-decode speed between spikes. It assumes the requests are served at all: if prefill duty has reached 100% the queue is unbounded and nothing reaches a steady state, which is why the tile refuses to quote a speed there.
The point depends on the request rate and the output length only through their product, and on nothing else — so those two inputs are the entire error budget. n is not linear in that product: per-user speed falls as the batch grows, so successive output-length multiples move n super-linearly until the curve saturates outright. Output length was long the one assumed input on this page — the workload model is fitted on 1,850 real prompt lengths and had never fitted output lengths. Since 2026-08-27 the 400-token default is measured (mean 404 over a 7-day production agentic trace; the earlier 1,000-token assumption was a consistency guess against the traced 10.8 s served per request), and it remains an exposed slider rather than a buried constant. Mirrored as steady_decode_point() in scenario_model.py; the tables regenerate from tables.py.
The one readout priced in FLOPs, not HBM bytes (research/prefill.md). A miss re-prefills its whole context in max_num_batched_tokens chunks (GEMM + the quadratic attention term) against the part's dense FP8 peak; every readout is pinned to vLLM's 32,768 default, where the effective MFU is the calibrated 45% — the soft input: the plausible [30–55%] bracket (three production calibration points; low edge re-opened on 2026-09-18) spans ~1.8× end to end. The headline is 1/(expected miss cost), priced on the context distribution's heavy tail (E[L²] — the quadratic attention term must not be priced at the mean length); the p5–p95 sub-line is the cost spread of a single miss. It is a per-replica-group ceiling that no KV pool, CPU offload or warm headroom can raise. f* is the miss rate that saturates the group at its share of the current load (users / think time, warm turns included; a DP grid splits that load across replicas).
Every chunk is charged its attention over the cache it lands on, so a miss's FLOPs are chunk-size invariant (the pair count telescopes) — but each of its passes also streams the resident weights, an overhead that multiplies by the pass count, so its total machine time is not: that per-pass roofline is what makes the effective MFU fall at small chunk sizes. Small chunks shrink the ITL spike every decoder sees (the spike prices the chunk's marginal FLOPs — its host pass streams the weights anyway) but sink MFU and the cold-request ceiling with it: that is why vLLM's default is 32k, not 2k, and why the explorer sweeps the knob in a chart instead of exposing it as a slider. A warm hit pays its new turn's attention over the whole cached context at the marginal rate (its small pass rides the serving steady state).
Max cold req/s and f* are a duty cycle — a mean rate against a mean service time — and a mean sees neither variance nor correlation. Both bite. A miss's service time runs as L² on a log-normal L, so its squared coefficient of variation lands at 5.5–8.3 where an exponential would sit at 1, and the M/G/1 (Pollaczek–Khinchine) wait diverges well below f*: the latency ceiling f_sla — the miss rate whose mean TTFT reaches the TTFT budget — binds at 0.35–0.93× f* (tightest on the most prefill-fragile config, Mistral-3.5/TP4), with the duty cycle still reading a comfortable 76–93%. And invalidation arrives in clumps, so B* prices the largest simultaneous burst of misses whose last request still gets a first token in budget; it is linear in the budget (a 5 s target halves every number, changing no ranking) and reaches zero exactly at f* — which is what makes f* a limit rather than an operating point. A global flush puts the machine at f = 100% until sessions re-warm; above 100% duty there is no steady state and recovery is set by admission control, unmodelled here. One queue per replica group: a DP burst spreads across replicas only as well as the router balances it, which the sticky routing DP needs for cache reasons works against.
Mean TTFT comes from the same M/G/1 queue, solved against the mean — a p95 budget binds at a lower miss rate than anything shown. The sharpest consequence is on the requests that hit: under first-come-first-served a warm hit waits behind whatever misses are in front of it, so the cache-miss rate is a latency parameter for the hitting users too — at a 20% miss rate on the 27B/TP2 a hit's TTFT reaches 74× its own service time. Processor sharing is the other end of the bracket (vLLM admits in arrival order but runs several admitted prefills concurrently); neither end is uniformly optimistic, and which is which flips by request class.
A backlog drains at (1 − duty) seconds of work per second, because the standing traffic keeps arriving throughout — so the last request's TTFT is the drain time under either scheduling discipline. During the drain the scheduler has a prefill chunk to place in every forward pass, so the ITL spike is the steady state for the whole drain: the warm users who did nothing wrong simply stop receiving tokens at their normal rate, and the tokens-lost figure is that difference integrated over the drain. The "full flush" burst preset sets the burst to the p5 warm population of one replica group, capped at the slider's 512 — the correlated event a prompt-template deploy actually is.
Chart G sweeps one assumption (the miss rate); the sensitivity panel sweeps every soft input — miss rate, think time, TTFT budget, warm turn, prefill MFU, speculative speedup, and the prompt-length median and shape — one at a time with the rest held fixed, and reports where the binding constraint changes hands or the current load stops fitting. The closed-form ceilings (latency, saturation) are exact along every sweep. The two sampled ceilings cannot be Monte-Carlo re-filled at every point, so the workload rows (marked ≈) use mean-field stand-ins — expected pool cost per session for cache, mean-context decode speed for decode — each calibrated to pass exactly through the Monte-Carlo value at the current settings. Flip locations on those rows are approximate to the stand-ins' curvature error; the ranking of which assumption sits closest to a flip is robust.
Every one of these makes a real machine worse than the model: kernel-launch/scheduler per-pass costs (the small-chunk end of the explorer's chart E reads better than a real machine), Poisson arrivals (real agentic traffic is burstier), solving against mean rather than percentile TTFT, preemption/recompute under a full KV pool, the decode batch stretching a drain 1–3%, and PCIe restore latency for offloaded sessions. NVFP4 checkpoints are charged the FP8 tensor rate — their mixed W4A4/FP8/BF16 recipes could really run faster or slower, so for NVFP4 configs the prefill figures are a modeling choice, not a bound.
The H200 (141 GB HBM3e, 4.8 TB/s) is the calibrated baseline. The B300 (Blackwell Ultra: 288 GB HBM3e, 8 TB/s, native FP4) reuses the H200-solved ~18 GiB per-GPU reserve, plus a measured +9.75 GB/GPU correction: the H200 actually delivers ~150.75 GB usable against its 141 GB vendor figure (the calibration silently absorbs that margin), while a real B300 nvidia-smi dump shows 275,040 MiB = 288.4 GB — nominal bytes, no Hopper-style over-provision — so the transferred reserve must add the hidden margin back (research/gpu_b300.md; formerly a sensitivity, measured 2026-07-27). Both parts are modelled as 8-GPU NVLink domains, so a deployment is one node at most.
Swaps in real NVFP4-checkpoint byte counts (4.5 bits/param on quantized tensors; what stays high-precision is recipe-specific — see research/nvfp4.md — e.g. RedHatAI's 35B-A3B keeps the DeltaNet blocks BF16 while NVIDIA's GLM recipe quantizes only the routed experts). Gated to native-FP4 GPUs: vLLM's Hopper fallback is weight-only Marlin with a known correctness bug (open as of 2026-07-27), so H-generation NVFP4 is deliberately not modelled. The KV cache is never 4-bit here — an owner policy: vLLM's nvfp4 KV shipped 2026-05 (Blackwell-datacenter-only) but is not modelled. Non-obvious: on the MoE models NVFP4 makes the fixed per-step read heavier (BF16-kept blocks) while expert reads shrink 1.78× — low-concurrency decode slows, high-concurrency speeds up. Every model but GLM-5.3 and DeepSeek-V4.1-Flash has a measured NVFP4 checkpoint as of 2026-09-10 (research/nvfp4_2026-09.md, every figure read from every shard header): NVIDIA's for Qwen3.8-Flash-Next (routed experts only, 132.6 vs 185.5 GB) and DeepSeek-V4-Flash-0731 (its experts already ship 4-bit with E8M0 block-32 scales; NVIDIA's repack to E4M3 block-16 scales is 5% heavier — the arm exists for the NVFP4 kernel path, and the explorer prices what it weighs), RedHatAI's for Qwen3.8-27B (dense MLPs only, 23.4 GB) and GLM-5.3-Flash (the vLLM recipe's named checkpoint: 42 decode layers' experts NVFP4, the rest upcast to BF16 — 197.8 vs 328.3 GB resident, but the fixed per-step read grows 14.0 → 16.7 GB). GLM-5.3 itself has no NVIDIA or RedHatAI checkpoint; NVIDIA's GLM-5.2 recipe is kept as a projection onto its tensor-identical weights. DeepSeek-V4.1-Flash (released 2026-09-10) has no official NVFP4 checkpoint; its experts already ship 4-bit with E8M0 block-32 scales, and NVIDIA's repack of V4-Flash-0731 to E4M3 block-16 scales came out 5% heavier, so the option is greyed out rather than projected.
research/prefill.md): the two share every config field and every tensor shape (1,606 tensors, identical FP8 checkpoint size), so the memory, prefill and decode constants carry over exactly; the MTP acceptance (2.94) is a property of the draft head's weights and is carried over unmeasured. Terminal-Bench rises from 60.7% to 79.8% on 2.1 (AA, xhigh effort); on 4.0 it scores 5.6% and Qwen3.6-27B has no run. research/model_qwen38_27b.md.research/model_35ba3b.md. 262k native, 1M via YaRN.research/model_mistral_medium35.md.transformers_version differs) and on every one of 118,629 tensor shapes (identical FP8 checkpoint size), so the memory, prefill and decode constants carry over exactly; the MTP fit (1.7, itself transplanted) stays unmeasured, and the NVFP4 bytes are NVIDIA's 5.2 recipe as a projection. Terminal-Bench rises from 77.9% to 83.9% on 2.1 (AA, max effort); on 4.0 it scores 41.9%, the best AA-measured figure on this frontier, and GLM-5.2 has no run. research/model_glm52.md, research/model_glm53.md.research/model_dsv4flash.md.research/model_dsv41flash.md.research/model_qwen38flashnext.md.research/model_glm53flash.md.Wall power is priced from the duty cycle the model already computes, in three GPU states (research/power.md): prefill at ~0.90× TDP — compute-bound prefill is power-cap-limited, so the figure is flat across the MFU 30–55% band (the cap binds before the FLOP peak); decode at ~0.55× TDP (bandwidth-bound; the softest constant, measured band 0.45–0.75 on Hopper); idle at a measured warm-idle floor. The prefill fraction is min(1, ρ) — the duty cycle, clamped at saturation, past which the GPU simply cannot prefill more than 100% of the time; the decode fraction is the output-token demand (a measured ~400 tokens per request — 7-day production agentic trace, 2026-08-27; previously assumed 1,000) against the decode capacity at the per-user decode floor (40 tok/s by default; the decode-floor slider moves it), capped at what prefill leaves. On top: a per-GPU host/chassis adder (DGX spec ceiling — conservative) and the facility PUE. The GPU term carries ±20–25%; every B300 figure is extrapolated — no published Blackwell Ultra power-state measurements exist. The hardware line is GPU-hours at an on-demand rental list price (cross-provider medians, getdeploying.com, September 2026: H200 $4.40, B300 $7.89 per GPU-hour at EUR/USD 1.16; the GPU-price slider overrides it), 720 h/month, flat. A market snapshot, not a cost of ownership: no depreciation schedule, staff, networking or storage, and NVIDIA publishes no list price for either part. Note the convention: a rental rate is the provider's all-in price, power included, so for a rented GPU the electricity line double-counts (~7% of the total at the defaults) and the hardware line alone is the bill; for owned hardware, enter an amortised €/GPU-hour and both lines apply. The bill, the frontier's cost column and the €/user and €/Mtok figures are the sum of the two lines. Mirrored as power_draw() / energy_cost() in scenario_model.py.
The frontier table ranks every model × split on this GPU by max users and prints the bill. The hardware line of the bill is a function of the GPU count alone (only the electricity term follows the load), so a users-versus-cost view collapses every row of one topology onto a band and says "run fewer GPUs". Chart H asks the purchasing question instead: what does one seat cost against what the model can do? y = the bill with the configuration full — at its max users, electricity included at that load — divided by those users, its €/seat at capacity (log). Not the bill at your load over your users: that is the GPU count again, and every row on a topology would price the same; x = the model's Terminal-Bench pass@1 as measured by Artificial Analysis (one lab, one harness per version; vendor cards quote other versions and harnesses and are deliberately not used, with one exception: DeepSeek-V4.1-Flash carries its card's 90.6 and 31.2 by owner decision until AA publishes a run of either; research/terminal_bench.md). Which version is a toggle on the chart, because the two do not rank this field the same way: 2.1 (89 tasks × 3 repeats, Terminus 2 — AA's legacy eval) puts the top four models inside 7 points, about what one scaffold change moves a single model, while 4.0 (66 tasks × 3 repeats, mini-SWE-agent v2.4.6 — the version in AA's Intelligence Index v4.3) puts them inside 17 and reverses the order at the top: GLM-5.3 leads Qwen3.8-Flash-Next by 17 points there and trails it by 2 on 2.1. The staircase is redrawn per version, and the frontier table prints both columns whichever is on the axis. 4.0 being the harder benchmark does not make it the better axis here — it is also a different harness and a smaller task set, and two models score a measured 0.0% (0 of 198 runs), which is a score and is plotted, not a missing run. The default axis is 2.1, the version every model in the study has a run on. The score is a model property: every split of a model shares its x, so a model's rows stack in a column and the column is the price of the topology choice; the FP16-KV and NVFP4 arms inherit their base model's score because the quantisation loss is unmeasured. Only rows that carry your load are drawn — a configuration that cannot has no seat price — and the rest are counted in-chart. The Pareto-efficient set (no other row scores at least as high for no more money) is joined as a staircase: for any capability floor, the cheapest seat within the tolerance. Two bills within 1% of each other are the same money — the power model carries ±20–25%, and without the tolerance three 1-GPU rows differing by a few euros of electricity would all count as efficient — so a row can be dimmed by one that scores higher and bills up to 1% more; rows at the same score are dimmed by any strictly cheaper one. Nothing here measures the score against the study's workload: AA's runs are at the vendor's maximum effort, and a cheaper effort setting scores lower and generates fewer tokens — neither side of that trade is modelled.
The planning stance defines "comfortable capacity" as measured SLO capacity — the largest replayed population meeting explicit p95 TTFT and per-user decode targets — and is explicit that this model cannot produce it. The explorer's "Test these hypotheses" button hands out the on-screen configuration as a workingset.toml, and ws test measures it: closed-loop simulated users sharing one byte-identical prefix (so vLLM prefix caching engages), log-normal contexts, forced-miss injection, a load ladder bracketing the predicted limit, and a predicted-vs-measured verdict table. The predictions travel in no file — ws predict recomputes them from the config, so a stale number cannot be smuggled into a run. One run bounds warm capacity from below unless it reaches eviction, and B* needs --burst — the report prints its own "what this run does not establish" trailer.
The B300 / NVFP4 / Mistral-3.5 / GLM-5.2 constants were researched 2026-07-27 with HuggingFace and NVIDIA domains proxy-blocked — chains run through first-party GitHub repos, three-way config mirrors, and cross-checked snippets, with an assumptions / re-verification ledger in each research note and per-claim confidence tiers in nvfp4.md and gpu_b300.md. Strongest cross-check: the derived GLM-5.2 NVFP4 resident matches the vLLM recipe's ~465 GB within 0.05%. The 2026-08 notes (Qwen3.8-Flash-Next, GLM-5.3-Flash) sit on a stronger tier: HuggingFace was read directly, every FP8 shard header was fetched via HTTP range requests (131 and 62 shards respectively), and the per-module byte sums reproduce each checkpoint's total_size exactly (the vLLM recipe's 172.78 GiB floor is the on-disk file total; net of the 21.08 MB of safetensors headers across the 131 shards it reproduces the same figure to the byte).
research/prefill.md #1), agreeing at ≈40% of the raw advertised peak on both a BF16-Ampere and a Hopper-FP8 deployment — ≈44–49% against the model's own TP-efficiency-adjusted denominator, which is the convention the 45% central lives in (research/prefill.md #1 states both conventions). Still the softest input on the page: it scales every prefill time and every derived ceiling almost proportionally. That is why B* carries a band instead of a single number. It does not affect warm capacity, which is an arithmetic-free byte count.max_num_seqs stays at the ceiling so the batch can absorb bursts. Far below the warm population, because arrivals are open-loop — which is why the per-user speed beside it is far above the all-warm stress figure.Mirrors scripts/scenario_model.py; constants live in the explorer's CONFIG block. Full write-up: docs/writeup.md and docs/scenarios.md in the repository. Research notes: research/model_35ba3b.md, model_mistral_medium35.md, model_glm52.md, model_dsv4flash.md, model_dsv41flash.md, model_qwen38flashnext.md, model_glm53flash.md, gpu_b300.md, nvfp4.md, kv_tp_sharding.md, prefill.md, spike.md.