Local models on NVIDIA GB10 · spark-e2b0 — which one should write your code?

NVIDIA GB10 · spark-e2b0 — 20-core Grace (Cortex-X925 / Cortex-A725) · NVIDIA GB10 · CUDA sm_121 · 128 GB unified · llama.cpp CUDA. 21 models in this tree. A row appears only when the run used the shared profile (temperature 0 on every trial, seed 42, one 16384-token slot, C compiled -std=gnu11). Aya-23 clamps that context to 8192. Older sweeps used different stacks, context sizes, and a 0.7-temperature retry, so they are not in this table. Their raw JSON is still on disk. Click any column header to sort. Generated 2026-10-02 09:47.

Where to look: this page ranks the models and prices them by what a working answer costs. Analysis covers behaviour under load, whether the code they write is fast, whether the wording of the prompt changes the answer, and self-repair. The failing samples are split by technology — C, Python, Bash, research — and models shows how to reproduce every number. Charts is the same data as pictures.

How many times does each test run? Coding suites (C, Python, Bash — easy, hard and brutal) and the research paper: 3 trials per task, all at temperature 0 with seed 42, so a miss is the same answer again. Framing, from the older sweep: 20 trials per wording. Decode speed: median of 3 repeated 2048-token generations — the tok/s column shows ±1 std across those runs (hover a cell for the exact count), as does the dot plot on the analysis page. Quality: 6 probes × 3 trials (temp 0, then 0.7×2). Concurrency: one pass per stream level (no repeats). Self-repair: one initial attempt, then up to 5 rounds of compiler feedback. Two writing tasks that are easy to confuse: tok/s is measured on a 1500-word essay about MIT (speed only, content not graded — each model's essay is on its detail page), while the research column is a different test: extracting NFS facts from RHEL 10 documentation. All raw data is downloadable as CSV files.

Dense vs mixture-of-experts

A dense model runs every parameter on every token; a mixture-of-experts model routes each token to a few of its experts, so only the active column does compute. That is why the 125B flash-next decodes like a 6B model and the whole top of the table is MoE — on memory-bandwidth-bound Apple silicon, active parameters are what you pay per token, and MoE buys a large total capacity at a small active cost. The last column, tok/s per active billion, is the efficiency of that trade; dense models are 1x by definition and omitted.

Green cells are strong, red weak — shaded by percentage so a column can be scanned without reading every number. Perplexity is llama-perplexity on WikiText-2 (50 chunks). It is not comparable to the MLX numbers on the other machine. Gemma's absurd PPL is a tokenizer artifact — trust the coding score.

What it costs to get working code

Correctness alone picks a model that is right and unusably slow; tok/s alone picks one that is fast and wrong. The number that decides it is the two divided: seconds of wall clock per solution that passes. Across the 41 coding tasks (research excluded), 3 trials each at temperature 0 — timed end to end, failures included, because a wrong answer costs you its generation time too.

Those totals are everything the model spent, right or wrong. Dividing by the answers that actually worked gives the figure below. first try is trial 1 alone, the honest number if you paste the first thing you get. with retry re-asks only when the previous attempt failed and stops at the first pass, so unused retries cost nothing — what a loop around the model really costs.

Rank is the frontier first (most solutions, then cheapest), then everyone else. beaten means another model is at least as accurate and cheaper — drop it.

kimi-k3 (referee) is not in these tables: the cost here is generation wall-clock, and the referee is a hosted cloud model whose solutions were written in-session, not generated through the harness — there is no timing to report.