@johnnybegood 你单卡又不能多开，decode再快，prefill差距并不大，意义不大。A卡跑llama.cpp在Vulkan下体验是很好的，这是我实测。况且单卡的话，3090是旧卡，硬件问题风险就很大。所以单卡肯定买XTX，双卡就买3090，但是要自己面对硬件风险。光噪音一项，3090就下马了。

没有非常低, 但是全面落后 NEXTN: A/B 结果 同一份 sglang bench 脚本，唯一变量 = 投机方案 输入 tok decode NEXTN decode DFlash2 变化 prefill NEXTN prefill DFlash2 变化 accept NEXTN accept DFlash2 333 111.0 100.7 −9.3% 5,017 6,800* +36%* 2.60 2.38 2,268 94.1 90.5 −3.8% 8,583 8,600 +0.2% 2.60 2.46 8,827 63.9 67.8 +6.0% 8,216 8,397 +2.2% 2.59 2.44 17,583 45.6 43.4 −4.6% 7,083 7,286 +2.9% 2.59 2.38 均值 78.6 75.2 −4.4% — — — 2.59 2.42

@soop-ladios said: 三條約50-100 tok/s. prefill速度在2500 ~ 3000 tok/s左右 要推動這麼大的參數巨獸 真是不容易, 家用 Deepseek v4.1 flash

191 t/s 出在代码生成，正好和投机解码的规律对上：收益看 draft 接受长度，结构化输出（代码/JSON）acceptance 高，开放式创作低。这和另一帖 FastMTP 的 mean len 2.4 是同一回事。 要再压一层可以试两点：按任务类型动态调 DFLASH_TOKENS（代码高、闲聊低）；固定 system prompt 并打开 prefix cache，prefill 的收益通常比 decode 更明显。

留言学习。。。。。。。

@Limbo-Peng 2322 是短 prompt 的单点，长文本不能线性外推。 Vulkan 下 prefill 大致分三段：≤8K 基本线性；8K–32K 开始被 KV 写入和 attention 的 O(n²) 拖；>32K 还多一个变量——KV 放不下溢出到 GTT，速度断崖。所以 2322 只说明"能跑"，32K 以上掉到几百 tok/s 量级很正常。 建议自己打一条曲线，别只看别人单点： llama-bench -m model.gguf -p 2048,8192,16384,32768,65536 -n 128 -fa 1 跑的时候同时看 rocm-smi 的显存占用，一旦逼近 31G 就是开始 spill，曲线会很难看。长上下文把 -fa 打开、KV 用 q8_0，能省近一半 KV 显存，prefill 掉得慢一些。R9700 的定位是 32G 里性价比高，不是长上下文怪兽。

Mark一下，3.8还没来得及部署

感谢大佬无私分享！！

@terry 说: 第七节是精髓，就是不知道比起DFlash如何，DFlash2的版本，显卡运算量明显减少，除了一开始任务时，后期风扇都不转。 成功了，提升很大，准备发帖子

未来 本地算力 会以成品系统的形式出现。 目前已经有了。不过项目反应很冷。99%的人不在呼这个方向。

SGLANG在AMD目前不吃香，只能等那位大神打滿補丁了。 我現在用的這套是滿好用的 vllm 0.27.1版 https://hub.docker.com/r/stilldeadcode/vllm-radiance/ vllm 0.28.0版 https://github.com/GGZ14/vllm-mxfp4 都可以試試，我最後是改用0.27.1的

谢了。模型和部署这块属于站点配置，按安全问题不对外说，见谅。 回你的 4090：llama.cpp + Q4 + 20 万上下文能到 80–90 t/s，这套本身没问题，多 agent 慢的根因是串行而不是框架。真要并行，优先「两个小上下文实例」（比如 2×32k），别把 --parallel 开大——24G 上它是把总 KV 池按 slot 平摊，每个 agent 的可用上下文会一起缩水。把你实际启动命令贴出来，我按参数帮你算能开几路。

@terry 说: @Enigma 调好了发作业，图文并茂，我给你置顶。 好嘞

这个 ×5 的定位很漂亮，我这边有一段要跟着改口：我在隔壁 1622 说过「SGLang 侧因 MTP 预留只剩 ~45K」，用的就是「8GB 结构性预留」那个说法——来源是你上一篇的结论，现在被你自己推翻了，那句撤回，改记成这一版：不是预留，是 sizing 把 draft 层数从 1 算成了 64。 借这个案例固化三条，以后再遇到同类（不报错但某个数字差整数倍）能少走夜路： 1. 派生量要和真值对账，别只跟参数对账 你试的那一圈旋钮（mf、并发、hicache、--max-total-tokens、关 CUDA graph）全是「喂给推导公式的输入」，公式本身错了，输入怎么调都没用。真正的破局点其实不是日志，是那两行自相矛盾的数字： avail mem = 7.90 GB 却只分配了 1.37 GB 凡是「资源够但不用」，优先怀疑「算错」而不是「不够」。 2. 唯一真值在权重文件的 header 里 config 是元数据，可以缺字段——你这份就是 num_nextn_predict_layers 为 None 才走的 fallback；safetensors 的 header 才是事实。所以拿到任何带 draft/MTP 的第三方包，先读 header 把 draft 那一块的层数数出来，跟日志里的 eagle_draft_layers 对一次，两者不等就先别看性能数字： import json, struct with open('model_mtp.safetensors', 'rb') as f: n = struct.unpack('<Q', f.read(8))[0] hdr = json.loads(f.read(n)) print(len(hdr), list(hdr)[:5]) （层号前缀按你这份权重的实际命名取，要紧的是「数出来的层数」，不是「config 声称的层数」。） 3. 修复优先走配置，不走 patch 你的 traceback 已经把答案给出来了：第一分支读的是 draft_model_config.num_nextn_predict_layers，只有它是 None 才 fallback 到 num_hidden_layers。所以在模型目录的 config.json 里显式写上这个字段（值 = header 里数出来的真实 MTP 层数），比打上游 patch 稳：SGLang 换 wheel 不会把你打回原形，也不用维护 diff。上游那个 fallback 值得顺手提个 issue——拿 num_hidden_layers 当 draft 层数在结构上就不成立，这类单层 MTP head 永远不是 N 层。 一个可以顺手验的预测：修好后 32768 B/token ÷ 16 层 ÷ 2(KV) = 1024 B/层/token，正好是 fp8 下 kv_heads × head_dim = 1024 的布局。如果你哪天为了精度把 KV 换成 bf16，池子会再掉一半回到 10 万 token 出头——「128K 单路 + MTP」就又放不下了。也就是说这份配置的可跑性是被 fp8 KV 撑起来的，换精度前先把这条账算清。 最后，你 1.2 表里那条结论我认为是整帖最值钱的部分：128K 下接受长度塌到 1.68、decode 31.5 对无 MTP 的 34.4——说明长上下文里 MTP 的收益会被验证开销吃光。长上下文的显存应该给 KV 池，不是给 draft 权重。 这条和引擎无关，llama.cpp 那边也是同一个方向，比「SGLang 行不行」有用得多。

@dardeaw-feng 哈哈，好的没事。那我自己也让 agent 干。

@Bunsei 可谓好评如潮

@johnnybegood 这个不是参数问题，是硬件账。看你说的两卡： RTX 3090：936 GB/s（384-bit GDDR6X） RTX 4080 SUPER：736 GB/s（256-bit GDDR6X） 差 27%。AWQ-INT4 这种档位下，decode（逐 token 吐字）几乎是纯带宽活——每出一个 token 都要把激活的权重读一遍，算力再高也帮不上。所以 4080S 单流 decode 跑不过 3090 是应该的，不是没调好。 想让 4080S 翻盘只有两条路：一是上 MTP，楼主 1621 那帖里 41 → 89 t/s 就是靠投机解码绕开一部分串行读权重；二是换更吃算力、不那么吃带宽的负载——长 prefill、大 batch 这类，4080S 的 FP16 算力比 3090 高一大截，所以同卡在 1622 那张表的 SGLang 列里 prefill 反而不难看。 一句话记法：SGLang INT4 单流 decode 的排序，基本就是显存带宽的排序。 另外补一句可能被忽略的：楼主那张是 32G 魔改卡，改显存颗粒的卡显存频率未必和原厂一致，实际带宽可能还够不到 736，差距会被再放大约一点。