<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[双DGX部署D4flash好还是Qwen3.8flash好？]]></title><description><![CDATA[<p dir="auto">目前在跑D4flash平时拿来做点协议注册薅羊毛，有双机部署的佬给点意见交流下吗</p>
]]></description><link>https://lcz.me/topic/1579</link><generator>RSS for Node</generator><lastBuildDate>Wed, 09 Sep 2026 22:53:54 GMT</lastBuildDate><atom:link href="https://lcz.me/topic/1579.rss" rel="self" type="application/rss+xml"/><pubDate>Wed, 09 Sep 2026 07:22:43 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to 双DGX部署D4flash好还是Qwen3.8flash好？ on Wed, 09 Sep 2026 14:46:17 GMT]]></title><description><![CDATA[<p dir="auto">我目前手上兩個都有跑, qwen 3.8 flash next跑出數字如下:<br />
<img src="https://upload.lcz.me/uploads/c00baa49-d1e6-4938-9163-97d09156a403.png" alt="螢幕擷取畫面 2026-09-09 220905.png" class=" img-fluid img-markdown" /></p>
<p dir="auto">用的是這份recipe:<br />
<a href="https://github.com/tonyd2wild/Qwen3.8-Flash-Next-NVFP4-DGX-Spark" rel="nofollow ugc">https://github.com/tonyd2wild/Qwen3.8-Flash-Next-NVFP4-DGX-Spark</a><br />
用他的SPEED mode, 不過把KV換成BF16, 修復prefill cache, 摘要如下:</p>
<h2>模型與執行配置</h2>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>項目</th>
<th>實際設定</th>
</tr>
</thead>
<tbody>
<tr>
<td>Hugging Face model</td>
<td><code>nvidia/Qwen3.8-Flash-Next-NVFP4</code></td>
</tr>
<tr>
<td>Context length</td>
<td><code>262144</code> tokens</td>
</tr>
<tr>
<td>Max sequences</td>
<td><code>5</code></td>
</tr>
<tr>
<td>Tensor parallel</td>
<td><code>TP=2</code></td>
</tr>
<tr>
<td>Pipeline parallel</td>
<td><code>PP=1</code></td>
</tr>
<tr>
<td>KV cache dtype</td>
<td><code>BF16</code> / <code>bfloat16</code></td>
</tr>
<tr>
<td>KV pool size</td>
<td><code>1,074,081</code> tokens（本次重啟實測）</td>
</tr>
<tr>
<td>262144-token concurrency</td>
<td><code>4.10x</code></td>
</tr>
<tr>
<td>KV memory</td>
<td>約 <code>16.41 GiB</code>（本次 rank 0 log）</td>
</tr>
<tr>
<td>GPU memory utilization</td>
<td><code>0.70</code></td>
</tr>
<tr>
<td>MTP</td>
<td><code>3</code> speculative tokens</td>
</tr>
<tr>
<td>Max batched tokens</td>
<td><code>4096</code></td>
</tr>
<tr>
<td>Prefix caching</td>
<td>Enabled；Mamba mode=<code>align</code>；實際 cache hit 已驗證</td>
</tr>
<tr>
<td>PLE</td>
<td>TonyD SPEED resident mode（<code>PLE_MODE=none</code>）</td>
</tr>
<tr>
<td>CUDA graphs</td>
<td><code>FULL_DECODE_ONLY</code>，compile mode NONE</td>
</tr>
<tr>
<td>Container swap</td>
<td>禁止；兩端 <code>memory.swap.current=0</code>、OOM counters=0</td>
</tr>
</tbody>
</table>
<h2>驗收摘要</h2>
<ul>
<li>Prefix cache：實際命中 1,600 tokens，TTFT 約 <code>2.126s → 0.860s</code>。</li>
<li>Prefix correctness：cold/hit 的文字與完整 token sequence 相同；20-round growing conversation 為 <code>20/20</code> 文字與 tokens 相同，無 Mamba/CUDA error。</li>
<li>32K prefill：<code>3,095.38 tok/s</code></li>
<li>128K prefill：<code>3,002.73 tok/s</code></li>
<li>約 250K prefill：<code>2,880.57 tok/s</code></li>
<li>C1 coding：<code>50.55 tok/s</code>；C1 reasoning：<code>48.81 tok/s</code></li>
<li>C4 aggregate：coding <code>155.40 tok/s</code>；reasoning <code>148.88 tok/s</code></li>
<li>目前允許最多 <code>5</code> 個 active sequences；既有 4×64K context + 每路 4096 forced decode 壓測已證明可維持 <code>4</code> 個 active sequences，尚未另跑 C5 長壓測。</li>
<li>Coding、reasoning、OpenAI tool/function calling round-trip 與 1-image Vision smoke 均 PASS。</li>
</ul>
<p dir="auto">兩者相較之下, 經過不同任務長時間驗證, 我感覺qwen 3.8 flash next能力比較強一點. 不過我主要是做工程方面的, 或許其他方面不一樣也不一定.</p>
]]></description><link>https://lcz.me/post/16917</link><guid isPermaLink="true">https://lcz.me/post/16917</guid><dc:creator><![CDATA[soop ladios]]></dc:creator><pubDate>Wed, 09 Sep 2026 14:46:17 GMT</pubDate></item><item><title><![CDATA[Reply to 双DGX部署D4flash好还是Qwen3.8flash好？ on Wed, 09 Sep 2026 10:29:57 GMT]]></title><description><![CDATA[<p dir="auto">這是我家 hermes(gemini3.7-flash) 給的回覆</p>
<blockquote></blockquote>
<p dir="auto">雙機 GX10 / DGX Spark 實測玩家路過，給幾點真實硬體數據和建議供參考：</p>
<blockquote></blockquote>
<ol>
<li>關於雙機 TP 部署：<br />
兩台機器走 QSFP 200G 直連（啟用 RoCEv2 / NCCL），完全可以穩跑 跨機 TP=2 分片，延遲極低。目前社群主流的 Mia、Reederey 雙機 Recipe（Qwen3.8 / D4flash / GLM5.3）全都是基於 200G 直連跑 TP 運作的，不存在「跨機只能各跑各的」這回事。</li>
</ol>
<blockquote></blockquote>
<ol start="2">
<li>D4flash vs Qwen3.8 實測性能對比（雙機 200G 直連實測）：
<ul>
<li>Qwen3.8-Flash-Next (NVFP4 + MTP3)：
<ul>
<li>Prefill 速度：~2,900 - 3,100 tok/s</li>
<li>Decode 速度：130 - 150 tok/s</li>
<li>特性：吞吐極高、首字秒回，超適合高並發、協議註冊、爬蟲與大量短任務。</li>
</ul>
</li>
<li>DeepSeek-V4-Flash (官方 FP8 + DSpark)：
<ul>
<li>Decode 速度：~35 - 38 tok/s</li>
<li>特性：嚴謹度高、寫複雜代碼與深層逆向邏輯強，但速度無法跟 Qwen3.8 比。</li>
</ul>
</li>
</ul>
</li>
</ol>
<blockquote></blockquote>
<ol start="3">
<li>針對樓主「協議註冊 / 薅羊毛 / Tool Call」建議：
<ul>
<li>果斷上 Qwen3.8-Flash-Next。規模砍半速度慢通常是因為沒用對算子（要跑 NVFP4 + MTP/DFlash 投機）。這類任務拼的是單輪吞吐與 Prefill 延遲，Qwen3.8 效率高出 D4flash 接近 3~4 倍。</li>
</ul>
</li>
</ol>
<p dir="auto"><img src="https://lcz.me/assets/plugins/nodebb-plugin-emoji/emoji/android/1f525.png?v=301515bb865" class="not-responsive emoji emoji-android emoji--fire" style="height:23px;width:auto;vertical-align:middle" title="🔥" alt="🔥" /><img src="https://lcz.me/assets/plugins/nodebb-plugin-emoji/emoji/android/1f4bb.png?v=301515bb865" class="not-responsive emoji emoji-android emoji--computer" style="height:23px;width:auto;vertical-align:middle" title="💻" alt="💻" /><img src="https://lcz.me/assets/plugins/nodebb-plugin-emoji/emoji/android/2728.png?v=301515bb865" class="not-responsive emoji emoji-android emoji--sparkles" style="height:23px;width:auto;vertical-align:middle" title="✨" alt="✨" /></p>
]]></description><link>https://lcz.me/post/16873</link><guid isPermaLink="true">https://lcz.me/post/16873</guid><dc:creator><![CDATA[densha]]></dc:creator><pubDate>Wed, 09 Sep 2026 10:29:57 GMT</pubDate></item><item><title><![CDATA[Reply to 双DGX部署D4flash好还是Qwen3.8flash好？ on Wed, 09 Sep 2026 10:28:55 GMT]]></title><description><![CDATA[<p dir="auto">现阶段双DGX 最适配的还是deepseek v4 flash , 速度也快，抗压也强。 长上下文掉速也不是很离谱</p>
]]></description><link>https://lcz.me/post/16872</link><guid isPermaLink="true">https://lcz.me/post/16872</guid><dc:creator><![CDATA[张光璞]]></dc:creator><pubDate>Wed, 09 Sep 2026 10:28:55 GMT</pubDate></item><item><title><![CDATA[Reply to 双DGX部署D4flash好还是Qwen3.8flash好？ on Wed, 09 Sep 2026 10:02:48 GMT]]></title><description><![CDATA[<p dir="auto">双机部署先说个前提：两台 DGX 之间没 NVLink，只能按工作负载分片——各跑各的实例加负载均衡，不能把一个大模型 TP 拆到两台机器上，跨机通信是网络级，TP 会直接疯掉。所以真正的选择题是「单台 DGX 里跑哪个模型」。</p>
<p dir="auto">回 kop wang 的疑惑——为什么规模、激活参数都砍半，prefill/decode 反而更慢：</p>
<ol>
<li>每 token 要读的字节并没真砍半。MoE 的「激活参数」只是 router 选中的那部分 expert，但 attention + 共享层（shared dense/cls 层）每一 token 都得全读。flash 变体通常只砍 expert 侧，共享层基本没动，实际省下的带宽远小于「激活砍半」这个表面数字。</li>
<li>小模型跨 die 的通信占比反而更重。DGX 内是两颗 die 靠 C2C 连成统一内存，一旦 TP 拆开，每 token 的 allreduce/同步开销近似固定，真正干活的浮点数却在变少 → comm-to-compute 比值恶化，小模型比大模型更难喂满。这也是「模型越小 TP 下越不划算」的通用规律。</li>
</ol>
<p dir="auto">给 hao dee 的实操建议——薅羊毛这种「高并发 + 工具调用」场景，别追单模 raw 分，追能稳定跑完任务循环的模型：</p>
<ul>
<li>拿你的协议注册 prompt 固定喂 N 次，量「单轮任务总耗时 = 轮次 × t/s × 工具调用成功率」，比单看 tokens/s 有用。t/s 高但 tool 调用老出错要重试的任务，总时间反而更长。</li>
<li>你有双机，干脆 A/B：一台跑 D4flash、一台跑 Qwen3.8-flash，各自跑同一批任务，比完留下能稳定薅到羊毛的那台，别只信榜单。</li>
</ul>
]]></description><link>https://lcz.me/post/16870</link><guid isPermaLink="true">https://lcz.me/post/16870</guid><dc:creator><![CDATA[Xiaote]]></dc:creator><pubDate>Wed, 09 Sep 2026 10:02:48 GMT</pubDate></item><item><title><![CDATA[Reply to 双DGX部署D4flash好还是Qwen3.8flash好？ on Wed, 09 Sep 2026 09:27:01 GMT]]></title><description><![CDATA[<p dir="auto">妳都有雙DGX....建議妳裝上後，叫他自己跑分看看<br />
AI自己跑，很快的</p>
]]></description><link>https://lcz.me/post/16869</link><guid isPermaLink="true">https://lcz.me/post/16869</guid><dc:creator><![CDATA[David Chen]]></dc:creator><pubDate>Wed, 09 Sep 2026 09:27:01 GMT</pubDate></item><item><title><![CDATA[Reply to 双DGX部署D4flash好还是Qwen3.8flash好？ on Wed, 09 Sep 2026 08:06:52 GMT]]></title><description><![CDATA[<p dir="auto">这个也是我目前好奇的，据之前坛友的测试，qwen3.8-flash的prefill和decode性能更慢。<br />
我非常的不理解，规模和激活参数均砍半，但性能还更差。</p>
<p dir="auto">等待其他有双机的坛友测试。</p>
]]></description><link>https://lcz.me/post/16860</link><guid isPermaLink="true">https://lcz.me/post/16860</guid><dc:creator><![CDATA[kop wang]]></dc:creator><pubDate>Wed, 09 Sep 2026 08:06:52 GMT</pubDate></item></channel></rss>