hipfire 是一个用 Rust 编写的 RDNA 原生 LLM 推理引擎，专为 AMD 显卡打造。它的杀手锏之一是MoE 专家卸载（expert offload）：把 MoE 模型里放不进显存的"专家层"映射到系统内存，从而让Qwen3.8-Flash这类约125GB的巨型 MoE 模型，在一张32GB 显卡（如 Radeon AI PRO R9700）加足够内存的机器上完整跑起来。本文用通俗语言拆解 hipfire 背后的四层思路，帮你理解为什么"显存不够"不再是"跑不动"的借口。

125GB 的 MoE 模型，为什么 32GB 显卡也有得跑？

先泼一盆冷水：Qwen3.8-Flash（registry 标签qwen3.8:flash-next）的单体量化文件约125.3 GB，任何 32GB 显卡都装不下，这是算术问题，没有奇迹。

但 MoE 模型的结构给了一个天然突破口。以 Qwen3.8-Flash 为例：

• 它有49 个 MoE 路由层、24576 个专家，但每个 token 只激活其中 8 个（top-8 路由）；
• 也就是说，每一步计算真正用到的专家只是一小部分，其余 90% 以上的专家权重大部分时间"睡大觉"；
• 模型里注意力、GDN 状态、语言头这些每步必算的"骨干"权重才必须留在显存里。

hipfire 的专家卸载就是抓住这一点：

显存只放骨干权重 + 最热的专家；剩下的专家层整体放进主机内存（pinned host RAM），需要时再访问。

速度会有代价（下文有实测曲线），但模型从"拒绝加载"变成"可以日常用"，这正是卸载的第一目标——官方设计文档的原话是"先让装不下的模型能跑起来，速度是二阶问题"（docs/plans/partial-gpu-offload-design.md）。

拆包加载：split base + PLE 旁车

要卸载，先得把 125GB 拆成"该进显存"和"该进内存"两部分。hipfire 对 Flash-Next 采用split base（拆分基座）方案：

• split base：由上一代 125.3GB 单体文件用hipfire ple split拆分而来，1197 个骨干张量与单体文件逐字节一致，只是把 128 个 PLE n-gram 分片剥离成独立旁车（配方与摘要见 AGENTS.md 的 Pinned Flash-Next bench fixture 一节）。
• PLE 行表：Flash-Next 的 n-gram 加速行。它本身体积大（q4 约 29GB），所以放在主机内存，靠 docs/MODELS.md 里描述的ple_prewarm机制在空闲时把"最热行"预温进 page cache，请求一来不卡盘。
• 下载时用一条命令即可，客户端会交互式询问选哪档：

hipfire pull qwen3.8:flash

标签档位、体积与"小卡如何从主机内存映射剩余专家"的说明，集中在 docs/PICK-A-MODEL.md（48–72 GB 一行："A smaller card maps the remaining experts from host RAM (the 0.4.4 release smoke ran it on a 32 GB R9700 and a 24 GB 7900 XTX)"）。

放置算法：auto 自动放置把"能塞多少塞多少"做成默认

拿到拆包后，hipfire 的放置器决定哪些 MoE 层的专家留在 VRAM、哪些 host-mapped。核心规则（docs/CONFIG.md partial-offload 一节）：

1. auto 是默认路径：不设置memory.moe_expert_budget/HIPFIRE_QWEN4_EXPERT_VRAM_LAYERS时，加载器按"fit-capacity placement"自动决定——先放骨干权重，再逐层塞路由专家，直到显存预算用尽，其余层自动落到 pinned 主机内存。
2. 手动旋钮：HIPFIRE_QWEN4_EXPERT_VRAM_LAYERS=N表示"前 N 层的专家留显存、第 N 层起进内存"，适合想精确控制 VRAM 占用的进阶用户。
3. 热专家旁车（expert-hotset）：Flash-Next 附带一个按 decode 热度排名的专家旁车（约 213KB），gfx1201 上会自动应用，让显存优先留给最常激活的专家，而不是平均分配。
4. 失败要"响亮"：放不下的配置不是 OOM 闪退，而是在加载时明确拒绝并打印具体是哪个旋钮、差多少字节（docs/SERVE.md 对 partial-offload refusal 有完整清单）。

一个硬性前提：主机内存要够大。实测结论（docs/MODELS.md、docs/EMU.md）：Flash-Next 有 38–61GB 的路由专家要 host-mapped，16GB 显存 + 64GB 内存的机器会因 GTT 上限加载失败，32GB 显卡跑它通常建议 128GB 主机内存。

PCIe 直通：GPU 直接"读"内存里的专家

专家放在内存里，谁来算？hipfire 默认答案是——还是 GPU 算。

memory.offload_exec默认是pcie模式：host-mapped 权重通过 pinned 零拷贝内存对 GPU 可见，GPU kernel 直接沿着 PCIe 链路读取内存中的专家权重，不需要先拷进显存。这是性能与复杂度的平衡点：

• 每个 token 只激活 top-8 专家，单步要搬的字节数有限；
• 换一批专家再读一遍，链路带宽就是天花板，但没有来回拷贝的往返延迟。

hipfire 还有一个"测速再决定"的机制（docs/CONFIG.md D2 measured default）：加载时实测本机 PCIe 链路与 CPU GEMV 的速度，只有当 CPU 直算至少快 15% 时才切到 CPU 执行，否则坚持 PCIe 路线——决策悲观对待 CPU、乐观对待 PCIe，宁可不切。

卸载的"档位"怎么选？看实测前沿曲线（docs/perf-checkpoints/2026-10-04-moe-offload-manual-vs-auto.md）：

上图以 Qwen3.5-35B 为同构样本（40 层、每层 408MiB 专家）：卸载 13 层时 decode 约 63 tok/s，卸载 36 层时约 42 tok/s——每多放走一层专家，速度线性掉一点，但从不崩溃。auto 放置落在"能塞下的最小卸载量"上（14 层 host-mapped，62.9 tok/s），与手工调参几乎重合。作为参照，llama.cpp 在同等卸载量下的锚点曲线：

实测成绩：32GB R9700 上的 Qwen3.8-Flash 有多快？

v0.4.4 发布版在R9700（32GB）+ 主机内存上跑qwen3.8:flash-next（split base + hot set，10-27 实测，docs/PICK-A-MODEL.md）：

日常对话 40–50 tok/s 已可读，开启原生 MTP 投机解码后代码场景逼近 83 tok/s。注意这些是特定构建、特定 prompt 的单点测量，不是保底值——官方文档对此有明确的历史测量声明。

进阶与替代路线：双卡 EP、统一内存 APU

单卡卸载是"能跑"的保底方案，如果你的硬件更好，hipfire 还有更快的路：

• 双卡/多卡专家并行（EP）：2–8 张同架构卡设topology.ep = N，专家直接分片到多卡显存。实测 2×32GB R9700 在 32K 上下文下每卡仍 host-map 19/49 层，EP4 可全部驻留，且 prefill 比单卡还快（docs/multi-gpu.md）。
• 统一内存 APU（Strix Halo）：128GB 统一内存可把整个模型放进单一内存池，无需卸载；甚至能挂 XDNA2 NPU 做 trunk prefill（16K prefill 2472 tok/s）。
• 更小的卡 + 更低档位：qwen3.8:flash-next-mq2-xts档位（base 44.5GB）让小卡更从容。

上手清单与常见问题

三步跑起来（以 32GB R9700 + 128GB 内存为例）：

hipfire pull qwen3.8:flash # 拉取 split base + PLE 旁车 + hotset hipfire run qwen3.8:flash "你好" --stats hipfire serve # 需要 HTTP 服务时

排障时记住这些"拒绝"信息都是有意设计的（docs/CLI.md 有 fit 报告的experts/host_ram/gtt三类结论）：

1. DOES NOT FIT+fix:行：说明差多少 VRAM / 内存，按提示加内存或换小档位，而不是盲目重试；
2. 16GB 卡 + 64GB 内存加载失败：GTT 上限问题，属已知限制，加内存或换 24GB/32GB 卡；
3. 速度低于预期：先看加载日志里qwen4 expert placement一行，确认多少层专家驻留、多少 host-mapped——卸载越多越慢是物理规律，想快就加卡上 EP；
4. 主机内存吃紧：PLE 表 29GB 也占内存，--ple q4拉低精度旁车可以省约 25GB 磁盘与内存压力（docs/MODELS.md）。

小结：专家卸载让"显存焦虑"变成"内存焦虑"

hipfire 用四个环环相扣的设计，把 125GB 的 Qwen3.8-Flash 塞进了 32GB 显卡的机器：

1. split base 拆包——骨干与专家物理解耦，各得其所；
2. auto 放置 + hotset 热排名——显存留给最该在的权重，其余进 pinned 内存；
3. PCIe 零拷贝直通——GPU kernel 直接读内存中的专家，少一次拷贝往返；
4. 响亮拒绝 + 实测选路——装不下就说清楚差多少，执行路线用实测数据说话而不是拍脑袋。

代价是 decode 速度随卸载量线性下降，收益是原本拒绝加载的模型变成日常可用的模型——对 32GB 显卡用户来说，40–80 tok/s 的 Qwen3.8-Flash 和"无法加载"之间，没有中间选项。

延伸阅读：docs/ARCHITECTURE.md（含 CPU 执行核心 crates/hipfire-cpu/）、docs/QUANTIZATION.md、docs/GETTING_STARTED.md。