实机调优 · 2026-09-12 更新

24GB 显存笔记本
跑 177B MoE 模型

用 llama.cpp 的专家卸载把 79GB 的模型拆到显存、内存、固态三层， 配合上下文调优与 KV 量化，把生成速度推到 27 tok/s， 同时保留完整的图像识别能力。

RTX 5090 Laptop 24GB · Core Ultra 9 275HX · 64GB DDR5-5200 · NVMe SSD
27.12tok/s
生成速度（112K 上下文）
79.1GB
模型体积（3.84bpw）
+23%
本轮调优提升
112K
可用上下文（约 8.4 万字）
23.2GB
显存占用 / 24GB
0.85GB
图像识别的额外开销

它是怎么跑起来的

模型 79GB、显存 24GB。核心思路是按访问频率把模型拆成三层，而不是简单按层切分：

位置放什么原因占用
显存 24GB注意力层 + 16 层专家 + KV 缓存 + 图像投影每 token 都要用，带宽最高（1.8 TB/s）23.2 GB
内存 64GB其余 32 层专家稀疏激活（每 token 只用 10/512 个），带宽够用~33 GB
固态 NVMen-gram 查表（35.8GB）dio 模式直读，不占内存35.8 GB
为什么这样拆

注意力每 token 都要用，必须放带宽最高的显存；专家层稀疏激活，可以放带宽低但容量大的内存里由 CPU 计算。这样 79GB 的模型才能在 24GB 显存上跑起来。

瓶颈在哪

实测推理期间 GPU 利用率约 25%，CPU 接近满载 —— 这是"专家由 CPU 计算"的必然：GPU 算完注意力段就得等 CPU 算专家段。

这不是配置问题

在"模型 79GB > 显存 24GB"的前提下，GPU 等待 CPU 是物理必然。增加内存解决不了（瓶颈是显存容量），唯一办法是换更大显存的显卡。

先下载模型

本方案使用的模型与配套文件，全部来自公开的 Hugging Face 仓库（按 Qwen Community License 1.0 发布）：

文件说明大小来源
AD-3.84bpw-IQ4_XS-M64 主模型（28 分片） 84.9 GB AtomicChat/Qwen3.8-Flash-Next-GGUF →
mmproj-Qwen3.8-Flash-Next-F16.gguf 视觉投影（图像识别，可选） 0.85 GB 同一仓库 →
llama.cpp 推理引擎（需支持 Qwen3.8-Flash-Next 架构的构建） — github.com/ggml-org/llama.cpp →
Qwen/Qwen3.8-Flash-Next 原始权重（仅作参考，不需要下载） — Qwen 官方 →
⚠️ 务必选 AtomicChat 版本，不要用其他发布方的同类量化

区别不在位宽，而在分片布局：只有 AtomicChat 的 -M64 版本把 N-gram 表（35.8GB） 放进独立分片。其他发布方（如 unsloth 的 UD 系列）把表与专家混装在同一分片里 —— 一旦这片被访问，整片（几十 GB）都会被锁进内存，在 64GB 机器上直接压垮。

实测对比：同一台机器上，混淆分片的量化会出现"长对话到 60K~100K token 时静默崩溃"， 而 AtomicChat 版本可以塞满整个 256K 上下文稳定运行。

下载方式（任选）

# 方式 1：huggingface-cli（推荐，支持断点续传）
pip install -U "huggingface_hub[cli]"
hf download AtomicChat/Qwen3.8-Flash-Next-GGUF --include "*AD-3.84bpw-IQ4_XS-M64*" --local-dir D:\models\Qwen3.8-Flash-Next

# 方式 2：同时下载主模型 + 视觉投影
hf download AtomicChat/Qwen3.8-Flash-Next-GGUF --include "*3.84bpw*" --include "*mmproj*" --local-dir D:\models\Qwen3.8-Flash-Next

# 方式 3：网页端
# 打开 https://huggingface.co/AtomicChat/Qwen3.8-Flash-Next-GGUF
# → Files and versions → 下载 28 个分片
硬件前提

24GB 显存 + 64GB 内存 + NVMe SSD 是本方案的实测配置。 内存少于 64GB 时，模型无法完整驻留（需要更小的量化，但质量会下降）； 显存少于 24GB 时需要提高 --n-cpu-moe，速度会明显下降。

快速开始

核心启动命令（推荐配置）

# 112K 上下文 + 图像识别 + 优化配置（27 tok/s）
cd D:\llama.cpp
.\llama-server.exe -m "D:\models\Qwen3.8-Flash-Next\Qwen3.8-Flash-Next-AD-3.84bpw-IQ4_XS-M64\Qwen3.8-Flash-Next-AD-3.84bpw-IQ4_XS-M64-00001-of-00028.gguf" `
  -ngl 99 --n-cpu-moe 32 -fa on -fit off `
  -c 114688 -np 1 --jinja --alias qwen3.8-flash-next `
  --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0 `
  --host 127.0.0.1 --port 8080 `
  -ctk q8_0 -ctv q8_0 --load-mode dio `
  -mm "D:\models\Qwen3.8-Flash-Next\mmproj-Qwen3.8-Flash-Next-F16.gguf"
加载需要多久

约 30~60 秒。看到 listening on http://127.0.0.1:8080 即就绪。

停止

D:\llama.cpp\stop-qwen38.ps1

或在启动窗口按 Ctrl+C。关掉启动窗口 = 服务停止（前台进程）。

按场景调整

场景改动实测
极速-c 114688 --n-cpu-moe 3227.12 tok/s
均衡-c 163840 --n-cpu-moe 3325.83 tok/s
长文档（推荐）-c 262144 --n-cpu-moe 3625.08 tok/s

客户端接入

配置项值
API 类型OpenAI 兼容
Base URLhttp://127.0.0.1:8080/v1
模型名qwen3.8-flash-next
API Key任意（如 sk-local）
流式输出务必开启
上下文长度114688（按启动档位填）
max_tokens16000

思考强度：默认即最高档

实测不传 reasoning_effort 时，服务端默认按 xhigh 处理（思考量 95 字 vs low 的 28 字）。客户端没有该选项时无需任何操作。

用 xhigh 时 max_tokens 必须设够

实测复杂推理题思考量可达 5700+ 字符（约 3000 token）。设成 500 会出现"模型想完了但一个字答案都没输出"。建议 16000 —— 它是上限而非消耗。

性能实测

数据来自服务端日志的 eval time（只计纯生成时间），temperature=0 固定输出长度保证可比。

本轮关键发现：关掉 MTP 反而更快

配置显存decode说明
MTP 开 + ncmoe=3623.5 GB22.0 tok/s起点
MTP 关 + ncmoe=3620.2 GB25.4 tok/s关 MTP 省 3.5GB、快 15%
MTP 关 + ncmoe=3421.1 GB26.93 tok/s省下的显存换专家层
MTP 关 + ncmoe=3223.2 GB27.12 tok/s当前最优
为什么 MoE + CPU 专家时 MTP 是负收益

推测解码的验证批要读取"多个 token 激活专家的并集" —— 在专家大部分驻留内存的架构下，这会把内存流量放大，省下的前向次数抵不过多读的权重。

上下文 vs 速度（无 MTP，实测）

29 27 25 23 21 32K 64K 80K 112K 160K 192K 256K 27.12 25.08 26.61 decode (tok/s)
上下文ncmoedecode显存
32K3526.61 tok/s22.6 GB
64K3525.81 tok/s23.3 GB
80K3625.37 tok/s22.9 GB
112K3227.12 tok/s23.2 GB
128K3225.44 tok/s23.5 GB
144K3223.93 tok/s23.6 GB
160K3325.83 tok/s23.3 GB
192K3425.31 tok/s23.1 GB
256K（全长）3625.08 tok/s23.4 GB
256K 只比 112K 慢 7.5%，但上下文是 2.3 倍

曲线整体很平（21~27 tok/s 区间），说明上下文容量几乎不影响生成速度 —— 真正的决定因素是显存里的专家层数。需要长文档时直接开满 256K。

首字节等待（决定"感觉快不快"）

输入长度首字节说明
1K token1~3 秒日常短问，体验流畅
8K token约 25 秒中等文档
12.6K token约 40 秒长文档
112K token约 350 秒极限（整本书）

prefill 阶段要把文档"读"一遍并建 KV 缓存，速度约 320~400 tok/s，不是故障。多轮对话中第 2 轮起会快很多（prompt cache 复用）。

调优历程

从 22.0 tok/s 到 27.12 tok/s，以及一路试错的经验。

✅ 有效（按贡献排序）

优化贡献原理
关闭 MTP 推测解码+23%MoE + CPU 专家下验证批放大内存流量，得不偿失
减小上下文（128K→112K）+15.6%释放显存压力，越过"临界点"
--n-cpu-moe 精调（40→32）+10~15%更多专家进显存，减轻 CPU 负担
--load-mode dio约 +10%绕页缓存直读 SSD，可用内存 7GB→20GB
换 3.84bpw 小模型约 +10%体积小 8.9GB，省出的显存多放专家
KV 量化 q8_0约 +6%省约 1GB 显存换专家层（本机验证精度无损）

❌ 无效（别再折腾）

尝试结果原因
MTP 推测解码−15%见上
MTP 模型挪到 CPU−11%草稿生成变慢，拖累整体
MTP 的 KV 量化−19%草稿精度下降，接受率 0.49→0.37
ncmoe 低于 30OOM显存不够
-ub 1024OOM计算缓冲随 ubatch 增大
--poll 0−2%无改善
KV 降到 q4_0不更快量化开销抵消显存收益
--cpu-strict 1+0.2%核心绑定，噪声范围
--prio 2−0.8%进程优先级，无改善
-b 4096±0%更大批处理，无改善
关闭 VBS / HVCI≈0VBS 开销在系统调用/页表，瓶颈是 CPU 矩阵运算
软件层面已到底

累计排除 12 项优化方向。剩余提升路径只在硬件侧：更快内存（+7.7%）、更小量化（+10~15%，质量待验证）、换更大显存显卡（唯一大幅提升）。

GPU 利用率为什么只有 25%

这是结构性的，不是浪费

decode 是串行接力：每生成一个 token 都要走完 48 层，每层是「GPU 算注意力 → CPU 算专家」。GPU 在 CPU 算专家时只能干等。要填满 GPU 只能把更多专家放进显存，而显存已经满了。

对比：若 79GB 模型能全放显存（约需 4 张 5090），利用率可达 80%+。

常见问题

服务起不来 / 报 OOM

速度比预期慢

能不能提升 GPU 利用率

当前硬件上不能。显存 24GB 已满载，无法再往 GPU 塞专家。增加内存也没用（瓶颈是显存容量）。

加内存到 128GB 有帮助吗

收益程度
系统更从容明显
提速几乎没有
提高 GPU 利用率不能

注意：本机 4 个内存插槽全满，升级需整组替换（4×32GB）。

NVFP4 量化有帮助吗

对生成速度没有。NVFP4 加速的是 prefill（首字节 +43~68%），decode 完全不变（~0%） —— decode 是带宽受限，FP4 张量核帮不上。此外该模型目前也无 NVFP4 版本。

想改参数

编辑 D:\llama.cpp\start-best-*.ps1：

$NCMOE    = 32        # CPU 侧专家层数（调低=更快，但会 OOM）
$CTX      = 114688    # 上下文容量
$KVQUANT  = "q8_0"    # KV 量化
$LOADMODE = "dio"     # 加载模式
$NMAX     = 4         # MTP 草稿长度（当前已停用 MTP）

参数速查

参数当前值作用
-ngl 9999所有层上 GPU（注意力必须留显存）
--n-cpu-moe32前 32 层的专家权重放 CPU
-c114688上下文（112K）
-ctk / -ctvq8_0KV 缓存量化
-fa ononFlashAttention（必开）
--load-modedio绕过页缓存直读 SSD
-mmmmproj-F16图像识别
--spec-type不使用MTP 在此架构下为负收益
-np1并发槽位

环境

项值
GPURTX 5090 Laptop 24GB（Blackwell sm_120）
CPUIntel Core Ultra 9 275HX
内存64GB DDR5-5200（4×16GB，最大可扩 128GB）
引擎llama.cpp b10840
模型Qwen3.8-Flash-Next AD-3.84bpw-IQ4_XS-M64（79.1GB / 28 分片）
视觉mmproj-F16（0.85GB）
系统优化Defender 排除模型目录；VBS/HVCI 已关闭（实测无影响）

三条纪律

  1. 只开一个实例 —— 多开必爆显存，速度跌到个位数
  2. 用完就关 —— 常驻占 23GB 显存
  3. 改配置后必须重启进程 —— 参数只在启动时读取