抡锤者

感觉上下文太长，失忆了？

@terry 我也不知道是哪里， codex说它改好了。。。

128G ram， 最高跑到UD-Q5_K_XL， 最低测了IQ4_XS-v31 + N-gramQ8. 发出来方便大家参考

硬件 / 软件环境

项目	环境
CPU	AMD Ryzen 9 5900XT，16核32线程，AVX2
GPU	AMD Radeon RX 7900 XTX，24GB，gfx1100
内存	128GB；系统可用约125.7GiB
模型存储	XG7000 1TB NVMe，ZFS
系统	TrueNAS 25.10.7，Linux 6.12.105-production+truenas
AMDGPU	7.1.9.31600000
ROCm	10.1.0，系统路径 /opt/rocm
hipBLASLt	100401，匹配 gfx1100 调优表（43行）
推理后端	Strata RDNA3 fork，具体引擎版本见下表
GPU 队列	引擎 GPU_MAX_HW_QUEUES=6；视觉助手限制为2
ZFS ARC	自动管理，zfs_arc_max=0

文件体积与速度总表

PP = prefill，TG = decode，速度单位均为tokens/s；每格按 PP / TG 排列。GB按10⁹字节，括号GiB按2³⁰字节。

配置	引擎版本	原GGUF分片合计 GB（GiB）	实际N-gram / PLE	GGUF＋所用外置表 GB	约8K输入 PP / TG	长输入 PP / TG
IQ4_XS-v31	0.1.49.1	93.67（87.24）	外置Q8_0，54.40GB；mmap；1MiB块	148.07	802.3 / 65.5	32K：1126.8 / 62.7；128K：1489.9 / 60.0
UD-Q4_K_XL	0.1.43	111.33（103.69）	内置IQ4_NL，28.80GB；ram	111.33	2082.7 / 57.4	64,358 tokens：3670.2 / 58.3
UD-Q5_K_XL	0.1.49.1	158.29（147.42）	外置Q8_0，54.40GB；direct；16KiB块	212.69	1600.5 / 46.0	32K：2368.5 / 50.9；128K：3432.4 / 47.4

体积口径： 原GGUF分片合计包含包内N-gram。IQ4_XS和Q5_K_XL另外使用独立Q8表，所以额外计入54.40GB；Q4_K_XL直接使用包内28.80GB的IQ4_NL表，不再重复加一次。合计不含native pack、MTP、视觉投影及备用文件，不等于RAM占用。

测速口径： IQ4_XS与Q5_K_XL取对应最终配置的固定新输入记录，temperature=0、top_k=1、top_p=1、seed=42，各输出384 tokens，禁止prompt复用。Q4_K_XL取最终版本的完整无缓存日常日志：约8K一栏为11条记录的中位数，输入7,961～8,072、输出158～506 tokens；64,358一栏为单次150-token输出。Q4日常请求的实际采样未统一。不同输入语料、输出长度、PLE方式和引擎版本的结果只作整套配置参考，不作为严格同条件量化排名。

三套共用参数

以下是启动参数片段，公共段与对应方案段合并使用。模型、pack、MTP和profile路径按各自安装目录填写；数值取实际最终配置。

--pack "$PACK_DIR" \
--native "$MODEL_GGUF" \
--expert-profile "$EXPERT_PROFILE" \
--mtp "$MTP_DIR" \
--expert-cache auto \
--max-context 153600 \
--spec 5 \
--spec-min-p 0.70 \
--mtp-window 4096 \
--mtp-q4 all \
--pcie-frac 0.20 \
--kv int8 \
--kv-resident 32768 \
--pool-tasks 96 \
--ple-row-cache 1048576 \
--prompt-cache 12 \
--prompt-cache-tail \
--adapt-every 1 \
--adapt-decay 0.97 \
--conversation-cache-min-tokens 2000 \
--conversation-cache-min-free-mib 2048 \
--stats \
--vision

公共MTP数据目录为rt格式。三套默认采样均为temperature=0.5、top_p=0.95、top_k=40；客户端显式参数可以覆盖默认值。

1. IQ4_XS-v31

• 引擎：RDNA3 0.1.49.1。
• 主模型：UD-IQ4_XS-v31，4个GGUF分片。
• PLE：独立Q8_0表，mmap读取；实际文件为1MiB ZFS数据块。
• 专家arena约56.24GiB，不含N-gram缓存、KV和系统开销。

--pool-workers 12 \
--prefill 32768 \
--vram-reserve-mib 768 \
--ple-io mmap \
--ple-gguf "$Q8_ENGRAM" \
--adapt-swaps 80 \
--conversation-cache-mib 4096 \
--conversation-cache-slots 4 \
--mtp-draft-vocab "$ZH60K_DRAFT_VOCAB"

对应方案环境变量：

export STRATA_PREFILL_CPU_SHARE=0.6
export STRATA_PREFILL_CPU_SHARE_MAX=7936
export STRATA_ADAPT_OVERLAP=1
export STRATA_TOPK_SPLIT_MIN=98304
export STRATA_QSA_ROWS=1
export STRATA_ENGINE_NICE=0

2. UD-Q4_K_XL

• 引擎：RDNA3 0.1.43。
• 主模型：UD-Q4_K_XL，4个GGUF分片。
• PLE：直接使用包内的IQ4_NL表，ram模式锁入内存。
• 专家arena约71.73GiB；加上约26.82GiB的PLE表及其他开销，128GB内存接近满载。
• Prefill为auto，最终上限32768；未额外指定mtp-draft-vocab。

--pool-workers 12 \
--prefill auto \
--vram-reserve-mib 512 \
--ple-io ram \
--adapt-swaps 160 \
--conversation-cache-mib 2048 \
--conversation-cache-slots 2

对应方案环境变量：

export STRATA_PREFILL_AUTO_MAX=32768
export STRATA_PREFILL_CPU_SHARE=auto
export STRATA_PREFILL_CPU_SHARE_MAX=6144
export STRATA_PREFILL_MMQ_TILE_ROWS=32
export STRATA_PF_SWITCH_MIN_T=4096
export STRATA_WMMA_GEMM=1

3. UD-Q5_K_XL（当前在用）

• 引擎：RDNA3 0.1.49.1。
• 主模型：UD-Q5_K_XL，6个GGUF分片。
• PLE：独立Q8_0表，direct读取；使用16KiB ZFS数据块的文件副本。
• 专家arena约91.61GiB。N-gram表放在NVMe按需读取，不将整张54.40GB表锁入RAM。
• 所用Q8表与原表字节相同，SHA256校验通过；主模型专家仍完整放在RAM。

--pool-workers 10 \
--prefill 32768 \
--vram-reserve-mib 832 \
--ple-io direct \
--ple-gguf "$Q8_ENGRAM_16K" \
--adapt-swaps 160 \
--conversation-cache-mib 4096 \
--conversation-cache-slots 4 \
--mtp-draft-vocab "$ZH60K_DRAFT_VOCAB"

对应方案环境变量：

export STRATA_PREFILL_CPU_SHARE=0.6
export STRATA_PREFILL_CPU_SHARE_MAX=7936
export STRATA_ADAPT_OVERLAP=1
export STRATA_TOPK_SPLIT_MIN=98304
export STRATA_QSA_ROWS=1
export STRATA_ENGINE_NICE=0

当前Q5配置另通过了两轮150,000-token输入检索验证。GPU加载模型后的待机实测为0%占用、约23W。

共用环境变量

下面是三套配置中取值相同的环境变量；与各方案自己的环境段一起使用。HIPBLASLT_TABLE应指向与本机gfx1100、hipBLASLt 100401相匹配的调优表。

export HIP_PLATFORM=amd
export ROCM_PATH=/opt/rocm
export HIP_PATH=/opt/rocm
export HSA_OVERRIDE_GFX_VERSION=11.0.0
export LD_LIBRARY_PATH=/opt/rocm/lib
export GPU_MAX_HW_QUEUES=6
export STRATA_HIP_WMMA=1
export STRATA_SELECT_WMMA=1
export STRATA_HC_UPMIX=1
export STRATA_HEAD_MIX_MULTI=1
export STRATA_GR_RDNA=1
export STRATA_GR_RDNA_Q8=1
export STRATA_GR_RDNA_A8=1
export STRATA_GR_FUSED=1
export STRATA_GR_INJ_UP=1
export STRATA_GDN_CHUNKED=1
export STRATA_GDN_HEAD=1
export STRATA_GDN_CONVL2=1
export STRATA_GDN_NOY=1
export STRATA_GDN_PP=1
export STRATA_GDN_CHUNK_GDV=0
export STRATA_PF_FUSED=1
export STRATA_PF_GEMM=1
export STRATA_PF_F16=2
export STRATA_PF_HCDOWN=1
export STRATA_PF_PAD=1
export STRATA_PF_GROUP_RES=1
export STRATA_PREFILL_RING=384
export STRATA_QFUSE=1
export STRATA_PA_FAST=1
export STRATA_PA_KLDS=1
export STRATA_KV_HOST_DMA=1
export STRATA_COMBINE_CPU=1
export STRATA_WAIT_FUSE=1
export STRATA_ROUTE_PUBLISH=1
export STRATA_VERIFY_QDEDUP=1
export STRATA_RDNA_MMVQ_WAVE=3
export STRATA_RDNA_Q6K=1
export STRATA_STAGER_RING=64
export STRATA_PEER_TRANSPORT=host
export STRATA_HIPBLASLT_TUNING="$HIPBLASLT_TABLE"
export STRATA_PF_FUSED_KQ=1
export STRATA_FUSE_CONVAB=1
export STRATA_SH_STREAM=0

ZFS的16KiB块需要对应文件实际以该块大小写入；改变dataset的recordsize不会自动改变旧文件的数据块。当前整个models dataset仍为1MiB，Q5所用独立Q8表副本为16KiB。

项目：Strata RDNA3；模型：Unsloth Qwen3.8-Flash-Next GGUF。

@好米玉 别慌，大家都差不多，这里能完全手动设置每个参数的也不多

@terry 读了下作者描述，预估跟rdna3分支提升差不多

@好米玉 新買的 E5 2673 V3 +X99 +128G DDR3 1866 + 舊卡3090 跑 Q4XL 是否要捕到256G? 不用，但 ple io必须 mmap， 不能ram

@rongda-weng 抄作业就好了，基本7900xtx大家都用 nicejunjie的rdna3 folk。刚测了一下，decode比最新的strata快15%的样子

@stxpnet 能请教下，iq4xs + 你的新表，一共占多少vram+ram？ 不知道7900xtx+ 128g能不能塞下

@Thanaots 72g pro 5000 $8999 本地还有一张， 可惜我穷

@Y-G-0 这个是可以的， 我的agent也真的干了， 成功了。rdna3 的作者这几天也有基于新引擎的更新， 我也都测试了。 不过我的问题是，我用128g内存跑Q4_K_XL. 0.1.43引擎可以把PLE io 设成ram （差不多还剩10g的ram余量）， 是最快的。 引擎从某个版本开始， 对内存占用提高了，结果就是只能选direct或mmap，否则就是OOM，把东西挤回硬盘， 都没有原版rdna3设成ram快。 我估计很长一段时间内， 我都没法更新了， 不过这样也比原版strata快不少， 7900xtx单卡， 干长活60tps， 写一段简单代码80+tps

@ralfzhu nb， 不懂就问，什么是干净版，好奇不干净版长什么样

@terry 看帖不够仔细，已经是双卡了哦

真牛， 膜拜。。。。

在linkedin上找到这个分支作者原来是在AMD上班的，这可能是它更熟悉A卡的原因？ 牛的是看他本科，博士都不是科班出身。
顺便分享，我试了他这个分支上周的一个branch，用了稍微新一点的strata引擎，没有换参数，在我的7900xtx是负提升。可能我的设置后上周某个版本的strata不是很兼容。希望他能一直更新下去。

@AGI 说的有道理，我这几个月都在钻研手搓rag。尤其是一开始只有5070， 跑一个27b后，显存就已经很紧张了，随便给点rag，上下文就爆了。 那时我的策略是根目录加一个index， 特定问题只读特定部分。最近用上qfn后，开始放飞自我了，不再刻意给rag瘦身。
另外我的体验是，开放式问题，比如这个帖子里说的中医，其实对本地模型还是有点难。但如果是在rag里给足模版，按照特定流程，生成一个文件，其实模型不用太聪明也能做到。

@terry 我想做一个给数据就自动跑数学模型， 出报告的agent， 一个任务时间比较长， 上下文要多次压缩。 之前用IQ3， 速度倒是快， 但偶尔不稳定， 会陷入死循环的自言自语， 也不是每次都发生， Q4好很多

@懒人烘培 靠你们大佬们加油了， 我抄作业更爽啊

@懒人烘培 嗯， 刚刚测了， 是RNDA3起作用， 退回去， 速度也回去了

@懒人烘培 我看你们100 decode多都是IQ3_s, 我这个size的模型可能也差不多到头了？ 我现在保留所有参数， 让agent帮我退回0.2.8的原版strata， 看看到底是fork在起作用， 还是调的参数在起作用

参考这篇复测帖和部署帖，也在自己的 NAS 上折腾了两天。模型保留原来的 Qwen3.8-Flash-Next UD-Q4_K_XL。
下面是AI总结的速度， 我实际写专业模型代码的速度从60tps升到80多， prefill的体感速度也是快了很多。

最终结果：32K prefill 提升约 20.4%；之后单独校准 decode，同为 12 workers 时提升约 3%–6%。 两轮基线不同，下面分开列。

配置

项目	本机配置
CPU / RAM	Ryzen 9 5900XT，16 核 32 线程 / 128GB
GPU	RX 7900 XTX 24GB，PCIe 4.0 ×16
系统	TrueNAS 25.10.7
驱动 / ROCm	AMDGPU 7.1.9.31600000 / ROCm 10.1 系统 SDK，非 TheRock 轮子
推理框架	nicejunjie/Strata-rdna3，PR #1，commit 309f0c8，engine 0.1.43
模型 / KV	UD-Q4_K_XL / int8，最大上下文 262144

简要优化过程

1. 先照配置跑，再处理本机差异

最初照搬参数，没有复现帖子中的 decode。我的 CPU、量化和测试内容都不同，不能直接拿 IQ3_S 的 100+ tok/s 当目标。

PLE 最后保留 ram，加载日志确认表已锁在 RAM；direct 在这台机器上出现过很慢的随机读取。这个选择主要解决本机加载体验，没有单独做可归因的速度百分比对照。

2. 针对 Q4 测 prefill 开关

逐项及组合测试后，保留：

STRATA_PF_FUSED_KQ=1
STRATA_PREFILL_RING=384
STRATA_FUSE_CONVAB=1

这一轮全部固定 15 workers，比较的是同一 RDNA3 fork 内的参数变化：

指标	调整前	三项开启后	变化
8K prefill，tok/s	2432.4	2631.5	+8.2%
32K prefill，tok/s	3169.4	3815.1	+20.4%
32K 首字耗时，秒	10.39	8.64	−16.8%
32K 完整请求耗时，秒	19.82	17.94	−9.5%

32K 的读取收益在 KQ 融合单项测试中就能重复看到；ring 和 CONVAB 单独开启没有明确收益。三项组合在本轮混合负载中总耗时最低，因此保留，但不把全部提升归功于每个开关，也不将这一轮约 1%–2% 的 decode 波动当成稳定收益。

hipBLASLt 调优表也做了开关对照：这些负载走 WMMA/自定义路径，日志中 hipBLASLt 调用为 0，关表没有改善，因此保留原有 43 行表，没有为了凑参数额外重做。

3. 跑内置 calibrate，再用长输入复测

内置校准约 16 分钟，扫描 PCIe 分工、MTP 阈值、worker 数和专家更新参数。之后把日常 worker 固定为 12 （10-14差别都很小），并补做了 两组都为 12 workers 的对照；上面的三个 prefill 设置在这两组中均保留。

场景	校准前 decode，tok/s	校准后 decode，tok/s	变化
8K 合成代码	55.8	57.5	+3.0%
缓存对话续问	59.4	61.3	+3.2%
32K 合成检索	54.4	57.4	+5.5%
128K 合成检索	57.8	61.4	+6.2%

这一轮 prefill 基本不变，完整请求耗时缩短约 1.2%–2.7%。decode 的百分比不能直接当成整笔任务的提速。12 workers 是最终日常选择，不代表已经证明它是所有负载的最优值。

最终保留的关键参数

以下是关键项，模型路径及其余已有配置省略：

--pool-workers 12
--pool-tasks 96
--pcie-frac 0.20
--spec 4
--spec-min-p 0.70
--adapt-every 1
--adapt-swaps 160
--adapt-decay 0.97
--prefill auto
--ple-io ram
--max-context 262144
--kv int8
--kv-resident 32768
--vram-reserve-mib 512

另外限制 ROCm 队列：主进程 GPU_MAX_HW_QUEUES=6，视觉辅助进程覆盖为 2。模型驻留后的短时观察为 GPU 0% busy、约 14–18W，没有再出现此前待机约 110W 的现象；这是显卡功耗，不是整机功耗。

测试口径与体会

每组先预热，候选每个场景测 3 次取中位数；第一轮基线另复测一次，合并 6 次取中位数。输入为固定的合成代码/检索文本，输出 512 tokens；temperature 0、top-k 1、top-p 1、min-p 0、seed 42，关闭 thinking。新输入确认无提示词缓存复用，续问允许缓存；冷启动时间不计入上述速度。输入输出长度、检索码和固定代码答案检查均通过，但不等于完整的质量评测，也不是实际 DSH 长任务计时。