每天30分钟，10周50节课，最后只交一个推理服务

Akshay Pachaar 在 X 上放了一份 LLM 推理路线图。10 周，50 节课，每天 30 分钟，最后只交付一个东西：一个 OpenAI 兼容的推理服务。部署在租来的 GPU 上，接监控，压到 1000 并发以上，做量化、投机解码、KV 缓存淘汰，再在前面挂一个按成本、延迟、质量选后端的 router，最后把 benchmark 公开到能复现。

这个计划值得看的地方在顺序，不在清单长度。第一周先讲 roofline 和 arithmetic intensity，把 decode 为什么受内存带宽限制、prefill 为什么受计算限制说清楚。后面所有优化都落在同一张图上。量化打的是 memory-bound decode，continuous batching 把 arithmetic intensity 往 compute roof 推，投机解码用便宜的 FLOPs 换顺序内存加载，prefill/decode 分离则来自两个阶段抢同一张 GPU。缺了这层模型，剩下就是一堆技巧。

第二周部署 vLLM，然后读 block manager 和 scheduler 的代码。路线图明确说，PagedAttention 和 continuous batching 不要重写，读代码更有用。理由很直接：vLLM 已经把两者实现了，chunked prefill 还是 vLLM 和 SGLang 的默认调度策略。重写一遍，不如读到能解释 KV 内存浪费为什么能压到 4% 以下，以及 GPU 为什么不在请求之间空转。

第三周才上观测。有网友认为 observability 应该排第一，这个分歧本身有意思。路线图把它放在优化之前，第 3 周接 Prometheus 和 Grafana，第 5 周才做 1000 并发压测。没有 TTFT、inter-token latency、吞吐、队列深度的面板，后面的调参无法验证。公开 benchmark 的核心，经常是一套可信的测量工具，模型只是挂在上面。

第 5 周的压测要求很具体：脚本化扫并发，报告 p50、p95、p99，两个独立工具交叉验证。有网友说 p50 p95 p99 应该纹在每个 benchmark 帖子上，均值会藏住那个等很久的用户。另一个容易忽略的点是负载必须固定，否则调的是噪声。

第 4 周用 SGLang 对照 vLLM，讲 RadixAttention 和前缀复用。有网友补了一个实战细节：prefix caching 经常悄悄不生效。prompt 顶部放时间戳、session id 或用户名，每个请求都变成 cache miss，表现是 prefill 时间跟着完整 prompt 长度涨。稳定字节放前面，易变内容放后面。

第 6 到第 8 周是量化、投机解码、KV 淘汰、prefill/decode 分离和 Kubernetes。这里有两个反常识结论值得记住。投机解码在低 QPS 下可能到 2.8 倍，在高 QPS 下会慢 1.4 到 1.8 倍，交叉点比加速比更有用。INT4 更适合当内存压力杠杆，质量代理指标掉超过 1% 到 2% 时，默认还是 FP16 或 FP8。

第 9 周把 unit economics 和 router 放在一起。GPU 小时价除以峰值 token/s、利用率和 3600，再乘 100 万，算出每百万 token 成本。router 按成本、延迟、质量选后端，每请求 token 预算进代码，成本上仪表盘。第 10 周发布 benchmark，固定版本和命令，让别人能复现。路线图还提醒，文中引用的性能数字是来源自己愿意辩护的数字，不是独立复现，GPU 价格和每百万 token 成本变得快，得按自己的硬件重算。

工具链不复杂：vLLM、SGLang、GuideLLM、genai-perf、Prometheus、Grafana、Kubernetes，加上 kind 或托管集群。GPU 成本大概是一张 24GB 卡按半小时租，外加两次 H100 会话。大部分阅读和周 1、周 3 多数时间不需要 GPU。

仓库在 GitHub，CC BY 4.0，欢迎补链接、补新来源、补 benchmark。地址：https://github.com/patchy631/time-to-first-token 。原推：https://x.com/akshay_pachaar/status/2118699262259466406 。

模型发布新闻永远读不完。这个路线图至少把 50 次学习收束到一个能部署、能压测、能公开复现的服务。收藏 17 个互不相连的实验，最后通常只剩环境配置。一个服务持续长大，至少留下仪表盘、压测脚本和一份别人能挑刺的 benchmark。