LLMOps 系统化学习路线

LLMOps 不是一组互不相干的工具。它讨论的是：怎样让一个模型从实验结果，稳定地变成可评测、可部署、可观测、可迭代的生产服务。

先建立一张全局地图

一条完整链路可以拆成六段：

1. 数据与模型：数据版本、训练配方、模型权重和 tokenizer 必须能对应起来。
2. 评测：离线指标回答“模型能力是否满足要求”，线上指标回答“真实用户是否得到价值”。
3. 制品与发布：权重、镜像、配置和运行环境需要被共同追踪。
4. 推理服务：把模型计算转成有吞吐、时延和可用性约束的在线系统。
5. 可观测与运维：用指标、日志和 Trace 识别退化，完成定位、止损和恢复。
6. 反馈闭环：把线上问题重新送回数据、评测和工程改进。

这六段不是线性流水线。一次推理服务的超时，可能最终暴露的是模型输入分布变化、网关路由错误或发布配置漂移。

推荐学习顺序

第一阶段：理解边界

• 分清训练、微调、评测、推理与运维各自解决的问题。
• 理解模型权重、tokenizer、推理引擎和服务框架之间的关系。
• 能画出一次请求从网关到模型输出的完整路径。

第二阶段：补齐系统基础

• GPU 内存与算力的基本约束。
• 张量并行、流水线并行、数据并行的通信方式。
• 容器、调度、服务发现、负载均衡和故障恢复。

第三阶段：深入推理引擎

• Prefill 与 Decode 为什么具有不同的计算特征。
• Continuous Batching、Paged KV Cache 和调度策略怎样影响吞吐与时延。
• TP、DP、EP 以及 PD 分离分别改变了什么。

第四阶段：建立可观测与排障方法

• 指标用来发现异常，日志用来还原事件，Trace 用来连接跨组件因果。
• 现场采样要同时覆盖进程、线程、GPU、网络与运行时栈。
• 每个根因结论都应该说明证据、反证和仍待确认的边界。

怎样判断自己真正掌握了

不要只问“这个概念能否复述”。可以用三类任务检验：

层级	检验任务	产出
理解	解释一个机制为什么存在	一页原理笔记
应用	在真实配置中找到它	配置与指标对照
诊断	用证据排除两个错误假设	一份故障复盘

后续内容会沿着这条路线展开，并尽量把原理笔记和真实现场放在一起。