04 — Reading Code Daily¶

Fluency in vLLM, SGLang, flash-attn, and llama.cpp IS the job qualification.

The claim¶

Every inference engineer you admire on the vLLM contributor list can, from memory, tell you roughly what _prepare_model_inputs does, where the sampler lives, how the block manager allocates KV cache, and which file to look at when TTFT regresses. This isn’t intelligence — it’s familiarity from repeated exposure. They’ve had these files open, in some form, for hundreds of hours.

You need that familiarity too. And there’s exactly one way to get it: 30 minutes a day, every day, for 13 months.

30 × 396 = 11,880 minutes = 198 hours of code reading. That’s the equivalent of a solid month of full-time work spent inside these codebases. That’s how fluency gets built. Not by cloning them and running them once. By reading them, in small doses, until they stop being scary.

The rotation (put on your calendar as a recurring event)¶

Monday      vLLM             https://github.com/vllm-project/vllm
Tuesday     SGLang           https://github.com/sgl-project/sglang
Wednesday   FlashInfer       https://github.com/flashinfer-ai/flashinfer
Thursday    llama.cpp        https://github.com/ggerganov/llama.cpp
Friday      flash-attention  https://github.com/Dao-AILab/flash-attention
Saturday    (rest)
Sunday      Whatever you're currently stuck on

Why this specific set:

vLLM — the reference Python-first serving engine. If you know one codebase deeply, this is the one.
SGLang — the aggressive-optimization sibling. Reading vLLM + SGLang in parallel teaches you why design choices differ.
FlashInfer — the kernel library both engines increasingly depend on. Reading this teaches you where the actual GPU work happens.
llama.cpp — the C++/GGUF/quant-first world. Different design axis. Keeps you honest about “the Python stack isn’t the whole industry.”
flash-attention — the attention kernel canon. Read Tri Dao’s code until it stops feeling like magic.

You can substitute occasionally (TensorRT-LLM, MLC-LLM, ExecuTorch) but not more than 1 day/week. Rotation depth > breadth.

How to read code (the PR method)¶

Do NOT open a random file and try to “understand it.” That’s tourist mode. You’ll bounce off.

Instead, pick a PR. Every day. One PR from that day’s repo. Here’s the ritual:

Step 1 (5 min): Pick the PR¶

Go to github.com/<repo>/pulls?q=is:pr+is:merged sorted by most recently merged. Pick one that:

Is 20-400 lines of diff (not a 4000-line refactor, not a typo fix)
Has a linked issue or a real description
Touches something you don’t fully understand (the point is to grow)

Step 2 (10 min): Read the linked issue and PR description¶

What problem is this solving?
Whose problem? (User reports? Benchmark regression? New model support?)
What’s the proposed approach in English?

Step 3 (10 min): Read the diff¶

Read the tests first — tests tell you the observable contract
Then the implementation — read every line, don’t skim
When you hit an unknown function, jump to its definition (GitHub’s “go to definition” or your local clone with rg)
Timebox: if after 10 min you’re deep in a rabbit hole, close it. Note the rabbit hole for later.

Step 4 (5 min): The 3-sentence summary¶

Into /lab_notes/reading_log.md:

## 2026-08-10 — vLLM PR #8432 "Add chunked prefill for MQA models"

1. **Problem:** MQA (multi-query attention) models were skipping the chunked-prefill
   optimization because the KV cache layout assumed MHA head grouping.
2. **Approach:** Added a branch in `worker/model_runner.py` that reshapes the KV write
   path when `num_kv_heads == 1`; kernel dispatch in `attention/backends/xformers.py`
   now takes an explicit `kv_heads` arg instead of inferring from Q shape.
3. **What I learned:** vLLM's KV layout is `[num_blocks, block_size, num_kv_heads, head_dim]`
   and the block manager doesn't know about attention head structure — that's pushed
   down to the kernel. That's a cleaner abstraction than I would have picked.

That’s it. Five sentences a day. In 6 months, reading_log.md has 130 PR summaries. That log is a searchable index into your fluency.

The “grep before you ask” rule¶

Before you post any question in a Discord, Slack, or GitHub issue, you must:

rg the repo for the relevant symbol name / error string. Read every hit.
git log --all --oneline -S "<string>" to find when it was introduced. Read that PR.
Search the closed issues on the repo for the same keywords. Read the top 3 threads.

Only if all three fail do you ask. And when you ask, you show what you searched: “I greped for page_size, found it defined in block_manager_v2.py:88, PR #4321 introduced it, but I can’t figure out why the fallback path in _maybe_swap_out was necessary — anyone remember?”

That kind of question gets answered in minutes by senior contributors, because it demonstrates you did the work. “How do I use vLLM?” gets ignored. This rule alone will 10x your signal-to-noise in every community you join.

How to know it’s working¶

By month 3, you should be able to:

Open vLLM to worker/model_runner.py and roughly explain what runs on prefill vs decode
Locate where the sampler lives (model_executor/layers/sampler.py) without searching
Point at where the KV block manager lives (core/block_manager_v*.py) without searching
Read a merged vLLM PR title and predict which files it touched, before opening the diff

By month 6:

You have a running list of “things I’d change / questions I’d ask” — the seed of your first PR
You’ve filed at least one issue with a good repro
You recognize 5-10 handle names in every thread

By month 9:

You’ve submitted your first PR (even a docs fix or small bug counts)
You could give a 15-min talk to a junior engineer on “how vLLM handles a request end-to-end”

If you’re behind these markers, you’re not reading enough. Not “not smart enough” — not reading enough. The fix is mechanical: put it on the calendar. 30 min. Every day. It compounds.

The one honest rule¶

Some days you’ll be too fried to read code. Fine. On those days:

Do 10 minutes instead of 30. Not zero. Ten.
Just read the PR titles and pick which one you’ll actually read tomorrow.
Or read the reading log itself. Re-reading last month’s summaries is legit review.

The streak matters more than the depth on any given day. You break the streak, you break the compounding. Ten minutes on a bad day is worth a hundred zero days.