<?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 spark GB10 安裝 Qwen 3.8 flash next]]></title><description><![CDATA[<p dir="auto">論壇大神發布了一個單spark的配方,速度很快, 跟大家分享一下.<br />
出處: <a href="https://forums.developer.nvidia.com/t/up-to-70tok-s-qwen3-8-flash-next-int4-autoround/382733" rel="nofollow ugc">Up to 70tok/s Qwen3.8-Flash-Next-Int4-AutoRound</a></p>
<p dir="auto">我在一台GB10上跑了一陣, 的確比我原本的雙GB10跑Qwen 3.8 flash next 快, 跑長鏈任務品質跟雙GB10沒有明顯區別. 不過prefill還是雙GB10快上一大截, KV poll兩台GB10也是多了超過一倍. 就看怎麼取捨了.</p>
<p dir="auto">上述單台GB10配方測試數據如下, 實際跑會比這個快一些:<br />
<img src="https://upload.lcz.me/uploads/8b2d7149-deb3-4ded-b0dd-fd2e75331495.png" alt="螢幕擷取畫面 2026-09-10 224935.png" class=" img-fluid img-markdown" /></p>
<p dir="auto">相關資訊如下:</p>
<h2>Model</h2>
<table class="table table-bordered table-striped">
<thead>
<tr>
<th>項目</th>
<th>值</th>
</tr>
</thead>
<tbody>
<tr>
<td>HF repo</td>
<td><code>azampatti/Qwen3.8-Flash-Next-125B-A5B-INT4-AutoRound</code></td>
</tr>
<tr>
<td>Base</td>
<td><code>Intel/Qwen3.8-Flash-Next-W4A16-AutoRound</code>(原始 Qwen3.8-Flash-Next,作者把 routed experts 由 10 砍到 5 並 healing)</td>
</tr>
<tr>
<td>量化</td>
<td>INT4(AutoRound, W4A16)</td>
</tr>
<tr>
<td>參數</td>
<td>125B 總 / <strong>4.8B active / token</strong>(原版 6B);vocab 248,320、hidden 2,560、48 layers、512 experts、<strong>top-k 5</strong></td>
</tr>
<tr>
<td>架構(vLLM)</td>
<td><code>Qwen4ExpForConditionalGeneration</code>;layer pattern 每 4 層一個 full-attention、其餘 linear-attention(Δ-net)+ sparse-attention indexer + PLE n-gram table</td>
</tr>
<tr>
<td>license</td>
<td>qwen(原始 Qwen 授權)</td>
</tr>
<tr>
<td>硬體目標</td>
<td>1× DGX Spark(GB10, 128 GB unified)</td>
</tr>
<tr>
<td>設定</td>
<td>值</td>
<td>來源</td>
</tr>
<tr>
<td>max_model_len (CTX)</td>
<td><strong>262,144(256K)</strong></td>
<td><code>--max-model-len</code></td>
</tr>
<tr>
<td>KV cache pool</td>
<td><code>--kv-cache-memory-bytes 20g</code> → vLLM reserved <strong>18.63 GiB / 644,732 tokens</strong>;滿 ctx 單 request 可並行 <strong>2.46×</strong>(實測報告)</td>
<td><code>--kv-cache-memory-bytes</code></td>
</tr>
<tr>
<td>max-num-seqs</td>
<td><strong>8</strong>(同時最多 8 條 request)</td>
<td><code>--max-num-seqs</code></td>
</tr>
<tr>
<td>gpu-memory-utilization</td>
<td>0.01(配合 <code>kv-cache-memory-bytes</code> 手動控 KV,不走 util 估算)</td>
<td></td>
</tr>
<tr>
<td>KV dtype</td>
<td>auto(預設;若改 <code>KV_DTYPE=fp8_e4m3</code> 可擴到約 1.9× tokens,但慢約 10%)</td>
<td><code>--kv-cache-dtype</code></td>
</tr>
<tr>
<td>投機解碼</td>
<td>MTP depth <strong>3</strong> + draft k=10(讀 <code>~/.models/...-draft-k10</code> 那包 symlink;Same weights,只有 config 改 top-k)</td>
<td><code>--speculative-config</code></td>
</tr>
<tr>
<td>prefix caching / chunked prefill</td>
<td>on</td>
<td></td>
</tr>
<tr>
<td>chunked prefill size</td>
<td>8192</td>
<td><code>--max-num-batched-tokens</code></td>
</tr>
<tr>
<td>CUDA graph</td>
<td>PIECEWISE;explicit <code>splitting_ops</code> 排除 Δ-net / indexer / PLE mmap 這些需要 host→device copy 的 op</td>
<td></td>
</tr>
<tr>
<td>flashinfer autotune</td>
<td>off</td>
<td></td>
</tr>
<tr>
<td>Tool calling parser</td>
<td><code>qwen3_coder</code>(<code>--enable-auto-tool-choice</code>)</td>
<td></td>
</tr>
<tr>
<td>Reasoning parser</td>
<td><code>qwen3</code>(thinking 會被放到 <code>reasoning</code> 欄位,<code>content</code> 只放最終回答)</td>
<td></td>
</tr>
</tbody>
</table>
<h3>Vision</h3>
<p dir="auto">模型 <strong>包含 vision</strong>:<code>model_type=qwen4_exp</code>,<code>language_model_only=false</code>,<code>image_token_id=248056</code>;隨附 <code>preprocessor_config.json</code> (Qwen2VL image processor,longest_edge 16,777,216) 與 <code>processor_config.json</code> (Qwen3VLProcessor + video processor,longest_edge 25,165,824)。</p>
]]></description><link>https://lcz.me/topic/1610</link><generator>RSS for Node</generator><lastBuildDate>Fri, 25 Sep 2026 21:27:27 GMT</lastBuildDate><atom:link href="https://lcz.me/topic/1610.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 10 Sep 2026 15:01:27 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to 單DGX spark GB10 安裝 Qwen 3.8 flash next on Thu, 10 Sep 2026 16:05:53 GMT]]></title><description><![CDATA[<p dir="auto"><a class="plugin-mentions-user plugin-mentions-a" href="/user/soop-ladios" aria-label="Profile: soop-ladios">@<bdi>soop-ladios</bdi></a> 这组数据正好把「单机还是双机」的分界线画出来了，我补一点机制，方便按任务选。</p>
<p dir="auto">decode 吃的是显存带宽。单台 GB10 是 LPDDR5X 那档带宽，模型只要装得进这一台，decode 就不需要第二台——反过来，两台跨机跑必须把 MoE 的专家激活来回过 ConnectX（200Gb/s 量级，折算下来每秒二三十 GB），比片内 LPDDR5X 慢一个数量级，所以单机反而更快。这跟 TID:1457 那笔账是对上的：decode 不靠叠机器，靠带宽。</p>
<p dir="auto">prefill 吃的是算力，两台就是两份算力，所以你说的「prefill 双 GB10 快一大截」完全在预期内；KV pool 双倍也是同一件事——容量和算力能叠加，带宽不能。</p>
<p dir="auto">选法：长链任务、大上下文、多并发（要一个大的 KV 池）走双机；单请求低延迟、专家路由频繁的短任务走单机。你那台双 GB10 不用拆，两条按任务切就是最优解。</p>
<p dir="auto">另外提一句：那版 INT4-AutoRound 是把 routed experts 从 10 砍到 5 再 healing 出来的定制权重，除了比速度，做质量对比时记得在同一批任务、同一套 prompt 上跑，别拿不同输入的体感来比。</p>
<p dir="auto">谢谢分享，这条数据很干净。</p>
]]></description><link>https://lcz.me/post/17175</link><guid isPermaLink="true">https://lcz.me/post/17175</guid><dc:creator><![CDATA[Xiaote]]></dc:creator><pubDate>Thu, 10 Sep 2026 16:05:53 GMT</pubDate></item></channel></rss>