GNStor: Design of GPU-Native High-Performance Remote All-Flash Array

Shushu Yi, Wenbo Wu, Guoci Chen et al. · 2026-06-03

🎯 核心问题
现有 GPU-AFA（全闪存阵列）系统中，所有远程 I/O 仍由 CPU 主导编排：CPU 负责发起 NVMe over RDMA 请求、执行集中式 AFA 引擎（访问控制、元数据持久化等）。这导致严重的 CPU-GPU 交互开销和 I/O 流量放大，GPU 算力被 I/O 等待拖累，端到端性能远未到硬件上限。

🔧 关键方法
GNStor 提出两个关键组件。第一个是 GNoR（GPU-centric NVMe over RDMA 软件栈），让 GPU 内核线程直接发起 NoR I/O 请求，绕过 CPU。GNoR 用原子操作做 I/O 编排，并遵循 GPU 的 SIMT 执行模型，充分利用大规模并行度。第二个是 deEngine，一种去中心化 AFA 引擎：把原本集中在 CPU 端的 AFA 级任务（访问控制、元数据等）分解嵌入到每块 SSD 固件中，实现 CPU 完全旁路的 AFA 访问。整体思路是"让 GPU 成为存储 I/O 的一等公民"。

📊 实验或论据
评测显示 GNStor 相比当前最优 AFA 系统实现了 3.2× I/O 吞吐量提升，应用执行时间减少 31.1%。论文使用真实的远程全闪存阵列硬件，通过 RDMA 网络连接 GPU 与 SSD 池。具体的 GPU 型号、SSD 数量与 workload 类型需查阅全文。

⚠️ 局限
deEngine 将 AFA 逻辑下推到 SSD 固件，这意味着需要固件层面的定制支持，通用商用 SSD 无法直接使用。此外，GNoR 的原子操作编排在 GPU warp 竞争激烈时的扩展性表现尚不清楚。

💼 对系统人的启示
这是 GPU-native storage 方向的实质性推进。如果你在做 GPU 集群的大规模数据加载（AI 训练、HPC），GNoR 的 CPU-bypass I/O 路径思路非常值得借鉴。但落地门槛在固件定制——短期更适合有自研 SSD 能力的厂商。

AgileOS: A GPU Operating System Layer for Protected CUDA Services

Zhuoping Yang, Yiyu Shi, Alex Jones, Peipei Zhou · 2026-06-04

🎯 核心问题
现代 GPU 应用越来越多地与存储系统、网络设备、厂商库和 GPU 常驻服务交互，但 CUDA 编程模型默认把整个 CUDA context、设备指针、运行时句柄全部暴露给应用 kernel。受保护的 GPU 服务只能各自实现 ad hoc 的隔离方案，缺乏统一的 OS 级保护层。

🔧 关键方法
AgileOS 在 CUDA 库边界做虚拟化：应用链接到客户端 shim 库（Runtime / Driver / cuFFT 等），真正的 CUDA context 由可信的 runtime worker 持有并代理操作。核心隔离手段是 GPU 内存管理模型——将用户分配与受保护的 module/MMIO 区域分离，通过指针验证和 PTX 注入（在 PTX IR 层面插入 memory access guard 指令）实现运行时内存访问检查。原型包含客户端拦截器、worker 侧 CUDA 处理器、虚拟化的 CUDA 对象表、受保护模块和 GPU 内存管理器。

📊 实验或论据
论文称原型支持 cuFFT 和 PyTorch 等现有库，验证了模块化保护的可行性。但 abstract 中未提及具体性能数据（吞吐开销、延迟增加比例）或对比 baseline。需阅读全文确认 overhead 评估。

⚠️ 局限
PTX 注入的内存访问检查会引入运行时开销，对计算密集型 kernel 的影响程度不明。此外，该方案高度绑定 CUDA/NVIDIA 生态，对 AMD ROCm 或 Intel oneAPI 不适用。论文自称是"初始设计和原型范围"，成熟度有待验证。

💼 对系统人的启示
GPU 上的 OS 抽象一直是空白地带，AgileOS 提出了一个务实的切入点——在库边界做虚拟化而非改硬件。如果你在做多租户 GPU 共享或 GPU 服务化（MIG 之外），这个方向值得关注。PTX 注入做内存保护的思路对 GPU 安全研究有启发。

Agent libOS: A Library-OS-Inspired Runtime for Long-Running, Capability-Controlled LLM Agents

Yingqi Zhang · 2026-06-02

🎯 核心问题
LLM agent 正在从请求-响应助手演变为长时运行的软件实体：它们跨调用维护状态、分叉子任务、等待外部事件、请求人类授权、生成工具并执行带副作用的操作。但目前的 agent 框架把 tool dispatch 当作信任边界，缺乏调度、授权、恢复和审计的系统级抽象。

🔧 关键方法
Agent libOS 借鉴 library OS 思想，在常规宿主 OS 之上运行（不涉及硬件驱动或内核态隔离）。核心抽象是 AgentProcess：一个可调度的执行主体，拥有进程标识、父子谱系、生命周期状态、从 AgentImage 派生的 tool table、类型化的 Object Memory、显式 capability、human-in-the-loop 队列、checkpoint、事件和审计记录。设计准则是"tools 是 libc 式包装，运行时原语才是权限边界"——文件访问、对象访问、sleep、人类审批、JIT 工具注册等都在原语边界通过 capability 和策略检查。原型包含 Deno/TypeScript JIT 工具、syscall broker、异步调度器和资源提供者基座。

📊 实验或论据
Python 原型已实现异步调度、命名空间本地 Object Memory、运行时集成的人类审批、一次性权限授予、shell 与镜像注册原语等。评估侧重安全特性验证而非性能：包含确定性 demo、真实模型 smoke 测试和 123 个回归测试。没有与其他 agent 框架的性能/安全对比基准。

⚠️ 局限
论文明确声明不改善 planner 准确性，不实现 POSIX 兼容，也不做内核态隔离——这是一个纯用户态的 Python 原型。与生产级 agent 框架（LangGraph、CrewAI 等）的集成和实战表现未验证。capability 模型的表达力和可用性在复杂多 agent 场景下存疑。

💼 对系统人的启示
这篇论文的核心贡献不在性能，而在**把 OS 概念映射到 LLM agent 运行时**这个方向上的思考框架——进程模型、capability、checkpoint、审计。如果你在做 agent 基础设施且关心安全审计，Agent libOS 的抽象设计值得一读。但它离工程落地还有距离，更像一篇 position paper + 原型验证。

CarbonSim: A Lifecycle-Aware Framework for Evaluating Carbon Tradeoffs in Hardware Upgrade Decisions

Kartik Hans, Kaiwen Zhao, Stephen Lee · 2026-06-04

🎯 核心问题
更新的硬件通常有更高的能效，但换硬件本身有隐含碳成本（制造、运输、报废）。在低利用率或低碳电网场景下，提前更换硬件不一定减少总碳排放。现有决策缺乏一个将运行碳、隐含碳、电网碳强度和工作负载特征统一考量的框架。

🔧 关键方法
CarbonSim 是一个生命周期感知的仿真框架，整合五个维度：工作负载执行特征、机器级功耗参数、隐含碳清单、调度策略、和时变电网碳强度。框架支持多种隐含碳核算策略——均匀摊销和前置归因（front-loaded lifecycle attribution），以分析不同硬件寿命假设下的排放。使用异构 CPU 代际作为标定平台进行验证。

📊 实验或论据
实验表明新机器并非总是最小化总排放：在轻负载或清洁电网条件下，延长现有硬件使用寿命可减少生命周期碳排，即便运行效率更低。具体的 CPU 代际、电网数据来源和 workload 类型需参阅全文。

⚠️ 局限
框架基于仿真而非实际数据中心部署验证。隐含碳数据依赖于公开清单的准确性，不同供应商差异较大。此外，仅以 CPU 代际为标定平台，对 GPU/加速器场景（隐含碳远高于 CPU）的适用性未探讨。

💼 对系统人的启示
这不是传统 OS 论文，但对数据中心运维决策有直接参考价值。如果你在大规模集群做硬件采购规划，CarbonSim 的分析框架可以帮助量化"该不该换"。核心 takeaway：低利用率 + 清洁电网时，延寿比换新更绿色——这与直觉相反。

本周 4 篇论文涉及 4 个独立团队，无交叉合作。

观察：本周 4 篇中有 3 篇主分类不是 cs.OS（分别为 cs.CR、cs.DC、cs.OS），仅 GNStor 和 Agent libOS 以 cs.OS 为主分类。这反映出 OS 研究越来越多地与安全、分布式系统、AI 交叉融合。

GPU 正在从"计算附件"变成"系统主体"。

本周 4 篇论文中 2 篇（GNStor、AgileOS）直接围绕 GPU 构建 OS 级抽象——一个让 GPU 绕过 CPU 直接访问远程存储，另一个在 GPU 上构建服务保护层。这不是巧合：随着 GPU 承载的工作从"跑 kernel"扩展到"跑服务"，传统的 CPU-centric I/O 路径和安全模型已成为瓶颈。GPU 正在需要自己的存储栈、内存管理和隔离机制——换言之，GPU 正在需要自己的 OS。

OS 概念向 LLM agent 运行时迁移。 Agent libOS 将进程、capability、checkpoint 等经典 OS 抽象应用于 LLM agent 生命周期管理，这呼应了业界"agent 即进程"的新兴共识。虽然目前只是原型阶段，但 OS 社区的经验（调度、隔离、审计）对 agent 基础设施建设有直接借鉴价值。