01
Quick recommendation
Choose 0.9B when footprint is the primary constraint and you are targeting edge-class hardware. Choose 3.7B for small local experiments where efficiency matters. Choose 7B when you want the strongest broadly practical local starting point. Choose 32B for workstation or server resources, 36B-A4B when sparse active compute and MoVA fit your serving stack, and 375B-A23B for enterprise-scale inference.
02
0.9B, 3.7B and 7B: edge to practical local use
IFM positions 0.9B for highly constrained environments such as watches and glasses. That positioning does not mean every wearable can run the unmodified checkpoint; actual deployment still depends on quantization, runtime, memory and device acceleration.
The 3.7B model is a small dense option with a native 524,288-token context window. Its current official model card reports 68.6 on SWE-bench Verified and 25.1 on Terminal-Bench 2.1 under IFM’s evaluation setup.
The 7B model is the family’s medium dense option and a sensible general local starting point. Its current official card reports 70.6 on SWE-bench Verified, 39.1 on Terminal-Bench 2.1 and 59.0 on BrowseComp. Those results are vendor-reported, and IFM notes that some comparison protocols differ.
03
32B, 36B-A4B and 375B-A23B
The 32B model is a dense workstation/server-class option for users who want more capacity without moving to the flagship. All parameters participate in the standard dense forward computation.
The 36B-A4B model is structurally different: IFM describes it as roughly 36B total parameters with about 4B active under a sparse MoVA architecture. The A4B label therefore does not make it equivalent to a dense 4B checkpoint; storage and memory behavior still reflect a much larger model.
The 375B-A23B flagship activates about 23B parameters and is positioned for demanding enterprise reasoning and agentic workloads. Sparse activation reduces active compute, but the total checkpoint remains extremely large and belongs in serious infrastructure or hosted-inference discussions.
04
Dense vs sparse: compare more than active parameters
Dense variants are straightforward: the full parameter set participates in the forward computation. Sparse variants contain more total parameters but activate a subset per token or operation.
That can lower active compute without making total storage requirements disappear. Comparing 36B-A4B directly with a 7B dense model only as ‘4B active versus 7B’ hides architectural, storage and serving differences. Measure latency and memory on the stack you actually plan to use.
05
Which K2 Horizon model is best for local use?
For most developers, 3.7B and 7B are the clearest practical starting points because official cards document serving paths and quantization discovery while keeping model size far below the larger workstation and enterprise variants.
The separate local-running guide covers Transformers, vLLM, SGLang and GGUF setup in detail. Move to 32B or 36B-A4B only when your own evaluations justify the extra infrastructure and your runtime supports the architecture well.
06
Choosing for coding and agents
IFM reports strong coding and agentic results across the family, but benchmark rank alone should not choose a production model. Test your own repository, tool-use behavior, context requirements and latency.
For a local agent baseline, 7B is a reasonable place to start, then move upward only if your evaluation shows a meaningful gain. A smaller model that responds quickly and reliably with your tools can be operationally better than a larger checkpoint with a higher vendor benchmark.
07
Context length changes the deployment equation
The current 3.7B and 7B cards document native 524,288-token context. Long context can dramatically increase KV-cache memory and latency, so support for 512K does not mean every local request should run at the maximum.
Choose a context window around the actual task and available memory. Model size is only one part of the deployment decision.
08
K2 Horizon model-selection FAQ
- Smallest model: 0.9B.
- Largest model: 375B-A23B.
- A4B meaning: roughly 4B active parameters in the 36B sparse model, not a dense 4B checkpoint.
- Practical local starting point: usually 3.7B or 7B, depending on hardware and quantization.
- Universal best model: none—choose by workload and deployment constraints, then validate on your own evaluation set.
For the broad release, licensing and API picture, return to the main K2 Horizon guide. For implementation details, continue to the local-running guide.
Sources
Primary and supporting sources
Facts were rechecked against the linked sources immediately before publication. Pricing, product availability and rollout status can change.