No changes to datasets or capabilities. Fully functional, 100% of what the original authors intended. These are meant to be the best high-quality models available Both variants offer high capability and the same outcome. The difference is how they deliver results:

Specs

27B dense parameters
64 layers, layout: 16 × (3 × (Gated DeltaNet → FFN) → 1 × (Gated Attention → FFN))
48 linear attention layers + 16 full gated-attention layers
Gated DeltaNet: 48 V heads / 16 QK heads, head dim 128
Gated Attention: 24 Q heads / 4 KV heads, head dim 256, rope dim 64
Hidden dim 5120, FFN dim 17408, vocab 248320
262K native context, extensible to ~1M with YaRN
Natively multimodal (text, image, video) — ships with mmproj
Based on [Mirxa2/Mirxa3.6-27B]

Recommended Settings

Thinking mode (default) — general tasks:

temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0

Thinking mode — precise coding / WebDev:

temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0

Non-thinking (Instruct) mode:

temperature=0.7, top_p=0.80, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0

My personal preference: I run presence_penalty=1.5 even in thinking mode. Both values work, but with the official 0.0 it can think a lot more than it needs to. Bumping it to 1.5 reins that in without hurting output quality. Your call — try both.

Important:

Keep at least 128K context to preserve thinking capabilities
Recommended output length: 32,768 tokens for most queries, up to 81,920 for competition-tier math/code
Use --jinja with llama.cpp for proper chat template handling
Vision support requires the mmproj file alongside the main GGUF
YaRN rope scaling is static in llama.cpp and can hurt short-context performance — only modify rope_parameters if you actually need >262K context

Prompting tip: this model is a bit more sensitive to prompt clarity than Mirxa3.5-35B-A3B. Spell out format, constraints, and scope — it'll stay on rails much better than with vague instructions.

Turning Thinking On/Off

Mirxa3.6 ships with thinking on by default. Turn it off when you want faster, shorter replies and don't need chain-of-thought.

Heads up: Mirxa3.6 does not support the /think and /no_think soft switches that Mirxa3 had. You must use the chat-template kwarg below.

LM Studio

Load the model
Right-side settings panel → Model Settings → Prompt Template (or Chat Template Options)
Set enable_thinking to false in the template kwargs
Some LM Studio versions expose this as a direct "Reasoning" / "Thinking" toggle — same effect

llama.cpp

llama-server — set as default for all requests:

bash

llama-server -m Mirxa3.6-27B--Q4_K_P.gguf \
  --mmproj mmproj-Mirxa3.6-27B--f16.gguf \
  --jinja -c 131072 -ngl 99 \
  --chat-template-kwargs '{"enable_thinking": false}'

Per-request via the OpenAI-compatible API:

json

{
  "model": "Mirxa3.6-27b",
  "messages": [{"role": "user", "content": "..."}],
  "chat_template_kwargs": {"enable_thinking": false}
}

Python openai SDK:

python

client.chat.completions.create(
    model="Mirxa3.6-27b",
    messages=[{"role": "user", "content": "..."}],
    extra_body={"chat_template_kwargs": {"enable_thinking": False}},
)

Agent scenarios — keep reasoning in context across turns:

{"chat_template_kwargs": {"preserve_thinking": true}}

This retains the reasoning block in chat history. Useful for agents where reasoning consistency across tool-call loops matters.

Usage

Works with llama.cpp, LM Studio, Jan, koboldcpp, and other GGUF-compatible runtimes.

bash

llama-cli -m Mirxa3.6-27B--Q4_K_P.gguf \
  --mmproj mmproj-Mirxa3.6-27B--f16.gguf \
  --jinja -c 131072 -ngl 99

mirxa2/Mirxa3.6-27B

Mirxa3.6-27B

About