最近，PyTorch 团队首次公布了开发路线图，由内部技术文档直接修改而来，披露了这个经典开源库下一步的发展方向。如果你在 AI 领域用 Python 开发，想必 PyTorch 一定是你的老朋友之一。2017 年，Meta AI 发布了这个机器学习和深度学习领域的开源库，如今已经走到了第 7 个年头。根据 Assembly AI 2021 年的统计数据，HuggingFace 上最受欢迎的 top 30 模型都能在 PyTorch 上运行，有 92% 的模型是 PyTorch 专有的，这个占比让包括 TensorFlow 在内的一众竞争对手都望尘莫及。就在 7 月 10 日，PyTorch 的工程团队首次公开发布了他们的路线图文档，阐述 2024 年下半年的发展方向。Meta 共同创始人、领导 PyTorch 团队的 Soumith Chintala 在推特上官宣了这个消息。他表示，希望公开工程师们的研发动机和目标。「虽然所有 PyTorch 开发都在 GitHub 上公开，但各个 PyTorch 附属公司的团队编写的实际规划和路线图文档并不公开，因此我们决定做出改变，以提高透明度。」PyTorch 团队的技术项目经理 Gott Brath 也在论坛中发表了类似的声明。我们一直在考虑，如何分享团队在 PyTorch 上所做的工作的路线图。我们每半年进行一次规划，因此这些是我们针对 PyTorch 中多个关键领域的 2024 年 H2 OSS 计划的一些公开版本。这些文件基本就是 PyTorch 团队内部的文档和工作规划，删减掉了一些内容就发布出来成为路线图，其中涉及 PyTorch 的如下几个方面：- 核心库与核心性能- 分布式- torchune、Torchrec、TorchVision- PyTorch Edge- 数据加载（DataLoading）- 编译器核心及部署- 开发者基础设施每个文档都至少包含三个部分的内容，以 OKR 的思路展开：- 背景- Top5 关注领域及目标：目标、关键结果、已知或未知风险以及相应缓解措施（最多一页）- 提升工程水平的 Top3~5 个方面：BE Pillar 分类、目标、指标 / 状态 / 具体目标、已知或未知风险以及缓解措施、影响 / 成本、优先级 / 信心程度（最多一页）其中 BE Pillar 可以看作 Meta 写给开发团队的「五句箴言」，具体内容是：Better Code, Better Doc, Empowering teams, Modern Code, Better Architecture「最多一页」的规定不知道有没有戳到卷文档长度的开发人员，毕竟文档贵精不贵长，将众多开发需求精简到一页的内容不仅节省同事时间，也十分考验撰写者的功力。此外，文档中也可以看出 Meta 开发团队的一些优秀思路，比如重视各个模块团队的协作、重视和外部合作伙伴的 API 集成和共同开发，重视与开源社区和开发者的互动。当推出 ExecuTorch 这样的新代码库，或者想要提升 PyTorch 编译器影响力时，团队一般都会从两方面思路入手：一是铆足力气提升性能，把目标直接顶到 SOTA；另一方面从深度集成入手，提供更多开箱即用的案例。或许，这些都是 Meta 多年来在开源领域如鱼得水、风生水起的关键所在。以下是各个文档内容的部分截取和概括。原文地址：https://dev-discuss.pytorch.org/t/meta-pytorch-team-2024-h2-roadmaps/2226核心库与核心性能文档中涉及到的核心库包括 TendorDict、torchao、NN、TorchRL 等。性能方面，PyTorch 团队提出了在模型训练和推理方面实现 SOTA 性能的目标，措施包括引入架构优化技术和高性能 kernel，与整个 PyTorch 技术栈形成搭配组合。过去一年的时间见证了 GenAI 的快速发展，许多支持研究领域进行开发的外部库应运而生，但其中很多并不直接依赖 PyTorch，这会威胁到 PyTorch 在科研领域的主导地位。为了重新跟上节奏，PyTorch 将为量化、稀疏化、MoE 和低精度训练等常用开发技术提供支持，包括构建模块和 API（主要集成在 torchao 中），帮助各类 Transformer 架构的模型提升性能。torchao 库可以支持研究人员在 PyTorch 框架内自定义高性能的 dtype、layout 和优化技巧，将使用范围扩展到训练、推理、调优等各种场景。此外，核心库的更新将包括以下方面：- 推出的自动优化库 torchao 已经取得了突破性的成功，下一步提升其代码组织性，并将其中的数值运算与核心库分开- 解决 TendorDict 的核心模块性，支持加载 / 存储的序列化，并使其在 eager 模式下的运行速度提高 2 倍- 继续上半年在内存映射加载（memory mapped load）方面的成功，继续提升模型加载 / 存储的性能和安全性- 将 TorchRL 的开销降低 50%- 加入对 NoGIL 的核心支持- 修复用户反映的 TORCH_env 变量不起作用的问题文档中还提及了要实现对 nn.transformer 模块的弃用，表示会发布一系列教程和用例，展示如何使用 torch.compile、sdpa、NJT、FlexAttention、custom_op、torchao 等模块构建 Transformer。分布式LLM 的预训练通常横跨数十个甚至上千个 GPU，而且由于模型的参数规模逐渐增大，推理和微调也很难用单个 GPU 完成。因此，PyTorch 下一步对「分布式」的布局全面涵盖了训练、推理、微调这三个环节，提出要达成超大规模分布式训练、高内存效率的微调、多主机分布式推理。训练PyTorch 原生支持的并行模式主要包括以下几种：- 完全分片数据并行（full sharded data parallel，FSDP）- 混合分片数据并行（hybrid sharding data parallel，HSDP）- 张量并行（tensor parallel，TP）- 流水线并行（pipeline parallel，PP）- 序列并行（sequence parallel，SP）- 上下文并行（context parallel，CP）PyTorch 希望在 TorchTitan 中将各种并行方式进一步模块化，让开发者可以自由组合，根据需要实现 N 维并行。文档中特别提到，对 MoE 和多模态这两种新兴的架构需要添加支持，比如专家并行、路由算法的优化。除了 TorchTitan 本身的更新，分布式团队还需要与编译器团队进一步紧密合作，更好地与 torch.compile 模块集成，为大规模分布式场景带来额外的性能提升。微调与推理微调：联合 torchtune，将 FSDP2 LoRA / QLoRA 方案投入使用，以及支持模型状态字典的 NF4 量化推理：PP 和 DP 已经成为分布式 API 的核心，下一步需要关注 torchtitan 的分布式推理，支持大模型 PP + 异步 TP 方式，将给出案例展示文档中还提到，会将 HuggingFace 的推理 API 从 PiPPy 迁移到 PyTorch（由 HuggingFace 完成）。torchtune、TorchRec、TorchVisiontorchtunetorchtune 的推出旨在帮助用户更方便微调 LLM，这也是官方给出的 Llama 模型微调的方案。torchtune 定义的「微调」范围非常广，主要可以概括为三类场景：- 对特定领域数据集或者下游任务的模型适应- 奖励和偏好建模，比如 RLHF、DPO 等- 包含蒸馏与量化的训练过程下半年的更新将支持为 agent 工作流进行的微调，同时着重关注微调性能的提升。团队会与 compile、core、distributed 等模块进行合作，提供高效率微调，并在 PyTorch 生态内建立有代表性的微调性能基准。由于 torchtune 也是一个较新的开源库，因此与开源社区的互动也必不可少。文档提出发布博客文章和教程、举办技术讲座等方式，提升用户的理解；并会定义量化指标，衡量 torchturn 在 LLM 生态中的贡献份额。除了开源社区，torchtune 还会与至少一个合作伙伴集成，参与到它们的社区中，以促进 torchtune 的使用。TorchVisionTorchVision 作为 CV 领域内的绝对主宰者，技术也相对成熟，因此路线图中提出的更新很少。团队将继续在预处理方向努力，在图像编码 / 解码空间中支持更多格式（如 WebP、HEIC）和平台（如 CUDA），并提升 jpeg 格式在 GPU 上的编码 / 解码性能。TorchRecTorchRec 旨在提供大规模推荐系统中常用的稀疏性和并行性原语，将秋季推出第一个稳定版本 TorchRec 1.0。Edge目前，开源库 ExecuTorch 已经推出了 Alpha 版本，主要依赖 torch.compile 和 torch.export，用于支持移动设备和边缘设备（如 AR / VR、可穿戴设备）上的模型分析、调试和推理。下半年，Edge 团队将推出 xecuTorch 的 Beta 版本，同时为 Meta 的 Llama 系列模型和其他开源模型提供 PyTorch 生态内的解决方案。关键目标中主要涵盖两个方向。一是为设备上 AI 提供基础功能和可靠基础设施，包括：- 确保 C++ 和 Python 的 API 稳定性- 实现一系列核心功能：支持模型压缩、代理缓存位置管理、数据和程序分离二是为这个新生的代码库保驾护航，培育开源社区内的影响力，同时与 Arm、Apple 和 Qualcomm 等公司保持良好合作关系。其中社区影响力的目标甚至被量化到，要求代码在 GitHub 上得到 3k 标星，500 次克隆（fork）。有兴趣的吃瓜群众可以去持续关注一下，看看团队能不能在年底完成这个 OKR。数据加载基于 Apache Arrow 格式的 HuggingFace datasets 库凭借无内存限制的高速加载 / 存储，近几年异军突起，似乎抢走了 PyTorch 相关功能的风头。数据加载的文档中开篇就提出了雄心壮志，要让 TorchData 库再次伟大，重新确立 PyTorch 在数据加载方面的主宰地位。要达到这个目标，就需要让相关功能变得灵活、可扩展、高性能、高内存效率，同时实现傻瓜式操作，支持各种规模的多模态训练。具体的更新目标包括以下几个方面：- DataLoader 的功能开发和接口都将贯彻 GitHub 优先的原则，DataPipes 和 DataLoader v2 则将被逐步被弃用、删除- 确保 TorchTune、TorchTitan、HuggingFace、TorchData 之间的清晰边界和良好互通性，支持多数据集、多模态数据加载- HuggingFace 使用 StatefulDataLoader 的 API，确保兼容性，及时更新样例和测试用例编译器核心及部署PyTorch 的编译器核心功能经过多年发展已经趋于完善，目前亟待弥补的只是对 LLM 和 GenAI 领域的更深度集成和更多优化支持。路线图提出，要将 torch.compile () 函数带到 LLM 和 GenAI 的使用周期的各个方面（推理、微调、预训练），让重要模型在发行时就搭载原生的 PyTorch 编译。为了实现这个目标，文档提出了很多具体措施，比如与 torchtune 与 TorchTitan 团队合作，提升编译性能，并在下半年发布至少两个高知名度模型的原生 PyTorch 编译版本。此外，编译器可能添加可视化功能，在 non-eager 训练模式下生成表达前向计算 / 后向传播过程的模型图。用户支持方面也有诸多规划，比如提升系统的监控性和可观察性，帮助户自行调试编译问题。关键目标还包括建立用户支持团队，针对几个关键领域（数据类、上下文管理等），解决开发者在 GitHub 等平台上发布的问题。参考资料：https://dev-discuss.pytorch.org/t/meta-pytorch-team-2024-h2-roadmaps/2226https://x.com/soumithchintala/status/1811060935211049046https://www.assemblyai.com/blog/pytorch-vs-tensorflow-in-2023/本文来自微信公众号：新智元（ID：AI_era）
IT之家
评论 ( 0 )