如何从零设计大模型基础设施

本文根据最近学习心得整理而成，主要阐明如何去设计一个大模型的 IT 基础设施，文章内容会保持在框架性方法层面，尽量避免具体细节绑定而产生的面向范围狭窄问题。

一．前期评估

首先，在开始设计之前，你必须明确自己搭建私有化大模型的目的所在，并对可投入的时间和成本有明确估算，确保在可行性评估上没有明显不通过项。

有些基本常识在设计前，需要再次重申，如下：

1. 建设大模型需要三个生产要素， IT 基础设施，算法模型和数据，同时需要相应技术人员。
2. 基于 GPU 的算力集群资源不仅贵，还紧缺，这个状况最保守估计在 2023 年底前不会改变，（个人认为在 2024 年上半年前也不会有大变化）。你需要克服困难去筹集 GPU 卡资源 ( 由于显存和通信带宽时延的能力差距，目前最适合大模型训练的仍然是 H100 ， 4090 只能承担推理 )
3. 前期的数据归集和预处理，以及后期的训练和微调，时间周期通常以月计，整个过程很难在几周内完成，在项目周期评估上要有心理准备。
4. 虽然大模型已经表现出了令人惊艳的能力，但私有化大模型通常面向垂直行业应用，最初得到的效果可能会有所不同，和数据质量，行业特点以及项目预期都有关系。

以上基本信息明确无误后，需要再次评估是否具备启动条件，如果以上问题都有好的答案或者解决方法，那么就可以进入设计阶段。

二．整体设计流程

分为三步：筛选模型，规模训练，适配部署

1．以最小规模，快速寻找最合适的模型

现在可用的开源模型已经相当丰富，但针对你的特定应用需求，必然有合适与不合适之分，在这一步，你需要寻找最优模型。如何评价最优？通常来讲，大模型训练的最终结果呈现都是“一个能够进行完成某些任务的辅助工具”， co-pilot 、副驾、数字助理都是非常形象的描述，评价好坏主要是看这个工具的准确度。

查找模型的过程，业界使用了另一个术语“超参数搜索（ Hyperparameter Search ）”来描述。 Lambda 的一份公开资料中有个图画得很形象，我这里借用一下

所谓超参数是在机器学习过程启动之前就预先设置的参数，典型的超参数有学习率 learning rate ，批次大小 batch_size ，迭代次数 Epoch ，影响模型泛化能力的正则化系数，和神经网络的结构参数层数，神经元数量，卷积核大小等。不同的超参数设定加在一起，基本就确定了具体模型。通常情况下，我们需要做超参数调整优化，选择一组最优超参数，以提高机器学习的性能和效果，得到最优模型。在实践中超参数调整一般使用人工设置调整的范围，然后用机器在超参数范围内进行搜索，这个过程称为超参数搜索。常见的基础超参数搜索方法通常有网络搜索 GridSearch 、随机搜索 RandomizedSearch 或者拉丁超立方采样 Latin hypercube 等，具体细节有很多公开资料介绍，这里不再深入。

超参数本质上是参数的参数，人工介入配置，每次改变调整超参数，模型都要重新训练，然后做相应的验证评估工作，一个轮次周期可能从几个小时到两三天不等。这时候的设置的硬件规模也可以比较小，甚至可以从一台有 GPU 的游戏笔记本电脑起步，只是时间周期可能会长，如果有三台 GPU 服务器，搜索周期一定会大大缩短，毕竟算力决定时间；并且由于资源的保障，也可以考虑每台服务器并行跑不同的模型，这样更快出结果

2．按需扩大至设计规模，进行训练和微调

找到了最适合的模型之后，那就该“动真格的了”，上规模。至于是扩展到几十台服务还是几万台，一得看设计预期，二得看预算和硬件资源筹集能力。在无视第二点“可能的实际困难情况下，我们看看如何分析需求：

2.1 需求分析

设计构建训练集群的基础设施时，主要是分析算力需求，总算力需求的计算方法可以参考以下公式，并适当考虑余量

训练总算力需求 = 模型的参数量 x 训练数据的 token 数 x 6

其中， 6 这个倍数是 Transformer 架构所决定的，因为每个 token 在模型正向传播时会做一次乘法和一次加法，而反向传播做两次乘法和两次加法，合计总计算次数为 6 。

注：神经网络通常是左边若干个神经元，右边若干个神经元，组成一个完全二分图。假设我们选出其中任意两个：左边的神经元 P 和右边的神经元 N 。

正向传播的时候：

P 把它的输出乘上 P 和 N 之间的权重 w ，发给 N ； 乘法 1
N 连了多个神经元 P ，因此要加到一起，这就是 reduce ，需要一次加法。 加法 1

反向传播的时候：

N 把它收到的梯度乘上 P 和 N 之间的权重 w ，发给 P ； 乘法 2
P 同样连了多个 N ，需要把梯度 reduce 一下，也做个加法； 加法 2

除外，权重 w 需要更新，那就要计算 w 的梯度，

把 N 收到的梯度乘上 P 正向传播的输出（ activation ）； 乘法 3

一个 batch 一般有多个 sample ，

权重 w 的更新需要把这些 sample 的梯度加到一起。） 加法 3

因此一共是三次乘法和三次加法，计算总量的倍数就是 6

而推理算力需求可以参考公式，如下：（至于如何推出的公式，这里就不细说了）

推理总算力需求 = 2 x 输出 token 数量 x 参数数量 flops

至于 GPU 算力，主要的网卡公开资料也都有，如下表：

其中 A100 和 H100 训练和推理都适合，但 4090 只适合做推理，通信能力和显存都太低，非常拖累训练效率，基本可以认为不可用。

需求的算力可以计算，典型GPU算力也有数据，让两部分得到匹配，需求分析的基本工作就可以完成了，接下来就可以进入设计阶段。

如何设计管理大集群本就是一个很难的课题，尤其集群规模扩大到一定程度后，必须考虑节点数量带来的故障概率，所以如何设计故障域隔离，实现高可靠机制，组建多重高性能网络等，都是必须要考虑的因素。

总的来说， 整体系统设计可以分为三个层次：集群级，机柜级和节点级，下面逐个讨论。

2.2 集群设计

集群设计和在 IDC 的部署运维紧密相关，这个阶段都是非常基础的内容，设计从头出发，具体来说是 5 个方面：数据中心的状况、算力服务器、存储平台选择、高速网络，以及基础集群软件

数据中心 : 数据中心的 T 级标准，平面布局，机柜容量和每机柜电力容量

算力服务器：多少实际算力需求， 算力服务器的GPU 卡和接口配置等

存储：存储容量，并发性能，共享能力，高速缓存， GDS 兼容和优化

网络： IB 高速网络构建，复杂网络拓扑，冗余，并发，带外管理网络和监控网络，网络安全

基础软件：集群管理，任务调度，资源排布，容器和虚拟化，向量数据库等，包括最新的 InfiniBand 和 Nvidia 驱动， CUDA ， PyTorch 和其他大模型基础软件。

以上每一个方面展开来都有非常多的内容，也需要根据实际情况才能深入讨论，这里只能谈到设计原则。

2.3 机柜级设计

机柜级设计主要操心的是电源问题和机柜空间布置，可能需要机房管理的专业工程师和服务器存储网络的硬件工程师帮助你核对设备的电源规格，功率大小等电气参数，也需要核对设备的实际物理外形规格，包括几 U 高度，设备的深度和线缆长度等，所有这些和打算部署的机柜实际情况的匹配度都可能成为制约因素。特别是网络布局的实际落地，这部分情况会比较复杂，在大模型集群里，也许会存在 4 个网络：计算网络，存储网络，带外管理 IPMI 网络和入站管理网络。实际部署中，还可能会出现一个单独的核心网络机柜，这些都是在实际部署之前需要考虑的设计因素。

2.4 节点级设计

节点设计要关注的东西已经到 BOM 级别，但一般来说也只是集中到计算节点，而存储通常由存储方案商整体提供，存储节点内部的配置仅仅是知会或协商，小规模很难定制设计。

计算节点的配置已经有大量参考典型配置，你只需要关注几个重点： PCIe 的拓扑和代次， Lane 通道数量，这些对性能至关重要；另外 Numa 节点拓扑可能对 GPU 对等互联产生影响；同时，如果计算节点支持 NVlink ，能够避免通过 CPU 互连的数据传输瓶颈，在训练时会很有帮助。

3．部署和并提供推理能力

完成训练后，有两种选择，一是继续利用训练时候的集群提供服务，二是另行部署一套推理集群。第一种选择不用再重新设计，第二种选择需要根据推理集群的情况对以上设计适当修改。

推理集群通常高度适配某个行业应用，如果规模够大，另一端可能有数十万的用户调用，需要处理潜在的成千上万个并发请求，实时性是重要考虑因素。每一个推理请求都可能会有一个实际用户在等待推理结果，需要快速反馈答案，因此集群设计上除了前诉内容，还可以参考互联网应用的要求，具备高可用能力和 QoS ，对各种意外带来的中断都有应对机制，虽然不一定需要真正和用户签署小数点后很多个 9 的 SLA 协议，但是 SLA 必须要在心中。

另外，虽然部署的是相同的模型，但是实际处理的数据却不同，因此节点之间不会像训练时那样处理太多通信，不需要设计集群内部节点间的超高性能网络，满足高可用和冗余机制设计和一点点数据传输应该就可以了。

在不同阶段，设计要考虑的因素是不同的，我总结了一个表，如下：

三、总体集成和测试（可选）

系统部署完成后，理论上应该进行集成测试，但是利用大模型打造的应用可能出现多种形态，也不一定限于类似 ChatGPT 的问答式应用；同时垂直行业有自身的特点，需要紧密结合行业特点制定测试方案。

如果是通用型的大模型，考虑到国内基本还都是中文大模型和应用环境，目前有一个很好的中文知识能力测试数据集 [C-Eval] ， 1.4w 道选择题，涵盖共 52 个学科，从初中水平到大学再到专业水平，算是业界标杆测试之一