Checkpoints and datasets both live on storage. Why does one system sized for both usually serve neither well?

One is a write burst of terabytes in a minute followed by half an hour of silence; the other is a steady read that never stops and never spikes. Provisioning for the peak of the first wastes most of its capacity, and provisioning for the average of the second fails the moment a checkpoint lands.

Updated Sep 2026 · Grounded in real AI infrastructure interview loops and written to a senior-engineer editorial bar, with every number worked and every diagram hand-built.

20 answers per topic instead of 10, plus saved progress and bookmarks · no cardor unlock all 283 remaining answers · ₹2,000 / $25

The concepts behind this question

Ranked by how closely each one overlaps this question's topic, so the first card is the thing to read if the answer above moved too fast.

Foundational

🖧 Hardware & Cluster Build-Out

Cluster Bring-Up: Firmware, Drivers and the StackBring-up is an ordered dependency chain and skipping a step produces a symptom that points somewhere else. Firmware first, then the operating system and kernel, then the GPU driver, then the fabric manager, then the network stack, then GPUDirect, then CUDA and NCCL, then the container and scheduling layer. On Blackwell HGX systems the fabric manager reaches the NVSwitches through a bridge device and therefore depends on the InfiniBand stack being present, which is a dependency that surprises almost everyone the first time.

Foundational

🧮 Napkin Math & Capacity

KV Cache SizingThe KV cache is the memory that decides how many users a serving replica can hold and how long their context can be. Its size per token comes from four numbers in the model's config file (layers, KV heads, head dimension, bytes per element) and one formula; multiplied by context and concurrency it is the number every capacity plan is built on. This page derives it, works it for four models including an MLA one, and shows the two places candidates get it wrong by a factor of eight.

Foundational

🧮 Open Weights & Serving Engines

Capacity Planning for Open-Weights FleetsPlanning a fleet for a sparse open-weights model works differently from planning one for a dense model, because memory follows total parameters and throughput follows active parameters, and those now differ by more than twenty times. The sizing goes in one direction only: from a traffic forecast to tokens per second, to replicas at a measured operating point, to GPUs, to racks and kilowatts. Doing it in the other direction, from an available GPU count, produces a fleet that fits the hardware rather than the demand.

Foundational

📐 AI Systems Design

Multi-Region Serving and FailoverRunning inference in more than one region buys latency for distant users and survival when a region fails, and it costs a second fleet that must be capable of absorbing the first one's traffic. The design turns on three decisions: whether regions are active-active or active-passive, what state has to cross regions and what deliberately does not, and how much headroom each region carries so a failover does not simply move the outage.

Explore the full curriculum →

UP NEXT ON YOUR JOURNEY

Next in this trackSeveral unrelated jobs slow down at once and nothing is dropping packets. How do you confirm a pause cascade and find where it started?Next in this track8,192 GPUs exceeds what a two-tier Clos of 64-port switches supports. Compare adding a tier against using higher-radix switches.Next in this trackHow would you know GPUDirect RDMA is not being used, given that nothing reports an error when it is disabled?

FEDITOR'S NOTE

Scored on characterizing the two access patterns by burstiness rather than volume, on the provisioning arithmetic that shows why one system serves neither, and on the tier assignment that follows.

DISCUSSION · 0

No comments yet — be the first to share your approach.