Awesome System Papers Wiki

OSDI-2026

258分钟阅读

OSDI 2026

总览

OSDI 2026 共收录 136 篇论文。本综述为了便于比较，把它们重排为 17 类、每类 8 篇；这不是会议官方 session 划分，而是按论文真正解决的问题和主要证据来归类。前三分之一集中在 LLM 推理、训练、RL、GPU 编译和 AI 运维；中间三分之一处理 CXL、内存、虚拟化、存储与数据库；其余论文覆盖网络、复制、一致性、安全、程序分析和云运维。AI 系统很显眼，但没有替代传统 OS，反而把内存层级、故障恢复、隔离和调度重新推到前台。

最值得注意的变化不是某个单点倍率，而是论文越来越少把一个资源或一条快路径单独拿出来优化。Strata-OSDI26 同时处理 KV 布局、GPU 搬运和调度，TrainMover-OSDI26 同时处理运行时预热、通信状态与角色迁移，FORGE-OSDI26 同时处理远端原子开销、对象分组和 RNIC 片上小元数据区。系统的真实边界常跨 GPU、CPU、NIC、CXL、SSD 与控制面；因此，本页把“最强结果”和“证据边界”并列写，不把论文标题中的最佳结果当作普遍保证。

生产证据也明显增多。AEGIS-OSDI26 分析约 3500 万 GPU-hours，Alibaba-ASI-OSDI26 使用 15.5 万 GPU 的集群轨迹，OpenTela-OSDI26 在 Swiss AI/Alps 的三个子集群运行超过 22 个月，StriaTrace-OSDI26 覆盖 1700 多个实例和每天 1.8 亿次请求，CoreSec-OSDI26 汇总三年 70 万余起事件。大规模轨迹提高了问题真实性，但这些数据多来自单一组织，外部读者仍需区分“生产中确实发生”与“机制能跨组织复现”。

阅读口径

  • 论文集合只统计会议官方论文集中的 136 篇正式论文；keynote 等非论文演讲页面不计。
  • 每篇论文只放进一个主类别。它仍可能与其他类别强相关，例如 Umap-OSDI26 同时属于虚拟内存、分布式存储和模型加载，本页按其主要机制放入存储与 I/O。
  • 数字尽量保留论文的模型、硬件、工作负载和基线。写“最高”表示扫描中的最佳点，不表示所有点都达到该倍率。
  • 模拟、轨迹回放、微基准、真实部署和端到端应用证据分开看。qTPU-OSDI26 的多 QPU 扩展主要基于估算执行时间，但也包含 IBM Marrakesh 单 QPU 真机验证；Murakkab-OSDI26 使用构造的轨迹回放，OpenTela-OSDI26 则有长期生产运行，三者不能按同一置信度解读。
  • “无损”“安全”“线性一致”或“形式验证”都只在论文定义的语义和可信计算基内成立。ECHO-OSDI26 的无损是相对原生稀疏模型的 exact top-k，Spain-OSDI26 的证明允许显式数值误差界；ZENO-OSDI26 的普通 DBMS 不在隐私 TEE 内，而在另一个受信任的完整性区，保证只在这种分区信任模型内成立。

论文分类与全量设计空间矩阵

下面 17 类各含 8 篇论文。每篇都先给出核心问题、机制、关键结果和证据边界，再在同类矩阵中对齐比较；17 个矩阵合起来正好覆盖全部 136 篇论文，没有重复。

1. LLM 推理系统与资源调度（8 篇）

这一组关注的不是单个算子还能快多少，而是请求、模型和推理阶段怎样共享 GPU。共同背景是：prefill 与 decode 的资源需求不同，输出长度有长尾，prefix cache 会让路由产生“局部性与负载”的冲突，大量冷模型又不值得一直占着显存。各论文分别从离线批处理、PCIe 多卡流水、P/D 错峰、prefix-aware 路由、本地超大 MoE、复杂 workflow、跨集群共享和多模型弹性服务切入。

逐篇解读

  • BatchGen-OSDI26：核心问题是在线 serving 沿用“一个 sequence 长期绑定一张 GPU、一次 forward 不可中断”的模型后，离线大批量 MoE 仍得不到足够大的 expert batch，最后少数长输出还会拖住整批。机制是把 sequence 变成可 YIELD/COMBINE/PARTITION/MIGRATE 的事件驱动 coroutine，在 Attention–MoE 边界重组 token，并在尾部把 straggler 迁到空闲 GPU。关键数字是 10K 请求、128 张 H20 的 batch completion time 最多改善 2.3 倍；单张 A5000 的 offloading 实验相对最强可运行基线最多快 9.6 倍。证据边界是主实验为 8–128 张 H20/H200 的离线固定请求集合；单卡结果仍需 30.8–328.5 小时，部分基线由作者重实现，且没有 dense model、VLM、在线到达或公平性评测。

  • DCP-OSDI26：核心问题是 PCIe GPU 上用 pipeline parallelism 避免 TP All-Reduce 后，长短 prompt、prefill/decode 混跑和 decode batch 波动会在相邻 stage 之间制造气泡。机制是 dynamic chunked prefill 根据 SLO 和在线预测选择 chunk 大小，再用 delay scheduling 重排 decode 请求，尽量让流水段同时有活可做。关键数字是在 4 张 A100 PCIe、Qwen2.5-14B/32B 上，相对调优过的静态 PP，Azure trace 的 P90 TPOT/E2E 最多降低 35%/31%，CNN trace 最多降低 42%/36%；在线性能模型的 MAPE 为 3.26%。证据边界是请求按 Poisson 和缩放后的 15 分钟 trace 生成，只报告以 P90 SLO 为主的 goodput；在 decode-heavy 数据上，delay scheduling 反而让 P99 TPOT 最差增加 15%，也没有 NVLink、MoE 和更多节点结果。

  • EcoServe-OSDI26：核心问题是 prefill/decode 共置会互相干扰，完全拆分又要经网络搬 KV cache，普通 Ethernet 下代价很高。机制是让每个完整模型副本按较长时间窗轮流做 prefill 和 decode，并把多个副本的窗口错开，让系统始终有副本接收 prefill，同时不跨实例搬 KV。关键数字是在 32 张 L20 与普通 Ethernet 上，相对 vLLM、Sarathi、DistServe、MoonCake 的 goodput 分别提高 1.96、1.99、2.51、2.40 倍；把所有可运行组合平均后仍为 2.01、1.87、3.43、3.41 倍。证据边界是方法需要同时放下多个完整模型副本；到 H100 高速互联上收益缩到 1.34、1.25、1.75、1.24 倍，CodeLlama 个别点 MoonCake 更快，公开 workload 主要是合成到达，也没有完整成本和能耗账本。

  • LMetric-OSDI26：核心问题是 router 若只追求 prefix KV 命中，会把热 prefix 请求堆到少数 instance；若只做最短队列，又会浪费已有 cache。机制是用“路由后需要新算的 prefill token 数 × 当前 batch size”作为无权重分数，把缓存复用和排队代价放进同一量纲。关键数字是在 16 张 H20、Qwen2-7B/Qwen3-30B 与多条真实 trace 回放中，相对 vLLM 的 mean TTFT/TPOT 最多降低 92%/24%；数百 GPU 的一天 production canary 相对旧 scheduler 降低 39%/51%。证据边界是主要实验为同构、共置实例，默认到达率缩为测试床最大吞吐的一半；生产结果没有公开 P99、成本、随机化和完整请求分布，遥测陈旧、hot-prefix 突发与跨机异构尚未验证。

  • Wang-LocalMoEInference-OSDI26：核心问题是 DeepSeek-R1、Kimi-K2 这类原生 FP8 超大 MoE 权重约 1 TB，消费级 GPU 显存放不下，逐层从普通主存搬权重又很慢。机制是把权重留在双路 CPU DRAM：长 prefill 把当前 expert 流式送入 1–2 张 RTX 5090，decode 在 CPU 上只算被激活的稀疏 expert，再用 SmallEP、节点内 P/D 分离和 AVX-512 FP8 GEMV 降低通信与小矩阵开销。关键数字是 DeepSeek-R1 671B 单流 FP8 decode 达 21.5 token/s，双 GPU 可让约 45K-token prompt 满足论文定义的 30 秒 TTFT 目标。证据边界是机器有 1.15 TB DDR5 和双 EPYC，并非普通桌面；优势集中在长于约 512 token 的 prefill，部分 baseline 数据来自异机或外推，且没有云端可用性、并发尾延迟、功耗和长期稳定性。

  • Murakkab-OSDI26：核心问题是 LLM workflow 的模型、工具、并行方式、实例数、路由和质量档位互相影响，逐层手调会得到局部最优。机制是让开发者只写任务依赖，系统根据离线 profile、请求 SLO、流量和硬件供给，联合搜索 workflow 参数、模型/工具选择、placement、实例数与路由。关键数字是在论文构造的 24 小时双 workflow trace replay 中，相对手工 LangGraph，GPU 数从 2,568 降到 912，能耗从 82.1 MWh 降到 22.1 MWh，成本从 211.7K 美元降到 47.2K 美元。证据边界是这些是画像驱动的构造回放，不是同规模 24 小时线上 A/B；许多节省来自允许更低 accuracy tier 或更宽 SLO，例如 Code Generation 的大幅下降主要来自换模型，因此不能解释为同质量下的纯系统加速。

  • OpenTela-OSDI26：核心问题是不同 Slurm/Kubernetes 集群中的闲置 allocation 难被普通用户发现和共享，集中服务又容易要求管理员统一改造。机制是用用户态 wrapper 把 allocation 包成 LLM endpoint，用 libp2p 与 CRDT gossip 维护去中心化注册表，再由 simulator 和约束规划选择能放下模型、满足精度与上下文要求的 endpoint。关键数字是 Swiss AI 部署运行超过 22 个月，累计服务 1,300 万请求和 150 亿 token。证据边界是服务是 best effort，主要生产资源来自同一 Alps 超算中的三个子集群，而不是跨国家、跨运营商的开放 WAN；论文也没有给集中式强基线、严格可用性 SLO、恶意参与者、计费与数据治理结果。

  • Prism-OSDI26：核心问题是大模型在线服务中大量模型间歇活跃，若每个模型固定占显存，冷模型浪费容量；只做时间复用又会在 KV cache 压力变化时失衡。机制是用 CUDA VMM 与 kvcached 把权重和 KV cache 都做成可伸缩的 GPU 内存气球，跨 GPU 按 KV 压力放置模型，单 GPU 内再用 slack scheduling 在空间共享和时间共享之间切换。关键数字是四组生产 trace 中任一时刻只有 23%–50% 模型活跃，活跃集合每小时变化 54–766 次；58 模型实验用 16 张 H100 达到接近 99% TTFT SLO 达标率，MuxServe++ 要 32 张才接近。证据边界是 characterization 来自 4 条 trace、端点回放只用其中 2 条且做过缩放；production shadow replay 报告 3.89 倍 token/GPU 和 2.86 倍 revenue，但负载与成本细节不公开，系统还依赖较大的 host DRAM/NVLink，所有模型都热时没有额外容量。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
BatchGen-OSDI26离线 MoE 批处理expert batch 太小、输出长尾拖批coroutine、跨序列重组、尾部迁移8–128 H20/H200；10K 请求BCT 最多改善 2.3 倍离线 workload；部分基线重实现；无 dense/VLM
DCP-OSDI26PCIe 多卡流水P/D 混跑让 pipeline 起泡动态 chunked prefill、delay scheduling4×A100 PCIe；Qwen 14B/32BP90 TPOT/E2E 最多降 42%/36%缩放 trace；decode-heavy 的 P99 可退化 15%
EcoServe-OSDI26P/D 时域错峰共置互扰，拆分搬 KV 太贵完整副本分时、实例间错峰32×L20 Ethernet对四基线 goodput 提高 1.96–2.51 倍需多个全副本；高速互联收益变小
LMetric-OSDI26Prefix-aware 路由KV 局部性与负载冲突新 prefill token × batch size16×H20 回放；数百 GPU canary回放 mean TTFT 最多降 92%同构实例；生产未报 P99 和成本
Wang-LocalMoEInference-OSDI26本地超大 MoE约 1 TB 权重放不进消费卡CPU DRAM 驻留、P/D 分工、SmallEP双 EPYC、1–2×RTX 5090671B decode 21.5 token/s1.15 TB 主存；单流、节点内、长 prompt
Murakkab-OSDI26LLM workflow 优化跨层决策互相耦合画像驱动的联合搜索与路由构造的 24 小时双 workflow 回放成本 211.7K 降至 47.2K 美元很多收益来自放宽质量/SLO；非线上 A/B
OpenTela-OSDI26跨集群共享闲置 allocation 难发现和组合用户态 endpoint、CRDT、约束放置Swiss AI 22 个月生产部署1,300 万请求、150 亿 tokenbest effort；主要是同一超算的三个子集群
Prism-OSDI26多模型弹性服务冷模型常驻、KV 压力漂移权重/KV 内存气球、压力放置、slack 调度58 模型、16/32×H10016 H100 达接近 99% TTFT SLOtrace 缩放；依赖 host DRAM/NVLink；全热无余量

跨论文综合

  • 跨论文观察：主要浪费来自“粒度绑得太死”。 BatchGen-OSDI26 解除 sequence 与 GPU 的长期绑定，DCP-OSDI26 动态改变 prefill chunk，EcoServe-OSDI26 改变 P/D 时间窗，Prism-OSDI26 则让模型权重和 KV 都能伸缩。四者的共同点是先找到可安全切换的边界，再重新聚合工作。
  • 跨论文观察：局部信息越来越重要。 LMetric-OSDI26 依赖 prefix cache 与 batch 状态，Prism-OSDI26 依赖模型活跃度和 KV 压力，Murakkab-OSDI26 依赖 SLO、质量和成本画像。只看队列长度或 GPU 利用率，已经不足以做好的服务决策。
  • 共同假设：未来可以被预测，切换成本可以摊销。 DCP-OSDI26 假设长度和 stage 时间可预测，Murakkab-OSDI26 假设离线画像能代表线上，Prism-OSDI26 假设活跃集合变化不会快到超过换入换出速度，OpenTela-OSDI26 假设 gossip 状态仍足够新鲜。这些假设一旦遇到突发、漂移或故障，收益可能迅速变成排队和迁移开销。
  • 主要张力：专用优化与通用服务互相拉扯。 Wang-LocalMoEInference-OSDI26 为单机超大 MoE 深度定制，BatchGen-OSDI26 面向离线大批量，EcoServe-OSDI26 需要多份完整副本；OpenTela-OSDI26 和 Murakkab-OSDI26 则追求跨模型、跨集群和跨 workflow 的通用性。越专用，单点收益往往越高，但适用范围、运维和复现实验越窄。
  • 后续方向：统一报告预测失误和重配置税。 可在 LMetric-OSDI26、DCP-OSDI26、Prism-OSDI26、Murakkab-OSDI26 上用同一套突发与漂移 trace，分别报告预测误差、迁移/换模字节、cache loss、P99、能耗和失败回退；这样才能比较“更聪明的策略”是否在净成本上胜出。
  • 后续方向：把资源效率与用户公平一起纳入。 DCP-OSDI26 的 delay scheduling 可能伤害个别请求，LMetric-OSDI26 可能形成 hot-prefix 偏置，OpenTela-OSDI26 只有 best-effort 保障。下一步应公开 starvation、tenant isolation、deadline miss 和取消请求浪费，而不只看 mean latency 或总 goodput。

2. LLM 推理内存、稀疏与设备协同（8 篇）

这一组把瓶颈放到“模型或 KV 放不下、数据在哪里、何时搬、谁先使用”。ADAngel 和 KAIROX 处理低精度或稀疏权重计算，DirectKV、ECHO、Strata 处理跨 GPU/CPU/SSD 的 KV 路径，Nixie 与 Sereno 处理本地设备上的共享内存争用，SPEX 则利用推理搜索中的依赖空档。它们都用更多预测、缓存层和运行时状态，换取更少的数据搬运或更高的设备利用率。

逐篇解读

  • ADAngel-OSDI26：核心问题是 W4A8 等混合精度 GEMM 没有一个 kernel 能在 prefill、decode、不同 shape 和 bit-width 上一直最好。机制是用 DPR 统一描述数据布局与计算，再生成 Padding、Split、Bitwise 三类 kernel，部署前穷举建立模型—硬件专用的最佳实现表。关键数字是 Llama-3-8B 在 Jetson AGX Orin 上，W4A8 decode 相对 llama.cpp 最多快 5.10 倍，prefill TTFT 相对 TensorRT-LLM 快 1.17–2.38 倍。证据边界是基线量化格式并不完全相同；建表耗时 5.7 小时，多布局权重约占 14.96 GiB、峰值显存 18.8 GiB，只测一个主要模型与 Orin/A100，也没有报告量化后的任务质量。

  • DirectKV-OSDI26：核心问题是 GH200 的 NVLink-C2C 允许 GPU 直接读 CPU 内存，但朴素 zero-copy 会让多个 query/head 重复跨链路读取同一 KV。机制是按 CPU memory 特性重新 tiling，用 warp pipeline 遮住远端访问，并把 projection 与 Attention 融合，去掉先把 KV 搬进 HBM 的 staging buffer。关键数字是 GPU 内存降到 47 GB，比其他 offloading 系统平均少 43%；论文报告跨 context 平均提速 1.2 倍。证据边界是正文没有为 1.2 倍始终固定同一 baseline；设计强依赖 GH200 的高带宽一致 CPU–GPU 内存，默认 FP16/BF16 与 MHA/GQA，不能直接外推普通 PCIe 服务器、稀疏 attention 或多租户负载。

  • ECHO-OSDI26：核心问题是原生稀疏 attention 仍需保存完整历史 KV，长上下文时 GPU 容量先耗尽；传统 host offload 又不易纳入 CUDA Graph。机制是把完整 KV 留在 host，只在 GPU 缓存最终选中的 token，并把 allocate/free/recall 做成 GPU 端、可 graph capture 的操作，同时预取候选 top-k。关键数字是在 8 张 H20 上用 1.8M-token、约 1000 GB host pool，InfiniteBench 固定输出吞吐最高为 SGLang 的 2.15 倍、vLLM 的 4.1 倍。证据边界是“无损”只指预取不改变最终 exact top-k；主要收益来自内存扩大后的并发，intra-query prefetch 端到端最多贡献 4%，且只验证 DSA、H20/H200、极长上下文，轻载延迟还可能变差。

  • KAIROX-OSDI26：核心问题是显存不足时，离线固定的 hot-neuron placement 会随 batch 和语义变化失效，CPU–GPU 频繁搬神经元。机制是提前一层预测激活，把神经元成组传输，再用带反馈的 temporal activation momentum 决定哪些组继续驻留 GPU。关键数字是在两台消费级独显主机、标准生成负载中，相对 llama.cpp 的几何平均加速为 4.45/5.00 倍，相对三种稀疏基线为 2.08–3.06/2.36–2.58 倍。证据边界是主评测为 batch 1，预测会改变实际计算路径；offline profile 来自 C4、请求来自固定 ShareGPT，质量平均下降虽通常小于 0.5，但不是所有配置都如此，也没有 unified memory、非 NVIDIA 或在线多请求验证。

  • Nixie-OSDI26：核心问题是多个本地 ML App 各自接近占满显存时，UVM 会在两个工作集之间逐页抖动，交互应用和后台任务都变慢。机制是由统一 daemon 联合决定 kernel admission、整 App 驻留和双向迁移，用粗粒度 ownership 避免 page-level thrashing。关键数字是在 RTX 5090 上，交互式代码补全相对 nvshare 快 3.1–3.8 倍；保持相同 TTFT 时 pinned memory 最多减少 66.8%。证据边界是频繁 1 秒交互会让后台吞吐下降 23.5%；实现假设同一用户、整 App 可暂停且 kernel 较短，只报平均值，没有 P99、长期公平、硬 preemption 和多租户安全结果。

  • Sereno-OSDI26：核心问题是手机 NPU 与前台 CPU/GPU 共享 DRAM，但 NPU 默认高优先级；后台 LLM 本身只少约 1% 吞吐，却让前台应用明显卡顿。机制是把 speculative decoding 的 draft layer 当成亚毫秒级让出点，自探测争用，再联动 draft preemption、verification batch 和 micro-sleep 调节内存带宽。关键数字是在 OnePlus 13、Llama-3.1-8B 加 1B draft、30 个应用上，平均 jank 相对 PowerServe 低 58.5%，LLM 吞吐高 26.4%；未治理时 25 个前台应用总 jank 增加 153%。证据边界是一次只运行一个前台 App 与一个后台 LLM；策略依赖 Android/NPU 的优先级行为，重游戏等 compute-bound 场景改善较小，能效 3.52 token/J 还略低于普通 speculative decoding 的 3.78 token/J。

  • SPEX-OSDI26：核心问题是 Tree-of-Thought 每扩展一步要等待 reward 决定下一分支，依赖链让 GPU 在生成与评分之间空闲。机制是利用短期 reward 排名较稳定，提前生成可能被采用的分支；多个 query 之间再共享空闲 GPU，并复用 prefix cache。关键数字是在相同 SGLang-based ToT 实现上，DFS query throughput 提高 1.8–3 倍，BFS 提高 1.2–1.9 倍。证据边界是 early termination 单独带来约 1.2 倍稳定收益，却改变了实际搜索空间；部分 AIME25 配置准确率明显下降，例如 Qwen REST5 从 70 降到 63.3。论文也没有清楚报告 GPU 数、浪费 token、能耗和 P99。

  • Strata-OSDI26：核心问题是分层 KV cache 的“命中”只有在数据及时、按 GPU 所需布局到达时才有价值；传统 CPU 控制碎片搬运和 page-first 到 layer-first 转置会拖慢 critical path。机制是让少量 GPU 线程并行搬数千碎片并边搬边转置，调度器推迟来不及的 hit，平衡 load/compute，再用 decode 填 I/O 气泡。关键数字是在 H200 长上下文、高复用场景中，相同平均 TTFT 下相对 vLLM-LMCache 吞吐最多提高 5 倍，相对 TensorRT-LLM-HiCache 最多 3.75 倍。证据边界是主机有 8 张 H200 和 1.6 TB DRAM，长上下文 workload 的 cache hit 约 95%；结果主要是平均 TTFT 与吞吐，ShareGPT 只做到相近，未充分覆盖 tail、GPU SM 争用、故障、低命中率和多租户。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
ADAngel-OSDI26混合精度 kernel最佳 W4A8 实现随阶段和 shape 改变DPR 与三类 kernel、离线 oracle 表Orin/A100；Llama-3-8BOrin decode 最多快 5.10 倍格式不完全等价；profile 和多布局存储昂贵；无质量结果
DirectKV-OSDI26CPU–GPU KV 直读zero-copy 重复拉取 KVCPU-aware tiling、warp pipeline、P-A fusionGH200 长上下文HBM 47 GB，平均少 43%1.2 倍基线口径不固定；依赖 NVLink-C2C
ECHO-OSDI26稀疏 attention KV offload完整 KV 撑爆 HBMhost 全量 KV、GPU selected cache、graphable 管理8×H20；1.8M-token host pool吞吐最高为 SGLang 2.15 倍收益主要来自并发；“无损”只约束 exact top-k
KAIROX-OSDI26神经元 offload静态热度随语义漂移前瞻预测、成组传输、反馈动量两台消费级 GPU 主机；batch 1对 llama.cpp 几何平均快 4.45/5.00 倍近似计算；固定 profile/trace；质量非始终等价
Nixie-OSDI26本地多 App 共享UVM page thrashingkernel admission、整 App 驻留、全双工迁移RTX 5090 交互与后台混跑代码补全快 3.1–3.8 倍高频交互牺牲 23.5% 后台吞吐；同用户假设
Sereno-OSDI26移动端内存争用高优先级 NPU 伤害前台流畅度draft 让出点、自探测、batch 与 sleep 控制OnePlus 13；30 Appjank 低 58.5%，LLM 吞吐高 26.4%单前台 App；平台策略专用；能效略降
SPEX-OSDI26ToT 推测执行reward 依赖制造 GPU 空档分支预测、跨 query 并行、prefix 复用SGLang ToT；DFS/BFSDFS throughput 提高 1.8–3 倍early termination 改语义；部分准确率下降
Strata-OSDI26分层 KV cache命中数据到得太晚、布局不合GPU 搬运/转置、delay-hit、I/O 填充8×H200；DRAM/SSD 变体同平均 TTFT 下吞吐最多高 5 倍长上下文、高命中；主要报平均值；硬件资源很强

跨论文综合

  • 跨论文观察：容量优化已经变成数据路径优化。 DirectKV-OSDI26、ECHO-OSDI26、Strata-OSDI26 都不是简单把 KV 放到更大内存，而是重写 tiling、预取、布局转换和调度；慢层容量只有在搬运成本能被计算遮住时才有意义。
  • 跨论文观察：预测正在替代静态放置。 KAIROX-OSDI26 预测下一层神经元，SPEX-OSDI26 预测下一条搜索分支，Strata-OSDI26 判断 cache hit 是否来得及，Sereno-OSDI26 从自身延迟推断带宽争用。它们都接受小量误判，以换取更早行动。
  • 共同假设：可让出的细粒度边界存在。 Nixie-OSDI26 需要 App/kernel 边界，Sereno-OSDI26 依赖 draft layer 的亚毫秒边界，ECHO-OSDI26 要把内存管理变成 GPU graph 内操作，Strata-OSDI26 要把 KV 拆成可独立搬运的页面。若 kernel 太长、状态不可迁移或 layout 不透明，系统很难安全介入。
  • 主要张力：省显存不一定省时间，也不一定无损。 DirectKV-OSDI26 的远端读可能被链路限制，ADAngel-OSDI26 与 KAIROX-OSDI26 的低精度/稀疏预测可能改变质量，SPEX-OSDI26 的 early termination 更直接改变搜索。报告容量或吞吐时必须同时给质量、轻载延迟和失败配置。
  • 主要张力：前台体验与后台吞吐。 Nixie-OSDI26 在频繁交互下主动牺牲后台吞吐，Sereno-OSDI26 用更多让出点保护前台，ECHO-OSDI26 在轻载时管理开销反而突出。这说明“GPU/NPU 利用率越高越好”不是终端系统的唯一目标。
  • 后续方向：做统一的多层内存压力测试。 可把 DirectKV-OSDI26、ECHO-OSDI26、Strata-OSDI26 放到相同模型、context、prefix hit、PCIe/C2C/SSD 带宽和并发曲线上，联合报告 HBM、host/SSD bytes、SM 占用、TTFT/TPOT P99、能耗与 OOM ceiling，避免只在各自最合适的硬件上比较峰值。
  • 后续方向：把预测错误当作一等指标。 对 KAIROX-OSDI26 和 SPEX-OSDI26 报 precision、浪费计算与质量，对 Sereno-OSDI26 报误判争用后的前台/后台损失，对 Strata-OSDI26 报 delay-hit 错误率；再提供保守 fallback 和在线校准成本。

3. 大模型训练、通信与容错（8 篇）

这一组覆盖训练系统的三条关键路径：算得对、算得快、出故障后尽快继续。AEGIS、OpGuard 和 TrainMover 分别处理静默硬件错误、软件/执行差异定位和机器替换；Hetu v2、Kareus、Syncopate、Tessera 重新安排异构设备、通信、流水与能耗；Cocoon 则把隐私训练中特殊的历史噪声计算放到分层内存。它们都说明：大规模训练的控制面已经不能只管理“哪个 rank 在哪张卡”，还要理解 tensor 边界、通信依赖、硬件状态和可提前完成的恢复工作。

逐篇解读

  • AEGIS-OSDI26：核心问题是 silent data corruption（SDC）可能不崩溃、不触发 ECC，却悄悄污染训练；若对所有算子做高精度检查，成本又无法接受。机制是在线 cSensor 采样组合代数高精度校验与训练中本来存在的重复计算，先找可疑 GPU/算子；离线 cVerifier 再用更重的检查确认。关键数字是在 3,500 万 GPU-hours 的生产部署中平均开销为 0.86%，发现 18 起 SDC、涉及 13 张 GPU；对 8 张已知坏卡，AEGIS 检出 8 张，vendor 工具只检出 2 张。证据边界是 0.86% 来自采样，不等于每个算子都完整检查；事件极少、缺少无偏 ground truth，检查依赖相对确定的算子和重复计算，对 common-mode 错误、未被采样的短暂错误与控制面故障覆盖有限。

  • Cocoon-OSDI26：核心问题是相关噪声隐私训练为改善模型效用，要保留约 (b̂−1)×参数量 的历史并在每步做大 GEMV，模型稍大就超过 HBM。机制是把历史分片到 GPU、CPU 和 CXL near-memory processing，在数据所在处并行算；对稀疏 embedding，则预计算并合并未来噪声，减少每步随机访问。关键数字是非平凡 DLRM 配置相对较好基线快 2.33–10.82 倍，加入 NMP 的大模型配置快 1.23–2.32 倍。证据边界是 NMP 结果由真实 GEMV 加按 22 GB/s 缩放的 memcpy 模型组成，并非完整真实 CXL 集群；LLM 只到 1.3B/4 GPU，embedding 优化还采用较弱攻击者模型，固定 sampler、未来投影存储和真实隐私效用都需进一步验证。

  • Hetu-v2-OSDI26：核心问题是标准 SPMD 要求设备对称，在 H800/H20 混合、故障后少卡和变长数据中会让快卡等慢卡或被迫按最弱设备切分。机制是 HSPMD 用两层非对称 annotation 表达不同设备的分片与执行差异，编译器为每类设备生成专用 graph，运行时按场景在线切换 graph。关键数字是在 16 张 H800 加 32 张 H20 上训练 32B Llama，step time 为 6.05 秒，DeepSpeed、Megatron、HexiScale 分别为 13.78、10.45、8.06 秒。证据边界是只覆盖两种 GPU、最多 48 张和 Llama 系列；高质量 plan 来自场景专用外部 planner，其搜索成本和次优风险没有系统验证，所谓免重启恢复依赖可用的数据并行副本，也缺少真实 crash 注入。

  • Kareus-OSDI26：核心问题是通信何时启动、占多少 SM 和 GPU 频率会共同改变计算—通信争用与能耗，分开调优容易互相抵消。机制是把 iteration 分成可搜索局部区间，为每段联合选择通信时机、SM 配额和频率，再组合成时间—能耗 Pareto 前沿。关键数字是在 16 张 A100 的 1.7B/3B 实测中，相对 Megatron 的最大时间降幅为 14.9%、最大能耗降幅为 22.1%，两者来自不同配置；相对 Megatron+Perseus，同时间最多省 28.3% 能耗，或同能耗最多快 27.5%。证据边界是 70B 主要靠模拟，搜索本身约 32 GPU-hours；能耗只算 GPU，profile 假设训练阶段稳定，也没有更大网络、动态频率干扰或端到端收敛结果。

  • OpGuard-OSDI26：核心问题是生产训练故障可能来自 framework、fusion、kernel、硬件或输入；不同实现的完整执行轨迹又无法逐条对齐。机制是在两个可比较 run 的共同模型算子边界记录轻量 XOR fingerprint，先固定可避免的随机性，再用容忍局部乱序的 mapper 找最长逐位相同前缀，把第一个差异定位到 faulty operator 或其首个 consumer。关键数字是 ByteDance 的 20 个生产故障全部定位到该边界；表中 11 个案例从历史人工 4 小时–14 天缩为论文估算的 UI 操作 5–30 分钟。证据边界是 trusted runtime 增加约 25%–45% 运行时间，完整模式约 80%–95%；必须有健康 reference run，时间节省不是随机对照的人体实验，硬件/模型和 false positive 信息也有限。

  • Syncopate-OSDI26：核心问题是上层分布式计划通常只到 operator/collective 粒度，过粗 kernel boundary 会留下 launch、wave quantization 和通信尾部，手工 distributed kernel 又难复用。机制是把通信 region 表示为由计算 tile 组成的 chunk，推导 chunk—tile 依赖，按数据到达顺序重排 tile，并在 copy engine、TMA、CUDA load/store 和不同 SM 配额间搜索。关键数字是在单机 4/8 张 H100 的 GEMM/attention operator 上，对既有 compiler lowering 平均快 1.3 倍、最高 4.7 倍；对最佳手写 GEMM baseline 的平均性能为 99.8%/104%。证据边界是两组数字不是同一 baseline；输入仍需要已有 global communication plan 和带注释的 Triton kernel，只测单机 NVLink、固定 shape 的 operator，没有完整训练、跨节点、调优总成本或非 NVIDIA 结果。

  • Tessera-OSDI26：核心问题是异构 MoE 的不同 layer pair 可隐藏的通信比例相差约 3 倍，按串行 FLOPs 平分 pipeline 再套统一 overlap 会重新失衡，router 波动还会产生运行时气泡。机制是为候选 layer pair 生成并实测细粒度 overlap schedule，再联合选择 pipeline partition；运行时把 Wgrad 等可移动任务塞入临时空档。关键数字是在 4,096–12,288 张 Hopper GPU 的五个 Qwen3/Qwen3-Next 生产任务上，MFU 相对内部基线提高 20.0%–32.8%。证据边界是规模证据强，但模型、基线、硬件细节和 trace 为内部数据，外部难以复现；系统仍限制在固定 pipeline 模板，profile 在 64 GPU 上可花约 3,050 秒，动态 bubble optimization 也可能因额外 buffer 造成 OOM。

  • TrainMover-OSDI26：核心问题是训练迁移或坏机替换时，传统 restart 把进程冷启动、kernel warm-up、通信组建立和全部状态恢复都放在停机路径。机制是提前做无通信 shadow iteration，先建立不依赖最终角色的 CCL，再增量连接变化部分；意外故障则由一台可接任首段、末段或中间段的 general standby 热切换。关键数字是 1,024 GPU 上计划迁移停机 16.6 秒、意外恢复 21.1 秒，Megatron-LM 在同图接近 300 秒；64K GPU 成本模型预测每周少浪费 55% GPU-hours。证据边界是 64K/128K 是由 1,024/32 GPU 测量、外部 MTTF 和单故障假设外推；不含 fault detection 与 rescheduling，要求布局基本不变、有兼容 standby、执行路径可 record/replay，也未覆盖相关故障和恢复中再次失败。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
AEGIS-OSDI26在线 SDC 检测全量高精度检查太贵采样 cSensor、离线 cVerifier3,500 万 GPU-hours 生产部署0.86% 平均开销发现 18 起 SDC稀有事件、无完整 ground truth；采样有漏检窗口
Cocoon-OSDI26隐私训练相关噪声历史超 HBM、GEMV 很重GPU/CPU/CXL-NMP 分片与近数据计算DLRM、最大 1.3B LLMDLRM 快 2.33–10.82 倍NMP 含缩放模型；攻击者假设与 workload 有限
Hetu-v2-OSDI26异构训练SPMD 对称性浪费混合 GPUHSPMD annotation、设备专图、在线切换16 H800+32 H20；Llama-32Bstep 6.05 秒，对 HexiScale 8.06 秒仅两类 GPU/48 卡；依赖外部 planner
Kareus-OSDI26通信与能耗共调时机、SM、频率相互耦合局部分区搜索与 Pareto 组合16×A100 实测；70B 模拟同时间最多省 28.3% 能耗峰值来自不同配置；搜索贵；只算 GPU 能耗
OpGuard-OSDI26训练故障定位异构执行轨迹难直接对齐算子边界 fingerprint、容错 trace mapping20 个 ByteDance 生产故障20/20 到 faulty op 或首 consumer需 reference；trusted 模式慢 25%–45%；时间为估算
Syncopate-OSDI26通信—计算融合operator 粒度 overlap 太粗chunk IR、tile 重排、多 backend 搜索4/8×H100 operator benchmark对 compiler 平均 1.3 倍、最高 4.7 倍对强手写主要是追平；无跨节点/完整模型
Tessera-OSDI26异构 MoE 流水layer pair overlap 差异导致失衡候选实测、联合 PP partition、运行时填泡4,096–12,288 Hopper 生产任务MFU 相对提高 20.0%–32.8%内部基线与 trace；固定模板；profile 和显存成本
TrainMover-OSDI26训练迁移与恢复warm-up/CCL 都在停机路径shadow iteration、两阶段 CCL、通用 standby最大 1,024 GPU 实测计划/意外停机 16.6/21.1 秒64K 的 55% 为外推；未含检测/重调度和相关故障

跨论文综合

  • 跨论文观察：把工作移出关键路径比单纯加速更有效。 AEGIS-OSDI26 把重验证放到离线，OpGuard-OSDI26 先采轻量 fingerprint，TrainMover-OSDI26 提前 warm-up 和建通信，Tessera-OSDI26 把可移动 Wgrad 填进气泡。系统速度来自重新划分“现在必须做”和“可以以后/以前做”。
  • 跨论文观察：通信已经下沉到 tile 和硬件资源层。 Syncopate-OSDI26 搜索 chunk、backend 和 SM 配额，Kareus-OSDI26 还把频率加入决策，Tessera-OSDI26 对不同 layer pair 单独测 overlap。只在图级插一个 collective，已经难以接近硬件上限。
  • 共同假设：执行足够稳定，profile 与 reference 有意义。 Hetu-v2-OSDI26、Kareus-OSDI26、Tessera-OSDI26 需要 profile 能代表后续 step；AEGIS-OSDI26 和 OpGuard-OSDI26 需要可重复或可比较的计算；TrainMover-OSDI26 需要 shadow iteration 触发正确初始化。动态 shape、非确定 kernel 和软件升级都可能破坏这些前提。
  • 主要张力：低开销检测与完整覆盖。 AEGIS-OSDI26 靠采样控制成本，OpGuard-OSDI26 只在共同边界比较，TrainMover-OSDI26 假设故障已定位。三者都缩短了正常或恢复路径，却没有单独解决未采样错误、common-mode divergence、silent corruption 定位与相关故障。
  • 主要张力：峰值性能与可移植性。 Syncopate-OSDI26 深度依赖 Hopper/Triton/NVSHMEM，Tessera-OSDI26 依赖内部 Hopper MoE 模板，Hetu-v2-OSDI26 则把适配压力交给 annotation 与 planner。越靠近具体硬件，数字越强，迁移到新 GPU、网络或模型的重新画像成本也越高。
  • 后续方向：把训练正确性纳入性能实验。 对 Hetu-v2-OSDI26、Kareus-OSDI26、Syncopate-OSDI26、Tessera-OSDI26 应同时报告 tensor differential、loss/reward 多 seed 曲线和故障注入；对 Cocoon-OSDI26 还要验证完整隐私预算与模型效用，避免只证明 kernel 或 step 更快。
  • 后续方向：统一计算总拥有成本。 TrainMover-OSDI26 的 standby、Kareus-OSDI26 的搜索、Cocoon-OSDI26 的 host/CXL 容量、Tessera-OSDI26 的 profiling 都是隐藏资源。可用“有效训练 token/GPU-hour + CPU/存储/网络/能源成本 + 故障损失”作为统一口径。

4. RL 与 AI 集群（8 篇）

这一组分成两个层面。Alibaba ASI 与 Quota Marketplace 从整个 AI 集群看碎片、预留容量和组织优先级；其余六篇集中在 LLM RL，将 rollout、training、tool、environment、reward 和 weight sync 拆开重排。RL 的特别难点是长尾会被同步 barrier 放大，组件的可扩展曲线不同，状态又不能随意丢弃。论文因而大量使用动态迁移、异构硬件、跨作业复用和有界陈旧。

逐篇解读

  • Alibaba-ASI-OSDI26：核心问题是生产 GPU 集群的碎片不只来自小数卡，还来自型号锁定、8-GPU 节点剩余卡、CPU 配比、网络拓扑与在线服务预留。机制包括用 IPC 的分区与 ejection chain 清空节点、按 ASW entropy 做拓扑集中，以及让低优先级 SpotGPU 作业回收高优先级服务的 Standby 容量。关键数字是六个月 trace 覆盖约 1,400 万 jobs、155,410 GPUs；SpotGPU 将 allocation ratio 从 68% 提到 93%，IPC 在两个月回放中让未满载节点减少 20.2%，低优先级 completion time 降低 24%。证据边界是 93% 表示已分配，不是 SM 利用率，在线推理 SM 中位数仍只有 6%；IPC 容量收益来自 replay，约 40% 任务不可迁移，生产迁移失败率、临时双份容量和 SLO 未报告。

  • DynaRL-OSDI26：核心问题是 rollout 后期不足 30% 的长尾 query 仍拖住几乎所有 inference engine，多轮 tool call 的 FIFO 又破坏 KV 局部性。机制是用动态 hypergraph 汇总 RL 组件状态，按组件可中断点在 rollout/inference/trainer 间重分 GPU，并提供 reboot、workload、P2P 三种迁移；请求侧优先推进接近完成、cache 可复用的 late turn。关键数字是 64/128 张 H100 上 math RL 吞吐相对基线提高 1.27–1.98 倍，带优先级的 agentic RL 相对 RLinf 提高 1.27–1.64 倍；调度决定少于 200 ms。证据边界是迁移本身为约 0.5–7.5 秒，不是 200 ms；最大 128 H100、同构资源、每点只平均 10 iteration，正确性只有 1.5B math 的单条 reward 曲线，未测 exactly-once tool side effect 和迁移失败。

  • Quota-Marketplace-OSDI26：核心问题是按季度分配静态 accelerator quota 无法表达团队当下 job 的价值，也很难把新硬件和冷门地点快速交给愿意适配的人。机制是公司用 market weight 决定业务单元购买力，团队持续获得 credit，并用 queue、bid 与 limit price 表达优先级；中央纯函数约每分钟清算，失败时 scheduler 使用最后一份 quota。关键数字是系统管理数十万加速器，所比较 QM pool 平均 occupancy 为 93%，传统 pool 为 75%，端到端 quota 反馈约 30 秒。证据边界是生产数据主要是汇总观察，没有 matched A/B 的 job completion、deadline miss、抢占浪费和公平性；理论依赖大而可分的市场、price taker 与未来价格可知，而真实 gang/topology/CPU/network 约束仍由下层 scheduler 处理。

  • RLinf-OSDI26：核心问题是 generation、inference、training、tool 和 simulator 的最佳资源切分随算法和 workload 变化，固定 colocated 或 disaggregated 模式都可能输。机制是 M2Flow 将宏观 workflow 展开为 temporal、spatial 或 hybrid 计划，profile 少量并行度后搜索 placement；运行偏差持续超过 15% 时 checkpoint、重画像和重规划。关键数字是在最多 256 张 H100 的 reasoning、agentic、embodied RL 中，整体相对现有系统提高 1.07–2.43 倍；GRPO temporal 对 veRL 为 1.10–1.58 倍，PPO spatial 提高 27.2%–69.6%。证据边界是部分收益来自 KV 管理、同步、环境初始化和 fused forward，而非 M2Flow 本身；Qwen3 MoE 的 spatial 模式到 128 GPU 反而落后，4,096 GPU 只有搜索器模拟，运行时 replan 与故障恢复没有定量结果。

  • RobustRL-OSDI26：核心问题是 trainer、rollout 和 tool 的正常空闲模式不同，统一故障检测容易误报；整任务重启又会丢掉昂贵的长 rollout。机制是按角色检测和局部重启，每步把 trainer checkpoint 到 host/HDFS 保持权重一致，用 UCX 动态重连，并在 async/semi-sync 时借 rollout 机器临时补 trainer gang。关键数字是 256-GPU 高频 trainer 故障压力测试中 ETTR 从 ByteRobust 的约 60% 提到 80% 以上；128 GPU 每 10 step 注错时，局部恢复占总时间少于 5%，对照约 20%，单次 trainer 恢复从 277.8/305.5 秒降到 173.0/182.6 秒。证据边界是故障频率远高于普通生产，故障类型说明有限；role-aware detector 没有 precision/recall，控制面、silent corruption、fail-slow、跨 DC 和纯同步部署都未充分验证。

  • RollArt-OSDI26：核心问题是 agentic RL 的 prefill、decode、environment、reward、training 适合不同资源，batch barrier 又把环境长尾扩散到整批。机制是按 task domain 把阶段映射到 H800/H20/CPU/FaaS，trajectory 级异步推进，用 serverless reward 回收低利用专卡，再以 bounded staleness 和异步 weight transfer 控制训练。关键数字是 Qwen3-32B 达 validation score 0.85 的时间相对 Sync+、One-off、AReaL 缩短 2.05、1.35、1.31 倍；一个 3,000 多 GPU、数千亿参数 MoE 运行一周。证据边界是映射和 P/D 比例仍由人声明，serverless 成本、隐私与失败未计；放宽 staleness 虽最多再少 1.22 倍 step time，但 α=2 后期 time-to-score 已落后 α=1，生产单例仍有最高 62% get_batch 等待。

  • Seer-OSDI26：核心问题是严格同步 GRPO 中，同一 prompt 的 8–16 个 response 有相关的长度和 token pattern，但普通 FIFO 不利用这种组内信息，最后 10% 长请求成为 barrier。机制是把 rollout 拆成可迁移 chunk，用组内已完成 response 估计其余长度，优先推进长组；全局 KV pool 支持迁移，组级 suffix context tree 再做自适应 speculative decoding。关键数字是在 32–256 张 H800、32 GB–1 TB 三种 reasoning model 上，rollout throughput 相对优化 veRL 提高 44%–104%，tail 处理时间降低 72%–94%。证据边界是系统依赖每节点 2 TB DRAM、4 TB NVMe 和 8×400 Gbps RDMA；一轮可迁移约 3 TB KV，性能只平均 5 iterations，质量只用 Moonlight 100 iteration 单曲线，未报长度预测误差、跨 rack 拥塞和节点故障。

  • Weave-OSDI26：核心问题是同步 on-policy RL 的 rollout 池和 training 池交替空闲，单个作业内部无法利用另一阶段的专用 GPU。机制是把阶段互补的不同作业组成固定协同组，用 host DRAM 保留热状态，在约 80% response 完成后迁移长尾，并用分层 weight sync 降低跨 H800/H20 集群传输。关键数字是两周、200 个生产作业 trace 回放中，以 510 美元/小时完成负载，成本相对 Solo-D 改善 1.84 倍、相对 veRL 改善 1.38 倍，并在该名义回放中满足全部 SLO；微基准吞吐相对 Solo-D 提高 1.82–1.99 倍。证据边界是 SLO 由实验者从 (1, 2) 均匀采样，不是原生产合同；trace 只来自一个 tenant，固定组依赖 host DRAM 和稳定阶段画像，漂移后的 fallback 是停掉重交，不是无缝重组。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
Alibaba-ASI-OSDI26AI 集群碎片型号、节点、CPU、拓扑与预留叠加IPC、ASW 放置、SpotGPU六个月 15.5 万 GPU traceallocation 68% 提至 93%allocation 非 SM 利用；IPC 收益为 replay
DynaRL-OSDI26RL 动态资源rollout 长尾和多轮 cache 失衡hypergraph、三种迁移、late-turn 优先64/128×H100math 吞吐提高 1.27–1.98 倍同构小规模；迁移秒级；正确性证据弱
Quota-Marketplace-OSDI26组织级配额静态 quota 不反映即时价值weight、credit、bid、分钟级清算数十万 accelerator 生产部署QM pool occupancy 93% 对 75%汇总观察；理论忽略 gang/topology 和策略行为
RLinf-OSDI26RL workflow 编排固定共置/拆分不能通吃M2Flow temporal/spatial/hybrid 搜索最大 256×H100，四类 workload整体提高 1.07–2.43 倍收益混合实现优化；重规划与故障未测
RobustRL-OSDI26RL 容错整任务重启丢长 rollout角色检测、局部恢复、每步 checkpoint、UCX64–256 GPU 注错高频故障下 ETTR 超过 80%非真实故障 trace；detector 无准确率；控制面未测
RollArt-OSDI26Agentic RL 解耦阶段硬件偏好和环境长尾异构映射、trajectory async、FaaS reward、stalenessQwen3 8B–32B；3,000 多 GPU案例32B time-to-score 最多快 2.05 倍人工映射；staleness 有质量税；成本/故障不全
Seer-OSDI26严格同步 GRPO rollout同组长尾形成 barrierchunk 迁移、组长估计、共享 suffix context32–256×H800，最大 1 TB 模型throughput 高 44%–104%极强 RDMA/DRAM；5 iterations；单一质量曲线
Weave-OSDI26跨作业 RL 复用rollout/training 两池交替空闲固定协同组、热启动、长尾迁移、分层同步两周 200-job trace replay成本改善 1.84/1.38 倍SLO 人工采样；单 tenant；固定组难应对漂移

跨论文综合

  • 跨论文观察：RL 系统的基本调度单位正从 job 变成阶段、trajectory 和 chunk。 RLinf-OSDI26 选择 component placement，DynaRL-OSDI26 在 iteration 内迁移资源，RollArt-OSDI26 按 trajectory 异步推进，Seer-OSDI26 再把 trajectory 切成可迁移 chunk。粒度越细，越能吸收长尾，但状态一致性和控制面也越复杂。
  • 跨论文观察：集群级效率需要跨作业协调。 Alibaba-ASI-OSDI26 用低优先级 job 收割预留，Quota-Marketplace-OSDI26 用内部价格移动需求，Weave-OSDI26 直接把两个 RL 作业的互补阶段配对。单作业优化无法处理组织优先级、预留容量与全局碎片。
  • 共同假设：工作负载愿意合作。 Alibaba-ASI-OSDI26 要求低优先级任务可 checkpoint 和被驱逐，Quota-Marketplace-OSDI26 假设团队近似 price taker，DynaRL-OSDI26 与 RLinf-OSDI26 要求组件实现 interrupt/onload/offload，Weave-OSDI26 要求 SLO 能写成相对 slowdown。用户或组件不配合时，控制器没有同样强的保证。
  • 主要张力：吞吐、样本新鲜度与训练质量。 RollArt-OSDI26 明确看到更宽 staleness 不一定更快达到目标分数；Seer-OSDI26 保持严格同步，却需要很强的 KV 基础设施；DynaRL-OSDI26 和 RLinf-OSDI26 的质量证据只覆盖少数曲线。RL 系统不能只用 tokens/s 代表最终训练价值。
  • 主要张力：热备用与资源机会成本。 RobustRL-OSDI26 借 rollout 卡恢复 trainer，Weave-OSDI26 用 host DRAM 保持多作业热状态，RollArt-OSDI26 借异构池与 FaaS，Alibaba-ASI-OSDI26 则显式收割 standby。更快切换的代价经常被转移到内存、备用卡或可抢占任务上。
  • 后续方向：统一用 wall-clock-to-quality 和有效 GPU-hours 评测。 对 RLinf-OSDI26、DynaRL-OSDI26、RollArt-OSDI26、Seer-OSDI26、Weave-OSDI26 用相同算法、prompt group、故障和到达 trace，报告多 seed 达到目标 reward 的时间、丢弃 token、陈旧样本、迁移 bytes、峰值显存和总 GPU-hour。
  • 后续方向：把市场、调度与故障联合起来。 Quota-Marketplace-OSDI26 和 Alibaba-ASI-OSDI26 主要决定资源归谁，RobustRL-OSDI26、DynaRL-OSDI26 决定拿到资源后怎样迁移。下一步需要验证价格或抢占变化期间的 checkpoint 新鲜度、恢复时间、deadline、公平与相关故障，而不是让两层各自假设另一层稳定。

5. GPU 编译与异构加速器（8 篇）

这一组从“硬件能力已经存在，但软件没有把它变成可用性能”出发。GraCE、MPK、Twill 和 VTC 改写 GPU graph、kernel 与数据表示；MoonBright 下沉到 GPU 虚拟内存；TileLoom 面向空间数据流芯片；μShell 处理可重构 FPGA；qTPU 则统一量子与经典张量计算。多数编译类工作建立更贴近硬件的表示并搜索实现；MoonBright 与 μShell 则直接改造虚拟内存和 FPGA 运行时底座。

逐篇解读

  • GraCE-OSDI26：核心问题是 CUDA Graph 的收益常被三个细节抵消：一个 CPU tensor 让大图无法 capture，动态参数在每次 replay 前复制，或某个小 graph 本身就不值得 capture。机制是在 PyTorch 编译链中把安全的 host tensor 移到 device，用参数间接寻址消除 replay copy，再逐 graph profile 决定是否启用。关键数字是在 25 个固定 H100 workload 上相对 PyTorch2-CG 几何平均快 29%、最高 3.36 倍，并避免该集合中 4 个至少 3% 的退化；多 GPU TP 场景平均快 75%。证据边界是 workload 预先筛选为 CG-sensitive、shape 固定；75% 只覆盖 4 个 TP workload、最多 4 张 H100/NVLink；编译时间平均变成 2.21 倍、最长 506 秒，device placement 改写缺少系统化语义等价测试，也没有动态 shape、线上漂移和专用 serving runtime 对照。

  • MoonBright-OSDI26：核心问题是 GPU 大块内存分配的时间主要花在 host 串行构造页表和 TLB shootdown，而非拿到物理页；prefix cache 与 beam search 的频繁 remap 会把这个成本放大。机制是让 GPU kernel 并行填 device page table，并为新映射始终分配从未用过的虚拟地址，把 shootdown 延后到 free、同址 remap 或地址 epoch 回收。关键数字是 A100 上 2 GB fresh mapping 从 36 ms 降到 14 µs；单 A100 prefix-cache 实验中 Llama-2-7B TTFT 最多降低 8.2 倍，Llama-3-8B 最多 2.9 倍。证据边界是 2,500 倍级结果只针对已获得 PFN、2 MB page 和 fresh VA 的低层 primitive；设计需要 trusted runtime、私有页表布局和大量 VA，普通无 prefix-cache 长上下文最多只快约 5%，多租户安全与长时间地址 churn 未验证。

  • MPK-OSDI26：核心问题是每个 operator 一个 GPU kernel 会引入 launch/barrier，并阻止 producer tile 就绪后立即触发通信或下游计算。机制是把 tensor graph 展成 SM 级 tGraph，由一个 persistent mega-kernel 内的 scheduler 在 worker SM 上执行任务，用 event fusion、linearization 和 JIT/AOT 混合调度控制图规模与动态 MoE。关键数字是在五个模型、A100/H100/B200、固定 64-token prompt 与 1,024-token decode 的离线 batch 中，相对最佳 vLLM/SGLang 为 1.0–1.7 倍；8 张 H100 上为 1.1–1.4 倍。证据边界是全部主结果为 batch 1–16 的 offline greedy decode，没有真实 arrival、TTFT/TPOT P99、取消和 prefix cache；编译成本未报告，persistent kernel 的抢占、多租户、profiling 和故障隔离也未验证。

  • MuShell-OSDI26：核心问题是 FPGA accelerator 以整应用 bitstream 部署时，即使多个应用共享相同模块也要重复 partial reconfiguration，模块间经 CPU 转发还会损失流式性能。机制是把 accelerator 拆成可跨 vFPGA 连接的模块，用 capability execution unit 检查 endpoint 与 DMA 权限，直接流式 IPC 传数据，scheduler 优先复用已经驻留的模块。关键数字是 U280 原型相对 Coyote v2 平均吞吐损失 3.3%，而调度实验总完成时间降低 24%–35%；capability 更新只需 2–3 µs，单次 PR 约 58 ms。证据边界是共享只支持无状态模块；调度实验并未真实反复 PR，而是注入预先测得的延迟，只测单 U280、最多 8 个 vFPGA，安全性也没有攻击或撤销竞态实验。

  • qTPU-OSDI26：核心问题是量子 circuit、classical tensor contraction、circuit cutting 和 error mitigation 分属不同工具，跨边界看不到“更少量子误差需要多少经典计算”的整体权衡。机制是用 hybrid Tensor Network 统一 qTensor/cTensor，以 symbolic iswitch 压缩一族 circuit，compiler 搜索 quantum-error 与 classical-FLOPs Pareto 点，runtime 再按 index slicing 分给 QPU/GPU。关键数字是 VQE-SU2 140-qubit 编译为 2.51 秒，对 QAC 的 134.1 秒，快 53.4 倍；IBM Marrakesh 上 80-qubit QNN fidelity 从 monolithic 的约 0.003 提到 0.12。证据边界是 error model 默认独立 gate error，FLOPs 不含 memory、queue、network 和总 shots；16 logical QPU 的 14.4 倍扩展及巨大 end-to-end 数字主要用估算 QPU 时间，不是真实多 QPU 集群，较高 fidelity 也未固定总量子工作预算。

  • TileLoom-OSDI26：核心问题是空间数据流加速器没有 GPU 的动态 block scheduler 与隐式 cache，tile 的物理位置、执行时间和显式 NoC 复用都要由软件决定。机制是用统一 df 硬件描述、仿射访存分析和静态性能模型枚举空间/时间复用，把 Triton/Helion kernel 映射到 Tenstorrent；可选 top-k 实机 profile 修正模型误差。关键数字是 Wormhole/Blackhole 上 FlashAttention 分别达到 TTNN 的 1.94/1.98 倍，GEMM 为 0.95/1.10 倍；空间复用让五个 Wormhole GEMM 快 1.42–2.12 倍并平均减少 70% DRAM access。证据边界是端到端真机只覆盖同一厂商两代芯片和少量 dense affine kernel；Mamba 的 10–55 倍使用 unfused TTNN baseline，混入 fusion 收益，模型误差为 17%，dynamic/sparse 和完整模型未测。

  • Twill-OSDI26：核心问题是传统 modulo scheduling 找到最小 initiation interval 后，有限寄存器、blocking sync、合作式指令与跨 warp 通信可能让该流水根本无法生成。机制是把软件流水与 warp specialization 一起交给整数规划和 SMT，在固定 tile IR 与抽象机器模型内寻找可行且最优的 schedule。关键数字是长度 16,384 的 forward attention 上，Hopper 的 Twill-SWP 距 FA3 1% 以内，Blackwell 联合版本距 FA4 2% 以内；五个搜索实例耗时 18–242 秒。证据边界是只测 FP16 non-causal attention，输出由作者手工翻成 CUDA，不是完整自动 compiler；最优性只在给定 tile/成本模型内成立，Blackwell backward 还因 ptxas 未预测的 spill 需要人工收紧寄存器预算。

  • VTC-OSDI26：核心问题是 Transpose、Split、ScatterND 等只搬数据的算子会把中间 tensor 完整写回再读出，即使值没有改变。机制是用“物理 tensor 指针 + index mapping”表示不 materialize 的 virtual tensor，组合搬运映射，并通过 profile-guided VTOG 贪心选择省下搬运多于 consumer 访问回归的路径。关键数字是在五类模型组件、A100/H100、batch 1/16 的 20 个 case 中，相对每项最快 compiler 最多快 1.93 倍、论文报告平均 1.28 倍；A100 峰值显存最多省 60%。证据边界是强 vLLM 对照中 A100 完整 decoder layer 只快 1.011 倍，H100 默认不优化，强制虚拟化反而慢 8%；没有完整训练、动态 shape、多 GPU、自定义算子兼容和 greedy 全局最优性。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
GraCE-OSDI26CUDA Graph 编译capture 阻塞、replay copy、负优化代码变换、参数间接寻址、逐图 profile25 个固定 H100 workload对 PyTorch2-CG 平均快 29%CG-sensitive 集合；编译 2.21 倍；动态性未测
MoonBright-OSDI26GPU 虚拟内存页表构造与 TLB flush 很慢device PTE、Always-Fresh VAA100/H100/MI210 primitive；单卡 LLM2 GB mapping 36 ms 降至 14 µsprimitive 口径；trusted runtime；多租户和 churn 未测
MPK-OSDI26Persistent mega-kerneloperator barrier 阻断细粒度流水tGraph、in-kernel scheduler、图压缩A100/H100/B200 offline inference对最佳 vLLM/SGLang 为 1.0–1.7 倍固定长离线 batch；无 P99、编译与共存结果
MuShell-OSDI26FPGA 模块化整体 PR 重复、CPU IPC 慢capability、流式 IPC、驻留模块复用单 U280、最多 8 vFPGA调度 makespan 降 24%–35%PR 为延迟注入；只共享无状态模块
qTPU-OSDI26量子—经典编译跨工具无法联合切分与权衡hTN、symbolic qTensor、Pareto 切分MQT、IBM Marrakesh、估算多 QPU140q 编译快 53.4 倍；80q fidelity 约 0.12多 QPU 时间多为估算；error/FLOPs 模型不完整
TileLoom-OSDI26空间数据流映射软件必须显式安排核、NoC 与复用df 描述、仿射分析、cost modelTenstorrent Wormhole/BlackholeFA 达 TTNN 1.94/1.98 倍同厂商两代；dense affine；Mamba 对照不等价
Twill-OSDI26GPU schedule synthesisSWP 与 warp 约束分开会不可实现ILP+SMT 联合求解H100/B200 attention forward/backwardforward 距 FA3/FA4 1%/2% 内单算法族；手工 CUDA lowering；模型内最优
VTC-OSDI26虚拟 tensor纯搬运中间结果浪费带宽指针+映射、VTOG profile 搜索5 组件、A100/H100、batch 1/16最多 1.93 倍，平均 1.28 倍vLLM 层仅 1.011 倍；H100 强制版退化 8%

跨论文综合

  • 跨论文观察：新的优化边界正在穿过传统层次。 GraCE-OSDI26 同时改 Python/PyTorch、Triton 和 CUDA Graph，MoonBright-OSDI26 从应用一直下到页表，MPK-OSDI26 把整图放进一个 kernel，VTC-OSDI26 让 tensor 物化决定跨 operator 传播。单层 pass 很难看到完整收益。
  • 跨论文观察：数据移动比算术越来越重要。 MoonBright-OSDI26 优化映射而非模型计算，VTC-OSDI26 消除纯搬运，TileLoom-OSDI26 搜索跨核复用，qTPU-OSDI26 则用切分交换量子错误与经典 contraction。新硬件的峰值算力只有配合数据路径才能兑现。
  • 共同假设：专用化成本能够摊销。 GraCE-OSDI26、MPK-OSDI26、TileLoom-OSDI26 和 Twill-OSDI26 都为特定 shape、GPU 或 kernel 做编译/求解，VTC-OSDI26 还要实机 profile。短作业、shape churn、驱动升级和多租户干扰会缩短优化结果的有效期。
  • 主要张力：更低层控制带来更大可信边界。 MoonBright-OSDI26 让 device 写 PTE，MuShell-OSDI26 动态改 capability 与互连，MPK-OSDI26 长驻一个 mega-kernel，Twill-OSDI26 依赖人工机器模型。性能更高，但隔离、回滚、可观察性和错误 blast radius 都更难。
  • 主要张力：自动结果接近专家，不等于流程已自动。 Twill-OSDI26 的 schedule 仍手译 CUDA，TileLoom-OSDI26 复用厂商 backend，qTPU-OSDI26 依赖简化 error/cost model，MuShell-OSDI26 的模块还需专家写 RTL/HLS。论文自动化的是关键搜索环节，不是整个部署生命周期。
  • 后续方向：建立跨版本、跨硬件的编译耐久性评测。 对 GraCE-OSDI26、MPK-OSDI26、TileLoom-OSDI26、Twill-OSDI26、VTC-OSDI26 记录冷编译、cache hit、recompile、失败 fallback、数值差异和升级后性能 regret；至少覆盖一代新 GPU 和一个非 NVIDIA/非 Tenstorrent 后端。
  • 后续方向：把安全和共存放进性能主结果。 MoonBright-OSDI26 应测试恶意 PTE 更新与地址回收，MuShell-OSDI26 应注入 stale capability、DMA 越界和模块 hang，MPK-OSDI26 应与高优先级 kernel/第二模型共跑。只在独占硬件上报吞吐，无法证明这些机制适合共享生产环境。

6. AI 数据管线、诊断与自动优化（8 篇）

这一组关注 GPU 计算之外的“生产系统知识”：训练框架知道未来会读什么，性能问题藏在应用自定义资源里，故障模式存在于长时间序列和跨层 trace 中，优化机会散落在数十亿行代码里。多篇论文使用 LLM 或生成模型，但最重要的设计不是让模型直接做决定，而是先把问题压成结构化证据，再用静态检查、动态验证、回放或人审限制错误。

逐篇解读

  • Chen-LLMDataPipelines-OSDI26：核心问题是传统 HDFS 面对 LLM 训练出现三种新瓶颈：异地 evaluation 的小 tensor 反复支付 WAN RTT，数千 rank 同步恢复把少数 checkpoint 文件读成热点，多模态数据加载主要卡在 host CPU 解码。机制是利用训练框架已知的未来信息：提前复制 checkpoint 到 evaluation DC、恢复前提高 hot-file 副本、按确定样本顺序把 decode/crop/normalize 下推到闲置 storage CPU。关键数字是 30 天 19 个任务、3,589 次 evaluation 中 merge latency 平均降低 76.1%；2,048 GPU 实验的总 checkpoint load 从 38.48 秒降到 22.78 秒；生产 MM-L 的转换 stall 降低 63.2%。证据边界是三组数字来自不同 workload，不能合并成一个端到端结果；单一公司的 HDFS/WAN，预测错误、额外副本/流量、storage CPU 与 transformation correctness 成本都未完整报告。

  • Drs-NAS-OSDI26：核心问题是推荐系统 NAS 通常要训练超网或大量候选，搜索需数小时 GPU，而且找到的模型可能仍很大。机制是从一个 2,048 样本批次计算参数、FLOPs、权重/梯度范数、zico、synflow、meco 七维 zero-cost proxy，用 Gumbel-Softmax 只更新架构权重，联合选择算子、连边和成本。关键数字是 10,000 次搜索在 Threadripper 5975WX 上用 1.56 CPU-minutes；三个数据集上搜索模型保持最佳或第二梯队效果，相对 NAS 基线平均缩小 34.9 倍参数、减少 14.7 倍 FLOPs。证据边界是 5.04–18 GPU-hours 的基线来自不同论文和硬件，不能当同机 193–692 倍加速；Criteo 不及 NASRec，参数/FLOPs不含 embedding table，也没有七个 proxy 的组件消融或大量候选排名相关性。

  • ECO-OSDI26：核心问题不是 LLM 偶尔能否写出快代码，而是怎样从数十亿行代码找到高价值位置，并在生产前过滤语义错误、无效补丁和性能回归。机制是把全机群 profile 归因到函数，用历史性能提交和 code embedding 检索反模式，让 Gemini 生成小补丁，再经 build/test、LLM checklist、人审、渐进部署和回滚筛选。关键数字是一年落地超过 6,400 个提交、修改超过 25,000 行，持续节省数十万 normalized cores，生产回滚率少于 0.5%；检索 MAP@5 为 0.2036。证据边界是少于 0.5% 是整套流水线的上线回滚率，不是模型原始准确率；代码、profile 和收益分布均为 Google 私有，检索测试只有 63 个正例，未给完整 reviewer/CI/维护成本和端到端组件消融。

  • gigiprofiler-OSDI26：核心问题是 buffer pool、UNDO、query cache 等应用内部资源对 OS profiler 不可见，受害请求的热点调用栈常指向结果而非真正占用者。机制是把资源生命周期统一为 WAIT、ACQUIRE、USE、RELEASE；LLM 先靠语义找候选，静态分析检查代码行为，LLVM 插桩与运行时轨迹再验证，并把等待者连接到持有资源的责任任务。关键数字是在五个大型系统的 15 个已知问题中，真实根因全部排第一；另找到两个已被 MariaDB 开发者确认和修复的问题，9 个可测案例平均吞吐开销 3.7%、最高 7.8%。证据边界是四事件抽象只覆盖经验研究 45 个问题中的 87%；严格事件真值仍平均漏约 23%，开销不是全部 15 个案例，完整 LLM 扫码/构建/复现时间与费用也未计，且依赖 C/C++ 源码、LLVM 和可复现故障。

  • MIMESYS-OSDI26：核心问题是不能公开的生产应用很难交给硬件/系统团队重放，而简单 stressor 又只匹配平均 CPU 使用率，复现不了随时间变化的 CPU、LLC、内存带宽和 I/O 干扰。机制是条件 diffusion model 将目标 trace 反推成每核 stressor 组合，novelty-guided profiling 扩展稀有区域，上一窗口表示历史状态，再用实际执行反馈做 alignment。关键数字是在同一 Haswell 平台的 benchmark 混部中，资源轨迹 DTW 距离相对基线最多改善 5.5 倍；受害应用性能下降误差平均 8.3 个百分点，下一名为 19.4 个百分点。证据边界是复现的是 aggregate resource pressure，不是业务逻辑、同步或请求尾部；Redis P99 退化倍率仍可差最多 9 倍，Haswell 生成物直接放到 Skylake 时误差高 190%，隐私也没有正式攻击评估。

  • SDCHunter-OSDI26：核心问题是 GPU SDC 常只在特定 kernel、data type 和输入值上触发，GPU-Burn、ECC、温度和通用 GEMM stress 很容易漏掉；异常发生后又要尽快恢复大训练。机制是保存原模型、checkpoint、input shard、operator 和通信顺序，做 bit-wise deterministic replay；在线先比较 pipeline 边界 hash 找可疑 DP group，离线再比较全 tensor signature 找具体 GPU。关键数字是生产识别 40 张缺陷 GPU，offline debug 从数天降到一小时内；50B/150B、128/512 GPU 上在线开销为 1.14%–3.90%，注入 tensor corruption 时 coverage 91%、平均 3 steps。证据边界是它由异常触发，不是 always-on 全覆盖 detector；91% 来自直接改 tensor 的注入，不等同真实微架构故障，依赖确定性、健康 reference、spare capacity 和可重放输入，对不产生明显告警的 SDC 与 common-mode 错误有限。

  • SMARTTalk-OSDI26：核心问题是 LLM 直接读取 30 天密集 SMART 数值容易忽略局部趋势，也会产生数值幻觉；静态规则又难覆盖新的故障形状。机制是 CNN 将时间序列切成 patch embedding，聚类成 pattern，再转成“缓慢上升”“末尾尖峰”等短语；LLM 判断风险和 time-to-failure，PatternMemory 准备在线吸收远离旧中心的新 pattern。关键数字是在 Alibaba MB1/MB2 固定采样测试集上，最佳 F0.5 为 0.78/0.66，比各自强数值基线高 0.03；正确检出为风险的窗口中，TTF macro-F1 最高 0.70。证据边界是 MB2 最佳 recall 只有 0.34、FNR 为 0.66；TTF 不计漏检窗口，在线 PatternMemory 没有单独消融，解释和建议只由 GPT-5.1 Thinking 与合成扰动评分，没有真实运维人员研究或跨厂商结果。

  • StriaTrace-OSDI26：核心问题是 LLM serving 的偶发慢 token 难复现，但 full profiler 常驻会严重扰动服务并产生海量 trace。机制是只埋同步边界与语义关键路径，只记录 GPU kernel/memory copy；按每 step token 数拟合 P99 roofline，仅把异常 step 的完整 trace 上传，再关联 Python sampling、CPU span 和 GPU kernel。关键数字是高并发时完整 tracing 的 median TPOT/TTFT overhead 为 0.6%/0.8%；系统连续 6 个月覆盖 1,700 多实例、每天 1.8 亿请求，辅助定位 19 类根因，正常过滤后上传量约为 raw stream 的 1.6%。证据边界是 concurrency 8 时完整开销仍为 5.2%/2.7%，不是所有点都低于 1%；两类强 fault injection 只报 100% recall、未报样本数与 precision，生产 flag 约 7% 是自然波动，持续退化还可能被 roofline 吸收为新常态。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
Chen-LLMDataPipelines-OSDI26训练数据管线WAN 小读、恢复热点、CPU 转换长尾预测复制、hot-file hint、storage-side transform30 天生产 trace；2,048 GPU；MM-Lmerge/load/stall 分别降 76.1%/40.8%/63.2%三个独立证据集；成本、误预测和正确性不全
Drs-NAS-OSDI26推荐模型 NAS超网和候选训练太慢、模型太大七维 zero-cost proxy、可微架构搜索Criteo/Avazu/KDD；CPU 搜索、A6000 验证搜索 1.56 CPU-minutes跨硬件基线；proxy 无组件消融；embedding 不计成本
ECO-OSDI26LLM 代码优化找高价值位置并过滤错误补丁fleet profile、反模式检索、生成、多层验证Google 一年生产部署6,400 多提交，回滚少于 0.5%私有数据；可靠性来自完整流水线；无完整净成本
gigiprofiler-OSDI26应用资源诊断OS profiler 看不见应用资源因果链四事件抽象、LLM+静态+动态验证五系统 15 个已知问题15/15 根因 top-1；两个新 bug 修复抽象覆盖 87%；事件仍漏；依赖源码与复现
MIMESYS-OSDI26私有 workload 合成stressor 难重现时变干扰diffusion 逆映射、novelty profile、execution alignmentHaswell benchmark 混部退化误差 8.3 对 19.4 个百分点aggregate 非 tail/语义；跨代误差高 190%
SDCHunter-OSDI26SDC 诊断workload-specific SDC 难复现定位确定性 replay、分层 hash/signature40 张生产缺陷卡；128/512 GPU在线开销低于 4%，诊断一小时内事件触发而非 always-on；注入不代表全部实错
SMARTTalk-OSDI26SSD 故障解释长数值序列不适合直接给 LLMCNN patch、pattern phrase、PatternMemoryAlibaba MB1/MB2F0.5 为 0.78/0.66MB2 recall 0.34；在线 memory 与真人解释未验证
StriaTrace-OSDI26LLM serving 诊断full profiler 开销与数据量过高关键 span、GPU event、P99 roofline、异常保留6 个月、1,700 多实例高并发 TPOT/TTFT 开销 0.6%/0.8%低并发高于 1%；detector precision/慢漂移未知

跨论文综合

7. 解聚内存与 CXL（8 篇）

这一组论文讨论的不是简单地“把更多内存接到机器上”，而是远端内存和 CXL 改变了访问延迟、带宽隔离、元数据位置和一致性成本之后，系统应如何重新分工。Blowfish-OSDI26、RamRyder-OSDI26 从虚拟机和物理通道层面拆开容量与性能；Duhu-OSDI26、FORGE-OSDI26、Soul-OSDI26 分别重做对象传递、缓存淘汰和锁协议；LiteSwitch-OSDI26、MAC-OSDI26 把慢访问暴露给处理器或近内存硬件；DGC-OSDI26 则把垃圾回收的并发标记阶段变成共享远端服务。共同结论是：远端内存只有在系统同时减少软件路径、跨节点往返和不必要的数据移动时才有价值，单纯扩大容量经常会把瓶颈转移到 CPU、NIC 或控制面。

逐篇解读

Blowfish-OSDI26

Blowfish 解决虚拟机使用解聚内存时的两个叠加问题：传统 swap 路径要反复修改 guest page table、EPT 和 IOMMU page table，软件开销很高；2 MB 透明大页又会把其中少数热 4 KB 页与大量冷页绑在一起。它让 guest 内的 Fair MGLRU 先找出冷 GPA，并在必要时临时跟踪大页中的 4 KB 子页；host 只改 EPT，把冷页经 RDMA 换到远端，不改 guest page table 和 IOPT，再由 PSI 控制器调节回收强度。在 100 Gbps InfiniBand、7 个工作负载上，相同不超过 5% 的性能损失下，Blowfish 比 HyperAlloc 路径多回收 1.6–6.1 倍内存；4 KB 页的回收和恢复分别约 14.5 与 9.8 微秒，比基线低 53% 和 60%。这些结果来自需要 guest 与 host 都修改内核、guest 主动合作的原型；多租户只做了两个 VM 的有限测试，也没有覆盖远端内存失效、安全隔离和更慢网络。

DGC-OSDI26

DGC 观察到，低暂停并发 GC 仍会在 CPU 受限容器里与应用线程争抢核心，因而放大服务尾延迟。它把并发标记工作交给共享的解聚 marker pool：应用用 SATB 记录一致快照，远端 worker 以 2 MB region 为单位分页和缓存对象图，编排器再用 CP-SAT 决定每次标记的开始时间与线程数；远端不可用时仍可退回本地标记。在总 CPU 资源相同的设置中，SPECjbb 的 critical-jOPS 比 Shenandoah 提高 24.0%，关键负载下 P99 降低 64.4%；RDMA 版本的 P99 也降低 60.3%。消融显示没有协调器会让 GC 集中爆发，而扩到 12 个 backend 后 200 Gbps NIC 已成为瓶颈。证据主要覆盖中等 GC 压力：低 GC 压力时收益很小，极高应用负载时因为本地核心更少反而可能变差；共享信任、worker 崩溃和网络分区也未验证。

Duhu-OSDI26

Duhu 针对 Ray、Spark 一类数据分析框架按值传递大型不可变中间对象所造成的复制。它把对象只保存一份到共享解聚内存，消费者收到引用而非副本；发布时用 non-temporal write，第一次远端读取前做失效，并让每个 segment 只有一个元数据 owner，以 bitmap 维护引用计数。Duhu-Channel 负责引用传递，FlexShuffle 还能直接传对象切片。在 4 台服务器和延迟约 600–800 ns、带宽约 10 GB/s 的 FPGA CXL pool 上，四阶段 FlexShuffle 的作业时间最多缩短 3.39 倍，后续 reduce 阶段单独可快 3.59–13.81 倍；但 64 GB 场景因第一次复制反而慢 1%，TPC-H 平均只快 1.08 倍，小查询约慢 1.2 倍；相反，在 fan-out 微基准中，Duhu-Ray 的 blocking time 比 Ray 低 2.80–4.29 倍。它更适合写一次、读多次的大对象，尤其是 fan-out 或只读对象切片的场景，并依赖固定虚拟地址、可信 owner 和编排器；真实大规模 CXL fabric、故障 fencing 与可变对象都没有覆盖。

FORGE-OSDI26

FORGE 发现，解聚对象缓存经 RDMA 访问时，逐对象频率更新、链表维护和淘汰扫描产生的远端元数据流量可能比 Get 和 Set 本身更贵。它把对象放入固定 object group：先按到达时间成组，接近淘汰时再按热度合并；淘汰队列是 lock-free ring FIFO，频率只在对象进入淘汰窗口时批量刷新，virtual segment 则让热组留在队列中。RNIC device memory 只缓存计数器和游标，不承载完整元数据。在 3 个 compute node、3 个 memory node 的环境中，主实验使用一个 100 Gbps memory node；固定大小真实 trace 的吞吐最多是 Ditto 或 GLCache-DM 的 4.5 倍，P99 最多低 7.5 倍，平均命中率提高 1.14 倍；YCSB 吞吐提高 2.0–8.7 倍，P99 改善 3.9–13.3 倍。边界是：部分强基线由作者重实现并增强，group 内部碎片没有量化；协议假设频率刷新及时，也未测试崩溃、丢失 RDMA write、版本回绕和多 memory node 热点。

LiteSwitch-OSDI26

LiteSwitch 处理的是处理器等待 CXL load 时，长延迟 miss 占住 ROB 和提交端，而普通中断与线程切换又太重的问题。它提出新的 LDMB 硬件信号，只在某个 load 确实阻塞退休且目标位于 CXL 时触发；运行时随后在同一进程内跳到 handler，Bundled Handoff 把核心交给另一个可运行线程，并依据静态函数 bitmap 只保存真正使用的扩展寄存器。在 200 ns CXL 延迟的模拟中，bfs/urand 相对本地 DRAM 的降速从 20.7% 降到 4.1%，cc/urand 从 29.4% 降到 9.6%，FASTER 从 9.9% 降到 2.5%，Silo 从 9.0% 降到 3.1%；固定热路径约 18 ns，但许多负载需要 6–12 倍线程超额订阅才能隐藏延迟。最重要的边界是 LDMB 只存在于模拟器，没有 RTL、周期精确实现或真实 CPU；模拟还乐观简化了 CXL miss、MLP 与尾延迟，JIT、剥离符号和缺少备用线程的程序也难以采用。

MAC-OSDI26

MAC 指出，数 TiB CXL 内存会让 Linux 的 page descriptor 和 XArray 元数据本身占用大量本地 DRAM，而且 kswapd 在远端逐页遍历和删除映射时可能跟不上空闲页消耗。它把页元数据移到 CXL，并让近内存固定功能加速器过滤 page descriptor、批量遍历和删除 XArray；每批处理 32 页，host 同时执行 unmap 与 writeback，协议依赖预期中的 CXL 3.x BIsnp 一致性。在 Linux 6.14、双 NUMA 模拟的 2–2.5 TiB 数据库上，RocksDB P99.99 比优化 Linux 降低 97%–98%，PostgreSQL P99.99 降低 92%，前台回收查询降低 88%；FPGA 微基准中 XArray 热路径快 82%，descriptor 遍历快 48%，端到端 kswapd 回收快 30%。不过完整数据库结果来自 NUMA 加模型的模拟，FPGA 并非原生 CXL 3 数据库系统；实验偏向文件后备、高内存压力，也没有处理加速器超时、锁长期持有、内核升级、故障和多租户隔离。

RamRyder-OSDI26

RamRyder 认为传统 BIOS 把数据交错到全部 DIMM channel，导致虚拟机的容量分配和带宽分配绑死：两个容量足够的 VM 仍可能因共享 channel 互相干扰。它关闭硬件交错，把每条 DIMM 或 CXL channel 暴露为 DAX/C-NUMA，再组合成应用可见的 S-NUMA；系统按页在选定 channel 间软件交错，可以独立增加容量或 channel，并用 hotplug 和惰性迁移调整映射，同时把 VM 固定到独立 CCX/LLC。在一台 AMD Zen 5、8 条 DIMM channel 加 4 个单通道 CXL 2.0 设备上，多数应用距独占 Ideal 不超过 5%；共享 VM 最坏延迟增加 78.5%、带宽下降 41.2%，RamRyder 则把延迟控制在 5% 内。在线加 channel 后带宽在 2.2 秒内从 38 增至 68 GB/s；基于集群 trace 的配对分析声称容量和带宽利用率平均提高 28.6% 与 43.2%。后两项是 trace 外推而非真实集群部署，系统也只测一台机器和单通道设备；1 秒监控、粗粒度 channel 分配、CPU pinning 的贡献以及 DMA、迁移和故障语义仍不清楚。

Soul-OSDI26

Soul 研究页一致解聚共享内存上的锁：锁协议和内存一致性协议分层后，一个临界区会重复触发 5–10 微秒 Ethernet 往返。它提出广义一致性协议 GCP，在“时间”上通过等待队列让权限跨临界区保留，在“空间”上用共享内存列表把锁与任意数据区域绑定；writer 之间可连同版本和队列直接转交权限，并提供 pthread 与 Rust shim。在 8 个 compute blade 的 MIND Ethernet 原型中，只读 YCSB-C 达 3710 万 ops/s，比传统锁高 2–3 个数量级；获取锁和 4 KB 数据约 100–200 微秒，少一个数量级且只需一次一致性事务。在 gem5 的 16-host CXL 模拟中，Twitter 和 YCSB 最多提高 1.7 与 2.0 倍。证据同时显示写密集 KV 不扩展，全局独占的 Kyoto/TPC-C 没收益；真实 CXL 未实现，接口也只有基本读写锁，且假设可靠、有序、无损 RoCE，没有测试 compute 或 memory blade 失效。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
Blowfish-OSDI26VM 远端换页多级页表开销与 THP 冷热混装guest MGLRU、子页跟踪、只改 EPT 的 RDMA swap100 Gbps IB、7 个负载同等不超过 5% 损失时多回收 1.6–6.1 倍guest/host 均改内核；两 VM；无远端故障测试
DGC-OSDI26解聚垃圾回收并发标记争抢应用 CPU共享 marker pool、SATB、CP-SAT 编排SPECjbb、SHM 与 200 Gbps RDMAcritical-jOPS 提高 24.0%，关键负载 P99 降 64.4%中等 GC 压力有效；共享信任；12 backend 已受 NIC 限制
Duhu-OSDI26共享对象传递不可变中间对象被反复复制单副本引用、segment owner、切片传递FPGA CXL pool、FlexShuffle、TPC-H四阶段作业最多快 3.39 倍首次复制和小查询会亏；仅不可变对象；非真实大 fabric
FORGE-OSDI26解聚对象缓存远端淘汰元数据流量过高object group、ring FIFO、惰性频率刷新3 CN/3 MN、真实 trace、YCSB固定对象吞吐最多 4.5 倍，P99 最多低 7.5 倍强基线重实现；碎片和协议故障未量化
LiteSwitch-OSDI26CXL 延迟隐藏长 load 阻塞退休，普通切换太重LDMB、同进程 handler、Bundled Handoff200 ns CXL 模拟、图与数据库负载多数负载恢复 30%–80% 的远端内存降速无真实硬件；常需 6–12 倍备用线程；模拟乐观
MAC-OSDI26近内存页回收TiB 内存元数据与 reclaim 扫描过重CXL 元数据、固定功能过滤、批量 XArray 操作NUMA 模拟数据库、FPGA 微基准RocksDB P99.99 降 97%–98%完整系统为模拟；依赖未来 CXL 3；故障与锁等待未测
RamRyder-OSDI26通道级资源隔离内存容量和带宽 channel 被绑死C-NUMA、S-NUMA、软件交错、hotplug单台 Zen 5、8 DIMM 加 4 CXL channel干扰场景延迟回到独占基线 5% 内集群收益为 trace 外推；channel 粗粒度；CPU pinning 混杂
Soul-OSDI26远端锁与一致性锁层重复触发数据一致性往返GCP、权限保留、锁与数据空间绑定8 blade MIND、16-host CXL 模拟只读 YCSB-C 达 3710 万 ops/s写密集和全局独占无收益；真实 CXL 与故障恢复缺失

跨论文综合

  • 共同观察：远端内存的主要损失常来自控制路径，而不只是介质延迟。Blowfish 减少页表更新，FORGE 减少淘汰元数据，Soul 合并锁与一致性事务，Duhu 消除副本；四者都说明“少一次软件动作或往返”可能比换更快链路更重要。
  • 共同假设：多数设计依赖可利用的结构。Duhu 需要不可变大对象，LiteSwitch 需要足够多可运行线程，FORGE 与 DGC 需要热度或 GC 压力可预测，RamRyder 需要 channel 级干扰能被较慢控制回路捕获。结构消失时，收益会迅速缩小。
  • 核心张力：把功能推向 guest、RNIC、memory controller 或近内存加速器能缩短路径，却扩大可信计算基、协议状态和部署改动。Blowfish 与 RamRyder 修改虚拟化栈，MAC 和 LiteSwitch 需要新硬件，Soul 修改一致性控制器；FORGE 的软件路径最容易落地，但也最受 RNIC 与单 memory node 瓶颈限制。
  • 后续方向：一条可行路线是统一测量“数据字节、元数据字节、控制往返”三类成本，在真实多租户 CXL fabric 上复现实验，并加入远端节点崩溃、链路抖动和权限撤销。另一条小团队可做的路线是建立跨系统 trace replay，将 Duhu 的对象大小、FORGE 的淘汰窗口和 RamRyder 的 channel 需求放到同一动态负载中，比较静态阈值与在线控制器何时失效。

8. 内存管理与并发数据结构（8 篇）

这一组工作横跨 lock-free 索引、内存分配器、垃圾回收、碎片整理、冷热分层和硬件遥测，但共同目标都是在并发运行中移动或回收内存，同时不破坏指针、可见性和尾延迟。ARCTIC-OSDI26 与 jwmalloc-OSDI26 把并发协议做得更局部；InfiniDefrag-OSDI26、LifeLine-OSDI26、OBASE-OSDI26 重新选择移动的粒度；MDK-OSDI26 给主动回收建立正确的优化目标；NEMO-OSDI26 把观测下沉到内存控制器；Megalon-OSDI26 则为“少量一致内存加大量非一致内存”预先设计数据结构。它们说明，内存效率不是单独追求更高利用率，而是要同时约束并发进度、重定位成本、观测误差和真实 SLO。

逐篇解读

ARCTIC-OSDI26

ARCTIC 解决 Adaptive Radix Tree 在结构修改操作中要改多个位置、因而依赖锁的问题。它把 edge byte、节点类型、frozen 标志和指针压进一个 128-bit 原子字；修改节点时先冻结所有可写 slot，任何遇到中间状态的线程都能帮助完成替换。点查询是 wait-free，更新是 lock-free；range scan 也保证结束，但不是线性一致快照。回收方面，hazard key 发布逻辑操作的 key 或 prefix，而非每个物理节点指针。在 80 核 x86、1 亿次操作下，相对 ART 的几何平均吞吐从 YCSB-C 的 1.3 倍到 YCSB-A 的 7.7 倍；作为 RocksDB memtable 提高 1.05–1.40 倍，Turso 提高 1.08–1.12 倍。Zipf 0.99 时 hazard key 的未回收垃圾少 5.6–19 倍，但部分设置吞吐会低 6%–12%。边界是依赖 128-bit CAS 且只测 x86；scan 不线性一致，长字符串、极端 SMO 抖动与完整形式化并发证明也未覆盖。

InfiniDefrag-OSDI26

InfiniDefrag 的关键观察是：guest GPA 碎片并不等于物理内存碎片，因为 nested EPT 可以把散落 HPA 重新映射到连续的新 GPA。系统用地址空间末端的连续区换走等量零散 free GPA，再把原 HPA 映射过去；host-base 模式甚至用自身页表完成自重映射，host-huge 模式则结合大页和后台物理整理，并延迟 TLB flush、设置租户 quota。在极端碎片下，它生成连续内存约 20 GB/s，而 Linux compaction 约 0.91 GB/s，快约 19 倍；10 个工作负载中，host-huge 多数接近无碎片基线，Redis 相对 LLFREE、THP 或 4 KB 配置提高 21%–105%。不过所谓“无 compaction”仅指 guest 关键路径，host-huge 仍做后台整理；实验使用极端合成碎片，需要宽 57-bit GPA、足够末端地址空间和可移动冷页，metadata 约占 1.6%。DMA、pinned page、live migration、长期多 VM 与崩溃一致性尚未验证。

jwmalloc-OSDI26

jwmalloc 面向手机上的尺寸分布变化、前后台切换、激进回收和线程被抢占等组合压力。它用统一 4 KB slab 管理小对象，用闭合 sibling size-class tree 在相邻类之间借用空间；默认 R=3，最坏内部舍入为 25%。two-buffer 机制按对象寿命回收，冲突时不阻塞等待锁，而是暂时从更大 size class 分配并延迟 free。作者还用 VSync 对缩小状态空间后的并发协议做有界验证。微基准中，slab 内 allocate、本地 free、跨线程 free 分别约 16、22、29 条指令，jemalloc 为 27、38 和超过 100 条；P99.99 为 1.5 微秒，最佳对手 5.9 微秒。Mate 70 Pro 两小时真实负载中，jemalloc 让全机指令多 10%，用户态分配指令为 jwmalloc 的 3.84 倍；论文称已部署 1200 万设备、累计 300 亿用户小时。证据仍局限 HarmonyOS 与一类手机，部署没有 A/B 崩溃率；接近 2 KB 的对象可能退化，有界验证也不是整个 allocator 的证明。

LifeLine-OSDI26

LifeLine 针对 Android compacting GC：整页 remap 只有在一页几乎全是存活对象时才划算，而普通分配会把不同寿命对象混在一起。它采样 reference write，识别稳定 owner edge，用分层 Bloom filter 划分对象图；LAGC 把同一子图对象放进相邻页，ZCGC 对存活率超过 90% 的页用 UFFDIO_MOVE 重映射，其余仍复制，并在布局漂移后重新对齐。在 Pixel 7 Pro 的商业应用滚动负载中，每次 GC 复制量从 61.9 MB 降到 26.4 MB，平均 GC 时间从 198 ms 降到 153 ms；Instagram 在 GC 期间的 P90 frame latency 约降 29%，Amazon Shopping 在 GC compaction 期间的 1-ppm memory-read tail latency 最多降低 85%。跟踪 CPU 增加 3.8%，LAGC 增加 12.5%，三分钟平均 CPU 开销 2.7%。边界是单一设备、每应用约 10 次 GC 和特定交互脚本；结果主要是均值而非 pause P99，也没测能耗、长期碎片和复杂 hidden ownership。

MDK-OSDI26

MDK 重新定义主动回收问题：目标不是只最小化 miss 或满足一个瞬时工作集，而是在每个时间窗性能代理不超过 SLO 的前提下，最大化整个运行期的平均内存节省。它用 Memory Performance Curve 表示这条约束；两遍 oracle OPP 根据未来访问给各窗口分配 promotion budget，并利用决策与时间的单调性快速生成精确曲线。在线版本包括 PAW、PACE，以及从 oracle 标签学习的 L-OPP。曲线生成器相对逐点模拟误差低于 1%，快 12.5–208 倍；在离线 access-bit trace 上，Cassandra 的 OPP oracle 在 1% promotion 约束下平均可节省约 40% 内存，这不是 Linux 在线部署结果。Linux 的 GraphX 实验中，PAW 使用 9.11±0.84 GB，AGE 为 9.52±0.27 GB，运行时间约 16.9 与 17.1 分钟。严格边界是 OPP 的精确性依赖“同一 access-bit 窗内访问同时发生”的模型；用精确时间戳存在 100 对 170 的反例，promotion rate 也不等于真实异构层成本。系统验证只有 GraphX、SSD 与 4 KB 页，PACE 还在同一 trace 上调参。

Megalon-OSDI26

Megalon 面向一种尚未商品化的 CXL 形态：TB 级共享区不保持缓存一致，但只有数百 MB 的 shared coherent region 可存元数据。它不把每个对象的完整索引放入一致区，而是让每台 host 在本地 DRAM 保存冷的大索引，只为近期被多个 host 写过的对象在 SCR 动态分配小型 consistency record；LNR log 排序索引与状态迁移，counter wrapping 处理有限版本位。在 3-host NUMA 模拟、200 MB SCR 中，只读负载约 2400 万 ops/s，是 HCMeta 的 15.26 倍；5% 和 50% 写入时分别快 10.11 与 4.22 倍，YCSB A/B/C/D/F 为 3.93/9.12/14.18/4.55/3.18 倍。内存多用 7.6%，但 throughput per GB 提高 14.19 倍。主要证据来自 3 台 host 的 NUMA 模拟；目标中的部分一致 CXL 硬件尚未商品化，实验也未达到设想的 8–16 host。固定 slot、对象尺寸、durability、失效恢复和日志重放尾延迟都没有验证。

NEMO-OSDI26

NEMO 认为 PEBS、MBM 一类 OS 遥测看不到 prefetch，采样有偏且消耗 CPU，导致分层和带宽控制反应太慢。它在内存控制器旁放置不阻塞数据路径的 match–update–notify pipeline，用物理地址翻译表把访问映射到 page、subpage 或 tenant 的 SRAM counter；update 只允许简单、可交换和可结合操作，OS 可轮询或接收通知，有限 SRAM 通过时间复用覆盖更多范围。在 CXL 2.0 FPGA 原型中，HeMem 恢复 hot set 的时间从 324 秒降到 67 秒，FASTER 最多快 1.69 倍；MEMTIS 找到 95% candidate 的速度最多快 10.4 倍，Silo 提高 13%。噪声租户实验中，NEMO 仅用 0.09% CPU，把 P99 增幅控制在 5.2%；1 ms MBM 的 CPU 成本为 32%。但 FPGA 只看到 CXL 慢层，DRAM 仍依赖 PEBS；notify 未真正实现，0.09% 是理想化通知模拟。SRAM 从 16 GiB 的 1.4 MiB 外推到每 TiB 约 90 MiB，ASIC 面积、功耗、溢出和安全均未知。

OBASE-OSDI26

OBASE 解决 page-level tiering 的粒度错配：一页只要混入少数热对象，整页就不能降级，大量冷对象因此留在快层。它通过 Guide indirection 访问对象，持续估计对象 hotness，并发搬迁后把 HOT 与 COLD 对象分别聚到页中；后端仍由 kswapd、cgroup、TMO、TPP 或 Memtis 决定哪些页迁移，阈值随压力调整。在 10 个并发结构、13 GiB 数据上，页利用率在 6–8 分钟内从 18%–20% 提升到 40%–80%，RSS 降 65%–72%，平均吞吐仅降 2.5%，P90 增 5%。67 GiB MassTree 分层时，工作集从 16.3 GiB 降至 6.33 GiB；生产 trace 回放中的利用率提高 1.8–3.4 倍。边界是应用必须标注并通过 Guide 使用独占 pointer object，不能跨操作保存 raw pointer；数组、矩阵、一般图、双向链表和稳定地址都不适合。默认 120 秒控制周期看不到快速 phase，硬件也是 Optane NUMA 而非真实 CXL，且没有 P99 或线上部署因果证据。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
ARCTIC-OSDI26并发 ART结构修改跨多地址，锁限制扩展128-bit 原子 slot、freeze/help、hazard key80 核、YCSB、RocksDB、TursoYCSB-A 相对 ART 快 7.7 倍仅 x86；scan 非线性一致；依赖 128-bit CAS
InfiniDefrag-OSDI26虚拟内存碎片guest GPA 碎片触发昂贵物理 compactionEPT 重映射、地址尾部交换、延迟 TLB flush极端碎片、10 个应用、Redis连续内存生成约 20 GB/s，约快 19 倍极端合成场景；host 仍可后台整理；DMA 等未测
jwmalloc-OSDI26移动端分配器size class 与线程状态快速变化4 KB slab、sibling tree、非阻塞 fallback微基准、mstress、Mate 70 Pro 真实负载P99.99 1.5 微秒，最佳对手 5.9 微秒单平台；接近 2 KB 对象可退化；验证是有界的
LifeLine-OSDI26Android GC不同寿命对象混页，整页 remap 难生效owner-edge 学习、LAGC、ZCGCPixel 7 Pro 商业应用每次 GC 复制量降 57.4%，平均 GC 时间降 22.7%单设备、约 10 次 GC；缺 pause P99 与长期能耗
MDK-OSDI26主动内存回收现有 oracle 优化错目标MPC、两遍 OPP、PAW/PACE/L-OPPtrace 模拟、Cassandra、GraphX Linux离线 Cassandra trace 的 OPP oracle 在 1% promotion 下约省 40%精确性依赖窗口模型；Linux 只验证 GraphX
Megalon-OSDI26部分一致 CXL一致元数据区太小本地冷索引、动态 consistency record、LNR log3-host NUMA 模拟、YCSB只读吞吐为 HCMeta 的 15.26 倍目标部分一致 CXL 尚未商品化；无 durability、故障和 8–16 host
NEMO-OSDI26近内存遥测PEBS/MBM 有盲区且 CPU 成本高match–update–notify、SRAM counterCXL 2.0 FPGA、HeMem、MEMTIS、SiloHeMem hot-set 恢复 324 秒降到 67 秒notify 未实现；只观测 CXL 层；ASIC 成本为外推
OBASE-OSDI26对象级内存分层热冷对象混页阻止降级Guide、hotness、并发对象重排10 个结构、MassTree、生产 trace 回放RSS 降 65%–72%，平均吞吐降 2.5%需标注和指针约束；Optane 代 CXL；控制周期慢

跨论文综合

  • 共同观察：页是硬件与 OS 的自然单位，却未必是应用状态的正确单位。InfiniDefrag 用页表把“地址连续”与“物理连续”分开，LifeLine 和 OBASE 用对象寿命或热度重组页，MDK 则提醒回收策略还必须按时间窗衡量 SLO。
  • 共同假设：系统都需要某种稳定信号。LifeLine 假设 owner edge 相对稳定，OBASE 假设历史 hotness 能指导重排，MDK 假设 promotion proxy 能代表性能，NEMO 假设简单硬件 counter 足够表达策略需要。短 phase、别名指针或复杂设备成本会破坏这些假设。
  • 核心张力：更细粒度能减少浪费，却会增加元数据、间接访问和并发协议。ARCTIC 用 128-bit 原子状态换 lock-free 进度，jwmalloc 用 4 KB slab 与有限舍入换稳定尾延迟，OBASE 用 Guide 换对象搬迁自由，Megalon 则用每 host 一份索引换少量一致元数据。
  • 后续方向：首先应把安全重定位接口做成可复用抽象，明确 raw pointer、DMA、JIT、GC 与 crash recovery 的合同，而不是每篇论文各自限制应用。其次可在同一套长期 phase-changing trace 上比较 PEBS、NEMO、LifeLine 和 OBASE 的观测误差、控制滞后与搬迁成本，并报告 P99、能耗和内存峰值，而不只报告平均吞吐与稳态利用率。

9. 虚拟化、Serverless 与容器（8 篇）

这一组论文都在重新划分隔离边界。Arca-OSDI26 把进程切成可移动的 continuation，Spice-OSDI26 让 serverless 快照只恢复真正需要的页；GOODKIT-OSDI26 让观察 VM 与目标 VM 安全程度有限地共享状态，JANUS-OSDI26 与 Nested-SEV-OSDI26 分别压缩嵌套虚拟化的地址翻译和加密上下文成本；M3U-OSDI26 重做 post-copy migration；vBOIDs-OSDI26 与 vBPF-OSDI26 则给容器增加虚拟调度实体和逻辑 eBPF namespace。共同主题是：隔离层越多，通用边界上的复制、地址翻译、调度和状态重建越贵；性能改善来自让边界更贴近实际共享和迁移单位，但可信计算基和语义复杂度也随之增加。

逐篇解读

Arca-OSDI26

Arca 处理 serverless 函数在 I/O 后暂停、跨机继续时，完整进程或 VM 快照远大于真正需要保存的控制状态。它提出 procedure-oriented process：修改 libc，在 I/O 边界捕获 continuation，把函数分成可单独恢复的 funclet，并用 effect handler 表达外部操作。若状态仍在原地址空间，可原地恢复而不复制；跨机只传 continuation 和明确依赖的数据。无复制捕获加恢复约 2.55 微秒，且与堆大小基本无关；128 路 sandbox 创建为 32.2 微秒，Wasmtime 为 110 微秒，普通 process 和 Firecracker 分别约 540 与 742 毫秒。12 MiB image、32 KiB continuation 的跨机吞吐为 557.3 rps，而完整状态方案为 9.42 rps，约高 59.2 倍；128×128 整数矩阵乘法负载的稳定吞吐约为 17K rps。证据最适合“大数据、小控制状态”的函数；CPU 长循环没有 I/O 边界，线程、共享内存、持久 socket 和完整控制面未实现，effect 的崩溃重试与 exactly-once 语义也没有定义。

GOODKIT-OSDI26

GOODKIT 想让传统 VM introspection 不再为每次读取目标状态做昂贵跨 VM 翻译与 pause。它把 observer VM 与 target VM 放进同一个 Firecracker VMM，选择性地把目标内存直接映射给 observer；observer 还可加入目标内核的锁协议，在锁保护下读取或修改状态。probe 和 policy 可组合，mutualizer 协调多个 observer，减少重复冻结。地址翻译约 45–85 ns，获取目标锁约 26–36 ns；用锁而非 pause 后，lock/unlock 快 17 倍，P1–P9 的 turnaround 最多快 110 倍。14 个工作负载上，单 observer 的 target slowdown 最高 1.06 倍，LibVMI 为 5.15–37.6 倍；4 个 observer 平均为 1.16 倍。代价是 observer 获得很强权限：它能写坏内存或持锁不放，论文没有完成 RCU、observer crash 后释放锁等机制；方案还假设 observer 理解同一 kernel image 和类型布局，与 confidential VM 的威胁模型不兼容。

JANUS-OSDI26

JANUS 解决嵌套安全容器的双重 EPT walk 和频繁 L0 VM exit。它让 L1 software switcher 负责 CPU 在 L1 与 L2 间切换，而 L0 直接维护 EPT0→2；VMFUNC 切页表、#VE 处理敏感事件，shadow root 与 GPA 分区防止 L1 越界，PML 协助跟踪脏页。平均内存应用相对传统 PVM 和 KVM 分别快 144% 与 28.6%；多进程负载分别提高 339.7% 与 51.8%，多线程提高 37.0% 与 13.3%。Redis 相对两者提高 9.7% 与 45.1%，Memcached 提高 4.4% 与 48.2%；切换约 2700 cycles，接近 PVM 的 2681，远低于 KVM 的 16002。Flink 生产工作负载相对 RunC 开销低于 5%。边界是 Intel VMFUNC、#VE、PML 与 VMCS shadow 特定设计，需要三层内核修改；威胁模型仍是传统单层隔离，不保护恶意 L0，跨架构和更完整 I/O 路径也未验证。

M3U-OSDI26

M3U 针对 post-copy VM migration 中的页表锁、4 KB demand fault 与 2 MB bulk copy 冲突，以及设备 I/O page fault 造成的停顿。它保留静态物理页框，只并行标记 non-present，最后做一次 TLB flush；PVA 与多条 copy stream 和单一 page-table updater 解耦，4 KB demand pull 与 2 MB push 并行，并预装 VirtIO 状态减少设备恢复等待。默认实验为 64 vCPU、256 GB VM 和 100 Gbps 网络。脏页注册时间降低 60%–90.2%，6 条 stream 的复制带宽提高 7.6–8.3 倍并接近 80 Gbps；downtime 降低 47%，post-copy completion time（PCT，post-copy 迁移完成时间）降低 85.8%–89.6%。Redis 与 Memcached 的迁移期吞吐损失改善 2.6–4.1 倍，I/O page fault 最多降低 98.5%。结论来自一对 x86 主机、DPU 与 VirtIO，且假设源端所有内存常驻、目标端不 overcommit 或 swap；post-copy 的源端失效容错、不同设备状态和大规模并行迁移均未覆盖。

Nested-SEV-OSDI26

Nested-SEV 解决 AMD SEV/SEV-ES/SEV-SNP 在嵌套虚拟化中没有足够硬件上下文的问题。它给出两种模式：virtualization mode 为不可信 L1 分配分离加密上下文并由 L0 软件复用，passthrough mode 则让可信 L1 与 L2 共享上下文以减少切换；SNP 下用 exclusive GPA 维持隔离，并用定制 qboot、VMSA pool 和 CRC 管理启动与状态。在 EPYC 9334 上，跨 KVM、BitVisor、Xen 和三类 SEV 的平均 slowdown 约 0.9%–30%；在 VMMCALL 微基准中，nested SEV virtualization 的 VM-exit 成本约为 no-SEV nested 的 2 倍；passthrough 相对 virtualization mode 在不同测试中快 0.5%–28%。STREAM 在 KVM 上损失 10%–12%，BitVisor/Xen 为 0.4%–3.6%；单层 SEV 的 iperf 已损失 51%–53%，说明部分网络代价并非嵌套新增。边界是方案不保护 L0 控制的 VM-exit 路径、侧信道、DoS 或 L0/L1 串谋；passthrough 直接信任 L1，也没有独立 L2 attestation。实现依赖 AMD 与定制固件，未测多 L2 扩展、迁移和故障恢复。

Spice-OSDI26

Spice 关注 serverless 冷启动恢复稀疏快照时的三个浪费：按虚拟地址恢复会产生随机磁盘访问，成千上万个 VMA 要逐个 syscall 重建，普通 checkpoint metadata 也按 syscall 历史而非恢复需求组织。它用 SHELF 稀疏文件按磁盘读取顺序排列页，用 spliceVMA 批量建立 VMA 和 PTE，reexec metadata 直接重建状态，并在 Junction 中结合共享 page cache、异步预取和预分配 sandbox pool。13 个函数的 cold start 只比 warm 多 0.6–18 ms，平均比 process snapshot 快 7.5 倍、比 VM snapshot 快 9.5 倍；一个 RNN 的 3212 个 VMA 原本增加 21 ms，优化后约 2 ms。metadata 恢复为 0.9–7.5 ms，CRIU 为 2.6–749 ms；25 并发时，共享 page cache 让存储带宽少 20%、吞吐多 30%。边界是 host 与 Junction 特定实现，并非完整 Linux/VM；干净 LibOS、sandbox 和页池预先准备且不计入延迟，外部 socket、快照生成和平台控制路径未覆盖，预取还假设 profile input 稳定。

vBOIDs-OSDI26

vBOIDs 发现容器把内部所有线程暴露给全局调度器后，负载变化会触发大规模迁移和 cache pollution；单纯 pinning 又浪费空闲核。它把多个线程组合成 BOID 虚拟核心：全局层只放置 BOID，容器内层在已分配 BOID 之间重新平衡线程。Hotel workload 要求平均延迟不超过 200 ms 时，默认 Linux 在约 1K rps 停滞，vBOIDs、静态 pinning 和 Firecracker 都达到约 4K rps；vBOIDs 只使用默认方案约 40% 的 CPU。Social Network 吞吐从约 2K 提到 5K rps，迁移少 85%；Online Boutique 的调度实体从 359 降到 31 个 BOID，P95 从超过 4 秒降到 500 ms 内。CPU-bound Media workload 只与 unpinned 基线相当，说明收益主要来自减少调度抖动。BOID 数目前手工配置，实现深改 Linux 6.15 CFS；实验仅单台 x86，缺 P99、公平性、SMT 与 EEVDF 分析，自动伸缩尚未实现。

vBPF-OSDI26

vBPF 处理多租户共享内核上 eBPF 的两个冲突：程序挂在全局 hook，难以只作用于一个容器；每租户复制一套 hook 又让事件路径线性变长。它为每租户建立逻辑 eBPF namespace，并把虚拟 hook 在运行时 late bind 到当前资源；Snifer 维护资源到 namespace 的归属，dispatcher 用 hash 与扁平祖先路径选择程序，compiler analyzer 和 per-namespace overlay 隔离状态。普通共置负载开销不超过约 5.18%；跨租户 syscall latency 比逐租户原生挂载改善 3.7–3.9 倍。160 个 kprobe 程序时，吞吐最多为 native 逐个执行的 54 倍、filter 基线的 11.4 倍；PostgreSQL TPS 提高 29%、延迟降 23.6%，Apache 最多快 2.8 倍。事件归属约 130 ns，Snifer 在 Apache/fio 中约占 39 MB。它提供的是共享可信内核内的逻辑隔离，不等于 MicroVM；归属集合竞态、kfunc analyzer、RCU 并发和恶意程序安全测试仍不完整，并依赖管理员人工标注安全函数。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
Arca-OSDI26Serverless continuation完整进程状态远大于实际控制状态funclet、I/O 边界捕获、effect handler微基准、跨机 image、HTTP 与内存服务12 MiB image 场景跨机吞吐约高 59.2 倍无线程、共享内存和完整控制面；重试语义未定义
GOODKIT-OSDI26VM introspection跨 VM 翻译与 pause 太贵同 VMM 映射、加入目标锁、mutualizerFirecracker、14 个负载、4 observer单 observer slowdown 最高 1.06 倍observer 权限强；崩溃持锁、RCU、confidential VM 不支持
JANUS-OSDI26嵌套安全容器双重翻译与 L0 exitL1 switcher、直接 EPT0→2、VMFUNC 与 PML内存负载、Redis、Memcached、Flink多进程相对 PVM/KVM 提高 339.7%/51.8%Intel 特定；三层修改；不防恶意 L0
M3U-OSDI26Post-copy migration页表串行和设备 IOPF 阻塞迁移并行 flag、PVA、多 copy stream、混合页粒度64 vCPU/256 GB VM、100 GbpsPCT 降 85.8%–89.6%，复制接近 80 Gbps单对主机；需内存常驻；无源端失效容错
Nested-SEV-OSDI26加密嵌套虚拟化硬件加密上下文不足virtualization/passthrough、VMSA pool、exclusive GPAEPYC、KVM/BitVisor/Xen、SEV 三模式passthrough 比隔离模式快 0.5%–28%passthrough 信任 L1；AMD 特定；无迁移与多 L2
Spice-OSDI26Serverless 快照稀疏页随机读与 VMA 重建过慢SHELF、spliceVMA、reexec、共享 page cache13 函数、CRIU/VM snapshot、并发恢复平均比进程/VM snapshot 快 7.5/9.5 倍预热 sandbox 成本省略；Junction 特定；外部状态未恢复
vBOIDs-OSDI26容器调度线程过多引发迁移风暴BOID 虚拟核心、两级放置与平衡DeathStarBench、Online BoutiqueHotel 约 3 倍吞吐且只用约 40% CPUBOID 数手工配置；单机；缺公平性与 P99
vBPF-OSDI26多租户 eBPF全局 hook 缺租户边界，复制又线性变慢namespace、late binding、Snifer、状态 overlay160 kprobe、PostgreSQL、Apache160 程序时最多快 54 倍共享内核仍可信；分析器与竞态处理不完整

跨论文综合

  • 共同观察：完整 VM、进程、线程或 hook 集合往往不是实际工作单位。Arca 迁移 continuation，Spice 恢复稀疏页，vBOIDs 调度 BOID，vBPF 分派租户 namespace；缩小单位后，固定边界成本显著下降。
  • 共同假设：优化后的快速路径依赖平台能够准确识别状态归属。GOODKIT 要知道目标内核类型和锁，vBPF 要知道资源属于哪个 namespace，Arca 要在正确 I/O 边界捕获，M3U 要区分 demand page 与 bulk page。归属错误会从性能问题变成隔离或一致性问题。
  • 核心张力：性能越接近共享地址空间，隔离越需要额外信任。GOODKIT 的 observer 可直接读写目标，Nested-SEV passthrough 信任 L1，vBPF 信任共享内核和管理员，JANUS 则用更多硬件机制保住分层隔离。论文间没有一个同时获得最小可信基、通用部署和最低开销的方案。
  • 后续方向：需要用统一 fault campaign 检查迁移中源端崩溃、observer 持锁死亡、错误 namespace 归属、快照外部状态丢失和嵌套层恶意行为。另一个务实方向是将快速路径与可验证慢路径配对：正常时用 continuation、late binding 或 passthrough，检测到不确定归属时自动退回完整快照、显式过滤或隔离上下文，并量化退回频率和尾延迟。

10. 内核、移动系统与运行时（8 篇）

这一组论文把可观测、可调度和可修改能力放进真实运行时。Blink-OSDI26、Ichnaea-OSDI26、TypeCraft-OSDI26 分别从函数、对象和类型字段层面解释执行；iLand-OSDI26 用 AOT 解释器在未越狱 iOS 上运行和检查应用；MUSCHED-OSDI26 与 PeeR-OSDI26 重做移动交互任务和 eBPF 网络任务的调度；SANI-OSDI26 为异构移动 CPU 生成不同 kernel；Xkernel-OSDI26 则让运行中的内核常量可安全更新。共同特点是尽量不把系统停下来：观测、抢占、调优和更新都嵌入正常执行，但结论高度依赖硬件、编译器、调度规则和工作负载覆盖。

逐篇解读

Blink 解决移动设备上函数级 CPU 计数器剖析覆盖低、采样偏差大、调参要反复运行的问题。编译器在函数入口和出口放 PMU 读取占位符，运行时按每线程、每函数的 N/T 策略自修改二进制，只对选中的调用读取计数；MIR 阶段知道真实指令布局，可校正 ISB 与 44 条插桩指令。在一个范围较窄的直线型执行路径验证中，1.77 亿次调用、157 个函数里只有 568 次 retired-instruction 结果不同，DI 指标超过 99.999% 精确。12 个移动负载的函数覆盖率为 94%–97%，平均 96%，perf 4K 和 30K 采样分别约 54% 与 62%；单个采样点约增加 140.9 条指令和 38.7 cycles。用一次运行即可挑参数，传统方式需 50 次以上；Jank0（按时完成的 frame）从 65% 降到 64%，差约 1 个百分点，没有明显恶化。边界是单台 Kirin ARM64、已取得 root 权限的 Huawei 设备；精度的真实参照只覆盖 DI 和简单路径，PMU cycles 没有真实参照，JIT、特殊 ABI、存根代码和生产最坏尾延迟未测，先取前 N 次样本也有阶段偏差。

Ichnaea-OSDI26

Ichnaea 想以对象为单位记录所有读写，而不承担 Pin 动态插桩的巨大成本。它用 Intel MPK 把目标对象所在页设为不可访问；当前线程触发 SIGSEGV 后临时打开 PKRU，解码并模拟 faulting instruction，记录对象、调用栈、时间和值，再恢复保护；不支持的指令退回 breakpoint，page-isolated heap 减少同页无关对象。9 个 SPECint 上 slowdown 为 1.07–4.88 倍，Pin 为 12.9–86.54 倍；PostgreSQL wall time 为 35 秒，native 17 秒、Pin 944 秒。快速路径中位和 P99 为 9 与 19.5 微秒；AFL 合成测试 25 分钟找到 17/17 个目标，Pin 12 小时一个也没找到。但隔离 1 万对象时 RSS 为 80.3 MiB，普通分配仅 4.2 MiB，约高 19 倍；分配耗时 5.5 微秒对 728 ns。边界包括需预先标注对象、无完整 precision/recall、模拟器不完整及共享 text breakpoint 竞态；kernel/direct syscall 访问会绕过，MPK 也只适用于 x86。

iLand-OSDI26

iLand 解决未越狱 iOS 上无法 JIT、无法插桩系统进程，却仍希望动态分析第三方应用的问题。它把 Arm64 提前翻译成只读微操作 IR，由签名过的 RX execution unit 解释；定制 dyld 和 IR loader 装载代码，trampoline 截获 native library 回调到解释代码，不需要运行时生成机器码。应用使用虚拟环境，而系统库继续 native 执行。SPEC 性能实验在已越狱的 iPhone X/iOS 16.7.7 上完成：iLand 相对 native 慢 15–90 倍；未越狱的 iPhone 14 Pro/iOS 17.3.1 用于 64 个热门应用的兼容性测试。64 个应用中 49 个完全可用、11 个部分可用、4 个崩溃；60 个可使用应用里发现 13 个调用 private API、15 个直接读取 syscall 结果。它不是对恶意应用的安全 sandbox：应用与解释器同进程，native system library 内部不可见。实现超过 30 万行并包含 6709 个汇编 execution unit，依赖私有 ABI 长期维护；兼容性来自人工操作路径，完整可用率为 76.6%，覆盖不等于全部代码路径。

MUSCHED-OSDI26

MUSCHED 处理 Android 交互任务既不能占用 RT 调度、又会在普通 CFS 中被后台任务拖延的问题。它定义位于 RT 与 CFS 之间的 VIP class，用 eBPF 与 sched_ext 实现策略；VIP 优先放到 big core，采用 3 ms slice 和 budget，并把优先级沿锁和 Binder 依赖传播。在 Magic 7 的 10 个应用中，cold launch 平均缩短 14.8%，变异性降 24.25%；VIP 的不可中断睡眠时间降 71.8%，runnable wait 降 52.6%。论文报告部署超过 2000 万设备后，每 1000 小时 launch 超过 2 秒、animation 和 scroll 异常分别少 30.7%、25.0% 和 35.7%；pick-next 开销约从 2 增至 3 微秒。游戏负载没有收益，说明它主要解决交互依赖链而非所有移动性能。线上数据缺随机 A/B、样本量与置信区间，阈值是经验规则；误标、长期公平性、能耗以及 GPU/I/O 瓶颈的消融没有充分报告。

PeeR-OSDI26

PeeR 解决长时间运行的 eBPF/XDP 程序不能被普通内核调度器抢占，因而一个重任务会阻塞同核短请求。它只在 verifier 证明安全的 helper 或 kfunc 边界进行 cooperative preemption；JIT 插入预算检查，yield 时保存约 600 B continuation 和 xdp_frame 引用，通过 pointer relocation 与 trampoline 恢复。每 CPU kthread 配合 sched_ext，同时做宏观租户调度和微观程序调度。Redis GET 的 P99 相对默认下降 19.8 倍，吞吐增加 10.3%，相对 KeyDB 吞吐高 3.77 倍；Memcached P99 降 4.5 倍，但总吞吐略低。一次 yield 加 resume 为 247 ns，公平份额误差不超过 6%。不过 SRPT 会让长任务尾延迟恶化 1.5–2.3 倍；没有 helper 的长程序和长 helper 仍不可抢占，只支持 native single-buffer XDP，也无 work stealing。抢占改变 eBPF 原有原子性和交错，现有程序兼容性与安全验证不足。

SANI-OSDI26

SANI 针对 big/LITTLE CPU 使用同一个神经网络 kernel 时，tile 与并行策略无法同时适配不同核心。它为不同 cluster 生成各自 kernel，再用统一的 LCM block 坐标划分任务；反馈控制器根据进度合并或拆分任务，线程迁移到另一 cluster 时切换 index 与 kernel。在 5 款 SoC、6 个模型上，相对 native 的设备平均 latency 降 17.6%–23.7%，按模型汇总降 15.7%–29.5%；相对 AsyMo 仍快 9.8%–15.7%。一台手机上的能耗节省为 5.5%–39%；动态压力下 waiting latency 降 20%–40%，execution time 降 7%–10%。在线控制低于 3 ms，但 load preparation 最多 11 ms。证据主要是 FP32、NEON 和移动模型，能耗只测一台设备；成本模型和调参细节不足，报告以平均端到端 latency 为主，没有长期 thermal 与尾延迟。方法还要求 operator 能独立切 tile，未覆盖 GPU、NPU 和强依赖 kernel。

TypeCraft-OSDI26

TypeCraft 试图把 PMU 的“某条指令 cache miss”还原成“哪个 C/C++ 类型和字段造成 miss”。它结合 precise PMU sample、DWARF 和离线 binary dataflow：局部分析追踪地址计算，全局分析跨调用传播，最后按字段聚合访问、cache miss 和 affinity，给布局调整建议。Linux 的 memory-instruction 覆盖从 75.2% 提到 92.7%，覆盖的 sampled cycles 为 92.8%；ThinLTO 场景从 66.2% 提到 86.2%，但离线分析分别耗时约 2900 和 6729 秒。依据结果重排 cfs_rq 后 LLC miss 降 26.4%；MySQL TPS 和 IPC 提高 1.8%；Binutils nm 端到端快 2.7%，两类 miss 降 32.1% 与 55.4%。FFmpeg 和 Git 虽减少 miss，却没有端到端提升。边界是没有字段归属 precision/recall 的独立真值；x86 C 与完整 DWARF 最适配，assembly、JIT、Go 和复杂 C++ 较弱，手工改 layout 还可能破坏 ABI 或造成新冲突。

Xkernel-OSDI26

Xkernel 让管理员在不重启、不完整 live patch 的情况下更新内核性能常量。它离线差分编译两个常量版本，找出直接受影响的 critical span，再用 binary dataflow 扩出覆盖依赖状态的 safe span；运行时借 Kprobe/eBPF 修改值，并用 refcount 确认所有线程离开旧 safe span 后完成切换。140 个候选常量中支持 139 个，得到 367 个 critical span，多数只有 1 条指令；300 个 safe span 的中位大小为 10 条，最大约 8000 条。更新 P50 为 2.8 ms，KLP 为 30.4 ms，但后者不含 patch 生成；每线程过渡通常低于 10 ms，全局最大 144 ms。32 个热 probe 吞吐损失不超过 4%，128 个为 7%–14%。调 HDD 参数使读写快 7 与 54 倍，RocksDB 快 1.2 倍，CUBIC P99.99 FCT 降 81%。边界是常量手工挑选且绑定精确源码、编译器和配置；分析主要追数据依赖，可能漏控制流、异步设备状态，也不检查新值范围和 knob 约束。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
Blink-OSDI26函数级 profiling采样覆盖低且调参运行次数多MIR 插桩、PMU 直读、二进制自修改Kirin ARM64、12 负载函数覆盖平均 96%，perf 为 54%/62%单设备；精度真值窄；JIT 与生产尾延迟未测
Ichnaea-OSDI26对象访问追踪动态插桩太慢MPK fault、指令模拟、page-isolated heapSPECint、PostgreSQL、AFLSPEC slowdown 1.07–4.88 倍，显著低于 Pin需标注；内存可增 19 倍；MPK/x86 特定
iLand-OSDI26iOS 动态分析未越狱环境不能 JITAOT 微操作 IR、签名执行单元、trampolineiPhone X/iOS 16.7.7 的 SPEC；iPhone 14 Pro/iOS 17.3.1 的 64 个应用49/64 应用完全可用SPEC slowdown 15–90 倍；非安全隔离；应用只做人工路径覆盖
MUSCHED-OSDI26移动交互调度CFS 拖慢交互依赖链VIP class、sched_ext、优先级传播Magic 7、10 应用、线上统计cold launch 平均降 14.8%，线上慢启动异常降 30.7%线上非随机 A/B；阈值经验化；游戏无收益
PeeR-OSDI26eBPF 抢占长 XDP 程序阻塞短请求安全 yield point、continuation、sched_extRedis、Memcached、公平性微基准Redis GET P99 改善 19.8 倍helper-free 路径不可抢占；长任务尾延迟可变差
SANI-OSDI26异构移动 kernel同一 kernel 不适配 big/LITTLEcluster-specific kernel、LCM block、反馈调度5 SoC、6 模型、动态压力相对 native latency 降 15.7%–29.5%FP32/NEON 为主；能耗仅一设备；无 GPU/NPU
TypeCraft-OSDI26类型级性能分析PMU sample 无法归因到字段DWARF、局部/全局 binary dataflowLinux、MySQL、Binutils、FFmpeg、GitLinux memory-instruction 覆盖 92.7%无归因真值；离线分析耗时高；布局需人工修改
Xkernel-OSDI26在线内核调参常量更新通常需重启或完整 patch差分编译、critical/safe span、Kprobe/eBPF139 常量、存储与网络应用更新 P50 2.8 ms；CUBIC P99.99 FCT 降 81%手工常量；精确构建绑定；不验证新值合法性

跨论文综合

  • 共同观察：低开销来自把动作放到已经存在的安全点。Blink 在函数边界采样，PeeR 在 verifier-safe helper 边界让出 CPU，Xkernel 等线程离开 safe span，MUSCHED 沿 Binder 和锁传播优先级。边界选对时，无需全局暂停；选漏时，系统会失去覆盖或安全性。
  • 共同假设：这些方案相信编译器和静态信息能代表运行时。Blink 依赖 MIR 布局，TypeCraft 依赖 DWARF 与 binary dataflow，SANI 依赖可分块 operator，Xkernel 依赖差分编译的依赖闭包。JIT、汇编、设备异步状态和优化器变化是共同盲区。
  • 核心张力：观测越细，扰动和部署限制越大。Ichnaea 能看到对象值与栈，但可能把 RSS 放大 19 倍；Blink 覆盖广但只在函数边界；TypeCraft 归因到字段却离线耗时数千秒；iLand 无需越狱，但解释执行慢 15–90 倍且看不到 native library 内部。
  • 后续方向：应建立统一的真实参照套件，包含 JIT、汇编、信号、异步 I/O、线程迁移和故意构造的长 helper，用来量化覆盖率、错误归因、调度公平性和探针扰动。对线上移动系统，还应把平均启动时间之外的 P99、能耗、热降频、误标伤害与随机 A/B 一并公开，使部署规模不再替代因果证据。

11. 存储、文件系统与 I/O（8 篇）

这一组论文覆盖 GPU 直连存储、单机文件系统、分布式维护、CXL SSD、勒索恢复、用户态 mmap 和纠删码，但都在回答同一个问题：怎样把数据路径拆开，让常见 I/O 不再被一个全局 CPU、日志、锁或恢复边界串行化。CoPilotIO-OSDI26 在 GPU 与 CPU 间分工提交和完成；DeLFS-OSDI26 按核拆 F2FS domain；DINGO-OSDI26 合并维护读取；Espresso-OSDI26 借用相邻 SSD 的计算与 DRAM；Oxbow-OSDI26 把读写和日志阶段放到不同组件；Timelock-Drive-OSDI26 用小检查器强制保留历史；Umap-OSDI26 在分布式文件系统上实现用户态内存映射；WiseCode-OSDI26 则快速生成宽条带纠删码。性能结果通常很强，但崩溃一致性、相关故障和真实硬件部署是最常见的证据缺口。

逐篇解读

CoPilotIO-OSDI26

CoPilotIO 观察到 GPU 直接存储系统让 GPU 同时提交 NVMe 命令和轮询完成，会占用大量 SM；完全交给 CPU 又可能让 GPU 等待。它让 GPU 负责产生 SQ 请求，CPU 用户态线程轮询 CQ，完成后通过硬件可见 barrier 唤醒 GPU；若 CPU 跟不上，GPUAgent 可自适应加入轮询。这样控制路径由 CPU 承担，数据仍直接进入 GPU memory。在 A100/H800 与 4 块 Samsung 990 Pro 上，约 24 个 SM 就达到约 25 GB/s，而 BaM/AGILE 需要 72 个以上；I/O stall 最多减少 55.5%。FlashMoE 与 DLRM 相对 BaM 分别快 1.44 与 1.85 倍，4 KB 小请求收益尤其明显，通常需要 3–8 个活跃 CPU poller。边界是单 GPU、4 SSD 和 NVIDIA 软件栈；它依赖计算与 I/O 可重叠、host 有空闲核心，小请求获益比大顺序请求大。没有多 GPU、NUMA、SSD 故障和 CPU 机会成本的完整实验。

DeLFS-OSDI26

DeLFS 解决 F2FS 虽为 flash 设计，却仍让 log、SIT、NAT、SSA、I/O 和 GC 共享锁与全局元数据，128 核下扩展失败。它为每核建立相对独立的 domain，分开这些结构和 I/O 队列；更新别的 domain 的旧 block invalidation 时使用 delayed distributed lock，本地 free list 不足则委托其他 domain，并重新安排 checkpoint 的持久化顺序。在 128 核、单 NVMe、4 KB 随机写中，吞吐分别是 F2FS、MAX、ScaleLFS、F2FSJ 的 4.34、4.29、4.10、4.50 倍，P99 相对强变体低 2.75–3.73 倍。Filebench 提高 1.31–2.34 倍，RocksDB 提高 1.19–2.24 倍；write amplification 从 1.088 小幅升到 1.101。当空闲空间接近 1% 时优势消失，说明 domain 局部余量是关键假设。实验只覆盖单机、单盘、高并发写；CrashMonkey 仅测两个场景，free-space skew、CPU migration、多租户、多 NVMe 和更复杂 crash ordering 未充分验证。

DINGO-OSDI26

DINGO 指出大规模存储中的 scrub、re-encode、re-replication 等维护任务常重复读同一 sealed block，而且各任务各自调度会制造磁盘峰值。它让维护任务声明 read set、deadline 和可接受的 subset，planner 在 deadline 内合并共享读取，dispatcher 再用短期 cache window 执行计划。在 HDFS 原型中，每读取 1 字节逻辑维护数据只需 0.74 字节物理读取，减少 26%，接近 predictor 的 28%；前台 P50 与 P99 也改善。100 PB 模拟中，维护所需 disk headroom 降 28%–51%，原本 36 TB 的节点在相同约束下可扩到 64 或 58 TB，约 1.7 与 1.5 倍；结果距 clairvoyant lower bound 不超过 5%。1 EB、小时级 quantum 的计划在 15 分钟内完成，但需约 205 GB RAM。容量结论主要来自 sealed HDFS block 与 trace-driven 模拟，只优化 read I/O，不涵盖写、CPU、网络；前台 tail 仍可能受短时 burst，planner HA 和自身故障只做定性讨论。

Espresso-OSDI26

Espresso 面向 CXL 3.0 可组成 SSD：一块 SSD 可能有空闲 ARM core 或 DRAM，邻居却在缺资源。它把 SSD 分成 compute end 和 data end，请求可重定向到 lender ARM 执行而数据留在 borrower；borrowed DRAM 以 2 MB FTL segment 管理，在线 MRC 决定借多少，borrower redo log 记录远端 metadata 变更，各盘每 10 ms 去中心化轮询调整资源。在 12 SSD 模拟、资源减半的设置下，256 KB 顺序读的 CPU 利用率比 Shrunk 高 50.4%；14 条生产 trace 的平均吞吐比 Shrunk 高 19.2%，比 VH 高约 20%，接近完整资源。按论文价格假设，BOM 降 19%；lender 自身吞吐平均只降低 1.3%；相对 Conv，Espresso 新增的 inter-SSD latency 占总请求延迟的比例最多为 2.9%。但真正的 CXL 3 多 SSD 机器不存在：本地组件在 OpenSSD 上，整体依赖模拟器和 NUMA 类比。结果假设同构可信 firmware，未测相关 burst、lender 失效、dirty remote metadata 恢复、安全隔离和价格变化。

Oxbow-OSDI26

Oxbow 认为纯用户态文件系统虽能绕过 kernel，却要自己重做 page cache、sendfile 与持久化，且 fsync 被集中 server 串行化。它采用 hybrid split：oxLib 拦截调用并跟踪 mmap dirty page，精简 kernel 路径保留 VFS/page cache read，可信 H-Server 负责写与 SPDK，D-Server 在 computational storage device 上做后台 journal 和 checkpoint；split journaling 把 fsync 的多个阶段流水化。写延迟相对 ext4 低 1.2–3.5 倍，吞吐高 1.3–4.8 倍，相对 µFS 最多高 86%；CPU efficiency 为 µFS 的 1.8–3.9 倍。fsync 单客户端快 16.8–19.2 倍，顺序读比 µFS 快 10.5–18.5 倍，但最多仍比 ext4 低 24%；LevelDB 最多快 89%，checkpoint 吞吐增 58%、延迟降 46%。CSD 由 BlueField/DPU 加 SR-IOV SSD 模拟而非集成设备；host CPU 指标不含 device CPU/energy，四组件 crash protocol 没有故障注入，复杂 POSIX 语义、长期碎片和 staging 饱和也未充分测试。

Timelock-Drive-OSDI26

Timelock-Drive 想在主机和版本系统都可能被勒索软件控制时，仍强制保留最近数据。可信约 400 行 checker 只允许 block 从 freeze 经倒计时变为 unfreeze，再被 free；append-only metadata log 记录状态，主机侧 untrusted cache 提供性能，checker 用 MAC 和 freshness 防止伪造或回滚，版本系统本身不进入可信基。已知 18 种 ransomware 场景均可恢复，Dafny 对状态机和 log replay 做了形式化验证。SSD 执行时间开销约 0.4%，吞吐开销约 0.5%，trace latency 均低于 1%；恢复为 7.8–58 秒，LVM 为 7.4–45 秒，metadata 几何平均约 1.35 MB/10 万操作。可是性能实验把 checker 放在同机共享内存，真正隔离只在 Raspberry Pi 做安全演示；secure clock、controller 和 key storage 不是产品硬件。checker cache 很小时开销可达 400%，系统强依赖主机全量 cache；证明也不覆盖完整版本系统、恢复工具、patient attacker、DoS、长期 retention 和 SSD wear。

Umap-OSDI26

Umap 为分布式文件系统上的大数据提供普通 mmap 接口，避免应用自己写缓存和异步 I/O。它用 userfaultfd 在用户态接管 page fault；PIAO 合并待处理 4 KB 请求并在多 channel 间公平调度，shadow copy 协调同步写，lock-free cache protocol 支持并发 fault，reuse-distance 策略惰性调整缓存大小。在 32 线程、128 GB FBM 数据上，GPFS 后端相对本地 Optane mmap 的读写吞吐分别提高 2.8 与 8.3 倍；ImageNet 快 1.2–1.9 倍，serverless LLM load 快 2.3 倍，finance 最高快 6.7 倍，OpenBLAS 科学计算的 JCT 只缩短 13%–28%；32-thread write 下，Umap 的内存占用少于 mmap 的 10.4%。论文称 18 个月生产运行未观察到相关终止。边界是收益偏向数据并行、read-mostly 与 aggregate throughput；单线程小读约慢 20%，节点间没有隐式 cache coherence，重叠写需要应用约束。只测分布式文件系统，生产数据无对照组，dirty crash semantics 与 LD_PRELOAD 边角行为未展示。

WiseCode-OSDI26

WiseCode 解决宽条带纠删码搜索空间巨大、传统枚举验证一个候选都很慢的问题。它从较窄的 maximum-size-recoverable 模板构造宽码，把共享矩阵的候选组成 sibling group，复用重复矩阵计算系数；稀疏两阶段编码先聚合局部数据，再解 parity，减少 CPU 与网络开销。一个 (104,100,64) 候选的验证从 22.3 ms 降到 0.78 ms；若干配置用基线搜索超过 24 小时，WiseCode 只需 21 或 341 秒。在 161 节点、1 Gbps Ceph 集群上，相同存储开销时 repair throughput 提高 1.41–2.18 倍，前台 latency 降 11%–27%，编码快 5.5–22.4 倍。可靠性主要用独立失效假设下的 MTTDL 模型证明，没有相关机架、批次或网络故障实验；高速网络和 HDD 结果部分来自单盘模拟或外推。某些 degraded read 的 RP 方案会慢 117%–200%，说明修复优势不能泛化为所有读取。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
CoPilotIO-OSDI26GPU storage I/OGPU 轮询浪费 SM，CPU-only 又可能落后GPU SQ、CPU CQ、barrier、GPUAgentA100/H800、4 SSD、FlashMoE、DLRM约 24 SM 达 25 GB/s；应用快 1.44–1.85 倍单 GPU/NVIDIA；需 spare CPU；无多 GPU 与故障
DeLFS-OSDI26多核 F2FS全局元数据与锁限制扩展per-core domain、延迟分布锁、委托 free list128 核、单 NVMe、Filebench、RocksDB4 KB 随机写吞吐提高 4.10–4.50 倍单盘高并发写；低 free space 收益消失；crash 测试少
DINGO-OSDI26分布式维护 I/O独立维护任务重复读取并制造峰值声明式 read set、deadline、合并计划HDFS 原型、100 PB/1 EB 模拟物理维护读取降 26%，disk headroom 降 28%–51%容量为模拟；sealed block；只优化读取
Espresso-OSDI26CXL 组成式 SSDSSD 间 CPU/DRAM 利用不均compute/data end、2 MB segment、MRC、redo logOpenSSD 组件、12 SSD 模拟、生产 trace资源减半时吞吐比 Shrunk 高 19.2%无真实 CXL 3 系统；同构信任与失效恢复未测
Oxbow-OSDI26混合文件系统纯用户态重做 cache 且 fsync 串行oxLib、kernel read、H/D-Server、split journalDPU 模拟 CSD、LevelDB、Filebenchfsync 快 16.8–19.2 倍非集成 CSD；device CPU 未计；四组件 crash 未注入
Timelock-Drive-OSDI26勒索恢复主机与版本系统都可能被攻陷小 checker、倒计时状态机、append-only log18 攻击、Dafny、SSD trace正常吞吐开销约 0.5%高性能路径未物理隔离；依赖大 host cache；证明非端到端
Umap-OSDI26DFS mmap应用手工缓存与同步复杂userfaultfd、PIAO、shadow copy、lock-free cacheGPFS、AI/finance/science 应用、18 个月运行finance 最高快 6.7 倍；OpenBLAS JCT 缩短 13%–28%headline 同时更换 runtime 与 storage backend；单线程小读退化；无跨节点 coherence；生产无对照
WiseCode-OSDI26宽条带纠删码候选码搜索和编码成本高MSR 模板、sibling group、稀疏两阶段编码161 节点 Ceph、搜索微基准、MTTDLrepair throughput 提高 1.41–2.18 倍1 Gbps；可靠性依赖独立失效；部分 degraded read 更差

跨论文综合

  • 共同观察：把一个共享串行点拆成多个角色是主要性能来源。CoPilotIO 分离提交与完成，DeLFS 分离 per-core metadata domain，DINGO 合并跨任务读取，Oxbow 分离读、写、日志与 checkpoint，Espresso 分离数据位置与计算位置。
  • 共同假设：这些拆分都依赖后台或远端组件按时完成。CoPilotIO 假设 CPU poller 不落后，DeLFS 假设每个 domain 有足够 free space，DINGO 假设任务 deadline 与 read set 已知，Espresso 假设 lender 稳定，Oxbow 假设 D-Server 可持续排空日志。突发或失效会重新形成队列。
  • 核心张力：数据路径越分布，crash ordering 越难证明。Timelock-Drive 的可信状态机最小但高性能实验未隔离；Oxbow 和 Espresso 有四方或跨盘 metadata；Umap 把脏页放进用户态协议；WiseCode 的可靠性仍依赖独立失效模型。性能表格不能替代端到端故障实验。
  • 后续方向：建议用同一套 fault injection 覆盖 power loss、poller stalled、CSD/lender crash、重复完成、网络分区和相关磁盘失效，并把恢复时间、数据丢失边界和前台 P99 与吞吐一起报告。另一个方向是显式计算“被借出的 CPU、DPU、poller 和维护 planner”成本，避免只看 host CPU 或设备吞吐而隐藏系统总能耗与资源占用。

12. 数据库、索引与图处理（8 篇）

这一组论文把数据结构和查询执行放到 DPA、GPU、SSD 或多机图引擎上，也包括缓存策略与数据库测试。DPA-Store-OSDI26 把学习型索引（learned index）遍历下沉到 DPA，FlowANN-OSDI26 与 Helmsman-OSDI26 分别优化混合 CPU/GPU ANN 和大 top-k SSD ANN；Merlin-OSDI26、S4-FIFO-OSDI26 从对象级特征或模型调参改进缓存；Pluto-OSDI26、POEGA-OSDI26 减少分布式图和演化图的冗余工作；ValScope-OSDI26 用集合与值的变形关系发现数据库 bug。共同结论是，真实访问分布中有大量可利用的局部性和单调性，但许多最大加速来自静态数据、离线访问轨迹或特定硬件，动态更新、故障和按数据来源留出后的泛化仍是关键边界。

逐篇解读

DPA-Store-OSDI26

DPA-Store 解决 learned index 在 host 上遍历会消耗 CPU，而直接搬到 DPA 又受小内存和低写性能限制的问题。它让 DPA traverser 缓存热 inner model，并在 leaf 维护 write buffer；host 保存 value、负责 retrain 与 split。结构变更用 COPY 加 CONNECT 把新子树接入，RCU epoch 回收旧版本；客户端经 UDP hash 到 traverser，并自行 retry 和维持请求次序。在 BlueField-3 B3140L、100 Gbps、64-bit key/value 设置中，GET、RANGE、UPDATE、INSERT 分别约 33、13、12.1、1.7 Mops/s。多数数据集 learned index 达 24.8–26.3 Mops/s，B+ tree 为 18.8–21.5 Mops/s；但 osmc 上 learned index 只有 14.6，B+ tree 为 20.8。复制 192 MB 要 1.605 秒，约 120 MB/s，解释了 split 路径为何慢；另一块 B3220 在 skew GET 下达 48.5 Mops/s。边界是单节点内存系统、8-byte value 与短 range，没有复制、durability、exactly-once 或故障恢复；DPA 只保持 index 状态，插入与结构调整明显是瓶颈。

FlowANN-OSDI26

FlowANN 针对十亿级 ANN 图：全部放 GPU 显存不够，传统 CPU/GPU 分步搜索又频繁同步和拷贝。它用 locality-preserving assignment 让短边形成 GPU 内的 compact local ID，长边留在 CPU；GPU 以单个 fused kernel 搜索本地图，xCopier 让 CPU 通过 BAR/MMIO 拉取少量远端向量，adaptive deferred discovery 根据窗口估计器推迟不急的 CPU 探索，最后由 CPU rerank。在 H20、160-core CPU、2 TB 内存、recall@10 为 0.9 的十亿级数据集上，相对不同类别基线平均吞吐提高 4.08–45.7 倍，最大 172.6 倍。主吞吐比较覆盖三个十亿级数据集；论文只在 SIFT1B 画出 query latency，batch 2,048/16 时平均延迟分别降低 83.8%/81.6%，P99 分别降低 75.4%/86.1%。另一个独立微基准中，xCopier 相对 cudaMemcpy 将 32–8,192 B fetch 的端到端延迟降低 78%–80%。一张 H20 在多数 batch 下比 8-GPU GGNN 快 2.22–15.3 倍，但 batch 2048 时会落后。证据集中在静态、低维图；高维向量计算可能主导，基线多为作者重实现。它还假设 BAR/PCIe 延迟可预测，未测试在线更新、数据漂移、多租户和 GPU/CPU 故障。

Helmsman-OSDI26

Helmsman 面向生产中 large top-k ANN：数据远大于 DRAM，通用文件系统和单条随机 SSD I/O 无法吃满设备，固定 nprobe 也不能同时满足不同查询。它把聚类 posting list 批量读到 12 块原始 NVMe，通过 SPDK、固定 list 和 chunk allocator 减少软件开销；LLSP 用近期日志训练 GBDT，为每个查询预测 nprobe。建索引时 GPU 做 coarse 阶段，弹性 CPU 集群做 fine 阶段；线上用周期 rebuild、辅助 HNSW 和 tombstone 处理更新。SIFT 上相对 DRAM-SSD 方案吞吐高 2–16 倍，平均 latency 低于 10 ms、P99.9 低于 20 ms，SSD 利用率为 70%–85%。HNSW 仅用少量 DRAM仍达到完整方案 25%–70% 吞吐，10B 数据为 47%–85%；LLSP 再提高 1.1–1.6 倍。0.1B index build 从 9–12 小时降到 1 小时内，10B 从 16 小时降到 4–7 小时，但用约 1 万 CPU core。部署约 40 台服务器替代部分 3.5 万核与 0.35 PB 资源。边界是 12 块本地 Gen5 SSD、large top-k 和平均 90% recall，不保证逐查询 recall；成本未完整计算构建集群、轮询和能耗，也未测试 SSD crash 与高频 update。

Merlin-OSDI26

Merlin 发现，把整条访问轨迹分类为少数工作负载类型，再切换淘汰算法，会丢掉对象级差异；多个“互补”算法组合还可能相互驱逐。它按缓存容量划分 epoch，为每个对象同时估计当前热度（hotness）和跨 epoch 流行度（popularity）；filter、core、staging 三个 FIFO 数据队列加一个 ghost 队列执行统一淘汰，count-min sketch 压缩计数。11 个数据集含 5423 条真实访问轨迹、3380 亿请求、330 亿对象。在缓存为 10% WSS 时，平均 hit rate 比 LRU 高 10.4 个百分点，S3-FIFO、Cacheus、ARC 分别高 7.1、6.8、6.1 个百分点；但这些是访问轨迹模拟。2 亿请求的合成混合流中，32 线程吞吐比基线高 1.4–7.8 倍；去掉 10 微秒后端 miss 后，纯管理吞吐只比 S3-FIFO 高 16%。仍有 2.9% 对抗性访问轨迹比最佳算法低超过 5%，常因历史热点失效或 sketch 假阳性。动态缓存容量、TTL、每次 miss 成本和生产 P99 未覆盖，大规模访问轨迹也没有按数据来源留出后再测试泛化。

Pluto-OSDI26

Pluto 重新审视 edge-cut 分布式图中的 mirror：若某 host 上一个顶点只有一条本地入边，建 mirror 并做聚合反而比直接传 update 更贵。static partial 模式只在至少两条本地入边时保留 mirror；mirror-free 模式把远端顶点变成 phantom，把更新工作迁到合适 host，并用固定 push/pull 路径、dirty phantom、聚合工作项和本地 ID 降低通信。无法适配的 BC backward 可退回 full mirror。在 Stampede3 的 8–48 host 上，达到容量要求所需的最少主机数仅为 full-mirror 的 50%–90%，例如 Magellan 从 26 台降到 17 台、Kronecker 从 46 台降到 23 台。相对开源系统最快可达 12 倍，正文 harmonic mean 约 2.5 倍；相对 D-Galois+ 最多 3.8 倍、harmonic mean 1.75 倍。没有聚合的方案部分超过 1000 秒 timeout。边界是静态 edge-cut 和固定 update model；无动态图、repartition、失败恢复，BC backward 仍可能内存突增。真实图 topology 上附加的 LPG property 是合成的，BSP 通信实现也可能影响比较。

POEGA-OSDI26

POEGA 处理一系列相邻演化图 snapshot 上重复执行分析的问题。它用 UnionCSR 合并全部边；Evolution Pruning Guide 构建只占原 snapshot 12.1%–15.9% 的代理图，让 P1 先给出近似结果；对 addition-only 图，P2 refinement 再得到精确结果。系统把多个 snapshot 融合执行，利用单调 relaxation 的上下界剪枝；AMVA 让多个版本先共享 scalar state，再在分歧时展开 vector state。在 5 个真实大图、6 个算法和 32 个合成 evolution snapshot 上，相对最快非 POEGA 基线平均快 6.6 倍、最多 14.3 倍，相对 EGraph 最多 253.9 倍。EPG accuracy 为 87.1%–98.8%；P2 coalescing 相对 multi-stream 与 sequential 分别快 13.6 与 21.9 倍，AMVA 最多快 3.3 倍，但 8 或 16 snapshot 时有时会变慢。主要边界是更新由真实 topology 上随机合成，并非真实演化日志；只支持若干单调算法，UnionCSR 离线构建，未测 ingestion latency、多 GPU、故障和查询到达延迟。

S4-FIFO-OSDI26

S4-FIFO 的问题是 S3-FIFO 有少量全局参数，但最佳值会随访问轨迹和缓存容量变化，人工固定值在不同工作负载下不稳。它从前 20% 访问轨迹提取 73 个特征和队列直方图，用小型 GBDT 一次预测 5 个参数；数据路径仍只有 3 个物理 FIFO 队列。模型异步运行，策略以 FIFO 为安全锚点，并用后悔值（regret）约束极端退化。5175 条访问轨迹随机划分为 4140 条训练、1035 条测试；缓存为 10% 时，相对 FIFO 的 miss 降幅约 16%，这个降幅比 S3-FIFO 高 26%、比 3L 高 8%，最坏只比参照多约 0.8% miss。v2 与离线选择的差距不超过 0.2%；CacheBench 中 GET 为 5.1 Mops/s，S3-FIFO 为 5.8 Mops/s，SET 都约 1.2 Mops/s，模型预测低于 2 ms。边界是随机切分访问轨迹，而不是按数据来源留出，同源模式可能泄漏；模型只在前 20% 预测一次，不适应后续阶段，也只优化 miss ratio，没有考虑字节成本、TTL、后端延迟与尾延迟 SLO。

ValScope-OSDI26

ValScope 解决数据库 query optimizer 和执行器 bug 难以用单一预期结果判断的问题。它构造同时包含集合包含关系与值单调性的 metamorphic relation：先生成相关查询集合，再沿 SQL AST 传播 set 与 scalar 的变化方向，从而推导结果应扩大、缩小或数值单调变化。系统自动生成 query pair、缩减失败用例，并跨版本去重。连续一个月测试 6 个 MySQL-family DBMS，发现 67 个新 bug，其中 57 个确认，61 个在前 24 小时暴露；对已审阅 oracle，61 个中的 48 个无法被它们发现，占 78.9%。query pair 的生成速度约为每秒 1,923–2,000 对，六个 DBMS 的执行成功率为 72%–93%；45 个 bug 涉及 subquery，22 个涉及 grouping 等组合。边界是 MySQL 系 DQL，只覆盖可建立单调关系的函数；NULL、float、cast 和 vendor semantics 可能破坏规则。规则没有完整形式化证明，10 个问题未确认，root-cause 去重是启发式，也不测试 transaction、recovery 和并发隔离。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
DPA-Store-OSDI26DPA learned indexhost 遍历耗 CPU，DPA 内存和写入弱DPA traverser、热 model、leaf buffer、COPY/CONNECTBlueField-3、100 Gbps、64-bit KVGET 33 Mops/s，RANGE 13 Mops/s单节点、8-byte value；无持久化；INSERT 仅 1.7 Mops/s
FlowANN-OSDI26混合 CPU/GPU ANN十亿图放不进 GPU，跨设备同步太多LPA、fused GPU search、xCopier、deferred discoveryH20、160 核、2 TB、十亿数据平均吞吐提高 4.08–45.7 倍静态低维图；基线重实现；无更新与多租户
Helmsman-OSDI26SSD large top-k ANN随机 I/O 与固定 nprobe 限制吞吐12 NVMe/SPDK、LLSP、GPU/CPU 构建SIFT、10B 数据、生产部署吞吐提高 2–16 倍，P99.9 低于 20 ms平均 90% recall；成本未含大构建池；无 SSD 故障
Merlin-OSDI26自适应缓存粗粒度分类和算法组合互相干扰cache-sized epoch、hotness/popularity、三 FIFO 加 ghost5423 trace 模拟、合成吞吐10% WSS 时比 LRU 高 10.4 个命中百分点主证据为模拟；2.9% adversarial；无 TTL/动态容量
Pluto-OSDI26分布式图低收益 mirror 浪费内存与通信partial mirror、phantom、工作迁移、固定路径Stampede3、8–48 host、多图算法所需最少主机数为 full mirror 的 50%–90%静态 edge-cut；无动态图、repartition 与故障
POEGA-OSDI26演化图分析相邻 snapshot 重复计算UnionCSR、EPG/P2、融合执行、AMVA5 图、6 算法、32 合成 snapshots平均快 6.6 倍，最多 14.3 倍演化更新合成；单调算法；离线构建与单 GPU
S4-FIFO-OSDI26学习型缓存调参固定 S3-FIFO 参数跨 trace 不稳73 特征、GBDT、5 参数、FIFO regret anchor5175 trace、CacheBench10% cache 相对 FIFO miss reduction 约 16%随机 trace split；只预测一次；只优化 miss ratio
ValScope-OSDI26数据库测试SQL bug 缺结果 oracle集合包含加值单调、AST 传播、自动缩减6 个 MySQL-family DBMS、一个月发现 67 个新 bug，57 个已确认仅 DQL 与单调函数；规则未完整证明；无并发事务

跨论文综合

  • 共同观察：把全局问题拆成对象、查询或 snapshot 的局部特征后，系统可以跳过大量无效工作。Merlin 按对象分类，S4-FIFO 按 trace 特征调参，FlowANN 区分短边和长边，Helmsman 按查询选 nprobe，Pluto 按本地入边数决定 mirror，POEGA 按版本影响范围剪枝。
  • 共同假设：历史与结构必须能预测未来。Merlin 假设对象的近期与跨 epoch 访问历史能预测后续，S4-FIFO 则假设 trace 前 20% 有代表性；Helmsman 假设近期日志能预测查询难度，FlowANN 假设图 locality 稳定，POEGA 假设 snapshot 之间变化小且算法单调。论文都展示了失效信号，但很少给出在线检测后自动退回的完整机制。
  • 核心张力：专用硬件与离线准备换来高吞吐，却让更新变贵。DPA-Store 的 GET 达 33 Mops/s，但 INSERT 仅 1.7 Mops/s；Helmsman 查得快，却动用大 CPU pool 周期重建；FlowANN 静态图很强，在线变化未测；POEGA 需先建 UnionCSR。ValScope 从另一面说明，复杂优化越多，越需要能跨实现检查语义的测试工具。
  • 后续方向：一是按数据来源留出，并按时间顺序评测，避免随机切分访问轨迹时把站点或时期特征泄漏到训练和测试，并报告负载阶段变化后的恢复时间。二是把更新、重建、DPA/CPU/GPU 资源、SSD 轮询和失败恢复计入统一的单次查询总成本，而不只比较稳态查询吞吐。三是将 ValScope 一类关系测试扩展到 ANN recall 约束、缓存策略不变量和图快照单调性，为这些高度专用的优化提供持续语义检查。

13. 网络、RDMA 与服务路径（8 篇）

这一组研究同一个现象：网卡和链路已经很快，但请求仍卡在传输、锁、消息调度、缓存和 GPU 通信接口上。它们不再只按数据包或连接做控制，而是直接管理消息、数据块、票号和资源额度。这样更容易贴近应用需求，但也可能占用更多 CPU 核、依赖特定硬件，或要求开发者补充标注。

逐篇解读

  • BALBOA-OSDI26 — 核心问题：商用 RNIC 的 transport、重传和扩展点大多固化，研究者很难在不丢线速的情况下加入加密、检测或预处理。机制：BALBOA 在 FPGA 上用 512-bit 流水线拆开 data、control 和 completion stream，把 QP state 放在片上、重传数据放进 HBM，并预留 service slot。关键结果：32 KiB 以上 READ/WRITE 达约 11.2–11.6 GB/s，接近 100GbE payload 上限；32 个 QP 下总带宽仍约 11.2–11.5 GB/s，AES 只增加 44 ns pipeline latency。证据边界：实现仅覆盖 RC 的一侧 READ/WRITE，默认容量 500 QP 但性能只测到 32 QP；没有 DCQCN/TIMELY、loss/incast/conformance 实验，200G 也只有 synthesis timing，DLRM 案例只是三个 stateless operator 的 micro-pipeline。
  • FARLock-OSDI26 — 核心问题：公平 RDMA lock 会让本地请求绕回 RNIC，ALock 的 local/remote 双队列又会打乱真实到达顺序并增加 handover。机制：local 和 remote requester 先在各自队列排队，两个队首再用 Peterson lock 领取全局 ticket，最后按 ticket 顺序提交；local grouping 可减少跨节点 ownership bounce。关键结果：10-node 高争用 microbenchmark 中，local tail latency 相对公平 MCS/Ticket 最多低 62 倍；替换 Sherman 的锁后，random update 的 local tail 最多低 14 倍，吞吐近似不变。证据边界：最大倍数来自特定 percentile 和 lock 数；lock 多于 30、争用下降时，多一次 RDMA operation 已显出成本，remote grouping 还会负收益。论文没有 holder crash、QP reset、网络分区或 reader-heavy transaction 实验。
  • Rakaia-OSDI26 — 核心问题：TCP 只向用户态暴露逐 connection byte stream，而调度器真正需要跨连接的完整 message；长 handler 会让 connection-centric worker 出现队头阻塞。机制：Rakaia 在 Linux receive softirq 中解析 Memcached/HTTP/2 message，用 per-core FIFO、power-of-two choices 和 work stealing 做全局 work-conserving scheduling，并把 gRPC 请求直接交给 worker。关键结果：100 µs bimodal handler、20 connections 时约维持 160 KQPS，分别约为 TCP-CS 和 KCM 的 4 倍、5 倍；gRPC-Go/C++ 相对 POSIX API 最多提高 1.56 倍和 2.69 倍，Silo 在 500 µs P99 SLO 下为 350 KQPS。证据边界：评测只有单机 20 hardware threads 且均为 CPU-bound；parser 只覆盖 Memcached binary 与 gRPC 所需 HTTP/2，TLS 路径不占优，TCP loss HOL、kernel parser 安全和大 NUMA 扩展都未解决。
  • SBB-OSDI26 — 核心问题：central timer、queue monitor 和 packet dispatcher 会分别卡住抢占、CPU 分配和负载均衡，使微秒级 runtime 在几十核后停止扩展。机制：SBB 用每核 timer 和 NIC User Interrupt 触发抢占，以短期 task stealing 修正瞬时不均，再用长期 flow migration 改变 RSS/flow placement，删除三个中心线程。关键结果：相同 tail-latency SLO 下，论文汇总吞吐比对应先前系统高 1.7–5.2 倍；48 workers 的 Fixed(1) 约 26.5 MRPS，16 workers 约 9.5 MRPS；UINTR notification 约 0.45 µs，传统 interrupt 约 3.4 µs。证据边界：只测支持 UINTR 的 Intel Sapphire Rapids 和两款 NIC，最多 48 workers 时已经 sublinear；轻量 TCP/UDP stack 没有拥塞控制，RocksDB 关闭 logging，不同 baseline 还使用不同 kernel/NIC。
  • Sepia-OSDI26 — 核心问题：DDIO working set 即使小于 LLC 总容量，也会因 Rx page 在 slice/set 上分布不均而超过局部 associativity，形成“leaky DMA”。机制：Sepia 用 Stride-1 page coloring 均匀分配 Rx page，再缩小 Rx ring 和 TCP buffer，把 DMA working set 控制在真实可用 LLC 内。关键结果：effective LLC 从 Linux 默认的 18 MB 提到实用方案的 32 MB；200 Gb/s TCP 中以 3.5 而不是 6 个 core 饱和链路，LLC miss 约 0.4%；NVMe-over-TCP 128 KB read 最多提高 51.1%。证据边界：单独 coloring 平均只提高 8.62%，完整 headline 依赖 ring/TCP throttling；94.4% capacity 增益来自不可部署的 Tetris 上界。主证据是单 socket Ice Lake、ConnectX-6、Rx path，SPDK target 还是 NULL device。
  • Svalinn-OSDI26 — 核心问题：服务往往同时有 CPU、memory bandwidth、mutex 等多个局部瓶颈，只在入口维护一个共享 AQM 队列会错误地限制未触碰该资源的请求。机制：全局 controller 只寻找最高 utility 的总负载，局部 controller 在真正访问点排队或丢弃；m_semaphore 把隐式内存带宽变成显式 credit。关键结果：三个真实应用和合成 workload 中，相对 SEDA/Protego 的应用 goodput 最高提高 6.51/6.49 倍；双瓶颈实验中 CPU P99 最多低 5.95 倍，memory controller 在负载切换后平均约 50 ms 收敛。证据边界：开发者必须正确标出 memory-heavy path；默认策略会丢弃已经开始执行的请求，依赖 cleanup 和另一 replica。评测只组合 CPU、内存带宽和 mutex，最高结果来自人工 request mix，缺少生产 trace 与不可重试副作用。
  • UCCL-Tran-OSDI26 — 核心问题：ML collective 变化快，而 RNIC 的拥塞控制、可靠性和单路径策略更新慢；把整个数据面搬回 CPU 又无法承载多块 400G NIC。机制：payload 继续由 NIC 在 GPU memory 间 GPUDirect DMA，host engine 只处理 control header、拥塞控制、路径选择和部分重传；多 QP 提供 path entropy，默认每 32 KB 合并一次控制决策。关键结果：无拥塞 ConnectX-7 上基本追平硬件 transport；跨机架 CX_ETH all-to-all 最多提高 4.54 倍，真实 16B DeepSeek-V2-Lite 训练 TFLOPS/GPU 最多提高 7.5%，EQDS 将 victim P99.9 FCT 最多降低 4.88 倍。证据边界：物理规模最多 6 台 server，60K QP 只是在 16 块 NIC 上模拟大规模 state，1024 NIC 只来自 packet simulation；默认每 active NIC 多用约 2 个 core，应用集中于 1 MB–1 GB message，DeepSeek-V3 serving 是 trace-driven emulation。
  • UEP-OSDI26 — 核心问题：GPU 必须快速决定 MoE token 路由，但让 GPU 直接操作某一种 NIC 会把系统绑死在 IBGDA/厂商 transport 上。机制：GPU 把 16-byte TransferCmd 写入共享 FIFO，CPU proxy 做地址检查、QP/NIC 选择并发 GPUDirect RDMA；receiver proxy 用 immediate data 和 host counter 修补 EFA SRD 的乱序与无 atomic 语义。关键结果：4-node EFA 上训练相对 NCCL 提高 12%–24%；SGLang 的 prefill-heavy Qwen EP32 为 62K tok/s，NCCL 为 44K，约高 40%；AMD training 的论文口径最高提高 45%，FIFO 可到约 8 Mops。证据边界：45% 结果的 16-node NIC 口径在正文、图注和表格间冲突，不能写成已确认的 16-node Broadcom；DeepEP 无法在 EFA 对比，SGLang 主要是 4,096/5 的 prefill-heavy 请求。系统每 GPU 最多用 4 个 CPU core，尚无 proxy crash、CQ overflow、800G 或 decode-heavy 证据。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
BALBOA-OSDI26可编程 RDMA transport固定 RNIC 难扩展服务FPGA 512-bit pipeline、片上 QP、HBM 重传U55C、ConnectX-5/7、100GbE、最多 32 QP大块 READ/WRITE 达 11.2–11.6 GB/s只实现 RC READ/WRITE 子集；无拥塞和故障实验
FARLock-OSDI26RDMA 锁本地快路径与全局 FCFS 冲突双队列、Peterson 协调、全局 ticket10-node lock microbenchmark、Sherman updatelocal tail 最多低 62 倍；Sherman 最多低 14 倍高争用、旧 FDR；无 failure 和 reader-heavy 结果
Rakaia-OSDI26TCP RPC 调度connection stream 隐藏 message 与服务时间softirq message parser、P2C、stealing20-thread 单机、synthetic、gRPC、Silo相对 KCM 最多 5 倍，gRPC-C++ 最多 2.69 倍CPU-bound；协议、TLS、NUMA 和 parser 安全范围窄
SBB-OSDI26微秒级 runtime中心 timer/dispatcher/monitor 不扩展每核 UINTR、task stealing、flow migration16–48 workers、Memcached、RocksDB、synthetic相同 tail SLO 下吞吐提高 1.7–5.2 倍Intel UINTR；简化网络栈；48 核后已 sublinear
Sepia-OSDI26DDIO 与服务路径 cacheRx page 的 slice/set 冲突浪费 LLCStride-1 coloring、ring/TCP working-set control200G TCP、SPDK NULL target、Nginx、Memcached3.5 core 饱和 200G，Linux 需 6 coreheadline 不是 coloring 单独贡献；单 socket Rx 平台
Svalinn-OSDI26多瓶颈资源控制单入口 AQM 无法表达局部瓶颈全局 utility controller、局部 credit、m_semaphore两平台、Shenango/Go、三应用和合成负载应用 goodput 最高提高 6.51/6.49 倍需人工标注；允许丢执行中请求；无生产 trace
UCCL-Tran-OSDI26GPU 软件 transport固定 RNIC policy 跟不上 ML 流量NIC 搬 payload、host 控制、多 QP、32 KB coalescing4 个小型真实 testbed、训练、serving emulation、模拟all-to-all 最多 4.54 倍，真实训练最多提高 7.5%最多 6 台物理 server；额外 CPU；大消息假设
UEP-OSDI26可移植 MoE P2PGPU-initiated 通信绑定厂商 NICGPU command、CPU proxy、GPUDirect、乱序修补EFA/ConnectX/Broadcom、NVIDIA/AMD、训练与 SGLangSGLang 最多提高 40%，AMD 口径最高 45%平台口径冲突；CPU 成本；无 proxy 故障与 800G

跨论文综合

  • 共同观察：路径控制比裸带宽更容易成为瓶颈。 UCCL-Tran-OSDI26 在无拥塞网络只追平 RNIC、遇到 flow collision 才显著领先；Sepia-OSDI26 的 200G 路径受 LLC set 冲突影响；Rakaia-OSDI26 和 SBB-OSDI26 则受 message visibility 与中心调度线程限制。共同结论不是“软件比硬件快”，而是硬件带宽提升后，控制粒度、状态放置和调度路径决定可用 goodput。
  • 共同观察：系统正在把不可见工作变成显式对象。 FARLock 的 ticket、Rakaia 的 message、Svalinn 的 memory credit、UCCL-Tran 的 chunk、UEP 的 TransferCmd 都让调度器看见原本隐藏在连接、硬件或共享资源里的工作。这个方向依赖抽象与真实成本对应；错误 parser、错误标注或过粗 chunk 会把性能问题变成正确性问题。
  • 共同假设：总有一类“可借用资源”。 UCCL-Tran 和 UEP 假设 host core 有余量，Sepia 假设 LLC/CMA 可控，Svalinn 假设应用能标出资源路径，SBB 假设平台提供 UINTR。多租户环境中这些资源可能同时紧张，需要在同一 CPU、cache、NIC 和内存预算下重测，而不能逐项单独优化。
  • 核心张力：可编程性、可移植性和短控制环很难同时做到最好。 BALBOA 把扩展逻辑放在 FPGA，UCCL-Tran 把控制策略放在主机，UEP 再用主机代理统一不同厂商接口。逻辑越靠近数据面，控制路径通常越短，但升级和验证越难；放到主机更灵活、更容易跨硬件复用，却要付出 CPU、NUMA、调度抖动和代理故障的成本。
  • 核心张力：吞吐优化可能伤害尾延迟或正确性。 Sepia 缩 ring/TCP buffer 可能在高 RTT/burst 下丢吞吐；Svalinn 主动丢弃执行中请求；FARLock 在低争用时多一次 operation；Rakaia 的 kernel parser 和 SBB 的 flow migration 都新增可信代码。需要同时报告 P99.9、drop/retry amplification、CPU/core-hours 和 failure correctness。
  • 后续方向：建立跨 transport 的统一故障与一致性测试。 小团队可在 commodity NIC/VM 上实现 packet loss、reorder、QP reset、proxy crash、parser fuzz、interrupt loss 和 workload phase change campaign，对 BALBOA-OSDI26、UCCL-Tran-OSDI26、UEP-OSDI26 的不同 control placement 做同口径验证。
  • 后续方向：做多资源、带尾延迟约束的自动控制。 把 Svalinn 的局部 controller、Sepia 的 cache working set、SBB 的 CPU stealing 和 UCCL-Tran 的 CPU/NIC cost 放进一个小规模 testbed，用稳定性、P99.9 和资源成本寻找 phase boundary，而不是追单一峰值倍率。

14. 一致性、复制与持久执行（8 篇）

这一组论文都在拆开过去绑在一起的职责：Ambulance 让快速提交与恢复准备同时进行；Bodega 让租约记录每个 key 可由哪些副本回答；Jetpack 把可交换命令的快路径接在原协议旁；libDSE 把执行结果与落盘分开；LogDrive 把日志编号与数据保存分开；WriteGuards 用很小的写入护栏保护缓存。共同收益来自更小、更容易组合的底层能力；难点则转移到恢复、配置和跨 key 操作。

逐篇解读

  • Ambulance-OSDI26 — 核心问题：BFT 用固定 timeout 判断 leader slowdown，短 timeout 会误切换，长 timeout 又让请求持续等待。机制：leader 同时走两轮通信的 sports-car lane，所有 replica 走三轮的 truck lane；系统根据协议进度而不是墙上时钟进入恢复，并用持久化 lane 证明跨 view 安全。关键结果：n=4 正常路径与 Autobahn 都约 214k tx/s、205/203 ms；10 秒单 replica sleep 时峰值 latency 最多低 10.8 倍。40-replica、20-region 的 24 小时部署中 median 几乎相同，P99 从 1.27 s 降到 662 ms。证据边界：受控注入只有一个 replica sleep，最大倍率高度依赖 Autobahn timeout；没有 correlated/Byzantine-selective slowdown、loss/reorder、crash/restart 或大 n control-message 成本，生产证据也只有单日。
  • Bodega-OSDI26 — 核心问题：leader lease 只能本地读，quorum lease 又会被冲突写频繁撤销，WAN 下本地读覆盖不足。机制：lease 保护“哪些 replica 可以回答哪些 key”的 responder roster；写提交前必须到达该 key 的全部 responder，roster 变化通过租约到期或显式切换完成。关键结果：五站点 WAN 的中等写入干扰下，平均读延迟比既有方案低 5.6–13.1 倍；10% 写入时吞吐上限约 6k ops/s，Quorum Leases 约 3.4k。显式健康切换约 75 ms。证据边界：只证明非事务单 key；杀死 responder 后要约 1.1 s 检测再等约 2.6 s lease 到期。YCSB 中 ZooKeeper/etcd 对照语义更弱，不能当作同保证胜出；没有大 roster、长期分区和跨 key snapshot。
  • Jaber-S3Conformance-OSDI26 — 核心问题：S3 API 状态、参数和值域巨大，手写 unit/integration test 很难覆盖所有可观察组合。机制：AWS 把服务行为写成有状态 Java 参考模型，用谓词抽象把无限值域变成可计数 scenario，再自动准备前置状态、发请求并逐字段比对；campaign 用 first-error 等规则控制组合数。关键结果：S3 Express 上线、frontend 重写和持续 CI/CD 三个项目共发现 372 个偏差，其中 46 个高严重度，全部在生产前处理；随机 PBT 的 28,457 个请求中约 68% 落在重复 scenario。证据边界：coverage 只相对于人工谓词和 campaign；不覆盖并发 history、一致性、durability、性能或故障恢复。生产模型、误报漏报、维护人时与 escaped regression 都未公开，随机 PBT 对照也较弱。
  • Jetpack-OSDI26 — 核心问题：1-RTT fast consensus 往往要求重写复制协议，已有生产系统很难采用；快路径还必须在换主后保持安全。机制：Jetpack 不改原协议，而是在旁边并行提交可交换命令；shim 检查冲突，原协议提供 fallback，恢复流程把快路径证据纳入换主。作者为 Raft、Copilot、Mencius、MongoDB、etcd、ZooKeeper 分别建 TLA+ 模型。关键结果：在 10 个 AWS 数据中心中，平均提交延迟对五个主要系统降低 39.06%–63.90%；Jetpack-Raft 低载延迟接近 CURP/SwiftPaxos/EPaxos，饱和后自适应关闭快路径并回到原系统吞吐。证据边界：收益随冲突和 geography 下降，Mencius 只有 18.87% 请求真正受益；不支持 BFT、交互事务和动态 membership。六个 adapter 的原协议改动很小，但没有计算 shim、冲突函数和恢复验证的全部成本。
  • libDSE-OSDI26 — 核心问题：持久 workflow 每层都同步落盘时，group commit 延迟会沿深度累加。机制：服务可先发送尚未持久化的推测结果；recovery dependency graph、原子 action、轻量 sthread 与对外 barrier 决定哪些状态一起提交或回滚。关键结果：10-service TravelReservations 中 p95 少于约 70 ms，关闭推测约 480 ms、Temporal 约 1 s；EventProcessing 在 500 ms persistence window 下 p95 约 1.0 s，非推测约 8.2 s，写入从约 1,200 MB 降到 60 MB。证据边界：规模只有 10 个工作节点、coordinator 到 64 services；自动 gRPC interceptor 在饱和时损失约 25% 吞吐。安全/活性只有 sketch，开发者要正确封装状态和 fencing，外部副作用密集时 barrier 会吃掉收益。
  • LogDrive-OSDI26 — 核心问题：传统 shared-log append 同时决定位置并保存数据，两个 backend 会给同一 entry 不同位置，因此无法像 RAID 一样 striping、quorum 和在线切换。机制：底层只提供 single-value address 与弱 weakTail(K)；soft-state sequencer 和 K-window AtomicLog 在其上恢复 linearizable log，Striped/Quorum wrapper 可组合 S3、DynamoDB、S3Express。关键结果：K2 生产 deployment 持续约 9 GB/s produce、27 GB/s fetch；2K write/s、6K read/s 模型中 metadata cost 从 7.20 降到 0.69 美元/小时，总成本从 9.57 降到 3.06 美元/小时。证据边界：成本结论依赖 5 倍 compression、100 ms batching、指定价格和假想 direct-DynamoDB strawman，并伴随约 6.5 倍 write P99 slowdown。安全依赖 single-value address 与正确小 K，sequencer 本身不高可用，相关故障审计未公开。
  • Pompe-SRO-OSDI26 — 核心问题：共识即使满足 safety 和 ordering linearizability，也可能让网络位置更好的客户端稳定抢先，形成交易排序不公平。机制：论文定义 ε-Ordering Equality 与 Δ-Ordering Separation，用 TEE 或 threshold VRF 产生秘密随机延迟，改造 Pompe 的排序结果而不公开未来随机数。关键结果：2 s random window 下四组城市请求的最坏双请求偏差降到 0.10，即约 55% 对 45%；12-process 跨城市 emulation 中吞吐为 1,893 cmd/s，Pompe 为 1,842 cmd/s。证据边界：P50/P99 延迟增加到 Pompe 的 1.12–1.42 倍，P99-P50 差约 1.7–1.8 s；实验是 12 台机器模拟 80-node stake，关闭 batching。TVRF 没进端到端路径，公平定理量词、adaptive delay、membership 与真实 MEV 都未闭合。
  • WriteGuards-OSDI26 — 核心问题：强一致 cache 要么每次读回 storage 验证，要么容易被延迟写和 owner 迁移破坏 linearizability。机制：storage 按 key range 保存当前 owner 的不透明 guard token，并拒绝旧 token 写；CLINK、CRINK-R/L 在内存或远端 cache 回答读，reshard 时先更新 guard 再转移 owner。关键结果：三组生产 trace 中 CLINK P90 为 0.5–4.2 µs，direct storage 为 4.8–10.3 ms；24 cores 达 22.8 M QPS，0.5% traffic churn 下 assignment 少于 20 ms 调整。证据边界：只在 TiDB/TiKV 架构实现；单 hot key 在 P99/P90/P50 约 80/200/400 write QPS 时命中崩塌并回到毫秒级 storage latency。跨 key transaction、tablet split/partition、legacy writer 绕过 guard 和 cross-DC ownership 都未验证。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
Ambulance-OSDI26BFT slowdown 恢复timeout 在误切换与久等间冲突双 lane 并行、progress-based recoveryn=4 故障注入、40-replica 一日部署10 秒暂停峰值延迟最多低 10.8 倍单节点 sleep；倍率依 timeout；缺组合故障
Bodega-OSDI26WAN linearizable readlease 覆盖与写干扰冲突per-key responder roster、写前覆盖五站点 WAN、YCSB、故障切换、TLA+读延迟低 5.6–13.1 倍，吞吐约 6k ops/s单 key；节点故障要等 lease；语义不等价基线
Jaber-S3Conformance-OSDI26云 API 一致性测试巨大有状态行为空间参考模型、谓词抽象、scenario 生成三个 S3 项目和 CI/CD上线前发现 372 个偏差、46 个高严重度仅顺序功能；coverage 依赖人工谓词；闭源证据
Jetpack-OSDI26可插拔共识快路径快协议难接入已有系统commutativity shim、1-RTT 并行快路径、fallback六协议、10 AWS DC、TLA+五系统平均延迟降低 39.06%–63.90%冲突时收益降；无 BFT、事务、动态成员
libDSE-OSDI26持久推测执行每层同步 persistence 累加延迟recovery dependency、action、sthread、barrier三应用、10 节点、故障注入深 workflow p95 从约 480 ms 降到少于 70 ms应用改造重；gRPC 最高损失 25%；证明是 sketch
LogDrive-OSDI26可组合 shared logappend 位置与数据保存绑定single-value address、weakTail(K)、AtomicLog多 backend、K2 生产、成本模型生产 9/27 GB/s produce/fetch；模型总成本低 3.13 倍写 P99 慢 6.5 倍；成本和 K 假设强
Pompe-SRO-OSDI26共识排序公平网络地理优势造成稳定抢先ε/Δ 公平定义、秘密随机预言机12 城市 emulation、TEE/TVRF microbenchmark2 s 窗口最坏偏差降到 0.10延迟增加；TVRF 未端到端；真实 MEV 未覆盖
WriteGuards-OSDI26线性一致 cache延迟写和 owner 迁移破坏 cacherange guard token、旧写拒绝、reshard fencingTiDB/TiKV、三 trace、hot-key 与 churnCLINK P90 0.5–4.2 µs，24 core 达 22.8 M QPS单 hot key 写频繁时退化；仅一种 storage 架构

跨论文综合

  • 共同观察：正常路径可以很短，恢复路径才决定系统是否可信。 Ambulance 的 sports-car lane、Jetpack 的 1-RTT path、libDSE 的 speculative action、WriteGuards 的内存读都能缩短 common case，但每篇都必须额外定义跨 view、rollback、owner change 或 fencing。只比较无故障平均延迟会遗漏最难的协议状态。
  • 共同观察：小而弱的 primitive 可以支撑更强语义。 LogDrive 只要求 single-value address 与 weakTail(K)，WriteGuards 只要求 range guard，Bodega 只把 responder-covering 写进 lease。它们以更小存储接口换可组合性，但 correctness 依赖的前提也更集中，一旦 K、owner 或 roster 配错就可能静默破坏安全。
  • 共同假设：操作能被准确分类。 Jetpack 要知道哪些命令 commute，Jaber 要人工定义 predicates，Bodega 与 WriteGuards 假设 key/range 边界准确，libDSE 要识别不可回滚外部效果。分类错误不是普通性能退化，而可能是 safety bug。
  • 核心张力：一致性、可用性、延迟和公平是不同轴。 Bodega/WriteGuards 优化线性一致读，Ambulance 优化 slowdown 下活性，Pompe-SRO 加入 ordering fairness，LogDrive 优化成本与 backend 组合。Pompe-SRO 的随机等待和 LogDrive 的 batching 都表明，增加新语义往往要付尾延迟。
  • 后续方向：把模型检查与真实 fault campaign 接起来。 小团队可以为 Ambulance-OSDI26、Bodega-OSDI26、Jetpack-OSDI26、WriteGuards-OSDI26 建统一 history checker，注入 pause、partition、stale packet、membership change、owner crash 和 delayed write，把 model counterexample 自动转成实现测试。
  • 后续方向：验证跨 key 和外部副作用。 现有证据多停在 single key、commutative command 或可回滚内部 state。应以两到四个 key 的 transaction、不可撤销消息/支付和 tablet migration 为最小 benchmark，量化 barrier、roster、guard 与快路径的组合成本。
  • 后续方向：让配置前提可机检。 对 LogDrive 的 K、Jaber 的 predicate、Jetpack 的冲突函数和 WriteGuards 的 writer capability 生成运行时 assertion 与 fail-closed 检查，比继续增加正常路径 microbenchmark 更能降低真实部署风险。

15. 安全、隐私与形式验证（8 篇）

这一组论文不试图用一种机制保护所有行为，而是主动缩小可信或验证范围：Acumen 让新成员验证快照而不拿到完整历史，Mohabi 隔离整个 JS 引擎，Osprey 只利用“密文访问不随内容变化”的区域，Spain 接受有界数值误差，USEC 只保护管理员声明的资源，uUSB 只重放录制过的设备路径，ZENO 只把明文映射放入 TEE。这样才能把性能控制在可用范围内，但覆盖是否完整、标注是否正确、策略是否遗漏以及升级后是否仍兼容，也随之成为安全边界。

逐篇解读

  • Acumen-OSDI26 — 核心问题：不可信 relay 和恶意协作者环境中，新成员既要验证 snapshot 来自合法协作历史，又不应拿到已删除内容或完整明文历史。机制：history hash、签名 state descriptor、Merkle accumulator 与 placeholder 证明 fork-causal consistency；因果稳定后做二阶 GC，删除 history 但保留可验证摘要。关键结果：25 用户 round-trip 为 2.7 ms，network-only 为 1.5 ms；local insert/delete 保持约 0.29–0.44 ms，90% deletion 时 snapshot size 可比 Snapdoc 小约三个数量级。证据边界：snapshot sweep 只到 1,000 operations、10 users，network 最多 25 users；fork 被发现后永久分裂，没有 reconciliation、归责或 safe rejoin。离线/恶意 member 可阻止 GC，DoS 和 timing leakage 不在保证内。
  • Mohabi-OSDI26 — 核心问题：浏览器 JS engine 同时包含 interpreter、JIT、runtime 和 GC，漏洞可直接破坏 Firefox；只沙箱 JIT 又覆盖不足，禁用 JIT 则代价太高。机制：Mohabi 用 MH-LFI 把整个 SpiderMonkey 划进 256 GiB software fault isolation domain，提供 forward/backward CFI、store masking、syscall mediation 和动态 JIT code validation。关键结果：Firefox 的 JetStream 2.2 和 Speedometer 3.1 分别慢 24.82% 和 24.43%，而禁用 JIT 的消融慢 53%；SPEC CPU 子集的 large-memory write-only SFI 平均开销 5.9%。证据边界：只评 x86-64、Firefox ESR 115 和单机 benchmark；完整 JSAPI 边界 sanitizer 尚未覆盖，也没有真实 exploit replay或形式化 validator/并发 dual-mapping 证明。write-only SFI 不防读泄漏、侧信道、DoS 和合法 API 滥用。
  • NeuroSymbolicProof-OSDI26 — 核心问题：seL4 这类大型 Isabelle 证明库高度依赖人工 tactic、premise 与长搜索，通用 LLM 直接生成成功率低。机制：从 181,887 个 proof-state/next-step pair 微调小模型，以 tree search 生成 tactic，Isabelle 执行与 revision 修复，QuickCheck/Nitpick/等价检查剪枝，最后用 Sledgehammer 收尾。关键结果：表 1 按作者口径报告 Mistral 版本 77.6%、Hammer 40.3%；200-theorem 消融中，DeepSeek tree search 为 12.5%，加 RAG 为 33.0%，再加 Hammer 为 52.0%；四个外部 benchmark 为 22.6%–65.1%。证据边界：success count、rate、split denominator、692 failures 和 120 分钟上限/139.1 分钟平均耗时互相不能完全复算。任务只为给定 theorem 找 proof，不生成 specification/invariant；主要仍是 seL4 ecosystem，长 proof 成功率明显下降，GPU 与总成本也未报告。
  • Osprey-OSDI26 — 核心问题：安全计算的 working set 可达 73–192 GB，32 GB 内存下 Linux swap 无法预知未来访问，手工 MAGE schedule 又要求重写应用。机制：利用密文内容无关性，让低成本 speculative process 提前执行并输出 page trace，真实进程据此异步 swap；eBPF、共享队列和 OSPREY_TOUCH 补全动态路径。关键结果：8 个 CKKS/garbled-circuit kernel 中相对 Linux swapping 最多加速 12 倍，四线程最多 16 倍；6 个 workload 的时间不超过 unbounded-memory 的 1.6 倍，每应用线程 CPU 最多降低 45%。证据边界：正确性依赖开发者只把真正 content-oblivious 数据放进 CO region，当前没有自动验证。实现依赖 Linux 5.15、eBPF、内核模块和 Intel MPK；一个细粒度库 workload 被排除，8 个固定 kernel 不能代表所有 secure computation。
  • Spain-OSDI26 — 核心问题：把浮点程序逐位编码进 R1CS 会产生巨大约束，而许多数值程序本就允许有界近似误差。机制：Spain 在有理数上定义 approximate R1CS，用新的证明后端直接验证误差界，避免 IEEE-754 bit-level 模拟，并通过 batching 摊 verifier/setup 成本。关键结果：LP、ML、GPT-2、fluid 和 geolocation 上约束数减少 32–17,000 倍，通用 prover 加速 8–2,700 倍；最大 LP 实例 verifier 为 30 ms，原生重算为 300 ms。证据边界：多数非 LP benchmark 的 prover 仍比原生慢约 1,500–120,000 倍；最大 GPT-2 batch verifier 79 s，但 prover 3.3 h、内存最高约 267 GB。当前主要保证 absolute error，不完整支持 relative error、IEEE exception、zero knowledge 与 non-interactivity，精度参数还需人工分析。
  • USEC-OSDI26 — 核心问题：安全产品只保护少量高价值资源，但 SELinux 要在大量 type、attribute、hook 中表达政策，配置长且 runtime 每次都经过宽泛检查。机制：USEC 用 resource-centric JSON 描述 subject、resource 和 operation，从 capability 编译需要的 LSM hook；bitmap 与 unified AVC 跳过无关检查，并可导入部分 SELinux policy。关键结果：camera 案例从 SELinux 300 多行降到两份合计少于 20 行 JSON；Nginx 为 92,185 req/s，SELinux 为 84,748；论文报告已被 210 多家厂商、800 万 enterprise endpoints 采用。证据边界：未声明资源不会 fail closed，采用规模不是攻击阻断效果。性能只在 Linux 4.19/UOS 单台笔记本；兼容性只有两个案例，没有 allow/deny 等价、策略热更新 stale allow 或真实漏拦截率。
  • uUSB-OSDI26 — 核心问题：把完整 Linux USB driver 放进 TEE 会扩大 TCB，重写可信 driver 又难覆盖 MMIO、DMA、IRQ 和设备状态机。机制：从可信 gold driver 的多次变异执行记录 I/O trace，离线做 differential analysis 和 qualified taint，把单一功能提升为模板，再在 TrustZone 内严格重放已记录路径。关键结果：在 Raspberry Pi 5 上为 4 类、6 款设备生成 8 个模板，executable 为 15–400 KB，相对 native module 小 12–116 倍；storage/audio/video/HID 多数接近或优于 native，模板经过两周 stress，camera+storage 组合连续运行超过一天。证据边界：安全和正确性只覆盖 gold driver 在可信录制环境走过的路径；没有 malicious USB emulator、malformed descriptor、hotplug/stall/reset campaign 或形式化 coverage。设备、firmware、USB speed 与复用范围都很窄。
  • ZENO-OSDI26 — 核心问题：encrypted DB 在每个中间值上反复 decrypt/compute/encrypt，密文膨胀、查表和 enclave crossing 会压垮查询。机制：不可信 PostgreSQL 只保存与明文无关的 64-bit FID，隐私 TEE 用紧凑数组 O(1) 定位明文；mapping block 和 WAL 仍加密，布局分区与 cache 减少 enclave I/O。关键结果：TPC-H 相对 HEDB 在 ARM/x86 TEE 平均快 4.4/5.3 倍，单 query 最高 53.1/94.7 倍；空间少 38.9%–52.8%，mapping WAL 使 TPC-C TPS 仅下降 2.6%。证据边界：系统明确泄露访问与布局信息，不提供 obliviousness 或 side-channel 防护；只测单机 PostgreSQL，工业 schema 用每表 100 万行合成数据。replication、PITR、schema migration、长期 GC 和多种 crash point 尚未验证。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
Acumen-OSDI26隐私协作 snapshot验证状态而不泄露删除历史history hash、Merkle accumulator、placeholder、GClocal trace、snapshot sweep、最多 25 用户25 用户 round-trip 2.7 ms；高删除 snapshot 小约三个数量级snapshot 仅 1K 操作；fork 不修复；离线成员阻塞 GC
Mohabi-OSDI26浏览器 SFI完整 JS engine 隔离与 JIT 性能冲突256 GiB MH-LFI、CFI、mask、JIT validatorFirefox benchmark、SPEC 子集、安全分析完整浏览器开销约 24%x86 单版本；JSAPI 边界未闭合；无真实 exploit
NeuroSymbolicProof-OSDI26神经符号形式证明大型 Isabelle proof 搜索难微调 tactic model、tree search、RAG、Isabelle/HammerseL4 splits、四外部 benchmark、消融表 1 口径 77.6%，Hammer 40.3%数字分母与时间口径不一致；不生成 specification
Osprey-OSDI26安全计算内存管理content-oblivious 程序 swap 无前瞻speculative trace、异步 swap、eBPF/MPK8 个 73–192 GB kernel、32 GB limit相对 Linux 最多 12 倍，四线程最多 16 倍CO 标注未自动验证；特定 Linux/Intel；负载范围窄
Spain-OSDI26近似可验证计算浮点 bit-level proof 约束过大rational approximate R1CS、新 proof backend、batchLP、ML、GPT-2、fluid、H3约束少 32–17,000 倍，prover 快 8–2,700 倍多数仍远慢原生；保证和功能不完整；人工精度参数
USEC-OSDI26资源中心 LSM宽泛 MAC policy 复杂且检查多capability JSON、hook 编译、bitmap/UAVCpolicy 案例、UnixBench/Filebench/Nginx、部署Nginx 92,185 req/s；800 万 endpoint 采用资源遗漏不 fail closed；旧 kernel 单机；缺攻击效果
uUSB-OSDI26TEE 设备驱动最小化完整 driver TCB 过大gold-driver trace、差分提升、FSM 模板重放Pi 5、4 类 6 设备 8 模板、stress15–400 KB 模板，多数性能近 native只保证已录路径；无 malicious-device fuzz 与广泛兼容
ZENO-OSDI26TEE 数据库中间密文反复变换和膨胀64-bit FID、TEE 数组 mapping、encrypted WALPostgreSQL、TPC-C/H、合成工业 schemaTPC-H 平均快 4.4/5.3 倍泄露访问模式；单机；无 replication/PITR/长期 GC

跨论文综合

  • 共同观察：缩小可信范围比加固整个通用栈更容易落地。 Mohabi 隔离 SpiderMonkey，uUSB 只保留录制过的功能路径，USEC 只编译声明过的资源，ZENO 只把映射和明文放进 TEE，Spain 只证明带误差界的数值关系。性能来自缩小范围，但系统必须清楚说明未覆盖行为会怎样处理：uUSB 遇到模板外状态会停止，USEC 对未声明资源却不会默认拒绝。因此，“代码更少”不能直接等同于“安全更完整”。
  • 共同观察：coverage 已成为安全属性的一部分。 Acumen 的 causal stability、Osprey 的 CO region、USEC 的 resource inventory、uUSB 的 trace path、NeuroSymbolicProof 的 library context 都决定机制看得到什么。当前多数论文报告 benchmark 成功，却没有把未覆盖状态做成可检查 artifact。
  • 共同假设：可信输入和标注正确。 Osprey 信任 CO annotation，uUSB 信任 gold driver 和录制环境，USEC 信任管理员列全资源，Spain 信任误差参数，NeuroSymbolicProof 信任 theorem 与 imported assumptions。错误输入会使证明或隔离“在错误问题上正确”。
  • 核心张力：通用性与可验证性相互拉扯。 Mohabi 选择完整 JS engine、付约 24% 开销；uUSB 选择窄功能模板、覆盖更小；Spain 放宽数值语义换巨大 proof 缩减；ZENO 接受访问模式泄露换实用数据库速度。综述不能用一个“更安全”排序覆盖这些不同 threat model。
  • 后续方向：把 coverage manifest 变成第一等输出。 小团队可为 Osprey-OSDI26、USEC-OSDI26、uUSB-OSDI26 开发共同格式，列出受保护 object、允许 path、未覆盖 branch、版本与 fail-closed 行为，并用 mutation/fuzz campaign 验证 manifest 与执行一致。
  • 后续方向：做 adversarial upgrade 和 lifecycle 测试。 真实风险常来自 browser/driver/kernel/DB schema 更新。应跨版本重放 exploit、malformed device、policy alias、WAL crash 和 key rotation，测规则/模板/validator 是否自动拒绝不兼容更新。
  • 后续方向：统一报告性能、近似误差和信息泄漏。 Spain 应把证明开销与允许的误差界一起报告；ZENO 应同时报告访问模式泄漏；Acumen 应明确编辑时间、快照结构和旧成员串通等隐私边界。不要只用平均加速或空间节省掩盖这些代价。

16. 程序分析、测试与开发工具（8 篇）

这一组论文都先划出一个清楚的工作边界来降低分析难度：微服务按 RPC 和数据库操作分析，shell 按命令和数据流分析，调度器按离散事件分析，Web 应用按处理函数和查询点分析，C/C++ 按用户指定的函数范围分析。边界越清楚，静态分析、推测执行、增量重放、确定性测试和动态分析越容易落地；但边界外的副作用、并发、人工标注和不完整模型仍会带来误报、漏报或错误复用。

逐篇解读

  • Aletheia-OSDI26 — 核心问题：微服务把原本由单数据库约束的数据拆到多个异构 datastore 后，referential/entity/uniqueness integrity 只能靠分散的应用代码维持。机制：Aletheia 把五类危险 operation pattern 编译成 Go SSA taint 和抽象调用图分析，沿 RPC 与 datastore invocation 追踪 key/value 关系。关键结果：七个应用上得到 81% precision、69% recall；50 个 true positive 中，46 个此前未报告。真实应用均在 4 秒内分析完。证据边界：22 个 false negative 中，8 个来自非 key filter、14 个来自跨请求关联；12 个 false positive 来自业务语义和过度 taint。部分应用经 Blueprint 移植或补 endpoint。扩展实验来自 synthetic stub：500-service 案例峰值约 10.08 GB；最大 2,887-call-graph 案例只有 50 services，峰值约 11.32 GB。
  • hS-OSDI26 — 核心问题：shell command 内部不透明，静态方法难知道依赖，保守顺序执行又浪费独立任务并行。机制：hS 把未来命令放在隔离环境推测执行，运行时跟踪文件读写，若依赖已满足就提交，否则丢弃并重跑；同一机制也用于受限 Python 前端。关键结果：49 个真实 shell script 相对 Bash 几何平均加速 2.6 倍、最高 9.3 倍；对 9 个已手工并行的脚本仍平均快 1.5 倍。证据边界：7 个脚本反而变慢，误推测平均浪费 17% command time，每命令固定开销约 217 ms，小文件 workload 可慢 6.2–7.2 倍。IPC、signal、设备、NFS、GPU ioctl 和不可回滚外部效果不在精确模型内。
  • Incr-OSDI26 — 核心问题：shell 开发流程每次小改动都全量重跑，现有 build system 又要求人工声明依赖与缓存语义。机制：INCR 从系统调用、环境与隔离文件系统自动推断 effect，缓存并重放 stdout/stderr、exit code 和文件副作用；streaming eager execution、compaction 和可选 annotation 控制缓存成本。关键结果：85 次修改中 69 次加速；只在这 69 次中平均快 34.2 倍、最高 373.3 倍。Bash suite 输出匹配 10,279/10,282 行。证据边界：另 16 次平均只有 Bash/INCR=0.73，即明显变慢；首次执行平均约为 Bash 的 2.01 倍，cache 平均为原输入 6.05 倍。network、clock、entropy、daemon、IPC 与隐藏硬件状态不在默认安全 effect model，19 个 parser-error case 被排除。
  • kSTEP-OSDI26 — 核心问题：Linux scheduler bug 常不 panic、不报错，又依赖 task、CPU、tick 和 cgroup 的精确交错，普通 workload 难以确定性重现。机制：kSTEP 把用户任务、内核事件、CPU 属性和 scheduler tick 做成可编程 event，driver 明确安排次序，trace 对比触发前后状态；fuzzer 在同一 event space 搜索。关键结果：7 个历史 bug 都有不超过 20 events、47 LoC 的手写 reproducer，并都能在数秒内运行；手写 driver 和 fuzzer 又找到 4 个新 bug。证据边界：driver 按顺序发出事件，不能直接覆盖 scheduler 内部的并发缺陷；7 个案例不代表 232 个历史缺陷。案例都在 QEMU 中运行，拓扑和 CPU capacity 等硬件属性也是模拟的；fuzzer 的判错条件仍靠人工编写，20K-task 案例在 24 小时内没有触发。
  • Ote-OSDI26 — 核心问题：从 Rails 应用自动抽取 SQL access-control policy 会遭遇路径爆炸、动态 query 和大量与 SQL 无关的分支。机制：Ote 用有界 concolic execution 记录“路径条件—SQL”，把复杂 SQL 近似成可化简 view；LLM judge 只判断分支与 SQL relevance，人工审核所有 irrelevant verdict，最终将 view 交给 Blockaid 类 enforcement。关键结果：三个应用的 18 个选定 handler 在 59 分钟至 4.7 小时内生成 24–144 个 view；最大 handler 将 391,621 个 conditioned query 化简为 1,592 个，再 pruning 到 138 个，并发现多项手写 policy 宽松或过严的问题。证据边界：只分析明确选定的 18 个 handler，没有 coverage 或最紧 policy 保证；仍需 9–63 条人工业务 invariant 和额外的缩小范围约束。作者只逐一确认了五个 handler 中的 635 个 irrelevant verdict，不能据此推断其他判断或未见应用的准确率；数据库每张表最多只有 2 个 symbolic row。
  • RT-OSDI26 — 核心问题：shell pipeline 的上游可能输出不符合下游安全输入语言的行，传统 shell checker 不理解 stream 内容。机制：RT 用正则语言描述 command 输入/输出，以 language inclusion 检查组合；多态类型、有限状态 transducer、环境具体化、heuristic 与 annotation 提高精度并生成 witness。关键结果：730 个 correct、224 个 buggy 程序上，无 annotation 总准确率 91%，correct 96%、buggy 72%；加 annotation 后总准确率 97%，buggy 94%，平均分析 0.020 s。证据边界：无 annotation 时仍漏 63 个 bug，49 个来自缺输出规格；command database 只覆盖 71/106 coreutils 和 GitHub 中 86% invocation，未知命令默认宽泛。正则语言不表达跨行结构、side effect 或完整 shell control semantics。
  • Try-OSDI26 — 核心问题：运行不透明命令前很难知道文件副作用，传统 dry-run 不完整，Docker 又复制和启动过重。机制：try 用 user/PID namespace 与 OverlayFS semisolate，把修改保留在 upper layer，用户可隐藏资源、审查、选择提交或丢弃。关键结果：25 个 benchmark 中，所有 try -y 结果的输出和文件副作用，都通过人工检查或整棵文件树 checksum 确认与直接执行一致；相对直接执行慢 1.0–8.3 倍，但比 Docker 快 1.1–225.7 倍；危险 pre-commit hook 案例最多只慢 1.3 倍。证据边界：它只防日常误操作，不是 malicious-code sandbox；远端 API、数据库、设备和任意 IPC 不可回滚。选择提交不是原子事务，空 echo 固定约 165 ms，10,000 个小文件仅扫描 upper directory 就需 6.3 s。
  • UCSan-OSDI26 — 核心问题：KLEE/Angr 解释整个程序太慢，而直接运行用户指定 C/C++ function 又会遇到未初始化指针和欠约束外部对象。机制：UCSan 将选定 function scope 编译成用户态程序，用伪指针、shadow metadata 和即时初始化补对象，再把 native execution 接入 fuzzing/concolic exploration。关键结果：UBITect 任务中可分析的 66,999 项完成 63,957 项，即 95.46%，KLEE-IL 完成率 41.29%；表内平均 time-to-finish 为 14.37 s 对 105.71 s。Linux 5.10/6.16 分别成功编译 96.2%/88.9% scope。证据边界：论文正文的 6.36/15.06 倍与表中时间不能完全复算，应引用原始时间。scope 与外部函数模型会造成 false positive，当前不支持循环对象图、并发、多入口状态和大量 inline assembly；大 TCP scope 只覆盖 16.1%。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
Aletheia-OSDI26微服务数据完整性分析跨 datastore constraint 落到应用代码SSA taint、抽象调用图、五类 operation pattern7 个应用、synthetic 500-service81% precision、69% recall，46 个新问题人工 ground truth；框架/语言窄；synthetic 扩展
hS-OSDI26shell 推测并行不透明 command 隐藏依赖隔离推测、动态读写依赖、commit/replay49 个脚本、受限 Python相对 Bash 几何平均 2.6 倍7 个变慢；217 ms/command；外部效果不完整
Incr-OSDI26shell 增量执行小修改仍全量重跑effect inference、stream/effect cache、compaction14 场景、85 次修改、Bash suite69 个加速案例平均快 34.2 倍16 个减速；首次约 2.01 倍；cache 平均 6.05 倍
kSTEP-OSDI26scheduler 确定性测试隐性 bug 依赖精确事件序列可控 task/CPU/tick/event、trace、fuzzer7 个历史 bug、4 个新 bug历史 bug 最多 20 events、47 LoCdriver 事件串行；7 个案例均在 QEMU；硬件行为不是实机验证
Ote-OSDI26SQL policy 抽取concolic 路径爆炸和无关分支conditioned query、view 化简、LLM relevance pruning3 Rails 应用、18 handler59 分钟至 4.7 小时生成 24–144 view无 coverage；人工 invariant/审计；合成 DB state
RT-OSDI26shell stream 类型pipeline 上下游语言不匹配正则语言 inclusion、多态、FST、annotation954 程序无标注 91%，有标注 97%buggy 无标注仅 72%；command DB 与语义不全
Try-OSDI26可审查命令副作用dry-run 不完整、容器太重namespace、OverlayFS semisolate、选择提交25 benchmark、五类用例文件副作用一致；比 Docker 快 1.1–225.7 倍比直接运行慢；不防恶意；commit 非原子
UCSan-OSDI26欠约束动态分析全程序解释慢、局部函数缺对象scope 编译、伪指针、shadow、即时初始化Linux scope、UBITect、CVE、kernel bug完成率 95.46%，KLEE-IL 41.29%scope/model 决定结果；无循环对象、并发和多入口

跨论文综合

  • 共同观察：合适的边界比更强的全程序分析更重要。 Aletheia 选 RPC/datastore operation，hS/Incr/Try 选 command，kSTEP 选 scheduler event，Ote 选 handler/query，UCSan 选 function scope。边界让工具可运行，也决定它看不见哪些状态。
  • 共同观察：推测和缓存都需要准确的 effect model。 hS 推测未来 command，Incr 重放历史 effect，Try 暂存副作用，Ote 跳过无关 path。错误 effect 可能造成错误结果或安全遗漏；过于保守则退化成重跑、拒绝或无加速。
  • 共同假设：人工知识可以控制在可接受范围。 RT 依赖 command type/annotation，Ote 依赖 invariant 与 LLM verdict 审查，kSTEP 依赖 event driver/invariant，UCSan 依赖 scope 和外部模型。论文通常报告运行时间，很少报告开发、审查和长期维护人时。
  • 核心张力：soundness、coverage 与实用性难同时最大化。 Aletheia 81% precision/69% recall、RT 无标注 buggy 72%、Ote 没有 coverage、UCSan 大 scope coverage 16.1%，都说明减少误报和提高速度会留下漏报空间。总准确率或平均 speedup 不能代替分类型错误统计。
  • 后续方向：统一描述副作用和分析边界。 小团队可以为 shell、Web handler 和函数范围设计一份共同清单，列出会读写什么，是否使用网络、时间和随机数，能否回滚，哪些外部函数未知，以及实际覆盖了多少。hS、Incr、Try 可据此判断能否安全执行，Ote、UCSan 可把它写进分析报告。
  • 后续方向：把 concurrency 变成最小必测维度。 kSTEP、Try、UCSan 与 Ote 都缺强并发模型。可先从 bounded two-thread/two-request interleaving 开始，报告状态数、误报漏报、运行时间和能否复现历史 race，而不是直接追全内核并发。
  • 后续方向：用累计开发时间评估工具。 对 20–50 个真实修改 session 记录 annotation、scope、model、warning triage、cache 空间和首次运行成本，比较“总节省人时”而不只比较单次 execution speedup。

17. 云资源管理与生产运维（8 篇）

这一组既包含 Azure、Alibaba、Meta 和 Ant Group 的长期生产系统，也包含 SPADE 这样的原型和仿真研究。它们共同面对资源和信号的不确定性：CoreSec 允许“不归因”，DVLA 记录并偿还放置债务，PIMS 用统一约定管理故障域容量，PowerSight 给功率预测留安全余量，SPADE 只延迟价值较低的任务。生产规模提高了现实性，但许多结果仍来自上线前后对比、模型回放或反事实估计，不能直接当成严格因果证据。

逐篇解读

  • CoreSec-OSDI26 — 核心问题：大型 Clos fabric 永远有异常 counter 和缺失 telemetry，weighted voting 即使证据冲突也强选根因，长期产生错误 mitigation。机制：借鉴 PAM 的 requisite/required/sufficient/optional flag 组合 agent，规则不满足时明确 abstain，再用 topology dominance 把低层证据向上归并。关键结果：三年 712,345 个 incident 中，false positive 从历史 baseline 的 18%–22% 降至少于 1%，最近六个月约 98.5% 自动归因、1.5% abstain；约 99% 在两次 5-minute rerun 内稳定。证据边界：这是系统上线前后不同时期比较，postmortem 非盲，期间 telemetry/agent 也演进；高层 T1/T2/cluster 根因只占 2%。内部数据不可复现，完整 flag stack 与 multi-fault/stale agent 还没有 model checking。
  • DiTing-OSDI26 — 核心问题：百万节点 observability 全集中到 AZ 会造成高 CapEx 与 query bottleneck，而节点本地又有大量闲置 CPU、DRAM 和 disk。机制：node agent 保存近期 co-Log 并执行大部分 local query，AZ 层保存长期数据和 failover；metrics、logs、traces 用 SQL 与 metadata mapping 统一查询。关键结果：系统已部署超过 100 万节点；50/400-node production test 中 QPS 比匿名内部方案高 4–9 倍，latency 为其四分之一到十分之一；财务模型总 CapEx 低约 3–65 倍，60K-node global query 约 0.8 s。证据边界：harvested node 资源已由业务购买，未计入 Type-II accounting，centralized baseline 也没开 pre-aggregation；65 倍不是完整 TCO 普遍值。论文缺 ingestion p50/p99、burst loss、SSD wear、功耗、AZ 同时过载和 agent fleet failure 结果。
  • DVLA-OSDI26 — 核心问题：静态 VM lifetime bucket 会随 cluster 和时间漂移，少量误放 long-lived VM 长期钉住机器，形成 online placement 无法偿还的 debt。机制：按观测动态更新 affinity group，online placement 对错误类型采用非对称策略，再在维护窗口 live-migrate 被钉 VM；Stable/Observation/Cooldown 防止频繁振荡。关键结果：23 个生产 cluster 两个月 trace 中，相对 LAVA 的加权 packing density 多提高 0.6 个百分点；七个月生产上线后，相对模型反事实的 long-lived packing density 高 1.19 个百分点，stranded machine 从 25.3% 降到 21.3%。证据边界：没有 randomized holdout cluster，生产收益是历史关系外推的 counterfactual；论文未闭合 live migration 网络、pause、能耗与 workload SLO。目标主要是 CPU packing，内存、网络、NUMA 和 accelerator debt 尚未建模。
  • mwait-sched-OSDI26 — 核心问题：原生 mwait passthrough 让独占 VM 低延迟，却对 hypervisor 隐藏 vCPU idle；oversubscription 后空闲 tenant 仍占 pCPU。机制：用短 timer slice 把等待重新变成调度点，以 IOPS/utilization 区分 CPU/I/O VM，整 VM 唤醒维持协同，并用多地址 proxy 支持更高密度。关键结果：1:2 受控共置中，Redis/ZooKeeper 等 P99 相对 mwait-nop 降 30%–50%；320 万 pCPU dedicated fleet rollout 后，高争用 steal 事件在三个区域下降 85%–97%，可售 vCPU 约增加 60 万。证据边界：生产数字只覆盖 1:2 的 mwait-sched，不覆盖 proxy burst fleet；1:4–1:6 时部分服务 P99 可达 1:1 的 4.9–12 倍。rollout 无同期对照，timer 会显著增加 host CPU，classifier phase-change 与功耗未完整报告。
  • PIMS-OSDI26 — 核心问题：计划维护、物理维护和意外故障各自留 buffer，会重复占用容量；多个团队独立 rollout 又可能同时碰同一 fault domain。机制：PIMS 把“一次只维护一个维护域”写成跨基础设施、服务和团队 contract，用 sequencing、intent discovery、boxcar drain/work window 和 enforcement 统一三类维护，并允许故障快速收回自动维护容量。关键结果：在 Meta 数百万服务器上运行五年；2025 Q2 移动 15,716 racks 后专用 buffer 相对减少约 15%；95% server 的 OS provisioning 从约三年缩到 45 天。证据边界：全部来自私有 fleet，无公开 trace 和对照；15% 是同期 fleet 增长下的相对计算，截至 2026 年 5 月约为 3%。共享 buffer 的相关故障证据只有四次事件，drain/work window 平均利用率仅 7%/23%，说明结果依赖大量时间余量。
  • PowerSight-OSDI26 — 核心问题：用 design power 或 benchmark 估 rack budget 会浪费供电，生产 workload 又会随硬件代际和服务 mix 漂移，可靠传感器上线前缺少整机功率标签。机制：Meta 先用服务 peak/平均比例制定 forecast RPB，再用 PowerSight 从 CPU、memory、accelerator performance counter 预测整机功率，并在硬件生命周期中逐步收紧预算。关键结果：十年加权运营结果是在总供电不变时约多放置 20% 机架；MLP 对现有架构新 workload 的 MAPE 为 3.81%，对未见 CPU-H+GPU-B 架构和新 workload 为 7.89%。证据边界：约 20% 是长期综合运营结果，不能分离模型、预算流程、调度与硬件变化；没有低估 P95/P99、供电越界或 power-capping incident。数据、模型和绝对功率未公开，新架构样本不足时误差会超过 10%。
  • Quark-OSDI26 — 核心问题：Spark long-lived executor 预留资源但平均只有 67% 真正在计算，stage 内 task skew 又让静态 allocation 留下大量空闲。机制：Quark 把 executor 改成 task-level serverless instance，以显式 quota 分配资源、干扰感知 placement 抑制 jitter，并从安全 template fork 将启动降到亚秒级；失败 task 可按更大内存重试。关键结果：生产迁移后每 job 归一化资源消耗降低 37.37%，不平衡 stage 比例约从 15% 降到 2%；六个月日均约 902K jobs，成功率 99.11%。TPC-H 中平均 CU 比 Spark 少 56.01%，trace replay 总执行时间少 22.4%。证据边界：迁移不是随机对照，深度绑定 Ant secure container、scheduler 和远程 metadata；shuffle-heavy 与短 task 收益较小，3.4% trace job 的 CU 反而增加。QM 单 active leader、cold-start 尾部、跨平台和统一 CU 口径仍缺验证。
  • SPADE-OSDI26 — 核心问题：碳/功率外部信号不准时统一收缩 executor 会误伤 DAG bottleneck，阻塞下游 stage 并放大 job tail。机制：SPADE 复用 Decima/Graphene 的 task score 估计相对重要性，只推迟低分任务，并同步限制 stage parallelism；policy 在 forecast bound 内调 conservation ratio。关键结果：51-VM 原型中 SPADE-Decima 相对 Spark/Kubernetes Default 的模型碳足迹降低 32.9%，平均 makespan 只增加 1.3%；完整 trace 模拟相对 Decima 降 23.1%，power-overload 指标降 43.9%。证据边界：原型压缩时间、使用 100 个同构 executor，碳结果来自 trace 和 utilization model 而非功率计；P95 JCT 相对 Default 增加 45.4%，且论文若干 makespan 百分比不能由表中归一化均值复算。未覆盖 deadline、公平、异构和 interactive co-location。

设计空间矩阵

论文主题核心问题关键机制主要评测最强结论证据边界
CoreSec-OSDI26网络根因归属缺失/冲突证据下强选根因PAM flag、abstention、拓扑 dominance三年 712,345 个 Azure incidentfalse positive 少于 1%，最近 abstain 1.5%前后对比、非盲 ground truth、内部数据、高层样本少
DiTing-OSDI26分布式可观测性全集中架构成本和查询瓶颈node co-Log、SQL 统一、AZ fallback百万节点生产、microbenchmark、财务模型QPS 高 4–9 倍，总 CapEx 低约 3–65 倍harvested 资源不计成本；baseline/ingestion/TCO 边界强
DVLA-OSDI26VM 放置债务lifetime bucket 漂移和长寿 VM 钉机动态 group、非对称 placement、维护迁移23 cluster trace、七个月生产比 LAVA 多 0.6 点 PD；生产反事实高 1.19 点 PDL无 randomized holdout；迁移成本/SLO 与多资源未闭合
mwait-sched-OSDI26VM idle 调度passthrough 隐藏 idle、超售抢核timer、idle classifier、整 VM wake、proxy220 场景、1:2 实验、320 万 pCPU rolloutP99 低 30%–50%，争用事件降 85%–97%生产仅 1:2；高密度 tail 很差；无因果对照/功耗
PIMS-OSDI26维护容量治理多类维护重复 reserve failure buffer单维护域 contract、sequencing、boxcar、enforcementMeta 五年、数百万 serverbuffer 相对少约 15%，OS rollout 三年降到 45 天私有、无对照；相关故障样本少；窗口利用率低
PowerSight-OSDI26数据中心功率预算设计峰值与生产功率错配分生命周期设置 RPB、基于计数器的 MLP数百万机器、十年运营、模型留出测试同供电约多放 20% rack；现有架构上的新 workload MAPE 3.81%20% 非单机制因果；未报告危险低估的尾部；数据不公开
Quark-OSDI26serverless Sparklong-lived executor 空闲与 task skewtask instance、quota、干扰放置、安全 forkTPC-H、trace replay、六个月生产每 job 资源低 37.37%，不平衡 stage 15% 降到 2%平台强绑定、非随机迁移、短/shuffle-heavy 边界
SPADE-OSDI26信号感知 batch 调度粗暴缩容伤 DAG bottlenecktask importance、selective delay、stage 限流51 VM 原型、trace 模拟、碳模型模型碳低 32.9%，平均 makespan 加 1.3%非实测功率；P95 JCT 加 45.4%；同构且时间压缩

跨论文综合

  • 共同观察：生产系统必须管理不确定性，而不是假装预测永远正确。 CoreSec 允许 abstain，DVLA 用 Observation/Cooldown 和维护迁移还债，PIMS 通过 contract 保留可收回容量，PowerSight 按生命周期逐步收紧，SPADE 只在 signal bound 内行动。这比一次离线最优解更符合真实运维。
  • 共同观察：闲置资源只有在控制面能看见并重新分配时才有价值。 DiTing 用节点闲置的 CPU、内存和磁盘保存近期数据并执行查询；mwait-sched 让 hypervisor 看见空闲 vCPU；Quark 把 executor 的空闲资源改成按 task 分配；PIMS 让不同维护共用 buffer。这样做也会增加 node agent、timer、fork、migration 和大规模发布的故障面。
  • 共同假设：集中控制器、telemetry 和历史 trace 足够可靠。 CoreSec、DiTing、DVLA、PIMS、PowerSight 都依赖内部长期数据；SPADE 依赖外部 forecast，Quark/mwait-sched 依赖平台 scheduler。novel failure、stale mapping、相关预测错误或控制面 bug 可能使全部收益反转。
  • 核心张力：平均效率与尾部风险不一致。 SPADE 平均 makespan 只增 1.3%，P95 JCT 却增 45.4%；mwait-sched 在 1:2 改善尾延迟，1:6 部分 workload 又是 1:1 的 7.9–12 倍；PowerSight 的平均 MAPE 不说明危险低估尾部。运维系统必须报告 risk-weighted tail，而不是只报 fleet average。
  • 核心张力：生产规模增强现实性，却削弱可复现因果。 CoreSec、DVLA、PIMS、PowerSight、Quark 都有长期生产数字，但多为上线前后、模型反事实或综合运营结果。需要把“系统在生产运行”与“某个机制导致 headline 收益”分开。
  • 后续方向：做风险感知的 canary 与 holdout。 小团队可以用公开 trace 和小型 cluster 复现 controller，再设计 cluster-level randomized rollout、长期 holdout 或 switchback，统一报告均值、P95/P99、fallback、rollback 和控制面故障；这比追求百万节点规模更能补因果证据。
  • 后续方向：把单资源收益改成可兑现容量。 DVLA/Quark 的 CPU packing、PowerSight 的功率、DiTing 的 harvested storage、mwait-sched 的 vCPU 都应联合到 memory、network、energy 和 SLO，最终回答多少机器真的能关、多少供电真的可复用，而不是只报 utilization 点数。
  • 后续方向：验证 correlated failure。 对 PIMS 的共享 buffer、CoreSec 的 agent 组合、DiTing 的 node/AZ fallback 和 DVLA 的相关 lifetime 误判，构造 common-mode outage、stale telemetry、控制器重启和错误 rollout campaign，测 blast radius、恢复时间与 fail-safe 行为。

跨论文共同趋势

1. 管理与调度粒度持续变细

很多论文把系统控制粒度继续下沉：BatchGen-OSDI26 把生成序列拆成可暂停、合并和迁移的协程；MPK-OSDI26 把张量图拆成 SM 级任务；Quark-OSDI26 把常驻执行器改成 Spark 任务级容器；OBASE-OSDI26 从页级分层下沉到对象级；Megalon-OSDI26 则把大索引和小一致性记录分开管理。

更细粒度能减少 head-of-line blocking 和内部碎片，却会增加 metadata、状态机、验证与恢复成本。论文常在正常路径证明收益，但对取消、崩溃和跨版本恢复讲得较少。未来的关键不是继续无限细分，而是找到“节省的等待时间大于新增控制税”的拐点。

2. 内存层级变成可计算、可调度的执行面

CPU DRAM、CXL 内存、GPU HBM、NVMe 与 SSD 不再只是容量不同的仓库。DirectKV-OSDI26 让 attention kernel 直接读取 CPU 中的 KV，ECHO-OSDI26 用主机内存池承载原生稀疏模型的完整历史，Cocoon-OSDI26 把相关噪声历史分到 GPU、CPU 和 CXL 近数据计算设备，CoPilotIO-OSDI26 让 GPU 直接生成 NVMe 命令，Espresso-OSDI26 把 SSD 计算资源和数据端解耦后重新配对。

共同结论是：放置策略必须知道访问语义和就绪时间。只报缓存命中率、容量或峰值带宽不够；数据布局、访问粒度、NUMA、并发和故障路径都会决定命中的数据是否真的能在 SLO 前就绪。

3. 异构不再是异常，而是默认条件

OSDI 2026 的“异构”同时出现在硬件、模型、阶段和故障角色中。Hetu-v2-OSDI26 面向不规则异构训练图，Tessera-OSDI26 处理混合 attention/DeltaNet/MoE pipeline，Weave-OSDI26 配对 H20 rollout 与 H800 training，UEP-OSDI26 跨 NVIDIA/AMD GPU 与多种 NIC，TileLoom-OSDI26 跨两代空间加速器。

这使静态最优配置更容易过时。多数系统采用“离线画像 + 在线选择”，但画像因版本、温度、并发和拓扑变化而失效时，回退机制往往没有同等完整地设计。

4. 优化目标从峰值吞吐转向有效吞吐、尾延迟、能耗与恢复时间

EcoServe-OSDI26 以 TTFT/TPOT SLO 下的有效吞吐比较阶段调度；PowerSight-OSDI26 用性能计数器预测整机功率，支持机架功率预算；AEGIS-OSDI26 在线采样检测训练中的静默数据损坏（SDC），OpGuard-OSDI26 则比较参考执行与故障执行的算子边界指纹，定位首个差异；TrainMover-OSDI26 关注迁移或故障停机，CoreSec-OSDI26 在证据不足时明确放弃自动归因。

这比只报平均吞吐更接近生产，但不同论文的 SLO、计费和故障模型仍不统一。一个系统可能平均更快，却在低负载、突发、背景争用或恢复时更差；矩阵中的证据边界专门保留这些反例。

5. 快路径越来越依赖保守回退

许多系统用预测加速常见路径，再用精确检查或旧路径守住正确性。ECHO-OSDI26 先预测要搬的 KV，最后仍补齐精确的 top-k；GraCE-OSDI26 只在离线画像认为有益时启用 CUDA Graph；NeuroSymbolicProof-OSDI26 用微调小模型提出 Isabelle tactic，再由 Isabelle 执行和检查；Jaber-S3Conformance-OSDI26 用可执行模型判断对象存储 API 行为；CoreSec-OSDI26 不把缺数据硬判成健康。

这种设计比“预测永不出错”更容易部署。代价是回退路径必须真的可用，并要测触发率、最坏开销和状态一致性；不少论文只充分测了常见路径。

6. 软件重新拿回硬件快速路径的控制权

UCCL-Tran-OSDI26 保留 NIC 数据搬运，把传输控制放到主机；UEP-OSDI26 让 GPU 生成紧凑命令，由 CPU 代理调用可移植 verbs；CoPilotIO-OSDI26 把 NVMe 提交队列放到 GPU，把完成处理留在 CPU；BALBOA-OSDI26 在 FPGA 上开放可修改的 RoCEv2 数据路径，但当前只覆盖 RC 模式的一侧 RDMA READ/WRITE 子集，也没有实现生产级拥塞控制。共同点是让软件或 CPU 重新掌握原本封在设备里的控制路径；只有其中一部分同时追求跨厂商移植。

控制移到软件会消耗 CPU 核、增加队列和调度抖动；控制留在硬件又难以快速修改拥塞、故障和路由策略。会议没有给出统一答案，而是画出了不同设备与工作负载下的边界。

7. LLM 既是工作负载，也是系统组件和工具

前六类论文把 LLM 当成要被训练、服务、诊断的重型工作负载；gigiprofiler-OSDI26、ECO-OSDI26、NeuroSymbolicProof-OSDI26 又把 LLM 用于性能分析、代码优化和证明搜索。后者的共同模式是：LLM 提高候选覆盖，再由静态分析、测试或证明检查器做可审计验证。

这种组合比让 LLM 直接给最终答案可靠，但验证器只会检查已经形式化的性质。遗漏的环境语义、未建模的副作用和测试覆盖不足仍会造成漏报；“有验证器”不等于整个系统已被验证。

8. 生产轨迹变多，因果识别仍是短板

大规模生产轨迹能证明突发、碎片、故障或长尾确实存在，却不自动证明某个改动造成所有改善。Quark-OSDI26 的真实迁移前后工作负载同时变化，Prism-OSDI26 的多模型结果依赖放大后的到达轨迹，StriaTrace-OSDI26 的异常屋顶线会把持续退化吸收成新常态。更好的会议论文已主动写出这些边界，但统一的公开回放和反事实实验仍很少。

互相冲突的设计选择

先搬数据，还是直接远端读取

Strata-OSDI26 在 H200 长上下文、高复用场景中，用 GPU 线程并发搬运大量碎片小页，在搬运时完成 page-first 到 layer-first 的布局转换，再用调度隐藏 I/O；DirectKV-OSDI26 则在 GH200 上让 kernel 直接读取 CPU 中的 KV，省去 HBM 暂存。前者适合高复用且搬运可隐藏的场景，后者依赖低延迟 NVLink-C2C，且远端读取不能被重复放大。真正需要的是按互连、稀疏率、复用距离和批次在线选择，而不是固定站队。

透明一致性，还是显式所有权

Soul-OSDI26 将锁等待并入广义一致性，并提供基本的 pthread/Rust 读写锁接口，但尚不支持 try-lock、超时、中止和条件变量，而且需要修改一致性控制器和目录；Duhu-OSDI26 给可变元数据设置单一所有者，用消息传递避免跨节点一致锁；Megalon-OSDI26 把大索引留在主机副本，只让小记录使用一致区，不过目前证据来自三台主机的 NUMA 模拟，并非真实 CXL 互连。读多写少、共享粒度和一致区容量不同，会得到不同答案。

共置，还是解聚

EcoServe-OSDI26 认为普通以太网上完全 P/D 解聚的 KV 传输太贵，选择在同一实例内错开阶段；Weave-OSDI26 在微基准和两周 200-job 轨迹回放中，通过跨作业配对利用 H20 rollout 与 H800 training 两个资源池的互补气泡；RollArt-OSDI26 只把短促的 reward 阶段送到 FaaS。是否解聚取决于状态搬运时间与阶段时间之比、硬件差异、SLO 余量和能否找到互补作业。

静态深度优化，还是动态适应

Twill-OSDI26 和 MPK-OSDI26 依赖静态输入形状、硬件模型或预生成任务图来做深度 GPU 优化；DCP-OSDI26、KAIROX-OSDI26 和 DynaRL-OSDI26 则在线调整切块、稀疏执行或资源分配。静态方案在稳定工作负载上开销低，动态方案能处理工作负载变化，却多出观测误差和控制振荡。二者更可能以“少数预编译档位 + 在线选择”结合。

硬件传输，还是软件传输

BALBOA-OSDI26 用开放 FPGA 数据路径换取协议可修改性，UCCL-Tran-OSDI26 保留普通 NIC 的数据搬运路径、把控制移到主机；UEP-OSDI26 不需要新专用 NIC，但仍要增加 GPU 端的 16-byte 命令通道、EP kernel 移植、CPU 代理和共享顺序协议。选择时应一起比较 CPU 核占用、报文率、功能完整性、跨厂商移植成本和故障恢复，不能只看无拥塞时是否跑满链路。

缓存局部性，还是负载均衡

LMetric-OSDI26 用未缓存输入 token 数与批次大小的乘积平衡 KV 局部性和解码负载；Prism-OSDI26 面对多模型权重和 KV 占用随请求变化，还要处理模型冷热。缓存感知调度会偏爱热门键或模型，因此需要显式限制冷请求的饥饿时间并保障公平性。

反复出现的脆弱假设

  • 局部性会持续。 KV 前缀、attention 选择、对象热度、模型活跃集和后缀树都依赖过去预测未来；领域切换、版本更新或对抗性工作负载会破坏它。
  • 离线画像仍有效。 ADAngel-OSDI26、Kareus-OSDI26、Twill-OSDI26、DCP-OSDI26 都用离线画像或成本模型；驱动、编译器、温度和共租户变化会移动最优点。
  • 额外工作能离开关键路径。 预取、验证、检查点复制、后台去碎片和追踪常假设有资源余量；系统接近饱和时，这些工作会反过来造成尾延迟。
  • 高速互连足以隐藏状态搬运。 Seer-OSDI26 的 KV 迁移、TrainMover-OSDI26 的角色加入、DGC-OSDI26 的远端标记都在高规格网络上验证；跨机架拥塞和共享网络会改变结论。
  • 控制面可信且不会成为瓶颈。 很多设计依赖集中调度器、注册表、租约所有者或验证器，却没有完整测试控制面分区、升级和灾难恢复。
  • 平均基准代表风险。 稀疏、近似、LLM 生成和学习控制器可能让平均分数不降，却在少数关键输入上静默失败；需要逐请求保护和专门的失败集。
  • 内部轨迹可代表外部部署。 生产数据很真实，但硬件采购、租户组合、SLO 和软件栈都可能只属于一个组织。

后续研究方向

  1. 统一多资源 SLO 模型。 把 GPU/CPU/NIC/CXL/SSD 的占用、数据就绪时间、能耗和 P99 放进同一模型，并允许低成本在线校准：用 Strata-OSDI26 表达数据就绪时间，用 EcoServe-OSDI26 和 DCP-OSDI26 表达 TTFT/TPOT SLO，用 Kareus-OSDI26 表达训练时间与 GPU 能耗权衡，再接入 PowerSight-OSDI26 的整机与机架功率估计。
  2. 为细粒度状态设计恢复语义。 协程、SM 任务、对象、租约和分布式 KV 在取消、迁移、节点失败后由谁持有、怎样重放，应成为抽象的一部分，而非实现附录。
  3. 公开可重放的生产形状。 在不泄露用户数据的前提下发布到达、长度、资源、故障和拓扑统计，让调度、缓存和控制器能做同条件比较。
  4. 测试控制器的变化适应性与稳定性。 对离线画像过时、测量噪声、突发和多控制器相互作用做故障注入，报告收敛、振荡、回退频率和最坏 SLO。
  5. 把正确性检查放进性能接口。 稀疏、量化、近似证明、LLM 工具和推测执行都应暴露置信度、验证成本与回退，而不是在性能 API 外另做离线质量测试。
  6. 统一直接访问与暂存的临界点基准。 在 PCIe、CXL、NVLink-C2C、RDMA 和 SSD 上扫描访问粒度、复用、并发与稀疏率，形成可移植的路径选择规则。
  7. 报告完整 TCO 与资源外部性。 GPU 利用率提高可能多用 CPU、DRAM、NIC 或 SSD；应同时报告设备小时、能耗、容量驻留和运维复杂度。
  8. 验证跨组织可复现性。 对依赖内部轨迹、专用硬件或厂商运行时的结果，至少提供缩小版 artifact、公开工作负载映射和不能复现的明确清单。

关系图谱

反向链接