AhoosAI/nimbus-2-apex

<p align="center"> <img src="https://huggingface.co/AhoosAI/nimbus-2-apex/resolve/main/banner.png" alt="AhoosAI — Nimbus 2 Apex" width="820"> </p>

<p align="center"> <b>Trained to do exactly as it is told.</b><br> +8.7 points of instruction-following over the weights it was trained on.<br> <a href="https://ahoos-ai.site/nimbus-2-apex-benchmarks.html">benchmarks</a> · <a href="https://ahoos-ai.site/int-offline-studio">run it offline</a> · <a href="https://ahoos-ai.site/models/">models</a> · <a href="https://ahoos-ai.site">ahoos-ai.site</a> </p>

Nimbus 2 Apex

A LoRA adapter for Qwen/Qwen3-8B, rank 32, 87M trainable parameters — 1.05% of the model. Trained on behaviour: 36,024 rows and 106M tokens of how a request should be answered, not of code the base model had already read.

It ships at three quarters strength. lora_alpha is 48 against r 32, which is 75% of the 64 it was trained with. That is not a mistake in the config and the section below explains why it is the version published.

The easy way to run it

**AhoosAI Studio, offline** — a desktop app for Windows, macOS and Linux that downloads the base weights once and then needs no connection. It carries this adapter, the two dials the model was trained under, a working folder with a permission gate, and a terminal. No account and no sign-in.

Source and releases: github.com/mmdop/ahoos-studio-offline

What it changes

Every arm ran in one session on the same loaded weights, so base and adapter differ by the adapter and nothing else, and the per-item answers exist for both. Changes are tested with a two-sided sign test over the items that disagree.

One benchmark moved, and it is the one the training was for. The two blanks are blank because the rented GPU ran out before those arms; they are not the full-strength numbers borrowed and relabelled.

At full strength, where all four arms did run:

A gain and a loss both survive the arithmetic, and the loss is the reason for the strength this ships at.

Why 75%

Training taught the model to think longer. On the same 140 MMLU-Pro questions:

When the reasoning budget is tight the ceiling closes the thought mid-sentence, and an answer that comes out of a severed reasoning is worse. That is the entire mechanism behind the −10.0.

LoRA multiplies its update by lora_alpha / r, so a weaker copy is the same weights with one number changed. Three strengths were measured for the cost of running the benchmarks, not of training anything:

75% keeps most of the gain and the loss is gone — not smaller, gone: at p 0.597 there is nothing left to explain.

The two dials it was trained under

Thinking level, 1 to 20. The level sets a word target for the reasoning, max(12, round(15 * level ** 1.5)), with a hard ceiling at 2.5× that. Generation is two phases: reason until </think> or the ceiling, then answer from a closed block. The model was trained against these targets, so the level is a control and not a suggestion.

Temperature, 1 to 10. Each step is a whole sampling profile — temperature, top-p, top-k, repetition penalty — rather than one number moved. A model told to be careful should also be told to stop repeating itself.

Both are implemented in the Studio. Using the adapter directly, a plain temperature and a max_new_tokens work fine; you simply do not get the ladder.

Pictures

The weights are text-only and stay that way. In the Studio an image is turned into an XML description of the scene before the model sees it — colour quantisation, connected components, rule merging, axis calibration, OCR for the labels — and the model reads that as text.

It was measured cold, with no vision training at all, and reads about half the charts put in front of it correctly. What it does not do well is know when it has the other half wrong, so check anything that matters.

Using it

from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer

base = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3-8B", device_map="auto",
                                            torch_dtype="auto")
model = PeftModel.from_pretrained(base, "AhoosAI/nimbus-2-apex")
tok = AutoTokenizer.from_pretrained("AhoosAI/nimbus-2-apex")

messages = [{"role": "user", "content": "Write a pricing page. Persian, RTL."}]
text = tok.apply_chat_template(messages, tokenize=False,
                               add_generation_prompt=True, enable_thinking=True)
out = model.generate(**tok(text, return_tensors="pt").to(model.device),
                     max_new_tokens=2048, temperature=0.7, top_p=0.8, top_k=20)
print(tok.decode(out[0], skip_special_tokens=True))

A GGUF of the adapter is in this repository (nimbus-2-apex.gguf) for llama.cpp:

llama-server -m Qwen3-8B-Q4_K_M.gguf --lora nimbus-2-apex.gguf

Qwen publish GGUF builds of Qwen3-8B themselves, from q4 upward; there is no q3, so 12 GB of memory is the floor.

Training

The last eleven steps were lost to the time budget and cost nothing: the learning rate had already reached its floor.

What this is not

It is not a better programmer than its base and does not claim to be — LiveCodeBench and AIME did not move in a way that survives a test. It is a model that follows the instruction you actually wrote. That is the whole claim, at its real size, and the benchmark page shows the losses beside the gain.

Licence

The adapter is released under Apache-2.0, the same as Qwen/Qwen3-8B, which keeps its own. You need the base weights to use this; they are not redistributed here.

<p align="center"> _{© 2026 AhoosAI · <a href="https://ahoos-ai.site">ahoos-ai.site</a>} </p>