参悟llama.cpp中的Qwen3.6-35B-A3B

参悟llama.cpp中的Qwen3.6-35B-A3B

懒人版：直接复制给LLM，“总结一下这篇文章讲了什么”

前言

这篇文章既是对一系列探究性实践的记录与总结，也是深入理解 MoE（Mixture of Experts）架构底层逻辑与 llama.cpp 部署机制的学习过程。

模型: Qwen3.6-35B-A3B
框架: llama.cpp (Build: 91c631b21)
硬件: 1 x RTX 3090 (24GB, 936 GB/s), 1 x Tesla T4 (16GB)

Qwen3.6-35B-A3B: https://www.modelscope.cn/models/Qwen/Qwen3.6-35B-A3B

llama.cpp: https://github.com/ggml-org/llama.cpp

1. 疑问

1.1 什么是MOE？

MoE 的本质是将一个巨大的神经网络拆解为多个独立的子网络（专家，Expert），并配有一个“路由器”。

  • 路由器：分析输入 Token，决定哪几个专家（通常 2-8 个）最适合处理当前上下文。
  • 专家：彼此独立，擅长特定领域（如代码、数学）。
  • 稀疏激活：推理时，只有被选中的专家参与计算。对于 Qwen3.6-35B-A3B，总参数 35B，但每个 Token 仅激活约 3B 参数。

以Qwen3.6-35B-A3B为例，

参数总量：共 35B，其中激活参数为 3B
隐藏层维度：2048
Token 嵌入：248320（已填充）
层数：40
隐藏层结构：10 × (3 × (门控 DeltaNet → MoE) → 1 × (门控注意力 → MoE))
门控 DeltaNet：

  • 线性注意力头数量：V 为 32，QK 为 16
  • 头维度：128
    门控注意力：
  • 注意力头数量：Q 为 16，KV 为 2
  • 头维度：256
    旋转位置嵌入维度：64
    混合专家（Mixture Of Experts）
  • 专家总数：256
  • 激活专家数：8 个路由专家 + 1 个共享专家
  • 专家中间层维度：512

忽略潜入层、预测层和MTP层等一次性层，只考虑循环了40层的（注意力+MoE）结构，Qwen3.6-35B-A3B的参数比例可以粗略估计：

设40层注意力的总和参数规模为X，40层路由专家的总和参数规模为256Y，40层共享专家的总和参数规模为Z，则有：

  • X + 256Y + Z = 35B
  • X + 8Y + Z = 3B

可以推算出：

  • Y = (35B - 3B) / (256 - 8) ≈ 4/31 B = 0.129 B
  • X+Z = 1.9677 B
  • 路由专家占据了 256Y 约等于 33.03B，留给其他层的容量只有不到2B。

以上为纯以理解为目的的粗略估算，精准数值还是要认真学习对应架构、知识、源码才能算得出来。

1.2 为什么MOE推理速度快？

由于MoE架构中只有部分专家参与计算，因此可以显著减少每次推理时需要处理的参数量，从而提高推理速度。

以3B为例，就算以fp16精度进行计算，完成一个token的推理也只需要处理约6GiB的数据，在3090 35.6 TFLOPS的算力下，理论上可以在不到1ms内完成一个token的推理。真正的算力瓶颈反而是其936 GB/s的显存带宽，其推理速度的物理上限就是 936/6 ≈ 156 T/s，而现实中还得考虑推理框架的效率、算力调度等因素，实际速度一定会明显低于这个上限。

但是理论物理上限仍然高于同系列的Qwen3.6-27B模型，后者的参数量为27B，激活参数量为27B，fp16精度下每个token的推理需要处理约54GiB的数据，3090的显存带宽936 GB/s下，理论物理上限为 936/54 ≈ 17 T/s，远低于Qwen3.6-35B-A3B的156 T/s。

1.3 MOE的显存占用更小吗？

取决于上下文长度和注意力层的设计。

当上下文很短的时候，Qwen3.6-35B-A3B的显存占用反而大于Qwen3.6-27B。这是因为显存占用主要由模型权重+KVCache+中间激活值组成，而KVC的占用量与上下文长度成正比，注意力层的设计也会影响KVC的占用量。

当上下文很长的时候，Qwen3.6-27B的显存占用会超过Qwen3.6-35B-A3B，因为Qwen3.6-35B-A3B的注意力层参数规模远小于Qwen3.6-27B，KVC的占用量也远小于Qwen3.6-27B。此时KVCache成为了Qwen3.6-27B的主要显存占用来源，而Qwen3.6-35B-A3B即使在原生最大的256K上下文下，KVCache的占用量也只有约6.25GiB，相比于总权重数据量大35GiB不值一提。

门控注意力的KV Cache大小 (字节) = 层数 × 序列长度 × 每个 Token 的 KV 维度 × 2（K和V） × 字节数
30 * 262144 * 128 * 2 * 2 + 10 * 262144 * 256 * 2 * 2 = 6,710,886,400 字节 ≈ 6.25 GiB

1.4 llama.cpp对MOE有哪些支持？

  • 支持运行高度量化的MoE模型（q4_0, q8_0等）。
  • ncmoe N：将前 N 层的 MoE 权重卸载到 CPU。N=0 全在 GPU，N=40 全部在 CPU。
  • ctk / -ctv：控制 KV Cache 的量化精度（f16, q8_0, q4_0）。
  • ngl：控制加载到 GPU 的层数（对于 MoE，通常设为 999 让 llama.cpp 自动管理，或通过 ncmoe 精细控制）。

1.5 1张3090能跑Qwen3.6-35B-A3B吗？

直接下载usloth量化的Qwen3.6-35B-A3B-UD-Q4_K_M.gguf，其大小为22.13GB，显然1张3090理论上刚好能装下。但如果你真的去部署就发现会OOM，因为：

  • 显存占用不仅仅是模型权重，还包括KV Cache和中间激活值。
  • llama.cpp的固有开销。
  • 预留显存给系统和其他程序。

那么就只能尝试更高强度的量化，例如Qwen3.6-35B-A3B-UD-Q2_K_XL.gguf(12.29GB)或者Qwen3.6-35B-A3B-UD-IQ4_NL.gguf(18.04GB)。

一般来说，Q4_K_M量化能去的质量与性能的平衡，强度高于q4都会显著损失性能，强度低于q4则显存占用会显著增加。

因此可以尝试IQ4_NL量化，或者，迎难而上，从其他角度解决这个问题。

2. 理解

2.1 个人部署大模型关注的性能指标

个人使用大模型往往用于Chat和Agentic Engineering，往往只关注3个指标：

  • 显存占用：显存占用越小，部署的灵活性越高。
  • 上下文长度：上下文长度越长，模型的上限就越高。
  • 推理速度：推理速度越快，交互体验越好。

2.2 影响显存占用的因素

  • 模型参数量：参数量越大，显存占用越高。（这一项没有办法通过工程手段控制）
  • 权重量化精度：量化精度越低，显存占用越小。（这一项没有办法通过工程手段控制）
  • 上下文长度：上下文长度越长，KV Cache的显存占用越高。
  • 中间激活值：中间激活值越多，显存占用越高。（这一项没有办法通过工程手段控制）

这就让我们陷入了一个矛盾，如果我们想要更长的上下文长度，就必须要有更大的显存占用，但是我们想要更小的显存占用，就必须要有更短的上下文长度。

幸好，llama.cpp提供了ctk/ctv参数来控制KV Cache的量化精度，从而在一定程度上缓解了这个矛盾。

2.3 影响推理速度的因素

  • 模型激活参数量：激活参数量越大，推理速度越慢。（然而这一项只由模型作者决定）
  • GPU的计算精度支持：原生支持的精度越低，浪费在反量化上的时间越少，推理速度越快。（3090只支持fp16和int8，且算力已经溢出）
  • GPU的显存带宽：显存带宽越高，推理速度越快，这是第一个内存墙。（3090只有936 GB/s，成为瓶颈）
  • CPU的计算精度支持：可惜，CPU最低通过AVX2支持fp16，推理速度远低于GPU，但服务器级别的CPU算力性能对于“A3B”来说也溢出了。
  • CPU RAM的带宽：这是第二个内存墙，CPU RAM的带宽远低于GPU显存带宽，成为瓶颈。

有时候，我们不得不卸载部分权重和计算到CPU上。

3. 采样实验

太多了，可以直接跳到第4章。

对于我来说，理论分析最大的障碍不是知识本身，而是缺乏实践导致的就算完成了理论推算，也不敢相信自己推算的正确性。

这种心理往往会让人陷入精神内耗，而教员的实践论说了，想不通就先干。

为了用1张3090部署256K上下文的Qwen3.6-35B-A3B，有两种潜在的方向：

  1. 卸载部分权重和计算到CPU上，降低GPU显存占用，llama.cpp的-ncmoe参数可以做到这一点。
  2. 降低KV Cache的量化精度，降低GPU显存占用，llama.cpp的-ctk和-ctv参数可以做到这一点。

3.1 不同配置下的显存占用测试

用llama-server不断在不同的配置下部署模型，并在推理过程中观察显存占用情况，记录如下：

序号 KV类型 ncmoe 上下文长度 已用显存 总显存
1 f16 0 8192 21386MiB 24576MiB
2 f16 0 16384 21554MiB 24576MiB
3 f16 0 32768 21890MiB 24576MiB
4 f16 0 65536 22562MiB 24576MiB
5 f16 0 131072 23906MiB 24576MiB
7 f16 1 8192 21078MiB 24576MiB
8 f16 1 16384 21246MiB 24576MiB
9 f16 1 32768 21582MiB 24576MiB
10 f16 1 65536 22254MiB 24576MiB
11 f16 1 131072 23598MiB 24576MiB
13 f16 2 8192 20618MiB 24576MiB
14 f16 2 16384 20786MiB 24576MiB
16 f16 2 65536 21794MiB 24576MiB
17 f16 2 131072 23138MiB 24576MiB
19 f16 4 8192 19830MiB 24576MiB
20 f16 4 16384 19998MiB 24576MiB
21 f16 4 32768 20334MiB 24576MiB
22 f16 4 65536 21006MiB 24576MiB
23 f16 4 131072 22350MiB 24576MiB
25 f16 8 8192 17974MiB 24576MiB
26 f16 8 16384 18142MiB 24576MiB
27 f16 8 32768 18478MiB 24576MiB
28 f16 8 65536 19150MiB 24576MiB
29 f16 8 131072 20494MiB 24576MiB
30 f16 8 262144 23182MiB 24576MiB
31 f16 16 8192 14264MiB 24576MiB
32 f16 16 16384 14432MiB 24576MiB
33 f16 16 32768 14768MiB 24576MiB
34 f16 16 65536 15440MiB 24576MiB
35 f16 16 131072 16784MiB 24576MiB
36 f16 16 262144 19472MiB 24576MiB
37 f16 32 8192 6840MiB 24576MiB
38 f16 32 16384 7008MiB 24576MiB
39 f16 32 32768 7344MiB 24576MiB
40 f16 32 65536 8016MiB 24576MiB
41 f16 32 131072 9360MiB 24576MiB
42 f16 32 262144 12048MiB 24576MiB
43 f16 64 8192 3058MiB 24576MiB
44 f16 64 16384 3226MiB 24576MiB
45 f16 64 32768 3562MiB 24576MiB
46 f16 64 65536 4234MiB 24576MiB
47 f16 64 131072 5578MiB 24576MiB
48 f16 64 262144 8266MiB 24576MiB
49 q8_0 0 8192 21312MiB 24576MiB
50 q8_0 0 16384 21420MiB 24576MiB
51 q8_0 0 32768 21638MiB 24576MiB
52 q8_0 0 65536 22074MiB 24576MiB
53 q8_0 0 131072 22946MiB 24576MiB
55 q8_0 1 8192 21004MiB 24576MiB
56 q8_0 1 16384 21096MiB 24576MiB
57 q8_0 1 32768 21282MiB 24576MiB
58 q8_0 1 65536 21654MiB 24576MiB
59 q8_0 1 131072 22630MiB 24576MiB
61 q8_0 2 8192 20544MiB 24576MiB
62 q8_0 2 16384 20636MiB 24576MiB
63 q8_0 2 32768 20822MiB 24576MiB
64 q8_0 2 65536 21194MiB 24576MiB
65 q8_0 2 131072 22170MiB 24576MiB
66 q8_0 2 262144 23914MiB 24576MiB
67 q8_0 4 8192 19756MiB 24576MiB
68 q8_0 4 16384 19848MiB 24576MiB
69 q8_0 4 32768 20034MiB 24576MiB
70 q8_0 4 65536 20406MiB 24576MiB
71 q8_0 4 131072 21238MiB 24576MiB
72 q8_0 4 262144 22982MiB 24576MiB
73 q8_0 8 8192 17900MiB 24576MiB
74 q8_0 8 16384 17992MiB 24576MiB
75 q8_0 8 32768 18178MiB 24576MiB
76 q8_0 8 65536 18550MiB 24576MiB
77 q8_0 8 131072 19382MiB 24576MiB
78 q8_0 8 262144 21126MiB 24576MiB
79 q8_0 16 8192 14190MiB 24576MiB
80 q8_0 16 16384 14282MiB 24576MiB
81 q8_0 16 32768 14468MiB 24576MiB
82 q8_0 16 65536 14840MiB 24576MiB
83 q8_0 16 131072 15672MiB 24576MiB
84 q8_0 16 262144 17416MiB 24576MiB
85 q8_0 32 8192 6766MiB 24576MiB
86 q8_0 32 16384 6858MiB 24576MiB
87 q8_0 32 32768 7044MiB 24576MiB
88 q8_0 32 65536 7416MiB 24576MiB
89 q8_0 32 131072 8248MiB 24576MiB
90 q8_0 32 262144 9992MiB 24576MiB
91 q8_0 64 8192 2984MiB 24576MiB
92 q8_0 64 16384 3076MiB 24576MiB
93 q8_0 64 32768 3262MiB 24576MiB
94 q8_0 64 65536 3634MiB 24576MiB
95 q8_0 64 131072 4432MiB 24576MiB
96 q8_0 64 262144 6176MiB 24576MiB
97 q4_0 0 8192 21272MiB 24576MiB
98 q4_0 0 16384 21340MiB 24576MiB
99 q4_0 0 32768 21478MiB 24576MiB
100 q4_0 0 65536 21754MiB 24576MiB
101 q4_0 0 131072 22306MiB 24576MiB
102 q4_0 0 262144 23410MiB 24576MiB
103 q4_0 1 8192 20964MiB 24576MiB
104 q4_0 1 16384 21016MiB 24576MiB
105 q4_0 1 32768 21122MiB 24576MiB
106 q4_0 1 65536 21334MiB 24576MiB
107 q4_0 1 131072 21990MiB 24576MiB
108 q4_0 1 262144 23094MiB 24576MiB
109 q4_0 2 8192 20504MiB 24576MiB
110 q4_0 2 16384 20556MiB 24576MiB
111 q4_0 2 32768 20662MiB 24576MiB
112 q4_0 2 65536 20874MiB 24576MiB
113 q4_0 2 131072 21530MiB 24576MiB
114 q4_0 2 262144 22634MiB 24576MiB
115 q4_0 4 8192 19716MiB 24576MiB
116 q4_0 4 16384 19768MiB 24576MiB
117 q4_0 4 32768 19874MiB 24576MiB
118 q4_0 4 65536 20086MiB 24576MiB
119 q4_0 4 131072 20598MiB 24576MiB
120 q4_0 4 262144 21702MiB 24576MiB
121 q4_0 8 8192 17860MiB 24576MiB
122 q4_0 8 16384 17912MiB 24576MiB
123 q4_0 8 32768 18018MiB 24576MiB
124 q4_0 8 65536 18230MiB 24576MiB
125 q4_0 8 131072 18742MiB 24576MiB
126 q4_0 8 262144 19846MiB 24576MiB
127 q4_0 16 8192 14150MiB 24576MiB
128 q4_0 16 16384 14202MiB 24576MiB
129 q4_0 16 32768 14308MiB 24576MiB
130 q4_0 16 65536 14520MiB 24576MiB
131 q4_0 16 131072 15032MiB 24576MiB
132 q4_0 16 262144 16136MiB 24576MiB
133 q4_0 32 8192 6726MiB 24576MiB
134 q4_0 32 16384 6778MiB 24576MiB
135 q4_0 32 32768 6884MiB 24576MiB
136 q4_0 32 65536 7096MiB 24576MiB
137 q4_0 32 131072 7608MiB 24576MiB
138 q4_0 32 262144 8712MiB 24576MiB
139 q4_0 64 8192 2944MiB 24576MiB
140 q4_0 64 16384 2996MiB 24576MiB
141 q4_0 64 32768 3102MiB 24576MiB
142 q4_0 64 65536 3314MiB 24576MiB
143 q4_0 64 131072 3792MiB 24576MiB
144 q4_0 64 262144 4896MiB 24576MiB

3.2 不同配置下的推理速度测试

model size params backend ngl fa test t/s
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 pp256 2597.45 ± 27.18
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 tg256 154.43 ± 0.34
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 pp512 3430.11 ± 33.18
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 tg512 153.56 ± 0.40
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 pp1024 3428.32 ± 19.55
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 tg1024 153.09 ± 0.28
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 pp2048 3389.95 ± 15.49
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 tg2048 151.92 ± 0.15
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 pp4096 3331.15 ± 18.29
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 tg4096 150.90 ± 0.27
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 pp8192 3246.80 ± 23.03
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 tg8192 149.02 ± 0.03
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 pp16384 3121.98 ± 11.93
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 tg16384 146.02 ± 0.22
model size params backend ngl type_k type_v fa test t/s
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 pp256 2588.50 ± 42.67
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 tg256 151.48 ± 0.64
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 pp512 3441.18 ± 25.07
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 tg512 150.97 ± 0.16
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 pp1024 3392.41 ± 22.50
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 tg1024 149.47 ± 0.30
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 pp2048 3353.24 ± 15.10
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 tg2048 147.73 ± 0.42
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 pp4096 3271.68 ± 19.67
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 tg4096 145.95 ± 0.19
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 pp8192 3214.79 ± 20.45
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 tg8192 142.95 ± 0.15
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 pp16384 3075.39 ± 8.89
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q8_0 q8_0 1 tg16384 138.21 ± 0.07
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 pp256 2572.44 ± 31.25
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 tg256 149.69 ± 0.34
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 pp512 3408.31 ± 34.58
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 tg512 148.75 ± 0.23
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 pp1024 3382.18 ± 18.49
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 tg1024 148.04 ± 0.27
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 pp2048 3342.87 ± 17.04
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 tg2048 147.15 ± 0.16
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 pp4096 3276.92 ± 20.85
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 tg4096 145.38 ± 0.24
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 pp8192 3208.74 ± 21.82
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 tg8192 141.83 ± 0.16
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 pp16384 3065.99 ± 12.52
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 q4_0 q4_0 1 tg16384 136.11 ± 0.10
model size params backend ngl n_cpu_moe fa test t/s
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 pp256 1382.40 ± 40.33
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 tg256 143.65 ± 0.82
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 pp512 2101.12 ± 27.76
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 tg512 144.80 ± 0.25
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 pp1024 2111.58 ± 19.31
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 tg1024 137.42 ± 1.84
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 pp2048 2102.57 ± 18.04
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 tg2048 137.34 ± 2.13
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 pp4096 2084.55 ± 6.25
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 tg4096 140.47 ± 0.50
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 pp8192 2055.45 ± 8.94
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 tg8192 137.27 ± 0.39
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 pp16384 2001.76 ± 7.48
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 1 tg16384 136.56 ± 0.26
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 pp256 934.74 ± 16.93
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 tg256 132.00 ± 0.58
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 pp512 1502.21 ± 20.14
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 tg512 135.54 ± 0.33
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 pp1024 1506.38 ± 9.86
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 tg1024 135.84 ± 0.68
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 pp2048 1511.62 ± 16.53
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 tg2048 127.74 ± 0.48
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 pp4096 1492.47 ± 8.55
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 tg4096 125.46 ± 0.42
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 pp8192 1487.76 ± 7.11
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 tg8192 125.11 ± 0.53
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 pp16384 1469.13 ± 3.86
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 2 1 tg16384 130.18 ± 0.23
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 pp256 574.18 ± 7.65
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 tg256 113.82 ± 1.83
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 pp512 954.11 ± 11.41
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 tg512 123.88 ± 1.11
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 pp1024 961.74 ± 7.78
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 tg1024 123.63 ± 0.21
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 pp2048 961.56 ± 4.45
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 tg2048 122.61 ± 0.38
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 pp4096 959.54 ± 2.39
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 tg4096 120.99 ± 0.42
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 pp8192 956.03 ± 2.05
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 tg8192 121.32 ± 0.41
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 pp16384 946.81 ± 2.85
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 4 1 tg16384 114.45 ± 0.33
model size params backend ngl n_cpu_moe type_k type_v fa test t/s
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 pp256 1357.53 ± 67.94
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 tg256 140.76 ± 0.55
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 pp512 2105.04 ± 33.56
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 tg512 135.62 ± 1.49
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 pp1024 2110.99 ± 13.32
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 tg1024 137.20 ± 0.90
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 pp2048 2108.66 ± 8.02
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 tg2048 134.88 ± 0.72
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 pp4096 2083.96 ± 10.21
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 tg4096 138.41 ± 0.12
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 pp8192 2056.76 ± 6.87
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 tg8192 135.32 ± 0.12
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 pp16384 2004.78 ± 5.40
qwen35moe 35B.A3B Q4_K - Medium 20.60 GiB 34.66 B CUDA 999 1 q8_0 q8_0 1 tg16384 129.76 ± 0.12

4. 结论、推论、实践

4.1 近似模型

有了第三章采样的大量数据，我们可以先彻底忘记MoE架构，TransFormer理论，直接暴力拟合一个近似模型来预测显存占用和推理速度。

4.1.1 显存占用近似模型

\[\boxed{ \text{Mem}(L, q, n) = B(n) + \alpha(q) \cdot L } \]

其中：

\[\alpha(q) = \begin{cases} 0.021, & q = \text{f16} \\ 0.0125, & q = \text{q8\_0} \\ 0.0075, & q = \text{q4\_0} \end{cases} \quad,\quad B(n) = \begin{cases} 21210, & n = 0 \\ 20900, & n = 1 \\ 20400, & n = 2 \\ 19600, & n = 4 \\ 17700, & n = 8 \\ 14000, & n = 16 \\ 6600, & n = 32 \\ 2900, & n = 64 \end{cases} \]

例 1：配置 \(q = \text{q4\_0}\)，\(n = 4\)，\(L = 262144\)

\[\begin{aligned} \text{Mem} &= B(4) + \alpha(\text{q4\_0}) \times 262144 \\ &= 19600 + 0.0075 \times 262144 \\ &= 19600 + 1966.08 \\ &= 21566.08 \text{ MiB} \end{aligned} \]

实测值：21702 MiB，误差 \(\approx 0.6\%\)

例 2：配置 \(q = \text{f16}\)，\(n = 8\)，\(L = 65536\)

\[\begin{aligned} \text{Mem} &= B(8) + \alpha(\text{f16}) \times 65536 \\ &= 17700 + 0.021 \times 65536 \\ &= 17700 + 1376.26 \\ &= 19076.26 \text{ MiB} \end{aligned} \]

实测值：19150 MiB，误差 \(\approx 0.4\%\)

4.1.2 推理速度近似模型

\[\text{Decode}(L, q, n) = \text{CapDecode}(q, n) - \gamma(q, n) \cdot L \]

其中：

符号 含义 单位
\(\text{Decode}\) Decode 阶段速度 tokens/s
\(\text{CapDecode}\) Decode 初始速度（\(L \to 0\) 时） tokens/s
\(\gamma\) Decode 速度衰减系数 (tokens/s)/token
\(L\) 上下文长度（实际处理的 token 数） tokens
\(q\) KV Cache 量化类型 -
\(n\) ncmoe 值 -
Decode 参数
\(q\) \(n\) \(\text{CapDecode}\) (t/s) \(\gamma\) (\(\times 10^{-4}\))
f16 0 ~154.5 ~1.1
f16 1 ~144.0 ~0.9
f16 2 ~133.0 ~0.8
f16 4 ~116.0 ~0.6
q8_0 0 ~152.0 ~1.5
q8_0 1 ~141.0 ~1.2
q4_0 0 ~150.0 ~1.8
q4_0 1 ~140.0 ~1.5

4.2 近似模型的自回归测试

目前llama.cpp的显存占用在部署完成之后就基本稳定不变了，但仍然可能存在1GB以内的波动（经验数据）。所以，在选择配置时，建议预留至少1GB的显存空间，以避免OOM错误。

然后就是规划的顺序，优先考虑显存，然后考虑速度。在质量方面可以以显存为主，毕竟没有使用q4_0以上的量化等级，根据社区经验来讲，质量损失不会太大，只需尽量使用较低强度的量化即可。

仍然是256k上下文，那么就有

\[B(n) + \alpha(q) \times 262144 \leq (24576-1024)= 23552 \]

可行解有：

n \(B(n)\) q \(\alpha(q)\) \(L\times \alpha(q)\) Mem(L=262144, q, n) Decode(L=262144, q, n)
0 21210 q4_0 0.0075 1966 23176 121.2
3 20000 q8_0 0.0125 3277 23277 缺少q8_0,n=3的采样
6 18000 f16 0.021 5494 23494 缺少f16,n=6的采样

这三组的实际部署测试结果是：

  • 0, q4_0, ncmoe=0, ctx=262144: 120.31t/s （2535 tokens generated）, 22726 MiB（空闲: 24576-22726=1850MiB）

这个实际速度结果和理论值121.2t/s非常接近，误差约为0.7%，实际显存占用和理论值23176 MiB也非常接近，误差约为1.9%。

  • 3, q8_0, ncmoe=3, ctx=262144: 110.46 t/s (2535 tokens generated), 23446 MiB
  • 6, f16, ncmoe=6, ctx=262144: 85.98 t/s (2714 tokens generated), 24120 MiB

后两组的ncmoe=3和ncmoe=6的在实验一中没有测试过，所有没有相关的速度模型常数，无法预测，但显存占用和理论值也非常接近，误差约为0.4%和0.3%。

工程博士的手段，就是这么朴实无华。

而单卡3090部署qwen3.6-35B-A3B+256K上下文的最优方案显然就是直接使用q4_0量化KVCache，不需要卸载到CPU。此时推理速度达到理论物理上界的77%，显存占用方面也有超过1GiB的余量，完全可以满足实际部署的需求。

4.3 近似模型的合理外推测试

速度近似模型一定与显卡强相关，但是显存近似模型大概率只与llama.cpp的版本相关。因此，我们完全可以用3090采样得来的显存模型去预测T4的显存占用情况。从而回答一个进阶问题：

4.3.1 1xTesla T4 + Qwen3.6-35B-A3B + 256K上下文

1张Tesla T4能把Qwen3.6-35B-A3B跑到什么水平？

Tesla T4: 15360MiB 显存，300GB/s，半精度性能65.12TFLOPS

理论上，因为显存限制，只能考虑q4_0和ncmoe>0

65.12TFLOPS的计算性能决定了“A3B”将不会是瓶颈，主要瓶颈是显存。

此时的理论物理上界是 300/6=50T/s。

假设显存的占用模型是设备无关的，只与llama.cpp的实现相关，那么可以使用上面的显存占用公式来推算在Tesla T4上可行的配置。

已知参数

q4_0 的 KV 增长率：α = 0.0075 MiB/token

考虑的上下文长度：

128K：L₁₂₈ = 131072 tokens

256K：L₂₅₆ = 262144 tokens

KV 缓存占用：

KV₁₂₈ = α * L₁₂₈ = 0.0075 * 131072 = 983.04 MiB

KV₂₅₆ = α * L₂₅₆ = 0.0075 * 262144 = 1966.08 MiB

假定可用显存上限：Mem_avail = 14000 MiB

因此，模型权重及固定开销 B(n) 必须满足：

对于 128K：B(n) ≤ 14000 - 983.04 = 13016.96 MiB

对于 256K：B(n) ≤ 14000 - 1966.08 = 12033.92 MiB

B(n) 的线性插值

已知表中数据（部分）：

n B(n)
16 14000
32 6600

在区间 [16, 32] 内，我们合理假设B(n) 随 n 线性下降，斜率为：

(6600 - 14000) / (32 - 16) = -7400 / 16 = -462.5 MiB/单位n

因此，在该区间内：
B(n) = 14000 - 462.5 * (n - 16)

从而，我们可以计算满足部署需求的最小 n

128K 上下文

需要 B(n) ≤ 13016.96：

14000 - 462.5 * (n - 16) ≤ 13016.96

462.5 * (n - 16) ≥ 983.04

n - 16 ≥ 983.04 / 462.5 ≈ 2.126

n ≥ 18.126

由于 n 必须是整数，最小 n = 19。

此时：

  • B(19) = 14000 - 462.5 * (19 - 16) = 14000 - 1387.5 = 12612.5 MiB
  • 总显存 = 12612.5 + 983.04 = 13595.54 MiB，小于 14000 MiB。

256K 上下文

需要 B(n) ≤ 12033.92：

14000 - 462.5 * (n - 16) ≤ 12033.92

462.5 * (n - 16) ≥ 1966.08

n - 16 ≥ 1966.08 / 462.5 ≈ 4.251

n ≥ 20.251

最小整数 n = 21。

此时：

  • B(21) = 14000 - 462.5 * (21 - 16) = 14000 - 2312.5 = 11687.5 MiB
  • 总显存 = 11687.5 + 1966.08 = 13653.58 MiB，同样小于 14000 MiB。

可行方案汇总

上下文长度 最小 ncmoe 预计显存占用 (MiB) 备注
128K 19 ~13596 非常接近 14GB 上限，余量约 404 MiB
256K 21 ~13654 余量约 346 MiB，更紧张

实际测试结果：

  • 128k, q4_0, ncmoe=19 --> 13492 MiB (误差约为0.7%), 42.8t/s with 2700 tokens generated
  • 256k, q4_0, ncmoe=21 --> 13670 MiB (误差约为0.4%), 41.6t/s with 2084 tokens generated

256K上下文的41.6t/s达到了理论物理上界的83.2%，而且显存占用也有约1.6GiB的余量，完全可以满足实际部署的需求。

下面是不同ncmoe和上下文长度的实测显存占用和推理速度：

ncmoe ctx 实测显存(Mib) 实测推理速度(T/s)
40 256k 4730 34
40 128k 3626 34
40 64k 3148 34
30 256k 9472 38
30 128k 7856 38
30 64k 8368 38
20 256k 14114 43

显然，3090的显存近似模型可以外推到Tesla T4上，但是，工程暴力破解的局限性也体现出来了，那就是实际上还存在ncmoe=20的更优解，推理速度达到43t/s，显存占用约为13.8GiB，余量约为1.2GiB，也完全可以满足实际部署的需求。

5. 开始想象1张3090部署DeepSeek-V4-Flash + 1M上下文

这次不再先采样然后近似了，一方面是DeepSeek-V4-Flash的参数规模远大于Qwen3.6-35B-A3B，另一方面是llama.cpp对它的支持度还不够完善，最重要的还是，现在我有点信心可以直接进行理论推算了。

DeepSeek-V4-Flash是一个284BA13B的模型，其注意力层使用了CSA + HCA混合注意力，kvcache的效率为最高节省98%。其专家层也包含1个共享专家+256个路由专家，但每次只激活6个专家。

V4 整体架构图包含从 Input Tokens → Embedding → Residual Mixing（mHC）→ CSA/HCA → Residual Mixing → DeepSeekMoE → Prediction Head → MTP Modules 的完整数据流，层间由 Pre-Block Mixing 和 Post-Block Mixing 做 mHC 的通道混合

其中CSA/HCA->DeepSeekMoE 一共重复了43次（Transformer Block * L, L=43）。

那么我们可以同理推算X, Y, Z。

设43层注意力层总权重为X, 43层路由专家的总权重为256Y, 43层共享专家的总权重为Z, 其他层之和暂且视为常数忽略掉（Embedding, Prediction Head和MTP）。

那么有

\[X + 256Y + Z = 284 \]

\[X + 6Y + Z = 13 \]

我们可以先分别估算出Y和X+Z的值，Y=1.084, X+Z=6.496。

因为注意力层和共享专家总是一定在GPU完成计算，所以也不需要具体求解X和Z,后续统一称为XZ

那么推理时一个1token对应需要的固定参数量为X+Z=6.496B, 路由专家总参数量6B=6.504B

然后我们下载usloth量化的Q4_K_XL量化版本，在4bit量化下，按照1B约等于0.5GB的映射关系，那么在存储上：

  • 固定开销需要的存储大小为6.496*0.5=3.248GiB
  • 路由专家总需要的存储大小为6.504*0.5=3.252GiB

但是我们的3090不支持int4计算，那么在实际计算时需要先将q4还原成fp16, 那么实际计算过程中1个token需要的显存带宽为：

  • 13B*2GiB/B = 26 GiB
  • （如果只还原成int8）则是13B*1GB/B=13GiB

3090的显存带宽为936GB,但是社区经验告诉我们实际上最多只有300GB能够被有效利用，根据内存墙规律，我们理论上的最大推理速度为：

  • fp16: 936/26 = 36 T/s

然而这个理论值完全不可能被实现和验证，因为3090只有24GB显存，我们不可能将DeepSeek-V4-Flash完整放在显存里面。因此必须使用专家卸载技术。

说干就干，开始测算。

在静态显存占用方面：

  • 注意力层+共享专家需要的总显存：(X+Z)*0.5=3.248 GB
  • 256个专家需要的总显存：Y2560.5=138.752 GB

在动态显存（KV Cache）方面：

我们直接采用最极端的q4_0量化。V4一共有43层重复的注意力层，KV头数为1, 头维度为512, 查询头数为64, 根据deepseek-v4-flash的开源权重config.json,每一层的压缩率分别为：

[
0, 0,
4, 128, 4, 128, 4, 128, 4, 128, 4, 128,
4, 128, 4, 128, 4, 128, 4, 128, 4, 128,
4, 128, 4, 128, 4, 128, 4, 128, 4, 128,
4, 128, 4, 128, 4, 128, 4, 128, 4, 128,
4, 0, 0, 0
]

应该有两层没有压缩，即有21层压缩率是4, 20层压缩率是128, 2层压缩率是1

那么每1KB的kvcache显存占用为：

KV Cache大小 (字节) = 层数 (L) × 2 (K和V) × 隐藏维度 (head_dim) × 键值头数 (num_key_value_heads) × 精度字节数 (FP16为2) × Token数

  • 2 * 512 * 1 * (21 / 4 + 20 /128 + 2) * 0.5 * 1024 = 7584 * 0.5 * 1024 = 3,883,008 Byte = 3.703125 MiB
  • 那么要达到DeepSeek-V4-Flash的原生1M上下文所需要的显存为 3.703125 * 1024 = 3792 MiB = 3.703125 GiB

假设我们将n层的专家权重放在CPU上，那么就必须满足

\[3.248 + 138.752*(43-n)/43 + L * 3.703125 / 1024 \le R \]

其中L是上下文长度（K），R是显存（GiB）

即

\[n \ge 43 - \frac{(R - 3.248 - L*3.703125/1024) * 43}{138.752} \]

接下来是怎么计算推理时需要计算的数据量：

接下来是怎么计算推理时需要计算的数据量：

纯GPU计算时:

  • 单token总数据量 =（注意力层+共享专家总参数量）* GPU计算精度 + 路由专家总参数量 * GPU计算精度
  • 推理速度 = 显存带宽 / 单token总数据量

采用专家卸载时：

  • 单token的GPU数据量： 注意力层+共享专家总参数量）* GPU计算精度 + 路由专家总参数量 * GPU计算精度 * (1-n/43)
  • 单token的CPU数据量： 路由专家总参数量 * CPU计算精度 * n/43
  • GPU推理速度 = 显存带宽 / 单token的GPU数据量
  • CPU推理速度 = CPU内存带宽 / 单token的CPU数据量
  • 最终推理速度 = min(GPU推理速度, CPU推理速度)

计算精度/量化压缩级别： fp16(f16)=2, int8(q8_0)=1, int4(q4_0)=0.5
3090支持int8计算，CPU先假设支持int4计算（这一假设来自于我对于CPU高性能计算的无知，以至于后面先进入了幻想时间）

计算速度取决于激活量，对于GPU和服务器级别的CPU来说，MoE架构的激活量都太小了，不存在计算瓶颈，影响推理速度的是内存带宽搬运数据的速度，即内存墙。

我通过lmbench的bw_mem测得当锁定一个NUMA, 24线程的时候，CPU read 内存的实际速度是102GB/s, 48 线程则为210GB/s,
所以用这个102-210之间的值来代替内存理论带宽将会更真实，先按102的保守值来计算。

3090的显存带宽是960GB/s,但是社区经验告诉我们llama.cpp可能只有20%-30%的利用率，也就是应该用192-288GB来计算（187.5GiB-281.25GiB）

ncmoe还涉及到CPU与GPU之间的通信，而PCIE通信的带宽可以约等于32GB, 仅仅用来传递中间激活值（A13B）的话，就算是fp16精度也完全能cover住，可以认为只有延迟，没有速度损失。

上下文长度(K) min-n GPU计算精度 静态显存(GiB) kvcache(GiB) GPU数据量(GiB) CPU数据量(GiB) GPU T/s CPU T/s 最终 T/s
1024 38 fp16 19.382 3.703 13.370 2.874 22.44 35.49 22.44
1024 38 int8 19.382 3.703 6.874 2.874 43.64 35.49 35.49
1024 38 int4 19.382 3.703 3.626 2.874 82.73 35.49 35.49
512 38 fp16 19.382 1.852 13.370 2.874 22.44 35.49 22.44
512 38 int8 19.382 1.852 6.874 2.874 43.64 35.49 35.49
512 38 int4 19.382 1.852 3.626 2.874 82.73 35.49 35.49
256 37 fp16 22.609 0.926 13.446 2.798 22.31 36.45 22.31
256 37 int8 22.609 0.926 6.950 2.798 43.17 36.45 36.45
256 37 int4 22.609 0.926 3.702 2.798 81.04 36.45 36.45

这个估计结果就很符合预期，因为对于MOE模型来说，在启用了专家卸载时，显存和内存构成了双重内存墙，适当的卸载能减轻对CPU内存带宽的需求，但转移给GPU的负载对于显存来说仍然是九牛一毛，从而实现最大化的推理速度。

同理可以考虑双3090的情况，因为没有nvlink，所以必须放弃tensor split, 只能选择layer split, 那么PCIE仍然不会成为瓶颈，此时可以认为显存翻倍，延迟增加，推理速度的推算方式不变，此时：

上下文长度(K) min-n GPU计算精度 静态显存(GiB) kvcache(GiB) GPU数据量(GiB) CPU数据量(GiB) GPU T/s CPU T/s 最终 T/s
1024 31 fp16 41.969 3.703 13.900 2.344 21.58 43.51 21.58
1024 31 int8 41.969 3.703 7.404 2.344 40.52 43.51 40.52
1024 31 int4 41.969 3.703 4.156 2.344 72.19 43.51 43.51
512 30 fp16 45.196 1.852 13.975 2.269 21.47 44.96 21.47
512 30 int8 45.196 1.852 7.479 2.269 40.11 44.96 40.11
512 30 int4 45.196 1.852 4.231 2.269 70.90 44.96 44.96
256 30 fp16 45.196 0.926 13.975 2.269 21.47 44.96 21.47
256 30 int8 45.196 0.926 7.479 2.269 40.11 44.96 40.11
256 30 int4 45.196 0.926 4.231 2.269 70.90 44.96 44.96

单卡实际跑通的配置和结果：

上下文长度(K) ncome GPU显存（MiB） 推理速度（T/s）
1024 40 20918 3.6
512 39 22958 7.5
256 44 9290 7.55
256 43 9290 7.90
256 42 12554 7.97
256 41 15816 7.65
256 40 19086 8.3
256 39 22346 8.4
128 39 22044 8.4

可以得出：

  • 纯注意力层+共享专家+llama.cpp固有开销的显存占用是 9290 MiB
  • ncmoe从43->42, 显存占用增加3264MiB; 从42->41,显存占用增加3262MiB;基本稳定，直接计算从43->39, 显存占用增加13056MiB，平均每层3264MiB=3.1875GiB，与估算值3.252GiB相差2%。
  • 在ncmoe=39的情况下，上下文从128K增加到512K, 显存占用增加了914MiB, 平均每K需要2.38MiB，低于估算的3.703125 MiB，DeekSeek-V4的混合注意力机制比想象中的更厉害
  • 减少ncmoe会减少cpu负担，增加gpu负担，但是推理速度却增加了，说明GPU带宽游刃有余，CPU是主要瓶颈

实际推理速度与估算值差距非常大，说明对CPU瓶颈的分析肯定存在问题，潜在的原因：

  • CPU内存的随机访问带宽远低于顺序读取，每个Token只激活6个专家，但256个专家分布在CPU内存的不同物理地址。
  • CPU没有高效的int4计算能力，或者没有使用，导致实际数据搬运量是int4的2-4倍

这两个原因组合起来倒是能解释实测的7-8T/s

验证这个猜想的方法很简单，再测试一下双卡，将更多的负载转移到GPU就知道了

双卡实际跑通的配置和结果：

上下文长度(K) ncome sm ts GPU0显存（MiB） GPU1显存（MiB） 推理速度（T/s）
1024 33 layer 5,1 22484 23200 9.48
512 33 layer 5,1 21360 22338 9.63
256 33 layer 5,1 20820 22010 9.65

llama.cpp目前不支持DeepSeek-V4-Flash的tensor split，只能选择layer split

进一步提高了，但是不能超过10T/s。

理论上，ncmoe=33时，GPU负载的路由专家数据量=103.18756/256=0.747GiB，相比于注意力层的数据量不值一提，和单卡时的ncmoe=39没什么区别。因此瓶颈一定在CPU。

为了进一步验证，再试一下3*3090

上下文长度(K) ncome ts GPU0显存（MiB） GPU1显存（MiB） GPU1显存（MiB） 推理速度（T/s）
1024 27 21,4,5 21284 22662 23200 10.72
512 27 21,4,5 20298 21800 22344 10.63
512 26 21,4,5 23564 21800 22338 11.48

显然，我们每为CPU减少一点负担，CPU的瓶颈就会增大一点。

不妨将CPU的计算精度假设为fp16,那么每层的数据量就是3.1875*4=12.75GiB

  • 1024K+卸载40层时，CPU有效带宽是 12.75406/256*3.6 = 43.03125 GiB
  • 512K+卸载39层时，CPU有效带宽是 12.75396/256*7.5 = 87.4072265625 GiB
  • 256K+卸载39层时，CPU有效带宽是 12.75396/256*8.4 = 97.89609375 GiB
  • 1024K+卸载33层时，CPU有效带宽是 12.75336/256*9.48 = 93.485390625 GiB
  • 512K+卸载33层时，CPU有效带宽是 12.75336/256*9.63 = 94.9645898438 GiB
  • 1024K+卸载27层时，CPU有效带宽是 12.75276/256*10.72 = 86.4928125 GiB
  • 512K+卸载26层时，CPU有效带宽是 12.75266/256*11.48 = 89.19421875 GiB

随着卸载层数减少，内存随机地址的影响应该会越来越小，访问速度越来越快，这没问题。基本可以确定，实际上的CPU计算就是先反量化到fp16再交给CPU算的。

如果那么我们的理论预测表格就可以更新为

单卡：

上下文长度(K) min-n GPU计算精度 静态显存(GiB) kvcache(GiB) GPU数据量(GiB) CPU数据量(GiB) GPU T/s CPU T/s 最终 T/s
1024 40 fp16 18.634 2.380 37.184 11.953 25.82 8.53 8.53
1024 40 int8 18.634 2.380 18.592 11.953 51.63 8.53 8.53
1024 40 int4 18.634 2.380 9.296 11.953 103.27 8.53 8.53
512 39 fp16 21.822 1.190 37.483 11.654 25.61 8.75 8.75
512 39 int8 21.822 1.190 18.742 11.654 51.22 8.75 8.75
512 39 int4 21.822 1.190 9.371 11.654 102.45 8.75 8.75
256 39 fp16 21.822 0.595 37.483 11.654 25.61 8.75 8.75
256 39 int8 21.822 0.595 18.742 11.654 51.22 8.75 8.75
256 39 int4 21.822 0.595 9.371 11.654 102.45 8.75 8.75

双卡：

上下文长度(K) min-n GPU计算精度 静态显存(GiB) kvcache(GiB) GPU数据量(GiB) CPU数据量(GiB) GPU T/s CPU T/s 最终 T/s
1024 33 fp16 40.947 2.380 39.276 9.861 24.44 10.34 10.34
1024 33 int8 40.947 2.380 19.638 9.861 48.88 10.34 10.34
1024 33 int4 40.947 2.380 9.819 9.861 97.77 10.34 10.34
512 32 fp16 44.135 1.190 39.575 9.562 24.26 10.67 10.67
512 32 int8 44.135 1.190 19.788 9.562 48.52 10.67 10.67
512 32 int4 44.135 1.190 9.894 9.562 97.03 10.67 10.67
256 32 fp16 44.135 0.595 39.575 9.562 24.26 10.67 10.67
256 32 int8 44.135 0.595 19.788 9.562 48.52 10.67 10.67
256 32 int4 44.135 0.595 9.894 9.562 97.03 10.67 10.67

这下就基本全对上了。

新的问题在于实际有效带宽在39层达到97GiB之后，再减少卸载层数，有效带宽反而降低了。肯定又有别的因素开始占据主导地位了，但是又对整体影响不是很大。

至于别的因素到底是什么？I don't know, it's time to learn more.

6. 思考环节：MOE架构还能怎么优化？

6.2.1 横向卸载与专家缓存池

llama.cpp的-ncmoe是纵向卸载的，将前n层的专家卸载到CPU上，后续的专家仍然在GPU上计算，整体形成了一个计算流水线，影响首字延迟，但是完全不影响吞吐。

有没有可能，将每一层的x个专家卸载到CPU上，其余的就呆在GPU上。在一次推理时，如果共享专家选择了在GPU上的路由专家，那么就直接在GPU上计算，如果选择了在CPU上的路由专家，那么就将这个专家的权重从CPU搬运到GPU上计算，然后通过缓存池常见的方式踢掉另一个专家的权重去CPU上。这样我们的推理速度瓶颈就更有可能来自于显存带宽，前提是我们的缓存策略设计的足够好，路由专家的轮换频率足够低，否则，频繁的搬运专家权重会导致CPU内存带宽再次成为瓶颈。

6.2.2 注意力压缩

DeepSeek-V4-Flash的混合注意力机制已经证明了注意力压缩的可行性，甚至可以说是非常成功的，建议其他厂商都学习一下。

不过，是否可以从推理引擎的角度，实现一种为任意模型提供注意力压缩的通用方法呢？

posted @ 2026-08-04 16:18  凉快李某  阅读(93)  评论(0)    收藏  举报