# 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
- 类型：帖子
- 来源：Reddit
- 发布时间：2026-10-24
- 首次精选：2026-10-26 15:47
- 分级：值得看
- 学习层级：进阶
- 主题：[inference-hardware-memory](<https://oplearnx.com/md/topics/inference-hardware-memory.md>)（第 4 位）、[model-quantization](<https://oplearnx.com/md/topics/model-quantization.md>)（第 4 位）、[local-model-deployment](<https://oplearnx.com/md/topics/local-model-deployment.md>)（第 12 位）
- 原文链接：[https://reddit.com/r/LocalLLaMA/comments/1xebdzl/8\_gb\_gpu\_262k\_context\_35\_bpw\_qwenflashnext\_coder](<https://reddit.com/r/LocalLLaMA/comments/1xebdzl/8_gb_gpu_262k_context_35_bpw_qwenflashnext_coder>)
- 本站页面：[https://oplearnx.com/resources/pk\_4fcc8532917f](<https://oplearnx.com/resources/pk_4fcc8532917f>)

## 摘要

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 模型的人阅读。

## 原帖

> 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 · 2026-10-24 · [原帖](<https://reddit.com/r/LocalLLaMA/comments/1xebdzl/8_gb_gpu_262k_context_35_bpw_qwenflashnext_coder>)

## 中文大意

发帖人 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 模板对编码更有效，双方各执一词。（[出处](<https://www.reddit.com/r/LocalLLaMA/comments/1xebdzl/8_gb_gpu_262k_context_35_bpw_qwenflashnext_coder/19rldtiymydsy/>)）
- 不少人对能否在 8 GB 显存跑出这样的速度存疑，有人实测 32 GB 内存 \+ Vulkan \+ 32K 上下文只有 5-10 tok/s 且经常中断；发帖人认为是上下文上限或 harness 问题，并建议减小 KV cache 位宽、监控显存占用。（[出处](<https://www.reddit.com/r/LocalLLaMA/comments/1xebdzl/8_gb_gpu_262k_context_35_bpw_qwenflashnext_coder/19rtrzyk6qp9h/>)）
- 关于量化质量：有人试用后认为量化模型很笨、连简单 HTML 都写不对；发帖人强调实际是 3.5 bpw，只相当于原模型 IQ1\_M 的体积，大模型量化损失较小，并称其长上下文任务曾成功完成。（[出处](<https://www.reddit.com/r/LocalLLaMA/comments/1xebdzl/8_gb_gpu_262k_context_35_bpw_qwenflashnext_coder/19rtss0sbnc6d/>)）
- 多人提到 Strata \+ Gyro 方案在同等硬件上快得多（约 800 t/s PP、35 t/s TG、满 262K 上下文），归因于更激进的 hot MoE 缓存；发帖人认为等 Strata 支持 Gyro Coder 会更好。（[出处](<https://www.reddit.com/r/LocalLLaMA/comments/1xebdzl/8_gb_gpu_262k_context_35_bpw_qwenflashnext_coder/19rlm0f63f68y/>)）
- 为何仍用 llama.cpp 而非 Strata：兼容性好（支持 Vulkan、老卡也能跑）、长期维护有保障、方便作为速度对比基准；Strata 模型选择有限且偏新架构。（[出处](<https://www.reddit.com/r/LocalLLaMA/comments/1xebdzl/8_gb_gpu_262k_context_35_bpw_qwenflashnext_coder/19rlnjxytx7c2/>)）
- 有人建议用 --dry-multiplier 替代 repeat/presence penalty，以免人为限制模型思考；发帖人称这些参数只是防止小模型/量化模型陷入重复思考的预防措施。（[出处](<https://www.reddit.com/r/LocalLLaMA/comments/1xebdzl/8_gb_gpu_262k_context_35_bpw_qwenflashnext_coder/19rlcn8x4j1wl/>)）

## 原文涉及

- [GitHub - ggml-org/llama.cpp: LLM inference in C/C\+\+](<https://github.com/ggerganov/llama.cpp>)

---
来源：LearnMap · 学径（https://oplearnx.com）
