入局AI基础设施：程序员必须了解的系统设计与挑战知识

AI Infra 正重塑技术格局，传统程序员如何快速转型？本文揭秘 AI 系统设计的核心挑战与实战经验。

核心内容：
1. AI Infra 与传统 Infra 的硬件架构差异
2. GPU 计算革命带来的系统设计范式转变
3. 千亿参数大模型训练中的实战经验总结

AI Infra 和传统 Infra 到底有什么本质区别？程序员好不容易积累下来的技术栈和方法论，还能不能复用到 AI 系统架构设计上？

大模型技术爆发之后，AI Infra 已经成为基础设施领域绕不开的核心战场。过去一年多，基础架构算法工程团队落地了多个大模型应用——语音合成、内容理解多模态、生成式推荐，把大模型从训练到推理的全链路跑通了。踩坑无数，但也攒下不少经验。这篇文章就来聊聊传统后台工程师积累的那些技术和方法论，怎么延续和迁移到 AI 系统里，同时系统性拆解 AI Infra 在硬件、软件、训练和推理几个维度上的挑战。

1

硬件演进

经济基础决定上层建筑——软件层面的架构设计，永远脱离不了硬件约束。所以，了解现代 AI 硬件特性是必须要补的一课。

1.1 从CPU为中心到GPU为中心

传统基础设施以 CPU 为核心，通过多线程和微服务构建分布式系统，处理高并发请求（比如 Web 服务）。这些方面已经有一套成熟的方法论了（像"海量服务之道"）。主要处理的是逻辑事务，瓶颈通常卡在网络 I/O 和 CPU 核心数量上。发展到现在，硬件其实很少成为 CPU 系统设计的制约了。

而 AI Infra 的核心是 GPU，设计目标从逻辑事务处理转向了高吞吐浮点计算。这时候，CPU 多线程被 GPU 并行计算替代，内存被显存替代。举个例子，H20 单卡 96GB 显存，可以提供 44TFlops 的单精度浮点运算，算力和访存带宽是主流 CPU 的几十倍甚至几百倍。每台机器装 8 卡就是 768GB 显存，另外还有 CPU 192核384线程 + 2.3TB 内存。

为什么 GPU 成了主角？因为 LLM 大模型每生成一个 token，都需要把全量模型参数读一遍。传统的 CPU + 内存的算力和带宽根本扛不住这么恐怖的计算密度，计算和通信必须全部转移到 GPU 内部完成。CPU 退化成了数据搬运工和"辅助处理器"。

为了更直观地理解这个计算密度，我们直接算一笔账：不考虑计算延时，LLM 大模型生成一个 token 的耗时公式为

以 DeepSeek-R1-671B-A37B-FP8 模型为例，计算一个 token 耗时，H20 是 37B × 1byte ÷ 4000GB/s = 9ms，换到 CPU 则是 37B × 1byte ÷ 64GB/s = 578ms——差距一目了然。

1.2 从"去IOE"到"AI大型机"

很明显，我们正身处新一轮烈火烹油的硬件革命进程中，各种专用硬件、专用网络层出不穷。DeepSeek-R1 和 QWen3-235B 这些千亿级参数模型，训练时需要千卡 GPU 集群协同，通过专用网络互联构建"AI超算"，它的设计逻辑和当年的 IBM 大型机惊人地相似——用硬件集中化换取极致性能和可靠性。

传统 Infra 的分布式理念在这个时代好像失灵了。传统后台追求横向扩展，而 AI Infra 反而呈现出"AI 大型机"的特性。原因在于：传统服务可以容忍毫秒级延迟，但 AI 集群不行——GPU 的算力是 CPU 的几百倍，微秒级的等待都会造成巨大算力损耗，所以必须硬件高度集成。可以预见，未来 1-3 年，这种专用硬件+网络的集中式架构很难有太大改变。

回头看历史，我们总在寻求科技平权。之前推动"去IOE"（IBM小型机、Oracle数据库、EMC存储），用分布式廉价 x86 PC 机替代集中式高端硬件，本质上是靠软件创新重构高可用+低成本的互联网基础设施。"AI大型机"是技术发展的必经之路，但绝不是终极形态。长期（比如5年）来看，必然会出现"AI 去 NVIDIA 化"，重演"去 IOE"的历史逻辑。

2

软件演进

说完硬件体系的革命，再来看看软件层面的变化。

跟传统后台应用的增删查改不同，AI 应用的新范式是模型训练和推理。训练就是通过海量数据拟合出一个复杂的神经网络模型，推理则是利用训练好的模型进行运算，输入新数据得到新结论。

举个简单的例子：训练是根据<年龄, 身高>的分布，用最小二乘法拟合模型 y = ax + b；推理就是利用这个模型，输入一个新年龄来预测身高。

2.1 深度学习框架

工欲善其事，必先利其器。传统后台应用依赖 tRPC 或 Spring 等微服务框架，帮我们屏蔽负载均衡、网络通信这些底层细节，让我们把精力放在业务实现上。

AI 应用也有类似的工具——深度学习框架。没有它，我们可能得陷在茫茫数学深渊里，挣扎在痛苦的 GPU 编程泥潭中。有了深度学习框架，才能把全部精力花在模型设计和创新上，而不用关心底层实现细节，极大降低了 AI 应用的门槛。

大家可能听说过 TensorFlow、PyTorch 这些框架。现在是 2025 年，不用纠结选哪个——PyTorch 就是 AI 模型训练和推理的事实标准。开源模型和代码几乎都是 PyTorch 一边倒。

得益于动态计算图、自动微分和丰富的 Tensor 操作算子，PyTorch 能快速帮我们实现模型设计。只需要描述模型结构+待学习的网络参数，完全不用关心数学计算和 GPU 编程的细节。

2.2 GPU 编程

绝大多数 AI 应用确实不需要我们手写数学计算的 GPU 代码。但如果有模型创新的需求，学习 GPU 编程就很有必要了。比如 Meta 发布的 HSTU 生成式推荐模型，核心的 hstu_attn 计算如果用 PyTorch 框架算子组合实现，时间复杂度是 O(M * N²)，M 和 N 同一数量级，相当于 O(N³)。但通过自定义内核可以优化到 O(N²)。

在 GPU 核心上运行的代码片段叫内核（kernel）。编写高性能的 CUDA 内核需要丰富经验，学习曲线很陡。原因在于我们习惯了传统 CPU 编程的串行计算思维，通过多线程提高并发；而 GPU 采用 SIMT 架构，有大量计算单元和数万个线程，但分组后的线程同一时刻只能执行相同的指令——这和传统 CPU 的串行思维、不同线程处理不同任务的方式存在根本冲突，所以 GPU 编程学习难度大。

现在推荐用 Triton 编程语言来完成 GPU kernel 开发。它提供类似 Python 的语法，无需深入理解 GPU 硬件细节（比如线程调度、共享内存管理），而且和 PyTorch 深度学习框架的生态结合更好。推荐 Triton-Puzzles-Lite 这个项目作为入门学习材料。

2.3 Python 编程

就像客户端开发离不开 Kotlin/Objective-C，AI Infra 的第一编程语言就是 Python。PyTorch 深度学习框架的设计哲学强调 Python 优先。

以前大部分模型可以轻松导出 ONNX、TorchScript 等用 C++ 部署，但现在对模型的细粒度优化和控制越来越多——比如 KV Cache、MoE/模型并行、复杂的 if/for 控制流、自定义 Triton 算子等——模型越来越难脱离 Python 的控制进行部署。不少开发者也从" C++ Boy"变成了"Python Boy"。

3

模型训练的挑战

我们一直在追求更大的模型。DeepSeek-R1 有数千亿参数，用了数十万亿 token 的训练数据，涉及算力、存储、通信等多维度的工程挑战。有了 PyTorch 深度学习框架，只是 AI 应用落地的万&里长征第一步。接下来聊聊深度学习框架之上，模型训练到底会碰到哪些硬骨头。

3.1 存得下

DeepSeek-R1 模型大小 = 670GB，一台 GPU 服务器有 8 张 H20 卡，总共 768GB 显存，单机似乎放得下一个完整的模型。那为什么整个行业还要投入大量人力物力，顶着通信延时造成的算力损耗，去建设分布式 GPU 集群？核心原因是单台 GPU 服务器"存不下"。

3.1.1 显存刺客：中间激活

看下面的模型示意图，x1/x2/x3/x4 这些中间变量就是"中间激活"。它们是神经网络前向传播的"堆栈帧"——记录每一层处理后的数据快照，确保反向传播时可以回溯梯度，根据预测误差调整模型权重，最小化损失函数。

这些中间激活为什么成了"显存刺客"？因为它的空间复杂度和输入数据长度正相关，尤其对于 LLM 来说是 O(N²)——正比于输入数据长度的平方，这是一个指数爆炸式的增长。就像函数递归中不断增长的"堆栈帧"导致内存溢出一样，我们遇到了 AI Infra 的 OOM（Out of Memory）挑战。

借助 PyTorch 的 profiler 工具，能直观地看到这个 OOM。下图展示了训练过程中不同阶段的显存分配：模型参数、优化器状态、中间激活、梯度。前向传播结束后，显存占用（中间激活）会出现一个尖峰，远大于模型参数本身。

3.1.2 模型并行

传统后台服务用分片（Sharding）策略解决单机存不下的问题。AI Infra 也有类似思路——"模型并行"，就是把单个大模型拆成多个子模块，分布到不同 GPU 上协同工作，通过通信来共享数据。拆分策略有好几种：按模型模块划分、按张量划分，或者混合使用。PyTorch 深度学习框架和开源方案 Megatron 都能帮助我们高效地实现模型并行。

3.2 算得快

建设分布式 GPU 集群，一方面是因为单机存不下，另一方面是为了提升训练速度。但简单堆叠机器，算力不一定线性增长。因为分布式训练不是简单地把一个 GPU 的任务分给多个 GPU 各自做——需要协调多个 GPU 机器的计算任务分配，GPU 之间的数据传输会引入网络 IO 和通信开销，反而可能拖慢训练速度。

3.2.1 通信计算重叠

常规训练时序是串联式的，存在很多网络 IO，GPU 利用率低，训练速度慢。我们当然希望 GPU 大部分时间都在计算，而不是花在数据传输或等待其他 GPU 上。

传统后台服务通过多线程或异步 IO 避免阻塞 CPU 主线程；AI Infra 也提出了类似方法论——通信计算重叠。GPU 编程模型中有流（stream）的概念，一个流表示一个 GPU 操作队列，操作按入队顺序依次执行。不同流之间可以并行执行。所以，让计算和通信操作分别加入不同的流，就能做到两者在时间上重叠。比如 TorchRec 的训练流水线就能帮我们实现高效的通信计算重叠。

4

模型推理的挑战

AI 模型训练成本很高——哪怕 DeepSeek 优秀如斯，也要烧掉 500 万美金。但再贵也是一次性的。模型推理的成本反而更高，因为用户越多，推理次数越多，总成本就越高。模型推理面临的挑战和传统 Infra 非常相似，主要是两个：高吞吐（降本）和低延迟（增效）。

4.1 降低延时

现在的 AI 模型越来越多地直面终端用户，需要实时交互——比如文本对话和语音合成。模型推理耗时过高，直接伤害用户体验，导致用户流失和转化率下降。

传统后台服务我们使用连接复用、缓存、柔性等技术来降低响应时间。AI Infra 也有类似的做法。

4.1.1 CUDA Graph

在 GPU 编程模型中，CPU 和 GPU 是异构的。CPU 通过 API（比如 CUDA API）向 GPU 提交任务，然后异步等待计算结果返回。GPU 收到任务后，会执行内核启动、内存拷贝、计算等操作。这个过程中，CPU 与 GPU 之间的通信、驱动程序的处理以及 GPU 任务的调度，都会产生一定的延迟。模型推理需要大量重复的 GPU 操作，每个操作都要重复上述环节，这些非核心的开销会被成倍放大，最终影响响应时间。

传统后台里，我们用 Redis 的 Lua 脚本封装多个操作和计算逻辑，一次提交，减少网络开销。AI Infra 则利用 CUDA Graph 技术，把多个 GPU 操作转化成一个有向无环图（DAG），一次性提交给 GPU 执行，由 GPU 自己管理依赖关系和执行顺序，从而减少 CPU 和 GPU 之间的交互开销。

4.1.2 KV Cache：空间换时间

LLM 大模型推理存在大量矩阵乘法运算，而且高度依赖上下文信息。每次推理都需要把之前生成过的词重新输入模型进行计算——这种方式让复杂度达到 O(N²)，其中必然有大量重复计算。

比如，给定"天气"，模型逐个预测下一个字，假设接下来两个字是"真好"。将"真"拼接到"天气"后面得到"天气真"，再预测"好"。观察后发现，多次预测中，X @ W_K 和 X @ W_V 的结果上半部分都是相同的——这是 LLM 模型结构的特殊设计导致的。这些重复计算的结果可以缓存下来（即 KV Cache），用空间换时间，大幅减少计算量。几乎所有 LLM 推理框架都支持了 KV Cache，比如 vLLM。

4.1.3 流式响应

有时候模型推理延时实在避免不了，还可以从工程交互上想办法。传统后台服务的 RPC 通信是一问一答方式，不太适合语音合成或文本对话场景。因为大模型推理需要几秒到几十秒，如果等到推理结束才展示结果，用户会等得很痛苦。

流式响应就是当模型推理计算得到第一个 token 或第一个音频帧时，立马展示或播放给用户，后续推理结果在已经建立的 TCP 流上继续顺序传输。工程上不再关注整体耗时，而是关注首 token 或首个音频帧的耗时。几乎所有 LLM 推理框架都支持了流式响应。

4.2 提高吞吐量

提高吞吐量是程序员在传统 Infra 领域孜孜不倦的追求——更高的吞吐量意味着更低的机器成本。实现 AI 应用的高吞吐，本质上就是提高昂贵 GPU 的利用率，让 GPU 在单位时间内完成更多任务。

尽管模型推理需要执行万亿次浮点运算，但 GPU 有大量计算单元，单个请求的模型推理很难让 GPU 利用率达到饱和。提高利用率有两个方法：传统批处理和连续批处理。这里的"传统"是相对"连续"这种新型方式而言的。

4.2.1 传统批处理

其实传统后台服务也大量使用批处理——比如 Redis 的 MGet 命令，一次请求完成所有 key 的获取，把 N 次网络往返压缩为 1 次。模型推理的批处理也是类似：多个输入样本打包（batch），把串行的 N 次轻量推理合并为 1 次重量计算，单位时间处理更多请求，提高 GPU 利用率。

"打包输入样本"是个共性需求，大部分推理框架都提供这个功能，比如 Triton Inference Server 的 Batcher。

4.2.2 连续批处理

传统批处理就像"固定班次的公交车"：乘客（请求）必须等发车时间（组建一个 batch），发车后所有乘客同步前进。就算有乘客提前下车（短请求完成），车辆也要等所有乘客到达终点（长请求完成）才能返程接新乘客。传统批处理的问题是 GPU 空闲——要等长请求处理完，不能处理新请求。

这个问题在 LLM 应用领域格外突出。不同用户请求的 Prompt 不同，模型回答的长度差异巨大，如果用传统批处理，GPU 空闲率很高。本质上是个任务调度问题——传统后台服务用工作窃取算法（work stealing）解决线程空闲问题，AI Infra 则提出了"连续批处理"来解决。

连续批处理就像"随时随地拼车的顺风车"：每辆车（GPU）在行程中可随时上/下客。新乘客（请求）直接加入当前空位（空闲计算单元），已完成的乘客立即下车（释放资源）。几乎所有 LLM 推理框架都支持了连续批处理，比如 vLLM 的 Continuous Batching。

5

结语

AI Infra 面临的工程挑战——计算、存储、通信——大部分都是新时代的老问题。在传统 Infra 领域，我们都能找到对应的场景和解决思路。区别只在于战场从 CPU 转移到了 GPU。传统后台工程师积累下的方法论，依然可以无缝衔接到 AI Infra。说到底，技术的底层逻辑没变，变的是计算密度和硬件形态。谁能快速理解这些变化，谁就能在新的基础设施浪潮中占据先机。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：入局AI基础设施：程序员必须了解的系统设计与挑战知识要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题