DevOps -> AI Infra 工程师的学习 Roadmap（2026）

本文最后更新于 2026年9月29日 凌晨

过去我的工程背景主要集中在 Mobile / SDK 的 CI/CD、Build & Release。
维护构建环境、流水线；管理制品、版本发布，稳定交付。
进入 AI Native 时代后，再只搞这些业务就要被斩杀了。
现准备把这些经验迁移到 AI Platform 方向，特此维护本文进行指路。
路线参考：roadmap.sh/ai-engineer、roadmap.sh/ai-agents。

当前学习进度

在 AI大人 的帮助下，初步实现了记录学习打卡、能力证据与规划建议的 Skill Compass。导出功能尚未完成，动态进度先以该项目为准。

本文记录能力路线；具体任务、实验记录和完成证据放在进度系统中维护。

职业定位修正

已有的 Build & Release / DevOps 能力能迁移到哪里？

怎样用实际成果证明自己能为团队提供 AI 能力？

方向 主要对象 核心工作 与我的关系
Build & Release / DevOps App / SDK、环境、流水线、制品 可重复构建、测试、发布、回滚、交付自动化 已有经验，是迁移起点
AIOps 告警、日志、事故和运维流程 用 AI 辅助检测、诊断与处置，即 AI for Operations 可以作为业务用例，不等于建设 AI 基础设施
LLMOps / AI Platform 模型端点、内部调用方、数据与治理链路 统一接入、模型交付、权限配额、观测评测、自助服务 近期重点，先形成团队可用的能力
AI Infra GPU、集群、网络、存储与运行时 为 AI 负载提供算力、调度、可靠性与资源治理 长期深入基础设施的方向
Inference / AI Performance 推理运行时、计算、显存和通信瓶颈 优化质量约束下的延迟、吞吐与成本 长期深入推理与性能的方向

LLMOps 更侧重 LLM 生命周期与生产运行实践，AI Platform 更侧重把这些能力产品化后提供给团队。

岗位名称会因公司而异，应以负责的系统和交付物为准。

原有经验的迁移关系如下，表更多用于定位能力。

原有经验 在 AI Platform 中的对应问题 需要新增的知识
App / SDK 构建 模型镜像、推理 Runtime、依赖和可重复环境 CUDA、模型格式、GPU 容器运行时
制品管理 Base Model、Adapter、Tokenizer、数据集、Prompt 和镜像版本 Model Registry、数据血缘、模型许可证
CI/CD 模型服务、Prompt、RAG Pipeline 和 Agent Harness 的测试发布 Eval Gate、质量回归、影子流量
多环境发布 Dev/Staging/Prod 的模型端点、配额和数据隔离 多租户、模型路由、数据治理
灰度与回滚 模型版本、Prompt、Adapter、路由策略的灰度与回滚 质量指标、A/B、Canary Eval
SDK 设计 统一 LLM API、内部 SDK、错误模型和兼容层 Streaming、Tool Calling、Token/Context 语义
可观测性 LLM Trace、Generation、Tool Span、GPU 与队列指标 GenAI 语义、TTFT、TPOT、Token 成本
容量规划 GPU 容量、KV Cache、并发、吞吐和队列 显存估算、Batching、并行策略
运维与排障 模型下载、加载、OOM、驱动、网络和尾延迟 vLLM/SGLang、NCCL、GPU Profiling
平台化 自助申请、统一入口、模板、策略和治理 AI Gateway、模型目录、Eval as a Service

0. 总览路线图

在 Cloud Native 方兴未艾时进行过一次痛苦的转型，现在装备了 AI大人 辅助（就是有点卡经济），准备沿着已有交付经验继续向前：

会调用模型 → 会部署模型 → 能提供团队服务 → 能接入业务知识 → 能持续评估和运营。

如何阅读导图

  • 蓝色 Stage 1–5：推荐的主线阅读顺序；每章交付一个可验证的增量成果。
  • 黄色 Stage 6–7：任务执行方向的选修，先理解 Workflow / Agent，再扩展 Harness。
  • 黄色 Stage 8：微调独立分支，具备 Stage 2 的部署能力与 Stage 5 的评测基础后按需进入，不依赖 Stage 6–7。
  • 紫色提示：评测、观测、安全与成本从第一阶段就开始加入，Stage 5 集中深化。
  • 图中的编号表示学习组织方式，不是必须全部通过的岗位资格清单。托管 API 也能支撑平台练习；自部署实验可按硬件条件选小模型或短时租用 GPU。
flowchart TD
    Start(["已有经验：CI/CD / Build & Release"]) --> S1["Stage 1 · LLM 基础与服务<br/>成果：可靠调用工具"]
    S1 --> S2["Stage 2 · Serving / Quantization / Inference<br/>成果：推理端点与容量实验"]
    S2 --> S3["Stage 3 · LLMOps / AI Platform<br/>成果：团队统一入口"]
    S3 --> S4["Stage 4 · RAG / Context / Internal Use Cases<br/>成果：可引用、可更新的知识问答"]
    S4 --> S5["Stage 5 · Eval / Observability / Safety / Cost<br/>成果：回归评测与运营闭环"]
    S5 --> Main(["主线成果：可交付、可评估的内部 AI 服务"])

    Main -.-> S6["Stage 6 · Workflow / Agent（选修）<br/>成果：可控的任务执行"]
    S6 -.-> S7["Stage 7 · Agent Harness / MCP（选修）<br/>成果：接入平台的执行环境"]
    S5 -.-> S8["Stage 8 · LoRA / QLoRA（独立选修）<br/>前置：Stage 2 + Stage 5<br/>成果：经过评测的模型与 Adapter 交付"]

    Quality["全程加入：评测 / 观测 / 安全 / 成本<br/>Stage 5 集中深化"] -.-> S1
    Quality -.-> S3
    Quality -.-> S5
    Main --> Next["后续方向<br/>AI Infra / AI Performance / AI Platform 深化"]

    classDef main fill:#e7f0ff,stroke:#4b6f9c,color:#172b4d
    classDef optional fill:#fff4d6,stroke:#aa7a2a,stroke-dasharray:5 5,color:#47351d
    classDef cross fill:#f0eaff,stroke:#8362a8,color:#35254c
    class Start,S1,S2,S3,S4,S5,Main,Next main
    class S6,S7,S8 optional
    class Quality cross

阶段之间怎样分工

  • Stage 1 / Stage 3：前者统一客户端调用与错误处理；后者提供多用户共享的网关、权限、配额和交付流程。
  • Stage 2 / Stage 3：前者理解推理运行时与容量；后者把模型端点变成团队服务，引用前面的实验结论。
  • Stage 3 / Stage 5：前者接入基础控制和指标；后者建立质量判断、变更验证和持续改进的方法。
  • Stage 4 / Stage 7：前者为一次回答准备业务信息；后者管理多步骤任务中的上下文、会话和恢复。

各章保持“目标—关键概念清单—资源—实战项目”的结构，实战末尾说明完成标准。资源按需选读，进阶材料不作为进入下一阶段的门槛。

Stage 1 · LLM 基础与服务

这一阶段解决：一次 LLM 调用怎样可靠完成？

目标

  • 理解 LLM API 的输入、输出与限制，知道上下文、采样、结构化输出和工具调用分别解决什么问题。
  • 能使用一个原生 SDK 做出小工具，并处理流式输出、错误、超时和用量记录。
  • 建立质量、可用性、延迟和成本的基本直觉。

关键概念清单

  • 输入与预算：Tokenization、消息角色、上下文窗口、输入与输出 Token；KV Cache 先理解用途，机制留到 Stage 2。
  • 输出控制：temperature、top-p 等采样参数，JSON Schema、Structured Output 和输出校验；参数支持情况以所选模型为准。
  • 工具调用：模型提出工具名和参数，由程序校验并执行；此处先理解一次交互，循环决策留到 Stage 6。
  • 调用可靠性：Streaming、SSE、Async I/O、超时、取消、限流、有限次数重试与退避；失败重试可能增加费用，需记录请求状态。
  • 成本与延迟：Token 用量、首段输出等待、总耗时、缓存命中与质量取舍。API Prompt Caching 的行为由服务提供方决定。
  • 模型选择：在同一组任务上比较质量、速度和费用，再决定是否使用推理模型或更大的模型。

资源

实战项目

  1. 发布文档总结器：用原生 SDK 总结一份发布说明，支持 Streaming、超时、取消和用量记录。也可用 CLI 翻译器代替这一练习。
  2. Structured Extractor：从发布说明中抽取版本、变更项和风险字段；比较直接结构化输出与工具调用方式，记录 Schema 校验失败。
  3. 客户端多模型适配器：统一两个模型服务的输入、输出和错误类型，在固定样本上比较延迟、成本与质量。这里不建设团队网关。

完成标准：交付一个可靠调用工具；能够复现限流、输出格式错误和流式中断，并说明哪些错误会重试、如何记录费用。无需读完所有论文或熟悉所有供应商。

Stage 2 · LLM Serving / Quantization / Inference

这一阶段解决：一个模型服务怎样跑稳、跑得合适？

目标

  • 能解释模型原生上下文、服务端实际配置和单次请求实际占用之间的关系。
  • 能部署、验证并排障一个推理服务，理解权重、显存、KV Cache 和量化的取舍。
  • 能用可复现的实验说明延迟、吞吐、质量与资源消耗的变化。

关键概念清单

  • 服务启动：模型权重、Tokenizer、Config、Chat Template、模型版本和许可证；健康检查、模型名称与 API 兼容范围。
  • 上下文与显存：权重占用、KV Cache、激活与运行时开销；服务端 max-model-len 与请求输入、输出长度。
  • 推理机制：Prefill / Decode、PagedAttention、Continuous Batching、Prefix Caching、Chunked Prefill。
  • 量化与格式：BF16/FP16、INT8/INT4 是数值表示；AWQ/GPTQ 是量化方法；GGUF 是可容纳不同量化类型的模型文件格式。实际支持取决于模型与运行时。
  • 测量方法：TTFT（首 Token 延迟）、TPOT（平均每输出 Token 耗时）、端到端延迟、P95/P99、并发、请求吞吐和 Token 吞吐。
  • 常见故障：下载或 DNS 失败、文件不完整、驱动与 CUDA 不匹配、OOM、KV Cache 不足、模型名称错误。

先选择 vLLM 或 SGLang 中的一个跑通，再用第二个引擎做对照。Tensor Parallel、多机并行、PD 分离与 Speculative Decoding 作为进阶方向，在基本容量实验完成后按需学习。

资源

实战项目

  1. 单机服务化：按硬件条件选择小模型，将 Stage 1 总结器的调用切到自己的模型端点。记录下载、启动、健康检查与重启步骤。
  2. 量化与容量实验：在同一组样本上比较原始精度与量化版本的回答质量、显存、TTFT、TPOT 和吞吐，再改变上下文与并发寻找容量边界。
  3. 引擎对照（选做）：同一模型、同一机器和同一负载下比较 vLLM 与 SGLang，记录差异和适用条件。

完成标准：交付推理端点、容量报告与故障手册。报告必须记载硬件、模型版本、量化配置、输入/输出长度分布、并发、预热和统计口径；改变一个变量后能解释结果，不只展示成功截图。

Stage 3 · LLMOps / AI Platform

这一阶段解决：怎样让其他人可靠地使用已经跑通的模型能力？

目标

  • 将托管 API 和自部署模型组织为统一接入服务。
  • 让团队能够申请、调用、发布和排查模型服务，并建立基本权限、配额和反馈渠道。
  • 复用 Build & Release 经验，为模型端点和配置建立可重复的交付过程。

关键概念清单

  • 统一接入：Gateway、模型目录、能力与限制说明、内部 SDK、路由与 Fallback；兼容接口不等于所有功能语义完全相同。
  • 服务交付：模型、镜像与配置版本；Dev/Staging/Prod；灰度、回滚、变更记录与可重复部署。
  • 团队使用：身份认证、租户与项目、凭据管理、授权、配额、预算和自助申请。
  • 基础运营：健康检查、请求成功率、延迟、Token 与队列指标；超时、限流、容量、降级和故障手册。
  • 平台边界：控制面负责目录、策略与配置，数据面处理调用和推理。API 接入层、GPU 推理运行时与 Agent 会话承担不同职责。
  • 反馈入口：记录模型与 Prompt 版本、收集失败样本。此处建立基础能力，质量回归和改进闭环在 Stage 5 展开。

推理引擎内部机制引用 Stage 2 的结论。多机并行、复杂 GPU 调度与 PD 分离留到“后续方向”，不用在搭建第一个团队入口时全部实现。

资源

实战项目

  1. 团队统一入口：给 Stage 1 的客户端提供一个稳定入口，背后接托管 API 和 Stage 2 的模型端点；加入身份、模型选择、配额、基础日志和 Fallback。
  2. 发布与回滚：把部署、配置和模型版本写成可重复流程；先在测试环境升级，再演练失败回滚。已有 K8s 可使用 Helm，单机练习也可先用容器完成。
  3. 用户接入手册：让另一个人按文档完成申请、调用和错误排查，收集接入阻碍。故障演练至少覆盖端点不可用、配额耗尽和高并发。

完成标准：交付最小内部 LLM 平台，使用者无需手工操作你的 GPU 节点即可调用模型；可以找到请求对应的模型与配置版本，说明权限、配额、降级和回滚如何生效。

Stage 4 · RAG / Context Engineering / Internal Use Cases

这一阶段解决：怎样把业务信息正确、及时、按权限地送进一次回答？

目标

  • 理解从文档接入到引用回答的完整链路，并能分辨解析、检索、排序与生成问题。
  • 让研发知识库支持更新、删除、来源追踪和访问控制。
  • 建立小型检索与回答评测集，为 Stage 5 的回归打基础。

关键概念清单

  • 数据接入：文档解析、清洗、来源 ID、版本、增量更新、删除与权限元数据。
  • 基础检索：Chunking、Embedding、向量索引、BM25、Hybrid Search、Metadata Filter 与 Reranker；先建立基线再比较策略。
  • 上下文组装：相关性、去重、Token 预算、片段顺序、引用、无依据时拒答或提示不确定。
  • 可追溯性：保存回答实际使用的文档和版本；权限过滤须覆盖检索、缓存和最终引用。
  • 评测分层：召回是否找到正确资料、排序是否把资料放在前面、答案是否有依据；具体方法在 Stage 5 统一。
  • 方案取舍：长上下文、缓存与 RAG 各有成本、更新和权限边界，用自己的问题集比较。

这里聚焦一次回答的信息供给。多轮任务状态、Compaction 与长期 Memory 留到 Stage 7；GraphRAG、多模态检索和 Agentic RAG 均为进阶选学。

资源

实战项目

  1. 研发知识问答：导入发布文档、故障复盘或个人博客，生成带原文引用的回答。用公开样本搭基线，再加入模拟权限。
  2. 更新与权限实验：修改、删除一份文档，验证索引、缓存和回答；用两个不同权限的账号检查能看到哪些资料。
  3. RAG 评测台：准备一组带参考资料的问题，分别改变 Chunk、Embedding 或 Reranker，记录错误属于召回、排序还是生成。

完成标准：交付可引用、可更新且遵守访问权限的知识问答服务。能追溯一次回答的来源版本，能复现失败样本，并说明下一步应改哪一个环节。

Stage 5 · Eval / Observability / Safety / Cost Governance

这一阶段解决：怎样证明服务可靠，判断变更是否值得上线，并持续改进？

目标

  • 为 Stage 3 的模型服务与 Stage 4 的 RAG 建立可重复的质量、性能和成本评测。
  • 用 Trace 追踪用户问题，并把失败样本转回回归测试。
  • 建立风险分级、发布门禁、线上反馈和回滚流程。

关键概念清单

  • 质量评测：有版本的 Golden Dataset、独立测试集、Offline / Online Eval、人工标注、评分规则与 LLM-as-Judge 校准；公开 Benchmark 仅作背景。
  • 请求追踪：关联客户端、Gateway、检索、重排和生成；记录模型、Prompt、数据版本、Token、耗时与错误。敏感内容应脱敏、按权限访问并设置保留期。
  • 安全验证：Prompt Injection、间接注入、越权检索、PII 泄漏与数据投毒；结构化输出能约束格式，但不保证事实正确或授权正确。
  • 成本管理：按模型、应用与团队归集 API 和基础设施成本；观察单位有效回答的成本、超预算行为、缓存与 Fallback 的实际效果。

Stage 3 负责接入控制和基础指标，这里负责设计测量与验证方法。Agent 的工具副作用和任务执行评测将在 Stage 6–7 加入。评测、观测、安全与成本从 Stage 1 就应逐步建设，本章负责形成完整闭环。

资源

实战项目

  1. 版本化评测集：从已有案例整理正常问答、无答案、错误文档、权限与注入样本，先形成小型基线，再逐步扩展。保留独立测试集，抽样对齐人工与自动评分。
  2. 变更回归：更换模型、Prompt 或 Reranker 时运行同一评测集，对比质量、P95 延迟与成本；为退化设置发布门禁。
  3. 线上问题回流：从失败回答追到模型版本、检索资料和各环节耗时；脱敏后补充测试样本、修复并重跑。
  4. 治理演练：验证越权检索、恶意文档、预算超限和端点故障下的行为，记录防护边界与回滚步骤。

完成标准：交付一份可支持上线决策的评测报告和运营手册。能够解释一次变更带来的收益与代价，定位失败并形成回归案例。至此，“调用—部署—平台—知识—治理”的主线形成可演示闭环。

Stage 6 · Workflow / Agent：从回答到执行（可选）

这一阶段解决：什么时候由程序固定流程，什么时候让模型决定下一步？

目标

  • 能区分 Workflow 与 Agent 的控制方式，并根据任务选择。
  • 能把现有问答能力扩展为有限步骤、可观察、可终止的任务执行。
  • 能比较固定流程与动态决策带来的质量、延迟和成本差异。

关键概念清单

  • Workflow：程序定义步骤、分支、超时与重试；其中的模型输出仍可能不确定，Token 成本也需要实测。
  • Agent Loop：模型观察当前状态，选择工具，接收结果，再决定继续或结束。
  • 工具边界：名称、Schema、参数校验、授权、执行结果和错误语义；模型提出调用，不直接获得系统权限。
  • 任务状态：目标、已完成步骤、当前结果、失败原因；避免重复调用，对有副作用的操作设计幂等或人工确认。
  • 运行约束：最大步数、时间、预算、取消、失败退出和人工介入；每次模型或工具调用前检查余量，并设置调用超时，不能只在执行返回后检查。
  • 任务评测：完成率、工具错误、步骤数、延迟、成本和越权/副作用，用 Stage 5 的方法记录和比较。
flowchart TD
    Task["任务目标与当前状态"] --> Limit{"达到运行上限或已取消？"}
    Limit -->|"否"| Decide["模型选择下一步"]
    Limit -->|"是"| Stop["退出并报告 / 请求人工介入"]
    Decide -->|"调用请求"| Check["参数、权限与剩余额度检查"]
    Check -->|"通过"| Tool["工具执行"]
    Check -->|"拒绝或校验失败"| Feedback["结果或错误反馈"]
    Tool --> Feedback
    Feedback --> Limit
    Decide -->|"任务完成"| Done["返回结果与执行记录"]

资源

  • 先理解设计并跑通一个例子
  • 出现具体需求后再选框架
    • LangGraph —— 状态、持久化和流程控制。
    • Pydantic AI —— Python 类型与结构化接口。
    • 不要求同时学习多个框架，也不把代码行数当作理解程度的指标。

实战项目

  1. 发布检查 Workflow：固定执行“检索版本文档 → 汇总变更 → 查询构建状态 → 生成检查报告”，先使用模拟或只读工具。
  2. 动态查询 Agent：在同样的工具集合上，让模型决定查询顺序；只扩大决策范围，不额外增加工具权限。
  3. 对比与失败测试：让工具超时、返回空结果或矛盾信息，比较两种实现的任务完成率、步骤、Token 和耗时。

完成标准：能给出选择 Workflow 或 Agent 的具体理由；程序会拒绝未授权工具调用，在达到限制后退出，并保留足以复现问题的记录。

Stage 7 · Agent Harness / MCP：执行环境与运行治理（可选）

这一阶段解决：怎样让 Agent 在真实环境里运行、接入平台，并从失败中恢复？

目标

  • 理解 Agent Harness 在模型之外承担哪些运行职责。
  • 选择一个现有 Harness，连接模型服务与内部查询能力。
  • 验证权限、上下文管理、会话恢复和运行观测。

关键概念清单

  • Harness 的职责：组织模型调用、工具执行、上下文、会话、权限与恢复；可以是 CLI、应用或服务端运行时，不限于某种界面。
  • MCP：客户端与服务端之间发现和调用工具、获取资源的连接协议；协议本身不替代身份认证、授权与工具隔离。
  • Skills / 仓库规则 / Hooks：分别承载任务知识、工作约定和事件扩展。支持方式因 Harness 而异，约定文件不能代替系统级权限控制。
  • 执行边界：Sandbox、文件与网络范围、凭据隔离、只读工具和写操作审批；用实际拒绝结果验证限制。
  • 上下文与恢复：组装历史和工具结果、压缩上下文、保存 Checkpoint、取消与 Resume；持久化的状态和安全约束不能只依赖模型摘要。
  • 进阶选学：确有跨会话需求时再加入长期 Memory；确有可独立子任务时再使用 Sub-agent，并测量成本和结果归并质量。

Agent 框架提供构建流程的组件，Harness 提供承载任务的运行环境，两者可以组合。Stage 4 处理一次回答所需的信息，这里处理多步骤任务中哪些状态需要保留、何时恢复，以及哪些能力允许执行。

资源

先查清所选版本的模型接入、工具权限和恢复能力，再决定需要扩展什么；不要求从零实现完整 Harness。

实战项目

  1. 接入平台模型：验证所选 Harness 的模型与工具调用兼容性，将请求接到 Stage 3 的统一入口，保留平台身份和预算。
  2. 接入查询工具：把 Stage 4 检索或内部构建状态查询包装成 MCP 工具；传递用户身份，校验权限、超时与错误响应。
  3. 沉淀任务知识：把发布检查步骤和排障约定整理为一个知识包，验证加载后是否提高任务完成率。
  4. 运行与恢复演练：接入 Stage 5 的观测，测试工具拒绝、任务取消、进程中断、上下文压缩与恢复；确认不会重复执行有副作用的动作。

完成标准：交付一个接入平台的执行环境，能够追踪模型与工具调用，说明哪些操作被允许、被拒绝或需要审批；恢复后保留关键状态与约束，并有测试记录。

Stage 8 · LoRA / QLoRA：小规模微调与模型交付（可选）

这一阶段解决：当现有模型行为不满足要求时，怎样验证微调是否有用，并交付训练产物？

这是独立分支：具备 Stage 2 的模型部署能力与 Stage 5 的评测基础后进入，不要求先完成 Agent 或 Harness。

目标

  • 区分知识更新、上下文缺失、流程问题和模型行为问题，判断是否值得微调。
  • 在可承担的算力预算内完成一次小规模训练与独立评测。
  • 把 Adapter 纳入已有模型发布、观测和回滚流程。

关键概念清单

  • 方法边界：SFT 是监督微调任务；LoRA 是低秩参数高效适配方法；QLoRA 结合量化基座与 LoRA，减少训练资源需求。
  • 数据质量：来源、许可、清洗、去重、训练/验证/测试划分；防止把测试答案泄漏到训练或调参过程。
  • 兼容关系：Base Model、Tokenizer、Chat Template、Adapter 与推理引擎支持范围。
  • 训练与评测：超参数、显存、训练时间、过拟合；与固定 Prompt-only 基线比较，必要时加入 RAG 基线。
  • 模型交付：Base Model 与 Adapter 版本绑定、元数据、发布、回滚，以及上线后的质量和性能回归。

DPO、GRPO、完整 RL 训练体系和多卡训练均留到进阶阅读。当前练习不要求同时学习所有对齐方法。

资源

实战项目

  1. 先做基线：选“发布风险分类”或“规范化故障摘要”任务，固定独立评测集，记录 Prompt-only 的失败类型。
  2. 小规模训练：在本地或短时租用 GPU 上训练 LoRA/QLoRA，记录数据版本、配置、显存、时间和成本。
  3. 评测与交付：比较质量收益、通用能力退化、推理延迟与资源开销；有收益再接回 Stage 2/3，并演练 Adapter 回滚。

完成标准：能够根据独立评测决定采用或放弃微调，有可复现训练记录、Base Model / Adapter 对应关系和发布回滚步骤。证明微调不值得采用，也是一项有效实验结果。

学习方法与阶段成果

贯穿项目始终是“内部研发知识与排障服务”。每一步保留可运行成果，再增加下一种能力：

  • Stage 1 留下调用工具与错误处理记录。
  • Stage 2 留下模型端点、性能实验与故障手册。
  • Stage 3 留下统一入口、发布流程与用户接入文档。
  • Stage 4 留下知识索引、引用与权限测试。
  • Stage 5 留下评测集、变更报告、运营与回滚手册。
  • Stage 6–7 按需增加任务执行和 Harness 接入。
  • Stage 8 按需提交微调基线、实验结论与 Adapter 交付记录。

使用这条路线时，记住几条原则：

  1. 先做最小版本，再补深度：一个模型、一个引擎、一套检索和观测工具足以开始。
  2. 由失败决定下一步：优先补能解释当前错误或瓶颈的知识，进阶资料按需阅读。
  3. 完成标准用证据表达：以仓库、实验条件、数据和复盘判断“会不会”，不以看完多少资料判断。
  4. 明确技术取舍：部署规模、模型大小、框架选择和安全要求应与当前任务匹配。
  5. 保留交付优势：文档、版本、测试、回滚、可靠性和用户体验同样是 AI 工程能力。
  6. 动态进度统一维护：学习任务与证据放入 Skill Compass，正文保持稳定的阶段边界。

完成一个阶段意味着能交付它承诺的成果，并解释主要失败情况，不意味着掌握该领域所有工具。

后续方向：AI Infra / AI Performance / AI Platform

AI Infra：扩大资源与基础设施责任

继续补 GPU 驱动和运行时生命周期、集群调度、队列、配额、拓扑、存储和网络。可从“多团队共享 GPU 服务”入手，衡量排队时间、资源利用率、隔离与故障恢复。

资源入口：NVIDIA GPU Operator、MIG、SkyPilot。

Inference / AI Performance：深入性能瓶颈

在 Stage 2 的实验方法上，继续学习 Profiling、显存带宽、通信、并行策略、Speculative Decoding 和 Prefill/Decode 分离。按实际瓶颈选择优化方式，比较同一质量要求与负载下的结果。

资源入口：TensorRT-LLM、NVIDIA Dynamo、llm-d、AIPerf。

NVIDIA 文档已说明 GenAI-Perf 正在退场，新基准测试优先采用 AIPerf；阅读旧实验时仍可参考 GenAI-Perf 的指标定义。

AI Platform：扩大服务与组织影响

继续完善模型目录、自助接入、SLO、成本归集、治理标准与跨团队交付。以接入耗时、采用率、故障处理和单位有效结果成本衡量收益。

成长路径可以从维护一个端点，到独立负责子系统，再到建设跨团队平台能力。岗位晋升取决于问题范围、可靠交付与组织影响；学习新工具应服务于这些责任。

延伸阅读与可选背景

系统补课与长期资料

Career
#Agent #LLM #AI #Roadmap #Career
DevOps -> AI Infra 工程师的学习 Roadmap（2026）
https://gou7ma7.github.io/2026/05/12/career/@2026_ai_learn_roadmap/
作者
Roy Lee
发布于
2026年5月12日
许可协议