> ## Content Index
> Fetch the complete content index at: https://computefit.dev/llms.txt
> Use this file to discover other available public pages before exploring further.

# Ornith-1.5 for Local AI: What a New MoE Family Means When Your GPU Fits One Model but Not Two
- URL: https://computefit.dev/ornith-1-5-local-ai-24gb-moe-upgrade-decision/
- Published: 2026-08-23T08:59:57.000Z
- Updated: 2026-08-23T09:37:58.000Z
- Description: The new Ornith-1.5 open-weight family (35B-A3B MoE, 9B, MIT) fits inside one consumer GPU. What you should actually run on a 24 GB card, why its hybrid attention makes long context unusually cheap from the math, and when it replaces what you already host.
- Author: Alex Vale
- Tags: Local AI, Ornith, Ollama

## 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](https://computefit.dev/qwen3-8-27b-upgrade-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.

| File (vendor official repo)                                           | Download size            |
| --------------------------------------------------------------------- | ------------------------ |
| Ornith-1.5-35B-A3B full weights, bf16 safetensors (official download) | 71.90 GB / 66.97 GiB     |
| Q8\_0 GGUF                                                            | 37.80 GB / 35.21 GiB     |
| Q6\_K GGUF                                                            | 29.21 GB / 27.20 GiB     |
| Q5\_K\_M GGUF                                                         | 25.35 GB / 23.61 GiB     |
| **Q4\_K\_M GGUF (lowest published quant)**                            | **21.71 GB / 20.22 GiB** |
| Vision projector mmproj for 35B (separate file, bf16)                 | 0.90 GB / 0.84 GiB       |
| Ornith-1.5-9B Q4\_K\_M GGUF                                           | 5.63 GB / 5.24 GiB       |

Sizes are exact file bytes from the official Hugging Face repo index, converted deterministicly (GB = 109, GiB = 230). 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](https://computefit.dev/qwen3-8-27b-which-quant-fits-your-gpu/) 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](https://computefit.dev/runpod-vs-vast-ai-local-ai-cloud-gpu/), 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\]

| Context length              | KV cache (bf16-KV upper bound) |
| --------------------------- | ------------------------------ |
| 4,096 tokens                | ≈ 0.08 GiB                     |
| 32,768 tokens               | ≈ 0.63 GiB                     |
| 131,072 tokens              | ≈ 2.5 GiB                      |
| 262,144 tokens (native max) | ≈ 5.0 GiB                      |

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\]:

| Benchmark (harness)                                     | Ornith-1.5-35B-A3B                     | Nearest comparable row shown by the card                                                                                 |
| ------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| SWE-bench Verified (OpenHands, 256K)                    | 79                                     | Muse Glimmer-30B: 76; Qwen3.6-35B-A3B: 73.4                                                                              |
| SWE-bench Pro (OpenHands, 256K)                         | 59.6                                   | Muse Glimmer-30B: 51.2; Qwen3.6-35B-A3B: 49.5                                                                            |
| Terminal-Bench 2.1 (Terminus-2)                         | 67.8                                   | Muse Glimmer-30B: 51.7; Qwen3.6-35B-A3B: 52.5                                                                            |
| Toolathlon-Verified (official service, max 128K tokens) | 48.7                                   | Qwen3.6-A3B: 41.7; Gemma-4-31B: 40.8; Qwen3.5-397B reference row: 38.3 — Ornith leads all printed rows on this benchmark |
| MCP-Atlas (500 tasks, 10 min/task)                      | **70.2** *↓*                           | **Muse Glimmer-30B: 75.5; Qwen3.5-397B: 72.3 — both ahead of Ornith on this row**                                        |
| HLE, no tools (judge model named by vendor)             | 25.6 *↓*                               | Qwen3.5-397B: 28.7 — the big reference row wins                                                                          |
| GPQA Diamond                                            | 89.2 (highest of the six card columns) | Next-best on this sheet: Qwen3.5-397B at 88.4                                                                            |

↓ 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](https://computefit.dev/qwen3-8-27b-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](https://computefit.dev/runpod-vs-vast-ai-local-ai-cloud-gpu/), 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.