今年早些时候我有幸入职了 Perplexity AI，终于用上了最强配置的服务器——AWS p5 实例，上面搭载了8张 NVSwitch 互联的 NVIDIA H100 显卡。更令我兴奋的是，服务器之间搭载了 3200 Gbps 的超高速网络。我觉得要是我能写一个程序用上这 3200 Gbps 的带宽，一定是一件非常炫酷的事情！

最近我花了一周的时间，大概摸到了一些门道，写了个小小的概念验证程序，用上了 97% 的带宽。因为我觉得这个摸索的过程挺有意思的，再加上网上关于 RDMA、EFA、libfabric、高性能网络的文章和教程十分有限，所以我打算把我这一周学到的知识分享出来。既是一个记录，也可以当作一个入门教程来看。

对 MLSys 熟悉的朋友们可能要问了：这不是 PyTorch 或者 NCCL 一行代码就能搞定的事情吗？确实，NCCL 在集体通信（Collective Communication）方面已经非常成熟了，也是大语言模型的训练和推理的基石。然而在其他应用场景下，我觉得集体通信还是有一些不太适合的地方：

1. 集体通信需要建立起全局通信域（MPI World）。如果要动态地增加、减少或者替换集群中的节点，那么就需要先让整个集群停下来。
2. 集体通信采用了同步通信模型，不论实现方式是阻塞式的还是非阻塞式的，对我来说都是一种很强的心智负担。我更习惯的是像 gRPC 那样的异步通信模型。
3. 最重要的是，能自己造一个轮子不是很好玩吗？

因为我的实验环境是 AWS p5 集群，所以本文提到的一些技术细节可能只适用于 AWS p5 集群。不过我希望本文还是能对其他的高性能网络环境有一定的参考价值。

因为内容比较多，所以我把内容拆成了几篇文章，欢迎大家点击阅读：

• 驾驭3200Gbps网络(0): 导言
• 驾驭3200Gbps网络(1): RDMA和EFA
• 驾驭3200Gbps网络(2): 高性能网络系统设计哲学
• 驾驭3200Gbps网络(3): libfabric
• 驾驭3200Gbps网络(4): 单向接收发送
• 驾驭3200Gbps网络(5): 双向接收发送
• 驾驭3200Gbps网络(6): GPUDirect RDMA WRITE
• 驾驭3200Gbps网络(7): 操作队列及带宽测试 [97.433 Gbps (97.4%)]
• 驾驭3200Gbps网络(8): 总线拓扑
• 驾驭3200Gbps网络(9): 使用32张网卡 [287.089 Gbps (9.0%)]
• 驾驭3200Gbps网络(10): 测试前预热 [293.461 Gbps (9.2%)]
• 驾驭3200Gbps网络(11): 多线程 [355.301 Gbps (11.1%)]
• 驾驭3200Gbps网络(12): 绑定CPU核心 [1237.738 Gbps (38.7%)]
• 驾驭3200Gbps网络(13): 状态分片 [1522.567 Gbps (47.6%)]
• 驾驭3200Gbps网络(14): 批量提交操作 [2589.488 Gbps (80.9%)]
• 驾驭3200Gbps网络(15): 惰性提交操作 [3108.283 Gbps (97.1%)]

随着开源预训练大型语言模型（Large Language Model, LLM ）变得更加强大和开放，越来越多的开发者将大语言模型纳入到他们的项目中。其中一个关键的适应步骤是将领域特定的文档集成到预训练模型中，这被称为微调。

通常情况下，来自领域特定文档的额外知识与预训练模型已经知道的相比微不足道。在这种情况下，低秩适应（Low-Rank Adaptation，LoRA ）技术证明是有价值的。

通过 LoRA，微调模型仅向预训练模型添加不到0.1%的参数。具体来说，这意味着 LoRA 微调模型仅增加了10~200 MB 的存储，具体取决于配置。从计算角度来看，考虑到与预训练模型相比参数的增加极少，额外的计算负载相对较小。

基于存储和计算的额外开销都很小这一点，我相信构建一个多租户的大语言微调模型的推断服务具有很大潜力。这个服务可以托管成千上万个 LoRA 模型，它们都共享相同的预训练大语言模型。在每个批次的执行中，每个用户请求都会调用一个独立的微调模型，从而分摊存储和计算成本到各种不同的模型中。

在我的上一篇博客文章中，我深入探讨了大语言模型推断中的批处理效应。在这篇文章中，我将详细介绍为什么多租户 LoRA 推断服务具有巨大的潜力。

机器学习模型依赖于批处理(Batching)来提高推断吞吐量，尤其是对于ResNet和DenseNet等较小的计算机视觉模型。GPT以及其他大型语言模型(Large Language Model, LLM)是当今最热门的模型。批处理对于GPT和大语言模型仍然适用吗？让我们一探究竟。

上交了连照片名字都没有的临时工牌，上星期五我为期13周的谷歌实习告一段落。我给谷歌写了7500行C++代码，再加上还没有合并的1000行，我觉得我对自己贡献代码的数量和质量还是比较满意的。这次谷歌实习是我第一次在工业界的经历，感觉收获很多。

每当我的程序崩溃的时候，我都会用核心转储 (core dump) 文件来找出来崩溃发生的具体位置。（关于怎么产生和使用核心转储可以看我之前的文章。）一直以来我调程序的时候都是很开心的……直到我遇到了这个新的 bug。当我把它的核心转储文件载入到 GDB 之后，我很失望地发现所有的堆栈追踪 (stack trace) 都是关于系统库的，没有一行是关于我的代码的。

太长不看：那就看看这个补丁就好了。

让我们踏上探索未知的旅程吧。