抡锤者

g d

一句话结论，省得你翻半天：在真正吃重的三个维度上——难推理/数学、代码、长文档长会话——3-bit 的 IQ3_S 都明显更强（LiveBench 80 题 +8.1 个百分点，p=0.016 显著；代码类 −12.5pp；prefill 快 29%）。4-bit 的 UD-IQ4_XS 只在工具调用这一项上占优（BFCL 核心 7 类 +4.9 个百分点，单轮），中等难度算法题两边打平（630 个配对样本，p=0.093 不显著）。

顺带说一句代价：UD-IQ4_XS 是全线更慢——同负载下 prefill 慢 29%、decode 慢 16%，而 3-bit 这边稳定后基本不读盘。所以「4-bit 一定比 3-bit 聪明」这个直觉，这次实测里只在一个角落成立。

总览（一眼看完）

维度	IQ3_S（3-bit）	UD-IQ4_XS（4-bit）	差距
LiveBench（80 题，推理/数学/代码/语言/指令）	81.5%	73.4%	−8.1pp（p=0.0156 显著）
BeyondBench（29 个共有 medium/hard 任务）	74.3%	73.6%	−0.7pp（打平）
BFCL V4（工具调用，核心 7 类 1390 条）	65.9%	70.8%	+4.9pp（单轮）
prefill（同负载，引擎侧中位）	255 t/s	180 t/s	−29%
decode（同负载，引擎侧中位）	98.4 t/s	82.9 t/s	−16%
MTP 投机接受率	88%	87%	基本一致

两件事值得先记住：① 差距最大、也最贴近日常重活的几项（推理/数学、代码、长上下文、速度）全是 IQ3_S 赢；② 4-bit 唯一的优势项来自单轮 BFCL，±5pp 里含噪声。

免责声明

数据只代表我这台机器、当前 ROCm 栈与引擎版本，不建议外推到别的卡或别的量化。两个模型互斥加载（59GiB 内存只够一个常驻）、同一台机器、同一份引擎、同参数、同题序（同 seed）串行跑。

§1 环境与被测对象

项	值
CPU / 内存	Ryzen 7 9700X（8C/16T）/ 64GB DDR5（实跑 6000，可用 59GiB）
GPU	Radeon AI PRO R9700 32GB（gfx1201 / RDNA4），PCIe 5.0 x16
系统 / 栈	Ubuntu26.04，kernel 7.0.0-30；ROCm 走引擎 venv 内 TheRock wheels（hipBLASLt 1.2.0）
引擎	Strata v0.1.40（上游 `github.com/Niko1221/Strata`，MIT；我只在本机从源码编译 HIP 引擎，代码不是我的）
	IQ3_S	UD-IQ4_XS
---	---	---
量化出处	ISTA-DASLab GSQ-RCO（官方档）	Unsloth Dynamic（第三方重打包）
下载体积	83.6 GB	93.7 GB
路由专家体积	50.3 GB	59.5 GB
专家格式	IQ3_S	gate/up = IQ3_S、down = IQ4_NL（5 层 Q8_0）；dense 侧 Q8_0，打包用 `--compat-bf16`
官方定位	公开测试上追平完整模型	介于 IQ3_S 与 UD-Q4_K_XL 之间

两边完全相同的运行参数：256K 原生上下文、KV int8、KV 常驻 pinned RAM 32K、MTP 投机 --spec 4、服务端 reasoning_effort=none（关思考）、功耗墙 210W、dpm=auto。差别只在加载模式：IQ3_S 跑 low-RAM（mmap 专家 + RAM 副本），UD-IQ4_XS 跑 RAM 预算模式（预算 31GiB，其余按需从文件读）。

测法一句话：三套基准都打同一个 OpenAI 兼容端点、只换 model-id；速度直接取引擎日志（prompt N tokens ... in X ms (P tok/s), M generated in Z ms (D tok/s)），prefill 与 decode 分开统计，累计 4700+ 次请求、约 240 万输出 token。

§2 能力对比

2.1 LiveBench（80 题，10 任务 × 8 题，逐题配对）—— IQ3_S 全线领先的一栏

任务	IQ3_S	UD-IQ4_XS	Δ
reasoning/zebra_puzzle	100.0%	100.0%	0
reasoning/web_of_lies_v2	100.0%	100.0%	0
math/math_comp	100.0%	87.5%	−12.5
math/olympiad	89.4%	55.6%	−33.9
coding/LCB_generation	75.0%	62.5%	−12.5
data_analysis/cta	62.5%	62.5%	0
data_analysis/tablejoin	67.0%	57.5%	−9.5
language/connections	75.0%	62.5%	−12.5
language/typos	62.5%	62.5%	0
instruction_following/summarize	83.3%	83.3%	0
总体（任务均值）	81.5%	73.4%	−8.1

逐题配对：IQ3_S 独对 7 题、UD-IQ4_XS 独对 0 题 → McNemar 双尾 p = 0.0156（显著）。
也就是说这 8 分不是采样噪声：UD-IQ4_XS 连一道 IQ3_S 答错的题都没捞回来，输的全是自己答错的。而它输得最惨的正是最需要长链推理的那几项——奥赛数学 −33.9、代码生成 −12.5、语言推理 −12.5。

2.2 BeyondBench（ICLR 2026 抗污染推理，29 个共有 medium/hard 任务）—— 打平，但 IQ3_S 微微在前

模型	共有任务	任务均值	满分任务	0 分任务
IQ3_S	29	74.3%	18	5
UD-IQ4_XS	29	73.6%	18	5

逐样本配对（同 seed → 同一批题，630 个样本）：IQ3_S 78.3% vs 77.3%，IQ3_S 独对 16、UD-IQ4_XS 独对 7 → p = 0.0931（不显著，但方向是 IQ3_S）。

差距集中在几个「算法味最重」的题上，其余 24 项逐题完全相同：

任务	IQ3_S	UD-IQ4_XS	Δ
edit_distance	66.7%	37.5%	−29.2
knapsack	79.2%	68.8%	−10.4
traveling_salesman	75.0%	66.7%	−8.3
boolean_sat	45.8%	62.5%	+16.7
n_queens	75.0%	87.5%	+12.5

两边同为 0 分的 5 项：algebraic_sequence、complex_pattern、geometric_sequence、prime_sequence、tower_hanoi——这两个量化在这几题上都不会做。

2.3 BFCL V4（工具调用，核心 7 类 = 1390 条）—— 4-bit 唯一翻盘的地方

类别	IQ3_S	UD-IQ4_XS	Δ
Simple AST（总体）	61.7%	66.4%	+4.8
— Python Simple	92.0%	87.2%	−4.8
— Java Simple	41.0%	60.0%	+19.0
— JavaScript Simple	52.0%	52.0%	0
Multiple AST	89.0%	88.0%	−1.0
Parallel AST	55.5%	69.0%	+13.5
Parallel Multiple AST	57.5%	60.0%	+2.5
Irrelevance Detection（该不该调工具）	58.8%	68.8%	+10.0
Non-Live Overall	65.9%	70.8%	+4.9

这是 UD-IQ4_XS 唯一的加分栏，值得记下：它在"并行调用"和"该不该调用"上更稳（+13.5 / +10），Java 那 +19 也很醒目。但请注意这是单轮结果（BFCL 惯例就是单轮），±5pp 里含噪声；而且同栏里 Python 简单调用它反而差 4.8pp——它不是全面更会调工具，是"某些子项上更稳、某些子项上更容易写歪"。

2.4 三套合起来看：能力画像

任务类型	谁强	幅度
竞赛数学 / 长链推理	IQ3_S	olympiad −33.9pp
代码生成	IQ3_S	−12.5pp
算法题（编辑距离/背包/TSP）	IQ3_S	−29.2 / −10.4 / −8.3pp
布尔可满足性、N 皇后	UD-IQ4_XS	+16.7 / +12.5pp
指令遵循 / 摘要 / 逻辑谜题	打平	逐题完全相同
工具调用（尤其并行与"该不该调"）	UD-IQ4_XS	+4.9pp（单轮）

看这一栏的结论很清楚：IQ3_S 赢在"需要真思考"的题目上，而且赢面更大；UD-IQ4_XS 赢在"要不要动手、要不要一次动手多个"的调用判断上。

2.5 比分数更有意思的现象：4-bit 话更多、分更低

同一批题下，UD-IQ4_XS 的输出总量比 IQ3_S 多 56%（147 万 vs 94.4 万 token），但分更低。翻答案能看到原因：

它的答案有效部分明显更短，好几条尾部是推理打转——原话像 Let's re-read the composite part carefully. / No, I used 18 for ... 这种来回自我怀疑；
多条答案直接撞上 12000 token 上限被截断（奥赛题里 IQ3_S 的答案长度接近它的 1.6 倍，反而全须全尾）；
它不是"不会"，而是更容易想岔了之后在原地绕——这在需要一次改对、或者红线约束明确的活上代价很大。

§3 速度对比

3.1 同负载引擎侧数据（这才是可比的口径）

	请求数	prefill 中位 / 均值	decode 中位 / 均值	MTP 接受	输出 token
IQ3_S	1684	255 / 279 t/s	98.4 / 96.5 t/s	88%	944,122
UD-IQ4_XS	2050	180 / 189 t/s	82.9 / 81.9 t/s	87%	1,472,703

prefill（读 prompt）慢 29%、decode（生成）慢 16%——全程一边倒
投机接受率 88% vs 87%，差距不是投机造成的，是模型本身的算力/内存路径
换算成体感：用 4-bit 的代价是每个 prompt 多等约 29%、每个 token 多等约 16%；它这话还更多，实际墙钟差距更大

3.2 各自单独测的场景数字（不同题面，供参考）

场景	IQ3_S	UD-IQ4_XS
15K 左右 prompt 的 prefill	1170-1230 t/s	949 t/s（16.9K prompt）
短问答 decode	55-89 t/s（内容相关）	64.5 t/s
中文长输出 decode	57-61 t/s	57.0 t/s（425 token 输出）
250K 超长上下文	prefill 852-917 / decode 57-59 t/s（本机做过针检索验证）	未验证

3.3 为什么慢：驻留结构不一样（引擎自报）

	VRAM 专家缓存	RAM 常驻专家	文件层
IQ3_S	10,031 slots	25.63 GiB（low-RAM 模式）	稳定后 0 blob 读盘
UD-IQ4_XS	10,677 slots / 24.07 GiB	31.00 GiB（page-locked）	仍有 24.4 GiB 专家要按需读文件

UD-IQ4_XS 的读盘行为实测很具体：首次加载读 25.9 GB；一条 16.9K token 的长 prompt 触发 14.5 GB 读盘（prefill 会把冷专家全拉进来）；但纯聊天/长输出只增 177 MB。所以它是**「短对话几乎不啃盘、长文档读取狂啃盘」**——这正好解释了为什么它的 prefill 掉得比 decode 更狠（−29% vs −16%）：prompt 越长大文件读取越吃亏。而长文档、长会话恰恰是日常最容易碰到的场景。

§4 结论：IQ3_S 更值得留在机器上；4-bit 的价值在一个窄场景

你的用途	更合适	依据
难推理 / 竞赛数学	IQ3_S	LiveBench olympiad −33.9pp
代码生成 / 精确改动既有代码	IQ3_S	LiveBench coding −12.5pp；BeyondBench edit_distance −29.2pp
长文档 + 长会话	IQ3_S	prefill 快 29-42%；250K 上下文做过针检索验证
中等难度算法题	打平（IQ3_S 微微在前）	630 配对样本 p=0.093，方向偏 IQ3_S
出活速度	IQ3_S	decode 快 16%、prefill 快 29%
工具调用 / 函数调用（agent 干活）	UD-IQ4_XS	BFCL +4.9pp（单轮）

我自己的取舍：留 IQ3_S。 我的活是高约束的代码改造（改一个既有 Rust 内核、红线模块零 diff、默认构建要逐位不变），改错一次整批作废，风险在"改对了没有"而不在"工具调用格式对不对"；再加长会话里 prefill 快 29-42% 是实打实的墙钟收益。4-bit 那边我唯一会考虑换过去的场景：如果你的日常主要是 agent 式活（读文件、查数据、串工具为主，推理深度要求不高），那它在并行调用与"该不该调用"上的稳定性可能值那 20-30% 的速度损失——但这属于"按你的活来定"，不是它的能力全面更好。

§5 读这些数时要注意的（影响解读，不是操作指南）

4-bit 的唯一优势项来自单轮 BFCL（±5pp 含噪声），也是本次最难复现的一项；相比之下 LiveBench 与 BeyondBench 都是逐题配对的，可信度更高，而这两套的结果都偏向 IQ3_S。
BeyondBench 有 6 个 hard 任务被框架自身卡住（题目生成器 24 分钟 0/8，或在某些规模参数下 0 秒零样本）→ 这些任务两边一起跳过，是框架问题不是模型问题。
BeyondBench easy 档已饱和（两边都基本满分）→ 有区分度的只有 medium/hard；本次对比只在 29 个共有任务上做。
别只看准确率：UD-IQ4_XS 的低分一部分来自答案被 12000 token 上限截断和推理打转，所以除了 accuracy 还要看答案长度与截断率。
LiveBench 的公开题库只到 2024-11-25（2025 之后的 release 官方不公开），所以想找"更新鲜的题"得换基准，不是换 release。
这个 4-bit 打包用 --compat-bf16，官方自己测过同文件困惑度比 llama.cpp 高 6-9%（修法未进当版）——跟上面"4-bit 在推理题上反而更差"方向一致，但不是因果证明。

数据来源：本机自定义基准流程采集的引擎日志 + 逐题判分明细。三套基准合计 4700+ 次请求、约 240 万输出 token；两个模型同题同参、逐题配对检验。

g d

先把机器和环境交代清楚，免得后面对不上号（这也是我一开始的排查方向之一：先确认不是硬件/环境的问题）。

环境（完整）

机器

CPU：AMD Ryzen 7 9700X（8 核 16 线程，最高 5.58 GHz，L3 32 MB），amd_pstate=active，测性能时把 governor 调成 performance、boost 打开
内存：59 GiB
主卡（跑模型的）：AMD Radeon AI PRO R9700 32 GB（RDNA4 / gfx1201），ROCm 7.2.0，走 HIP 后端
副卡：NVIDIA RTX 4060 8 GB（驱动 610.57.04）——跟这次推理无关，只是插着
系统：Ubuntu 26.04 LTS，内核 7.0.0-30-generic，x86_64

模型

Qwen3.8-Flash-Next，IQ3_S 量化，83.6 GB 的 MoE，两个分片（GSQ-RCO）
上下文 256K，KV 用 int8、kv-resident 32768，MTP 草稿 spec 4，专家缓存开着（GPU 常驻 + 约 28.6 GiB 内存页缓存）
实测速度：decode 54~75 tokens/s（短 prompt 能到 ~89），prefill 约 500~1300 tokens/s（看上下文多长），专家缓存命中率 95~97%——日常用完全够

推理引擎

Strata 0.1.32：开源项目（MIT，上游 github.com/Niko1221/Strata），官方定位是"用一张 12–24 G 的 NVIDIA 卡 + 64 G 内存，在自己电脑上跑 125B 的 Qwen3.8-Flash-Next"，默认面向 N 卡 + Windows/Linux 一键安装
我们是把它搬到 AMD RDNA4 上跑（HIP/ROCm，加上 WMMA、hipBLASLt 调优表这些），所以配置里有一堆 STRATA_HIP_WMMA / STRATA_SELECT_WMMA / STRATA_PREFILL_MMQ 之类的开关
️ 关键前提：这个引擎没配 sampling 的时候默认是贪婪解码（greedy）——对单轮对话/代码生成这种要确定性输出的场景挺合理，但一放进 agent 循环就出大事

Agent 壳

DeepSeek Harness（dsh）0.2.0-rc，agent 跑在 headless / web profile 里；权限模式设成完全放开，沙箱和审批都不介入（先把"卡审批"这条可能性排除掉）
任务是一个 Rust 项目（多文件）的改造：agent 得自己读规格文档 → 改代码 → 编译 → 跑测试 → 写自查报告

结论我先摆这儿，省得你往下翻半天：不是模型笨，是引擎默认走了贪婪解码。而 agent 每跑一步又会把"这次调用+结果"原样塞回上下文，上下文越长越自相似，贪婪一解码，输出就锁死在同一条上——稳定 2-周期。你在提示词里写一百遍"别重复"，它照样重复。

一、现场：看着忙得飞起，其实 53 分钟在空转

看到的	实际
工具调用总数	773
其中两条一模一样的 bash 命令	各 311 次，加起来 622 次（80%）
长啥样	严格 A/B 交替：命令1→命令2→命令1→命令2…（最长"连续相同"只有 2）
那 311 次的结果	字节完全相同（同一个 MD5），而且不空、它想查的字段都在里面
有内容的助手消息	整个回合就 1 条（"我已掌握全部信息，开始实现"）
循环期间写文件	0
正式卡住到被我掐	~53 分钟

掐掉之后 git status 看一眼：干净。一个字没写。

记个教训："文件 mtime 是新的 / 事件数在涨 / 进程活着"这三件事，全都是假信号。 复读的时候这三样一个不缺。别拿它们判断"agent 在干活"。

二、我踩过的坑（这些假设全被我否了，贴出来给你省时间）

我一开始的猜测	后来怎么否的
上下文被裁剪，它"忘了自己读过"	时间线对不上：裁剪事件循环前后都有（11+4+1），而且循环期间每 10 分钟就裁一次。既不充分也不必要
grep 窗口开小了，没看到想要的字段	直接否：311 次输出完全相同、非空、字段齐全。信息一直在上下文里
它幻觉出一个不存在的类型，才反复 grep	只解释"为什么盯着同一个文件"，不解释"结果一模一样还重发"。换个真名重查，照样循环
harness 根本没做重复检测	方向对、事实错：harness 自带重复提醒插件，默认还开着

那自带的守卫为啥没拦住？三层全漏：

它只数连续相同的调用 → 我这是 A/B 交替，"连续计数"永远是 1，阈值（3/5/8 三档）根本够不着 ⇒ 全场就响了 2 次；
它拿整个参数对象当键 → 模型只要把 description 改一下（"第 N 次执行"），再随手补两个无关字段，就一次都数不上；
它只往上下文里塞提醒文字，不动控制流 → 后来实测提醒响了 8 次（连最高档都响了），模型在正文里连着写了三次"我已停止重复调用"——然后继续发同一条命令。

三、真根因：引擎默认贪婪 × 自相似上下文

证据是一步步挖出来的：

抓会话里每一轮的请求头：只有 {provider, model, maxTokens}，没有 temperature；
翻 harness 的适配层代码：只有显式设置了 options.temperature 才会把它带上（if (options.temperature !== undefined)）；
看引擎侧 run config：没有 sampling 段 → 走引擎默认，而这个默认就是贪婪；
于是闭环成立：同一段上下文 → 同一个 argmax → 同一条命令；而 agent 每步都把"这次调用 + 结果"追加进上下文，上下文自相似 → 输出自相似 → 卡成 2-周期；
反证：引擎 run config 里加上 temperature=0.3 之后，同一个请求连发 3 次，输出各不相同（贪婪时是逐字节一样的）。

为什么"写规矩"治不了这个病？

我在任务书里加过一整套硬条款（同一条命令最多 2 次、一次读够、连续 5 次没推进就停下写报告）。结果：模型嘴上照做、行为照旧。

道理很简单：贪婪解码下它没有"换个说法"的自由度。只要上下文差不多，输出就是那一条。这不是听话不听话的事。

四、修：两头一起上（有前后对照）

1）引擎侧——治根因（改配置，不用改引擎源码）

sampling: { temperature: 0.3 }

为什么改引擎不改 harness：大多数 harness 没有 per-model 采样字段，改引擎一次覆盖所有客户端；请求里显式带了 temperature 时，还是以请求为准。
验证：引擎日志出现 sampling defaults from the config: temperature=0.3，同请求连发 3 次输出不同。
️ 有个副作用得知道：改完同一个输入不再有可复现的输出。以后别拿"同输入同输出"当验证手段了，要判稳不稳，就统计多次运行的重复率。

2）harness 侧——兜底熔断

判据（命中任一就动手）：

滑窗：最近 20 次调用里，同一条"语义载荷"出现 ≥8 次（bash 取整条 command，读写取文件路径+内容）——滑窗这一条专门干"连续判据抓不到的 A/B 交替"；
无信息：连续 10 次调用既没写文件、也没出现"以前没见过的调用"。

处置两级：

第一次命中：把这次调用拦下来，把"别重复了、用已有信息收尾"当工具结果还给模型；
再犯：直接结束回合并落日志。

写插件踩的两个坑：① harness 官方的"优雅收尾"接口在工具执行体外面调用没效果（收尾标记在更早阶段就结算了）；② 拦调用时返回的反馈必须是"内容块数组"，塞字符串会报 content.map is not a function。

3）前后对照（同任务、同模型，隔离副本里跑，真实仓库零改动）

	修之前	修之后
工具调用	101	153
滑窗内重复峰值	9（最长连续 9）	1
自带提醒命中	8 次（含最高档）	0 次（压根没复读）
写文件	0	新模块 13.6KB + 3 个文件改动，还顺带出了演示和性能数据
结局	回合 `completed`、退出码 0、答复"我已掌握全部信息，转入实现" ⇒ 假完工	正常推进中，被我按时间上限掐断

再记一个坑：退出码 0 + completed ≠ 有产出。 判断有没有干活，用"工作区指纹"：git status --porcelain -uall + git diff --numstat + 源码最新 mtime。别拿命令文本猜"这算不算写盘"——agent 爱用 bash heredoc 落盘，2>&1 这种字串一眼看过去很像写操作，其实什么都不是。

五、同样在跑本地 agent 的，照这个清单查

先看你的客户端到底把采样参数发出去了没——抓一次请求体，看有没有 temperature。适配层"你不设置我就不带"是常态。
再看引擎/服务端默认用什么采样——不少后端默认就是 greedy（单轮推理常这么配），放到 agent 场景直接放大成复读。
重复判据用"滑窗内出现次数"，别用"连续相同次数"——A/B 交替能骗过所有连续判据。
提醒 ≠ 拦截：只往上下文里塞提示的守卫，对这个病没用，必须"先拦调用、再结束回合"。
判产出用工作区指纹，别信 mtime / 事件数 / 进程存活 / 退出码。
调参和复现一定放隔离副本里跑：agent 会照着文档里的绝对路径直接改你的真实仓库（实测它的 grep 全打在真实仓库路径上）。unshare -m + bind 挂一个副本最省事。
把"假完工"当一等失效模式：回合 completed、工作区纹丝不动——长任务里这比直接崩还贵。

六、还没搞定的

temperature=0.3 是"能跑"的起点，我没做系统调参。要是发现输出发散、格式不稳，可以试 0.2 + repetition_penalty 1.05，判据还是"多次运行的重复率"，别看单次。
熔断里"语义载荷"的定义：bash 取整条命令、写工具取"路径+内容"。实测仍有小概率把同一个文件的密集分段编辑误判成重复（后来把写工具的键改成"剔除包装字段后的整参数"——只改 description 的重复照样抓到，内容变了就不算重复）。
这是单机、单模型、单个任务的经验（n=1）。如果你也遇到过"交替型"复读，欢迎补充：别的模型/引擎是不是也能用"greedy + 自相似上下文"解释掉。

七、附：后端模型启动脚本（可直接抄）

1）引擎运行配置 `strata-iq3_s.json`

本次修复加的就是最后那个 sampling 块——不写它，引擎默认贪婪：

{
  "exe": "$HOME/Strata/engine/strata",
  "args": [
    "--pack",            "$HOME/Strata-iq3s/packs/iq3_s",
    "--native",          "$HOME/Strata-iq3s/models/IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00001-of-00002.gguf",
    "--ple-gguf",        "$HOME/Strata-iq3s/models/IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00002-of-00002.gguf",
    "--expert-profile",  "$HOME/Strata/data/expert-profile.bin",
    "--expert-cache", "auto",
    "--mmap-experts", "--resident-cpu-experts",
    "--prefill", "auto",
    "--spec", "4",
    "--mtp", "$HOME/Strata-iq3s/mtp/rt",
    "--max-context", "262144",
    "--kv", "int8",
    "--kv-resident", "32768",
    "--spec-min-p", "0.5"
  ],
  "cwd": "$HOME/Strata",
  "tokenizer": "$HOME/Strata-iq3s/packs/iq3_s/tokenizer",
  "model_name": "qwen3.8-flash-next-iq3_s",
  "log": "$HOME/Strata/strata-iq3_s.log",
  "backend": "hip",
  "host": "127.0.0.1",
  "port": 8080,
  "env": {
    "STRATA_HIPBLASLT_TUNING": "$HOME/Strata/tools/hip/gfx1201-hipblaslt-100200.txt",
    "STRATA_PREFILL_MMQ": "1",
    "STRATA_PREFILL_RING": "96",
    "STRATA_IO_THREADS": "32",
    "STRATA_HIP_WMMA": "1",
    "STRATA_SELECT_WMMA": "1"
  },

  "sampling": { "temperature": 0.3 }
}

几个参数的作用：--spec 4 + --mtp 是草稿式投机解码；--expert-cache auto + --resident-cpu-experts 让 MoE 专家常驻（GPU 缓存 + 内存页缓存，实测命中 95~97%）；--kv int8 + --kv-resident 32768 是 KV 量化与常驻量；--max-context 262144 = 256K。

2）systemd 用户服务（端口 8081）

# ~/.config/systemd/user/strata-iq3s.service
[Unit]
Description=Strata engine (Qwen3.8-Flash-Next IQ3_S)
After=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/Strata
ExecStart=%h/Strata/.venv/bin/python %h/Strata/serve/server.py \
          --engine strata --config %h/Strata/strata-iq3_s.json --port 8081
Restart=no
TimeoutStopSec=30
KillMode=mixed
MemorySwapMax=0
MemoryMin=24G

[Install]
WantedBy=default.target

️ 这行 MemoryMin=24G 是下限（保内存），别写成 MemoryMax：我们踩过——把它塞进带 MemoryMax=4G 的 cgroup scope 里，模型一涨到 4G 就被内核 OOM 杀掉（看着像"引擎自己崩了"，其实是启动方式的问题）。

3）启动器（精简版：起 / 停 / 等就绪 / 看指标）

#!/usr/bin/env bash
# strata-flash.sh —— 起服务 + 等就绪 + 打印模型与显存
set -uo pipefail
SVC=strata-iq3s.service
PORT=8081
BASE="http://127.0.0.1:${PORT}"
LOG="$HOME/Strata/strata-iq3_s.log"

wait_health() {                      # Strata 加载约 40~60s，别急着判失败
  echo -n "→ 等 health"
  for i in $(seq 1 60); do
    [ "$(curl -s -m 3 -o /dev/null -w '%{http_code}' "$BASE/health")" = "200" ] \
      && { echo " 就绪（约 $((i*2))s）"; return 0; }
    sleep 2; echo -n "."
  done
  echo " ❌ 超时；看日志 $LOG"; return 1
}

case "${1:-start}" in
  start)   systemctl --user start "$SVC" && wait_health
           curl -s -m 5 "$BASE/v1/models" | head -c 300; echo ;;
  stop)    systemctl --user stop "$SVC" ;;
  restart) systemctl --user stop "$SVC"; "$0" start ;;
  status)  echo -n "服务: "; systemctl --user is-active "$SVC"
           curl -s -m 5 -o /dev/null -w "health:%{http_code}\n" "$BASE/health" ;;
  health)  curl -s -m 5 "$BASE/metrics" | python3 -c '
import json,sys
e=json.load(sys.stdin).get("engine",{})
for k in ("model","version","max_context","kv","kv_resident","expert_slots","spec","vram_free_mib"):
    if k in e: print(f"  {k}: {e[k]}")' ;;
  logs)    tail -f -n 80 "$LOG" ;;
  *) echo "用法: $0 [start|stop|restart|status|health|logs]" ;;
esac

单卡机器上记得：这个引擎和别的推理服务（另外的 llama/vLLM）抢同一张卡，启动前先把它们停掉，不然不是端口冲突就是显存不够。

（路径里的 $HOME 按自己的目录替换；上游 Strata 自带的 run-iq3_s.sh 也能起，上面这份是我们这边加了"等就绪 + 健康指标"的日常用版本。）

小注：配置里 "port": 8080，实际启动时由服务单元用 --port 8081 覆盖（同一台机器上 8080 留给别的引擎，方便来回切），别被两个数字绕晕。

最后一句：如果你也撞上 agent 复读，先按上面第 3、5 条把现象量化（滑窗重复率 + 工作区指纹），再去查第 1、2 条的采样。"模型太笨"应该排在最后，不是第一个。

抡锤者

g d

帖子