Chapter 1: ML Systems：从模型算法走向完整系统

《Machine Learning Systems》第一章的目的，并不是介绍某一种机器学习算法，也不是直接讲 GPU 集群、分布式训练或模型推理框架。作者首先希望建立一种更基础的认识：

机器学习模型不是独立运行的数学公式，而是一个受到数据、算法、硬件和部署环境共同约束的计算系统。

传统机器学习通常把注意力集中在模型结构、训练方法和准确率上，而 ML Systems 更关注另一个问题：模型如何在现实硬件上满足延迟、吞吐、成本、功耗和可靠性要求。

因此，本章主要是在建立后续内容所需要的系统分析框架。

1. 从模型指标转向系统指标

单纯从算法角度看，一个模型通常通过准确率、损失函数和泛化能力进行评价。

但模型进入实际系统后，还需要面对一系列工程约束：

• 模型能否放入设备内存；
• 数据能否及时送到计算设备；
• 推理延迟能否满足业务要求；
• 训练过程能否充分利用 GPU；
• 系统的功耗和成本是否可以接受；
• 网络不可用时，模型是否仍然能够运行。

因此，一个准确率更高的模型，不一定是更好的系统方案。

例如，一个模型的准确率提高了 1%，但模型大小扩大十倍、延迟增加五倍，那么它可能无法部署到手机或实时边缘设备上。ML Systems 关心的是准确率与系统代价之间的整体权衡，而不是孤立地追求单一指标。

2. 部署环境决定系统约束

本章将常见的机器学习部署环境分为四类：

这里的“部署范式”并不是机器学习算法的分类，而是对模型运行环境的分类。

作者通过这些场景说明：同一个模型部署在不同位置，面临的系统问题可能完全不同。

例如，云端服务可以使用高性能 GPU，但请求需要经过网络传输；边缘设备算力较弱，却能够减少网络延迟；移动设备强调电池续航；TinyML 系统甚至首先需要解决“模型能否放得进去”的问题。

因此，系统设计的起点不应该是“使用什么模型”，而应该是：

应用需求
  ↓
部署环境
  ↓
延迟、功耗、内存和成本约束
  ↓
模型与硬件设计

3. DAM：分析 ML 系统的三个维度

作者使用 DAM 框架描述一个 ML 系统的基本组成：

• Data：需要处理和搬运的数据；
• Algorithm：需要执行的计算过程；
• Machine：负责实际执行的硬件平台。

Data

Data 不仅包括训练集和输入数据，也包括数据在存储、内存和计算设备之间的移动过程。

常见问题包括：

• 数据读取速度不足；
• 数据预处理成为瓶颈；
• GPU 等待 CPU 或存储提供数据；
• 权重和激活值在内存层次间反复搬运。

Algorithm

Algorithm 决定系统需要执行多少工作，例如：

• 模型参数规模；
• 神经网络层数；
• 输入序列长度；
• 运算精度；
• 是否存在重复或无效计算。

算法优化的本质，是减少完成任务所需的计算量或数据量，例如量化、剪枝、蒸馏和稀疏化。

Machine

Machine 是执行算法的物理平台，包括：

• CPU、GPU、TPU、NPU；
• 内存容量和带宽；
• 存储与网络；
• 功耗和散热条件。

更高的峰值算力并不必然带来更高的实际性能。只有当工作负载确实受到计算能力限制时，增加 FLOPS 才能产生明显收益。

DAM 的价值在于提醒系统设计者：性能问题并不一定来自硬件，也可能来自数据路径或算法工作量。

4. Workload Archetypes：识别主要瓶颈

为了进一步描述不同工作负载的性能特征，本章提出了几种典型工作负载原型。

Compute Beast

计算量很大，主要受计算吞吐限制。

典型场景包括大规模神经网络训练。此类工作负载通常包含大量矩阵乘法，能够较充分地使用 GPU Tensor Core。

对应传统体系结构中的：

Compute-bound workload。

Bandwidth Hog

计算单元需要不断读取模型权重和激活值，主要受内存带宽限制。

例如，大语言模型在小批量 Decode 阶段，每生成一个 Token 都可能需要读取大量模型权重。此时 GPU 的理论 FLOPS 很高，但计算单元可能长期等待 HBM 提供数据。

对应：

Memory-bandwidth-bound workload。

Sparse Scatter

工作负载需要在大型数据结构中进行大量离散、随机访问。

推荐系统中的 Embedding Table 查询是典型例子。其问题通常不是连续带宽不足，而是随机访问、缓存局部性和通信开销。

对应：

Irregular memory access 或 latency-bound workload。

Tiny Constraint

系统首先受到内存容量、功耗和设备资源的硬约束。

这种场景通常出现在微控制器、传感器和始终在线的低功耗设备中。优化目标可能不是提高峰值性能，而是让模型能够在有限资源中运行。

可以将四种原型简化为：

Compute Beast：计算量大
Bandwidth Hog：数据搬运量大
Sparse Scatter：数据访问不规则
Tiny Constraint：资源上限严格

这些原型不是模型类别，而是对运行时瓶颈的描述。同一个 Transformer 在训练阶段和推理阶段，也可能表现为不同的工作负载类型。

5. 系统平衡与硬件配置

所谓系统平衡，是指计算、内存、存储和网络能力需要与工作负载匹配。

系统性能通常由最慢的环节决定：

计算时间
内存搬运时间
存储与网络 I/O 时间
同步和启动延迟
        ↓
其中最大的部分成为主导瓶颈

如果模型受到内存带宽限制，那么继续增加计算单元不会显著提高性能；如果模型受到计算吞吐限制，仅增加内存容量同样没有意义。

因此，硬件配置不能只看单个峰值指标，而要考虑多个维度：

• 峰值计算吞吐；
• 内存容量；
• 内存带宽；
• 设备间通信；
• 存储和网络吞吐；
• 能耗与散热；
• 实际硬件利用率。

例如，LLM 推理系统可能更关注 HBM 容量和带宽，而大批量训练系统通常更关注矩阵计算能力和多设备通信效率。

系统平衡并不是让所有硬件指标达到同一水平，而是避免某个组件明显无法满足工作负载要求。

6. 本章各概念之间的关系

部署范式、DAM、工作负载原型和系统平衡并不是四套相互独立的理论，而是同一个系统设计过程中的不同阶段。

部署环境
  ↓
确定延迟、功耗、容量和成本约束
  ↓
使用 DAM 分析数据、算法和机器
  ↓
识别主要工作负载瓶颈
  ↓
调整模型、数据路径和硬件配置

例如，对于 LLM Decode：

• 部署环境可能是云端在线服务；
• Data 侧需要频繁读取模型权重和 KV Cache；
• Algorithm 侧每个 Token 的计算复用有限；
• Machine 侧 GPU 计算能力可能没有完全利用；
• 工作负载表现为 Bandwidth Hog；
• 优化方向包括量化、批处理和提高内存带宽利用率。

这些概念最终都服务于同一个目标：找到系统中真正限制端到端性能的因素。

7. 常见误区

误区一：模型越大，系统效果越好

模型规模只是影响效果的一个因素。更大的模型意味着更多计算、内存和数据搬运成本，未必符合实际部署条件。

误区二：GPU FLOPS 越高，程序一定越快

当程序受到内存、网络或存储限制时，增加峰值算力的收益可能非常有限。

误区三：Workload Archetype 是模型分类

它不是在区分 CNN、Transformer 或推荐模型，而是在描述它们运行时暴露出的主导瓶颈。

误区四：一个模型只有一种性能特征

模型的性能特征会随训练或推理阶段、Batch Size、输入规模和硬件平台而变化。

例如，Transformer 训练可能是计算受限，而小批量 Decode 更可能受到内存带宽限制。

误区五：只需优化最明显的局部组件

局部组件加速后，瓶颈可能转移到系统的其他位置。ML Systems 更强调端到端分析，而不是孤立地优化单个算子或设备。

8. 本章的核心目的

这一章真正希望读者建立的，是一种工作负载驱动的系统观：

先明确应用需求和物理约束，再分析数据、算法和机器之间的关系，最后选择模型、优化方法和硬件配置。

对于具有体系结构或系统背景的读者，本章中的很多内容可以映射到熟悉的概念：

因此，本章并不是在提出一套完全不同于传统计算机系统的理论，而是在将工作负载分析、内存墙、局部性和端到端性能优化等思想应用到机器学习场景中。

总结

ML Systems 关注的并不只是模型本身，而是模型在真实计算环境中的完整生命周期。

本章可以压缩为一条主线：

运行在哪里
  ↓
受到什么约束
  ↓
需要处理多少数据和计算
  ↓
真正的瓶颈是什么
  ↓
应该优化算法、数据路径还是硬件

这也是后续理解 ML 框架、模型训练、硬件加速、模型压缩和推理服务的基础。