Hardware verified directly

• NVIDIA DGX Spark and ASUS GX10, both GB10 unified-memory systems. The old site described the GX10 as a second DGX Spark.
• Mac Studio M5 Max, 18 CPU cores, 40 GPU cores, 48 GB unified memory.
• RTX 5090 workstation, Ryzen 9 9950X3D, Windows + WSL2. The GPU driver reports 32,607 MiB device capacity. Guest RAM is not presented as installed Windows RAM.

Some dashboard hardware labels also lag the real machines. System reports take precedence for hardware facts; active configs take precedence for role placement.

The current placement

The primary coder is Qwen3.8-Flash-Next NVFP4 on vLLM 0.30.0, across both GB10 nodes with tensor and expert parallelism. Its running launch arguments specify 262,144 context, eight sequences, an 8,192 prefill batch, allocator 0.74 and three native MTP draft positions.

The coordinator now routes agent and embeddings to the Studio. The Studio runs an exclusive primary swap group for its large models and image alternatives, with embeddings in a separate persistent group.

The workstation is the primary route for media and several utility roles: OCR, translation, transcription and speech. Several coding candidates also exist in its configured inventory. Configured does not mean benchmark-qualified or loaded.

Keep the evidence separate

No new inference benchmark was run during this read-only audit. These are configuration facts, not throughput claims. The older Spark studies and September Studio evaluation keep their own dates and protocols. Upstream deployment-kit changelog measurements were not republished as results from this lab.

The reusable lessons and current limits are collected in hardware, setup guides and the software stack.

Live generation was idle (0 tok/s) on every node. That is the only live throughput number from this pull. A later coordinator-page pull showed live gauges as connecting / incomplete, so this idle probe remains the published snapshot. No invented tok/s.

Catalog figures such as ~80–82 tok/s for agent / lightning, ~65 for agent-gemma, and ~60 for omni are dated roster copy; the Oct 1 probe saw agent unloaded. The coordinator roster (Capabilities) lists resident agent / lightning, embed, and Kokoro tts, with on-demand Mage-Flow image, omni, ocr, translate, stt, agent-gemma, tts-clone, and coder-ornith.

OCR, translate, STT, and TTS selectors were unloaded in the Oct 1 window. The Gaming PC (RTX 5090) peer was online and is the exclusive media box (music, video, image edit) — not the Spark chat worker. Mac Studio M5 Max had embeddings ready; its GPU block from that pull was mis-templated and is not published.

No private hostnames, no live charts, no public gateway URL, no connect recipes.

Review is a separate role

QABot returns MERGE or HOLD from the evidence. MergeBot squash-merges eligible changes under repository policy. A HOLD sends the change back for correction and verification. Deployment authorization remains a separate policy decision.

The reusable prompt

The public agent workflow contains a reference prompt adapted from this process. It is a reusable technical template; private repository targets and original operating instructions are omitted.

The record for each pass should contain the problem, resulting behavior, tests actually run, review decision, limitations and next justified improvement. Project identities and business work stay private.

One Spark is the coordinator (resident agent / lightning, embeddings, Kokoro; on-demand Mage-Flow image and perception). The other is the GB10 coding peer (tensor-parallel Qwen3.8-Flash-Next, Coder-Next / long-context profiles, ornith, voice clone). The 5090 is exclusive media — music, video, image edit — not the Spark chat roster.

This site will not expose live internals, private hostnames, connect recipes, or a public API. The journal carries the study chronology from the internal benches record (page last-modified 2026-09-12): gates, rejects, and deploys, labeled as historical. The Oct 1 snapshot on the home page is a separate attributed pull — live generation that day was idle (0 tok/s). A later coordinator-page pull had incomplete live gauges, so that idle probe stays the published snapshot.

Three models, three jobs

Lightning MLX 4-bit was the fast-agent candidate. Qwen3.8-27B MLX 4-bit was the coder. Gemma-4 QAT Q4_K_M was evaluated as a writer through llama.cpp Metal.

• Chat-adapted HumanEval: Qwen 156/164 (95.1%), Lightning 140/164 (85.4%). Gemma was not run on this coding benchmark.
• Code decode medians: Lightning 150.1 tok/s, Qwen 33.0 tok/s, Gemma 78.1 tok/s. Each is a median of three short 512-output probes on a loaded backend.
• Framework criteria: 71.5% / 89.5% / 84.3%. These are regex checks, not compilation results.
• Prose constraints: 73.5% / 87.2% / 97.0%. Constraint adherence is not a literary-quality rating.

The serving path changed the answer

The original metrics proxy reconstructed content and dropped non-streaming tool calls. Separate stochastic tool runs scored 32.4% through that proxy, 79.4% directly and 88.2% through the repaired path. The broken response structure was demonstrated; the difference between the latter two runs is not proof of a model quality gain.

The original launcher also left the MLX backend outside normal unload ownership. The repaired supervisor owns backend and proxy together. Embeddings gained an independent persistent group; TTL zero by itself had not kept them resident. Passive metadata polling was changed so it did not wake inactive models.

What the measurements establish

HumanEval used all 164 original tasks, one greedy chat sample, a 2048-output cap, thinking off, sandboxed executable tests and no answer repair. All reference solutions passed runner validation. This is chat-adapted pass@1, not EvalPlus, SWE-bench or a vendor leaderboard reproduction. Training-data contamination remains possible.

The local tools and prose suites are custom gates. Some developer-tool regex checks penalized valid alternatives, so their raw percentages are not autonomous coding success rates. The retrieved synthetic records reached about 34K input positions, not a 64K or 262K capacity qualification. Manual Swift review found correctness issues even in answers that scored well.

The public benchmark records retain these distinctions.

Both production lanes were remeasured after their runtime upgrades, then Mistral Small 4 119B-A6B NVFP4 ran the same fast gates on one Spark at 256K. Non-reasoning mode.

Verdict — keep the split

• Keep agent. Lightning owns latency: 2.5× Mistral at c1 and 2.2× at c4. A long-form pass reached 85.9 tok/s and 0.13 s TTFT, though a requested 10K-word essay stopped at 3,935 words.
• Keep coder. Qwen3.8-27B + DFlash2 owns code: best framework score and 94.1% broad tools, including perfect multi-turn follow-through and restraint.
• Retain checkpoint. Mistral wins broad tools (100%) and prose constraints (86.9%). It fits TP1 at 256K, but 66.1 GiB weights and a ten-minute reload make it an unrouted specialist.

Fast-gate table

• Framework code (8 tasks): Lightning 80.3% · Qwen 85.9% · Mistral 81.4%
• Developer tool choice (12): 75.0% · 75.0% · 83.3%
• Broad agent tools (34): 82.4% · 94.1% · 100.0%
• c1 decode: 77.6 / 19.6 / 30.7 tok/s
• c4 aggregate: 169.0 / 42.7 / 75.9 tok/s
• Prose constraints: Lightning 63.8% · Qwen not rerun · Mistral 86.9%
• Ready time: Lightning and Qwen resident / instant; Mistral 674 s cold · 585 s cached

Capacity screen

GLM-5.3-Flash NVFP4 is 204.4 GB and DeepSeek-V4.1-Flash FP8 is 510.3 GB. Neither fits one 121.6 GiB Spark. Mistral’s one-Spark fit allocated 66.12 GiB model memory plus a 27.33 GiB KV pool; retrieval was not needle-tested in this fast gate.

Day-0 NVIDIA Nemotron-3.5-Lightning 30B-A3B (3B active), official NVFP4 + DSpark on a single DGX Spark. Question: is Lightning a coder upgrade, or a fast sub-agent / long-context challenger?

Verdict

• Rejected as primary coder. Quality gap is decisive under the same rule that reverted Laguna: need a speed or capacity win without losing code. Lightning has both operational wins and still loses code by sixteen points.
• Kept as on-demand lightning. Sub-agent / multi-agent workhorse. Not in the coder spillover.
• Ornith stays the tools specialist. Lightning devtool 66.7% beats the then-champion 58.4% but loses to Ornith 75.0%.

Measured (vs Coder-Next champion)

• devcode: 70.0% vs 86.4% (−16.4, outside ±4 noise)
• devcode wall: 44 s vs 85 s (1.93× faster)
• Single-stream c1: 82.3 vs 50.9 tok/s (1.62×)
• Aggregate c2 / c4: 108.5 / 161.5 vs 76.2 / 76.0 — Lightning scales; the champion plateaus
• Footprint: ~22 GB + 1.3 GB DSpark vs champion 53.9 GiB

Speed alone does not promote a coder. Lightning earns a fleet seat as a challenger because the speed and capacity win is large and the quality loss is honest.

Day-0 open weights from Meta Superintelligence Labs (Apache 2.0). Dense multimodal 30B distilled from Muse Spark. Question: is it a fleet fit as coder or always-on agent?

Verdict — rejected both roles

• Not a coding lane. devcode 81.5% vs champion 86.4% (−4.9, outside ±4 noise). devtool collapsed to 25.0%. Wall-clock 20× slower. Native context 131K fails the verified-256K coder gate.
• Not always-on agent. Tools 91.2% tie the Gemma agent, and developer sidecar 30/30 matches Omni. Dense 30B at 10.1 tok/s loses to MoE Gemma at 60.4 tok/s on every felt agent loop.
• Not justified as an on-demand specialist. Ornith already owns tools, Omni owns developer vision, Gemma owns fast agent.

Coder axes vs Coder-Next

• c1: 10.1 vs 50.9 tok/s (0.20×). Even DFlash code peak 34.3 tok/s stays 0.67×.
• GPU footprint ~21 GiB vs 53.9 GiB — a win that does not pay for 0.2× decode.
• Cold start 17 s vs 90 s — also not enough.

Same promotion rule as the Laguna revert: do not promote on tool quality alone when single-stream is 0.2×. Not added to llama-swap.

The production coder sat 33rd on SWE-bench Verified (self-reported 70.6%). Of the 32 entries above it, only three both outranked it and fit one Spark at 256K native context. Every score on that board is self-reported (verified: false). A rank buys a gate slot, nothing more. Local numbers below were measured idle, thinking off.

Local gate versus Coder-Next

• Ornith-1.0-35B — published 16 · 75.6%. Local: devcode median 84.2%, devtool 75.0%, c1 61.6 tok/s, 28.2 GiB.
• Qwen3.6-35B-A3B — published 24 · 73.4%. Local: 81.7% / 75.0% / 62.4 tok/s / ~28 GiB.
• Laguna-XS-2.1 — published 31 · 70.9%. Local: 83.9% / 50.0% / 35.3 tok/s / ~87 GiB.
• Coder-Next incumbent — published 33 · 70.6%. Local: 86.4% / 58.4% / 50.9 tok/s / 53.9 GiB.

One gate run is not a result. Ornith’s five-run spread was 73.2, 81.7, 84.2, 85.7, 87.3 — median 84.2 against the champion’s 86.4 (median of 6), with roughly double the variance (stdev 5.6 vs 2.9). Swift stayed the hole: median 60.7 vs the champion’s 74.1.

Verdict — role split

All three rejected as primary coder. Ornith took the tools-specialist slot. coder-laguna was retired. Promoting on one lucky observation is how Laguna S 2.1 was promoted on July 23 and reverted three days later.

A -ub sweep on this architecture left 2048 as the standard: 4096 bought almost nothing at 30K and decode stayed flat.

The first same-node, same-day A/B of the two coders, one resident at a time. The July 23 promotion of Laguna had been made on a single axis — code score — and every other axis favoured the incumbent. On this day the code score reversed too.

Measured (Laguna S 2.1 vs Qwen3-Coder-Next)

• devcode: 87.2% vs 90.9% (Coder-Next +3.7)
• Same-suite wall: 435.7 s vs 82 s (5.3×)
• devtool: 75.0% vs 66.7% — Laguna’s one durable edge
• c1: 17.7 vs 52.7 tok/s (2.98×)
• c2 / c4: 33.3 / 55.2 vs 76.2 / 76.0 — Coder-Next scales, Laguna flattens
• Resident footprint: 101 GiB vs 53.9 GiB (47 GiB reclaimed)
• Cold start: 8–15 min vs ~90 s

Verdict

• Keep coder: Qwen3-Coder-Next restored as the primary lane at 2 × 262,144.
• Specialist: Laguna S 2.1 retained on demand for tool-calling and verified 257K retrieval. Swaps with coder, so only one large coding model is resident. (Retired as a named lane four days later, July 30.)
• Promotion criteria corrected: devcode on this model spanned 83.6–92.1 — a ~9-point spread. Speed, scaling, and memory now carry the weight.

Ops after the revert

507 coder requests, 0 errors, 59.3 tok/s average, longest turn 123 s. Independent sparkrun comparison ranked Coder-Next first of ~30 Spark configurations (0.74 lm-eval mean, HumanEval 0.71 vs Laguna 0.37).

Prompt-speed observability (same day)

The dashboard had been recording coder prompt speed as unknown or worse: 23 of 24 stored samples were negative (min −121,862, max 46,591,011 tok/s), which flattened the prompt histogram into two of fourteen bins. Cause: a metrics shim synthesized timings for engines that omit llama.cpp’s timings block, then shadowed real llama.cpp measurements. After the shim left the coder path: 0 negatives, realistic band 13–709, and an extra proxy hop on an identical 19-token prompt fell 2,930 ms → 1,342 ms. The −1.0 sentinel (not measured) is preserved. Not live Oct 1 telemetry.

Question: can Laguna’s serving runtime be tuned on GB10? Sweep covered DFlash, FP8 KV, CUDA graphs, and the allocator.

Outcome

• Promoted (this day): eager mode with a .79 allocator. .80 crossed the earlyoom threshold during startup.
• Rejected: DFlash K=7. Draft accepted 1,320 of 8,666 tokens — 15.2% — and reduced c4 throughput.
• Best profile still only 17.6 tok/s c1 / 54.6 c4. KV pool allocated 1,173,283 tokens (4.48× the configured 262,144 window).

The ceiling was the model on this hardware, not the configuration. This is the promotion the July 26 same-node A/B reversed.

Image generation — Mage-Flow Turbo 4B

Six fixed prompts at 1024². Mage was the only tested model combining high visual quality, sub-10-second output, and under-20 GiB peak allocation.

• Mage-Flow Turbo 4B — 3.96 s warm, 17.03 GiB peak. Production image alias. Not uncensored (life-drawing prompt returned a blank refusal).
• Z-Image-Turbo — 5.70 s warm, 21.69 GiB. Quality / text-rendering reference.
• Sana Sprint 1.6B — 0.79 s warm, 10.19 GiB. Preview specialist; weaker count fidelity.

image later moved on demand rather than resident — the pipeline had pinned 17 GiB around the clock. Warm generation ~4 s; cold ~120 s.

BTL-3 and Laguna refresh — superseded

Fresh local runs of eight framework tasks and twelve tool-choice scenarios against refreshed NVFP4 snapshot 0761412.

• Laguna S 2.1: code 89.0%, tools 58.3%, c1 19.0 tok/s, context edge 257,107. About 96.5 GB.
• BTL-3: code 88.0%, tools 75.0%, c1 4.1 tok/s. Always-on thinking exhausted its answer budget.
• Then-current Coder-Next control: code 83.6%, two-agent 76.2 tok/s.

Superseded. This study produced the July 23 Laguna promotion that the July 26 A/B reversed (Laguna then measured 17.7 tok/s single-stream).

Five controlled studies landed the same day.

Three-lane coder — deployed

Capacity-aware dispatcher. Two Spark slots plus one local lane. Four concurrent 256-token streams reached 99.6 aggregate tok/s (42.0–56.8 per stream); excess queued, no 409s. Session affinity keeps a conversation on one worker so its prompt cache stays local.

Coder 2 × 256K — qualified

Will two independent 262,144-token slots hold on one Spark? Yes. Both deep sessions retrieved correctly near 241K. 52.6 tok/s single · 76.0 aggregate on two streams · warm turns 4.3–4.4 s. About 55.2 GiB. This is warm-session affinity, not a 2× cold accelerator.

Laguna S vs coder — rejected

First evaluation, including native TP=2. Code 79.7% vs incumbent 87.8%. Native TP=2 deadlocked on 512-token generations. Not a quality or throughput upgrade.

Coder quantization — keep UD-Q4_K_XL

Three Q5 variants beside production Unsloth dynamic Q4, same 256K settings.

• UD-Q4_K_XL (keep): 89.2% code, 50.1 tok/s, 49.6 GB
• Q5_K_M: tools rose to 66.7%, code fell to 86.2%
• UD-Q5_K_M: 87.4% code, ~17% slower
• UD-Q5_K_XL: best Swift 74.1%, still lost overall quality and speed

More bits did not make a better default. Q5 cost 7–10 GB and ~17% decode for no complete-workload win.

Split vision router — Nemotron Omni

Images are described once and replaced with cached text; coding stays on the text-only coder.

• Keep vision: Nemotron Omni — 30/30 developer facts in 10.0 s; production context raised to 262,144. Perfect retrieval through 240,123 actual tokens.
• Keep coder: Qwen3-Coder-Next — 87.6% code, 75.0% developer tools, retrieval near 255K.
• Fallback: Qwen3.5-9B — also 30/30, but 80.7 s wall (8×).
• Does not fit: Nemotron Super 120B — loaded, then OOM-killed.

llama.cpp runtime — promoted

Identical before-and-after tests on both Sparks. Production moved from b9967 to b10069 only after speed, cache, tools, long context, and multimodal gates passed. Active for agent, coder, embed, and omni. Prior image kept for rollback.

• Coder toolbench held 94.1%. Retrieval and arithmetic remained 3/3 through 121,512 real prompt tokens.
• Warm 17K prefix: 16,668 cached tokens, 0.625 s warm vs 13.63 s cold (21.8×).
• External draft-simple no longer crashed but only 30.2 tok/s at 2K / 13.6 tok/s at 30K. Production kept ngram-mod.

256K coding + vision — keep Coder-Next

Five native-256K challengers. Does any beat Coder-Next on framework code?

• Keep Coder-Next: 87.6%. Best challenger 81.8%.
• Nemotron Cascade 2 was the context-efficiency winner, not the code winner.
• No challenger justified a production-route change.

Which model should be the always-on agent? Four candidates ran the same long-form, tool, vision, cache, concurrency, and 120K-context suite. The current Agent remained the strongest operational baseline.

Verdict — keep Agent authoritative

Gemma-4-26B QAT won the job: best blind writing average, MoE-class latency, full context retrieval, no reliability regression.

• Blind overall: 8.35 / 10 (six constrained assignments)
• Tools: 91.2%
• Single stream: 60.4 tok/s
• Four-way aggregate: 129.9 tok/s
• Warm 17K prefix: 0.303 s (23.2× over cold)
• Deep edge pair: 78.3 s · 119,593 prompt tokens

Rejected

• Goetia (Gemma-4 heretic): tools and vision matched; blind writing 6.65. Operationally strong, not the writer.
• Qwen3.6 Fable Fusion: tools 97.1%, but blind 4.77 and ~10.8 tok/s. Rejected for the always-on seat.
• Ortenzya (dense 31B): blind 8.17, interesting as a routed creative specialist at 9.8 tok/s — not the resident agent.

Production restored with seven aliases live. This is dated study-page content, not the Oct 1 idle snapshot.

Same model, different acceptance

Qwen3.6-35B-A3B Q6_K on llama.cpp b9967, one slot, quiet hardware. Native MTP used six draft positions.

• Code, temperature 0.3: 64.1 → 100.9 tok/s with MTP enabled.
• Creative writing, temperature 0.7: 64.6 → 53.6 tok/s with MTP enabled.

The local summary attributes the difference to draft acceptance: rejected speculative work can cost more than it saves. Repeat count and spread were not recorded in the reviewed summary, so this is not a universal speedup claim.

Configure by role

Keep speculation as a measured per-role choice. A result on this model and sampling policy does not transfer automatically to a different checkpoint, drafting method or runtime. The current Flash-Next MTP3 configuration is a separate record.