<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Dgx-Spark on Code is cheap, let&#39;s talk</title>
    <link>https://blog.ferstar.org/en/tags/dgx-spark/</link>
    <description>Code is cheap, let&#39;s talk</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <copyright>© 2026 ferstar · [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/deed.en)</copyright>
    <lastBuildDate>Sun, 27 Sep 2026 08:25:00 +0800</lastBuildDate>
    <ttl>60</ttl><atom:link href="https://blog.ferstar.org/en/tags/dgx-spark/index.xml" rel="self" type="application/rss+xml" /><image>
      <url>https://blog.ferstar.org/site-logo.png</url>
      <title>Code is cheap, let&#39;s talk</title>
      <link>https://blog.ferstar.org/</link>
    </image>
    
    <item>
      <title>Dual DGX Sparks for Agent Workloads: Great Benchmarks, Crawling Reality</title>
      <link>https://blog.ferstar.org/en/posts/dgx-spark-agent-inference/</link>
      <pubDate>Sun, 27 Sep 2026 08:25:00 +0800</pubDate>
      
      <guid isPermaLink="true">https://blog.ferstar.org/en/posts/dgx-spark-agent-inference/</guid>
      <description>Benchmarking MiMo-V2.6-Flash on two DGX Sparks hits 173 tok/s aggregate with 6 concurrent short prompts. But throw 5 sub-agents at a real codebase, and single-stream speed plummets to 15–25 tok/s, taking over 6 minutes without completing a single task.</description><content:encoded><![CDATA[<blockquote><p>I am not a native English speaker; this article was translated by AI.</p>
</blockquote><p>Social media and YouTube are flooded with dual DGX Spark (GB10) benchmark videos, each title more hyped than the last: “170+ Tokens/sec!” and “Datacenter AI on Your Desk.”</p>
<p>A few days ago, I wired up two DGX Sparks directly using QSFP copper DAC cables, grabbed the community recipe, and spun up <code>MiMo-V2.6-Flash</code> with Tensor Parallelism (TP=2). But I didn’t set this up to benchmark <code>Hello World</code>. I only had one practical question: <strong>Can this thing actually plug into my daily coding agent as the primary model?</strong></p>
<p>The short answer: <strong>It’s totally fine for single-user turn-by-turn chat. But if you expect to run concurrent sub-agents or scan large codebases, forget it.</strong></p>
<hr>

<h2 class="relative group">Don’t Be Fooled by “200G” Ports and Synthetic Benchmarks
    <div id="dont-be-fooled-by-200g-ports-and-synthetic-benchmarks" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#dont-be-fooled-by-200g-ports-and-synthetic-benchmarks" aria-label="Anchor">#</a>
    </span>
    
</h2>
<p>When people see two 200G ports on each machine, their immediate assumption is often: “Dual-rail 400G aggregated inter-node bandwidth!”</p>
<p>Run <code>ethtool</code> and <code>lspci</code> once and the illusion falls apart:</p>
<ol>
<li>
<p><strong>The physical inter-node bandwidth ceiling is ~200 Gb/s</strong>: The two machines connect directly via dual QSFP DAC cables—no switch, and no inter-node NVLink. While <code>ethtool</code> reports <code>200000Mb/s</code> on both ports, the ConnectX-7 behind each port is only wired to PCIe Gen5 x4 (<code>32GT/s, Width x4</code>). The unidirectional theoretical max is only about 126 Gb/s:</p>
<p><code>32 × 4 × (128/130) ÷ 8 ≈ 15.8 GB/s ≈ 126 Gb/s</code></p>
<p>With <code>ib_write_bw</code>, a single cable saturates at ~99.7 Gb/s, and dual rails run at 97.9 + 97.9 ≈ 196 Gb/s aggregate.</p>
</li>
<li>
<p><strong>Memory bandwidth is the real bottleneck</strong>: DGX Spark uses unified memory with 128 GB LPDDR5X per node, delivering only <strong>273 GB/s</strong> of bandwidth.
Compare that against mainstream hardware:</p>
<ul>
<li>RTX 4090: <strong>1008 GB/s</strong> (24 GB VRAM)</li>
<li>Mac Studio M4 Max: <strong>410–546 GB/s</strong></li>
<li>Mac Studio M3 Ultra: <strong>819 GB/s</strong></li>
</ul>
</li>
</ol>
<p>DGX Spark’s selling point is <strong>“massive unified memory capacity”</strong>, not <strong>“high memory bandwidth”</strong>. A 200G link is plenty to shard an oversized model across two nodes via TP=2, but decode speed stays pinned by the 273 GB/s memory bandwidth anyway.</p>
<hr>

<h2 class="relative group">Synthetic Benchmarks Look Fantastic: Short Prompts
    <div id="synthetic-benchmarks-look-fantastic-short-prompts" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#synthetic-benchmarks-look-fantastic-short-prompts" aria-label="Anchor">#</a>
    </span>
    
</h2>
<p>Running typical benchmark scripts with fixed 128-token short prompts and <code>ignore_eos</code> enabled:</p>
<table>
  <thead>
      <tr>
          <th style="text-align: left">Concurrency</th>
          <th style="text-align: center">Aggregate Throughput (tok/s)</th>
          <th style="text-align: left">Latency & Per-Stream Decode</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td style="text-align: left"><strong>1</strong></td>
          <td style="text-align: center">37.1</td>
          <td style="text-align: left">Single-stream decode ~43.8 tok/s</td>
      </tr>
      <tr>
          <td style="text-align: left"><strong>2</strong></td>
          <td style="text-align: center">73.6</td>
          <td style="text-align: left">Linear scaling</td>
      </tr>
      <tr>
          <td style="text-align: left"><strong>4</strong></td>
          <td style="text-align: center">127.4</td>
          <td style="text-align: left">Decent multi-stream scaling</td>
      </tr>
      <tr>
          <td style="text-align: left"><strong>6</strong></td>
          <td style="text-align: center"><strong>172.7</strong></td>
          <td style="text-align: left">Peak aggregate throughput, batch finished in 4.5s</td>
      </tr>
      <tr>
          <td style="text-align: left"><strong>8</strong></td>
          <td style="text-align: center">79.8</td>
          <td style="text-align: left">Wall time 12.8s, per-stream decode scattered from 10 to 47 tok/s</td>
      </tr>
  </tbody>
</table>
<p>Six-way concurrency is the peak, 172.7 tok/s aggregate. At eight streams the aggregate falls to 79.8 and the per-stream rates scatter. I did not see a scheduler error. Idle single-stream decode touches about 54 tok/s. A normal back-and-forth chat, with prefix-cache hits around 90%, stays around 35–45 tok/s.</p>
<p>It’s why benchmarks written up online love shouting “170+ tokens/sec!"—they’re measuring a few hundred idle bytes, each stream decoding in its own little bubble.</p>
<hr>

<h2 class="relative group">Real Workloads: 5 Sub-Agents Scanning a Codebase Stall Out
    <div id="real-workloads-5-sub-agents-scanning-a-codebase-stall-out" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#real-workloads-5-sub-agents-scanning-a-codebase-stall-out" aria-label="Anchor">#</a>
    </span>
    
</h2>
<p>Next, I hooked the setup into my daily Coding Agent environment and spawned 5 sub-agents to concurrently explore a medium-sized open-source repo.</p>
<p>The backend looked perfectly healthy: HTTP 200 everywhere, queue depth zero.</p>
<p>Then reality hit: <strong>single-stream generation dropped to 15–25 tok/s. After 6 full minutes, not a single sub-agent summary had finished streaming.</strong></p>
<p>What that session actually recorded: HTTP 200, queue depth 0, 15–25 tok/s per stream, and no final answer after six minutes. A separate two-stream decode was about 65–75 tok/s aggregate, about 30–37 each. The 173 figure is a 128-token <code>ignore_eos</code> aggregate. It is not the same kind of input.</p>
<p>Long prefill is a different observation, not a log line from the five-stream run. Prefill of about 250K tokens can take minutes by itself and pulls generation speed down inside the same stats window. This run did not record each stream’s input length or its prefix-cache hit rate. The ~90% hit rate is from single-user chat with a repeated system prompt. Sub-agents reading different files should hit less of that cache. That is an inference, not a measurement from this run.</p>
<hr>

<h2 class="relative group">Other two-node logs sit in the same band
    <div id="other-two-node-logs-sit-in-the-same-band" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#other-two-node-logs-sit-in-the-same-band" aria-label="Anchor">#</a>
    </span>
    
</h2>
<p>Published GLM-5.3-Flash NVFP4 on two Sparks is about 20–30 tok/s on one stream, and about 36 on four. Raising the GPU clock from 1500 MHz to 2100 MHz adds about 4% decode. That clock result is the three-node post, not the four-node 35.7. The post titled 43.4 reports a median of 21.8 in the body. Figures in the sixties come from lower-bit EXL3, structured output, and a short context. DeepSeek V4.1 Flash full weights are served in four-node recipes. A two-node EXL3 folder exists and is marked not benchmarked. Links are at the end.</p>
<hr>

<h2 class="relative group">Epilogue: Switching to a Modded Card—Does the Math Add Up?
    <div id="epilogue-switching-to-a-modded-carddoes-the-math-add-up" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#epilogue-switching-to-a-modded-carddoes-the-math-add-up" aria-label="Anchor">#</a>
    </span>
    
</h2>
<p>Someone’s bound to ask: same budget, why not just buy a modded card? Don’t reach for the wallet yet—a bare card is only the opening line; the real bill comes after:</p>
<ul>
<li><strong>48G-modded RTX 4090</strong>: 1008 GB/s on one card, more than three times the Spark’s bandwidth. But a card is not a machine. Board, CPU, RAM, a kilowatt PSU, case and cooling all cost extra, and everyone knows what memory prices did in 2026. It also assumes you already own a desktop to plug it into—if you do, sure, that’s free performance.</li>
<li><strong>96G-modded RTX 5090</strong>: Suqiao’s Alibaba listing was $3,888 for the bare card. The same reports point out that the product page calls the memory GDDR6X at 14Gbps, which does not add up to 96GB, and no independent teardown covers the first batch. <a href="https://www.cnbeta.com.tw/articles/tech/1577618.htm"  target="_blank" rel="noreferrer">cnBeta</a>, <a href="https://www.tomshardware.com/pc-components/gpus/china-modified-nvidia-rtx-5090-with-massive-96gb-of-memory-appears-on-alibaba-for-less-than-usd4-000-3x-more-vram-at-65-percent-the-cost-of-the-original"  target="_blank" rel="noreferrer">Tom’s Hardware</a></li>
<li><strong>Two Sparks</strong>: no assembly. NVIDIA lists a 240W power supply and a 140W GB10 TDP, with the vendor warranty. The 128 GB is inside the system price.</li>
</ul>
<p>The bandwidth gap is on the spec sheets. I did not price a full host against two Sparks, so this section does not say which bill is smaller.</p>
<hr>

<h2 class="relative group">Takeaways: What Is This Setup Actually Good For?
    <div id="takeaways-what-is-this-setup-actually-good-for" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#takeaways-what-is-this-setup-actually-good-for" aria-label="Anchor">#</a>
    </span>
    
</h2>
<p>If you have a dual DGX Spark cluster:</p>
<ul>
<li><strong>Barely acceptable fit</strong>: Single-user, turn-by-turn pair programming. With a stable system prompt and high prefix cache hit rates, 35–45 tok/s is just about usable without depending on cloud APIs—provided your code and data are too sensitive to ever leave your machine; otherwise the performance penalty simply isn’t worth it.</li>
<li><strong>Natural fit</strong>: An expensive flex / desktop toy for tech influencers and sponsored reviewers. It looks sleek on a desk, screams “cutting-edge geek”, and recording short-prompt benchmarks produces delightfully inflated charts.</li>
<li><strong>Unrealistic fit</strong>: Acting as the backend for concurrent multi-agent swarms, repository-wide audits, or heavy long-context workloads. LPDDR5X memory bandwidth and long-context prefill latency will humble you instantly.</li>
</ul>
<p>Piling on more nodes only solves <strong>“can we fit the model in memory”</strong>; it does nothing to change the physical reality that <strong>“single-stream decoding stays slow”</strong>. Don’t fool yourself with short-prompt benchmarks: under real agent workloads, physical bottlenecks never lie.</p>

<h2 class="relative group">Sources
    <div id="sources" class="anchor"></div>
    
    <span
        class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none">
        <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#sources" aria-label="Anchor">#</a>
    </span>
    
</h2>
<p>Numbers from these two machines stay separate from numbers copied out of other people’s posts.</p>
<p><strong>Measured here in September 2026. No public log.</strong> MiMo used <a href="https://github.com/tonyd2wild/MiMo-V2.6-Flash-DGX-Spark-Recipe"  target="_blank" rel="noreferrer">tonyd2wild’s two-node recipe</a>, TP=2, model id <code>mimo-v2.6-flash</code>, <code>max_model_len</code> 300,000, <code>max_num_seqs</code> 8, served on port <code>:8888</code> of the head node. The short-prompt table is 128-token generations with <code>ignore_eos</code>, sent from my own machine. The five-sub-agent run is a real session on that same server: nothing queued, about 15–25 tok/s per stream, and no final answer after six minutes. <code>ethtool</code> reported <code>200000Mb/s</code>, Direct Attach Copper, on both live ports. <code>lspci</code> showed PCIe Gen5 x4 (<code>32GT/s, Width x4</code>) on both. The 126 Gb/s figure is <code>32 × 4 × (128/130) ÷ 8</code> from that link. <code>ib_write_bw</code> was about 99.7 Gb/s on one rail and about 97.9 + 97.9 with both rails active.</p>
<p><strong>Spec sheets, not measured token rates.</strong></p>
<ul>
<li>DGX Spark memory bandwidth 273 GB/s, 128 GB LPDDR5X, 240W power supply, 140W GB10 TDP: <a href="https://www.nvidia.com/en-us/support/dgx-spark.md"  target="_blank" rel="noreferrer">NVIDIA specifications</a></li>
<li>RTX 4090 memory bandwidth 1008 GB/s, 24 GB: <a href="https://www.nvidia.com/en-us/geforce/graphics-cards/40-series/rtx-4090/"  target="_blank" rel="noreferrer">NVIDIA GeForce</a>. A 48 GB mod is a capacity mod. The bandwidth number is still the stock card’s. There is no single spec sheet for the mod.</li>
<li>Mac Studio: M4 Max 410 GB/s, 546 GB/s on the 40-core GPU; M3 Ultra 819 GB/s. <a href="https://www.apple.com/mac-studio/specs/"  target="_blank" rel="noreferrer">Apple technical specifications</a></li>
</ul>
<p><strong>Community benches.</strong> The ~4% clock gain is the three-node post. The four-node 35.7 is a different post.</p>
<ul>
<li>Two nodes, NVFP4: body median 21.8 tok/s, peak 22.7. The title says 43.4. The same post’s four-node TP4 figure is 35.7. <a href="https://forums.developer.nvidia.com/t/glm-5-3-flash-on-2x-nvidia-dgx-spark-43-4-tok-s-peak-checkpoint/381429"  target="_blank" rel="noreferrer">NVIDIA forum</a></li>
<li>Another two-node run: 24.7 tok/s code, 30.3 structured, 19.6 prose, 14.6 with speculative decoding off. Single stream, temperature 0. <a href="https://forums.developer.nvidia.com/t/glm-5-3-flash-running-on-2x-dgx-spark-sm-121-day-0-24-7-30-3-tok-s-with-mtp-5-two-silent-gb10-gotchas-worth-knowing/381433"  target="_blank" rel="noreferrer">Forum</a>, <a href="https://github.com/kingjones30/GLM-5.3-Flash-2x-DGX-Spark"  target="_blank" rel="noreferrer">recipe</a></li>
<li>Three nodes, TP3: 35.2 tok/s at 1500 MHz, 36.8 at 2100 MHz. At about 160K tokens of context, 7.5 tok/s per stream at two-way and 6.1 at three-way. <a href="https://forums.developer.nvidia.com/t/glm-5-3-flash-nvfp4-on-3x-dgx-spark-tp-3-512k-context-35-tok-s/381534"  target="_blank" rel="noreferrer">NVIDIA forum</a></li>
<li>Two nodes, EXL3 4bpw: 62.9 tok/s structured, prose median 26.9. <a href="https://github.com/MiaAI-Lab/GLM-5.3-Flash-EXL3-2x-DGX-Sparks/blob/main/README.md"  target="_blank" rel="noreferrer">MiaAI</a></li>
<li>One node, EXL3 2.05bpw: about 64 structured, about 25 prose. Replies mention looping and quality. <a href="https://forums.developer.nvidia.com/t/60-tok-s-glm-5-3-flash-on-a-single-dgx-spark/382140"  target="_blank" rel="noreferrer">Forum</a>, <a href="https://huggingface.co/gitcommit90/GLM-5.3-Flash-EXL3-2.05-One-Spark"  target="_blank" rel="noreferrer">model card</a></li>
<li>DeepSeek V4.1 Flash on a four-node ring: about 43–50 tok/s one stream. <a href="https://github.com/yunwei37/dgx-spark-4-ring-no-switch/blob/main/docs/deepseek-v41-flash.md"  target="_blank" rel="noreferrer">Log</a>. Another four-node post reports 23 tok/s prose. <a href="https://forums.developer.nvidia.com/t/deepseek-v4-1-flash-552b-moe-on-4x-dgx-spark-tp4-77-2-tok-s-c1-on-peak-52-code-72-tok-s-on-a-warm-code-run-47-math-39-reasoning-23-prose/382897"  target="_blank" rel="noreferrer">Forum</a>. Two-node EXL3 is marked not benchmarked; four-node EXL3 prose is 30.2 and code is 33.4. <a href="https://github.com/vcruz305/DeepSeek-V4.1-Flash-EXL3-DGX-Spark-recipe"  target="_blank" rel="noreferrer">Recipe</a></li>
</ul>
]]></content:encoded>
      
    </item>
    
  </channel>
</rss>
