LLMCheck Index Methodology
How the LLMCheck index ranks 79 local and frontier LLMs for Mac — a published estimation model, linked third-party benchmarks, and community submissions. Fully transparent, fully reproducible.
LLMCheck is an independent index of local-LLM performance on Apple Silicon — not a benchmark lab. Every figure is either a transparent estimate from the published model below, a sourced third-party benchmark (linked per row), or a community submission. Each data point is labeled with its provenance, and no figure is claimed as a first-party lab measurement.
Where Every Number Comes From
Every row in the leaderboard, the benchmarks table, and the open dataset carries one of three provenance labels. This mirrors the provenance_policy field published in benchmarks.json:
Derived from the LLMCheck estimation model — memory-bandwidth scaling plus quantization arithmetic, documented in full below. Estimates are useful for planning ("will this model fit and feel usable on my Mac?") but are not measurements. Every estimated speed figure on the site links back to this page.
A published figure from an accountable source, with the URL attached to the row — a vendor’s model card or announcement, an independent press review that documents its setup, Arena AI ELO ratings, MMLU/HumanEval/SWE-Bench results from official model cards and papers, or independent hardware test data. We link, we don't re-host or re-run.
One person’s run on a real Mac — a blog post, forum thread or benchmark submission — with its URL as the source. Community numbers are sanity-checked against the estimation model and known baselines before inclusion. Own a Mac? Submit a benchmark — real runs beat estimates every time.
Why an index and not a lab? A single lab machine can only test one chip, one runtime, one macOS version. An index that publishes its estimation math, links its sources, and accepts community runs covers the entire Apple Silicon range — and you can audit every step. When we're estimating, we say so.
How We Estimate Performance
Local LLM performance on Apple Silicon is unusually predictable, because two hardware numbers dominate everything: unified memory capacity (can the model fit?) and memory bandwidth (how fast can weights stream through the GPU?). The LLMCheck estimation model is built on those two numbers.
Step 1 — Will it fit? (RAM model)
+ KV cache: grows with context length — ~1–4 GB typical at 4k–32k context
+ macOS overhead: ~2–3 GB for the OS and the inference runtime
Fit rule: total must stay within ~75% of unified memory — macOS lets the GPU address roughly three-quarters of RAM by default
That 75% rule is where the minimum-RAM guidance across the index comes from: a 16 GB Mac has a ~12 GB working budget, a 24 GB Mac ~18 GB, a 64 GB Mac ~48 GB, and so on.
Step 2 — How fast? (Speed model)
Token generation is memory-bandwidth-bound: for every token, the runtime must stream essentially all active model weights from RAM through the GPU. Compute is rarely the bottleneck on Apple Silicon. That gives a simple ceiling:
model_bytes_GB: weight bytes read per token — total size for dense models, active-parameter bytes for MoE
0.783: runtime efficiency on the bandwidth term — inside the ~0.6–0.8 range typical of llama.cpp / MLX-class runtimes. Mixture-of-experts models use the same form with their own constants (below)
0.00146: fixed per-token cost in seconds (~1.46 ms) — kernel launches and sampling, which do not shrink as the model does
Cross-chip scaling: tok/s scales with the bandwidth ratio only while the bandwidth term dominates — below roughly 4 GB of weights the fixed cost takes over, and doubling bandwidth stops doubling speed
They are solved, not chosen. The two unknowns are fixed by the two vendor-published Apple Silicon figures in this dataset, both on M5 Max: LFM2.5-2.6B at 220 tok/s and Muse Glimmer 30B at 27 tok/s.
The result was then checked against a figure it had never seen — Muse Glimmer 30B on M4 Max, vendor-published at 24 tok/s. The formula predicts 24.1, an error of +0.5%. The single community figure on an M4 Pro comes out about 23% high, which is what a thermally-limited laptop under sustained load should do.
5 October 2026: the fit was first solved with the M5 Max at 600 GB/s, the figure the index carried for its MacBook Pro configurations. Apple’s figure is 614 GB/s (and 307 GB/s for the M5 Pro, which the index had at 273), so the efficiency is 0.783 rather than 0.801. Bandwidth × efficiency on the M5 Max is unchanged, so every M5 Max estimate is unchanged; other chips’ estimates moved about 2% lower, M5 Pro estimates up to 12% higher, and the held-out M4 Max check improved from +3% to +0.5%.
One efficiency multiplier cannot fit both ends of the range. At 30B, decode really is bandwidth-bound; at 2–3B the fixed per-token cost dominates, and a pure bandwidth model predicts speeds no small model actually reaches. Every estimated figure in the index was recomputed with the formula above on 15 August 2026. Before that, 63 of them implied a model reading its weights faster than the memory bus could deliver them — not achievable on any hardware. Measured figures, the filled squares and hollow circles, were not touched by this and never are.
Mixture-of-experts models — refit 5 October 2026
A mixture-of-experts (MoE) model stores all of its parameters but reads only the active ones for each token, so its bandwidth term uses active-parameter bytes: a 35B MoE with 3B active reads about 1.7 GB per token instead of 20 GB. It also pays more fixed cost per token than a dense model — routing, gathering experts, more kernel launches per layer. Until October the index scaled the dense formula by a flat 0.42, fitted to a single 2-bit DeepSeek V4 Flash run. Six fully specified plain-decode measurements of small MoEs then came in at 2–4× those estimates:
| Model | Chip | Quant / runtime | Measured | Source |
|---|---|---|---|---|
| Qwen 3 30B-A3B | M4 Max | 4-bit, MLX | 109.7 tok/s | arXiv 2601.19139 (sourced) |
| Qwen 3 30B-A3B | M4 Max | 4-bit, llama.cpp | 89.9 tok/s | arXiv 2601.19139 (sourced) |
| Qwen 3.6-35B-A3B | M5 Max | 4-bit, MLX, MTP off | 125.8 tok/s | oMLX database (community) |
| Qwen 3.6-35B-A3B | Mac mini M6 | 4-bit, MLX | 63.8 tok/s | HDZucht, raw data (community) |
| Nemotron 3.5 Lightning | Mac mini M6 | Q4_K_M | 45.1 tok/s | HDZucht (community) |
| Gemma 4 26B-A4B | Mac mini M6 | QAT | 48.2 tok/s | HDZucht (community) |
0.42: the large-MoE factor, fitted to the only fully specified large-MoE runs (DeepSeek V4 Flash at 2-bit). Treat large-MoE estimates as floors: BGR’s Qwen 3.5 122B-A10B runs landed at 0.58–0.61 of the unscaled formula, quantization unstated
Own measurements first: a model with its own measured rows has every other chip scaled from its nearest-bandwidth measured row, using the same class model
Not bandwidth-bound: ternary and sub-2-bit formats decode through unpacking kernels; the index quotes only their measured figures and scales those, labelled estimated
The refit moved the small MoE models up the leaderboard: on an M5 Max several now estimate above 100 tok/s, where speed points cap at 25. The index’s #1, KAT-Coder-V2.5, ranks on an estimate from this model; #2, Qwen 3.6-35B-A3B, on its community-measured 126 tok/s. The full 35B of weights still has to be resident — about 20 GB — which is why it is a 24 GB-Mac model despite generating like a 3B one.
Step 3 — A worked example
▶ Llama 3.3 70B (dense) on an M5 Max, Q4_K_M
- Weights:
70 × 0.57 ≈ 40 GBon disk and in RAM. - Total RAM needed:
40 + ~2 (KV cache) + ~3 (macOS) ≈ 45 GB. - Fit check: a 64 GB Mac budgets
64 × 0.75 = 48 GB— fits. A 48 GB Mac budgets36 GB— the 40 GB of weights alone don't fit. So a 64 GB Mac is the practical floor; the catalog records the model’s own need, about 44 GB. - Speed ceiling:
614 GB/s ÷ 40 GB ≈ 15.4 tok/stheoretical maximum. - Apply the formula:
1 ÷ (40 ÷ (614 × 0.783) + 0.00146) ≈ 12 tok/s— the estimated figure the index shows.
What the estimates can't capture
Honest limits of the model: thermals (a fanless MacBook Air throttles on long generations; a Mac Studio doesn't), context length (speed degrades as the KV cache grows — long chats get slower), quantization variants (Q5, Q8, and MLX 4-bit all shift size and speed), and runtime differences (Ollama, LM Studio, llama.cpp, and MLX can differ 10–20% on the same hardware). Real numbers will vary from the estimates — that's exactly why every estimated row is labeled, and why community submissions are invited to replace estimates with real runs.
Time to first token. The estimator models decode only. Since 5 October 2026 estimated rows carry no time-to-first-token; a TTFT appears only where a source published one. Prompt processing is where the M5 generation’s Neural Accelerators made their biggest gains, so a decode estimate says little about it.
The LLMCheck Score Formula
The estimation model above feeds one of four components in the composite 0–100 LLMCheck Score used to rank the catalog:
Speed (0–25): tok/s on the reference chip × 0.25, capped at 25 — measured where the index has a figure, otherwise estimated via the model above
Accessibility (0–15): RAM tier: ≤8 GB = 15, ≤16 GB = 12, ≤24 GB = 10, ≤32 GB = 9, ≤48 GB = 6, ≤64 GB = 5, above 64 GB = 3
License (0–10): MIT = 10, Modified MIT / GLM-5.3 = 9, Apache 2.0 / OpenMDW = 8, Gemma / Solar / LFM Open / NVIDIA Open = 6, Meta / Moonshot / Qwen Custom = 5, xAI Custom = 4, CC-BY-NC / N/A = 2
Dimension 1: Capability (50 points) — sourced
Raw model intelligence — reasoning, knowledge, coding, instruction following. Sourced from published third-party benchmark systems, linked per model.
The capability score (capScore) is the most heavily weighted dimension because the primary value of an LLM is output quality. capScore is sourced, not estimated: the index normalizes it from three public benchmark systems:
- Arena AI ELO Rating (40% weight) — Human preference ranking from lmarena.ai. Measures how often real users prefer a model's response over competitors in blind A/B tests. The gold standard for "does this model feel good to use."
- MMLU Score (35% weight) — Massive Multitask Language Understanding. Tests knowledge across 57 academic subjects. Sourced from official model cards on HuggingFace and arXiv papers.
- Coding Benchmarks (25% weight) — HumanEval (code generation) and SWE-Bench Verified (real bug fixing). Sourced from llm-stats.com and official model publications.
When official benchmarks are unavailable for a model (common for very new releases), the index extrapolates from related models in the same family and marks the score as estimated — same provenance rules as everything else. These estimates are replaced with sourced scores within 2–4 weeks of release.
Why 50 points? A very fast model that gives poor answers is less useful than a slower model with excellent reasoning. Capability is weighted highest because it determines whether the model actually solves your problem. Speed and RAM determine whether you can run it — but there's no point running a model that can't help you.
Capability Score Table (All 91 Models)
| Model | Params | capScore | License | Key published evidence | Source |
|---|---|---|---|---|---|
| DeepSeek V4.1 Flash | 552B MoE | 50 | MIT | Terminal-Bench 2.1 90.6, DeepSWE v1.1 74.2, GPQA 90.9 (model card); no Mac runtime yet | HF |
| MiMo-V2.6-Pro | 1.02T MoE | 50 | MIT | Terminal-Bench 2.1 89.9, DeepSWE v1.1 71.9, OSWorld-Verified 82.0 (model card) | HF |
| MiMo-V2.6-Flash | 309B MoE | 49 | MIT | Terminal-Bench 2.1 87.6, DeepSWE v1.1 67.9 (model card) | HF |
| Qwen 3.5 122B-A10B | 122B MoE | 38 | Apache 2.0 | SWE-bench Verified 72.0, GPQA 86.6, MMLU-Pro 86.7 (model card) | HF |
| GLM-5.3 | 753B MoE | 50 | GLM-5.3 | Terminal-Bench 2.1 88.2, DeepSWE v1.1 66.9 (model card); post-training upgrade of GLM-5.2 | HF |
| GLM-5.3-Flash | 320B MoE | 48 | MIT | Terminal-Bench 2.1 84.3 (model card); vendor claims above GLM-5.2 — no SWE-Bench Pro figure on the card as of 7 Sep 2026 | HF |
| Qwen3.8-Flash-Next | 125B MoE | 47 | Qwen Custom | SWE-Bench Pro 62.5 (vendor scaffold), LiveCodeBench v6 91.9, GPQA 91.7 (model card) | HF |
| DeepSeek V4 Flash Vision-Exp | 305B MoE | 47 | MIT | Inherits V4 Flash text evidence; vision experimental, no independent benchmark verified | HF |
| Qwen3.8-2.4T-A95B | 2.4T MoE | 50 | Qwen Custom | SWE-Bench Pro 67.7, GPQA 92.6 (model card) | HF |
| GLM 5.2 | 753B MoE | 50 | MIT | SWE-Bench Pro 62.1% (SEAL standardized) / 68.5% vendor scaffold | HF |
| Kimi K3 | 2.8T MoE | 50 | Moonshot Custom | AA Intelligence Index #3; Frontend Code Arena #1 (1,679) | HF |
| DeepSeek V4 Pro | 1.6T MoE | 50 | MIT | SWE-bench Verified 80.6% (V4-Pro-Max, vendor) | HF |
| Kimi K2.6 | 1T MoE | 48 | Modified MIT | 1T-A32B multimodal agent flagship | HF |
| GLM-5.1 | 754B MoE | 48 | MIT | Led open SWE-Bench Pro before GLM 5.2 | HF |
| Inkling | 975B MoE | 47 | Apache 2.0 | AA Index 41; SWE-bench Verified 77.6 | HF |
| DeepSeek V4 Flash | 284B MoE | 47 | MIT | AA Index 50 (top open tier); Terminal-Bench 2.1 82.7 (vendor) | HF |
| Kimi K2.5 | 1T MoE | 47 | Modified MIT | — | HF |
| Inkling-Small | 276B MoE | 46 | Apache 2.0 | SWE-bench Verified 80.2 (open record); GPQA 89.5 | HF |
| Qwen3-235B-A22B | 235B MoE | 46 | Apache 2.0 | — | HF |
| DeepSeek V3.2-Speciale | 685B MoE | 45 | MIT | High-reasoning sibling of V3.2 | HF |
| Qwen 3.6-27B | 27B | 44 | Apache 2.0 | SWE-bench Verified 77.2 | HF |
| Laguna S 2.1 | 118B MoE | 43 | OpenMDW | Terminal-Bench 2.1 70.2 (max thinking); SWE-Pro public 59.4 | HF |
| Muse Glimmer 30B | 30B | 42 | Apache 2.0 | SWE-Bench Pro 51.2; AIME 94.7; GPQA 83.5 (vendor) | HF |
| Solar Open 2 250B | 250B MoE | 42 | Solar License | MMLU-Pro 86.2; LiveCodeBench v6 92.4 (vendor) | HF |
| DeepSeek V3.2 | 685B MoE | 42 | MIT | — | HF |
| Hunyuan Hy3 | 295B MoE | 41 | Apache 2.0 | AA Index 41 | HF |
| MiniMax M2.5 | 230B MoE | 40 | Modified MIT | SWE-bench Verified 80.2 (launch coverage) | HF |
| Gemma 4 31B | 31B | 40 | Apache 2.0 | — | HF |
| KAT-Coder-V2.5 | 35B MoE | 39 | Apache 2.0 | SWE-bench Verified 69.4 | HF |
| Ling-3.0 Flash | 124B MoE | 38 | MIT | AA Index 38 | HF |
| Qwen 3.5 397B-A17B | 397B MoE | 38 | Apache 2.0 | — | HF |
| Qwen 3.6-35B-A3B | 35B MoE | 38 | Apache 2.0 | SWE-bench 73.4 | HF |
| DeepSeek V3 | 685B MoE | 37 | MIT | — | HF |
| DeepSeek R1 | 671B MoE | 37 | MIT | — | HF |
| Nemotron 3.5 Lightning | 30B MoE | 36 | OpenMDW | AA accuracy-vs-speed Pareto claim (vendor) | HF |
| Mistral Large 3 | 675B MoE | 36 | Apache 2.0 | — | HF |
| Llama 4 Maverick | 400B MoE | 36 | Meta Custom | — | HF |
| GLM-4.7-Flash | 31B | 35 | MIT | — | HF |
| Llama 3.1 405B | 405B | 35 | Meta Custom | — | HF |
| Qwen3-Coder-Next | 80B MoE | 35 | Apache 2.0 | SWE-bench Verified 70.6 | HF |
| Gemma 4 26B-A4B | 26B MoE | 35 | Apache 2.0 | — | HF |
| GLM-4.7 | 355B | 34 | MIT | — | HF |
| Mistral Small 4 | 119B MoE | 34 | Apache 2.0 | — | HF |
| Laguna XS 2.1 | 33B MoE | 33 | OpenMDW | — | HF |
| Bonsai 27B | 27B | 33 | Apache 2.0 | ~90% of Qwen3.6-27B FP16 quality (vendor) | HF |
| GLM-4.5-Air | 106B MoE | 33 | MIT | — | HF |
| Step-3.5-Flash | 196B MoE | 33 | Apache 2.0 | — | HF |
| MiMo-V2-Flash | 309B MoE | 32 | MIT | — | HF |
| GPT-oss 120B | 117B MoE | 32 | Apache 2.0 | — | HF |
| Llama 4 Scout | 109B MoE | 30 | Meta Custom | — | HF |
| Nemotron-Cascade 2 | 30B MoE | 30 | NVIDIA Open | AIME / LiveCodeBench golds at 3B active (vendor) | HF |
| Gemma 4 12B | 12B | 30 | Apache 2.0 | MMLU-Pro 77.2, GPQA Diamond 78.8, LiveCodeBench v6 72.0 (model card) | HF |
| DeepSeek R1 70B | 70B | 30 | MIT | — | HF |
| Apertus 1.5 70B | 70B | 29 | Apache 2.0 | — | HF |
| Hermes 4 70B | 70B | 28 | Meta Custom | — | HF |
| Mixtral 8x22B | 141B MoE | 28 | Apache 2.0 | — | HF |
| Qwen 2.5 72B | 72B | 28 | Apache 2.0 | — | HF |
| Llama 3.3 70B | 70B | 27 | Meta Custom | — | HF |
| Qwen 3.5 35B-A3B | 35B MoE | 27 | Apache 2.0 | — | HF |
| QwQ 32B | 32B | 26 | Apache 2.0 | — | HF |
| Mistral Small 3.2 24B | 24B | 25 | Apache 2.0 | — | HF |
| Qwen 3 32B | 32B | 25 | Apache 2.0 | — | HF |
| Devstral Small 24B | 24B | 24 | Apache 2.0 | — | HF |
| DeepSeek R1 32B | 32B | 24 | MIT | — | HF |
| GPT-oss 20B | 21B MoE | 22 | Apache 2.0 | SWE-bench Verified 53.2, GPQA Diamond 58.6 at medium reasoning (model card) | HF |
| Qwen 3 30B-A3B | 30B MoE | 22 | Apache 2.0 | — | HF |
| Gemma 3 27B | 27B | 22 | Gemma | — | HF |
| Qwen 3.5 27B | 27B | 21 | Apache 2.0 | — | HF |
| Maple Preview 20B-A1B | 20B MoE | 20 | MIT | IMO-level claims (vendor, unverified) | HF |
| Nanbeige4.2-3B | 3B | 20 | Apache 2.0 | SWE-bench Verified 63.6 (vendor) | HF |
| Qwen 3 14B | 14B | 20 | Apache 2.0 | — | HF |
| Phi-4 14B | 14B | 19 | MIT | — | HF |
| Qwen 2.5 14B | 14B | 18 | Apache 2.0 | — | HF |
| Ministral 3 14B | 14B | 18 | Apache 2.0 | — | HF |
| Qwen 3.5 9B | 9B | 18 | Apache 2.0 | — | HF |
| Gemma 3 12B | 12B | 17 | Gemma | — | HF |
| Apertus 1.5 8B | 8B | 16 | Apache 2.0 | — | HF |
| Gemma 4 E4B | 4B | 16 | Apache 2.0 | — | HF |
| DeepSeek R1 8B | 8B | 16 | MIT | — | HF |
| Qwen 3 8B | 8B | 15 | Apache 2.0 | — | HF |
| LFM2.5-2.6B | 2.6B | 14 | LFM Open | Size-class instruction-following leader (vendor) | HF |
| Ministral 8B | 8B | 14 | Apache 2.0 | — | HF |
| Phi-4 Mini | 3.8B | 14 | MIT | — | HF |
| Gemma 4 E2B | 2B | 13 | Apache 2.0 | — | HF |
| Mistral 7B | 7B | 13 | Apache 2.0 | — | HF |
| Llama 3.1 8B | 8B | 12 | Meta Custom | — | HF |
| Qwen 3.5 4B | 4B | 12 | Apache 2.0 | — | HF |
| Qwen 3 4B | 4B | 11 | Apache 2.0 | — | HF |
| SmolLM3 3B | 3B | 10 | Apache 2.0 | — | HF |
| Gemma 3 4B | 4B | 10 | Gemma | — | HF |
Dimension 2: Speed on Apple Silicon (25 points) — estimated
Tokens per second at 4-bit on the reference chip: the M5 Max — or, for models that need more than 128 GB, which no M5 Max can hold, the Mac Studio M5 Ultra, tagged on the leaderboard. A measured figure (sourced or community) is used where the index has one for that chip; otherwise the estimate from the model above. LLMCheck runs no lab.
Speed points are calculated as: est. tok/s × 0.25, capped at 25 points. Any model estimated at 100+ tok/s on the reference configuration receives full speed points. The estimates assume these reference conditions:
- Quantization: Q4_K_M (most common consumer quantization)
- Reference hardware: M5 Max, 128 GB Unified Memory (614 GB/s bandwidth); Mac Studio M5 Ultra (1,228 GB/s) for models above 128 GB
- Runtime class: llama.cpp / MLX-class engines (Ollama, LM Studio) with dense efficiency ~0.6–0.8
- Context: short-context generation — long contexts reduce speed as the KV cache grows
- Provenance: rows are upgraded from estimated to sourced or community as linked third-party tests and user submissions come in
Models that fit no Mac (more than 512 GB) or have no Mac runtime yet receive 0 speed points. The full dataset — with a provenance label on every row — is available for download at /data/.
Dimension 3: Accessibility (15 points)
How many Mac users can actually run this model? Lower RAM requirements = higher accessibility score.
Accessibility is a step function based on minimum RAM required at 4-bit quantization, derived from the RAM model above (weights + KV cache + macOS overhead, within the ~75% unified-memory budget). Since a large share of Mac users have 16 GB or less, accessibility is crucial for real-world impact:
| Min RAM (4-bit) | Points | Example Models | Est. Mac Users |
|---|---|---|---|
| ≤ 8 GB | 15 | Gemma 4 12B, Qwen 3.5 9B, Maple Preview 20B-A1B | ~100% of Apple Silicon |
| ≤ 16 GB | 12 | GPT-oss 20B, Mistral Small 3.2 24B, Phi-4 14B | ~85% |
| ≤ 24 GB | 10 | Qwen3.8-27B, Qwen 3.6-35B-A3B, KAT-Coder-V2.5 | ~40% |
| ≤ 32 GB | 9 | — (no current model) | ~30% |
| ≤ 48 GB | 6 | Qwen3-Coder-Next, DeepSeek R1 70B, Apertus 1.5 70B | ~15% |
| ≤ 64 GB | 5 | GLM-4.5-Air, GPT-oss 120B, Llama 4 Scout | ~10% |
| > 64 GB | 3 | DeepSeek V4 Flash, Qwen3.8-Flash-Next, GLM 5.2 | 128 GB+ Macs, or server |
Dimension 4: License Openness (10 points)
How freely can you use, modify, and distribute the model? More open = higher score.
| License | Points | Can Modify? | Commercial Use? | Models |
|---|---|---|---|---|
| MIT | 10 | Yes | Unrestricted | DeepSeek V4 Flash, GLM 5.2, Maple Preview |
| Modified MIT | 9 | Yes | Yes (attribution clauses) | Kimi K2.5/K2.6, MiniMax M2.5 |
| Apache 2.0 | 8 | Yes | Yes (with notice) | Qwen 3.6, Muse Glimmer, Gemma 4, Inkling |
| OpenMDW-1.1 | 8 | Yes | Yes | Nemotron 3.5 Lightning, Laguna S/XS 2.1 |
| Gemma | 6 | Yes | Yes (restrictions) | Gemma 3 (old license) |
| Solar / LFM / NVIDIA Open | 6 | Yes | Yes (attribution / terms) | Solar Open 2, LFM2.5-2.6B, Nemotron-Cascade 2 |
| Meta Custom | 5 | Limited | Yes (<700M users) | Llama 4, Llama 3.x, Hermes 4 70B |
| Moonshot / Qwen Custom | 5 | Limited | Yes (revenue thresholds) | Kimi K3, Qwen3.8-2.4T-A95B |
| CC-BY-NC | 2 | Yes | Non-commercial only | (none currently listed) |
| Proprietary / N/A | 2 | No | API only | (none currently listed) |
Note: CC-BY-NC (non-commercial) scores 2 — usable for research but not commercial deployment. Meta / xAI community licenses score 5 / 4, reflecting modification rights with commercial caps.
Score Examples
Gemma 4 26B-A4B (Score: 67) = capScore 35 + speed min(25, est. 48 tok/s × 0.25 = 12) + accessibility 10 (24 GB) + license 8 (Apache 2.0) + rounding = 65–67. Top-ranked because it combines Arena AI #6 quality with fast MoE inference on a 24 GB Mac.
Qwen 3.5 9B (Score: 66) = capScore 18 + speed min(25, est. 100 tok/s × 0.25 = 25) + accessibility 15 (8 GB) + license 8 (Apache 2.0) = 66. Ranks high because maximum speed + accessibility points compensate for lower raw capability.
Kimi K2.5 (Score: 60) = capScore 50 (highest!) + speed 0 (server only) + accessibility 0 (>128 GB) + license 10 (MIT) = 60. Despite being the most capable model, it scores lower because no Mac user can run it locally.
Limitations & Known Issues
- Arena ELO volatility: Ratings shift weekly as new votes come in. The index snapshots monthly and notes the capture date.
- Estimated capScores: ~15% of capScores are extrapolated from model-family performance when official benchmarks are pending. These are marked "est." in the table above.
- Estimates are not measurements: speed figures come from the bandwidth model, which cannot capture thermals, long-context slowdown, or runtime-specific optimizations. Expect real-world variance of 10–20% either way — sometimes more on fanless machines.
- Quantization baseline: All estimates assume Q4_K_M. Some models are commonly run at Q5, Q8, or MLX 4-bit, which shift both size and speed; the index standardizes on one baseline for fair comparison.
- No multimodal scoring: The current score does not reward multimodal capabilities (image/audio input). Models like Gemma 4 E4B have multimodal features not captured in the 0–100 score.
Corrections and real-world benchmark data are always welcome. If you have runs that differ from the index's estimates, submit them through the community benchmark process — verified community rows replace estimates.
Frequently Asked Questions
Does LLMCheck run its own benchmarks?
No. LLMCheck is an independent index, not a benchmark lab. Every figure on the site is one of three things: an estimate from the published LLMCheck estimation model (memory-bandwidth math and quantization arithmetic, fully documented on this page), a sourced number from a linked third-party benchmark, or a community-submitted run. Each row is labeled with its provenance, and no figure is claimed as a first-party lab measurement.
How does LLMCheck calculate its scores?
The LLMCheck Score is a 0–100 composite metric: Capability (50 pts) sourced from published third-party evaluations such as Arena AI ELO ratings and MMLU/coding benchmarks, Speed (25 pts) from estimated tokens/sec on the M5 Max reference configuration, Accessibility (15 pts) inversely proportional to minimum RAM, and License Openness (10 pts) where MIT scores 10 and restrictive licenses score lower. The formula is fully transparent and reproducible.
Where does LLMCheck get its capability scores?
Capability scores are derived from three public benchmark sources: Arena AI ELO ratings (human preference, weighted 40%), MMLU scores from official model cards (knowledge breadth, weighted 35%), and coding benchmarks like HumanEval and SWE-Bench (weighted 25%). All sources are linked per model. When official benchmarks are unavailable, the index extrapolates from related models in the same family and marks the score as 'estimated'.
How does LLMCheck estimate tokens per second on Apple Silicon?
Token generation on Apple Silicon is memory-bandwidth-bound, so estimated tok/s ≈ (memory bandwidth in GB/s ÷ model size in GB at Q4_K_M) × an efficiency factor of roughly 0.6–0.8 observed for llama.cpp/MLX-class runtimes. Mixture-of-Experts models use active-parameter bytes instead of total size, which is why they are much faster. The active-bytes figure is then scaled by a MoE factor of 0.42, fitted to the index’s one community-measured MoE row (DeepSeek V4 Flash, 13B active, M5 Max, 39 tok/s); routing, expert-loading and KV overheads mean a sparse model does not reach the bandwidth-bound ceiling its active size alone would suggest, and the existing MoE estimates all sit in the 0.24–0.53 band of the unscaled formula. Update, 23 September 2026: the first press measurements of a sparse model on the new Studios — Qwen 3.5 122B-A10B at ~80 tok/s on M5 Ultra and ~60 on M3 Ultra (BGR) — land near 0.6 of the unscaled formula. The index keeps 0.42 as a deliberately conservative factor rather than refit to a spread that wide, so MoE estimates may understate real speed; a model with its own measured rows has its other chips scaled from those measurements instead. On the Best-by-Mac pages, a chip with no row of its own is filled from the model’s nearest-bandwidth row using the same two-term model, and is always marked estimated. Scaling across chips follows the bandwidth ratio. The full model is published at llmcheck.net/methodology#estimation, and every estimated figure is labeled as such.
Why does LLMCheck weight capability at 50% of the total score?
Capability receives the highest weight because the primary value of an LLM is the quality of its outputs. A very fast model that gives poor answers is less useful than a slower model with excellent reasoning. However, speed (25%) and accessibility (15%) ensure that models which actually run well on consumer Macs score higher than server-only models with superior capability but no practical local use.
How often are LLMCheck scores updated?
Scores are updated within 48–72 hours of major model releases. The full leaderboard is refreshed monthly with the latest Arena AI ELO ratings and community benchmark submissions. Speed estimates are recomputed as new Apple Silicon hardware specifications become available. All updates are timestamped in the open dataset at llmcheck.net/data/.
Benchmark Sources
- Arena AI / LMSYS Chatbot Arena — Human preference ELO ratings
- HuggingFace Model Hub — Official model cards with MMLU and benchmark data
- LLM Stats — Aggregated benchmark scores (HumanEval, SWE-Bench)
- Onyx Open LLM Leaderboard — Tier rankings and benchmark aggregation
- Google DeepMind Gemma 4 Blog — Official Gemma 4 benchmarks
- GEO: Generative Engine Optimization (Princeton/Georgia Tech) — Research methodology reference
See the Full Leaderboard
91 verified models ranked by LLMCheck Score. Filter by your Mac's RAM, sort by speed or capability — every figure labeled with its provenance.
View Leaderboard →