About This Site
Local Model Watch is a reference site, in English and Japanese, for open-weight generative models — text, image, video and audio — that you can run on your own PC or server. It helps you find out what has been released, how much GPU memory it needs, what to run it with, and what actually happens when you run it.
Alongside articles on new releases, the site offers hub pages that cut across all of our coverage, and measurements we take ourselves by actually running models.
- Articles: new models and inference-engine updates, always with
sources. Every model article includes a memory-requirement table computed from the actual size of the distributed files, and GGUF and other converted builds released later are appended to it. - Hub pages: browse the models and tools we have covered by VRAM, model family,
publisher, model format, task and inference engine. - Our own measurements: we read tokenizers and GGUF files ourselves, and run small
models on our own CPU-only server, publishing the numbers and the answers verbatim.
How it’s run
Local Model Watch uses AI agents and code to automate collecting and organizing information, writing articles, updating the hub pages and taking measurements.
The operator (an individual) designs and maintains the automation itself, the sources we follow, the publication criteria, how articles are structured, how measurements are taken, and how corrections are handled. Since October 6, 2026, every new article is drafted by AI and then checked by the operator against its sources before publication; only articles the operator approves are published (earlier articles were reviewed after publication; the scope of the review is described in our editorial policy).
The one exception is the “Hands-on Reports" category: those articles are written by the operator after actually running the model on their own machine (not written by AI; their English versions are translated with AI). Each of them says so at the top.
What we cover
We track inference engines, quantization and fine-tuning tools, as well as new releases and updates for models that generate text, images, video or audio. Models that don’t generate anything — embeddings, classifiers and the like — are out of scope.
Announcements from companies and research labs (funding, partnerships, data-center products and so on) that have nothing to do with running models on your own hardware do not get articles of their own; the weekly roundup summarizes them briefly under “Industry News".
Our sources
We follow announcements from well-known projects and organizations (major inference engines and model publishers), as well as topics that clearly show a spike in attention on developer communities such as Hacker News and Bluesky.
Publication criteria
Wherever possible, articles cite official announcements and primary sources. We never publish an article that has no source links. How articles are produced, how figures are computed and how corrections are handled is described in our Editorial Policy.
Our own measurements
All results and our methods are on Our Measurements.
- Japanese token efficiency: we count a fixed Japanese text written by this site
with the tokenizer of each model we cover. - GGUF internals: we read the header of GGUF files to check per-layer quantization
types, whether an imatrix was used, and the chat template. - CPU runs: small models are run with llama.cpp on our own CPU-only server; we
publish their speed, memory use and verbatim answers to the same five Japanese questions. - Our CPU picks: from the models we ran on the CPU, we pick one per purpose based on
a score computed by code from the questions with a single correct answer, Japanese generation speed, memory use and license. - Decision models: models that return a probability for each option instead of writing text
get the same decision tasks we wrote (yes/no, options and levels) in Japanese and in English; code counts the correct answers and the time per decision. Models that llama.cpp can run go through its/v1/systemoneendpoint; for models whose decision part llama.cpp cannot run, we run the publisher’s own code on a rented cloud GPU inside a container with its network cut off, and publish the steps. - Quantization loss: for each quantization of a model, we measure how far it drifts
from the reference precision on a fixed Japanese text. - GGUF conversion: when no GGUF release exists, we convert the model ourselves and
publish the exact commands we ran. - Image generation: for image models whose license allows publishing the output,
we publish images generated on our server from fixed prompts, without picking or editing them. - Speech generation: on the same terms, text-to-speech models read out fixed sentences
we wrote, and we publish the audio without picking or editing it. We use no reference audio (no one’s voice is imitated), and the publisher’s inference code runs on our server in an isolated environment, with generation done offline. - Video generation: on the same license terms (for derived models we check every model they
were built from), we publish video generated from our fixed prompts without picking clips. Our server cannot run these models, so we rent a cloud GPU and generate inside a container with its network cut off, using only public libraries. The articles include the setup and run steps. - llama.cpp speed by version: whenever llama.cpp ships a new version, we run the same small
model on our CPU and show how the speed changed between versions on the llama.cpp page and in that version’s article. - Inference engine comparisons: when a new inference engine claims to be faster than llama.cpp,
we run it on our CPU with the same model file as llama.cpp and publish the speeds together with the exact steps we ran. The publisher’s prebuilt binaries run on our server in an isolated environment with no network access. - Observation logs: how long it takes for a GGUF build to appear after a model is
released, how many days it takes for a new architecture to be registered in the inference engines, and how often each engine ships releases.
We only run models whose license permits commercial use. CPU figures always come with the CPU name, thread count, llama.cpp version and quantization — they are not a guide to GPU speed.
Hub pages
- Local Models by VRAM quick reference: every model we
have covered, grouped by the smallest VRAM tier it is estimated to run in. - Model family pages: one page per model series gathering our
articles, tracked variants and hardware requirements, with an explanation of what the model is and what it does well. - Publishers: for each company and lab, the models it has
released on Hugging Face alongside our articles. - Model formats: what GGUF, MLX, FP8 and other formats are, and
which models are available in each. - Models by task: the models we have covered, grouped by task —
image, audio, video and text. - Engines and tools release tracker: for llama.cpp, Ollama,
vLLM and the other projects we watch, the full release history alongside our articles — including the smaller releases that do not get an article of their own. - Trending models we’ve covered: likes and downloads of the
models we have written about, recorded every week. - Glossaries: how to read benchmark scores and
quantization and model formats — the same definitions our writing pipeline works from.
Tables in our articles
- Hardware requirement tables: each model article includes memory
requirements and GPU tiers computed by this site from the actual size of the distributed files — not figures quoted from the model card. - Variant tracking: GGUF, MLX and other converted builds released after our
original article are appended to that article. - “Recent models in the same size class": each new-model article lists recently
covered models with a similar parameter count for comparison. - “This Week in Numbers" in every weekly roundup, computed from the week’s
articles.
Services we use
To choose which model our writing agents themselves use, we refer to model performance data published by Artificial Analysis. This data is only used behind the scenes for that selection and is never included in article content.
When we get something wrong
If an article turns out to be wrong, we do not delete it. We add a correction notice at the top of the article and update it so that what was wrong and what was corrected both stay visible. See our Editorial Policy for more.
Modified dates and update history
When we change an article after publication (adding converted or quantized builds, rewriting the text, changing its category, verifying it against a primary source, issuing a correction, or adding our own measurements), an “Update History" section at the end of the article records what changed and when. It is generated automatically by our code.
Sections that are rebuilt whenever new articles are published, such as “Related Articles" and “Other Models in the Same Class", are not recorded there. The modified date shown on an article can move because of those sections alone, so if the update history has no entry, the article text itself has not changed.
Get in touch
If you have feedback or a correction to report, please let us know via the contact page.