K2 Horizon Tested Locally: 0.9B, 7B, 32B Results Are Rough
Hands-on local testing of K2 Horizon's 0.9B, 7B, and 32B models on coding and multilingual tasks shows an early checkpoint with real bugs.
What is K2 Horizon and who built it?
K2 Horizon is a family of six open language models released by the Institute of Foundation Models (IFM), the AI research arm of MBZUAI, a university in Abu Dhabi with additional labs in Paris and Silicon Valley. The lineup spans from a tiny 0.9 billion parameter model up to a 375 billion parameter mixture-of-experts flagship, with a 3.7B and other sizes in between. IFM released all six under Apache 2.0, along with training data, checkpoints, and code, which puts K2 Horizon among the more fully open model releases this year, not just open weights.
The name comes from K2, the world’s second-tallest mountain, located in Pakistan. It’s a popular name in open-model circles, and this K2 has no relation to other models that have used it before.
TL;DR
- Three sizes run on a single GPU: the 0.9B, 7B, and 32B models are small enough for one-GPU deployment via vLLM, while the 3.7B and the 375B MoE flagship sit outside that scope.
- Context windows differ sharply by size: the 0.9B model tops out at 128K tokens, while the 7B and 32B both stretch to 512K.
- Benchmark strengths are size-specific: the 0.9B model leads on AIME 2026 math and BFCL tool-calling, the 7B wins on SWE-bench and terminal-bench (agentic coding), and the 32B pulls far ahead on GPQA Diamond (82 vs 27), a graduate-level science reasoning test.
- Hands-on coding tests exposed real problems: a from-scratch HTML/CSS/JS animation task (a rotating doner kebab in front of a vertical broiler) produced non-functional or visually broken output across all three sizes.
- Tool calling didn’t work in vLLM: the built-in tool parser failed to save files or execute tool calls as instructed, forcing a workaround via a separate Python script.
- Multilingual quality drops off hard for low-resource languages: major languages like English, Spanish, French, Russian, Polish, and Czech translated cleanly, but Bengali, Swahili, Tamil, Punjabi, and Urdu produced garbled, mixed-script text with English words bleeding in.
- This is explicitly a stage-one checkpoint, not a final release, which explains some rough edges, though IFM’s own blog post describes a full post-training pipeline (mid-training, SFT, model merging, RL, and agent training) that would normally produce more polish.
How do the three sizes compare on paper?
According to IFM’s own comparison, each model size has a distinct “moment” on benchmarks rather than one model simply beating the others across the board:
- 0.9B: strongest on AIME 2026 (math reasoning) and BFCL (tool-calling benchmark), which is notable for a model this small and suggests it’s tuned for edge or on-device use where compact tool use matters more than raw knowledge.
- 7B: wins on SWE-bench and terminal-bench, both of which test real software engineering and agentic terminal work rather than static Q&A. This points to the 7B as the pick for local coding assistance on a workstation.
- 32B: dominates GPQA Diamond, a graduate-level science reasoning benchmark, scoring 82 versus 27 for comparison. This is the model IFM positions for heavier reasoning tasks.
Context window length also scales unevenly: 128K for the 0.9B, and 512K for both the 7B and 32B, a jump that matters for anyone doing long-document or long-codebase work.
What happened when the models were tested locally?
Testing was done on a machine with 96GB of VRAM, running Ubuntu, with models served through vLLM.
VRAM footprint: the 32B model consumed roughly 92GB of VRAM with KV cache enabled at a 65K token context. The 7B model used around 16.76GB. The 0.9B model needed just over 2GB even with KV cache. For anyone planning local deployment, the 7B is the practical sweet spot for a single consumer or prosumer GPU, while the 32B effectively requires a high-VRAM card like an A100 or H100-class GPU, or renting cloud GPU time.
Coding test: the task was to build a self-contained HTML file simulating a rotating doner kebab skewer in front of a vertical gas broiler, from scratch, with no reference chart or scaffolding. Results were disappointing across the board:
- The 32B model took over 30 minutes to respond and produced an HTML file with a “not earth-shattering” but not entirely broken thinking trace. The output, however, didn’t actually work when opened, containing bugs that prevented it from rendering or running properly.
- The 7B model’s output was described bluntly as not resembling anything close to a working kebab animation.
- Both models failed to save the file via tool call despite explicit instructions and tool calling being enabled, forcing a manual save and, for later tests, a workaround Python script instead of relying on vLLM’s tool parser.
Multilingual test: a single sentence was translated into a wide set of languages, from high-resource (English, Spanish, French, Russian, Polish, Czech) to low-resource (Bengali, Swahili, Tamil, Punjabi, and others, including Urdu). Across all three sizes, high-resource languages came out clean and usable. Low-resource languages fell apart, producing mixed-script, garbled text with untranslated English words bleeding into the output. One notably strange result surfaced in the Urdu translation, where unrelated strings like “AWS” appeared for no clear reason.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
Interestingly, the 32B model’s reasoning trace showed the model visibly second-guessing and self-correcting sentence by sentence on harder languages, indicating it was not confidently hallucinating even when its output was wrong. That’s a small positive signal about calibration, even if the final translations weren’t usable.
Is K2 Horizon worth running right now?
Based on this round of local testing, the honest answer is: not yet, at least not for coding or multilingual production work. All three single-GPU sizes struggled with a from-scratch coding task that required no external references, and tool calling didn’t function correctly through vLLM’s parser for any of them. Multilingual performance was solid for major world languages but broke down badly for low-resource ones, which matters if your use case involves anything beyond English/European-language text.
The mitigating factor is that this is explicitly a stage-one checkpoint, not IFM’s final release. That said, IFM’s own materials describe K2 Horizon as having gone through a full modern post-training pipeline (mid-training, supervised fine-tuning, model merging, reinforcement learning, and specialized agent training), which is the same pipeline used to produce polished instruct models elsewhere. That raises a fair question about why a checkpoint at this stage of training shows this many rough edges, particularly around tool use and code generation reliability.
The openness of the release (Apache 2.0 weights, training data, checkpoints, and code) is genuinely valuable for researchers who want to study or fine-tune on top of it, regardless of current benchmark performance. Anyone evaluating it for production coding or multilingual deployment today should test rigorously first and treat this as an early-access release rather than a finished product.
Frequently Asked Questions
What is IFM, the lab behind K2 Horizon?
The Institute of Foundation Models (IFM) is the AI research arm of MBZUAI, a university based in Abu Dhabi that has also built out research labs in Paris and Silicon Valley. K2 Horizon is one of its recent open model releases.
Which K2 Horizon size can I run on a single GPU?
The 0.9B, 7B, and 32B models are all sized to run on one GPU. The 0.9B needs roughly 2GB of VRAM, the 7B around 17GB, and the 32B around 92GB with KV cache enabled, so the 32B effectively requires a high-VRAM data center GPU or cloud rental.
Does K2 Horizon support tool calling?
Tool calling is technically enabled in the release, but in local testing through vLLM, the tool parser failed to execute basic instructions like saving a file, requiring a manual workaround using a separate Python script.
How good is K2 Horizon at multilingual translation?
It handles major world languages (English, Spanish, French, Russian, Polish, Czech) reasonably well, but performance drops sharply for low-resource languages like Bengali, Swahili, Tamil, and Punjabi, producing garbled, mixed-script output.
Is this the final version of K2 Horizon?
No. The version tested is described by IFM as a stage-one checkpoint, not a final release, which may account for some of the rough edges observed in coding and tool-calling behavior.