llama.cpp 新参数让16G显卡跑35B拉满262K上下文|cpp|cpu|gb|上下文|内存|固态硬盘|新参数|显卡

对于本地跑Qwen3.6-35B-A3B这个模型来说，之前的甜点是24G以上显卡，既能用到Q4无损档，又能拉长上下文，又能kv都开Q8保上下文精度，还能挂视觉塔读图，对于16G显卡来说，是做不到全都要的，必须有所取舍，要么降低量化权重（最先损伤agent能力），要么缩短上下文长度（更容易撞墙压缩），要么参数剪枝（损伤智力），要么卸载专家进内存（随层数线性降低速度），要么降低kv缓存量化到Q4档（损伤上下文记忆能力）或者多项一起砍才能取到合适平衡。

但近期lllama.cpp推理引擎更新了一个新参数，用上这个参数，极大程度上解决了大部分问题，我本地跑的Qwen3.6-35B-A3B对比之前不仅略微提速了，并且上下文长度还可以直接拉满262k了，下面说说下具体是个什么思路，怎么实现的。

思路的灵感来自于最近爆火的Strata说起，它的卖点很抓人：一张 12G 显存的卡，配上 64G 内存，就能跑 125B 参数的 Qwen3.8-Flash-Next。

原理不复杂——这是个稀疏构建（MoE）模型，总参 125B，但每次激活的只有 6B，大部分权重平时在内存里睡大觉，用的时候才搬进显存。说白了它不是把 125B 塞进显存，是「显存放脑子、内存放仓库，用的时候才搬」。

这倒是把「内存焦虑」又炒起来了，我看有些朋友打算加内存跃跃欲试了。毕竟换显卡有点费劲，但加内存可能就是顺手的事情，尤其是老平台捡垃圾的方案，似乎是个不错的选择，但我越看越觉得，焦虑的对象搞错了。

一、Strata 好用，但我没跟风

我研究了一阵子，决定了不跟，主要是有三个拦路虎：

第一， 内存不够 。我机器只有 32G，Strata 这类玩法起码 64G 起步，勉强跑也是瘸腿。并且我的内存是D5，加内存是天价，老电脑是D4，但只有两根槽，不适合。

第二， 量化太狠，伤的是 agent 命门 。网上的测评，量化几乎都压在 q2 档，最高也就 iq3_xxs。对一个激活参数只有 6B 的模型来说，这点量化损失会集中爆在 工具调用和长链推理 上——而这恰好是 agent 最吃重的能力。本地跑 agent，图的就是这两样稳，为了塞进内存把命门削了，不值。

第三， 本末倒置 。真要把内存堆到 100G 去逼近 4bit，那还不如直接调云端 API，省钱省事还更稳。

实际上Qwen3.8 Flash 我天天在用它的云端API，好用、性价比不错， 但偶尔会出计算错误 。但本地化对我仍有意义，只是不是靠 Strata 这条路。

二、「专家缓存分层」这个思路，我认定值得抄

Strata 真正值钱的不是「堆料」，是那个念头： 不用把全部权重都怼进显存，谁热谁上来，冷的就待在内存里。

这个思路本地推理早就能玩——我 10 月那篇就写过，用 --n-cpu-moe 把专家卸到内存、用 CPU 跑。既然 llama.cpp 自己也刚加了同类机制，那我手上这张 16G 卡里的 Qwen3.6-35B-A3B，是不是还能再榨一层？

我的显卡是AMD 9070XT，目前我的主力本地模型Qwen3.6-35B-A3B，如果你用过阿里云 API 里调用的云端 Qwen3.6 Flash，实际上它底层就是 Qwen3.6-35B-A3B 。我本地跑的是它的 4bpw 量化：unsloth UD-IQ4_XS，18.2G （加上视觉塔mmproj文件共 19.1 GB）。

之前的文章里也写过它的加载设置和推理设置，用的是这套

Qwen3.6-35B-A3B模型加载参数设置教程

Qwen 本地模型推理参数设置教程：加载完再改，即时生效不用重载

三、旧跑法的痛：逐层调参地狱

我之前的部署，是在 16G 卡（RX 9070 XT）上 --n-cpu-moe 17 ，把 16 层专家卸到内存用 CPU 跑。速度还行：同一份 9 万 token 的长文档，prefill 约 1093 t/s，生成约 77 t/s。

但最大的痛不是慢，是调参。

这 17 层是我 一层一层试出来的 ：16 层能用，15 层必定爆显存、速度暴跌；18 层往上 每层逐渐掉速 。实际卸到二十多层时，生成已经掉到四五十 t/s、prefill 也跌破一千——这时候本地体验就明显不如云端了。上下文长度、ub 大小、 k 缓存 q8、v 缓存 q4 全都得严控；想开大上下文，就得多卸专家，牵一发动全身。

还有一块更隐蔽的： 我没有核显，桌面是独显输出的 。9070 XT 平时被 Windows 桌面占着 1–2G 显存，等于凭空多卸了 5、6 层专家。也就是说，标称 16G 的卡，真正能给你的模型用的远没有 16G。每次调参，都得在「桌面吃掉的那 1–2G」和「模型要的层数」之间反复腾挪，谁调谁知道。

四、llama.cpp 的新参数 -moe-cache ，和 Strata 想到一块去了

-moe-cache-mib 这个参数，是 PR #29887 在 2026-10-07 合并的（build b11480 起可用），多卡支持 #30112 在 10-08，随 v0.7.0 在 2026-10-15/16 正式发布，所以当我看到这个信息的时候，我的第一反应是：终于来了！我打算用到我的A3B上测试一番！

原理一句话：在显存里开一块 LRU 专家缓存 ，路由命中的专家直接从显存取，只有 miss 才走 PCIe 从内存搬——和 Strata 的「按需搬运」是同一个念头。

当然它有限制条件： 只对 ≤32 token 的批次生效 ，也就是 生成（decode）阶段受益，prefill 仍走老 offload 路径 ；官方标称 offload 场景下最高约 2.2x decode。模型本来就全塞进显存时，这个参数几乎没用——它专治「专家在内存、显存放不下」这种病。

我拿它实测了一把，参数： -moe-cache-mib 4096 ，KV 缓存从「k q8 / v q4」 全升到 q8 ， --n-cpu-moe 从 17 提到 28 。

翻开日志看了看：context 262144 ，引擎加载估算 Model 19.68 GB + KV 3.33 GB = Total 23.01 GB ——稳稳装下，显存还有富余（这个 19.68 是加载估算口径，不是文件体积：gguf 本体 18.2G + 视觉塔 0.9G ≈ 19.1 GB）。实时 GPU 面板更直观： 专用 14.7/16.0 GB + 共享 12.5/15.9 GB = 总计 27.2/31.9 GB ，还剩 4.7G 余量。

速度上，同一份任务：prefill 读取速度基本没有下降，还是1300t/s左右；生成速度反而还小幅提高到了76t/s，这还是在多卸载了11层专家并且上下文拉满的情况下做到的。

缓存还能再喂大：把 -moe-cache-mib 提到 4800，生成速度能超过 80 t/s，但 prefill 读取速度会降——所以这块就是权衡读取和生成的速度了，看你需求是怎样的；再往上加到五千多，内存就报警不够了——32G 确实是天花板，我没再继续试了。

我又下了 UD Q4_K_XL （22.9G，比 IQ4_XS 更接近无损，但大了 4.7G），也试了试。也能跑动，但 -moe-cache-mib 只能压到 2048 左右，读取速度 1750-1000 t/s、生成速度约 58 t/s，这速度还是可以接受的。但最大的问题在于显存和内存都吃紧，热点专家缓存拉不大，上下文也拉不高，可以腾挪的空间不多，有点像 27B 必须全部塞进 16G 显卡的那种感觉，又到了需要取舍的时候了。

瓶颈还是那 32G 内存。内存再大点，就能无脑上、不用焦虑；深入一点的测试这次没时间搞了，留到以后比较了再说。

还有一句老经验： mmap 必须关 。卸了大量专家时不开 mmap，速度会暴跌没法用。

配置 / 速度对照表