# 750B MoE 分离推理：从 RoCE 到 EFA 的全栈验证 > **合规声明（生成式 AI 服务）**：前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。 > > **完整资料：如果想了解更多内容可以访问:https://events.amazoncloud.cn/china-summit-on-demand/ > > **免责声明**：本摘要仅为便于您了解峰会内容而提供，我们不对其完整性及准确性作出任何保证，且不构成任何建议或结论。相关内容仅供参考，实际内容以峰会回放视频为准。 > **合规声明（受限芯片）**：本环节的内容仅为演讲者提供的独立解释和分析，不代表亚马逊云科技的观点，亦未获得亚马逊云科技的认可。我们鼓励与会者独立评估演讲者分享的观点。 ## 一、基础信息 - **会议类型**：专题演讲 - **Persona**：模型实践者 - **时间信息**：6月23日 | 14:30 - 15:00 - **标题**：750B MoE 分离推理：从 RoCE 到 EFA 的全栈验证 - **PDF 资料**：无 - **视频回放**：有 ## 演讲人信息 ### 会议信息 - **地点**：上海世博中心（2026 亚马逊云科技中国峰会） - **日期**：2026年6月23日（Day 1） - **时间**：14:30 - 15:00 - **会议类型**：专题演讲 - **面向 Persona**：模型实践者 ### 亚马逊云科技演讲人 - **倪惠青**：解决方案架构师 - **赵可名**：解决方案架构师 ## 二、会议资料 PDF 转录内容 （本场次无 PDF 资料） ## 三、会议回放视频转录内容 大家好，首先我们先说一下我们今天为什么会有这样的一个话题 因为我们面向的是中国头部互联网的客户 那么我们为这些客户在今年在真实落地的一个过程中 发现了一个比较有意思的现象 就是这些企业他们在 AgentLoop 大型企业的时候 比如像我们的 Claude Code、像 CodeX 等等这样的一些应用 逐渐落地的时候呢 这些企业就逐渐发现说 我与其说持续的用 SaaS 的方式烧 token 那不如说用自建的模型 那另外呢如果说我用 IDC 去部署模型 又不如用云上的 GPU 来的更加就有弹性 然后更具有性价比 所以在这样的一个场景下 我们前不久就刚为我们的一个客户完成了一个 两 P 两 D 的这个 750B 大模型 从 IDC 迁移上云的这个项目 那我和赵可名老师呢 我们两个是这个项目的一个主要的负责人 所以呢今天呢 我就借这个机会给大家讲一下 我们从端到端的一个全栈实践 那今天呢 真的主要是分那么几个部分 首先呢 我会给大家简单的介绍一下 我们这个项目的背景和 IDC 上云 过程中遇到的一个差异和挑战 那第二部分呢 这个赵可名老师就会给大家按这个挑战的 这样的一步一步看我们的这个工程拆解 那第三部分呢 我给大家看一下我们的一个实测的数据 嗯 那首先我们看这个项目的背景 那我们这个客户呢 主要现在他当时是 GLM-5.1 750B 这个大模型 做了两 P 两 D 的这样的一个分离 啊推理的框架呢 是用的是 SGLang 的 0.5.10 他主要关注的场景就是120K 超长上下文 这样的一个推理的性能 他在 IDC 呢 就主要的是这个 用了四台 H200 的机器 那上云的时候呢 选择的是亚马逊云科技四台 P5EN 那从这个计算节点上来说 从它的那个 GPU 上 其实是完全一致的 那下面呢 我就是给大家看一下 那从 IDC 上云以后 从硬件软件两个层面上 那我们都会有哪些差异 啊同时客户会遇到哪些挑战 然后我们看这个 P5EN 的这个内部拓扑 从硬件层面啊 您看到我们每一个节点 是都是有两个 NUMA 域的啊 那在每一个 NUMA 域里头 这个 CPU 和 GPU 是通过 PCIe 进行连接的 那每一台机器呢 是有8 卡 8 张 H200 卡 然后呢这8张卡呢 是通过 NVSwitch 全连接互联的 然后这个双向的带宽 是 900 GB 每秒 那这一部分其实从计算节点上来看呢 跟 IDC 是完全一致的 不同的点呢 是在网卡这一部分 客户这边呢 它使用的是标准的 ConnectX 系列 是在以太网上 基于的是 RoCE v2 那上了云以后呢 在亚马逊云科技这边呢 我们使用的是亚马逊云科技自研的 Nitro 卡 嗯 这四个绿色的 那四乘四我们一台机器是 有16张 Nitro 卡 那在 Nitro 卡之上呢 就是如果说是普通的网络流量 我们是走 ENA 然后如果说是 RDMA 的流量呢 我们是走 EFA 那这两个流量是共享带宽的 那每一张卡呢 是提供的是200 Gbps 的 这样的一个带宽 16 张卡就是 3.2T 的这样的一个网络带宽 那 EFA 呢 是其实现在是可以通过 我们是通过是 OS Bypass 可以跨过 OS Kernel 实现跨节点的这个高速的互联 嗯 那说完了这个咱们硬件层面 我们可以看一下 就是在硬件层面的一个差异上来说 我们再分析说 软件层面会有哪些差异 那这里呢 我会主要是说 按着客户现在两 P 两 D 的一个切分的方式 来看 跨节点的一个传输 会带来哪些差异 那首先呢 我们看一下 就是客户这边使用的是 PD 分离 我们说为什么要去做 PD 分离 是因为说我们大模型推理的时候 它天然就是一个 Prefill / Decode 的 这样的两个阶段 比如说 那对 Prefill 阶段呢 我们是说 就好像我们做阅读理解一样 那大量的成千上万的 token 进来以后 我们要去批量的去理解 所以这一部分 它是一个 GPU 的一个 是算力的一个密集 我们关注的是 TTFT 每 token 就是 first token 的 首 token 的一个输出延迟 那对于这个 Decode 的部分呢 就好像我们阅读理解完了 然后我们就开始写答案了 一个 token 的写对吧 这时候其实 GPU 它的一个消耗并不高 这一部分的时候呢 我们关注的是它的一个 每 token 的延迟时间 它是一个卡的 我们显卡的一个带宽抢占 所以如果说把这两个 两个内容放在一起的时候 就会发生自然的抢占 如果我们把它分离开的话 是可以进行各自的优化 同时可以达到 每个都可以达到更好的一个效果 那这个 PD 分离以后呢 这个是 P 我们下一页是 PD 那 PD 分离以后呢 实际上我们带来一个问题 就是我们要做跨节点的 一个 KV Cache 的传输 这里面在客户的一个 IDC 它是用的 Mooncake 刚才鹤男老师介绍的 用的 Mooncake 那迁移上云时候呢 我们其实现在有两个方案 一个是用 Mooncake 那其实它的那个 EFA 已经 我们的 EFA 已经可以支持 Mooncake 作为后端接到 Mooncake 了 在前端的软件栈上 不需要做任何的修改 那另外呢就是 还可以说是使用 NIXL NIXL 是英伟达提供的这一种 传输的这个软件库 那现在呢也是可以通过说 我们的 EFA 通过标准的 libfabric 接到 NIXL 上面 所以从这个 PD 分离上来说 我们只是后端的库 做了一个后端的标准库 做了切换 对前端的应用没有任何的影响 那说完了这个 PD 分离以后呢 我们看一下 Prefill 节点 这个 Prefill 节点 那这里面呢 我们现在主要是 大家可以看到我们是750B 的 这样的一个参数 占用的显存 这样占的一个显卡呢 就会只是参数这一部分 就会到750 GB 同时我们在推理的过程中 它还会有一些 显卡的临时的存放对吧 那这时候我们两个 一个节点是放不下的 所以我们是采用了一个 就是节点之间 通讯最小的一个方式 用的那个 PP 分离 流水线并行 那这时候就说我们的这个 70 78层 这个模型是78层 那我们前39层 放在第一个节点 那后39层放在第二个节点 那节点和节点之间 是通过 NIXL 这样的一个传输 传输库来进行传输 点对点的传输 那这一部分呢 那其实我们现在 EFA 也是通过 libfabric 接入到 NIXL 上面去 可以完全的支持 那说完这个 Prefill 的这样的一个部分的话 我们来看一下 Decode 那 Prefill 其实跟 Decode 是完全不同的两个计算模式 那 Prefill 的时候 我们是通过这个上下文并行 来保证 GPU 的一个使用效率最高 对吧 但是在 Decode 阶段呢 我们知道它是一个 token 一个 token 顺序生成的 那这时候 我们为了保证这个 GPU 的使用率 我们是要使用这个数据并行 数据并行的话 这里头我们用的 DP=16 去做的这样的一个数据并行 那在这个切分的时候呢 我们就不能说 因为它两个跟 Prefill 是不同的一个机制 所以我们不能说 沿用 Prefill 的一个流水线并行进行切割 那为什么呢 因为我们回头看一下 因为上 Prefill 的阶段呢 我们所有的 token 我们所有的 Prompt 都是已知的 序列都是已知的 所以我们可以说 在 Stage 1 再处理新的一批 在处理第一批数据的时候 那第二批已知的数据 可以放到 Stage 0 继续处理 整个流水线是完全的并行的 它的 GPU 的使用效率是能达到100% 的 但是如果说 Decode 我们也用 PP 分离的时候 它会出现什么问题呢 因为我们的下一个 token 的输出 是要依赖上一个 token 生成以后才能输出 那这时候呢 就是如果说我们的这个 现在正在处理的 token 在处理的时候 那必须等到这一部分处理完了以后 再翻过来 给到 Stage 0 再处理 这时候就是会出现一部分等待时间 所以这个 Pipeline 的这个流水线 它会出现气泡 它的这个 GPU 的使用效率就不高 所以能在这个 Decode 阶段 我们不能用这个 PP 的分离 为了解决这个问题 包括说为了能让这个模型在 这个能放得下的这样的一个问题 我们就使用的是一个 这个 EP 更细粒度的专家的并行 那我们把这个256个专家 切成了 一共切成了16个部分 每个部分是16个专家 这样的一个方式放在两个节点上 进行这个 进行这个并行的推理 那这时候呢 你可以看到就是 这个 EP 的 EP 等于16 的时候 带来的是一个 多个两个节点之间的一个 MoE All-to-All 的 Dispatch/Combine 这样的一个数据的交互 它的这个特点呢 就是我们是一个 小数据量 高频 这样的一个交换 那这里呢 就是在客户的场景那儿 它是用的 DeepEP 然后到了云上呢 现在 DeepEP 我们就是 EFA 对 DeepEP 的支持 还是在 Roadmap 中 预计也就是下个 Q 吧 下个 Q 的这样的就可以支持 那当时我们在 在客户的这个项目里头呢 我们就使用的 UCCL-EP 去做的替换 UCCL-EP 是 UC Berkeley 和 UC Davis 开发的这样的一个软件库 嗯 然后这一块呢 就是它的一个 比较好的一个地方呢 就是这个 UCCL-EP 它的 它是完全兼容 就完全复刻了 DeepEP 的 API 只是在后端使用了这个 可以支持多种网卡 那 EFA 在支持之列 所以呢 我们使用了这个 UCCL-EP 其实在对用户层面 也没有任何的修改 它是可以完全支持 并且可以 已经在大的 呃 这个生产环境上 经过验证了 所以呢 就是经过我们刚才 这样的一个分析可以看到 那我们的这个 呃 PD 分离 使用的可以使用 Mooncake 和 NIXL 呃 是开 KV Cache 的传输 那对于呃 PP 这个流水线并行呢 我们使用的是 NIXL 那这些软件库 这些软件库都是 EFA 都是通过 libfabric 直接向上提供服务的 呃 它不需要我们对前端的 这个软件做任何的修改 那对于这个 MoE 的 All-to-All 的这样的一个 呃 传输呢 它的一个特点 刚才说的是小数据量高频 它对这个延时是非常敏感的 所以呢 这一部分的实现 是走 直接走了底层的 libibverbs 没有用这种高阶的 libfabric 来保证我们的这个延时 嗯 嗯 所以不管是从 刚才分析的 不管是从哪一种方式 那 EFA 的支持 都是不需要改 前端用用户的 这样的一个代码的 OK 那我们前面分析了 整个的一个传输 网络传输的 这样的一些呃 那个差异 那下面呢 我们就会看一下 那我们在实际的这个部署推理过程中 遇到了哪些挑战 啊 首先呢 就是我们在 IDC 里头 你是可以去 呃 完全的是主动的放置我们的这个物理机啊 那保证它的一个 拓扑就近 那在云端 我们是不是也有这样的一个手段 来保证我们机器之间的这个 呃 延时更低呢啊 然后第二个呢 就是说 我们这个 EFA 刚才分析的是 呃 有 EFA 多卡 会牵扯到很多的这个软件站 那么我们有一些什么样的 正确的这个方法 来让它更快的在云上落地啊 第三个呢 就是我们这个啊 模型的权重越来越大 我们有一些什么样的快速的方法 可以让它进行快速的加载和部署 那这些问题呢 我就留给赵可名老师 给我们——解答 哎 大家好 呃 我是赵可名 然后我们看到其实 倪老师给我们带来三个问题 那这个三个问题呢 其实也是在工程落地的过程中 我们实际上遇到的一些挑战 那其实我们在做的时候呢 也是想就是说 那我们在做这个项目中 能不能沉淀出来一些固定的 能够让大家去开箱 一键去用起来的 这样的一些资产 所以呢 其实我们总结了一套 就是基于亚马逊云科技的 EKS 那这样的一个服务上来去构建的啊 Terraform 的这样一个脚本 那可以解决这几个问题的同时 那我们来看一下一个问题 是怎么一个个就解决的 呃 首先呢 其实我们看到的是一个网络的问题 首先从网络的问题 这个角度的话 我们要看呃 云上的网络 和我们在机房里的网络有什么不一样 在机房里面的话 我们通常会提到 哎 我的 TCP 这块就是网络怎么去构建的 然后我 RDMA 这块的高性能网是怎么构建的 但是在云上的话 呃 亚马逊云科技其实是把两部分的网络 合在了一起进行这样的一个管理 那这个管理的一个方式呢 首先其实我们可以看一看就是 我们的这个机房 它的一个构建的一个形式 那这个机房那个构建的一个结构图呢 实际上是我们在打开我们的这个 GPU 的机器 或者是说 GPU 的机器预定到了之后的话 就可以通过这个 describe topology 这样的一个 API 来去得到的 那这样的一个网络层次呢 你就会得到某一台机器 它所对应的类似于我们传统机房的 这种 spine-leaf 的里面的 TOR 的机器 或者是说它上面的 spine 的机器 和 leaf 上的机器的具体的 id 那这个 id 如果落在我们比如说 K8s 里面的标签上的话 那后续我就可以通过这个 id 来去调度整个 GPU workload 上尽量的更近一点 但是从整个机房的这样的一个设计来说的话 即使我们是落到了不同的 节点的交换机下面最远的跳到了 最高的这样的一个交换机的情况下 我们也是可以保证 一个设计目标在10 微秒以内 来做一个10 PB 这样的一个 带宽的一个交换 ok 那我们在开机的时候的话 通常对于 GPU 这类的机型 有两种开机的形式 一种叫 ODCR 就是我们去买一部分的容量 预留下来 那另外一种 就是我们去买那个 Capacity Block 这两种情况下 在第一种用 ODCR 的时候 我们可以设置一个叫 Cluster Placement Group CPG 这样的一个东西 那这个 CPG 这个东西的话 其实是可以保证我们在第二层 也就是说 layer 2 这个级别的网络 是聚集在一起的 为什么不是最后一层 就我们看到其实第三层网络下面的话 那这两个节点是不是更近 其实不是 就是说确实是更近 但是第三层只能容纳两台机器 因为 GPU 节点 它其实对网络和供电的要求是非常高的 所以 我们设置了 CPG 以后之后 在第二层的节点上 是可以保证你的机器在一个第二层节点下的 ok 那从网络的配置上来看 我们传统的 TCP 网络的一个构建的话 其实大家非常熟悉 安全组也好 然后我自己去设置 我 vpc 里边的这样的一些网络的规则 但是到了 RDMA 这个时候的话 我们怎么去设置 尤其是开机的时候 这些设置是要提前去自动化的注入好的 那我们就看到 比如说 P5EN 这样的一台机器 它其实是需要我们去设置 它的 TCP 技术栈 也就是说 EFA 网卡 以及呢 就是它的 RDMA 技术栈 也就是说 EFA-only 网卡 两种设置 那这种情况下的话 ENI-0 也就是说我们第一张网卡 是默认留给 TCP 栈的 那这张网卡是干什么用的呢 比如说我们去加载 S3 上的模型权重 比如我们去访问这个机器上 所联通的这些各种的 TCP 资源 都要用到这张网卡 它的带宽是100 Gbps 那下面的这些 EFA 的网卡呢 我们就要设置成 EFA only 这样的一个形式 来去满足我们 RDMA 的这样一个通信要求 另外右边这张图呢 实际上是我们最新一代的机型 就是 P6b300 这样的一个机型 那它和前面的机型有一个不同 就是它把这张 eni 的就是 第一张网卡完全独立出来 那这张网卡的带宽是350 Gb 为什么这样设计呢 其实是因为就是我们 S3 的内网带宽 实际上是100 Gbps 每秒 但是呢我们有的时候模型在 并行的加载权重的时候 有可能会需要更高的带宽 那这个时候你 TCP 的网络 如果是能达到更高的一个带宽的 吞吐的情况下 可以方便更好的加载一个模型 那底下的这16张卡的话 还是按照我们就是 EFA only 这样的一个模式来去做的一个设计 对就是讲一下最新的机型和我们之前的 传统机型的这样一个区别 讲过了网络 网络我们去在 K8s 上 就是说自己的去构建好之后 打上了这些标签 那下面一部分可能就是我们在 讲去装机 可能对于我们客户来说的就是 SRE 团队或者说是中台的这个团队 我需要干什么 那我画这张图其实更希望 就是说把这个边界给大家讲清楚 就是说哪些可能是 亚马逊云科技已经提前配置好的 哪些是我们中台要去做的 哪些是我们要交给算法的这些同事 要去做配置也好 还是说去后面一步去管理的内容 那首先我们自下而上去看 就是最底层 第三层和第四层 其实是开机配置好的 就是亚马逊云科技会提供 我们叫 Deep Learning AMI 的这样的一个 软件包的一个更新 它的更新节奏大概是 每两周一次这样的一个版本发布 那也是结合了就是英伟达的这样的 一个驱动的一个发布频率 那里面会包含 那就是我们 EFA 软件的这样的 一个 driver 支持 同时也会包括最新的 英伟达的一个套件 那这一部分的话 其实是已经覆盖了我们的 node 节点 以及 node 节点以上的 这个 container runtime 这一块的所有的软件 进入包的最新的一个版本 那我们可以根据我们的工作负载 去选择我们自己合适的 一个内核版本 来去把这个 node 节点拉起来 这是第一步 那第二步其实就到了我们中间这一层 我们现在把它叫 K8s 的一个 GPU 的一个 stack 那这里面包含什么呢 首先是两个 device plugin 一个是我们用于发现我们的 GPU 能够让 GPU 被容器所使用的这样的一个 device plugin 就 GPU device plugin 那还有一个是我们 EFA 设备 那就是 EFA 设备在容器里 比如想去使用的时候 那我们需要先找到这个设备 那这个 DP 就是负责去找到这样的 EFA 设备的这样的一个 DaemonSet 再往右看 那我们去管理一个 GPU 的时候 其实我们想知道 GPU 的温度 那 GPU 的工作的这样的一个状态 显存的一个使用 ECC 有没有报错 等等有这样的一个信息 这些信息是通过什么样的一个 东西来去发现的 我们用 DCGM Exporter 包括 node 的这个状态的 exporter 来去得到 GPU 的这些信息 这一部分软件的话 其实是因为大家的各种的 安装包里面来提供的 它也是开源的这些软件 那同时我们在制作我们的开机脚本的时候 也配置了就是完全支持 GPU 的 就是英伟达的就有一个叫 GPU operator 的 一键开机的一个软件 包括我们比如说想做 GPU 的 MIG 这样的一些组件的话 都可以自动化的 有一键安装到这里面去 那再往上看一层的话 就是我 GPU 的这个中间件 这一层我都基本上安装好了之后 那我们在上面去做我们 国内可能更多的就叫训推一体平台 那这个平台我们怎么去做呢 那这个时候 首先我们可以看一下第一个产品 Amazon SageMaker HyperPod Amazon 的 SageMaker Amazon SageMaker HyperPod 其实就是这样的一个软件的一个产品 那它也是基于我们看到底层的这些中间件 各种的 Device Plugin 来去发现你的 GPU 的一个状态 得到 GPU 的 Metrics 来去进行一个调度 包括可能我们训练一开始的时候 我现在要用热机 然后把整个机器跑起来 最高的负载去做两分钟的这样的一个测试 等等这样的一些就是调度的一个逻辑 其实都是在这层软件上来去做配置的 而同时我们也看到其实国内现在就是 开源的这种软件时代可以很多 包括就像 HAMi 像 Volcano 等等这样的一些产品 都可以非常方便的用于我们去做 比如自己的这样的一个 GPU 训推一体平台 那从职责的分工来看的话 就是这三层 其实是我们通常会接触到的 而在第二层这一块的话 包括底层这一部分 我们其实已经做成了一键开机 就是说我们只要把这个 Terraform 拿过来 去把我们想要找到的这个组件配置好 那其实就一键可以把这个 K8s 的集群拉起来 一键部署起来 上面的这个集群的这部分的这个调度软件 比如我们自己去选择一个我们比较喜欢用的 一个平台直接就可以使用起来 通信的技术栈这块的话 其实刚才倪老师也做过一次介绍 那就是说我们自下来自下而上去看的话 整个技术栈我们可能首先先分为两层 一部分是在内核态 就是说我们 Linux 内核这里边的话 有 EFA 的 Driver 包括 SRD 的这种 就是说 EFA 的这样的一个协议的一个实现 那在我们看平常看的这个用户态这块的话 有 RDMA Core 它实际上是实现了我们去 RDMA 的原语 就是 Send 和 Receive 等等这样的一些 就是命令的一个方式 中间这一层的 libfabric 其实也是我们在开机了之后 已经自动集成好的 再往上去看的时候 就是我们用 KVCache 去做 P 节点到 D 节点的数据传输 还有就是说做 EP 的时候 我的整个的 EP 的跨节点 的 All-to-All 的传输的时候 这部分的软件实际上是我们需要选择的 那我们根据我们的 Workload 的话 如果是推理的 Workload 的 其实目前像 SGLang vLLM 已经用英伟达的这套的这样的一个框架 其实我们就可以配置 NIXL 和 Mooncake 的 叫 Mooncake Transfer Engine 这一部分的一个使用 其实今天就是鹤男老师也在场 就是我们 Mooncake Transfer Engine 的 EFA 部分实现也是 鹤男老师给我们做了一个支持 也写得非常棒 然后就是 EP 这块的话 我们可以使用 UCCL-EP 这样的一个 就是由一个研究院来去做实现的 和 DeepEP 与一模一样的这样的一个软件包 来去使用 最后我们去说一下 在云上除了我们要配置网络 配置自己的 GPU 的这样的一个技术栈之外 还有很多的存储可以选 那这个存储我们到底是用哪个比较合适 我相信其实第一个我可能没列出来 就是我们的 GPU 节点里面本身其实是有本地盘的 这个本地盘是有大概28个 T 那这个本地盘其实它速度非常快 那如果我们是把它能够非常好的使用起来 其实本身是 就是因为这个盘是随机已经带的 非常方便 那首先我们使用本地盘做推理的时候的话 第一步是要去做模型的这样一个加载 那前面我也讲到 就是 S3 是一个天然的去存放模型 做一次性的加载模型 去做部署的这样一个非常好的存储 因为首先来说的话非常便宜 同时内网带宽非常高 有100个 Gb 那这个时候的话 我们可以直接把 S3 上的文件模型权重 拿到我们的本地盘上来去做快速加载 那这个部分的 S3 的 Mount Point 以及它的以及 CSI Controller 以及这些需要提前配置的内容 也在我们做的 Terraform 脚本里面已经配置好了 那再有两个东西 其实是 S3 Express One Zone 它其实不是简单的 我们把 S3 就是放到一个区里边 减少了这种多副本 就能得到一个更好的速度 其实里面做了很多 包括就是传输性能 吞吐等等这样的一个优化 就是我们实测下来的话 其实在训练场景中 尤其是你的文件比较小 然后需要多次去做加载的时候 那是非常方便的去使用 S3 以及 Express One Zone 的 也作为稍微一个提示 它的价格可能会比 S3 的标准版稍微贵一些 那最后一个点 就是说 当我们是做一个大规模的训练的时候 我们可能会需要一种高速的 能够去做除了 TCP 级别的 能做 RDMA 级别的 就是说能和 EFA 去通信起来的 这样的一个高速的文件系统 这个时候的话你就会用到 Amazon FSx for Lustre 这样的一个高速存储产品 这个产品其实也是我们看到 如果我们把这个 TCP 网络和高网 也就是 RDMA 部署在同样的一个网络里边的话 我们就非常方便的可以把 FSx 这样的一个高速的存储网络 直接的接入到我们 GPU 机群里面去 而这部分就是 它需要装一些提前的这种 Device Plugin 或者说是 Client 等等这样的一个安装 也是提前预置在我们这套 Terraform 里边的 我们可以做到一键就可以把 整个的机群 按照我们需要的一个配置 配置起来 不管你是一个训练的 Workload 还是一个推的 Workload 都可以实现一个非常方便的配置 OK 从工程上我们实现了这样一套脚本 后面倪老师应该也会把这套脚本的 就是下载方式提供给大家 好 我把时间还给倪老师 OK 刚才可名老师 把我们的这个模型已经部署完了 那我们最后 就看一下我们实测的数据 这里的实测数据 我们可以看到 客户的输入是120K 的 长上下文 Token 然后请求 我们的 Request Rate 是每秒0.36 的这样的一个请求 出来的数据可以看到 在 Prefill 阶段 我们的 TTFT P5EN 跟客户的 IDC 基本上是一致的 11 秒 12 秒这样的样子 对于 Decode 阶段 就是每 Token 的一个输出延迟 那每 Token 基本上是 稍微高一点 这个5 毫秒的样子30% 主要的一个原因是因为现在 就是因为在 IDC 客户使用的是 ConnectX 这个系列 它跟 GPU 是紧密集成的 所以就是 GPU 可以直接敲这个网卡的这个 Doorbell 那对于像 EFA 目前这个支持 还在 Roadmap 中 那预计我们是在 对 B 系列的机器 可以提供这样的支持下一步 那目前还是要借助 CPU Proxy 来多做一跳 来实现这个信令的一个同步 所以这一部分 就是在我们完成了 这个 GDA GPU-Initiated 这样的一个 Feature 的时候 这一步的差距就会被拉平了 然后在下面这个 就是客户对我们最满意的一个 一个指标是这个 Max P99 就是 长尾延迟的这样的一个时间 就是每 token 输出的 长尾延迟的这个时间 可以看到 IDC 这样是 EFA 的 差不多有四倍的样子 为什么会出现这样的一个差距 是因为在以太网 RoCE v2 这里 它是用的面向连接、有序的 所以一旦是出现网络拥塞的时候 队头就会发生 出现这个阻塞 所以就是说是在 这种 长尾延迟的时候会出现毛刺 但是亚马逊云科技 是使用 SRD 面向无连接 是面向无连接 无序的 它的数据包 可以通过这种多路径的 模式选择 所以天然的就可以避免了 这种路由的阻塞 这里面 就是客户当时对我们这个 也非常满意的原因是因为说 那时间我们在做 尤其是在推理场景 影响客户的一个体验 往往就是说最慢的那个几个 token 对吧 等半天 这个就说 所以他们感觉 我的这个 token 的一个持续的输出 比真正的一个平均速度 微小的平均速度的差异 是更为重要的 因为时间也差不多了 我们最后给大家也准备了一个礼包 就是我们把这次测试的时候 总结的一些经验 遇到的坑 包括说刚才可名老师 给我们说做的一些脚本 Terraform 的脚本 那我们都打包起来了 大家可以扫码 会后就可以上手去做测试 希望我们的这样的一些 分享能够让大家 GPU 上云的这个路径 更加顺畅丝滑吧 谢谢大家