RackSched: A Microsecond-Scale Scheduler for Rack-Scale Computers

相关论文 #

RackSched 将 ToR 可编程交换机用作 rack 级微秒调度器，与以下五篇论文共同构成"RDMA/bypass 驱动的分布式调度"研究簇：

本篇 vs 相关论文的 delta #

vs FaRM #

FaRM 的 bypass 策略是在端侧替换传输协议：TCP/IP → RDMA [farm-nsdi14]。RackSched 的 bypass 策略是在网络设备上嵌入计算逻辑：软件调度器 → 交换机数据面调度器。核心 delta：FaRM 通过 RDMA 让每个数据操作更快（10× throughput）[farm-nsdi14]，RackSched 通过在网络路径上做调度让请求分配更优（近线性扩展 + 单服务器级尾延迟）[racksched-osdi20]。FaRM 的优化是端到端的（任何应用受益），RackSched 的优化是 workload-specific（仅适用于无状态/已复制的微秒级服务）。

vs KRCore #

KRCore 优化的是"建立一条 RDMA 连接需要多久"（5.4μs vs 15.7ms）[2201.11578]，RackSched 优化的是"哪台服务器处理这个请求"。两者的 trade-off 维度正交：KRCore 降低传输层开销，RackSched 降低路由层开销。KRCore 的 DC→RC 升级策略 [2201.11578] 暗含了类似 RackSched 的负载感知思想——检测 hot path 并优化，但在端侧而非网络侧执行。

vs OnePiece #

OnePiece 的 Node Manager 实现了一种集中式调度器（Paxos HA、GPU 利用率监控、阈值触发实例调拨）[2601.20655]。RackSched 也是集中式调度但在交换机硬件实现。核心 delta：NM 的调度决策需 CPU 时间 + Paxos 共识，延迟在毫秒级；RackSched 的 power-of-k-choices 全在交换机数据面完成，延迟在纳秒级 [racksched-osdi20]。但 RackSched 只做 stateless 请求路由，OnePiece 的 NM 做有状态资源编排（GPU 实例分配/回收）——职责范围不同。

vs Blink #

Blink 和 RackSched 都将调度决策从 CPU 移到专用硬件（DPU vs ToR switch），但作用粒度根本不同。Blink 解决 per-token 调度：每个 decode step 的 CUDA graph 选择和 launch [2604.07609]。RackSched 解决 per-request 路由：首次请求到达时选择目标服务器 [racksched-osdi20]。在 LLM serving 场景中，两者自然分层：RackSched 决定请求去哪台 GPU 服务器 → Blink 在该服务器上完成 CPU-free 推理。

vs CPU-Slowdowns #

CPU-Slowdowns 识别了两个结构性瓶颈：barrier 同步放大和 shared-memory broadcast 竞争 [2603.22774]。RackSched 的 INT piggyback 反馈机制 [racksched-osdi20] 提供了一个旁路——如果调度决策在交换机完成，CPU 端无需承担调度逻辑，可减轻 broadcast 竞争。但 CPU-Slowdowns 发现的 tokenization 瓶颈（占 TTFT 50%）[2603.22774] 是 RackSched 无法解决的——交换机不能执行 BPE 分词。

可攻击面 #

1. 微秒级请求假设不适用于 LLM 推理：RackSched 的理论基础（排队论、power-of-k-choices 收敛）假设请求服务时间在 50–5000μs [racksched-osdi20]。LLM prefill 可达数百毫秒至数秒（Blink 实验中 Qwen-3 32B P99 TTFT ~9.5s）[2604.07609]，decode 则持续数十秒。在此时间尺度下，RackSched 的亚微秒反馈环路优势被稀释到可忽略，power-of-k-choices 的调度增益也因请求处理时间的高方差而衰减。
1. 无状态假设与 KV-cache 状态冲突：RackSched 假设服务无状态或已复制 [racksched-osdi20]，但 LLM 推理的 KV-cache 是强状态——一旦 prefill 分配到某台 GPU，后续 decode 必须在同一 GPU 或迁移 KV-cache（代价极高）。RackSched 的 per-request 路由自由度在 LLM 场景下被 KV-cache affinity 约束为近零。
1. Tofino ASIC 资源紧张：RackSched 消耗 25% Stateful ALU（最紧约束资源）[racksched-osdi20]。若要同时在交换机上运行其他数据面功能（遥测、ACL、ECMP），剩余资源不足。在多租户 GPU 集群中，ToR 交换机通常需承担多种网络功能，不太可能专用于调度。
1. ReqTable 规模限制：64K slots 限制了最大并发请求数 [racksched-osdi20]。LLM serving 的长请求（每个持续数十秒）意味着 64K 并发 slot 可能不够——若每个请求占用 slot 30s，最大新请求到达率仅 ~2K RPS。论文未分析长请求场景下 ReqTable 溢出概率。

生态位 #

RackSched 占据"网络侧 μs 级调度"的独特生态位——唯一在交换机数据面实现 per-request 动态负载感知调度的系统。在 bypass 技术的空间划分中：

• 端侧数据面 bypass：FaRM (RDMA)、KRCore (DCT) → 加速端到端传输 [farm-nsdi14] [2201.11578]
• 端侧控制面 bypass：Blink (DPU + GPU persistent kernel) → 加速推理编排 [2604.07609]
• 网络侧调度 bypass：RackSched (ToR switch) → 加速请求路由

RackSched 的范式影响力在于证明了"网络设备不只是管道，可以承担调度智能"。但其在 LLM 场景的直接适用性受限于三个假设不匹配：请求时间尺度（μs vs s）、状态性（stateless vs KV-cache）、调度粒度（per-request vs per-token）。

在 GPU 推理集群的实际部署中，RackSched 更可能作为"入口层负载均衡器"——在多个 vLLM/SGLang 实例间做粗粒度请求分发，而非做细粒度的 per-token 调度。此定位与 KV-cache aware routing（Mooncake 等系统探索的方向）有交叠但机制不同。

未探索方向 #

1. KV-cache-aware in-network scheduling：扩展 RackSched 的 LoadTable 为包含 per-server KV-cache 命中率的状态表，INT piggyback 携带 prefix-cache hit ratio 而非仅 queue length。交换机可据此做 prefix-aware 路由——将共享相同 system prompt 的请求路由到同一服务器。这需要在交换机数据面增加 prefix hash 匹配逻辑。
1. RackSched + Blink 分层架构：RackSched 在 ToR 做 inter-server 请求分发（ms 粒度，基于 GPU 利用率），Blink 在 server 内做 CPU-free per-token 调度（μs 粒度）[2604.07609]。反馈信号从 Blink 的 ring buffer 状态（slot 占用率）piggyback 到 RackSched 的 LoadTable，形成两级 bypass 调度闭环。
1. 跨 rack 扩展：RackSched 限于单 rack（ToR 交换机直连服务器）[racksched-osdi20]。大规模 GPU 集群跨多 rack，需要 spine/leaf 层的分层调度。可编程交换机在 spine 层的部署成本更高，但 power-of-k-choices 的理论优势不依赖单跳——可在 leaf 层做 intra-rack 调度、spine 层做 inter-rack 调度。
1. GPU 推理请求的服务时间预测：RackSched 的调度质量依赖准确的负载信息。LLM 请求的服务时间高度异构（短 prompt → μs prefill，长 prompt → s prefill），如果交换机能基于首包的 token 数预估服务时间（而非仅看 queue length），调度质量将显著提升。但这要求在数据面解析应用层 payload——超出当前 P4 的典型用例。