Studio 4.11: resilience economics made visible

Driven by a direct user question: why do N+1 and N+N+DR double the hardware while capacity, tokens per second and concurrency stay the same?

Because those figures are what you can guarantee even during the failure you chose to survive. Redundant hardware idles (spares, mirrors, DR standby) or serves day-to-day as burst headroom (Active/Active) that you must not plan sustained load on. The tool now shows this instead of implying it:

• Resilience economics strip under the topology: guaranteed at peak, normal-day capacity, idle hardware, and cost versus bare N. For Active/Active it shows the real day-to-day burst (about 2x) next to the guaranteed figure; for half-size DR it notes capacity halves during a site loss.
• Selector grouped by outcome: no redundancy / survives a server failure / survives a site loss / survives both, with plain-language labels.
• Two practical patterns added: N+2 (two idle spares, the usual step up for larger fleets) and half-size DR (1.5N, degraded failover), drawn in the topology and mirrored in the XLS export.

Studio 4.10: explainable auto-sizing and a saner input flow

Usability release, driven by testing with real exported reports.

Auto-size explains itself
The decision now stays on screen under the button: why this TP (with the exact GB math), the trade-off when one copy spans several workers, the precision change that would keep it inside one node, and an honest bottom line: fits and passes, or fits but an SLO fails for reasons hardware cannot fix.

Input flow matches how people decide
SLO targets live in the Workload station where presets set them. Hardware runs GPU, then GPUs per worker, then resilience, then Auto-size; workers and TP sit after it as labeled fine-tune controls. MFU, MBU, interconnect and overhead fold into an Advanced tuning drawer.

Honest P95 verdicts
A new recommendation distinguishes a fixable P95 miss (it names the batch value that would meet the target, or speculative decoding) from a workload whose reasoning + output token count cannot meet the target on any amount of hardware, and says which workload knob to change. The Balanced configuration card and the bottleneck line no longer contradict a failing SLO.

Studio 4.9.1: auto-size solves TP, workers and batch together

Follow-up driven by a real exported report: 4.9.0's auto-sizer kept batch fixed, which ballooned worker counts for latency-tolerant workloads and produced configurations its own recommendations then criticized.

• Auto-size now treats batch as part of the solution. Interactive workloads (any SLO set): fewest workers that admit the peak concurrency at batch 64 or less, grown until the configuration fits. No SLOs: treated as offline, minimal hardware, largest fitting batch, queueing accepted.
• A TTFT target widens TP before sizing, since prefill speed scales with TP.
• Cross-node TP with the penalty already modeled (interconnect 0.75 or less) is reported as an informational note, not a critical finding.
• Queue guidance computes worker needs correctly when TP spans workers and offers the batch value that admits everyone when memory allows.

Verified across seven scenarios from consumer 2x RTX 4090 chat to 2.8T-parameter models on B300 fleets: every auto-sized result fits and passes its SLOs. Example regression: Kimi K3 BF16, document generation, 250 concurrent went from 64 workers with 186 calls queueing to 16 workers with all 250 admitted.

Studio 4.9: auto-size the hardware split

Users should not need to derive tensor parallelism by hand. This release adds it as a one-click suggestion.

Auto-size TP & workers (Hardware station)

• Picks the smallest TP whose slice group fits one full copy of the selected model at the selected precision (keeping ~20% headroom for KV), preferring the NVLink island.
• Then adds workers until the peak concurrent calls (from the use-case preset or the Little's-law estimator) are admitted at the current batch.
• If the suggested TP crosses nodes, interconnect efficiency is set to 0.7 and the toast says so. Everything remains editable afterwards.
• Scripting: window.GPUscale.autoSize().

Clarity

• The hardware card now always states the fleet layout in plain language: how many replicas exist, that each replica is a full copy of the model on TP GPUs, and that raising TP distributes one copy wider while adding workers creates more copies for more users.

Example: Kimi K3 2.8T FP8 on B300, 377 concurrent calls. Manual TP8 gives 8 overflowing copies (127% on every GPU). One click: TP16, 32 replicas, fits at 66% with 22.8 ms TTFT.

Studio 4.8.2: clearer model-distribution guidance

Copy-level release following user feedback: it was not obvious that the Tensor parallel slider is what distributes the model and that workers beyond TP replicate it.

• TP help text now states the rule directly: one copy of the weights spans TP GPUs; GPUs beyond TP form additional replicas that each load the full model.
• The hardware meta card shows an explanatory note whenever replicas > 1.
• The 'one replica cannot hold the model' recommendation explains copies-vs-room and names the exact fixes with numbers, including the TP value that fits one copy and the full-fleet TP that distributes a single copy.

Studio 4.8.1: explain structural misfits

Patch release prompted by a real user report: a 2.8T-parameter model on 8x TP8 workers showed every GPU at 127% with no clear reason and a misleading 'add workers' suggestion.

• When one TP replica cannot hold a single copy of the model, the verdict, the reading panel and a new top-ranked recommendation now explain it directly: each TP group is a full copy of the weights, so adding workers adds demand as fast as capacity. The recommendation names the minimum TP that would fit, the largest weight quant that fits at the current TP, higher-VRAM parts, and notes that pipeline parallelism is not modeled.
• 'Add workers' is suppressed when it cannot help. Queueing guidance and the 'balanced configuration' insight no longer appear on non-fitting configurations.

Studio 4.8: recommendations, Active/Active resilience, split-scroll layout

Feature release.

Recommendations panel
A new panel at the end of the readout names the primary bottleneck of the selected configuration (VRAM capacity, prefill compute, decode bandwidth, admission, or headroom) and lists concrete, numbered fixes ranked by severity: how many workers to add, what a TP change does to TTFT, what halving batch does to per-user speed, when FP8 weights or KV pay off, and when a deployment is over-provisioned.

Resilience

• Two new modes: Active/Active (two live sites behind geo load balancing, 2N) and Active/Active + N+1 per site (2N+2), with full topology diagrams, procurement and power roll-ups, and XLS support.
• Topology frames now draw up to 16 workers per site before truncating.

Layout and clarity

• On desktop the input rail pins to the viewport and scrolls independently of the results canvas; columns are captioned (Inputs / Results) and the five input stations are numbered to make the filling order obvious.
• A header chip and a highlighted footer callout make the privacy model explicit: everything runs in the browser, nothing entered is saved, uploaded or tracked.
• The footer shows the full repository URL: github.com/mahmoudyassine/gpu-scale-tool.

Studio 4.7: correct multi-replica sizing, library v24, publishing polish

Correctness release, verified by a multi-agent adversarial review plus an automated engine harness.

Engine v23

• Multi-replica accounting fixed. Total VRAM now charges weights and activations per data-parallel replica instead of once per fleet. Fit verdicts for multi-worker configurations were previously far too optimistic (4 replicas of Llama 3.1 70B BF16 need 563 GB of weights, not 140). The batch chart's memory limit, admission guidance and topology utilization inherit the correction.
• Capacity counts serving GPUs only (replicas x TP); idle-GPU VRAM is no longer credited.
• New warning when resident sequence plus reasoning exceeds the model's max context; MHA per-token KV insight corrected (was overstated 1000x).
• The Excel export mirrors every change cell-for-cell.

Library v24

• Llama 3.1 405B kvHeads 16 -> 8 · Llama 4 Scout/Maverick headDim 256 -> 128, Maverick hidden 8192 -> 5120 · Qwen3-Next 80B effective KV -> 2x64 · RTX PRO 6000 Blackwell SE dense TFLOPS 500 -> 250 · GGUF Q5_K_S/Q3_K_S sizes · Gemma 3 arch labels.

Robustness

• Topology frames truncate mirror/standby/DR cards correctly (no more "+-1 more").
• Every slider-backed input clamps through its field config: typed out-of-range or cleared values cannot desync the engine from the display or produce NaN.
• Printing from dark mode auto-switches to light for the snapshot and restores after; imported themes lock against OS scheme changes; hardened single-file build.

Design and publishing

• Redesigned header (version chip, grouped toolbar, GitHub link) and a three-column footer.
• Social share cards (dedicated 1200x630 OG image), web manifest, branded 404, robots.txt.
• Rewritten README with live demo, screenshot, worked example and architecture diagram; schemas in docs/DATA.md; Cloudflare DNS import file for gpuscale.net.

Studio 4.6: LLM Capacity & Dimensioning Studio

First public release of GPUscale.net.

Studio 4.6 · Engine v22 · Library v23 (94 models, 38 GPUs)

A self-hosted, dependency-free web studio for sizing LLM deployments: pick a model, precision, workload and hardware; get memory fit, latency, throughput, SLO compliance and a resilient worker topology (N / N+1 / N+N / DR / N+N+DR). Exports JSON configs, a live-formula Excel template, and a printable PDF report.

Highlights

• Fully static, no backend and no build step; open index.html or serve the folder
• 94-model library with effective-KV encodings (MLA, hybrid SSM, sliding-window), including the Arabic/GCC sovereign set
• 38-GPU library from RTX 4060 Ti to Rubin VR200 / MI455X (2026 parts flagged as pre-launch estimates)
• Worker x GPUs-per-worker hardware model with resilience procurement roll-up (workers, GPUs, kW)
• Single portable file: dist/gpuscale_standalone.html