这是一篇面向想系统了解 AI Infra 的长文。它不假设读者已经是 CUDA、分布式训练或推理系统专家，而是试图从“大模型为什么需要基础设施”讲起，逐层拆解 AI Infra 的技术栈、核心问题、典型优化方法，以及普通工程师应该如何建立学习路线。

过去几年，很多人讨论大模型时，最先想到的是模型结构、训练数据、提示词、Agent、RAG 或者各种应用形态。但真正让大模型从论文、Demo 和实验室走向线上产品的，并不只是算法本身，而是一整套支撑模型训练、推理、部署和服务化的工程系统。这个系统，通常被称为 AI Infra，也就是 AI 基础设施。

如果把大模型比作一辆高性能赛车，算法决定了赛车的发动机设计和驾驶策略，而 AI Infra 则是赛道、维修站、燃料供给、调度系统、传感器、后勤团队和整套赛事组织能力。没有 AI Infra，模型再聪明，也很难稳定、低成本、高吞吐地服务真实用户。

这也是为什么越来越多公司开始招聘 AI Infra 工程师、推理优化工程师、高性能计算工程师、分布式训练工程师、CUDA 算子优化工程师、LLM Serving 工程师。它们名字不同，但底层关注的问题高度一致：如何让 AI 模型在有限硬件资源上跑得更快、更稳、更便宜。

本文会按照一个自顶向下的方式展开：

1. 什么是 AI Infra，它和算法、应用的边界在哪里
2. 大模型为什么让 AI Infra 变得重要
3. AI Infra 的完整技术栈：硬件、系统软件、训练、推理、性能工程
4. CUDA 和算子优化为什么是很多岗位的硬核能力
5. 分布式训练到底在解决什么问题
6. 推理优化为什么越来越像一门独立工程学科
7. 性能分析应该如何建立思维框架
8. 普通工程师如何学习 AI Infra
9. 面试和求职时应该重点准备什么

---

一、什么是 AI Infra

AI Infra，全称 AI Infrastructure，可以理解为支撑 AI 模型从训练到推理再到线上服务的基础设施系统。它不是一个单独的软件，也不是某个框架，而是一整套技术体系。

更具体一点，AI Infra 通常包括：

• 算力硬件：GPU、NPU、TPU、AI ASIC、CPU、内存、网络互联
• 编程与运行时：CUDA、ROCm、驱动、编译器、运行时库
• 高性能算子：GEMM、Attention、Softmax、LayerNorm、Embedding 等
• 训练系统：数据并行、张量并行、流水线并行、ZeRO、FSDP、Megatron、DeepSpeed
• 推理系统：KV Cache、PagedAttention、Continuous Batching、量化、Speculative Decoding、vLLM、TensorRT-LLM、SGLang
• 调度与服务：模型部署、请求调度、负载均衡、弹性伸缩、监控告警
• 性能工程：Profiling、Benchmark、Roofline、Nsight、PyTorch Profiler、瓶颈定位

它和 AI 算法的关系非常紧密，但关注点不同。

算法工程师更关心：

• 模型效果是否更好
• Loss 是否更低
• 生成质量是否更强
• 数据配比、训练策略、模型结构是否合理

AI Infra 工程师更关心：

• 模型能不能训起来
• 多卡训练效率是不是足够高
• 推理延迟能不能降下来
• 显存是不是被浪费
• 吞吐能不能提升
• 在线服务是否稳定
• 成本能不能控制

当然，在大模型时代，这两个方向的边界越来越模糊。例如 FlashAttention 既可以被看作一种注意力计算方式的算法改进，也可以被看作一种 IO 感知的 CUDA Kernel 优化；MoE 既是模型结构创新，也会带来专家路由、负载均衡、通信调度和 serving 复杂度；KV Cache 看似是推理系统问题，但它直接改变了大模型自回归生成的工程成本结构。

因此，一个优秀的 AI Infra 工程师不一定要发明新模型，但需要理解模型结构背后的计算模式；一个优秀的大模型算法工程师，也很难完全不懂训练和推理的工程约束。

---

二、为什么大模型时代让 AI Infra 变得关键

传统深度学习时代，很多模型可以在单卡甚至 CPU 上完成训练和部署。即使是稍大的 CV 模型、推荐模型或 NLP 模型，也往往可以通过成熟框架比较顺畅地落地。但大模型改变了这一切。

1. 模型参数规模急剧膨胀

当模型参数从几千万、几亿增长到几十亿、几百亿甚至上千亿，最直接的问题就是显存不够。以一个 70B 参数模型为例，如果使用 FP16 或 BF16，仅参数本身就需要约 140GB 显存。这还没有计算梯度、优化器状态、激活值、中间 buffer 和通信缓存。

训练时的显存开销通常远高于推理。一个参数在训练中可能对应：

• 模型权重
• 梯度
• 优化器一阶动量
• 优化器二阶动量
• FP32 master weight
• 激活值
• 临时计算 buffer

这意味着模型训练不仅需要更多 GPU，还需要复杂的并行策略来切分参数、梯度、优化器状态和激活。

2. 多卡通信成为核心瓶颈

单卡放不下模型，就必须多卡协同。多卡协同带来的第一类问题是通信。

在数据并行中，每张卡都有一份模型副本，但处理不同 batch，反向传播后需要同步梯度。在张量并行中，一个矩阵乘法会被切到多张卡上，需要频繁 AllReduce、AllGather 或 ReduceScatter。在流水线并行中，不同层放在不同设备上，前向和反向过程都需要跨设备传递激活和梯度。

随着 GPU 算力不断提升，很多时候计算本身越来越快，通信反而成为瓶颈。训练效率不高，可能不是因为 GPU 不够强，而是因为 GPU 在等数据、等梯度、等通信。

3. 推理成本成为长期支出

训练通常是一次性或阶段性成本，而推理是长期成本。一个大模型产品只要上线，每一次用户请求都需要消耗计算资源。

对于大语言模型，推理还有一个很特殊的特点：自回归生成。模型不能一次性生成完整答案，而是一个 token 一个 token 地生成。每生成一个 token，都要进行一次前向计算。用户看到的“流式输出”，背后其实是模型不断重复计算和调度。

这带来了几个核心挑战：

• 首 token 延迟要低
• 每秒生成 token 数要高
• 多用户并发要稳定
• KV Cache 显存占用要可控
• 长上下文不能把显存打爆
• 请求长度不同，调度不能浪费 GPU

于是，推理优化逐渐从“部署模型”变成了一套复杂系统工程。

4. 成本决定商业可行性

大模型时代有一个残酷事实：效果很重要，成本同样重要。一个模型如果效果很好，但推理成本过高、延迟过高、吞吐太低，很难支撑真正的大规模商业化。

AI Infra 的价值就在这里。它不是锦上添花，而是决定一个模型能否被真实使用、能否规模化服务、能否长期盈利的关键能力。

优化 10% 的训练效率，可能意味着节省大量 GPU 时间；优化 20% 的推理吞吐，可能意味着同样硬件能服务更多用户；降低 30% 的显存占用，可能意味着模型可以部署到更便宜的硬件上。

所以 AI Infra 的本质不是“炫技”，而是围绕性能、成本和稳定性的工程能力。

---

三、AI Infra 的技术栈全景

可以把 AI Infra 分成五层来看。

第一层：硬件层

硬件是所有性能优化的底座。当前大模型训练和推理最核心的硬件仍然是 GPU，尤其是 NVIDIA GPU。理解 GPU 架构，是理解 AI Infra 的起点之一。

GPU 之所以适合深度学习，是因为深度学习中的核心计算大量是矩阵乘法、向量运算和张量操作。这类计算具有高度并行性。GPU 拥有大量计算核心，可以同时处理许多数据元素。

常见需要理解的硬件概念包括：

• SM：Streaming Multiprocessor，GPU 的基本计算单元
• Warp：通常由 32 个线程组成，是 GPU 调度执行的基本单位
• Register：线程私有的高速存储
• Shared Memory：一个 block 内线程共享的高速片上存储
• L2 Cache：跨 SM 共享的缓存
• HBM：高带宽显存
• Tensor Core：专门用于矩阵乘法加速的硬件单元
• NVLink / NVSwitch：GPU 间高速互联
• PCIe / InfiniBand：节点内和节点间通信通道

对于 AI Infra 工程师来说，硬件不是背概念，而是为了回答实际问题：

• 为什么有些算子是 memory-bound，有些是 compute-bound？
• 为什么访存合并会影响性能？
• 为什么 shared memory bank conflict 会拖慢 kernel？
• 为什么 Tensor Core 能极大提升 GEMM 性能？
• 为什么多机训练扩展效率上不去？
• 为什么 HBM 带宽有时比峰值算力更重要？

第二层：系统软件和编程模型

硬件不会自动高效运行模型，需要系统软件把上层计算映射到底层设备。

这一层包括：

• CUDA / ROCm 编程模型
• GPU Driver 和 Runtime
• cuBLAS、cuDNN、NCCL 等基础库
• 编译器和图优化系统
• Triton、TVM、XLA、torch.compile 等工具链

CUDA 是 NVIDIA GPU 编程的基础。理解 CUDA 不一定意味着每个人都要天天手写 kernel，但至少要理解线程组织、内存层级、同步机制和性能瓶颈。

CUDA 编程中最基本的结构是 Grid、Block、Thread。一个 Kernel 启动时，会生成大量线程，这些线程按照 block 和 grid 组织。线程通过索引计算自己负责的数据位置，然后并行执行。

但能跑不等于跑得快。高性能 CUDA 需要考虑：

• 全局内存访问是否连续
• 是否充分利用 shared memory
• 是否减少重复访存
• 是否避免 warp divergence
• 是否提高 occupancy
• 是否使用向量化加载
• 是否使用 Tensor Core
• 是否需要算子融合

这就是算子优化的核心。

第三层：训练系统

训练系统要解决的问题是：模型太大、数据太多、单卡太慢，如何让多卡甚至多机高效协同。

常见训练并行策略包括：

数据并行：每张卡持有完整模型，处理不同数据，反向传播后同步梯度。优点是简单，缺点是每张卡都要放完整模型，模型太大时不适用。

张量并行：把单层中的大矩阵切分到多张卡上。例如线性层的权重矩阵可以按列或按行切分，每张卡计算一部分结果，再通过通信合并。它适合单层参数量很大的模型。

流水线并行：把模型按层切成多个 stage，不同 GPU 负责不同层。数据像流水线一样前向传播和反向传播。它适合层数很多、模型很深的情况。

ZeRO / FSDP：把优化器状态、梯度、参数切分到不同设备上，减少每张卡的冗余存储。ZeRO-1 切优化器状态，ZeRO-2 进一步切梯度，ZeRO-3 连参数也切分。

真实大模型训练往往不是单一并行策略，而是 3D 并行：数据并行、张量并行和流水线并行组合使用，再叠加 ZeRO、activation checkpointing、混合精度训练等显存优化手段。

训练系统的难点在于，它不仅是“把模型切开”，还要平衡：

• 显存占用
• 通信开销
• 计算效率
• pipeline bubble
• 负载均衡
• 容错恢复
• checkpoint 保存和加载
• 集群调度

第四层：推理系统

推理系统关心的是模型上线后的服务效率。

训练阶段往往追求整体吞吐，推理阶段则同时关心吞吐和延迟。对于用户来说，首 token 延迟、流式输出速度、请求稳定性都很重要。

LLM 推理可以分成两个阶段：

Prefill 阶段：处理用户输入 prompt，计算上下文的 KV Cache。这个阶段通常计算密集，可以较好地并行。

Decode 阶段：一个 token 一个 token 地生成。每一步都要读取历史 KV Cache，计算当前 token。这个阶段通常更容易受内存带宽、调度和 KV Cache 管理影响。

推理系统里的关键技术包括：

• KV Cache
• PagedAttention
• Continuous Batching
• Prefix Caching
• Chunked Prefill
• Speculative Decoding
• Quantization
• Tensor Parallel Inference
• 多模型调度
• 请求队列和优先级控制

以 KV Cache 为例，它的思想很简单：自回归生成时，历史 token 的 Key 和 Value 不需要重复计算，可以缓存起来。这样每一步 decode 只计算新 token 的 QKV，并复用过去的 K/V。

但 KV Cache 会占用大量显存，并且随着 batch size、上下文长度、层数、head 数增长而增长。因此推理系统必须非常重视 KV Cache 的分配和复用。

PagedAttention 的出现，就是为了解决传统 KV Cache 连续分配导致的显存浪费问题。它借鉴操作系统分页思想，把 KV Cache 切成固定大小的 block，按需分配和管理，从而提升显存利用率。

第五层：性能工程

性能工程贯穿训练和推理全流程。它不是简单地“调参数”，而是建立一套定位瓶颈、解释瓶颈、验证优化的系统方法。

常见工具包括：

• Nsight Systems
• Nsight Compute
• PyTorch Profiler
• NVIDIA SMI
• CUPTI
• Triton profiler
• benchmark scripts

性能分析常见问题包括：

• GPU 利用率低，是计算不足还是 CPU 调度慢？
• Kernel 时间长，是访存瓶颈还是计算瓶颈？
• 多卡训练慢，是通信瓶颈还是负载不均？
• 推理吞吐低，是 batch 策略问题还是 KV Cache 管理问题？
• 延迟抖动大，是请求队列、动态 shape、内存碎片还是调度问题？

一个重要思维工具是 Roofline 模型。它用算术强度来判断一个算子更可能受限于计算还是访存。算术强度可以理解为每读取或写入一个字节数据，能做多少浮点运算。

如果算术强度低，说明大量时间花在搬数据上，优化重点应该是减少访存、提高缓存命中、做算子融合、合并访存等。如果算术强度高，说明更可能是计算瓶颈，优化重点可能是 Tensor Core、并行度、指令调度和矩阵分块。

---

四、为什么 CUDA 和算子优化很重要

很多人刚接触 AI Infra，会觉得 CUDA 离自己很远。但只要深入一点就会发现，CUDA 和算子优化是 AI Infra 的硬核基础之一。

深度学习框架的上层 API 很简单，比如一个线性层、一层 Attention、一个 Softmax。但真正运行时，这些操作都会落到具体 kernel 上。kernel 的性能，直接决定训练和推理效率。

以 GEMM 为例，几乎所有大模型模块都离不开矩阵乘法：

• Attention 中 Q、K、V 投影是 GEMM
• Attention 输出投影是 GEMM
• FFN 中升维和降维是 GEMM
• LM Head 通常也是大矩阵乘法

GEMM 优化的核心是数据复用。朴素矩阵乘法会反复从全局内存读取相同数据，浪费带宽。高性能 GEMM 会使用 tiling，把矩阵切成块，加载到 shared memory 或寄存器中，尽可能让一次读取服务更多计算。

典型优化路径包括：

1. 朴素实现，建立 baseline
2. block 级 tiling，减少全局内存访问
3. thread 级 tiling，提升每个线程计算量
4. warp 级 tiling，贴合硬件执行方式
5. 向量化访存，提高加载效率
6. 避免 bank conflict
7. 双缓冲，让加载和计算重叠
8. 使用 Tensor Core
9. 指令级调度和寄存器优化

Softmax 也是一个典型例子。它看起来只是一个简单函数，但在大模型中经常出现在 Attention 里，性能和数值稳定性都很重要。

普通 Softmax 需要先找最大值，再计算指数和，再归一化。为了数值稳定，通常会减去最大值。Online Softmax 进一步把多遍扫描转成可以在线更新的形式，是理解 FlashAttention 的基础。

Attention 优化更复杂。传统 Attention 需要显式计算 QK^T，再做 Softmax，再乘 V。中间的 attention matrix 可能非常大，尤其是长上下文时会带来巨大显存压力。FlashAttention 的关键思想是分块计算，不把完整 attention matrix 写回 HBM，而是在片上存储中完成局部计算和在线归一化，从而显著减少 IO。

这说明 AI Infra 中的很多优化，本质不是“数学公式变了”，而是“同样的数学计算，用更适合硬件的方式执行”。

---

五、分布式训练：让大模型训得起来

分布式训练的起点很简单：单卡放不下，单卡太慢。

但真正实现高效分布式训练并不简单，因为你要同时处理计算、通信、显存和调度。

数据并行

数据并行是最容易理解的方式。每张 GPU 有一份完整模型，各自处理不同 batch。反向传播后，各卡得到不同梯度，需要通过 AllReduce 同步，保证模型参数一致。

它的优点是实现简单，扩展直观。缺点是每张卡都保存完整模型、梯度和优化器状态，当模型太大时，显存会成为问题。

FSDP 和 ZeRO

FSDP 和 ZeRO 的核心思想是减少冗余。既然每张卡都保存完整优化器状态很浪费，那就把状态切分到不同卡上。需要时再通过通信聚合，用完释放。

ZeRO 的三个阶段可以粗略理解为：

• ZeRO-1：切分优化器状态
• ZeRO-2：切分优化器状态和梯度
• ZeRO-3：连参数也切分

FSDP 与 ZeRO-3 类似，也会对参数进行分片，在前向和反向过程中按需 gather 参数。

这类方法用通信换显存。显存省了，但通信变多了。因此实际使用时要考虑模型规模、网络带宽、batch size 和训练吞吐。

张量并行

张量并行关注的是单层内部切分。对于大模型来说，单个矩阵可能非常大。可以把权重矩阵按列或按行切开，让多张卡共同完成一次矩阵乘法。

张量并行的优点是可以解决单层太大的问题，缺点是通信频繁，对网络要求较高。

流水线并行

流水线并行把模型按层切分，不同 GPU 负责不同层。它的挑战是 pipeline bubble，也就是某些设备在等待其他设备，不能一直满负荷工作。

为了减少 bubble，可以使用 micro-batch，把一个 batch 拆成多个小批次，让流水线尽可能持续运转。

混合并行

真实训练大模型时，通常会同时使用数据并行、张量并行、流水线并行和 ZeRO/FSDP。问题不再是“用哪一种”，而是如何组合。

组合策略取决于：

• 模型参数量
• 层数和 hidden size
• GPU 数量
• 单卡显存
• 节点内互联和节点间网络
• batch size
• 训练稳定性要求

这也是分布式训练工程师的价值所在：不是会调用一个框架，而是能理解背后的 trade-off。

---

六、推理优化：大模型产品化的关键战场

如果说训练系统解决“模型如何被训练出来”，推理系统解决的就是“模型如何被大量用户便宜、稳定、快速地使用”。

LLM 推理有几个显著特点。

第一，输入输出长度变化大。不同用户 prompt 长度不同，输出长度也不同。静态 batch 很难高效利用 GPU。

第二，decode 阶段串行。每个 token 都依赖前一个 token，不能像训练那样完全并行。

第三，KV Cache 占用显存。上下文越长、batch 越大，KV Cache 越大。

第四，在线服务有延迟要求。用户不会只关心吞吐，也会关心响应速度。

因此推理优化通常围绕几个方向展开。

1. Batching

传统 batching 要等一批请求凑齐再一起执行，但 LLM 请求长度不同，简单 batching 会导致短请求等待长请求。Continuous Batching 允许请求动态加入和退出 batch，让 GPU 更持续地工作。

2. KV Cache 管理

KV Cache 是推理系统的核心资产。它既能减少重复计算，也会占用大量显存。PagedAttention、block manager、prefix cache 等技术，本质都是围绕 KV Cache 做更高效的管理。

3. 量化

量化通过降低权重或激活精度来减少显存和计算成本。常见有 INT8、INT4、FP8、GPTQ、AWQ、SmoothQuant 等方法。

量化的关键是平衡效果和性能。不是精度越低越好，而是要看模型质量是否可接受、硬件是否支持高效低精度计算、端到端吞吐是否真的提升。

4. Speculative Decoding

Speculative Decoding 的思想是用一个小模型先猜多个 token，再让大模型验证。如果猜对了，就能一次接受多个 token，从而减少大模型调用次数。

它的收益取决于小模型速度、猜测准确率和验证开销。不是所有场景都一定收益明显，但它是当前推理加速的重要方向。

5. Prefill / Decode 解耦

Prefill 和 Decode 的计算特征不同。Prefill 更像大矩阵计算，Decode 更受 KV Cache 读取和小 batch 影响。将两者解耦部署，可以让不同硬件资源处理不同阶段，提高整体效率。

---

七、AI Infra 工程师应该具备什么能力

AI Infra 是一个交叉领域，能力模型可以分成几块。

1. 编程基础

C++、Python、Linux 是基本功。C++ 用于高性能系统和底层模块，Python 用于模型、训练脚本和工具链，Linux 用于部署、调试、性能分析和集群环境。

需要掌握：

• C++ 内存管理、并发、模板基础
• Python 深度学习生态
• Linux 进程、线程、文件系统、网络基础
• Shell 脚本和常用调试工具

2. 深度学习基础

AI Infra 不需要你成为模型结构发明者，但必须理解模型的计算图。

至少要理解：

• Transformer
• Attention
• FFN
• LayerNorm / RMSNorm
• Embedding
• Tokenization
• 自回归生成
• KV Cache
• MoE 基本原理

因为你优化的不是抽象代码，而是这些结构对应的计算和数据流。

3. GPU 和 CUDA

CUDA 是很多 AI Infra 岗位的硬通货。即使不做极致 kernel 优化，理解 CUDA 也能帮助你判断性能瓶颈。

建议学习：

• 线程模型
• 内存模型
• warp 执行
• shared memory
• coalesced memory access
• occupancy
• stream 和异步执行
• 原子操作和同步
• GEMM / Reduce / Softmax 基础优化

4. 分布式系统

训练和推理都离不开分布式。

需要理解：

• collective communication
• AllReduce / AllGather / ReduceScatter
• NCCL
• 数据并行、张量并行、流水线并行
• ZeRO / FSDP
• 多机多卡训练配置
• 网络带宽和拓扑对性能的影响

5. 推理服务

推理服务越来越重要，尤其是大模型应用落地后。

需要理解：

• vLLM / SGLang / TensorRT-LLM
• KV Cache
• PagedAttention
• batching 和调度
• 量化
• 模型加载和权重格式
• 延迟和吞吐指标
• 服务监控和稳定性

6. 性能分析

性能分析是把经验变成工程方法的关键。

需要掌握：

• 如何设计 benchmark
• 如何区分端到端耗时和 kernel 耗时
• 如何看 GPU 利用率
• 如何分析显存带宽
• 如何定位通信瓶颈
• 如何判断优化是否真实有效

---

八、AI Infra 学习路线建议

如果从零开始，建议不要一上来就啃最难的 CUDA 或 Megatron 源码。更合理的路线是逐层建立认知。

第一阶段：建立大模型计算图认知

先弄懂 Transformer 的基本结构：

• Self-Attention
• Multi-Head Attention
• FFN
• LayerNorm / RMSNorm
• 残差连接
• Position Encoding / RoPE
• 自回归生成
• KV Cache

目标不是推导每个细节，而是知道每个模块对应什么计算、什么张量形状、主要消耗在哪里。

第二阶段：掌握 PyTorch 和训练基础

理解 PyTorch 的 tensor、autograd、module、optimizer、dataloader。能写一个简单训练 loop，知道前向、loss、反向、optimizer step 的流程。

然后学习混合精度、梯度累积、checkpointing、DDP 基础。

第三阶段：学习 GPU 和 CUDA

从最简单的 vector add 开始，逐步写 reduce、matrix transpose、softmax、GEMM 的简化版本。重点不是一开始就追 cuBLAS，而是理解性能为什么变化。

每写一个 kernel，都问自己：

• 访存是否连续
• 每个线程做多少工作
• 是否有分支发散
• shared memory 是否合理
• occupancy 是否足够
• 算子是计算瓶颈还是访存瓶颈

第四阶段：学习分布式训练

先理解 DDP，再理解 FSDP/ZeRO，然后看 Megatron 的张量并行和流水线并行。

可以从小规模实验开始，比如 2 卡 DDP，观察梯度同步；再尝试 FSDP，观察显存变化；再读一些 Megatron 的并行策略设计。

第五阶段：学习推理系统

从 vLLM 入手比较友好。理解它为什么需要 PagedAttention，如何做 continuous batching，KV Cache 如何管理。

然后再看 SGLang、TensorRT-LLM、量化和 speculative decoding。

第六阶段：学习性能分析

不要只看理论，一定要动手 profile。哪怕是一个简单矩阵乘法，也可以用 Nsight 或 PyTorch Profiler 看时间花在哪里。

性能优化最重要的是闭环：

1. 先测 baseline
2. 提出假设
3. 修改实现
4. 再测结果
5. 解释变化

没有数据的优化，很容易变成玄学。

---

九、求职和面试应该怎么准备

AI Infra 面试通常有几个高频方向。

1. 项目深挖

面试官会追问你做过的训练、推理、部署或优化项目。重点不是项目名字多大，而是你能不能讲清楚：

• 背景是什么
• 瓶颈是什么
• 你怎么定位
• 做了什么优化
• 指标提升多少
• 有没有 trade-off
• 如果重做会怎么改

2. CUDA 和性能优化

常见问题包括：

• CUDA 线程模型
• warp 是什么
• shared memory 有什么用
• coalesced access 是什么
• occupancy 如何理解
• reduce 如何优化
• softmax 如何实现
• GEMM 为什么要 tiling
• FlashAttention 为什么快

3. 分布式训练

常见问题包括：

• DDP 原理
• AllReduce 过程
• ZeRO 三个阶段
• FSDP 和 DDP 区别
• 张量并行和流水线并行
• 通信瓶颈如何定位
• activation checkpointing 为什么省显存

4. 推理优化

常见问题包括：

• Prefill 和 Decode 区别
• KV Cache 显存如何计算
• PagedAttention 原理
• Continuous Batching 为什么有效
• 量化方法有哪些
• TensorRT-LLM / vLLM 的特点
• 长上下文推理有什么挑战

5. 系统设计

更偏工程的岗位可能会问：

• 如何设计一个 LLM serving 系统
• 如何支持多模型部署
• 如何做请求调度
• 如何处理超长 prompt
• 如何监控 GPU 服务
• 如何做限流、降级和容错

面试准备时，不要只背答案。AI Infra 面试很容易被连续追问，一旦只背概念，很快会露馅。更好的方式是建立因果链：

为什么需要这个技术？它解决什么问题？代价是什么？适合什么场景？不适合什么场景？如何验证它有效？

---

十、AI Infra 的长期价值

AI Infra 之所以值得学习，不只是因为它现在热门，而是因为它处在算法、系统、硬件和产品之间的交汇处。

模型会变，框架会变，硬件会变，但几个核心问题会长期存在：

• 如何更高效地利用算力
• 如何降低训练和推理成本
• 如何让模型稳定服务真实用户
• 如何在硬件约束下实现算法能力
• 如何把实验室模型变成生产系统

从这个角度看，AI Infra 不是某一个短期风口，而是一类长期工程能力。

对于个人成长来说，学习 AI Infra 有几个好处。

第一，它能让你理解大模型背后的真实成本。你不会只停留在“模型效果很好”的层面，而是能看见一次请求背后消耗了多少显存、多少算力、多少带宽。

第二，它能让你具备更强的问题定位能力。当模型训练慢、推理慢、显存爆、吞吐低时，你知道应该从哪里查，而不是只会换参数。

第三，它能让你跨越算法和工程之间的断层。很多大模型应用最终拼的不是 demo，而是稳定性、延迟、成本和规模化能力。

第四，它能提升职业壁垒。AI Infra 的学习曲线更陡，但也因此更难被简单替代。

---

结语

AI Infra 可以很难，也可以很有意思。

难在它横跨太多层：模型结构、GPU 架构、CUDA 编程、分布式系统、推理服务、性能分析、线上稳定性。任何一层深入下去，都有大量细节。

有意思也在这里。它不是纯粹纸面上的理论，而是非常工程化、非常可验证的领域。你做了一个优化，吞吐会不会提高，显存会不会下降，延迟会不会减少，profile 结果会直接告诉你答案。

如果你正在学习大模型，不妨在关注算法和应用之外，给 AI Infra 留出一部分时间。理解它之后，你会更清楚地看到：大模型真正落地，不只是模型会“思考”，还要系统能“承载”。

未来的大模型竞争，不只是谁的模型更聪明，也是谁能以更低成本、更高效率、更稳定的方式把智能交付给用户。

而这，正是 AI Infra 的价值所在。