福桃九分饱从一台 4 卡 4090 的机器落地开始说吧。最近拿到了一批新模型文件，其中 Qwen3.8-Flash-Next 的 GGUF 版本标签是 125b-a6b-q4_k_m，配套还有个 HY4-preview 要一起做横向对比。标题看着像模型名拼接，实际干的事很具体：把总参数量 125B、激活参数只有 6B 的稀疏模型，量化到 Q4_K_M 之后塞进 4 张 4090 的显存里跑推理，再和 HY4-preview 比速度、比显存占用、比生成质量。这篇文章把这套流程完整记录下来，包括硬件选型、显存估算、llama.cpp 编译参数、张量并行配置，以及和 HY4-preview 同台实测的数据。如果你手上也有类似的中等规模 MoE 模型部署需求，或者正准备在消费级显卡集群上跑稀疏大模型，这篇应该能帮你少走不少弯路。
1. 为什么 125b-a6b 这种“大而稀疏”的架构能塞进 4090
1.1 总参数 125B 但激活参数只有 6B，意味着什么
第一次看到 125b-a6b 这个标签，很多人第一反应是“125B 的模型，4 张 4090 一共才 96GB 显存，怎么可能跑得动”。这里的关键就在 a6b 上。
a6b 表示实际激活参数是 6B，属于典型的 MoE（Mixture of Experts，混合专家）架构。MoE 的做法是：把一个大模型拆成若干专家子网络，每个 token 进来之后，路由器（Router）只选择其中一小部分专家执行计算，而不是让所有参数都参与前向推理。所以“总参数 125B”和“激活参数 6B”是两个完全不同的概念——前者决定文件体积和显存占用，后者决定计算量和推理速度。
类比一下：一个 125 人的公司，档案柜里有所有人的资料（总参数），但每天实际需要办公的人只有 6 个（激活参数）。你租的办公楼只需要给这 6 个人留工位，而不是给全部 125 人准备工位。这就解释了为什么这种架构能在消费级显卡上做推理。
跟传统的稠密模型对比会更直观。一个 6B 稠密模型，所有参数全部参与计算，虽然显存需求不高，但能力和 125B 总参数的模型完全不是一个量级——毕竟 MoE 模型即使只激活 6B 参数，experts 的多样性也让它在知识密度和复杂推理上明显占优。这也是为什么现在各家都往“总参数做大、激活参数卡在个位数”的方向走。
1.2 Q4_K_M 量化到底做了什么
q4_k_m 是 GGUF 格式里常见的量化等级。具体来说，q4 表示以 4-bit 为主来做权重量化，k 表示基于 k-quants 方法，m 表示中间档位，兼顾模型质量和文件大小。相比 F16 原始权重，Q4_K_M 通常能把模型体积压到四分之一左右，同时保持相当高的生成质量。
对 125B 总参数的模型来说，F16 权重大约需要 250GB，这在任何单机上都很难跑。Quant 到 Q4_K_M 以后，模型文件体积大约在 68GB 到 72GB 之间（不同版本的文件略有差异）。这个体积正好卡在 4 张 4090 的 96GB 总量之内，剩下的显存还可以分配给 KV Cache、CUDA context 和推理中间缓冲。
不过要注意一个点：量化是拿精度换体积。Q4_K_M 对绝大多数常规任务的影响很小，但如果你的场景是代码生成、数学推理这类对数值精度敏感的任务，强烈建议先在 Q4_K_M 上跑一遍基线，再对比 Q5_K_M 或 Q6_K 的质量差异，不要盲目追求最低比特数。
1.3 显存估算：96GB 总量到底够不够
我在部署之前先做了一版显存估算，公式如下：
总显存占用 ≈ 权重显存 + KV Cache + CUDA Context / 临时缓冲
- 权重显存：约 70GB（Q4_K_M 的 GGUF 文件加载后基本不额外膨胀太多）
- KV Cache：以 4096 上下文、GQA 分组查询注意力计算，大约 1GB 到 2GB 起步
- CUDA Context +