关于传统 infra 和 AI Infra 的差异。总结来说就是觉得这套东西和传统 Infra 差太远了。很多熟悉网络，计算，存储等传统infra的工程师，会觉得自己原来的经验在 AI 场景里难以直接利用，尤其是看到 GPU，KV Cache，3D parallelism 这些新概念时，容易产生一种感觉完全换了一套体系的落差感。

我个人感觉这些看法其实挺有代表性的，反映出很多工程师对 AI Infra 的第一印象：陌生，高门槛，甚至有些割裂感。本文就想聊聊我的一些粗浅的理解。AI Infra 真的是和传统 Infra 差异很大的新体系吗，还是说它其实是过去 Infra 经验的演化？（首先声明一下，本文仅代表我个人观点。如有错误，请大伙多多指出！）

我的答案是：差异其实不大。AI Infra 是对传统 Infra 在新场景下的重构与延展。

传统 Infra 处理的是 web request，数据存储，和分布式服务协调，而 AI Infra（特别是大模型）更多围绕的是 GPU 推理，KV Cache 管理，以及大模型训练框架等全新领域。

请求形态也不一样：web request通常是毫秒级的request，stateless，而 LLM 推理一个 session 往往持续数秒甚至更久(随着context window 和模型大小增加），还要动态维护 token-level 的上下文状态。

tech stack 看起来也不同：传统用的是 Kubernetes + Docker，现在大家在用 GPU, vLLM, DeepSpeed, FlashAttention, Triton, NCCL 这些仅仅从名字上听起来就很高大上的架构。

从这点来看，说传统经验无法直接迁移，确实没错。但这只是表面的现象，不是本质。

回到工程本身，其实我们仍然在面对和传统 Infra 极其类似的问题：

• • 如何调度资源（从CPU/内存 变成了 GPU 显存）
• • 如何处理高并发请求（从http resource request ，变成了 prompt request）

我们来看一组对比：

这些机制其实都是传统 Infra 思维方式在 AI 场景中的利用。

拿 vLLM 举个例子：

它像是给 LLM 写了一个操作系统，用来调度“页面”（KV Cache），管理“进程”（requests), 本质上是引用了OS 的内存管理principles用来管理 kv cache。

所有系统的底层挑战，基本都绕不开这三个关键词：

Scaling（扩展）：系统如何支持更大的规模和更高的并发？

在传统 Infra 中，这意味着如何横向扩展服务器，部署更多容器，使用负载均衡 (load balancing) 来分散请求

在 AI Infra 中，这些问题转化为如何通过 数据并行， 模型并行，流水线并行 来分布和执行 GPU workload，以支持超大模型的训练以及 large number of inference requests

Sharding（切片）：系统如何切分状态和计算，以实现并行处理？

在数据库系统中，这是将数据按照主键或范围切分到不同的分区，以支持高吞吐访问

在 AI Infra 中，sharding 变成了对模型参数，KV Cache，activation，gradients，以及optimizer states的split，比如tensor parallelism和KV paging等，是实现分布式推理和训练的前提

Copying（复制）：系统如何高效同步数据或状态？

传统系统中，复制体现在数据库副本同步或者缓存预热，以及Kafka Replication

在 AI Infra 中，复制的代价更加显著，比如data parallelism 怎么copy model to different GPUs（所以会有ZeRO optimization 来shard 参数，gradient 等等），通常需要依赖高性能通信机制（比如 RDMA和NCCL）

这些挑战的本质没有变：仍然是如何高效并且低成本地协调跨不同机器的资源。但在 AI Infra 中，由于gpu显存limited，large context window，以及模型参数量大，它们变得更加脆弱和重要，也更需要更好的工程策略去解决这些问题。

Google 的 Jeff Dean 曾整理出一份广为流传的延迟参考 Key Numbers Every Programmer Should Know。这些数据强调：在设计基础设施时，需要通过 estimate latency 来部署基础system。

深入理解这些延迟数据，能让你在系统设计时更加aware 真正的bottleneck 是什么，这样也能在部署后迅速找到性能bottleneck，然后及时修复。

延迟参考值

这些数值会随硬件不同而略有不同，但是相对的数量级非常值得记住，是做系统设计时最基本的参考。

在 AI Infra 中的mapping

• • Token-level KV Cache：GPU 全局显存访问
• • 多个 GPU 通信：通过 NCCL/RDMA 进行同步
• • 跨机（cross server）通信：比如在多个 server 之间调度推理任务

为什么记住这些数字/运用这些数字做估算很重要？

事前估算：训练一个模型需要多少时间，推理吞吐量，token latency 都应基于这些latency numbers进行初步估计

事后诊断：部署之后，如果性能不是很好，理解这些延迟能帮助你快速定位瓶颈究竟在哪里（是communication，memory bandwidth，or compute bound？）

案例参考：据说 Meta 在训练 LLaMA 系列模型时，GPU 报错或任务失败每几十分钟就会发生一次。因此，高质量的 log, error tracing, 和 profiling 工具，对 LLM training Infra 稳定性至关重要。

真正有经验的 Infra 工程师，不仅仅是能搭件一个working的系统，而是有能力去从头到尾追踪每一个延迟点，把系统之间的关联和可能存在的bottleneck拆解成一系列可量化的问题，并在上线后持续做 cost/performance profiling。这正是 AI Infra （或者传统 Infra）对工程基本功要求极高的原因。

感觉现在有很多讨论AI Infra，并且有点把它过度“神化”了。

是的，LLM 的发展带来了新形态，新需求，和新的资源瓶颈（主要是GPU memory 和 communication bottleneck，GPU 本身设计就是算力非常强，因为有非常多的cores）。但是，解决这些问题的工程本质从来没有变：系统的目标仍然是优化资源利用 （降低成本），保障service的稳定性，提升吞吐量以及响应能力。

而这些问题，在传统 Infra 中我们已经解决过很多次了。只不过这次，我们需要重新设计整个框架，让它在 GPU 上，高并发 LLM 请求下，仍然能够跑得快，跑得稳。

AI Infra 的门槛确实高，但是它的高门槛不在于你熟不熟悉神经网络，而在于你能不能把已有的工程能力（system design thinking and implementation skills）转化为新的问题的视角。

如果你做过网络通信：你会发现 NCCL 的 ring topology 其实跟设计高性能集群异构调度非常像

如果你知道缓存以及os paging，你会非常快地理解 KV Cache 的重要性以及管理思路

如果你写过服务调度器，那 dynamic batching会让你产生一种这是流水线并发的熟悉感

我越来越觉得，AI Infra 是对传统 Infra 知识体系的一种融合以及拓展，是一些旧的问题在新的范式中的rephrasing。

真正有竞争力的 ai Infra 工程师，不是只懂如何调个prompt或者跑个inference/finetuning，而是能把底层系统逻辑与模型特性融合起来的人。

这种shift of thinking 并不容易，但如果你愿意去搭建起传统 infra → AI infra 的 mental map，会发现很多传统经验看起来和AI 毫不相干的东西，其实都有非常相似的部分（俗话说，换汤不换药）。所以，传统infra 的经验同样适用于ai infra，它们两之间有很多关联。

欢迎大家留言讨论！