OnePiece: A Large-Scale Distributed Inference System with RDMA for Complex AI-Generated Content (AIGC) Workflows

相关论文 #

OnePiece 将 AIGC 多阶段推理拆分为微服务并用 one-sided RDMA 传输中间结果，与以下五篇论文共同构成"RDMA/bypass 驱动的分布式调度"研究簇：

本篇 vs 相关论文的 delta #

vs FaRM #

FaRM 的 RDMA ring buffer 针对定长消息（16–512 byte KV 操作）[farm-nsdi14]。OnePiece 的核心 delta 是将 ring buffer 扩展到变长消息（AIGC 中间张量大小跨越数 KB 到数百 MB），通过分离 buffer region（变长数据）和 size region（定长元数据 + busy bit）解决变长 slot 管理问题 [2601.20655]。FaRM 的 lock-free read 用 cache-line versioning 保证一致性 [farm-nsdi14]；OnePiece 的 double-ring buffer 用 CAS spinlock + timeout 重入保证 liveness（Theorem 2）——safety 模型不同（FaRM 严格一致 vs OnePiece 允许极小概率数据损坏）。

vs KRCore #

OnePiece 假设 RDMA 连接已建立（论文未提及连接建立开销）[2601.20655]。KRCore 的 DCT 虚拟化可直接消除此盲点：当 NM 动态调拨新 Diffusion 实例时，该实例需在微秒内建立到上游 VAE Encode 和下游 VAE Decode 的 RDMA 连接——verbs API 需 15.7ms per QP [2201.11578]，对于时间敏感的弹性扩展（Theorem 1 的实例数调整）是不可接受的延迟。

vs Blink #

Blink 的 ring buffer 在 GPU memory 中实现（4096 fixed slots + atomic CAS 状态机）[2604.07609]。OnePiece 的 ring buffer 在 host memory 中实现（RDMA 注册区域、CAS spinlock 保护）[2601.20655]。核心 delta：Blink 追求 device-native 协调（GPU 线程直接操作 ring buffer），OnePiece 追求跨节点通信（RDMA WRITE 跨越网络）。Blink 的 ring buffer 定长（每 slot 固定大小），OnePiece 的 ring buffer 变长——Blink 通过预编译 CUDA graph cache（650–1000 graphs, 2–3 MB each）[2604.07609] 回避了变长问题，OnePiece 必须直面变长消息（AIGC 中间张量大小不固定）。

vs RackSched #

RackSched 的调度是无状态的 per-request 路由（power-of-k-choices）[racksched-osdi20]。OnePiece 的调度是有状态的 per-workflow 编排——NM 需跟踪每个阶段的 GPU 利用率、实例健康状态、流水线拓扑关系 [2601.20655]。RackSched 通过交换机数据面实现纳秒级决策，OnePiece 的 NM 通过 Paxos 共识 + CPU 轮询实现毫秒级决策——延迟差异 >10³×，但 RackSched 无法做有状态资源编排。

vs CPU-Slowdowns #

CPU-Slowdowns 识别了 shared-memory broadcast 的 1-writer-N-reader 竞争作为结构性瓶颈 [2603.22774]。OnePiece 的 double-ring buffer 也是 multi-producer-single-consumer 模式，面临同类竞争问题——但 OnePiece 用 RDMA CAS（NIC 硬件原子操作）替代 CPU 端 busy-wait [2601.20655]，将竞争从 CPU 核心转移到 NIC 处理单元。CPU-Slowdowns 报告的 dequeue 19× 膨胀 [2603.22774] 理论上可通过 OnePiece 的 RDMA 方案缓解，但 OnePiece 未提供此方向的实验验证。

可攻击面 #

1. 无正式实验章节——核心声称缺乏实证：OnePiece 声称 16× GPU 资源节约，但论文无独立 Evaluation section，无延迟/吞吐基准测试，无与 NCCL baseline 的对比 [2601.20655]。此外，摘要/引言声称"16× reduction"与结论处"16% reduction"存在数值不一致——可能为笔误但严重削弱可信度。在本研究簇中，OnePiece 是唯一缺乏实验验证的工作：FaRM 有完整 micro-benchmark + KV-store + Tao 实验 [farm-nsdi14]，Blink 有 4 模型 × 3 基线 × 2 条件的全面评估 [2604.07609]。
1. CAS spinlock 竞争未量化：double-ring buffer 的 producer 互斥用 CAS spinlock，但论文未报告 CAS 竞争率、retry 次数分布、或在高并发（多个 Diffusion 实例同时写入下游 ring buffer）下的吞吐退化 [2601.20655]。FaRM 至少报告了 hot-key 场景下的 flat combining 优化 [farm-nsdi14]；OnePiece 对竞争场景完全沉默。
1. Theorem 2 的 safety 放松可能导致静默数据损坏：Theorem 2 承认 liveness 但不保证 data validity——timeout 重入后前一 producer 的部分写入可能被覆盖 [2601.20655]。在 AIGC 推理中，一帧损坏的中间张量可能导致下游阶段生成视觉伪影但不触发系统层面错误——静默质量退化比崩溃更危险。Checksum 检测仅在事后发现损坏，无法防止损坏发生。
1. Node Manager 的 Paxos 共识延迟未分析：NM 用 Paxos 选主保证 HA [2601.20655]，但 Paxos 共识延迟（尤其在跨 rack 部署时）可能使调度决策延迟达数十毫秒——与 OnePiece 追求的"快速弹性调度"目标矛盾。RackSched 的调度延迟在纳秒级 [racksched-osdi20]，KRCore 的连接建立在微秒级 [2201.11578]，OnePiece 的调度延迟可能成为新瓶颈。

生态位 #

OnePiece 占据"RDMA for AIGC microservice communication"的生态位——唯一为多阶段视觉生成流水线设计 RDMA 通信层的工作。在 RDMA 应用光谱中：

• FaRM (2014)：通用分布式 KV-store / 事务平台 [farm-nsdi14]
• KRCore (2022)：RDMA 控制面基础设施 [2201.11578]
• OnePiece (2025)：AIGC 推理专用 RDMA 通信层 [2601.20655]
• Blink (2026)：LLM 推理专用 CPU-free 架构 [2604.07609]

OnePiece 的独特价值在于将 RDMA 从"通用基础设施"推向"AI 推理专用通信"——ring buffer 的变长消息支持、Workflow Message 的路由语义、流水线吞吐匹配理论（Theorem 1）都是 AIGC 场景特有的设计选择。

但 OnePiece 的范式影响力受限于实验缺失。在同簇论文中，Blink 已证明 CPU-free 推理可行且有完整实验支撑 [2604.07609]，FaRM 有产业影响力（Microsoft 内部系统）[farm-nsdi14]。OnePiece 目前更像是一个架构提案而非经过验证的系统。16× 声称若经独立复现确认，将显著改变 AIGC 部署经济学。

未探索方向 #

1. OnePiece ring buffer + Blink persistent kernel 融合：将 OnePiece 的跨节点 RDMA ring buffer 与 Blink 的 GPU-resident persistent scheduler 结合——GPU 侧常驻 kernel 直接轮询 RDMA ring buffer（GPU memory 中），消除 CPU 在 inter-node 通信中的角色。需要解决 GPU-initiated RDMA（NVSHMEM 或 GPUDirect Async）的 ring buffer 管理。
1. 变长 ring buffer 的 lock-free 改进：当前 CAS spinlock 方案在高竞争下性能退化。可借鉴 FaRM 的 flat combining 思想 [farm-nsdi14]——多个 producer 的写入请求合并为一次批量 RDMA WRITE，由 combiner 线程统一提交。这需要在 RDMA one-sided 约束下实现 batching 语义。
1. ring buffer 容量与 KV-cache 的联合管理：AIGC 流水线中 Diffusion 阶段产出的中间张量与 LLM 的 KV-cache 都是显存密集型资源。ring buffer 的容量规划应与 GPU 显存分配器联动——当 KV-cache 压力大时缩小 ring buffer、反之扩大，实现显存的动态分时复用。
1. 端到端实验验证：最急迫的未探索方向——需要在 Wan2.1 I2V 全流水线上比较 OnePiece vs NCCL-based monolithic vs Mooncake-style KV-store 中转，测量 end-to-end latency、throughput、GPU utilization、RDMA 带宽利用率，验证或证伪 16× 声称 [2601.20655]。