测试日期：2026-08-31
后端：Unsloth Studio + llama.cpp
模型：unsloth/Qwen3.8-Flash-Next-GGUF，UD-Q4_K_XL
主要硬件：RTX PRO 5000 Blackwell 48GB + Ryzen 7 9700X + 128GB DDR5-3600（4×32GB）
先说结论
折腾了一天以后，我对这个模型的看法比刚下载时乐观不少。
Qwen3.8-Flash-Next UD-Q4_K_XL 下载体积大约 111GB，在 48GB 显存 + 128GB 内存的机器上可以正常加载，第一次加载大约 80 秒。纯文本时，64K 和 128K context 下的生成速度基本都能维持在 30 tok/s 左右。这个速度谈不上快，但实际聊天和分析任务已经能用了。
真正拖体验的是 prefill。多数文本任务大约只有 230～250 tok/s，长对话或视觉配置下还会继续往下掉。这个模型有很大一部分权重需要放在系统内存里，所以内存带宽和 llama.cpp 对新架构的优化都会直接影响体感。
视觉是另一个明显短板。Studio 默认给我用了 --no-mmproj-offload，三张截图跑了 20 多分钟还没出结果，最后被 Studio 终止。手动改成 --mmproj-offload 后，同类任务能在 5～6 分钟内完成，但文本生成速度会从 30 tok/s 左右降到 24～28 tok/s。
模型能力方面，Flash-Next 给我的感觉是：推理上限比 Qwen3.8-27B 高，自我检查和反思也更强，但它还不够“稳”。有几次它能做出很漂亮的推导，却把一个合理猜测说成已经确认的事实。相比之下，27B 没这么爱往外扩，做 Agent 时反而更让人放心。
目录
- 测试环境
- 111GB 模型为什么看起来只用了几 GB 内存
- 64K 和 128K 下的文本速度
- 10 道测试题和自我纠错
- 几轮对话里暴露出来的问题
- MTP 为什么一直没有真正启用
- 视觉：默认 CPU 路径太慢，GPU offload 才能用
- Prefill 偏低，换 DDR5-5600 有没有意义
- 和 Qwen3.8-27B 的实际对比
- 写在最后
1. 测试环境
硬件：
- CPU：AMD Ryzen 7 9700X，8C16T
- 内存：128GB，4×32GB DDR5-5600，目前为了稳定运行在 DDR5-3600
- GPU：NVIDIA RTX PRO 5000 Blackwell 48GB
- 系统：Ubuntu 24.04
软件：
- Unsloth Studio：2026.8.x
- llama.cpp：Unsloth 当前调用的版本约 b10639
- CUDA 后端
- 我是在 Mac 上通过浏览器打开 Ubuntu 上的 Unsloth Studio
模型：
unsloth/Qwen3.8-Flash-Next-GGUF
UD-Q4_K_XL
总下载体积约 111GB
第一次在 Studio 里加载大约 80 秒。界面会直接提示模型超过显存容量，部分层会放到系统 RAM。
2. 111GB 模型为什么看起来只用了几 GB 内存
这是我一开始最困惑的地方。
模型加载前后，我看了一下 free -h：
加载前：
Mem: 123Gi total, 15Gi used, 92Gi buff/cache, 108Gi available
Swap: 8Gi total, 0 used
加载后：
Mem: 123Gi total, 7.1～8.6Gi used, 115～116Gi buff/cache, 114～116Gi available
Swap: 8Gi total, 2.7～2.8Gi used
乍一看很奇怪：模型明明 111GB，为什么 used 反而只有 7～9GB？
后来直接看 llama-server 进程就比较清楚了：
VmRSS: 63,959,868 kB
RssAnon: 2,268,348 kB
RssFile: 61,188,636 kB
VmSwap: 122,460 kB
同时 NVIDIA 这边：
llama-server GPU memory: 47,038 MiB
大致换算一下：
GPU VRAM ≈ 45.9 GiB
File-backed RAM ≈ 58.3 GiB
合计 ≈ 104.2 GiB
这个数字和 111GB 十进制的模型文件换成 GiB，再加上 mmproj 后基本能对上。
也就是说，模型并不是在普通匿名内存里再完整复制一份。GGUF 大量通过 mmap 映射，CPU 侧的那一大块主要体现在 RssFile 和 Linux 的 page cache 里，所以 free -h 的 used 看起来很低，buff/cache 却非常大。
我又跑了 vmstat 1。实际推理时 wa 基本为 0，so 也基本为 0，磁盘读取多数只是 KB/s 到少量 MB/s，没有持续从 NVMe 大量拉权重，也没有明显的 swap thrashing。
所以至少在这次测试里，正常生成阶段可以理解成：一部分权重常驻显存，另一部分主要在系统内存的 mmap/page cache 里。SSD 不是持续推理的主要瓶颈。
3. 64K 和 128K 下的文本速度
64K，Parallel=1
我用论坛里之前那套 10 道测试题跑了一轮，Studio 给出的数据是：
Prompt eval 6.45 s
Prompt speed 232.1 tok/s
Generation 335.79 s
Speed 31.2 tok/s
Tokens 10,480
Total 421.42 s
后面又跑了几轮不同任务，纯文本时基本都在这个范围：
Prompt speed 230～254 tok/s
Decode speed 30～31 tok/s
30 tok/s 我自己是能接受的。真正让人等得比较明显的是 prefill，尤其上下文越来越长以后，首 token 等待时间会比较明显。
128K
后来把 context 拉到 128K，显存占用仍然在 95%～97% 左右，生成速度没有明显掉下去：
Prompt speed ≈ 243.6 tok/s
Decode speed ≈ 30.6 tok/s
这点比我预想得好。context 翻倍以后，显存并没有跟着大幅增加。比较合理的解释是 Studio/llama.cpp 会重新做 placement：KV 和工作区需要更多显存，就少放一点模型 tensor 到 GPU，让更多权重留在 RAM 里。
从结果看，128K 对 decode 的影响不大，至少我这几轮没有看到从 30 tok/s 掉到十几 tok/s 这种情况。不过这也意味着系统对 RAM 侧访问的依赖更重了。
4. 10 道测试题和自我纠错
我用的是之前论坛里那套 10 道题，内容包括精确算术、日期推理、逻辑题、中文歧义、C++ 并发、数论、RAID 误导题、速率建模、贝叶斯以及一道人为设置的抗幻觉题。
按原来的判分点，Flash-Next 10 道都过了。几个我比较在意的点也都答对了：
- C++ DCLP 能指出 data race、UB 和 acquire/release；
- 贝叶斯那题给出约 1.94%；
DeltaFormer-X 那题没有顺着题干去编所谓“三大创新”。
问题出在它主动多写的部分。
它第一次给自己打了 98/100，但复核后发现：RAID 那题的 UBER 数量级一开始算错；池子那题主答案 3 小时没问题，但它自己扩展 Torricelli 模型时建错了方程；贝叶斯主答案没错，但又多写了一个“三次阳性约 86%”，正确值应该接近 88.6%；另外还有负整数证明和中文切分上的小瑕疵。
我把这些问题再发给它，它重新算了一遍，最后把自己的分数降到 94.5。它不是简单认错，而是能继续往回追，找出自己到底在哪一步出了问题。这一点我觉得比“10/10 全对”本身更有意思。
但这里也能看出它的一个特点：它很愿意反思，不代表第二次就一定能算对。它第一次自评时已经在“检查自己”，可还是漏掉了 A8 和 A9 里自己额外加出来的错误。
5. 几轮对话里暴露出来的问题
后面我没有继续做封闭题，而是让它直接分析 Unsloth Studio 的截图和前面几轮的运行数据。这个阶段反而更能看出模型做真实 Agent 时可能有什么问题。
5.1 把 Mac 客户端当成了推理主机
截图是在 Mac 的 Chrome 里打开的，但真正跑模型的是 Ubuntu 主机上的 RTX PRO 5000。
它有一轮看到 Mac 菜单栏以后，直接按“Apple Silicon 统一内存跑大模型”去解释性能。这显然是把浏览器在哪台机器上，和模型真正在哪台机器上运行混到一起了。
实际链路是 Mac 浏览器通过端口转发访问 Ubuntu 上的 Unsloth Studio，推理发生在 Ubuntu + RTX PRO 5000 上。
这类错误对 Agent 比数学题算错更麻烦。因为如果连客户端、服务器、实际执行环境都分不清，后面判断文件路径、GPU、Shell 命令时就有可能出问题。
5.2 被纠错以后又有点过头
在前面几轮被指出“不要从一个事实顺着推下一个事实”以后，它又变得很保守，一度拒绝承认自己就是当前加载的 Flash-Next。
模型当然没法靠“内省”知道自己的营销名称，这没问题。但当外部启动命令已经明确写着：
-m .../Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf
那就没必要继续说“我不能确认这是不是我”。更合理的说法应该是：我自己不能内省型号，但从当前运行环境可以确认这次回复就是由这个 GGUF 生成的。
也就是说，它不是单纯容易乱猜，有时被纠错以后还会往另一个方向用力过猛。
5.3 很会解释，但容易把解释说得太确定
它看 Studio 的性能浮窗时做了不少反推，例如：
Prompt eval × Prompt speed 大致可以估算 prompt token 数；Chunks 大约是 Tokens 的两倍；Total - Prompt - Generation 多出来大约 90 秒。
第一条拿来做数量级检查没什么问题。后两条它就走得有点远了，直接解释成“每个 token 大约两个 SSE chunk”和“那 90 秒就是模型加载时间”。
后来再看 Studio 的实现，能发现这些字段本来就不是全都来自同一套计时：Prompt eval / Prompt speed / Generation / Speed 是 server timing，Tokens / First token / Total / Chunks 是前端 message timing。既然口径不同，就不能简单拿几个数字相减以后直接认定原因。
这种情况在 Flash-Next 上我碰到不止一次：它给出的解释经常很像那么回事，逻辑也顺，但“很可能是这样”和“已经证实就是这样”之间的边界不够稳。
5.4 参数规模也出现过类似问题
它还根据 Q8 文件大小反推过一次总权重规模，然后说这和“125B”标称对不上。问题是它没有把主模型、n-gram embedding、MTP 这些不同部分放到一起算，局部数字都看到了，最后整合时漏了一块。
这类错误不太像传统意义上的“胡编”。更像是模型很会做局部推理，但跨几段信息整合时偶尔会漏条件，然后把一个看起来非常完整的解释说得太肯定。
这也是我目前对 Flash-Next 最担心的地方。不是它不会推理，而是它的推理能力长得比“证据到底够不够”这件事更快。
6. MTP 为什么一直没有真正启用
我在 64K、128K 下都试过 Studio 的 MTP/Auto 设置，但 unsloth-runtime-check 一直显示：
[MTP]
Enabled: no
Type: n/a
Auto 模式下实际启动参数看到的是：
--fit on
--spec-default
而不是：
--spec-type draft-mtp
从现在的运行结果看，我也没有特别想强行把 MTP 打开。这个 Q4_K_XL 本身就远超 48GB 显存，必须 partial offload。MTP 还要额外占用 draft/rollback 相关资源，如果最后为了开 MTP 又把更多主模型权重挤到 RAM 里，未必能得到正收益。
更实际的一点是：MTP 没开，现在纯文本已经能稳定在 30 tok/s 左右。对我来说这个速度已经过了“能不能用”的门槛，所以暂时没必要为了多几 tok/s 把当前 placement 搞得更复杂。
7. 视觉：默认 CPU 路径太慢，GPU offload 才能用
这部分差距非常明显。
最开始让 Flash-Next 分析三张截图时，Studio 的启动参数里是：
--mmproj .../mmproj-F16.gguf
--no-mmproj-offload
跑起来以后，最开始 NVIDIA 功耗大概 140～160W，CPU 大约 70W。过一阵 GPU 掉到 20W 左右，CPU 反而升到 137W 左右。然后就一直等，20 多分钟都没有结果，最后 Studio 把任务终止了。
这个表现基本说明视觉这段主要落到了 CPU 上。9700X 跑这种 F16 vision workload 实在太慢，实际没法用。
后来我明确加了：
--mmproj-offload
同时把 KV cache 设成 q8_0，再跑同类三图任务，5～6 分钟左右能出结果。虽然还是不算快，但至少从“不可用”变成了“能用”。
代价也很直接，后续连续回复的文本速度降到大约：
Prompt speed 174～242 tok/s
Decode speed 24～28 tok/s
下面几张就是打开 GPU mmproj 以后连续几轮的速度。
48GB 显存在跑 111GB 模型时本来就非常紧，视觉编码器再搬到 GPU，肯定要挤占模型或缓存的空间，所以文本速度会掉一些。
8. Prefill 偏低，换 DDR5-5600 有没有意义
目前最影响我体感的不是 decode，而是 prefill。
纯文本常见大约：
230～250 tok/s
视觉、长对话或者 placement 更重时会掉到：
170～220 tok/s
我现在这套 4×32GB 内存虽然标称 DDR5-5600，但四条插满以后为了稳定只能跑在 DDR5-3600。双通道理论带宽大约是：
3600 MT/s × 8 bytes × 2 channels = 57.6 GB/s
如果换成 2×64GB DDR5-5600，理论带宽是：
5600 MT/s × 8 bytes × 2 channels = 89.6 GB/s
理论上高了 55% 左右，但因为现在的瓶颈不只有内存，还包括 GPU/CPU 两边的计算、offload、调度以及llama.cpp 对这个新架构本身的优化程度，估计prefill 不会跟着涨 55%。
不过 Flash-Next 和 27B 不一样。27B Q6 基本能放进 GPU，而Flash-Next 现在实测有大约 58GiB 权重长期在 RAM 侧，因此系统内存带宽提升应该能带来实打实的性能提升。
如果最后确认 Flash-Next 会长期留下来，我会考虑把 4×32GB DDR5-3600 换成 2×64GB DDR5-5600。预期prefill大概从现在的 230～250 tok/s 提高到 260～320 tok/s 这一档，但这只是估计，真正能涨多少还是要换完以后实测。
另外，我觉得软件优化的潜力可能比换内存还大。Flash-Next 架构很新，llama.cpp 后面如果继续补专用 kernel，prefill 还有可能明显改善。
9. 和 Qwen3.8-27B 的实际对比
不能像官方公布的数据那样简单说 Flash-Next “全面强于” 27B。两者更像是不同取向。
| 项目 |
Qwen3.8-27B |
Qwen3.8-Flash-Next |
| 基础推理 |
强 |
更强一些 |
| 复杂分析 |
比较稳 |
上限更高 |
| 自我纠错 |
有 |
明显更强 |
| 证据边界 |
相对稳 |
容易把推测说得太确定 |
| 回答风格 |
更收敛 |
更爱继续往下推 |
| Agent 执行 |
目前更放心 |
还要继续观察 |
| Vision |
GPU mmproj 已比较成熟 |
48GB 下需要明显取舍 |
| RTX PRO 5000 生成速度 |
27B Q6 约 85～89 tok/s |
纯文本约 30～31 tok/s，视觉配置约 24～28 tok/s |
| 显存/内存压力 |
基本可全 GPU |
必须大量 RAM offload |
| 目前成熟度 |
高 |
还在快速变化 |
我觉得两者最大的差别不是“谁更聪明”，而是做事风格。
27B 比较像一个已经比较成熟的工具，知道多少说多少，速度快，也没那么爱往外展开。Flash-Next 更喜欢继续推理、找矛盾、自己反驳自己，这种能力在复杂问题上很有价值，但它自己多出来的那些推导，也会带来新的错误机会。
10. 写在最后
总的来说，这次测试让我确认了一件事：这个 111GB 的 Q4_K_XL 不是“只能勉强启动”。在 48GB 显存 + 128GB 内存的机器上，它已经能达到可以正常交互的速度。但我也不觉得现在就到了把Qwen3.8-27B 删掉的时候。Flash-Next 代表了一个新的技术方向，但是还远未到成熟的时候。
「ComfyUI基础工作流」
「ComfyUI进阶工作流」
）。出门了就用Windows笔记本远程登录到Mac上，拿Mac mini当一个跳板机（功耗超低，24小时开机）。
