Field notes from the bench.

The Agent Readiness Score (ARS) was always meant to be a living measurement. When we shipped v2026.4 in late September, sleep/resume reliability carried 8% of the composite. That was a defensible number when most Spark laptops were still on launch firmware and we had limited longitudinal data. Six weeks of fleet telemetry later, it is clearly too low.

Across 312 devices reporting opt-in telemetry, the single most common cause of an agent loop dying overnight was not a model crash, not a vLLM OOM, not even a thermal shutdown — it was the laptop failing to re-bind the Grace NPU after a lid-close/lid-open cycle. On four of the ten SKUs in our registry, we measured a non-trivial probability that an 8-hour sleep cycle would leave the agent runtime in a degraded state, requiring a manual `systemctl restart` of the inference daemon.

We are bumping sleep/resume from 8% to 14% of ARS, taking 4 points from raw throughput and 2 from cold-start latency. Both of those sub-scores were saturating at the top of the registry — the gap between the best and worst Spark on raw 70B throughput is now only about 35% — while the gap on resume reliability is closer to 4x.

Three devices moved by more than four points under the new weighting. The Razer Blade 16 Spark Edition lost 5 points (84 → 79) primarily because its current firmware drops the NPU context on hibernate. The Dell Precision S16 gained 2 points (88 → 90) because Dell shipped a firmware that survives a 72-hour suspend without re-binding. The HP Z-Spark Mini, which we always run headless, was unaffected because it never sleeps.

We are publishing the full re-scoring CSV alongside this note. If your fleet planning depends on a specific device staying above an ARS threshold, re-pull the registry before your next procurement cycle.

We caught this during our weekly regression sweep, not from a user report — which is itself a warning sign about how quickly silent firmware regressions can ship through OEM update channels.

Symptom: after applying Dell firmware 1.04.2 (released October 28), the Precision S16 drops from a sustained 22 tokens/sec on Llama-3.1-70B Q4_K_M to an erratic 9–12 tokens/sec under vLLM 0.6.2. Llama.cpp and Ollama are unaffected. The pattern strongly suggests a regression in the kernel-side memory pinning path that vLLM's PagedAttention relies on.

Reproduction: load Llama-3.1-70B Q4 with vLLM 0.6.2 (`--tensor-parallel-size 1 --gpu-memory-utilization 0.85`), warm with 50 prompts of ~512 input tokens, then measure decode throughput on a 30-prompt sweep. Pre-1.04.2 firmware: 22.1 tok/s ± 0.4. Post-1.04.2: 10.8 tok/s ± 1.9. The variance is as telling as the mean.

Workaround: roll back to 1.04.1 via Dell Command Update (`dcu-cli /downgrade /firmware=1.04.1 -force`). Disable the auto-update policy until 1.04.3 ships. If you cannot roll back (some enterprise images forbid it), pin vLLM to 0.5.6 — the older PagedAttention path does not appear to hit the affected kernel branch.

We have shared a reproducer with Dell's Precision firmware team and confirmed they have it bisected. Estimated 1.04.3 release is the week of November 17. We will update this note when it lands.

Broader lesson: Spark devices ship enough novel silicon (Grace + Blackwell + a unified memory controller) that OEM firmware is doing real work, not just splash-screen art. We are formalizing a 'firmware advisory' channel and an RSS feed for it; subscribe link below.

The Agent Stress Suite v1 includes a 72-hour soak we internally call 'the long Friday' — five concurrent agent loops (a planner, a coder, two RAG retrievers, and a long-running researcher), all backed by Llama-3.1-70B Q4 with a 16k effective context, hitting the device continuously from Friday 09:00 to Monday 09:00 local time.

Most Spark desktops we have tested either thermally throttle by hour 30 or hit a memory fragmentation cliff between hours 50 and 60 when vLLM's KV cache compaction collides with a long-running Aider session. The MSI Spark Titan is the first to clear the test without intervention.

Thermals: the Titan held its GPU junction at a mean of 78.3 °C with a p99 of 81.6 °C, against a throttle ceiling of 83 °C. That is 1.4 °C of headroom at the 99th percentile, which is not generous, but it never crossed the line. CPU package temperature was a much calmer 64 °C mean.

Power: peak wall draw 478 W (measured at a Kill-A-Watt P4400, which we acknowledge has ±2% accuracy). Sustained average over 72 hours: 312 W. For a workstation pushing roughly 25 tokens/sec of 70B reasoning continuously, that is excellent. Energy per million tokens worked out to 1.42 kWh, which we cover in detail in our TCO calculator.

Throughput stability: decode tokens/sec on the anchor 70B model held within ±3% of the warm-state mean across the entire run. No measurable degradation. Cold-start to first token after a planned 5-minute pause was a consistent 1.8 s, which is impressive for a model of this size.

Failure modes we did not hit but were watching for: KV cache fragmentation (none — vLLM 0.6.2's `--enable-prefix-caching` held up), tokenizer drift between agents (none — we pinned versions), and the infamous Grace memory controller ECC scrub stall that bit us on a different Spark device in August (none — MSI's BIOS exposes a tunable for this and we left it at default).

Conclusion: we are raising the ARS ceiling to 90, with MSI Spark Titan as the new reference point at exactly 90. The Titan's SCS remains the highest in the registry at 96. If you are buying a single-node Spark to anchor a small team's agent workload, this is currently the device to beat.

Caveats: this test runs on Ubuntu 24.04 with the NVIDIA Spark driver branch r580. Windows results will differ — we have a separate Windows soak running now and will publish those numbers when they conclude in mid-November.

This playbook covers the cheapest credible path to running Llama-3.1-70B Q4 with comfortable headroom for KV cache and a real chance at Mixtral 8x22B: two 64 GB Spark desktops, wired point-to-point over 10 GbE, with vLLM doing tensor-parallel inference across both.

Bill of materials: 2 × HP Z-Spark Mini (64 GB, $1,899 each), 2 × Intel X550-T2 10 GbE NIC ($229 each — the onboard 2.5 GbE is a non-starter for NCCL), 1 × 2 m Cat 6A cable ($14), 1 × cheap unmanaged switch only if you want SSH from a third machine on the same subnet ($65 — skip if you SSH from one of the nodes). Total hardware: $4,335.

Network: do not use a switch between the two nodes if you can avoid it. Point-to-point with static /30 IPs (we use 10.42.0.1 and 10.42.0.2 with /30) cuts latency by roughly 18 µs in our measurements and removes a class of switch-firmware bugs from the picture. Set MTU to 9000 on both ends. Verify with `iperf3 -c <peer> -P 4` — we want at least 9.4 Gbps with 4 parallel streams.

NCCL flags that actually matter on Spark: `NCCL_IB_DISABLE=1` (no InfiniBand on these boxes), `NCCL_P2P_LEVEL=NVL` (Grace's unified memory likes this), `NCCL_NET_GDR_LEVEL=PIX` (GPUDirect over the X550 works surprisingly well), and `NCCL_SOCKET_IFNAME=enp7s0` (replace with your actual NIC name; do not let NCCL guess). Without these, we measured a 31% throughput loss vs. our tuned config.

vLLM invocation: `vllm serve meta-llama/Llama-3.1-70B-Instruct --quantization gguf --tensor-parallel-size 2 --pipeline-parallel-size 1 --gpu-memory-utilization 0.88 --max-model-len 16384 --enable-prefix-caching --distributed-executor-backend ray`. We use Ray as the executor backend because vLLM's native multi-node path is still rough at the time of writing.

Ray bootstrap: on node 0, `ray start --head --node-ip-address=10.42.0.1 --port=6379`. On node 1, `ray start --address=10.42.0.1:6379 --node-ip-address=10.42.0.2`. Verify `ray status` shows 2 nodes and 2 GPUs before launching vLLM.

Systemd unit: we ship a hardened example in the GitHub repo (rtxsparks/cluster-playbooks). The key bits are `Restart=on-failure`, `RestartSec=30s`, and a `RuntimeMaxSec=86400` so the daemon restarts cleanly every 24 hours — this paper-bags over a slow memory leak we still haven't fully root-caused in vLLM 0.6.2's prefix cache.

Gotcha 1: clock skew. NCCL becomes unstable if the two nodes drift more than ~200 ms apart. Install chrony on both and point them at the same upstream pool. We watched two collectives hang for 90 seconds because node 1's RTC had drifted 3 seconds during a power blip.

Gotcha 2: huge pages. Spark's unified memory benefits enormously from 1 GB huge pages, but they are not on by default. Add `default_hugepagesz=1G hugepagesz=1G hugepages=24` to the kernel cmdline on both nodes and reserve them at boot. We measured a 7% decode throughput uplift on the 70B anchor after enabling.

Gotcha 3: the SSD trim cliff. Both Z-Spark Minis ship with the same 2 TB NVMe SKU, and we observed a 40-second stall on both nodes simultaneously about 14 hours into our first long run. Turned out to be background TRIM kicking in on a near-full filesystem during a KV cache spill. Workaround: keep the OS volume below 70% full, or move the swap/cache to a second drive. We are writing this up separately because it bit us twice before we figured it out.

Results, for impatient readers: 28 tok/s on Llama-3.1-70B Q4 (vs. 14 tok/s on a single 64 GB node), 14 tok/s on Mixtral 8x22B Q3 (which simply will not run on a single 64 GB node), and a real-world steady-state of 4 concurrent agents at acceptable latency.

On paper, Apple's Mac Studio M5 Ultra (192 GB unified memory option, 800 GB/s bandwidth) and the NVIDIA-spec'd Spark desktops (128 GB unified, 546–600 GB/s) look like comparable answers to the same question: how do you host a 70B-class model and a small fleet of agents on one workstation under your desk.

In practice, they are quite different machines with different strengths. We ran our Agent Stress Suite v1 on a Mac Studio M5 Ultra (192 GB, $5,799 as configured) and an MSI Spark Titan (128 GB, $3,899). Both are top-of-class for their respective ecosystems.

Raw 70B decode throughput, Llama-3.1-70B Q4: MSI Spark Titan 26 tok/s, Mac Studio M5 Ultra 22 tok/s. The Mac has more bandwidth but the Spark's Blackwell tensor cores win the FLOP-bound parts of decode. This is a smaller gap than we expected.

Prompt prefill (long context, 16k tokens): Mac Studio 1,940 tok/s, MSI Titan 2,610 tok/s. Spark wins comfortably here — prefill is FLOP-bound and the Blackwell silicon eats it.

Ecosystem: this is where it gets interesting. CUDA-targeted projects (vLLM, TensorRT-LLM, NCCL, anything Triton-flavored) run on Spark with one command. On Mac, you are picking between MLX (excellent, Apple-native), llama.cpp Metal (mature, slightly slower than MLX on prefill), and Ollama (which wraps both). vLLM does not run on Mac.

Agent stack maturity: OpenShell, Letta, AutoGen, LangGraph all have first-class CUDA paths and uneven Apple Silicon stories. If your agent stack relies on a CUDA kernel you did not write yourself, Spark is the lower-friction choice today. If your stack is HTTP-only (OpenAI-compatible endpoints + tool calls), the difference shrinks.

Multi-node: Spark wins by default. Two Spark desktops over 10 GbE with vLLM tensor-parallel works today. Mac Studios cluster awkwardly — Thunderbolt 5 is fast (80 Gbps) but the software story (MLX distributed, EXO) is younger and rougher.

Power: Mac Studio sustained 195 W, Spark Titan sustained 312 W under the same workload. Mac is meaningfully more efficient in joules per token (roughly 38% less). If your machine is on 24/7, this adds up.

Cost: Mac Studio 192 GB M5 Ultra $5,799, MSI Spark Titan 128 GB $3,899. The Mac has 50% more memory at 49% more cost. If you genuinely need >128 GB unified for a single model, the Mac is currently the only single-box option.

Our recommendation: choose Spark if your workload is CUDA-aligned, leans on vLLM or TensorRT-LLM, will eventually scale to multiple nodes, or includes heavy prompt prefill. Choose Mac Studio if you need >128 GB unified, run macOS-native creative tooling alongside your agents, or care more about joules per token than raw FLOPS.

Both are excellent. The 'one true local AI machine' framing in most YouTube content is unhelpful — these are tools with different shapes.

We have published the ARS weights before, but only ever as a summary table. Several readers have asked for the full methodology, including the parts we ourselves still debate. Here it is.

ARS is intentionally narrower than SCS (Spark Capability Score, which measures raw hardware) and TLS (Trust & Lifecycle Score, which measures vendor behavior). ARS asks one question: how reliably can this device run a real agent workload, today, with a real software stack, on its current firmware?

The nine sub-scores, with current weights:

1) Sustained 70B decode throughput (24%). Measured as tokens/sec on Llama-3.1-70B Q4_K_M after a 10-minute warm-up, averaged over a 30-minute window. We use Q4 because it is what 90% of our community telemetry shows people actually running. Q8 would advantage devices with more bandwidth; Q3 would advantage devices with more FLOPS. Q4 is the honest middle.

2) Multi-agent throughput (18%). Four concurrent agent loops, each with a small (7B) planner and a shared 70B reasoner. Measures end-to-end task completion rate, not raw token throughput. A device that single-streams fast but multiplexes badly will lose points here.

3) Sleep/resume reliability (14%, recently raised from 8%). 50 lid-close/lid-open cycles with the agent runtime running. Measures the probability of the NPU coming back without manual intervention. Headless devices get a synthetic full-credit score here, which we acknowledge is a methodological compromise.

4) Cold-start latency (12%). Time from `systemctl start` to first generated token on the anchor 70B model. Includes model load from disk. Penalizes devices with slow NVMe or fussy CUDA init paths.

5) Thermal stability under sustained load (10%). Measured as the standard deviation of GPU junction temperature during the 72-hour soak. Lower is better. We do not penalize for absolute temperature as long as the device does not throttle.

6) Driver/firmware update cadence (8%). Slow-moving sub-score; measured as the median time between OEM driver releases over the prior 90 days, with a penalty for >60 days.

7) Linux driver maturity (6%). Boolean-ish: does the upstream NVIDIA Spark driver branch work out of the box on Ubuntu 24.04 LTS and Fedora 41? Partial credit for one but not the other.

8) NCCL multi-node behavior (5%). Synthetic 2-node test against a reference HP Z-Spark Mini. Measures the throughput delta vs. theoretical with our standard NCCL flags. Headless devices benefit most here.

9) Tool-calling latency under load (3%). Measures the latency overhead of OpenAI-compatible tool calls vs. raw decode, under the multi-agent workload. A new sub-score added in v2026.4.

Things we argue about internally: should sleep/resume be 14% or 18%? (We compromised at 14% but expect it to keep rising.) Should we measure Q8 throughput separately for the 128 GB devices that can actually run it well? (Likely yes in v2026.5.) Should we punish closed Linux drivers more harshly? (Two of us yes, three no.)

Things readers argue about with us: why no Windows score? (Coming in v2026.5 — the Windows agent stack is finally mature enough to test repeatably.) Why no MLX comparison? (Out of scope — ARS is Spark-only by definition; cross-platform comparison happens in separate articles like the Mac Studio piece.) Why is OEM update cadence in ARS and not TLS? (Because slow updates affect today's agent reliability, not just long-term trust. Reasonable people disagree.)

Full v2026.4.1 weights, current snapshot CSVs, and the test harness are open-source under the rtxsparks/ars-methodology repo.

Qwen3-Coder-32B replaced our previous default coding model (Llama-3.1-70B-Instruct) at the top of our internal Aider + ripgrep harness as of last week. This is a real shift — the previous champion held that slot for nearly four months.

Benchmark setup: 142 real-world refactor tasks pulled from anonymized telemetry of our community users, scored by (a) test pass rate, (b) human review of diff quality, and (c) round-trip latency. Models compared: Qwen3-Coder-32B Q4_K_M, Llama-3.1-70B-Instruct Q4_K_M, DeepSeek-Coder-V3 Q4, and Claude 3.7 Sonnet via API as a cloud reference.

Headline result: Qwen3-Coder-32B passed 71% of tasks, vs. Llama-70B at 64%, DeepSeek-Coder-V3 at 67%, and Sonnet at 84%. The gap to Sonnet is real, but the gap to Llama-70B has now flipped in Qwen's favor — at half the parameter count.

Where Qwen wins decisively: small-to-medium refactors with explicit instructions, library-aware code generation (especially Python, TypeScript, Go, Rust), and anything requiring 32k of context (Qwen3-Coder ships with a strong 32k context window vs. Llama-3.1's nominal-but-shaky 32k).

Where Llama-70B still wins: tasks requiring genuine planning over many files (Qwen tends to commit too early), tasks with sparse instructions where the model has to infer intent, and any task involving non-code reasoning bolted onto code (Llama's general reasoning is still stronger).

Throughput on Spark: 34 tok/s on a 64 GB Spark, 41 tok/s on a 128 GB Spark with prefix caching. Cold start is fast (sub-3 s on NVMe) because the quantized weights are only ~17 GB.

Memory: comfortably fits with a 32k context on a 64 GB Spark with ~12 GB of headroom for a second 7B planner model. This is the configuration we now recommend by default for solo developers — Qwen3-Coder-32B as the worker, Qwen3-7B as the planner/router.

Quantization sensitivity: we tested Q3, Q4_K_M, Q5_K_M, and Q6. Q4_K_M is the right pick — Q3 loses ~9% on test pass rate, Q5 gains only ~1%. Q6 fits on 128 GB but the gain is in the noise.

Agent integration: works well with Aider out of the box. We had to disable `--cache-prompts` in Aider when running with vLLM's prefix caching enabled — they fought each other. With one or the other, both are fine.

Recommendation: if you are doing more than ~2 hours/week of coding work locally, switch your default to Qwen3-Coder-32B. Keep Llama-70B around for the planning-heavy tasks where it still wins.

When we designed the score triad (SCS, ARS, TLS), it would have been easy to skip TLS entirely. Capability and Readiness are 'real' technical scores; Trust & Lifecycle has a softer feel. We almost cut it.

We did not, because every honest conversation we have had with enterprise procurement leads pointed to the same thing: their hardest question is not 'will this device run my model fast enough today?' It is 'will I still be able to patch this device, source replacement parts, and trust the firmware supply chain in 36 months?'

TLS is a 0–100 composite of: (1) committed firmware/driver support window in months [25%], (2) signed-firmware posture and SBOM publication [20%], (3) right-to-repair score (parts availability, schematics, removable components) [15%], (4) security advisory cadence and CVE response time [15%], (5) end-of-life policy clarity [10%], (6) ecological/recyclability disclosures [8%], (7) regional repair network density [7%].

The score most OEMs hate is signed-firmware posture. NVIDIA's reference DGX Spark ships with a signed boot chain, SBOMs published per firmware release, and a clearly documented attestation path. Most OEMs are nowhere close — two of the ten devices in our registry do not publish SBOMs at all, and one ships firmware with only opt-in signature verification.

The score most procurement officers care most about is committed support window. The current registry-wide median is 36 months. The best is Lenovo ThinkPad P1 Spark Gen 1 at 60 months (which is why it leads TLS at 94). The worst is a 24-month commitment from a name we will not call out in this post but is visible in the registry data.

Right-to-repair is where Framework runs away with the category. The Framework Spark 13 has full schematics, every part on their store, and a modular mainboard. No other device in the registry comes close — most are glued.

Things TLS does not measure (and should not): subjective brand reputation, social media sentiment, founder behavior. We get asked about these regularly. They are out of scope and will stay out of scope.

Things TLS will start measuring in v2026.5: firmware update payload size and delivery channel security (some OEMs ship firmware over plain HTTP, which is 2026 and inexcusable), and clear telemetry opt-out paths.

TLS will not be the score that sells a device to a hobbyist. It is the score that should — and increasingly does — determine which devices land on enterprise procurement shortlists. That is the audience it is built for.

Timeline (all times PDT, August 12): 14:31:08 — eval harness begins a long-context (24k input tokens) sweep against the cluster. 14:33:42 — both nodes simultaneously report `nvme0n1` queue depth spike to 256. 14:33:44 — vLLM logs `WARNING: KV cache eviction taking >5s`. 14:33:51 — heartbeats stop on both nodes from the Ray dashboard. 14:34:24 — first node returns; second follows 1.2s later. 14:34:31 — eval harness times out and marks the sweep failed.

Total wall-clock impact: 40 seconds of unavailability, one failed eval, no data loss.

Root cause: both NVMes were the same SKU (Crucial T700 2TB), at 73% and 74% full respectively. vLLM 0.6.2's KV cache spill path uses a memory-mapped file on the OS volume. When the cache spilled, the writes triggered enough block invalidations to wake the kernel's deferred TRIM worker, which on a near-full drive does a long-running pass. Both drives were on the same firmware and hit the same code path within milliseconds of each other.

Why both at once: this is the part that took us longest. The two nodes were synchronized closely enough (Ray heartbeats, NCCL collectives) that the spill happened on both within ~5 ms, and both drives' background workers were idle and ready to fire. Correlated failure on correlated hardware running correlated software is a class of problem we should have anticipated.

Immediate fix: moved vLLM's spill volume to a second NVMe (a cheaper Crucial P3 1 TB), kept the OS volume below 60% full as a policy, and added a watchdog systemd timer that pre-emptively runs `fstrim` weekly during a known-idle window.

Longer-term fix: we are filing a patch upstream to vLLM to add a configurable threshold for spill-vs-evict behavior, so operators can avoid spill entirely on space-constrained nodes. PR link in the GitHub repo.

Broader lesson: correlated hardware behaves in correlated ways under correlated load. The exact same model NVMe in the exact same node config running the exact same firmware will hit the exact same edge case at the exact same time. For mission-critical clusters, consider mixing SSD vendors or at minimum mixing capacities to break the correlation. This is the kind of thing that is obvious in hindsight and embarrassing to write up.

We get asked 'what is the best Spark to buy?' more than any other question. It is also the question we are least willing to answer in one sentence, because the right answer depends entirely on what you are buying it for. Here are six personas, six recommendations, and the reasoning for each.

1) The solo developer who codes for a living and wants local agents in the loop. Recommendation: Framework Spark 13 ($2,199, 64 GB). Reasoning: repairable, excellent Linux drivers, 64 GB is the sweet spot for Qwen3-Coder-32B + a planner, and you will keep it for five years. Alternative: Lenovo ThinkPad P1 Spark Gen 1 ($2,599) if you want a 16-inch screen and the best TLS in the registry. Deal-breaker: do not buy a 32 GB Spark for this — you will outgrow it in six months.

2) The data scientist or researcher who needs to run 70B+ models comfortably and occasionally a frontier MoE. Recommendation: MSI Spark Titan desktop ($3,899, 128 GB). Reasoning: highest SCS in the registry, best sustained throughput, holds together under 72-hour loads. Alternative: GIGABYTE AI TOP Spark Tower ($3,699) if you want extra PCIe expansion. Deal-breaker: do not buy a Spark laptop for this — the workstation chassis matters.

3) The team lead building a small shared inference cluster. Recommendation: 2 × HP Z-Spark Mini Cluster Node ($1,899 each = $3,798). Reasoning: cheapest path to 128 GB-effective, designed for headless rack mounting, best $/ARS in the registry. Alternative: 4-node version of the same for $7,596 if you need >4 concurrent agents. Deal-breaker: do not try this with a switch between nodes; go point-to-point.

4) The mobile developer who needs Spark performance on the road. Recommendation: Dell Precision S16 ($3,499, 128 GB). Reasoning: only laptop in the registry with workstation cooling at 128 GB, sustains long sessions without throttling. Alternative: Razer Blade 16 Spark Edition ($3,299) if you also want the best display and can live with thermal throttling on long jobs. Deal-breaker: the ASUS ZenBook Spark and Acer Aspire Spark are too thermally constrained for sustained agent work — they are good chat-only machines.

5) The enterprise IT buyer outfitting a fleet of 50+ developers. Recommendation: Lenovo ThinkPad P1 Spark Gen 1 ($2,599, 64 GB). Reasoning: highest TLS in the registry (94), 60-month support commitment, signed firmware, well-documented driver branches, fits IT-managed imaging workflows. Alternative: Dell Precision S16 for users who specifically need 128 GB. Deal-breaker: avoid devices with <36-month support commitments for fleet deployments.

6) The hobbyist who wants to learn local AI without committing $3,000+. Recommendation: ASUS ZenBook 14 Spark ($1,599, 32 GB). Reasoning: cheapest Spark laptop that is actually pleasant to use, runs 13B–32B models well, opens the door to the ecosystem. Alternative: Acer Aspire Spark 15 ($1,399) if budget is the absolute constraint. Deal-breaker: do not expect to run 70B models locally on these — plan to add a headless mini-PC later for that workload.

What we did not recommend, and why: no NVIDIA DGX Spark Reference in this list, despite its excellent scores. It is a reference design with limited retail channels, and most readers will be better served by an OEM equivalent with normal warranty and support. If you have a direct NVIDIA developer relationship, ignore this caveat.

Prices accurate as of August 1, 2026. Q4 launches may shift the recommendations — we will refresh this guide on November 15.

We tested four agent frameworks against the Spark NPU offload paths: OpenShell 0.4, LangGraph 0.3, AutoGen 0.5, and CrewAI 0.8. Only OpenShell consistently lit up the NPU under our standard multi-agent workload.

Why this matters: the Grace NPU on Spark is not a marketing checkbox. Under the right workload, it handles roughly 18% of the FLOPs at meaningfully better power efficiency than the Blackwell GPU. Frameworks that route work appropriately gain real throughput and lose real heat.

Test workload: four-agent loop (planner + coder + retriever + critic) running Qwen3-7B (planner) and Llama-3.1-70B (everyone else), backed by vLLM 0.6.2, 90-minute warm steady-state measurement.

Throughput results (tasks completed per hour): OpenShell 0.4 — 47. LangGraph 0.3 — 38. AutoGen 0.5 — 36. CrewAI 0.8 — 33. OpenShell's lead is roughly 23% over the next best.

NPU utilization (nvidia-smi-spark sampled at 1 Hz): OpenShell — 41% mean, 78% peak. LangGraph — 4% mean, 11% peak. AutoGen — 0% (does not use the NPU API). CrewAI — 0% (same).

Why OpenShell wins: it ships with a driver-level shim (open-source under Apache 2.0) that routes the small planner model and the tool-call orchestration onto the NPU while keeping the 70B worker on the GPU. The other frameworks treat the Spark as a single CUDA device.

Caveats: OpenShell is younger software. We hit two bugs during testing (one cosmetic, one a real deadlock under high concurrency). The team fixed both within 72 hours. LangGraph is more mature, more documented, and has a larger ecosystem.

Recommendation: if you want maximum throughput on Spark today, run OpenShell. If you need the broader LangGraph ecosystem (the hundreds of community-contributed nodes), accept the throughput cost and run LangGraph — or run them side by side, which is what we do internally.

We are not paid by anyone in this space. OpenShell, LangGraph, AutoGen, and CrewAI are all open-source projects we have contributed bug reports or patches to.

All four laptops we tore down use the same Grace-Blackwell silicon with nominally the same 100 W sustained TDP. Their thermal solutions are wildly different and the impact on sustained agent performance is large.

Dell Precision S16 (Workstation cooling): full vapor chamber spanning CPU and GPU, four heat pipes feeding two 75mm fans, and crucially a separate auxiliary chamber for the unified memory controller. This last detail is what lets the S16 sustain full 70B decode without throttling — the memory controller throttles before the GPU on the other three laptops we tested.

Razer Blade 16 Spark Edition (Performance cooling): vapor chamber, three heat pipes, two 70mm fans. Beautiful design, tight tolerances, and visibly thermally constrained under sustained load. p99 GPU temperature on our standard soak: 91.4 °C, which sits 1.6 °C below the throttle ceiling. It does not throttle, but it has no margin. The first hot day in a non-A/C room and it will.

Lenovo ThinkPad P1 Spark Gen 1 (Workstation cooling): full vapor chamber, three heat pipes, two 65mm fans. More conservative than the S16's design and slightly noisier under load (49 dBA at the keyboard vs. 44 dBA on the S16) but holds temperatures comfortably below throttle.

ASUS ZenBook 14 Spark (Thin & Light cooling): two heat pipes, two 50mm fans, no vapor chamber. This is fine for chat-only workloads and the 32 GB memory ceiling effectively prevents anyone running sustained 70B inference on it. ASUS made the right choice — adding more cooling to a laptop that physically cannot run the workloads that need it would have been a waste of weight and battery.

The surprising tower fan: the MSI Spark Titan desktop uses a 200mm front intake fan running at an absurdly low 480 rpm under sustained load. It is the quietest workstation we have ever tested at full tilt (33 dBA at 1 m). MSI sized the airflow for the silicon and let the rest of the chassis do the work of being big.

Failure mode worth noting: on two of the four laptop tear-downs, the thermal paste was visibly under-applied (small voids near the GPU die corner). Industry-wide, mass-production thermal paste application is still hit-or-miss. If you are buying a Spark laptop you intend to push hard, a careful repaste with PTM7950 phase-change pad is a 4 °C win for $14 and 30 minutes of your time.

Photos of all four tear-downs and thermal camera imagery under sustained load are in the linked GitHub repo (rtxsparks/teardowns). Treat warranty implications appropriately.

We believe in publishing our errors. Here are the five things we got most wrong in the first six months of this site, what we did about each, and the meta-lesson we drew.

1) We launched with a single Spark Capability Score (SCS) and no separate Agent Readiness Score. Within six weeks it was obvious that 'how fast is this chip' and 'will my agent loop survive overnight' were different questions. ARS shipped in v2026.2. The meta-lesson: do not collapse multiple questions into a single composite to keep the homepage simple.

2) Our first 70B throughput benchmark used Llama-2-70B Q5. Llama-2 was already legacy and Q5 advantaged devices with more bandwidth. We re-ran everything on Llama-3.1-70B Q4 and the rankings shifted meaningfully — one device moved 8 points. Meta-lesson: pick benchmark models that match what users actually run, not what is convenient.

3) We initially gave the NVIDIA DGX Spark Reference design a synthetic 'reference 100' score across all categories, on the theory that it was the reference. This was lazy and slightly misleading — the reference design has real trade-offs (no ethernet over Thunderbolt, no consumer warranty channel) and should score on its merits. We re-scored it and it landed at 95/93/95, which is excellent but not perfect.

4) Our first cluster playbook recommended a 2.5 GbE switch between nodes. This was simply wrong — we tested with a switch because that is what we had on hand, never measured the latency cost, and shipped the playbook before validating. A reader caught it within 48 hours. We updated the playbook and added a 'measurement provenance' note to all subsequent playbooks documenting exactly what hardware was used.

5) We rated firmware update cadence inside TLS for the first three releases, then moved it to ARS in v2026.4 (see the ARS anatomy post). This was the right move but we should have predicted it — slow updates degrade today's agent reliability, which is an ARS concern, not a long-term trust concern. Meta-lesson: when a score sub-component is doing double duty, split it sooner.

Things we considered errors at the time and now think were defensible: not including a 'best overall' device on the homepage (still defensible — the question is poorly posed), not running Windows benchmarks at launch (defensible — the Windows agent stack was not ready), and not including any cloud-only comparisons (defensible — this site is about local agents).

Things we are watching for as potential future errors: under-weighting Linux distro coverage (we test on Ubuntu and Fedora; some users run Arch and NixOS), not yet having a formal community-benchmark validation team (we have the submission flow but only 2 people reviewing), and our scoring methodology being too slow to react to firmware changes (we are working on a continuous-scoring pipeline).

If you have caught us being wrong about something not listed here, tell us. The fastest way is to open an issue on the rtxsparks/methodology repo. We will respond, and if you are right, you will end up in the next version of this post.

The 'local vs. cloud' debate is mostly vibes. We built a real model. The headline: a $3,899 MSI Spark Titan pays for itself against $/M-token cloud pricing on Llama-3.1-70B-class inference in 4 to 9 months, depending on utilization — or never, if you only run a few hours a week.

Methodology: we use $5.00 per million output tokens as the cloud reference (a blended rate across the three major Llama-70B-class hosted endpoints as of June 2026, weighted by market share). For the Spark, we amortize $3,899 hardware over 36 months and add $0.13/kWh electricity at the measured 1.42 kWh per million tokens — so $0.18/M-token in marginal cost, plus $108/month amortization.

Heavy utilization (8 hours/day, 5 days/week of active agent work, generating ~6 M tokens/day): cloud cost $900/month, Spark cost $108 amortization + $11 electricity = $119/month. Break-even at month 4. Three-year savings: $28,000.

Moderate utilization (3 hours/day, 5 days/week, ~2 M tokens/day): cloud cost $300/month, Spark cost $108 + $4 electricity = $112/month. Break-even at month 9. Three-year savings: $6,800.

Light utilization (1 hour/day, 3 days/week, ~250K tokens/day): cloud cost $37/month, Spark cost $108 + $0.50 electricity = $108.50/month. Break-even: never (in 36 months). The Spark loses by $2,575 over three years.

Things the model does not capture (and you should): (a) latency and privacy benefits of local — these are real but hard to dollarize, (b) opportunity cost of capital — adds maybe 5% to local TCO at current rates, (c) developer time spent operating local infra — adds materially to local TCO if you are not already running Linux servers comfortably, (d) cloud price drops — we have seen $5/M-tokens drop to $3/M-tokens over the past 18 months on equivalent models, and that trend is not over.

The under-discussed factor: utilization stickiness. People who buy a Spark use it more than they predicted. In our community survey (n=412), users who bought a Spark for 'occasional' use reported 2.8× their predicted hours by month 6. The cloud bill they would have paid grew accordingly.

Recommendation: if you can credibly forecast >3 hours/day of active agent use, the math is a clear win for local. If you are at <1 hour/day, stay on cloud. The middle case is genuinely a judgment call and depends on how much you value latency, privacy, and the ability to experiment without watching a meter.

We have published the full spreadsheet (Google Sheets and CSV) with all assumptions broken out. Fork it and plug in your own numbers.