Megatron-LM - Training Multi-Billion Parameter Language Models Using Model Parallelism
Attention 计算的线性代数问题
attention 和 FFN 的关系
如果记某层输入为 x, 那么可以粗略理解成:
attention 输出: 给 x 补充上下文信息, 像"开会听别人说话"
FFN 输出: 给 x 补充局部计算后的新特征, - 像"你自己在脑子里消化, 归纳, 形成判断"
如果我们尝试把一个 FFN 层变成一个 attention 层, 结果就是可能会更加适合长距离语义传输但是缺少本地语义特征变换器
多层 attention-FFN 结构
可以理解为不断重复"交换信息 →\rightarrow→ 消化信息 →\rightarrow→ 再交换 →\rightarrow→ 再消化"
也就是说各自对本 token 处于上下文的含义理解之后再次进行交换分享,让整体的文意理解更加深刻
Transformer 架构的训练计算
假设训练句子是:The capital of France is Paris.
训练时,decoder-only 模型会把它转成一种“前缀预测后一个 token”的形式, 比如模型看到 ...
GPipe - efficient training of giant neural networks using pipeline parallelism
神经网络基础
如图是一个基础的神经网络结构, 我们这里首先要明确几个函数:
每一层内部的计算是 hi:=σ(zi)h_i := \sigma(z_i)hi:=σ(zi), zi:=Wihi−1+biz_i := W_i h_{i-1} + b_izi:=Wihi−1+bi
我们最终的输出函数是 L:=L :=L:=loss(sample; forward)
forward: 指的是从输入样本数据 h0h_0h0 到 最终输出 σ(z2)\sigma(z_2)σ(z2) 的所有计算过程
backward: 从 LLL 开始不断计算每一层中的 ∂L∂Wi\frac{\partial L}{\partial W_i}∂Wi∂L 和 ∂L∂bi\frac{\partial L}{\partial b_i}∂bi∂L 的方向梯度, 然后用这个来不断更新 Wi, biW_i,\ b_iWi, bi
现在来拆解一下反向传播的过程: 基本根据的是莱布尼茨链式法则 (chain-rule)
∂L∂W2=∂L∂z2∂z2∂W2=∂L∂z2h1T\frac{\partia ...
1. JVM GC 工作思路
📝 术语别名
GC: Garbage Collection, 自动垃圾回收;
STW: Stop-The-World, GC 期间所有应用线程被 JVM 冻住;
Heap: JVM 管理的对象内存区, 所有 new 出来的东西都在这里;
GC Roots: 一组"一定还活着"的引用起点, 可达性分析的种子;
前置: 为什么 Java 需要 GC
C/C++ 程序员是手动管内存的, 你 malloc 一块就要负责 free 一块, 漏了就内存泄漏, 重复 free 就 double-free crash; Java 把这个负担拿走了, 程序员只负责 new Foo(), 永远不主动释放;
那对象怎么消失? 答案是 JVM 启动了一个叫 GC 的后台机制, 周期性扫整个 heap, 把"再也不会被用到的对象"自动清掉, 这一行为的代价是: 扫的时候得短暂冻住应用线程 (STW), 这就是 GC 给你带来的延迟代价;
所以理解 GC 本质上要回答两个问题:
怎么判断一个对象"已经死了";
判断完之 ...
6. Unix ping 与 ICMP 协议
📝 术语别名
ICMP: Internet Control Message Protocol, IP 层的"控制/反馈"协议;
RTT: Round-Trip Time, 一来一回的总时延;
Echo Request / Echo Reply: ICMP type 8 / type 0, 就是 ping 用到的两种报文;
前置: ICMP 在协议栈中的位置
ICMP 经常被人当成"网络层之上的小协议", 但它实际上是 IP 协议的一个直接附庸, 跑在 IP 之上, 但属于 network layer 的控制平面;
IP 包的 header 里 Protocol 字段为 1 时, 上层就是 ICMP (对比 TCP=6, UDP=17);
ICMP 报文不走传输层, 没有端口号; 它的"复用"由 ICMP type + code 这两个字节自己完成;
ICMP 的存在意义是给 IP 这个 best-effort 协议一个反馈信道, 比如告诉 src “你这个包 TTL 跑光了”, “目标不可达 ...
5. Docker 网络栈协议
📝 术语别名
NIC: Network Interface Card, 物理网卡, 真正的硬件;
net_device: Linux 内核里描述"一张网卡"的统一抽象, 虚拟和物理共用同一个数据结构;
虚拟网卡: 没有对应物理硬件、纯软件模拟的 net_device, 例如 lo / veth / tap / tun / bridge;
tap / tun: 给用户态进程收发包用的虚拟网卡, VM 和 VPN 的标配;
netns: Linux network namespace, 内核提供的网络栈隔离机制;
veth pair: virtual ethernet pair, 一对虚拟网卡, 一端发, 另一端收, 是连接两个 netns 的通道;
bridge: 内核虚拟二层交换机, 把若干网卡拉到同一广播域;
DNAT / SNAT: destination / source NAT, iptables 用来改包的 dst/src IP, 是端口映射和"出口走主机 IP"的核心;
前置 A: 物理网卡 (NIC ...
kubernetes
Load Balance
1. Distributed Data Parallel
DDP 是什么
DDP(Distributed Data Parallel)是 PyTorch 官方提供的分布式数据并行训练机制;
它的核心思想是:
让多个训练进程各自持有同一个模型的副本, 分别处理不同的数据子集, 并在反向传播阶段自动同步梯度, 从而保持所有模型副本的一致更新;
DDP 要解决什么问题
深度学习训练通常面临两个核心限制:
单张 GPU 的计算吞吐有限
单张 GPU 每一步能处理的数据量有限
如果只用单卡训练, 随着模型和数据规模变大, 训练速度会越来越慢;
DDP 的目标是:
利用多张 GPU 并行处理更多数据
在提高吞吐的同时, 仍然保持"训练的是同一个模型"
让多卡训练的优化语义尽量接近单卡上的大 batch 训练
因此, DDP 本质上是在解决: 如何让多个 GPU 高效, 稳定地共同训练同一个模型;
DDP 的设计理念
DDP 的设计建立在一个基本前提上: 如果 单张 GPU 能放下完整模型, 那么最自然的数据并行方式不是切模型, 而是复制模型; 所以 DDP 的基本设计不是"拆模型", 而是:
每个进程 ...
0. 基本 GPU 架构
Data-Level Parallelism (DLP)
在前面的工作中我们主要学习的 并行架构 就是 pipelining
简单的做法就是并行使用多个 核 core 或者使用多个硬件结构实现并行, 但是这里要讨论的是 数据层面的并行
在固有的处理器中, 我们计算如下公式
12for(i = 0; i < 100; i++) z[i] = A * x[i] + y[i];
很显然这一步可以用矩阵和向量等式进行优化
即表达式 z⃗=A⋅x⃗+y⃗\vec z = A\cdot \vec x + \vec yz=A⋅x+y
那么接下来的问题就是如何用硬件快速计算向量
SIMD 方法论
基础方法称为 single insturction single data 处理, 即每个指令获取一个对应的 data 部分, 但是事实上我们可以从一个指令调用多个 变量(来自一个 vector 的多个相关变量) 这就是 simd (可以在单核处理器上面有出色表现)
当然也可以 多个指令调用多个变量, 这个取决于多核同时工作
对比 cpu 和 gpu, 我们会发现当我们要处理大量相同类型的数据的时候 ...
10. Tradeoffs btw
平衡的背景
利用冗余(replicas)来降低尾延迟(tail latency), 以及它和 Paxos 共识, load / sharding 之间的关系;
核心是: 复制本来是为了容错/可用性, 但你也可以把它当成"多条独立路径/多台机器"的并行机会, 用来对抗偶发慢请求;
一个 key 有多个副本(N replicas);
- 正常读: 只读一个副本
- 好处: 负载低, 便宜
- 风险: 这一次刚好遇到这个副本慢(GC, 排队, 抖动), 尾延迟就被拖垮
First idea: read from all in parallel(最直接: 全部并行读, 取最快)
做法: 同时向所有副本发 GET, 拿到第一个返回就用(其他请求丢掉/忽略);
优点: 尾延迟会显著下降(你拿的是 min(response times))
问题(slide 点出的): 系统负载和成本暴涨
每次读都变成 N 倍 RPC
平均延迟可能更好, 但整体排队更严重, 反而把系统推到更拥塞, 导致更差的 tail
所以"全并行"通常太贵, 只能在极少数场景用;
Sec ...
8. Sharding, Facebook and Implementation
分片 (Sharding)
分片是分布式系统设计中的一个关键概念, 它与复制(Replication)一起, 构成了构建大规模系统的基础;
分片的本质与目标
分片的本质在于解决单一机器的限制和不可靠性问题,;
复制(Replication): 通过复制数据来使机器可靠(reliable), 提高容错性;
分片(Sharding): 通过分割数据来提高机器的容量限制 (raise the machine’s limits);
分片适用于任何存储系统, 通常是通过将 键空间(key space) 分割到多个复制对(例如主/备份对)来实现;
Facebook 架构中的分片应用
复制存储: 数据库在所有数据中心之间进行复制(replicated), 可以想象每个数据中心都包含一份完整的数据拷贝,;
数据库分割: 数据库被分割成多个分片(shards), 每个数据元素都属于一个特定的分片,;
- 领导者/跟随者: 每个分片都有一个数据中心作为其领导者(leader), 其余的中心是跟随者(followers);
- 数量: 分片的数量通常远多于(many more)数 ...
