LLM Systems Engineering Roadmap

当你的"调API侠"之路遇到天花板

如果你已经能在 Python 里写几行代码调通 GPT-4 接口，生成一些看起来还挺像样的回答，恭喜你：你已经站在了 LLM 应用开发的第一层。

但接下来，你开始遇到一些让人头疼的问题：

• RAG 系统的检索结果总是不靠谱，明明文档里有相关内容，为什么检索出来的上下文跟问题驴唇不对马嘴？
• 模型推理延迟高得离谱，32K 长度的文档一喂进去，首 token 延迟直接飙到 20 秒，你开始怀疑是不是自己代码写错了。
• 模型选型时面对 vLLM、SGLang、TensorRT-LLM、llama.cpp 这一串名字两眼一抹黑，不知道该选哪个。
• 幻觉问题严重，模型一本正经地引用了不存在的论文，你需要一套评估体系来量化这件事。
• 终于搭了一套系统上线，老板问"现在模型的准确率是多少"，你发现自己根本答不上来。

这些问题，没有一个是靠"调 API + 写 Prompt"能解决的。它们是系统层面的工程问题——你需要懂模型的内部机制、训练原理、推理系统、检索架构、智能体控制、评估方法，以及生产环境的约束。

h9-tec 的 LLM Systems Engineering Roadmap 正是为这个阶段准备的。

这个项目是什么

这是一个完全用 Markdown 写成的系统化学习路线图，目标是帮助工程师从"会调用 LLM API"提升到"能设计生产级 LLM 系统"。项目作者在 README 中写道：

"It is not a collection of model news. It is not a prompt-engineering cookbook. It is a systems roadmap."

整份路线图覆盖了 12 个核心层级，从 LLM 内部原理一直延伸到生产级架构设计，每个层级都包含了目标说明、核心概念、需要深入理解的内容、实现工件（Artifacts）、工程决策点、失败模式、评估门控，以及推荐学习资源。

目前 GitHub 获得 170 Stars，属于高质量的技术学习资料，尚未有中文版本。

12 层结构：从 Token 生成到生产架构

路线图的核心框架用一句话概括：

LLM competence = 模型内部原理 + 训练逻辑 + 推理系统 + 检索架构 + 智能体控制 + 评估方法 + 生产约束

Layer 1-4：模型内部 → 训练 → 后训练 → 推理模型

前三层帮助你理解 LLM 的底层机制。这里不仅仅是科普"Transformer 是啥"，而是要你真正理解：

Tokenization 的影响有多深。 Tokenizer 把文本转成整数 ID，这个过程直接影响成本、延迟、多语言质量、代码处理能力，甚至阿拉伯语形态学和提示压缩效果。路线图要求你对比不同语言和领域的 Token 效率，记录每个 tokenizer 把"hello"切成几个 token——这一步看似简单，却是很多成本估算错误的根源。

KV Cache 为什么是推理系统的命门。 生成第 N 个 token 时，模型需要重新计算前 N-1 个 token 的 Key/Value 矩阵。KV Cache 把这些已计算过的 K/V 张量存下来，避免重复计算。它的大小由 batch_size × context_length × layers × KV_heads × head_dim × bytes_per_value 决定——这直接决定了你需要多少 GPU 显存。

MQA 和 GQA 是怎么省显存的。 传统 Multi-Head Attention 每个头都有一组独立的 K/V，而 MQA 让所有 Query 头共享一对 K/V，GQA 则是分组共享。KV Cache 小了，推理时的显存压力也就降下来了。Llama 2 之后的很多模型都在用这套机制。

SFT 和 RLHF 各自的局限。 SFT（监督微调）教会模型指令跟随，但容易产生"模仿"而非真正的偏好质量。RLHF 用奖励模型做策略优化，能提升有帮助性，但存在奖励黑客（Reward Hacking）、过度优化、冗长偏见等风险。DPO（Direct Preference Optimization）则绕过了奖励模型训练这一步，直接用偏好对优化模型，简化了流程，但也高度依赖偏好数据的质量。

推理模型（Reasoning Models）的工作原理。 OpenAI o1、DeepSeek-R1 等推理模型在生成最终答案之前，会先生成一系列"思考 token"，将额外计算资源分配给复杂推理任务。这不仅仅是"让模型多想一会儿"，而是改变了 token 生成的动态过程——用户最终只看到答案，但模型内部可能生成了数百个中间推理步骤。

Layer 5-8：推理工程 → 服务引擎 → KV Cache → 量化压缩

这四层是 LLM 系统工程的核心硬骨头。

为什么 LLM 推理是系统工程问题？ 自回归生成（每步只预测一个 token）意味着无法像传统服务那样做批量并行处理。Prefill 阶段（处理输入 Prompt）和 Decode 阶段（逐 token 生成）的计算特征完全不同：Prefill 是计算密集型，Decode 是内存密集型。服务引擎需要在两阶段之间做动态 batching 和调度优化。

vLLM、PagedAttention 与显存管理。 vLLM 通过 PagedAttention 技术把 KV Cache 分成固定大小的"页"来管理，类似操作系统虚拟内存的思路。相比连续存储，PagedAttention 可以把 GPU 显存利用率从 30-40% 提升到 90% 以上，因为不需要为每个请求预分配整块显存。

量化是在精度和成本之间找平衡。 INT8 量化可以在保持模型质量基本不降的前提下，把显存占用减半；INT4 量化可以进一步压缩，但存在"silent quality collapse"（质量静默崩溃）的风险——模型输出看起来正常，但某些边缘case 的准确率悄悄下降了。路线图强调：永远用 evals 来验证量化效果，不要相信理论数值。

Layer 9-12：RAG → 智能体 → 评估 → 生产架构

这三层把 LLM 从"单点工具"变成"生产系统"。

RAG 的失败可能发生在任何一个环节。 路线图列举了 RAG 管道中可能失败的 10 个节点：解析（Parsing）→ 分块（Chunking）→ 嵌入（Embedding）→ 索引（Indexing）→ 检索（Retrieval）→ 重排序（Reranking）→ Prompt 构建 → 生成（Generation）→ 引文验证。其中最容易被忽视的是"解析"——如果 PDF 解析把表格转成了乱码，后面的检索和生成再好也无济于事。

Agent 的边界控制是生死线。 智能体系统的危险在于：自主性越高，失败面越大。路线图提出的核心设计原则是"先做 Workflow，再考虑 Agent"——只有在步骤路径需要动态决策时才引入 Agent。每个 Agent 系统都需要实现：Planner（规划器）、Tool Registry（工具注册）、Executor（执行器）、Verifier（验证器）、Retry Limit（重试限制）、Cost Limit（成本上限），以及最重要的 Human Approval Gate（人工审批门）——在高风险操作执行之前停下来等待人类确认。

评估是一切改进的前提。 路线图的核心哲学是：如果你的知识不能产生可衡量的工件，那你的知识还没有"可操作化"。评估类型覆盖了模型评测、RAG 评测、Agent 评测和生产评测四个层次，每个层次都有具体的指标定义。LLM-as-Judge（用 LLM 做评测裁判）是一个有效但需要严格控制的工具——需要明确的评分标准、成对比较、标定示例、人工审核样本，以及裁判一致性检查。

生产架构需要考虑 12 个维度。 路线图给出的参考架构从客户端一路延伸到监控面板，涵盖：API 网关 → 认证 → 限流 → 请求日志 → Prompt 构建 → 路由 → 检索服务 → 工具服务 → 模型网关 → 服务引擎 → 响应验证 → Trace 存储 → 评估管道 → 监控面板。同时，安全维度必须覆盖：提示词注入、间接提示词注入、工具滥用、数据泄露、PII 泄露、检索投毒、未经授权访问、多租户隔离和审计日志。

能力等级体系：你的位置在哪里

路线图定义了从 Level 0 到 Level 6 的能力等级：

• Level 0 API User：能调用托管 API、调整 Temperature、会写 Prompt，但无法解释和调试 API 层以下的问题。
• Level 1 Prototype Builder：能构建简单 RAG、使用 LangChain/LlamaIndex、连接向量数据库、创建 Chatbot Demo，但缺少评估、可观测性和失败分析能力。
• Level 2 LLM Application Engineer：能设计检索管道、构建结构化 Prompt、管理引文、处理工具调用，但可能不深入理解推理、KV Cache、服务引擎或 GPU 成本。
• Level 3 LLM Systems Engineer：能理解 Prefill/Decode、基准测试推理引擎、选择服务引擎、估算 KV Cache 显存、评估量化效果、构建 RAG 评估。这是最低的专业水平线。
• Level 4 LLM Infrastructure Engineer：能操作 vLLM/SGLang/TensorRT-LLM、处理多 GPU 服务、管理并发、调优批处理、处理前缀缓存、评估量化内核、监控 GPU 利用率。
• Level 5 Research Engineer：能机械地阅读论文、做消融实验、修改后训练配方、测试推理方法、构建自定义评估。
• Level 6 LLM Architect：能定义平台架构、管理模型使用策略、构建评估基础设施、设计多租户系统、处理安全和合规、控制规模化成本。这是目标水平。

Master Artifact Portfolio：15 个必须亲手打造的工件

路线图要求读者在每个层级产出可衡量的工件，而非停留在"懂了"层面。其中最核心的 15 个工件包括：

1. Tiny Transformer（从头实现一个小型 decoder-only 模型）
2. Tokenizer Comparison Notebook（对比多个 tokenizer 在不同语言/领域的效率）
3. Mini Pretraining Pipeline（完整跑一遍从小数据到 base model 的流程）
4. Inference Benchmark Suite（测量 TTFT、TPOT、延迟、吞吐）
5. Serving Engine Matrix（对比 vLLM、SGLang、TensorRT-LLM、llama.cpp）
6. KV Cache Calculator（估算服务显存需求）
7. Quantization Benchmark（量化质量/成本权衡实验）
8. Production RAG System（带引文的 RAG 系统）
9. Agent Workflow（带边界控制的工具调用系统）
10. Eval Dashboard（质量、延迟、成本、安全监控面板）
11. Security Red-Team Suite（提示词注入、工具滥用测试套件）
12. Cost Model（任务级别和平台级别的成本估算模型）

这个项目的局限性

必须指出，这个项目并非完美无缺：

纯 Markdown 格式带来维护挑战。 46K 字的单文件 README 包含了所有内容，虽然有目录结构，但实际操作中 Ctrl+F 是主要导航手段。项目建议的目录结构（roadmap/、artifacts/、templates/、resources/、checklists/ 子目录）在当前仓库中并不存在，实际只有一个巨大的 README.md——这本身就是一个"知行不一"的有趣案例。

缺乏交互性和进度追踪。 没有 Web UI，没有进度看板，没有配套练习的在线评测系统。所有的学习过程需要读者自行设计工具来管理。如果你不自律，这份路线图会变成"收藏等于学会"的又一份心理安慰。

内容深度参差不齐。 Layer 1（LLM Foundations）和 Layer 5-8（推理工程）的技术细节非常扎实，包含具体的公式、实现要点、失败案例。但某些层级（如 Layer 12 生产架构）的建议相对概念化，缺乏具体的架构图或代码示例。

社区活跃度存疑。 项目目前 170 Stars，24 Forks，issues 为 0。没有看到作者更新日志或社区贡献的痕迹。在 LLM 领域三个月就是"上古历史"的节奏下，这份路线图的更新频率需要关注。

行业意义：为什么这份路线图现在出现

2024-2025 年是 LLM 应用开发的分水岭。前两年是"Demo 繁荣期"，无数团队用 LangChain + GPT-4 做出了令人眼前一亮的 Demo。但到了 2025 年，大家开始意识到：Demo 到生产之间隔着一整个工程宇宙。

这份路线图的流行，本质上反映了市场对 LLM Systems Engineer 的强烈需求。根据各公司 JD 统计，能设计 RAG 管道、评估模型质量、理解推理延迟来源、能在 vLLM 和 SGLang 之间做技术选型的工程师，薪资普遍比纯 Prompt Engineer 高 40-60%。这不是一个会调 API 就能胜任的岗位——它需要扎实的系统设计和工程实践能力。

路线图的 12 层结构恰好对应了行业中逐步形成共识的 LLM 系统知识图谱：从模型内部机制到生产架构，每一层都是一个独立的工程领域，都需要专门的学习和实践。

适合谁，不适合谁

适合：

• 已经能写出 LLM 应用 Demo，但遇到性能、成本、质量瓶颈的开发者
• 想从"调 API"升级到"设计 LLM 系统"的 ML/AI 工程师
• 需要系统化学习 LLM 工程知识的架构师和技术负责人
• 想从学术研究走向工业实践的 NLP 研究者

不适合：

• 还没入门 LLM 开发的纯新手（建议先从 FastAPI + LangChain 的基础教程开始）
• 只想找"最新模型排名"的 AI 新闻消费者
• 希望一个周末学完"成为 LLM 专家"的速成派

总结：这是一份诚实的路线图。 作者没有承诺"30 天精通 LLM"，而是把学习目标定在了"能设计生产级 LLM 系统"的 Level 3-4，坦承这需要跨越 12 个层级的系统学习。每一个层级的结尾都有明确的"Evaluation Gate"（评估门控）——你必须能解释指定的技术问题，才算通过该层级。这种设计让学习路径有了可衡量的终点，而非无限延伸的"我再学一会儿"。