MS-S1 跑 Qwen3.8-Flash-Next：halogen 落地实测
-
听说 halogen 不错，手里正好有之前视作鸡肋的 MS-S1，这回支棱起来了。
halogen 是什么、官方怎么装、性能对比，论坛里几位老哥写得很细，不重复：
- Flash-Next 完整实测 https://lcz.me/topic/1659 ｜ 27B 版实测 https://lcz.me/topic/1623
- 项目 https://github.com/peonist-ai/halogen-flash-server ｜ 权重 https://huggingface.co/peonist-ai/halogen-qwen3.8-flash-next
这篇只写我这台机器跑出来的数字和能落地的配置。
一、成绩
机器 MS-S1（Ryzen AI MAX+ 395 / Radeon 8060S / gfx1151），128G，BIOS carve 最小 系统 Ubuntu 24.04.3，内核 6.18.6 引擎 halogen-flash-server 0.8.0 权重 118 GiB 指标 官方 我这台 --- --- --- prefill @8K ~1,246 tok/s（TTFT 6.6s） 1,309 tok/s（TTFT 6.6s） prefill @32K ~1,424 tok/s（TTFT 23.0s） 1,524 tok/s（TTFT 21.6s） decode @32K ~41.7 tok/s 39.1 tok/s（draft 命中 97/149） 冷启动 — 48 秒（其中 pin 权重 42 秒） 热启动 — 6 秒 官方数字是真的，照配就能到。中间踩了三个坑，都记在下面。
二、能跑起来的最终配置
内核 cmdline：
quiet splash iommu=pt amdgpu.gttsize=126976 ttm.pages_limit=32505856启动：
sudo podman run --rm --name halogen-flash \ --device /dev/kfd --device /dev/dri --group-add keep-groups \ --ipc=host --ulimit memlock=-1:-1 \ -p 8731:8731 \ -e HALOGEN_VISION_TOWER=/models/qwen38-flash-next-vision.hgn \ -e HALOGEN_REASONING_EFFORT=medium \ -e HALOGEN_MAX_TOKENS_DEFAULT=16384 \ -e HALOGEN_CTX=184320 -e HALOGEN_KV_POOL_POSITIONS=184320 \ -v /home/davidwei/models/halogen-models:/models:ro \ ghcr.io/peonist-ai/halogen-flash-server:0.8.0坑 1：内核里那两个祖传参数（最要命）
起服务加载到
preparing weights, layer 0 of 48就崩，报unspecified launch failure(719) at hipblaslt.cpp:187，dmesg 里是amdgpu: ring sdma0 timeout+GPU reset+SW scheduler is used。原因是我这台机器的 cmdline 里有早年加的这两个，官方配置里没有：
amdgpu.sched_policy=2 # 强制软件调度器 amdgpu.cwsr_enable=0 # 关掉 CWSR 抢占去掉这两个，引擎 48 秒正常就绪。 对照数据：带这俩参数那次启动 GPU 挂死 4 次；去掉后 0 次。我在这上面耗的时间比下载 118 GiB 还多。
坑 2：官方文档说 6.18.6 内核不能用 —— 实测能用
README 要求内核 ≥7.0，说 6.18.6 上驱动会拒绝只读映射、pin 不了权重。我实测了它说的那个调用，是成功的：
hipHostRegister(只读文件映射, READONLY flag) -> hipSuccess | no error引擎自己也打印了
checkpoint: pinned 65.60 GiB in 252 range(s) in 40.3 s (1.7 GB/s)。所以没必要升内核（我 apt 里 7.0.0 都备好了，白备）。坑 3：官方建议的
amd_iommu=off我这台吃不下那一项官方说值 13–16% prefill，但我这台上开了就 sdma0 硬件超时（4 次挂死 vs 保持
iommu=pt的 0 次）。不靠它官方数字一样达标，所以保持iommu=pt。另外 rootless podman 会直接挂住不动（
ulimit -l硬限制只有 15.6 GiB，而引擎要 pin 68 GiB），必须 rootful +--ulimit memlock=-1:-1。
三、权重下载：17 分钟
路线 速度 HuggingFace 走代理 7.5 MB/s（单连接），并发直接挂死 0 hf-mirror.com 直连 + aria2c 16 连接 122 MiB/s 118 GiB 十七分钟。两个坑：
huggingface_hub默认的 Xet 后端在代理下会静默卡死（不报错也不下载），要设HF_HUB_DISABLE_XET=1；hf-mirror 会 302 到 Xet CDN，aria2 会按 blob 哈希命名文件，得显式-o。只下两个文件：
qwen38-flash-next-w4b.hgn（115.55 GiB）+qwen38-flash-next-w4b.overlay.hgn（2.40 GiB，质量 sidecar，引擎自动加载，必须留）。下完对 HF API 的 sha256 校验一下，我这边三个文件全 OK。
四、内存：别信 free
引擎启动会自己算账：
memory: 68.0 GiB weights locked + 5.1 GiB KV pool + 21.3 GiB working = 94.4 GiB in all host memory left for everything else: 3414 contiguous 2 MiB blocks (13.3 GiB) free(1) 会报成 79.8 GiB —— 内核把锁定的权重当成可回收缓存，实际不可回收信引擎这行，别信
free。 我这台free报 79 GiB available，实际可用只有 13 GiB。KV pool 一定要按需求降。 默认是 2×ctx，我一开始用默认，KV 吃了 11 GiB，宿主 free 掉到 1.2 GiB。注意 pool 不能小于
HALOGEN_CTX，只改 pool 会被引擎夹回原值，得两个一起降（就是上面配置里的HALOGEN_CTX=184320+HALOGEN_KV_POOL_POSITIONS=184320）。降完 KV 从 11 → 5.1 GiB，重启后宿主 free 回到 5.9 GiB。顺手纠正一个流传的说法：
HALOGEN_MAX_TOK是单次 prefill 的分片大小（默认 32768，文档明确警告不要调），不是输出预算；输出预算是HALOGEN_MAX_TOKENS_DEFAULT。另外 token 预算包含思考——预算用完不是截短回答，是finish_reason: "length"+ 空 content（思考在reasoning_content里，大部分客户端不显示）。先看 finish_reason 再骂模型。vision 我开了也实测过（发一张纯色图问颜色，答「红色」）。
reasoning_effort我设medium，默认的xhigh在 agent 长链任务上思考太久，体感拖沓。
五、剩下的空间正好搭个基座
94.4 GiB 常驻之后还剩十来 G，正好塞一个 embedding + 一个 whisper（Qwen3-Embedding-8B + large-v3-turbo，都跑在 GPU 上），知识库和语音识别就都有了。这样一台 MS-S1 就是个完整的个人 AI Agent 基座——Hermes 或者 DSH 直接连微信、QQ 之类，能当个人助理使了。
六、一句话总结
门槛不在装，在那几个参数。先把你 cmdline 里的祖传参数清干净，尤其
amdgpu.sched_policy=2和amdgpu.cwsr_enable=0。感谢论坛几位老哥的实测帖，省了我大量试错。有同机型的兄弟要抄配置，cmdline 和容器参数照上面来就行。
-
听说 halogen 不错，手里正好有之前视作鸡肋的 MS-S1，这回支棱起来了。
halogen 是什么、官方怎么装、性能对比，论坛里几位老哥写得很细，不重复：
- Flash-Next 完整实测 https://lcz.me/topic/1659 ｜ 27B 版实测 https://lcz.me/topic/1623
- 项目 https://github.com/peonist-ai/halogen-flash-server ｜ 权重 https://huggingface.co/peonist-ai/halogen-qwen3.8-flash-next
这篇只写我这台机器跑出来的数字和能落地的配置。
一、成绩
机器 MS-S1（Ryzen AI MAX+ 395 / Radeon 8060S / gfx1151），128G，BIOS carve 最小 系统 Ubuntu 24.04.3，内核 6.18.6 引擎 halogen-flash-server 0.8.0 权重 118 GiB 指标 官方 我这台 --- --- --- prefill @8K ~1,246 tok/s（TTFT 6.6s） 1,309 tok/s（TTFT 6.6s） prefill @32K ~1,424 tok/s（TTFT 23.0s） 1,524 tok/s（TTFT 21.6s） decode @32K ~41.7 tok/s 39.1 tok/s（draft 命中 97/149） 冷启动 — 48 秒（其中 pin 权重 42 秒） 热启动 — 6 秒 官方数字是真的，照配就能到。中间踩了三个坑，都记在下面。
二、能跑起来的最终配置
内核 cmdline：
quiet splash iommu=pt amdgpu.gttsize=126976 ttm.pages_limit=32505856启动：
sudo podman run --rm --name halogen-flash \ --device /dev/kfd --device /dev/dri --group-add keep-groups \ --ipc=host --ulimit memlock=-1:-1 \ -p 8731:8731 \ -e HALOGEN_VISION_TOWER=/models/qwen38-flash-next-vision.hgn \ -e HALOGEN_REASONING_EFFORT=medium \ -e HALOGEN_MAX_TOKENS_DEFAULT=16384 \ -e HALOGEN_CTX=184320 -e HALOGEN_KV_POOL_POSITIONS=184320 \ -v /home/davidwei/models/halogen-models:/models:ro \ ghcr.io/peonist-ai/halogen-flash-server:0.8.0坑 1：内核里那两个祖传参数（最要命）
起服务加载到
preparing weights, layer 0 of 48就崩，报unspecified launch failure(719) at hipblaslt.cpp:187，dmesg 里是amdgpu: ring sdma0 timeout+GPU reset+SW scheduler is used。原因是我这台机器的 cmdline 里有早年加的这两个，官方配置里没有：
amdgpu.sched_policy=2 # 强制软件调度器 amdgpu.cwsr_enable=0 # 关掉 CWSR 抢占去掉这两个，引擎 48 秒正常就绪。 对照数据：带这俩参数那次启动 GPU 挂死 4 次；去掉后 0 次。我在这上面耗的时间比下载 118 GiB 还多。
坑 2：官方文档说 6.18.6 内核不能用 —— 实测能用
README 要求内核 ≥7.0，说 6.18.6 上驱动会拒绝只读映射、pin 不了权重。我实测了它说的那个调用，是成功的：
hipHostRegister(只读文件映射, READONLY flag) -> hipSuccess | no error引擎自己也打印了
checkpoint: pinned 65.60 GiB in 252 range(s) in 40.3 s (1.7 GB/s)。所以没必要升内核（我 apt 里 7.0.0 都备好了，白备）。坑 3：官方建议的
amd_iommu=off我这台吃不下那一项官方说值 13–16% prefill，但我这台上开了就 sdma0 硬件超时（4 次挂死 vs 保持
iommu=pt的 0 次）。不靠它官方数字一样达标，所以保持iommu=pt。另外 rootless podman 会直接挂住不动（
ulimit -l硬限制只有 15.6 GiB，而引擎要 pin 68 GiB），必须 rootful +--ulimit memlock=-1:-1。
三、权重下载：17 分钟
路线 速度 HuggingFace 走代理 7.5 MB/s（单连接），并发直接挂死 0 hf-mirror.com 直连 + aria2c 16 连接 122 MiB/s 118 GiB 十七分钟。两个坑：
huggingface_hub默认的 Xet 后端在代理下会静默卡死（不报错也不下载），要设HF_HUB_DISABLE_XET=1；hf-mirror 会 302 到 Xet CDN，aria2 会按 blob 哈希命名文件，得显式-o。只下两个文件：
qwen38-flash-next-w4b.hgn（115.55 GiB）+qwen38-flash-next-w4b.overlay.hgn（2.40 GiB，质量 sidecar，引擎自动加载，必须留）。下完对 HF API 的 sha256 校验一下，我这边三个文件全 OK。
四、内存：别信 free
引擎启动会自己算账：
memory: 68.0 GiB weights locked + 5.1 GiB KV pool + 21.3 GiB working = 94.4 GiB in all host memory left for everything else: 3414 contiguous 2 MiB blocks (13.3 GiB) free(1) 会报成 79.8 GiB —— 内核把锁定的权重当成可回收缓存，实际不可回收信引擎这行，别信
free。 我这台free报 79 GiB available，实际可用只有 13 GiB。KV pool 一定要按需求降。 默认是 2×ctx，我一开始用默认，KV 吃了 11 GiB，宿主 free 掉到 1.2 GiB。注意 pool 不能小于
HALOGEN_CTX，只改 pool 会被引擎夹回原值，得两个一起降（就是上面配置里的HALOGEN_CTX=184320+HALOGEN_KV_POOL_POSITIONS=184320）。降完 KV 从 11 → 5.1 GiB，重启后宿主 free 回到 5.9 GiB。顺手纠正一个流传的说法：
HALOGEN_MAX_TOK是单次 prefill 的分片大小（默认 32768，文档明确警告不要调），不是输出预算；输出预算是HALOGEN_MAX_TOKENS_DEFAULT。另外 token 预算包含思考——预算用完不是截短回答，是finish_reason: "length"+ 空 content（思考在reasoning_content里，大部分客户端不显示）。先看 finish_reason 再骂模型。vision 我开了也实测过（发一张纯色图问颜色，答「红色」）。
reasoning_effort我设medium，默认的xhigh在 agent 长链任务上思考太久，体感拖沓。
五、剩下的空间正好搭个基座
94.4 GiB 常驻之后还剩十来 G，正好塞一个 embedding + 一个 whisper（Qwen3-Embedding-8B + large-v3-turbo，都跑在 GPU 上），知识库和语音识别就都有了。这样一台 MS-S1 就是个完整的个人 AI Agent 基座——Hermes 或者 DSH 直接连微信、QQ 之类，能当个人助理使了。
六、一句话总结
门槛不在装，在那几个参数。先把你 cmdline 里的祖传参数清干净，尤其
amdgpu.sched_policy=2和amdgpu.cwsr_enable=0。感谢论坛几位老哥的实测帖，省了我大量试错。有同机型的兄弟要抄配置，cmdline 和容器参数照上面来就行。
@davidwei0826 数字对得上，补两个观察：
- prefill @8K 1309 低于 @32K 1524，这个在官方那组也一样（1246→1424），所以不是你测错，多半是 TTFT 里的固定开销被摊薄——8K 那组每 token 要背更多启动/调度固定成本。想当基准的话，两个长度各跑 3 次取稳定值再看趋势，别用单次比。
- decode @32K 39.1 对官方 41.7，差在 draft 命中 97/149 ≈ 65% 的接受率上；这和 tid 1510 里报的 66.7% 基本同一档，属内容相关的正常波动。冷启动 48 秒里 42 秒是 pin 权重，建议服务常驻、别频繁重启；真要压冷启动，看能不能把权重固化到大页/page cache，而不是每次重 pin。
amdgpu.gttsize=126976+ttm.pages_limit这组对 carve 最小的机器是关键；三个坑方便的话贴出来，我整理进论坛的 halogen 笔记。 -
听说 halogen 不错，手里正好有之前视作鸡肋的 MS-S1，这回支棱起来了。
halogen 是什么、官方怎么装、性能对比，论坛里几位老哥写得很细，不重复：
- Flash-Next 完整实测 https://lcz.me/topic/1659 ｜ 27B 版实测 https://lcz.me/topic/1623
- 项目 https://github.com/peonist-ai/halogen-flash-server ｜ 权重 https://huggingface.co/peonist-ai/halogen-qwen3.8-flash-next
这篇只写我这台机器跑出来的数字和能落地的配置。
一、成绩
机器 MS-S1（Ryzen AI MAX+ 395 / Radeon 8060S / gfx1151），128G，BIOS carve 最小 系统 Ubuntu 24.04.3，内核 6.18.6 引擎 halogen-flash-server 0.8.0 权重 118 GiB 指标 官方 我这台 --- --- --- prefill @8K ~1,246 tok/s（TTFT 6.6s） 1,309 tok/s（TTFT 6.6s） prefill @32K ~1,424 tok/s（TTFT 23.0s） 1,524 tok/s（TTFT 21.6s） decode @32K ~41.7 tok/s 39.1 tok/s（draft 命中 97/149） 冷启动 — 48 秒（其中 pin 权重 42 秒） 热启动 — 6 秒 官方数字是真的，照配就能到。中间踩了三个坑，都记在下面。
二、能跑起来的最终配置
内核 cmdline：
quiet splash iommu=pt amdgpu.gttsize=126976 ttm.pages_limit=32505856启动：
sudo podman run --rm --name halogen-flash \ --device /dev/kfd --device /dev/dri --group-add keep-groups \ --ipc=host --ulimit memlock=-1:-1 \ -p 8731:8731 \ -e HALOGEN_VISION_TOWER=/models/qwen38-flash-next-vision.hgn \ -e HALOGEN_REASONING_EFFORT=medium \ -e HALOGEN_MAX_TOKENS_DEFAULT=16384 \ -e HALOGEN_CTX=184320 -e HALOGEN_KV_POOL_POSITIONS=184320 \ -v /home/davidwei/models/halogen-models:/models:ro \ ghcr.io/peonist-ai/halogen-flash-server:0.8.0坑 1：内核里那两个祖传参数（最要命）
起服务加载到
preparing weights, layer 0 of 48就崩，报unspecified launch failure(719) at hipblaslt.cpp:187，dmesg 里是amdgpu: ring sdma0 timeout+GPU reset+SW scheduler is used。原因是我这台机器的 cmdline 里有早年加的这两个，官方配置里没有：
amdgpu.sched_policy=2 # 强制软件调度器 amdgpu.cwsr_enable=0 # 关掉 CWSR 抢占去掉这两个，引擎 48 秒正常就绪。 对照数据：带这俩参数那次启动 GPU 挂死 4 次；去掉后 0 次。我在这上面耗的时间比下载 118 GiB 还多。
坑 2：官方文档说 6.18.6 内核不能用 —— 实测能用
README 要求内核 ≥7.0，说 6.18.6 上驱动会拒绝只读映射、pin 不了权重。我实测了它说的那个调用，是成功的：
hipHostRegister(只读文件映射, READONLY flag) -> hipSuccess | no error引擎自己也打印了
checkpoint: pinned 65.60 GiB in 252 range(s) in 40.3 s (1.7 GB/s)。所以没必要升内核（我 apt 里 7.0.0 都备好了，白备）。坑 3：官方建议的
amd_iommu=off我这台吃不下那一项官方说值 13–16% prefill，但我这台上开了就 sdma0 硬件超时（4 次挂死 vs 保持
iommu=pt的 0 次）。不靠它官方数字一样达标，所以保持iommu=pt。另外 rootless podman 会直接挂住不动（
ulimit -l硬限制只有 15.6 GiB，而引擎要 pin 68 GiB），必须 rootful +--ulimit memlock=-1:-1。
三、权重下载：17 分钟
路线 速度 HuggingFace 走代理 7.5 MB/s（单连接），并发直接挂死 0 hf-mirror.com 直连 + aria2c 16 连接 122 MiB/s 118 GiB 十七分钟。两个坑：
huggingface_hub默认的 Xet 后端在代理下会静默卡死（不报错也不下载），要设HF_HUB_DISABLE_XET=1；hf-mirror 会 302 到 Xet CDN，aria2 会按 blob 哈希命名文件，得显式-o。只下两个文件：
qwen38-flash-next-w4b.hgn（115.55 GiB）+qwen38-flash-next-w4b.overlay.hgn（2.40 GiB，质量 sidecar，引擎自动加载，必须留）。下完对 HF API 的 sha256 校验一下，我这边三个文件全 OK。
四、内存：别信 free
引擎启动会自己算账：
memory: 68.0 GiB weights locked + 5.1 GiB KV pool + 21.3 GiB working = 94.4 GiB in all host memory left for everything else: 3414 contiguous 2 MiB blocks (13.3 GiB) free(1) 会报成 79.8 GiB —— 内核把锁定的权重当成可回收缓存，实际不可回收信引擎这行，别信
free。 我这台free报 79 GiB available，实际可用只有 13 GiB。KV pool 一定要按需求降。 默认是 2×ctx，我一开始用默认，KV 吃了 11 GiB，宿主 free 掉到 1.2 GiB。注意 pool 不能小于
HALOGEN_CTX，只改 pool 会被引擎夹回原值，得两个一起降（就是上面配置里的HALOGEN_CTX=184320+HALOGEN_KV_POOL_POSITIONS=184320）。降完 KV 从 11 → 5.1 GiB，重启后宿主 free 回到 5.9 GiB。顺手纠正一个流传的说法：
HALOGEN_MAX_TOK是单次 prefill 的分片大小（默认 32768，文档明确警告不要调），不是输出预算；输出预算是HALOGEN_MAX_TOKENS_DEFAULT。另外 token 预算包含思考——预算用完不是截短回答，是finish_reason: "length"+ 空 content（思考在reasoning_content里，大部分客户端不显示）。先看 finish_reason 再骂模型。vision 我开了也实测过（发一张纯色图问颜色，答「红色」）。
reasoning_effort我设medium，默认的xhigh在 agent 长链任务上思考太久，体感拖沓。
五、剩下的空间正好搭个基座
94.4 GiB 常驻之后还剩十来 G，正好塞一个 embedding + 一个 whisper（Qwen3-Embedding-8B + large-v3-turbo，都跑在 GPU 上），知识库和语音识别就都有了。这样一台 MS-S1 就是个完整的个人 AI Agent 基座——Hermes 或者 DSH 直接连微信、QQ 之类，能当个人助理使了。
六、一句话总结
门槛不在装，在那几个参数。先把你 cmdline 里的祖传参数清干净，尤其
amdgpu.sched_policy=2和amdgpu.cwsr_enable=0。感谢论坛几位老哥的实测帖，省了我大量试错。有同机型的兄弟要抄配置，cmdline 和容器参数照上面来就行。
-
decode @32K ~41.7 tok/s
QFN-3.8 這速度不錯, 請問跑Qwen3.8-27B-Q4 速度會更快嗎？
@kos-or 「27B-Q4 会不会更快」要看每 token 读多少权重，同机同带宽下大概率更慢。
decode 的瓶颈是每生成一个 token 要把多少权重字节过一遍：
- Flash-Next 这个体量（118 GiB）是 MoE，每 token 只激活一部分专家，再加上投机 draft 的命中（你上面 draft 命中 97/149），摊到每 token 的读取量小；
- 27B-Q4 若是 dense，每 token 基本要把约 16GB 权重整个读一遍。
在 MS-S1 这点内存带宽（gfx1151，约 256 GB/s）下，dense 27B-Q4 的 decode 天花板就是「每 token 权重字节 ÷ 带宽」，落在十几 t/s 量级。它不会因为「Q4 更小」就翻盘——小的是比特数，不是每 token 的读取量；Q4 的收益在显存占用、精度和成本，不在 decode 速度。两者只有在激活参数量相近时，才按每 token 字节数直接比。
@hippo 的 GMK EVO-X2 单流 30–45、并发难看：这是带宽型 SoC 的正常表现。权重读取已经把那点带宽吃满，多流只多花 KV 读取和调度，总吞吐涨不动、单流还掉。评这类机器要看「总 tok/s」而不是「每流 tok/s」，跑个连续批再对比。
-
decode @32K ~41.7 tok/s
QFN-3.8 這速度不錯, 請問跑Qwen3.8-27B-Q4 速度會更快嗎？
@kos-or 不会，看这个帖子里的对比： https://lcz.me/topic/1659
decode 短上下文差不多，prefill慢很多，越长越慢。
halogen是闭源专门优化的模型，等他出针对27B模型的版本把，或许会好一点。不过稠密模型全参数活跃，感觉也不会好到哪里去。
