will-change 无法真正通知 gpu 预留显存，仅触发浏览器创建独立图层；显存实际由底层图形 api（如 vulkan/metal）在首次绘制时按需分配，且需通过 webgpu 或 cuda 等直连运行时才能实现预分配与物理页绑定。

“层合成提升”本身不通知 GPU 预留显存缓冲区——它只是触发浏览器将元素提升为独立图层，而显存预留需由底层渲染引擎（如 Skia/Vulkan）或 GPU 运行时（如 CUDA、Metal）在实际绘制前动态完成。

为什么 will-change: transform 或 translateZ(0) 无法真正“通知”GPU 预留显存

这些 CSS 属性仅向浏览器的合成器（Compositor）发出提示，让其将该元素单独建一个绘图表面（composited layer），但它不传递任何显存大小、对齐方式或生命周期要求给 GPU 驱动。显存分配仍由渲染管线在帧提交（SubmitCommandBuffer）时按需触发，且通常使用默认分配器（如 Vulkan 的 VkMemoryAllocator 或 Metal 的 MTLHeap），不会提前锁定连续大块。

• 浏览器无权直接调用 cudaMallocAsync 或 vkAllocateMemory；它只能通过图形 API 封装层间接影响
• 所谓“独立缓冲区”，实际是纹理（Texture2D）或帧缓冲（Framebuffer）对象，其显存由 GPU 驱动在首次 glTexImage2D 或 vkCmdCopyBufferToImage 时才真正申请
• 若页面存在多个 will-change 元素，浏览器可能复用同一块显存区域（尤其在内存压力下），无法保证“隔离”

真正能控制 GPU 显存预留的路径：绕过浏览器，直连底层运行时

如果你需要在动画开始前就确保某段显存被独占、连续、不可抢占，必须脱离 CSS 合成流程，改用可编程渲染后端。典型场景是 WebGPU + 自定义内存池，或桌面端 Electron + ONNX Runtime + CUDA_MALLOC_ASYNC。

• WebGPU 中可通过 GPUDevice.createBuffer({mappedAtCreation: true, size: N}) 强制预分配显存，并用 GPUQueue.submit() 前确保 buffer 已绑定到 pipeline layout
• 在 Electron + CUDA 场景中，启动时执行：export CUDA_MALLOC_ASYNC=1 和 export CUDA_MALLOC_ASYNC_LIMIT_GIB=8，再初始化推理引擎——此时 ONNX Runtime 会从该预分配池中切出子块用于动画纹理缓存
• 注意：Chrome/Edge 当前 WebGPU 实现（2026 Q2）仍不支持显存池大小配置，必须依赖系统级环境变量或 native 插件桥接

容易被忽略的关键点：显存“预留” ≠ “已映射”

即使你成功调用 cudaMallocAsync 分配了 16GB 池，GPU 显存也并未真正“驻留”——它只是虚拟地址空间预留。只有当第一个 tensor 调用 torch.cuda.empty_cache() 后再触发 tensor.to('cuda')，驱动才会把物理页映射进 GPU 地址空间。动画帧生成若发生在映射前，依然会触发 page fault + fallback 分配，导致卡顿或 OOM。

• 验证是否真正映射：检查 torch.cuda.memory_allocated() 在动画启动前是否 > 0，而非只看 memory_reserved()
• Web 端更隐蔽：需监听 GPUAdapter.requestDevice() 完成后，立即创建一个 dummy GPUTexture 并 writeTexture 1x1 像素，强制驱动完成物理页绑定
• 桌面应用中，MTools 类工具会在主窗口 show() 前就执行一次空推理（如输入空字符串调用 TTS 模型），目的正是触发显存池热身