| Entity | Title | 关联维度 | 关联强度 |
|---|---|---|---|
| 2511.02168 | Eliminating Multi-GPU Performance Taxes: A Systems Approach to Efficient Distributed LLMs | 多 GPU 通信优化——两者均攻击 collective communication 在 LLM workload 中的不足，但层级和路径完全不同 | 强 |
关联逻辑：fabric-lib 和 Iris/Three Taxes 代表了分布式 LLM 通信优化的两个正交策略：
两者共同的隐含论断：NCCL/RCCL 式 opaque collective library 在延迟敏感的 LLM 推理中已不够用。但攻击角度互补：fabric-lib 说"对于某些负载 P2P 比 collective 更合适"；Iris 说"即使需要 collective，也应该融合进 kernel 而非独立调用"。
fabric-lib 工作在 NIC/网络层（libibverbs / libfabric），解决的是 inter-node 400 Gbps 线速通信问题 [2510.27656]。Iris 工作在 GPU kernel 内部（Triton compiler），解决的是 intra-node Infinity Fabric 896 GB/s 互连上的 kernel fusion 问题 [2511.02168]。
两者的通信距离、带宽量级、和延迟预算完全不同：
| 维度 | fabric-lib | Iris/Three Taxes |
|---|---|---|
| 通信范围 | Inter-node (跨 NIC/网络) | Intra-node (GPU↔GPU via IF) |
| 带宽目标 | 400 Gbps per GPU | 896 GB/s per GPU |
| 延迟预算 | 数十 µs (RDMA RTT) | 数 µs (kernel tile transfer) |
| 依赖硬件 | ConnectX-7 / EFA (NIC) | AMD Infinity Fabric (GPU IF) |
| GPU vendor | NVIDIA H100/H200 | AMD MI300X/MI325X |
| 评测规模 | 64 nodes × 8 GPU = 512 GPU | 1 node × 8 GPU |
Delta 1: fabric-lib 补充了 Iris 完全未触及的 inter-node 场景。Iris 的 scope 仅限单节点 [2511.02168]，对于 MoE all-to-all（需跨节点）和 disaggregated inference（prefiller 与 decoder 在不同节点）完全无解。fabric-lib 的三个 use case 全部涉及跨节点通信。
fabric-lib 的立场是"P2P complements collectives"——对于结构化并行（TP, DP），NCCL collective 仍然最优；P2P 是为 disaggregated inference、MoE routing、async RL 这些 collective 不适用的场景而生 [2510.27656]。
Iris 的立场更激进："Three Taxes are artifacts of the BSP programming model, not fundamental"——即使是 All-Gather 这样标准的 collective，也应该被融合进 compute kernel 以消除 BSP overhead [2511.02168]。
Delta 2: 两者对 opaque collective 的态度构成辩证补充。fabric-lib 接受 collective 在其适用场景的最优性；Iris 质疑 collective 实现方式的最优性。两者都认为现有 NCCL/RCCL 有局限，但解决方向一个向外（新原语 P2P），一个向内（将 collective 逻辑拉入 kernel）。
fabric-lib 是 production-deployed 系统（Perplexity AI 生产环境，MLSys 2026 发表）[2510.27656]，包含完整的错误处理（心跳、取消确认、per-request cancellation token）、CUDA Graph 兼容性、以及 Rust 实现的工程优化。
Iris 是 研究原型（AMD Research 发表），仅在 8 GPU 单节点上验证，batch=1，FP16，无错误处理讨论 [2511.02168]。AG+GEMM 在 M=8~64 时甚至不如 RCCL baseline（承认是 GEMM tuning 不足）。
Delta 3: fabric-lib 展示了从研究到生产的完整路径，而 Iris 仍处于 primitive validation 阶段。fabric-lib 的 1.3s RL 权重传输 [2510.27656] 和 3-6× MoE decode 加速 [2510.27656] 是在完整推理 pipeline 中测量的端到端指标，而 Iris 的 10-20% speedup 是 isolated kernel 级别的 micro-speedup [2511.02168]。
fabric-lib 的核心技术贡献是 跨 NIC vendor 可移植性——通过找到 ConnectX RC 与 EFA SRD 的最小公共语义（reliable-unordered + WriteImm），在同一接口下支持两种截然不同的 RDMA 实现 [2510.27656]。
Iris 则 完全绑定 AMD 生态——依赖 AMD Infinity Fabric 的 GPU-initiated remote memory access，RCCL 作为 baseline，无 NVIDIA 平台验证 [2511.02168]。
Delta 4: fabric-lib 解决了 vendor lock-in 问题，Iris 反而加深了 vendor 依赖。这是一个有趣的反差：fabric-lib 的作者（Perplexity AI）作为推理服务提供商需要跨云部署，portability 是业务需求；Iris 的作者（AMD Research）的目标是展示 AMD 生态的竞争力，vendor-specific 优化是合理策略。
fabric-lib 声称 host proxy 匹配/超越 GPU-initiated DeepEP [2510.27656]，但 Table 9 显示 CPU proxy overhead 在 EP64 时 post time ~28 µs，且与 EP 线性增长。
攻击角度：Iris 的 kernel fusion 方法完全消除了 CPU proxy 的 PCIe round-trip——Pull Model 中 GPU 直接 iris.load() 远程数据，无 CPU 参与 [2511.02168]。当 EP 从 64 扩展到 256+（下一代 MoE 如 Kimi-K2 的 1T 参数量级），fabric-lib 的 host proxy 线性开销可能超过 GPU-initiated 方法的常数开销，此时 Iris 式的 in-kernel communication 可能更优。
反驳：Iris 的 Pull Model 在 8 GPU 以上未验证，其 spin-wait 在大规模 all-to-all 下可能导致更严重的 compute cycle 浪费。fabric-lib 已在 EP=64 生产环境验证，且 host proxy 的线性增长是可预测的。
fabric-lib 在 EP=64 时产生大量 all-to-all 并发流（每 GPU 向 63 个 peer 同时发送），但论文 未讨论任何拥塞控制机制，完全依赖底层协议（RC flow control / SRD built-in congestion）[2510.27656]。
攻击角度：在实际多租户云环境（EFA 是共享资源），缺乏应用层拥塞控制可能导致尾延迟飙升。Table 8/9 仅报告 p50 延迟 [2510.27656]，缺少 p99 数据——这在生产 serving 系统中是严重的评测缺陷。
fabric-lib 将自身定位为 RC 和 SRD 的交集（Table 1），刻意放弃了 Read 和 Atomic 操作 [2510.27656]。
攻击角度：Iris 的 Pull Model 等价于 RDMA Read 语义（consumer 主动拉取远程数据），在小 workload（M≤128）下优于 Push Model（等价于 RDMA Write）[2511.02168]。fabric-lib 放弃 Read 操作意味着 MoE decode 中的 consumer 端无法主动拉取 token——必须等待 producer 推送。在 load imbalance 场景（某些 expert 被更多 token 命中），Pull 语义可能更高效，因为空闲 expert 可以主动拉取工作。
反驳：EFA SRD 的 Read latency 不适合实时推理（fabric-lib 引用 Kalia et al. 2016 说明 Read/Atomic latency 不合适），这是基于硬件实测的务实选择，非纯理论取舍。
Iris 声称 10-20% Flash Decode speedup [2511.02168]，但这是 isolated kernel 测量（batch=1, FP16, 单 attention kernel）。
攻击角度（对 Iris）：在 fabric-lib 展示的完整推理 pipeline 中，MoE dispatch/combine 仅是解码延迟的一部分——与 attention 计算、expert FFN、sampling 等并列。10-20% 的单 kernel 加速在端到端模型中可能仅贡献 2-5% 的 wall-clock 改善。fabric-lib 的端到端评测方法论（Table 6 直接报告 tok/s）更能反映实际部署价值。
两篇论文代表了分布式 LLM 通信优化的两个不同范式阶段：
| 维度 | fabric-lib | Iris/Three Taxes |
|---|---|---|
| 范式 | "P2P as first-class primitive" | "Fusion eliminates BSP overhead" |
| 成熟度 | 生产部署，开源 | 研究原型 |
| Vendor stance | 跨 vendor 可移植 | Vendor-specific 优化 |
| 目标用户 | 推理服务提供商（Perplexity, vLLM 等） | Kernel 开发者（AMD 生态） |
| 解决的根本问题 | 新兴 LLM 工作模式需要新通信原语 | 现有通信原语的调用方式低效 |
fabric-lib：
Iris：
fabric-lib 的直接竞争者是 NIXL (NVIDIA) 和 Mooncake (Moonshot AI)。fabric-lib 在评测中略优于 NIXL [2510.27656]，且在 EFA 支持上领先。这意味着 fabric-lib 占据了"cross-cloud P2P RDMA for LLM inference"的生态位——一个之前没有成熟方案的空白区域。
Iris 的竞争者是 Triton Distributed 和 NVSHMEM（在 NVIDIA 侧）/ rocSHMEM（在 AMD 侧）。Iris 的优势是更 Pythonic 的 API，但 10-20% 的 speedup 幅度不足以驱动大规模采用——特别是考虑到 fused kernel 需要完全重写。
fabric-lib 的 host proxy 和 Iris 的 in-kernel communication 可以互补：对于 inter-node MoE dispatch，用 Iris 式 kernel fusion 处理 intra-node NVLink/IF 通信（消除 Kernel Launch Tax），同时用 fabric-lib 的 TransferEngine 处理 inter-node RDMA 通信。这等价于一个两层通信架构：
GPU kernel (Iris-style) ──[NVLink/IF]──> Node boundary ──[fabric-lib RDMA]──> Remote node
目前 fabric-lib 的 MoE kernel 已经使用 NVLink 做 intra-node 通信 [2510.27656]，但没有将 NVLink 通信逻辑 fuse 进 compute kernel（仍通过 host proxy 协调）。将 Iris 的 fine-grained fusion 应用于 intra-node 部分，可能进一步消除 fabric-lib MoE kernel 中 NVLink 通信的 host-proxy 开销。
Iris 发现 Pull 适合小 workload、Push 适合大 workload [2511.02168]。fabric-lib 的 MoE dispatch 使用固定的 Push 模式（两轮投机发送）。在 MoE routing 中，expert 负载天然不均衡——popular experts 需要处理更多 token（Push 更优），cold experts 处于 idle 等待（Pull 可能更高效让 cold expert 主动拉取少量 token）。
未探索方向：per-expert adaptive communication mode，根据实时 routing 统计动态切换 Pull/Push 策略。这需要将 Iris 的 Pull 语义引入 fabric-lib 的 inter-node 场景（可能需要 RDMA Read 或某种变体）。
Iris 的 kernel fusion 目前绑定 AMD IF [2511.02168]。fabric-lib 已解决 NIC 层的 portability [2510.27656]。一个自然延伸是：能否在 fabric-lib 的统一 P2P 接口之上构建 Triton-style kernel-level communication primitive，使得 fused kernel 可以跨 NIC 运行？
挑战在于 Iris 的 iris.load() 假设 sub-µs latency（Infinity Fabric），而 inter-node RDMA 延迟在数十 µs——spin-wait 在 RDMA 延迟下会浪费大量 GPU cycles。解决方案可能是 async prefetch + compute overlap：kernel 预发起 RDMA Read，继续处理已有数据，后续 tile 中检查完成。
fabric-lib 和 Iris 均未讨论拥塞控制 [2510.27656] [2511.02168]。对于 EP=64+ 的 MoE all-to-all，同时有 512 个 GPU 向彼此发送 token，网络拥塞不可忽略。
未探索方向：在 fabric-lib 的 TransferEngine 中加入轻量级 application-layer rate control——根据 ImmCounter 的完成速率动态调整发送速率。这比依赖底层 RC/SRD 拥塞控制更精准，因为 fabric-lib 拥有 per-transfer 的语义信息（哪些 expert 热、哪些冷）。
Iris 的 "Three Taxes" 框架（Kernel Launch Tax, Bulk Synchronous Tax, Inter-Kernel Data Locality Tax）[2511.02168] 是一个通用分析工具。将其应用于 fabric-lib 的 host proxy 架构可以揭示：
fabric-lib 的 two-round speculative dispatch 已经部分消除了 Proxy Launch Tax（第一轮投机发送隐藏 routing 交换延迟），但 Host-Device Synchronous Tax 和 PCIe Locality Tax 尚未被系统性优化。GPU-initiated RDMA（未来 EFA 可能支持）将同时消除所有三种 tax。