从上一篇文章，我们知道grpc使用HTTP/2作为底层传输协议，并且在响应消息包含 3 个主要部分：响应头信息、以长度作为前缀的消息以及 trailer。那么什么是trailer呢？大家很多人前端或者后端工作中都在使用http协议，但我咨询了一些同事，都没听过http trailer，包括没在使用grpc的自己。

什么是Trailer HTTP 标头？

Trailer HTTP 标头是一个响应标头，指示使用分块传输编码编码的消息的标头中是否存在一组指定的标头字段。它使发送者能够在分块消息的末尾放置附加字段以传递元数据。分块传输编码是 HTTP 版本 1.1 中包含的一种数据传输技术。要启用Trailer HTTP 标头中的trailer 字段，必须将TE 请求标头设置为trailers。用户代理准备接受的传输编码在 TE 请求标头中指定。Trailer HTTP 标头只有一个值。Trailer HTTP 标头语法是 header-name，它是在使用分块传输编码编码的消息预告片中找到的标头字段的集合。Trailer HTTP 标头的示例如下所示。

1
2
3
4
5
6
7
8
9
10
11
12
13

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: Expires
7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
Expires: Wed, 21 Oct 2015 07:28:00 GMT\r\n
\r\n

‍

Trailer HTTP 标头的语法是什么？

Trailer HTTP 标头的语法是标头名称。使用 Trailer HTTP 标头的语法如下。

1

Trailer: header-names

‍

Grpc他是由谷歌开发，其中主要有以下特点：

1. 高性能 ：gRPC 使用基于二进制的协议，并采用 Protocol Buffers 进行高效的消息序列化和反序列化。它使用 HTTP/2 作为底层传输协议，支持多路复用、头部压缩和流等特性，提供了更低的延迟和更高的吞吐量。
2. 跨语言支持 ：gRPC 提供了多种编程语言的支持，如 C++, Java, Python, Go 等。通过使用 Protocol Buffers 的接口描述语言，可以自动生成客户端和服务端的代码，提供了更好的类型安全性和编译时检查。

其中使用 HTTP/2作为底层传输协议，然后我们使用proto文件生成的Java或者python代码进行服务提供者和客户端调用。那么他内部协议设计是怎样的呢？

在 HTTP/2 中，客户端和服务器端的所有通信都是通过一个 TCP 连接完成的，这个连接可以传送任意数量的双向字节流。

相关术语如下：

流（stream）：在一个已建立的连接上的双向字节流。一个流可以携带一条或多条消息。
帧（frame）：HTTP/2 中最小的通信单元。每一帧都包含一个帧头，它至少要标记该帧所属的流。
消息（message）：完整的帧序列，映射为一条逻辑上的 HTTP 消息，由一帧或多帧组成。这样的话，允许消息进行多路复 用，客户端和服务器端能够将消息分解成独立的帧，交叉发送 它们，然后在另一端进行重新组合。
如图所示，gRPC 通道代表一个到端点的连接，也就是一个 HTTP/2 连接。当客户端应用程序创建 gRPC 通道的时候，它会在幕后创建一个到服务器端的 HTTP/2 连接。在通道创建完成之后，就可以重用它来发送多个到服务器端的远程调用。这些远程调用会映射为 HTTP/2 中的 流。远程调用中的消息以 HTTP/2 帧的形式进行发送，帧可能会携带一 条 gRPC 长度前缀的消息，也可能在 gRPC 消息非常大的情况下，一条消息跨多帧。

​

1. 请求消息

   请求消息用于初始化远程调用。在 gRPC 中，请求消息始终由客户端应用程序来触发，它包含 3 部分：

请求头信息
以长度作为前缀的消息
流结束标记（end of stream flag，以下简称 EOS 标记），
如图所示。远程调用在客户端发送请求头信息之后就会初始化，然后其中会发送以长度作为前缀的消息，最后发送 EOS 标记，通知收件方请求消息已发送。

1. 背景与挑战

近年来，大模型由于良好的模型效果和广阔的应用前景，逐渐受到业界的广泛重视。主流的 AI 科技公司也站在了大模型研究的前沿，模型参数量的规模呈现快速增长的趋势。从 2018 年 1 亿参数规模的模型增长至今已达千亿参数量规模。

​

大模型的出现给模型训练带来极大的挑战。即使使用 A800、H800 这样的 GPU，单张 GPU 的算力和显存都是远远无法满足大模型训练需求的。为了保证大模型可训练，并提高整体训练吞吐，需要用到模型并行 + 数据并行等技术。

​

这张图展示的是大模型分布式训练技术的发展历程。

对于十亿及以下的模型，单卡往往就能放下全量模型参数和梯度，传统的数据并行即可即可覆盖其应用场景。当模型规模到了百亿量级以后，需要使用分组参数切片的方式将模型参数、梯度和优化器状态切分到各个卡上，保证单机可放下。当模型规模到了千亿以后，则需要同时使用模型并行、数据并行等多种并行技术混合进行高效训练。在这个阶段里，分布式并行技术从单一的基础并行策略演进为多种并行策略的组合。

当模型规模到了万亿级别以后，稠密模型已经难以高效训练，从而衍生出稀疏专家模型，也伴随着 MoE 等并行策略的演进与迭代。

下面，我将为大家介绍飞桨在大模型训练领域的特色分布式训练技术。

1. 向量检索应用简介

向量是多维数学空间里的一个点，在各维度上的坐标的一串数字。这个点就是来源于真实世界的物体进行数字化之后在数学空间的投影。那么不同点之间有一个数学关系，就是距离，距离远近就代表两个物体的相似程度。

​

非结构化数据转换成向量的过程称为 embedding。通过深度学习的训练，可以将真实世界数字化后的离散特征提取出来，投影到数学空间上，成为一个数学意义上的向量，同时很神奇的保留着通过向量之间的距离表示语义相似度的能力，这就是 embedding 的效果。

​

在大语言模型出现之前（2020 年以前），向量检索这项技术就已经发展成熟。随着深度学习的技术，广泛应用于图片、音频、视频的搜索和推荐、人脸识别、语音识别等传统人工智能应用领域。

​

大模型的出现改变了人机交互方式，带来了人工智能技术的新革命，一下子火起来，进入了一个大模型的时代。当然现在处于初期阶段，在实际应用上还存在很多问题。

1. 从机器学习到百模大战

众所周知，目前我们实现人工智能的主要技术手段是机器学习技术，特别是其中基于深层神经网络的深度学习技术。机器学习的本质是通过具有学习能力的算法、对数据进行建模的技术。深度学习借助大规模的算力解决了机器学习中特征表示的人工干预的瓶颈，在效果上取得了巨大突破。因此，机器学习成为目前人工智能的主流技术。

深度学习和生成式大模型之间的关系，如下图右侧所示，在 2012 年至 2016 年左右，像卷积神经网络、对抗生成网络、ResNet 等经典的深度学习模型，已经在计算视觉、语音识别、自然语言处理等领域取得了显著的效果提升。这些经典深度学习模型既有判别式、也有生成式，它们往往会在 ImageNet、COCO 等有标注的数据集上进行预训练，形成带有预训练权重、可以进一步进行 Fine-tuning 的预训练模型。

在 2017 年之后，Transformer 结构在自然语言处理领域首先被成功应用，在这之后以 Transformer 为基础组件的生成式大模型逐步成为视觉、自然语言处理、跨模态理解和生成领域的主流技术。这类技术通常以 Transformer 和注意力机制作为组件，并且它可以并行地进行自监督学习，参数规模在十亿以上。其中，将生成式大模型技术应用在语言建模上的方式，被称为「大语言模型」。在经过进一步的调优之后，形成了像 ChatGPT、文心一言等被大家熟知的对话式、生成式大语言模型应用。

​

在过去的半年，我们经历了一场百模大战。尤其是在开源社区，新的大模型如雨后春笋般涌现，而大模型相关的技术也越来越标准化、同质化。在这里为大家分享一个小故事。我们可以在大模型中了解到很多「驼」系英语词汇，比如 Llama 是美洲驼，Alpaca 是羊驼，Vicuna 是小羊驼。

为什么有那么多以「驼」命名的大语言模型？因为大语言模型 Large Language Model 的缩写是 LLM，2 个 L 放在一起不方便读出来，Meta 公司为了方便大家记忆，所以选了相近的词语 Llama（美洲驼）。后来很多基于 Llama 开源模型进行调优和构建的大语言模型，都以「驼」系的名称命名。

如下图所示，我们可以看到在硅谷的大模型创业公司中，除 OpenAI 外，目前已有将近 1/3 的资金投入了 MLOps 和 LMOps 相关的平台和工具方向。接下来，我将为大家详细拆解，在百模大战的背后，为什么 MLOps 和 LMOps 平台和工具能够获得资本的青睐。

​

首先看看大模型在技术和应用层面带来了哪些变化。比如在以下 4 个技术层面：

1. 大模型训练对网络的要求

我们先来聊聊大模型训练对网络的需求。

最近半年以来大模型持续火爆。虽然关于大模型的发展与应用还有很多的争论，但可以肯定的是，大模型能力已经成为了接下来人工智能发展的基础。

和以前的小模型相比，大模型对大规模的分布式并行训练有更强的诉求。

这一方面是因为模型本身非常大。受制于今天的 GPU 显存限制，我们不得不把一个模型分拆到很多个 GPU 上来存储。比如说，百度的文心大模型有 2600 亿个参数，但是实际上一个 80G 显存的 A800，算上训练中间的计算状态，也只能存放大概 10 亿-20 亿参数。那显然光是存放 2600 亿的模型本身，就需要一两百块 GPU。这已经是一个比较大的规模了。

另一方面，因为训练更多的参数需要更多的计算量，因此我们必须得引入更大规模的 GPU 来进行加速，所以我们需要的 GPU 又要有一个数量级的提升。

在百度我们根据一个任务的 GPU 卡数来命名训练的规模。比如百卡以下我们叫小规模，百卡到千卡我们叫中规模，千卡以上我们叫大规模，超过万卡我们则以超大规模进行命名。依照这个命名方式，我们可以说，千卡以上的大规模并行训练是大模型成功的基础。

​

分布式并行训练有多种策略，我们这里列举出常用的三种。

NLP的技术原理

首先，我们要弄明白，NLP任务（自然语言处理，AI的一个技术领域，即文本类的AI任务）的核心逻辑是一个“猜概率”的游戏。

比如说，“我今天被我朋友___”，经过大量的数据训练后，AI预测空格出会出现的最高概率的词是“放鸽子了”，那么CPU就会被填到这个空格中，从而答案产生——“我今天被我朋友放鸽子了”

虽然非常不可思议，但事实就是这样，现阶段所有的NLP任务，都不意味着机器真正理解这个世界，他只是在玩文字游戏，进行一次又一次的概率解谜，本质上和我们玩报纸上的填字游戏是一个逻辑。只是我们靠知识和智慧，AI靠概率计算。

在近几年的自然语言处理领域中，BERT和GPT是两个引起广泛关注的语言模型。特别是在GPT3.5的基础上进行微调的chatGPT，持续出圈和火爆。chatGPT的火爆表明了预训练语言模型在自然语言处理领域具有巨大的潜力，并且在提高自然语言理解和生成能力方面取得了显著的进展。这可能会带来更多的应用和更广泛的接受。

BERT和GPT也都是基于预训练语言模型的思想，通过大量的语料训练而得到的高效率的语言模型。为了帮助大家更好的理解和选择不同的技术和模型，本文将着重比较BERT和GPT这两个语言模型之间的区别，为大家提供一个全面的认识。

在设计系统时，应该多考虑 墨菲定律：

• 任何事物都没有表面看起来那么简单。
• 所有的事都会比你预计的时间长。
• 可能出错的事总会出错。
• 如果你担心某种情况发生，那么他就更有可能发生。

在划分系统时，应该多考虑 康威定律：

• 系统架构是公司组织架构的反映。
• 应该按照业务闭环进行系统拆分／组织架构划分，实现闭环／高内聚／低耦合，减少沟通成本。
• 如果沟通出现问题，那么应该考虑进行系统和组织架构的调整。
• 在合适时机进行系统拆分，不要一开始就把系统／服务拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高。

copy from: https://www.zybuluo.com/TryLoveCatch/note/1809593

研发工程师的基本功

1. 需求的交付能力；
2. 系统的设计与架构能力；
3. 行业对标与演化改进能力；

想要系统化的提升基本功，首先要全面的对我们所接触到的技术要素做分解，站在全局进行思考。

规划

• 为什么要做？
  以客户为中心，从业务角度出发，业务最关心什么，我们不做会不会影响业务的核心指标
• 为什么现在做？
  时间上 dead line
• 为什么是我们做？
• 怎么做
  拆解

一个规划应该主要分为：

• 背景
  业务理解，内部现状、业务影响、外部变化、背景总结
• 目标
  根据背景要能推出来目标，也可分短期和长期目标，或者业务目标和技术目标，或者定性目标和定量目标
• 方案
  方案是要解决背景中遇到的问题
• 指标
  如果衡量结果的好坏呢
• 规划
  具体的方案拆解，子任务拆解，具体到人和时间，每一个子任务应该是里程碑
• 风险以及应对
  技术风险、资源风险、质量风险等或者业务维度（抓重点解决核心问题）、技术维度（难度）、组织维度（资源不足）、流程维度

技术要素拆分法（BeafQPS）

组成

1. 行业对标 Benchmark
2. 效率 Efficiency
3. 架构 Architecture
4. 功能 Feature
5. 质量 Quality
6. 性能 Performance
7. 安全 Security

1.监控

1.1 监控的目的

• 了解业务量级增长
• 感知系统健康度
• 告警 -> 及时发现问题

可用性量化： MTTF， MTTR， SLA， SLO

1.2 好的监控体系应该做到哪些？

• 指标全面，但不冗余.
• 报警敏感，但不误报
• 自动发现问题，以及分析原因

1.3 监控指标

USE (Utilization Saturation and Errors）： 将注意力集中在处理工作负载的资源上。目标是了解这些资源在存在负载时的行为方式。

• 使用率，表示资源用于服务的时间或容量百分比。100% 的使用率，表示容量已经用尽或者全部时间都用于服务。
• 饱和度，表示资源的繁忙程度，通常与等待队列的长度相关。100% 的饱和度，表示资源无法接受更多的请求。
• 错误数表示发生错误的事件个数。错误数越多，表明系统的问题越严重。

RED（Request Throughput，Error Rate, Duration Time）: 它是由资源提供服务的工作负载行为的外部可见视图

四个黄金信号: 延迟（Latency），流量（Traffic），错误（Errors）和 饱和度（Saturation）