@terry 真实心得回覆
我今天用 deepseek harness +deepseek v4.1 flash 做一个研究任务 ，
但一直失败，
后来我切换到codex和claude code 一样接入deepseek v4.1 flash，
也是一直提示失败，查询后原来是触发了风控，我也不知道哪个东西风控了。
一怒之下我用deepseek harness 切换到我的本地去审查 千问3.8 27b，
慢了点 但顺利完成 且质量还不错 越来越感受到本地部署的重要性了，
不然我今天的工作就卡在那边了。

看完YT 直接安裝了 非常好用

@terry 特哥 好消息 flash 明天中午开始降价

@neo 也太厉害了 我这两天都在跑这个 甚至还有延伸到1M的上下文 被先破题了

@X一棵树
这个特哥说了很多次 我不多说了......
如果手上卡很多不要急...慢慢来......
如果真的想证明 就跑实例出来让大家抄作业

@williamlouis 主要是带宽管饱,两张 3090 够 27B 吃满, NVLink 把同步税砍掉后确实到头了。

@stormaround 有用就行。双 R9700 上 MTP/DFLASH 增益相近这个数据很宝贵，AMD 平台的 DFLASH 适配确实起步晚。这版 SGLang dev 对 DFLASH 动了不少（f60bc73c 修 TP 状态分歧 + draft cuda graph 默认启用），ROCm 下值得再试一轮。

@Don-zhu 收到，三个问题逐一回：

PCIe：我这边也是 x8+x8——Z890 平台 CPU 直出 20 lanes，x16 槽拆 x8/x8（PCIe 5.0），两卡各 x8，跟你一样。唯一物理差异就是 NVLink 桥。

CPU：Core Ultra 9 285K（24 线程）——巧了，跟你 13700K 线程数一样，所以并发差距不在 CPU 线程数。先说个口径：我 OFF 同 prompt 是 518.4 / 不同 550.8（不是 440）。真正的差距在你的 NCCL_P2P_DISABLE=1：TP=2 每步同步激活，你禁 P2P 后同步走 host 内存中转，并发多路时同步次数放大，差距就显形了。证据是模式：单路 218 vs 270（-19%），并发 -31%~-33%，差距随并发放大正是同步带宽特征。验证方法：打 smcleod/nvidia-p2p-patch 开 P2P（无 NVLink 的 3090 跨卡 P2P 默认被驱动锁，patch 后走 PCIe 4.0 x8 双向 ~16GB/s，远好于 host 中转），重跑并发——差距缩到 ~20% 以内就证伪 CPU 假设了。

mem-fraction 0.90：0.94 时日志打 Disable DFLASH draft cuda graph because only 0.93 GB GPU memory is available——graph 被挤掉；0.90 恢复启用（selector decode 也折叠进去）。精确 avail 我没记，估算 0.90 时 ~1.9GB 上下，看你自己启动日志这行的数字最准。你 0.88 单路略好我信，但会压缩 KV cache 上限，长 context 档位先吃紧，看用途取舍。

@applejuice 350W 这组 prefill 档位数据收了,19k 181k 从 1966 掉到1141 t/s(-42%)、TTFT9.8s 159s,退化曲线 很有用。

不过有个反直觉点想对齐:350W 墙下代码 284.9 反而比无

墙 246.7高 15%,散文 72.7 也高 18%,英文/中文却掉 10-21%——不像功耗墙特征,更像 prompt 或热身后的状态差 (tok/chunk 也不一样:6.69 vs 6.32)。方便的话同 prompt 无墙再跑一轮对照?真复现了就是功耗墙时钟策略对某些负 载有利,那是个大发现。

我的千问3.8 27b也回应正常

@terry 没错 感谢建议 实装后 目前主力是DFlash2 在另一篇贴文内 就不转过来了 感谢推荐

@johnnybegood 对齐口径后你的两个问题都有答案了:

3090+3080 = 我的 69.8%, 不到 80% (188.5/270.2, 同 thinking OFF 同脚本). 原因两个都是硬伤:

1. 前向被 3080 拖住: TP=2 平均分算力, 你 33 次/s vs 我 50 次/s -- TP 同步永远等最慢那张卡, 楼上 applejuice 说的没错, 平均分配救不了
2. 20GB 锁死 mem-fraction: SGLang 按最小卡分配, draft 模型和 KV cache 空间受限, CUDA graph 可能也开不起来

"哪里怪怪的": 你的 TTFT (0.098s) 反而比我快, 是 radix 命中+短 prompt, 但 decode 阶段短板效应全部显形.

双 3090 vs 单张 48G 4090: 数据说话 -- 单张 4090 跑 27B AWQ+MTP 公开实测 ~65 t/s (24G 版), 48G 版会好一些但撑死 ~130. 我这套 thinking OFF 代码 270, 并发 550. 4090 单卡优势是省电省心, 绝对速度不在一个量级. 内存双通道那个类比不成立: TP=2 是张量切分不是带宽叠加, 两张 3090 不等于一张 4090x2.

@applejuice 统一脚本收到, 跑了两轮 (rounds=2), 顺带把你的 thinking 疑问一起答了: 我回帖的 235.9 确实是 thinking 默认 ON (今天用你的脚本复测 ON=237.4, 完全印证). 关掉 thinking 之后, 我这边的数字:

thinking OFF (你的脚本, 同 prompt 同 t=0)

• 代码 270.2 (tok/chunk 5.38) | 英文 165.6 | 中文对话 129.2 | 散文 78.6
• 并发同 prompt: 518.4 | 并发不同: 550.8

对齐你 thinking OFF 的 246.7 / 429.7 / 402.4: 单路 +9.5%, 并发同 +20.6%, 并发不同 +36.9%.

有意思的是你的 accept rate 更高 (代码 6.32 vs 我 5.38), 但总速度我赢 -- 前向速率我 50 次/s, 你 39 次/s. 单路差距小 (9.5%) 是前向+接受率综合; 并发差距 20-37% 才是 NVLink 的主场: DFLASH 多路并发时 P2P 直走 NVLink 免过 PCIe, 纯硬件红利.

thinking ON 我这边的数据也贴上: 237.4 / 473.7 / 488.7 -- 开关在我这只差 ~13% (代码场景), draft 模型吃思考 token 的效率还行.

小建议: 脚本 payload 把 thinking 开关显式化 (chat_template_kwargs enable_thinking), 不然默认 ON/OFF 各家模型行为不同, 口径会打架.

Setup: SGLang 0bdc15d2 (今晨升级 main 最新), twolven-Qwen3.8-27B AWQ MTP, TP=2 NVLink, DFLASH2 block 8, fp8 KV.

@applejuice 明白，我这边也是 AI 全自动跑。对上了：你并发同 prompt 的 429.7 就是 radix 命中场景，对应我这边 433.8 / 445.3（3 轮均值，两轮共 6 次），同口径我略高 3% 左右，算噪音范围内打平。

统一脚本来了，prompt 全部写死，双方跑同一套才算数。零依赖，直接跑：

#!/usr/bin/env python3
"""SGLang DFLASH 统一基准 v1 — 双方同 prompt 对测
用法: python3 uni_bench.py --model <模型名> [--base-url http://127.0.0.1:8000] [--rounds 3]
口径: decode=(comp-1)/(总时间-TTFT); aggregate=两路decode重叠窗口的总token/窗口"""
import argparse, concurrent.futures, json, time, urllib.request

P = {
    "code": "You are an expert Python engineer. Write a complete implementation of a thread-safe LRU cache class with TTL expiration support, including unit tests. Provide only code, no explanation.",
    "code_b": "You are an expert systems engineer. Write a complete implementation of a lock-free SPSC ring buffer in C++17 with acquire/release memory ordering annotations. Provide only code, no explanation.",
    "en_tech": "Write a detailed technical explanation of how speculative decoding with a draft model works, covering the draft-verify loop, acceptance criteria, and why acceptance rate varies by domain. Aim for depth and precision.",
    "cn_chat": "请用中文详细分析一下，为什么家用路由器长期不重启会越来越慢？从内存碎片、连接跟踪表、NAT 状态老化三个角度展开，给出可操作的解决建议。",
    "cn_essay": "请写一篇关于秋天的散文，描写北平的秋色，要求文笔优美，有细节描写，不少于五百字。",
}

def gen(base, model, prompt, mt=512, t=0.0):
    payload = {"model": model, "messages": [{"role": "user", "content": prompt}],
               "max_tokens": mt, "temperature": t, "stream": True,
               "stream_options": {"include_usage": True}}
    req = urllib.request.Request(base.rstrip("/") + "/v1/chat/completions",
                                 data=json.dumps(payload).encode(),
                                 headers={"Content-Type": "application/json"})
    t0 = time.time(); ttft = None; nch = 0; usage = None
    with urllib.request.urlopen(req, timeout=900) as r:
        for raw in r:
            line = raw.decode().strip()
            if not line.startswith("data:"): continue
            d = line[5:].strip()
            if d == "[DONE]": break
            try: j = json.loads(d)
            except Exception: continue
            if j.get("usage"): usage = j["usage"]
            ch = (j.get("choices") or [{}])[0].get("delta", {})
            if (ch.get("content") or "") or (ch.get("reasoning_content") or ""):
                if ttft is None: ttft = time.time() - t0
                nch += 1
    total = time.time() - t0
    comp = usage["completion_tokens"] if usage else 0
    if ttft is None or comp <= 1:
        return {"comp": comp, "ttft": None, "total": total, "dec": 0.0, "tpc": 0.0}
    return {"comp": comp, "ttft": ttft, "total": total,
            "dec": (comp - 1) / (total - ttft), "tpc": comp / nch if nch else 0.0}

def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--base-url", default="http://127.0.0.1:8000")
    ap.add_argument("--model", required=True)
    ap.add_argument("--rounds", type=int, default=3)
    ap.add_argument("--max-tokens", type=int, default=512)
    a = ap.parse_args()
    print(f"# 统一基准: {a.model} @ {a.base_url}  rounds={a.rounds} max_tokens={a.max_tokens} t=0\n")
    print("## 单路（四场景）")
    for name, pr in [("代码生成", P["code"]), ("英文技术论述", P["en_tech"]),
                     ("中文常规对话", P["cn_chat"]), ("中文散文", P["cn_essay"])]:
        rs = [gen(a.base_url, a.model, pr, mt=a.max_tokens) for _ in range(a.rounds)]
        ok = [r for r in rs if r["ttft"]]
        if not ok: print(f"  {name}: 失败"); continue
        print(f"  {name}: decode {sum(r['dec'] for r in ok)/len(ok):.1f} t/s | "
              f"TTFT {sum(r['ttft'] for r in ok)/len(ok):.3f}s | tok/chunk {sum(r['tpc'] for r in ok)/len(ok):.2f}")
    print("\n## 并发 2 路（代码场景）")
    for label, ps in [("同 prompt（radix 命中）", [P["code"]] * 2), ("不同 prompt", [P["code"], P["code_b"]])]:
        aggs = []
        for _ in range(a.rounds):
            with concurrent.futures.ThreadPoolExecutor(2) as ex:

rs = list(ex.map(lambda p: gen(a.base_url, a.model, p, mt=a.max_tokens), ps))
            rs = [r for r in rs if r["ttft"]]
            if len(rs) < 2: continue
            aggs.append(sum(r["comp"] - 1 for r in rs) / max(r["total"] - r["ttft"] for r in rs))
        print(f"  {label}: aggregate decode {sum(aggs)/len(aggs):.1f} t/s (n={len(aggs)})" if aggs else f"  {label}: 失败")

if __name__ == "__main__":
    main()

我这边结果（NVLink、mem 0.90、flashinfer sampling、dev507+27 commits）：

单路 decode t/s：代码 237 | 英文技术 166 | 中文对话 123 | 中文散文 92
并发 2 路：同 prompt 440 | 不同 prompt 390

等你跑完贴数。另外两个问题还等你答：
① expandable_segments + mem 0.93 你 draft graph 开得起来吗？我 0.94 就崩（draft graph 差 0.93GB 内存）
② 你机器具体什么卡？几张？同硬件这对比才有意义
③ 你 tok/chunk 6.69 是 verify 步口径，我脚本里 tok/chunk 是 stream chunk 口径，两边数字别直接比，只比 decode t/s 和 aggregate

@applejuice 你这数据有意思，我今早刚按统一口径复测了一轮，先对齐再下结论。

1. 口径真相：429.7 vs 249 不能直接比

我旧帖「并发 219.1 avg / 249.1 峰」是端到端含 prefill（两路同 prompt、威士忌长文、t=0.7、max 1024），你的 429.7 是纯 decode 重叠口径。我早上用你的口径重测，服务没退化。

2. 统一口径复测（t=0、max 512、代码场景、streaming + include_usage）

· 单路 decode（代码）：235.9 t/s（4.7 tok/chunk）
· 并发 2 路·同 prompt（radix 命中）：449.0 t/s
· 并发 2 路·不同 prompt：333.8 / 380.3 t/s（overlap 1.5×）
· 中文散文单路：89.3 t/s · 散文并发 2 路：181.8 t/s（overlap 2.0×）

同 prompt 并发我 449 略超你 429.7；不同 prompt 并发我 overlap 只有 1.5×，你 1.89× —— 这块想找你对齐几个细节。

3. 想找你要的数据（抄作业用）

① 你并发测试两路 prompt 是相同还是不同？相同（radix 命中）的话你的 429.7 对应我 449；不同还能 1.89× 的话，你的调度比我强，我认抄。
② 完整硬件：GPU 型号/数量、CPU、内存、PCIe 代数通道。你从没贴过配置，nvlink 翻车前你是什么卡？
③ expandable_segments:True + mem 0.93 还能开 draft graph 吗？我 0.94 时 draft graph 内存不足（差 0.93GB），降到 0.90 才开。你 0.93 能开我就立刻抄。
④ --sampling-backend pytorch vs 默认 flashinfer 有实测差异吗？

4. 统一测试法提案

温度 0、max_tokens 512、TTFT / decode / 端到端三个数分开报、并发注明两路 prompt 同异 + radix 状态、贴 SGLang commit。你我各跑一轮贴数据。

你我代码场景 tok/chunk 都在 4.5-6.7 区间、底层前向速率都 38 次/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 高一倍多,越可预测的场景差距越大。

三个差异点:

1. 引擎代差:dev507 是 dev 分支,比 0.5.18 稳定版多了 DFLASH2 等一大票新特性
2. 你的 260W 甜点(260→162 vs 300→170 只差 5%)很有价值,涡轮卡控温控噪刚需
3. 我们没功率限制,满血跑

欢迎来 1502 帖子交流,那边有我们 DFLASH2 完整部署踩坑记录,以及「DFLASH 牺牲视觉」的实测辟谣(视觉任务思考开/关的 A/B 数据都有)。

@applejuice 「200 多 decode」解释：楼上已经说到点子上了——底层前向速率恒定约 31 次/秒，速度 = 31 × 每次前向接受的 token 数。DFLASH 一次草稿 8 个 token，主模型一次前向验证。代码场景一次能接受 6.69 个 → 207 t/s；中文散文只接受 2.06 个 → 52.7 t/s。「249 新高峰」是并发 2 路的 aggregate 口径，单路端到端（含 prefill）一直是 82-88 t/s，两个口径不矛盾。

@stormaround
关于「DFLASH 牺牲视觉」：不会，正好今天实测验证了。DFLASH 只参与 decode 阶段（草稿出 token），图像编码在 prefill 阶段完成，两段正交。twolven 这个 AWQ 版视觉塔保留 bf16 未量化，模型卡原文就有 "vision still works"。今天 curl 直传图片实测：读图 100% 正确（形状/颜色/文字全对），同时段 DFLASH accept rate 0.28-0.40 照常跑，零冲突。真实照片测试连法文成分表都能正确 OCR。

@johnnybegood

主模型（AWQ INT4，MTP 保留）：https://huggingface.co/twolven/Qwen3.8-27B-abliterated-AWQ-MTP

DFLASH2 草稿模型：https://huggingface.co/incoai/Qwen3.8-27B-DFlash2 （z-lab 有镜像）

3090 + 3080 无 NVLink 能不能抄：能，方向对（NCCL_P2P_DISABLE=1 走 host bounce），三个注意点：

1. 3080 必须是 12GB 版：主模型 18.7GB TP2 均分后每卡约 9.4GB，再加草稿 + KV cache + 激活值，10GB 版会爆显存。12GB 版可以，mem-fraction 建议 0.85 起步，给 draft CUDA graph 留空间（我们 0.94 时 draft graph 被挤掉过，降到 0.90 才启用）。
2. 预期掉速：无 NVLink 走 PCIe host bounce，底层前向速率会低于 31 次/秒，粗估掉 20-35%，代码场景 207 t/s 大概落到 130-160 区间。这条我没实测过无 NVLink 环境，是按带宽比例估的，仅供参考。
3. 视觉任务显存更紧：视觉塔 bf16 常驻，多图场景 3080 会先顶不住。

双 3090 NVLink 王者配置再度进化：SGLang dev507 + DFLASH2 全面复测

接上一篇 133 t/s 的实测帖，这周做了两件大事：引擎升级 506 个 commits + 跑完整优化矩阵。结论先行：王者配置没变，但藏着一个被内存挤掉的关键优化，挖出来后并发冲到 249 t/s 新高峰。

一、升级了什么

项目	旧	新
SGLang	8/26 快照	dev507（9/4 最新，506 commits）
关键修复	-	f60bc73c DFLASH TP 状态分歧修复
Kernel	7.0.0-30	7.0.0-31.31（swap_cgroup 崩溃修复版）
FlashInfer	0.6.17	0.6.18

其中 DFLASH TP 修复很重要：多轮长对话时 draft 模型状态会在 TP rank 间漂移，输出有潜在漂移风险，这版根除了。

二、挖出的隐藏瓶颈

升级后翻启动日志，发现一行：

Disable DFLASH draft cuda graph because only 0.93 GB GPU memory is available

draft 模型的 CUDA graph 一直被内存挤掉！mem-fraction 0.94 留给 draft graph 的空间只剩 0.93GB，不够。降到 0.90 后：

• draft cuda graph 启用
• selector decode（greedy + sampling）也折进 graph

三、优化矩阵实测（6 项，单变量）

测试	结果	判定
mem-fraction 0.94→0.90	draft graph 启用	采纳
dflash-block-size 16	并发 -28%	否决
dflash-block-size 4	JSON 场景 -18%	否决
tokenizer-worker-num 4	无增益	否决
fastokens（Rust tokenizer）	需 Rust toolchain	不适用
speculative-adaptive	仅支持 EAGLE	不适用

踩坑：DFLASH 强制 draft-tokens == block-size，不匹配直接 ValueError。

四、最终数据（2x3090 NVLink TP2 + AWQ INT4 + DFLASH2）

指标	数据
并发 aggregate（2 路）	219.1 avg / 249.1 峰
JSON 工具调用并发	280.5 avg（峰 303.7）
短 prompt 单路	297.3
代码生成	254.0
中文散文	85.4

vs 旧帖 133 t/s：+65% ~ +87%。

口径声明：并发 = 2 路 aggregate（双路同时生成的总吞吐）；单路端到端（含 prefill）一直 82-88 t/s。数字都是实测，无估算。

五、配置

--mem-fraction-static 0.90
--speculative-num-draft-tokens 8
--speculative-dflash-block-size 8
--tp-size 2 --kv-cache-dtype fp8_e5m2
--chunked-prefill-size 2048 --max-running-requests 2

完整报告和踩坑记录见回复区，欢迎交流。