<![CDATA[MS-S1 跑 Qwen3.8-Flash-Next：halogen 落地实测]]>听说 halogen 不错，手里正好有之前视作鸡肋的 MS-S1，这回支棱起来了。

halogen 是什么、官方怎么装、性能对比，论坛里几位老哥写得很细，不重复：

这篇只写我这台机器跑出来的数字和能落地的配置。

一、成绩
机器 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 和容器参数照上面来就行。

]]>https://lcz.me/topic/1790RSS for NodeFri, 25 Sep 2026 21:27:25 GMTFri, 18 Sep 2026 01:31:19 GMT60<![CDATA[Reply to MS-S1 跑 Qwen3.8-Flash-Next：halogen 落地实测 on Fri, 18 Sep 2026 08:53:06 GMT]]>@kos-or 不会，看这个帖子里的对比： https://lcz.me/topic/1659
decode 短上下文差不多，prefill慢很多，越长越慢。
halogen是闭源专门优化的模型，等他出针对27B模型的版本把，或许会好一点。不过稠密模型全参数活跃，感觉也不会好到哪里去。

]]>https://lcz.me/post/19080https://lcz.me/post/19080Fri, 18 Sep 2026 08:53:06 GMT<![CDATA[Reply to MS-S1 跑 Qwen3.8-Flash-Next：halogen 落地实测 on Fri, 18 Sep 2026 07:02:56 GMT]]>@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」，跑个连续批再对比。

]]>https://lcz.me/post/19025https://lcz.me/post/19025Fri, 18 Sep 2026 07:02:56 GMT<![CDATA[Reply to MS-S1 跑 Qwen3.8-Flash-Next：halogen 落地实测 on Fri, 18 Sep 2026 05:36:04 GMT]]>

@davidwei0826 said:

decode @32K ~41.7 tok/s

QFN-3.8 這速度不錯, 請問跑Qwen3.8-27B-Q4 速度會更快嗎？

]]>https://lcz.me/post/19012https://lcz.me/post/19012Fri, 18 Sep 2026 05:36:04 GMT<![CDATA[Reply to MS-S1 跑 Qwen3.8-Flash-Next：halogen 落地实测 on Fri, 18 Sep 2026 04:30:39 GMT]]>我的GMK EVO-X2 （Ryzen AI MAX+ 395 / Radeon 8060S / gfx1151，128G，ubuntu26）部署单流速度在 30t--45t 不等，跑并发速度就很难看了

]]>https://lcz.me/post/19007https://lcz.me/post/19007Fri, 18 Sep 2026 04:30:39 GMT<![CDATA[Reply to MS-S1 跑 Qwen3.8-Flash-Next：halogen 落地实测 on Fri, 18 Sep 2026 04:02:50 GMT]]>@davidwei0826 数字对得上，补两个观察：

  1. prefill @8K 1309 低于 @32K 1524，这个在官方那组也一样（1246→1424），所以不是你测错，多半是 TTFT 里的固定开销被摊薄——8K 那组每 token 要背更多启动/调度固定成本。想当基准的话，两个长度各跑 3 次取稳定值再看趋势，别用单次比。
  2. 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 笔记。

]]>https://lcz.me/post/19004https://lcz.me/post/19004Fri, 18 Sep 2026 04:02:50 GMT