-
@starryskyknight 三个问题分开说，都是能直接上手验证的：
1. mamba 参数在 TP=2 下怎么算
--mamba-full-memory-ratio（默认 0.2）是给 mamba state 池预留的显存比例，不是绝对值。TP=2 时 state 张量按 hidden 维切到两张卡上，每 rank 只存一半——所以官方单卡 calculator 算出的 state 需求，落到每张卡上直接减半，0.2 这个默认值双卡下通常够用甚至偏松。别拍脑袋调：你反正开着--enable-cache-report，跑一轮长对话看 mamba 段实际占用和有没有 state 淘汰/重建日志——有淘汰就 +0.05，占用离上限很远就降到 0.15，把显存让给 KV。--mamba-track-interval 2048保持默认就行。2. HiCache 多 agent 并发
机制是三层 KV（GPU→RAM→NVMe），收益完全取决于前缀重叠度：多个 agent 共享同一套 system prompt + 工具 schema + 长文档时前缀命中率高，这正是它设计的场景（TID:1341 单卡 32GB 三层 KV 实测就是这类）；每个 agent 上下文完全独立时 L2/L3 命中≈0，跟你单 agent 的结论一致。量级上注意：262K 满上下文的 KV 是 GB 级，RAM 层换入零点几秒，SSD 层换入秒级——所以多 agent 场景要把热数据钉在 GPU/RAM 层，SSD 只放真冷会话。开
--enable-cache-report看各层 hit-len 统计，比问谁都准。顺带一句：TID:1329 Ben Lee 那个 HiCache 崩staged_write_back.cuh是 kernel 层问题（换 NVFP4 可绕），跟你在 3090 上跑不是一回事，别被吓到。3. 比 EAGLE K=3 更好的配置
你 accept len 3.85 ≈ K=3 的草稿窗口已经打满，瓶颈在窗口长度不在接受率——直接试
--speculative-num-steps 4~5+--speculative-num-draft-tokens 5~6，accept len 还能再涨，预期 +5~15%；每多一步多一次 verify 开销，收益递减，K=5 基本到顶。--speculative-eagle-topk 1是对的，topk>1 只对采样多样性有意义。DFLASH2 是 DeepSeek 系专属（TID:1340 那台 4090 48G 110 tok/s 就是它），Qwen 走 EAGLE/MTP 就是正解，不用换。另外 88 vs 178 的差距是输出长度摊薄固定开销的正常现象，不是配置问题。一个提醒：
--mem-fraction-static 0.94很激进，--max-running-requests 2正好压住；以后要多开 agent 记得降到 0.90 左右留余量。 -
精彩的分享
mamba-full-memory-ratio 官方默认为0.9，对于个人使用非常浪费显存。
最佳值需要根据mem-fraction-static和max-running-requests的值结合日志来看。
比如你需要：
max-running-requests = 4 ，那么你需要的max_mamba_cache_size应该为：44=16 (extra_buffer_lazy的情况下)
接下来查看启动日志：
max_mamba_cache_size是否为16
大于16就调小，比如0.35，小了就调大，直到这个值为16就是最佳值
如果没有开启extra_buffer_lazy的情况，这个值应该是45=20，这个看自己选择了。
另外
MTP+HiCache 目前确实性能冲突，推理速度腰斩是可能的。
只是开启HiCache的情况下，我的测试中推理速度影响为5%左右。
在内存配置为kv缓存1.5倍以上时，多会话能大幅减少prefill，减少首字吐字延迟。
如果配置了NVME，重启sglang可以完美命中之前会话的kv缓存。 -
精彩的分享
mamba-full-memory-ratio 官方默认为0.9，对于个人使用非常浪费显存。
最佳值需要根据mem-fraction-static和max-running-requests的值结合日志来看。
比如你需要：
max-running-requests = 4 ，那么你需要的max_mamba_cache_size应该为：44=16 (extra_buffer_lazy的情况下)
接下来查看启动日志：
max_mamba_cache_size是否为16
大于16就调小，比如0.35，小了就调大，直到这个值为16就是最佳值
如果没有开启extra_buffer_lazy的情况，这个值应该是45=20，这个看自己选择了。另外
MTP+HiCache 目前确实性能冲突，推理速度腰斩是可能的。
只是开启HiCache的情况下，我的测试中推理速度影响为5%左右。
在内存配置为kv缓存1.5倍以上时，多会话能大幅减少prefill，减少首字吐字延迟。
如果配置了NVME，重启sglang可以完美命中之前会话的kv缓存。 -
感谢分享，同双 3090 NVLink 4-link + SGLang 0.5.18，果断换去了AWQ。我同时测了 shawnw3i/Qwen3.8-27B-AWQ-MTP（标准）和 twolven/...-abliterated-AWQ-MTP（去审查）：
实测对比（正确的 token 口径）
另外加一点：功率墙有甜点。 我的机器有功率限制，扫了一遍：180W→62 t/s、220W→116、260W→162、300W→170。260W 是甜点（往上只 +5%，往下掉 28%）。如果楼主那台想控温/控电，可以试 260W，几乎不掉速。
-
感谢分享，同双 3090 NVLink 4-link + SGLang 0.5.18，果断换去了AWQ。我同时测了 shawnw3i/Qwen3.8-27B-AWQ-MTP（标准）和 twolven/...-abliterated-AWQ-MTP（去审查）：
实测对比（正确的 token 口径）另外加一点：功率墙有甜点。 我的机器有功率限制，扫了一遍：180W→62 t/s、220W→116、260W→162、300W→170。260W 是甜点（往上只 +5%，往下掉 28%）。如果楼主那台想控温/控电，可以试 260W，几乎不掉速。
-
，
T terry 固定了此主题
-
，T terry 将此主题从 LLM讨论区 移至此处
-
，系统 取消固定了此主题
-
@Leon-Y 二位的主板和CPU是什么样的呢？ @applejuice
-
感谢分享，同双 3090 NVLink 4-link + SGLang 0.5.18，果断换去了AWQ。我同时测了 shawnw3i/Qwen3.8-27B-AWQ-MTP（标准）和 twolven/...-abliterated-AWQ-MTP（去审查）：
实测对比（正确的 token 口径）另外加一点：功率墙有甜点。 我的机器有功率限制，扫了一遍：180W→62 t/s、220W→116、260W→162、300W→170。260W 是甜点（往上只 +5%，往下掉 28%）。如果楼主那台想控温/控电，可以试 260W，几乎不掉速。
@Leon-Y 感谢同配置实测，260W 甜点的数据很有参考价值！涡轮卡起飞噪音我也深受其害，回头照你的区间测一下 245-260W。
顺便更新我这边的最新状态（9/1 实测，SGLang main + zlab DFLASH2 draft）：
- 单路端到端（2500 token 长输出含 prefill）：82-84 t/s
- 双路并发 aggregate：151 t/s，峰值 161
之前帖子里说的 108/133 都是并发口径，单路口径一直就是这个数。DFLASH2 相比 EAGLE 的提升在并发场景更明显（+40% 左右）。
另外这两天 SGLang main 更新比较勤，我做了 A/B 对比（8/29 版 vs 9/1 版），性能一致无 regression，可以放心 pull。
你那边 162/150 是单路还是并发口径？想对齐一下数据。
-
@Leon-Y 感谢同配置实测，260W 甜点的数据很有参考价值！涡轮卡起飞噪音我也深受其害，回头照你的区间测一下 245-260W。
顺便更新我这边的最新状态（9/1 实测，SGLang main + zlab DFLASH2 draft）：
- 单路端到端（2500 token 长输出含 prefill）：82-84 t/s
- 双路并发 aggregate：151 t/s，峰值 161
之前帖子里说的 108/133 都是并发口径，单路口径一直就是这个数。DFLASH2 相比 EAGLE 的提升在并发场景更明显（+40% 左右）。
另外这两天 SGLang main 更新比较勤，我做了 A/B 对比（8/29 版 vs 9/1 版），性能一致无 regression，可以放心 pull。
你那边 162/150 是单路还是并发口径？想对齐一下数据。
-
@starryskyknight
我这边 162 是单路口径，而且单路下测出来跨度很大：内容 单路解码
数字计数（高可预测） ~162-168 t/s
JSON/结构化 ~168 t/s
Python 代码 ~130 t/s
英文/中英混合 ~98-102 t/s
中文散文（典型） ~77-85 t/s@Leon-Y 感谢分享!同为双 3090 NVLink,你的 260W 功率墙下 MTP 单路 162-168 t/s 已经很猛了。我们刚从 MTP 换到 DFLASH2,用同口径数据做个对照:
唯一干净的同口径(单路端到端):
场景 你的(SGLang 0.5.18 + MTP) 我们的(dev507 + DFLASH2) 中文散文 77-85 t/s 85.4 t/s 中文散文我们只赢 5-10%——中文可预测性低是共同天花板,DFLASH2 在这类场景优势不大,这和你的观察一致。
高可预测场景(口径不同,仅供参考):
- 你:数字计数单路 decode 162-168 / JSON 168 / Python 130
- 我们:JSON 并发 280.5(峰 303.7)/ Python 并发 254 / 短 prompt 单路 297.3
我们没测「数字计数单路 decode」这个口径,不能直接比。但 DFLASH2 一次接受的 token 数(代码场景平均 6.69)比 MTP 3 token 高一倍多,越可预测的场景差距越大。
三个差异点:
- 引擎代差:dev507 是 dev 分支,比 0.5.18 稳定版多了 DFLASH2 等一大票新特性
- 你的 260W 甜点(260→162 vs 300→170 只差 5%)很有价值,涡轮卡控温控噪刚需
- 我们没功率限制,满血跑
欢迎来 1502 帖子交流,那边有我们 DFLASH2 完整部署踩坑记录,以及「DFLASH 牺牲视觉」的实测辟谣(视觉任务思考开/关的 A/B 数据都有)。
-
@Leon-Y 感谢分享!同为双 3090 NVLink,你的 260W 功率墙下 MTP 单路 162-168 t/s 已经很猛了。我们刚从 MTP 换到 DFLASH2,用同口径数据做个对照:
唯一干净的同口径(单路端到端):
场景 你的(SGLang 0.5.18 + MTP) 我们的(dev507 + DFLASH2) 中文散文 77-85 t/s 85.4 t/s 中文散文我们只赢 5-10%——中文可预测性低是共同天花板,DFLASH2 在这类场景优势不大,这和你的观察一致。
高可预测场景(口径不同,仅供参考):
- 你:数字计数单路 decode 162-168 / JSON 168 / Python 130
- 我们:JSON 并发 280.5(峰 303.7)/ Python 并发 254 / 短 prompt 单路 297.3
我们没测「数字计数单路 decode」这个口径,不能直接比。但 DFLASH2 一次接受的 token 数(代码场景平均 6.69)比 MTP 3 token 高一倍多,越可预测的场景差距越大。
三个差异点:
- 引擎代差:dev507 是 dev 分支,比 0.5.18 稳定版多了 DFLASH2 等一大票新特性
- 你的 260W 甜点(260→162 vs 300→170 只差 5%)很有价值,涡轮卡控温控噪刚需
- 我们没功率限制,满血跑
欢迎来 1502 帖子交流,那边有我们 DFLASH2 完整部署踩坑记录,以及「DFLASH 牺牲视觉」的实测辟谣(视觉任务思考开/关的 A/B 数据都有)。
@starryskyknight DFlash或者DSpark会更有前途，因为工作原理有差距，它草稿模型先工作，主模型验证，这样很多时候连显卡风扇都不转。
-
@starryskyknight DFlash或者DSpark会更有前途，因为工作原理有差距，它草稿模型先工作，主模型验证，这样很多时候连显卡风扇都不转。
