RTX 5070 Ti 本地部署 Qwen3 35B-A3B (MoE) vs 27B (Dense) 对比报告

? 离线

前几个帖子，很多朋友提出不少建议，包括perfill性能差，输出慢，上下文短等问题。受限于16g内存，要满足这些条件在dense模型下，实在是无米之炊。现奉上moe解决方案，请各位大佬提宝贵意见。

摘要：本文记录了在 RTX 5070 Ti 与 AMD 9800X3D 平台上，将主力本地模型从 Qwen3.6-27B (Dense) 升级至 35B-A3B (MoE) 的完整调优过程、性能实测数据以及踩坑实录。实测表明，35B MoE 在速度、显存和上下文上实现了对 27B 的全面碾压。

一、硬件与测试环境
核心硬件：
CPU：AMD Ryzen 7 9800X3D (8核16线程，96MB 超大 L3 缓存)
GPU：NVIDIA RTX 5070 Ti (16GB GDDR7 显存)
内存：32GB DDR5-6000
软件与模型：
系统：Ubuntu 24.04 LTS / CUDA 12.8 / 驱动 595.71.05
推理引擎：llama.cpp (CUDA 编译版)
对比模型 A：Qwen3.6-27B-Q4_K_M (密集架构，16 GiB)
对比模型 B：Qwen3.6-35B-A3B-UD-Q4_K_M (MoE架构，3B 激活/步，20.6 GiB)

二、核心参数与“反直觉”的显存表现
在将总参数量更大的 35B MoE 塞进 16GB 显存时，我们遇到了一个极其反直觉的现象：35B 的显存占用竟然比 27B 更低！
27B Dense 配置（优化后）：
GPU 层数：-ngl 50（全部 50 层卸载至 GPU）
上下文：98K
Flash Attention：开启
显存占用：15,048 MiB（空闲 1,255 MiB）
35B-A3B MoE 配置（稳定版）：
GPU 层数：-ngl 26（26 层在 GPU，14 层 offload 到 CPU）
上下文：128K
Flash Attention：关闭（踩坑后妥协）
显存占用：14,826 MiB（空闲 1,477 MiB）
显存表现解析：
虽然 35B MoE 的模型文件更大（20.6 GiB），但由于仅 26 层 offload 到 GPU，且 MoE 架构在注意力层的设计差异，其实际显存占用反而比 27B 全层密集模型低了 222 MiB。这多出来的显存余量，让我们成功将上下文从 98K 提升到了 128K！

三、推理速度实测：MoE 架构的降维打击
得益于 MoE 架构“每次仅激活 3B 参数”的物理特性，35B-A3B 在推理速度上对 27B 形成了降维打击。

短 Prompt 场景（22 tokens）
首字耗时 (TTFT)：27B 为 0.52s，35B 为 0.24s（提速 2.2 倍）
Prefill 速度：27B 为 42.7 t/s，35B 为 77.3 t/s（提速 1.8 倍）
Decode 生成速度：27B 为 12.7 t/s，35B 为 48.0 t/s（狂飙 3.8 倍）
长 Prompt 场景（266 tokens）
Prefill 速度：27B 为 507 t/s，35B 为 713 t/s（提速 1.4 倍）
Decode 生成速度：27B 为 13.3 t/s，35B 为 51.7 t/s（狂飙 3.9 倍）
单 Token 生成延迟：从 75.1 ms 骤降至 19.3 ms（降低 74%）
速度解析：
在生成阶段（Decode），GPU 必须读取模型权重。27B 需要读取 27B 的完整权重，而 35B MoE 仅需读取 3B 的激活权重。在 RTX 5070 Ti 固定的显存带宽下，读取数据量减少为原来的 1/9，理论速度上限大幅提升。实测 3.8 倍的速度提升，完美印证了 MoE 架构在消费级显卡上的物理优势。

四、避坑指南：Flash Attention 的兼容性地雷
在测试 35B MoE 时，我们遇到了一个严重的兼容性问题，这也是本文最有价值的“排雷”经验：
崩溃现象：
当尝试使用 -ngl 28 并开启 Flash Attention (-fa on) 时，llama.cpp 在启动阶段直接崩溃（CUDA flash attention kernel 初始化失败）。
原因分析：
llama.cpp 的 Flash Attention 实现主要针对标准的 Dense Transformer 进行了高度优化。Qwen 的 MoE 架构在注意力层可能包含特殊的路由机制或混合注意力设计，当 GPU 加载层数较高时，MoE 路由计算与 FA 的 CUDA Kernel 在显存分配或线程调度上发生了冲突。
最终解决方案：
果断放弃 Flash Attention，并将 GPU 卸载层数微调至 -ngl 26。
稳定配置：-ngl 26 -c 131072 --cache-type-k q4_0 --cache-type-v q4_0（无 -fa 参数）。
注：虽然关闭 FA 会稍微增加 KV Cache 显存占用，但 35B MoE 本身显存余量充足（1.48 GiB），完全扛得住。

五、综合结论与部署建议
经过 6 个维度的严苛对比，35B-A3B 在显存、上下文、Prefill 速度、Decode 速度、TTFT 上全面压倒 27B。
最终结论：
在 16GB 显存的 RTX 5070 Ti 上，35B-A3B MoE 应当全面取代 27B Dense，成为本地子 Agent 的绝对主力。在四项核心指标全部更优的情况下，没有理由继续留恋 27B。
MoE 的缺点是“局部专家各自为战”。在面对需要极度严密、跨越几十个步骤的深层逻辑推导（例如：极其复杂的数学证明、或者需要全局视角的超大型架构重构）时，27B Dense 模型因为“所有参数都在同时参与每一次计算”，其逻辑连贯性有时会略好于同级别的 MoE。

给 16GB 显存玩家的部署建议：
拥抱 MoE 架构：在显存受限的消费级显卡上，MoE 是兼顾“大模型智商（35B 总参数）”与“极速推理（3B 激活参数）”的唯一解。
善用 9800X3D 的 L3 缓存：将 14 层 offload 到 CPU 并非性能瓶颈。9800X3D 的 96MB L3 缓存足以吞下 3B 的激活参数，CPU 部分的推理几乎零延迟。
警惕 FA 兼容性：在跑 MoE 模型时，如果遇到 CUDA Kernel 崩溃，请第一时间尝试关闭 Flash Attention 并微调 -ngl 参数。

启动命令参考：
#!/bin/bash
MODEL_PATH="$HOME/Downloads/Qwen3.5-35B-A3B-UD-Q4_K_M.gguf" # 请确认实际文件名
SERVER_BIN="$HOME/llama.cpp/build/bin/llama-server"

"$SERVER_BIN"
-m "$MODEL_PATH"
-ngl 26
-c 131072
--cache-type-k q4_0
--cache-type-v q4_0
-t 8
-b 1024
--port 58080
--host 127.0.0.1

? 离线

补充说明：我是deepseek V4 flash 云端和本地的双模型委托模式，DeepSeek v4 (脑) + 9800X3D/5070 Ti (躯体) + 35B MoE (神经) 的组合，对本地速度要求更高，MOE的智商符合我的要求。对仅本地，经常长推理的同学来说，MOE可能比全GPU加载的Dense模型要差点意思。

566656661

論家用級的電腦其實大多數只適合MoE, 32GB顯存以上的近代電腦不多不少都是已經清楚了自己的需求後再額外配置的

然後既然樓主談到了有關混合Attention的話題, 并且提供了從用家出發的數據分析, 那允許我在這裏基於Model Card跟模型的機制分析一下吧 (其實也算是現代模型的一些基礎知識)

Qwen 3.6 無論是Dense還是MoE都是運用了Gated DeltaNet + Gated Attention
知乎上面有一篇寫得很好的文章, 我就不獻醜了, 簡單理解就是可以在長上下文時平衡VRAM支出跟注意力的精度

	Dense (27B)	MoE (35BA3B)	簡單理解
層數 (Layer)	64	40	可以理解成模型的思考深度, 有點類似Thinking Effort
隐藏维度 (Hidden Dimension)	5120	2048	可以理解成模型的思考寬度/發散性, 越大可以理解成在頭腦風暴上越能天馬行空
Hidden Layout (這個真的想不到有什麽中文字...)	16 Blocks of 4 layers	10 Blocks of 4 layers	思考結構, 可以理解成邏輯性, 從輸入到輸出的推論過程
Active Params	27B	3B	這個就是常見的模型名上寫的, 可以理解成人的工作時的整體腦力
架構分別	FFN, 寬度17408	MoE, 256專家, 每次用9 (8 + 1)個, 每個專家寬度512	可以簡單理解成知識流量限制, 越大代表越多Token能同時處理
Gated Attention Head (這個也是..)	24 for Q and 4 for KV	16 for Q and 2 for KV	這個會影響在長上下文中從一個Token提取其他相關Token的精度

然後個人推理Up所說的路由機制或者混合注意導致崩潰就是這裏:

llama.cpp (2026-06-13) 推測是一開始就是爲了配合不同的硬件 (Mac, AMD, Cuda, 現在再加上一個Intel), 所以是使用causal self-attention, 然後llamacpp的causal self-attention其實就是基於flash attention (本體使用softmax構造, 可以理解成softmax attention) 修改出來, 沒特別針對gated delta net (linear attention)進行優化, 所以在這裏翻車的機會很大

而正如@kop-wang kop大在這裏提到, 儘管能跑, 但是距離llamacpp實際優化估計還有很長一段路要走, 畢竟gated delta net跟gated attention的實際應用就是Qwen 3 Next, 然後gated delta net更是2024年的產物

這樣應該就能理解爲什麽在長上下文或者需要深度思考時會選Dense而不是MoE的原因

? 离线

@566656661 谢谢，受教了。1 .看MoE和llama的后续更新和发展吧。 2. 大显存肯定是解决问题的核心，但魔改的质量和5090的高价实在让人下不了手。 3. 现阶段Dense在思考层面还是强于MoE的。

? 离线

花了一个下午，和Hermes一起进行测试和查找原因，毕竟大佬出场，不能马虎，要认真对待，情况如下，供参考，不妥之处，请指正。粗体字

结论出乎意料——这和 FA 没关系。

我原帖说"FA 和 DeltaNet 不兼容"是错的

查了 llama.cpp 源码确认：DeltaNet 有独立 GLA kernel（ggml_cuda_op_gated_linear_attn），FA 根本不会碰 DeltaNet，它只处理 10 层 Gated Attention。

实测 6 组对照，结果一目了然

配置结果 VRAM 余量
───────────────────────────────────────
ngl=25 +fa on OK 14,249 2,054 MiB
ngl=26 +fa on OK 14,819 1,484 MiB
ngl=26 +fa off OK 14,826 1,477 MiB ← 原稳定
ngl=27 +fa on OK 15,331 972 MiB ← 新发现
───────────────────────────────────────
ngl=28 +fa on 134 OOM
ngl=28 +fa off 134 OOM ← 一样崩！

关键证据：ngl=28 关掉 FA 照样崩，报错完全一致：
CUDA error: out of memory
launch_fattn at fattn-common.cuh:1109
cudaOccupancyMaxActiveBlocksPerMultiprocessor(...)

llama.cpp 的 warmup decode 必经 launch_fattn（标准注意力），-fa 只控制是否走 WMMA 优化，不影响基础 FA kernel 的调用。

真相

纯 VRAM 不够。35B-A3B 的 GGUF 文件 20.6 GiB，ngl=27→28 多拖 1 层进 GPU（~500 MiB 权重），warmup 时显存被榨干，CUDA occupancy 查询分配不到内存直接 OOM。

有趣的是 ngl=27 +fa on 反而能跑（余 972 MiB），说明 FA 本身在 16GB 卡上完全可用，问题只是 ngl 到了临界点。

27B Dense 没有这个问题

27B 的 GGUF 才 ~16 GiB，同样 ngl=50 全层加载也只占 15,048 MiB。35B 虽然激活参数只有 3B/步，但总模型文件大得多，每层权重更多，"全层"的 ngl 天花板天然更低。

总结：5070 Ti 16GB 上 35B-A3B 的 ngl 上限就是 27，和 FA 开不开没关系。你之前怀疑 attention head 配置的想法是对的，只是实际卡住的是显存预算而不是 kernel 兼容性。

不知道你那边 32GB 的卡上 ngl 上限能到多少？很好奇这个模型的显存曲线。

补充：

VRAM 占用
• 旧配置 (ngl=26, 无FA): 14,826 MiB
• 新配置 (ngl=27, FA on): 15,331 MiB
• 变化: +505 MiB

显存余量
• 旧配置 (ngl=26, 无FA): ~1,477 MiB
• 新配置 (ngl=27, FA on): ~972 MiB
• 变化: 少了 505 MiB

Decode 速度
• 旧配置 (ngl=26, 无FA): ~48 t/s
• 新配置 (ngl=27, FA on): ~54 t/s
• 变化: +13%

williamlouis

现在是没有显存。战未来吧。5系等等应该也能魔改。

? 离线

@williamlouis 赞同，从80286开始玩，一路到现在，深刻体会到现在的高端，不管是硬件还是软件，就是明天的垃圾。另外，主要是享受折腾的乐趣，全搞好了，动力没了。毕竟我不需要像坛主一样，每天上管传教带骂人（坛主看到不许骂我），我过了用Ai做生产力的年纪了。

williamlouis

我看新闻说今年就有望流出 5系的显存。战未来也用不了太久。

566656661

@kevon

辛苦了, 我這裡也學到新東西, 因為我還沒空去研究llama.cpp所以沒有特別研究底層代碼

之後有空再折騰一下llama.cpp, 不過kop大自己也有研究就是了

566656661

然後至於ngl的話

27B FP16大約62gb左右, FP8大約30到31, INT4或者NVFP4會大約再減半到15到16

理論上我的4500 Pro可以全部都塞進VRAM裡面, 外加10GB作為KV Cache.

限制24GB的話也許可以用iq4 ks + fp8 kv, 塞個130到140K上下文左右吧……？

不過16GB就真的太緊了, 只能用MoE

? 离线

@566656661 螺蛳壳里做道场，享受的只是乐趣，大公司在线版肯定蹍压我们。但，这是我们自己的，就像自己家一样。意义大抵在此吧，个人所见，难免偏颇。

抡锤者

RTX 5070 Ti 本地部署 Qwen3 35B-A3B (MoE) vs 27B (Dense) 对比报告