Skip to page content
SAVRN
Search Plan a project

Open-weight model · Image and text to text

Ornith-1.5-9B-EXL3-16GB-12GB

by Jorge Ramírez Espejo JRamirez-UAB/Ornith-1.5-9B-EXL3-16GB-12GB

Ornith-1.5-9B-EXL3-16GB-12GB is an open-weight model for image and text to text from Jorge Ramírez Espejo, released under MIT License. It has 4.4B parameters and a 262,144-token context. At 16-bit it needs about 10.5 GB of GPU memory, which fits on 1x MI300X from $1.85 an hour, at the lowest prices in the SAVRN Index. It draws 192 downloads a month.

An EXL3 quantization of ornith-ai/Ornith-1.5-9B made with exllamav3's per-tensor bit-allocation ("SC") pipeline with our own calibration, in two sizes: - main — 6.00 bpw, for 16 GB GPUs (e.g.

Parameters4.4B
Context262,144
Weights7.7 GB
Licensemit
AccessOpen weights
Monthly Downloads192

Runs On

What it takes to serve Ornith-1.5-9B-EXL3-16GB-12GB (4.4B parameters): the memory its weights need at each precision, and the cheapest way to rent enough data-center GPUs to hold them.

PrecisionWeightsMemory neededCheapest setupPer hourAlso fits
16-bit 8.8 GB 10.5 GB 1x MI300X (192 GB)
Vultr
$1.85 1x H100 $1.99 · 1x MI325X $2.00
8-bit 4.4 GB 5.3 GB 1x MI300X (192 GB)
Vultr
$1.85 1x H100 $1.99 · 1x MI325X $2.00
4-bit 2.2 GB 2.6 GB 1x MI300X (192 GB)
Vultr
$1.85 1x H100 $1.99 · 1x MI325X $2.00

Memory is the weights at that precision plus 20% for the runtime and a short context; a long context needs more. Prices are the lowest on-demand hourly rates in the SAVRN Index, read Oct 16, 2026.

Ornith-1.5-9B-EXL3-16GB-12GB on every accelerator the SAVRN Index prices, at every precision

Model Card

By Jorge Ramírez Espejo, published under mit, revision bcbd6df205fa.

An EXL3 quantization of ornith-ai/Ornith-1.5-9B made with exllamav3's per-tensor bit-allocation ("SC") pipeline with our own calibration, in two sizes: - main — 6.00 bpw, for 16 GB GPUs (e.g. RTX 5060 Ti 16 GB / 4060 Ti 16 GB): the full 262,144-token context with vision, MTP speculative decoding and 2 concurrent sessions, KL divergence 0.0019 against BF16. - 4.50bpw — 4.50 bpw, for 12 GB GPUs (e.g. RTX 3060 12 GB): 198,000 tokens with vision or 220,000 text-only, KLD 0.0095. Both are served with vLLM (continuous batching) through the OrcaSAQ2 plugin and a small plugin of ours (included), with INT8 token embeddings. Highlights (one RTX 3090 24 GB, measured on 2026-10-14; details in Family…

Read Jorge Ramírez Espejo's full model card

Ornith-1.5-9B — EXL3 for 16 GB and 12 GB GPUs (vision + MTP, served with vLLM)

Install from this card, not from generic snippets. This is an EXL3 checkpoint: vLLM loads it only together with exllamav3 and our plugins. Follow Requirements & install and Quick start; a plain pip install vllm, Transformers or SGLang cannot load it.

An EXL3 quantization of ornith-ai/Ornith-1.5-9B made with exllamav3's per-tensor bit-allocation ("SC") pipeline with our own calibration, in two sizes:

  • main — 6.00 bpw, for 16 GB GPUs (e.g. RTX 5060 Ti 16 GB / 4060 Ti 16 GB): the full 262,144-token context with vision, MTP speculative decoding and 2 concurrent sessions, KL divergence 0.0019 against BF16.
  • 4.50bpw — 4.50 bpw, for 12 GB GPUs (e.g. RTX 3060 12 GB): 198,000 tokens with vision or 220,000 text-only, KLD 0.0095.

Both are served with vLLM (continuous batching) through the OrcaSAQ2 plugin and a small plugin of ours (included), with INT8 token embeddings.

Fix 2026-10-09 — sampling parameters (please update): until 2026-10-09 this repo, like the original ornith-ai/Ornith-1.5-9B, had no generation_config.json. vLLM then samples from the whole vocabulary (temperature 1.0, top_p 1.0, no top_k) whenever the client sends no sampling parameters (e.g. opencode without "temperature": true), and the model drifts into stray Chinese text and broken output in long answers. The repo now ships generation_config.json with top_p 0.95 / top_k 20 (Ornith's values for coding) and temperature 0.8 (Ornith recommends 0.6; 0.8 since 2026-10-14, see Sampling and repetition loops), which vLLM applies automatically. If you downloaded before, fetch it again (hf download JRamirez-UAB/Ornith-1.5-9B-EXL3-16GB-12GB generation_config.json, also with --revision 4.50bpw) or add --override-generation-config '{"temperature":0.8,"top_p":0.95,"top_k":20,"min_p":0.0,"repetition_penalty":1.0}' to vllm serve. Measured on the long opencode request: stray CJK text in 2 of 4 answers without it, in 0 of 8 with it.

Our focus. We quantize and evaluate models for one use case: a local Linux system-administration agent (opencode with tool calling) for a university IT department, used in Spanish. Our calibration traces include real sysadmin/agent conversations in Spanish, and our quality checks (tool calls with the real opencode request, agent tasks with real command execution, long-context retrieval, long answers in Spanish) reflect that use. KL divergence is also reported on turboderp's public trace, so it can be compared and reproduced. Numbers for other domains or languages may differ.

Re-evaluation (2026-10-11): with the sampling configured, Ornith-1.5-9B works well as a sysadmin agent. Our earlier note said it did not; most of that came from running it without sampling parameters. With this repo's generation_config.json (temperature 0.6 at the time of this test, top_p 0.95, top_k 20), on the same tests as the other 9B models we evaluate (main 6.00 bpw, vLLM, RTX PRO 6000 at 300 W): - Agent tasks (10 real sysadmin tasks with opencode run, real command execution): 9/10, and 23/30 over three more runs (NeoHorse-1-9B: 21/30 on the same runs). Over 60 tasks (20 × 3): 45/60 as written, 55/60 with file names in backticks (NeoHorse-1-9B: 50/60 and 53/60). Tool calls with the real opencode request: 30/30. - Stray Chinese text in long Spanish answers (10 long answers each): no sampling parameters 7/10; with the sampling above 1/10 (3 characters); with the sampling plus a system line "Responde siempre en castellano" 0/10. In English: 3/10 without parameters, 0/10 with them. Again on 2026-10-14 (10 long Spanish + 10 English answers per run, no sampling parameters): 0 of 20 at 0.6 and at 0.7; at 0.8, 1 of 40 (2 stray characters, no drift into Chinese). For non-English use, add a language line to your system prompt or AGENTS.md: unlike other 9B models we tested, Ornith needs it. - Weak spot: code that runs. In our small browser-game test only 0-1 of 4 games ran (NeoHorse-1-9B: 2-3 of 4). Prefer a larger model for coding. - It reasons briefly: ≈25-30k reasoning tokens for 48 checkable problems at xhigh (Qwen3.5-9B: ≈146k). The quantization itself is very close to the original (KLD 0.0019 at 6.00 bpw, 0.0095 at 4.50 bpw).

Recommended sampling (Ornith's model card; for coding we use temperature 0.8 instead of 0.6): - Coding / agents: temperature 0.8, top_p 0.95, top_k 20, min_p 0.0, presence_penalty 0.0, repetition_penalty 1.0 (the default in generation_config.json since 2026-10-14; 0.6, Ornith's value, from 2026-10-09: 2 of 30 long answers looped at 0.6 and 0 of 30 at 0.8, see Sampling and repetition loops). - General tasks: temperature 1.0, top_p 0.95, top_k 20, min_p 0.0, presence_penalty 1.5, repetition_penalty 1.0. - opencode: declare "temperature": true on the model and set the agent temperature to 0.8; otherwise opencode sends no sampling parameters.

Tested setup: RTX 3090 (24 GB, Ampere, power limit 350 W), vLLM 0.31.0 + exllamav3 1.5.1 + the OrcaSAQ2 plugin + our qwen38_exl3_vision 0.3.1 plugin, weights downloaded from this repo, the Quick start configuration (2026-10-14). Only this setup has been tested.

Highlights (one RTX 3090 24 GB, measured on 2026-10-14; details in Family comparison): - KLD 0.0019 against BF16 on our evaluation set (0.0017 on turboderp's public trace). - 262,144 with vision on one 24 GB GPU with MTP (2.88 tokens per step); needle 8/8 at 241,437. - Tool calls with the real opencode request 60/60, opencode agent tasks 23/30 (10 sysadmin tasks × 3 runs), images 14/15. - Reasoning 45/48 at xhigh with 27,067 reasoning tokens in total. - Decode 136.5 / 240.6 / 252.3 tok/s with 1 / 2 / 8 requests; 15,232 MiB of VRAM used at peak.

What is in this repository

Which one to use

All Ornith-1.5-9B variants we publish, measured on 2026-10-14 under the same conditions (see Family comparison for every number):

Variant Weights Context on one RTX 3090 KLD vs BF16 Agent tasks Decode, 1 request Pick it for
EXL3 6.00 (16 GB) (this repo) 7.20 GiB 262,144 with vision 0.0019 23/30 136.5 tok/s a 16 GB GPU: 262,144 tokens with vision
EXL3 4.50 (12 GB) (this repo) 5.77 GiB 198,000 with vision 0.0095 20/30 138.0 tok/s a 12 GB GPU: 198,000 tokens with vision

Variants / revisions

Revision Target Linear layers (achieved) lm_head Vision MTP head Embeddings Size KLD (ours / pub.)
main 16 GB 6.00 bpw (5.999), SC allocation 6 bits 6 bits 6 bits INT8 per row 7.20 GiB 0.0019 / 0.0017
4.50bpw 12 GB 4.50 bpw (4.500), SC allocation 5 bits 4 bits 6 bits INT8 per row 5.77 GiB 0.0095 / 0.0086

For comparison, a uniform 6.00 bpw allocation measured 0.0023 / 0.0021: the per-tensor recipe is ≈18 % closer to BF16 at the same size. We also made 3.50 and 3.00 bpw versions for 8 GB GPUs (KLD 0.032 and 0.065; text only, 46k / 63k tokens of context, peak ≈7,400 MiB used, tools 15/15, reasoning 46–47/48); they are an ongoing project and not published here.

Files and reproducibility

  • model-*.safetensors, config.json (quantization_config: exl3), quantization_config.json (per-tensor allocation); SHA256SUMS.
  • plugin/qwen38_exl3_vision/: our vLLM plugin. scripts/embed_int8.py: re-encodes embed_tokens to INT8 per row.
  • The calibration and evaluation sets are internal and not published; the public KLD figures use turboderp's qbench_prompts_gen.json, so they can be reproduced with exllamav3's qbench against the BF16 model.
  • NOTICE: license and attribution of the original model.

Results

Family comparison (Ornith-1.5-9B, same conditions)

Measured on 2026-10-14 for every variant in the same way: weights downloaded from Hugging Face, one RTX 3090 24 GB (power limit 350 W, no other use), vLLM 0.31.0 (EXL3: + exllamav3 1.5.1 + plugins), each variant with its own Quick start configuration. KLD and perplexity come from exllamav3's qbench (see How to read it).

Variant Weights KLD mean / median (internal · public) Perplexity (BF16 3.1395 · pub. 2.0882) Needle (8 facts) near max. context Tools: real opencode request Agent tasks (10 × 3) Reasoning xhigh: correct · tokens Vision
EXL3 6.00 bpw (main, this repo) 7.20 GiB 0.0019 / 0.0008 · pub. 0.0017 / 0.0003 3.1427 · pub. 2.0896 8/8 at 241,437 60/60 23/30 45/48 · 27,067 14/15
EXL3 4.50 bpw (4.50bpw, this repo) 5.77 GiB 0.0095 / 0.0040 · pub. 0.0086 / 0.0016 3.1447 · pub. 2.0950 8/8 at 182,413 60/60 20/30 45/48 · 29,708 14/15
Variant Context on one RTX 3090 Sessions Prefill near max. context Decode, 1 / 2 / 8 requests (tok/s) MTP tokens per step VRAM used at peak (fits a 16 GB card up to ≈15,700 MiB, a 12 GB card up to ≈11,700)
EXL3 6.00 (16 GB) 262,144 with vision 2 1,694 tok/s 136.5 / 240.6 / 252.3 2.88 15,232 MiB
EXL3 4.50 (12 GB) 198,000 with vision 2 1,665 tok/s 138.0 / 249.7 / 265.0 2.84 11,560 MiB

How to read it: - KLD / perplexity: next-token KL divergence against the BF16 model with exllamav3's qbench (lower is better). Internal: our sysadmin/agent evaluation set (not published, separate from the calibration data); public: turboderp's qbench_prompts_gen.json, reproducible by anyone. GPTQ checkpoints were evaluated as a BF16 copy holding the dequantized weights. These two columns come from qbench, not from this campaign. - Needle: 8 facts spread through one prompt at about 92 % of the served context; all 8 must come back. Tools: the real request of the opencode agent (system prompt + 11 tools), 3 cases × 20 tries, at the model's default sampling (generation_config.json); a try counts when it calls a valid tool with valid arguments and the expected command. Agent: 10 sysadmin tasks run with opencode run and real command execution, 3 runs, at the recommended temperature; with sampling on, the same checkpoint varies by about ±2 of 30 between runs, so other measurements in this card may differ by that much. Reasoning: 6 checkable problems × 8 at xhigh; total reasoning tokens over the 48. Vision: our 4-image test. - Prefill / decode: prefill from the needle prompt; decode is aggregate throughput with 1 / 2 / 8 simultaneous requests (temperature 0; with more requests than Sessions, the extra ones wait). MTP tokens per step: vLLM's speculative-decoding metrics over the whole run. - VRAM really free: lowest memory.free while serving (nvidia-smi every 0.5 s, from the end of start-up to the end of the run); we require ≥100 MiB. - Older sections below keep their own date and setup; use this table to compare variants.

How many sessions fit with each Quick start configuration (KV size in tokens as reported by vLLM at start-up; a session uses the KV of its own context, and vLLM never runs more than max sessions at once):

Variant KV pool (tokens) Max sessions 32k each 64k each 128k each Full context each
EXL3 6.00 (16 GB) 267,185 2 2 2 2 1 × 262,144
EXL3 4.50 (12 GB) 199,980 2 2 2 1 1 × 198,000

Few users or many users. The Quick start configuration is tuned for 1–2 simultaneous users (fastest single request). For more users, the many users option below (measured the same day, same GPU) gives more total throughput; each request gets slower when many run at once. Same model, same quality: only the serving settings change.

Variant Configuration Decode by simultaneous requests (aggregate tok/s) N sessions at once, needle 8/8 Tools (5 × 3) VRAM used at peak
EXL3 6.00 (16 GB) Quick start (2 sessions, MTP 3) 1: 136 · 2: 241 · 8: 252 — 60/60 15,232 MiB
EXL3 6.00 (16 GB) many users (8 sessions of up to 262,144 tokens, MTP 3) 1: 131 · 2: 240 · 4: 474 · 8: 579 6/8 of 22k 15/15 15,442 MiB
EXL3 4.50 (12 GB) Quick start (2 sessions, MTP 3) 1: 138 · 2: 250 · 8: 265 — 60/60 11,560 MiB
EXL3 4.50 (12 GB) many users (8 sessions of up to 198,000 tokens, MTP 3) 1: 144 · 2: 253 · 4: 497 · 8: 644 5/8 of 22k 15/15 11,688 MiB

Benchmarks and validated configurations (RTX 3090, 350 W, within the target memory budget)

Earlier measurements, before the controlled comparison of 2026-10-14: other dates, vLLM versions or settings, as stated in each table. Use Family comparison above to compare variants.

Test main 6.00 bpw, 16 GB, 262,144 + vision 4.50bpw, 12 GB, 198,000 + vision 4.50bpw, 12 GB, 220,000 text only
KV pool 267,185 tokens (KV 5.25e9 B) 199,980 tokens (KV 4.0e9 B) 222,986 tokens (KV 4.43e9 B)
8 facts in one long prompt (greedy) 8/8 at 246,788 tokens, 190 s (1,296 tok/s) 8/8 at 184,931 tokens, 121 s (1,529 tok/s) 8/8 at 206,162 tokens, 143 s (1,445 tok/s)
2 simultaneous sessions 2 × ≈125k, 8/8 in both 2 × ≈91k, 8/8 in both 2 × ≈102k, 7/8 in both
Decode, 1 request / 2 concurrent (t=0) 130.6 / 251.6 tok/s 137.8 / 255.8 tok/s 127.4 / 251.8 tok/s
Images (4 synthetic tasks, 18 checks; two runs) 18/18 and 17/18 17/18 and 17/18 —
Real opencode request, tool calls (3 cases × 20; T=1.0 / T=0.3) 59/60 / 60/60 58/60 / 60/60 60/60 / 60/60
Peak memory used 14,072 MiB (16 GB budget ≈15,700) 11,444 MiB (12 GB budget ≈11,700) 11,406 MiB

Images: failed-service screenshot, chart, dense firewall ruleset, and a terminal where a port is held by another process while the journal shows a dead PID as a trap. The missed check, when there is one, is always the same: after freeing the port the model restarts the service without checking the port again first.

Reasoning and agent tasks

6 problems with checkable answers (arithmetic, word problem, counting, logic, subnetting, systemd) × 8 tries, temperature 0.6, total reasoning tokens over 48 requests; agent = 4 sysadmin tasks × 2 with opencode run (xhigh, temperature 0.3, our setting until 2026-10-13, real tool execution):

Revision low medium xhigh Correct (low · medium · xhigh) Agent (plain prompts) Agent (file names in backticks)
main 6.00 32,636 23,479 31,415 46 · 43 · 44 6/8 (both misses: errors.txt) 16/16 (earlier 6.00 build)
4.50bpw 22,839 27,007 23,145 45 · 45 · 47 6/8 (both misses: errors.txt) 16/16

For reference, on the same 48 problems Qwen3.5-9B used ≈146k reasoning tokens at xhigh (39/48, 9 answers cut off) and a 27B Qwen3.8 ≈18–23k.

Agent turns and 8 sessions (--max-num-seqs 8, same KV pool)
Revision Turn: time to first token / total (median) 8 sessions: needle each, aggregate prefill Decode with 8 sessions (t=0) Peak used
main 6.00 (16 GB) 0.76 / 1.4 s 8 × 29k, 8/8 in all, 2,824 tok/s 556 tok/s ≈14,180 MiB
4.50bpw (12 GB, 198,000 + vision) 0.75 / 1.3 s 8 × 22k, 8/8 in 7 and 7/8 in one, 2,931 tok/s 591 tok/s ≈11,530 MiB

Sampling and repetition loops

Measured on 2026-10-14 with the same software and GPU as Family comparison, on our EXL3 6.00 (16 GB) build of Ornith-1.5-9B (loops come from the model and the sampling, not from the quantization format): 5 long Spanish sysadmin prompts × 6 runs per temperature, up to 16,000 tokens, top_p 0.95 and top_k 20; a loop = more than 30 % repeated 8-grams. Serving: the Quick start with a 32k context and 8 sessions.

Temperature 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
Loops / 30 6 2 3 1 1 0 0 0
Answers that finished before 16,000 tokens / 30 25 23 26 25 25 22 24 20

From temperature 0.6 up, loops are rare (at most 1 of 30). This repo's default (generation_config.json) is 0.8.

Other models, same test and setup (loops / 30):

Model (build) 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
Qwen3.8-27B · EXL3 3.85 12 12 7 8 1 1 1 0
Qwen3.8-27B-pi · EXL3 3.85 9 4 9 10 4 2 1 0
Qwopus3.8-27B-Flash-V2 · EXL3 3.85 3 1 2 1 2 0 0 0
Swift 1.5 (Qwen3.8-27B) · EXL3 3.85 7 5 3 4 3 1 1 0
NeoHorse-1-9B · EXL3 6.00 (16 GB) 6 3 3 1 0 0 0 0
Qwen3.6-35B-A3B · EXL3 4.00 0 0 1 1 0 0 0 0
Ornith-1.5-35B-A3B · EXL3 4.00 1 0 0 0 0 0 0 0
Qwopus3.6-35B-A3B-Coder · EXL3 4.00 9 13 12 6 11 6 5 4
Swift 1.5 Qwen3.8-Flash-Next (125B-A6B) · EXL3 2.25 · vLLM 24 24 21 21 17 8 0 0
Qwen3.8-Flash-Next (125B-A6B) · EXL3 2.25 · vLLM — — 13 7 5 2 0 0

Requirements & install (vLLM 0.31 + exllamav3 1.5.1 + plugins)

EXL3 is not a native vLLM format. Two plugins are needed, both loaded through vLLM's vllm.general_plugins entry point: - Continuum-AI-Corp/OrcaSAQ2-kernel (commit 7ddffb12c00c24b8bc6b1164723c04ac490a91bc): EXL3 linear layers through exllamav3's kernels, and INT8 / packed embed_tokens and lm_head for qwen3_5 models (no vLLM patch needed). - qwen38_exl3_vision 0.4.0 (ours; 0.4.0 adds multi-GPU: tensor parallelism for the dense models, -tp 2, e.g. Swift 27B on 2 GPUs with the same log-likelihood (+0.04 %) and +43 % speed for one request, and expert parallelism for the MoE ones, -tp 2 --enable-expert-parallel; 0.3.2 freed the host-RAM copy of the checkpoint, ~14 GB less for a 27B; in plugin/qwen38_exl3_vision/, the same version in all our EXL3 repos): the EXL3 vision tower (drops the separate attn.{q,k,v}_proj tensors and pads input dimensions to multiples of 128 where needed), EXL3 MoE experts with exllamav3's fused kernel, and the Qwen3.8-Flash-Next model.

Use exllamav3 1.5.1 (with 1.6.x the KLD is the same, but tool calls without reasoning got worse in our tests) and Python 3.12 (the exllamav3 wheels are cp312). flashinfer compiles some kernels on first start with the CUDA toolkit that comes with the vLLM wheel; if your system nvcc does not match, point CUDA_HOME at a CUDA 13.0 toolkit.

uv venv --python 3.12 venv
uv pip install --python venv/bin/python vllm==0.31.0 --torch-backend=auto        # torch 2.13.0
W=exllamav3-1.5.1+cu132.torch2.13.0-cp312-cp312-linux_x86_64.whl
curl -L -o /tmp/$W "https://github.com/turboderp-org/exllamav3/releases/download/v1.5.1/${W/+/%2B}"
git clone https://github.com/Continuum-AI-Corp/OrcaSAQ2-kernel && (cd OrcaSAQ2-kernel && git checkout 7ddffb12c00c24b8bc6b1164723c04ac490a91bc)
hf download JRamirez-UAB/Ornith-1.5-9B-EXL3-16GB-12GB --include "plugin/*" --local-dir .
uv pip install --python venv/bin/python /tmp/$W -e OrcaSAQ2-kernel -e plugin/qwen38_exl3_vision
venv/bin/python -c "import torch; from exllamav3.ext import exllamav3_ext; print(torch.__version__, torch.cuda.get_device_name(0))"

Quick start

16 GB GPU — main (6.00 bpw), vision + MTP 3, full 262,144 context, 2 concurrent sequences, 1 image per request (≤1 MP):

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True VLLM_USE_FLASHINFER_SAMPLER=0
vllm serve JRamirez-UAB/Ornith-1.5-9B-EXL3-16GB-12GB \
  --served-model-name ornith-1.5-9b \
  --limit-mm-per-prompt '{"image":1,"video":0}' \
  --mm-processor-kwargs '{"max_pixels":1003520}' \
  --max-model-len 262144 \
  --kv-cache-dtype fp8_e4m3 \
  --kv-cache-memory-bytes 5250000000 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 2 \
  --enable-prefix-caching \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder

12 GB GPU — 4.50bpw: the same command with --revision 4.50bpw and - with vision: --max-model-len 198000 --kv-cache-memory-bytes 4000000000 --max-num-batched-tokens 2048 (peak 11,500 MiB used; 4096 goes 22 MiB over a 12 GB budget); - text only (drop --limit-mm-per-prompt / --mm-processor-kwargs, add --language-model-only): --max-model-len 220000 --kv-cache-memory-bytes 4430000000 --max-num-batched-tokens 1024 (peak 11,406 MiB used).

Both leave ≈250–300 MiB under the ≈11,700 MiB a 12 GB card offers. A first measurement at 210,000 / 235,000 tokens peaked at 11,684 / 11,706 MiB: it works, but with no margin at all, so we recommend the values above.

8 concurrent sessions: add --max-num-seqs 8 and keep the same KV cache (the pool is shared: 8 × ≈30k tokens at once, or one long session). Validated on 16 GB (peak ≈14,180 MiB used) and on 12 GB with vision at 198,000 (peak ≈11,530 MiB used) — both measured with --max-num-batched-tokens 1024: use 1024 for 8 sessions.

For many users (measured on 2026-10-14, same GPU): the same command with --max-num-seqs 8 — 8 sessions of up to 262,144 tokens, MTP 3. Aggregate decode 579 tok/s with 8 requests (Quick start: 252 with 8); a single request runs at 131 tok/s (136 with the Quick start); 6 of 8 simultaneous sessions returned all 8 needle facts; 15,442 MiB of VRAM used at peak. Rule for CUDA graphs: they must cover sessions × (1 + MTP) tokens per step.

Using it with opencode (how we tested)

This checkpoint is meant to be used as a coding / sysadmin agent from opencode (tested with opencode 1.18.33). Tool calling was measured with the real opencode request (captured and replayed against vLLM) and with opencode run agent tasks; context, speed, memory and image tests were run against the vLLM API.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "local-vllm": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "local vLLM",
      "options": { "baseURL": "http://127.0.0.1:8000/v1" },
      "models": {
        "ornith-1.5-9b": {
          "name": "Ornith 1.5 9B EXL3 (local)",
          "tool_call": true,
          "temperature": true,
          "attachment": true,
          "modalities": { "input": ["text", "image"], "output": ["text"] },
          "limit": { "context": 262144, "output": 32000 },
          "variants": {
            "none":   { "chat_template_kwargs": { "enable_thinking": false } },
            "low":    { "chat_template_kwargs": { "reasoning_effort": "low" } },
            "medium": { "chat_template_kwargs": { "reasoning_effort": "medium" } },
            "xhigh":  { "chat_template_kwargs": { "reasoning_effort": "xhigh" } }
          }
        }
      }
    }
  },
  "agent": {
    "build": { "model": "local-vllm/ornith-1.5-9b", "variant": "xhigh", "temperature": 0.8 },
    "plan":  { "model": "local-vllm/ornith-1.5-9b", "variant": "xhigh", "temperature": 0.8 }
  }
}
  • limit.context = --max-model-len (use the 12 GB value with the 4.50bpw branch); opencode compacts the history at ≈context − output tokens of input.
  • Declare "temperature": true in the model, otherwise opencode sends no temperature to a custom model. Drop attachment / modalities for text-only serving.
  • Start opencode inside a project directory; for opencode run from scripts, close stdin (`

Configuration

Architecture
Qwen3_5ForConditionalGeneration
Context length (tokens)
262,144
Layers
32
Hidden size
4,096
Feed-forward size
12,288
Attention heads
16
Key/value heads
4
Head dimension
256
Vocabulary size
248,320
Model type
qwen3_5
Quantization
exl3

Identity and Version

Repository
JRamirez-UAB/Ornith-1.5-9B-EXL3-16GB-12GB
Publisher
Jorge Ramírez Espejo
Task
Image and text to text
Modality
Image and text
Library
exllamav3
Parameters
4.4B parameters
Languages
es, en
Revision
bcbd6df205fa93ae93a19da3003edbc9fada876e
First published
2026-10-03
Last updated
2026-10-16

Files and Weights

24 files, 7.8 GB in total. The weights are 2 files totalling 7.7 GB in safetensors.

Weights2 files · 7.7 GB
Configuration12 files · 472.0 KB
Tokenizer4 files · 22.9 MB
Documentation2 files · 35.8 KB
Other3 files · 8.7 KB
Repository1 file · 1.6 KB
Every file
FileTypeSizeSHA-256
model-00001-of-00002.safetensorsWeights7.6 GB c53d95cb96d9
model-00002-of-00002.safetensorsWeights164.7 MB 567c433bf9c8
config.jsonConfiguration3.7 KB —
generation_config.jsonConfiguration223 B —
model.safetensors.index.jsonConfiguration184.0 KB —
plugin/qwen38_exl3_vision/qwen38_exl3_vision/__init__.pyConfiguration7.6 KB —
plugin/qwen38_exl3_vision/qwen38_exl3_vision/moe.pyConfiguration13.2 KB —
plugin/qwen38_exl3_vision/qwen38_exl3_vision/service_ple.pyConfiguration10.0 KB —
plugin/qwen38_exl3_vision/qwen38_exl3_vision/tp.pyConfiguration9.4 KB —
preprocessor_config.jsonConfiguration390 B —
processor_config.jsonConfiguration1.2 KB —
quantization_config.jsonConfiguration238.2 KB —
scripts/embed_int8.pyConfiguration3.6 KB —
video_preprocessor_config.jsonConfiguration385 B —
NOTICEDocumentation1.3 KB —
README.mdDocumentation34.5 KB —
SHA256SUMSOther462 B —
chat_template.jinjaOther7.6 KB —
plugin/qwen38_exl3_vision/pyproject.tomlOther607 B —
.gitattributesRepository1.6 KB —
merges.txtTokenizer3.4 MB —
tokenizer.jsonTokenizer12.8 MB 5f9e4d4901a9
tokenizer_config.jsonTokenizer16.7 KB —
vocab.jsonTokenizer6.7 MB —

License and Download

License
mit
Access
Open weights, no gate
Download size
7.7 GB
Download from Jorge Ramírez Espejo

Released by Jorge Ramírez Espejo through its official repository on Hugging Face. Read the license.

Built From

  • Derived from ornith-ai/Ornith-1.5-9B
  • Described by arXiv:2406.11235
  • Quantized from ornith-ai/Ornith-1.5-9B

Memory Requirements

PrecisionWeights in memory
As published7.7 GB
16-bit8.8 GB
8-bit4.4 GB
4-bit2.2 GB

Weights only, from the published parameter count; the key-value cache and runtime add to this.

Questions About Ornith-1.5-9B-EXL3-16GB-12GB

How much GPU memory does Ornith-1.5-9B-EXL3-16GB-12GB need?

About 10.5 GB at 16-bit and 2.6 GB at 4-bit: the weights (4.4B parameters) plus a working margin. A long context needs more.

What is the cheapest GPU to run Ornith-1.5-9B-EXL3-16GB-12GB on?

At 16-bit, 1x MI300X from $1.85 an hour; at 4-bit, 1x MI300X from $1.85 an hour, at the lowest on-demand prices the SAVRN Index lists.

Can I use Ornith-1.5-9B-EXL3-16GB-12GB commercially?

Yes. Ornith-1.5-9B-EXL3-16GB-12GB is released under MIT License. The MIT License is a short permissive license. It permits commercial use, modification and redistribution, provided the copyright notice and permission notice are included.

What is Ornith-1.5-9B-EXL3-16GB-12GB's context length?

262,144 tokens, from the maximum position embeddings in its published configuration.

Similar Models

Model · Image and text to text

NeoHorse-1-9B-EXL3-16GB-12GB

Jorge Ramírez Espejo

An EXL3 quantization of TokenRhythm/NeoHorse-1-9B (an agent-oriented finetune of Qwen3.5-9B) made with exllamav3, in two sizes: - main — 6.00 bpw, for 16 GB GPUs (e.g. RTX 5060 Ti 16 GB / 4060 Ti 16 GB): the full 262,144-token context with vision, MTP speculative decoding and 2 concurrent sessions, KL divergence 0.0015 against BF16. - 4.50bpw — 4.50 bpw, for 12 GB GPUs (e.g. RTX 3060 12 GB): 176,000 tokens with vision, KLD 0.0058. Both are served with vLLM (continuous batching) through the OrcaSAQ2 plugin and a small plugin of ours (included), with INT8 token embeddings. Why this model: we evaluate small models as a Linux sysadmin agent driven by opencode, used in Spanish. Among the 9B…

Open weights apache-2.0 4.4B parameters 262,144 tokens exllamav3

Model · Image and text to text

Qwen3-VL-4B-Instruct

Qwen

Meet Qwen3-VL — the most powerful vision-language model in the Qwen series to date. This generation delivers comprehensive upgrades across the board: superior text understanding & generation, deeper visual perception & reasoning, extended context length, enhanced spatial and video dynamics comprehension, and stronger agent interaction capabilities. Available in Dense and MoE architectures that scale from edge to cloud, with Instruct and reasoning‑enhanced Thinking editions for flexible, on‑demand deployment. Text Understanding on par with pure LLMs: Seamless text–vision fusion for lossless, unified comprehension. 1. Interleaved-MRoPE: Full‑frequency allocation over time, width, and height…

Open weights apache-2.0 4.4B parameters 262,144 tokens transformers

Model · Image and text to text

gemma-3-4b-it

Google

[Gemma 3 Technical Report][g3-tech-report] [Responsible Generative AI Toolkit][rai-toolkit] [Gemma on Kaggle][kaggle-gemma] [Gemma on Vertex Model Garden][vertex-mg-gemma3] Summary description and brief definition of inputs and outputs. Gemma is a family of lightweight, state-of-the-art open models from Google, built from the same research and technology used to create the Gemini models. Gemma 3 models are multimodal, handling text and image input and generating text output, with open weights for both pre-trained variants and instruction-tuned variants. Gemma 3 has a large, 128K context window, multilingual support in over 140 languages, and is available in more sizes than previous…

Access requested at publisher gemma 4.3B parameters transformers

Model · Image and text to text

medgemma-4b-it

Google

Model on Google Cloud Model Garden: MedGemma GitHub repository (supporting code, Colab notebooks, discussions, and Foundations terms of use](https://developers.google.com/health-ai-developer-foundations/terms). This section describes the MedGemma model and how to use it. MedGemma is a collection of Gemma 3 variants that are trained for performance on medical text and image comprehension. Developers can use MedGemma to accelerate building healthcare-based AI applications. MedGemma currently comes in three variants: a 4B multimodal version and 27B text-only and multimodal versions. Both MedGemma multimodal versions utilize a SigLIP image encoder that has been specifically pre-trained on a…

Access requested at publisher other 4.3B parameters transformers

Model · Image and text to text

Mephisto-1.5-4B

Model Merge JP

Mephisto-1.5-4B is a 4B-parameter agentic language model constructed via multi-stage model merging using mergekit. The model integrates reasoning, coding, and agentic capabilities into a single 4B checkpoint based on the Qwen3.5-4B architecture, targeting performance exceeding Mephisto-4B-v2 on Japanese and agentic benchmarks while maintaining deployment feasibility on consumer hardware (RTX 3060 12GB). The model is constructed through a three-stage merging pipeline: Normalized spherical linear interpolation (NuSLERP) on task vectors derived from a common base model (Qwen3.5-4B). This stage fuses a reasoning-distilled model (Opus-reasoning distillation) with a code-specialized model.…

Open weights 4.2B parameters 262,144 tokens transformers

Model · Image and text to text

h2o-lightning-4b

H2O.ai

H2O-Lightning-4B is a 4B-parameter decision model from H2O.ai, built on Qwen/Qwen3.5-4B. It answers typed decision questions about a record (a document, a ticket, a policy, a conversation) and about images that come with the record (photos, screenshots, scanned documents, charts). It returns a probability for every option: - yes/no (noul): gives the probability that a statement is true; It runs on unmodified vLLM 0.30.0 with a small standard-library shim in front (h2olightningshim.py). Each decision is one forward pass and one output token, so the cost is input tokens only. Try it in your browser: live demo on Hugging Face Spaces (text and images; built by the Hugging Face team and running…

Open weights apache-2.0 4.5B parameters 262,144 tokens transformers