关于人工智能大模型的几点思考

清华大学郑纬民 报告内容 人工智能进入大模型时代 行业+ AI AI基础大模型 加速行业智能化升级，开始创造更大价值 从单模态向多模态发展 ChatGPT实现真正像人类一样来聊天交流 文本交互 MidjourneyAIGC画作《太空歌剧院》获得人类艺术比赛冠军 阿里云视频生成大模型I2VGen-XL，上传1张图后2分钟生成高清视频 报告内容 ， 数据获取 ， 数据获取 大模型训练需要收集海量多模态小文件 多模态：文本、音频、图像、视频特点：任一模态的数据集包含多达数亿至数百亿个小文件 海量小文件的存储挑战——元数据管理难 扩展性要求高：存储100亿的小文件需要管理7TB元数据延迟要求高：典型要求百微秒级读取延迟，以满足数据分析、模型训练等应用的需求因元数据瓶颈，现有系统延迟在毫秒级,如Ceph 小文件读取，元数据开销成瓶颈 问题：现有分布式文件系统无法同时满足可扩展和低延迟的需求 —元数据分布式管理架构(CephFS)：可横向扩展，但访问延迟高 低延迟：将目录元数据集中在一台目录元数据服务器中，实现路径解析的低延迟路径解析在目录元数据服务器本地完成，无跨网开销 可扩展：将文件元数据分布到多台文件元数据服务器中，支持文件数目横向可扩展 文件元数据服务器之间无共享，扩展性好 [1]SingularFS: A Billion-Scale Distributed File System Using a Single Metadata Server,USENIXATC’23 2023年5月(ISC23):IO500总分全球第一2023年11月(SC23):IO500总分全球第一2024年5月(ISC24): IO500总分全球第一 数据获取 据谷歌数据中心统计，30%的训练时间用于数据预处理[1]微软分析了9种常见模型，数据预处理最多占用65%的模型训练时间[2] 数据预处理挑战：预处理需要从分布式文件系统读取数据，开销大 需要处理的数据分散在多个节点上，读远端节点的数据会引入极大的网络开销已有的方法通常以计算为中心，将需要处理的数据搬移到进行计算任务的节点 解决方法：提出以数据为中心，将计算任务搬到数据节点上 将计算任务动态地根据其需要的数据调度到数据所在的节点上从分布式系统的数据读入转换成从本地文件系统读入 诸葛弩大数据处理引擎的设计理念： 以数据为中心的执行模式：数据读入开销低，动态负载均衡 兼容PySpark编程接口：对PySpark用户没有额外的学习成本采用大量编译优化技术：通过静态分析、算子融合、向量化、紧凑化数据排布等编译技术，降低数据处理开销提供良好的编程接口：提供基于C++RDD编程接口，供性能工程师编写高性能计算模块，嵌入端到端PySpark数据预处理管线中 数据获取 模型训练对分布式技术的挑战 原因：对于十万卡规模万亿参数量检查点读写 默认策略：采用每个专家的0号进程写数据方案1(单超节点写)：负载不均(超过10小时)方案2(跨超节点写)：进程数少(~3小时) 影响性能核心因素：存储系统架构 神威平台存储系统与计算网络系统共享同一套链路网络利用效率会直接影响存储系统性能 默认读写策略性能差的因素： 进程数不足：无法充分利用网络链路带宽负载不均：进程分布不均匀，无法利用所有交换机资源 采用分布式检查点策略 解决思路：分布式检查点策略 调整检查点处理适应神威平台的存储架构特点 效果：十万亿参数量模型每次检查点~10分钟 数据获取 模型推理 数据获取 报告内容 外部限制强化，中国AI内循环加速到来 国家力量推动智算中心建设，引导国产算力发展•上海：到2025年新建智算中心国产算力使用占比超50% •北京：智算基础设施2027年实现100%国产算力覆盖•江苏：要求新建算力中心国产算力使用占比达70%以上•其他：在建的杭州人工智能计算中心、贵安人工智能计算中心等均采用100%国产算力部署 国产AI芯片只要达到国外芯片60%的性能，如果生态做好了，客户也会满意。 大多数任务不会因为芯片性能只有60%而有明显感知，大家感觉到的不好用还是生态不行。 国产算力基础软件层 在神威新一代超级计算机上研制了大模型训练加速系统：八卦炉 八卦炉：支撑国产AI算力的基础软件集 扩展到全机规模（10万台服务器）目前正适配八卦炉系统支持更多国产芯片 PowerFusion：面向国产AI芯片智能编译器 FastMoE：MOE大模型并行加速系统 Einet：图算融合智能编译器 八卦炉支撑多个大模型的训练任务：北京智源研究院悟道2.0、阿里巴巴M6大模型等 八卦炉+国产超算 神威E级超级计算机（算力等效1.8万块A100） 支撑多个AIforScience应用程序： 实现百万亿参数量预训练模型加速 跨尺度大气预测模型：swMPAS-A第一性原理大模型：乾坤Net 模型规模：174万亿参数量（世界最大）训练性能：1.18 EFLOPS（世界最快）运行规模：3700万处理器核 目前“八卦炉”已经在国产超算系统成功移植百川、LLAMA等大模型 精度验证：国产超算与其它平台一致 Baichuan-7b精调任务：精度与百川公司实现对齐LLaMA-7b预训练任务：与NVIDIA实现loss曲线对齐 硬件环境 GPU：512×沐曦曦云C500系列GPU卡机内互连：4卡间高速互连，前后4卡PCIe 5.0机间互连：每机配备2个400GbIB卡 LLAMA-70B：广泛使用的benchmark模型 稠密模型Global batch size设置为256 MoE-567B:MOE模型是目前大模型发展趋势 稀疏模型参数量大，每token计算量与LLAMA持平Global batch size设置为64和1024 提升算子效率:计算密集型算子和访存密集型算子开展优化改进并行方案:减少通信量、提高硬件利用率底层系统支持:提高内存利用率和通信效率 “八卦炉”优化沐曦512卡智算集群训练任务，平均性能提升30% 部分优化后算子效率提升300%并行方案效率提升整体性能≥10%数据并行相关集合通信带宽提升50%Llama 70B模型，性能提升15%MoE567B模型(Batchsize=64)，性能提升31%MoE567B模型(Batchsize=1024)，性能提升45% 优化前后，精度曲线保持一致 混合专家模型（MoE）已成为扩展模型规模的主流手段传统的MoE模型训练采用数据并行或专家并行方式，难以解决显存容量不足、网络通信量过大、集群负载不均衡等问题FastMoE采用新的并行策略，解决了上述问题经移植，已在摩尔线程MCCX-D800 8卡机取得1.32倍加速比 加速比（以MEGATRON为基准） Megatron（专家并行） 基础算子性能是制约AI大模型性能的主要因素之一IntelliGen编译器擅长为Attention等访存密集型算子自动生成高性能执行代码经初步移植，已能在摩尔线程S4000上取得2.95倍加速在其他平台上IntelliGen可取得20×加速，还有进一步提升空间 容量挑战：GPU显存容量难以满足大模型推理的需求 为节省算力，必需保存kv-cache，即推理过程的历史中间结果随着生成序列越来越长，kv-cache大小线性增加以万亿模型为例:•模型大小2TB，至少需26张显卡•KV-Cache大小为7TB，还需要86张显卡345678910所需显存大小/ TB 挑战：如何为kv-cache设计高容量、高带宽的存储系统？ 假设显存大小为80GB，batch size为8，序列长度128k 解决思路：使用闲置CPU和主存来处理KV-Cache KV-Cache处理所需计算/访存比例更适合CPUCPU主存容量更大，可容纳更多KV-Cache，同时处理更多序列例子：仅需4台CPU服务器，即可容纳8TB的KV-Cache优势1：Batch size不再受到KV-Cache显存占用限制，GPU利用率提升优势2：聚合存储带宽高，KV-Cache处理吞吐量提升，成本降低 清程pro推理服务器 清程max推理机柜 Llama-13b模型 某国产130b模型 清程Pro相比云燧S60+vLLM提升1.7倍吞吐 清程Max相比原有方案吞吐量提升7.6倍吞吐 清程Max提升5.4倍吞吐 所用数据越多算力缺口越大 模型越大推理成本越高 _Kimi底层推理架构，承载其80%以上的流量以存换算！提升Kimi吞吐75%以上以超大规模分离式内存池为中心的KVCache缓存和调度用户体验（SLO）优先、面向过载场景的调度策略icon 更多可参见：https://github.com/kvcache-ai/MooncakeMooncake (1):在月之暗面做月饼，Kimi以KVCache为中心的分离式推理架构 KVCache缓存的关键：存的多，传得快，性价比高！ 充分利用当前GPU集群中闲置的内存容量和互联带宽 省成本的同时降低响应延迟 基于采样Kimi真实负载的模拟实验 本系统使用10个预填充个实例和10个解码模拟实例（Mooncake-[10P+10D]），vLLM使用20个标准模拟实例（vLLM-[20M]） 在满足SLOs的前提下，Mooncake-[10P+10D]相较于vLLM-[20M]可多处理75%的请求 报告内容 报告内容 02 03 大模型正在重新定义软件 Large Language Model Is Redefining The Software