devmaksi/KAT-Coder-V2.5-Dev-NVFP4-freetoken

KAT-Coder-V2.5-Dev

This is a locally NVFP4-quantized copy of the post-trained KAT-Coder-V2.5-Dev (see About this NVFP4 quantization), served with FreeToken. Note: this release ships only the language-model weights and operates as a text-only model; the vision/multimodal components are not included and are unavailable.

Following the release of KAT-Coder-V2.5 in July, we are pleased to release the open-weight version KAT-Coder-V2.5-Dev, an MOE model with a total parameter count of 35B and 3B activated parameters, to strengthen communication with the community and showcase our research achievements.

KAT-Coder-V2.5-Dev Highlights

• Performance improvement. Through SFT/RL training, KAT-Coder-V2.5-Dev achieves SOTA results in the field of Agentic Coding among models with similar parameter scales.
• Optimization of abnormal behaviors. Through RL training, certain abnormal behaviors have been significantly optimized, such as: abnormal tool labels -9pp (9.34% -> 0.28%), single-turn continuous repetition -0.34pp (0.34% -> 0%).

Benchmark performance

Benchmark	KAT-Coder-V2.5-Dev	Qwen3.5-27B	Qwen3.6-35BA3B	Gemma4-31B	Qwen3.5-35BA3B	Ornith-1.0-35B	Gemma4-26BA4B	Qwen3-Coder-30B
Coding Agent
SWE-bench Verified	69.40	68.60	64.40	60.60	58.60	55.80	35.80	31.80
SWE-bench Multilingual	63.00	57.67	57.00	49.33	47.67	51.67	27.33	20.67
SWE-bench Pro	45.96	42.13	40.63	32.97	38.03	34.47	9.58	19.84
Terminal-Bench 2.1	41.02 32.60 / 49.44	34.84 41.57 / 28.10	32.02 34.83 / 29.20	32.59 30.34 / 34.83	26.12 26.44 / 25.80	35.98 35.96 / 36.00	20.94 27.27 / 14.60	13.50 10.11 / 16.90
PinchBench	93.43	90.71	92.21	85.53	88.75	91.62	82.01	72.3
Scicode	44.20	25.58	37.53	33.19	27.73	30.34	30.84	18.27
KAT-Code-Bench	46.21	44.83	42.76	37.93	35.86	33.10	22.06	15.17

_{For Terminal-Bench 2.1, the bold number is the average across two agent harnesses; the small numbers below are the per-harness scores (Terminus-2 / Claude Code).}

1. Evaluation method. All metrics presented in the table are reproduced in-house: we download the public model checkpoints, deploy them via vLLM or SGLang, and evaluate under a unified standardized pipeline. No officially reported results of the respective models are directly adopted in this table. Each model is tested only once on each evaluation set; retests are conducted only if obvious errors are found.

2. Evaluation configuration.

* SWE-bench Verified / Multilingual / Pro, KAT-Code-Bench: agent=claude_code@2.1.195, pass@k=1, temperature=1.0, top_p=0.95, 256k ctx.

* Terminal-Bench 2.1: agent=terminus-2 / claude_code, pass@k=1, temperature=0.7, top_p=1.0, 256k ctx.

* PinchBench: agent=openclaw@2026.3.13, pass@k=1, temperature=0.7, top_p=1.0, 256k ctx.

* Scicode: pass@k=1, temperature=0.6, top_p=1.0, 256k ctx.

3. Anomaly description.

* Qwen3.6-35BA3B: We found that on the SWE-bench Verified, SWE-bench Multilingual, and SWE-bench Pro test sets, our test results this time have an approximate 10 pp gap compared with the official results. We believe this is mainly caused by the harness version and some optimizations made to the test sets by the Qwen team, and it should not be an issue with the model itself.

* Qwen3.5-35BA3B: We observed frequent hallucinations during evaluation, including attempts to invoke the unavailable MultiEdit tool under the current agent environment, which negatively impacts the final metric.

* Gemma4-26B-A4B-it: Two main factors degrade evaluation performance: context overflow (exceeding the 256k context limit) and hallucinated calls to the unsupported MultiEdit tool in this evaluation setup.

The above deviations arise from mismatches between model tool preference and the allowed toolset in the evaluation harness, rather than inherent capability limitations of the models.

Post-training

To provide a systematic overview of our team's work on data and algorithms, we adopt the widely recognized Qwen3.6-35B-A3B as the base model for post-training and build KAT-Coder-V2.5-Dev on top of it. Overall, KAT-Coder-V2.5-Dev largely follows the post-training recipe of KAT-V2.5, with most settings—including data construction, training pipeline, and optimization strategy—remaining unchanged. The full pipeline consists of two stages: supervised fine-tuning (SFT) and reinforcement learning (RL). We first fine-tune Qwen3.6-35B-A3B on a dataset of 127K examples and then perform RL training on the resulting SFT model.

During the RL stage, we retain the training infrastructure and key technical designs validated in KAT-V2.5, including the following four components:

1. Token-in-Token-out (TITO) consistency. We use TITO to ensure that the token sequences in the rollout and training stages are strictly identical, preventing training discrepancies caused by differences in chat templates, serialization, or tokenizer behavior.
2. Truncated Importance Sampling (TIS). To mitigate policy staleness and off-policy issues introduced by asynchronous rollouts, we apply TIS to truncate importance-sampling weights, reducing the variance and instability caused by excessively large weights.
3. Reliable sandboxes and verifiers. We systematically inspect and validate the stability and correctness of the sandboxes and verifiers. This helps prevent infrastructure failures—such as execution timeouts, environment errors, or verifier misjudgments—from being incorrectly treated as model failures and contaminating the reward signal.
4. Hierarchical rewards based on harness execution feedback. We construct hierarchical rewards from fine-grained execution feedback provided by the harness. This allows the model to optimize toward the final task objective while also receiving credit for meaningful progress in unsuccessful trajectories, thereby increasing the training value of failed attempts and providing denser reward signals.

However, Qwen3.6 exhibits trajectory patterns that differ from those observed in KAT-V2.5, requiring additional reward adaptations tailored to its behavior. In our initial experiments, a simple binary 0–1 reward caused model collapse as early as the second epoch. An analysis of the training trajectories revealed that, as training progressed, the model increasingly tended to issue a large number of parallel tool calls within a single turn—occasionally exceeding 70 calls. This behavior caused the context length to grow rapidly, generated a substantial number of invalid trajectories and execution errors, and ultimately destabilized RL training.

To address this issue, we augmented the original hierarchical reward with several Qwen3.6-specific penalties targeting (including but not limited to the following):

• Excessive parallel tool calls within a single turn;
• Failed tool calls;
• Empty tool-call blocks; and
• Large amounts of repeated content.

These targeted reward adjustments effectively suppressed pathological tool-use and repetitive-generation behaviors, enabling stable RL training for 10 epochs. Our experiments validate the effectiveness and feasibility of both the overall training pipeline and the Qwen3.6-specific reward design.

_{The proportion of samples that pass the unit test (1 for pass, 0 for fail) within a batch of samples during RL training.}

About this NVFP4 quantization

This directory is a locally quantized copy of KAT-Coder-V2.5-Dev (bf16). The original checkpoint in ../KAT-Coder-V2.5-Dev is untouched.

What changed vs the unquantized model

Component	Was (bf16)	Now	Why
Routed MoE experts (gate/up/down, 256 experts x 40 layers)	bf16, 65 GB total	NVFP4: packed e2m1 codes (2 elems/byte) + e4m3 per-16-element block scales + per-tensor global scales (ModelOpt convention: w = fp4 * scale * (1/weight_global_scale))	The experts are ~90% of all weights. FP4 cuts them ~4x; on Blackwell (RTX 50-series) FP4 runs on tensor cores. The MoE experts are read by FreeToken's offload cache from the packed NVFP4 banks without dequantization
Attention and GDN projections (q/k/v/o, in_proj_qkv, in_proj_z, out_proj)	bf16	Block FP8, 128x128 blocks: e4m3 weights + bf16 scale_inv	FP8 keeps attention quality near-lossless (cosine 0.9997 vs bf16 on test tensors) and these layers are latency-critical
Router, shared expert, in_proj_b/a, norms, embeddings, lm_head	bf16	bf16 (unchanged)	Small tensors; quantizing them saves little and risks quality (router logits, first/last projection)
Vision weights	not present	not present	The open-weight release ships no vision tower; serve text-only

Overall: 65 GB -> 21 GB (6 shards). Weight layout follows the compressed-tensors (llm-compressor) NVFP4 dialect that FreeToken reads for the Qwen3.5-MoE architecture.

Quality

• Round-trip through FreeToken's own NVFP4 dequant kernel: cosine 0.994, ~10% mean relative error - typical for RTN FP4 without calibration.
• Verified live: server starts, /v1/chat/completions produces coherent code (reasoning + answer), long-context prefill and decode work at 128k and 200k.

Measured throughput (RTX 5080 16GB, KV cache 210k tokens)

Context	Prefill	Decode
128k tokens	28 s (4,550 tps)	~84 tps
200k tokens	49 s (4,000 tps)	~78 tps

Reproducing

quantize_kat_nvfp4.py in the FreeToken repository root reproduces this checkpoint from the bf16 original.

Quickstart

For streamlined integration, we recommend using KAT-Coder-V2.5-Dev via APIs. Below is a guide to use KAT-Coder-V2.5-Dev via OpenAI-compatible API.

Serving the NVFP4 checkpoint with FreeToken

FreeToken reads this NVFP4 checkpoint directly - no conversion step needed. FreeToken serves OpenAI /v1/*, Anthropic /v1/messages and Responses APIs, with chunked prefill, paged KV / radix cache and MoE expert offload.

Note: serve with --text-model-only: this checkpoint carries no vision weights, and the Qwen3_5MoeForConditionalGeneration architecture makes FreeToken build (and expect) a vision tower unless disabled.

From the FreeToken repository root:

./run-kat-nvfp4.sh

This starts the API server on http://127.0.0.1:1919 with sensible defaults for this checkpoint. Equivalent manual command:

ft serve \
    --model /path/to/KAT-Coder-V2.5-Dev-NVFP4 \
    --text-model-only \
    --port 1919

• Tool use and reasoning are auto-detected from the checkpoint (Qwen tool-call parser, reasoning parser splits chain-of-thought into reasoning_content).

• Long context: the server sizes the KV cache from free VRAM automatically. To raise it explicitly (e.g. for 200k+ tokens of headroom on a 16 GB GPU):

  ft serve --model /path/to/KAT-Coder-V2.5-Dev-NVFP4 --text-model-only --port 1919
  # then, live, without a restart:
  ft ctl cache --kv 210000 --moe 2000 --wait 300
  

• Chat in the terminal:

  ft shell --model /path/to/KAT-Coder-V2.5-Dev-NVFP4
  

• Hook up a coding agent (Claude Code, Codex, OpenCode, ...):

  ft launch opencode
  

See the FreeToken CLI reference for all options.

Note: this NVFP4 checkpoint is in FreeToken's compressed-tensors NVFP4 dialect. Other frameworks (transformers, KTransformers) do not read this format; use the original bf16 checkpoint for them.

Using KAT-Coder-V2.5-Dev via the Chat Completions API

The chat completions API is accessible via standard HTTP requests or OpenAI SDKs. Here, we show examples using the OpenAI Python SDK.

Before starting, make sure it is installed and the API key and the API base URL is configured, e.g.:

pip install -U openai

# Set the following accordingly
export OPENAI_BASE_URL="http://localhost:8000/v1"
export OPENAI_API_KEY="EMPTY"

Text-Only Input

from openai import OpenAI
# Configured by environment variables
client = OpenAI()

messages = [
    {"role": "user", "content": "Type \"I love KAT-Coder-V2.5-Dev\" backwards"},
]

chat_response = client.chat.completions.create(
    model="Kwaipilot/KAT-Coder-V2.5-Dev",
    messages=messages,
    max_tokens=81920,
    temperature=1.0,
    top_p=0.95,
    presence_penalty=1.5,
    extra_body={
        "top_k": 20,
    },
)
print("Chat response:", chat_response)

Instruct (or Non-Thinking) Mode

KAT-Coder-V2.5-Dev will think by default before response. You can obtain direct response from the model without thinking by configuring the API parameters. For example,

from openai import OpenAI
# Configured by environment variables
client = OpenAI()

messages = [
    {"role": "user", "content": "Write a Python function that returns the n-th Fibonacci number."},
]

chat_response = client.chat.completions.create(
    model="Kwaipilot/KAT-Coder-V2.5-Dev",
    messages=messages,
    max_tokens=32768,
    temperature=0.7,
    top_p=0.8,
    presence_penalty=1.5,
    extra_body={
        "top_k": 20,
        "chat_template_kwargs": {"enable_thinking": False},
    },
)
print("Chat response:", chat_response)

Preserve Thinking

By default, only the thinking blocks generated in handling the latest user message is retained, resulting in a pattern commonly as interleaved thinking. KAT-Coder-V2.5-Dev has been additionally trained to preserve and leverage thinking traces from historical messages. You can enable this behavior by setting the preserve_thinking option:

from openai import OpenAI
# Configured by environment variables
client = OpenAI()

messages = [...]

chat_response = client.chat.completions.create(
    model="Kwaipilot/KAT-Coder-V2.5-Dev",
    messages=messages,
    max_tokens=32768,
    temperature=0.7,
    top_p=0.8,
    presence_penalty=1.5,
    extra_body={
        "top_k": 20,
        "chat_template_kwargs": {"preserve_thinking": True},
    },
)
print("Chat response:", chat_response)

This capability is particularly beneficial for agent scenarios, where maintaining full reasoning context can enhance decision consistency and, in many cases, reduce overall token consumption by minimizing redundant reasoning. Additionally, it can improve KV cache utilization, optimizing inference efficiency in both thinking and non-thinking modes.

Processing Ultra-Long Texts

KAT-Coder-V2.5-Dev natively supports context lengths of up to 262,144 tokens. For long-horizon tasks where the total length (including both input and output) exceeds this limit, we recommend using RoPE scaling techniques to handle long texts effectively, e.g., YaRN.

YaRN is configured via the model configuration file: in config.json, change the rope_parameters fields in text_config to:

{
    "mrope_interleaved": true,
    "mrope_section": [
        11,
        11,
        10
    ],
    "rope_type": "yarn",
    "rope_theta": 10000000,
    "partial_rotary_factor": 0.25,
    "factor": 4.0,
    "original_max_position_embeddings": 262144
}

FreeToken reads max_position_embeddings from the checkpoint, so after the config edit the server picks the extended length up automatically:

./run-kat-nvfp4.sh

Citation

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

@misc{katcoder_v25_2026,
  title={{KAT-Coder-V2.5 Technical Report}},
  author={{KwaiKAT Team}},
  year={2026},
  month={July},
  eprint={2607.05471},
  archivePrefix={arXiv},
  primaryClass={cs.AI},
  url={https://arxiv.org/pdf/2607.05471}
}