Offering Microsecond-Scale Cross-VM Core Elasticity on Colocated Lightweight Virtual Machines

Yibo Yan, Seo Jin Park · 提交日期 2026-08-12

🎯 核心问题
Serverless 场景需要在密度和尾延迟之间取得平衡。当延迟敏感型 VM 出现流量突发时，需要在微秒级别将物理核从空闲 VM 迁移到繁忙 VM。现有方案要么热插拔 vCPU 需要毫秒级（KVM），要么在启动时固定核数（Firecracker），要么根本不支持多核（最轻量的 ultralight VM）。

🔧 关键方法
HyperFlux 基于 commodity KVM 构建，使 VM 的并行宽度（backing 物理核数量）在运行时弹性可调。核心机制是绕过传统 vCPU hot-plug 路径，实现 13μs 的跨 VM 核迁移——即便从繁忙的 donor VM 强制回收。VM 冷启动 1.37ms、内存开销仅 3.2MB，与最快的 ultralight VM 持平，但独特地支持多核并行执行。

📊 实验或论据
与 Firecracker 和 Cloud Hypervisor 的静态核共享对比，高负载下高优先级 VM 尾延迟降低 10×。与 cgroup + vCPU hot-plug 方案对比，在变化突发负载下尾延迟更低且更稳定。评估在 colocation 场景下进行。

⚠️ 局限
依赖 KVM 作为底层 hypervisor，尚不清楚在非 x86 架构或嵌套虚拟化场景下表现如何。13μs 的迁移延迟是否能在核数更多的 NUMA 拓扑下维持未被讨论。

💼 对系统人的启示
这是 serverless 基础设施层的实质性突破。如果你在做 FaaS 调度或 VM 密度优化，HyperFlux 的"运行时并行宽度弹性"是一个新维度——不再需要在"给够核防尾延迟"和"省核提密度"之间做静态权衡。

CoRun: Padding is Simple and Efficient for Deterministic LLM Inference

Shiju Zhao, Jiacheng Yang, Qihang Chen et al. · 南京大学 · 提交日期 2026-08-14

🎯 核心问题
即使固定采样参数和随机种子，LLM 推理仍会出现输出不一致——根源是 batch-dependent GPU 执行：动态输入形状改变了 kernel tiling 和浮点归约顺序。现有 batch-invariant kernel 方案虽确保确定性，但引入 2× 以上延迟增长、吞吐下降 74%。

🔧 关键方法
作者观察到：大多数 kernel 虽非 batch-invariant，但是 position-invariant——同一位置的 token 无论 batch 中其他 token 如何变化，其计算路径不变。CoRun 利用这一性质，通过隔离 prefill 阶段 + 固定形状的 batched decode，配合 CUDA Graph 缓存执行计划，在调度层面实现确定性，无需修改底层 kernel。

📊 实验或论据
在 Qwen 和 DeepSeek 等多种架构上评估。相比 batch-invariant 方案：吞吐提升 15–324%，TTFT 降低 51.8%，TPOT 降低 48.6%。确定性得到完整保证。

⚠️ 局限
fixed-shape batched decode 本质是 padding——在 batch 利用率低时会浪费 GPU 算力。当请求到达模式极度不均匀时，padding 开销可能抵消调度收益。此外 CUDA Graph 的静态性意味着无法动态调整 batch 大小。

💼 对系统人的启示
如果你的 LLM 评估或 RL 训练流水线受困于不确定性输出，CoRun 提供了一个"不牺牲性能也能确定"的工程路径。position-invariance 的观察本身就值得内化——它暗示着 GPU kernel 的确定性约束可以被大幅放宽。

The Ingestion Tax: Adopting File-Backed Weights in Tensor Frameworks

Yuan Si, Yufeng Lin, Daming Li, Jialu Zhang · 提交日期 2026-08-12

🎯 核心问题
在集成/一致性内存系统（如 Apple Silicon、NVIDIA GH200）上，模型权重作为文件页已经驻留在 GPU 可读的地址域中，但框架（PyTorch/MLX）仍然要拷贝到自己管理的分配中。这笔"ingestion tax"——OS 持有 clean evictable file pages，硬件使其 GPU 可读，只是框架的所有权模型横在中间。

🔧 关键方法
file-backed weight adoption：producer 用 MAP_SHARED 映射每个 tensor，包装为 no-copy GPU buffer，通过 DLPack capsule 导出给 PyTorch/MLX 作为普通 storage 导入。关键是一套三部分执行契约（读映射、激活驻留加速器、GPU 上排序），违反后两项会慢 2.3×。契约满足时，adoption 完全消除 ingestion tax，达到 516 GB/s（默认构造器仅 53–82 GB/s）。

📊 实验或论据
Qwen2.5-72B: 7.14 vs 7.23 tok/s（与 resident storage 持平，[-0.66%, +0.48%]）。多进程场景：N 进程共享一份映射 vs N 份 resident loading（满载时 5.5 vs 0.08 tok/s）。65GB checkpoint TTFT 快 6.4×。Kimi K3 spine 从 2.62s → 0.35s/token（3.8×）。llama.cpp 在 AMD APU 上 1.21× 提升、占用减半。PCIe 拓扑下则慢 39×——内存拓扑决定一切。

⚠️ 局限
仅在一致性内存拓扑下有效（Apple Silicon、GH200 等）；PCIe 连接的离散 GPU 完全不适用（39× 性能回退）。这意味着在 NVIDIA A100/H100 + PCIe 主流数据中心配置下此方案无用。

💼 对系统人的启示
对 Apple Silicon / GH200 部署场景，这是"把 page cache 当作一等 accelerator storage tier"的完整论证。核心 insight：OS 已经替你做了 LRU + eviction + shared mapping，框架再做一次是浪费。如果你在统一内存设备上部署大模型，直接用。

Who Should Own the Expert Cache? Kernel-Managed Tiering for Trillion-Parameter MoE Inference

Yuan Si, Yufeng Lin, Daming Li, Jialu Zhang · 提交日期 2026-08-12

🎯 核心问题
MoE 模型的 expert pool 远超 DRAM 容量（万亿参数模型 1.45TB expert pool），所有 serving 系统都需要 expert cache。现有系统通常在用户态实现 expert-granular、frequency-ranked、显式 pinned 的分层缓存。但 OS page cache 天然提供了同样的能力——问题是：用户态 expert cache 真的比内核 LRU 强吗？

🔧 关键方法
作者将 page cache 直接用作 expert tier，在 GH200 节点上用三种独立机制强制容量约束，replay 三个 MoE 模型（128–896 experts/layer）的 router traces。核心对比：untuned kernel LRU vs. same-domain oracle frequency table。MGLRU + balloon-style mostly-mlocked memory 的组合会引入 reclaim artifact（deep-pressure knee），但 cgroup limits 和物理内存配置则不会。

📊 实验或论据
256GB 等容量约束下：kernel LRU hit rate 75.3% vs oracle frequency table 74.6%，oracle 机制优势仅 1.09×，且 off-domain 时消失（LRU 保持 70–71%）。Router lookahead（64.7% recall）作为 readahead advice 仅贡献 0.3%，作为同步 prefetch 无收益。端到端 decode 性能提升 1.09–1.10×，token-identical 输出。

⚠️ 局限
评估限于 GH200 统一内存节点。balloon-based 研究会高估 2× 的 device traffic 是重要发现，但也意味着此前文献中的数字需要重新审视。内核 LRU 的"足够好"结论是否在更大模型或更极端容量比下仍然成立，需进一步验证。

💼 对系统人的启示
设计原则极为清晰：在这个 regime 下，让内核管 eviction，模型特定知识花在 admission 和 advice 上。如果你在做 MoE serving 且在犹豫要不要写复杂的用户态 cache——先试 kernel page cache，很可能已经够用。这也是"不要重复造 OS 已经造好的轮子"的又一例证。

vToken: Token-Level Virtualization for Reclaimable KV Caches

Yuanhang Gao, Xiangrui Yang, Yuanfeng Chen et al. · 提交日期 2026-08-13

🎯 核心问题
PagedAttention 用固定大小 block 管理 KV cache，减少了分配器级碎片。但最近的 KV eviction 算法（H2O、Scissorhands 等）以 token 粒度驱逐，比 block 粒度更细。这导致 intra-block fragmentation：block 内大量 dead tokens 无法回收，浪费了已分配的 KV 内存。

🔧 关键方法
借鉴 OS 虚拟内存的思路，vToken 在 logical token liveness 和 physical block placement 之间引入一层 token-table indirection（类似页表）。逻辑视图保持稳定，物理层通过异步 repacking 回收 dead tokens 占据的空间。设计兼容 PagedAttention kernel 和 CUDA Graph。实现在 vLLM 中，将每个 eviction policy 的集成代码从 500+ 行降到 50 行以下。

📊 实验或论据
与 Naive-Evict baseline 对比：每请求 retained KV blocks 减少 27.2%–72.3%，SLA-constrained throughput 提升最高 1.37×。受限 active-KV budget 下，最大可行并发扩展 2×。在 H2O、Random、Scissorhands 三种策略上均验证。

⚠️ 局限
token-table indirection 引入查表开销（虽然作者称 lightweight）；异步 repacking 的触发时机和延迟是否在极端高并发下成为瓶颈，abstract 未详述。primary_category 为 cs.AI，OS 味道主要体现在虚拟化抽象的借用上。

💼 对系统人的启示
经典 OS 概念（虚拟内存 + 间接层 + 异步 compaction）在 GPU 内存管理中的又一次成功复用。如果你在做 LLM serving 的内存管理，vToken 的 token-table 是一个可以直接借鉴的工程模式——特别是当你需要支持多种 eviction policy 而不想每次改 kernel 时。

MemSpec: Memory-Aware Runtime for Adaptive Draft Scheduling in Speculative Decoding on Edge Devices

Eunjeong Kim, Yeong Jun Jeon, Myeonggyun Han · 提交日期 2026-08-11

🎯 核心问题
Speculative decoding 通过轻量 draft model 预测多 token 来加速 LLM 推理。自适应方法会根据输入动态选择 draft model，但在内存受限的边缘设备上，切换 draft model 的加载开销往往抵消了选择收益——draft selection 和 draft availability 之间存在 mismatch。

🔧 关键方法
MemSpec 将 draft selection 与 execution 解耦：一个轻量预测器根据 prompt 和生成上下文估计各 draft model 的效果，一个 memory-aware scheduler 主动管理 resident working set（类似 OS 的 working set 管理），进行 proactive 加载以减少 reactive model loading 开销。核心是"预测即将用到的 draft 并提前驻留"。

📊 实验或论据
在 Jetson Orin Nano 上评估。相比 SOTA bandit-based 自适应方法，steady-state generation throughput 平均提升 40.7%，且接近 oracle 上界。

⚠️ 局限
仅在单一边缘平台（Jetson Orin Nano）评估，未涉及其他内存约束设备（手机 SoC、Raspberry Pi 等）。预测器的准确性在分布外 prompt 上的退化情况 abstract 未提及。

💼 对系统人的启示
边缘 LLM 部署的实际工程问题：内存不够时，选最好的 draft 不如选"已经在内存里的次好 draft"。MemSpec 的 proactive working-set management 思路对任何需要在内存受限环境下做模型切换的场景都有参考价值。

本周亮点：Yuan Si 团队一周连发两篇 OS-for-LLM 论文（Ingestion Tax + Expert Cache），形成完整论证链——page cache 不仅可作为权重存储层，还可作为 MoE expert 缓存层。这是一个有明确系统观点的持续输出团队，值得关注后续工作。

OS 正在成为 LLM 推理的性能关键层。本周 8 篇中有 7 篇直接与 LLM 推理相关，且切入角度全部是系统层面的：GPU 调度（CoRun）、内存虚拟化（vToken）、VM 弹性（HyperFlux）、page cache 复用（Ingestion Tax + Expert Cache）、edge 内存管理（MemSpec）、GPU 控制路径（Ready Cohorts）。

两个值得注意的信号：

• "让 OS 做它擅长的事"——Expert Cache 和 Ingestion Tax 的共同论点是：内核 LRU / page cache 已经够好，用户态重写是过度工程化。这种"回归 OS"的设计哲学可能代表一种风向转变。
• 统一内存改变游戏规则——Ingestion Tax 在 GH200/Apple Silicon 上的 dramatic 收益 vs PCIe 上的 39× 性能退化，暗示 LLM 推理系统的最优设计正在分叉：一致性内存架构 vs 离散 GPU 架构需要完全不同的系统设计。