我做了个工具让 8GB 显卡跑 30B 模型从 3 tok/s 提到 21 tok/s，记录一下技术发现
最近在折腾本地大模型，发现一个核心问题：Ollama 和 LM Studio 能让模型跑起来，但参数全靠猜——上下文长度、KV cache 类型、MoE expert 放哪、ubatch 多大……用默认参数基本是在浪费显卡。
于是做了个工具自动找最优配置，过程中踩了不少坑，记录一下。
核心发现
1. MoE 模型的 offload 策略决定了一切
Qwen3-30B-A3B 是 MoE 架构，在 8GB 显卡上：
- LM Studio 默认把所有层塞进显存 → 7549MB （ 93%），3 tok/s
- 只把 attention 层放 GPU ，MoE expert 层走 CPU → 2603MB （ 32%），21 tok/s
快了 7 倍，显存反而省了 65%。关键是 llama.cpp 支持这个，但你得自己识别哪些 tensor 是 MoE expert （.ffn_.*_exps. 这类命名），然后手动配。
2. KV cache 类型影响比大多数人想的大
同一张 8GB 显卡跑 Llama 3.1 8B ，不同 KV cache 配置速度差异：
| 配置 | ctx | 速度 |
|---|---|---|
| iso3+iso3 ，4 slot | 8K | 19.4 tok/s |
| q8_0+q4_0 ，1 slot | 8K | 38.2 tok/s |
| f16+f16 ，1 slot | 8K | 51.7 tok/s |
| f16+f16 ，1 slot （自动） | 64K | 26.2 tok/s |
f16 比 iso3 快将近 3 倍。但 f16 显存占用更大，所以正确策略是：先算 f16 KV cache 占多少显存，装得下就用 f16 ，装不下再降级。
公式：KV_MB = 2 × layers × kv_heads × head_dim × ctx × bytes / 1024²
3. oobabooga 公式用来预测 ctx 上限
社区里流传的 oobabooga 显存估算公式，原本用来预测装载模型后剩余显存能支持多大 ctx 。但这个公式是基于 q8_0/f16 拟合的，用 iso3 的时候会严重高估显存需求，导致 ctx 只算出 4K 。
最后放弃公式预测，改成二分探测：从 min(nativeCtx, 65536) 开始，OOM 就减半，最多探 5 次，让 llama-server 自己告诉我能跑多少。Llama 3.1 8B 的 ctx 从 4K 直接到 64K 。
4. parallel slot 数量对单用户场景影响巨大
llama.cpp 默认开 4 个并行 slot （为了多用户并发），但单用户场景下这会把 VRAM 分成 4 份。
关掉多余 slot （--parallel 1）之后：18.5 → 38.2 tok/s ，直接翻倍。
5. ubatch 实测比理论更可靠
ubatch 128 vs 512 的性能差异跟模型和显卡都有关系，没有通用最优值。实测结论：
- 8K ctx：ubatch 512 比 128 快 7.6%
- 64K ctx：ubatch 512 比 128 快 21.6%
直接 benchmark 两个值取快的，比查文档猜靠谱。
6. 对话压缩不要用模型生成摘要
最初方案是上下文满了之后调本地模型生成摘要——结果单 slot 阻塞，直接超时。
改成纯算法提取：保留头部（ system prompt + 首轮对话）和尾部（最近 8K tokens ），中间部分提取代码路径、函数名、文件名、TODO 等关键信息。压缩率 73%，耗时 <1ms 。
用了哪些技术，实现了什么功能
llama.cpp — 推理引擎核心
直接调用 llama.cpp 的 llama-server ，所有参数（ ctx 、KV cache 类型、线程数、ubatch 、mlock 、tensor split ）都通过启动参数注入。Kaiwu 本质上是一个参数决策层，不改推理引擎本身。
IsoQuant / TurboQuant — 3-bit KV cache 压缩
集成了 johndpope 的 turboquant fork （feature/planarquant-kv-cache），支持 -ctk iso3 -ctv iso3 参数。iso3 的压缩系数实测 0.73 ，理论值 0.75 ，在 VRAM 紧张的设备（ 8GB ）上可以把 KV cache 占用压缩到 q8_0 的一半。但有约 600MB 固定解码 buffer 开销，VRAM 充裕时反而比 f16 慢 8%，所以策略是 VRAM > 16GB 才默认开 iso3 。
oobabooga 显存估算公式 — ctx 上限预测（已放弃）
社区流传的公式用来预测剩余显存能支持多大 ctx ，基于 q8_0/f16 拟合。iso3 场景下高估显存需求，导致 ctx 只算出 4K 。最终改成二分探测代替公式，让 llama-server 自己决定能跑多少。
GQA 架构识别 — KV cache 精准估算
Qwen3 等新模型用 GQA （ Grouped Query Attention ），kv_heads 远小于 attention_heads 。KV cache 大小公式里用的是 kv_heads 而不是 heads ，不识别这一点会高估 3-4 倍。通过读 GGUF metadata 拿到准确的 kv_heads 值再做计算。
MoE tensor 识别 — 自动 expert offload
读取模型的 tensor 名称列表，匹配 .ffn_.*_exps. 模式识别出 MoE expert 层，自动决定把这部分路由到 CPU 。不需要用户手动指定，也不需要提前知道模型架构。
Extractive Summary — 零延迟对话压缩
上下文到 75% 时触发，纯算法提取：保留 system prompt 、首轮对话、最近 8K tokens ，中间部分按关键词权重保留（代码路径、函数名、文件名、TODO 、命令行等）。不调用任何模型，压缩耗时 <1ms ，73% 压缩率。最初试过调本地模型生成摘要，单 slot 阻塞直接超时，这条路走不通。
GitHub Actions CI — 跨平台自动编译
turboquant fork 需要自己编译带 iso3 支持的 llama-server 。用 GitHub Actions 同时编译 Windows （ MSVC ）和 Linux （ GCC ）版本，CUDA 12.4 ，覆盖 sm_75/80/86/89 架构，RTX 50 系列通过 PTX JIT 运行时支持。踩了三个 MSVC 编译坑（ extern “C” 声明改定义、M_PI 未定义、全局符号缺失），记录在 PROGRESS.md 里。
工具
把上面这些逻辑都自动化了，叫开物（ Kaiwu ）。一行命令启动，参数全部自动找，结果缓存起来，第二次 2 秒启动。
GitHub： https://github.com/val1813/kaiwu
OpenAI 兼容 API ，Continue / Cursor / Claude Code 直接接。
有遇到类似问题的欢迎交流，尤其是 MoE offload 和 KV cache 这块踩坑挺深的。
看起来显卡还是不够…: 本地大模型部署器 vv0.1.1 · llama.cpp b8864 by llmbbs.ai · 本地 AI 技术社区
[1⁄6] Probing hardware…
GPU: NVIDIA GeForce RTX 3080 (SM86, 10240 MB VRAM, 760 GB/s)
RAM: 47 GB UNKNOWN
OS: windows amd64
[2⁄6] Selecting configuration…
Model: Gemma 4 26B A4B It (moe, 19B total / 1B active)
Quant: Q3_K_S (11.4 GB)
Mode: moe_offload (experts on CPU)
Accel: Flash Attention
[3⁄6] Checking files…
Using bundled iso3 binary: llama-server-cuda.exe
Binary: llama-server-cuda.exe [cached]
Model: gemma-4-26B-A4B-it.Q3_K_S.gguf [cached]
[4⁄6] Preflight check…
✓ VRAM sufficient
[5⁄6] Warmup benchmark…
Probe 1: ctx=256K ... OOM
Probe 2: ctx=128K ... OOM
Probe 3: ctx=64K ... OOM
Probe 4: ctx=32K ... OOM
Probe 5: ctx=16K ... OOM
Probe 6: ctx=8K ... OOM
⚠️ Warmup failed: all ctx probes failed (tried down to 4K)
Using default parameters
[6⁄6] Starting server…
llama-server 不支持 iso3 ，回退到 q8_0/q4_0
Waiting for llama-server to be ready (port 11434)…
⚠️ 显存不足，降低上下文至 4K 重试...
Waiting for llama-server to be ready (port 11434)…
Error: failed to start llama-server: 连续 2 次启动失败，即使最小上下文(4K)也无法运行
建议：选择更小的量化或使用 MoE offload 模型
Usage:
kaiwu run
Flags:
--bench Run benchmark after starting
--ctx-size int 手动指定上下文大小（ 0=自动）
--fast Skip warmup, use cached profile
-h, –help help for run
--reset 清除缓存，重新 warmup 探测最优参数
@KaiWuBOSS 是 win10, 显存 10G ，内存 48G ，我在下载 qwen3-30b 试试看
@damontian 直接上 30b 模型你选你喜欢的 50 系列看 nvfp 的
@KaiWuBOSS 嗯，是 0.1.1 版本。是的，就是编译涡轮量化不知道怎么弄
@damontian 换 Qwen3-30B-A3B 这个模型专为低显存优化 3080 10GB 跑起来没问题
@sentinelK 我也参考了他的 fiton 但他没有涡轮量化 另外我还做了上下文优化 相比而言 我这个不用调参 而且是硬件最大上下文 最优显存 -fit on 是随机削层，Kaiwu 是精准分层。
–fit on：显存不够就把后面几层丢给 CPU ， 不管是什么层，速度损失大。
Kaiwu：专门识别 MoE 的专家层， 只把专家层放 CPU ，注意力层全在 GPU ， 速度损失极小——这就是为什么 同样 8GB 显存，Kaiwu 能跑出 21 tok/s ， LM Studio 只有 3 tok/s 。
llmbbs.ai 欢迎交流。