Inside vLLM Capstone — Predict the PR, Then Check Yourself Against the Diff
How This Works
What is "Predict the PR"?
"Predict the PR" is this track's capstone: read a real, merged vLLM pull request — its title, its own description, nothing else — and predict every file it touched, using only the map you built across eleven modules. Then reveal, and find out how close you got. All three pull requests in the panel to the right genuinely merged into vllm-project/vllm, and every file they touch exists at the same v0.26.0 ref every other module in this track cites from — all three merged before that tag was cut. Nothing here is invented for teaching purposes; the diffs exist, and you could go check them yourself.
Why prediction, and not one more file to open together
Every module before this one worked the same way: a claim, then a real excerpt sitting right next to it, so you were never more than a paragraph from being told exactly what you were looking at. That's a legitimate way to learn a codebase — arguably the only honest way to start one — and it's also a comfortable one. A real pull request lands with no such paragraph. It has a title, sometimes a few sentences of description, and a diff that assumes you already know your way around. Nobody is going to hand you a footnote linking the change back to the module that taught it.
So this module flips the exercise. Instead of reading code with the answer already lined up beside it, you name the files before you're allowed to look — and the only tool you get is the same eleven-module map everything else in this track built. If that map is real, it should let you point at roughly the right part of a codebase you've never opened a diff for, on a PR you've never seen, using nothing but a title and a paragraph. That's the actual skill this whole track has been building toward, and it's also the skill that matters the day you go read a PR against a codebase this track never taught at all.
How the panel works
The panel holds three PRs, one per tab. For whichever one is active, you get its real title, its real description, and a list of candidate files — the ones the PR actually touched, mixed in with plausible-sounding files from adjacent subsystems that it didn't. Click to build your prediction; click again to change your mind. Nothing is scored until you submit, and once you do, your prediction locks — no editing after you've seen how you did.
Reveal buckets the true files onto the same two lanes the rest of this track has used all along: startup (config-plus-hardware decisions, settled once before the first request) and request (code that runs on some phase of the per-request loop) — plus an honest third outcome for any true file this track's own map never taught at all, filed as "not on the map" rather than forced into a guessed lane. Expect that third bucket to do a lot of the work across this module: this track's own manifest only tracks the files it explicitly cited, so a real PR's touched files routinely land mostly outside it. Noticing which ones do, and why, is as much the point of this exercise as getting a lane right. Source vs. test is called out separately, above the three lanes, because it's a fact about a file's name, not about where it runs. Your hits, misses, and false positives are counted independently, on purpose: a single combined score would let a "select everything" click-through look identical to a real prediction, and those are not the same skill.
The panel doesn't warn you before you submit, and it doesn't let you take a selection back afterward — treat your first submit as the real one. If you're tempted to select every candidate file "to be safe," watch the false-positive count in the reveal: that strategy racks those up fast, and the reveal counts every one of them, right alongside your hits and misses — nothing treats a false positive as free. A prediction that gets three files exactly right beats one that selects everything on offer and hopes.
What's ahead
The next three steps hand you one PR each — the narrowest first, then one that spans two of this track's modules, then one built to make you think hard about where tests actually live. After that, a step on reading a diff you've never seen at all, without this panel's candidate list to lean on. Then, honestly: what this whole track left out, and where to go read it. Read each PR's title and description in full before you touch a single candidate — that's the entire input you're supposed to be working from.
PR #45840 — The Narrow One
PR #45840 — the narrowest of the three
Switch the panel to PR #45840 if it isn't active already, and read its real title and description in full before reading any further here. This is the smallest of the three PRs in this module, and its own title puts you in familiar territory — the word "scheduler" is right there. That makes it the right one to predict first — a subsystem you already know, one PR, and a clean look at how the scoring works before the harder two.
What the brief is actually telling you
The description names a specific field — CachedRequestData.all_token_ids — and tells you exactly where it's read: the model runner, and only under one condition. What it does not tell you directly is where that field is produced, or which side of that relationship the diff actually touches. Those are two different questions, and it's worth pausing on the difference before you start clicking: a field being read in one place doesn't by itself tell you where a PR trimming that field's cost has to make its change. Producer and consumer are not automatically the same file, and a real diff review starts from exactly this kind of gap — closing it is the job, not something the brief does for you.
You've spent prior modules inside this exact territory: the Scheduler module's two halves — schedule() doing admission, update_from_output closing the loop — and enough of the KV Cache Manager and Model Runner modules to know roughly what the model-runner side of "resumed request, output tokens, a gap step" looks like. Nothing here requires new vocabulary. It requires deciding, concretely, which side of that producer/consumer relationship a change this title describes as a scheduler perf fix would actually live on.
Predicting
Build your prediction in the panel, then submit. Resist the urge to hedge by selecting broadly — the reveal counts every false positive right alongside your misses, and this PR is small enough that a careless guess is more likely to cost you than help you.
Before you submit, separate two questions in your head: where does this field get consumed, and where does it get produced or copied? The brief only answers the first one directly. The second is yours to work out from what you already know about where a scheduler's own responsibilities end.
PR #48011 — The Cross-Module PR
PR #48011 — the cross-module PR
Switch the panel to PR #48011 and read its title and description before continuing. Where PR #45840 named one subsystem and stayed inside it, this one sits across two modules of this track: Attention Backends, and Compilation. That's not a hint about file count — it's a hint about shape. A change described as adding "an explicit backend capability" could, in principle, touch exactly one file: the class that owns the new flag. Or it could ripple outward into everything downstream that has to know the flag exists. Deciding which of those this PR actually is — before you click anything — is the whole exercise.
What you already know that bears on this
Two settled facts from earlier modules are directly relevant here, and neither one is a spoiler about files:
Backend selection is a startup-time, config-plus-hardware decision — resolved once, as attention layers are constructed, and fixed for the life of the deployment. Nothing in this track supports a backend switching per request. But that's a fact about when the decision gets made, not about which files a PR touching that decision has to edit. The classes that declare a capability like supports_sliding_window() are the same classes that also build per-request attention metadata on every forward pass — so a file in this PR's diff can carry both a startup-time capability declaration and code that runs on the request path. Don't let "startup-time decision" collapse into "startup-only files."
The Attention Backends module's own registry holds more than thirty concrete backend classes behind one enum, each declaring its own capabilities — sink support, sparsity, MLA, and so on — explicitly, one flag at a time, class by class. A capability that's modeled "explicitly, mirroring the existing checks," as this PR's own description says, is describing a pattern that already has many existing instances. The open question is how many of those existing instances a PR adding one more capability actually has to revisit versus how many it can leave untouched.
Predicting
Hold both of those in mind — the startup-only timing, and the shape of "one flag added to a pattern with many existing members" — and build your prediction. This PR is the broadest of the three in this module; don't let that push you toward selecting everything as a hedge. The false-positive count doesn't care how plausible a guess sounded, only whether it was real.
This track's own map puts this PR across two modules, not just one — the PR's title and description talk entirely in attention-backend vocabulary, so the second module is this track's own classification of where the affected code lives, not something the PR says about itself. Before you submit, decide for yourself whether "spans two modules" means the diff is evenly split between them, lopsided toward one, or something looser than "touches files in both" at all. One more thing worth knowing before you click: "this PR spans two modules" is a claim about which of this track's modules teaches the affected code, not a claim about when in the request lifecycle that code runs — the reveal groups files by the second thing, not the first, so don't expect the two framings to line up file-for-file, and don't let a candidate's name alone stand in for either one.
PR #44165 — Where the Tests Live
PR #44165 — the one about where tests actually live
Switch the panel to PR #44165 and read its title and description before anything else. This one names two classes directly: KVCacheManager and KVCacheCoordinator. You already know that chain — the KV Cache Manager module walked all four layers of it, in order: KVCacheManager calls into KVCacheCoordinator, which delegates to a SingleTypeKVCacheManager per KV-cache group, which ultimately allocates through BlockPool. That's real, settled structure, not a hint specific to this PR — it's the same four-layer chain every prediction in this module can draw on.
What kind of change this is
Read the description closely and one word matters more than the class names: refactor. The scheduler already resolves a scheduling-alignment quantity, scheduler_block_size; a coordinator separately recomputed the same number under a different name. This PR threads the already-resolved value down explicitly instead of recomputing it — and its own description is explicit that no default behavior changes, because the two values were already numerically identical everywhere that reaches the multi-group coordinator.
Sit with that for a second before you predict. A change that provably alters no runtime behavior still has to prove it didn't — and the thing that proves it is the test suite. So this is a genuinely different prediction problem than the first two: you're not just asking "which source files does a change to X touch," you're asking "which tests already pin the exact numeric identity this refactor is relying on, and would need to keep passing unchanged." Don't assume those tests live in a directory that mirrors the source tree one-for-one. Real repositories don't always keep that promise, and this is a good PR to find out on.
Predicting
Build your prediction with both questions in mind — the source-side plumbing through the four-layer chain, and the test-side files that would have to still pass for a behavior-preserving refactor to actually be safe to merge. Submit when you're done; the reveal separates hits, misses, and false positives independently, same as the first two PRs.
This is the PR to read most carefully before submitting. It's tempting to predict test files as if they'd sit in whatever directory mirrors the source file's own — resist that until you've actually reasoned about it, not assumed it.
Reading a Diff You've Never Seen
What do you do with a diff you've never seen?
The panel gave you a curated candidate list for all three PRs — the true files mixed in with plausible distractors, so predicting meant choosing, not searching. A real diff, the day you open one against a codebase you don't have a track for, hands you no such list. You get a title, maybe a description, and a wall of changed files with no hint about which ones matter first. This step is about the order to read that wall in, and it's grounded in the same two pipelines this track has used since Module 1: the ones that run once, and the ones that run per request.
Sort before you read
The single highest-leverage move, before reading a single line of the actual change, is sorting every touched file into one of two buckets:
- The startup pipeline. Code that runs once, before the first request — config validation, backend selection, model loading, graph capture. Ask yourself: would this file's code still execute if the server never received a single request? If yes, it belongs here.
- The request pipeline. Code that runs on some phase of the per-request loop this track opened in its very first module — admission, KV allocation, the forward pass, sampling, output. This is where most bugs that show up "only in production, only under load" tend to live, because it's the code that runs thousands of times a minute instead of once at boot.
This is exactly the sort the reveal panel just performed for you, automatically, on all three PRs in this module — startup lane, request lane, or "not on the map." Doing that sort yourself, by hand, on a file list nobody curated for you, is the actual transferable skill.
An order that works
| # | Step | Why this order |
|---|---|---|
| 1 | Read the title and description for the verb and the noun | The verb (fix, perf, refactor, feature) tells you whether to expect a behavior change at all; the noun tells you which subsystem's vocabulary to listen for |
| 2 | Sort every touched file: startup pipeline or request pipeline | These two buckets behave differently — a startup-pipeline bug typically reproduces on every launch with the same config; a request-pipeline bug usually depends on what's in flight when it fires |
| 3 | Inside the request pipeline, order by phase | Earlier phases produce the state later phases consume — reading phase 7 before phase 5 means reading code that assumes an admission decision you haven't seen yet |
| 4 | Read test files last, as the spec | A test only makes sense once you already know what production code it's pinning down — read it after the source change, not instead of it, and it becomes the clearest single statement of what the author considered worth locking down |
| 5 | Treat an unmapped file as a signal, not a failure | A file that doesn't sort cleanly into anything you've been taught means the diff reaches territory this track — or whatever you've read before — never covered. That's Step 6's territory, and it's also just what reading unfamiliar code always eventually requires |
Why this generalizes
None of this is specific to vLLM. Most real codebases you'll ever read a diff against have some version of "runs once" versus "runs on the hot path," and some files that matter more to read first because they produce the state everything after them consumes — the split won't always be as clean as the startup/request lane this track drew, but the instinct to look for it first still pays off. The two-lane sort just happens to be the exact shape this track built the whole way through — eleven phases across two processes, a startup lane, and a request lane — which is why the panel's reveal draws on it directly rather than on file paths alone.
Try this order on all three PRs from the previous steps, now that you already know their true file sets. Would sorting by pipeline first, then reading tests as the spec, have gotten you to a correct prediction faster than clicking through the candidate list top to bottom? That comparison is the point of this step.
What This Track Left Out
What did this track deliberately leave out?
Eleven modules is already a lot of ground, and the boundary of what to teach was as deliberate as the boundary of what got included — which means an honest capstone owes you an honest account of where that boundary sits, not a vague gesture at "and more." Every subsystem in the table below came up somewhere in this track already, usually as a branch, a config flag, or a value parked on the side of a call this track did trace in full. A mention is not a lesson, the same way glimpsing a file's name in someone else's diff is not the same as having read it — so here's what you actually got, and where to go read the rest.
| Subsystem | What this track showed you | What it didn't teach |
|---|---|---|
| Multimodal inputs | That the model registry keeps a separate per-task table for multimodal models alongside text-generation and embedding models, and that request-path tokenization does "multimodal work" as part of preparing a prompt for the engine | The vision or audio encoder itself, how an image becomes tokens the model consumes, or how the KV cache and prefix cache treat multimodal content differently from text |
| LoRA (Low-Rank Adaptation) | That a request can name an adapter at the API boundary, that adapter slot accounting is one of several things riding on the scheduler's token-budget loop, and — in a bare remove_lora=False argument to a startup warm-up call, shown but never narrated — a hint that warm-up itself has to account for LoRA state somehow | How an adapter's low-rank delta actually merges into a base layer's forward pass, or how multiple adapters share GPU memory in vLLM's own serving pool |
| Speculative decoding internals | Repeated appearances as a qualifier on other claims — an "optimistic" token-count assumption, a deferred correction after a forward-pass launch, disabled logits processors, a metadata field threaded through backend contracts | The draft model, the verify loop itself, or how accept/reject sampling actually decides which drafted tokens survive |
| Pooling and embedding models | Named repeatedly as the reason a forward pass can skip sampling entirely — execute_model returning a value directly, no logits processors built at all | How a pooling model's own forward pass differs from a generative one, or how its output gets aggregated and returned to a client |
| Quantization kernels | That the model loader's own weight-finalization step has a quantization-packing branch, explicitly elided from several excerpts in the Model Registry module | Any specific kernel — AWQ, GPTQ, FP8, INT8 — or how a quantized layer's forward pass differs numerically from a full-precision one |
| TPU and CPU backends | Named together once, as two of several platform subclasses alongside CUDA and ROCm. TPU gets two further, narrower mentions on its own — as one of two exceptions the Distributed Execution module names and then explicitly declines to trace, and again as one of several things that can claim the multiprocessing-executor slot in the Model Runner module. CPU never comes back after that first joint mention | Either backend's platform implementation, kernel set, or executor selection. Unlike ROCm, which the Attention Backends module's own simulation walks as a full worked example — an MI300X machine resolving to RocmAttentionBackend, cited from real source — neither TPU nor CPU ever appears as a worked machine or a cited excerpt anywhere in this track |
Where to actually go
- vLLM — Multimodal Inputs — the deployment-facing guide to what this track only named in passing
- LLM Serving track → Multi-LoRA for the serving concept, then vLLM — LoRA Adapters for vLLM's own mechanism
- LLM Serving track → Speculative Decoding for the draft-verify concept, then vLLM — Speculative Decoding for vLLM's implementation
- vLLM — Pooling Models — no track on this site covers this yet
- LLM Internals track → Quantization for the general concept, then vLLM — Quantization for the specific kernels this track never opened
- vLLM's own
vllm/platforms/tpu.pyandvllm/platforms/cpu.pyat the samev0.26.0ref every other excerpt in this track was pinned to, plus vLLM's CPU installation guide
Nothing in that table is a defect in this track — a curriculum that tried to cover all six of those in the same depth as the eleven modules you just finished would be twice as long and half as deep. The honest version of "what's next" isn't a promise that this site will eventually cover them; it's telling you exactly which door this track opened partway and left for you to finish opening yourself, with a real link on the other side of each one.