8GB 显卡跑 176.9B Coder：Qwen3.8-Flash-Next 剪枝版实测 262K 上下文
Reddit 用户 jonathanx37 10 月 24 日发帖：在 8GB 显存 + 24GB 内存的机器上，用 llama.cpp 跑通了 Qwen3.8-Flash-Next Coder 特化版——底模 176.9B 参数、262K（262144）上下文、CoT 代码模型。这篇实测的价值在于配置可复现：显存、内存、磁盘三层各装什么、启动参数怎么写，原帖和评论区都给全了。
模型：剪掉一半专家的 Coder 特化版
这个 GGUF 来自 ISTA-DASLab（奥地利科技研究所 DASLab），发布于 9 月底，做法是「剪枝 + 量化」两步：用 RCO 优化（按剪枝前后模型的 KL 散度搜专家组合）从每层 512 个专家里剪掉一半，保留 256 个；留下的权重按 3.5 bpw 存储（GSQ 标量量化）。
| 项目 | 底模 BF16 | GSQ-RCO Coder |
|---|---|---|
| 参数 | 176.9B | 常驻权重 29.6 GB |
| 总占用 | 354 GB | 58.4 GB（含可放磁盘的 n-gram 表） |
| SWE-bench Verified | 82.80 | 75.60（保留 91.3%） |
| LiveCodeBench v6 | 87.43 | 86.28（保留 98.7%） |
官方模型卡特别澄清了一个常见误会：这套文件名里带 IQ1_M，但不是 1-bit 量化——「1.89 bit/参数」是把剪掉的专家摊回原参数量的有效速率，实际存储的权重是 3.5 bpw。剪枝针对代码、agent 工具调用、视觉与空间推理保留专家，这些域之外的 Capability 有损（官方明说这是方法代价，通用场景请用未剪枝版）。实测口径为 xhigh reasoning effort。
8GB 显卡怎么塞：三层分装
模型卡说 29.6GB 常驻权重「单张 32GB 加速器可容纳」，8GB 卡显然不行——发帖人的思路是把三层介质按访问频率分装：
| 介质 | 装什么 | 依据 |
|---|---|---|
| SSD（最快的盘） | n-gram 表（28.8 GB，IQ4_NL） | 查找表，按需读盘 |
| 内存 24 GB | 大多数 MoE 专家权重 | 每 token 只激活 10/512 个（剪后 256），按需经 PCIE 取 |
| 显存 8 GB | 非专家权重、共享专家、小的路由专家、KV cache | 常驻热路径 |
关键工具是 llama.cpp 的 -ot（override-tensor）正则：把指定层的 ffn_*_exps 权重划给 CPU，正则里的层号按专家张量大小从大到小排，显存有富余就从列表尾部往回删层号——每多留一个小专家在显存，就少一次 PCIE 往返。发帖人给了逐层大小表：48 层的 routed 专家每层 369–655 MB，合计 23.42 GB，正好对上「显存放小的、内存放大的」的分法。
启动参数要点
完整命令 40 余行见原帖评论（常规版 + 显存更紧版两条），核心开关：
./llama-server \
--model ./Qwen3.8-Flash-Next-GSQ-RCO-IQ1_M-merged_P1G_Pruned.gguf \
--ctx-size 262144 \
--n-gpu-layers 999 \
--cache-type-k q5_0 --cache-type-v q4_0 -fa on \
--kv-unified \
--load-mode none \
-ot 'token_embd=CPU,blk\.(47|17|25|...)\.ffn_.*_exps\.weight=CPU' \
--spec-type ngram-map-k4v --spec-draft-n-max 16 \
--jinja --chat-template-file ./chat_template.jinja
几个开关的用处：
- KV 量化 + 统一 KV：K 用 q5_0、V 用 q4_0，262K 上下文的 KV cache 才塞得进显存预算；
--load-mode none：不用 mmap。发帖人实测把 mmap 换成 none 后预填充从 70 T/s 提到 104 T/s（+50%）——lazy 模式下按需读盘比 mmap 页错误调度更高效，代价是内存压力变大；--spec-type ngram-map-k4v：n-gram 投机采样（3-gram 命中、草稿 16 token），这是 n-gram 表存在的意义——用磁盘上的查找表给 PCIE 慢的专家取数打掩护；- qwen sharp 聊天模板：发帖人称减少过度思考（overthinking），同一任务总时长因此缩短。
发帖人还提醒：CUDA 后端在部分 8GB 卡上跑不起来（后台应用挤占显存时更甚），跑不动就换 Vulkan 后端，并关掉浏览器硬件加速。
性能：预填充快，生成慢，瓶颈在 PCIE
实测数字（8GB VRAM + 24GB RAM，PCIE 3.0）：
| 阶段 | 速度 | 说明 |
|---|---|---|
| 预填充 PP | 104 T/s | 原帖标题的 70 T/s 是 mmap 时代的旧值 |
| 生成 TG | 8 T/s | 受 PCIE 3.0 带宽限制，作者想换 PCIE 4.0 验证 |
先说清一个容易误读的地方：原帖标题「70 T/s」指的是预填充（处理输入）速度，不是生成速度——生成只有个位数。评论区的实际体验讨论也围绕这一点展开：有人算过 agentic 工作流下 8 T/s 的首 token 要等两三分钟；发帖人的回应是 Flash-Next 过度思考少、同一个任务的反覆次数比 Qwen3.8-27B / Qwen3.6-35B A3B 少得多，单看 T/s 慢，看任务总时长反而快。这套配置适合能接受慢速生成、但需要大上下文喂代码库的场景，追求交互速度的人不适合。
评论区给出的另一条路：Strata 引擎
官方模型卡自己就推荐了第三方引擎 Strata（8GB 单卡、一键安装、OpenAI 兼容端点）。评论区有 RTX 5060 8GB + 32GB 内存的用户报告：跑同家族的 Gyro S 量化版（三元量化，TQ1 档约等于 Q3 质量）拿到约 800 T/s 预填充、35 T/s 生成，262K 上下文满开——原因是 Strata 会把「热」专家激进缓存进显存，多轮运行后命中率越高速度越快。发帖人复测截图在 739 T/s PP / 39 T/s TG，并预期 Strata 支持 Gyro Coder（同样的半专家剪枝思路）后缓存命中还会更高。llama.cpp 路线的价值在于可微调、可复现、不依赖特定引擎；Strata 路线快但黑盒程度高，两条路目前都只能选一边。
参考链接
- Reddit 原帖：8 GB GPU, 262K context 3.5 BPW Qwen-Flash-Next Coder 70 T/s using llama.cpp（2026-10-24）— https://www.reddit.com/r/LocalLLaMA/comments/1xebdzl/8_gb_gpu_262k_context_35_bpw_qwenflashnext_coder/
- ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF 官方模型卡（体积、基准、方法说明）— https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-Coder-GGUF
- GSQ 论文（arXiv:2604.18556）与 RCO 论文（arXiv:2605.00649），见模型卡引用节