Where to go next

01 · What you now know

The whole arc, in one paragraph

You started with a paradox — one program, a million workers — and built the mental model: SMs, warps, SIMT, occupancy, latency hiding (days 1–6). You learned the memory system the way a courier learns a city: coalescing, shared memory and its banks, registers and spills, caches, and the roofline that prices every access (days 7–12). You wrote kernels: launches and indexing, grid-stride loops, tiling, reductions, streams, and the profiler loop that turns opinions into numbers (days 13–18). You picked up Triton and let the compiler own the lanes while you owned the data flow — fused softmax, autotuning, fusion arithmetic (days 19–23). Then you read the field's real work — FlashAttention, quantized kernels, KV-cache serving — and finished by writing and profiling one of your own (days 24–29). Thirty days, one grammar.

02 · The open-source road

The next thousand kernels are public

The field you just learned to read is developed in the open, and it absorbs newcomers through exactly the work you've practiced. A pragmatic sequence: reproduce — take day 29's kernel, benchmark it against vLLM's production RMSNorm, and write up where and why yours loses; that one exercise surfaces a dozen production concerns no tutorial mentions. file well-formed performance reports — a reproducible benchmark with a profile attached is rarer and more welcome than you'd think. take small kernel bugs — mask edge cases, dtype handling, missing autotune configs — in vLLM, SGLang, FlashInfer, or Triton itself, whose tutorials/ directory is the project's front porch for exactly this. The maintainers of these repos review performance PRs the way day 18 taught you to: baseline, one change, measurement. You already speak review.

03 · A practice, not a certificate

The constants expire; the method doesn't

Every specific number in this journey — 46 SMs, ~504 GB/s, a ridge point of 58, 100 KB of shared memory per SM — describes one GPU at one moment in history. The next generation moves them: more SMs, wider caches, higher bandwidth, new formats. What doesn't move is the method, because it was never about the 4070: count the bytes, place the kernel on the roofline, profile before and after, change one thing at a time. When new hardware lands, the ritual is to re-run day 11 with the new constants and re-read your favorite kernel — the numbers will have moved, the shape of the argument won't. Kernel engineering is a practice in the same sense music is: the instrument changes under your hands every few years, and you re-tune rather than re-learn.

04 · Part 2, deliberately deferred

What was left out, and why it's next

This journey promised a Part 2, and the fence was deliberate: everything deferred builds on what you now have, rather than being blocked by it. Tensor cores — the matrix-matrix instructions behind every serious GEMM — are warp-level programming with fragments and layouts, which only makes sense once warp-level thinking (day 04) and tiling (day 15) are reflexes. Multi-GPU collectives — NCCL, all-reduce, the communication patterns of distributed training — extend day 17's concurrency story across a PCIe or NVLink fabric. PTX-level tuning — reading the compiler's assembly, scheduling around its blind spots — is day 18's loop carried one level deeper, for the last few percent that only specialists can see. When you pick those up, you'll be doing it with the only prerequisite that matters: you already know what the memory system charges and why.

That's the journey. The next kernel you open — in vLLM, in FlashAttention, in your own project — is the real final exercise, and there's nothing left in these thirty chapters that you need first. Go read it.

The end of the road — for now. The Lab is where new journeys open; the journal's post on VRAM budgeting pairs with days 25–26 if you want the memory-accounting side in more depth. Until Part 2.