Qwen3.8-Flash-Next 本地部署亲测：8G 显卡到底能不能跑？

摘要：本文记录作者在 8G 显存单机（RTX 3070 + 64G 内存 + NVMe）上跑通 117B 剪枝版 Qwen3.8-Flash-Next 的实测过程。通过剪枝、量化与 llama.cpp 新版 lazy-mode 三招，62GB 模型得以在 64G 内存机器上按需加载运行；实测纯内存跑（-ngl 0）反而比塞显卡更快。文章重点剖析了开深度思考时约三分之一概率"装死"的坑，并给出求稳与求质两条绕坑路线，最后附硬件清单、内存占用与实测小结。

我的 8G 显存单机把 117B 剪枝版跑起来了，但有个坑

文章定位：普通人落地大模型实测。本文只讲"跑通 + 轻度测试 + 坑"，系统跑分见下篇。

Qwen3.8-Flash-Next 开源第一天我就盯上了。

那阵子前面有开源的新闻分析文章，也有不少人做及时的全网检索，专门找"最低什么硬件能跑通"。上一批最低硬件跑通的方案集中在 Mac 系列——巧了，我没有 Mac。但也就是那批文章，我第一次知道了"剪枝"这个神奇的玩法：原来大模型不一定非要原样搬，砍掉一半专家也能跑。

所以之后我一直没放下，持续盯着。

直到今天，我看到 llama.cpp 做了个关键适配——把 Qwen3.8-Flash-Next 那张 51B 的表（官方叫 PLE 表）丢到 SSD 上按需读，不再死占内存。哈哈，我的机会来了。

第一时间把权重和 llama.cpp 新版本下下来，跑起来。

这篇文章我想回答就三件事：我这台破机器到底能不能跑起来？轻度测下来到底是什么效果？中间有哪些坑？

你要是想自己玩一把，能不能直接抄我作业？或者你只是想搞清楚 Qwen3.8-Flash-Next 本地部署到底怎么回事——那恭喜，来对了，亲测结果新鲜出炉。

一、先交底：我到底跑了个什么

我的机器：RTX 3070（8G 显存）+ 64G 内存 + NVMe 固态，llama.cpp b10731（CUDA 12.4）。

模型：AnonimousA 出的 Qwen3.8-Flash-Next-REAP-256-duo GGUF，量化档 Q3_K_XL，两分片共 62GB，标称 117B 总参。它从一个更大的 Qwen3.8-Flash-Next 底座（官方说是 176B 级别）压下来，靠两招：剪掉一半专家（512 留 256），再把权重压到 3bit 出头。

62GB 还是比 64G 内存大。真正让它塞得进来的，就是开头说的那张 51B 的 PLE 表——llama.cpp 新版 lazy-mode 让它不常驻内存，按需从 NVMe 读。剪枝 + 量化解决"文件多大"，lazy-mode 解决"内存够不够"，NVMe 解决"读得动不"。三样齐了，我这台机器才接得住。

二、跑通：比想象中顺，除了一个反直觉

跑通本身没几步，但有个前提：我机器上原来的 llama.cpp 是 b10166，太旧，既不认这个模型架构，也没有 lazy-mode，必须先升到 b10731。升完就顺了。

GGUF 是分片的（48G + 14G 两片），不用合并，启动命令指第一个分片，llama.cpp 自己读后续。启动后约 6 秒加载完，控制台打出 listening，浏览器开 http://localhost:8080 就能聊。

速度我实测了两组，反直觉：

• 纯靠内存跑（-ngl 0）：4.85 ~ 6.03 token/秒
• 往显卡塞 8 层（-ngl 8）：4.60 ~ 4.70 token/秒

按常识塞显卡应该更快，实测反而更慢。原因是 3070 只有 8G，塞几层后专家权重要在 PCIe 上来回搬，把显卡那点收益全吃光了，还挤占显存。这台机器，不往显卡塞反而快。

验证过的启动命令（关思考、求稳版）：

llama-server.exe ^
-m "模型路径/Qwen3.8-Flash-Next-UD-Q3_K_XL-reap256-00001-of-00002.gguf" ^
-ngl 0 –jinja –reasoning off ^
-c 16384 –lazy-mode auto ^
–host 0.0.0.0 –port 8080 ^
–temp 0.6 –top-p 0.95 –top-k 20 –min-p 0.0 ^
–presence-penalty 1.0 ^
–dry-multiplier 0.8 –dry-base 1.75 –dry-allowed-length 2

–reasoning off 是关深度思考；想开思考就把这句删掉，后面解释为什么。

三、那个坑：它有三分之一概率"装死"

跑通不等于好用。我拿它问"写篇 300 字春色散文"，三种反应：

我第一反应是：量化烂？启动脚本参数没调对？还是客户端（Cherry Studio）的 Agent 参数背锅？

没拍脑袋，做了三轮对照实测。

第一轮，看日志猜"是漏了 presence-penalty（防重复惩罚）"。这参数官方明说能压重复，我们脚本没设。改上。结果——还是翻车。光加 presence 没用。

第二轮，绕开客户端用 llama-cli 直接测，发现"开着深度思考必死"：模型在思考过程里自己写 I'm stuck（我卡住了），把 900 个 token 全耗在内心独白，正文一个字没有。我据此判"思考模式是元凶"。

第三轮，起 llama-server 走真实 HTTP 请求（模拟客户端），同一套参数、同一道题，开思考——它居然写出了整篇，而且是我见过质量最高的一篇 343 字散文，有远景有近景有收尾。比如它写春色，落笔是"春色的初醒，非全，非盛，似为春之初句"——这种收束感，关思考的版本给不出来。

三轮下来，真相才清楚：

"装死"不是必死，是概率。开着深度思考时，模型约三次里有一次会在思考里打转，把 token 烧光，最后给你空回复。不是它拒绝答，是它把自己绕晕了。

而采样参数（presence-penalty + DRY）不是主犯，是"刹车片"：

• presence 罚"出现过的词"，但循环是"若X若X"——字在换、结构在重复，presence 罚了个寂寞；
• DRY 查"重复模式"，但漏"退步退步"这种整词重复。

两个必须叠着用，各补对方盲区。没有它必翻车，有它也压不到零。

把我实测日志里的原样贴一段，感受下"循环"长什么样：

• 只加 presence 时的循环：若微若淡若青若黄若灰若白…若真点若假点若实
• 只加 DRY 时的循环：退步，退步。退步：退步。退步退步退退退退退退
• 开思考卡死时，模型自己在思考里写：I'm stuck / Let's craft（反复重写同一句开头）

第一种每个字都是新的，presence 罚不到；第二种整词重复，DRY 漏了。所以两个都得留。

还有个隐蔽坑：客户端会覆盖服务端。我在脚本里关了思考，结果 Cherry Studio 请求里带了"开深度思考"，服务端设置直接被无视。想关思考，客户端开关也得关；想开，两端都得开。

说句公道话：这模型底子本来就不厚。量化作者 bartowski 给 Q3_K_XL 这档的评价就是"较低但可用"；REAP 论文自己也承认剪枝后"多样性略降"。所以"重复"不全是参数的锅，3bit + 剪一半专家，先天就更爱说车轱辘话。参数只是把这天性按住。

四、怎么绕：稳和质，你挑

实测结论落到操作上，就两条路：

A. 求稳（脚本默认）：关思考。永不翻车，代价是回答偏短偏平，复杂推理弱。普通聊天、写写小段落够用。

B. 求质：开思考 + 留着惩罚参数。质量明显更高，代价是约三分之一概率空回复。处理办法粗暴有效：看到空的，再问一次，通常第二次就正常。

切换方法：脚本里删掉 –reasoning off 那句，同时客户端打开"深度思考"开关——只改一边没用，客户端会覆盖。

我现在的用法：日常关思考图省心；真要它写点像样的，开思考，空了就重问。一分钱不花，多按一次回车而已。

最后：硬件交底及复盘

1）我的硬件清单

• 显卡：RTX 3070，8G 显存
• 内存：64G DDR5
• 硬盘：NVMe 固态（机械盘不行，51B 的表要按需读盘，机械盘会卡死）
• 软件：llama.cpp b10731（CUDA 12.4）

2）内存占用（实测观察）

最重度测试时，内存占用大概在 80% 左右（64G 里吃了约 51G，主要是模型加那张表）；平时我机器内存占用在 20%~30% 徘徊，跑起来后峰值也就到这个水平。64G 是够的，还有余量。

3）有没有必要

说实话，从速度和轻度测试的效果看，它只能算个玩具——而且是被砍了一刀的玩具。单字速度每秒五六个 token，复杂活干不了，质量上限也不如原版。

你要是问我"同样这台机器，跑它还是跑 Qwen3.8-27B 的 Q4 版更有生产力"，我倾向于后者：27B Q4 体量小、跑得轻松、质量更齐整，这台 117B 剪枝版在生产力上可能还不如它。

当然，本地跑的好处也在：数据不出门、不花 API 钱、断网也能用。只是论"干活"，它目前就是个能跑的玩具。下一篇我把它和 27B 同机拉出来比一比，看是不是真不如。

一句话结尾（可截图）：8G 显卡跑 117B，能跑——但先知道坑在哪，也先想清楚你图啥。

实测小结

数据来源与口径

• 速度、加载、空回复机制、内存占用：本人 2026-09-01 至 09-02 在本机实测（llama.cpp b10731，RTX 3070 8G + 64G，REAP-256 Q3_K_XL 62GB），原始日志在 D:\\llamaB10731\\logs\\。
• "约三分之一空回复"基于 3 个样本，为粗略估计，非统计结论，下篇补多点采样。
• 内存占用为实测观察值（峰值 ~80% / 空闲 ~20-30%），非架构推算。
• 模型架构 / lazy-mode / 量化档信息来自 llama.cpp b10731 release notes 与模型仓库说明；bartowski 量化评级、REAP 论文"多样性略降"表述均引自原文档。

更多实测信息、免费API、AI相关教程等等首发同名gzh，感兴趣可以关注。