PyTorch x Hugging Face in Bengaluru: Building India’s Next Generation of ML Systems Contributors

PyTorch x Hugging Face 在班加罗尔：构建印度下一代 ML 系统贡献者 – PyTorch

特色项目

TL;DR

超过 170 名学生、工程师、研究人员和开源贡献者齐聚班加罗尔，参加由 Red Hat 和 Hugging Face 主办的技术活动，围绕 PyTorch、大规模推理、强化学习环境、分布式训练和下一代通信原语展开探讨。活动邀请了来自 Hugging Face 的三位演讲者和 Red Hat PyTorch 工程团队的两位成员，与其说是一场通用 AI 交流会，不如说是一次关于基础设施、抽象层和系统思想的深度工作坊，这些内容正在塑造开源 ML 堆栈的未来。

最引人注目的是演讲内容的技术广度，以及背后一致的理念。印度并不缺乏使用 AI 和 ML 系统的人才。当前更深层次的机会在于帮助更多学生和从业者成为这些系统的构建者和维护者：他们正在塑造整个生态系统依赖的性能分析工具、运行时环境、训练抽象层、强化学习工具链、内核库和分布式通信层。

定调：从 AI 用户到 AI 基础设施构建者

Sudhir Dharanendraiah 在活动开场提出了一个全场共鸣的挑战：印度不应仅仅作为 AI 和 ML 技术的庞大消费市场存在。印度拥有人才、研究活力和工程成熟度，完全有能力成为核心软件栈的重要贡献者。

这一视角的转变至关重要。它将活动从产品演示转向了系统思维。讨论不再局限于如何调用 API 或微调模型，而是深入探讨底层机制：什么让推理更高效？什么让强化学习具备可扩展性？什么让分布式训练具备可组合性而非脆弱性？随着集群规模扩大和异构性增强，通信库又需要发生哪些变化？

对于现场的学生、早期工程师和创业团队而言，这是一个重要信号。下一波 AI 创新浪潮将不仅属于模型使用者，也将属于那些改进编译路径、内核库、服务引擎、奖励框架和分布式系统的人——这些技术让现代 ML 在生产环境中真正可行。

PyTorch 中的性能分析：让性能可见

Hugging Face 的 Aritra Roy Gosthipaty 以一个实用的演讲开启了技术环节，围绕一个简单但持久的原则展开：无法分析的性能，就无法优化。

该环节没有将性能视为模糊的结果，而是将其分解为可重复的工作流程。Aritra 展示了如何使用 torch.profiler.record_function 注释感兴趣区域，使用 torch.profiler.profile 包裹执行过程，并利用调度机制区分等待、预热和主动收集阶段。随后，他逐步演示了如何导出追踪记录、生成汇总表格，并熟练解读这些数据，区分 CPU 开销和实际 GPU 工作负载。

一个特别有启发性的讨论点是“受开销限制”（overhead bound）的概念。小型工作负载很容易让人误以为GPU加速表现不佳，但实际上CPU端的启动和协调成本主导了整体运行时间。通过扩大工作负载规模并比较实际在CUDA内核上消耗的时间，该演讲展示了每个实践者最终都会以痛苦方式学到的教训：并非所有性能下降都源于模型问题，也并非所有优化都应从模型代码开始。

对于一个由构建或调试真实系统的工程师组成的观众群体来说，这提供了一个强有力的起点。性能分析（profiling）往往决定了是有条理的优化还是迷信式猜测之间的分水岭。幻灯片可在此处找到。更多阅读材料可在此处获取。

SGLang、Transformers 和内核：推理的新形态

Hugging Face的下一场演讲由Adarsh主讲，他从SGLang、Transformers后端和新兴内核生态系统角度探讨了现代大语言模型（LLM）推理。核心信息简洁且具有现实意义：单用户演示容易实现；高效处理数千个并发请求才是系统设计的起点。

演讲深入剖析了大语言模型中推理为何在结构上具有挑战性。预填充（prefill）阶段计算密集且高度并行，而解码（decode）阶段则具有顺序性、内存敏感性，并且受反复访问KV缓存的开销主导。从这里出发，演讲介绍了SGLang——一个高性能服务框架，其设计选择围绕这一现实展开。

演讲中的一个关键概念是RadixAttention。与请求完成后丢弃KV缓存状态不同，SGLang通过基于基数树（radix-tree）的LRU缓存保留先前看到的前缀。这种设计在共享提示、重复前缀或高请求并发的工作负载中尤为引人注目，因为它将用户流量中的重复结构转化为真正的系统优势。

演讲还强调了Hugging Face Transformers与SGLang等服务引擎之间富有成效的分工。Transformers继续作为模型定义、配置解析、分词器、模板和权重格式的权威来源。SGLang则围绕这一领域构建了快速路径：调度、连续批处理、注意力后端和可扩展服务行为。实际上，这种分工降低了服务Hugging Face模型仓库中长尾模型的门槛，无需将每个模型手动移植到定制运行时。

关于Hugging Face内核的最后部分进一步拓宽了视野。随着自定义算子和加速器专用内核在机器学习性能中的核心地位日益凸显，构建碎片化问题已成为现实挑战。不同的工具链、后端组合和兼容性约束往往使内核开发的共享难度超过预期。内核项目提出了更可复现的构建、更清晰的打包、更好的PyTorch兼容性以及更便捷的社区分发路径。

这些理念共同展示了推理系统的演变方向：不再是单一的单体堆栈，而是模型定义、服务运行时、编译器友好执行路径和可复用内核基础设施之间的分层协作。幻灯片可在此处找到。

Adithya S Kolavi 关于强化学习环境的演讲将训练后阶段的改进路径清晰地呈现出来。该演讲从预训练、监督微调到RLHF（基于人类反馈的强化学习）的演进轨迹展开，最终聚焦于当前前沿模型优化的核心——可编程验证的奖励机制。

演讲的核心观点在于：一旦某个任务能够被程序评分，它就能转化为模型学习的环境。这个概念看似抽象，但演示将其具体化。强化学习环境被描述为由任务、状态、工具、观测、奖励逻辑、执行后端和回合控制组成的结构化组合，而非黑盒系统。换句话说，环境是决定模型能尝试什么、能观测什么以及如何衡量成功的训练基质。

这种视角解释了为何大语言模型的强化学习既强大又困难。经典强化学习环境多年前就为控制问题设定了交互标准，但智能体训练引入了更多复杂因素。模型可能需要工具、沙箱、数据集、提示、验证器和多轮状态。标准化这些复杂性是区分一次性实验与可扩展训练基础设施的关键差异。

这正是OpenEnv进入讨论的切入点。作为LLM环境的通用框架，OpenEnv将Gym风格API的精神延续至训练后阶段。演讲展示了环境如何通过MCP暴露工具、服务任务、直接嵌入奖励评分标准，并通过相对少量的胶合代码接入TRL等训练库。这很重要，因为它将环境构建从临时的工程实践转变为可组合和可共享的模块。

演讲后半部分深入探讨了生态系统的潜在影响：如果优质环境能带来更优模型，那么生成大量高质量环境就成为战略优势。编程任务尤其具有吸引力，因为它们可验证、确定性强且经济价值高。这使代码仓库、测试用例、问题追踪和执行沙箱成为丰富的训练问题来源。Repo2RLEnv的引入精准体现了这一方向：将公开仓库转化为可扩展的、可验证的强化学习环境。

这场演讲是当晚最具启发性的内容之一，因为它为学生和从业者提供了明确的贡献方向。并非每个人都能构建基础模型，但许多人可以参与创建让模型优化更贴近现实世界的环境、验证器、工具和基准。幻灯片可在此处获取。

分步扩展，逐维推进

来自Red Hat PyTorch工程团队的Mansi Agarwal通过DeviceMesh、DTensor和FSDP2的演讲，带领观众深入现代分布式训练的核心。

演讲首先指出一个所有大型训练项目开发者都熟悉的痛点：历史上，结合不同并行方式需要过多手动配置。数据并行、张量并行和流水线并行通常需要独立的API、独立的组管理机制和独立的故障模式。将训练栈从单维并行扩展到二维或三维时，往往需要重写周边逻辑，而非简单地扩展系统规模。

PyTorch 新抽象的承诺，正如 Mansi 所指出的，是可组合性。DeviceMesh 让工程师能够将集群描述为一个 n 维拓扑结构。DTensor 让张量感知其在该拓扑结构中的分布方式。FSDP2 则在这些原语之上重建了分片数据并行性，将分片转化为原地转换，而不是破坏模型易用性的特殊包装器。

这很重要，因为它改变了开发者体验和运行时行为。工程师不再需要手动创建进程组并在模型代码中注入自定义通信，而是可以基于网格维度和放置规则进行推理。添加张量并行、流水线并行或上下文并行开始看起来更像是扩展网格，而不是从头重写训练堆栈。

会议也未回避权衡。DTensor 的即时模式开销、操作符覆盖不完整以及贪婪分片传播的局限性都是真实存在的约束。但这种坦诚让整体信息更具说服力：分布式训练中的可组合性不再是研究梦想或框架宣传用语，而正在成为 PyTorch 的实际设计方向。随着模型规模和硬件拓扑的持续增长，这一方向将变得越来越重要。

对许多参会者而言，这场演讲展示了他们在日常模型使用中可能不会接触到的系统设计层级，但如果选择参与核心堆栈开发，就一定会遇到这些内容。幻灯片可在此处找到：

PyTorch 中的零拷贝 GPU 到 GPU 通信

Arkadip Maitra 以一场关于 PyTorch 零拷贝 GPU 到 GPU 通信的深度系统演讲结束当晚活动，将讨论深入到支撑大规模训练的通信底层。

演讲从 c10d 开始，这是 PyTorch 默认的分布式通信层，以及它为何在很长一段时间内很好地服务于生态系统。它在 CPU 和 GPU 后端提供了通用抽象，并契合了当时大多数分布式工作负载以粗粒度同步、集体通信为主、规模相对较小的时代。

但通信的假设正在发生变化。网络接口已进化，GPUDirect RDMA 成熟，NVLink 路径增强，训练架构变得更具拓扑感知和专业化。随着集群规模和通信模式的变化，中间拷贝和线程开销的成本变得愈发明显。

这就是演讲中讨论的零拷贝路径如此重要的原因。通过避免不必要的拷贝步骤，PyTorch 可减少线程块消耗并实现显著的通信加速，尤其是在真实训练和推理系统中至关重要的消息大小范围内。演讲中报告的收益，包括拷贝税的降低和中等消息通信的加速，指出了一个更广泛的主题：扩展 ML 系统越来越依赖于从训练循环下方的不可见层中消除低效。

这场演讲是活动的完美收尾，因为它强化了当晚反复出现的教训：高层模型性能往往取决于大多数用户从未见过的底层工程选择。帮助更多从业者理解这些层级，是生态系统成熟的重要部分。该演讲的幻灯片可在此处找到：

为什么此次合作很重要

本次活动的独特之处不仅在于邀请了Red Hat和Hugging Face双方的演讲者，更在于这种协作呈现出了对技术栈的一致性认知。

Hugging Face从性能分析、推理基础设施和训练后强化学习工作流等维度带来了视角。Red Hat的PyTorch工程团队则从分布式训练内部机制和通信原语等层面分享了见解。这些演讲共同构建了一个完整的叙事：精准衡量系统表现、高效服务模型、构建更强大的训练环境、组合式扩展训练规模，并持续优化底层通信基础设施。

对印度学生和AI从业者而言，这种生态系统视角具有重要价值。它缩短了"使用AI"与"参与AI系统建设"之间的距离。这表明开源贡献不仅限于模型发布或应用演示，性能分析工具、内核开发、运行时后端、奖励基础设施、检查点机制、分片语义以及分布式通信库等领域同样存在大量有意义的工作。这类工作不仅能保持从业者持续参与并领先技术前沿，更能激发他们参与塑造未来技术的热情。

在许多人探讨印度如何更深度参与AI未来发展的当下，本次活动给出了可信答案：通过加入构建核心层的技术社区，并将技术协作视为从学生兴趣到严肃开源治理的转化通道。

前景展望

超过170位参与者的晚间活动清晰表明：印度对技术导向、系统视角的机器学习社区活动存在真实需求。现场氛围显示，学生渴望超越基础介绍，从业者追求深度最佳实践，生态系统已准备好探讨模型行为与底层基础设施之间关联的对话。

如果本次活动是任何预示，Red Hat、Hugging Face与更广泛的PyTorch社区之间的协作将产生深远影响。它们不仅能举办高质量的技术交流活动，更可能培育围绕开源机器学习栈的本地贡献文化——在这个文化中，下一代创新者将不再只是使用他人构建的工具，而是参与设计、维护和改进这些工具，使其惠及所有人。

/post-content

/inner-wrap