OnePiece 将 AIGC 多阶段推理流水线拆分为微服务，以 one-sided RDMA 传输中间结果，用 double-ring buffer 解决无 CPU 参与的 RDMA 死锁，配合 Node Manager 动态调度 GPU，在 Wan2.1 I2V 场景声称节约 16× GPU 资源。
AIGC 工作流（如 Wan2.1 I2V）由多阶段异构模型（T5/CLIP → VAE Encode → Diffusion → VAE Decode）组成，单体部署面临三个问题：
现有通信手段（NCCL）仅支持固定大小张量传输，占用 GPU 资源，且缺乏消息路由上下文，不适合异构微服务间通信。
OnePiece 的核心设计：
核心技术壁垒：在 one-sided RDMA 约束下（远端无 CPU 参与），为变长消息实现无死锁多 producer 单 consumer ring buffer。现有 ring buffer 方案要么假设定长 slot（不适配异构 AIGC 消息），要么依赖 CPU 做死锁检测（违背 RDMA zero-CPU 目标）。OnePiece 通过分离 size region + busy bit + 短超时重入 + checksum 校验，在仅 CAS 原子操作可用的条件下保证 liveness（Theorem 2），代价是允许极小概率单条数据损坏。
数据路径：Client 查询 NM 获取 Proxy 地址 → Proxy 分配 UID 并 fast-reject 限流 → 各 Stage 通过 one-sided RDMA ring buffer 传递 Workflow Message（header + payload）→ 最终结果写入 memory-centric DB → Client 凭 UID 拉取。
控制面：NM（Paxos 选主）持续收集 GPU 利用率，识别瓶颈阶段后从 idle pool 或低负载阶段调拨实例，通过 TaskManager 下发新路由。
Ring Buffer 结构：
| 符号 | 含义 |
|---|---|
| $T_X, T_Y$ | 阶段 X/Y 的单请求执行时间 |
| $K$ | 阶段 X 的并行 worker 数 |
| $M$ | 阶段 Y 的实例数，$M = \lceil K \cdot T_Y / T_X \rceil$ |
| $P_b$ | buffer region 写指针 |
| $P_{size}$ | size region 写指针 |
| CAS | Compare-and-Swap 原子操作 |
断言：当 $T_X < T_Y$，阶段 X 有 $K$ 个 worker，阶段 Y 有 $M = \lceil K \cdot T_Y / T_X \rceil$ 个实例时，两阶段稳态输出速率相等为 $K / T_X$。
物理意义：这是一个流水线瓶颈平衡条件——通过为慢阶段配置足够多的并行实例，使其聚合吞吐匹配快阶段的输出速率，消除排队积压。
证明摘要：X 的产出速率为 $K / T_X$（即每 $T_X / K$ 秒产出 1 个）。Y 有 $M$ 个实例并行处理，每个耗时 $T_Y$，因此 Y 的聚合产出率 $\geq M / T_Y \geq K / T_X$。稳态下每 $T_X / K$ 秒 X 产出 1 个，Y 恰好有 1 个实例完成，输出 1 个。
断言：若 sender X 成功将数据写入 buffer region 位置 $P$，receiver Z 最终必定访问 $P$；但 $P$ 处数据不保证有效。
物理意义：保证消费者不会"跳过"任何已写入位置（liveness），但承认死锁恢复机制可能导致数据被后来者覆盖（safety 的有限放松）。
证明摘要：假设 Z 跳过 P。Z 跳过只有在 size entry 被篡改的情况下发生。但 X 写入时设置了 busy bit，该 bit 只能由 Z（consumer）清除。故 size entry 保持不变，Z 遍历时必到 P。
| # | 检查项 | 结果 |
|---|---|---|
| 1 | 符号定义是否自洽 | ✓ $M, K, T_X, T_Y$ 定义清晰 |
| 2 | 等式量纲一致性 | ✓ Theorem 1 两侧均为 requests/sec |
| 3 | 边界条件检查 | ⚠ Theorem 1 未讨论 $T_X = T_Y$ 退化情况（应 $M = K$），但公式仍成立 |
| 4 | 假设是否明确声明 | ⚠ Theorem 2 假设"busy bit 只有 consumer 可清"但未形式化为前置条件 |
| 5 | 证明是否覆盖所有情况 | ✓ §6.1 枚举 8 种死锁场景逐一分析，覆盖完整 |
| 6 | 结论是否超出前提 | ⚠ Theorem 2 声称"eventually access P"但依赖消费者持续轮询假设（未形式化） |
论文未提供 RDMA 链路带宽数字（如 IB HDR 200Gbps vs NDR 400Gbps），也未给出 ring buffer 消息典型 payload 大小，因此无法独立验证 $Network(q)$ 项的量级。总延迟公式 $T(q) = T_X + T_Y + Network(q)$ 中 Network 项未量化。
$M = \lceil K \cdot T_Y / T_X \rceil$ 随阶段数线性增长。多阶段级联（$n$ 个阶段）时总实例数 $\sum_{i=1}^{n} M_i$，扩展性取决于 NM 的调度频率和 RDMA region 内可用节点数。论文未分析 $n > 2$ 的级联行为。
本文无正式实验章节。 §9 Fault Tolerance 直接跳至 §10 Related Work，缺少独立 Evaluation section。
现有数据点（均为声称，无方法论/基线细节）：
| 声称 | 来源 | 基线 | 方法论 |
|---|---|---|---|
| GPU 资源消耗降低 16× | Abstract, §1 | "monolithic inference pipelines" | 未描述 |
| GPU 资源消耗降低 16% | §10.1 Conclusion | 同上 | 未描述 |
| 2.4× throughput / 20% latency↓ / 50% cost↓ | §1（引用 Ant Group） | 非 OnePiece 自身数据 | 第三方报告 |
关键缺失：
| Step | 论点 | 支撑 | 依赖 |
|---|---|---|---|
| 1 | AIGC 多阶段流水线的 GPU 利用率低，因为各阶段异构且静态分配 | §1 问题分解（三条 root cause）+ Ant Group Triton 案例 | 前提假设 |
| 2 | 微服务拆分允许各阶段独立伸缩、共享公共组件 | §3-§4 设计：WS → Instance → TaskWorker 层次结构 | Step 1 |
| 3 | 微服务间需要高效通信；NCCL 不满足四条约束（任意类型、变长、不占 GPU、需路由上下文） | §2.3 + §6 开头的 L1-L4 分析 | Step 2 |
| 4 | 选用 one-sided RDMA 替代 NCCL，实现 zero-CPU 远端、zero-GPU 占用的内存直传 | §2.1 RDMA 背景 + §6 设计选择 | Step 3 |
| 5 | Bare-metal RDMA 下变长消息管理需要 ring buffer；但分布式 ring buffer 存在死锁风险 | §6.1 挑战 C1/C2 + 现有方案局限性 | Step 4 |
| 6 | Double-ring buffer（buffer region + size region + busy bit + CAS）保证 liveness；8 种场景覆盖完备 | §6.1 Theorem 2 + 8-case 枚举证明 | Step 5 |
| 7 | Node Manager 通过 GPU 利用率监控 + 动态实例调拨解决负载不均 | §8.2 六步调度流程 + idle pool | Step 2 |
| 8 | Theorem 1 保证流水线吞吐匹配，Proxy fast-reject 保证不过载 | §5 形式化证明 + Request Monitor | Steps 2, 7 |
| 9 | 整体声称：上述设计在 Wan2.1 I2V 下节约 16× GPU 资源 | Abstract/§1/§10.1（无实验支撑） | Steps 1-8 |
薄弱环节：Step 9 从 Step 1-8 的设计到最终量化声称缺乏实验桥梁。论证链的逻辑完整但实证为空。
[实现未公开]
论文未提供开源代码仓库、代码片段或具体实现细节（如 RDMA verb 调用序列、CAS 操作的具体实现、ring buffer 的 C/C++ 数据结构）。
ibv_post_send 的 CAS 操作获取 lock region。timeout 值需短于 RDMA 往返（论文称"short timeout interval"但未给出数值）。timeout 后 producer 释放并重新尝试 CAS，此时可能覆盖前一 producer 的部分写入——通过 checksum 检测损坏。