aboutInfra

AI Infra的定义

Infra 是 Infrastructure（基础设施） 的缩写。

简单来说：

Infra不是直接给用户提供具体功能的业务，而是为上层软件提供运行所需要的基础能力。

例如一个普通网站：

用户
 ↓
前端
 ↓
后端
 ↓
数据库
 ↓
服务器

其中：

• 前端：用户直接使用
• 后端：实现业务逻辑
• 数据库：保存数据
• 服务器：提供计算资源

而服务器、网络、存储、数据库等底层能力，就属于软件系统的：

Infrastructure

---

为什么叫“基础设施”？

可以类比现实世界。

一个城市：

城市
│
├── 道路
├── 电力
├── 自来水
├── 通信网络
└── 物流

这些东西通常不是最终产品。

例如：

用户不是为了“用电网”才去买手机。

但是：

没有电网，手机也很难正常工作。

因此：

基础设施
    ↓
提供底层能力
    ↓
上层系统
    ↓
提供具体业务
    ↓
用户

软件里的Infra也是同样的思想。

---

什么是AI Infra？

AI Infra就是：

为了让AI模型能够训练、部署、运行、扩展和被上层应用稳定使用，而建立的一整套底层计算、存储、网络、调度、模型服务和工程基础设施。

简单理解：

AI Application
      ↓
AI Agent
      ↓
LLM / Model
      ↓
AI Infra
      ↓
GPU / CPU / Network / Storage

因此：

AI Infra解决的不是“模型应该回答什么”，而是“模型如何高效、稳定、低成本地运行起来”。

---

AI系统为什么需要Infra？

一个非常简单的LLM：

用户
 ↓
LLM API
 ↓
回答

看起来非常简单。

但如果真正自己运行一个大型模型，就会出现大量问题：

模型文件放在哪里？
        ↓
GPU够不够？
        ↓
模型怎么加载？
        ↓
多个用户同时请求怎么办？
        ↓
GPU利用率低怎么办？
        ↓
显存不够怎么办？
        ↓
模型怎么扩容？
        ↓
模型怎么更新？
        ↓
请求怎么排队？
        ↓
如何监控？
        ↓
如何降低成本？

这些问题都不是单纯的：

“怎么训练一个模型？”

而是：

“怎么让模型成为一个稳定运行的计算服务？”

这就是AI Infra要解决的问题。

---

AI Infra的位置

可以把整个AI技术栈简单分成：

┌──────────────────────────────┐
│        AI Application        │
│  AI搜索 / AI客服 / AI编程    │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│            Agent             │
│  Planning / Tool / Memory    │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│        Model / LLM           │
│  GPT / Qwen / Llama / ...    │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│          AI Infra            │
│ Serving / Scheduling / Data  │
│ Training / Monitoring / etc. │
└──────────────┬───────────────┘
               ↓
┌──────────────────────────────┐
│     Hardware Infrastructure  │
│ GPU / CPU / Memory / Network │
│ Storage / Data Center        │
└──────────────────────────────┘

越往上越接近用户。

越往下越接近计算机硬件。

---

Infra到底“做什么”？

可以把AI Infra的工作总结成几个核心问题：

1. 算什么？
2. 在哪里算？
3. 怎么更快地算？
4. 怎么让很多人同时算？
5. 怎么少花钱？
6. 出问题怎么知道？
7. 怎么扩容？
8. 怎么保证稳定？

因此AI Infra本质上是在做：

计算资源的管理 + AI计算任务的调度 + 模型运行的优化 + 服务的工程化。

---

AI Infra的核心组成

AI Infra不是一个单独的软件。

它通常包含多个层次。

AI Infra
│
├── Hardware
│   ├── GPU
│   ├── CPU
│   ├── Memory
│   ├── Network
│   └── Storage
│
├── Distributed Computing
│   ├── GPU Cluster
│   ├── Distributed Training
│   └── Distributed Inference
│
├── Model Serving
│   ├── Model Loading
│   ├── Batch
│   ├── Scheduling
│   └── Routing
│
├── Data Infrastructure
│   ├── Dataset
│   ├── Data Pipeline
│   └── Vector Database
│
├── MLOps
│   ├── Training
│   ├── Evaluation
│   ├── Deployment
│   └── Monitoring
│
└── Platform
    ├── Resource Management
    ├── API
    ├── Permission
    └── Observability

---

1. Compute

AI Infra最底层的东西之一就是：

Compute（计算资源）

主要包括：

CPU
GPU
TPU
Memory

传统Web应用：

CPU
 ↓
运行程序

AI应用：

GPU
 ↓
矩阵计算
 ↓
模型推理 / 训练

因为深度学习涉及大量矩阵运算，所以GPU成为AI计算的重要硬件。

---

2. GPU Cluster

如果只有一张GPU：

GPU
 ↓
运行模型

模型规模变大以后，一张GPU可能放不下。

例如：

GPU 1
GPU 2
GPU 3
GPU 4

于是需要：

GPU Cluster

即：

GPU
GPU
GPU
GPU
 ↓
组成计算集群

这时候又产生新的问题：

任务应该放到哪个GPU？

哪个GPU还有显存？

哪个GPU比较空？

多个GPU之间怎么通信？

任务如何调度？

这就是AI Infra的重要工作。

---

3. Scheduling

Scheduling就是：

调度。

例如现在来了三个任务：

Task A
Task B
Task C

服务器有：

GPU 0
GPU 1
GPU 2

调度系统需要决定：

Task A → GPU 0

Task B → GPU 1

Task C → GPU 2

如果GPU不够：

Task A → GPU 0
Task B → GPU 1
Task C → Queue

GPU释放以后：

GPU 2
 ↓
Task C

因此：

Scheduling决定“谁什么时候用什么计算资源”。

---

4. Model Serving

训练好的模型不能直接让用户调用。

需要把模型变成一个：

Model Service

例如：

用户
 ↓
HTTP API
 ↓
Model Server
 ↓
GPU
 ↓
LLM
 ↓
Response

例如：

POST /chat

{
    "prompt": "什么是RAG？"
}

服务器：

Request
 ↓
Model
 ↓
Response

这就是：

Model Serving

---

5. 为什么Model Serving很重要？

假设只有一个用户：

Request
 ↓
GPU
 ↓
Response

非常简单。

但是如果同时有1000个用户：

1000 Requests
       ↓
    Server
       ↓
     GPU

如果一个请求一个请求执行：

Request 1
Request 2
Request 3
...
Request 1000

GPU可能没有得到充分利用。

因此需要：

Batching

---

6. Batching

假设有：

Request A
Request B
Request C
Request D

传统方式：

A → GPU
B → GPU
C → GPU
D → GPU

Batching：

A
B
C
D
 \ | /
  Batch
    ↓
   GPU

一次让GPU处理多个请求。

这样可以提高：

GPU利用率和吞吐量。

---

7. Continuous Batching

LLM还有一个特殊问题。

不同请求的生成长度不一样：

Request A → 100 tokens
Request B → 500 tokens
Request C → 50 tokens

如果必须等待所有请求结束再组成下一批：

A ─────────
B ───────────────────
C ─────

等待B

GPU资源可能被浪费。

Continuous Batching可以让：

A完成
 ↓
新的D进入

C完成
 ↓
新的E进入

也就是：

请求动态加入和退出Batch。

这类技术是现代LLM Serving的重要优化方向。

---

8. KV Cache

LLM生成文本的时候，并不是每生成一个Token都从零开始计算。

Transformer会产生：

Key / Value Cache

简称：

KV Cache

例如：

输入：

“请介绍一下RAG”

模型计算过程中产生：

K
V
 ↓
KV Cache

后续生成：

RAG
是一
种
……

可以复用之前的计算结果。

因此：

KV Cache可以减少重复计算，提高LLM推理效率。

但是它也会占用大量GPU显存。

于是AI Infra又要解决：

KV Cache怎么管理？

显存不够怎么办？

多个请求如何共享？

什么时候释放？

---

9. Model Parallelism

如果一个模型太大：

Model
 ↓
GPU放不下

可以把模型拆开：

Model
│
├── Layer 1~20
│      ↓
│    GPU 0
│
├── Layer 21~40
│      ↓
│    GPU 1
│
└── Layer 41~60
       ↓
     GPU 2

这就是：

Model Parallelism

多个GPU共同运行一个模型。

---

10. Data Parallelism

另外一种方式是：

GPU 0 → Model
GPU 1 → Model
GPU 2 → Model
GPU 3 → Model

每个GPU运行一个模型副本。

然后：

Request
   ↓
Load Balancer
   ↓
 ┌───┼───┐
 ↓   ↓   ↓
GPU0 GPU1 GPU2

这种方式更适合：

提高服务吞吐量。

---

11. Distributed Training

训练大型模型往往需要：

GPU 0
GPU 1
GPU 2
...
GPU N

共同训练。

例如：

Dataset
   ↓
Distributed Training
   ↓
┌──────┬──────┬──────┐
GPU 0  GPU 1  GPU 2  ...
└──────┴──────┴──────┘
           ↓
      Model Weights

这里需要解决：

• GPU之间通信
• 梯度同步
• 数据切分
• 参数同步
• Checkpoint
• 故障恢复

因此：

训练基础设施也是AI Infra的重要组成部分。

---

12. Storage

AI系统会产生大量数据：

Model
Dataset
Checkpoint
Logs
Embedding
Evaluation Data

例如一个模型：

model.safetensors
 ↓
几十GB
甚至
几百GB / TB

因此需要：

Object Storage
Distributed Storage
Local NVMe
Database

AI Infra需要解决：

数据放在哪里，以及如何快速读取。

---

13. Network

AI系统里的网络也非常重要。

特别是：

GPU 0
 ↕
GPU 1
 ↕
GPU 2
 ↕
GPU 3

如果GPU之间通信很慢：

计算速度很快
       ↓
等待网络
       ↓
GPU空闲

最终整个系统性能反而受到网络限制。

因此AI Infra需要关注：

Bandwidth
Latency
GPU-to-GPU Communication
Network Topology

---

14. MLOps

传统软件：

Code
 ↓
Build
 ↓
Test
 ↓
Deploy

AI系统：

Data
 ↓
Training
 ↓
Evaluation
 ↓
Model
 ↓
Deployment
 ↓
Inference
 ↓
Monitoring
 ↓
Retraining

所以AI需要一套：

Machine Learning Operations

也就是：

MLOps

它负责模型从开发到生产的整个生命周期。

---

15. Model Registry

模型不断训练会产生：

Model v1
Model v2
Model v3
Model v4

因此需要记录：

模型版本
训练数据
训练参数
评估结果
发布时间
部署状态

例如：

Model v3
 ↓
Accuracy: 94%
 ↓
部署Production

如果出现问题：

Production
 ↓
Rollback
 ↓
Model v2

这就是模型版本管理。

---

16. Evaluation

AI系统不能只看：

“程序有没有报错。”

还要判断：

模型回答得对不对。

例如：

Question
 ↓
Model
 ↓
Answer
 ↓
Evaluation

评估：

Accuracy
Faithfulness
Recall
Precision
Latency
Cost

因此AI Infra还需要：

Evaluation Infrastructure

---

17. Observability

系统上线之后，需要知道：

现在有多少请求？

GPU利用率是多少？

显存用了多少？

平均延迟是多少？

P95延迟是多少？

错误率是多少？

每次请求用了多少Token？

每次请求花多少钱？

因此需要：

Observability（可观测性）

主要包括：

Logs
Metrics
Traces

即：

日志
指标
链路追踪

---

18. AI Infra最关心的几个指标

传统Web服务经常关注：

QPS
Latency
CPU
Memory
Error Rate

AI系统除了这些，还会特别关注：

Throughput

单位时间处理多少Token / Request。

tokens / second

---

Latency

请求需要多久。

例如：

TTFT
Time To First Token

TPOT
Time Per Output Token

LLM通常不仅关心：

“多久返回？”

还关心：

“多久开始吐出第一个Token？”

---

GPU Utilization

GPU利用率：

GPU利用率
 ↓
高

通常说明GPU计算资源利用比较充分。

---

Memory Usage

特别关注：

GPU VRAM
KV Cache
Model Weights
Activation

因为AI模型非常吃显存。

---

Cost

最终还需要考虑：

GPU成本
+
存储成本
+
网络成本
+
模型运行成本

因此：

AI Infra的核心目标之一就是降低单位AI任务的计算成本。

---

AI Infra和普通Infra的区别

对比维度	传统Infra	AI Infra
核心计算	CPU为主	GPU/加速器
主要任务	Web、数据库、服务	Training、Inference
数据特点	结构化数据为主	Dataset、Model、Embedding
资源特点	CPU、Memory	GPU、VRAM
调度	Server调度	GPU/AI Workload调度
性能指标	QPS、Latency	Token/s、TTFT、GPU利用率
核心优化	服务稳定性	计算效率 + 显存 + 吞吐
模型管理	一般没有	Model Registry
AI评估	较少	非常重要
成本	服务器成本	GPU计算成本非常高

---

AI Infra与AI Application的区别

例如我们做一个：

AI客服

用户看到的是：

聊天窗口
 ↓
输入问题
 ↓
得到回答

这是：

AI Application

但是背后可能存在：

AI客服