Qwen3.8-Flash-Next 177B on an RTX 5090 Laptop

24 GB VRAM + 64 GB RAM · 256K Context · 110 tok/s peak · 100+ sustained · Vision Enabled

中文 ｜ English →

---

⚡ Strata 引擎实测 —— 26 轮实测 · 7 个量化档位筛选 · 25+ 组参数扫描 · 峰值 110 tok/s

筛选过程：2 个引擎家族（传统 CPU-offload 引擎、Strata 0.1.27/0.1.28）、7 个量化档位（AtomicChat AD-3.84bpw / ISTA-DASLab Coder IQ1_M / Q2_0 / IQ2_XS / IQ3_XXS / IQ3_S / Qwen BF16）、25+ 组参数扫描、12 个假设逐一排除——最终落位唯一"最佳"：

• 最佳选择（当前日常）：ISTA-DASLab GSQ-RCO IQ3_XXS（512 专家完整版）· 基准 77.4 tok/s，日常真实负载峰值 110.9 tok/s、3000+ token 长输出仍 101-103 tok/s（256K + Vision 全开）
• 曾设"速度优先"线（Q2_0 · 93.5 tok/s）：后被 IQ3_XXS 的真实负载速度全面反超——草稿接受率 78% 对 44-54%，质量档反而更快——速度线已无存在意义，退役（数据保留见下文实录）
• 附赠：ISTA-DASLab Coder IQ1_M（256/512 专家剪枝版，62.5 tok/s，内存减半，多开/超长上下文备选）

四个重点发现

1. GPU 与 CPU 第一次同时占满：传统 CPU offload 方案 CPU 单核钉死 100%、GPU 闲 20-40%；Strata 三层架构（热专家显存缓存 + CPU 池 + MTP 流水线重叠）让两个处理器同时满载——这是数倍提升的结构性根因
2. MTP 坏死之谜：31 个草稿层权重文件里 20 个因 HTTP Range 被镜像站忽略而下载损坏（存成了 shard 头部），sha256 校验无法发现；自编译引擎加 NaN 探针定位 → 重拉修复 → MTP 接受率 0% → 70.8%。完整复盘：docs/mtp-corruption-postmortem.md（已报上游 Strata#327，作者确认并于 v0.1.32 修复：强制校验 HTTP 206 + Content-Range、对照官方 pinned 版本逐张量 sha256、损坏自动重拉）
3. spec_min_p 峰值随草稿质量漂移：Q2_0 峰在 0.3，IQ3_XXS 峰在 0.7——换模型必须重扫（见下方曲线）
4. 256K 上下文几乎免费：KV streaming 下 65K/128K/256K 速度几乎相同，64GB 内存实测 256K 稳定；Vision 与 256K 并存（每图 ≤1024 token，单会话可塞 250+ 张图）

🤔 同一台 5090：本仓库 177B MoE vs 27B NVFP4 —— 怎么选？

两个仓库是同一台 RTX 5090 Laptop 24GB 上的两种使用姿势。差别不在谁更强，在这台电脑当时扮演什么角色：

一句话：这台电脑当"模型提供者"（本机不干别的）→ 用本仓库 Flash-Next；要在同一台电脑上一边工作一边用 → 用 27B NVFP4。

🚀 部署与启动（照着做即可）

引擎 Strata（MIT License），Windows/Linux 均可；只需 NVIDIA 驱动，Python 3.12 由安装器自动装到用户目录（无需管理员权限）。

① 安装引擎：按 Strata 官方 README 获取引擎（下载 release 的 strata-windows-x64.zip 解压，或 git clone 源码仓库）。

② 一条命令完成模型打包与配置（以我们的现役模型为例）：

cd Strata/app

:: 最佳选择（本仓库当前日常）：IQ3_XXS
python setup.py --family qwen --model IQ3_XXS --context 131072 --vision yes --port 8081 --yes --gguf-dir "D://models//Qwen3.8-Flash-Next-GSQ-RCO-GGUF"

• --gguf-dir 指向你已下载好的 GGUF 分片目录；不加这个参数 setup 会重新下载数十 GB
• 首次运行会自动安装 Python 3.12、创建独立 .venv、下载引擎、打包专家 profile（也可双击 START-HERE.bat 走交互式）

③ 启动：再次运行同一条命令或双击 START-HERE.bat，浏览器打开 http://127.0.0.1:8081/ 即可聊天与贴图（OpenAI / Anthropic API 同端口）。

④ 想要 256K 上下文：setup 出于保守会把 IQ3 系压到 128K。实测 64GB 内存下 256K 稳定——安装后编辑 strata-iq3_xxs.json：--max-context 改 262144，并追加 "--kv-resident", "32768"（KV 进内存、显存只留 32K 热窗），重启生效。详见上下文阶梯数据。

⑤ 验证 MTP 在工作：log 里 drafts accepted 必须非 0。若是 0 of 0 或 0 of N，先跑 tools/check_dense.py 体检草稿层权重——大概率是下载损坏（完整方法见事故复盘）。

⑥ 思考与并发（接入客户端前必读）：

• 思考默认 = xhigh（最高档）——聊天模板出厂写死。档位体系：xhigh（默认）> medium > low；没有 high 档（会被自动升为 xhigh）。日常想快可传 reasoning_effort: low（思考变"简短直给"，出答案明显更快），复杂推理保持默认
• 并发 = 无，FIFO 串行：HTTP 层多线程接得住并发连接，但推理层一把 FIFO 锁——同一时刻只有一条 decode 在跑，后来的请求排队等待（不丢不拒绝，GET /status 可看队列）。单人使用无感；多人/多客户端同时用会依次等
• 默认 max_tokens：客户端不传时引擎会给默认值，但思考型模型建议始终显式传 ≥600

License 与合规：引擎 Strata 为 MIT；llama.cpp / ggml 为 MIT；模型权重 license 以各 HF 页面为准（GSQ-RCO 系列页标注 Apache-2.0，继承 base model）。本仓库只含自测数据与工具，不再分发任何模型权重；所有商标归各自所有者。

---

Strata 时代 18 轮调优明细

📘 Strata 完整实录（中文） → docs/strata-log.zh.md ｜ English 🔬 MTP 损坏事故复盘 → docs/mtp-corruption-postmortem.md（上游 Strata#327） 🧪 原始数据 → results/strata-*.txt　🛠 修复工具 → tools/

---

模型档案：我们用过的每一个量化（优势 / 为什么选 / 最终结果）

全程涉及 4 个模型仓库、7 个量化档位。总表 + 逐个档案如下。

量化机构与量化学派速览

• ISTA-DASLab（奥地利科学技术研究所 Deep Algorithms and Systems Lab，GPTQ 与 QuIP# 的提出者，低比特量化领域最权威的研究组之一）—— 本次主力仓库，使用其自研的 GSQ（Gumbel-Softmax Quantization，2~3bit 逼近矢量量化精度的标量量化）与 RCO（Riemannian Constrained Optimization，在总比特预算下逐张量分配量化类型）两种有论文的方法，产出 GSQ-RCO 系列
• AtomicChat —— AD 系列逐层动态精度量化（AD-5.00bpw-Q5_K_M / AD-4.27bpw-Q4_K_M / AD-3.84bpw-IQ4_XS-M64），llama.cpp 时代的主力供应商
• Unsloth（UD 系列）—— 曾进入候选池，经体积与分片评估后淘汰
• Qwen 团队（阿里巴巴通义千问）—— Qwen3.8-Flash-Next 原始模型（176B MoE，混合 GDN/QSA 架构）与 MTP 草稿层权重的唯一来源

1️⃣ AtomicChat AD-3.84bpw-IQ4_XS-M64 —— llama.cpp 时代的主力

• 优势：4-bit 档少见的"动态逐层精度"量化（AD = AtomicChat Dynamic），精度与显存的平衡点；M64 分片让 llama.cpp 能在 24GB 显存跑通 177B MoE
• 为什么选：llama.cpp 时代它是唯一兼顾质量与速度、且社区验证过的选择
• 结果：22-25 tok/s。暴露了 llama.cpp 的结构性问题——CPU 单核 100%、GPU 闲 20-40%，任何调参都绕不过去。由此转向 Strata

2️⃣ ISTA-DASLab GSQ-RCO Q2_0 —— 速度王 ★

• 优势：2-bit 但有 GSQ（Gumbel-Softmax）+ RCO（逐张量精度分配）两篇论文方法背书，2-bit 下逼近矢量量化精度；专家 blob 最小 → 显存能塞最多热专家（13,212 slots，98%+ 命中）
• 为什么选：确认 Strata 的 GPU 缓存架构后，专家 blob 越小命中率越高、MTP 收益越能全额兑现——纯速度打法的最优解
• 结果：93.5 tok/s（spec_min_p=0.3），追平桌面 5070 参考值；草稿接受率 44-54%

3️⃣ ISTA-DASLab GSQ-RCO IQ3_XXS —— 质量线（当前日常）

• 优势：3-bit i-quant，质量高一档；草稿质量也是三个部署版本里最好的（接受率 59-71%）
• 为什么选：长项目/推理密集场景需要更低的量化损失；且 arena 42.9GB 在 64GB 内存上给 256K 上下文留足余量
• 结果：77.4 tok/s（32K）/ 74.4 tok/s（256K+Vision）。注意它的 spec_min_p 峰值在 0.7 与 Q2_0 的 0.3 完全不同

4️⃣ ISTA-DASLab GSQ-RCO IQ3_S —— 评估后否决

• 优势：3.5-bit，官方基准上匹配完整 BF16 模型——三档里质量最高
• 为什么放弃：arena 50.3 GB pinned，256K 上下文的 KV 还要 3.1 GB——64GB 内存的机器上只剩 ~10GB 给系统，官方自己也标注"64 GB PC with little else running"。256K 是硬需求，这个组合风险不可接受
• 复活条件：内存升级到 96GB 后即可启用（见 内存升级 96GB 可行性分析 本地文档）

5️⃣ ISTA-DASLab GSQ-RCO IQ2_XS —— 评估后未部署

• 优势：2-bit i-quant，质量略好于 Q2_0，速度官方描述"close in speed"
• 为什么没上：Q2_0 已实测 93.5 且 IQ2_XS 的质量增量介于 Q2_0 与 IQ3_XXS 之间——质量需求出现时我们直接跳了 IQ3_XXS，中间档没有部署价值
• 保留意见：若需要"比 Q2_0 好一点但比 IQ3_XXS 快很多"的档位，它是现成候选

6️⃣ ISTA-DASLab Coder IQ1_M —— 省内存线（备选）

• 优势：官方把 512 专家剪枝到 256（专门保留代码、工具、视觉相关的专家），arena 只有 23.4GB——内存减半；存储密度反而是"IQ3_S like"的 3.5bit
• 为什么选：内存紧张时多开实例、或需要 32K 以上上下文且不想动用 streaming 的场景
• 结果：62.5 tok/s（MTP 修复后）；官方数据非代码领域弱于完整版，与我们"剪枝专家"的预期一致

7️⃣ Qwen（阿里巴巴通义千问）BF16 官方 checkpoint —— 只取 MTP 权重

• 优势：无损原版，一切量化的理论上限；354GB 显然无法本地部署
• 为什么还下载它：Strata 的 MTP 草稿层权重只存在于 BF16 checkpoint 的 mtp.* 张量里（GSQ-RCO 量化版不带）——用 HTTP Range 精准拉取 5.2GB 而非 360GB 全量
• 结果：间接导致本次最大的坑（MTP 权重损坏事故），也间接产出了检测/修复工具链

8️⃣ mmproj BF16 Vision Encoder —— 视觉能力

• 优势：27 层 ViT + projector，1,024 token/图上限，GPU 编码 0.1-0.5s/张
• 为什么选：Vision 是硬需求；0.9GB 一次下载
• 结果：挂载成功，识别验证全对，256K+Vision 并存速度损失约 16%

---

这是什么 / What this is

在一台消费级笔记本上跑通 177B 参数的 MoE 大模型 —— 不是"能加载"，而是能日常使用：

• 256K 上下文开满（约 19.2 万字，整本书的量级）
• 25.0 tok/s 生成速度（约等于每秒 15 个汉字，比人阅读快）
• 图像识别可用（保留视觉能力）
• 显存占用 23.4 / 24 GB，长期稳定运行

本仓库记录了从零开始的完整调优过程：量化选型、三层内存分配、参数扫描、以及 12 项试过但无效的方向（避免重复踩坑）。

📘 可视化速查页 → index.html 🧪 原始实测数据 → results/ 🛠 可复用测试工具 → tools/ 📄 深度实录 → 中文 ｜ English 🔧 移植到其他硬件 → porting-guide.md

目录

• 成果总览
• 三分钟上手
• 架构：三层卸载
• 完整调优历程（8 步）
• 性能实测数据
• 试过但无效的（12 项）
• FAQ
• 硬件升级路径
• 关键结论

---

成果总览 / Results at a glance

上下文档位对照 / Context tiers

为什么推荐 256K：它只比 112K 慢 7.5%，但上下文是 2.3 倍 —— 容量收益远大于速度损失。

---

先下载模型 / Get the model

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

# 下载主模型 + 视觉投影（支持断点续传）
pip install -U "huggingface_hub[cli]"
hf download AtomicChat/Qwen3.8-Flash-Next-GGUF \
  --include "*3.84bpw*" --include "*mmproj*" \
  --local-dir D:\models\Qwen3.8-Flash-Next

[!IMPORTANT] 务必选择 AtomicChat 的 -M64 版本，不要用其他发布方的同类量化。

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

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

硬件前提：24GB 显存 + 64GB 内存 + NVMe SSD（本方案的实测配置）。

---

三分钟上手 / Quick start

1. 启动

llama-server \
  -m Qwen3.8-Flash-Next-AD-3.84bpw-IQ4_XS-M64-00001-of-00028.gguf \
  -ngl 99 --n-cpu-moe 36 \
  -fa on -fit off \
  -c 262144 -np 1 \
  -ctk q8_0 -ctv q8_0 \
  --load-mode dio \
  -mm mmproj-Qwen3.8-Flash-Next-F16.gguf \
  --jinja --alias qwen3.8-flash-next \
  --host 127.0.0.1 --port 8080

⚠️ 注意：不含 -md / --spec-type —— MTP 已停用（负收益，见下）。 加载约 30~60 秒。看到 listening on http://127.0.0.1:8080 即就绪。

2. 客户端配置

3. 三条纪律

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

---

架构：三层卸载 / Three-tier split

核心思路：按访问频率分配存储，而不是一味往显存塞。

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

瓶颈在哪

实测推理期间 GPU 利用率约 25%，CPU 接近满载。这是"专家由 CPU 计算"的必然：

每生成 1 个 token 要依次走完 48 层：
GPU 算第1层注意力 → CPU 算第1层专家 → GPU 算第2层注意力 → CPU 算第2层专家 → ... ×48
      ↑ 工作              ↑ 干等              ↑ 工作              ↑ 干等

要填满 GPU，唯一办法是把更多专家放进显存 —— 而显存已经满了。

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

---

完整调优历程（8 步）

从"能跑"到"跑到硬件极限"。每步记录做了什么 / 发现了什么 / 为什么有效。

第 0 步 · 选对量化布局（决定性）

筛除条件不是位宽，而是分片布局 —— N-gram 表（35.76 GiB）是否独占分片：

为什么布局是决定性的：GGUF 分片是 mmap 的最小单位。如果表与专家混在同一片里，一旦这片被访问，整片（可能几十 GB）都会进内存 —— 在 64GB 内存的机器上直接压垮。只有"表独占分片"的布局，才能让 dio/mmap 精确地按需分页。

为什么最终选 3.84bpw：除了布局，它还是"速度 vs 质量"的平衡点 ——

反直觉的一点：3.84bpw 的专家精度更高（4.25bit vs 2.5bit），它是靠压缩其他部分来控制总体积的。换过去不是降级。

第 1 步 · 让 79GB 模型跑进 24GB 显存 —— --n-cpu-moe

-ngl 99              ← 所有层上 GPU（关键：不要为了塞模型调低它！）
--n-cpu-moe 36       ← 前 36 层的【专家权重】放 CPU

关键认识：不要沿用稠密模型的思路去调 -ngl。MoE 应该让注意力层全部留在显存（每 token 都用），只把路由专家（稀疏激活）挪到内存。

两类静默失败要防：

第 2 步 · KV 量化（q8_0）—— 性价比最高的一档

KV 缓存不参与计算却占着显存。量化它 → 省下的显存换更多专家层：

精度用**多轮随机化「大海捞针」**验证：9.7k token 文档、3 个事实埋在随机深度、同种子跨配置对比、检查 finish_reason 排除截断假象。

结论：q8_0 精度无损且提速 3.4%。

第 3 步 · dio 加载模式 —— 省 13GB 内存

--load-mode dio    ← 绕过系统页缓存，直读 SSD

效果：可用内存从 7GB → 20GB。N-gram 表（35.8GB）不再被页缓存重复占用。

为什么可行：NVMe 随机读带宽（1.3GB/s+）足够喂饱 CPU 侧专家计算，页缓存的收益抵不上它挤占的内存。

第 4 步 · 换 3.84bpw 小模型 —— 省 8.9GB，多放 4 层专家

关键链条：

模型 88.03GB → 79.10GB（省 8.94GB）
  → 显存占用降 2.4GB
  → 可多放 4 层专家进显存
  → CPU 侧负担减轻 → 提速
  → 同时内存占用也降 → 可用内存 12.8GB → 26.2GB

双赢：速度和内存同时改善。

第 5 步 · 上下文调优 —— 找到"显存压力临界点"

发现：128K → 112K 只减 16K 就快 15.6%。存在一个"显存压力临界点" —— 128K 时显存被压得太满，各种分配开销都在最高档。

第 6 步 · ⭐ 关掉 MTP —— 最大的单项收益（+23%）

这一步推翻了最初的假设。

MTP（Multi-Token Prediction）推测解码的直觉是"草稿模型先猜、主模型一次验证"能省前向次数。但在 MoE + CPU 专家的架构下，它是负收益：

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

而且它还白占 3.5GB 显存（草稿模型 + 自己的 KV）。关掉后这 3.5GB 能换 4 层专家进显存。

代价：无。速度、显存双赢。

第 7 步 · 把省下的显存全部换成专家层

关掉 MTP 省下 3.5GB → ncmoe 从 36 降到 32 → 刷新纪录。

最终显存账本：

---

性能实测数据

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

生成速度

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

prefill 速度约 320~400 tok/s。这不是故障 —— 多轮对话中第 2 轮起会快很多（prompt cache 复用历史 KV）。

MTP 调参（已排除的方向）

已全部废弃 —— 因为 MTP 本身就是负收益（见第 6 步）。

思考强度（reasoning_effort）

按难度分化：

⚠️ 难题在 xhigh 下思考量可达 5700+ 字符（约 3000 token） —— max_tokens 设小了会出现"想完了但没答案"。建议 16000。

---

试过但无效的（12 项）

---

FAQ

Q: 为什么不用 NVFP4？Blackwell 不是原生支持吗？

A: 三个层次：

1. 这个模型没有 NVFP4 版本（两个发布方共 164 个文件全量枚举，无 FP4 量化）
2. 生成瓶颈是内存带宽不是算力 —— FP4 张量核加速的是矩阵乘法，帮不到"每 token 从内存读专家权重"。实测 NVFP4 只加速 prefill（+43~68%），decode 完全不变（~0%）
3. NVFP4 等效约 4.5 bpw，比现用的 3.84 bpw 更大，在内存受限场景反而更慢

Q: 为什么用 llama.cpp，不用 vLLM / TensorRT-LLM？

A: 只有 llama.cpp 提供 --n-cpu-moe 这种按层把专家留在内存的精细控制，以及 mmap 分片按需分页 —— 这两点是 24G 显存跑 79GB 模型的前提。（vLLM/SGLang 的 expert 粒度 offload 还在 RFC 阶段）

Q: 上下文最多能开多大？

A: 本机实测能开满 256K，速度 25.08 tok/s。自算公式：

VRAM ≈ 4.4 + (48−ncmoe)×1.03 + ctx×33KiB + 计算缓冲

Q: MTP 到底有没有用？

A: 在 MoE + CPU 专家的架构下，是负收益（实测关掉 +23%）。这是本仓库最反直觉的结论。

Q: GPU 利用率只有 25%，是不是浪费？

A: 不是，这是结构性的。 decode 是串行接力，GPU 在 CPU 算专家时只能干等。要填满 GPU 只能把更多专家放进显存，而显存已经满了。

Q: 内存升到 128GB 有帮助吗？

A: 对速度几乎没有（瓶颈是显存容量）。价值在"系统更从容"和"未来上更大模型"。注意本机 4 个插槽全满，升级需整组替换（4×32GB）。

Q: 生成速度还能再快吗？

A: 软件层面已经到底（12 项无效尝试）。剩余路径：

Q: 会不会把内存撑爆？

A: 单实例实测内存峰值 85~95%，稳定运行。真正的风险是同时开多个实例 —— 每个要 23GB 显存，两个必爆。

---

硬件升级路径

结论：提速只能靠显存；内存升级只为"系统从容"。

---

关键结论

1. 布局比位宽重要 —— N-gram 表是否独占分片，决定方案能否成立
2. 两类静默失败要防 —— CUDA 缺失静默退回 CPU；显存溢出静默走 PCIe（慢 30 倍无报错）
3. ⭐ MTP 在 MoE + CPU 专家下是负收益 —— 验证批的专家激活并集放大内存流量（实测关掉 +23%）
4. KV 量化是性价比最高的一档 —— q8_0 精度无损（12/12），换专家层 +3.4~5%
5. dio 省 13GB 内存 —— 让 N-gram 表留在 SSD
6. 上下文存在"显存压力临界点" —— 128K→112K 只减 16K 就快 15.6%
7. --n-cpu-moe 是唯一的旋钮，且存在悬崖（本例 28 层即崩，26.9→4.7 tok/s）
8. 换引擎不会更快 —— 生成受内存带宽限制（实测无提升）
9. 测速必须读服务端日志的 eval time —— 用 API 耗时推算会被冷启动和 prompt cache 干扰，误差可达 100%
10. 关掉 VBS 没有收益 —— 证明瓶颈是 CPU 算力/内存带宽的物理限制，不是软件虚拟化开销

---

硬件与软件

---

仓库结构

├── README.md                     ← 本页
├── README.en.md                  ← English
├── index.html                    ← 可视化速查页
├── assets/                       ← 图表 (SVG)
├── docs/
│   ├── deploy-log.zh.md          ← 完整实录（中文）
│   ├── deploy-log.en.md          ← Full write-up (English)
│   ├── model-reference.md        ← 架构参数、量化对照、NVFP4 说明
│   └── porting-guide.md          ← 移植公式与硬件对照表
├── results/                      ← 原始实测输出
└── tools/                        ← 可复用测试工具

---

免责声明

• 所有数据均为单机实测，硬件/驱动/构建版本不同结果会有差异；
• 模型权重与量化文件版权归各自发布方；
• 测试脚本会自动结束 llama-server 进程，请勿在有其他推理服务运行时使用。

License

MIT（仅适用于本仓库的文档与脚本）