Evidence and recommendation methodology
How LocalAIRun reaches a recommendation
LocalAIRun is a planning system, not a universal benchmark. It combines published specifications, artifact-level memory estimates, runtime compatibility, task signals, prices, and real-world reports. This page explains what each signal means, how it affects a result, and where uncertainty remains.
Evidence levels
A source can establish a specification without proving a complete workflow. LocalAIRun keeps those claims separate.
The documented workflow was run on hardware available to the maintainer and a structured result was recorded.
Applies to the exact tested versions and settings, not every machine in the same product family.
A user submitted a structured result or a sufficiently detailed public report can be tied to a specific setup.
Reports are environment-specific and may not be independently reproduced.
The value comes from a model card, vendor specification, paper, release note, or runtime documentation.
A published compatibility claim does not prove performance on every configuration.
LocalAIRun derives the value from weight size, quantization, context assumptions, overhead, price components, or related fields.
Useful for screening; actual memory, speed, and price can differ.
Public metadata exists, but an important field or end-to-end workflow has not yet been confirmed strongly enough.
Treat the page as a research starting point and verify before purchasing hardware.
Source hierarchy
Sources are preferred in this order. A lower-level source may fill a gap, but should not silently override stronger evidence.
- 1
Official model, hardware, and runtime documentation
Primary specifications, model cards, papers, license files, release notes, supported platforms, and published prices.
- 2
Artifact metadata and established model registries
Checkpoint files, quantized builds, configuration files, Hugging Face metadata, and runtime manifests used to establish the artifact that will actually load.
- 3
Reproducible benchmarks and structured reports
Results with identifiable models, settings, tasks, hardware, runtime versions, and enough context to interpret what was measured.
- 4
Community experience
Detailed issue reports, forum posts, and discussions that expose compatibility problems or practical tradeoffs not covered by official documentation.
- 5
LocalAIRun calculations
Derived memory, fit, price, and recommendation signals. These are explicitly presented as estimates rather than observed test results.
Memory and hardware fit
The selected artifact is evaluated, not just the model family. Estimated load memory starts with the weight size and adds runtime overhead. Context length adds KV-cache and workspace memory. The calculator also preserves headroom for the operating system and other applications.
Discrete GPUs are evaluated against VRAM first, with system-RAM offload treated as a slower fallback. Apple Silicon is evaluated as unified memory after reserving memory for macOS. Multi-GPU capacity can be combined, but interconnect, runtime support, and model sharding still affect speed and usability.
A result marked runnable means the memory model is plausible under the selected assumptions. It does not guarantee a target token rate, latency, image size, or generation time.
Task fit and recommendation order
The two planners share the same underlying model library but answer different questions. Neither removes manual choice.
Task-first planner
Filters by task capability, then weighs model quality, specialization, generation freshness, artifact availability, memory fit, runtime support, and budget.
Hardware-first planner
Starts with effective RAM or VRAM, context target, GPU count, runtime constraints, and task support, then ranks the models that remain plausible.
Newer versions receive a preference when they are credible successors, but recency does not automatically beat task specialization, runtime maturity, stronger public evidence, or a better memory fit. A recommendation is a shortlist; the full list remains available so users can choose a different tradeoff.
Hardware prices and cost estimates
Hardware prices are approximate planning inputs, not live quotes. They may represent an official starting price, a representative configuration, or a recent retail observation. Region, tax, memory configuration, availability, and used-market conditions can materially change the final cost.
System RAM and supporting components are included where the selected hardware profile requires them. Long-term totals may include estimated electricity, but they do not include every ownership cost. Price is deliberately a secondary signal behind task fit, memory fit, and a workable software path.
From estimate to tested workflow
Structured reports record the hardware, operating system, tool and recipe version, execution mode, outcome, and whether the actual steps matched the documented steps. Reports do not automatically rewrite rankings. They are reviewed, aggregated, and used to correct assumptions or promote a workflow's evidence level.
Known limitations
- •Runtime versions, drivers, kernels, and model-conversion quality can change compatibility after a page is published.
- •Maximum advertised context is not the same as a practical context length on limited memory.
- •A model that loads may still be too slow, unstable, or low quality for a particular workload.
- •Benchmark scores from different harnesses, prompts, dates, or tool configurations are not directly interchangeable.
- •Unified memory, discrete VRAM, CPU offload, multi-GPU sharding, and networked inference have different performance costs.
- •Retail prices and availability vary by country, tax, memory option, seller, and used-market condition.
Check, challenge, and improve the result
Use the planners to narrow the search, follow a recipe when one exists, and report the actual outcome. For a wrong specification or recommendation, send the affected URL and the strongest source you have.