arXiv 系统方向追新 · 全部期次

arXiv 公告日 · 周五

2026-10-30

各分类条数
  • cs.OS 6
  • cs.PF 6
  • cs.PL 8
  • cs.AR 26
  • cs.DC 37
  • cs.NI 21
  • cs.DB 11
  • cs.CR 83
  • cs.SE 50

回补：候选来自 arXiv /list/<分类>/recent 列表页，摘要来自 arXiv API。

本期看点

推荐精读 1

推荐精读编译 · JIT · 运行时cs.SE

用 WebAssembly 组件做可移植、带沙箱的插桩工具

Write Once, Instrument Anywhere: Portable, Sandboxed Tooling with WebAssembly Components

Elizabeth Gilbert, Chris Fallin 等 4 人

在多语言系统里做监控和调试，工程师常被迫退到 eBPF 这类底层插桩机制，代价是只能看到字节和数据包、工具不可组合、功能分散，而且工具对程序和环境拥有不受限的访问权。作者提出 Splicer，一个 WebAssembly 组件插入框架：提供应用层语义类型，支持可插拔的工具，可跨语言和硬件移植，并把每个工具限制在显式授权的沙箱里。评估展示了用多种语言编写的复杂工具的可插拔性和性能，摘要没有给出具体开销数字。

参考价值同样是在用户态对应用做可扩展、受控的插桩：Splicer 用 Wasm 沙箱加显式权限，用户态 eBPF 运行时用 verifier，两种安全模型和开销值得对照。

  • WebAssembly
  • 二进制插桩
  • 沙箱与隔离
  • 追踪与可观测性
arXiv:2610.38682PDF

其余精选 6

agent 跑在无网卡的 microVM 里，每个出口都要审批并签名

安全cs.CE › Tracekit Box: Running AI Agents in Micro-VMs Where Every Way Out Is Decided and Signed

Bravish Ghosh

每个任务一个 Firecracker microVM，唯一出口是宿主机经 vsock 提供的几扇“门”：命令、外连、密钥、模型调用和代码补丁。agent 碰不到的签名器决定放行与否并签名留档；密钥不进 VM，只给占位符；结果打包成可离线验证的 .tkb。作者列出了局限，例如尚未使用 Firecracker jailer。MIT 开源。

  • 13 项端到端检查通过
  • 模糊测试修复 9 个问题
  • 20 页
  • AI Agent
  • 沙箱与隔离
  • 虚拟化与容器
  • 安全
arXiv:2610.38458PDF

把 serverless 推理里的模型加载藏进 DAG 的空闲时间

AI / LLM 系统cs.DC › GearUp: DAG-aware Acceleration for Serverless Inference Serving via Slack-guided Pre-loading

Qi Qi, Yifan Sui 等 5 人

每个 ML 节点要加载库、权重和 CUDA kernel，这些开销沿 DAG 路径累积在关键路径上。GearUp 先分析各节点的加载阶段，再放进上游执行暴露出的 slack 里做，并复用已初始化实例，用随流量自适应的概率式 keep-alive 平衡内存与冷启动。在 L40S GPU 上用两个真实工作流评估。

  • 中位延迟比 SMIless −64.5%～75.9%
  • GPU 内存比 eager 预加载 −83.9%
  • LLM 推理服务
  • GPU
  • 调度
arXiv:2610.38196PDF

让大量“休眠”模型共享 GPU 上下文，省下显存

AI / LLM 系统cs.DC › PhOSv1: Efficient Scaling of Model Sleeping on a Single Server for Autoscaling with GPU-Context Deduplication

Tianle Sun, Xingda Wei, Rong Chen

vLLM 和 SGLang 的 sleep mode 让扩容几乎零成本，但每个休眠模型都要常驻一份 GPU 上下文，模型一多显存就被吃掉。作者发现这些上下文高度重复：CUDA 上下文可以共享，kernel 二进制也大量重叠。PhOSv1 通过 API remoting 把上下文分配交给中心 daemon 统一去重。

  • 扩容速度与 vLLM sleep 持平
  • IEEE HPCC 2026
  • LLM 推理服务
  • GPU
  • 内存管理
arXiv:2610.39999PDF

用一个共享页池统一管理 LLM 服务的权重与 KV 等张量

AI / LLM 系统cs.OS › Rimuru: Unified Memory Management for Modern LLM Serving via Elastic Expert Offloading

Zhiyuan Fang, Dingyang Li 等 9 人

现有系统给权重和注意力状态各自固定预留显存，负载变化时无法互相挪用。Rimuru 建共享页池，用“内存视图”让每类张量按自己的页大小和页表解读同一空间，配合可拆分合并的多级页分配器和页表感知的 fused MoE kernel，在专家卸载和 KV 之间按负载动态调页。基于 vLLM。

  • 吞吐最高 19.03×
  • TTFT 平均 −98.1%
  • LLM 推理服务
  • 内存管理
  • GPU
arXiv:2610.40305PDF

100 ms 粒度、逐 GPU 的 LLM 训练与推理功耗数据集

资源管理与性能eess.SY › LLM-PowerTrace: A Dataset of Time-Resolved GPU Power Traces for AI Compute

Jiansheng Wang, Jaskeerat Singh 等 9 人

现有能耗基准只报焦耳每 token 之类的总量，很少公开时间序列。该数据集覆盖多种模型规模的微调和推理，扫描批大小、序列长度、精度、并行方式、并发、GPU 频率、量化等参数，附完整元数据，并定义了面向电网的指标和功耗缩放规律。

  • 采样间隔 100 ms
  • 数据与代码公开
  • 能耗
  • GPU
  • 基准与测量
arXiv:2610.38315PDF

KV cache 不再分层，DRAM 和 SSD 当作平级介质

存储 · 内存 · 文件系统cs.DC › FlatCake: A Flat KVCache Storage Architecture for LLM Serving

Xin Huang, Teng Ma 等 10 人

生产负载的复用呈两极：要么是复用距离很长的一次性块，要么是超出 DRAM 的大型 agent 会话，DRAM 作为中间缓存层基本失效。FlatCake 利用 KV 块写一次、不可变、按会话复用的特点，创建时就按会话连续、层优先的顺序直接落到目标介质，之后不迁移，并经 GPUDirect Storage 直读进 GPU。用 Claude Code 生产 trace 评估。

  • 命中率 94%（Mooncake 64%）
  • 峰值负载 TTFT 降低 1.6×
  • 消除 6.5× SSD 读放大
  • LLM 推理服务
  • 存储与文件系统
  • 内存管理
arXiv:2610.38355PDF
其余论文92 篇 · 只列标题