企业官网建设流程全解析

《Dynamic Expert Quantization for Scalable Mixture-of-Experts Inference》提出了一种名为DynaExq的运行时感知混合精度服务系统，旨在解决单 GPU 在硬性 HBM 内存约束下部署 MoE 大模型时面临的专家权重占用过大、卸载/预取在密集激活下产生等待延迟、以及静态 PTQ 无法适应工作负载迁移等核心问题。以下是对其主要研究内容的全面总结。

一、研究背景与问题动机

1.1 MoE 部署的核心矛盾

MoE 架构通过将每个 token 路由到少量专家，实现了模型容量扩展而每 token 计算量保持适中。然而，激活计算的稀疏性并未带来存储需求的成比例降低：为保持无约束路由，系统必须以低延迟保持全部专家权重可访问。例如 Qwen3-Next-80B 每 token 仅激活约 3B 参数，但完整参数存储需要约 160 GB 内存，远超边缘级 GPU 容量。瓶颈因此从算术吞吐量转移到参数驻留。

1.2 现有两类方法的局限

（1）专家卸载与预取：将 GPU 内存视为缓存，在 GPU 与主机内存/SSD 之间移动专家。其有效前提是每次迭代触及小型、稳定的专家工作集。但论文通过实测表明（表 1、表 2）：

• 解码阶段 batch size 从 1 增至 32 时，Qwen3-30B-A3B 的专家激活比例从 6.3% 升至 62.0%，DeepSeek-V2-Lite 从 9.0% 升至 67.6%；

• 预填充阶段激活更加密集，Qwen3-30B-A3B 在 batch size 32 时达 96.6%，DeepSeek-V2-Lite 达 96.3%。

当工作集增长超出可在 PCIe/NVLink 重叠窗口内暂存的范围，传输便表现为 GPU 等待时间。图 1 显示 ExpertFlow 下 GPU 等待延迟随 token 数急剧上升，在预填充中形成流水线气泡。

（2）训练后量化（PTQ）：无需传输即可压缩专家权重，但主流流程要么对所有专家统一比特宽度，要么离线固定每专家精度映射。这隐含假设专家相对重要性在服务时保持稳定。论文指出该假设对 MoE 十分脆弱：

• 重尾分布：少数热专家占据大部分累积调用（图 2）；

• 工作负载依赖：同一模型同一层，WikiText（文本）、GSM8K（数学）、HumanEval（代码）三种工作负载下 top-10 最频繁激活的专家完全不相交。

静态精度映射因此会在工作负载迁移时错误分配稀缺高精度容量：要么为低贡献专家保留精度，要么过度压缩变热的专家，恰在任务更难时降低质量。

1.3 三个关键观察

论文通过实验提炼出三个支撑 DynaExq 设计的观察：

• 观察 1：MoE 激活在预填充和较大 batch size 下可能变得密集，使专家工作集超出卸载/预取可可靠暂存的范围，频繁驱逐和获取引入 GPU 等待时间。

• 观察 2：长时程上 MoE 专家使用呈重尾且依赖工作负载，热集合身份可跨任务大幅迁移，静态精度映射会错误分配高精度容量。

• 观察 3：当低精度主要应用于冷专家时，增加每层量化专家数量会产生平滑且可控的困惑度上升（图 3），表明存在可预测的质量-内存权衡，保护频繁使用的专家可捕获大部分质量收益。

二、核心研究内容：DynaExq 系统设计

DynaExq 的核心思想是：将专家精度视为运行时控制的资源，而非固定的离线选择。系统持续观察路由器输出，估计哪些专家在稳定时间范围内占据不成比例的流量份额，将有限高精度预算分配给这些专家，其余专家保持低精度回退，从而在硬性 HBM 上限内减少传输量并避免等待延迟。

系统被组织为一个轻量级控制循环，将策略决策与 token 关键路径分离，需同时满足三个约束：(C1) 预算可行性；(C2) 非阻塞前向路径；(C3) 路由波动下的稳定性。

2.1 整体架构（图 4）

• 工作器侧：每个请求调用路由器获得 top-k 专家 ID，用于索引句柄表；每个句柄身份稳定，解析到指向完全物化专家版本的active_ptr。

• 策略侧：调度器异步消费路由轨迹，热度估计器维护每专家统计量，预算可行调度器为每层选择高精度常驻集，容量由预算初始化一次性导出（考虑 KV 缓存等固定分配）。

• 内存侧：GPU 上专家权重存储在高精度池pool_hi和低精度池pool_lo中，与 KV 缓存区域隔离。

• 转换侧：转换管理器维护提升和驱逐队列，在专用迁移流上发出后台工作，通过发布步骤更新句柄表。

2.2 版本化专家驻留（VER）

VER 为每个 MoE 层和专家维护多个权重版本（最简配置为高精度 + 低精度），通过稳定句柄控制驻留：

• 专家条目与稳定句柄：句柄身份不可变，但包含指向当前活动版本的指针；计算路径解析句柄获得活动指针和量化参数，版本变化无需更新内核参数。

• 四种驻留状态：RESIDENT-HI、RESIDENT-LO、PROMOTING、DEMOTING、EVICTING，强制一个不变量——句柄必须始终解析到完整且可用的权重版本。

• 非阻塞切换语义：版本转换与 token 关键路径解耦，前向传播不等待传输，继续使用当前活动版本；传输完成后原子发布新版本（先发布后切换），确保没有内核观察到部分填充的版本。

2.3 GPU 内存管理

动态驻留对 GPU 分配器施加两方面压力：频繁大块分配导致碎片化；临时暂存缓冲区峰值需求取决于在途提升并发度。DynaExq 的应对策略：

• 分区池：pool_hi和pool_lo角色不重叠，是最大分配和碎片化主要来源。

• 固定粒度分配：以固定大小块分配，块对齐到与专家大小相当的大粒度，维护常数时间空闲列表，消除分配器争用。

• 预算模型与 OOM 安全：BudgetTracker暴露显式预留/释放操作；M_total中固定部分M_fixed保留给 KV 缓存、非专家参数、激活和框架开销，剩余分为高精度专家上限和低精度专家驻留；每次提升前调用try_reserve，成功才异步进行，失败则推迟或调度驱逐，前向路径继续用低精度版本执行。

2.4 非阻塞转换流水线

• 异步队列与背压：维护更新队列和驱逐队列；内存紧张时优先驱逐以回收高精度缓冲区；提升和驱逐在专用 CUDA 流stream_mig上执行，与计算流不相交；背压在准入处实施，仅通过预算预留检查的提升才入队。

• 更新/驱逐过程：以提升为例——预留容量 → 从pool_hi分配目标缓冲区 → 在stream_mig上异步复制预打包高精度权重（源在主机内存，避免即时重打包）→ 记录完成事件 → 事件完成后发布，更新稳定句柄。驱逐在发布完成后将旧版本标记为可驱逐。

2.5 在线调度策略

• 热度估计：每层每专家维护计数器c_{ℓ,e}，累积当前更新间隔内被路由器选择的次数；更新以固定时间间隔T_u触发（基于时间而非 token 数，在不同 batch 组成和提示长度下稳定）；用指数移动平均更新平滑热度分数S_{ℓ,e} ← α·S_{ℓ,e} + (1-α)·c_{ℓ,e}，仅使用路由器输出，不假设可访问标签或在线质量信号。

• 预算可行选择：每层高精度容量n_{hi,ℓ}由内存预算固定，策略选择 top-n_{hi,ℓ}专家构成高精度集H_ℓ，操作局部且构造上预算可行；集合差决定提升候选（H_ℓ \ H_ℓ^cur）和降级候选（H_ℓ^cur \ H_ℓ）。

• 稳定性迟滞：朴素 top-N 在分数相近时会引起不必要抖动，增加提升次数和后台带宽消耗；迟滞要求专家热度超过当前集最低排名专家一个边际才提升，低于集外最高排名专家相同边际才驱逐；不改变预算约束，减少振荡，使转换率更可预测。

三、实现与实验评估

3.1 实现

在 HuggingFace Transformers 栈之上实现约 3K 行 Python 扩展，修改 MoE 执行路径同时保留原始接口。插桩路由器暴露每 token top-k 专家 ID；VER 通过持久句柄表实现；内存管理实现为固定粒度设备池和预算跟踪器；转换管理器在后台线程运行，在专用 CUDA 流上发出异步主机到设备复制，用 CUDA 事件检测完成后再发布。

3.2 实验设置

• 模型：Qwen3-30B-A3B-Instruct、Qwen3-80B-A3B-Instruct、Phi-3.5-MoE-instruct（配置见表 3）。

• 基准：WikiText-2（困惑度）、MMLU-Pro、GPQA、AIME25、GSM8K、HumanEval。

• 硬件：单块 RTX A6000（48 GB）。

• 精度层级：热专家高精度（通常 FP16，Qwen3-80B 为 INT4），冷专家低精度（INT4 或 INT2）。

• 对比基线：静态量化（Qwen3-30B/Phi-3.5-MoE 为 Int4，Qwen3-80B 为 Int2）和 ExpertFlow+。

3.3 质量结果（Q1）

• Qwen3-MoE-30B：静态 Int4 将平均分从 65.29（FP16）降至 63.98；DynaExq 提升至 64.38，增益来自 GPQA（54.14 vs. 53.54）、GSM8K（89.91 vs. 89.39）、HumanEval（84.76 vs. 84.15）。

• Qwen3-MoE-80B：Int2 将平均分降至 73.09，DynaExq 提升至 77.57，恢复一致且接近 Int4 基线的 78.11，表明动态分配可在容量约束原本需要统一低比特压缩时接近更高比特配置。

• Phi-3.5-MoE：静态 Int4 从 58.06 降至 56.31，DynaExq 提升至 57.00。

结论：路由器驱动的精度分配可通过将较高精度集中在占执行份额较大的专家上，在固定 GPU 预算下保持精度。

3.4 性能结果（Q2）

• TTFT（图 6）：静态量化最低（避免关键路径权重移动）；ExpertFlow 随 batch 增长急剧上升；DynaExq 更接近静态基线，在各 batch size 下显著低于 ExpertFlow，差距在高 batch 下更大。

• TPOP（图 7）：ExpertFlow 显示更高 TPOP 和扩大的尾部；DynaExq 通过分离计算流和迁移流并限制迁移速率，TPOP 接近静态量化，平均-P99 差距更小。

• 端到端延迟（图 9）：排序为静态量化 < DynaExq < ExpertFlow；ExpertFlow 因重复传输和同步产生复合延迟；DynaExq 曲线增长更平缓。

• 吞吐量：DynaExq 始终优于 ExpertFlow，提升范围1.42× 至 2.73×，差距随 batch size 增长而扩大；在 batch size 32 时达最高 2.73×。

• 延迟随提示长度扩展（图 10）：ExpertFlow 增长最陡、尾部放大最大；Qwen3-30B 上其平均 TTFT 达约 10 秒、P99 接近十几秒，而 DynaExq 稳定在中等个位数；Qwen3-80B 上 ExpertFlow 平均 TTFT 约 40 多秒、P99 接近 90 秒，DynaExq 显著更低且增长更慢。

四、与相关工作的区别

4.1 与 MoE 服务/卸载系统对比

DeepSpeed-MoE、Tutel、MegaBlocks 假设专家参数在 GPU 内存中可用，主要杠杆是重构计算和调度；MoE-Infinity、ProMoE、ExpertFlow、SwapMoE、Pre-gated MoE 等回答“专家权重应驻留何处及何时移动”，将权重视为固定精度对象。DynaExq 的不同在于：将精度作为额外的控制轴，并采用稳定句柄将版本可见性与传输解耦。

4.2 与 MoE 量化/动态精度控制对比

SmoothQuant、GPTQ、AWQ、SpQR、QuaRot 等产生静态量化模型；HAQ、AdaQuant、FlexRound 等在层或块粒度操作，设计用于所有参数参与每个 token 的稠密网络。MxMoE、MoPEQ 等针对 MoE 利用专家异质性，但主要推导静态混合精度分配或需要与在线服务动态无关的离线分析。DynaExq 的焦点是在线精度驻留，依赖路由轨迹更新预算可行高精度常驻集，并提供窗口级固定、确定性内存管理和有界干扰转换的非阻塞实现。

五、主要贡献与结论

5.1 贡献总结

1. 问题建模：将硬性 HBM 约束下的单 GPU MoE 服务建模为一个在线的、预算受限的精度分配问题。

2. 调度器设计：设计预算可行调度器，跟踪长时程专家热度，通过稳定 top-n 规则为每层选择高精度专家。

3. 非阻塞机制：构建混合精度驻留的非阻塞机制，使用稳定专家句柄和异步提升/降级，将精度转换与 token 关键路径解耦。

4. 系统实现与验证：实现 DynaExq 并与最先进卸载/预取及静态 PTQ 方法比较，在 Qwen3-80B 上将精度从 73.09% 提升至 77.57%，在 batch size 32 时相较卸载/预取基线实现最高 2.73 倍吞吐量提升。

5.2 结论

DynaExq 将高精度集中在长时程热专家上，同时保持低精度回退，构造上强制预算可行性，并通过异步提升和降级更新驻留，使推理在稳定专家版本上继续。在具有偏斜和迁移路由的工作负载上，该设计较静态 PTQ 改善了质量-内存权衡，并减少了在密集激活下限制卸载与预取的等待延迟。

DynaExq 通过将 MoE 专家精度从离线固定选择转变为由路由器轨迹驱动的在线、预算受限资源分配，在单 GPU 硬性 HBM 约束下同时实现了优于静态 PTQ 的精度保持和远超卸载/预取基线的吞吐量，核心机制是稳定句柄解耦版本可见性与数据传输、确定性内存分区保证 OOM 安全、以及带迟滞的 top-N 热度调度抑制抖动。这里是自己的论文阅读记录，感兴趣的话可以参考一下，如果需要阅读原文的话可以看这里，如下所示：

摘要

混合专家（Mixture-of-Experts，MoE）已成为一种实用的架构，能够在大幅扩展大语言模型（LLM）容量的同时，保持每 token 计算量适中。然而，在单块显存受限的 GPU 上部署 MoE 模型仍然困难重重，因为专家权重占据了 HBM 内存的主要部分。现有的专家卸载与预取系统虽然减少了常驻内存集，但当激活变得密集时，它们往往会在关键路径上付出专家加载的代价。训练后量化（Post-Training Quantization，PTQ）无需数据传输即可降低内存占用，但主流流程离线固定专家比特宽度，并假设路由保持稳定——然而 MoE 的专家利用率呈重尾分布，且热集合会随工作负载发生迁移。

我们提出DynaExq，一种运行时感知的混合精度服务系统，将硬性 HBM 内存约束下的单 GPU MoE 推理视为一个在线的、预算受限的精度分配问题。其核心洞察是：让主导运行时流量的专家以较高精度常驻，同时为其余专家维持低精度回退版本，从而减少传输量并避免在密集激活下限制卸载与预取的等待延迟。DynaExq 从路由轨迹中估计长时程专家热度，通过预算可行的 top-n 规则为每层选择高精度常驻集，并通过稳定的专家句柄异步执行提升与降级操作，使前向传播始终在完全物化的专家版本上执行。在 Qwen3-MoE-30B/80B 及六个基准测试上，DynaExq 在可比设备内存预算下将 Qwen3-80B 的精度较静态 PTQ 提升（73.09% → 77.57%），并在 batch size 为 32 时相较卸载/预取基线实现最高 2.73 倍的吞吐量提升。

关键词

混合专家、训练后量化、GPU 推理

1 引言

大语言模型（LLM）的快速扩张推动了其在广泛应用中的采用[40]。除集中式数据中心的云部署外，将 LLM 运行在更靠近终端用户的位置也日益受到关注，以降低交互延迟、限制敏感数据暴露并避免对稳定网络连接的依赖[11]。这些压力使端侧与边缘推理成为越来越重要的部署模式，但也暴露了一个实际约束：现代 LLM 的内存占用往往超过单块商用加速器的容量，在边缘平台上尤为如此。

MoE 架构[42]已成为一种务实的路径，能够在不产生成比例每 token 计算量的情况下扩展模型容量。通过将每个 token 路由到一小部分专家，MoE 增加了表示容量，同时保持每 token 激活参数相对较少。然而，激活计算量的减少并未转化为推理时存储需求的成比例降低。为保持无约束路由，系统必须以低延迟保持全部专家权重可访问，这将瓶颈从算术吞吐量转移到了参数驻留。因此，基于 MoE 的 LLM 即使在每 token 仅使用一小部分参数时，仍可能保持内存密集型。例如，Qwen3-Next-80B 每 token 仅激活约 3B 参数，但存储全部模型参数需要约 160 GB 内存，远超典型边缘级 GPU 所能提供。这一差距使单设备部署变得困难，并促使系统支持将专家参数视为主要受限资源。

两类技术常用于缓解这一内存瓶颈。第一类是专家卸载与预取[8, 17, 21, 27-29, 35, 36, 41]，将 GPU 内存视为缓存，在 GPU 与主机内存或 SSD 等较慢层级之间移动专家。第二类是训练后量化（PTQ）[7, 9, 10, 12, 14, 18, 22, 39]，将专家权重压缩为低比特表示。两者在特定场景下均有效，但都依赖于在实际服务混合下可能被违反的假设。

卸载与预取在每次迭代触及小型、稳定的专家工作集时最为有效。实践中，MoE 激活在预填充（prefill）阶段和较大 batch size 下可能变得显著密集，从而扩大每迭代工作集并增加传输压力（表 2）。当工作集增长超出可在可用重叠窗口内通过 PCIe 或 NVLink 暂存的范围时，传输便表现为 GPU 等待时间并放大尾延迟（图 1）。在此类场景下，放置策略面临结构性局限：即使预测准确，系统仍须移动大量专家权重以维持吞吐量。

PTQ 可在不引入关键路径传输依赖的情况下减少专家内存占用。然而，大多数 MoE PTQ 流程为所有专家分配统一比特宽度，或使用有限校准离线固定每专家精度映射。这种设计隐含假设专家相对重要性在服务时保持稳定。该假设对 MoE 而言是脆弱的。专家利用率在长时程上呈重尾分布，且频繁使用专家的身份会随通用文本、数学推理和代码生成等工作负载发生迁移。在工作负载迁移下，静态精度映射会错误分配稀缺的高精度容量：要么为当前工作负载中贡献流量很小的专家保留精度，要么过度压缩变得热门的专家，恰好在工作负载更难时降低质量。

为填补这一部署缺口，我们提出 DynaExq，将硬性 HBM 约束下的单 GPU MoE 服务视为一个在线的、预算受限的精度分配问题。核心思想是使专家精度成为运行时控制的资源，而非固定的离线选择。DynaExq 在服务过程中持续观察路由器输出，估计哪些专家在稳定时间范围内占据了不成比例的流量份额，并将有限的高精度预算分配给这些专家，同时将其余专家保持在较低精度表示以维持在设备内存上限之内。

DynaExq 被组织为一个轻量级控制循环，将策略决策与 token 关键路径分离。在策略侧，调度器聚合路由轨迹并周期性计算预算可行的每层高精度专家常驻集。该选择受固定 HBM 预算约束，该预算考虑了非专家参数及 KV 缓存等运行时分配，因此所得精度方案在构造上即可行。在机制侧，DynaExq 通过将精度转换与计算解耦来强制非阻塞执行。它维护稳定的专家句柄，始终解析到完全物化的专家版本，并在专用迁移流上异步执行提升与降级。在转换期间，前向传播继续使用每个专家的最后发布版本执行，版本更新仅在相应数据移动完成后才可见。为在负载下保持切换可预测，DynaExq 还对专家权重使用确定性内存分区，并对提升操作实施显式准入控制，从而防止分配器碎片化，并避免服务工作负载演变过程中出现瞬态内存不足故障。

本文的主要贡献如下：

• 我们将硬性 HBM 约束下的单 GPU MoE 服务建模为一个在线的、预算受限的精度分配问题。

• 我们设计了一种预算可行的调度器，跟踪长时程专家热度，并通过稳定的 top-n 规则为每层选择高精度专家。

• 我们构建了一种非阻塞的混合精度驻留机制，使用稳定专家句柄和异步提升/降级，将精度转换与 token 关键路径解耦。

• 我们实现了 DynaExq 并与最先进的卸载/预取及静态 PTQ 方法进行比较，在 Qwen3-80B 上将精度较静态量化提升（73.09% → 77.57%），并在 batch size 为 32 时相较卸载/预取基线实现最高 2.73 倍的吞吐量提升。

2 背景与动机

2.1 MoE 推理

MoE 层通过将每个 token 路由到一小部分专家子网络（通常每 token 选择 top-k 个专家）来增加模型容量。虽然稀疏激活减少了计算量，但并未直接减少推理时的内存占用：为保持无约束路由，部署必须使专家权重以低延迟可访问。在现代 MoE LLM 中，专家权重主导参数占用，因此单 GPU 服务能力往往取决于专家权重能否装入 HBM。

MoE 推理的一个关键特性是专家利用率天然不均衡。即使在固定层内，一小部分专家也倾向于接收不成比例的路由 token，而许多专家很少被激活。这种偏斜仅从路由器输出即可观察，不依赖标签或真实质量测量。实践中，偏斜意味着在紧张 HBM 约束下，为每个专家分配同等保真度和内存很少具有成本效益。

2.2 MoE 服务的卸载与预取

在有限 GPU 内存中容纳 MoE 推理的一种广泛使用的方法是将专家权重视为受管理的工作集。一系列专用系统利用稀疏专家激活，提出门控感知的缓存与预取策略，包括 Adap-gating [21]、EdgeMoE [36]、MoE-Infinity [35]、Mixtral-offloading [8]、Pre-gated MoE [17]、AdaMoE [41]、Hobbit [29]、ProMoE [28] 和 ExpertFlow [27]。这些方法在预测即将到来的专家和暂存传输的方式上有所不同，但共享一个共同目标：仅在 GPU 上保留一部分专家，按需获取其余专家。在实际服务条件下，它们仍可能招致精度下降或延迟开销。

卸载与预取在每层激活小型且稳定专家子集时最为有效。表 1 和表 2 表明，这种稀疏机制在服务中往往并不成立。随着 batch size 增加，每层激活专家比例急剧上升，有时超过 60%。预填充阶段可能更加密集，某些情况下接近全激活。即使在小 batch size 下，长提示也可能激活许多专家。在这些条件下，专家工作集可能增长超出 GPU 预算，导致频繁驱逐和获取。如图 1 所示，我们测量了 ExpertFlow 下 GPU 停滞延迟随输入提示长度的变化。随着输入 token 数量增加，专家激活变得密集，交换流量可能饱和 PCIe 带宽，在原本重叠的执行流水线中引入气泡，使 GPU 利用不足。

观察 1：MoE 激活在预填充和较大 batch size 下可能变得密集，使专家工作集扩大到卸载与预取无法可靠暂存的程度。此时频繁驱逐和获取会引入 GPU 等待时间。

2.3 MoE 的训练后量化

PTQ 是一种标准方法，通过将权重压缩为低比特宽度来减少 LLM 内存占用而无需重训练，通常伴随校准程序以缓解量化误差[10, 22]。近期工作已将 PTQ 从稠密模型扩展到 MoE 架构，其中专家权重主导参数预算，从而决定单 GPU 部署是否可行[7, 9, 12, 14, 18, 39]。与稠密模型 PTQ 相比，MoE PTQ 还必须应对路由引起的不平衡：专家激活不均，校准数据可能偏向频繁选择的专家，异构专家执行可能与内核选择和内存流量相互作用。因此，若干 MoE 感知 PTQ 流程纳入了每专家或每块比特分配、离群值处理，某些情况下还包括针对混合精度专家高效执行的系统协同设计。总体而言，这一工作线大幅改善了质量-压缩权衡，使在受限 HBM 内运行更大 MoE 模型成为可能。

尽管有这些进展，PTQ 仍是有损压缩，在激进比特宽度下通常与 FP16 存在可测量的精度差距。对于 MoE 服务，一个更结构性的局限是大多数 PTQ 部署要么对所有专家应用统一精度，要么离线固定每专家精度映射并在推理时保持不变。这一选择忽略了 MoE 执行的一个定义性属性：专家利用率随时间高度不平衡。图 2 显示了累积激活的重尾分布，其中一小部分热专家占据了大部分专家调用，而大多数专家保持冷门。这与较大 batch size 下的激活密集化并不矛盾。密集化描述的是单次迭代内并发激活多少专家，而累积激活反映的是长时程流量集中度。即使在同一预填充或解码步骤中触及许多专家，它们在服务窗口内的总使用量仍可能相差数个数量级。

热集合身份也依赖于工作负载。图 2 显示，对于相同 MoE 模型和层，文本、数学和代码工作负载下 top-10 最频繁激活的专家可能完全不相交。在此类迁移下，静态精度分配可能将稀缺内存预算花在当前工作负载中贡献流量很小的专家上，同时过度压缩主导执行的专家。在严格 HBM 预算下，这种错误分配被放大，因为每个高精度槽位直接挤占了本可保护当前热专家的内存。

观察 2（专家利用率的偏斜与迁移）：在长时程上，MoE 专家使用呈重尾且依赖工作负载：一小部分热专家主导累积调用，且热集合身份可跨任务大幅迁移。因此，静态精度映射在实际服务混合下会错误分配稀缺的高精度容量。

2.4 在线精度控制的动机

上述观察表明，在严格 GPU 预算下，通过在线自适应专家精度来权衡模型质量与内存占用存在机会。一个关键担忧是这种自适应是否会在不破坏质量稳定性的情况下完成。为探究此问题，我们量化了当增加分配给低精度的专家比例时语言建模质量的变化。使用 WikiText-2，我们评估 128 个提示，每个 2048 输入 token 和 256 输出 token，并逐步增加每层被降级的专家数量。如图 3 所示，当降级仅限于不常激活的专家时，困惑度随更多专家被降级而平滑上升。这一行为表明，激活感知的精度分配诱导了可预测的质量-压缩曲线，保护频繁使用的专家捕获了大部分质量收益。

观察 3（对冷专家降级的平滑敏感性）：当低精度主要应用于冷专家时，增加每层量化专家数量会产生平滑且可控的困惑度上升，表明存在可预测的质量-内存权衡。

2.5 在线精度分配的挑战

MoE 服务的在线精度控制具有挑战性，因为它必须在适应路由迁移的同时满足难以放松的部署约束：

• (i) 硬预算不变性。精度变化直接改变常驻专家内存占用。系统绝不能违反 HBM 上限，否则 OOM 或强制驱逐可能级联导致不稳定。

• (ii) 关键路径隔离。路由决策发生在 token 关键路径上，但精度转换涉及重量级设备传输。如果转换与前向传播同步，会产生主导 TTFT/TPOP 的停滞。

• (iii) 非平稳性下的尾延迟鲁棒性。路由依赖工作负载，因此当分数接近或瞬态波动时，朴素重分配可能抖动，放大迁移流量并扩大 P99 尾部。

3 设计：DynaExq

3.1 概述

图 4 总结了端到端控制循环。工作器执行 MoE 推理，而调度器观察路由轨迹并在严格 GPU 内存预算下更新专家精度驻留。设计将推理工作流与后台转换分离，并暴露稳定接口，使驻留变化不会在窗口内扰动执行。

在工作器侧，每个请求调用路由器以获得 top-k 专家 ID，用于索引句柄表。每个句柄身份稳定，并解析到一个active_ptr，指向完全物化的专家版本。

自适应由异步消费路由轨迹的调度器驱动。热度估计器维护每专家的时间统计量。这些统计量馈入预算可行调度器，为每层 t 选择高精度常驻集，受层容量 nhi,t 约束。容量由预算初始化一次性导出，该初始化考虑 KV 缓存等固定 GPU 分配，并将剩余设备内存保留给专家权重。所得目标集驱动转换管理器，后者维护提升和驱逐队列，并发出后台工作以物化变更。

内存被分区以使转换可预测。在 GPU 上，专家权重存储在高精度和低精度版本的独立池中，与 KV 缓存区域隔离。当转换管理器提升一个专家时，它从高精度池分配空间，从主机内存获取准备好的权重版本，然后复制到设备。复制完成后，发布步骤更新句柄表，使新版本在下一迭代可见。驱逐在发布步骤成功后回收旧版本。这种组织使图 4 的架构与接下来描述的四个组件保持一致：

图 4：DynaExq 系统架构。VER 定义稳定句柄，内存管理提供确定性池和预算门控，转换流水线执行非阻塞提升和驱逐操作并限制干扰，策略根据路由器导出的热度在固定每层容量下决定高精度驻留。

3.2 版本化专家驻留（VER）

为在 GPU 上管理不同精度的专家，并在工作负载或激活分布变化时实现专家精度切换，我们设计了版本化专家驻留（Versioned Expert Residency，VER）。VER 提供了一种通过版本化精度控制专家驻留的机制。对于每个 MoE 层 ℓ 和专家 e，VER 维护多个权重版本，以不同数值格式实现相同算子。在最简配置中，每个专家有一个高精度版本和一个低精度版本。高精度版本面向精度关键执行，低精度版本提供内存高效回退。

专家条目与稳定句柄。VER 将每个专家表示为一个专家条目，拥有所有支持版本的元数据。每个条目导出一个稳定句柄，在执行时传递给 MoE 内核。句柄身份不可变，但包含指向 GPU 上当前活动版本的指针。计算路径解析句柄以获得活动指针和相关量化参数，然后调用相应内核。这种间接允许 VER 通过更新活动指针来改变驻留和精度，同时保持句柄位置稳定。因此，版本变化无需更新内核参数，只需更新句柄本身。

驻留状态。每个专家条目跟踪其版本在 GPU 上的驻留。我们考虑四种状态。在 RESIDENT-HI 中，高精度版本存在于 GPU 上，句柄指向它。在 RESIDENT-LO 中，仅低精度版本存在，句柄指向它。在 PROMOTING 中，系统正在将高精度版本传输到 GPU；在此状态期间，句柄继续指向先前有效版本，通常是低精度版本。在 DEMOTING 中，系统正在传输低精度版本到 GPU 以替换当前高精度版本。在 EVICTING 中，系统在将句柄切换到剩余有效版本后回收旧版本存储。这些状态强制执行一个不变量：句柄必须始终解析到完整且可用的权重版本。该不变量足以在前向传播中即使提升/降级正在进行时也保持非阻塞。

非阻塞切换语义。VER 将版本转换与 token 关键路径解耦。当运行时决定应提升或降级某专家时，它启动后台传输以分配 GPU 空间并复制高精度权重。前向传播不等待此传输。相反，它继续通过稳定句柄使用当前活动版本。传输完成后，VER 通过更新句柄的活动指针原子地发布新版本。类似地，驱逐先将句柄重定向到仍驻留的版本，然后在后台回收释放的存储。这种先发布后切换的纪律确保没有内核会观察到部分填充的版本。

VER 将驻留变化隔离在稳定句柄之后，并强制前向传播始终有有效版本可执行。这种分离允许调度策略专注于决定在内存预算下哪些专家应占用高精度容量。在设计其余部分，我们描述如何将 VER 与确定性内存管理和在线调度器结合，以限制转换开销并控制共享内存上的干扰。

3.3 GPU 内存管理

动态专家驻留以两种方式对 GPU 分配器施加压力。首先，提升和驱逐引入大型权重缓冲区的频繁分配，可能碎片化地址空间并增加分配延迟方差。其次，权重转换通常需要临时暂存缓冲区，其峰值需求取决于在途提升的并发度。如果这些分配与计算栈共享同一分配器路径，瞬态压力可能通过分配器抖动和附带同步传播到 token 关键路径。因此，我们通过显式分区和固定粒度分配管理内存，并通过全局预算跟踪器门控每次转换。

分区池。我们将分配给专家权重的 GPU 内存区域划分为具有非重叠角色的不相交池。高精度池pool_hi和低精度池pool_lo存储常驻高/低精度专家版本。这些池负责最大分配，若不加管理是碎片化的主要来源。

固定粒度分配。pool_hi和pool_lo以固定大小块分配内存，并通过组合一个或多个块来服务请求。块大小选择以平衡内部碎片和分配开销；在我们的实现中，我们将块对齐到与专家大小相当的大粒度，使分配和回收保持可预测。每个池维护常数时间空闲列表，因此分配和释放是简单指针操作，不调用通用运行时分配器。这种设计消除了分配器争用。

3.4 非阻塞转换流水线

VER 使用窗口级固定将版本可见性与数据移动解耦，但系统仍需要具体流水线来准备提升并执行驱逐而不停滞前向传播。转换流水线有两个目的：通过在专用迁移流上运行转换，使计算流与权重传输独立；并实施背压，使后台活动不会通过带宽争用放大尾延迟。

异步队列与背压。运行时维护两个逻辑队列：用于提升和降级的更新队列，以及驱逐队列，每个包含驻留变化候选的专家标识符 (ℓ,e)。后台工作器消费这些队列并发出异步工作。当内存预算紧张时，工作器优先处理驱逐，因为回收高精度缓冲区增加后续更新的可行集。在启动更新前，工作器确保临时池有足够容量用于暂存缓冲区，且全局预算跟踪器准入高精度分配。提升和驱逐在专用 CUDA 流stream_mig上执行，该流与注意力和专家内核使用的计算流不相交。这种分离避免了关键路径上的隐式同步，并使转换开销可观察、可控。

背压在准入处实施：仅当提升通过第 3.3 节所述的预算预留检查时才入队。当pool_hi和pool_lo满时，额外提升保持排队。前向传播继续使用当前固定的映射执行。

更新/驱逐过程。以提升过程为例，它在 GPU 内存中物化专家的高精度版本，并仅在安全发布点使其可见。对于目标专家 (ℓ,e)，工作器首先从全局预算跟踪器预留所需容量。然后从pool_hi分配目标缓冲区。接着在stream_mig上发出异步复制，用预打包的高精度权重填充目标。源位于主机内存；设计避免提升期间即时重打包，以防止不可预测的临时分配和额外带宽压力。复制发出后，工作器在stream_mig上记录完成事件。专家条目保持提升状态直到此事件完成。发布更新稳定句柄指向新高精度缓冲区。发布仅在完成事件后执行，确保前向传播永远不会观察到部分填充的版本。

至于驱逐过程，它在固定映射不再需要后回收高精度/低精度缓冲区。工作器在发布完成后将相应旧版本缓冲区标记为可驱逐。

3.5 在线调度策略

VER 和转换流水线定义了在窗口级固定下如何物化和发布专家版本。剩余问题是哪些专家应在每层占用有限的高精度容量。我们使用由路由轨迹驱动的轻量级策略。该策略刻意简单，使其开销可忽略且行为在工作负载迁移下易于推理。

稳定性迟滞。朴素的 top-N 规则可能在若干专家热度分数相近时引起不必要的抖动。这种抖动增加提升次数并放大后台带宽消耗，却没有相应的质量收益。因此，我们在更新 Hℓ​ 时应用迟滞。

具体而言，仅当专家热度超过当前高精度集中最低排名专家的热度一个边际时，才将其提升到高精度集。对称地，仅当专家热度低于当前集外最高排名专家的热度相同边际时，才将其驱逐。该边际可表示为分数上的加性阈值，或排名松弛，要求专家进入稍宽的候选集后才具备资格。迟滞不改变预算约束。它减少振荡，使转换率在瞬态路由波动下更可预测。

策略以更新节奏 Tu​ 运行，为每层产生目标高精度集。窗口级固定随后决定这些目标何时对计算路径可见，转换流水线在物化新高精度常驻时强制准入控制和有界干扰。

4 实现

我们在 HuggingFace Transformers 栈之上实现该设计，作为约 3K 行的自包含 Python 扩展，修改 MoE 执行路径同时保留原始模型接口。实现插桩路由器以暴露每 token top-k 专家 ID，并在主机上聚合这些轨迹用于热度估计和窗口调度。VER 通过持久句柄表实现，将每个专家映射到版本元数据。我们将确定性内存管理实现为高精度权重和临时暂存缓冲区的固定粒度设备池，以及在校准提升前预留容量的预算跟踪器。转换管理器在后台线程运行，在专用 CUDA 流上发出异步主机到设备复制，使用 CUDA 事件检测复制完成后再发布更新。专家权重离线准备为高精度和低精度版本，以内核就绪布局存储在固定主机内存中；运行时系统通过更新驻留和句柄表来提升和驱逐专家，而前向传播继续在计算流上使用当前固定映射执行。

表 3：评估的 MoE 模型配置

5 评估

我们在单 GPU 设备内存预算下评估 DynaExq，关注质量、延迟和吞吐量之间的权衡。评估回答两个问题。

Q1：质量。在相同设备内存占用下，在线、热度驱动的精度分配相对于静态压缩能恢复多少质量？（5.2 节）
Q2：性能。当设备内存是约束瓶颈时，DynaExq 达到何种延迟和吞吐量？（5.3 节）

5.1 实验设置

模型。我们在 Qwen3-30B-A3B-Instruct、Qwen3-80B-A3B-Instruct [30] 和 Phi-3.5-MoE-instruct [1] 上评估 DynaExq。这些模型的详细信息见表 3。

基准与质量指标。我们报告 WikiText-2 [23]（困惑度）、MMLU-Pro [32]、GPQA [26]、AIME25 [3]、GSM8K [5] 和 HumanEval [4] 上的任务性能。

服务栈与硬件。我们将 DynaExq 集成到基于 PyTorch 和 Transformers 的 MoE 推理栈中[24, 33]。所有实验在单块 RTX A6000（48 GB）上运行，实验中使用两个精度层级：热专家分配较高精度版本（通常为 FP16，Qwen3-80B 为 INT4），冷专家保持较低精度版本（INT4 或 INT2）。

资源限制下的延迟与吞吐量。我们用三个互补测量评估服务性能。第一，扫描 batch size 并报告平均和 P99 的 TTFT 与 TPOP。第二，变化 token 数量并测量延迟如何随提示长度和生成长度扩展，同样报告平均和 P99。第三，报告预填充和解码的端到端吞吐量。所有测量在相同内存预算下进行，因此报告的尾部行为反映了后台转换与计算路径之间的交互。

5.2 DynaExq 的质量

表 4 将 DynaExq 与 FP16 和静态低比特量化进行比较。在 Qwen3-MoE-30B 上，静态 Int4 将平均分从 65.29（FP16）降至 63.98。在相同单 GPU 能力下，DynaExq 将平均分提升至 64.38。增益来自 GPQA（54.14 vs. 53.54）、GSM8K（89.91 vs. 89.39）和 HumanEval（84.76 vs. 84.15）的改进。这些结果表明，将高精度重新分配给持续使用的专家可以在不增加模型占用的情况下恢复部分质量损失。

当静态基线被迫使用更激进比特宽度以适配预算时，收益更大。在 Qwen3-MoE-80B 上，Int2 将平均分降至 73.09，而 DynaExq 在相同预算下将其提升至 77.57。恢复在各基准上一致。与 Int4 基线相比，DynaExq 在总体上保持接近（77.57 vs. 78.11），表明当容量约束原本需要统一低比特压缩时，动态分配可以接近更高比特配置。

我们在 Phi-3.5-MoE 上观察到类似模式。静态 Int4 将平均分从 58.06 降至 56.31，而 DynaExq 将其提升至 57.00。改进反映在 GPQA（35.94 vs. 34.52）、GSM8K（88.25 vs. 87.54）和 HumanEval（70.22 vs. 69.41）上。总体而言，这些结果支持以下前提：路由器驱动的精度分配可以通过将较高精度集中在占执行份额较大的专家上，在固定 GPU 预算下保持精度。

表 4：不同模型/方法的精度比较

5.3 DynaExq 的性能

我们在相同设备内存预算下在单块 A6000 GPU 上评估性能。我们将 DynaExq 与静态量化基线（Qwen3-30B 和 Phi-3.5-MoE 为 Int4；Qwen3-80B 为 Int2）以及卸载与预取系统 ExpertFlow+ [27] 进行比较。我们报告预填充首 token 时间（TTFT）、解码每输出 token 时间（TPOP）、端到端请求延迟和吞吐量。为压力测试 MoE 执行变得不那么稀疏的场景，我们扫描 batch size 并相应增加每迭代处理的 token 数量。我们报告平均和 P99 以捕获争用下的尾部行为。

TTFT。图 6 显示 TTFT 随 batch size 增加的变化。静态量化基线提供最低 TTFT，因为它避免关键路径上的权重移动。ExpertFlow 随 batch 增长在平均和 P99 TTFT 上均急剧增加。这一趋势与预填充激活更大比例专家一致，增加了传输并减少了重叠机会，使迁移变成可见等待时间。DynaExq 更接近静态基线，并在各 batch size 下保持显著低于 ExpertFlow。差距在较高 batch size 下更大，此时预填充实际上变得密集，卸载策略面临重复提升的持续压力。

TPOP。图 7 报告解码期间的 TPOP。解码对提示长度效应不太敏感，但当并发请求间专家工作集变化时，仍受后台迁移影响。ExpertFlow 再次显示更高 TPOP 和随 batch 增加而扩大的尾部，表明传输干扰不仅限于预填充。DynaExq 通过分离计算流和迁移流并限制迁移速率来减少这种干扰，因此其 TPOP 保持接近静态量化，平均与 P99 之间的差距更小。

端到端延迟。图 9 总结端到端延迟。排序与 TTFT 和 TPOP 一致：静态量化最低，ExpertFlow 最高，DynaExq 居中但更接近静态基线。随着每迭代 token 量随 batch size 增加，ExpertFlow 经历重复传输和同步的复合延迟，反映在平均和 P99 延迟中。DynaExq 避免在转换上阻塞并限制后台干扰，因此端到端延迟曲线增长更平缓。相同模式延续到吞吐量：通过使预填充和解码不因专家移动而停滞，DynaExq 在较大 token 量下维持比 ExpertFlow 更高的有效吞吐量，同时在相同内存预算下接近静态基线。

增加 batch size 下的吞吐量。图 9 报告在相同设备内存预算下单块 A6000 上端到端吞吐量（tokens/s）随 batch size 增加的变化。在所有三个模型上，DynaExq 始终优于 ExpertFlow，吞吐量提升范围为 1.42 倍至 2.73 倍。差距随 batch size 增长而扩大。在较高 batch size 下，预填充在每迭代内激活更大比例专家，增加了专家移动量并减少了卸载与预取的重叠机会。这种效应限制了 ExpertFlow 的扩展并导致早期饱和。相比之下，DynaExq 在固定预算内保持高精度工作集常驻，并限制后台转换干扰，因此吞吐量随 batch size 更稳定增长。该趋势对 Qwen3-30B、Qwen3-80B 和 Phi-3.5-MoE 均成立，表明收益不依赖于特定专家池大小，而在于减少每迭代 token 量增加时的传输引起停滞。

延迟随提示长度的扩展。图 10 进一步扫描每请求处理的 token 数量并报告所得 TTFT 延迟（平均和 P99）。跨模型，当提示从极短输入增长到几百 token 时，延迟迅速增加，然后随着每请求预填充工作占主导而接近平台。静态量化基线保持最低，且随提示长度变化轻微，反映其避免关键路径上的专家传输。ExpertFlow 显示最陡增长和最大尾部放大。在 Qwen3-30B 上，其平均 TTFT 升至约 10 秒，P99 在提示达到扫描最长范围时接近十几秒，而 DynaExq 稳定在中等个位数，并将 P99 保持在远低于 ExpertFlow 的水平。差距在 Qwen3-80B 上更大，ExpertFlow 平均 TTFT 收敛到约 40 多秒，P99 接近 90 秒，而 DynaExq 保持显著更低，并随 token 增加跟踪更慢的增长趋势。Phi-3.5-MoE 显示类似模式：静态 Int4 保持最低，ExpertFlow 快速上升并高平台，DynaExq 居中且平均-尾部差距更小。这些结果与以下观察一致：更长提示使预填充不那么稀疏，增加专家移动量和频率；限制转换干扰并避免阻塞发布使 DynaExq 的延迟增长随 token 数量增加更平缓。

6 相关工作

在硬设备预算下高效神经推理是跨领域的反复出现的系统问题，从自动驾驶中资源受限的感知模型[38]到专家权重超过单 GPU HBM 的大型 MoE 语言模型。我们按各工作线在服务时暴露的控制轴组织先前工作：专家权重驻留位置和移动时机，与精度如何分配及该分配是否可在线变化。我们的贡献是使在线精度驻留在单 GPU 上预算安全且非阻塞的运行时执行契约。

6.1 MoE 服务系统与专家卸载

MoE 服务系统旨在减少调度开销、改善专家并行性，并管理 GPU、CPU 和存储层级间的数据移动。DeepSpeed-MoE [25]、Tutel [16] 和 MegaBlocks [13] 专注于高效路由和分组专家执行，改善内核利用并减少通信和启动开销。这些框架主要假设专家参数在 GPU 内存中可用，其主要杠杆是围绕稀疏激活重构计算和调度。

另一条工作线将 GPU 内存视为瓶颈，并显式将专家卸载到较慢层级。MoE-Infinity [35] 刻画激活局部性并使用追踪指导专家缓存和卸载。ProMoE [28] 使用主动缓存，通过预测未来专家使用并在需求前预取来减少缓存未命中。ExpertFlow [27] 研究缓存感知路由和自适应调度，以跨层协调预取和内存使用。SwapMoE [19] 通过维护小型动态虚拟专家集并将其重映射到物理专家来减少内存占用，依赖局部性摊销交换成本。细粒度卸载通过提取更详细激活模式指导预取和缓存决策，进一步细化这一权衡[37]。Pre-gated MoE 通过预门控专家改变算法接口以减少激活波动并简化系统级调度[17]。这些系统主要回答专家权重应驻留何处及何时移动，在服务期间将权重视为固定精度对象。

近期工作开始在卸载存在的情况下探索混合精度。HOBBIT 提出混合精度专家卸载设计，用较低精度版本替换较不关键的缓存未命中专家，以在内存压力下减少加载延迟[29]。我们的工作在执行契约和决策边界上有所不同。我们采用稳定句柄将版本可见性与传输解耦，并将精度选择建模为由路由动态驱动的在线、预算受限问题。在此视角下，卸载和缓存仍是相关机制，但精度成为满足严格 HBM 预算同时限制后台转换干扰的额外控制轴。

6.2 MoE 量化与动态精度控制

训练后量化已成为减少 LLM 内存占用和提高吞吐量的标准工具。SmoothQuant [34] 等方法减少激活离群值以实现高效低比特推理，而 GPTQ [10]、AWQ [22] 和 SpQR [6] 等仅权重方案通过二阶近似、激活感知校准或稀疏量化表示提高低比特宽度下的精度。QuaRot 进一步表明固定旋转可消除激活离群值并实现端到端低比特推理，包括 KV 缓存[2]。这些方法对稠密 Transformer 有效，但通常产生静态量化模型，服务期间精度配置固定不变。

动态量化和自适应推理根据运行时信号（如层敏感性、硬件反馈或输入难度）调整执行。HAQ [31] 使用硬件感知搜索选择量化配置，而 AdaQuant [15] 和 FlexRound [20] 通过优化舍入和校准改进 PTQ 以保持精度。这些技术通常在层或块粒度上操作，设计用于所有参数参与每个 token 的稠密网络。MoE 引入了不同结构：专家激活稀疏、重尾且对工作负载迁移敏感，服务系统必须在避免阻塞转换的同时强制执行硬 HBM 预算。

若干近期论文针对 MoE 量化，利用专家异质性。MxMoE 在推导混合精度配置时考虑专家敏感性和激活动态，并将量化与混合精度分组 GEMM 的内核生成耦合[7]。MoPEQ 研究混合精度专家量化，根据激活频率和敏感性度量分配不同比特宽度给专家[7]。这些方法主要推导静态混合精度分配或需要与在线服务动态无关的离线分析。相比之下，我们的关注点是在严格设备内存约束下的在线精度驻留。我们依赖路由轨迹更新预算可行的高精度常驻集，并提供窗口级固定、确定性内存管理和有界干扰转换的非阻塞实现。该执行契约对服务至关重要，因为精度变化不得在并发批处理和变化工作负载下引入停滞或破坏尾延迟稳定性。

7 结论

我们提出了 DynaExq，用于紧张 HBM 预算下的单 GPU MoE 服务，将问题建模为由运行时路由驱动的在线、预算受限精度分配。DynaExq 将高精度集中在长时程热专家上，同时保持低精度回退，构造上强制预算可行性，并通过异步提升和降级更新驻留，使推理在稳定专家版本上继续。在具有偏斜和迁移路由的工作负载上，该设计较静态 PTQ 改善了质量-内存权衡，并减少了在密集激活下限制卸载与预取的等待延迟。