8 GB 显卡、262K 上下文、3.5 BPW 的 Qwen-Flash-Next Coder，用 llama.cpp 达到 70 T/s
8 GB GPU, 262K context 3.5 BPW Qwen-Flash-Next Coder 70 T/s using llama.cpp
r/LocalLLaMA 的一篇社区帖子。作者介绍其做法：Qwen-Flash-Next 有 n-gram 和 MOE，激活参数为 6B，因此把大部分 MOE 放在内存、最小的 MOE 放进显存以提速、n-gram 放在最快的 SSD 上；配置为 8 GB 显存加 24 GB 内存，约 32 GB 总内存也能运行但需降低上下文长度，并需按硬件调整启动参数。帖子补充说明 CUDA 在 8 GB 显存下可能跑不起来，建议改用 Vulkan 后端，同时减小上下文并关闭浏览器硬件加速等占用显存的程序。作者还说明所用模型是 ISTA DASLab 的 3.5 BPW “Coder”变体、采用 GSQ RCO 量化，移除了一半专家，折算为原模型参数量的 1.89 比特有效速率，但没有任何单个权重以 1.89 比特存储。适合用 llama.cpp 在低显存消费级硬件上部署量化 MoE 模型的人阅读。
- 分级
- 值得看
- 收录时间
- 2026-10-26
原帖
We exploit this by keeping most MOEs in RAM (Smallest MOEs go in VRAM for speedup) and n-gram on disk - ensure you put the model on your fastest SSD. 8 GB VRAM, 24 GB RAM cost.
中文大意
发帖人 jonathanx37 在 8 GB 显存 + 24 GB 内存（约 32 GB 总内存也行，但需减小上下文）下用 llama.cpp 跑 ISTA DASLab 的 Qwen-Flash-Next "Coder" 3.5 BPW GSQ RCO 量化模型（砍掉一半专家，相对原模型相当于 1.89 bit，实际权重为 3.5 bpw，非 1 bit 量化），实现 262K 上下文、约 70 T/s 提示处理、8 T/s 生成（受 PCIe 3.0 限制）。做法：大部分 MoE 放内存、最小的放显存，ngram 放磁盘（需最快 SSD），用正则 -ot 选择性 offload 专家、--load-mode none 替代 mmap（PP 从 ~70 提升到 ~104 t/s），使用 qwen sharp chat template 减少过度思考；8 GB 卡跑不动时改用 Vulka…
讨论区核心观点
依据 40 条评论
- 围绕温度参数的争论：有人指出 0.6 不符合官方推荐的 instruct/thinking 参数，'过度思考'只是被跟风传播的流行词；发帖人回应自己实测低温和 qwen sharp 模板对编码更有效，双方各执一词。 出处（新标签页打开）
- 不少人对能否在 8 GB 显存跑出这样的速度存疑，有人实测 32 GB 内存 + Vulkan + 32K 上下文只有 5-10 tok/s 且经常中断；发帖人认为是上下文上限或 harness 问题，并建议减小 KV cache 位宽、监控显存占用。 出处（新标签页打开）
- 关于量化质量：有人试用后认为量化模型很笨、连简单 HTML 都写不对；发帖人强调实际是 3.5 bpw，只相当于原模型 IQ1_M 的体积，大模型量化损失较小，并称其长上下文任务曾成功完成。 出处（新标签页打开）
- 多人提到 Strata + Gyro 方案在同等硬件上快得多（约 800 t/s PP、35 t/s TG、满 262K 上下文），归因于更激进的 hot MoE 缓存；发帖人认为等 Strata 支持 Gyro Coder 会更好。 出处（新标签页打开）
- 为何仍用 llama.cpp 而非 Strata：兼容性好（支持 Vulkan、老卡也能跑）、长期维护有保障、方便作为速度对比基准；Strata 模型选择有限且偏新架构。 出处（新标签页打开）
- 有人建议用 --dry-multiplier 替代 repeat/presence penalty，以免人为限制模型思考；发帖人称这些参数只是防止小模型/量化模型陷入重复思考的预防措施。 出处（新标签页打开）