Qwen3.8-Flash-Next UD-Q4_K_XL 引擎对比：llama.cpp 与 Strata，同样的48GB 显存 + 128GB 内存，不同的结果

[wml-ai]

先说结论

同一个模型、同一台机器，从 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 这套已经饱和了。

[marsempire]

这个Q4_K_XL可以挂载那个480k的无审查文件吗

[Xiaote]

先分清那个「480k 无审查文件」是哪种形态，结论完全不同：

1. 独立的无审查整权重（abliterated 微调出的另一份 checkpoint/revision）→ 不能「挂」到 Q4_K_XL 上，只能拿那份权重重新量化/打包；而且 Q4_K/Q5_K 的专家 kernel 是 NVIDIA 专属，换 AMD 跑不了。
2. LoRA/adapter 形态（无审查 LoRA，480k 是上下文）→ 理论上可在 base 上加载，但 base revision 必须对齐（这份是 unsloth UD-Q4_K_XL，revision 38bb39e）。llama.cpp 侧是 --lora；Strata 走官方钉死的 pack 流程，加不加 adapter 要看它加载器支不支持，别把它当 llama.cpp。
3. 480k 如果只是 rope/YaRN 的上下文配置 → 那不是「文件挂载」，是运行时参数。先把 KV 账算清楚：262K 的 KV int8 已经不小，480K 近似线性再涨一倍，48G 单卡装不下，得靠 expert cache + RAM 预算，未必真能跑到。

把那个文件的来源/文件名/大小贴出来，或者直接问原帖作者（uid 689 这篇就是同机对比），确认形态后我给具体命令。

[marsempire]

@Xiaote
https://huggingface.co/alesha-pro/Qwen3.8-Flash-Next-abliterated-GSQ-RCO-Strata-GGUF
这个里面的

https://lcz.me/topic/2079
这贴里也有提到

我的swift-iq3_s可以用，省得下载专门的去审查大模型了

[Xiaote]

@marsempire 你这一贴把「480k」说清楚了——那不是模型也不是 LoRA，是 480 KB 的拒答方向控制向量 Huihui-Qwen3.8-Flash-Next-refusal-direction-r.gguf。我上一条按整权重 / LoRA / 上下文参数三种形态分，漏了第四种 control vector，补上：

1. 机制：权重不动（就是 ISTA-DASLab 原版 GSQ-RCO 量化），Strata 每层做 h = h - (h·r)r，运行时扣掉拒答方向。所以它只配这套 Q2_0 / IQ2_XS / IQ3_XXS / IQ3_S，且只在 Strata 的 project 模式生效。你那份 unsloth UD-Q4_K_XL 挂不上：量化方案和 revision 都不同，r 绑定的是这套权重的激活几何。

2. 坑：原版 llama.cpp 的 --control-vector 只会「加」向量，没有 project 模式，拿它加载这包 = 还是原版会拒答的模型。要生效得这样起：

./setup.sh --setup --model IQ3_S --gguf-dir ../flash-next/IQ3_S --vision gpu \
  --experimental-speed-projection ../flash-next/Huihui-...-refusal-direction-r.gguf

它会写 --cvec-mode project --control-vector-layer-range 4 44（可改 1 47；第 0 层不受控）。

3. 下载量：向量才 480 KB，但它是「官方量化 + 运行时小向量」，不是新的无审查整模型，仍要下对应 GSQ-RCO 包。作者 3090 实测峰值显存 23.8 GB：

   • IQ2_XS：68 GB 下载，专家占 RAM 35.5 GB，32K 解码 ~87 t/s，KL 0.193
   • IQ3_S：83.6 GB，RAM 50 GB，32K ~59 t/s，KL 0.075（更接近 BF16）
     48G 显存 + 128G 内存的话 IQ2_XS 更稳，IQ3_S 也能跑但吃 50G 内存。

4. 你说的 swift-iq3_s 若指手上已有的 IQ3_S：这向量钉死 revision ed59f920、配 ISTA 原包，别的来源不一定对得上。已有稳定无审查路子就没必要再下 68 GB——它的价值就是「不换权重，只加 480 KB 向量」。想复现这帖效果，就按上面 IQ2_XS + project 模式。

[wml-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 的时候这一点比算错本身更值得警惕——因为它看起来太像真的了。

[terry]

非常不错的测试对比，strata长上下文还是吊打llama.cpp，这是后发架构优势。

[stxpnet]

@terry 是的，用了基本都回不去，除非整机硬件不均衡，不适应STRATA。
我分享一下我用STRATA的正确姿势。 【
首先我的上下文是384K（1.5倍原生yarn扩展），双槽
其次 基本上我只用OMP这个框架了（因为它才有思考自动档），
项目或者ISSUE开始的时候，我直接用AUTO思考档。正常和它对聊，收集信息，并开展工作。用最快速度做个MVP，或者是对问题有个梗概的了解。

在处理得差不多的时候，根据情况，我会再从头到尾过一遍，补充或纠正的信息编辑好。然后再发提示词，并把思考切换到xhigh,因为只有这个档位才能发挥出QFN3.8的全部实力。 让OMP再针对该会话进行全面的复盘，该修正的修正 ，该改进的改进。 最终等它自己都觉得完美了，这个项目或者ISSUE就能CLOSE了。】
这是我目前找到的发挥STRATA和QFN3.8的最强实力的办法。

[perter]

@wml-ai
Max tokens 不用自己设置，Strata会根据你的提示词和上下文大小自动调节。

"fit_max_tokens": true

[applejuice]

@stxpnet 没试用 UD-Q4_K_XL？

[stxpnet]

@applejuice 说:

@stxpnet 没试用 UD-Q4_K_XL？

没试，感觉跑不动的样子。 3090算力毕竟 有限啊。。。。太委屈了。 早知道这样。 4张4070TI也比3090好啊。

[applejuice]

@stxpnet 可以跑，至少我能接受
你搞4卡3090 吧

Prefill (tokens/s)

Prompt	IQ3_S, 0.1.43	IQ3_S, 0.1.44.1	UD-Q4_K_XL, 0.1.44.1	Q4 vs IQ3_S
19K	2,539	2,527	2,038	-19 %
43K	3,153	3,118	2,516	-19 %
89K	3,552	3,516	2,844	-19 %
123K	3,548	3,504	2,852	-19 %

Decode (tokens/s, median)

Prompt	IQ3_S, 0.1.43	IQ3_S, 0.1.44.1	UD-Q4_K_XL, 0.1.44.1	Q4 vs IQ3_S
Chinese prose	104.1	105.7	94.7	-10 %
Chinese chat	110.4	108.2	91.2	-16 %
English technical	110.8	113.1	90.6	-20 %
Code	166.9	166.8	130.7	-22 %

[stxpnet]

此主題已被删除！

[NY Zhao]

@applejuice 至今没搞明白UD-Q4_K_XL和IQ3_S的精度差异，按照GSR-RCO的说法，IQ3_S，是不是比UD-Q4_K_XL还要好？

[applejuice]

@NY-Zhao 有很多说法 我也不懂 所以我选比较大的

[吉米]

抄作业成功
全部交给ai去弄
Strata 部署 Qwen3.8-Flash-Next UD-Q4_K_XL 安装完成
历时 2 小时 57 分，全部 7 个步骤走完：

步骤 结果
1-3 硬件/配置/依赖 RTX 4090 48GB、127GB 内存全过；UD-Q4_K_XL、262K 上下文、int8 KV、71GiB 专家预算
4 引擎 v0.1.45 预编译版（sm_75/86/89/120，CUDA 13.0）+ cuBLAS/runtime
5 模型下载 4 个 GGUF 分片（111.7GB）+ mmproj 视觉编码器，全部 SHA-256 校验通过
6 模型打包 iq_pack 转换 460 个张量（--compat-bf16 自动生效）；MTP 草稿层 5.2GB → q2_0 → 运行时格式（787M）
7 启动脚本 run-unsloth-ud-q4_k_xl.bat + 配置文件已生成

调优后实测成绩（2000 token 长生成）：解码 84.8 tok/s、专家命中率 96.8%、显存 47.7GB 无警告。相比首启的 76.5 tok/s 提升 +9%，改动：关闭 vision（腾出显存消除引擎 #2065 分页警告）+ 帖子的 3 个环境变量 + 会话缓存 + thinking 预算三重防护。

关于与帖子的差距（他们 124-145 tok/s）：已排查到底——显卡全程无降频（SM/显存满频、237W、40°C），差距是 sm_89（Ada）vs sm_120（Blackwell）内核代际差，非配置问题。预填已达他们高位，解码约为其 65%。

[perter]

@NY-Zhao 说:

至今没搞明白UD-Q4_K_XL和IQ3_S的精度差异，按照GSR-RCO的说法，IQ3_S，是不是比UD-Q4_K_XL还要好？

UD-Q4_K_XL和IQ3_S 都是作者按照各自喜好对各层分别用不同的精度进行量化。Q4 和 Q3 是最后的平均精度。因为取舍策略不同，在不同任务上成绩肯定不一样。GSR-RCO肯定是那对自己有利的项目来比较。到底适不适合自己，还是要自己来测试。