在《你的代码正在贬值》里，我们确认了一个事实：写代码不值钱了。在《AI 工程的三条腿》里，我们讨论了 RAG / MCP / Skill 这些"使用 AI"的技能。但那篇文章结尾，有一个没展开的问题——这些技能本身也没有壁垒，任何人一周就能学会。
所以这篇文章讨论一个更根本的方向选择题：如果"用 AI"不是护城河，那"让 AI 跑起来"是不是？
这篇文章解决什么问题
如果你和我一样是 Java/Go 背景的后端工程师，你可能在招聘网站上看到过以下这些岗位：
- AI 基础架构工程师
- 机器学习平台工程师
- GPU 云平台开发工程师
- 推理引擎开发工程师
- MLOps 工程师
- 大模型部署/优化工程师
它们看起来是 6 个不同岗位，但本质上是同一个方向的不同切面。 就像"后端工程师"、"Java 开发工程师"、"微服务架构师"、"中间件开发"本质上都是后端一样——上面这些，都是 AI Infra。
这篇文章要做三件事：
- 拆清楚 AI Infra 到底是什么、内部的技能层次结构
- 评清楚 从 Java/Go 切入的适配度、学习门槛、投入产出比
- 规划清楚 一条真实可执行的学习路线——不是 6 条分散的路线，是 1 条分层递进的路线
一、AI Infra 到底在干什么——一张图说清楚
忘掉那 6 个岗位名称。AI Infra 解决的是一个统一的问题：
算法工程师训练出一个模型文件。这个文件几十 GB，不能直接用。要让它变成千万用户可以调用的 API 服务、让 GPU 集群高效运转、让训练任务稳定完成——这中间的所有工程问题，就是 AI Infra。
类比一下你熟悉的领域：
传统后端的世界：
代码写完了 → 怎么部署？怎么扩容？怎么监控？怎么保证不挂？
→ 这些问题催生了 DevOps / SRE / 云原生工程师
AI 的世界：
模型训练完了 → 怎么部署到 GPU 上？怎么扛住并发？怎么省钱？怎么不 OOM？
→ 这些问题催生了 AI Infra 工程师
AI Infra 不是一个岗位，是一个技术栈。它有清晰的分层结构：
┌─────────────────────────────────────────────────────────────┐
│ 第四层：全链路运维（MLOps） │
│ 模型上线后的监控、告警、成本管控、安全审计、CI/CD │
│ ← 传统 DevOps/SRE 技能几乎可以直接迁移 │
├─────────────────────────────────────────────────────────────┤
│ 第三层：平台工程（ML Platform） │
│ 训练任务管理、实验追踪、模型仓库、特征平台、Pipeline 编排 │
│ ← Java/Go 大型系统开发经验直接适用 │
├─────────────────────────────────────────────────────────────┤
│ 第二层：资源调度（GPU Cluster Management） │
│ GPU 分配、多租户隔离、集群调度、自动扩缩容、成本优化 │
│ ← Go + K8s 经验是核心优势 │
├─────────────────────────────────────────────────────────────┤
│ 第一层：推理与训练引擎（Inference & Training Engine） │
│ 模型加载、显存管理、请求调度、量化加速、分布式并行 │
│ ← 需要新学，但不需要从头学算法 │
├─────────────────────────────────────────────────────────────┤
│ 第零层：硬件与系统（GPU Hardware & Runtime） │
│ GPU 架构、CUDA Runtime、NCCL 通信、InfiniBand 网络 │
│ ← 需要理解原理，不需要亲手写 Kernel（除非选极硬核路线） │
└─────────────────────────────────────────────────────────────┘
那 6 个岗位名称，只不过是不同公司对这 5 层中不同侧重点的 JD 包装：
| JD 名称 | 实际侧重层 | 说白了干什么 |
|---|---|---|
| 推理引擎开发工程师 | 第一层 | 让模型推理又快又省 |
| 大模型部署/优化工程师 | 第一层 + 第二层 | 把模型搞上线，调到能用 |
| GPU 云平台开发工程师 | 第二层 | 让 GPU 集群被高效共享 |
| 机器学习平台工程师 | 第三层 | 造"AI 工厂"，让算法团队自助式训练部署 |
| MLOps 工程师 | 第四层 | 让模型在生产环境稳定运行 |
| AI 基础架构工程师 | 全层 | 以上全要懂，偏架构设计 |
记住这个分层。后面所有的学习规划、难度评估、路线设计都围绕它展开。
二、为什么 Java/Go 程序员适合这个方向
在讨论怎么学之前，先回答一个前置问题：为什么是你？
AI 行业目前有一个巨大的人才错配：
做 AI 算法的人：
├── 擅长：PyTorch / 训练 / 论文复现
├── 不擅长：分布式系统 / 高并发 / K8s / 大规模工程
└── 数量：多（每年大量 AI 硕博毕业）
做基础设施的人（你）：
├── 擅长：分布式系统 / 高并发 / K8s / 大规模工程
├── 不擅长：GPU / 模型推理 / 训练框架
└── 数量：几乎没人往 AI Infra 方向走
市场现状：
→ 算法岗：供过于求，内卷严重
→ AI Infra：严重供不应求
为什么供不应求？因为这个方向需要的技能组合很特殊：
| 需要的能力 | 算法工程师有没有 | 后端工程师有没有 |
|---|---|---|
| 分布式系统设计 | 通常没有 | 有 |
| K8s 二次开发（Go） | 基本没有 | 有或能快速学 |
| 高并发服务架构 | 通常没有 | 有 |
| 理解 GPU 计算特征 | 有 | 没有（需要学） |
| 理解模型推理过程 | 有 | 没有（需要学） |
| 性能调优经验 | 部分有 | 有 |
看到没有？你缺的是 2 项，算法工程师缺的是 4 项。你的迁移成本更低。
而且你缺的那 2 项（GPU 特征 + 模型推理原理），是可以在 2-3 个月内补到"能用"水平的——不需要你去推公式、写论文，你只需要理解"模型推理这个工作负载消耗什么资源、瓶颈在哪、怎么优化"。
这就像你做 MySQL 调优不需要自己写一个存储引擎——你需要理解 B+ 树、Buffer Pool、索引选择性，但你不需要去实现它们。
三、学习门槛与投入产出评估——说真话
3.1 分层难度评估
| 层级 | 对 Java/Go 的学习难度 | 需要新学的核心知识 | 预计投入时间 | 市场价值 |
|---|---|---|---|---|
| 第四层 MLOps | ★★☆☆☆ 低 | AI 特有指标（模型漂移、推理延迟） | 1-2 月 | 35-70w |
| 第三层 ML Platform | ★★★☆☆ 中 | 训练流程、特征工程概念、Pipeline 编排 | 2-4 月 | 45-100w |
| 第二层 GPU 调度 | ★★★☆☆ 中 | GPU 资源模型、设备管理、拓扑感知 | 3-5 月 | 45-100w |
| 第一层 推理引擎 | ★★★★☆ 中高 | 推理优化原理、显存管理、量化技术 | 4-6 月 | 50-120w |
| 第零层 GPU/CUDA | ★★★★★ 高 | CUDA 编程、算子开发、编译器 | 8-18 月 | 80-150w+ |
几个诚实的判断：
入门最快、需求最大的切入点是第一层 + 第二层的交叉区域。 也就是"能把模型部署上线、能调优推理性能、能管理 GPU 资源"——这是目前每家公司都缺人的环节。
第四层（MLOps）最容易上手但天花板最低。 如果你有 DevOps 背景，1 个月就能切入，但长期来看容易被工具化（和传统运维一样的命运）。
第零层（CUDA/算子）天花板最高但投入最大。 需要学 C++、学 CUDA、学编译器——对 Java/Go 程序员来说迁移成本巨大。但一旦入门，你是市场上最稀缺的人。建议作为长期选修方向，不作为入门路径。
3.2 一个核心判断
你不需要从第零层学到第四层。你需要在第一层+第二层建立核心竞争力，对第三层和第四层有全局理解，第零层按需深入。
就像做后端不需要精通内核——但你需要知道 epoll 是什么、TCP 的重传机制是什么。AI Infra 也一样：你不需要写 CUDA Kernel，但你需要知道 GPU 的显存层级和计算瓶颈。
3.3 和其他转型方向的横向对比
| 转型方向 | Java/Go 适配度 | 学习周期 | 市场竞争 | 被 AI 替代风险 | 薪资天花板 |
|---|---|---|---|---|---|
| AI Infra（本文方向） | ★★★★★ | 6-12 月 | 低（供不应求） | 低（AI 自己跑不了自己） | 极高 |
| AI 算法工程师 | ★★☆☆☆ | 12-18 月 | 极高（硕博扎堆） | 中 | 高 |
| AI 应用开发（Agent 等） | ★★★★☆ | 1-3 月 | 高（门槛低） | 高（工具层迭代快） | 中 |
| 技术管理转型 | ★★★☆☆ | 看机遇 | 中 | 中 | 中高 |
| 独立开发/创业 | ★★★★☆ | 即时 | 看赛道 | 低 | 无上限/可能为零 |
四、AI Infra 技能地图——不是 6 条线，是 1 棵树
放弃"先学 A 岗位还是 B 岗位"的思路。AI Infra 的技能是分层生长的，像一棵树：
┌── MLOps 运维能力（第四层）
│ ├── Prometheus/Grafana GPU 监控
│ ├── 模型 CI/CD Pipeline
│ ├── 成本分析与优化
│ └── 安全审计与合规
│
┌─────┤
│ └── ML 平台能力（第三层）
│ ├── 训练任务管理（CRD + Controller）
│ ├── 实验追踪（MLflow）
│ ├── 特征平台（Feast）
│ └── Pipeline 编排（Argo/Airflow）
│
┌────┤
│ └── 资源调度能力（第二层）
│ ├── K8s GPU 设备管理
│ ├── 自定义 Scheduler（Go）
│ ├── 多租户隔离与配额
│ └── 自动扩缩容控制器
│
┌────┤
│ └── 推理引擎能力（第一层）
│ ├── vLLM 部署与调优
│ ├── 推理框架原理（PagedAttention / Continuous Batching）
│ ├── 模型量化（AWQ/GPTQ/FP8）
│ ├── 多卡并行策略（TP/PP）
│ └── 服务化（API Gateway / 路由 / 限流）
│
─────┤
└── AI 工作负载理解（根基）
├── 神经网络计算流程
├── Transformer / LLM 推理特征
├── GPU 资源模型（显存 / 算力 / 带宽）
├── 训练 vs 推理的资源差异
└── 关键指标体系（TTFT / TPS / GPU Util / MBU）
学习的顺序是自下而上。 根基不稳，上面全是空中楼阁。
五、学习路线——一条线，四个阶段
全局时间线
月份 1 2 3 4 5 6 7 8 9
|─── 阶段一 ───|
理解 AI 工作负载 |─── 阶段二 ──────|
推理引擎实战 |─── 阶段三 ──────|
K8s+GPU 平台(Go) |─ 阶段四(选修) ─→
分布式训练/ML平台
|═══════════════ 持续输出博客 / GitHub 项目 ═══════════════|
|── 投简历 ──|
阶段一：理解 AI 工作负载（第 1-6 周）
目标：不是学 AI 算法，而是像你理解 MySQL 的 Buffer Pool 一样理解 LLM 的推理过程——知道它的资源消耗特征、性能瓶颈在哪、哪些参数影响什么指标。
这个阶段解决一个问题：你将来要管理和优化的"工作负载"到底长什么样。
第 1-2 周：最小必要的神经网络知识
你不需要会训练模型，你需要理解训练和推理的计算过程。
需要看懂的核心代码结构（不是让你写，是让你看懂）：
for epoch in range(num_epochs):
for batch in dataloader:
inputs, labels = batch
outputs = model(inputs) # 前向传播 → 吃 GPU 算力
loss = criterion(outputs, labels) # 算损失
loss.backward() # 反向传播 → 吃 GPU 算力 + 显存
optimizer.step() # 更新权重 → 吃显存
optimizer.zero_grad()
你要关注的不是算法原理，而是：每一步的资源消耗特征是什么？batch size 翻倍，显存和算力怎么变？模型参数量和显存的关系是什么？
核心结论（先记住，后面会不断用到）：
- 1B 参数 FP16 ≈ 2GB 显存（仅模型权重）
- 训练时显存 ≈ 模型权重的 4-8 倍（梯度 + 优化器状态 + 激活值）
- 推理时显存 ≈ 模型权重 + KV Cache（随序列长度增长）
| 学习资源 | 时间 | 目的 |
|---|---|---|
| 3Blue1Brown《Neural Networks》4 集 | 1h | 直觉理解前向/反向传播 |
| PyTorch 60 分钟入门 | 2h | 跑通 MNIST，观察 GPU 显存变化 |
| 李沐《动手学深度学习》3-5 章 | 选读 | 想深入时查阅 |
第 3-4 周：Transformer 和大模型的计算特征
这是最重要的两周。 AI Infra 的所有优化工作都建立在对 Transformer 推理过程的理解上。
必须搞懂的四件事：
| 概念 | 一句话解释 | 为什么 Infra 要关心 |
|---|---|---|
| Self-Attention | 每个 token 和所有 token 做相似度计算 | 计算复杂度 O(n²)，决定了长序列推理的成本 |
| KV Cache | 推理时缓存已计算的 Key/Value，避免重复计算 | 显存占用随序列长度线性增长，是推理显存的主要消耗 |
| 自回归生成 | 每次只生成 1 个 token，串行 | 推理不是一次性算完的，是一个 token 一个 token 吐出来的 |
| Memory-bound | 推理的瓶颈不是算力，是显存带宽 | GPU 利用率上不去不是因为算力不够，是数据搬运不够快 |
必读： Jay Alammar《The Illustrated Transformer》——这是全网最直观的图解，3 小时能读完。
动手实验： 用 Hugging Face 加载一个 7B 模型（如 Qwen2.5-7B），测不同输入长度下的推理时间和显存变化。不是为了学框架，是为了建立对资源消耗的直觉。
第 5-6 周：训练 vs 推理的资源全景
| 维度 | 训练 | 推理 |
|---|---|---|
| 计算特征 | Compute-bound | Memory-bandwidth-bound |
| 显存消耗 | 参数 + 梯度 + 优化器 + 激活值 | 参数 + KV Cache |
| 多卡通信 | 频繁 AllReduce（梯度同步） | 少量 AllGather |
| 容错需求 | Checkpoint 恢复即可 | 必须高可用（实时服务） |
| 核心瓶颈 | GPU 计算速度 + 卡间通信带宽 | 显存容量 + 内存带宽 |
必读：
- vLLM 官方博客（理解 PagedAttention 的设计动机）
- NVIDIA《LLM Inference Performance Engineering》
必须能回答的问题：
- 为什么大模型推理不是 GPU 算力不够，而是显存带宽不够？
- KV Cache 的显存占用怎么算？（提示：和 layer 数、head 数、序列长度、精度有关）
- Continuous Batching 比 Static Batching 好在哪？
阶段验证标准： 你能向一个非 AI 背景的程序员讲清楚"为什么大模型推理很贵、贵在哪里、优化的方向有哪些"。如果讲不清楚，说明你还没真正理解。
阶段二：推理引擎实战（第 7-14 周）
目标：能独立部署和调优一个生产级的 LLM 推理服务，理解主流推理框架的核心架构。
这个阶段是你在简历上写出"有大模型推理优化经验"的关键。
第 7-9 周：vLLM 从部署到源码
第一步：部署 + 压测（1 周）
# 启动服务
vllm serve Qwen/Qwen2.5-7B-Instruct \
--tensor-parallel-size 1 \
--gpu-memory-utilization 0.9 \
--max-num-seqs 256
# 压测（用 locust 或自写脚本）
# 必须做的 3 组实验：
# 实验 1：固定输入 128 token，并发从 1 → 10 → 50 → 200，观察 TPS 和 TTFT
# 实验 2：固定并发 50，输入从 128 → 512 → 2048 → 8192，观察显存和延迟
# 实验 3：调 max-num-seqs 从 64 → 256 → 1024，观察吞吐和延迟的 tradeoff
这一步的目的不是"学会用 vLLM"——那太简单了。目的是建立参数和性能之间的映射直觉。
第二步：读 vLLM 源码核心模块（2 周）
不需要读完。聚焦三个模块：
| 模块 | 文件 | 要搞懂的问题 |
|---|---|---|
| Scheduler | vllm/core/scheduler.py | 请求怎么排队？什么时候 preempt？Waiting/Running/Swapped 三个队列怎么管理？ |
| PagedAttention | vllm/attention/backends/ | KV Cache 的 Block 怎么分配回收？物理块和逻辑块的映射？ |
| Engine | vllm/engine/async_llm_engine.py | 一个请求从 API 进入到返回的完整链路？流式输出怎么实现？ |
为什么要读源码？ 因为面试一定会问 vLLM 的 PagedAttention 原理，看博客能回答 70 分，看过源码能回答 95 分。而且读源码的过程会让你理解"为什么这样设计"，这比背原理重要得多。
第 10-12 周：推理框架横向对比
| 框架 | 核心特点 | 你需要知道的 |
|---|---|---|
| vLLM | PagedAttention，社区最大 | 通用首选，大部分公司在用 |
| TensorRT-LLM | NVIDIA 官方，极致性能 | 性能最好但灵活性差，绑定 NVIDIA 生态 |
| SGLang | RadixAttention，擅长多轮对话 | 有大量共享前缀的 Agent 场景下更优 |
实验任务： 同一个模型在 vLLM / TRT-LLM / SGLang 上跑相同压测，记录 throughput、latency P50/P99、显存占用。写成一篇对比评测。
第 13-14 周：推理优化技术
| 技术 | 原理（一句话） | 效果 |
|---|---|---|
| INT4 量化（AWQ/GPTQ） | 把 FP16 权重压缩到 4bit | 显存减 4 倍，速度提 1.5-2x，精度略损 |
| FP8 量化 | H100 原生 FP8 支持 | 接近 FP16 精度，2x 速度 |
| Speculative Decoding | 小模型猜多个 token，大模型并行验证 | 生成速度 2-3x |
| Prefix Caching | 缓存相同 system prompt 的 KV Cache | 相同前缀的请求大幅加速 |
每个技术做一个对比实验，记录量化前后或开启前后的性能差异。
阶段验证标准： 有人给你一个 70B 模型和 2 张 A100 80GB，你能在 2 小时内部署上线一个推理服务，说清楚选了什么框架、什么量化方案、什么并行策略、为什么。
阶段三：K8s + GPU 资源管理——Go 技能发力（第 15-26 周）
目标：能设计和开发基于 K8s 的 GPU 资源管理和模型服务平台。这是你 Go 背景的最大杠杆点，也是你和纯算法背景的人拉开差距的阶段。
第 15-17 周：K8s GPU 管理机制
你需要搞懂的核心机制：
K8s 默认对 GPU 的管理非常粗糙：
→ Pod 声明 nvidia.com/gpu: 1 → kubelet 通过 Device Plugin 分配一张卡 → 完
→ 不知道这张卡的显存用了多少
→ 不知道这张卡和哪张卡之间有 NVLink
→ 不支持显存级别的共享
→ 不支持"要么给我 4 张卡，要么一张都别给"（Gang Scheduling）
所有 AI Infra 的 GPU 调度工作，本质上都是在弥补 K8s 默认调度器对 GPU 的无知。
GPU 共享方案对比（必须搞清楚的基础知识）：
| 方案 | 隔离级别 | 性能损耗 | 适用场景 |
|---|---|---|---|
| MIG（Multi-Instance GPU） | 硬件级 | 几乎无 | A100/H100，生产推理 |
| MPS（Multi-Process Service） | 进程级 | 低 | 多个小模型共享一张卡 |
| Time-Slicing | 时间片 | 中 | 开发测试环境 |
| vGPU | 虚拟化 | 中 | 多租户云平台 |
学习路径： NVIDIA Device Plugin 源码（Go 写的）→ GPU Operator 架构 → 各共享方案实操。
第 18-22 周：核心项目——Go 实现 GPU-aware Scheduler
这是整个学习路线中最重要的产出。 它同时证明了三件事：你懂 K8s、你懂 GPU 资源管理、你的 Go 不是白学的。
项目定义：
一个 K8s 自定义调度器，能比默认调度器更聪明地分配 GPU。
功能清单：
├── 1. GPU 拓扑感知：多卡任务优先分配有 NVLink 互连的 GPU 组
├── 2. 显存感知 Binpack：小任务往已有任务的 GPU 上塞，大任务给空 GPU
├── 3. Gang Scheduling：分布式训练 N 卡全给或不给，避免死锁
└── 4. 优先级抢占：高优任务可以抢占低优任务的 GPU
技术方案：
├── 基于 K8s Scheduler Framework（Go 原生扩展点）
├── Filter 阶段：过滤 GPU 资源不满足的节点
├── Score 阶段：按拓扑 + 显存利用率打分
├── Reserve + Permit 阶段：Gang Scheduling 的等待逻辑
└── 参考：Volcano / YuniKorn 源码
第 23-26 周：模型服务网关（Go 项目）
在 GPU 调度器之上，构建模型服务层：
用户请求 → API Gateway → 模型路由 → 推理实例池
│ │ │
│ │ ├── Model-A (vLLM, 2×GPU)
│ │ ├── Model-B (vLLM, 1×GPU)
│ │ └── Model-A-v2 (canary, 1×GPU)
│ │
│ ├── 路由：按模型名 / 版本 / A-B 测试权重
│ └── 负载均衡：最少连接 / 加权轮询
│
├── 限流降级（令牌桶）
├── 认证鉴权（API Key）
└── 自动扩缩容（基于队列长度 + GPU 利用率）
这些组件对你来说应该是"舒适区"——高并发网关、负载均衡、限流降级，你做后端时都做过。区别只是负载均衡的目标从 CPU 服务变成了 GPU 推理实例。
阶段验证标准： GitHub 上有两个项目（GPU Scheduler + Model Gateway），用 Go 写的，有架构图、有 README、有性能测试数据。
阶段四：扩展深度——按需选修（第 27 周+）
这个阶段不是线性的，是根据你的目标公司和岗位侧重选修：
| 如果你目标是 | 选修方向 | 核心内容 |
|---|---|---|
| AI 创业公司 Infra 团队 | 分布式训练基础设施 | 数据并行/张量并行/流水线并行原理、NCCL 通信、弹性训练、Checkpoint 管理 |
| 云厂商 GPU 平台团队 | ML Platform | Kubeflow / MLflow 二次开发、特征平台、Pipeline 编排 |
| 推理优化方向深入 | CUDA + 算子 | C++ / CUDA 编程、FlashAttention 源码、Triton 语言、推理 Kernel 优化 |
六、怎么证明你学到了——产出清单
学习不产出就是自我感动。以下是你必须积累的"作品集"：
技术博客
| 阶段 | 文章 | 中文社区稀缺度 |
|---|---|---|
| 阶段一 | 《从后端工程师视角理解大模型推理的资源消耗》 | 中——但视角独特 |
| 阶段二 | 《vLLM 源码分析：Scheduler 是怎么调度请求的》 | 极高 |
| 阶段二 | 《vLLM vs TRT-LLM vs SGLang：7B 模型推理实测》 | 极高 |
| 阶段二 | 《AWQ 量化实战：性能、精度、显存的三方博弈》 | 高 |
| 阶段三 | 《用 Go 写一个 K8s GPU-aware Scheduler》 | 极高 |
| 阶段三 | 《大模型推理服务网关设计与实现》 | 高 |
vLLM 源码分析系列在中文技术社区几乎空白。你写了就是第一批，流量和影响力都有。
GitHub 项目
| 项目 | 语言 | 证明什么 |
|---|---|---|
gpu-scheduler | Go | K8s + GPU 资源管理能力 |
llm-gateway | Go | 高并发服务架构 + 模型部署能力 |
inference-bench | Python + Shell | 推理优化理解深度 |
开源贡献
给 vLLM / SGLang / Volcano 提 PR——哪怕是修文档、加测试。简历上"参与推理引擎开源项目"这一行的价值远超你想象。
七、目标岗位与面试准备
7.1 目标公司
| 层级 | 公司 | 团队方向 |
|---|---|---|
| 头部大厂 | 字节（AML/火山引擎）、阿里（PAI）、腾讯（机智平台） | 推理优化 + GPU 平台 |
| AI 原生公司 | DeepSeek、月之暗面、MiniMax、智谱 | 训练/推理基础设施 |
| 云厂商 | 火山引擎、阿里云、华为云 | GPU 云平台 + 模型服务 |
| 外企 | NVIDIA（Triton/TRT-LLM）、AMD | 推理引擎开发 |
7.2 高频面试题（覆盖全层级）
推理引擎（第一层）：
- vLLM 的 PagedAttention 解决什么问题？和 Static Batching 相比好在哪？
- Continuous Batching 怎么实现？如何处理不同长度的请求？
- INT4 量化 vs FP16，性能提升多少？精度怎么评估？
- Tensor Parallelism 和 Pipeline Parallelism 的区别？通信开销分别是什么？
GPU 调度（第二层）： 5. K8s 默认调度器为什么不适合 GPU 工作负载？你怎么改？ 6. MIG / MPS / Time-Slicing 各自的隔离级别和适用场景？ 7. Gang Scheduling 为什么需要？怎么避免死锁？
系统设计（综合）： 8. 设计一个支持千级 QPS 的大模型推理服务平台 9. 公司有 200 张 GPU、20 个团队，设计资源管理方案 10. 如何把 GPU 利用率从 30% 提升到 80%？
7.3 简历关键词
vLLM / TensorRT-LLM / 推理优化 / PagedAttention / Continuous Batching
Kubernetes / GPU 调度 / Device Plugin / Scheduler Framework / Operator
模型量化 / AWQ / FP8 / Tensor Parallelism
Go / gRPC / 高性能网关 / 分布式系统
Prometheus / Grafana / GPU 监控
八、回到开头的问题
在《你的代码正在贬值》里，我写了一句话：
代码贬值不等于程序员消亡。它意味着"只会写代码的程序员"消亡，而"会用代码解决问题的人"变得更值钱。
这句话是对的，但还不够具体。具体到什么程度？
AI 正在让"写代码"变成一种免费资源。但 AI 自己需要大量"不是写代码就能解决的工程问题"——GPU 怎么调度、显存怎么管理、推理怎么加速、集群怎么不崩。这些问题需要的是对硬件的理解、对分布式系统的经验、对资源约束的工程直觉。
这些你都有。只是还没有接到 AI 的工作负载上。
AI 替代了写代码的人。那就去做让 AI 能跑起来的人。
从写代码的人，变成修铁轨的人。代码是列车上的货物，越来越便宜；铁轨是让列车跑起来的基础设施，越来越值钱。
你选哪个？
