Tutti: Making SSD-Backed KV Cache Practical for Long-Context LLM Serving

Shi Qiu, Yifan Hu, Xintao Wang et al. · 2026-05-05

🎯 核心问题
长上下文 LLM 推理把 KV-Cache 撑爆 HBM/DRAM，必须下放到 NVMe SSD；但即便用上 GPU Direct Storage（GDS），CPU 仍要为每个 I/O 发起 syscall，碎片化的 GPU 内存布局又把传输切成海量小随机 I/O，结果 SSD 带宽吃不满、GPU 大量空转（stall）。

🔧 关键方法
Tutti 把 CPU 从关键路径上彻底移除：(1) 在 GPU 上提供原生的 KV-Cache 对象抽象，允许批量传输与管理；(2) 重做 GPU 侧存储栈，引入 GPU io_uring，让 GPU 自己异步发起 direct object I/O；(3) slack-aware I/O scheduling 避免与 compute kernel 抢资源。CPU 只在每层异步加载一次 I/O kernel。架构上是把传统 io_uring 的 SQ/CQ 提升到 GPU 端，颗粒度做粗。

📊 实验或论据
集成进 vLLM，与 SOTA 的 GDS-enabled LMCache 相比，在严格 SLO 下 TTFT 降低 78.3%、可承载请求率提升 2×、服务成本下降 27%；并且性能接近 DRAM-backed LMCache，但容量"几乎无限"。

⚠️ 局限
需要 NVMe + GDS 兼容硬件栈；"GPU io_uring" 的实现细节（如何绕过 NVIDIA 驱动的中断/通知路径）从 abstract 看不出工程化代价，需读全文。多租户场景下 slack-aware 调度是否仍稳健也未提及。

💼 对系统人的启示
经典 OS 模式（io_uring、对象存储抽象、I/O 调度）正在被原样搬到 GPU。做 LLM serving 基础设施的工程师可以重新审视：你的 CPU 真的有必要待在数据路径上吗？

KV-RM: Regularizing KV-Cache Movement for Static-Graph LLM Serving

Zhiqing Zhong, Zhijing Ye, Jian Zhang et al. · 2026-05-10

🎯 核心问题
静态图 LLM decoder（固定 tensor shape、低 submission overhead）和在线 decoding 的现实（请求长度不等、EOS 异步到来、KV 历史碎片化）天生矛盾。要么过度预留内存，要么忍受 burst-time 尾延迟尖峰。能不能把不规则性"压"到 decode 接口之下？

🔧 关键方法
KV-RM 在静态图 decoder 下面塞一层 KV-Cache 运行时：用 block pager 解耦逻辑 KV 历史与物理存储，每步 decode 通过一个"已提交描述符"物化；merge-staged transport 把非连续 KV 映射合并成少数大块再喂给固定 shape 的 attention kernel。可选 bounded far-history 摘要，但核心设计不依赖。本质是把 vLLM PagedAttention 的思路"反过来"放进静态图世界，关键边界从 kernel shape 移到 KV 数据搬运。

📊 实验或论据
2 块 NVIDIA A100：混合长度 decoding 的吞吐和尾延迟均优于静态图基线，多种 workload 下 reserved KV memory 降低，production-trace 重放下消除严重 burst-time 延迟尖峰。具体数字 abstract 未给。

⚠️ 局限
只在 2-GPU A100 节点上评估，未涉及更大规模或异构互联；与 vLLM/SGLang 等动态运行时的端到端对比 abstract 未提，需读全文确认"静态图 + KV-RM"是否真比"完全动态"更优。

💼 对系统人的启示
这是个有意思的"层界面"决策示范：相同问题（不规则 KV）可以由 kernel 端解决（动态形状），也可以由数据搬运层解决（描述符 + 合并传输）。做推理框架的同学应警惕把"灵活性"硬塞进 kernel——往下层挪一格往往代价更小。

Pomegranate: A Lightweight Compartmentalization Architecture using Virtualization Extensions

Shriram Raja, Zhiyuan Ruan, Richard West · Boston University · 2026-05-07

🎯 核心问题
单体内核里一个组件被攻陷就全军覆没。已有补救方案要么需重写为微内核（巨贵），要么用 MPK（需大量静态分析），要么靠虚拟化但每次切换都得 trap 到 hypervisor（慢）。能不能既不改源码、又不进 hypervisor？

🔧 关键方法
Pomegranate 用硬件辅助虚拟化把现有系统切成多个 compartment，依靠 Extended Page Tables (EPT) 强制 access-control 策略。亮点是引入 sentry function：跨 compartment 调用走预定义的入口函数，运行时即可校验合法性，不必 VMExit 到 hypervisor，从而砍掉切换的主要开销。源码改动最小化。

📊 实验或论据
在 Linux 上对网络栈与 igc NIC driver 做了 compartmentalization。结果：当 compartment 边界划得合理（避免频繁跨区通信）、MTU 大小的包，开销可忽略。

⚠️ 局限
依赖 x86 VT-x/EPT，ARM/RISC-V 适配未提；sentry 函数的覆盖完备性需人工或工具辅助审计——这是分区机制普遍痛点；如果 compartment 边界切得不好（跨区通信频繁）开销可能不再可忽略。

💼 对系统人的启示
对内核安全有兴趣但不想全栈重写的团队，这套"VT 但不 trap"的思路值得借鉴——尤其适合驱动隔离场景。能否拓展到 BPF helper 集合、文件系统模块这些复杂边界，是关键判据。

ipc_shared_ptr: A Publish/Subscribe-Aware Smart Pointer for Cross-Process Object Lifetime Management

Takahiro Ishikawa-Aso, Atsushi Yano, Koichi Imai et al. · 2026-05-05

🎯 核心问题
ROS 2 要做真正的 zero-copy IPC，订阅方需直接引用发布方共享内存里的对象。但对象不能"还在被引用就释放"，又必须"最终能释放"，还要处理订阅方崩溃恢复和 Transient Local QoS。通用的分布式引用计数过重，pub/sub 这套语义里能不能省掉？

🔧 关键方法
提出 ipc_shared_ptr：把 Birrell 的 reference listing 针对 pub/sub 做特化——全局元数据更新只在每个 subscriber 的 0↔1 转换发生，相对通用方案全局通信量降低一个数量级。讨论了一个关键 tradeoff：owner-driven reclaim（如 iceoryx2）可扩展性强但 race condition 多、验证状态空间大；single-writer（本文 Agnocast 采用）牺牲集中式 writer 换得结构性原子性，实现简单。

📊 实验或论据
在 Autoware（最大开源 ROS 2 应用）规模下对比 iceoryx2：200 topics × 每 topic 2 subscribers × 100 Hz，Agnocast 的 E2E p99.9 比 iceoryx2 低 2.9×。证明 single-writer 在自动驾驶量级仍够用。

⚠️ 局限
single-writer 终究是中心化结构，更高 fanout（如成百上千 subscribers/topic）下集中式 metadata 是否仍胜出 abstract 未说；崩溃恢复的具体协议细节也需读全文。

💼 对系统人的启示
经典案例：把"通用算法"按业务结构特化能砍掉数量级开销。做 RPC/消息中间件的工程师可以重新审视自家的引用计数/lease 协议——是不是被通用性绑架了？做自动驾驶/机器人栈的同学可直接关注 Agnocast。

CityOS: Privacy Architecture for Urban Sensing

Giorgio Cavicchioli, Mark Chen, Navid Salami Pargoo et al. · Columbia / Rutgers · 2026-05-04

🎯 核心问题
城市部署摄像头、环境传感器、信息亭等大量公共空间感知设备，但缺少统一的系统层架构来仲裁应用访问、聚合、保留数据——隐私和策略执行都失控。怎么给"城市"做一个 OS？

🔧 关键方法
CityOS 是一个 edge runtime，把不受信任应用跑在短生命周期 container里。其 API 分三层，空间范围逐层扩大、隐私约束逐层加强：On-Scene（本地实时，原始数据不出局部）→ Single-Locality Aggregation（定点纵向统计，加差分隐私）→ Cross-Locality Aggregation（城市级，用户设备执行 per-user 隐私预算）。差分隐私 loss 通过广播形式公开透明。

📊 实验或论据
实现并跑通了横跨三层的应用：行人安全提示、实时与预测停车位、交通仪表盘、地铁轨迹测量等。证明该架构能撑实际街景应用且仍执行强隐私约束。具体性能数字 abstract 未给。

⚠️ 局限
每用户设备执行隐私预算依赖用户侧合作软件，敌对用户/受损设备如何处理 abstract 未提；差分隐私预算的可组合性在实际部署中往往是个工程深坑；如何覆盖私有/商用传感网络也需进一步看。

💼 对系统人的启示
"API 层级即隐私边界"是个值得借鉴的设计思路。对做联邦学习、移动隐私平台、边缘计算栈的人，可以参考它把 DP 预算下沉到客户端 + 公开广播 loss 的做法。但落地"城市级 OS"涉及大量非技术因素，把它当成隐私架构参考更合适。

Shedding Light onto Safety Integrity Level and Basic Software Constraints in a Real-World Automotive Application: Case Study with Driverator Framework

Tobias Denzinger, Matthias Becker, Peter Ulbrich · 2026-05-06

🎯 核心问题
汽车 ECU 系统里 cause-effect chain 的时序分析已经被研究透了，但 SIL（Safety Integrity Level）分级、AUTOSAR Basic Software 开销、内存约束这些同样制约系统设计的非功能性属性却没有同等深度的工具支撑。错误的 task colocation 会破坏关键功能完整性。

🔧 关键方法
本文系统刻画了一个真实汽车应用：基于 SIL 约束的应用结构、AUTOSAR BSW（OS、运行时环境、通信栈、诊断等）开销如何随 task 特性与 SIL 类别变化、以及不同内存架构下的 SIL 相关依赖。在此基础上引入 Driverator——一个可扩展的系统分析配置框架。

📊 实验或论据
案例研究形式，目标是把一个真实汽车应用的 SIL/BSW/内存约束建模清楚。abstract 未给具体性能或验证数字。

⚠️ 局限
单案例研究，能否推广到其他 OEM/ECU 拓扑未知；框架是否开源、对非 AUTOSAR Classic 平台（如 AUTOSAR Adaptive、SOA 架构）是否适用 abstract 未提。

💼 对系统人的启示
对功能安全/嵌入式 RTOS 工程师有直接价值——把 SIL 当成调度/内存配置的一等约束。对纯 Linux/数据中心系统的人，本文价值在于提醒：在 safety-critical 领域，"task 怎么放在一起"是个比时序更复杂的多维约束问题。

本周 6 篇论文作者群体跨度大，整体呈现"LLM 系统侧（中美）+ 经典 OS 安全（美）+ 实时/嵌入式（日德）"的分布：

值得点名的"持续输出组"：Shinpei Kato 团队（ROS 2 / 自动驾驶系统侧多年深耕）、Geambasu × Nieh（哥大隐私 + 系统老组合再次合作）、Richard West（Boston U 内核安全持续产出）。

趋势 1：LLM serving 正在被"OS 化"

本周 6 篇里有 2 篇（KV-RM、Tutti）直接处理 KV-Cache，且都把经典 OS 概念搬过去——分页（block pager）、io_uring、I/O 调度、对象抽象。LLM serving 框架从"AI 工程"逐渐被识别为"内存层级管理 + I/O 调度"，传统 OS 工具箱在此非常有竞争力。建议数据中心系统/存储栈背景的工程师把目光投向这个方向。

趋势 2：隔离机制走向"硬件特化 + 工程化简化"

Pomegranate 用 EPT + sentry function 跳过 VMExit，ipc_shared_ptr 用 single-writer 牺牲扩展性换状态空间收敛——都体现了同一种思路：不再追求最通用的机制，而是针对具体场景把硬件原语和软件协议特化到最简。这与微内核年代追求"通用 capability"的研究取向是相反的，反映社区更看重"能落地、能审计、能验证"。