流水线并行（Pipeline Parallelism）最早是 Google 在 Gpipe 论文中提出的，这种并行训练模式能够充分利用多 GPU 的资源高效地训练评估大模型。目前 PyTorch 最新版本是 2.2，流水线并行的功能是基于 torchgpipe 论文中的设计来实现的，该功能当前还处于试验阶段。 问题背景 大模型无法直接放到单个 GPU 中进行训练，通过模型并行（Model Parallelism）的方法可以把模型进行分片，每一个分片放置到一个 GPU 上，这样能够很好实现模型并行且利用多 GPU 的资源。虽然使用这种较为初级的方式能够实现大模型的训练，但在训练的过程中并不能充分利用 GPU 资源，因为对顺序（Sequential）模型来说它每次只能激活一个 GPU 来进行训练，其它的 GPU 此时是闲置的，所以在底层设备上其实仍然是顺序执行。 例如，对一个有 4 层的顺序（Sequential）神经网络模型，经过模型分片后，训练过程中每一层（或 Subnetwork）放在一个 GPU 上，先进行前向传播计算得到 Loss，然后反向传播计算梯度，如下图所示： 使用这种方式利用 GPU 训练，我们可以看到在训练过程中 GPU 完全没有被充

在 AI 大模型训练场景中，数据是海量的，模型也是超大的，对于训练大模型会带来很大挑战，比如对算力的需求，对处理大模型的工程复杂度，等等。PyTorch 给出了一种实现方式——FSDP（Fully Sharded Data Parallel），它提供了易用的 API，可以非常方便地解决大模型分布式训练的难题。 FSDP 是在 DDP（DistributedDataParallel）的基础上提出的，首先我们了解一下 PyTorch 的 DDP（DistributedDataParallel） 训练模式的一些特点： 在 DDP 中，核心的能力还是训练数据并行（Data Parallel）。以多机多卡方式为例，每个 process/worker 都会持有模型的一个副本（Replica），通过使每个 process/worker 处理一个 batch 的数据试下并行处理，最后使用 all-reduce 操作对多个不同 process/worker 计算得到的梯度进行累加求和；接着，再将优化器状态、梯度通过跨多个 process/worker 进行复制，使得每个 process/worker 上的模型参数都得到同步更新。也就是说，在 DDP 中并没有实现对模型参数的分片管理，即模型并行（Model Parallel）。 在 FSDP 中实现了模型的分片管理能

Stable Diffusion 是一个文本到图像（txt2img）的潜在扩散模型（LDM），是由 CompVis、Stability AI 和 LAION 的研究人员实现并开源的。我们站在 Stable Diffusion 模型应用用户的角度来看，其实没有多么复杂，核心就是根据文本生成图像，其中可以通过一些技巧，或通过调整用户参数，来改变文本生成图像的过程，从而达到优化最终生成图像的目的。但是，从 Stable Diffusion 底层技术的角度看，这个过程非常非常复杂，所以我们这里先给出模型的 Architecture Overview，先从总体上看整个架构（或结构）是什么样的，然后深入到每一个部分去了解具体的技术细节和原理。 1 模型架构概览 从 High-level 的视角，Stable Diffusion 模型都包含哪些主要组件，以及整体的处理流程，我们引用了 The Illustrated Stable Diffusion 一文中的一个图，并在原图上做了微小改动（为了方便理解添加了表示三个核心步骤的数字序号），来表示 Stable Diffusion 模型的处理机制，如下图所示： 基于上图，我们分步骤描述一下 txt2image 处理的整个过程： 首先，输入 Prompt 提示词 “para

BERT 是 Bidirectional Encoder Representations from Transformers 的缩写，是由 Google 发布的先进的嵌入模型，BERT 是自然语言处理领域的一个重大突破，它在许多自然语言处理任务中取得了突出的成果，比如问答任务、文本生成、句子分类等。BERT 之所以能够成功，主要是因为它是基于上下文的嵌入模型，不同于像 word2vec 等其他一些流行的嵌入模型。 从 BERT 的含义来看，它使用多个 Transformer 表示，而且是基于双向 Encoder 的，我们要知道 BERT 的架构是只包含 Encoder 的 Transformer 模型架构。 BERT 模型配置 BERT 在发布模型的时候，给出了多种不同的配置，其中两种标准的配置为 BERT-base 和 BERT-large，另外还有一些小型的配置，如下表所示： BERT 模型配置 Encoder 层数（L） 注意力头个数（A） FFN 层隐藏神经元个数（H） BERT-base 12 12 768 BERT-large 24 16 1024 BERT-tiny 2 – 128 BERT-mini 4 – 256 BERT-small 4 – 512 BERT-medium 8 – 512 BERT-base 模型的网络参数总数可达 1.1 亿个，而

2017 年 Google 在论文《Attention Is All You Need》中提出 Transformer 模型架构，该架构是基于 Encoder-Decoder （编码器-解码器）的架构。作为当下最先进的深度学习架构之一，Transformer 被广泛应用于自然语言处理领域，它不仅替代了以前流行的循环神经网络（RNN）和长短期记忆网络（LSTM），而且后来的 BERT、GPT-3 等网络架构也是基于 Transformer 架构演化而来。 RNN 和 LSTM 已经在时序任务方面有了广泛的的应用，例如像文本预测、机器翻译、文章生成等等，但是这些应用都面临着如何记录长期依赖的问题，而使用 Transformer 架构就能解决这类问题。 自注意力（Self-Attention） Transformer 架构的核心主要是基于自注意力机制（Self-Attention），在详解 Transformer 架构之前，我们有必要理解一下自注意力这个概念，我们以《BERT 基础教程：Transformer 大模型实战》这本书的讲解来概述，这本书中的讲解非常浅显易懂。 给定一个英文句子： A dog ate the food because it was hungry. 句子中的代词 it 可能代表句子里的名词 food 或者 dog，虽然我们人类非

Apache Hudi 是一个 Data Lakes 的开源方案，Hudi 是 Hadoop Updates and Incrementals 的简写，它是由 Uber 开发并开源的 Data Lakes 解决方案。Hudi 具有如下基本特性/能力： Hudi 能够摄入（Ingest）和管理（Manage）基于 HDFS 之上的大型分析数据集，主要目的是高效的减少入库延时。 Hudi 基于 Spark 来对 HDFS 上的数据进行更新、插入、删除等。 Hudi 在 HDFS 数据集上提供如下流原语：插入更新（如何改变数据集）；增量拉取（如何获取变更的数据）。 Hudi 可以对 HDFS 上的 parquet 格式数据进行插入/更新操作。 Hudi 通过自定义 InputFormat 与 Hadoop 生态系统（Spark、Hive、Parquet）集成。 Hudi 通过 Savepoint 来实现数据恢复。 目前，Hudi 支持 Spark 2.x 版本，建议使用 2.4.4+ 版本的 Spark。 基本架构 与 Kudu 相比，Kudu 是一个支持 OLTP workload 的数据存储系统，而 Hudi 的设计目标是基于 Hadoop 兼容的文件系统（如 HDFS、S3 等），重度依赖 Spark 的数据处理能力来实现增量处理和丰富的查询能力，Hudi 支持 Incremental Pulling 而 Kudu 不

Azkaban 是一个非常简单实用，而且开源的作业调度系统。在 2.x 版本中不支持集群模式部署，在 3.x 版本中支持集群模式部署，适用于作业量比较大一些的应用场景。有关 Azkaban 更多详细信息，如特点、功能、特性、作业定义等，可以参考官方文档，这里不再详述。 Azkaban 集群架构 下面我们看一下 Azkaban 集群模式的架构，如下图所示： 从上图可见，Azkaban 集群部署模式，主要有 3 个核心的组件： Azkaban WebServer Azkaban WebServer，是整个调度集群的核心，负责所有作业的管理和调度。 Azkaban ExecutorServer Azkaban ExecutorServer，整个调度集群中实际运行作业的节点，该类节点可能是作为一个作业提交的客户端，比如 Spark on YARN 部署模式下，cluster 运行模式时只作为客户端使用，client 运行模式时会有部分计算逻辑；比如普通的 Java 程序需要处理量级较小的数据作业，这时Executor Server 节点可能有较大的工作负载，占用较多节点资源（内存、CPU）。 DB DB，是集群中所有节点运行共用的数据存储，包含作业信息、各种调度元数据等等。 核心调度

基于 PB 级海量数据实现数据服务平台，需要从各个不同的角度去权衡，主要包括实践背景、技术选型、架构设计，我们基于这三个方面进行了架构实践，下面分别从这三个方面进行详细分析讨论： 实践背景 该数据服务平台架构设计之初，实践的背景可以从三个维度来进行说明：当前现状、业务需求、架构需求，分别如下所示： 当前现状 收集了当前已有数据、分工、团队的一些基本情况，如下所示： 数据收集和基础数据加工有专门的 Team 在做，我们是基于收集后并进行过初步加工的基础数据，结合不同行业针对特定数据的需求进行二次加工的。 数据二次加工，会集成基础数据之外的其它有业务属性的数据，比如引入第三方 POI 数据等。 原始数据每天增量大约 30~40TB 左右。 计算集群采用 Spark on YARN 部署模式，大约 400 个节点。 所有数据各种属性、行为信息，都是围绕大约 40亿+ 的移动设备 ID 进行很多倍膨胀，比如每天使用微信 App 的设备的行为信息。 参与该平台的研发人员，对实际数据业务需求了解不会非常深入，因为跨多个行业及其不同数据需求的变化较快。 业务需求 另

本文试图将Kubernetes的基础相关知识描述清楚，让一个从来没有Kubernetes实践的开发人员，能够非常容易地理解Kubernetes是什么，能够做哪些事情，以及使用它能带来的好处是什么。 Kubernetes是什么 Kubernetes是一个开源的容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。我们在完成一个应用程序的开发时，需要冗余部署该应用的多个实例，同时需要支持对应用的请求进行负载均衡，在Kubernetes中，我们可以把这个应用的多个实例分别启动一个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要应用开发和运维人员去进行复杂的手工配置和处理。 Kubernetes是Google基于内部Borg开源的容器编排引擎，关于Borg的设计，可以查看对应的论文《Large-scale cluster management at Google with Borg》。这里，我们先说一说Borg系统，它是Google内部的集群管理系统，使用它能够获得如下好处： 在一个分布式系统中进行资源管理是非常复杂的，构建于Borg系统之上的其他系统，无需关

Docker 集群管理和编排的特性是通过 SwarmKit 进行构建的， 其中 Swarm mode 是 Docker Engine 内置支持的一种默认实现。Docker 1.12 以及更新的版本，都支持 Swarm mode，我们可以基于 Docker Engine 来构建 Swarm 集群，然后就可以将我们的应用服务（Application Service）部署到 Swarm 集群中。创建 Swarm 集群的方式很简单，先初始化一个 Swarm 集群，然后将其他的 Node 加入到该集群即可。本文主要基于 Docker Swarm 官网文档，学习总结。 基本特性 Docker Swarm 具有如下基本特性： 集群管理集成进 Docker Engine 使用内置的集群管理功能，我们可以直接通过 Docker CLI 命令来创建 Swarm 集群，然后去部署应用服务，而不再需要其它外部的软件来创建和管理一个 Swarm 集群。 去中心化设计 Swarm 集群中包含 Manager 和 Worker 两类 Node，我们可以直接基于 Docker Engine 来部署任何类型的 Node。而且，在 Swarm 集群运行期间，我们既可以对其作出任何改变，实现对集群的扩容和缩容等，如添加 Manager Node，如删除 Worker Node，而做这些操作不需要暂停或