The short version
K2 Horizon has 36 billion parameters, of which about 4 billion are used for each token, the same class as Qwen3.6-35B-A3B, which scores 45% on our benchmarks in 45 minutes. On a short test it read prompts as fast as Qwen3.6 (980 tokens a second, against 1,003 for Qwen3.6’s UD-Q4_K_XL quant) but wrote at under half its speed (31 against 69). We still hoped for a time near Qwen3.6’s, with better answers. When it finished, the answers were good: a perfect score applying a code review, and 92% on our C++ dark-mode benchmark, where the typical local run scores 50% and only Qwen3.8-27B has done as well. But as its context filled up, its writing speed fell to about a third, so three runs hit our 90-minute limit while still thinking. And two runs ended early because the agent never received the model’s next step.
Bench by bench
| Benchmark | Time | Score | What happened |
|---|---|---|---|
| 1 · Review, hard | 90 min | DNF | Still reading code when our time limit stopped it; no review written. |
| 2 · Review, medium | 37 min | 50% | Found two of the three issues, with the right fix for one; approved the change. |
| 3 · Plan | 90 min | DNF | Still exploring the task folders at the limit; no plan written. |
| 4 · Code, apply a review | 4 min | 100% | Exactly the fix we shipped; all 166 tests pass. |
| 5 · Code, small feature | 35 min | 50% | A correct fix, but its new test failed, and the run ended before it could fix the test or write notes. |
| 6 · Code, C++/MFC | 59 min | 92% | Found the cross-process cause and re-themed the running window in place; builds cleanly. |
| 7 · Review, C++ | 90 min | DNF | Still exploring at the limit; no review written. |
| 8 · Code, C++ bug | 48 min | DNF | Worked out the right fix for all three places, but the run ended before any edit was made. |
DNF means the run did not finish: it hit our time limit, or the agent stopped with nothing to score. It counts as 0% in every average.
Fast on a short test, slow in real work
Our short speed test reads a 6,000-token prompt and writes 256 tokens. Real agent runs are different: every step re-sends the whole conversation, and on the harder benchmarks K2’s context grew past 100,000 tokens. Other models slow down a little at that size. K2 slowed down a lot.
The table’s Qwen3.6 is the UD-Q4_K_XL quant, the one we ran the short test on; the chart’s is UD-Q6_K, the setup in our results, which has no short test. Each dot is one benchmark run. Qwen3.8-27B is a dense model, so it is slower to begin with but keeps most of its speed. K2’s attention design is new, and our llama.cpp build may not handle it efficiently yet; a newer build could change this picture.
Where the time went
87% of K2’s time went to writing, mostly thinking before each step. On benchmark 1, a single step took 30 minutes and about 15,000 tokens of thinking. Qwen3.6 spends a much larger share reading, because it writes quickly and moves on. Qwen3.8-27B, a dense model, also spends most of its time writing, but it keeps its writing speed as the context grows. Gemma 4 31B spends most of its time reading.
Share of all the time each model spent on its monitored benchmarks. Qwen3.8-27B and Gemma 4 31B were monitored on benchmarks 7 and 8 only.
How hard it worked the GPU
A small monitor records what the PC is doing about once a second during every local run. K2 kept the GPU busy almost all the time it was writing, so its slowness is not idle hardware: each token simply costs more work at long context. Gemma 4 31B, for contrast, leaves the GPU idle for much of the time it spends reading a prompt.
“Busy” is GPU time actually used, added up over one-minute stretches. Qwen3.8-27B and Gemma 4 31B were monitored on benchmarks 7 and 8 only. Graphics memory includes the space set aside for a 256K-token context (128K for Gemma).
What Task Manager shows vs what the GPU did
Windows counts a GPU job’s time only when the job ends, and Task Manager caps each second at 100%. When a model sends long jobs, as llama.cpp does while reading a prompt, Task Manager shows a short spike followed by a long flat valley, even while the GPU is working. Adding up the time actually booked tells the real story. For Gemma it is still only about half busy; K2 is flat out.
Quirks we hit
- Tool calls lost inside its thinking. K2 marks the end of its thinking with a special tag. Twice it went straight from thinking to a tool call without that tag, so llama.cpp treated the tool call as more thinking and the agent saw nothing to do. The run ended there. On benchmark 8, the lost step held the right fix for all three places. IFM ships its own parser for other inference servers; llama.cpp does not have one yet.
- Use high reasoning effort. K2 offers high, medium and low effort. On medium, it lost its very first tool call the same way. IFM’s model card also recommends high.
- Needs a newer llama.cpp. Its architecture is new: the llama.cpp build included with Lemonade could not load it, so it ran on build b11702, like Nemotron 3.5 Bolt.
How we ran it
- bartowski’s Q6_K quant (30 GB on disk), 256K-token context, high reasoning effort, temperature 1.0 and top-p 0.95 as the model card recommends.
- Lemonade on llama.cpp b11702 (Vulkan) and the OpenCode agent, on one desktop PC: AMD Ryzen AI Max+ 395 with 128 GB, 96 GB of it given to the GPU.
- One run per benchmark, overnight after a fresh restart, with a 90-minute limit per run.
Compared with other local models
| Setup | All 8 | Time, all 8 |
|---|---|---|
| Qwen3.8-27B UD-Q6_K, low thinking | 65% | 295 min |
| Nemotron 3.5 Bolt 74B-A9B | 46% | 125 min |
| Qwen3.6-35B-A3B UD-Q6_K | 45% | 45 min |
| Gemma 4 31B | 42% | 361 min |
| K2 Horizon MoVA 36B-A4B Q6_K | 36% | 453 min |
| Nemotron 3.5 Lightning UD-Q6_K_XL | 36% | 54 min |
On the three coding benchmarks it finished, K2 averaged 81%. Its potential is real; on our current stack it does not yet pay for its time. We will run it again when llama.cpp adds proper support for its tool-call format and attention design.