MoE 大模型能不能跑:容量和速度是两笔账,别混成一句「太大了」

成本账 · 约 2 步 / 10 分钟估算未标注整理于 2026-11-06 有效期 30d

Kimi K3.1 Pro 权重 1561GB,按单卡 141GB 算要 12 张卡;同一天网上两批说法——「2.8T 没戏」和「MoE 只激活 104B 没那么吓人」——都对但都没说到点上。容量是加法题、速度才是带宽题:总参是 65B 稠密模型的 43 倍,每 token 读取量只多 60%,但那 12 张卡一张都不能少。附两步判断顺序。

MoE激活率容量显存内存KimiB200稠密模型本地部署选型大模型参数量

这条适用于

版本指纹

官方模型卡参数 + HF 仓库文件体积

具体做法

【口径声明】本方案全部数字来自各模型官方公布的参数量与公开报道的权重体积,属按参数推算,不是本机实测。Kimi K3.1 Pro 权重 1.56TB(MXFP4)/ 5.6TB(BF16),本机最大内存 122GB,装不下,无法加载实测。

【四方对照(官方参数)】总参 / 激活 / 激活率 / FP8 每 token 需读:
PLaMo 0.8B(稠密)0.9B / 0.9B / 100% / 0.9 GB
Ripple-65B(稠密)65B / 65B / 100% / 65 GB
腾讯 Hy4(MoE)770B / 49B / 6.36% / 49 GB
Kimi K3.1 Pro(MoE)2800B / 104B / 3.71% / 104 GB

⇒ 关键比值:Kimi 总参是 Ripple-65B 的 43 倍,但每 token 读取量只多 60%(65 → 104 GB)。
⇒ 3.71% 激活率意味着 96.29% 的参数在任意单个 token 上都不参与计算。它是仓库,不是流水线。

【容量账】HF 仓库合计 1561GB;MXFP4 压到 1.56TB;BF16 需 5.6TB。按单卡 141GB 算,仅权重就要 12 张卡,还没算 KV 与计算缓冲。本机 122GB vs 1.56TB → 差 1439GB,需 13 台才装得下。且 12 张 141GB 的卡一台 8 卡机箱装不下,得两台。

【反证:小模型上两笔账是同一件事】65B 稠密模型 FP8 权重约 65GB,一张 80GB 卡就能装下,每 token 读 65GB —— 「装得下」和「跑得动」在这里重合。到 2800B 就分家了:容量要 12 张卡,速度只相当于稠密 104B 的水平。

【为什么会有两种误判】「2.8T 太大跑不动」把总参当成了每 token 读取量;「MoE 只激活 104B 所以还好」忽略了容量需求完全不变。两句话各自只覆盖了一半事实。

【Kimi K3.1 Pro 结构】93 层 = 69 层 KDA 线性注意力 + 24 层 Gated DSA;896 专家每次激活 16 个 + 2 个共享;1M 上下文;原生多模态;MXFP4 权重 + MXFP8 激活。

【本文唯一一条本机实测数】PLaMo 3 Translate 0.8B 档官方 GGUF Q4_K_M,实测 573,116,288 B —— 这是全文唯一在本机下过、校验过的数字,其余全是按参数推算。

【倍率写清】Kimi 总参 2800B 是 Ripple-65B(65B 稠密)的 43 倍;每 token 读取量 104 GB 对 65 GB = 1.6 倍。43 倍对 1.6 倍,这就是「参数大 ≠ 慢」的全部含义。
失效边界
全部为按官方参数与公开报道体积推算,非本机实测 —— Kimi K3.1 Pro 因 1.56TB 远超本机 122GB 内存,未做任何加载或推理实测。FP8 每 token 读取量按 1 字节/参数粗算,实际量化格式(MXFP4 / W4A16 / W4AFP8)会改变这个值,MXFP4 不是 1 字节/参数。激活率只决定带宽开销,不改变容量需求。KV 缓存与计算缓冲的精确占用未计入(本方案只算权重),实际显存需求会高于 12 张卡的权重下限。1561GB 为二手核实口径(社区按单卡 141GB 反算 12 张),非本体系直采。不同上下文长度、量化档位、并行策略下结论都会移动,判断顺序不变。
← 模型库 278GB,真正的权重只有 58 个文件「37 层压缩省 99%」到底省多少:按 config 逐层算一遍 →

← 返回全部排错方案