你好,这里是 zzudongxiang 👋

摘要：用 16 个 Claude Code 实例（独立容器、独立 Gitea 身份）完成一个昇腾 910C Triton 算子数据集，观察多 Agent 的自组织、互检与平台瓶颈。 1. 引言 最近RSI相关的研究比较热门，我手上正好有一些vLLM的推理资源，平时用来做主力大模型用感觉有些慢，所以恰巧可以拿这些资源来做一些多Agent协作的研究和探索。 初步的实验发现：多Agent协作确实可以做到一些单Agent做不到的事情，但是仍然存在很大的问题，这可能也是多Agent协作还没形成非常完整的工具链形态的原因之一吧。 2. 环境准备 多Agent协作最Naive的想法就是每个Agent都有独立的任何和独立的上下文关系维护，没错，我现在也是这么干的，后端的Agent工具使用Claude Code，通过SDK把他接入群聊会话，但是在实现的路上也遇到了一些别的问题和思考： 2.1 上下文隔离 CC没有Hermes那样的独立Profile，默认情况下所有实例共用同一份配置目录。仅通过环境变量拆分工作目录，在放开权限后仍不能保证实例不会越狱。一旦某个实例的上下文被污染，并且污染被写入本地文件或Memory，很容易在实例之间连续传播。 采用的方式比较简单：1. 一个Agent一个Docker 容器；2. 容器之间共享同一份CC二进制文件；3. 工作目录、Memory、History各自独立。 这样可以保证即使某个Agent的上下文被污染，影响范围也被限制在它自己的容器内。 实测发现，污染主要发生在Memory和本地文件这条路径上。如果污染是通过Agent之间的消息传播的，其他Agent反而更倾向于质疑、复现和纠正，这一点和预期相反。 2.2 身份与权限 多 Agent 协作首先需要解决身份问题。如果所有 Agent 共用一个git身份，会出现两类问题：1. 把其他 Agent 的提交认成自己的；2. 否认自己实际做过的提交。 任务越长，这种身份错乱越严重，并且会加重幻觉。因此每个 Agent 都需要独立的 Gitea 账号、独立的 token，以及对应的 git user.name 和 git user.email。谁提交、谁评审、谁验收，必须能对应到具体身份。 2.3 平台能力 平台主要提供三类工具面（独立的运管平台）： 统一MCP入口：代码提交、作业提交、知识库查询统一到一个入口； 群聊MCP网关：支持私聊、群聊和@； 项目管理工具：Issue、看板和PR，提供但不强制使用（需要把选择权交给Agent本身）。 但是实际上测试的时候发现，即便有这样的软约束，一旦Agent之间达成共识，也是按照他们的共识进行项目管理。（当然，并不是说这种方式不好，只是他们会在Git里面提交大量的实验日志和实验记录，并不太符合我的预期。） 3. 有趣的发现 3.1 自组织 向 Agent 下发一条约束：作业必须使用单机 8 卡提交。没有规定它们如何验证。 ...

1. 挑战与贡献 挑战 模型的多样性和更新速度无法与云基础设施上不断变化、高度多样化的人工智能生产工作负载相匹配 工程师或研究人员需要手动选择现有的生产或开源工作负载，并将其调整为可用于基准测试的形式 贡献 框架：建立了一个可扩展的自动化端到端基础设施，可对真实生产型人工智能工作负载的执行轨迹进行剖析和重现 高精度：通过在warehouse-scale fleet中运行的几个 PyTorch 生产工作负载对 Mystique 进行了评估，结果表明，生成的基准在性能和系统级指标方面与原始基准非常接近 可移植性：展示了跨平台生成基准的可移植性，并评估了 Mystique 可应用的几种情况，包括早期平台评估、子轨迹重放和缩小性能测试 2. 相关工作 Benchmark DeepBench：提供了一套深度神经网络（DNN）使用的基本操作，并在不同平台上对其进行了评估 TBD：确定了八个具有代表性的 DNN 模型，并在不同的深度学习框架和硬件配置上进行了详细的性能分析 DAWNBench：测量训练和推理的端到端性能，以规定的精度为前提，允许软件、算法、通信方法的创新 MLPerf：目前最为流行的Benchmark 仿真工具 Sniper：并行、可扩展的CPU仿真工具，对多核和多处理器进行高度抽象 gem5：一种微架构的仿真器，目前适用于仿真GPU GPGPU-Sim：提供一种时钟周期级别的仿真工具，可以对运行CUDA和OpenCL的Nvidia GPU进行仿真 性能建模 Daydream：根据内核-任务依赖图预测模型在某些优化条件下的运行时间 Habitat：使用波形缩放和 MLP 预测 DNN 训练的执行时间 CM-DARE：提出了一种利用云端 GPU 服务器进行分布式训练的性能模型 性能收集 MicroGrad：收集CPU指标，并使用基于梯度下降的调整机制来生成工作负载克隆和压力测试 PerfProx：根据硬件性能计数器得出的性能指标，生成真实世界数据库应用程序的miniature proxies CAMP：模拟核心性能、内存位置以及它们之间的相互作用，以模仿BigData应用程序 ECHO：重点是利用统计模型克隆分布式云应用中的网络行为，并生成与原始服务的定位和流量特征相似的合成基准 Ditto：提出了一种自动克隆框架，该框架可捕获分布式云应用程序的低级和高级性能指标 G-MAP：为 GPU 应用程序的内存访问模式和并行性建模，以创建内存代理 GPGPU-MiniBench：生成 CUDA GPGPU 内核的miniature proxies，以保持相似的性能 3. 相关背景 Pytorch ATen ops：低层级的Tensor库，是Pytorch的后端，用于执行真实的计算任务（加法、矩阵乘法等） Communication ops：多设备之间的分布式训练通信，通常为异步的。在Pytorch中c10d是一个非常流行的通信库，提供了大量的集合通信API和P2P通信API Fused ops：融合操作，是一种计算加速优化方法，可以把多个操作融合成一个运算操作。CPU中常用NNC作为融合操作的后端，GPU中为NVFuser Custom ops：允许用户实现比默认实现更好的模型块 4. Mystique设计 ...

Alibaba High Performance Network (HPN) HPN介绍了一种两层的双平面网络，可以在一个Pod中接入1.5w个GPU，通常需要3层Clos架构的网络才能容纳这么多GPU HPN 提出了一种新的双 ToR 设计，以取代传统数据中心网络中的单 ToR 1. 贡献与挑战 挑战 流量模式 传统网络无法应对LLM的低熵、周期性、突发的网络特点，传统的数据中心网络一般是高熵的（传统网络中会存在百万条流，但是每条流的利用率特别低，一半小于20%） ECMP在传统的数据中心的高熵、低利用率的网络中性能表现较好，但是在LLM训练中并不是最佳的 单点故障的敏感性高 LLM训练是一个同步过程，所有GPU合作完成一系列迭代，任何一个GPU发生故障都有可能导致整个训练过程出现问题 对LLM训练影响最大的是与机架顶部（ToR）相关的单点故障，这种故障可能会影响到各种GPU 生产统计数据显示，LLM训练中出现的故障造成的损失是一般云计算故障的 20 倍 贡献 非堆叠的双层ToR网络，可以在两个交换机之间直接同步，很好的改善了大规模部署的可信度 适配最新的51.2Tbps的交换机芯片，可以将1K个GPU部署在Tier 1网络中，使96.3%的训练任务获得高性能的网络 我们的实验表明，使用HPN的LLM训练吞吐量比传统数据中心网络高14.9倍 2. 背景知识 LLM的并行策略 DP：每次迭代使用All Reduce同步计算梯度数据 PP：每次使用Send/Recv传递中间结果 TP：每次迭代使用All Reduce/All Gather同步输出和对应的梯度 LLM的流量特征 带宽利用率周期性突发 流的数量少 传统的数据中心网络不适用于LLM流量模式 LLM对单点故障的敏感性 LLM每次的Checkpoint间隔大概在2-4小时，按照一个3k张GPU的集群计算，每次失败导致的回滚都将导致大约3w美元的损失 常见的监控工具和异常分析工具并不能避免网络产生故障，根据实验表明，在NIC到ToR之间每个月大概有0.057%的Link故障率，在ToR交换机每个月的故障率大约是0.051%，即一个LLM训练集群每个月可能会产生1-2次的Crash，5k-60k次的Link故障 LLM网络架构的建设目标 规模化：达到15K个GPU的规模，未来可以扩展到100K个GPU的规模 高性能：尽可能小的网络跳数，尽可能使用GPU-GPU直达的连接 单点故障容错率：在网络拓扑层尽可能改善单点故障的容错率 3. HPN架构 分为前端网络和后端网络，前端网络主要负责例如管理、接口、存储等网络流量，后端网络负责LLM的训练时的流量 每个Host包含8个GPU，使用NVLink互联，双向带宽达到400GBps-900GBps 每个Host包含9个2x200Gbps的网卡，其中一个连接到前端网络，其余的8个与GPU直连，接入后端网络 每个网卡的2个端口分别连接至不同的ToR网络，这种双ToR设计可以避免单点故障 4. 双ToR网络 传统数据中心的NIC的两个光缆接入一个交换机成为单ToR设计 双ToR设计将NIC的两个光缆接口分别接入不同的ToR交换机中 两个接口配置相同的IP和MAC地址，即使其中一个ToR故障，另外一个依旧可以正常工作 基于以上，同一个NIC的两个网卡共享相同的Queue Pair Context ...

we survey the current state-of-the-art collective communication libraries (namely xCCL, including NCCL, oneCCL, RCCL, MSCCL, ACCL, and Gloo), with a focus on the industry-led ones for deep learning workloads. 常见的MPI库：MPICH、MVAPICH、OpenMPI 其他的非MPI库：OpenSHMEM（Open-source Symmetric Hierarchical MEMory）、UCX（Unified Communication X）、UCC（Unified Collective Communication） 常见的xCCL库：NVIDIA Collective Communications Library (NCCL)、AMD’s ROCm Collective Communication Library (RCCL)、Gloo 1. 贡献与挑战 挑战 什么让同时代的xCCL比MPI更具有吸引力？ 每种集合通信库的性能特性如何？ 这些xCCL库是如何设计的？是否存在某种共享的设计模式？ 贡献 总结和研究集合通信原语、网络拓扑、算法，为同时代的深度学习训练奠定基础 讨论这些研究的工业集合通信解决方案以及其细节测试 对比当前的集合通信库的性能情况 2. 集合通信原语 Broadcast：常用于将训练数据发送到各个设备上 All Reduce：广泛应用于分布式神经网络训练的后向传播阶段 All Gather、Scatter、All-to-All、Reduce、Reduce Scatter 3. 网络拓扑架构 3.1 HyperCube 优点：高度的连接性，不容易发生故障 ...

《ASTRA-SIM: Enabling SW/HW co-design exploration for distributed DL training platforms》 1. 文章简介 1.1 摘要 现代深度学习系统主要依靠基于高性能加速器（如 TPU、GPU）的硬件平台进行分布式训练。目前的例子包括谷歌的云 TPU 和 Facebook 的 Zion。DNN 训练涉及 DNN 模型架构、并行化策略、调度策略、集体通信算法、网络拓扑和终端加速器之间复杂的相互作用。随着人工智能/ML 模型的创新不断加速发展，需要一种全面的方法来理解和驾驭未来系统中复杂的 SW/HW 设计空间，以支持未来 DNN 模型的高效训练。在这项工作中，我们做出了以下贡献：(i) 为分层扩展结构上的分布式训练建立了 SW/HW 设计空间；(ii) 开发了一个用于导航设计空间的网络模拟器；(iii) 展示了算法拓扑协同设计加速端到端训练的前景。 1.2 研究动机 对模型架构、并行策略、调度算法、集合通信、网络拓扑、终端算力的仿真 大规模并行训练成本高，在实际部署和训练之前，需要一个仿真工具进行评估 1.3 主要贡献 为分层加速器结构设计空间探索建立 SW/HW 设计空间，并确定扩展 DL 工作负载的关键瓶颈 开发名为 ASTRASIM 的端到端网络模拟器，用于评估设计空间的各个方面 使用 ASTRA-SIM 对 alltoall 和 Torus 拓扑的 all-reduce 和 all-to-all 集合的一维、二维和三维拓扑进行全面分析 2. 实现方法 3. 实验结果 实验参数 ...