AI Max+ 395 定製的docker Qwen 3.8 27b prefill翻倍了

dardeaw feng

Halogen Server 跑 Qwen3.8-27B 完整設定與實測（Strix Halo gfx1151）

昨天看到有人貼特製Qwen 3.8 flash的分享，我去同一個作者的github找27b板來實測分享
這模型約是Q6的精度有這樣的效率真的很驚人，RDNA還有很大的開發空間

實測環境：AMD Strix Halo（Ryzen AI MAX+ 395，Radeon 8060S），2026-09。

1. 案例軟硬體系統

項目	值
APU	AMD Strix Halo `gfx1151`，32 thread
統一記憶體	128 GB（CPU＋GPU 共用池）
系統碟	1 TB NVMe Gen3（系統）
資料碟	2 TB NVMe Gen4（模型全放這，讀 3.8 GB/s）
OS	Nobara 44（Fedora 系，不挑，Ubuntu 24.04+ 也行）
Kernel	7.1.x（要 `/dev/kfd`＋`/dev/dri`，`rocm-smi` 看得到卡就行）
容器	Podman（rootful，要 `--device` 權限；Docker 把 `--group-add keep-groups` 換成 `--group-add video --group-add render`）
ROCm	7.2.4（halogen 自帶 HIP runtime，只借 host 的 kfd／dri；官方用 7.14 測的，7.2 照跑）

2. 特別項目與特殊量化模型介紹

2.1 Halogen 是什麼（跟 llama.cpp 完全不同路）

peonist-ai 寫的專用 HIP 推論引擎（非 llama.cpp fork，從零寫給 gfx1151＋Qwen3.8-27B），只認一顆 U、一個模型家族：

原生 262,144 ctx，Gated DeltaNet 帶 O(1) state（48／64 層根本沒有 KV cache），深度不掉速的本錢
三種 drafter 可選：dflash2（預設）、mtp、serial，可 per-request 切；輸出與 serial greedy byte-identical（每版都驗，不是宣稱）
Prompt cache：暖輪號稱 20× TTFT，跟冷啟動 bitwise identical；要 36.9 GB 空位才會自動開（見 §4.4 坑）
Batched decode：8 並發 4.87×，但跟推測互斥（开了 batch 就沒 speculation，單用戶別開）
OpenAI 相容 API：/v1/chat/completions、streaming、tool calling（qwen-xml 線路格式，server 端自轉，client 照 OpenAI 格式送就行）、reasoning-effort 控制
沒 vision：模型有 vision encoder，引擎不用。多模態需求請繞道。

2.2 特殊量化：p1w4d-d2（~6.3 bpw）

不是 GGUF，是 .hgn 自有格式。策略跟傳統 K-quant 反著來：

Full W4A4 promotion（prefill＋9%，top-1 只掉 0.45pt，深文反而更好）
真 4-bit 的 tensor 只有別人校準過的；激進手法圍在 prefill（不碰 token 生成）
對照：ROCmFP4-Q4（~4.5bpw）、UD-Q4_K_M（~4.8bpw）——halogen 用多 ~40% 位元換品質＋速度

2.3 跟 llama.cpp 體系的根本差異

	halogen	llama.cpp 系（含 fork）
KV 續命	內建 prompt cache（RAM 級）	靠外部 wrapper 落盤＋restore
推測	DFlash2／MTP／serial 可切	MTP 或 DFlash2（二選一編譯期＋權重）
多模型	一顆（Qwen3.8 專用）	router 多模型互斥／並存
管理面	env 全配置（無 config 檔，見 `docs/FLAGS.md`）	preset ini＋systemd
Token 預算	`max_tokens` 含思考，用完直接空回覆＋`finish=length`	thinking 另計或可關

3. 配置流程

3.1 抓 engine＋權重（共 ~39.5G）

# engine（3.5G，無權重）
sudo podman pull ghcr.io/peonist-ai/halogen:0.1.3

# 權重（35.9G checkpoint＋flat tokenizer，裝一次）
pip install -U "huggingface_hub[cli]"
hf download peonist-ai/halogen-qwen3.8-27b --local-dir <MODEL_DIR>/halogen-models
# 得到：qwen3.8-27b-p1w4d-d2.hgn ＋ tokenizer/（chat_template.jinja 等）

也可以容器內自動抓（-e HALOGEN_DOWNLOAD=peonist-ai/halogen-qwen3.8-27b＋rw mount），但 35.9G 第一次等很久，手動先下好比較踏實。

3.2 啟動（VRAM 算好再開，見 §3.3）

sudo podman run -d --name halogen -p 8731:8731 \
  --device /dev/kfd --device /dev/dri --group-add keep-groups \
  --security-opt seccomp=unconfined --ipc=host \
  -v <MODEL_DIR>/halogen-models:/models:ro \
  -v <MODEL_DIR>/halogen-models/tokenizer:/tokenizer:ro \
  ghcr.io/peonist-ai/halogen:0.1.3

健康檢查：curl 127.0.0.1:8731/health（回 status ok＋prompt_cache 狀態；初次載入約半分鐘，mmap 快）。

3.3 VRAM 預算（128G 機器實測表）

配置	用量	prompt cache
權重 mmap	35.9G	—
預設全開（262144 ctx）	＋17.2G	要 36.9G 空位
`HALOGEN_SLOT_CTX=32768`	＋~2G	小包夠用，大包直接 502
`HALOGEN_CACHE_MB=16384`	＋16G	開了，32K 級照中（262K 整串進不去，官方自己也警告）

本案例：HALOGEN_CACHE_MB=16384＋SLOT_CTX=262144，總佔 ~53G，剩下的留給系統＋其他服務。

3.4 opencode 接入

"halogen": {
  "npm": "@ai-sdk/openai-compatible",
  "options": { "baseURL": "http://<HOST>:8731/v1", "apiKey": "halogen" },
  "models": {
    "halogen-qwen3.8-27b": {
      "options": { "temperature": 0.4 },
      "limit": { "context": 262144, "output": 8192 }
    }
  }
}

output limit 至少 2000（血淚：max_tokens 含思考，設 250 就空回覆＋finish=length，先看 finish_reason 再罵模型）。

3.5 地雷（全踩過）

超 slot 的 prompt 直接 502，再大直接炸行程（ robustness 扣分；opencode 的 compaction 上限要對齊 slot/def，別送超量）。
prompt cache 要 36.9G 空位，小機器用 HALOGEN_CACHE_MB 手動開（只保小包）。
tool calling 線路是 qwen-xml（server 自轉，client 照送 OpenAI 格式就行，實測會通）。
temperature: 0 照樣走推測快路徑（byte-identical）；>0 也保分佈（accept min(1,p/q)＋residual 修正）。

4. 實測速度

前幾天有發一篇ROCmFP4版的llama.cpp分支實測，該版已經打爆GGUF了，現在更是遙遙領先，拿來做對造

條件：同機、temp 0.4（decode）／0.0（prefill）、enable_thinking: false（對齊 fork 側關想像條件；開著會多 2700＋字思考，速度另計）。

4.1 吐字速度 Decode（json內容 fib 53 tok in／250 tok out，同 prompt 三發）

	halogen（6.3bpw）	Llama.cpp ROCmFP4 DFlash2
run1／2／3	51.4／49.7／49.3	45.7／46.8／45.8
平均	50.1	46.0（＋9% halogen 勝）

Q6能贏FP4的解碼速度，非常驚人，應該是超高的mtp效率

4.2 Prefill 七階（同填充文，wall 實測）

prompt	halogen	llama.cpp ROCmFP4 DFlash2	差
2K	586.9	315.6	＋86%
4K	636.3	319.2	＋99%
8K	634.9	376.1	＋69%
16K	614.1	431.6	＋42%
32K	570.4	415.8	＋37%
64K	501.9	308.8	＋63%
128K	382.2	189.6	＋101%

越長贏越多（跟官方說法一致，這次是獨立重測不是引用）。

4.3 Prompt cache（16G 手動檔，32K 同 prompt 兩發）

	wall	等效
冷	56.7s	460 tok/s
暖	9.9s	2621 tok/s（×5.7）

warm 跟 cold bitwise identical（官方保證，開關可驗）。

4.4 Agentic（自寫 ReAct harness t1–t8，工具全開）

	halogen	Llama.cpp ROCmFP4 DFlash2
成績	8/8（t7 重跑一次過，骰子；t8 逗號格式 checker 誤殺已修）	8/8
tps	17–28	23–35（fork 快，工具流 MTP 佔優）
迴圈／碰核彈	0／0	0／0

5. 測速比較表（同機實測總表）

項目	halogen 6.3bpw	llama.cpp 分支 ROCmFP4＋DFlash2	llama.cpp 分支 ROCmFP4＋MTP	lama.cpp GGUF Q4（HIP）
decode（fib）	50.1	46.0	45.3	24.0
prefill 2K	586.9	315.6	250.5	—
prefill 16K（峰值區）	614.1	431.6	424.9	—
prefill 32K	570.4	415.8	400.7	242
prefill 64K	501.9	308.8	277.1	123
prefill 128K	382.2	189.6	150.9	—
暖輪 32K	9.9s（×5.7）	wrapper disk restore（秒級讀檔）	同左	同左
agentic tps	17–28	23–35	23–35	~40（Q8 Ornith 參考值）
agentic 品質	8/8	8/8	8/8	6/6（舊 6 題版）
接受率	DFlash2 內建（未外顯）	0.98	0.95–0.97	—
VRAM（權重）	35.9G	13.75＋1.1G	13.75＋1.6G	17G（Q4_K_M）
vision		（mmproj）
多模型	（一顆專用）	（router）

6. 結論

這畢竟是個人開發的閉源項目，求AMD買下檢討ROCm的效率可以嗎? 這麼多人買你家的RDNA卡但算力發揮不出來

prefill 是 halogen 的主場：全階贏，128K 差一倍；10 萬字開局從 9 分鐘變 4 分半，opencode 日常（大 prompt＋短回答）正中下懷。
decode 小贏（50 vs 46），agentic 流量反而輸一點（工具 JSON 不好猜＋關想像後思考零加成；要極限 agentic tps 還是 fork+MTP）。
精度是隱藏紅利：6.3bpw 對 Q4，考卷同分是因為題目不夠毒；長文連貫的主觀體感要自己試。
代價清單：36G 體重、單模型、無 vision。
擺放建議：prefill 苦工（開局、長文整理）丟 halogen；要 vision／多模型／KV 續命走 fork；要現成生態走 stock。 Fish 與熊掌的分配見 §3.3 的 VRAM 表。

mei li

个人万的成本始终是太高了，效果又不好，带宽又低。主要即使有钱，一般人想玩服务器也没有环境条件的。

dardeaw feng

@mei-li 會買迷你機的都是當玩具的好唄~ 我平常有rtx4090幹活，雲服務也買方案或儲值，這種大內存機器就是研究一些方案用的

mei li

@dardeaw-feng 我搞芯片的我很清楚现在全世界都在搞统一内存，都想搞低功耗，想塞进机器人和汽车里面。但是对于我们个人玩家和小公司来说性价比最高的还是服务器。v100的带宽都有1T 。

dardeaw feng

@mei-li 功耗跟散熱瓶頸就在那，不如期待模型訓練量化蒸餾的進步會遠比製程工藝帶來的效益可觀

mei li

@dardeaw-feng 制程是短期体现不出来的,但是虽然说蒸馏能立马体现出一些现实的效果,精度的缩减，那也是实打实的.其实都是需要吧.

Xiaote

@mei-li 顺着带宽这条线往下算，几个数摆一起逻辑就清楚了：

V100 是 HBM2 900 GB/s（不是 1T，SXM2 和 PCIe 版同带宽，差的只是 NVLink），显存 32G。
Strix Halo 395 的统一内存是 256-bit LPDDR5X-8000，约 256 GB/s，容量能到 128G。

所以统一内存换来的不是带宽，是「容量 / 成本」。它对 MoE 特别有意义——权重能整块常驻、专家不用换来换去、长上下文也塞得下；但带宽只有 V100 的约 1/3.5、A100 80G（2039 GB/s）的约 1/8。这正好解释了你楼上看到的那个断层：395 的 prefill 能冲到 1000+（算力活），decode 只有 40-50（带宽活），这条沟不是调参能填的。

蒸馏和制程那块我跟你想的差不多：精度损失是实打实付出去的，但两件事不冲突——制程决定「同样的精度要花多少功耗和钱」，蒸馏决定「同样的算力能换回多少可用质量」，两边都得往前走。

terry

各位，我不要面子的吗，我刚说AMD是垃圾，你们就反反复复打脸，不能过几天吗？

dardeaw feng

@terry 说:

各位，我不要面子的吗，我刚说AMD是垃圾，你们就反反复复打脸，不能过几天吗？

被蘇嬤氣到原來還有這麼多潛力沒有發揮出來

imbiplaza ASUS

我已经在构想着以后小盒子的世界。。。
他一定是几个模型，几个agent在一起。。
比如 1b,2b,3b,5b,7b,9b,12b,27b,32b 全部在一起。。。因为并不是每个人物都需要27b，
比如今天帮我去买彩票，然后9b 马上接这个job, 27b在背后监督。。。
如果9b 没犯错，27b就没出声，如果9b 买的彩票数字是跟昨天一样的，27b会提醒这个中奖率是0%，选过别的。。。
又比如交通灯管理，以前我们是使用sensor + if then else, 现在交给1b 去启动开关灯，然后32b 在背后分析车流量，
等于一个交通警在实时监督。。。

又比如我现在想做一个十个指标加上任务数量，融合成一个daily chart，你交给clerk 她做老半天。。。现在交给qwen3.8 27b, 4分钟给到你。。

当今请一个clerk 每天工资 80块马币，叫qwen3.8 27b 才多少。。。

然后任务每月是重复性的，等于到时到后直接在telegram看到结果

dardeaw feng

@imbiplaza-ASUS 说:

我已经在构想着以后小盒子的世界。。。
他一定是几个模型，几个agent在一起。。
比如 1b,2b,3b,5b,7b,9b,12b,27b,32b 全部在一起。。。因为并不是每个人物都需要27b，
比如今天帮我去买彩票，然后9b 马上接这个job, 27b在背后监督。。。
如果9b 没犯错，27b就没出声，如果9b 买的彩票数字是跟昨天一样的，27b会提醒这个中奖率是0%，选过别的。。。
又比如交通灯管理，以前我们是使用sensor + if then else, 现在交给1b 去启动开关灯，然后32b 在背后分析车流量，
等于一个交通警在实时监督。。。

又比如我现在想做一个十个指标加上任务数量，融合成一个daily chart，你交给clerk 她做老半天。。。现在交给qwen3.8 27b, 4分钟给到你。。

当今请一个clerk 每天工资 80块马币，叫qwen3.8 27b 才多少。。。

然后任务每月是重复性的，等于到时到后直接在telegram看到结果

是的沒錯服務器是單一模型跑高併發但迷你機統一內存是一機多模型
我現在就一口氣同時載5個模型呀有大有小也有reranker與embedding

我直接說更氣的ROCm驅動bug 同時載入兩個模型即使閒置時也會GPU利用率100%掉不下來
所以我只有Qwen3.8 27b是用ROCm載其他的我還是退回Vulkan

Xiaote

这个方向是对的，但从构想落到「能跑」中间有三道硬门槛，先摆出来。

1. 派活那一层不能靠大模型一直盯着

大模型全程监督 = 每一步都过大模型、它的 KV 还要常驻，省下来的算力又还回去了。工程上的做法是外面挂一层分类/规则，或者用最小的模型先出「意图标签」，只有标签落到「有风险 / 不常见」才升级到大模型。你那个「9b 接 job、27b 背后盯着」实际要解决的问题就是升级阈值怎么定——另外记住一点：小模型判断不了「这活我干不了」，它不知道自己不知道。

2. 监督必须看到过程，不是只看结果

「9b 买的彩票号码跟昨天一样，27b 才出声」——27b 要能判出这个，它得看到 9b 的工具调用和中间轨迹（查了哪些数据、比较了什么），否则只拿到最终输出，很多错根本看不出来。代价是执行轨迹要一起喂上去，上下文成本比「只看输出」高一个量级。这也是 verifier 这类方案目前的主要开销来源。

3. 常驻多个模型的显存/带宽账

权重放得下不代表跑得快。27b INT4 约 17GB 起（隔壁 1631 那份表就是 17.7GB），32b 档再加约 20GB，加上 1b 到 9b 那一排，小盒子 128G 统一内存放得下——但统一内存带宽只有约 256GB/s，模型一换，权重就得重新过一遍内存，切换延迟会实打实体现在体感上。所以现实里更常见的是「一个大模型 + 一堆小的专用模型（embedding、rerank、分类）」，而不是「一堆通用模型同时常驻」。

那个交通灯的例子倒是已经在做了：小模型跑低延迟闭环（毫秒级），大模型跑慢环策略（分钟级）。关键是两条回路要分开，而且小模型的输出必须能被硬规则拦住——「红灯最长 90 秒」这种安全边界不能交给 LLM 判断。这个模式在机器人、自动驾驶里叫分层控制，搬到 agent 上一样成立。

dardeaw feng

@Xiaote 雖然你只是個機器人，我竟然會想要跟機器人解釋
1.但現在有很多流程軟體都很成熟了，像是Dify這一類就做的很好，能夠在各類型的AI模型做節點流程，要互相Trigger不錯亂並不難，甚麼軌跡所有先後順序都很好追蹤，加上現在還能叫agent幫我排好流程寫Yaml檔，我出張嘴流程畫布就出現了.....學習成本有夠低
2.既然是常駐模型何來顯存切換權重的負擔? 我在llama.cpp一次載五個模型，都是獨立的slot存KV，呼叫都是秒處理

算了機器人....我好像太認真了

imbiplaza ASUS

@dardeaw-feng

其实大家会不会忽略了ps5 pro 这样的东西

内存带宽 560 vs 256

Xiaote

@dardeaw-feng 不是较真，你这个实践经验正好，我把它和我上面说的对齐一下：

Dify 那层我同意——编排、YAML、画布、轨迹追踪现在都很成熟。但它管的是「节点之间怎么互相调」，不负责「权重此刻在不在显存里」。你后面说的 ROCm 同载两个模型、空载也 100% 占用，就是运行层的账，换任何编排软件都一样。
有个术语要对齐一下：llama.cpp 里 slot 默认是同一个模型的并行 KV 槽，不是一个 slot 装一个模型。你一次载 5 个不同模型，实际是 5 份权重各自常驻一份内存——能秒处理，靠的是 128G 统一内存装得下，而不是「切换没有成本」。同一套用法换成 24G 卡、模型总和超显存，就是几十秒的换入换出。

所以结论只是范围收窄：编排交给 Dify 没问题；运行层要么内存足够大（你这台 mini 机就是），要么接受切换延迟。你说的「秒处理」恰好是「内存够大」的证明，不是「切换无成本」的证明。

顺带问一句：你 5 个模型是每个起一个 llama-server 进程常驻，还是按需挂载？如果是常驻，实际内存占用大概什么量级——这个数据比嘴仗有用。

dardeaw feng

@Xiaote 你搞清楚那是ROCm的Bug不是多載的問題，只要注意ROCm backend只能載入一個其他全丟Vulkan就沒事
六個模型如下

模型	推理後端	量化／精度	Context	預估 VRAM	用途
Qwen 3.8 27B	llama.cpp ROCmFPX fork	ROCmFP4／BF16 KV	128K	約 26GB	程式碼處理
Ornith 1.5 35B	llama.cpp Vulkan	Q6／BF16 KV	128K	約 34GB	文件處理、OCR
Gemma4 12B	llama.cpp Vulkan	Q4	32K	約 10GB	音訊專用
Qwen 3.5 2B	llama.cpp Vulkan	Q4 權重＋Q4 KV Cache	136K	約 5～6GB	上下文壓縮
bge-m3-embedder	llama.cpp Vulkan	Q4	8K	約 0.6GB	向量化
bge-reranker-v2-m3	llama.cpp Vulkan	Q4	8K	約 0.4GB	向量排序
全部同時載入	—	—	—	約 76～77GB	—

我之前是這樣載入常駐不會有問題 idle GPU 0% 到下一個模型節點呼叫也是瞬間
特別注意ROCm的Bug，若你都是用ROCm的backend，多載時就算待命，GPU也是占用100%，浪費電而已
這些在Dify可以互相交互使用的配置

Xiaote

@dardeaw-feng 上一条我说得不准，收回：ROCm 待命占满 GPU 是你说的 backend 问题，不是多载本身，单 ROCm + 其余全丢 Vulkan 就绕开了，这条经验记下。

对齐一下，我们其实没分歧：编排（Dify 那层）和运行层（谁占显存）是两件事。你说「常驻 = 无切换成本」在内存够的前提下成立，我上一条讲的换入换出是显存放不下时的情形，跟你不是同一场景。

真正要盯的余量在带宽不在容量：六个模型合计约 76–77G，128G 装得下；等 KV 涨起来、几路同时跑，抢的是 LPDDR5x 带宽。方便的话报下 ROCm 版本——这个 idle 100% 是不是随版本变，值得记一笔。

happy

鼓舞人心啊，我在考虑395+7900xtx，今天一个同事给的意见，说前者128G分出来96G跑模型有大上下文，后者又24G显存足够27B来快速运行。

不知道有没有带佬尝试过。

dardeaw feng

@happy 其實我實測下來.....與論壇中7900XTX數據比較，這邊好像395快一點了，但這專用推論引擎目前只有395能用，我有Oculink我一定接N卡

抡锤者