尧图网络科技YAOTU DIGITAL 获取报价
获取报价
首页 / 资讯中心 / 文章详情

Dynamic Expert Quantization for Scalable Mixture-of-Experts Inference——动态专家量化:面向可扩展的混合专家推理

发布时间:2026/9/24 17:26:21

资讯中心
01
ARTICLE

Dynamic Expert Quantization for Scalable Mixture-of-Experts Inference——动态专家量化:面向可扩展的混合专家推理

Dynamic Expert Quantization for Scalable Mixture-of-Experts Inference——动态专家量化:面向可扩展的混合专家推理
《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 设计的观察观察 1MoE 激活在预填充和较大 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 版本化专家驻留VERVER 为每个 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 专家 IDVER 通过持久句柄表实现内存管理实现为固定粒度设备池和预算跟踪器转换管理器在后台线程运行在专用 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 A600048 GB。精度层级热专家高精度通常 FP16Qwen3-80B 为 INT4冷专家低精度INT4 或 INT2。对比基线静态量化Qwen3-30B/Phi-3.5-MoE 为 Int4Qwen3-80B 为 Int2和 ExpertFlow。3.3 质量结果Q1Qwen3-MoE-30B静态 Int4 将平均分从 65.29FP16降至 63.98DynaExq 提升至 64.38增益来自 GPQA54.14 vs. 53.54、GSM8K89.91 vs. 89.39、HumanEval84.76 vs. 84.15。Qwen3-MoE-80BInt2 将平均分降至 73.09DynaExq 提升至 77.57恢复一致且接近 Int4 基线的 78.11表明动态分配可在容量约束原本需要统一低比特压缩时接近更高比特配置。Phi-3.5-MoE静态 Int4 从 58.06 降至 56.31DynaExq 提升至 57.00。结论路由器驱动的精度分配可通过将较高精度集中在占执行份额较大的专家上在固定 GPU 预算下保持精度。3.4 性能结果Q2TTFT图 6静态量化最低避免关键路径权重移动ExpertFlow 随 batch 增长急剧上升DynaExq 更接近静态基线在各 batch size 下显著低于 ExpertFlow差距在高 batch 下更大。TPOP图 7ExpertFlow 显示更高 TPOP 和扩大的尾部DynaExq 通过分离计算流和迁移流并限制迁移速率TPOP 接近静态量化平均-P99 差距更小。端到端延迟图 9排序为静态量化 DynaExq ExpertFlowExpertFlow 因重复传输和同步产生复合延迟DynaExq 曲线增长更平缓。吞吐量DynaExq 始终优于 ExpertFlow提升范围1.42× 至 2.73×差距随 batch size 增长而扩大在 batch size 32 时达最高 2.73×。延迟随提示长度扩展图 10ExpertFlow 增长最陡、尾部放大最大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 贡献总结问题建模将硬性 HBM 约束下的单 GPU MoE 服务建模为一个在线的、预算受限的精度分配问题。调度器设计设计预算可行调度器跟踪长时程专家热度通过稳定 top-n 规则为每层选择高精度专家。非阻塞机制构建混合精度驻留的非阻塞机制使用稳定专家句柄和异步提升/降级将精度转换与 token 关键路径解耦。系统实现与验证实现 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-ExpertsMoE已成为一种实用的架构能够在大幅扩展大语言模型LLM容量的同时保持每 token 计算量适中。然而在单块显存受限的 GPU 上部署 MoE 模型仍然困难重重因为专家权重占据了 HBM 内存的主要部分。现有的专家卸载与预取系统虽然减少了常驻内存集但当激活变得密集时它们往往会在关键路径上付出专家加载的代价。训练后量化Post-Training QuantizationPTQ无需数据传输即可降低内存占用但主流流程离线固定专家比特宽度并假设路由保持稳定——然而 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 利用不足。观察 1MoE 激活在预填充和较大 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 设计DynaExq3.1 概述图 4 总结了端到端控制循环。工作器执行 MoE 推理而调度器观察路由轨迹并在严格 GPU 内存预算下更新专家精度驻留。设计将推理工作流与后台转换分离并暴露稳定接口使驻留变化不会在窗口内扰动执行。在工作器侧每个请求调用路由器以获得 top-k 专家 ID用于索引句柄表。每个句柄身份稳定并解析到一个active_ptr指向完全物化的专家版本。自适应由异步消费路由轨迹的调度器驱动。热度估计器维护每专家的时间统计量。这些统计量馈入预算可行调度器为每层 t 选择高精度常驻集受层容量 nhi,t 约束。容量由预算初始化一次性导出该初始化考虑 KV 缓存等固定 GPU 分配并将剩余设备内存保留给专家权重。所得目标集驱动转换管理器后者维护提升和驱逐队列并发出后台工作以物化变更。内存被分区以使转换可预测。在 GPU 上专家权重存储在高精度和低精度版本的独立池中与 KV 缓存区域隔离。当转换管理器提升一个专家时它从高精度池分配空间从主机内存获取准备好的权重版本然后复制到设备。复制完成后发布步骤更新句柄表使新版本在下一迭代可见。驱逐在发布步骤成功后回收旧版本。这种组织使图 4 的架构与接下来描述的四个组件保持一致图 4DynaExq 系统架构。VER 定义稳定句柄内存管理提供确定性池和预算门控转换流水线执行非阻塞提升和驱逐操作并限制干扰策略根据路由器导出的热度在固定每层容量下决定高精度驻留。3.2 版本化专家驻留VER为在 GPU 上管理不同精度的专家并在工作负载或激活分布变化时实现专家精度切换我们设计了版本化专家驻留Versioned Expert ResidencyVER。VER 提供了一种通过版本化精度控制专家驻留的机制。对于每个 MoE 层 ℓ 和专家 eVER 维护多个权重版本以不同数值格式实现相同算子。在最简配置中每个专家有一个高精度版本和一个低精度版本。高精度版本面向精度关键执行低精度版本提供内存高效回退。专家条目与稳定句柄。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 模型配置Qwen3-30BQwen3-80B (Int4)Phi-MoE总参数30.5B80B42B每 Token 激活参数3.3B3B6.6B总权重大小57GB41GB78GB专家权重大小54GB (95%)37GB (93%)75GB (96%)层数484832每层专家数12851216每层共享专家0102Top-K81025 评估我们在单 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 A600048 GB上运行实验中使用两个精度层级热专家分配较高精度版本通常为 FP16Qwen3-80B 为 INT4冷专家保持较低精度版本INT4 或 INT2。资源限制下的延迟与吞吐量。我们用三个互补测量评估服务性能。第一扫描 batch size 并报告平均和 P99 的 TTFT 与 TPOP。第二变化 token 数量并测量延迟如何随提示长度和生成长度扩展同样报告平均和 P99。第三报告预填充和解码的端到端吞吐量。所有测量在相同内存预算下进行因此报告的尾部行为反映了后台转换与计算路径之间的交互。5.2 DynaExq 的质量表 4 将 DynaExq 与 FP16 和静态低比特量化进行比较。在 Qwen3-MoE-30B 上静态 Int4 将平均分从 65.29FP16降至 63.98。在相同单 GPU 能力下DynaExq 将平均分提升至 64.38。增益来自 GPQA54.14 vs. 53.54、GSM8K89.91 vs. 89.39和 HumanEval84.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。改进反映在 GPQA35.94 vs. 34.52、GSM8K88.25 vs. 87.54和 HumanEval70.22 vs. 69.41上。总体而言这些结果支持以下前提路由器驱动的精度分配可以通过将较高精度集中在占执行份额较大的专家上在固定 GPU 预算下保持精度。表 4不同模型/方法的精度比较模型方法MMLU-ProGPQAAIME25GSM8KHumanEval平均Qwen3-MoE-30BFP1673.3754.5523.3390.4584.7665.29Int472.8453.5420.0089.3984.1563.98DynaExq73.0954.1420.0089.9184.7664.38Qwen3-MoE-80BInt475.9272.2270.0087.0485.3778.11Int272.7566.6763.3380.9781.7173.09DynaExq75.4871.2166.6786.7384.7677.57Phi-3.5-MoEFP1654.2336.7540.0088.6670.6458.06Int453.4034.5236.6787.5469.4156.31DynaExq53.9135.9436.6788.2570.2257.005.3 DynaExq 的性能我们在相同设备内存预算下在单块 A6000 GPU 上评估性能。我们将 DynaExq 与静态量化基线Qwen3-30B 和 Phi-3.5-MoE 为 Int4Qwen3-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 改善了质量-内存权衡并减少了在密集激活下限制卸载与预取的等待延迟。
02
RELATED NEWS

相关资讯

更多网站建设与数字化升级内容

03
WHY YAOTU

想打造同款高转化官网?

懂行业、懂生意,从建站到增长一站式陪跑

场景化定制

不做模板站,围绕你的业务场景量身设计,小众不撞款。

营销型架构

以转化目标组织内容与路径,让官网真正带来询盘。

全周期服务

设计、开发、运营、运维一体,上线只是开始。

免费获取你的建站方案

留下需求,专属顾问 24 小时内为你输出方案建议。