01 — The Industry Moves Faster Than the Plan¶

Failure class: Technology risk. Modal timing: Months 4–10, when the specific tools you invested in start to shift under you. Aggregate probability that at least one of the scenarios below materially reshapes the plan: ~85%. Probability this alone kills the plan: ~10% — low, if you built the right invariants.

The Scenario¶

It is Aug 5, 2027. You look back at the roadmap and half of the specific tool names in it are quaint. FlashAttention-2 in Triton was your Phase 3 exit criterion; the actual production kernels moved to something else. Marlin was the W4A16 hero; a Blackwell-native FP4 path made it obsolete. You spent six weeks getting fluent in Triton just as CuTe-DSL matured into the recommended path for anything perf-critical. The bake-off (GPTQ vs AWQ vs FP8 vs GGUF Q4_K_M) that was going to be your definitive quantization post became a historical curiosity.

Meanwhile, one of the two engines you invested in — SGLang — either merged with vLLM, forked into three warring successors, or slowly lost maintainers to a new project. And on the demand side, frontier models got so good, so cheap, and so multimodal that the “on-prem LLM” market that was supposed to be your commercial moat receded into a small band of regulated verticals.

None of these are hypothetical. Every one of them has a >20% probability. This is what an 18-month plan in a field moving on 3-month cycles looks like from the other end.

The Specific Failure Scenarios¶

1.1 FlashAttention-5 lands, and it’s not written in Triton (probability ~35%)¶

By Q2 2027 there is a new attention kernel that (a) integrates Blackwell tcgen05 / distributed shared memory idioms that Triton doesn’t yet expose cleanly, and (b) is the reference implementation everyone benchmarks against. Your Triton FA2 is a Phase 3 checkpoint but not the frontier. If you only know Triton, you cannot read or contribute to the new hotness.

Parry: Phase 3 studies the FA lineage, not just FA2. When you write your FA2 in Triton, immediately after, spend one sprint reading the FA3 code (CUTLASS/CuTe) even if you don’t reimplement it. Learn the idea of warp specialization and TMA before Triton or CuTe changes underneath you. The idea outlasts the DSL.

1.2 CuTe-DSL / Mojo / a new tile DSL replaces Triton in prod (probability ~30% for partial replacement, ~10% for full)¶

Modular’s Mojo, NVIDIA’s CuTe-DSL (the Python front-end to CuTe), and possibly TileLang or something not-yet-named eat Triton’s share for the perf-critical 10% of kernels. Your Phase 2 Triton fluency becomes a transferable skill but not the current one.

Parry: Triton is not the destination; tile-level parallel-programming thinking is. Once you can write a fused softmax in Triton from memory, you can port it to any tile DSL in a week. Budget one sprint in Phase 4 or 5 to write the same kernel (fused softmax or RMSNorm) in a second DSL (CuTe-DSL, Mojo, or whatever is ascendant when you get there). That comparison post is portfolio gold and future-proofs you.

1.3 Quantization converges on one format on Blackwell (probability ~40%)¶

NVFP4 with the MX-scaling scheme wins. FP8 remains for training/prefill; NVFP4 dominates decode weights. GPTQ and AWQ become historical. The whole bake-off you were going to run becomes moot at the frontier (still relevant for consumer GPUs, but that’s a smaller audience).

Parry: The bake-off has value as a rehearsal even if the winning format changes. What matters is that you can reason about outliers, block granularity, and the roofline of weight-only vs activation quant. Rerun the bake-off with whatever formats are current when you get to Phase 5 — the method is the deliverable, not the specific formats. Also: still do a GGUF k-quant deep-dive; the r/LocalLLaMA world will keep k-quants alive on consumer hardware for years regardless of what happens at datacenter scale.

1.4 vLLM and SGLang converge, or one dies (probability ~35%)¶

Either: (a) vLLM absorbs SGLang’s best ideas (RadixAttention, structured decoding) and SGLang stops being a distinct choice; (b) they merge governance; (c) SGLang keeps sprinting and vLLM slows; (d) a third contender (a Dynamo-native engine, a Modular engine, a Deepseek-published engine) eats both.

Parry: Don’t monoculture. Phase 4 explicitly says read both codebases. Keep it that way. Also read FlashInfer and llama.cpp regularly — those are the two most likely to outlive any specific serving engine because they are more foundational (kernel library and consumer runtime, respectively). Your credential is not “I know vLLM”; it is “I can read any inference engine source in a week.”

1.5 Frontier APIs crush the on-prem market (probability ~25%)¶

GPT-5.5 / Claude-5 / Gemini-3 hit a price point and a latency point that make on-prem 70B look silly for 80% of enterprise use cases. The on-prem moat that made your Zoho position a strategic advantage narrows to regulated verticals (banking, healthcare, government, defense) and the sovereignty-driven subset of Europe/India.

Parry: The remaining 20% is still a huge market, and inference engineering as a skill is not equivalent to “on-prem”. Hyperscalers running frontier models need inference engineers too — the memory-bandwidth math doesn’t care whose datacenter it lives in. Also: the regulated-vertical market has higher margins and slower obsolescence, which is actually a good place to be. Don’t hitch your career purely to “on-prem is winning”; hitch it to “inference is scarce” — that’s the durable claim.

1.6 The next big architectural shift makes your transformer knowledge partial (probability ~20% by Aug 2027, ~50% by 2029)¶

Mamba/SSM hybrids, diffusion LLMs, or something else eats a meaningful slice of the deployed base. Attention is no longer the kernel; it’s a kernel. Your FlashAttention obsession is worth less proportionally.

Parry: Read the SSM literature at awareness level (Mamba-2, hybrid Jamba/Zamba) once you finish Phase 4. You do not need to become an SSM expert. You need to know why the memory-bandwidth argument for SSMs is compelling and where their kernels live. The substrate skill — GPU arithmetic, memory hierarchies, fused kernels — transfers 1:1 to any post-transformer architecture. Attention is a use case of the skill, not the skill.

1.7 Compilers (MLIR, torch.compile evolutions, TensorRT-LLM builder) eat hand-written kernel work (probability ~30%)¶

By 2027, more kernels are auto-generated than hand-written. The peak numbers still come from experts (Tri Dao, the Marlin authors, the ThunderKittens crew), but the middle 60% of work moves into compiler flags and graph annotations. “Kernel engineer” narrows to a smaller elite.

Parry: This is arguably good news — it means the people who can hand-write kernels command more scarcity premium. But hedge by learning torch.compile and TensorRT-LLM’s builder flow well enough to know what the compiler already fuses for free. Also: kernel work is not the only path into inference engineering. Scheduling, KV routing, disaggregated serving, quantization method design, and evaluation infra all remain human-hard problems for a long time. Phase 4 and Phase 7 skills are more compiler-proof than Phase 2–3 skills.

Early Warning Signals¶

You will know one of the above is happening when:

A blog post or paper you’re reading feels like it’s using a vocabulary you don’t have (new DSL name, new format acronym, new engine name mentioned casually).
A GPU MODE lecture uses a tool you’ve never heard of and treats it as assumed knowledge.
A vLLM/SGLang PR you’re reading references a kernel library or scheduling paradigm not in your notes.
Two months pass without you seeing the specific tool you invested in mentioned in any new PR or benchmark post.
r/LocalLLaMA’s hot topic drifts entirely off the terminology you were fluent in six months ago.

Run a quarterly tool-audit ritual: at the end of each phase (or every 90 days, whichever comes first), spend one evening scanning MLSys accepted-papers list, GPU MODE recent lectures, vLLM/SGLang release notes, and one r/LocalLLaMA “state of” thread. Note what changed. Update the plan.

The Real Parry: Commit to Invariants, Not Tools¶

Here is the whole doctrine of this file in one paragraph. The specific tools in the roadmap are decorations on top of a small set of invariants. Commit to the invariants, treat the tools as fungible.

The invariants are:

Roofline reasoning — arithmetic intensity, ridge point, memory-bound vs compute-bound. This does not change when the hardware or format changes.
The three numbers — FLOPs, bytes, bandwidth. These outlast any tool.
Fused-op / HBM-round-trip thinking — the reason to fuse doesn’t care which DSL you fuse in.
KV-cache arithmetic — the math (2 × layers × kv_heads × head_dim × bytes × seq × batch) does not depend on which engine paginates the cache.
Continuous batching + paged KV as scheduling primitives — the ideas will still be running in whatever engine wins in 2028.
Speculative decoding economics — acceptance rate vs draft cost is a permanent framework, EAGLE will be replaced but the framework won’t.
The latency-throughput frontier — goodput vs throughput vs p99 ITL is the language of the discipline, not of any specific paper.
The stack itself — API → orchestration → engine → model → kernel → hardware → fabric. The layers will still be there, even if their contents change.

If, in Aug 2027, you have deeply internalized all eight of these, you have won — regardless of which specific FA revision or engine or DSL is on top. A candidate who arrives at an inference-team study and can derive the tradeoff their newest paper solves, from first principles, is worth more than one who has memorized last year’s paper list.

Failure Tree¶

Escalation Trigger¶

If, during any quarterly tool-audit, you find that three or more of the specific tools in the roadmap have been supplanted, do this:

Don’t panic-pivot mid-phase. Finish the current sprint.
Take one focused week (evening + weekend, not a full pause) to write a rewrite of the next phase in current-2027 vocabulary.
Confirm the invariants are unchanged — they will be.
Re-plan the specific deliverables around the current tools. Do not rewrite Phases 0–2 (those are foundational and stable); do rewrite Phases 3–7 as needed.
Publish the rewrite as a blog post: “How the inference-engineering landscape shifted in the last 6 months, and what I changed in my learning plan.” Post-mortems of your own plan-updates are extraordinary portfolio signal — they show a mind that can adapt, which is the actual scarce skill.

The Bottom Line¶

The industry will move faster than the plan. That is not a bug in the plan; it is a feature of the industry. The plan is not a map, it is a compass. The compass points at the invariants. If you keep walking toward them, the specific ground under your feet will change — but you will still be walking in the right direction.

And honestly? A person who has ridden through a tooling shift and shipped adaptations is more valuable in Aug 2027 than a person who stayed on rails that never bent. This vector, handled well, is not a failure at all — it is the credential.