抡锤者

@909 哈哈所以7900XTX持有者们需要多多出来碰瓷。现在MOE模型硬件门槛这么低了，7900XTX的独特地位确实有所下降，但是我辈既然买了就不纠结，干就完了。

不错，最近strata风头太盛，ninfer热度不足了，不然是个很好的帖子。

為了讓這類專用推論引擎能移植到RDNA家族，這是我啃了它十五個 kernel 後。gufo 快不是一個絕招，是十層疊起來的「零浪費」哲學： 讓它快的關鍵（按影響排序） 1. Dequant 永遠不落地（最大的一塊） 權重以 int8 進 WMMA，scale 只在最後乘一次——fp16 權重從不存在於記憶體。llama.cpp 系是先解量化成 fp16 再算（頻寬翻 2~4 倍）。這就是為什麼 Q3_K_M 跑出 310GB/s 有效頻寬：它真的只讀了 13GB。 2. 什麼都 fuse RMSNorm＋量化 activation：一遍搞定（FusedRMSNormQuantizeQ8_1） SwiGLU：gate＋up＋激活函數一個 kernel（BlockedSwiGLUFp32） Attention：QK^T＋softmax（online 跑 max/sum）＋P×V 全在 LDS 裡轉完，S 矩陣不出片 每 fuse 掉一次就省一整輪 VRAM 讀寫——decode 這種 memory-bound 場景直接變速度 3. 一個形狀一種 kernel，不做通用 small batch、prefill、wave64 是三套獨立 kernel（small_batch_wave64、prefill_quant、w8a8），不是一個 kernel 加 if。這就是它目錄爆炸的原因，也是它快的原因——每個 kernel 的 tile、occupancy、swizzle 都是為那個形狀手調的 全 constexpr＋static_assert：head_dim、GQA 數全是編譯期常數，runtime 零分支 4. WMMA 玩到極致 hand-written wave32/wave64 fragment，LDS swizzle 避 bank conflict（LoadSwizzled 那套），launch bounds 壓 occupancy——我在移植時看到的每個常數都是調過的 整數 dot 走 wmma.i32（Q8 累加 32 位，精度還比 fp16 好） 5. 零框架稅 沒 torch、沒 ggml graph dispatch——C++ 直接 launch kernel，權重一次 hipMalloc 常駐，scratch 重用，session 預分配。llama.cpp 的 graph 開銷在它這裡是零。 6. 推測解碼雙保險（qfn 有 ngram.cpp＋MTP）：n-gram Lookup＋小模型 draft 兩路並行，decode 少跑好幾次大模型。 7. Strix 紅利（不可移植）：gfx1151 調校＋128GB 統一記憶體零拷貝——這部分是作弊，換硬體就沒了。 哪些概念能搬去別的引擎 概念 可搬性 說明 dequant-in-register（永不落地） 任何 memory-bound 引擎吃了都快，llama.cpp 最該抄 norm+quant+GEMM fuse 純工程活，無硬體依賴 online softmax＋S 不出片 FlashAttention 已在做，gufo 版更激進 形狀特化 kernel（小 batch 獨立路徑） 要維護成本，llama.cpp 的 mmpq 方向類似但沒這麼絕 speculative 雙 draft n-gram 表那套很便宜，人人可抄 WMMA fragment 手調 綁架構（我現在手上有 gfx1151＋gfx1201 兩套 mapping，要的拿去） 統一記憶體假設 別學，會死（問我怎麼知道的） 一句話總結 gufo 的哲學是：把「通用」當成敵人——通用格式、通用 kernel、通用框架，每個通用都收稅；它一個個手寫收回來。這套在它能覆蓋的模型上無敵，代價就是新模型新架構要重寫一遍。

Dflash2效果最好，4090也是，NVFP4是50系列红利，搭配Dflash2应该就是当下最好的方案了。

高值入场和自杀没什么区别。 非使用现阶段入场都是资本的韭菜。

@johnnybegood 你的修正基本对，补两点。 UNO 就是把 DFlash/EAGLE 那类草稿模型「LoRA 化」：挂着主模型，用一个小 adaptor 出 draft，再由主模型做树验证。所以它是 speculative decoding 的一个 head 变体，不是「多种策略叠加」。你说的 NGRAM + DFlash 不能叠也对，SGLang 一次只选一个 spec algo；要混合只能两个 server + 客户端按 prompt 路由。 27B 没公开 LoRA 很正常：草稿头要拿同 tokenizer 的基座训，8B 训得起、验证快，社区先出 8B。两条路： 先跑 8B（s-sahoo/uno-qwen3-8B 或 SGLang cookbook 的 UNO 例子），量一下接受长度和加速比，确认值不值得投。 27B 自己训。注意词表/tokenizer 必须和目标模型一致，LoRA 秩不用大，重点是草稿分布要贴近 target。 入口是 --speculative-algorithm UNO --uno-lora-path <path>，镜像里的 uno_worker_v2 / uno_tree 就是树验证那套。提醒一句：spec decode 的收益跟输出长度强相关，输出短（agent 读指令、打标签）时收益有限，那种场景先把 prefill 做好更值。

这个作业抄的太晚了，大家早就抄完了.....

@terry @enigma 找到原因了, 测试方法不一样, 下面是我让AI给我的一个简要总结: 一句话结论 不是环境差异，是测的任务类型不同。 接受长度几乎完全由任务类型决定。 同一台机器、同一个目标模型、同一个 DFlash2 草稿，只换 prompt 类型： 任务类型 我们的 accept 速度 强制续写散文（我们最初一直用的） 2.4 45–93 t/s 摘要 2.86 92.5 t/s 中文创作 3.05 66.5 t/s 代码 4.99 164.6 t/s 抽取原文（照抄） 5.94 211.4 t/s 为什么会产生“他高我们低”的错觉 他的 4.74～5.33 是把整组任务合成的单一数字，而组里包含**“抽取原文”和“代码”**这两类近乎照抄的任务——它们天然把接受度拉到 5～6。 他表里三个场景的速度是分开报的，接受长度却只给一个合计值。这个合计值被高接受类主导了。 我们最初使用的： 散文续写 + ignore_eos 强制截断 256 token 是最难的一类——模型被逼着无目标地续写，接受的 token 最少。 因此，我们实际上是拿最难的类别去比较他的合计值，自然会出现接受长度相差接近一倍的现象。 换成他的任务类型后，我们反而比他快： 抽取原文：211 vs 143 t/s 代码：165 vs 130 t/s 顺带被否证的三个猜想 量化头（NVFP4 打包头） 单变量换 BF16 稠密头 accept：2.50 → 2.56（+2%） 但速度反而慢 10%～18% INT4 vs NVFP4 下载同名 INT4 checkpoint 实测 accept：2.51 vs 2.50 几乎零影响 而且 TTFT 翻倍 草稿选型（DFlash2 / DSpark / NEXTN） 同一任务类型下差距仅约 ±7%

@Ben-Lee 是的，有hicache就完全够用。有图的话可以单独发个帖子说明下。

还是大佬们多我还在摸索

https://youtu.be/00sLtkFo41w

@用户名违规 求大哥给个配置方法，另外请问你用的是哪个模型？可以说一下吗，谢谢啦

我试了dflash， 比普通mtp更慢了

@stxpnet 我在国外，邮寄需要一个星期多 前两天搞到卖家手上，不知道他们几时才能给回复 现在用着 Item Value Model Qwen3.8-27B UD-Q4_K_M (16.46 GB, sha256-verified, nextn head present) Engine llama.cpp b10498-60addddf3, static CUDA sm_86 Context 135,168 KV q8_0 / q8_0 Vision on (mmproj-F16) MTP draft-mtp, n-max 2

@terry 在文末补上了部分log。其实发这个帖子是看到论坛里面没什么人尝试7900xtx+Windows+vulkan，补一下刚刚更新的后端的测试。如果需要补充更多截图或者原始log我都有留档，希望有所帮助。

任何模型能工作才是最重要的。网络中的各种测试都是一个参考。只能作为你没安装前的考量参数。 输出速度再快。不能24小时无人值守运行程序也是一个展示型玩物。 这篇帖子的精华是给大家一个低门槛能链接互联网的 Qwen 27B。没有这个基础模块各种项目无法开展。 没上更复杂的链接方式是讲清楚让所有人都能安装太墨迹了。这套操作的适用行最强。安装最简单。