這次對決非常驚人，halogen你怎麼可以愈進化愈快，之前說好的開源呢?

液冷冷板几乎覆盖了PCB，一把140mm风扇把冷排的热风从顶部排出。满载时转速也不高，哪怕在深更半夜，一两米外就听不到了。

我入手比较早，当时 18k，到现在来看性价比相当高。当然从综合的使用感受上来看，哪怕是现在价格涨了不少，我觉得也可以考虑，放家里跑着基本上是无感的，能效比还高。除了本地的机器，我办公室的pc和笔电也通过Tailscale连了进来。这个还真得感谢halogen，一个月之前还只是玩具。

你设置160，但是要看功率是否往下掉，到目前为止风冷的395好像没有能顶住长时间120w的。

395这东西的TDP AMD已经限制死了。我没记错的话，60s的173w fast ppt，然后600s的154w slow ppt。跑模型只要散热够153w是可以常驻的，如果温度压不住，撞了温度墙就开始掉频率（不断降功耗）。

液冷的优势就太大了，单140mm风扇，风扇转速12xx声音基本听不到，温度也就不到70度，跑满slow ppt不要太轻松。双8cm的冷排散热面积小风扇转速高，就会差不少。

@fcys 说:

@dardeaw-feng 我跑满153w没有任何掉功耗，用的一套液冷，性能释放很充分

更新了0.16.2，解码速度又有了一点提升。

我现在挺满意这台机器，放家里做个服务器用，不占地方也不吵，功耗比较低。
其他机器我基本上就是各种折腾，这台基本是稳定使用

哇 迷你機用上液冷 能分享照片出來嗎
我之前把TDP上調到160W那噪音我受不了
還能上液冷可真是新鮮

更新了0.16.2，解码速度又有了一点提升。

我现在挺满意这台机器，放家里做个服务器用，不占地方也不吵，功耗比较低。
其他机器我基本上就是各种折腾，这台基本是稳定使用

@fcys 说:

@dardeaw-feng 先回答：全部是單路（一次一個請求、串行跑）。2080 / 1850 那些數字都是單請求測出來的。

看到你問，我順手補測了 4 路併發（服務 KV_SLOTS=4，4 路同時打 8K 提示詞、max_tokens=256、temp 0）：

4 路裡有 1 路是同一條提示詞、命中了剛才單路測試留下的前綴快取（prompt_n=0），所以 prefill 只列另外 3 路；decode 四路都是真實數據。

兩個結論：

1. prefill 併發幾乎不掉（每路仍 ~1830–1877 tok/s）；
2. decode 會塌：單路 43.2 → 每路 4–21 tok/s，四路加起來 ≈ 40 tok/s，跟單路同級。

原因寫在引擎自己的啟動日誌裡：

flash_serve: listening on 127.0.0.1:8730, 4 slots over ONE 262144-position KV pool ...
             MTP depth-2 selectable (drafter 1, speculates while alone)

speculates while alone —— 投機解碼只在「獨占」時開，有人同時生成就退回串行。所以多路併發的意義是「多個會話都要有回應」，不是提高總吞吐。

特別調了什麼

硬體 / 內核層

1. BIOS 的 UMA frame buffer 調回最小（只 carve 1 GiB），系統可見 124.4 GiB；
2. 內核參數（GRUB_CMDLINE_LINUX_DEFAULT）：

amdgpu.gttsize=126976 ttm.pages_limit=32505856 ttm.page_pool_size=32505856 amd_iommu=off

開機後 mem_info_gtt_total 出 124.0 GiB。（amd_iommu=off 是早期做過 A/B 後留下來的設定，這一輪沒有重測。）

3. 功耗：PBO 開啟，滿載穩定 ~153 W（跑滿 AMD 的 PPT slow 上限）；CPU governor 是 powersave。

引擎層（HALOGEN_*，跟預設不同的就這幾個）

核心邏輯一句話：MAX_TOK 與 KV_POOL_POSITIONS 都往小調，把 RAM 讓給那張 47.7 GiB 的 n-gram 查找表（它不常駐，全靠 page cache）。

checkpoint

用 v2（qwen38-flash-next-v2.hgn 62.11 GiB ＋ 獨立 ngram.hgn 47.68 GiB），不是舊的 w4b。常駐從 87.0 → 78.3 GiB（多出 8.7 GiB 給頁快取），同題 ppl 好 1.9%。

容器啟動參數

podman run --rm --name halogen-flash -p 8731:8731 \
  --device /dev/kfd --device /dev/dri --group-add keep-groups \
  --security-opt seccomp=unconfined --ipc=host --ulimit memlock=-1:-1 \
  -v <models>:/models:ro -v <cache>:/cache \
  -e HALOGEN_KV_POOL_POSITIONS=262144 -e HALOGEN_PROMPT_CACHE=2 \
  -e HALOGEN_HOST_RESERVE_GIB=24 -e HALOGEN_VISION_TOWER=1 \
  -e HALOGEN_COMPOSABLE_CONTEXT=0 -e HALOGEN_CACHE_DIR=/cache \
  -e HALOGEN_REASONING_EFFORT=low -e HALOGEN_MAX_TOK=16384 \
  -e HALOGEN_PREFILL_CHUNK=16384 -e HALOGEN_CACHE_PRUNE_OLD=1 \
  -e HALOGEN_CACHE_BRANCHES=3 \
  ghcr.io/peonist-ai/halogen-flash-server:0.16.0

啟動後記憶體實測行：

memory: 62.9 GiB of weights locked in RAM (0.8 of them the vision tower's),
        7.2 GiB of KV pool, 8.1 GiB of working memory, 78.3 GiB in all

單路完整數據（0.16.0 + v2，temp 0、effort low）

prefill 隨深度

4K → 260K 只掉 6%，沒有「越長越慢」。

decode（與深度無關）

decode 速度不隨上下文深度變化 —— 48/64 層沒有 KV cache。
它主要由投機解碼命中率（生成內容的可預測性）與樣本長度決定：
同一種任務在 192K / 244K / 256K 上分別測到 52.2 / 28.1 / 53.1 tok/s，
散布這麼大是短樣本的起停開銷造成的，不是「越長越快」。

檢索完整性（引擎 niah，深度 × 位置）

prompt cache

上限

prompt + max_tokens ≤ 262,144，用同一條 259,474 token 的提示詞卡過邊界：

max_tokens	合計	結果
2,670	262,144	200
2,671	262,145	400（leaving room for 2670）

非常感謝分享調校細節，看來關鍵不是功耗、你開PBO影響應該不大、因為我也設了CO -20，是halogen的參數，你這多路prefill數字非常的暴力

看到你問，我順手補測了 4 路併發（服務 KV_SLOTS=4，4 路同時打 8K 提示詞、max_tokens=256、temp 0）：

4 路裡有 1 路是同一條提示詞、命中了剛才單路測試留下的前綴快取（prompt_n=0），所以 prefill 只列另外 3 路；decode 四路都是真實數據。

兩個結論：

1. prefill 併發幾乎不掉（每路仍 ~1830–1877 tok/s）；
2. decode 會塌：單路 43.2 → 每路 4–21 tok/s，四路加起來 ≈ 40 tok/s，跟單路同級。

原因寫在引擎自己的啟動日誌裡：

flash_serve: listening on 127.0.0.1:8730, 4 slots over ONE 262144-position KV pool ...
             MTP depth-2 selectable (drafter 1, speculates while alone)

speculates while alone —— 投機解碼只在「獨占」時開，有人同時生成就退回串行。所以多路併發的意義是「多個會話都要有回應」，不是提高總吞吐。

特別調了什麼

硬體 / 內核層

1. BIOS 的 UMA frame buffer 調回最小（只 carve 1 GiB），系統可見 124.4 GiB；
2. 內核參數（GRUB_CMDLINE_LINUX_DEFAULT）：

amdgpu.gttsize=126976 ttm.pages_limit=32505856 ttm.page_pool_size=32505856 amd_iommu=off

開機後 mem_info_gtt_total 出 124.0 GiB。（amd_iommu=off 是早期做過 A/B 後留下來的設定，這一輪沒有重測。）

3. 功耗：PBO 開啟，滿載穩定 ~153 W（跑滿 AMD 的 PPT slow 上限）；CPU governor 是 powersave。

引擎層（HALOGEN_*，跟預設不同的就這幾個）

核心邏輯一句話：MAX_TOK 與 KV_POOL_POSITIONS 都往小調，把 RAM 讓給那張 47.7 GiB 的 n-gram 查找表（它不常駐，全靠 page cache）。

checkpoint

用 v2（qwen38-flash-next-v2.hgn 62.11 GiB ＋ 獨立 ngram.hgn 47.68 GiB），不是舊的 w4b。常駐從 87.0 → 78.3 GiB（多出 8.7 GiB 給頁快取），同題 ppl 好 1.9%。

容器啟動參數

podman run --rm --name halogen-flash -p 8731:8731 \
  --device /dev/kfd --device /dev/dri --group-add keep-groups \
  --security-opt seccomp=unconfined --ipc=host --ulimit memlock=-1:-1 \
  -v <models>:/models:ro -v <cache>:/cache \
  -e HALOGEN_KV_POOL_POSITIONS=262144 -e HALOGEN_PROMPT_CACHE=2 \
  -e HALOGEN_HOST_RESERVE_GIB=24 -e HALOGEN_VISION_TOWER=1 \
  -e HALOGEN_COMPOSABLE_CONTEXT=0 -e HALOGEN_CACHE_DIR=/cache \
  -e HALOGEN_REASONING_EFFORT=low -e HALOGEN_MAX_TOK=16384 \
  -e HALOGEN_PREFILL_CHUNK=16384 -e HALOGEN_CACHE_PRUNE_OLD=1 \
  -e HALOGEN_CACHE_BRANCHES=3 \
  ghcr.io/peonist-ai/halogen-flash-server:0.16.0

啟動後記憶體實測行：

memory: 62.9 GiB of weights locked in RAM (0.8 of them the vision tower's),
        7.2 GiB of KV pool, 8.1 GiB of working memory, 78.3 GiB in all

單路完整數據（0.16.0 + v2，temp 0、effort low）

prefill 隨深度

4K → 260K 只掉 6%，沒有「越長越慢」。

decode（與深度無關）

decode 速度不隨上下文深度變化 —— 48/64 層沒有 KV cache。
它主要由投機解碼命中率（生成內容的可預測性）與樣本長度決定：
同一種任務在 192K / 244K / 256K 上分別測到 52.2 / 28.1 / 53.1 tok/s，
散布這麼大是短樣本的起停開銷造成的，不是「越長越快」。

檢索完整性（引擎 niah，深度 × 位置）

prompt cache

上限

prompt + max_tokens ≤ 262,144，用同一條 259,474 token 的提示詞卡過邊界：

max_tokens	合計	結果
2,670	262,144	200
2,671	262,145	400（leaving room for 2670）