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

1. 清华大学郑纬民

2.

3. 报告内容

4. 人工智能进入大模型时代 AI基础大模型从单模态向多模态发展文本交互 ChatGPT实现真正像人类一样来聊天交流图像创作 Midjourney AIGC 画作《太空歌剧院》获得人类艺术比赛冠军视频生成阿里云视频生成大模型 I2VGen-XL，上传1张图后2分钟生成高清视频行业 + AI 加速行业智能化升级，开始创造更大价值 AI+金融企业财务异常识别准确率提升20% AI+智能制造输入小标题工业质检准确率提升14% AI+医疗 AI+司法药物研发周期从数年缩短到1个月智慧司法系统 AI+汽车 AI+气象自动驾驶智能网络比传统天气预报提速10000倍+

5. 报告内容

6. ，数据获取数据预处理模型训练模型微调模型推理获取不同类型的原始数据并存储随机读取训练样本进行预处理大数据大量数据经过模型需要海量算力精调垂域模型需要可控算力实时处理用户请求需要稳定可靠算力训练GPT4: 一万块A100 x 11月垂域模型: 基座模型精调需要算力实时的用户请求对算力需求强劲海量小文件存储对文件系统提出需求频繁、随机小样本读取对文件系统提出挑战

7. ，数据获取数据预处理模型训练模型微调模型推理获取不同类型的原始数据并存储随机读取训练样本进行预处理大数据大量数据经过模型需要海量算力精调垂域模型需要可控算力实时处理用户请求需要稳定可靠算力训练GPT4: 一万块A100 x 11月垂域模型: 基座模型精调需要算力实时的用户请求对算力需求强劲海量小文件存储对文件系统提出需求频繁、随机小样本读取对文件系统提出挑战

8. 大模型训练需要收集海量多模态小文件 Youtube 多模态：文本、音频、图像、视频 Common Crawl Dall-E数据集特点：任一模态的数据集包含多达数亿至数百亿个小文件海量小文件的存储挑战——元数据管理难 1亿音频文件 (< 2 MB) 扩展性要求高：存储100亿的小文件需要管理 7TB 元数据延迟要求高：典型要求百微秒级读取延迟，以满足数据分析、模型训练等应用的需求因元数据瓶颈，现有系统延迟在毫秒级, 如 Ceph 120亿图像文件 (< 20 KB) 100% 10% 65% 50% 数据部分元数据部分 0% 大文件 [1] https://help.aliyun.com/zh/oss/support/apsara-file-storage-nas 500亿网页文件 (< 8 KB) 小文件小文件读取，元数据开销成瓶颈

9. 问题：现有分布式文件系统无法同时满足可扩展和低延迟的需求 —元数据集中式管理架构 (HDFS、Lustre)：访问延迟低，但无法横向扩展 —元数据分布式管理架构 (CephFS) ：可横向扩展，但访问延迟高目录树目录树 / data home llm cv alice f 1 f 2 … f 3 f 4 f 5 f 6 bob f 7 … 采用元数据集中式管理架构的文件系统最大文件数 HDFS 1 亿 llm cv alice Lustre 40 亿 f 1 f 2 … f 3 f 4 f 5 data 元数据服务器2 元数据服务器元数据服务器1 / 能存储的最大文件数受限，无法支持AI场景的海量文件 home f 6 bob f 7 … 元数据服务器3 路径解析需跨多台元数据服务器，导致元数据延迟高，超过数据延迟两倍

10. 图例 / 目录元数据 / data 低延迟：将目录元数据集中在一台目录元数据服务器中，实现路径解析的低延迟 llm f 1 f 2 … f 3 文件元数据服务器之间无共享，扩展性好目录树 home cv alice bob f 4 f 5 f 6 f 7 f 8 … 解耦路径解析在目录元数据服务器本地完成，无跨网开销可扩展：将文件元数据分布到多台文件元数据服务器中，支持文件数目横向可扩展 f 文件元数据目录元数据服务器路径解析低延迟 f 1 f 2 f 3 文件元数据服务器1 … f 4 f 5 f 6 文件元数据服务器𝑛 文件数目可扩展

11. 文件操作延迟 1000 1645 1080 100 2031 59x 51x 10 1 File Create File Stat 文件操作 File Delete [1] SingularFS: A Billion-Scale Distributed File System Using a Single Metadata Server, USENIX ATC’ 23

12.  2023年5月 (ISC 23): IO 500总分全球第一  2023年11月 (SC 23): IO 500总分全球第一  2024年5月 (ISC 24): IO 500总分全球第一

13. 数据获取数据预处理模型训练模型微调模型推理获取不同类型的原始数据并存储随机读取训练样本进行预处理大数据大量数据经过模型需要海量算力精调垂域模型需要可控算力实时处理用户请求需要稳定可靠算力训练GPT4: 一万块A100 x 11月垂域模型: 基座模型精调需要算力实时的用户请求对算力需求强劲海量小文件存储对文件系统提出需求频繁、随机小样本读取对文件系统提出挑战

14. 据谷歌数据中心统计，30% 的训练时间用于数据预处理 [1] 微软分析了9种常见模型，数据预处理最多占用65% 的模型训练时间 [2] NVMe SSD 缓存随机采样数据解码变换 HDD [1] Murray D G, Simsa J, Klimovic A, et al. tf. data: A machine learning data processing framework. VLDB 2021. [2] Mohan J, Phanishayee A, Raniwala A, et al. Analyzing and mitigating data stalls in DNN training. arXiv 2020. … 模型计算

15. 数据预处理挑战：预处理需要从分布式文件系统读取数据，开销大已有的方法通常以计算为中心，将需要处理的数据搬移到进行计算任务的节点需要处理的数据分散在多个节点上，读远端节点的数据会引入极大的网络开销解决方法：提出以数据为中心，将计算任务搬到数据节点上将计算任务动态地根据其需要的数据调度到数据所在的节点上从分布式系统的数据读入转换成从本地文件系统读入管理节点 2. 反馈结果 1. 调度任务计算节点计算节点计算节点输入数据输入数据输入数据

16. 诸葛弩大数据处理引擎的设计理念：以数据为中心的执行模式：数据读入开销低，动态负载均衡兼容PySpark编程接口：对PySpark用户没有额外的学习成本采用大量编译优化技术：通过静态分析、算子融合、向量化、紧凑化数据排布等编译技术，降低数据处理开销提供良好的编程接口：提供基于C++ RDD编程接口，供性能工程师编写高性能计算模块，嵌入端到端PySpark数据预处理管线中领域支持层编译优化层 MinHash CCNet 诸葛弩Catalyst插件诸葛弩Python UDF编译器诸葛弩PySpark API 高效能底座层 …… 诸葛弩SDK (基于C++ RDD的扩展接口) 诸葛弩运行时

17. MinHash 流程删冗前的文本数据（JSON）文档的相似关系（JSON） SQL流程 MinHash时间（秒） RDD流程解析哈希计算 GroupBy 将JSON文件从文件系统中读入并解析成关系表格式 MinHashLSH 算法计算文档在各条带下的 MinHash值按照条带与哈希值进行分组写回 Join 生成边将表数据以 JSON格式写回文件系统将文档编号与文档属性关联每个条带下，相同MinHash 值的文档被视为相似，并生成边 Chukonu 100.24 PySpark 102.56 0 100 95.64 721.38 200 300 400 读写时间 500 计算时间 600 700 800 900

18. 数据获取数据预处理模型训练模型微调模型推理获取不同类型的原始数据并存储随机读取训练样本进行预处理大数据大量数据经过模型需要海量算力精调垂域模型需要可控算力实时处理用户请求需要稳定可靠算力训练GPT4: 一万块A100 x 11月垂域模型: 基座模型精调需要算力实时的用户请求对算力需求强劲海量小文件存储对文件系统提出需求频繁、随机小样本读取对文件系统提出挑战

19.

20. 模型训练对分布式技术的挑战原因：对于十万卡规模万亿参数量检查点读写默认策略：采用每个专家的0号进程写数据存储系统方案1 (单超节点写)：负载不均 (超过 10小时) 方案2 (跨超节点写)：进程数少 (~3小时) 顶层通信网络顶层存储网络影响性能核心因素：存储系统架构神威平台存储系统与计算网络系统共享同一套链路超节点超节点 … … … 超节点网络利用效率会直接影响存储系统性能默认读写策略性能差的因素：进程数不足：无法充分利用网络链路带宽负载不均：进程分布不均匀，无法利用所有交换机资源 … 新一代神威平台的存储与网络架构

21. 采用分布式检查点策略解决思路：分布式检查点策略调整检查点处理适应神威平台的存储架构特点效果：十万亿参数量模型每次检查点 ~10 分钟分布式检查点存储策略＞ 21 ＜

22. 数据获取数据预处理模型训练模型微调模型推理获取不同类型的原始数据并存储随机读取训练样本进行预处理大数据大量数据经过模型需要海量算力精调垂域模型需要可控算力实时处理用户请求需要稳定可靠算力训练GPT4: 一万块A100 x 11月垂域模型: 基座模型精调需要算力实时的用户请求对算力需求强劲海量小文件存储对文件系统提出需求频繁、随机小样本读取对文件系统提出挑战

23. 数据获取数据预处理模型训练模型微调模型推理获取不同类型的原始数据并存储随机读取训练样本进行预处理大数据大量数据经过模型需要海量算力精调垂域模型需要可控算力实时处理用户请求需要稳定可靠算力训练GPT4: 一万块A100 x 11月垂域模型: 基座模型精调需要算力实时的用户请求对算力需求强劲海量小文件存储对文件系统提出需求频繁、随机小样本读取对文件系统提出挑战

24. 报告内容

25.

26.

27. 外部限制强化，中国AI内循环加速到来国产AI算力总量和占比快速提升管制范围算力密度上限 AI模型 HBM >90% 时间 2024 2018 >50% AI要素全面进入本地化时代数据属地化算法主权化 2025 算力国产化国产算力非国产算力 2030 国家力量推动智算中心建设，引导国产算力发展 • • • • 上海：到2025年新建智算中心国产算力使用占比超50% 北京：智算基础设施2027年实现100%国产算力覆盖江苏：要求新建算力中心国产算力使用占比达70%以上其他：在建的杭州人工智能计算中心、贵安人工智能计算中心等均采用 100%国产算力部署数据来源：国家智能算力规划，公开资料整理

28.

29.

30. 并行系统 Megatron-LM 通信库编程框架算子库 AI编译器 cuBLAS NCCL cuDNN 编程语言调度器内存管理容错系统存储系统

31.

32. 团队自研系统并行加速 Megatron-LM 通信库编程框架算子库 SmartMoE cuBLAS cuDNN AI 编译器 NCCL EinNet 编程语言底层系统 Spread-n-Share 内存管理 Self Checkpoint 存储系统 PET

33. 国产AI芯片只要达到国外芯片60%的性能，如果生态做好了，客户也会满意。大多数任务不会因为芯片性能只有60%而有明显感知，大家感觉到的不好用还是生态不行。

34.

35. 国产算力基础软件层 “八卦炉”基础软件系统八卦炉：支撑国产AI算力的基础软件集 PowerFusion：面向国产AI芯片智能编译器 FastMoE：MOE大模型并行加速系统 Einet：图算融合智能编译器 FreeTensor：面向不规则智能程序编程语言 FastDecode：高吞吐大模型推理系统并行层并行加速计算层编程语言编译器加速库底层系统内存系统存储系统调度系统通信库容错系统模型规模：174 万亿参数量（世界最大）训练性能：1.18 EFLOPS （世界最快）运行规模：3700 万处理器核扩展到全机规模（10万台服务器）目前正适配八卦炉系统支持更多国产芯片八卦炉支撑多个大模型的训练任务：北京智源研究院悟道 2.0、阿里巴巴 M6 大模型等八卦炉 + 国产超算实现百万亿参数量预训练模型加速在神威新一代超级计算机上研制了大模型训练加速系统：八卦炉神威E级超级计算机（算力等效1.8万块 A100）支撑多个AI for Science 应用程序：跨尺度大气预测模型：swMPAS-A 第一性原理大模型：乾坤Net

36. 目前“八卦炉”已经在国产超算系统成功移植百川、LLAMA等大模型精度验证：国产超算与其它平台一致 Baichuan-7b 精调任务：精度与百川公司实现对齐 LLaMA-7b 预训练任务：与 NVIDIA 实现 loss 曲线对齐

37.

38.

39. 硬件环境 GPU：512 × 沐曦曦云C500系列GPU卡机内互连：4卡间高速互连，前后4卡 PCIe 5.0 机间互连：每机配备 2 个400Gb IB卡 LLAMA-70B：广泛使用的benchmark模型稠密模型 Global batch size设置为256 MoE-567B: MOE模型是目前大模型发展趋势稀疏模型参数量大，每token计算量与LLAMA持平 Global batch size设置为64和1024

40. 提升算子效率: 计算密集型算子和访存密集型算子开展优化改进并行方案: 减少通信量、提高硬件利用率底层系统支持: 提高内存利用率和通信效率

41. “八卦炉”优化沐曦512卡智算集群训练任务，平均性能提升30% 部分优化后算子效率提升300% 并行方案效率提升整体性能≥10% 数据并行相关集合通信带宽提升50% Llama 70B模型，性能提升15% MoE 567B模型 (Batchsize=64)，性能提升31% MoE 567B模型 (Batchsize=1024)，性能提升45% 优化前后，精度曲线保持一致

42.

43. 混合专家模型（MoE）已成为扩展模型规模的主流手段传统的MoE模型训练采用数据并行或专家并行方式，难以解决显存容量不足、网络通信量过大、集群负载不均衡等问题 FastMoE 采用新的并行策略，解决了上述问题经移植，已在摩尔线程 MCCX-D800 8卡机取得 1.32倍加速比加速比（以MEGATRON为基准） Megatron （专家并行） 1 1.32

44. 基础算子性能是制约 AI 大模型性能的主要因素之一 IntelliGen 编译器擅长为Attention等访存密集型算子自动生成高性能执行代码经初步移植，已能在摩尔线程 S4000 上取得 2.95倍加速在其他平台上 IntelliGen 可取得 20× 加速，还有进一步提升空间 2.95 1.96 PyTorch 1.43 1 1 GPT IntelliGen 1 B ERT V IT

45.

46. 容量挑战： GPU显存容量难以满足大模型推理的需求为节省算力，必需保存 kv-cache，即推理过程的历史中间结果随着生成序列越来越长，kv-cache 大小线性增加以万亿模型为例: • 模型大小 2TB，至少需 26 张显卡 • KV-Cache 大小为 7TB，还需要 86 张显卡挑战：如何为 kv-cache 设计高容量、高带宽的存储系统？所需显存大小 / TB 10 9 8 7 6 5 4 3 2 1 0 2048 8192 32768 131072 序列长度假设显存大小为 80GB，batch size 为 8，序列长度 128k 模型参数 kv-cache 其它

47. 解决思路：使用闲置 CPU 和主存来处理 KV-Cache KV-Cache处理所需计算 / 访存比例更适合CPU CPU主存容量更大，可容纳更多KV-Cache，同时处理更多序列例子：仅需4台CPU服务器，即可容纳8TB的KV-Cache 优势1：Batch size 不再受到 KV-Cache 显存占用限制，GPU 利用率提升优势2：聚合存储带宽高，KV-Cache 处理吞吐量提升，成本降低

48. 清程 pro 推理服务器清程 max 推理机柜 FastDecode 高吞吐推理软件系统 FastDecode 高吞吐推理软件系统燧原S60 燧原S60 推理燧原S60 推理燧原S60 加速卡推理加速卡推理加速卡加速卡 CPU CPU 大大大大大大大大大大大大大大大大容容容容容容容容容容容容容容容容量量量量量量量量量量量量量量量量主主主主主主主主主主主主主主主存主存存存存存存存存存存存存存存存 Attention 加速服务器 (纯CPU) Attention 加速服务器 (纯CPU) Attention 加速服务器 (纯CPU) 清程 pro 推理服务器高速本地网络

49. Llama-13b 模型某国产130b 模型清程 Pro 相比云燧S60+vLLM 提升 1.7 倍吞吐清程 Max 相比原有方案吞吐量提升 7.6 倍吞吐清程 Max 提升 5.4 倍吞吐清程 Pro 比英伟达A10+vLLM提升 1.3 倍 1394.092 1500 250 1200 205.795 200 900 600 300 450.297 350 258.8 300 14.983 0 13b模型均使用单燧原加速卡数值为生成长度1-1024的平均吞吐量。 150 75.772 100 50 27.585 10 0 130b模型均使用四块燧原加速卡+W8量化数值为生成长度1-1024的平均吞吐量。

50.

51.

52.

53. 所用数据越多算力缺口越大模型越大推理成本越高输入越长响应延迟越长

54. _ Kimi 底层推理架构，承载其 80% 以上的流量以存换算！提升 Kimi 吞吐 75% 以上以超大规模分离式内存池为中心的 KVCache- centric Conductor Cache- aware Prefill Scheduler Prefill Instance Paged KVCache Distributed KVCache Pool KVCache Balance Scheduler 景的调度策略 Local Chunked Prefill Scheduler GPU/VRAM PP/SP CPU/DRAM/SSD KVCache 缓存和调度用户体验（SLO）优先、面向过载场更多可参见： https://github.com/kvcache-ai/Mooncake Mooncake (1): 在月之暗面做月饼，Kimi 以 KVCache 为中心的分离式推理架构 Distributed KVCache Pool Load- balance Decoding Scheduler Paged KVCache CPU/DRAM/SSD Distributed KVCache Pool CPU/DRAM/SSD Distributed KVCache Pool GPU/VRAM GPU/VRAM 清华 KVCache.AI 团队 Local Chunked Prefill Scheduler Inter-node KVCache Transfer CPU/DRAM/SSD 月之暗面 + Prefill Instance GPU/VRAM icon Paged KVCache Paged KVCache Local Scheduler Decoding Instance Local Scheduler Decoding Instance

55. 所有查询可复用 User Question 1: 总结一下这篇论文 System Prompt: 你是一个论文阅读助手，… User Question 2: 这篇论文关键创新是什么 User Question 3: 有哪些相关研究？ User Question 4: 可以进一步探索什么？

56. KVCache 缓存的关键：存的多，传得快，性价比高！充分利用当前 GPU 集群中闲推理用机 2 推理用机 1 GPU 1-1 更新 X[1..s+1] 对应的 K/V向量置的内存容量和互联带宽 GPU 2-1 CPU/ DRAM/ SSD 装载 X[1..s] 对应的 K/V向量省成本的同时降低响应延迟 GPU/VRAM 透明多级缓存，未来可以进一 Prefix + tokens GPU/VRAM Paged KVCache Hash() 步下沉到底层廉价存储全局缓存节点 S3 PCIe 链路读缓存存储接口层读写缓存 Paged Paged KVCache KVCache SSD SSD SSD Paged Paged KVCache KVCache Paged Paged KVCache KVCache RDMA SSD SSD SSD NVMe-of 对象存储写缓冲 Paged Paged KVCache KVCache POSIX 并行存储系统 CPU/DRAM/SSD CPU/DRAM/SSD 下一级全局缓存

57. 基于采样 Kimi 真实负载的模拟实验本系统使用 10 个预填充个实例和 10 个解码模拟实例（Mooncake- [10P+10D]），vLLM 使用 20 个标准模拟实例（vLLM-[20M]）在满足 SLOs 的前提下， Mooncake-[10P+10D] 相较于 vLLM-[20M] 可多处理 75% 的请求注：TTFT 和 TBT 上限值分别设为 30s 和 0.1s

58.

59.

60.

61. 报告内容

62.

63.

64.

65.

66. 报告内容

67.

68. 01

69. 02 03

70.

71. 大模型正在重新定义软件 Large Language Model Is Redefining The Software