显存不够时不再靠缺页搬数据：Ember 把冷数据留在主机内存，超配下快过 UVM
导语
Ember 把统一虚拟内存的默认策略反过来：分配先映射到主机内存，只有被硬件访问计数器判定为热的区域才搬上 GPU，冷区域成批提前回收，让缺页与回收不再卡在计算路径上。
正文
Ember 让显存超配的应用不再依赖缺页来搬运数据，而是把分配默认映射在主机内存里，只把真正热的区域提升到显存。 此前的统一虚拟内存以缺页迁移为默认策略，一旦工作集超过显存容量，性能就会崩塌，生产系统因此要么手工编排放置策略，要么干脆关掉统一虚拟内存。 在超配条件下，Ember-static 在 RTX 5080、A40、H200 三块 PCIe GPU 的六个应用上相对原生 UVM 取得几何平均加速，Ember-adaptive 也取得相应加速。
它靠 GPU 的硬件访问计数器判断哪些区域值得搬上显存，并在显存填满之前成批把冷区域写回主机内存。 原生 UVM 不使用这些计数器，而是按缺页迁移，并在显存满后于关键路径上逐块回收，回收与执行交错会拖低 warp 占用率。 在 GH200 上，一个内核分八个阶段读取 8 GiB 托管缓冲区中的 1 GiB 窗口，窗口按固定比例前移；Ember-static 在热集不动时与预取持平，在完全漂移时仍优于所有基线。
接下来
Ember 面向显存被超配的独立 GPU，保持 UVM 的内存与编程模型不变，应用仍按原有方式分配托管内存并解引用指针。Ember-static 在原生驱动上以放置提示部署，不需要特权或裸机访问；Ember-adaptive 在 UVM 驱动内运行，需要硬件访问计数器以及管理员可加载模块的机器。它只处理通过 cudaMallocManaged 分配的内存，库内部自行分配的缓冲区不在其可见范围内。
Ember 无法直接观测已驻留区域是否变冷，只能根据提升前记录的访问需求随时间衰减来推断，因此仍热的区域可能被误回收并搬运两次。Ember-adaptive 需要裸机权限加载内核模块，且模块针对开源驱动的内部接口构建，每次新版本发布都需要重新适配。多 GPU 场景下对等显存构成第三层，尚未纳入设计。