Luce Spark：在 16GB 显存上运行 35B MoE 模型，无需承受 Offload 的性能损耗

背景

混合专家模型（Mixture-of-Experts, MoE）在推理效率上具有显著优势，但其内存占用问题一直是部署瓶颈。以 Qwen3.6 35B-A3B 和 Laguna XS.2 为例，这两类模型的总参数量分别为 35B 和 33B，但每个 token 仅激活约 3B 参数（即 A3B 架构）。具体而言，路由器在每一层从 256 个专家中仅选择约 8 个进行计算。

虽然计算开销很小，但内存账单却非常沉重。为了在 GPU 上运行此类模型，传统做法必须将所有专家权重保留在 VRAM 中，因为无法预知下一个 token 会路由到哪个专家。在 24GB 显存的显卡上，仅专家权重就占据了 18.2 GiB（Qwen）或 16.6 GiB（Laguna），加上非专家权重和 KV Cache，总显存需求达到 18-21 GiB，这已经逼近甚至超过了许多消费级显卡的极限。而在 16GB 显存的显卡上，这些模型根本无法加载。

传统的“专家卸载”（Expert Offloading）技术虽然可以将冷专家（不常用的专家）移至系统 RAM 并通过 CPU 计算，但这会带来巨大的速度惩罚。如果驻留集（Resident Set，即留在 GPU 上的专家集合）选择错误，CPU 层可能会处理每个 token 路由中三分之一的请求，导致性能断崖式下跌。因此，关键在于如何精准地决定哪些专家留在 GPU 上，以及如何在服务过程中低成本地修正这一决策。

核心内容

Luce Spark 是构建在 lucebox-hub 现有的热/冷 MoE 卸载引擎之上的解决方案，它通过两个核心创新解决了上述问题：精准知道保留哪些专家，以及以极低的成本在服务过程中动态调整这一决策。

1. 基于流量校准的放置策略（Calibrated Placement）

Spark 的核心逻辑是：真正应该驻留在 GPU 上的专家，是那些被实际流量路由到最多的专家。

• 动态学习：Spark 从真实请求中累积每个（层，专家）的路由频率，并将使用频率最高的专家集“钉”在 GPU 上（Hot）。
• 长尾处理：那些极少被访问的专家（长尾部分）保留在系统 RAM 中（Cold）。
• 效果：在保留流量测试中，这种基于校准的放置策略将“冷命中”率从均匀分布时的 36% 降低到了约 7%。

2. 有界专家缓存与异步复制（Bounded Expert Cache）

为了处理剩余的冷专家请求，Spark 引入了一种高效的缓存机制：

• 环形缓存：GPU 上预留了一组固定的备用插槽（Ring Buffer）。
• 异步交换：当请求命中冷专家时，其权重从固定的主机内存异步复制到 GPU 的备用插槽中，同时与计算重叠（Overlapped）。
• LRU 淘汰：如果备用插槽已满，则驱逐最近最少使用（LRU）的条目。
• 性能影响：在 60% 的专家驻留率下，虽然仍有少量路由未命中驻留集，但权重复制过程被隐藏在矩阵乘法（Matmul）之下，而不是阻塞计算。这意味着它消耗的是吞吐量而非导致性能悬崖。

3. 融合图解码消除 Offload 税

传统的卸载方案往往因为每层构建独立的 GPU 图（Graph）而产生巨大的提交开销。Spark 通过以下方式解决：

• 全图融合：Laguna 后端将路由后的 FFN（前馈神经网络）折叠到注意力图中，将整个 token 的解码作为一个单一的融合图执行，而不是每层构建 40 个独立图。
• 一致性验证：在完全驻留模式下，融合解码的结果与全 GPU 运行结果比特级一致（Bit-identical），且速度相同（119 tok/s）。

4. 自我调优与易用性

• 零校准步骤：无需离线校准或特定语料库。服务器从实时流量中学习放置配置，并将其写入模型文件旁的 .spark.csv 文件中。
• 渐进式优化：每次重启都会加载更好的配置档案，使模型启动时更“热”。
• 单一命令：通过 --spark 标志即可启用，支持 Laguna 和 Qwen 后端。

关键要点

• 显存占用大幅降低：

  • Qwen3.6 35B-A3B：显存占用降至 13.3 GiB（原需 ~20.5 GiB）。
  • Laguna XS.2 33B-A3B：显存占用降至 14.6 GiB（原需 18.8 GiB）。
  • 两者均在 RTX 3090（24GB）上测试，但均可在 16GB 显存的显卡上运行，这是此前无法实现的。

• 性能保持高位：

  • 在 60% 专家驻留率下，Laguna 的解码速度约为 100 tok/s，接近全 GPU 运行的上限（119 tok/s），是朴素卸载方案（66 tok/s）的 1.5 倍。
  • Qwen3.6 35B-A3B 在 13.3 GiB 运行点下，保持了全 GPU 性能 92% 的速度。

• 技术机制：

  • Hot/Warm/Cold 分层：Hot 专家（校准后常驻 GPU）、Warm 专家（在缓存环中）、Cold 专家（在 RAM 中，按需 Swap）。
  • 异步隐藏延迟：通过异步复制和计算重叠，将 Swap 开销隐藏在计算之下。
  • 融合图优化：消除每层图提交的开销。

• 操作极简：

  • 无需人工干预调参。
  • 命令示例：dflash_server <model.gguf> --spark
  • 可选参数：--spark-slots 调整缓存槽位数量（默认 32）。

• 自我进化：

  • 模型服务时间越长，放置配置越精准。
  • 支持可选的离线引导工具（optimizations/spark/），可使用自有日志快速生成初始配置，但非必需。

意义与影响

Luce Spark 的出现标志着 MoE 模型部署门槛的重大降低。它通过算法层面的优化，将原本需要 24GB 甚至更高显存才能运行的 33-35B 参数级 MoE 模型，成功压缩至 16GB 显存的消费级显卡上运行。

1. ** democratization of MoE**：对于本地推理（Local Inference）用户而言，这意味着在普通的 PC 上运行高性能 MoE 模型从“不可能”变为“可行”。16GB 显存的显卡（如 RTX 3060 12GB/16GB 或 RTX 4060 Ti 16GB）现在可以胜任此前需要专业硬件才能处理的模型。
2. 性能与成本的平衡：它证明了通过智能的内存管理和图融合技术，可以在不牺牲太多性能（仅损失约 15-20% 吞吐量）的前提下，大幅降低硬件需求。这对于资源受限的边缘计算或低成本部署场景具有极高价值。
3. 自适应推理范式：Spark 的“自我调优”特性代表了推理引擎的一种新趋势——即系统能够根据实际流量模式动态调整资源分配，而非依赖静态的、通用的配置。这种适应性使得模型在不同业务场景下都能保持较高的效率。

总之，Luce Spark 不仅是一个优化工具，更是一种新的 MoE 服务范式，它