Blink: CPU-Free LLM Inference by Delegating the Serving Stack to GPU and SmartNIC

相关论文 #

Blink 将 host CPU 从 LLM 推理关键路径完全移除（DPU 前端 + GPU persistent scheduler），与以下五篇论文共同构成"RDMA/bypass 驱动的分布式调度"研究簇：

本篇 vs 相关论文的 delta #

vs CPU-Slowdowns #

CPU-Slowdowns 是诊断，Blink 是处方。CPU-Slowdowns 发现 CPU oversubscription 导致 shared-memory broadcast dequeue 膨胀 19×（12ms → 228ms），且此问题与 TP degree 成正比 [2603.22774]。Blink 的解法是将整个 CPU 从关键路径移除——根本不存在 dequeue 路径，ring buffer 协调直接在 DPU 和 GPU 之间通过 RDMA + atomic CAS 完成 [2604.07609]。

关键 delta：CPU-Slowdowns 建议的短期修复是"增加 CPU 核心"（~1.5% 成本，1.36–5.40× 改善）[2603.22774]。Blink 追求的是架构级修复——即使 CPU 核心充足也不用它，从而获得完全的 interference immunity。在 isolation 条件下 Blink 仍优于基线（P99 TTFT 1.35–3.45× lower，throughput up to 37% higher）[2604.07609]，证明 CPU bypass 的收益不仅限于消除 interference。

CPU-Slowdowns 还发现 tokenization 占 TTFT 50% [2603.22774]。Blink 通过将 tokenization 迁移到 DPU 的 ARM 核心（SIMD 优化，8–19.7× faster than HuggingFace）[2604.07609] 解决此瓶颈——但将 CPU 瓶颈迁移到 DPU 后，DPU 的 16 个 ARM A78 核心是否会成为新瓶颈尚未分析。

vs FaRM #

FaRM 用 RDMA ring buffer 做 machine-to-machine messaging（host CPU 轮询 head）[farm-nsdi14]。Blink 的核心 delta 是将 ring buffer 的消费者从 host CPU 变为 GPU persistent kernel——256 个 GPU 线程并行扫描 4096 slot，1–5μs 完成全扫描 [2604.07609]。FaRM 的 lock-free read 依赖 x86 DMA cache coherence + RDMA write ordering 保证一致性 [farm-nsdi14]；Blink 的 ring buffer 用 per-slot 状态机 + atomic CAS 保证 DPU-GPU 跨域一致性。FaRM 面向通用 KV/TX workload，Blink 面向 LLM 推理的 CUDA graph dispatch——后者可利用预编译 graph 的确定性执行模式简化调度逻辑。

vs KRCore #

KRCore 优化 RDMA 连接建立（5.4μs vs 15.7ms）[2201.11578]。Blink 当前不涉及连接管理（单 GPU、DPU-GPU 直连）。核心 delta 在 scope：KRCore 是基础设施层（RDMA 控制面），Blink 是应用层（推理系统）。但 Blink 的 multi-GPU 扩展明确依赖 RDMA 连接管理——论文提及"GPU-initiated RDMA"作为 multi-GPU 方向 [2604.07609]，此时 KRCore 的 DCT 虚拟化可直接服务连接建立需求。

KRCore 的数据面 syscall overhead（+46% sync latency, 1μs）[2201.11578] 对 Blink 的 ≈2μs device-side graph launch [2604.07609] 来说是显著的——这暗示 Blink 的 multi-GPU 扩展可能需要绕过 KRCore 的 kernel module 路径，转而使用 GPU-native RDMA（NVSHMEM 或 GPUDirect Async）。

vs OnePiece #

OnePiece 和 Blink 都用 RDMA ring buffer，但设计目标根本不同。OnePiece 传递变长 AIGC 中间张量（KB–数百 MB），需要复杂的 double-ring buffer + CAS spinlock + timeout 重入 [2601.20655]。Blink 传递固定格式的 prompt/token（预分配 fixed slot），可用简洁的 per-slot 状态机实现 [2604.07609]。OnePiece 允许极小概率数据损坏（Theorem 2 的 safety 放松）[2601.20655]；Blink 的状态机通过 CAS 原子转换保证严格正确——benign races（re-scan）不导致数据损坏。

两者的互补方向清晰：Blink 做 node 内 CPU-free 推理，OnePiece 做 node 间 RDMA 通信，合并后为"全链路 CPU-bypass 分布式推理"提供完整技术栈。

vs RackSched #

Blink 和 RackSched 同属"将调度从 CPU 移到专用硬件"范式，但粒度差异三个数量级：RackSched 在 per-request 粒度做 inter-server 路由（ns 级决策）[racksched-osdi20]，Blink 在 per-token 粒度做 intra-server 执行（μs 级决策）[2604.07609]。RackSched 使用 programmable switch（Tofino ASIC），Blink 使用 DPU + GPU——硬件载体不同。分层组合自然：RackSched 做 L7 请求调度、Blink 做 device-level 执行调度。

可攻击面 #

1. 单 GPU 限制严重制约适用性：Blink 仅支持单 GPU 推理，模型必须放入 GPU 显存 [2604.07609]。主流大模型（Llama 3.1 70B/405B、DeepSeek V3 671B）需 tensor/pipeline parallelism 跨多 GPU——Blink 无法服务这些场景。Qwen-3 32B 实验中 Blink 相对基线优势已收窄至 parity 水平 [2604.07609]（TRT-LLM P50 TTFT 531.7ms vs Blink 786.2ms），说明 GPU-bound regime 下 CPU bypass 收益有限。
1. BlueField-3 DPU 硬件依赖：Blink 需要 NVIDIA BlueField-3 DPU + 200Gbps RDMA link [2604.07609]。BlueField-3 是 NVIDIA 独家产品，且 DPU 的 TCO（采购 + 运维）未计入 Blink 的能效分析。若将 DPU 成本分摊到 per-token 能效，Blink 的 13.7–48.6% 节省 [2604.07609] 可能被部分抵消。
1. 120 fire-and-forget launch limit 是未记录的 CUDA 行为：Blink 的 tail-launch recovery 依赖对 CUDA 内部行为的逆向工程——120 个 outstanding launches 的硬限制"produces undefined behavior" [2604.07609]。CUDA 版本更新可能改变此行为（增大或减小限制、改变溢出语义），导致 Blink 的核心机制失效。没有公开 CUDA API 合约保护此设计。
1. interference immunity 的评估基线可能偏弱：Blink 的 interference 实验使用 pbzip2 + Ninja LLVM build 作为 interferer [2604.07609]。CPU-Slowdowns 使用 attacker-victim 模式，interferer 是同类型 LLM 请求（更贴近生产环境的 co-location）[2603.22774]。基线系统（vLLM/SGLang/TRT-LLM）在 co-located LLM workload 下的退化模式可能与 pbzip2 不同——CPU cache 访问模式不同，TLB 污染程度不同。

生态位 #

Blink 占据"CPU-free LLM inference"的独特生态位——唯一完全移除 host CPU 从推理关键路径的系统。在 bypass 技术光谱中：

系统	bypass 目标	bypass 载体	粒度	成熟度
FaRM	TCP/IP 协议栈	RDMA NIC	per-op	产业验证 [farm-nsdi14]
KRCore	RDMA QP 创建	DCT + kernel module	per-connection	开源 + 完整实验 [2201.11578]
RackSched	CPU 调度逻辑	ToR switch	per-request	开源 + 完整实验 [racksched-osdi20]
Blink	整个 CPU	DPU + GPU persistent kernel	per-token	未开源、单 GPU
OnePiece	NCCL/CPU 数据搬运	RDMA WRITE	per-message	未开源、无实验 [2601.20655]

Blink 的范式影响力在于证明了一个激进假说："host CPU 完全不参与 steady-state 推理是可行的且有性能收益"。此前共识是 CPU 承担调度+编排是必要的（vLLM/SGLang 的架构前提）。Blink 用 33,000 行 CUDA/C++ 工程验证了替代方案。

在 MoE 模型上优势最大（Qwen-3 30B-A3B：P99 TTFT 3.45× lower, throughput +37% vs TRT-LLM）[2604.07609]——因为 MoE 每 token 仅激活 3B/30B 参数，GPU 计算快但 CPU 编排开销不随之缩小。这预示了随着 MoE 模型普及，CPU bypass 的价值将持续增长。

未探索方向 #

1. Multi-GPU persistent scheduling：当前最急迫的扩展方向。Blink 提及 GPU-native collectives 和 GPU-initiated RDMA 作为 multi-GPU 路径 [2604.07609]，但需解决：(a) 跨 GPU 的 persistent kernel 间如何同步——需替代 NCCL 的 CPU-initiated collective；(b) KV-cache 跨 GPU 管理——device-side memory allocator；(c) multi-DPU 协调——哪个 DPU 做 master scheduler。KRCore 的 DCT 虚拟化 [2201.11578] 可为 multi-GPU RDMA 连接管理提供基础。
1. DPU 侧 tokenization 的扩展性瓶颈分析：Blink 的 DPU tokenizer 在 BlueField-3 的 16 ARM A78 核心上运行 [2604.07609]。CPU-Slowdowns 发现 tokenization 占 TTFT 50% 且与输入长度线性增长 [2603.22774]。需量化：在 128K token context 场景下，16 ARM 核心的 tokenization 吞吐是否能跟上 GPU 消费速率？DPU 是否会取代 CPU 成为新的 tokenization 瓶颈？
1. 与 RackSched 的分层集成：RackSched 做 inter-server per-request 调度 [racksched-osdi20]，Blink 做 intra-server per-token 调度。集成需解决反馈信号问题：Blink 的 ring buffer slot 占用率如何 piggyback 到 RackSched 的 LoadTable？可通过 DPU 在 reply 包中插入 INT 字段实现——DPU 已在网络路径上，添加 piggyback 字段自然。
1. chunked prefill + speculative decoding 在 GPU-resident scheduler 中的实现：Blink 列出这些技术作为兼容扩展但未实现 [2604.07609]。chunked prefill 需要 persistent kernel 动态切分 prompt 并交错 decode batches——比当前"全 prefill 后 decode"模式复杂得多，需要 device-side 内存管理和调度策略变更。