IFM's K2-Horizon 7B Beats GPT-5 on Coding With 70.6 SWE-bench Score

The Institute of Foundation Models (IFM) has released K2-Horizon, an open-weight language-model family with three base sizes and an optional diffusion-decoding adapter. The checkpoints are available on Hugging Face under Apache 2.0. IFM says it will also publish the training data, recipes, code, and intermediate checkpoints, but those additional artifacts remain pending.

Every model uses the same vocabulary and chat templates, allowing applications to change serving tiers without rewriting prompts, tool schemas, or response handling. That common interface supports routing based on latency, cost, memory, and task difficulty.

One interface, four checkpoints

IFM provides detailed benchmark and training information for the MoVA and 7B checkpoints. The release contains less evidence for the 3.7B model, so teams considering that tier will need to measure its quality and throughput directly.

36B stored, 4B active

K2-Horizon-MoVA-36B-A4B combines a Mixture-of-Experts architecture with Mixture-of-Values attention. A conventional MoE routes each token through a subset of feed-forward experts. MoVA extends sparse routing into the attention block, reducing the parameters used to process each token.

The checkpoint contains 36 billion parameters and activates about 4 billion per token. The active count lowers per-token computation, while serving infrastructure must still store or shard the full 36 billion weights. IFM reports that the model outperforms listed dense open-weight models around 30B parameters and MoE systems with as many as 15 times its total parameter count on several reasoning and agent benchmarks.

Every K2-Horizon model was trained for a native context window of 524,288 tokens, or 512K, beginning in midtraining. That figure describes the trained window. KV-cache memory, attention cost, concurrency, and retrieval quality still determine whether using the full context is practical in production.

IFM’s results show the MoVA model performing strongly on tool use and terminal tasks, with weaker results in expert science and factual recall. Higher scores are better in the reported comparisons.

These figures come from IFM’s evaluation tables. Reliable comparisons require matching prompts, tool environments, sampling settings, model versions, and scoring harnesses.

The 7B targets coding and agents

K2-Horizon-7B uses a standard dense-transformer design and is positioned for deployments that need simpler serving than the sparse flagship. Its weights occupy roughly 14 GB at bfloat16 before runtime overhead, activations, and KV cache. Accelerator fit therefore depends on context length, concurrency, quantization, and the serving engine.

In IFM’s table, the 7B model leads the listed references across five math, software-engineering, reasoning, terminal, and browsing evaluations.

The reported 70.6 on SWE-bench Verified places the model well above Qwen3.5-9B’s listed 50.8. Its BrowseComp score of 59.0 also exceeds the release’s figures for GPT-5 at 54.9 and DeepSeek V4 Flash-0423 at 53.5. IFM used the Discard-all@95k context protocol described in the DeepSeek-V3.2 report, so results from other BrowseComp harnesses are not directly comparable.

Uno adds parallel diffusion decoding

K2-Horizon-7B-Uno attaches a diffusion adapter to the 7B base model. Diffusion decoding refines multiple token positions over several passes, reducing some of the sequential work required by conventional left-to-right generation.

IFM claims up to a 2.2-times decoding speedup with no quality loss. The adapter reuses the 7B base checkpoint, giving operators an autoregressive path and a diffusion path within the same model family. Real throughput will depend on output length, batch size, hardware, and runtime support, so the quality and latency claims require workload-specific testing.

Five RL specialists merge into one 7B

IFM describes a multi-stage training pipeline that moves from broad pretraining into long-context midtraining, specialist reinforcement learning, checkpoint merging, and supervised fine-tuning.

The 7B model follows the specialist RL and merge branch. The MoVA checkpoint proceeds from midtraining directly into supervised fine-tuning. Training separate policies can reduce cross-skill interference during RL, while weight merging introduces its own potential conflicts. The promised recipes and intermediate checkpoints would let researchers examine that tradeoff once IFM publishes them.

Serving hinges on custom parsers

K2-Horizon supports Transformers, vLLM, and SGLang. Transformers loading uses trust_remote_code=True, which executes Python code from the model repository. Production deployments should review that code and pin a specific model revision.

vLLM and SGLang require the dedicated k2_horizon reasoning and tool-call parsers. IFM provides the following SGLang configuration for the MoVA checkpoint:

python3 -m sglang.launch_server \
  --model-path IFM/K2-Horizon-MoVA-36B-A4B \
  --tp 2 --ep 2 --dtype bfloat16 \
  --attention-backend fa3 \
  --reasoning-parser k2_horizon \
  --tool-call-parser k2_horizon

This example uses two-way tensor and expert parallelism with the FlashAttention 3 backend. Operators will need to adjust the parallelism and attention backend for their accelerator topology and installed runtime.

IFM recommends the following generation and response settings:

• temperature=1.0
• top_p=0.95
• Reasoning depth selected per request through chat_template_kwargs
• Reasoning returned in reasoning_content
• Final answers returned in content
• Tool-call serialization available as json, xml, or xml_typed

The selectable tool format should ease integration with agent frameworks that already expect one of those schemas. Client libraries must preserve the separate reasoning and answer fields if an application needs both.

Benchmarks need production checks

K2-Horizon’s shared tokenizer and templates give agent platforms a consistent client contract across several compute tiers. The operational case depends on whether each checkpoint preserves prompt behavior, tool accuracy, and output structure when a router changes models.

A production evaluation should measure:

• Task success on representative prompts and tool workflows
• Factual accuracy, especially given the MoVA model’s reported recall weakness
• Latency and throughput at expected batch sizes and output lengths
• Weight, KV-cache, and activation memory at realistic concurrency
• Long-context retrieval quality across the advertised 512K window
• Parser compatibility with the selected vLLM or SGLang release
• Quality and speed of the Uno diffusion path on target hardware

Several parts of the release remain incomplete at launch, including the specialist RL checkpoints and the promised training artifacts. IFM points to its training repository for the code release. Until the remaining assets arrive, the immediately verifiable package consists primarily of the Apache-licensed model checkpoints, model cards, serving instructions, and reported evaluations.