Callosal: Rethinking the Kernel Page Cache for Disaggregated Storage and Memory

James McMahon, Amit Samanta, Seung-seob Lee (+ et al.) · Utah / Yale · 2026-10-26

🎯 核心问题
传统分布式文件系统（如 NFS）将文件操作集中到 server 端，cache 一致性靠 ad hoc 方式管理，导致可扩展性差、一致性弱，无法支撑并发读写共享文件的应用。作者观察到：当今大内存时代，OS page cache 才是数据访问的主角，存储层已不是瓶颈——但分布式 page cache 仍然缺位。

🔧 关键方法
Callosal 围绕 Linux 已有 page cache 路径构建集群级分布式 page cache，后端使用共享 disaggregated memory（通过 RDMA 和可编程交换机加速）。不做 NFS 式的 server 串行化：每个客户端直接通过 RDMA 访问共享内存中的 page cache 页。一致性模型对标本地文件系统（ext4/tmpfs 级别），而非 NFS 的弱一致性。核心设计在于将 cache consistency 协议嵌入 page cache 层而非文件系统层，避免存储-centric 的历史包袱。

📊 实验或论据
与 NFS、CephFS 及本地文件系统对比。混合读写负载下，无极端竞争时吞吐比 NFS 高 4.6×；一致性等价 CephFS 但性能更优。1% 写 + uniform 访问的 KV store 场景下，4 节点扩展 1.7×，而 CephFS 跨节点坍缩。

⚠️ 局限
在极端写竞争场景下性能优势不明显（论文措辞为"when contention is not extreme"）；RDMA + 可编程交换机的硬件假设在普通数据中心不普遍。

💼 对系统人的启示
这是对"分布式文件系统应该在哪一层做一致性"的重新思考。如果你在做分布式存储或缓存层，page cache-centric 的设计思路值得借鉴——尤其如果你的场景已经有 RDMA 网络。思路比实现更值得学。

safeL4: Rethinking Safe-Language-Based Single Address Space Microkernels

Zheyuan Xu, Xiaobei Zhang, Zihan Li (+ et al.) · SJTU / IPADS · 2026-10-26

🎯 核心问题
微内核依赖硬件隔离（MMU/Page table）导致 IPC 性能开销大；用 safe language（如 Rust）做单地址空间隔离可以消除硬件隔离开销，但面临两个挑战：如何保持微内核的 minimality 原则，以及如何实现 capability-based 的细粒度资源访问控制。

🔧 关键方法
safeL4 用 Rust 实现，核心设计两点：(1) 通过低层 abstraction 封装 unsafe 操作来保证 minimality——不是把所有 unsafe 禁掉，而是用最小化的 primitive 集合暴露给上层；(2) 基于 safe language 的 object capability 实现资源访问控制——利用 Rust 的所有权系统和 trait object 来自然地表达 capability 约束，无需额外运行时检查。单地址空间消除了传统微内核的 IPC 跨地址空间切换开销。

📊 实验或论据
Prototype 用 Rust 实现，与 seL4 对比：safeL4 的 primitive 操作平均快 1.9×。seL4 是 C 实现 + 硬件隔离 + 形式化验证的金标准，safeL4 在性能上能超越它说明 safe language 隔离的 IPC 优势显著。

⚠️ 局限
论文未提及 safeL4 是否有形式化验证（seL4 的核心卖点是 Isabelle/HOL 证明）；Rust 的 unsafe 边界审计如何系统化保证无漏洞，abstract 未展开。1.9× 的数字仅针对 primitive 层面，端到端应用性能未报告。

💼 对系统人的启示
"用语言安全替代硬件隔离"这条路线在学术界持续有人探索（从 singularity 到 safeL4）。如果你在考虑 Rust 写 OS 组件或安全沙箱，object capability 作为权限模型是个可以直接借鉴的设计模式。距离 production 还远，但方向值得关注。

Rimuru: Unified Memory Management for Modern LLM Serving via Elastic Expert Offloading

Zhiyuan Fang, Dingyang Li, Jianfeng Zhong (+ et al.) · Jinan Univ. / Sun Yat-sen Univ. · 2026-10-29

🎯 核心问题
LLM serving 中 model weights 和 attention state 各自独立分配显存，边界固定无法随负载弹性调整：高负载下 state 容量不足限制并发，低负载下 weight 区空闲显存无法挪用。MoE 架构引入异构 tensor（不同 layout、不同 lifetime），进一步复杂化内存管理。

🔧 关键方法
Rimuru 建立 shared page pool 让异构 tensor 共享显存空间。关键创新是"memory views"——每种 tensor 类型用自己的 page size 和 page table 解释同一片共享空间。配合 huge-page alignment + 多级 page allocator（可 split/merge），实现跨类型容量复用。还设计了 page-table-aware fused MoE kernel，直接访问非连续 expert weights（无需 copy）。workload-aware adjuster 根据运行时需求动态在 tensor 类型间重分配 page。基于 vLLM 实现，兼容主流 LLM。

📊 实验或论据
在 vLLM 上实现评估。吞吐量最高提升 19.03×，TTFT 平均降低 98.1%。数字非常激进，说明 baseline 在内存管理上的浪费可能极大。

⚠️ 局限
19.03× 的数字可能在极端 baseline 配置下取得，实际 production 场景收益待验证；MoE-specific 的 fused kernel 对非 MoE 模型不直接适用。abstract 未提及多 GPU 场景。

💼 对系统人的启示
"memory views" 的思路——同一片物理内存用不同 page table 解释给不同 allocator——是经典的 OS 虚拟内存思想在 GPU serving 上的移植。如果你在做 GPU 内存调度或 serving 引擎优化，这个设计 pattern 值得学。代码基于 vLLM，可直接 fork 试。

FlatCake: A Flat KVCache Storage Architecture for LLM Serving

Xin Huang, Teng Ma, Zhuoran Li (+ et al.) · 2026-10-28

🎯 核心问题
现有 LLM serving 系统用 DRAM→SSD 分层 hierarchy 管理 KV cache：DRAM 当中间 cache，SSD 当后端。但 production 负载打破了这个前提：(1) bimodal reuse——要么一次性 block 的 reuse distance 极长，要么 agentic session 的 KV cache 达 GB 级超 DRAM 容量——让 SSD 变成关键读路径；(2) DRAM staging buffer 与 eviction-ordered layout 导致 SSD 读取碎片化，无法大块顺序读。

🔧 关键方法
FlatCake 将 DRAM 和 NVMe SSD 作为 peer media 暴露在统一 64-bit 地址空间中，不做层级区分。利用 KV block 的 write-once / immutable / session-scope reuse 特性，创建时直接放到目标 medium 上（session-contiguous, layer-major order），永不迁移。通过 GPUDirect Storage 将 SSD 读取直接 stream 到 GPU 的 bounded window，绕过 host CPU。DRAM 和 SSD 的请求队列解耦，避免 head-of-line blocking。

📊 实验或论据
在 production Claude Code trace + DeepSeek-V4-Flash 上评估：cache hit rate 94%（Mooncake 64%），消除 Mooncake 的 6.5×–6.7× SSD 读放大，peak-load mean TTFT 降低 1.6×，token 吞吐提升 1.6×。Llama-3.1-70B 上 8K–128K context，TTFT 比 Mooncake 降低最高 2.4×。

⚠️ 局限
"never migrate" 策略依赖 block 的 write-once 性质，如果未来 LLM 架构引入 KV cache 更新/重写机制则不适用；GPUDirect Storage 的硬件要求（NVIDIA GPU + 兼容 NVMe）限制了部署灵活性。

💼 对系统人的启示
"不要做层级 cache，做 flat address space" 是对经典分层存储哲学的直接反叛。对于 KV cache 这种 immutable workload，flat 设计确实更优。这个思路对做 serving 引擎存储层的人有直接参考价值——尤其是在你已经用 GPUDirect Storage 的场景下。

PhOSv1: Efficient Scaling of Model Sleeping on a Single Server for Autoscaling with GPU-Context Deduplication

Tianle Sun, Xingda Wei, Rong Chen · SJTU · 2026-10-29

🎯 核心问题
Model sleeping（vLLM / SGLang 的 autoscaling 机制）通过暂停预 spawn 的引擎实现近零成本 scale-up，但每个 sleeping model 必须保持 GPU context resident（CUDA context），成本随模型数线性增长。一台 GPU server 上想 sleep 很多模型时，context tax 吃掉显存。

🔧 关键方法
PhOSv1 观察到 sleeping model 的 GPU context 大量重复：CUDA driver context 可跨模型共享，GPU kernel binary 因共用算子/库高度重叠。通过 API remoting 将每个引擎的 GPU context allocation 透明委托给 central daemon，由 daemon 做去重。一个 server 上能 sleep 的模型数远超现有引擎。本质上是把 GPU context 的管理从 per-engine 提升到 per-server 级别做 deduplication。

📊 实验或论据
Scale-up time 匹配 vanilla vLLM sleep mode，同时大幅降低 GPU memory footprint，提升 end-to-end 多模型 serving 性能。abstract 未给具体倍数数字。

⚠️ 局限
API remoting 引入额外 IPC 开销（虽然 abstract 声称 scale-up time 不变）；central daemon 本身可能成为单点或性能瓶颈。具体去重率和绝对显存节省数字 abstract 未给。

💼 对系统人的启示
"GPU context 不是 per-model 的，是 per-server 的"这个观察非常有工程价值。如果你在管 GPU 集群上的多模型部署，这个 dedup 思路可以直接降低 idle 模型的显存税。值得跟踪是否有人把它做成 K8s device plugin。

Tracekit Box: Running AI Agents in Micro-VMs Where Every Way Out Is Decided and Signed

Bravish Ghosh · 单作者 · 2026-10-28

🎯 核心问题
AI agent 可以安装包、调用 model API（带用户 key）、修改生产代码仓库——这些能力也是数据泄露、key 盗用、未授权系统修改的入口。Sandbox 能隔离 agent 但不记录越界事件；tracing 记录但不含隔离。需要两者兼做。

🔧 关键方法
每个 job 跑在自己的 Firecracker micro-VM 中，无网卡。唯一出口是 host 上的"door"（通过 vsock 暴露）：commands、outbound connections、secrets、model calls、workspace patch。每个 door 处有一个 agent 无法触及的 Tracekit signer 决定什么能通过并签名。DNS 解析在 host 完成；私有/云 metadata 地址一律拒绝；secret 不进 VM，VM 只看到 placeholder，host proxy 仅在 bound host 的单个 header 里替换真实值。修改以 patch 形式返回，file by file 由 signer 逐个决定。fail-closed 设计；每个 job 结束生成 .tkb bundle 可离线验证。

📊 实验或论据
MIT 许可证开源（v0）。13 个 end-to-end check 全部通过（KVM runner，28.5s 含 image pull + boot）；15 个 trust boundary fuzz target 产出 9 个发现，全部修复；demo run 的 102 条签名记录可验证。

⚠️ 局限
尚未运行 Firecracker jailer（安全加固缺一层）；signer 需 co-located（单点风险）；VM 内部进程仅在其越过 door 时才被记录——VM 内 lateral movement 不可见。

💼 对系统人的启示
这是目前看到的 AI agent sandboxing 设计中最细致的——"每个出口都是 door + signer"的思路比单纯 container 隔离安全得多。开源且工程化程度高，如果你在构建 agent 平台，值得直接试用或借鉴 door 模型。Firecracker + vsock 的组合在轻量隔离场景已经成熟。

GearUp: DAG-aware Acceleration for Serverless Inference Serving via Slack-guided Pre-loading

Qi Qi, Yifan Sui, Hanfei Yu (+ et al.) · 2026-10-28

🎯 核心问题
Serverless 平台跑 ML inference DAG 时，每个节点不仅要启 container，还要 load 库、model weights、CUDA kernel——这些 init 成本沿 DAG 依赖路径累积，成为端到端 critical path 的一部分。现有方案要么 DAG-agnostic 预加载（浪费资源），要么 DAG-aware 但只优化路由/扩展（不管节点内部 loading）。

🔧 关键方法
GearUp profile 每个 node 的 loading stage，在 DAG 暴露的 slack time 内调度这些 loading（利用上游执行时间隐藏 init）。initialized instance 跨 request 复用避免重复冷启动。概率性、流量自适应的 keep-alive policy 在 bursty load 下平衡内存成本与冷启动风险。核心是"把 loading 从 critical path 上摘下来塞进 slack"。

📊 实验或论据
AMBER Alert + FINRA-ML workflow，NVIDIA L40S GPU。对比 SMIless，median 端到端延迟降低 64.5% 和 75.9%，speedup 3.1× 和 10.0×（vs cold execution）。对比 InstaInfer 的 eager pre-loading，GPU 和 host 内存分配降低 83.9% 和 94.6%。4 worker 上 4.2× strong scaling。

⚠️ 局限
Slack-guided 调度依赖 DAG 结构有足够 slack——如果 critical path 本身就是串行且各 node loading 很重，slack 可能不够隐藏全部 init；abstract 未提冷启动后 keep-alive 在无流量时的回收延迟。

💼 对系统人的启示
"在 DAG slack 里藏 loading"是经典的 critical path scheduling 思想在 serverless ML 上的应用。如果你在做 serverless 函数编排或 pipeline scheduling，这个 slack-aware pre-loading 策略可以直接参考。数值效果显著，值得读全文看细节。

本周活跃机构

SJTU 系（IPADS + Wei/Chen group）本周输出 2 篇，分别覆盖微内核和 GPU serving——系统领域的持续高产组。FlatCake 作者团队未标明机构（可能为企业方），但从 production Claude Code trace 的使用推测为 Anthropic 或紧密合作方。

LLM serving 系统的 OS 化趋势愈发明显。 本周 10 篇论文中有 4 篇（Rimuru / FlatCake / PhOSv1 / GearUp）直接处理 LLM serving 的内存管理、存储架构、GPU context 和调度问题——而这些工作几乎全部在借用经典 OS 概念：page pool + page table（Rimuru）、flat address space（FlatCake）、context dedup（PhOSv1）、DAG slack scheduling（GearUp）。LLM serving 正在成为 OS 研究的新 workload。

另一个值得注意的信号：FlatCake 使用了 production Claude Code trace + DeepSeek-V4-Flash，说明工业界真实负载正在进入学术论文的评估基准——这对学术-工业 gap 的缩小是好事。