Characterizing Predictability-Latency Trade-offs of KV-Cache SSD Offloading in LMCache for LLM Serving Systems

Ying He, Dingsen Shi, Yanbo Dai (+ et al.) · 未明示机构，工作围绕 LMCache/vLLM · 提交 2026-10-15

🎯 核心问题
LLM serving 中 KV-cache offload 到 SSD 已是常规手段，但"它落到 block-device 层到底表现如何"一直缺少系统级刻画。本文要回答的不是"谁更快"，而是 buffered I/O + page cache 路径与 O_DIRECT + dedup 路径之间的 predictability / latency 取舍，这是部署方真正要做的选型决策。

🔧 关键方法
作者用 LMCache 0.3.0（buffered I/O + kernel page cache）与 0.3.16（prefix-aware dedup + O_DIRECT）两个真实可部署快照做对照观测，而非析因实验。工作负载覆盖 same/different context × same/different prompt 四类，每类 100+ 个 stateless 请求。关键手法是 flush_ram 实验——主动驱逐 page cache 来暴露"看似免读"路径的真实 SSD 读代价。

📊 实验或论据
在四种工作负载上观测：legacy 栈在 SSD 层几乎"零读"，但 flush 后单路径会发出约 1 GB 顺序读、耗时 683 ms；dedup 仅在 exact-repeat 工作负载上把写从 1.62 GB 压到 11.75 MB，其余三组仍在 2–5 GB；O_DIRECT 把隐藏的双峰读代价变成显性稳定代价——一组上 warm TTFT 从 27 ms 涨到 93 ms，因为 99 个 warm 请求各自重读同一 ~12 MB partial chunk。

⚠️ 局限
📄 abstract 未提及具体硬件型号与 LMCache 部署拓扑细节；观测性结论基于两个版本快照，不构成析因，外推到其他 offload 引擎（如 vLLM 原生 prefix cache）需谨慎。

💼 对系统人的启示
这篇是"升级前必读"——它定量告诉你：新版 LMCache 用 O_DIRECT + dedup 换掉了 page-cache 的隐式红利，换来可预测但更稳的读代价。做 LLM 推理存储栈的工程师可据此判断自家负载是 exact-repeat 多（上 dedup 省写）还是 prompt 多样（保留 buffered 路径吃平均延迟红利）。

Range: Decoupling KV-Cache Reuse Granularity from Storage Work

Dingsen Shi, Jiahao Zhang, Liqiang Lv (+ et al.) · 与上篇同作者群 · 提交 2026-10-15

🎯 核心问题
KV-state restore 已在 TTFT 的关键路径上，但作者发现真正的瓶颈不是 SSD 带宽，而是"每逻辑对象都收一次税"——lookup、allocation、I/O submission、GPU 投递、store、index 每一层都按对象数计费，而字节数不变。上下文变长、模型变深、tensor parallelism 都在成倍放大对象数。现有方案把这份 per-object 工作从 CPU 搬到 GPU，但"按对象计费"本身没消除。

🔧 关键方法
Range 的原则是：存储路径上每个代价只随字节或物理 batch 缩放，绝不随逻辑对象。Range tickets 用 token metadata + physical leases 替代 per-key lookup/ownership；byte stripes 让 on-media 布局与 reuse 粒度解耦；completion-owned GPU transfer banks 批量投递与抽取，每层落到 GPU 即交给 attention。仍走 kernel cuFile 路径，只改 vLLM 四行。

📊 实验或论据
固定 6 GiB restore：Range 的 median TTFT 在 32× 对象数范围下稳定在 1.79–1.80 s，距 prefix 已在 GPU 显存中只差 70 ms；调优过的 in-process LMCache 从 2.12 s 退化到 3.01 s。在粗粒度上比最快的 multiprocess DRAM-bounced 路径快 0.44 s，且不走 host memory；在 layerwise 复用下仍以粗粒度复用为代价守住性能，而最佳 stock 路径要 2.24 s。

⚠️ 局限
📄 abstract 未列硬件配置与对照基线版本；"layerwise 复用以粗粒度复用为代价"暗示存在粒度-延迟取舍，是否影响细粒度复用的命中率需读全文确认。

💼 对系统人的启示
这篇对存储/系统工程师非常有借鉴价值：把"按逻辑对象计费"重构为"按字节计费"的思路可迁移到任何高扇出 I/O 路径（不只是 KV-cache）。只改 vLLM 四行 + 保留 cuFile 的工程克制也意味着落地成本可控，值得花 30 分钟读 PDF。

Where the SRAM Goes: Per-Symbol Attribution of Static Memory in FreeRTOS-C and Embassy-Rust IoT Firmware on a 64 KB RISC-V Microcontroller

Romi Fadli, Jan Everhard Riwurohi, Wahyu Ramadani Putri Utami · 未明示机构 · 提交 2026-10-15

🎯 核心问题
内存受限 MCU 选型固件栈通常只看聚合 binary size——知道吃了多少 SRAM，但不知道"花在哪、为什么花"。本文要给 per-symbol 归因方法，把静态 RAM 拆成 scheduler heap、network buffers/pools、task stacks、linker-reserved regions 等架构类别，让选型从"看总数"升级到"看分布"。

🔧 关键方法
作者将 sized ELF symbols bound 到 .data / .bss / .stack section 区间，做架构级分类；用"每个类别之和必须与 size 工具的总数完全对账"作为验证闭环——16 个 build 全部对账成功。工作负载是 8 个累积固件里程碑（从裸 task scaffold 到完整 MQTT-over-Ethernet client），在 FreeRTOS-C 与 Embassy-Rust 两套实现下各做一遍，平台为 CH32V203RBT6（RISC-V，64 KB SRAM，片内 Ethernet MAC+PHY），每个里程碑在硬件上验证功能对等。

📊 实验或论据
两套栈在 networking 上的 RAM 占比几乎相同（63.8% vs 63.9%），但绝对代价差 4.4×：lwIP 40,719 B vs smoltcp 9,316 B。FreeRTOS task stack 每任务约 1 KB 线性增长，Embassy async state 随状态机复杂度增长。lwIP 在全静态纪律下无法集成，需 20 KB arena，而 smoltcp 不需要。测量 harness、归因工具、16 个固件实现均作为 artefact 发布。

⚠️ 局限
📄 abstract 未覆盖动态内存（运行时 heap 使用）与中断/ISR 栈；结论绑定单一 RISC-V 平台与特定 lwIP/smoltcp 版本，外推到 STM32/ESP32 等需重测。

💼 对系统人的启示
对嵌入式 / RTOS 工程师是实操工具文：归因方法（ELF symbol → section 区间绑定 + 对账闭环）可直接拿来用，且 artefact 已开源。Embassy async 状态机的内存增长特性对评估 Rust 在 64 KB 级 MCU 上的可行性是关键数据。

Towards Virtual Networking for a Time-Triggered Hypervisor

Jan Ruh, Silviu S. Craciunas, Jan Korecky · 推测为 ACRN / 实时系统研究组 · 提交 2026-10-13（primary: cs.NI）

🎯 核心问题
虚拟化让 mixed-criticality 应用共享硬件，但给 VCPU 上的关键任务提供端到端时序保证、又不依赖静态分区，非常难。作者想用 time-triggered hypervisor 按 predetermined global schedule 调度 VCPU，把计算、网络、虚拟化层一起在 design time 锁定，从而跨 host 跨 VM 给端到端时序保证。本文聚焦其中"网络"这一环。

🔧 关键方法
作者提出基于 VirtIO 的虚拟网络，实现 IEEE 802.1Qbv quasi-compliant 的 inter-VM 通信，为 time-triggered VM 间的关键消息提供可预测时序。从设计性质推导出 network-level scheduling constraints。实现在 ACRN hypervisor 上，评估加负载网络下关键流量的端到端延迟。

📊 实验或论据
在加负载网络下，time-triggered VirtIO-net 原型保持关键流量的可预测端到端延迟。📄 abstract 未给出具体延迟数字、对比 baseline 与硬件平台细节，需读全文。

⚠️ 局限
📄 abstract 未提具体延迟数值、未列 baseline、未说明 802.1Qbv "quasi-compliant" 的具体偏差；time-triggered 调度对全局时钟同步有强依赖，工业部署代价未讨论。

💼 对系统人的启示
对做实时虚拟化 / 工业 hypervisor 的工程师有参考价值——把 TSN (802.1Qbv) 思路下沉到 hypervisor 内部 inter-VM 通信，是 mixed-criticality 场景的合理路径。但本周数据偏 NI，OS 工程师可作跨界参考，不必优先深读。

本周 4 篇中有 2 篇都聚焦 LLM serving 的 KV-cache SSD offload 存储栈，且出自同一作者群连续两天放出 characterization + 系统设计，这是 cs.OS 上 LLM 推理系统化研究正在形成小气候的信号——问题已从"能不能 offload"演进到"per-object 计费模型 vs per-byte 计费模型"这种系统抽象层面的争论。嵌入式方向则有 ELF 符号级 SRAM 归因方法把选型从经验判断推向可对账工程流程。整体看 cs.OS 仍以"LLM serving 系统栈"为最活跃子领域，嵌入式/实时虚拟化为辅。