双DGX部署D4flash好还是Qwen3.8flash好？

[hao dee]

目前在跑D4flash平时拿来做点协议注册薅羊毛，有双机部署的佬给点意见交流下吗

[kop wang]

这个也是我目前好奇的，据之前坛友的测试，qwen3.8-flash的prefill和decode性能更慢。
我非常的不理解，规模和激活参数均砍半，但性能还更差。

等待其他有双机的坛友测试。

[David Chen]

妳都有雙DGX....建議妳裝上後，叫他自己跑分看看
AI自己跑，很快的

[Xiaote]

双机部署先说个前提：两台 DGX 之间没 NVLink，只能按工作负载分片——各跑各的实例加负载均衡，不能把一个大模型 TP 拆到两台机器上，跨机通信是网络级，TP 会直接疯掉。所以真正的选择题是「单台 DGX 里跑哪个模型」。

回 kop wang 的疑惑——为什么规模、激活参数都砍半，prefill/decode 反而更慢：

1. 每 token 要读的字节并没真砍半。MoE 的「激活参数」只是 router 选中的那部分 expert，但 attention + 共享层（shared dense/cls 层）每一 token 都得全读。flash 变体通常只砍 expert 侧，共享层基本没动，实际省下的带宽远小于「激活砍半」这个表面数字。
2. 小模型跨 die 的通信占比反而更重。DGX 内是两颗 die 靠 C2C 连成统一内存，一旦 TP 拆开，每 token 的 allreduce/同步开销近似固定，真正干活的浮点数却在变少 → comm-to-compute 比值恶化，小模型比大模型更难喂满。这也是「模型越小 TP 下越不划算」的通用规律。

给 hao dee 的实操建议——薅羊毛这种「高并发 + 工具调用」场景，别追单模 raw 分，追能稳定跑完任务循环的模型：

• 拿你的协议注册 prompt 固定喂 N 次，量「单轮任务总耗时 = 轮次 × t/s × 工具调用成功率」，比单看 tokens/s 有用。t/s 高但 tool 调用老出错要重试的任务，总时间反而更长。
• 你有双机，干脆 A/B：一台跑 D4flash、一台跑 Qwen3.8-flash，各自跑同一批任务，比完留下能稳定薅到羊毛的那台，别只信榜单。

[张光璞]

现阶段双DGX 最适配的还是deepseek v4 flash , 速度也快，抗压也强。 长上下文掉速也不是很离谱

[densha]

這是我家 hermes(gemini3.7-flash) 給的回覆

雙機 GX10 / DGX Spark 實測玩家路過，給幾點真實硬體數據和建議供參考：

1. 關於雙機 TP 部署：
   兩台機器走 QSFP 200G 直連（啟用 RoCEv2 / NCCL），完全可以穩跑 跨機 TP=2 分片，延遲極低。目前社群主流的 Mia、Reederey 雙機 Recipe（Qwen3.8 / D4flash / GLM5.3）全都是基於 200G 直連跑 TP 運作的，不存在「跨機只能各跑各的」這回事。

2. D4flash vs Qwen3.8 實測性能對比（雙機 200G 直連實測）：
   • Qwen3.8-Flash-Next (NVFP4 + MTP3)：
     • Prefill 速度：~2,900 - 3,100 tok/s
     • Decode 速度：130 - 150 tok/s
     • 特性：吞吐極高、首字秒回，超適合高並發、協議註冊、爬蟲與大量短任務。
   • DeepSeek-V4-Flash (官方 FP8 + DSpark)：
     • Decode 速度：~35 - 38 tok/s
     • 特性：嚴謹度高、寫複雜代碼與深層逆向邏輯強，但速度無法跟 Qwen3.8 比。

3. 針對樓主「協議註冊 / 薅羊毛 / Tool Call」建議：
   • 果斷上 Qwen3.8-Flash-Next。規模砍半速度慢通常是因為沒用對算子（要跑 NVFP4 + MTP/DFlash 投機）。這類任務拼的是單輪吞吐與 Prefill 延遲，Qwen3.8 效率高出 D4flash 接近 3~4 倍。

[soop ladios]

我目前手上兩個都有跑, qwen 3.8 flash next跑出數字如下:

用的是這份recipe:
https://github.com/tonyd2wild/Qwen3.8-Flash-Next-NVFP4-DGX-Spark
用他的SPEED mode, 不過把KV換成BF16, 修復prefill cache, 摘要如下:

模型與執行配置

項目	實際設定
Hugging Face model	nvidia/Qwen3.8-Flash-Next-NVFP4
Context length	262144 tokens
Max sequences	5
Tensor parallel	TP=2
Pipeline parallel	PP=1
KV cache dtype	BF16 / bfloat16
KV pool size	1,074,081 tokens（本次重啟實測）
262144-token concurrency	4.10x
KV memory	約 16.41 GiB（本次 rank 0 log）
GPU memory utilization	0.70
MTP	3 speculative tokens
Max batched tokens	4096
Prefix caching	Enabled；Mamba mode=align；實際 cache hit 已驗證
PLE	TonyD SPEED resident mode（PLE_MODE=none）
CUDA graphs	FULL_DECODE_ONLY，compile mode NONE
Container swap	禁止；兩端 memory.swap.current=0、OOM counters=0

驗收摘要

• Prefix cache：實際命中 1,600 tokens，TTFT 約 2.126s → 0.860s。
• Prefix correctness：cold/hit 的文字與完整 token sequence 相同；20-round growing conversation 為 20/20 文字與 tokens 相同，無 Mamba/CUDA error。
• 32K prefill：3,095.38 tok/s
• 128K prefill：3,002.73 tok/s
• 約 250K prefill：2,880.57 tok/s
• C1 coding：50.55 tok/s；C1 reasoning：48.81 tok/s
• C4 aggregate：coding 155.40 tok/s；reasoning 148.88 tok/s
• 目前允許最多 5 個 active sequences；既有 4×64K context + 每路 4096 forced decode 壓測已證明可維持 4 個 active sequences，尚未另跑 C5 長壓測。
• Coding、reasoning、OpenAI tool/function calling round-trip 與 1-image Vision smoke 均 PASS。

兩者相較之下, 經過不同任務長時間驗證, 我感覺qwen 3.8 flash next能力比較強一點. 不過我主要是做工程方面的, 或許其他方面不一樣也不一定.