测试日期：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 时反而更让人放心。

目录

1. 测试环境
2. 111GB 模型为什么看起来只用了几 GB 内存
3. 64K 和 128K 下的文本速度
4. 10 道测试题和自我纠错
5. 几轮对话里暴露出来的问题
6. MTP 为什么一直没有真正启用
7. 视觉：默认 CPU 路径太慢，GPU offload 才能用
8. Prefill 偏低，换 DDR5-5600 有没有意义
9. 和 Qwen3.8-27B 的实际对比
10. 写在最后

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。两者更像是不同取向。

我觉得两者最大的差别不是“谁更聪明”，而是做事风格。

27B 比较像一个已经比较成熟的工具，知道多少说多少，速度快，也没那么爱往外展开。Flash-Next 更喜欢继续推理、找矛盾、自己反驳自己，这种能力在复杂问题上很有价值，但它自己多出来的那些推导，也会带来新的错误机会。

10. 写在最后

总的来说，这次测试让我确认了一件事：这个 111GB 的 Q4_K_XL 不是“只能勉强启动”。在 48GB 显存 + 128GB 内存的机器上，它已经能达到可以正常交互的速度。但我也不觉得现在就到了把Qwen3.8-27B 删掉的时候。Flash-Next 代表了一个新的技术方向，但是还远未到成熟的时候。