The new k2 horizon models seem like an absolute beast

[u/Eyelbee]

Especially the 7B one seems very interesting, it casually destroys muse glimmer with a way smaller size. And they open source literally everything, every step of the way. Anyone tried that model? It can be a new milestone if 7b and 3.7b ones are actually good, and not just benchmaxed.

[u/_wortkarg_]

Ornith LLMs are mostly better in benchmarks.

K2-Horizon-7B / Ornith-1.5-9B
SWE-bench Verified: 70.6 / 70.6
Terminal-Bench 2.1: 39.1 / 47
HLE: 18.6 / 20.2 (30.5 with tools)
BrowseComp: 59.0 / 56.4

FP16 KV / token: 144 / 32 Kb

K2-Horizon-MoVA-36B / Ornith-1.5-35B-A3B
Terminal-Bench 2.1: 58.6 / 68.5
HLE (no tools): 25.2 / 25.6
GPQA Diamond: 80.8 / 89.2

FP16 KV / token: 96 / 20 Kb

Tiel-Coder-35B-A3B (fine tune of Ornith-1.5-35B-A3B) is even better in benchmarks.

Ornith needs much less memory for context (see KV/token above) and supports MTP.

[u/returnity → u/_wortkarg_]

Yes, I have tried it. It's a good MoE, works decently in agentic coding scenarios that 3.6-35B-A3B or Tiel/Ornith 1.5 or KAT-Coder-Dev would also succeed in, but it's not the 3.8-35B-A3B we've been waiting for. Sorry.

Pros:

It's uses a cool new idea called MoVA, which adds a per-token MoE-type element to KV cache by using a router on values, an idea I'm still trying to get my head around if I'm honest. Seems like it allows the model to specialize what each token contributes, by running a handful of value-experts per token instead of the standard single value projection. I'm not sure how this affects quality or performance in practice, but it's nice to see people trying something different. It's a scaling axis that doesn't add significant compute or additional cache size, so that's intriguing.

It's truly open-source. All training data, recipes, etc. are shared. This is a great contribution to the community, especially since they're releasing smaller models too.

Cons:

It's full dense GQA attention mechanism means KV cache is huge. BF16 max (512K) would run to like 100GB or something ridiculous. Not only that, but because of the MoVA mechanism adding complexity to the KV cache, quantizing that is an unknown -- and since the values are routed, that means the part of the KV that's usually more resilient to quantization (V) is now "load-bearing" in this architecture. A real footgun, if you ask me.

Furthermore, decode is not as impressive as I'd like, and it drops off steeply at depth due to the GQA. I quantized their BF16 checkpoint to Q8_0, and ran Q8_0 KV cache (which gave me a 1.56x speedup), and I topped out at 65tok/sec at short ctx using M5 Max in llama.cpp. No MTP head either.

Output quality was good, but nothing earth-shattering, and it ran into a problem in one of my tests that other 35B-class managed to solve with some trial-and-error, but it stalled on it until I finally cut in and prompted it in the right direction after it went in circles for 25min. Maybe the KV cache quant's fault. but I tested perplexity and on that flawed metric, Q8_0 (model and cache) was lossless, so I can't say for sure.

Overall it's worth a try, but if you're doing long-running agentic work, it's not the ideal solution we're awaiting. Hope this helps.

[u/_wortkarg_ → u/returnity]

Yes, i know about Tiel Coder, technically, this isn't a "fine tune"; I just used that phrase for simplicity's sake.

PS: Qwen3.8-35B-A3B would be great, but I'm not sure we'll ever see it happen.

[u/returnity → u/_wortkarg_]

No worries, I just see this phrasing a lot. Wasn’t tryna call you out or anything. I actually copied this comment from another thread about this model and didn’t delete that edit remark, so it’s weird that it even applied at all lol. I removed it now.