Ornith-1.5 for Local AI: What a New MoE Family Means When Your GPU Fits One Model but Not Two

The short answer

A new open-weight family called Ornith-1.5 landed on Hugging Face around August 18, 2026 [derived from official repo metadata], MIT-licensed [vendor model card tag and frontmatter], in three sizes: a 35B-A3B mixture-of-experts member (about 3B of its parameters active per token), a dense 9B, and a 397B that is not a local scenario. The vendor publishes official GGUF builds for the two small sizes, and Ollama’s library already lists them.

If your real question is “what should I actually run?”, here are the direct answers:

• A 24 GB card can host the 35B-A3B at its lowest official quant (Q4_K_M), but only barely, GPU-only. The weight file is a measured 20.2 GiB [measured — file size from the vendor’s official Hugging Face repo]; after that you have little room for context and runtime overhead before the runtime starts offloading to system RAM. It runs; it just sits at the edge of your card.
• A 32 GB+ card (or a Mac with comparable unified memory) is where this model actually gets comfortable, because its hybrid attention layout makes long context unusually cheap in bytes (worked out in section 4 from the public config file).
• Under ~16 GB of usable space, use the 9B member. The official quants for the 35B stop at Q4_K_M — anything smaller means leaving the vendor’s published repository [measured — file listing], which this article does not vouch for. The 9B’s Q4_K_M is a measured 5.2 GiB download.
• If you already run a comfortable dense model (Qwen-class 27B, Muse Glimmer-30B), do not switch purely because this one exists. The benchmark table below includes rows where Ornith loses to existing models; treat every number as vendor-reported until independent reproduction appears. Decide by your own workload, following the same rules as in our Qwen 3.8 upgrade decision guide.

1. What Ornith-1.5 actually is (confirmed facts)

From the official model cards and the config files we read directly:

• Provenance. It extends an Ornith-1.0 line that was developed on top of Qwen3.5 and Gemma 4 with continued pretraining, then trained further in a self-improvement reinforcement loop [vendor narrative — the lineage claim is theirs; the config architecture fields below are what we verified].
• Architecture. The 35B-A3B is an MoE built on a Qwen3.5-generation multimodal base: 256 experts with 8 activated per token, 40 layers in which only one layer in four uses full attention and the other thirty use linear (recurrent) attention [measured — config.json]. That hybrid layout is not cosmetic; it drives the context math in section 4.
• Context. 262,144 tokens natively for both small members [measured — max_position_embeddings in config]. Extending toward ~1M requires explicitly enabling YaRN RoPE scaling (the vendor validates factor 4.0) and is an advanced configuration act with a known quality caveat on shorter inputs — see section 6.
• Multimodal + agentic. Both small members ship vision projectors (mmproj files in the official GGUF repos [measured]) and tool calling surfaced as OpenAI-style tool_calls; it is a reasoning model with thinking on by default [vendor quickstart]. Ollama’s catalog marks 35b with chips for vision, tools, and thinking [Ollama official listing].
• License. MIT per the card tag and license link [vendor self-declared — note the API-level license field of the base repos is left unset by the uploader, so we are relying on the two consistent declarative markers, not a legal audit].

2. What actually exists to download (official files only)

Every byte count below was read from the file index of the vendor’s own Hugging Face repositories; none is measured VRAM occupancy.

Sizes are exact file bytes from the official Hugging Face repo index, converted deterministicly (GB = 10⁹, GiB = 2³⁰). The full weight parameter total is 35,951,822,704 [measured — HF API and the safetensors index agree]; dividing the 71.9 GB download by two bytes per parameter reproduces it exactly, consistent with a bf16-class checkpoint [derived].

Ollama’s one-click tags are different files. The official Ollama library lists ornith-1.5:35b as a 23 GB build and ornith-1.5:9b as 6.6 GB, both with 256K context [Ollama catalog]. Those are catalog statements; which exact quantization each tag wraps was not byte-verifiable from the sources we checked, so do not treat “the Ollama 35b tag” and “the 21.71 GB Q4_K_M file” as identical objects even though the sizes are close [boundary: catalog statement vs measured HF file].

For Apple Silicon, the vendor also publishes official MLX builds (e.g., a =Ornith-1.5-35B-A3B-MLX-4bit repository exists on Hugging Face [existence verified; we did not audit its file sizes here]).

3. Fit: which member, at what size, on your hardware

Rules of thumb before the cards, same boundaries as always:

• File size ≠ VRAM residency. A 20.2 GiB weight file means roughly 20.2 GiB+ of resident weights once loaded (plus attention/KV state, activations, framework overhead). Treat the table below as a class estimate from measured sizes, not a measurement [derived].
• The vision projector counts too. The mmproj is a separate ~0.84 GiB-class file. Its exact runtime VRAM cost when you feed it images was not measured — we hold it as an additional class-level allowance, never fold it into a hard number [boundary].
• No sub-Q4 official option exists for 35B. The published ladder starts at Q4_K_M. Below that = community quantizers of unverified provenance and quality — a different risk class than the vendor files above.

Your card is ~24 GB (e.g., RTX 3090/4090-class):

• ollama run ornith-1.5:35b is the low-friction route — it should host comfortably enough to use (provided that tag’s build falls in the Q4 class, which we could not verify; see section 2), but expect a context window that stays conservatively moderate if you want everything on one GPU, and expect some offload-to-RAM behavior as context grows.
• If your card has a history of sitting at its edge (see our Qwen quant fit piece for the same reasoning applied to dense models), check that system RAM can absorb offloaded KV before committing — a slow but working 24 GB setup is still useful, a thrashing one is not.
• You should plan around staying local here. The model’s own design (3B active per token) exists to make the big total parameter count cheap at inference even when it all has to reside in combined device memory [inference about design intent from config + vendor framing; not a speed measurement — this article cites no tok/s numbers we did not measure].

Your card is 32 GB+: Q5_K_M (23.6 GiB file) or even the 9B-at-Q8 territory gets comfortable, and because KV growth here is suppressed (next section), you can carry a genuinely long context without the usual “context eats my whole card” collapse.

Your usable space is under ~16 GB: run ornith-1.5:9b. 5.2 GiB of weights leaves real room for context and overhead at Q4 class, versus a zero-survival margin on any official 35B build.

Your target does not fit local hardware at all (e.g., you want the full-precision or 397B behavior): that is the temporary-cloud decision — covered in detail in our RunPod vs Vast.ai overflow guide, since this article deliberately does not duplicate it.

4. Why long context costs less here (real config, simple arithmetic)

In a plain dense transformer, the KV cache grows with every single layer and token — which is why 27B dense models starve by 3C–64K context on a 24 GB card. Ornith-1.5’s config changes that story structurally, and we can verify it from the public files rather than trust marketing:

• layer_types: of the 40 layers, only 10 use full attention, every fourth layer; the other 30 are linear-attention layers whose state does not grow with sequence length [measured — config.json].
• The full-attention layers run at an unusually tiny KV footprint: num_key_value_heads=2 and head_dim=256. With bf16 storage (an upper bound assumption) that is 2 × 2 heads × 256 dim × 2 bytes = 2,048 bytes per token per full-attention layer, so for all ten combined: [derived]

Pure arithmetic from config values: 10 full-attention layers × 2,048 B/token/layer × tokens. The actual runtime figure depends on KV dtype (many runtimes store Q8_0 or similar by default and would be about half this) plus framework overheads we did not measure.

The honest read: 5 GiB of KV at the full 262K window is small enough that “fits a long context” stops being a marketing sentence and becomes arithmetic you can check against your own card. But — vendor framing, not our measurement — linear-attention layers each carry their own fixed recurrent state (the config lists an fp32 mamba_ssm_dtype for those states [measured field name only]); we did not size it and no source we checked priced it. So the total still exceeds the weight-size alone by a margin you should verify on your own machine, budget-wise.

5. Benchmarks: vendor-reported, with its loss rows included

Reading rules first:

1. Every number below is self-reported in the official model card, averaged over five runs per its footnotes. We did not run any of them.
2. The vendor’s harness notes are unusually concrete (Terminus-2/Claude Code scaffolds for Terminal-Bench 2.1; OpenHands with git history stripped and network disabled for SWE-bench rows; external judge models named by version for HLE and MCP-Atlas) [vendor-described methodology]. That is more transparency than average, but still a party to its own scores.
3. Independent reproduction, in the trackers we actually checked as of writing: thinly covered. “Exists”, not “settle.”

Selected rows against peers printed on the vendor sheet [vendor]:

↓ marks rows where a printed peer outperforms Ornith-1.5 on the vendor’s own sheet — kept deliberately so the table can be read without being curated to flatter the subject.

The pattern to take away is narrow but real within this one vendor sheet: Ornith claims clear wins over same-size dense/MoE rivals (Qwen3.6-A3B, Gemma-4), sits near or below its own Qwen-class 397B reference on reasoning-heavy rows, and loses to Muse Glimmer-30B on MCP-Atlas per the sheet itself — even though the card’s summary text says it beats dense models like Muse by wide margins. The summary sentence is contradicted by the vendor’s own table in at least one row [observed contradiction against both vendor products]; when a marketing line and data rows disagree, run your own workload test — that has always been the rule with new releases.

6. Caveats before you act

• Freshness is extreme. Releases are roughly 5 days old [derived from repo timestamps]. Expect runtime support churn, early GGUF naming quirks, and possible re-tuned quants in coming weeks; pin what works once you find it.
• yarn scaling is opt-in and static. Enabling rope_scaling (YaRN) toward ~1M tokens applies the same factor to every prompt — including short chat messages, which may take a small quality hit [vendor caution]. If your prompts top out around 524K, the vendor’s own math says factor 2.0 is the better setting than 4.0.
• Version floors are stated for full-precision serving only: Transformers ≥ 5.8.1, vLLM ≥ 0.19.1, SGLang ≥ 0.5.9 [vendor quickstart]. The GGUF/Ollama/llama.cpp path is unversioned by the vendor — old runtimes just won’t load a new hybrid-attention architecture. If your Ollama build predates this model, update it before blaming the quant.
• No speed numbers here on purpose. We found tok/s claims in aggregators and community posts; none were backed by reproducible primary evidence we could cite, so none appear in this article [intentional exclusion — see the source-boundary rule].

Versions of the decision

• Run it today (≥ 24 GB card or Mac): ollama run ornith-1.5:35b, keep context conservative on first passes, watch your effective tok/s and offload behavior with your workload before committing anything production.
• You want headroom or big context: wait until the card is 32 GB+ (or a Mac at that class, where the vendor MLX quants apply) — then Q5-class + long context actually adds up [derived fit math above].
• Under ~16 GB: ornith-1.5:9b, no compromises required.
• You already have a dense model you trust on your real tasks: keep it. Do the switch decision exactly as we did for Qwen 3.8 — by workload A/B, not benchmark screenshots (“upgrade guide”), especially since every number in section 5 is vendor-derived until reproduced independent of the vendor.
• The use case demands more than any local card: that’s overflow-rental territory — see our RunPod vs Vast.ai guide, not this one.

Bottom line

Ornith-1.5 is one of the clearest examples of “35B on a consumer card” being arithmetic rather than marketing prose: measured weight files, a hybrid-attention config that makes long context cheap in bytes you can recompute yourself, MIT license, official GGUFs and an Ollama listing. What it is not, five days after release, is an independent verification event — its benchmark sheet includes rows where it loses to models many readers already run, and every number is the vendor’s until someone re-runs it. Test on your own tasks before you replace what works.