offmonreal/Ornith-1.5-35B-MaxQuality-MTP-GGUF

Ornith-1.5-35B MaxQuality MTP GGUF

⚡ Speed at a glance (10K context)

Variant	Generation speed	Behavior past 10K context
MTP (draft-mtp, n-max 2), Q4_K_M	~60 tok/s	Holds up — draft head keeps working with a longer context window
No MTP, Q4_K_M	~60 tok/s	Degrades as context grows — same starting speed, worse ending speed
MTP (draft-mtp, n-max 2), Q3_K_M	~85 tok/s	10 expert layers on CPU (blk.30-blk.39)
Q2-Quality MTP, AllGPU	~145 tok/s	Whole model + MTP head resident in VRAM, zero CPU offload — see Ornith-1.5-35B_Q2_K-AllGPU.gguf below

Both start at roughly the same speed at 10K tokens. The difference shows up as the conversation gets longer: the no-MTP file's throughput falls off with context, while the MTP file does not degrade the same way. If you only ever send short prompts the two are a wash; for anything that grows past 10K tokens, the MTP file is the better bet.

Tested hardware and software

• Linux
• NVIDIA GeForce RTX 5060 Ti, 16 GB VRAM
• AMD Ryzen 9 5950X, 16 cores / 32 threads
• 64 GB system RAM
• TheTom/llama-cpp-turboquant, commit c26cbdffc

About this release: donor head, not the native one

Ornith-1.5 ships its own trained Multi-Token Prediction layer (mtp_num_hidden_layers: 1 in the upstream config, real weights present — unlike Ornith-1.0, which shipped without one). We tested it directly and it was a genuine disappointment: at a realistic CPU-offload configuration, the native head's draft-acceptance rate came in around 34-41%, versus 57-61% for the donor head we already use on our Ornith-1.0 and KAT-Coder MTP releases (extracted from the base Qwen/Qwen3.6-35B-A3B, same architecture family). Quantizing the native head at higher precision (Q8_0, Q6_K) didn't close the gap — the acceptance shortfall is about the head itself, not its numeric precision. So this file grafts in the same external donor head as our other MTP releases, not Ornith-1.5's own.

The donor head is itself quantized to Q4_K — sweeping Q8_0 → Q6_K → Q4_K → Q2_K showed no meaningful acceptance-rate difference until Q2_K, so Q4_K was the size/quality sweet spot (520 MiB vs. 857 MiB at Q8_0, same measured acceptance).

Files

File	Size	BPW	Recipe
Ornith-1.5-35B_Q4_K_M_imatrix_MTP.gguf	20.22 GiB	4.92 (trunk)	Plain Q4_K_M trunk + iMatrix, no manual overrides; donor MTP head at Q4_K
Ornith-1.5-35B_Q3_K_M.gguf	16.43 GiB	3.98 (trunk)	Plain Q3_K_M trunk + iMatrix, no manual overrides; donor MTP head at Q3_K
Ornith-1.5-35B_Q2_K-AllGPU.gguf	12.62 GiB	~3.0 (trunk)	Q2v2 lean trunk (routed-expert gate/up at Q2_K, down bumped to Q3_K, embeddings/output at Q5_K, attention at Q4_K); donor MTP head at Q3_K — whole file, head included, fits a 16 GB card with zero CPU offload

Calibrated with the same iMatrix pipeline as our other releases (calibration_datav5.txt, 802 chunks).

We swept the donor head at Q4_K/Q3_K/Q2_K on this same Q2v2 AllGPU trunk, at --spec-draft-n-max 2 through 4, including a realistic ~112K-token real-source-code prompt (not just short synthetic text) to check whether a deeper draft window becomes favorable at large context. It doesn't: n-max 2 stayed the fastest at every context length and every head precision tested, and Q3_K/Q4_K heads performed identically (Q2_K measurably worse) — so Q3_K was picked for this file as the smaller of the two equivalent options.

MTP quantization and a quantizer bug workaround

Ornith-1.5's own MTP layer can't be quantized together with the rest of the model through the normal --imatrix path — the calibration forward pass never exercises the MTP layer, so llama-imatrix collects zero data for it, and this TurboQuant build's quantizer crashes on that layer specifically for MoE+nextn architectures (Bad layer 40 for tensor blk.40.ffn_down_exps.weight. Must be in [0, 40); the same operation is fine on dense nextn models). Worked around with --prune-layers 40 to quantize the 40-layer trunk cleanly, then grafted the (donor) MTP block back on afterward at its own precision — same technique as our Ornith-1.0/KAT-Coder MTP releases, just with the donor block itself independently requantized through a real K-quant pass (not just copied byte-for-byte) to hit Q4_K.

Recommended launch commands

MTP — holds speed across longer context

llama-server \
  --jinja --host 0.0.0.0 --port 8080 \
  -m Ornith-1.5-35B_Q4_K_M_imatrix_MTP.gguf \
  --spec-type draft-mtp --spec-draft-n-max 2 \
  --n-gpu-layers 99 --n-cpu-moe 0 \
  -ot "blk\.(2[2-9]|3[0-9])\.ffn_.*_exps\.weight=CPU" \
  --ctx-size 200144 --parallel 1 \
  --flash-attn on \
  --cache-type-k turbo3 --cache-type-v turbo3 \
  --batch-size 262144 --ubatch-size 1024 --cache-reuse 256

--spec-draft-n-max 2 is the measured optimum for this file — we swept 2 through 6 and acceptance/speed both fall off monotonically past 2, so don't reach for a bigger draft window expecting more free speed.

No MTP — same file, head simply unused

llama-server \
  --jinja --host 0.0.0.0 --port 8080 \
  -m Ornith-1.5-35B_Q4_K_M_imatrix_MTP.gguf \
  --n-gpu-layers 99 --n-cpu-moe 0 \
  -ot "blk\.(2[4-9]|3[0-9])\.ffn_.*_exps\.weight=CPU" \
  --ctx-size 200144 --parallel 1 \
  --flash-attn on \
  --cache-type-k turbo3 --cache-type-v turbo3 \
  --batch-size 262144 --ubatch-size 1024 --cache-reuse 256

Same starting speed at 10K context, but expect it to degrade as the conversation grows — the MTP file above does not show the same falloff.

Q3 MTP — 10 expert layers on CPU

llama-server \
  --jinja --host 0.0.0.0 --port 8080 \
  -m Ornith-1.5-35B_Q3_K_M.gguf \
  --spec-type draft-mtp --spec-draft-n-max 2 \
  --n-gpu-layers 99 --n-cpu-moe 0 \
  -ot "blk\.(3[0-9])\.ffn_.*_exps\.weight=CPU" \
  --ctx-size 131072 --parallel 1 \
  --flash-attn on \
  --cache-type-k turbo3 --cache-type-v turbo3 \
  --batch-size 32768 --ubatch-size 1024 --cache-reuse 256

Measured ~85 tok/s at 10K context. Lighter trunk than the Q4 file, so only the last 10 expert layers (blk.30-blk.39) need to go to CPU instead of 16-18.

Q2-Quality MTP — AllGPU, no CPU offload

llama-server \
  --jinja --host 0.0.0.0 --port 8080 \
  -m Ornith-1.5-35B_Q2_K-AllGPU.gguf \
  --spec-type draft-mtp --spec-draft-n-max 2 \
  --n-gpu-layers 99 --n-cpu-moe 0 \
  --ctx-size 131072 --parallel 1 \
  --flash-attn on \
  --cache-type-k turbo3 --cache-type-v turbo3 \
  --batch-size 32768 --ubatch-size 2048 --cache-reuse 256

No -ot line — the whole model plus MTP head fits resident in 16 GB VRAM. Measured ~145 tok/s at 10K context.

Licensing note: donor MTP head is Apache-2.0, not MIT

The MTP draft head grafted into every file in this repo (see "About this release" above) is extracted verbatim, unmodified, from Qwen/Qwen3.6-35B-A3B, which is released under the Apache License 2.0 — not the MIT license that covers the rest of this repo and the upstream Ornith-1.5 weights. That Apache-2.0 term applies specifically to the donor tensors in the final transformer block of each file (the nextn/MTP layer, a few hundred MiB to under 1 GiB depending on the file); every other tensor here is Ornith-1.5, under the MIT license declared at the top of this card. Full Apache-2.0 text: https://www.apache.org/licenses/LICENSE-2.0. Attribution: MTP head © Qwen Team, Alibaba Cloud, from https://huggingface.co/Qwen/Qwen3.6-35B-A3B.

Upstream model card

This release is based on the original Ornith-1.5-35B-A3B model card reproduced in full below. The upstream repository declares an MIT license in its model card but does not ship a separate LICENSE file at the time of this release; we have not fabricated one.

Ornith-1.5-35B-A3B

Chirp Chirp! 🐦 We are introducing Ornith-1.5, a major step toward building foundation models through end-to-end self-improvement.

Ornith-1.5 extends Ornith-1.0 (which was developed on top of Qwen3.5 and Gemma4 with additional continued pretraining, mid-training, and post-training) by expanding the self-improvement loop from scaffold and rollout optimization to jointly optimizing task generation, scaffold construction, and solution rollouts. Rather than relying on a fixed set of human-curated tasks and manually designed harnesses, Ornith-1.5 continuously generates new training tasks, discovers effective strategies for solving them, and improves the policy through reinforcement learning. For more details on the task, harness, and rollout reward design, please refer to our blog.

Ornith 1.5 35B-A3B

This model card documents Ornith-1.5-35B-A3B, the mid-size mixture-of-experts member of the Ornith-1.5 family. It activates only ~3B parameters per token, yet significantly outperforms its similar-sized peer Qwen 3.6-35B across all coding and agentic benchmarks, and outperforms dense models such as Gemma 4-31B and Muse Glimmer-30B by wide margins on agentic coding.

Benchmarks

	Ornith-1.5-35B-A3B	Ornith-1.0-35B-A3B	Qwen3.6-35B-A3B	Gemma-4-31B	Muse-Glimmer-30B	Qwen3.5-397B
Coding
Terminal-Bench 2.1 (Terminus-2)	67.8	64.2	52.5	42.1	51.7	53.5
Terminal-Bench 2.1 (Claude Code)	68.5	62.8	49.2	-	-	48.6
SWE-bench Verified	79	75.6	73.4	52	76	76.4
SWE-bench Pro	59.6	50.4	49.5	35.7	51.2	51.6
SWE-bench Multilingual	71.4	69.3	67.2	51.7	-	69.3
DeepSWE	22	0	0	-	-	1
Frontier-Bench v0.1	5.1	1.4	1.4	-	-	1.4
NL2Repo	46.2	34.6	29.4	15.5	-	36.8
SWE Atlas - QnA	39.8	37.1	15.5	-	-	20.4
Reasoning
HLE (no tools)	25.6	20.8	21.4	19.5	22	28.7
HLE (with tools)	33.4	30.1	28.9	26.5	-	48.3
GPQA Diamond	89.2	86.2	86	84.3	83.5	88.4
Agentic
MCP-Atlas	70.2	64.4	62.8	55	75.5	72.3
Toolathlon-Verified	48.7	42.4	41.7	40.8	-	38.3
WideSearch	67.8	63.4	60.1	54.2	-	74
BrowseComp	67.6	63.5	62	-	-	78.6
ClawEval	72.5	69.8	68.7	48.5	-	70.7

* All results reported for Ornith-1.5 are averaged over five independent runs.
* Terminal-Bench 2.1 (Terminus-2): We evaluate Terminal-Bench 2.1 using the Harbor/Terminus-2 framework with parser=json, temperature=1.0, top_p=1.0, and a 128K context window. Each run uses a 4-hour timeout with 32 CPU cores and 48GB RAM, and results are averaged over 5 runs. We adjust the Qwen chat template to ensure consistency between training and inference (https://huggingface.co/ornith-ai/Ornith-1.5-35B-A3B/blob/main/chat_template.jinja), and modify Harbor to align with vLLM's reasoning_content key.
* Terminal-Bench 2.1 (Claude Code): We evaluate Terminal-Bench 2.1 using Claude Code 2.1.126 with parser=json, temperature=1.0, top_p=1.0, max_new_tokens=131072. Results are averaged over 5 runs. Again, Qwen chat template needs to be modified.
* SWE-Bench Verified, Pro and Multilingual: using OpenHands harness with temp=1.0, top_p=0.95, 256k context window. Anti-hacking safeguards are applied throughout evaluation: Git history is removed from the local repository image to prevent access to prior solutions or commits; network access is disabled, preventing the model from retrieving external information or resources.
* DeepSWE: Evaluated using the Claude Code harness with temperature=1.0, top_p=0.95, and a 256K context window.
* SWE Atlas QnA: using mini SWE agent harness with temp=1.0, top_p=0.95, 128K context window. Results are averaged over 5 runs.
* NL2Repo: with temperature=1.0, top_p=1.0, 400K context, 48K output. Access to specified GitHub repositories and pip packages is blocked to prevent reward hacking.
* HLE: Evaluated using Claude 4.6 Opus as the judge model.
* MCP-Atlas: All models were evaluated in thinking mode on the 500-task public subset, with a 10-minute timeout per task. We use Claude 4.8 Opus as the judge model.
* Toolathlon-Verified: We use the official evaluation service with the maximum token limit set to 128K.
* ClawEval: An agentic code benchmark over real-user task distributions; temp=0.6 and 256K context.

Quickstart

📝 NOTE

Ornith-1.5-35B-A3B is a reasoning model: by default the assistant turn opens with a <think> … </think> block before the final answer. The serving recipes below enable a reasoning parser so the chain-of-thought is returned in a separate reasoning_content field, and a tool-call parser so the model's <tool_call> blocks are surfaced as OpenAI-style tool_calls.

Serving Ornith-1.5-35B-A3B requires recent runtimes:

• Transformers ≥ 5.8.1
• vLLM ≥ 0.19.1
• SGLang ≥ 0.5.9

Recommended sampling parameters:

• For general tasks: temperature=0.6, top_p=0.95, top_k=20
• To reproduce the reported benchmarks: temperature=1.0

Serving Ornith-1.5-35B-A3B

Ornith-1.5-35B-A3B is a ~35B mixture-of-experts model with ~3B activated parameters per token (≈70 GB in bf16). The recipes below stand up an OpenAI-compatible server on 2× 80GB GPUs to leave headroom for the 256K context; adjust --tensor-parallel-size / --tp to match your hardware.

vLLM

vllm serve ornith-ai/Ornith-1.5-35B-A3B \
    --served-model-name Ornith-1.5-35B-A3B \
    --host 0.0.0.0 --port 8000 \
    --tensor-parallel-size 2 \
    --max-model-len 262144 \
    --gpu-memory-utilization 0.90 \
    --enable-prefix-caching \
    --enable-auto-tool-choice --tool-call-parser qwen3_xml \
    --reasoning-parser qwen3 \
    --trust-remote-code

SGLang

python -m sglang.launch_server \
    --model-path ornith-ai/Ornith-1.5-35B-A3B \
    --served-model-name Ornith-1.5-35B-A3B \
    --host 0.0.0.0 --port 8000 \
    --tp 2 \
    --context-length 262144 \
    --mem-fraction-static 0.85 \
    --tool-call-parser qwen3_coder \
    --reasoning-parser qwen3

For Long-Context

Ornith-1.5-35B-A3B handles context windows of up to 262,144 tokens. When a task's combined input and output must go beyond this limit, we suggest extending the effective window with RoPE scaling — YaRN is the technique we validate against, and it is already built into both vLLM and SGLang. With a scaling factor of 4.0, the usable window grows to roughly 1M tokens.

You can turn YaRN on in either of two ways:

• Edit the checkpoint's config.json. Add a rope_scaling block to the model configuration:

  {
      "rope_scaling": {
          "rope_type": "yarn",
          "factor": 4.0,
          "original_max_position_embeddings": 262144
      }
  }
  

• Override at launch time. Leave the checkpoint untouched and extend the serve commands above with the equivalent flags.

  vLLM:

  VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 vllm serve ornith-ai/Ornith-1.5-35B-A3B ... --hf-overrides '{"rope_scaling": {"rope_type": "yarn", "factor": 4.0, "original_max_position_embeddings": 262144}}' --max-model-len 1000000
  

  SGLang:

  SGLANG_ALLOW_OVERWRITE_LONGER_CONTEXT_LEN=1 python -m sglang.launch_server ... --json-model-override-args '{"rope_scaling": {"rope_type": "yarn", "factor": 4.0, "original_max_position_embeddings": 262144}}' --context-length 1000000
  

📝 NOTE

Open-source runtimes implement YaRN statically: the same scaling factor is applied to every request regardless of its length, which can slightly hurt quality on ordinary-length inputs. Only enable rope_scaling when your workload genuinely needs the longer window, and size factor to match it — the target window is roughly factor × 262,144, so if your requests top out around 524,288 tokens, factor: 2.0 is the better setting.

Using Ornith-1.5-35B-A3B via the Chat Completions API

Once a vLLM or SGLang server is running, talk to it with any OpenAI-compatible client.

Basic Usage

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",  # any non-empty string works for a local server
)

response = client.chat.completions.create(
    model="Ornith-1.5-35B-A3B",
    messages=[
        {"role": "user", "content": "Write a one-line Python lambda that squares a number."}
    ],
    temperature=0.6,
    top_p=0.95,
    max_tokens=1024,
)

message = response.choices[0].message
# reasoning_content holds the <think> trace; content holds the final answer.
print("reasoning:", getattr(message, "reasoning_content", None))
print("answer:", message.content)

You can also stream tokens, or hand the model tools — Ornith-1.5-35B-A3B emits well-formed function calls that the server parses into the standard tool_calls field:

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get the current weather for a city",
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
            },
        },
    }
]

response = client.chat.completions.create(
    model="Ornith-1.5-35B-A3B",
    messages=[{"role": "user", "content": "What is the weather in Paris right now?"}],
    tools=tools,
    tool_choice="auto",
    temperature=0.6,
    max_tokens=2048,
)

tool_call = response.choices[0].message.tool_calls[0]
print(tool_call.function.name, tool_call.function.arguments)
# -> get_weather {"city": "Paris"}

You can point any OpenAI-compatible SDK (Python, Node.js, etc.) or curl at the same /v1/chat/completions endpoint.

Agentic Usage

Ornith-1.5-35B-A3B excels in tool-calling and agentic coding. It exposes an OpenAI-compatible endpoint with tool calling and works out of the box with standard agent frameworks.

Examples of using Ornith with agents:

Ollama

ollama run hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF

Atomic.chat

# Atomic.chat loads a GGUF build of Ornith (ornith-ai/Ornith-1.5-35B-A3B-GGUF)
# through llama.cpp's OpenAI-compatible API on port 8000.
llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF --port 8000 -c 262144

llama.cpp

# llama.cpp — serve an OpenAI-compatible API on port 8000.
llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF --port 8000 -c 262144

Hermes Agent

# Hermes talks to any OpenAI-compatible endpoint — point it at your Ornith server.
export OPENAI_BASE_URL="http://localhost:8000/v1"
export OPENAI_API_KEY="EMPTY"
export MODEL="ornith-ai/Ornith-1.5-35B-A3B"

OpenClaw

# OpenClaw talks to any OpenAI-compatible endpoint — point it at your Ornith server.
export OPENAI_BASE_URL="http://localhost:8000/v1"
export OPENAI_API_KEY="EMPTY"
export OPENAI_MODEL="ornith-ai/Ornith-1.5-35B-A3B"

Unsloth Studio

pip install unsloth

# Load Ornith for fast local inference or fine-tuning (Python):
#   from unsloth import FastLanguageModel
#   model, tokenizer = FastLanguageModel.from_pretrained(
#       "ornith-ai/Ornith-1.5-35B-A3B",
#       max_seq_length=262144,
#       load_in_4bit=True,
#   )

Coding CLIs

Ornith-1.5-35B-A3B is optimized for terminal-based coding agents. Point any OpenAI-compatible coding CLI at your Ornith-1.5-35B-A3B endpoint (set OPENAI_BASE_URL and OPENAI_API_KEY) to understand large codebases, automate tedious work, and ship faster.

OpenCode

# Register your local Ornith endpoint as a provider in ~/.config/opencode/opencode.json:
#
# {
#   "$schema": "https://opencode.ai/config.json",
#   "provider": {
#     "ornith": {
#       "npm": "@ai-sdk/openai-compatible",
#       "name": "Ornith (local)",
#       "options": { "baseURL": "http://localhost:8000/v1", "apiKey": "EMPTY" },
#       "models": { "ornith-ai/Ornith-1.5-35B-A3B": { "name": "Ornith-1.5-35B-A3B" } }
#     }
#   }
# }

opencode

Citation

If you find our work helpful, feel free to give us a cite.

@misc{ornith_1_5,
    title = {{Ornith-1.5}: From Self-Scaffolding to Self-Improvement},
    url = {https://ornith.ai/ornith_1_5.html},
    author = {{Ornith Team}},
    year = {2026}
}