Post
Ornith 1.0 35B AEON Ultimate keeps the coding and drops the refusals
I abliterated DeepReinforce's Ornith 1.0 35B, an agentic coding MoE, and kept the coder: 0 of 80 refusals, pass@1 identical to the base, a three-way BF16, NVFP4 and DFlash benchmark on a DGX Spark, and the quick start to serve it.
10 min read
I wanted a coding agent on one box that calls tools, reads a screenshot when I paste one, and does not stop mid-task to tell me it cannot help. DeepReinforce's Ornith 1.0 35B was the closest base I had seen: a mixture-of-experts model, meaning a router sends each token through a few small specialist sub-networks instead of the whole network, post-trained for the long, tool-heavy loops of agentic coding. It also refused most of a red-team prompt set, and when you are the safety layer yourself, that reflex costs you twice: in the security work it declines, and in the hedging that leaks into ordinary answers.
Ornith 1.0 35B AEON Ultimate Uncensored is my build with the refusals removed and the coder kept. It refused 0 of 80 harmful prompts, its agentic pass@1 on my 18-task probe is 0.833, the same 15 of 18 as the base, and it ships as BF16, about 66 GB, for any vLLM, and as NVFP4, about 23.7 GB, for Blackwell GPUs, where one DGX Spark decodes it at an average of 93.3 tokens per second single stream with speculative decoding. Here is how it got there, failures included.
What Ornith is, and where it comes from
Ornith uses the qwen3_5_moe architecture: 40 layers, 30 of them GatedDeltaNet linear-attention layers that carry a compact recurrent state forward instead of attending over every earlier token, and 10 full-attention layers, a mix that makes a 256K-token context affordable. There are 256 routed experts plus one shared expert, with about 3B of the 35B parameters active per token, which is what A3B means. It has a vision tower, and it thinks: every reply opens with a <think> block the server has to parse out.
The upstream card says the family is post-trained on Gemma 4 and Qwen 3.5, but my weight-correlation tests for the BF16 card show the 35B member initialized from Qwen3.6-35B-A3B: a relative L2 distance of 0.0022 to that model against 0.0256 to Qwen3.5-35B-A3B-Base. That is the same lineage as my Qwen3.6-35B-A3B Heretic build, so its DFlash drafter drops in unchanged. The license is MIT, inherited from the base.
Removing the refusals without removing the coder
Abliteration is weight surgery rather than retraining: you find the directions in the model's activation space that carry the decision to refuse and project them out of the weights. On a hybrid model with a recurrent state, 256 experts and a router, it took three stages before export and quantization.
The first stage was repair. The conv1d blocks inside the linear-attention layers had outliers, and abliterating over them collapsed coherence. Following FernflowerAI's method, I rescaled every block whose sigma exceeded 1.5 times the median; that caught layers 36 and 37 and brought their sigma from 0.10 down to 0.062.
The second was abliteration with abliterix v1.9: grimjim's norm-preserving biprojected abliteration plus Expert-Granular Abliteration, which edits all 256 fused experts and the shared expert one by one and suppresses the router's pull toward refusing experts, with an Optuna search trading refusals against KL divergence from the base. The Q, K and V projections, the GatedDeltaNet internals and the vision tower were left alone.
The third stage is where the build earned its character. The lowest-refusal trial looked perfect on first-token probes and produced word salad on real generation; it was over-abliterated. I shipped a trial whose expert edit is about 170 times lighter, removes the same refusals and holds up on 256-token generations, and I now check every candidate on long generation before I believe a refusal number.
What the validation says, and what it does not
The refusal set is 80 harmful prompts across CBRN, cyber, weapons and self-harm; the shipped build refused 0 of 80, where the base refuses about 94 in 100 prompts of this kind. The capability check is an 18-task self-contained agentic probe, compared family by family with the base: 15 of 18, a pass@1 of 0.833, identical to the base. Eighteen tasks shows that nothing broke, not that anything improved. The base's published Terminal-Bench 2.1 score of 64.2 and SWE-bench Verified score of 75.6 are what I claim to have preserved; I did not re-run those suites.
The fidelity number is a first-token KL divergence of about 0.0014 against the base; a KL divergence that close to zero means the edited model picks its first token almost exactly as the base would. For the NVFP4 build I also ran 10 long generations on benign and harmful prompts, and 0 of 10 degenerated.
Quantizing a hybrid model: FP8 failed, NVFP4 worked
The edited model first has to be exported to BF16, and since the Spark's unified memory pool cannot do that edit in memory, the export ran on a box with about 70 GB of RAM. My first plan for the small build was FP8, and it failed twice: W8A8, weights and activations both in 8 bits, degraded coherence on this hybrid architecture, and W8A16, weights only, had no kernel, so vLLM stopped at Failed to find a kernel ... ScaledMM. The quick start supersedes the FP8 mentions still in RECIPE.md and serve_ornith.sh.
NVFP4 is what shipped: NVIDIA's 4-bit floating-point format, with a small scale factor per block of weights, which Blackwell GPUs run natively. The build is MLP-only and weight-only, W4A16, made with llm-compressor in the compressed-tensors format: the routed experts and the shared MLP are NVFP4, while attention, the GatedDeltaNet layers, the vision tower, gates, embeddings, output head and norms stay BF16. Weight-only matters because the reasoning penalty people associate with NVFP4 comes from FP4 activations, W4A4. I quantized on a B200 and validated on the Spark: about 23.7 GB against about 66 GB, 64 percent smaller.
The three-way benchmark on one Spark
I benchmarked three configurations, all single stream on one DGX Spark: BF16 on stock vLLM, NVFP4 on stock vLLM, and NVFP4 with DFlash in my AEON vLLM Ultimate container. DFlash is speculative decoding: a small drafter proposes several tokens ahead, the big model verifies them in one forward pass, and accepted tokens come almost free. The drafter is AEON-DFlash-Qwen3.6-35B-A3B.
| Measure | BF16, stock vLLM | NVFP4, stock vLLM | NVFP4 + DFlash, AEON container |
|---|---|---|---|
| Decode, coding | 30.8 | 38.5 | 77.1 |
| Decode, reasoning | 30.6 | 38.4 | 107.0 |
| Decode, math | 30.5 | 38.3 | 119.0 |
| Decode, prose | 30.4 | 38.3 | 70.3 |
| Decode, average | 30.6 | 38.4 | 93.3 |
| TTFT, by workload | 193 to 247 | 69 to 77 | 88 to 94 |
| Prefill | 3,517 | 5,203 | 9,661 |
Quantization alone buys about 1.25 times the decode speed, 3.2 times faster TTFT and 1.5 times the prefill rate; DFlash multiplies decode by about 2.4 again, so the shipped configuration decodes 3.05 times faster than naive BF16, shows its first token 2.5 times sooner and prefills 2.75 times faster. The drafter gives back about 20 milliseconds of TTFT, and its gain follows the workload, 119.0 tokens per second on math against 70.3 on prose, as acceptance of its guesses varies with the text.
Concurrency and the prefix cache
DFlash is a single-user feature. With six speculative tokens and --max-num-seqs 16, one stream decodes at 70 tokens per second on the Spark, 8 streams reach 203 in aggregate and 16 reach 456; plain NVFP4 without the drafter starts lower and ends higher, 39 tokens per second at one stream, 221 at 8, 376 at 16 and 539 at 32, so for batch throughput drop the drafter. Six speculative tokens is the measured optimum, not a memory lever: in a one-stream sweep n=6 peaked at 73.8 tokens per second, 1.89 times the undrafted rate, with longer and shorter drafts both slower, and the all-full-attention drafter accepts 3.71 tokens per step against 3.35 for the sliding-window drafter it replaced. Agentic loops also resend the same prompt and history every turn, so prefix caching matters: on the Spark a repeated 9.7k-token context prefilled in 103 milliseconds instead of 1,716, and across 1.2k to 14.6k contexts the gain ran from 4.9 to 16.6 times.
Quick start on a DGX Spark
You need Docker with the NVIDIA runtime, about 25 GB of disk for the NVFP4 model and about 1 GB for the drafter, and a quiet machine: stop any other large model and check free -g, since I want at least about 100 GB free before serving with DFlash, which peaks around 80 GB. Stock vLLM is not recommended on the Spark for this architecture; the container carries the qwen3_5_moe support, sm_121a kernels and DFlash.
Code, shelldocker pull ghcr.io/aeon-7/aeon-vllm-ultimate:latest
huggingface-cli download AEON-7/Ornith-1.0-35B-AEON-Ultimate-Uncensored-NVFP4 --local-dir ~/models/ornith-nvfp4
huggingface-cli download AEON-7/AEON-DFlash-Qwen3.6-35B-A3B --local-dir ~/models/ornith-dflash-drafterdocker run -d --name ornith --gpus all --ipc=host --net=host \
-e TORCH_CUDA_ARCH_LIST=12.1a -e CUTE_DSL_ARCH=sm_121a -e VLLM_USE_FLASHINFER_SAMPLER=1 -e VLLM_ENABLE_CUDA_COMPATIBILITY=0 \
-v ~/models/ornith-nvfp4:/model:ro \
-v ~/models/ornith-dflash-drafter:/drafter:ro \
--entrypoint vllm ghcr.io/aeon-7/aeon-vllm-ultimate:latest \
serve /model --served-model-name ornith aeon-ultimate aeon-fast aeon-deep \
--quantization compressed-tensors \
--speculative-config '{"method":"dflash","model":"/drafter","num_speculative_tokens":6}' \
--gpu-memory-utilization 0.6 \
--max-model-len 262144 --max-num-seqs 16 --max-num-batched-tokens 16384 \
--mamba-cache-dtype float32 \
--reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder \
--limit-mm-per-prompt '{"image":4,"video":2}' --mm-encoder-tp-mode data \
--attention-backend flash_attn \
--enable-chunked-prefill --enable-prefix-caching --trust-remote-codeCode, shellcurl -fsS http://localhost:8000/v1/models
curl -s http://localhost:8000/v1/chat/completions -H 'content-type: application/json' -d '{"model":"ornith","messages":[{"role":"user","content":"Write a Rust function that returns the median of a slice."}],"max_tokens":400,"temperature":0.6,"top_p":0.95,"top_k":20}' | python3 -m json.toolA healthy start logs Application startup complete with zero not found in params_dict warnings. Sample at temperature 0.6, top_p 0.95 and top_k 20, and allow max_tokens of 1024 or more: an empty content means the thinking block consumed the budget. Single stream, expect about 74 tokens per second and about 90 milliseconds TTFT. --limit-mm-per-prompt with --mm-encoder-tp-mode data turns on image and video input.
If your GPU is Hopper, Ada or Ampere, the 4-bit build will not run. Serve BF16 on any vLLM instead; on another Blackwell GPU, plain NVFP4 uses the same flags plus --quantization compressed-tensors, the NVFP4 model name and --gpu-memory-utilization 0.70.
Code, shellvllm serve AEON-7/Ornith-1.0-35B-AEON-Ultimate-Uncensored-BF16 --served-model-name ornith --max-model-len 262144 --gpu-memory-utilization 0.85 --max-num-batched-tokens 16384 --mamba-cache-dtype float32 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder --limit-mm-per-prompt '{"image":4,"video":2}' --mm-encoder-tp-mode data --attention-backend flash_attn --enable-chunked-prefill --enable-prefix-caching --trust-remote-codeFlags and limits that keep the Spark alive
--gpu-memory-utilization 0.6is validated stable with DFlash; never go above about 0.7 with the drafter, since unified memory thrashes above about 0.8, and 0.88 is the hard ceiling.--attention-backend flash_attnis required: vision and DFlash need FA2, and auto-selection can crash engine init.- Do not add
--kv-cache-dtype fp8; the vision tower and DFlash force a BF16 KV cache. --mamba-cache-dtype float32sets the precision of the GatedDeltaNet recurrent state.- Do not pair the sliding-window drafter z-lab/Qwen3.6-35B-A3B-DFlash with the stock image; it fails at init with
unify_kv_cache_spec_page_size AssertionError. Use the AEON drafter, or buildhotfixes/ornith_dflash_kvfix/(issue 1 in the repository). - Drafter acceptance can decay over many hours of continuous traffic; restart the container on a schedule or from a health check.
You are the safety layer
This build is for people who accept the role that comes with a model that does not refuse. The README says it in one sentence: "You, not the model, are the safety layer." The clause on the model cards covers sole responsibility, delivery as is, legal compliance, downstream safety layers, binding individual arbitration and indemnification; read it before serving the model to anyone but yourself. To check my numbers, see Run your own AI benchmark; the rest of this library is in the catalog.
Sources
- Repository and its DGX Spark quick start
- BF16 model card, including the user responsibility and arbitration clause
- NVFP4 model card
- AEON DFlash drafter
- Base model, deepreinforce-ai/Ornith-1.0-35B
- Tooling credited: abliterix, heretic, llm-compressor
More like this
- Serving Qwen 3.6 35B-A3B heretic at NVFP4 with DFlash on a DGX Spark
How I serve an uncensored Qwen 3.6 35B-A3B at NVFP4 with DFlash speculative decoding on one DGX Spark: the seven container fixes, the mixture-of-experts angle, the drafter, the measured numbers and the exact command that works today.
The Aeon Forge11 min read - Qwen 3.8 27B AEON Ultimate: the current flagship and how to serve it
Qwen3.8-27B AEON Ultimate Uncensored is the model I now serve on one Spark, two Sparks and the RTX box: what coherent abliteration removes and keeps, the NVFP4-MIXED weight lattice, the three seat recipes with their commands, and the rules that keep them running.
The Aeon Forge14 min read - Nemotron 3 Nano Omni AEON Ultimate, served uncensored on a DGX Spark
An abliterated Nemotron 3 Nano Omni that reasons over text, images and audio on one DGX Spark. How the twelve-dimension refusal removal was found, what NVFP4 costs against BF16, what the source-built vLLM image patches, and how to deploy it.
The Aeon Forge9 min read - Gemma 4 26B-A4B at NVFP4: a mixture-of-experts recipe for a DGX Spark
How I serve Gemma 4 26B-A4B, a mixture-of-experts model at NVFP4, on one DGX Spark with a DFlash drafter: the production recipe, the bench recipe behind 816 tok/s at c64, and the drafter defects that made my earlier numbers wrong.
The Aeon Forge10 min read - modelopt-fast-moe cuts AWQ calibration time for MoE models at NVFP4
modelopt-fast-moe replaces the one-sample-at-a-time calibration loop that leaves a GPU mostly idle while nvidia-modelopt quantizes a Mixture-of-Experts model to NVFP4. What broke on a 26B MoE, what the batched loop fixes, and what it still leaves to you.
The Aeon Forge6 min read