2026 年 11 月 14 日，ONNX Runtime 发布 CUDA 插件 0.4.0，集成 CPU/GPU 混合专家卸载，让受支持的 MoE 模型根据显存条件安排专家计算。为本地 AI 或工作站应用部署模型的开发者，可以评估把部分专家交给 CPU 执行的方案。本文说明这种分工如何运作，以及版本配套、内存预算和完整任务延迟该怎样核对。官方发布记录

CPU 与 GPU 协同执行 MoE 专家计算的原创 AI 概念示意

[配图建议：CPU 与 GPU 分担专家计算，旁边呈现主机内存 + 暖色纸面上的硬件概念插画]

先确认版本配套，再判断模型能否接入

MoE 将部分计算分给多个专家，每个 token 按路由选择其中一些参与。部署时仍要为专家权重找到存放位置。已有 ONNX 模型的团队，可能遇到模型文件可以保存、显存却容纳不下全部专家的情况。专家卸载提供了按机器资源安排执行位置的路径。

本次插件发布于北京时间 11 月 14 日 14:34，配套核心版本为 ONNX Runtime 1.32.0。基础会话规划代码在 10 月 31 日合并，CPU/GPU 执行后端在 11 月 1 日合并，0.4.0 将相关能力纳入正式插件版本。规划器 PR 执行后端 PR

这项卸载能力需要配套的 1.32.0 核心。发布说明给出的插件最低核心版本是 1.24.4，而专家初始化位置管理等新能力依赖较新的核心。官方还建议核心与插件按同一源码修订构建，使贡献算子的定义保持匹配。部署记录应同时保留核心、插件、模型导出与量化版本。版本兼容说明

对标准 com.microsoft::QMoE 节点，固定版本文档列出了 NVFP4、预打包 INT4/INT2、原始 INT3 等支持布局，并附打包标记和分块条件。接入前先检查模型节点、权重布局和设备条件，才能确定已有模型包是否适用。固定版本架构文档

[配图建议：核心、CUDA 插件、ONNX 模型三个版本记录相互对应 + 简洁的工程笔记信息图]

热门专家留在 GPU，冷门专家按阶段处理

混合执行会为每层安排 GPU 中的专家槽位，热门专家优先驻留。逐 token 生成答案时，路由命中的冷门专家可以交给 CPU，GPU 同时处理驻留部分，随后合并结果。随着访问情况变化，默认的自适应放置策略还会调整专家驻留位置。混合执行实现 PR

输入提示词的预填充阶段采用另一条路径。它会把冷门专家分批送往 GPU，分波执行计算。因而，长报告输入和短问题逐字输出可能呈现不同的资源瓶颈。试点应分别观察首字等待与后续生成速度，再看用户拿到完整答案需要多久。固定版本 CUDA 算子说明

CPU 端采用能直接读取共享量化布局的内核，相关实现提供 AVX-512 与 AVX2 等路径。主机内存紧张时，还可以通过有界专家缓存和权重文件映射管理冷门专家。此时机器的 CPU、内存与存储读入，也进入了推理过程。CPU 共享布局实现 CPU 内核文档

例如，同一台工作站既承担模型推理，又运行文档索引。分担专家计算后，索引任务可能与推理争用 CPU 和内存带宽。这里需要实测两项任务并行时的完成时间，观察这种部署方式是否符合自己的使用节奏。

[配图建议：预填充分波传输、生成阶段 CPU/GPU 并行两条路径 + 标注清楚的双行流程图]

专家预算之外，还要为缓存与工作区留空间

配置中的 device_expert_bytes 管理专家驻留及相关结构的 GPU 预算。模型运行还会使用临时工作区、KV 缓存、状态和图捕获相关内存。固定版本配置提供了分别管理这些用途的入口，预算规划需要结合整个会话的实际分配。固定版本会话预算说明

下表列出三个适合先核对的配置项，键名均带 session.moe.offload. 前缀。

配置项 预算或预留范围
device_expert_bytes GPU 中的专家驻留、备用槽位与查找结构
reserve_device_bytes 自动专家预算计算时，为后续 KV、状态等用途留出的空间
gpu_device_mem_limit 经该会话 CUDA 分配器进行的设备分配上限

第三项需要在会话创建前设置，范围涵盖分配器管理的内存池增长及卸载缓冲。官方注明它与外部 CUDA 分配器或 CUDA 内存池的组合存在使用限制。应按实际分配路径核算边界，并观察进程级显存峰值。固定版本配置键定义

权重文件大小、专家预算和运行峰值应分别记录。可以先使用项目原有上下文长度与并发设置，测量短问题、长输入和连续多轮三类任务。再逐项改变专家预算，查看显存、主机内存与完整回答耗时如何变化，保留能稳定复现的一组配置。

[配图建议：专家权重、KV 缓存、临时工作区分别占用容量 + 无虚构数值的内存结构示意图]

从一个已有模型会话开始试点

已有兼容模型和 CUDA 执行环境的团队，可以先准备下面的会话配置，再接入工程原有的会话创建入口。片段只展示卸载选项，模型路径、插件注册和生成循环沿用项目对应版本的实现。

import onnxruntime as ort

session_options = ort.SessionOptions()
session_options.add_session_config_entry(
    "session.use_device_allocator_for_initializers", "1"
)
session_options.add_session_config_entry(
    "session.moe.offload.mode", "auto"
)
session_options.add_session_config_entry(
    "session.moe.offload.placement", "adaptive"
)

auto 会在可用显存足够时让专家全部驻留 GPU，容量不足时尝试混合卸载。需要显式验证准入条件的工程可以研究 required，遇到节点不满足条件或最低容量不足时，会话创建会失败。失败记录能帮助定位模型布局或预算条件。固定版本配置与示例

本版还提供可选的尾部专家跳过和替换策略，默认关闭。它们会改变路由结果，评估时应单独记录这些开关，并核对输出质量。试点起步时保留默认路由，再比较资源分配方案，有利于解释差异来自哪里。近似路由实现与作者验证范围

这条路径适合已有 ONNX 部署工程、受到显存容量限制且愿意调配 CPU 资源的团队。可以用一条真实任务记录模型加载、首字、答案完成、资源峰值和答案核对结果，再决定是否扩大使用范围。

[配图建议：一次试点记录输入长度、资源峰值与任务完成时间 + 清晰的技术实验记录插画]

今天先保存一份完整的资源记录

选一个现有 MoE 模型，先核对核心与插件版本、算子布局，再在独立测试会话中检查卸载是否准入。把一条真实问题的完整回答、内存峰值和耗时一起保存，便于判断 CPU/GPU 分工是否满足自己的任务。尚未准备 ONNX 模型包的读者，可以先从导出与算子支持核对入手。

你的本地 AI 目前更受显存容量、长输入等待，还是多任务争用影响？这三种情况会影响试点的输入选择和资源记录重点。

核查时间为北京时间 2026 年 11 月 15 日。本文依据官方发布、PR 与固定版本文档和源码阅读整理，配置为接入片段，场景与试点安排为应用分析，性能与资源占用留待具体环境测量，封面为原创 AI 概念示意。

[配图建议：模型版本与一条任务的资源记录并列呈现 + 留白充足的编辑式工作台插画]