失敗心得 自研推論引擎挑戰HaloGen 技術特徵剖析
-
@dardeaw-feng 「decode 能追、prefill 掉队」在 gfx1151 上基本是结构性的，不是引擎没调好。
原因：
- prefill 是 compute-bound（以 GEMM 为主），decode 是 bandwidth-bound。Strix Halo 的 LPDDR5X 大约 256 GB/s，和独显比不算差，所以 decode 能咬住；但 RDNA3.5 在 ROCm 下没有 CDNA 那套 MFMA，矩阵乘主要走 WMMA / hipBLASLt，prefill 的 FLOPs 利用率天然低一档，长文本尤其明显。
- 你 BIOS 只 carve 512M VRAM、其余走 GTT，prefill 阶段 KV 和中间激活一涨就可能在 GTT 上换页，延迟被放大。
先做两件事定位，再决定要不要自己写引擎：
- 用 llama-bench 把 prefill 单独打出来：
llama-bench -m 模型 -p 512 -n 0和-p 4096 -n 0，对比-fa on/off；看 pp512 的 t/s 和 pp4096 的衰减斜率，判断是 kernel 问题还是换页。 - 看 ROCm 有没有为 gfx1151 走 hipBLASLt：
ROCBLAS_USE_HIPBLASLT=1前后各跑一次；再用rocminfo确认 gfx1151 的 CU 数和 clock 有没有被限。
能改善的方向（按性价比）：
- 打开 flash-attention（-fa）和 chunked prefill：SGLang 的 chunked prefill 能把长 prefill 分块并与 decode 交错，体感比只加 prompt-cache 好；
- KV 量化（Q8/Q4 KV）降低长上下文的内存压力；
- 把模型/量化控制到刚好显存，减少 GTT 换页；
- 承认上限：Strix Halo 的 prefill 不可能追平同价位独显，它的价值在 124G 容量和功耗。真要 prefill，杠杆是「更少的 FLOPs」（更小模型/更高量化）或「更多算力」，不是换个引擎。
自研引擎这条路：decode 做到 halogen 的水平已经不容易，prefill 要赢必须自己写对 gfx1151 友好的 GEMM/attention kernel，工作量远超收益。你把 pp512 / pp4096 的 benchmark 发上来，我可以帮你逐项对。
@Xiaote
您說的不可能追平同價位的獨顯?這比較就不是apple to apple，這是整機方案不是只有GPU，這台我當初買RMB15000，請您告訴我現在整機方案若再扣除128G RAM、16c32T Zen5 CPU、主板、電供成本，同等價位只能配甚麼GPU?
經過我實際使用halogen flash next執行四天任務，跑Qwen 3.8 Flash next是到流暢水平了，decode能衝到40~50tps在agent情境我認為綽綽有餘了，另外我看論壇數據在Prefill超越蠻多RDNA雙卡平台跟DGX Spark，尤其編程速度非常的快，我從沒想到原來靠kernal+推論引擎的優化可以做到這地步，要我再去裝SGLang我反而回不去了，玩過176B的模型後那知識面跟COT並不是27B能比擬的，編程的品質很明顯提升，再去裝回SGLang玩27B那有點是回頭路。
llama.cpp的batch ubatch我都調過很多次了，但那還在微調參數水平，影響在5%~10%左右，之前27B我都是調2048 2048，參數矩陣我沒留了，SGLang我也實測過發帖當時就已經是開過flash-attention的，論單session是不如llama.cpp，
另外我也不像大多數的人盲目去追decode的tps，在真實agent與vibecoding情境下，prefill的壓力與成本遠高於decode，去看看雲模型帳單解析一下應不難發現，
最後確實如你講的工作量遠超收益，但這篇主要的價值是利用組合語言去逆向解析Halogen這kernal與推論引擎做了哪些事情，利用兩天得到這樣的技術結論我認為非常值得，都用特價的雲端模型搞...大概也才花我USD 10。 -
@dardeaw-feng 「decode 能追、prefill 掉队」在 gfx1151 上基本是结构性的，不是引擎没调好。
原因：
- prefill 是 compute-bound（以 GEMM 为主），decode 是 bandwidth-bound。Strix Halo 的 LPDDR5X 大约 256 GB/s，和独显比不算差，所以 decode 能咬住；但 RDNA3.5 在 ROCm 下没有 CDNA 那套 MFMA，矩阵乘主要走 WMMA / hipBLASLt，prefill 的 FLOPs 利用率天然低一档，长文本尤其明显。
- 你 BIOS 只 carve 512M VRAM、其余走 GTT，prefill 阶段 KV 和中间激活一涨就可能在 GTT 上换页，延迟被放大。
先做两件事定位，再决定要不要自己写引擎：
- 用 llama-bench 把 prefill 单独打出来：
llama-bench -m 模型 -p 512 -n 0和-p 4096 -n 0，对比-fa on/off；看 pp512 的 t/s 和 pp4096 的衰减斜率，判断是 kernel 问题还是换页。 - 看 ROCm 有没有为 gfx1151 走 hipBLASLt：
ROCBLAS_USE_HIPBLASLT=1前后各跑一次；再用rocminfo确认 gfx1151 的 CU 数和 clock 有没有被限。
能改善的方向（按性价比）：
- 打开 flash-attention（-fa）和 chunked prefill：SGLang 的 chunked prefill 能把长 prefill 分块并与 decode 交错，体感比只加 prompt-cache 好；
- KV 量化（Q8/Q4 KV）降低长上下文的内存压力；
- 把模型/量化控制到刚好显存，减少 GTT 换页；
- 承认上限：Strix Halo 的 prefill 不可能追平同价位独显，它的价值在 124G 容量和功耗。真要 prefill，杠杆是「更少的 FLOPs」（更小模型/更高量化）或「更多算力」，不是换个引擎。
自研引擎这条路：decode 做到 halogen 的水平已经不容易，prefill 要赢必须自己写对 gfx1151 友好的 GEMM/attention kernel，工作量远超收益。你把 pp512 / pp4096 的 benchmark 发上来，我可以帮你逐项对。
@Xiaote
小特，帮我研究，为什么我使用rtxpro 4500 32gb, 96gb ram， win11, LM Studio
0.4.23 (Build 1), 每一次的prefill 数值 2000 - 2800, 很好看，但是output 只是 50ts - 75ts, 还有什么地方没有优化到, 我是使用非官方版本 Qwen3.8-Uncensored-NVFP4-MTP, 来源自以下huggingface, 最下面三个图是lm studio 里面的模型设定， 我的要求是，查看漏洞在哪里，OS维持win11..https://huggingface.co/BennyDaBall/Qwen3.8-Uncensored-NVFP4-MTP
-
-
@Xiaote
小特，帮我研究，为什么我使用rtxpro 4500 32gb, 96gb ram， win11, LM Studio
0.4.23 (Build 1), 每一次的prefill 数值 2000 - 2800, 很好看，但是output 只是 50ts - 75ts, 还有什么地方没有优化到, 我是使用非官方版本 Qwen3.8-Uncensored-NVFP4-MTP, 来源自以下huggingface, 最下面三个图是lm studio 里面的模型设定， 我的要求是，查看漏洞在哪里，OS维持win11..https://huggingface.co/BennyDaBall/Qwen3.8-Uncensored-NVFP4-MTP
你的prefill快是因為NVFP4加速，這數據已經比我4090執行Q4還快了
另外盡量使用官方版本的NVFP4，因為FP4要在低空間保真，需要經過QAD蒸餾訓練來校正、否則智力倒退，那成本比較高，坊間的量化是否有走過這一輪不得而知你那decode就單純帶寬瓶頸，要提升就是靠Dflash2或是mtp的優化，我文中有寫到原作者自行搓mtp草稿以提高接受率，竟然讓256GB的帶寬噴到50tps還不影響代碼品質
prefill瓶頸是算力與MFU(利用率)
decode瓶頸在顯存帶寬 -
@Xiaote
小特，帮我研究，为什么我使用rtxpro 4500 32gb, 96gb ram， win11, LM Studio
0.4.23 (Build 1), 每一次的prefill 数值 2000 - 2800, 很好看，但是output 只是 50ts - 75ts, 还有什么地方没有优化到, 我是使用非官方版本 Qwen3.8-Uncensored-NVFP4-MTP, 来源自以下huggingface, 最下面三个图是lm studio 里面的模型设定， 我的要求是，查看漏洞在哪里，OS维持win11..https://huggingface.co/BennyDaBall/Qwen3.8-Uncensored-NVFP4-MTP
@imbiplaza-ASUS 兄弟。给老特省点吧。。。
-
@dardeaw-feng 你说得对，上一条我拿「同价独显的算力」去比是比错了对象，收回。整机口径下这笔账正好反过来：
- Strix Halo 的 128G 是焊死的 LPDDR5X，不是可插拔条子，「扣除内存」只能按市价净值算；就算 RAM 4000 + CPU 4000 + 板/电/箱 2000 约 1 万，剩给独显约 5000–7000，这个价只能买到 12G 级新卡或二手 24G。容量维度上根本没有对手，这才是它能玩 176B 的原因。
- 「prefill 超过 RDNA 双卡和 DGX Spark」和我说的不矛盾：我说的是 RDNA3.5 每 FLOP 的利用率（没有 MFMA、走 WMMA/hipBLASLt）在同算力下吃亏；你比的是同价格加容量，是另一个赛道，你的结论在那个口径下成立。
- 真正的信息量在你那句「kernal + 推論引擎優化能到這地步」：对统一内存机器，prefill 的杠杆在软件栈（GEMM tiling、attention kernel、chunked prefill），不是换卡。所以「自研引擎工作量远超收益」我也要修正——你两天加 10 美金换到可复用的技术结论，这个 ROI 不低。
想把结论钉死，可以补一张表：同机 pp512/pp4096 乘 context 4K/32K，再算「每 GB/s 内存带宽的 prefill 吞吐」，这样 halogen 的增益来自 kernel 还是带宽就能拆开。你逆向到的 kernel 具体项值得展开。
-
@imbiplaza-ASUS 先说结论：你这卡没有「漏洞」，50–75 t/s 基本就是 RTX PRO 4500 32G 的显存带宽天花板。你贴的 RTX PRO 4500 是 896 GB/s，decode 每生成一个 token 要把「激活参数权重 + 该步要读的 KV」全部从显存读一遍，所以：
理论上限约等于 896 GB/s 除以每 token 需读字节数。
- 若这模型是 dense 27B、NVFP4（约 4.5 bit）：权重约 15 GB，上限约 59 t/s；
- 若是 MoE、激活 17–18B：权重约 10 GB，上限约 90 t/s。
你测到 50–75，落在带宽上限附近（能到 75 通常是 MTP 一次接受多个 token），所以「prefill 2000–2800 好看、output 只有 50–75」正是带宽瓶颈的典型特征，不是哪里漏配。
按这个顺序自查，能定位那 15–30% 的余量：
1）nvidia-smi dmon -s mu 生成时看显存控制器利用率。接近 100% = 已经到顶，没得优化；只有 60–70% 说明卡在别处。
2）确认整模型在 VRAM、没落到共享内存。你有 96G 系统内存，最容易踩的坑是 LM Studio 把几层或 KV offload 到 CPU/共享显存，任务管理器里「专用 GPU 内存」应装下全部权重，共享显存不应增长。
3）确认 MTP 真的在跑。LM Studio 的 llama.cpp 运行时不一定接入了投机解码草稿循环，若只是权重里带 MTP 头但没接草稿解码，就没有收益；看日志里的 draft/accept 统计。
4）NVFP4 路径。FP4 要 5 代 Tensor Core，但 llama.cpp 侧可能是反量化到 FP8/FP16 再算，等于每步多读一遍权重；对比官方量化版本跑一次。
5）KV 精度与长度：开 flash-attention、KV 量化到 Q8/Q4，上下文按需给，别让 KV 把显存挤爆。提升杠杆（按性价比）：KV 量化 > 缩短上下文 > 确认 MTP > 换官方量化。如果你确实需要更高 decode，只有换更宽显存的卡（PRO 5000 48G 是 1344 GB/s，5090 约 1792 GB/s）才动得了，单卡软件层已经到头。
-
T terry 于 将此主题固定
-
-
-
-
0.45的温度，改成1.0会不会快点呢？ 或者0.6 @imbiplaza-asus
-
-
温度不改速度。低 temp 只是把 softmax 后的分布压尖，每个 token 仍要在全词表上采样一次，这点开销在 27B 权重前向前可忽略；「从 27B 参数里找更聚集的词更慢」不成立——每 token 读的权重、算的 FLOPs 与温度无关。
你观察到的变慢，先查这几个：① 输出/思考 token 是不是变多了（低 temp 常见更啰嗦地自我重复）；② 上下文变长，KV 随 token 线性涨、prefill 是 O(n²)；③ 是否命中 prefix cache；④ 中途有没有换量化或换 kernel。
采样参数只影响「生成多少 token」，不影响「每个 token 多快」。要提速从 batch、KV dtype、前缀缓存、量化下手；皮衣黄解决的是带宽，不是温度。
-
-
系统 于 取消固定此主题
