4. AI工作负载特征：训练与推理的资源需求
AI工作负载与传统企业应用在资源消耗模式上存在本质差异。传统应用通常是“请求-响应”型，资源占用相对平稳；而AI负载则呈现出高算力密度、大内存带宽、持续数据吞吐的特征。要制定有效的调优方案，首先必须区分训练（Training）与推理（Inference）两类负载，它们的资源需求曲线截然不同。
4.1 训练负载：算力饥渴与数据流水线
训练过程本质上是前向传播 + 反向传播的迭代优化。每一次迭代都需要将小批量（mini-batch）数据送入模型，计算损失，再通过反向传播更新权重。这一过程对硬件资源的消耗呈现以下特征：
- GPU算力（FLOPS）：训练是典型的“算力饥渴”型负载。模型参数越多、训练样本越大，所需的浮点运算次数越高。以GPT-3（1750亿参数）为例，单次训练需要约3.14×10²³ FLOPS，即使使用千卡A100集群也需要数周时间。
- 显存容量（VRAM）：训练时显存不仅需要存放模型权重，还需保存中间激活值（activations）、梯度、优化器状态（如Adam的动量项）。混合精度训练（FP16）下，一个70亿参数的模型仅权重就需要约14GB，加上激活和梯度，通常需要40GB以上显存。
- CPU与内存：CPU负责数据预处理（图像解码、文本tokenize、数据增强）和分布式训练中的梯度聚合。CPU性能不足会导致GPU等待数据，形成“数据饥饿”。内存容量需能容纳整个数据集的多个epoch副本或索引。
- 存储I/O：训练数据通常以TB甚至PB级存储。存储的顺序读取带宽和随机读取IOPS直接影响数据加载速度。若存储带宽低于GPU消费数据的速度，训练流水线将出现气泡。
核心原理：训练负载的瓶颈往往不在GPU本身，而在于“数据流水线”能否持续供数。GPU计算速度远快于磁盘读取速度，因此需要多层缓存（内存→页面缓存→SSD→网络存储）来平滑数据流。
4.2 推理负载：延迟敏感与吞吐权衡
推理是将训练好的模型部署到生产环境，对新的输入进行预测。推理负载的资源需求与训练完全不同，更强调低延迟、高吞吐、可控成本。
| 维度 | 训练 | 推理 |
|---|---|---|
| 算力需求 | 极高，持续满载 | 中等，但要求峰值响应快 |
| 显存需求 | 权重+梯度+激活+优化器状态 | 仅权重+KV Cache（Transformer） |
| 延迟要求 | 不敏感（分钟级/小时级） | 敏感（毫秒级/秒级） |
| 批处理策略 | 固定大batch（如1024） | 动态batch，需权衡延迟与吞吐 |
| CPU角色 | 数据预处理、分布式协调 | 请求路由、结果后处理、模型调度 |
| 存储需求 | 高带宽顺序读 | 低延迟模型加载、高频小文件读 |
推理负载中，KV Cache是Transformer模型特有的显存消耗点。对于自回归生成，每个已生成的token都需要缓存其Key和Value向量，序列越长，KV Cache占用越大。例如，7B模型在输入1024 token、输出1024 token时，KV Cache约占用2GB显存（FP16）。
4.3 GPU/CPU/内存/存储特性对比
为了更精确地规划资源，需要理解各硬件组件在AI负载中的角色差异：
- GPU：核心计算单元。训练时利用率应保持在85%以上；推理时利用率波动大，需通过动态批处理（dynamic batching）提升利用率。GPU间通信（NVLink/NVSwitch）带宽决定多卡扩展效率。
- CPU：训练时负责数据管线（DataLoader），推理时负责预处理/后处理和模型编排。CPU核数不足会导致预处理成为瓶颈，尤其在NLP任务中tokenization和图像任务中解码环节。
- 内存（DRAM）：训练时需容纳数据集索引、预处理后的特征向量；推理时需缓存模型权重（若GPU显存不足则需CPU内存卸载）。内存带宽影响数据拷贝速度，内存容量不足会导致OOM或频繁swap。
- 存储：训练场景需要高吞吐的并行文件系统（如Lustre、GPFS）或高性能NVMe SSD阵列；推理场景更关注模型加载时间（冷启动）和日志写入的IOPS。存储延迟过高会直接拉长推理P99延迟。
4.4 案例：推荐系统推理集群的资源画像
某互联网公司的推荐系统使用DeepFM模型（约5亿参数），部署在8台GPU服务器上。通过监控发现以下问题：
- GPU利用率平均仅35%，但P99延迟达到120ms（目标<80ms）；
- CPU核数配置不足（每台仅8核），特征工程预处理（拼接用户历史行为序列）耗时占整个推理链路的45%；
- 存储使用HDD，模型热加载（每5分钟更新一次）需要3.2秒，期间请求排队；
- 内存容量64GB，但缓存了全量特征表（约30GB），导致页面缓存不足，频繁触发磁盘读。
优化方案：
- 将CPU从8核提升至32核，并将特征预处理改为异步流水线，使GPU等待时间降低60%；
- 存储更换为NVMe SSD，模型热加载时间从3.2秒降至0.4秒；
- 内存扩容至128GB，确保特征表完全驻留内存；
- GPU启用动态batch（最大batch=8），吞吐提升2.1倍，P99延迟降至65ms。
4.5 常见误区与复盘
误区1：只关注GPU而忽略CPU/存储。许多团队在训练时发现GPU利用率低，第一反应是增加GPU卡数，但实际瓶颈在DataLoader的CPU预处理能力不足，或存储带宽不够导致数据读取等待。应使用 nvidia-smi dmon 和 iostat 联合排查。
误区2：推理服务盲目追求大batch。增大batch确实能提升吞吐，但会线性增加延迟。对于在线推荐、搜索等场景，延迟SLA是硬约束，应通过压测找到batch与延迟的平衡点，而非一味增大batch。
复盘要点：在AI系统调优中，应建立“端到端资源视图”——从存储读取、CPU预处理、GPU计算到结果返回，每一环都可能成为瓶颈。建议为训练和推理分别建立资源画像基线，记录不同负载下的GPU利用率、CPU等待率、内存带宽、存储IO延迟，用数据驱动扩容决策。
总结而言，训练负载是“持续高消耗型”，需要大算力、大显存、高带宽存储和充足的CPU预处理能力；推理负载是“波动敏感型”，需要低延迟、动态弹性、快速模型加载和精细的批处理策略。理解这些差异，是后续进行GPU调度、内存分配、存储分层和缓存设计的前提。