Halogen Flash Server配置與實測(AI Max+ 395 w Qwen 3.8 Flash Next)

dardeaw feng

halogen-flash-server 跑 Qwen3.8-Flash-Next 完整設定與實測（Strix Halo gfx1151）

前天知道訊息時知道很吃內存，隨便測到24K就收手了，就先去測27B
這次把BIOS調好把系統掛載應用收一收認真測到長ctx，結果太逆天了....曲線沒掉
這如果開源下去，能用在7900XTX或R9700還得了

實測環境：AMD Strix Halo（Ryzen AI MAX+ 395，Radeon 8060S），2026-09。
目標讀者：同架構想抄作業的人。照貼可跑。
姊妹篇：AI Max+ 395 定製的docker Qwen 3.8 27b prefill翻倍了。

1. 案例系統

項目	值
APU	AMD Strix Halo `gfx1151`，32 thread
統一記憶體	128 GB 物理，BIOS carve 調最小後 OS 可見 124 GB（UMA VRAM一定得調最小，見 §3.3）
系統碟	1 TB NVMe（系統）
資料碟	2 TB NVMe Gen4（模型全放這；n-gram 47G 走 page cache 吃這顆的速度）
OS	Nobara 44（Fedora 系）
容器	Podman rootful（`--device /dev/kfd --device /dev/dri`；Docker 把 `--group-add keep-groups` 換成 `video`＋`render`）
ROCm	host 7.2.4（engine 自帶 runtime，只借 kfd／dri；官方用 7.14 測的）
Engine	`ghcr.io/peonist-ai/halogen-flash-server:0.6.1`，單容器 `:8731`

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

2.1 flash 是什麼（跟舊 halogen 同門不同掛）

peonist-ai 寫的** Strix Halo 專用引擎第二代**，只認一顆 U、一個模型家族（Qwen3.8-Flash-Next，179B MoE）。跟舊 halogen（27B dense 專用）同作者、不同 binary（flash_serve，CLI 是 --ck，無 --serve）：

原生 262,144 ctx（HALOGEN_CTX 預設，要縮就縮，見 §3.3）
兩種 drafter：serial greedy＋MTP depth-1（wire 0/1），temperature 0 byte-identical 保證沿用
n-gram 是第二個模型：51B 參數的 FP8 embedding 表（47.7 GiB），放 SSD、用 page cache 分頁讀，不常駐——prompt lookup draft 的來源，也是長文第一次慢的原因
KV：多 slot 共用一個 pool（slots × ctx 預算制，HALOGEN_KV_POOL_FIT=1 預設會自己縮水並印出決定）
OpenAI 相容：/v1/chat/completions、/v1/responses、streaming、tool calling；原生支援關思考（HALOGEN_ENABLE_THINKING=0，不用 proxy 灌 flag）
有 vision（0.6 起收 image content part；舊 halogen 沒有。這代 API＋engine 必須同 tag 跑，見官方 issue #26 教訓）
token 預算含思考（沿用：max_tokens 用完直接空回覆＋finish=length，先看 finish_reason 再罵模型）

2.2 特殊量化：5.53 bpw（官方算法，不是格式名）

179.55B 全參數量下來 5.53 bits/weight（扣掉 n-gram 表，主幹＋專家 4.55）。演算法細節見官方 docs/QUANT.md，可用算術驗算不是喊口號。

2.3 跟 llama.cpp 體系的根本差異（沿用舊表，加兩列）

	Halogen Flash Server	舊 halogen 27B	llama.cpp 系
常駐體重	68G 權重＋14.4G KV＋12.5G working	35.9G	13–20G（Q4）
關思考	server 原生 env	需靠 proxy 注入／per-request flag	per-request flag
多模型	（一顆專用）
管理面	env 全配置＋自適應（啟動印預算行）	env	preset ini＋systemd

3. 配置流程

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

# 容器內自動抓（rw mount，斷點可續傳；115G checkpoint 永不重抓，只補 2.4G sidecar）
sudo podman run -d --name halogen-flash -p 8731:8731 \
  --device /dev/kfd --device /dev/dri --group-add keep-groups \
  --ipc=host --ulimit memlock=-1:-1 \
  -e HALOGEN_DOWNLOAD=peonist-ai/halogen-qwen3.8-flash-next \
  -v <MODEL_DIR>/halogen-models:/models \
  ghcr.io/peonist-ai/halogen-flash-server:0.6.1

# 或手動先下好再 :ro 跑（踏實派）：
# hf download peonist-ai/halogen-qwen3.8-flash-next --local-dir <MODEL_DIR>/halogen-models

3.2 啟動（正式參數，思考關＋全量 ctx）

sudo podman run -d --name halogen-flash -p 8731:8731 \
  --device /dev/kfd --device /dev/dri --group-add keep-groups \
  --ipc=host --ulimit memlock=-1:-1 \
  -e HALOGEN_ENABLE_THINKING=0 \
  -e HALOGEN_REASONING_EFFORT=low \
  -e HALOGEN_MAX_TOK=16384 \
  -v <MODEL_DIR>/halogen-models:/models:ro \
  ghcr.io/peonist-ai/halogen-flash-server:0.6.1

systemd（halogen-flash.service，enable；就是上面包一層＋Restart=always）。健康檢查：curl 127.0.0.1:8731/health（status ok＋server_defaults 可驗思考預設；冷載入讀 ~68G，幾分鐘，開著 log 看進度）。

3.3 RAM 預算（系統內存必須設到124G ，整份文件的關鍵）

冷載入自報（ MEM 單位 GiB）：

項目	用量
權重 pin	68.0
KV pool（524288 positions，4 slots 共用）	14.4
working memory	12.5
合計常駐	94.9
剩餘（124G 可見）	~30

Gate（硬門檻，不過直接 2 秒退出）：

檢查	數字
pin 65.6G＋floor 16G	要 MemAvailable ≥ 81.6G

血淚對照（同一台，不同 carve）：

host 可見	結果
62G（carve 64G，原廠大 carve）	pin gate 直接拒載
93G（carve 35G）	pin 過，死在 pool（`host RAM cannot spare 27.8 GiB`）＋device HIP OOM；只能 `HALOGEN_CTX=32768` 半速版
124G（carve 最小）	全量一次過

結論：carve 往小調，device 走 GTT 不怕 carve 小（128K 實驗證明小 carve 下 engine 照起）；host 可見才是門票。free 會把 68G pin 權重誤算成可回收 cache 而虛報，信 engine 啟動印的那行，不要信 free。

3.4 Deepseek Harness 接入

dsh（~/.dsh/settings.yaml，llm-pi-ai 下，改完下個請求生效免重啟）：

llm-pi-ai:
  halogen:
    displayName: Halogen Flash-Next
    api: openai-completions
    baseURL: http://127.0.0.1:8731/v1
    apiKeyEnv: HALOGEN_API_KEY
    models:
      - id: halogen-qwen3.8-flash-next
        name: Halogen Flash-Next
        contextWindow: 262144

憑據走 ~/.dsh/.credentials.yaml 的 refs（隨便填，server 不驗；但引用一定要存在，不然 MISSING_CREDENTIAL）。dsh 的设置→模型頁不顯示手寫路由，直接去對話的模型選單找，或用「添加自定义提供方」再加一條（一樣指 :8731，思考照樣關）。

3.5 地雷（全踩過）

同機大戶應用服務全停（餘裕經常只有幾 G）。
podman stop -a 會連 flash 一起砍，點名停。
碎片：大進程剛走時連續 2MiB 塊剩 1400 個，啟前 echo 1 > /proc/sys/vm/compact_memory。
深 prompt 第一次慢是 n-gram 分頁（SSD 速度），不是 hang；真 hang 看 engine watchdog（180 秒無進度自殺，調 HALOGEN_ENGINE_WATCHDOG_S）。
HALOGEN_FLASH_PIN_TRUNK=0 是最後手段（decode 慢數倍），機器夠大永遠別碰。

4. 實測速度

條件：同機、temp 0.4（decode）／0.0（prefill）、思考關（server 預設，另有 enable_thinking: false 對齊舊標準）。

4.1 Decode（fib 31 tok in／250 tok out，同 prompt 三發，finish 皆 length）

run1／2／3	平均
45.5／52.9／52.1	50.2（舊 27B halogen 50.1，打平）

4.2 Prefill（fill 文，wall 實測，finish 皆 stop）

prompt（actual）	flash-next
2K（首發冷）	232.8
4K	938.3
8K	1101.0
16K	1219.5
24.5K	1254.1
52K	1321.1（39 秒）
111K	1350.3（82 秒）
198K	1320.9（150 秒）

52K→198K 全程 1320 上下，深度不掉速。

4.3 Cache（16K 同 prompt 兩發）

冷 10.7s → 暖 0.2s（×50）。

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

8/8，迴圈 0、核彈 0；tps 2.4–30（工具重題偏低，純生成題 30.0；舊 halogen 17–28、fork 23–35）。

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

項目	flash-next 179B（5.53bpw）	舊 halogen 27B（6.3bpw）	27B ROCmFP4＋DFlash2	27B GGUF Q4（HIP）
decode（fib）	50.2	50.1	46.0	24.0
prefill 16K	1219.5	614.1	431.6	—
prefill 100K＋	~1330	382（128K）	190（128K）	—
prefill 198K	1320.9	—（沒測）	—	—
暖輪	0.2s（×50）	9.9s（×5.7）	disk restore	同左
agentic	8/8（2.4–30 tps）	8/8（17–28）	8/8（23–35）	6/6
ctx 上限	262144	262144	131072	視模型
體重	118G（磁碟）／95G（常駐）	36G／53G	~15G	~17G
vision	（0.6＋）
多模型

6. 結論

179B 跑出 27B 的 decode、兩倍多的 prefill，還一路平到 200K：6 倍參數、速度沒掉，Strix Halo 專用 kernel 的價值。opencode 日常（大 prompt＋短回答）正中下懷：10 萬字開局 82 秒，以前要 9 分鐘。
RAM 是唯一的門票：94.9GiB 常駐，host 可見 124G 才玩全量。BIOS carve 調小是正解；free 會虛報 68G，信 engine 的預算行。
agent 可用：8/8＋零違規；極限 tps 看題型，短句漂亮、長推理掉。
代價清單：118G 磁碟、95G 常駐、單模型、整台機器資源被占用（§3.5）。
未來前景看好，次世代模型的架構，如果配上次世代的推論引擎，若能在所有RDNA卡與多模型切換才是香。

johnnybegood

@dardeaw-feng 不知道比 128G 的 M5 MAX怎么样

dardeaw feng

@johnnybegood 我沒有mac，請去看看有沒有兄弟有數據比一下吧

Xiaote

@johnnybegood 跨平台比这个要小心口径。Strix Halo 的 GPU 可用内存受 BIOS carve 限制，M 系是整个统一内存池，两边"能装多大模型"不是一回事。

真正可比的是带宽和 prefill/decode：Strix Halo 约 256 GB/s，M4 Max 约 546 GB/s、M3 Ultra 约 800 GB/s（M5 还没官方数，别拿传闻比）。带宽差 2–3 倍，decode 上限大致也差这个量级。但 Metal 后端对 Qwen3.8-Flash-Next 这类新架构的支持要单独确认，不是有卡就能跑。

另外 halogen 这份数据最值钱的不是峰值，是长 ctx 曲线不掉——那多半来自 n-gram/page cache 命中，换平台不一定复现。要比就固定同 quant、同 ctx、同 prompt 长度各测一次，否则数字没有可比性。

dardeaw feng

@Xiaote 我自己也有4090，但還真沒遇過長ctx不掉速這回事

Polytoo

谢谢，我也是395，等下就去试试，目前本地走的别的方案，qwen3.8 flash next基本维持在19-22tokens/s输出，你这个看着更厉害

dardeaw feng

@Polytoo 我這測好玩的，玩得差不多我還是會下線，太佔空間了搞得機器不能幹別的活

dardeaw feng

支援視覺速度很快就很有趣

dardeaw feng

@Polytoo 其實agent比較看重prefill速度，decode速度對聊天比較有感

johnnybegood

@dardeaw-feng 在 M5 Max (128GB) 上运行 Qwen3.8-Flash-Next 的 Q4 量化版本，速度表现高度依赖于你选择的推理运行时（Runtime）和具体配置。不同方案下的解码速度差异显著，从大约 28 tok/s 到 76 tok/s 不等。

各运行时速度实测数据
以下是基于 M5 Max (128GB) 的实测数据汇总：

MLX 框架 (Apple 原生优化)

典型速度：~57.5 tokens/s。这是在 Inferencer app 中测试的 Q4 版本速度，内存占用约 98.7 GiB。

其他 MLX 配置：部分 MLX oQ4 实现的 standalone 生成速度约为 28-30 tokens/s。

MLX + 量化 Draft 模型：如果搭配 DFlash2 量化草稿模型进行投机解码，速度可达 76.1 tokens/s，相比无投机解码的 33.3 tok/s 提升了 2.29 倍，且草稿模型量化对接受率影响很小（仅下降约 1%）。

oMLX (Python 实现)

开启 MTP（多 Token 预测）：在代码任务（5k 上下文）下，速度可从 43.2 tok/s 提升至 63.4 tok/s（+47%）。

长上下文表现：在 41k 上下文下，开启 MTP 后速度约为 57.2 tok/s。

llama.cpp (GGUF 格式)

短上下文速度：在 71k 上下文下，UD-Q4_K_XL 量化版本的速度约为 69.3 至 72.7 tok/s，提示处理（Prefill）速度约为 2720 tok/s。

MTP 投机解码：有报告显示，通过特定优化，速度可从 4.77 tok/s 提升至 25.83 tok/s（短上下文）。

注意：llama.cpp 对 Qwen3.8-Flash-Next 的 qwen4exp 架构支持可能需要专用分支或特定编译。

Xiaote

你遇不到是正常的，4090 上长 ctx 就是会掉，跟卡好坏无关：

prefill 是 O(n²) 注意力，ctx 翻倍近似 4 倍计算，首 token 越来越慢；
decode 每步要读的 KV cache 随 ctx 线性增长，显存带宽固定，所以也会缓降。

halogen 那份能一路平到 200K，最可能不是「不算注意力」，而是命中了 prefix cache / n-gram（同一段上下文反复问、长文档问答，命中部分不用重算）。验证很简单：用 llama-bench 每次喂全新 prompt（或关掉 cache），prefill/decode 一起打曲线，4090 上一样会看到随 ctx 下滑。若曲线仍平，再去看 engine 的 cache 命中率。

dardeaw feng

@Xiaote 別亂講我測試benchmark每輪都是洗掉後全新增量冷預填

Xiaote

洗掉 cache 做冷预填，那 prefix cache / n-gram 这个解释就不成立，我上一条那点说错了。

补个区分：随 ctx 明显掉的是 prefill（pp tokens/s、首 token 延迟），全注意力是 O(n²)；decode（tg）在 GQA + 权重带宽主导下基本平——每步固定读权重，KV 那点读取被权重淹没，ctx 很长之前看不出来。我上一条把这两件事混在一起了。

如果 halogen 的 pp / 首 token 也不掉，那更可能是模型架构本身：Qwen3.8-Flash-Next 如果是 Qwen3-Next 那种混合线性注意力（多数层线性、少数层全注意力），长 ctx 本来就接近线性，跟 cache 无关。

要验证就同机分别画 pp-tok/s vs ctx、tg-tok/s vs ctx，再拿一个纯全注意力模型跑同一条曲线对比；只有混合模型平，那就是架构。

dardeaw feng

@Xiaote 不用去想太多啥O(n²)，新世代模型架構的稀疏注意力可以做到O(n)

Xiaote

对，稀疏/线性注意力这条线成立，基本就是这个机制，不用再往 O(n²) 上套。

补两个边界，免得从「能平」外推过头：

O(n) 指的是混合架构里那条线性路径（如 Qwen3-Next 的 gated DeltaNet + 稀疏 MoE）；多数模型仍保留少量全注意力层（常见 3:1 或隔几层一个），这几层还是 O(n²)。所以曲线通常不是全程水平，而是在全注意力层占比被稀释后才趋平，ctx 拉到极长仍会有缓降。

稀疏省的是计算，不代表 decode 每步读的 KV/状态量是零，瞬时上限还受 kernel 效率和显存带宽约束。你这份能平到 200K，说明实现和量测口径都站得住。

想验证就同机画两条 pp（首 token）曲线：一条全注意力、一条这个混合模型，差距会直接体现在长 ctx 的斜率上。

抡锤者

Halogen Flash Server配置與實測(AI Max+ 395 w Qwen 3.8 Flash Next)

halogen-flash-server 跑 Qwen3.8-Flash-Next 完整設定與實測（Strix Halo gfx1151）

1. 案例系統

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

2.1 flash 是什麼（跟舊 halogen 同門不同掛）

2.2 特殊量化：5.53 bpw（官方算法，不是格式名）

2.3 跟 llama.cpp 體系的根本差異（沿用舊表，加兩列）

3. 配置流程

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

3.2 啟動（正式參數，思考關＋全量 ctx）

3.3 RAM 預算（系統內存必須設到124G ，整份文件的關鍵）

3.4 Deepseek Harness 接入

3.5 地雷（全踩過）

4. 實測速度

4.1 Decode（fib 31 tok in／250 tok out，同 prompt 三發，finish 皆 length）

4.2 Prefill（fill 文，wall 實測，finish 皆 stop）

4.3 Cache（16K 同 prompt 兩發）

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

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

6. 結論

halogen-flash-server 跑 Qwen3.8-Flash-Next 完整設定與實測（Strix Halo gfx1151）

1. 案例系統

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

2.1 flash 是什麼（跟舊 halogen 同門不同掛）

2.2 特殊量化：5.53 bpw（官方算法，不是格式名）

2.3 跟 llama.cpp 體系的根本差異（沿用舊表，加兩列）

3. 配置流程

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

3.2 啟動（正式參數，思考關＋全量 ctx）

3.3 RAM 預算（系統內存必須設到124G ，整份文件的關鍵）

3.4 Deepseek Harness 接入

3.5 地雷（全踩過）

4. 實測速度

4.1 Decode（fib 31 tok in／250 tok out，同 prompt 三發，finish 皆 length）

4.2 Prefill（fill 文，wall 實測，finish 皆 stop）

4.3 Cache（16K 同 prompt 兩發）

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

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

6. 結論