作者 | 陈崇沛
从互联网时代到 AI 时代，架构设计承受不小的冲击。原本互联网架构是用来解决高并发这样的 IO 密集场景中所遇到的问题，面对 AI 时代的海量计算，传统架构束手无策。近两年，预训练大模型大行其道，进一步加剧了传统架构和 AI 系统架构之间的矛盾，如何让预训练大模型落地，是 AI 系统架构不得不面对的问题。
7 月 15 日，IDEA 研究院认知计算与自然语言研究中心 AI 系统架构师陈崇沛，在 ArchSummit 全球架构师峰会深圳站上，回以《预训练模型的 AI 系统实战》为题，回顾系统架构发展的历史脉络，分享他的实战经验，并与现场观众共同探讨了未来 AI 系统架构之路。
技术变迁和架构升级
近 10 年来，技术和架构的应用场景从在线（Online）逐渐发展到智能（Smart），从企业办公软件发展到电子商务、网络游戏，再演变到如今最热的短视频（推荐智能）和自动驾驶，流量越来越大，数据越来越大，软件也越来越“懂人”（智能化）。
企业软件时代以小并发情景下的单体软件为主，为企业管理提供信息化手段，解决办法是以微内核为基础，以插件化为手段。典型代表是 J2EE 企业架构，但这一架构存在的问题是，无法解决 to C 场景下的海量并发。
进入互联网时代，以流量大和数据量大为特征的微服务系统迅速占据架构主流，传统的单体架构向模块化和服务化演进。
2017 年，Tensorflow1.0 正式发布，吹响了 AI 工程化的号角，大量的视觉、NLP 和推荐广告深度学习算法模型纷纷上马，让在线系统承担了很大的计算压力，原来的 CPU 服务器越来越难以提供深度学习模型所需要的算力，随着模型体量越来越大，对在线系统的性能要求也越来越高。
当大模型的效果越来越好，预训练大模型如何落地？这是架构设计不得不面对、不得不回答的问题。
一套架构
两类模型，两个答案
针对上文提到的架构问题和技术痛点，我们的研究团队提出了一套架构思路，并通过两个产品实现它。
首先将足够多的预训练模型作为基础模型，覆盖不同的垂直领域、不同的模型结构、不同的应用场景。然后提供一套自动化生产机制，根据用户细分场景数据，自动化地生产出能满足用户实际需要的定制化小模型。用这两个方法解决预训练成本高、模型生产人力短缺的问题，我们给出实现这套架构思想的两个产品：GTSfactory 模型自动化生产平台、封神榜开源大模型体系。
GTSfactory
模型自动生产系统
解决海量定制模型的问题
GTS 是什么？多模型协作体系
GTS 是什么：Generator, Teacher, Student，一套多模型协作体系。
Generator ：数据增强，文本生成。
Teacher：小样本学习大模型，作为 Generator 模型的 Teacher，帮助 S 生产最终模型，在数据准备阶段也会提供标签检测能力。
Student ：最终小模型生产的主角，串联 Generator 模型和 Teacher 模型，整合各种下游优化的技巧。
Generator 模型和 Teacher 模型以封神榜大模型为基础模型。Teacher 用到了封神榜的二郎神模型和 39 亿 Bert 模型，G 用到了 50 亿样本生产模型。
GTS 又是什么？把算法做成系统
GTS 又是什么，Generator Training System，从模型协作的算法体系，转化成一套系统，进行模型自动化生产。
Generator：通用任务。支持多种分类，支持信息提取任务，支持多任务。
Training：融合多种学习范式。融合了 Multi-Task Learning，Meta Learning，Incremental Learning，AutoML 等算法技术。
System：自动化训练生产。结合交互式学习、任务编排、3 级调度器、多云算力系统来达到自动化模型生产的目的。
这套训练系统和一般的机器学习平台有什么区别？一般的机器学习平台是算法工程师模型结构研发和模型效果调试的开发工具，主要用来设计模型结构，给算法调整参数以到达理想效果，再配合一些外围的监控工具，提升模型研发的效率。
而 GTS 系统是用来自动化生产模型，满足不同任务、少量样本的模型生产，并且生产出来的模型效果好（甚至好于一般算法工程师）。由于这套系统不涉及到具体的算法开发环节，甚至用户都可以不懂算法，所以我们设计一套自动化生产机制，不仅能管理好底层的算力，体验上还需要可与算法交互，使得模型能不断迭代进化。总结一下，这套 GTS 系统几大特性：交互式学习、多任务编排、多级调度器、统筹多云算力。
三级调度机制：GTS 多模型协作的整体设计
我们重点展开讲讲 GTS 系统的三级调度机制。为了让系统能支持多种学习范式，支持不同模式的模型生产，需要有一套训练任务的编排机制，能对 G 模型、T 模型和 S 模型进行联合的编排，并且能支持循环控制和条件控制，我们在 Kubeflow Pipeline 的基础上，设计了任务编排的能力，使得训练任务之间可以进行复杂的编排。向训练任务开放调度 API，使得 S 模型训练任务可以异步进行 G 模型和 T 模型的数据增强训练任务——这就是我们第三级的调度能力，支持 DAG 任务编排，在 DAG 任务内能进行批任务调度和异步任务调度。
第二级的调度能力是任务调度能力，我们通过 arena 来支持批调度，配合 Kubernetes 的原生单体调度，使得第一阶段的 DAG 图编译成的 yaml 文件能被调度器调度，能顺利执行 DAG 图定义好的执行顺序和并行策略。
最后一级的调度，是对操作系统资源的调度，为了让计算效率更高，算力能更充分地被使用，我们支持 GPU 维度的虚拟化，为了避免数据在 CPU-GPU、GPU-GPU 之间传输造成 IO 瓶颈，我们在拓扑感知的基础上支持了拓扑亲和性的调度。
通过这套三级调度机制，我们让 GTS 模型之间的协同能更灵活地进行，让 GPU 算力能更充分地被使用。
总结这套 GTS 系统的价值：1、用模型自动化生产流程来支持复杂训练体系；2、一种新的人机交互方式，模型给人提出问题、人给模型提供反馈；3、协同管理多个算力池。
封神榜
开源的预训练大模型
解决预训练成本高的问题
预训练模型的痛点：生产成本高、难度大、中文模型少
英伟达今年刚发布的 H100 显卡，显存仍然是 80G，对比上一代显卡 A100 的显存没有提升。显存瓶颈是高带宽成本决定的，显存本身的制造成本并不算高，显存的提升最终要体现到计算上，需要 PCIE、Nvlink、CPU 高速缓存一起提升，我们知道 CPU 高速缓存已经按照 MB 来计价，这样整体成本提升就变得非常高了。
如果有一套优化好的模型训练框架，不就能大大降低训练门槛？再如果有开源的预训练模型可以直接拿来用，不就不用生产了？皆大欢喜。
FengShen 训练框架，浓缩了我们的训练技巧
我们在预训练大模型的过程中发现，现有的框架存在各自的缺点。Megatron-LM，支持模型少，用户定制化成本高；Pytorch-Lightning ，没有自己的模型库；HuggingFace，预训练示例少；DeepSpeed，没有好用的 Pipeline。
有没有办法可以取众之长，避众之短呢？我们在这些开源模型的基础上，研发并开源了一套训练框架 ：FengShen。
借助 HuggingFace 的生态进行开源，基于 Pytorch-Lightning 的方式进行开发，集成 Deepspeed、Megatron 等优势，实现一套属于 FengShen 的 Pipeline。得益于 Pytorch-Lightning 的便利性，训练者能快速实现自己的创新点，同时能及时集成业界最新解决方案到封神榜系列大模型上。统一的 Pipeline 规范了模型的生成，减少重复代码的编写，提高了生产性能及效率。这一框架集成 DeepSpeed、Megatron 等框架的先进点，适配百亿模型和海量数据集。支持大模型的生产，显著降低大模型的使用门槛。
在 FengShen 框架下，支持单卡百亿级别内的模型 finetune，对使用者来说，一个脚本就能快速将我们的成果应用到不同的下游任务中。
预训练大模型的生产系统
怎么完成中文预训练模型的目标，追上 Huggingface（万个中文预训练模型），达成我们的中文预训练模型开源目标？我们要有一套高效生产中文预训练模型的系统。
如何搭建这套系统：
我们建立了自己的数据体系和预训练基础，保证模型能高效生产；
从多个维度增加中文预训练基础模型；
未了方便用户使用封神榜大模型，我们开源 Fengshen 框架，可以拉取模型，用一套 Pipline 对模型进行继续训练或者 finetune，我们还在这套框架里面集成了一些训练的优化技术，也希望大家可以一起参与基础预训练模型的建设。
未来设想
下一代深度学习模型的
训练和部署系统和架构
当下预训练大模型的困境是，万亿以上的模型是真的训练不上去了。然而更大的模型仍然是有巨大价值的，怎么办呢？为了实现更高阶的人工智能。我们的假设是，模型应该是大而稀疏的，甚至模型中的专家都可以是动态变化的；计算必然是海量计算，而且要能池化治理，整个计算过程中还应该有弹性的特点；模型结构和计算应该是有中心的，两个中心还要能深度融合。针对上述假设，我们对未来 AI 架构设想是：大模型、多任务、多专家、稀疏激活的模型；智能调度多算法池的大规模算力系统；模型与算力系统有机结合，可以高效训练和部署稀疏、动态、多任务、多专家、多模态的大模型。我们将在这些技术领域上进行探索并努力把它变成现实。
