AMD RX 7900 XTX 部署 Strata / Qwen3.8-Flash-Next IQ3_S 实测记录
1. 硬件与前提
| 项 | 值 | 是否影响本文结论 |
|---|---|---|
| GPU | AMD RX 7900 XTX 24G(Navi31 / gfx1100) | 是,必须是 gfx1100 |
| CPU | Ryzen 9 3900X(12C/24T,全大核) | 影响解码速度,见 §6 |
| 内存 | 128GB DDR4-3200(双通道,实测 50.7 GB/s) | 必须 ≥ 96GB |
| 系统盘 | 2TB NVMe | 模型 78GB + pack 1.5GB |
| 操作系统 | Ubuntu 24.04 | |
| ROCm | 7.2.4.70204(装在 /opt/rocm) | 系统 ROCm 会被复用,不必装 TheRock wheels |
| 引擎版本 | Strata 6f32ec0(2026-10-04) |
必须满足的三个条件:
内存 ≥ 96GB。IQ3_S 官方标注需 62GB,Strata 加载时实际占 53GB 内存 + 21.9GB 显存。内存不足会退化成 SSD 读专家,首字延迟从 0.4 秒变成分钟级。
已有 /opt/rocm 且含 hipcc / libhipblaslt.so。setup 检测到系统 ROCm 就不下 10GB 的 TheRock wheels,省 10GB 下载和 6 分钟安装。
单卡独占。Strata 占 21.9/24.5GB 显存,不能与其它 GPU 服务并行。
2. 七个会卡住的坑(★ 建议先读完)
这七个都是 setup / 配置层面的问题,不是编程错误。 上游 docs/AMD_HIP.md 未提及,坛内 2059 / 2079 / 2095 / 2089 四帖也未提及。
坑 1 ★ 最隐蔽:--gguf-dir 指向默认路径时,setup 会自己把目录改名
症状(注意 [ok] 之后紧跟 [X],这不是矛盾):
[ok] model files from /opt/strata moved to /opt/strata/data
(a new copy of Strata finds them there)
=== Step 5: downloading Qwen3.8-Flash-Next IQ3_S ===
[X] missing /opt/strata/models/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00001-of-00002.gguf
Setup stopped.
根因:--gguf-dir /opt/strata/models 这个路径被 setup 判定为"它自己的默认目录",于是把整个目录重命名为 data/,然后再去 models/ 找文件——自然找不到。
修法:把 --gguf-dir 指向一个它不会动的目录,用软链接放模型:
mkdir -p /opt/strata/gguf
cd /opt/strata/data/models
for N in 1 2; do
ln -sf "Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-0000${N}-of-00002.gguf" /opt/strata/gguf/
done
ln -sf mtp-q2_0.gguf /opt/strata/gguf/
坑 2 ★ 最耗时:模型文件名两边都不一致
对照:
| 来源 | 文件名 |
|---|---|
| setup 期望 | Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00001-of-00002.gguf |
| HF 实际 | IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-IQ3_S-00001-of-00002.gguf |
差异两处:HF 多了 IQ3_S/ 子目录 和 abliterated 字样。
根因(setup.py 源码):
# setup.py:92 写死官方原版仓库
HF = hf("ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF")
# setup.py:187 文件名模板不含 abliterated、无子目录
"file": "Qwen3.8-Flash-Next-GSQ-RCO-{q}-0000{i}-of-00002.gguf"
坛内推荐的 SC117/...abliterated-GGUF 仓库是扁平结构 + 带 abliterated + 有子目录,与模板不匹配。
修法:下载后重命名对齐。
BASE="https://huggingface.co/SC117/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUF/resolve/main"
cd /opt/strata/models
for N in 1 2; do
curl -L -C - -o "Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-0000${N}-of-00002.gguf" \
"$BASE/IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-IQ3_S-0000${N}-of-00002.gguf"
done
必须校验字节数(curl 断点续传可能造成尾部或长度偏差):
stat -c %s /opt/strata/models/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-0000{1,2}-of-00002.gguf
# 期望:55063448064 和 28800138432
head -c 4 <文件> | xxd # 必须是 47475546("GGUF")
本机实测:55063448064
/ 28800138432
/ mtp 889017216
,三个 magic 全对。
注:mtp-q2_0.gguf(889MB)setup 会自己从官方仓库拉;若已备好放在 --gguf-dir 里会被复用。
坑 3:绕过 setup.sh 直接跑 setup.py → PEP 668 拒绝
症状:
error: externally-managed-environment
× This environment is externally managed
note: See PEP 668 for more information.
根因:setup.sh 第 37 行本来会建 venv,跳过它就没有隔离环境:
# setup.sh:36-39
$PY -m venv .venv || { rm -rf .venv; echo "could not create .venv: sudo apt install python3-venv"; exit 1; }
exec .venv/bin/python setup.py "$@"
修法:走 setup.sh,或手动补齐:
sudo apt install -y python3-venv python3-full
python3 -m venv .venv
坑 4:python3-venv 明明装过,apt install 却静默跳过
症状:python3 -m venv .venv 报缺模块,但 apt install python3-venv 无任何报错。
诊断:
dpkg -l python3-venv | tail -1
# +++==============+=============+=============+===============+
# un python3-venv <none> <none> (no description available)
# ^^ 状态是 un,不是 ii(installed)
根因:un = unknown / not-installed。该包是手工装进系统的,不在 apt 数据库里,apt install 认为"名字已匹配"就直接跳过。
通用判据:apt list --installed | grep <包名> 无输出 且 dpkg -l 显示 un ⇒ 就是这种状态。此时 apt install 无效,直接 python3 -m venv 试(真缺包会报错,报错再装)。
坑 5:--vision cpu 需单独编译编码器,编译完成前测试会拿到错误
症状:setup 跑完,配置里已有 vision 段,但服务重启后:
{"architecture": {"input_modalities": ["text"]}} // 图像没开
或直接 HTTP 400 Bad Request。
根因:AMD 后端没有 GPU 图像编码器(STRATA_VISION_CUDA=OFF),setup 会额外编译一个纯 CPU 的 strata-vision(7.5MB,131 个编译目标,2-3 分钟):
Compiling the image encoder (for the CPU) ...
cmake --build build-vision --target strata-vision -j 12
[ok] engine: .../strata, image encoder (CPU): .../strata-vision
若此时就重启服务测试,会拿到旧状态。必须等这行 [ok] 出现。
关键事实:AMD 上的 GPU 图像路径不存在(setup.py 原文):
if asked in ("yes", "gpu"):
warn("the AMD backend has no GPU image encoder yet: images off"
+ ("" if WIN else " (--vision cpu reads them on the CPU)"))
即 --vision yes 和 --vision gpu 在 AMD 上都退化为"关闭图像"。要图像只能 --vision cpu。
验证配置已生效:
curl -s http://127.0.0.1:8090/v1/models | python3 -c "import sys,json;print(json.load(sys.stdin)['data'][0]['architecture'])"
# 期望:{'input_modalities': ['text', 'image'], ...}
开销实测(比坛内普遍说的 10-30 秒快很多):336×336 图像额外 1.9 秒,512×512 额外 3.6 秒。配置里 threads: 12(全部物理核)起了作用。
坑 6:--calibrate 在 AMD 上静默跳过,且补不了 hipBLASLt tuning table
症状:加 --calibrate 后,1 秒结束,无 settings.json,配置零变化。
开始 09:25:05 → 结束 09:25:06 退出码 0
settings.json: 无
配置: 未变
根因:对应 setup.py 的 #566(AMD 校准功能仍在验证中)。
更重要的是:它补不了 tuning table。 那张表是仓库里的静态文件(setup.py:1833):
def hipblaslt_table(arch, lib_dirs, ver=None):
"""tools/hip/<arch>-hipblaslt-<version>.txt for this card AND the installed hipBLASLt, else None"""
table = ROOT / "tools/hip" / f"{arch}-hipblaslt-{ver}.txt"
现有表:
| 文件 | 适用 |
|---|---|
| gfx1100-hipblaslt-100100.txt | gfx1100 + hipBLASLt 100100 |
| gfx1100-hipblaslt-100200.txt | gfx1100 + hipBLASLt 100200 |
| gfx1200-hipblaslt-100202.txt | RDNA4 (gfx1200/1201) + 100202 |
| — | gfx1100 + 100202 无(ROCm 7.2.x 即此版本) |
结论:gfx1100 + hipBLASLt 100202 这张表上游没有,--calibrate 也生成不出来。 这条 [!] 警告可以无视——官方确认缺表会安全回退:
The runtime guards architecture, library version and actual shape/stride/workspace requirements, falling back when a table entry is unavailable or incompatible.
只影响 dense prefill 速度,不影响正确性。
坑 7:默认端口 8080 撞 llama.cpp,且默认只监听 127.0.0.1
症状一:同机跑 llama-server / Ollama 时,Strata 起不来或互相抢占。
修法:用 --port 改(本机用 8090)。
症状二:局域网内其它机器 curl 返回 HTTP 000,但 ping 通。
根因:Strata 默认只听 127.0.0.1。
修法:在 run-iq3_s.sh 里显式加 --host 0.0.0.0:
# /opt/strata/run-iq3_s.sh 完整内容
#!/bin/sh
cd "/opt/strata"
exec "/opt/strata/.venv/bin/python" "/opt/strata/serve/server.py" \
"--engine" "strata" \
"--config" "/opt/strata/strata-iq3_s.json" \
"--host" "0.0.0.0" \
"--port" "8090" \
"--open"
️ 加了 --host 0.0.0.0 后,局域网内任何设备都能访问这个无鉴权端点。 是否收回请自行判断网络环境。
3. 完整部署步骤(可复制)
3.1 环境自检(不装任何东西,1 分钟)
cd /opt/strata # git clone --depth 1 https://github.com/Niko1221/Strata.git .
python3 setup.py --check
期望输出:
[ok] GPU: AMD Radeon RX 7900 series (gfx1100), 24.0 GB VRAM, gfx1100
[ok] RAM: 126 GB
[ok] CPU: AMD Ryzen 9 3900X 12-Core Processor (AVX2)
IQ3_S needs ~62 GB RAM: fits
This PC can run Strata.
若 IQ3_S ... EXPERIMENTAL 或 doesn't fit ⇒ 内存不足,换 IQ3_XXS(需 ~60GB)或 IQ2_XS(~48GB)。
3.2 准备 venv(见坑 3、坑 4)
sudo apt install -y python3-venv python3-full
python3 -m venv .venv || { echo "venv 创建失败,检查 python3-venv"; exit 1; }
.venv/bin/python --version # 期望 Python 3.12.x
3.3 下载模型(见坑 2)
78 GB,本机实测 9 小时 16 分(夜间掉速;峰值 26 MB/s)。务必用 setsid 脱离 SSH 会话:
mkdir -p /opt/strata/models
cd /opt/strata/models
BASE="https://huggingface.co/SC117/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUF/resolve/main"
setsid nohup bash -c '
cd /opt/strata/models
for N in 1 2; do
curl -L --retry 8 --retry-delay 15 --retry-all-errors -C - \
-o "Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-0000${N}-of-00002.gguf" \
"https://huggingface.co/SC117/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUF/resolve/main/IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-IQ3_S-0000${N}-of-00002.gguf"
done
' > /dev/null 2>&1 < /dev/null &
校验(见坑 2):
stat -c "%n = %s" /opt/strata/models/*.gguf
# 期望 55063448064 / 28800138432
3.4 建软链接目录(见坑 1)
mkdir -p /opt/strata/gguf
cd /opt/strata/models
for F in Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00001-of-00002.gguf \
Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00002-of-00002.gguf \
mtp-q2_0.gguf; do
[ -f "$F" ] && ln -sf "$(pwd)/$F" /opt/strata/gguf/
done
ls -l /opt/strata/gguf/
3.5 执行 setup(自动编译引擎 + 准备 pack)
cd /opt/strata
.venv/bin/python setup.py \
--backend hip \
--family qwen \
--model IQ3_S \
--context 131072 \
--vision cpu \
--port 8090 \
--gguf-dir /opt/strata/gguf \
--data-dir /opt/strata/data \
--vram-reserve-mib 3000 \
--no-start \
--yes
各参数含义:
| 参数 | 值 | 为什么 |
|---|---|---|
| --backend hip | — | AMD GPU 必需 |
| --model IQ3_S | — | 3.5-bit i-quant,官方标注质量等同整模 |
| --context 131072 | 128K | 实测四档通过(§7) |
| --vision cpu | — | AMD 上唯一可用的图像路径(坑 5) |
| --port 8090 | — | 避开 8080(坑 7) |
| --gguf-dir | 独立目录 | 防 setup 改名(坑 1) |
| --vram-reserve-mib 3000 | 3 GB | 与 @guonetnet 一致,直接抄 |
| --no-start | — | 只装不启,便于先改 --host |
期望输出(关键行):
[ok] engine: /opt/strata/engine/strata, image encoder (CPU): .../strata-vision
[ok] vision encoder: /opt/strata/data/models/mmproj-Qwen3.8-Flash-Next-BF16.gguf
[ok] model prepared: /opt/strata/data/packs/iq3_s
[ok] MTP draft layer: /opt/strata/data/mtp/rt
[ok] KV streaming on: the context's KV cache lives in RAM (1.8 GB)
[ok] VRAM kept free for other programs: 3000 MiB
[ok] start script: run-iq3_s.sh
编译耗时参考:引擎 1 分钟(复用系统 ROCm,官方估 10-20 分钟);strata-vision 2-3 分钟;pack 准备 16 分钟。
️ strata-vision 那行 [ok] 出现前不要测图像(坑 5)。
4. 单卡互斥:与 llama.cpp / ComfyUI 共存
目录完全隔离,不存在互相覆盖:
| 服务 | 路径 | 模型 | 端口 |
|---|---|---|---|
| Strata | /opt/strata | /opt/strata/models | 8090 |
| llama.cpp | /opt/llama | /opt/llama/models | 8080 |
| ComfyUI | /opt/comfyui | /opt/models | 8188 |
唯一共享资源是 GPU。用 systemd Conflicts 自动互斥:
# /etc/systemd/system/strata.service
[Unit]
Description=Strata (Qwen3.8-Flash-Next abliterated IQ3_S, AMD HIP)
After=network-online.target
Conflicts=comfyui.service llama-server.service
[Service]
Type=simple
User=ubuntu
WorkingDirectory=/opt/strata
ExecStart=/opt/strata/run-iq3_s.sh
Restart=on-failure
RestartSec=15
TimeoutStartSec=600
Environment=HOME=/home/ubuntu
Environment=ROCR_VISIBLE_DEVICES=0
Environment=HIP_VISIBLE_DEVICES=0
StandardOutput=append:/opt/strata/service.log
StandardError=append:/opt/strata/service.log
[Install]
WantedBy=multi-user.target
另两个 unit 各加一行 Conflicts=strata.service:
sudo sed -i "s|^Conflicts=|Conflicts=strata.service\nConflicts=|" /etc/systemd/system/comfyui.service
sudo sed -i "s|^Conflicts=|Conflicts=strata.service\nConflicts=|" /etc/systemd/system/llama-server.service
sudo systemctl daemon-reload
切换脚本(任意路径可用):
#!/bin/bash
# /opt/strata/switch.sh
T=${1:-}
case "$T" in
comfyui)
sudo systemctl start comfyui
for i in $(seq 1 30); do sleep 6
[ "$(curl -s -m 3 -o /dev/null -w %{http_code} http://127.0.0.1:8188/system_stats)" = "200" ] && { echo "ComfyUI 就绪"; exit 0; }
done ;;
llama)
sudo systemctl start llama-server
for i in $(seq 1 30); do sleep 4
[ "$(curl -s -m 3 -o /dev/null -w %{http_code} http://127.0.0.1:8080/v1/models)" = "200" ] && { echo "llama-server 就绪"; exit 0; }
done ;;
strata)
sudo systemctl start strata
for i in $(seq 1 40); do sleep 10
[ "$(curl -s -m 5 -o /dev/null -w %{http_code} http://127.0.0.1:8090/v1/models)" = "200" ] && { echo "Strata 就绪"; exit 0; }
done ;;
status) for U in comfyui llama-server strata; do printf " %-14s %s\n" "$U" "$(systemctl is-active $U)"; done ;;
*) echo "用法: $0 {comfyui|llama|strata|status}" ;;
esac
实测三轮切换无损:
Strata → ComfyUI HTTP 200 VRAM 277 MiB
ComfyUI → llama HTTP 200 VRAM 21286 MiB
llama → Strata HTTP 200 VRAM 21853 MiB
5. 验证:确认真的在跑
5.1 最小冒烟(3 秒出字)
curl -s http://127.0.0.1:8090/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"local","messages":[{"role":"user","content":"说:你好"}],"max_tokens":20,"stream":false}'
5.2 流式测速(★ 必须用流式,非流式数字会低 4 倍)
import json, time, urllib.request
body = {"model":"local","messages":[{"role":"user","content":"用中文详细解释什么是向量数据库,举三个实际应用例子。"}],
"max_tokens":600, "stream":True}
req = urllib.request.Request("http://127.0.0.1:8090/v1/chat/completions",
data=json.dumps(body).encode(), headers={"Content-Type":"application/json"})
t0=time.time(); ttft=None; n=0
for raw in urllib.request.urlopen(req, timeout=600):
line = raw.decode('utf-8',errors='replace').strip()
if not line.startswith("data:"): continue
p = line[5:].strip()
if p == "[DONE]": break
d = json.loads(p)
t = (d.get("choices") or [{}])[0].get("delta",{}).get("content") or ""
if t:
if ttft is None: ttft = time.time()-t0
n += 1
total = time.time()-t0
print(f"TTFT {ttft:.2f}s | {n} tok | {n/(total-ttft):.1f} tok/s")
本机期望值:TTFT 1.65-2.57s | 440-470 tok | 64-70 tok/s
️ 非流式测出来的 ~18 tok/s 是错的——那把 prefill + 全部生成 + 传输都算进了总耗时。流式才是真实体感。
5.3 长上下文验证
filler = "数据分析与机器学习是现代技术的重要方向。" * 2400
body = {"model":"local","messages":[{"role":"user","content":filler+"\n\n请只回答三个字:最后一句?"}],
"max_tokens":50,"stream":False}
# 期望:prompt_tokens ≈ 96000,耗时 < 90s,回答正确指出最后那句
5.4 图像验证(见坑 5,必须等 strata-vision 编译完)
import base64, json, time, urllib.request
b64 = base64.b64encode(open("/path/to/test.png","rb").read()).decode()
body = {"model":"local","messages":[{"role":"user","content":[
{"type":"text","text":"图中有几个圆形的物体?它们是什么颜色?"},
{"type":"image_url","image_url":{"url":f"data:image/png;base64,{b64}"}}]}],
"max_tokens":300,"stream":True}
req = urllib.request.Request("http://127.0.0.1:8090/v1/chat/completions",
data=json.dumps(body).encode(), headers={"Content-Type":"application/json"})
# 期望:336×336 总 3.4s;512×512 总 5.1s
6. 与 @guonetnet X99 那台的对比
| 项 | X99 四通道(2059) | 本机 3900X 双通道 |
|---|---|---|
| CPU | E5-2683 v3,14C/28T @2.0GHz | Ryzen 9 3900X,12C/24T @3.8GHz |
| 内存 | 64G DDR4-2133 四通道(~68 GB/s 理论) | 128G DDR4-3200 双通道(50.7 GB/s 实测) |
| 预填充 | 1460-1614 tok/s | 900-1330 tok/s |
| 短提示解码 | 40.8 tok/s (IQ3_S) | 67.8 tok/s (IQ3_S) |
| GPU 专家槽 | 8903 | 7818 |
| Strata 版本 | 0.1.34 | 0.1.32(6f32ec0) |
| 亮机卡 | 有(R7 240) | 无 |
| 上下文 | 262144 | 131072 |
| 视觉 | 支持 | 支持(开销 1.9-3.6s) |
值得讨论的一点:按"内存带宽是 MoE 解码瓶颈"的推论,我少 34% 带宽、少 2 核,应该更慢——实测快 1.5 倍。
可能原因:
单核频率差 1.9 倍(3.8GHz vs 2.0GHz)。未命中显存的专家由 CPU 逐个计算,频率权重高于总带宽。
版本差异(0.1.32 vs 0.1.34)。
测试提示词不同(他"常规思考负载",我"解释+三个例子")。
若你是 2.0GHz 时代的 Xeon 平台,可考虑换高主频 CPU 再测。
他的配置确实占优的一项:亮机卡省下 1-3GB 显存,专家槽 8903 vs 7818,PCIe 搬运次数更少。同显存容量下,值得效仿。
6.1 --pool-workers:默认 11 核最优,★ 开满 SMT 会掉 27%
论坛提示"全开超线程反而争用",我在本机做了 A/B 验证(每档 3 次,同一提示词):
| 配置 | decode (tok/s) | σ | 结论 |
|---|---|---|---|
| 默认(不设) = 11 | 64.0 | 3.7 | 最优 |
| --pool-workers 12 | 63.8 | 3.8 | 与默认无差异(在噪声内) |
| --pool-workers 24 | 46.6 | 1.6 | ★ 掉 27% |
结论:不要手动设 --pool-workers,用默认值。
为什么 SMT 会掉这么多——官方 --help 的定义:
--pool-workers N CPU expert pool worker count.
Default 0 = every physical core except the one the host loop spins on
(with --pool-affinity auto or p-cores on a hybrid CPU: P-cores minus 1).
默认是 物理核数 − 1(12 核 → 11),减掉的那个核给 host loop——专职收 PCIe 传输、协调专家调度、维护 KV cache。
SMT 掉速的机理:专家的反量化 + 矩阵乘是 AVX2 整数运算。Zen 3 的 256-bit AVX2 实际拆成两个 128-bit 单元走两条流水线。同一物理核的两个 SMT 线程发到的是同一组向量单元,拿不到 2 倍吞吐,反而多一份 L2/L3 与内存请求队列的争用。
★ 一个反直觉的对照实验——本机内存带宽实测(sysbench):
1 线程 : 45.8 GB/s
12线程 : 41.1 GB/s ← 最差
24线程 : 50.7 GB/s ← 最好
24 线程带宽比 12 线程高 23%,但模型 decode 反而慢 27%。两者不矛盾,因为测的是不同瓶颈:
| 负载 | 瓶颈 | 最优配置 |
|---|---|---|
| 纯内存流式访存(sysbench) | 内存通道 | 线程越多越好 |
| 专家反量化 + AVX2 矩阵乘 | 执行单元 | 只用物理核 |
⇒ 如果你看到 sysbench 说 24 线程带宽更高,别据此去开 SMT。判断依据应是执行单元,不是内存带宽。
关于 12 和 11 相同:说明 host loop 并非"硬占一个核不让碰",而是"最多用 N-1"的上限。既然 12 和 11 无差异,就用默认值,别动。
7. 128K 上下文实测
| prompt_tokens | 耗时 | 速率 | 结果 |
|---|---|---|---|
| 16 061 | 17.8 s | 905 tok/s | ![]() |
| 48 061 | 51.9 s | 926 tok/s | ![]() |
| 96 061 | 72.2 s | 1330 tok/s | ![]() |
| 100 059 | 24.1 s | — | 回答"好的"完全正确 |
每档都准确找出长文末尾那句——KV cache 跨 10 万 token 无退化。
KV streaming 是 128GB 内存最值钱的地方:
[ok] KV streaming on: the context's KV cache lives in RAM (1.8 GB), more experts fit in VRAM
[ok] experts loaded: 46.84 GiB at 4.52 GiB/s (58 s so far)
[ok] filling the GPU's expert cache (7818 experts, 14.82 GiB of VRAM)
KV cache 从显存挪到内存,换来 7818 个专家常驻显存。这是 TTFT 只有 0.43-2.68s 的原因。
8. 启动参数完整清单
/opt/strata/strata-iq3_s.json 的 args 数组:
["--pack", "/opt/strata/data/packs/iq3_s",
"--native", "/opt/strata/gguf/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00001-of-00002.gguf",
"--ple-gguf", "/opt/strata/gguf/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00002-of-00002.gguf",
"--expert-profile", "/opt/strata/data/expert-profile.bin",
"--expert-cache", "auto",
"--prefill", "auto",
"--spec", "4",
"--spec-min-p", "0.5",
"--mtp", "/opt/strata/data/mtp/rt",
"--max-context", "131072",
"--kv", "int8",
"--kv-resident", "32768",
"--vram-reserve-mib", "3000"]
| 参数 | 值 | 来源 |
|---|---|---|
| --spec 4 | 4 | 与 @guonetnet 相同,直接抄 |
| --spec-min-p 0.5 | 0.5 | 同上 |
| --vram-reserve-mib 3000 | 3000 | 同上 |
| --pool-workers | 不设(默认 = 核数−1) | 见 §6.1 |
| --max-context 131072 | 128K | 想跑 262144 可改,注意内存 |
| --prefill auto | auto | 官方自动选择 |
9. 能力验证
| 测试 | 结果 |
|---|---|
| 算术 (17*23+45)/8 | 54.5 ![]() |
| 代码 is_palindrome() | 完整可用,含类型标注 ![]() |
| 逻辑 三开关三灯泡 | 标准三步法 ![]() |
| 工具调用 get_weather({"city":"北京"}) | ![]() |
| 自我认知 | 准确解释 abliterated 技术本质 ![]() |
9.1 Agent 实测:单文件任务
任务:创建 strata_test.txt 写入指定内容,再读回
结果:34.5 秒,2 次工具调用
9.2 Agent 实测:多步 + 计算 + 校验
任务:建 f1/f2/f3.txt 写 1/2/3,求和写入 sum.txt,再列出全部内容
结果:51 秒,10 次工具调用,4 条消息
验证:f1=1 f2=2 f3=3 sum=6(独立 cat 验证,非模型自述)
9.3 Agent 实测:单文件 HTML 游戏(★ 一次成型 + 真机跑通)
任务:用单个 HTML 文件实现贪吃蛇
产物:8.4 KB 单文件(HTML + CSS + JS 全内联)
浏览器真机测试(Chrome 实际加载 + 键盘事件注入 + canvas 像素追踪):
| 功能 | 测试方法 | 结果 |
|---|---|---|
| 页面加载 | document.title / canvas 尺寸 | 贪吃蛇,480×480 |
| 开始流程 | 点击 #startBtn | 覆盖层隐藏,游戏开始 |
| 方向键 | 注入 ArrowUp 事件,追踪蛇头像素 | (196,242) → (196,102) 向上 |
| WASD 双映射 | 注入 KeyD 事件 | (196,102) → (316,102) 向右 |
| 穿墙环绕 | 持续向右 3 次采样 | 436 → 36(480-60-20 精确换算) |
| 移动连续性 | 0.4s × 8 次采样蛇头位置 | 8/8 位置全不同 |
| 暂停冻结 | Space 后 1.2s 位置不变 | ![]() |
| 恢复 | Space 后重新移动 | ![]() |
| 吃食物加分 | 21 秒随机游走 | ️ 未触发,无法证实 |
️ 吃食物一项未能实测:食物坐标在 IIFE 内部,外部无法注入;随机布局下 21 秒内蛇头未与食物重合。代码审查显示逻辑正确(while (snake.some(...)) 避让 + 吃到后 unshift),但未实际验证,不做保证。
代码审查(逐行核对):
| 检查项 | 结果 |
|---|---|
| 单文件自包含 | 8.4 KB |
| 网格 24×24,Canvas 480×480 | 实测确认 |
| 穿墙环绕 (head.x + COLS) % COLS | 实测通过 |
| 禁止 180° 掉头 | if (x === -dir.x && y === -dir.y) return |
| 食物生成避开蛇身 | while (snake.some(...)) 重试 |
| 提速曲线 | 每 50 分一档,Math.max(60, 160 - (level-1)*11) 封顶 60ms |
| 最高分持久化 | localStorage['snake_best'] |
| 键盘监听用 e.code 而非 e.key | 正确,规避输入法干扰 |
| 触屏滑动 | 阈值 20px,横纵取大 |
| 暂停 / 重开状态机 | 实测通过 |
| 蛇身渐变 | rgba(74,222,128, 1-t*0.6) 头尾透明度递减 |
| 眼睛朝向 | 按 dir 偏移 |
| IIFE 作用域隔离 | (() => {...})() |
| Canvas 圆角 | ️ 用了 ctx.roundRect()(Chrome 99+ / Safari 16+) |
| 食物颜色读取 | ️ getPropertyValue('--food') 带前导空格,浏览器可容忍,不如写死 |
结论:一次成型,实测 8 项功能全通过。 两处小瑕疵(roundRect 兼容性、颜色字符串),均不影响运行。
一个测试方法上的提醒:我第一次用"绿色像素总数"判断是否在移动,结论是"
没动"——但那是判据错了,蛇头蛇身同为绿色,蛇移动时总数不变。改用追踪蛇头坐标后立刻看到 8/8 全不同。验证动态行为要用位置/状态,不要用聚合计数。
同一台机上同卡 llama.cpp(Qwen3.8-27B Q4_K_M)对照:
| 引擎 | 模型 | 短提示解码 | 上下文 |
|---|---|---|---|
| Strata | Qwen3.8-Flash-Next IQ3_S (abliterated) | 67.8 tok/s | 131072 |
| llama.cpp Vulkan | Qwen3.8-27B Q4_K_M | 73.9 tok/s | 131072 |
两者解码基本持平(差 8%),但定位不同:
Flash-Next:125B MoE / 6B 激活,128K 上下文 + 视觉 + 无审查
Qwen3.8-27B:稠密模型,逻辑严密场景
Flash-Next 视觉开销 1.9-3.6 秒/图(CPU 编码),27B 无视觉能力。
10. 资料与致谢
坛内参考
@guonetnet — X99 + 7900XTX 24G:四通道内存 + 14 核 CPU + 独立亮机卡(2026-10-03) 本文主要对照基准。 硬件三板斧(内存通道 / CPU 核数 / 亮机卡)、5 个量化档 A/B、参数基线(--spec 4 / --spec-min-p 0.5 / --vram-reserve-mib 3000)、"AMD 三件必须自己补"的判断,均来自此篇。
Niko1221 — 3080 Ti 单卡 12GB 跑 Strata / Qwen3.8 Flash-Next IQ2_XS(2026-10-04)
NY Zhao — 4090 48G + 128G,Strata 部署 Qwen3.8 Flash Next 无审查,均速 180+ tok/s
kop wang — 无审查版来了!Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUF 完全支持 Strata(无审查版仓库来源)
@terry — X99 洋垃圾服务器 E5-2666 V3 + 7900XTX + 4090D 48G
johnnybegood — 单卡 3090 跑 Qwen3.8 Flash Next 可到 100 tok/s
David Zhang — 7900XTX + llama.cpp Qwen3.6 27B TurboQuant + MTP(同卡 llama.cpp 基线:10 tok/s)
CHIA AN YANG — 7900 XTX 跑 Qwen3.8-27B 实测 73.4 t/s(本机同卡 llama.cpp 实测 73.9)
X超哥 — 无审查版 Strata 版部署教程(外部站,2026-10-03;模型档位与体积对照表)
官方仓库 / 文档
引擎:Niko1221/Strata(本机 commit 6f32ec0)
docs/AMD_HIP.md —— §2 坑 5、坑 6 直接引用
docs/AMD_HIP_PERFORMANCE.md
docs/INSTALL.md
官方量化:ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF
无审查版:SC117/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUF
基座 / 视觉 / MTP:Qwen/Qwen3.8-Flash-Next
论坛 2059 提到的社区补丁来源:gfx11 WMMA(PR #260)、hipBLASLt 调优表
本文所有数据均为本机实测(2026-10-04/05),不同硬件 / ROCm 版本会有差异,仅供参考。 §2 七个坑均为实际卡住 20 分钟以上的问题,其中坑 1、2、5、6 在上游文档与坛内现有帖中均未找到。 欢迎交流指正。
贪吃蛇,480×480