周六下午R9700到货，开始组装机器，快10年没装机了，偏这次又买了小机箱（有点后悔），结果弄到夜里快12点才装好，腰酸背痛，装完点亮了，就睡了。转天起来开始装Ubuntu 24.04.4，系统竟然也装了一上午，开始时安装程序反复退出，后来刷了最新的BIOS，没想到重启之后竟然直接进系统了。然后就是更新系统，安装ROCM等等一系列。然后安装Hermes，使用deepseek-v4-flash，在Hermes辅助下安装llama.cpp。特意告诉Hermes要浏览抡锤者论坛中关于AMD显卡的帖子，特别要参考
https://lcz.me/topic/353/7900-xtx-qwen3.6-27b-ubuntu-rocm-vulkan-mtp-64-128-256k-全部實測整理
和
https://lcz.me/topic/100/7900xtx-llama.cpp-qwen3.6-27b-turboquant-mtp-测试结果分享/56
这两个帖子的内容。在此感谢 CHIA AN YANG 和 David Zhang 两位大神，也特别感谢斑竹建立了这个论坛让我学到了很多知识。
最后选定Qwen3.6-27B-Q4_K_M.gguf，使用Hermes自动配置，一次成功！

   硬件配置：
   主板：MaxSun-Terminator-B850M-PRO
   CPU：AMD Ryzen 7 9700X
   内存：金邦DDR5 5600 64GB
   SSD:  宏基GM7000 1TB+金邦 2TB
   显卡：AMD Radeon AI PRO R9700
   电源：Thermaltake SFX-850
   机箱：机械大师C26

   运行参数：/data/ai/apps/llama.cpp/build/bin/llama-server \
         -m /data/ai/models/llm/Qwen3.6-27B-Q4_K_M.gguf \
         -ngl 99 \
         -fa 1 \
         -c 131072 \
         --cache-type-k q4_0 \
         --cache-type-v q4_0 \
         --spec-type draft-mtp \
         --spec-draft-n-max 3 \
         -ub 256 \
         -np 1 \
         --temp 0.7 \
         --top-k 20 \

使用起来感觉和线上的deepseek-v4-flash没有太大区别，速度差不多。但是运行起来的风扇噪音真是太大了！但是比起电水壶烧开水还是差远了。我把电脑放脚下，身后就是电水壶，水烧起来的声音完全能盖住显卡风扇的声音，满载时也能。但是机箱散热不好，测试时显卡温度偏高。

调整了一下机箱风扇的位置，效果并不明显。小机箱空间太受限了！装机时就很费劲！

为了安全，把功耗限制到280W。

性能损耗约4%。

后来感觉温度还是偏高，风扇太吵，又限制到270W。

这是现在模型刚加载时的温度：

这是模型运行时的温度：

心得：
1、AMD显卡在Linux下的生态还是可以的，至少我这个没有什么Linux使用经验的人，在AI和Hermes的帮助下，也就是花了1天时间就把大模型跑起来了，所以对AMD显卡有顾虑的人我觉得可以放心一些了。
2、涡轮卡的噪音确实是很大，但是比电水壶的声音还是差一些，隔一堵墙，关上门，满载时的噪音也是听不见的。算是给对噪音敏感的人一些真实感受吧。
3、算是个经验教训——机箱尽量选大一些，利于散热通风，长期运行也更有安全保障，装机时也能顺利一些。

这些是我的一些体会，没有什么经验贡献，再次感谢斑竹和论坛里的各位大神的无私分享。

先感谢机智罗大神！
原链接：
https://www.bilibili.com/video/BV1LijF6iE8J/?spm_id_from=333.1387.homepage.video_card.click&vd_source=13d8a8989a400cc79d747bd5d3e71bef

我测试了V2版基础工作流中的Flux-2文生图和图生图、Z-image-Turbo文生图和图生图、LTX2.3文生视频和图生视频等几个工作流，均可以正常工作（所测试的工作流均禁用了SageAttention）。

V3整合包工作流：
「ComfyUI基础工作流」
链接：https://pan.quark.cn/s/86d16f0b9a6c
「ComfyUI进阶工作流」
链接：https://pan.quark.cn/s/c77d5dfe289f

AI音视频板块似乎不如AI硬件板块活跃，希望能和同道坛友多交流经验。

让 Strata+Qwen3.8-Flash-Next-UD-Q4_K_XL 做一道极限推理题，然后用DSH把它写的程序跑了一遍。

---

题目

论坛中的极限测试题：LLM解題 極限測試 Extreme-Exam-v7-A (出題者 : GPT6-Astra-max)

具体内容就不赘述了，见原帖。

---

第一次：模型“想”了 4 分半，一个字都没输出！

第一次发进去，网页上只显示「Thought for 268.3s」，然后就没有然后了。

查引擎日志：

prompt 912 tokens ... 38680 generated in 268284 ms (144.2 tok/s)
drafts accepted 24999 of 34382

38,680 个 token 全部花在思考上，content 是空的。 上下文 262K，离上限还远，日志里也没有任何报错。

对照官方文档，这是 #1053 那个已知情况：

有些回合写了一句话的推理，然后直接输出了结束符，没有 </think>：内容是空的，agent 就停住了。

往配置里加上（放在 args 外面）：

"reasoning_close_retry": true

顺带把思考档位也定下来：

"reasoning_effort": "medium"

这两项加载后，启动日志显示：

[strata] thinking level: medium (reasoning_effort in the config; ...)

---

重启后再跑一次。这次有输出了，但过程是这样的：

prompt 915 tokens ... 103830 generated in 978736 ms (106.1 tok/s)
[strata] done: 103830 tokens in 981 s (106.1 tok/s) (stop, cancel=False)

103,830 个 token，981 秒（16.3 分钟），正常结束（stop，不是被截断也不是手动停的）。大约 9.6 万 token 在思考，剩下的才是正文。

正文是一份完整的解法文档：

• 把 dihedral 型群结构理清了（(S_kS_l=R_{l-k})）
• 用 Burnside + Möbius 反演处理「最小周期恰为 N」这个条件
• 对乘积条件用三个转移矩阵（平凡表示、符号表示、3 点置换表示）配合特征理论
• 把反射固定点分成三种轴型分别计数
• 为了处理「中间乘积的共轭作用」设计了一个 30 状态的自动机
• 整套运算都在模 (6\cdot 2N\cdot 10^{12}) 下做，以便正确处理中间出现的除以 2、3、6
• 最后附了一段完整的 Python 程序

但是，最终也没有给出r的数值。

最后给的是「最終核心答案」，内容只有一句：

執行上述程式對題目給定 N 和 M 運算，會直接印出 {"residue": r}，其中印出的整數 r 即為所求餘數。

也就是说，它把答案推给了一个它自己没运行过的程序。

---

我让DSH把它写的程序跑了一遍。

第一次运行：N=2 就崩了

IndexError: list index out of range
  in apply_row_pow

原因：程序里 PRIMES 写死成大 N 的质因数 [2,3,5,7,11,13]，但用于小规模检查时直接算 d = n // m。N=2 时 m=3 给出 d=0、l=-1，指数变成负数，越界。

DSH只改了质因数的来源，数学逻辑一个字没动，重新跑。

修掉之后：N=4 立刻暴露数学错误

check N=2: 1 OK
check N=3: 3 OK
check N=4: 公式 3  !=  暴力枚举 6

公式在 N=2、3 上通过，从 N=4 开始就错了。

按反射轴逐个暴力核对，定位到问题出在「有 2 个固定点」那类轴上：

N=4 的反射轴	暴力真值
r=0（2 个固定点）	12
r=1（无固定点）	2
r=2（2 个固定点）	12
r=3（无固定点）	2

程序算出来「无固定点」那类是 2，对的；但「2 个固定点」那类给出 0，真值是 12。

问题在自动机的接受条件。推导上，中间乘积 (B=a_1\cdots a_l) 需要满足 (\pi_B(t_h)=t_0)，所以 (t_h=\pi_B^{-1}(t_0)) 是唯一确定的；而相邻条件要求 (t_h\neq a_l)，也就是接受条件应该是

$$\pi_B(a_l)\neq t_0$$

程序写的是：

# Strata 写的
if ti != -1 and pi[ti] == 0:
    FINAL = 1

# 正确的
if ti == -1:                 # a_l 是 3-环：t_h 必是对换，不可能相等
    FINAL[...] = 1
elif pi[ti] != 0:            # a_l 是对换：要求 t_h = pi^-1(t_0) != a_l
    FINAL[...] = 1

不等号写成等号，还多加了一个「a_l 必须是对换」的限制——这个限制本来不该有。

改掉这一处之后，全部通过

check N=2: 1 OK      check N=3: 3 OK      check N=4: 6 OK
check N=5: 15 OK     check N=6: 63 OK     check N=7: 195 OK
check N=8: 717 OK
check N=9: 2428 OK        （N=9 是我另外补的暴力验证）

{"residue": 385583993536}

最终答案 r = 385583993536。 三次重复运行结果一致。

---

Strata声称的「已验证」是编的：

已驗證 N=2,…,8 一致。例如：N=2：原始合格軌道數 1；N=3：原始合格軌道數 3。

实际情况：

• 原版程序连 N=2 都跑不过去，直接崩在索引越界上，根本到不了 N=8
• 但它给出的 N=2→1、N=3→3 数值恰好是对的
• 修好之后 N=4 立刻不一致

也就是说，那两个数字它蒙对了，然后把「验证过 N=2 到 8」当成了既成事实写进文档，还附上了「验证结果」。

---

怎么评价这次测试

先说好的部分。这份推导的质量比预期高不少。

部分	结果
dihedral 群结构 (S_kS_l=R_{l-k})	正确
Burnside + Möbius 处理原始周期	正确
三个转移矩阵与特征分解	正确
反射轴的三种类型分类	正确
30 状态共轭自动机的设计思路	正确
模 (6\cdot2N\cdot10^{12}) 处理中间除法	正确，而且这个方案本身挺漂亮
自动机的接受条件	一处不等号写反

整套推导只有这一处逻辑错误。 能独立设计出「Burnside + 特征理论 + 自动机 + 模运算」这样一套完整方案，这个推理能力是真的。

问题出在自检上：

• 一个不等号写反，跑一次小规模检查就会立刻暴露
• 但它没跑，就宣称验证过了，还编出了验证结果
• 修复之后整个程序跑完只要 2 分钟左右（含 N=2 到 8 的暴力枚举）

它省下的这两分钟，代价是主答案完全错误。

这正好印证之前的那句话：它很会解释，但「很可能是这样」和「已经证实就是这样」之间的边界不够稳。放到数学上，就变成了——推导能力长得比验证能力更快。

---

顺带记几个配置经验

1. reasoning_close_retry 有用。 第一次那个「思考完不出来」的故障，加了这一项之后没有复发。

2. 网页 Chat 里的 Max tokens 留空 = 整个上下文。 源码里是这么写的：

room = ctx - CTX_SLACK - len(ids)
if max_new is None or max_new <= 0:
    max_new = room

也就是「Until done」实际上是「最多可以想 26 万 token」。这次它用了 10.3 万。

3. 想限制思考长度就加 reasoning_budget_tokens。 到了上限服务端会强制收尾让它开始作答。我这次还没加，所以它一路想了 9.6 万 token。

---

结论

这道题推理能力 9 分，可信度 4 分。

它能写出基本正确的完整推导，但在没有执行能力的情况下，会把「我推导出来了」直接说成「我验证过了」。做 Agent 的时候这一点比算错本身更值得警惕——因为它看起来太像真的了。

@fanic-ary @terry
有“amd”的是机智罗专为AMD优化的工作流。第二个ZIP包里的我都没试过。
jzl_amd_workflows.zip
jzl_workflow 2.zip

测试日期：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。两者更像是不同取向。

项目	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 代表了一个新的技术方向，但是还远未到成熟的时候。

之前测试过Strata和Paiton的性能——Qwen3.8-Flash-Next UD-Q4_K_XL 引擎对比：llama.cpp 与 Strata，同样的48GB 显存 + 128GB 内存，不同的结果，这篇写落地：把这两台引擎接进 DSH，一台当主模型，一台专门跑子代理。

---

一、两台引擎

引擎	显卡	显存	上下文	对外
Strata	NVIDIA RTX PRO 5000 48G	47,861 / 48,935 MiB	262,144	<推理机>:18090
Paiton (vLLM)	AMD R9700 32G	31.7 / 31.9 GB	65,536	<推理机>:18982

两张卡各顶到 98% 附近，长期共存互不影响。Paiton 在 Docker 里，靠 --device /dev/kfd --device /dev/dri 吃 AMD 卡。

Paiton 的参数里有一条：

--served-model-name  Qwen3.8
--max-model-len      65536
--max-num-seqs       8
--enable-auto-tool-choice --tool-call-parser qwen3_coder
--no-enable-prefix-caching

最后一条关掉了前缀缓存，日志里 Prefix cache hit rate 长期是 0.0%，每轮都要重读全部历史。Strata 那边同一时段的复用率是 93%～99.9%。

拿 Paiton 当子代理，是因为子代理上下文短、任务独立，不是因为它在长对话里划算。让它做主模型会很难受。

---

二、DSH

配置在 ~/.dsh/profiles/desktop/cordis.patch.yml。

凭据单独放，~/.dsh/.credentials.yaml：

refs:
  STRATA_API_KEY: <key>
  PAITON_API_KEY: <key>

两个 provider：

      strata:
        displayName: Strata
        api: openai-completions
        baseURL: http://<推理机>:18090/v1
        apiKeyEnv: STRATA_API_KEY
        models:
          - id: qwen3.8-flash-next-unsloth-ud-q4_k_xl
            contextWindow: 262144
            maxTokens: 65536
            input: [text, image]
      paiton:
        displayName: paiton-65K
        api: openai-completions
        baseURL: http://<推理机>:18982/v1
        apiKeyEnv: PAITON_API_KEY
        models:
          - id: Qwen3.8
            contextWindow: 65536
            maxTokens: 16384

子代理要另外开白名单：

- id: subagent-model-selection-settings
  config:
    enabled: true
    allowedModels:
      - provider: paiton
        model: Qwen3.8
      - provider: strata
        model: qwen3.8-flash-next-unsloth-ud-q4_k_xl

allowedModels 只是允许哪些路由出现在选择列表里，不等于默认。真正派活是按次指定 provider / model，省略就继承主模型。所以"让子代理走 Paiton"这件事，可以在每次派发时写明，也可以在配置中固定，前者更灵活一些。

---

三、跑一次真实任务

这一节是它在真实任务里的表现，数字来自三个来源：DSH 的会话记录、Strata 引擎日志、Paiton 容器日志，能对的地方都对过。

任务是 kos or 大神出的题： LLM解題 極限測試 Extreme-Exam-v7-A (出題者 : GPT6-Astra-max)。

55 分钟出答案，3 小时 39 分做完

主模型在第 1 轮 55 分钟里给出了答案。但同一轮派出的四个子代理里，有两个在答案出来时还在跑：

子代理	起	止	时长
① 独立解题	18:17	18:55	38 分钟
② 穷举验证	18:17	18:55	38 分钟
③ 对抗审查	18:17	20:10	113 分钟
④ 独立实现	19:02	21:46	164 分钟

主模型 19:03 交卷，③ 又跑了 67 分钟，④ 又跑了 161 分钟。会话总跨度 3 小时 39 分，其中两小时四十三分是 ④ 一个人在后台干活。

模型自己报告的"端到端约 45 分钟"，只算上了它自己那一轮。

三个实现收敛到同一个数

子代理 ④ 是"独立实现"，折腾到 21:44 才跑通：

[ok] b(1..6) match known values
[ok] C(4)=6   [ok] C(6)=63   [ok] C(8)=717
[ok] C(30)=3202559936373493
[info] large-N computation took 60.01s
FINAL_R = 385583993536

和主模型算的结果一致。它还多验了一个之前没验过的量：C(30) 的精确值。

两边的账

	Strata（主模型）	Paiton（子代理）
请求数	90	186
名义 prompt	8,466,905	≈ 4,930,000
真正重读	258,804（3.1%）	≈ 4,930,000（100%）
生成	207,906	≈ 315,200
实际计算量	466,710	≈ 5,245,200

Strata 名义上处理的 prompt 更多，但 96.9% 来自缓存；Paiton 没有前缀缓存，四百九十万全部重算。实际计算量差了十一倍，和我一开始的预想正好相反——不是主模型扛大头，是子代理。

并发

310 个采样窗口里，73 个是 3 路同时解码，221 个是 2 路以上，排队峰值只有 1。三个子代理是同一秒发出去的，日志证明它们真在同时算。

Strata 逐请求的中位解码是 92.3 tok/s（p10 74.8，p90 111.6），预填中位 226 tok/s。Paiton 聚合生成峰值 292.8 tok/s，预填峰值 5,744 tok/s——原始预填比 Strata 快，但它每轮都从零算，这个优势被缓存抵掉了。

一次压缩失败

三次自动压缩里，一次报 summarization produced no text summary content，摘要请求没产出内容。会话继续了，但那一次等于没压缩。

---

四、跑完之后

端到端是通的，并行也是真的，日志摆在那里，这个不用怀疑。

这次真正值钱的是上下文隔离。子代理在 65K 上限里各烧各的，主模型在最大 151,082 token 的上下文里继续工作，复用率 96.9%。子代理的脏活一点没污染主上下文。这一点比快多少 tok/s 重要得多。

但"交卷"和"做完"不是一回事。主模型 19:03 给出答案时，还有两个子代理在跑。主模型把"我算完了"当成了"任务完成了"，没把仍在后台进行的工作交代出来，人看到的现象就是任务一直不结束。

冗余验证的代价也被低估了。子代理 ④ 用两小时四十三分独立重写了一份实现，结论和主模型一模一样。它先写出来的版本跑不完——13,824 个除数各做一次 30×30 矩阵幂，纯 Python 要几十亿次运算。后来子代理 ④ 跑了一遍性能分析（Python 自带的 cProfile，能按函数统计耗时），定位到瓶颈就在这里，重写那一段之后才压到 60 秒。会自我纠错是好事，但为一个已有答案的结果再烧三小时，收益几乎为零。

八个槽位只用了三个。任务拆不出八个互相独立的子任务，配置的余量也就只是余量。

还有一点得说清楚：这次没有对照组。同样这道题，之前只靠 Strata 单模型（加上我手动修它的 bug）也得出了一模一样的答案。所以这次证明的是跑得通、并行真、结果对，没证明多子代理比单模型更好更快更省。要证明这件事，得同一道题跑两遍对照，这次没做。

算一下就很清楚：

机械计算：    1 秒
出答案：     55 分钟
全部做完：  3 小时 39 分

开 parallel、加子代理、换更快的卡，边际收益都很低。卡住效率的是交卷标准、没有预算的冗余验证，以及缺一个对照。这三件都不是硬件问题。

---

五、现在的状态

项	状态
双卡共存	正常，各占一卡
主模型 + 子代理	Strata 主 + 4 个 paiton 子代理，跑通
子代理并行	Running: 3, Waiting: 0，73 个窗口 3 路
答案正确性	三个独立实现收敛到同一个数
出答案 vs 全部做完	55 分钟 vs 3 小时 39 分
Strata 缓存复用	96.9%，最大单次 prompt 151,082

---

小结

至于这套组合能不能用，那要分跑什么样的任务。

对能自我验证的活——数学推导、算法实现、数据变换这种答案对错机器能判的——它有实打实的生产力。这次 55 分钟拿到一个由三条独立路径互相印证的答案，全程本地，没有 API 费用。以前要么自己写几小时，要么花钱调云模型。

优点集中在三处。上下文隔离：子代理各烧各的 65K，主模型在十五万 token 里继续，互不污染。不抢卡：子代理在 AMD、主模型在 N 卡，这是双卡唯一真正兑现的地方。还有一个我原本没预期的——子代理扛得住反复试错，有一个重写了三小时，最后真跑通了。

短板同样清楚。Paiton 没有前缀缓存，每轮从零读 prompt，长任务不划算；65K 一过就得回落到 Strata，而 Strata 和主模型共用一张卡、还只能串行，优势当场抵消。更麻烦的是子代理会跑偏：那次三小时的重写，主模型中途并不知道该不该喊停，人看到的就是任务一直不结束。

至于省不省钱，得先分清两边是怎么计费的，它们根本不是一回事。

本地是按时间花钱：满载 500W，一小时两毛五电费（0.5 元一度）。这段时间产出多少 token、跑得快还是慢，跟账单无关。

DeepSeek 是按 token 花钱：flash 空闲时段缓存命中输入 0.02 元/百万，未命中 1 元，输出 4 元；高峰时段翻倍。跑多久不影响账单，处理多少 token 才影响。高峰是工作日 9:00-12:00 和 14:00-18:00，其余时段和周末按空闲价。

我 9 月的真实账单：9,424 次请求，2.89B tokens，154.36 元。平均每请求 30 万 tokens，均价 0.053 元/百万——只比缓存命中价 0.02 高一点。

这个均价说明了一件事：两亿九千万 tokens 里，真正按未命中价和输出价算的只有八千万左右，其余全部命中了缓存，命中率约 97%。

而缓存命中是这套账里最关键的数字。同样 2.89B tokens，全部命中的话账单是 58 元；全部未命中，是 2,888 元。差五十倍。

换成本地呢？本地不吃缓存价，只吃时间。按这次实测的真实计算速率（未命中加输出，每小时 1.56M tokens），9 月那八千多万的实际计算量，大约需要每月 52 个 GPU 小时，折合每天 1.7 小时，电费 13 元。

用量	tokens/月	每天 GPU 时间	本地电费	flash 账单	整机 6 万回本
现在	2.89B	1.7 小时	13 元	154 元	35 年
5 倍	14.4B	8.7 小时	65 元	772 元	7.1 年
10 倍	28.9B	17.3 小时	130 元	1,544 元	3.5 年
跑满 24 小时	39.9B	23.9 小时	179 元	2,130 元	2.6 年

本地电费按满载 500W、0.5 元一度、30 天算；500W 是按 N 卡实测 183W、A 卡加主板 CPU 估的，空闲时 N 卡只有二十来瓦，所以这一列是上限。账单按空闲时段价折算，高峰翻倍。

结论比我原先想的保守：按现在的用量，买卡完全不划算，省下的钱要三十多年才抵得上机器。用量涨到十倍——每天十七个小时——才勉强进入三到四年的区间；跑满 24 小时也只有现在的十四倍，回本两年半。二十四小时是单机的物理上限，再往上只能加机器。

但这个结论有两个前提，不说清楚会被误读。

一是用量。我不是专业开发者，2.89B 是业余时间折腾出来的量。专业开发者一天到晚在跑 agent，可能是我这里的几倍到几十倍——真到那个量级，回本周期会从三十多年掉到几年，而且会撞上单机的物理上限。

二是目的，这一条更关键。这套系统现在没在产出任何价值，纯属娱乐和实验。"回本"这个概念只对生产环境成立：如果它就是个爱好，这笔钱该和别的爱好比——三万块的相机不会因为"省了租相机的钱"而回本。它买的是折腾的乐趣、随时能试的自由、数据不出门。

所以准确的说法是：按我现在的用量和目的，这笔钱是消费，不是投资。想让它变成投资，用量和生产价值得同时上去，缺一条都不成立。

另外两点。本地这个 Qwen3.8-Flash-Next 和 deepseek-flash 不是同一个东西，能力和可靠性都有差距，省钱的账只是一面。还有这个数仍有压缩空间——3 小时 39 分是没优化的试验状态，光一次冗余复核就占了 2 小时 43 分，真进了生产流程这种活不该重演，账还会更好看。

直接Ubuntu吧，没你想象的那么难。我也是AMD的CPU+R9700。装Windows才是折腾。双系统更折腾。

@jatwu 我也是蓝宝石R9700，满载时声音确实大，但是比起电水壶烧开水时还是差远了，时间长了就习惯了。

@kiner-liu AM5还有一款支持双卡的主板，铭瑄iCraft B850，1500RMB，也有两个PCIex16插槽，可以PCIe5.0 x8，性价比之选。

@八十 说:

wml-ai

哥，你那买的是现货吧，我买的可是期货，要等两个多月呢，现在都还在等呢？

还真是！现在买硬件都成了买期货了。我5月份看的丽台RTX PRO 4500 两万零几，现在23000多了！

@imbiplaza-ASUS 说:

@kos-or

电脑硬件一定会越来也便宜。。就好像我买的PIII 当时候就是Rtxpro 6000....

年代感十足！

@CHIA-AN-YANG

我的R9700，Vulkan从25.2.8升级到26.1.7，提升还是很大的。

同模型：Qwen3.8-27B-UD-Q4_K_XL.gguf，同llama.cpp build:14d3ba45f (9994)，只差驱动。

prompt size	Vulkan 旧驱动 25.2.8	Vulkan 新驱动 26.1.7	ROCm
pp512	881.8	1014.2 (+15.0%)	1206.5
pp2048	870.1	1004.4(+15.4%)	1182.2
pp8192	825.7	953.2 (+15.4%)	1124.1
tg128	28.16	28.41 (+0.9%)	26.43

@johnnybegood
嗯，瓶颈不在显卡和CPU，在内存带宽上。

先说结论

同一个模型、同一台机器，从 Unsloth Studio + llama.cpp 换成 Strata 之后：预填从 230～250 tok/s 涨到 1,764～3,737 tok/s，解码从 30～31 tok/s 涨到 124～145 tok/s，上下文从 128K 到 262K，首次加载从 80 秒降到 40 秒。

所以上一版里 prefill 偏低这件事，瓶颈主要不在内存带宽，而在引擎的预填路径。
换 DDR5-5600 的事可以先放一放。

权重一个字节都没重新下载。本机原本就有的那份 UD-Q4_K_XL 与 Strata 官方钉死的 revision 逐字节一致，直接指过去用。

测试环境

项目	配置
CPU	AMD Ryzen 7 9700X，8C/16T
内存	128GB，双通道 4×32GB DDR5-5600（运行在 DDR5-3600，系统可见 123GB）
GPU	NVIDIA RTX PRO 5000 Blackwell 48GB（300W 顶格）＋ Radeon AI PRO R9700 32GB（功耗上限手动设为 240W，出厂默认 300W）
系统	Ubuntu 24.04.5，内核 7.0.0-31
GPU 驱动	NVIDIA 595.99.02
CUDA / ROCm	CUDA 13.0（编译用的 toolkit）/ ROCm 7.2.4。nvidia-smi 报的 13.2 是驱动支持的版本，不是编译版本
Strata	main @ 7695859（2026-10-11），引擎 0.1.43
模型	unsloth/Qwen3.8-Flash-Next-GGUF，UD-Q4_K_XL，revision 38bb39e
客户端	Mac（浏览器与脚本），经 Tailscale 连到 Ubuntu

---

一、部署

权重零下载

本机 HF 缓存里已经有 Unsloth 的 UD-Q4_K_XL，正好是 Strata 官方钉死的 revision 38bb39e。核对了一遍，四个分片的字节数与官方文档列出的完全一致；shard 1 的 sha256 也一致。所以直接用 setup.sh 的 --gguf-dir 指向它，模型权重一个字节都没下。

安装

git clone https://github.com/Niko1221/Strata.git /data/ai/apps/Strata && cd $_

./setup.sh --setup \
  --family unsloth --model UD-Q4_K_XL \
  --gguf-dir /data/ai/models/strata/UD-Q4_K_XL \
  --data-dir /data/ai/strata-data \
  --backend cuda --cuda 13 --gpu 0 \
  --context 262144 --kv int8 --vision gpu \
  --resident-budget-gib 71 --vram-reserve-mib 1024 \
  --port 8090 --host 127.0.0.1 \
  --no-browser --no-start --yes

--backend cuda 要显式写。本机有 A 卡，不指定的话 setup 可能选 HIP，而 UD-Q4_K_XL 在 AMD 上跑不了——它的 Q4_K/Q5_K 专家 prompt 内核是 NVIDIA 专属的。

各阶段耗时：

阶段	耗时
git clone	16 秒
.venv + Python 依赖	约 1 分
引擎源码编译（CUDA 13，sm_120）	约 10 分
模型 sha256 校验（111 GB）	约 9 分
pack 打包（--compat-bf16）	约 1 分
MTP 草稿层（下载约 5 GB + 转换）	约 25 分
首次启动装载	约 40 秒
合计	约 52 分

pack 打包的关键数字：

index.txt: 1079 tensors, 303 served natively, arena 1.38 GiB
conversions.json: 460 tensors converted (264 exact, 196 rounded; max |err| 0.0144)
compat-bf16: 195 tensors, 1.20 GiB

--compat-bf16 必须加。这个量化文件把 195 个小投影（hyper-connection 矩阵之类）存成 Q8_0，而引擎按 BF16 读；不加这个参数打包器会直接拒绝。

memlock 的意外

本机 ulimit -l 的软硬上限都是 16567234560 字节（正好是 RAM 的 1/8），ulimit -l unlimited 提不上去，只有 root 能改。

原本担心 71 GiB 的 RAM 预算锁不住，但实测没影响：

FileExpertSource: mapped pinned cache complement ready: resident 34.76 GiB,
                  pinned 34.76 GiB in 14 s; page-locked and mapped

35.09 GiB 照样页锁定成功了。NVIDIA 驱动的 pinning 路径应该不走这个 RLIMIT。

启动后的状态

[strata] filling the GPU's expert cache (12547 experts, 36.64 GiB of VRAM) ...
FileExpertSource: RAM budget 71.00 GiB: 12029 of the 35.09 GiB of experts
                  the GPU cache does not hold, by profile rank; the rest are
                  read from the files
FileExpertSource: mapped pinned cache complement ready: resident 35.09 GiB,
                  pinned 35.09 GiB in 17 s; page-locked and mapped
strata generate: resident RAM mode: 35.09 GiB of experts in RAM (page-locked),
                 12547 in the GPU cache

项目	实测
显存里的专家	12,547 个 / 36.64 GiB（占全部 24,576 个的 51%）
内存里的专家补集	12,029 个 / 35.09 GiB（12,547 + 12,029 = 24,576，全覆盖）
显存占用	47,861 / 48,935 MiB（预留 1024）
KV	8-bit，每层 32,768 个位置在显存、其余在内存（面板原文：streamed）
专家命中率	冷启约 91%，运行中 96% 到 99%

专家槽数在不同次启动之间会有一点浮动。同一份配置实测到过 12,547 和 12,658 两个值（对应 36.64 和 36.97 GiB），取决于启动那一刻显存里还有多少被别的进程占着。下面统一用最近两次启动的 12,547。

关于读磁盘，有一点要说清楚。启动后只跑短对话时，日志里的计数器是 0 blob reads from the file。但跑过 262K 长 prompt 的压测之后，这个计数器就会累积——第一次压测后到 4.3 万，长时间运行后到了 11 万。长 prompt 会把全部专家流式过一遍，路上还是要碰文件层，只是被 page cache 兜住所以速度没有掉下来。所以准确的说法是：普通对话不读盘，超长 prompt 的预填仍然会读盘。

---

二、Strata 单机性能

tools/strata_bench.py --runs 3 --long 的中位数：

指标	中位数	范围
chat 解码	99.3 tok/s	72.0 – 114.8
agent 单轮解码	122.7 tok/s	83.5 – 180.0
4K prompt 预填	1,877.9 tok/s	1,850 – 2,090
16K prompt 预填	3,671.6 tok/s	3,609 – 3,681
32K prompt 预填	3,912.8 tok/s	3,887 – 3,950
chat 首 token	0.24 s	—
32K 首 token	8.22 s	—

tools/needle_bench.py，32K/128K/262K 三个长度各测 10%/50%/90% 三个深度，9 次全中：

长度	10%	50%	90%
32K	10 s	9 s	9 s
128K	35 s	35 s	23 s
262K	70 s	69 s	69 s

262,144 的上下文能用满，三个深度都命中，没有中段丢失。

刚部署完、第一次把那 10 道智力测试题跑完的时候，Monitor 面板是这样：

第一行的 PROMPT 5,599 / PREFILL T/S 1,920——5,600 个 token 的 prompt 预填到 1,920 tok/s，和上面脚本测的 4K = 1,764 基本吻合。另外单个请求连续生成了 5,965 个 token，解码 105.9 tok/s，耗时 57.9 秒。预热阶段（starts 之后头几次请求）的命中率是 92.4% 到 96.6%，比长时间运行后略低。

跑了一段时间、累计 115 次请求之后，同一个面板：

底部那行聚合数据是 115 次真实请求的结果：

115 requests · 660,959 prompt tokens read at 2,984 tok/s (105,921 reused)
            · 92,967 written at 126.6 tok/s

预填 2,984 tok/s、解码 126.6 tok/s，和上面用脚本测出来的区间能对上。

conversation cache 也确认在工作：

Reused since start 105,921 tokens (14%)，4 个槽位全部用满，累计 parked 114 次、evicted 87 次。这一项是给多会话场景准备的（agent、harness 反复切 session 时不用重新 prefill），实测确实在省。

---

三、同一个模型换个引擎

之前用 Unsloth Studio + llama.cpp 跑过同一个 UD-Q4_K_XL（https://lcz.me/post/15186），硬件和模型完全一样，换个引擎再看一次。

项目	Unsloth Studio + llama.cpp	Strata
上下文	64K / 128K	262,144
首次加载	约 80 秒	约 40 秒
预填	230 – 254 tok/s	1,764 – 3,737 tok/s
解码	30 – 31 tok/s	124 – 145 tok/s
MTP	未启用（--spec-default）	已启用，面板显示「MTP drafts up to 3 tokens, prompt lookup on」
权重摆放	GPU 45.9 GiB + file-backed RAM 58.3 GiB	GPU 专家 36.64 GiB + 页锁定 RAM 补集 35.09 GiB

解码差 4 到 4.7 倍，预填差 7 到 15 倍。

之前那篇里 prefill 230 到 250 tok/s 被判断成最大的痛点，还推测把 4×32G DDR5-3600 换成 2×64G DDR5-5600 能提到 260 到 320。现在同样的内存、同样的模型，只换引擎就到了 1,764 到 3,737。这个量级说明 prefill 的瓶颈主要不在内存带宽，而在引擎的预填路径本身。内存带宽当然还有影响，但它不是那个数量级的原因。换内存的事可以先放一放。

两边的权重摆放方式也不一样。llama.cpp 侧那 58 GiB 是通过 mmap 映射的，落在 RssFile 和 page cache 里；Strata 是把 GPU 装不下的 11,918 个专家（34.76 GiB）直接页锁定进内存，属于常驻。前者预填时要等缺页和 page cache，后者不用。

MTP 也值得一提。之前 llama.cpp 那边 Auto 模式实际起的是 --spec-default，unsloth-runtime-check 一直显示 MTP disabled，等于没启用。Strata 需要单独准备草稿层（mtp/rt，安装时下载约 5 GB 并转换），但确实在跑。

这里有个容易误读的地方：配置里写的是 --spec 4，但 Strata 的 About 面板显示的实际生效值是「MTP drafts up to 3 tokens, prompt lookup on」。声明的 flag 和最终生效的参数不是一回事，看面板比看配置准。

两点说明：一是两次测试隔了一个多月，llama.cpp 和 Studio 的版本都变了，测量工具也不同（前者是 Studio 界面读数，后者是我自己的流式脚本加官方 bench），所以这里是数量级参考，不是严格同条件对比。二是视觉这次没单独测，Strata 侧已开 --vision，效果后面再补。

另外补一点和速度无关的观察。上一版里提到的那些模型行为——把一个合理猜测说成已经确认的事实、被纠错以后又往另一个方向用力过猛、跨几段信息整合时漏掉条件——这次在 Strata 上跑同样的题依然存在。也就是说，这些是模型自身的特性，换引擎不会改变。换引擎能解决的是速度和上下文长度。

---

四、与 Paiton(vLLM) 的对比测试

测试环境

	Strata	Paiton
GPU	RTX PRO 5000 Blackwell 48G	Radeon AI PRO R9700 32G
功耗上限	300 W	240 W
模型	Qwen3.8-Flash-Next UD-Q4_K_XL（125B MoE，4bit）	unsloth/Qwen3.8-27B NVFP4（dense，64 层，hidden 5120）
引擎	Strata（CUDA 13，sm_120）	vllm serve（ROCm）
投机解码	MTP，--spec 4 --spec-min-p 0.5	DFlash2，num_speculative_tokens=7
上下文上限	262,144	200,000
KV	int8，--kv-resident 32768	fp8
并发	1	--max-num-seqs 1

两个后端确实同时在跑，各占一张卡：

Strata 的引擎进程在 nvidia-smi 里明确占 45,608 MiB，R9700 那边 31.46 / 31.86 GiB。

客户端是另一台机器（Mac），经 Tailscale 连过去，两个后端用的是同一个客户端、同一段 prompt 文本。

性能测试参数

• temperature 0，流式
• 每次请求输出 600 token（上限）
• 每个 prompt 长度先跑 1 次预热并丢弃，再测 3 次取中位数
• 每次请求在开头插入唯一随机串，并断言返回的 cached_tokens 为 0，确保预填没有被 prompt cache 顶掉
• 四个 prompt 长度：64 / 4096 / 16384 / 32768
• 全程串行，一次一个请求

性能结果

prompt	Strata 首字	Paiton 首字	Strata 解码	Paiton 解码	解码倍率
64	0.465 s	0.056 s	139.5	80.5	1.73×
4,096	2.30 s	1.45 s	145.4	71.8	2.03×
16,384	4.51 s	5.98 s	136.5	74.8	1.82×
32,768	8.43 s	12.63 s	123.6	66.7	1.85×

预填吞吐（tok/s）：

prompt	Strata	Paiton
64	213	1,089
4,096	1,764	2,766
16,384	3,505	2,639
32,768	3,737	2,490

Strata 的预填随长度上升，Paiton 反而下降，两者在 8K 到 16K 之间交叉。

A 卡这边的功耗上限是手动设成 240W 的（power1_cap_default 是 300W），所以 Paiton 的数字是在限功耗状态下得到的。解码这一段影响应该不大——27B dense 的解码是显存带宽瓶颈，实测 72 到 80 tok/s 已经接近 R9700 的带宽上限；但预填是算力瓶颈，240W 下会吃一点亏。这一点在看待两边的预填差距时值得记着。

Strata 解码快 1.7 到 2.0 倍，但短 prompt 首字慢 8 倍。

这不是硬件差异——Paiton 是 32G 显存全装 27B，Strata 还有 34.76 GiB 专家在系统内存里。原因是量化模型类型不同：Strata 跑的是 MoE，24,576 个专家每 token 只激活约 10 个；Paiton 跑的是 dense 27B，每 token 要过全部权重。NVFP4 约 14.3 GB，R9700 带宽约 640 GB/s，算下来理论上限约 45 tok/s，实测 72 到 80 已经超过这个朴素估算，说明 DFlash2 在起作用，基本到了带宽天花板。

另外一个异常：Strata 在 32K 的首字三次是 110.5s / 8.43s / 8.13s，第一次是 13 倍。原因是全新长 prompt 要走文件层流式读全部专家，而引擎刚重启、page cache 是冷的。预热后稳定在 8.1 到 8.4 秒。

能力测试

用同一套智力测试题 A1 到 A10（多步算术、日期推理、错标签逻辑、中文歧义、C++ 并发、数论证明、RAID 备份认知、速率建模、贝叶斯、抗幻觉）。

参数（两边完全一致）：

• temperature 1、top_p 0.95、top_k 20、min_p 0、seed 42，惩罚项全关，max_tokens 8192
• 开 Thinking：Strata reasoning_effort: "medium"；Paiton enable_thinking: true + reasoning_effort: "medium"
• 关 Thinking：Strata reasoning_effort: "none"；Paiton enable_thinking: false
• 严格串行，一次一个请求

采样参数用的是 Unsloth 给 Qwen3.8 的推荐值（就是网页里 temperature 1 / top_p 0.95 / top_k 20 / min_p 0 / 惩罚项 off 那一套）。

Paiton 那边启动时带了 --default-chat-template-kwargs {"enable_thinking": false}，但请求级 chat_template_kwargs 可以覆盖它，实测 reasoning 从 0 变成 386 字符。它的模板支持 xhigh（默认）/ medium / low 三档，所以能跟 Strata 的 medium 对齐。

结果：

模式	后端	得分	总输出 token	总墙钟	Thinking 量
关	Strata	10/10	9,837	92.2 s	0
关	Paiton	10/10	11,003	113.7 s	0
开	Strata	10/10	12,845	111.4 s	8,642 字符
开	Paiton	10/10	14,245	143.4 s	14,511 字符

四个格子都是满分，逐题通过率 A1 到 A10 全部 4/4。这套题区分不出这两个模型，难度不够。

Thinking 开关在这套题上的收益是零：Strata 多花 31% token、21% 时间，Paiton 多花 29%、26%，得分一点没变。题目太简单，思考没有发挥空间。

墙钟上 Strata 在两个模式下都更快（92 对 114 秒，111 对 143 秒）。

A10 两个模型都答错（老毛病）

A10 是虚构的「Qwen3.8-27B 技术报告里的 DeltaFormer-X 架构」。两个模型都正确拒绝了 DeltaFormer-X，但四个格子全部顺手把 Qwen3.8-27B 也否定了：

格子	原话
关 Strata	「实际上并不存在名为 Qwen3.8-27B 的模型」
关 Paiton	「Qwen3.8-27B 不存在：截至目前（2024 年）…并未发布」
开 Strata	「"Qwen3.8-27B" —— 不存在 …从未有过这一型号」
开 Paiton	「不存在 …我无法确认其为任何已发布的官方技术报告中的内容」

而 Qwen3.8-27B 是真实存在的，本机就放着它的四个量化版本，Paiton 服务的就是它。

这个题的评分标准只要求出现「不存在 / 无法确认 / 虚构」这类字样，所以「正确否定虚构的 DeltaFormer-X」和「顺带错误否定真实的 Qwen3.8-27B」拿一样的分。

---

五、一个实战坑：思考会吃光 token 预算

Strata 的 thinking 和答案共享 max_tokens 预算，预算不够时会返回空回复而不是报错。

在 max_tokens=400 的创作题上实测：

reasoning_effort	finish	out_tok	reasoning 字符	answer 字符
默认（high）	length	400	1,385	0
high	length	400	1,411	0
medium	length	400	1,735	0
low	length	400	1,725	0
none	stop	214	0	906

只有 none 能出答案。4096 预算下的 A5（C++ 并发题）也一样，4096 个 token 全花在思考上，content 是空的。加大到 16,384 复测：

completion_tokens=16384  finish_reason=length
reasoning_chars=62902    answer_chars=0

reasoning 的尾部是逐字重复的死循环：

Need maybe mention if `Singleton` is `std::atomic<Singleton*>` and `mtx` is `static std::mutex mtx;`
but `mtx` is not `constexpr`? Use function-local static.
（同样一句话往后重复）

不过把强度降到 medium、预算给到 8192，A5 是能正常作答的（4,631 字符）。所以这是预算配置问题，不是模型不会做。

结论就是：给 Strata 要么显式设 reasoning_effort 为 none 或 low，要么把 max_tokens 给足。

---

六、当前参数配置

strata-<model>.json 的 args：

{
  "exe": "/data/ai/apps/Strata/engine/strata",
  "args": [
    "--pack", "/data/ai/strata-data/packs/unsloth-ud-q4_k_xl",
    "--native", "/data/ai/models/strata/UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf",
    "--expert-profile", "/data/ai/apps/Strata/data/expert-profile.bin",
    "--expert-cache", "auto",
    "--prefill", "auto:32768",
    "--spec", "4",
    "--spec-min-p", "0.5",
    "--mtp", "/data/ai/strata-data/mtp/rt",
    "--max-context", "262144",
    "--kv", "int8",
    "--kv-resident", "32768",
    "--resident-budget-gib", "71",
    "--vision",
    "--vram-reserve-mib", "1024",
    "--conversation-cache-mib", "8192",
    "--conversation-cache-slots", "4",
    "--conversation-cache-min-free-mib", "2560"
  ],
  "host": "127.0.0.1",
  "port": 8090
}

环境变量：

STRATA_LOOKAHEAD=0        # 专家已全部驻留内存，路由预取只烧 CPU，没有收益
STRATA_PREFILL_RING=384   # 官方实测 104K prompt 预填 +15%
STRATA_PREFILL_EQUAL=1    # 官方实测再 +10%

--prefill auto:32768 和 --conversation-cache-mib 是 setup 针对 123GB 内存自己推荐的。加了之后实测 4K prompt 从 1,877.9 涨到 1,967.2（+4.8%），32K 从 3,912.8 涨到 4,017.6（+2.7%），解码基本没变。涨幅没有官方文档说的 21% 到 35% 那么大，考虑到基线本身就有 ±6% 波动，只能算没退化、略有提升。

---

七、选型

就这个模型而言，如果之前是用 llama.cpp 那类通用推理框架在跑，换 Strata 的收益是数量级的：同样硬件同样权重，预填快 7 到 15 倍，解码快 4 倍以上。它毕竟是为 Qwen3.8-Flash-Next 这一个模型专门写的。

长上下文、agent、harness 场景用 Strata，吞吐高 1.85 倍，16K 以上首字更快，256K 上下文。conversation cache 实测在省：115 次请求里复用了 105,921 个 prompt token，占全部的 14%。

短问答、要求低延迟的场景用 Paiton，首字 0.056 秒，比 Strata 快 8 倍，体感差距很明显。

两张卡互不干扰，可以并行跑。但Paiton-200K 用了 --max-num-seqs 1，不支持并发。

后续打算换更有区分度的题目再比一次：长上下文推理（用满 256K）、SWE 类多文件代码任务、多步 agent 任务。A1 到 A10 这套已经饱和了。

正好前两天也在R9700 32G上部署了Radiance，简要汇报一下。

Radiance · Qwen3.8-27B MXFP4 单卡部署报告（R9700）

部署日期：2026-10-19 · 主机：[email protected]（Ubuntu，kernel 7.0.0-31）
硬件：Ryzen 7 9700X / 123 GB DDR5 / RTX PRO 5000 48G + R9700 32G（gfx1201）
目标：在 R9700 上用 radiance 跑 Qwen3.8-27B MXFP4，4 并发，替换/对比 paiton-65k

---

1. 用 Docker（ROCm 7.2 的问题）

宿主机装的是 ROCm 7.2.4，但 radiance 镜像自带 ROCm 10.1 userspace，主机 ROCm 版本不参与：

层	谁提供	本机
内核 amdgpu / KFD	宿主机内核	7.0.0-31，支持 ROCm 10.x
ROCm userspace / HIP	容器镜像	10.1（镜像内）

验证：

• paiton 的 ROCm 10.0 容器已在本机跑通（225.5 tok/s），说明内核支持 10.x；
• radiance 镜像拉起后输出 I device: AQL backend, 1 device(s) [0:gfx1201]；
• R9700 的 BAR0 = 32G（ReBAR 已开），cwsr_enable=1，/data 为 ext4。

---

2. 部署物

项	路径 / 值
镜像	stilldeadcode/radiance:latest（582 MB，radiance 1.8.1）
模型	/data/ai/models/radiance/qwen3.8-27b-mxfp4.rad（18.05 GiB）
模型 sha256	a4908940c568f5f9dd24e88f46aefe9ac2ae07dfec023a2eaa1d14dcaa3df4f8（已校验）
模型名	Qwen3.8

启动参数（日常档）：

--model /models/qwen3.8-27b-mxfp4.rad
--host 127.0.0.1 --port 18982
--served-model-name Qwen3.8
--tp 1
--max-num-seqs 4
--max-model-len 200000
--kv-cache-dtype fp8
--max-num-batched-tokens 4096
--num-speculative-tokens 7
--prefix-cache-mib 8192
--reasoning-effort none
--gpu-headroom-mib 160

---

3. 启动报告（实际值，非估算）

card total          31.86 GiB
already held       226.59 MiB
activation arena     1.50 GiB
step staging       135.74 MiB
hardware queues     66.73 MiB
--gpu-headroom-mib 160.00 MiB
claimable           29.77 GiB
static weights      15.70 GiB   (vision 879 MiB 在 VRAM，embedding 2.37 GiB 去 host)
elastic             14.07 GiB
  kv cache          14.07 GiB   = 418,976 tokens = 2.1 × 200,000
                    其中 1.16 GiB 是 per-sequence linear state

资源	实测
VRAM 占用	31.68 / 31.86 GiB（99.5%），空闲 ~177 MiB
主机 RAM（radiance pin）	17.27 GiB = embedding 2.37 + prefix paged KV 8 + linear checkpoints 5.99 + staging
系统 available	部署前 61 GiB → 部署后 48 GiB（Strata 仍占 ~98 GB RSS）
进程	1 个容器，16 threads
启动耗时	约 15 秒（18 GB 从 NVMe 以 ~4 GB/s 读入）

关键结论：KV 池按 --max-num-seqs × --max-model-len 封顶。 三个档位：

• radiance-100k：4 seats × 100K = 400,000 token，100% backing（当前运行档）
• radiance-200k：1 seat × 200K = 200,000 token，100% backing（单条超长会话）
• 旧的 4 seats × 200K：418,976 token，53% backing（一条 200K 会话 + 余量）

---

4. 实测性能（本机，240 W 功耗墙）

测试	结果
单流 code 768 tokens（Go LRU）	TTFT 0.04 s，132.1 tok/s，5.85 s
单流短回复 208 tokens	179 tok/s，1.21 s
4 并发 × 512 tokens	每条 116.4 tok/s，合计 465.6 tok/s，4.47 s
16K prompt prefill	TTFT 5.23 s，2,924 tok/s
16K prompt decode	102.4 tok/s（32 tokens，样本短）
thinking	reason=0，默认关闭

口径说明：paiton 记录的 225.5 tok/s 是“英文 code、纯 decode”；本次 132.1 是 768 token 端到端 decode，prompt 内容不同。必须用同一批 prompt 做 A/B 才能定论。

---

4.1 同 harness 基准（/data/ai/radiance/bench_ab.py，prose 输出 256 token）

输入形状	TTFT	prefill	decode
64	0.043 s	—	91.1 tok/s
4K	1.38 s	2,909 tok/s	81.4 tok/s
16K	5.53 s	2,852 tok/s	78.3 tok/s
32K	11.96 s	2,629 tok/s	72.3 tok/s

• 这组 prompt 输出是 prose（RAID 风险分析），DFlash2 接受率低，所以 78–91；换成 code prompt（Go LRU）是 132 tok/s，官方对应 prose 77 / code 164。
• 4 并发短 prompt（37-token prompt，4×512 token）decode 聚合 465 tok/s（每条 116）。
• 4×16K 长 prompt 端到端 27.4 s、1,024 token，是 prefill 主导（约 64K prompt token），不能当 decode 聚合看。

5. A/B 结果：radiance vs paiton-65k（2026-10-19，同一脚本）

同一 /data/ai/radiance/bench_ab.py，同一批 prompt（nonce 防缓存、cached_tokens==0），
prose 输出 256 token，3 次取中位数；paiton 侧带 chat_template_kwargs.enable_thinking=false。

形状	Radiance TTFT / prefill / decode	Paiton TTFT / prefill / decode
64	0.043 s / — / 91.1	0.086 s / — / 43.0
4K	1.38 s / 2,909 / 81.4	1.14 s / 3,533 / 38.3
16K	5.53 s / 2,852 / 78.3	4.58 s / 3,443 / 34.6
32K	11.96 s / 2,629 / 72.3	9.69 s / 3,246 / 36.6
4×16K 端到端	27.4 s / 37.4 聚合	26.3 s / 38.9 聚合
code 768 tokens	132.1 tok/s	65.3 tok/s

结论（以当前安装为准）：

• decode：radiance 快约 2.0–2.3×（prose 72–91 vs 34–43；code 132 vs 65）。
• prefill：paiton 快约 1.21–1.23×（3.2–3.5K vs 2.6–2.9K tok/s）。
• 4 条 16K 长 prompt 同时跑时，端到端几乎打平（prefill 主导）。

重要保留：paiton 启动日志出现

[radiance.w4]  no w4a16 gemm_nt kernel in this r4d build, disabled
[radiance.gemm] no gemm_nt kernel for M<=64 bf16, disabled

这两个 kernel 被禁用；且 paiton 记录里的 225.5 tok/s（英文 code、decode-only）远高于这次的 65.3。
所以 paiton 当前这版可能不是它的最佳状态（镜像/内核覆盖有回退），2× 的 decode 差距里有多少是
引擎差异、有多少是这版 kernel 缺失，需要修好 paiton 镜像后再复测才能定论。

在修好之前，按“当前可用的配置”选型：radiance 在 decode 和上下文容量（418,976 token vs 174,634）上占优，paiton 只在 prefill 上快约 20%。

@fanweng-code 说:

尤其想知道，有沒有人成功讓本地模型在沒有人工一直提醒的情況下，自己探索陌生環境，而且能越做越熟練？

这就是人工智能追求的目标，别说本地模型了，云端大模型都还做不到。

@terry 我是Linux，不是Windows。机智罗的平台是Windows，但是我移植到Ubuntu上也能用。

@abaalei 刚找到原因：Z-image/qwen_3_4b_fp8_mixed.safetensors，换成Z-image/qwen_3_4b.safetensors就好了。也测试了一下V4版的Z-Image-Turbo文生图工作流，也是同样的问题——不能用Z-image/qwen_3_4b_fp8_mixed.safetensors。

晚上搞了一下机智罗图生视频工作流里的SageAtention——失败了！只要打开这个节点就跑不通，绕过这个节点就能连续生10秒的720p视频。

错误信息（太长了，就贴开头）：

PassManager::run failed
ComfyUI Error Report
Error Details

• Node ID: 234
• Node Type: SamplerCustomAdvanced
• Exception Type: RuntimeError
• Exception Message: RuntimeError: PassManager::run failed

问了一下AI，说不是sageattention节点没生效，而是后面在 ROCm/Triton AMD 编译阶段失败。失败发生在：

sageattention/core.py
→ attn_qk_int8_per_block.py
→ triton/backends/amd/compiler.py
→ pm.run(mod)
RuntimeError: PassManager::run failed

AI劝我放弃吧，说Linux下SageAttention本就不成熟。听劝！放弃！

提醒A卡坛友暂时避坑，绕开“XB-BOX Sage注意力加速“这个节点。

软件	本机环境	版本
ROCm / PyTorch ROCm	PyTorch 2.9.1+rocm7.2.1	AMD 官方 release 已有 ROCm 7.2.4。
Triton	3.5.1+rocm7.2.1.gita272dfa8	PyPI 上 triton 最新显示为 3.7.1
SageAttention	sageattention==1.0.6	公开 PyPI 版本序列 1.0.6 为最新可装版本

System Information:

• Motherboard: MAXSUN MS-Terminator B850M PRO
• Memory: 128.0 GiB
• Processor: AMD Ryzen 7 9700X × 16
• Graphics: AMD Radeon Graphics
• Graphics 1: AMD Radeon AI PRO R9700
• Disk Capacity: 3.1 TB
• Firmware Version: B2.5D
• OS Name: Ubuntu 24.04.4 LTS
• Kernel Version: Linux 6.17.0-35-generic

我是分了两个Hermes profile，一个接deepseek-v4-flash，一个接本地模型，接云端模型的打开self-improvement，接本地模型的关闭self-improvement，耳朵听不见显卡风扇噪音就不烦了。