AIREITERA six-model release from 0.9B to 375B sounds like a full deployment ladder, but the economics are less tidy. K2 Horizon’s Apache 2.0 license removes a model-license fee; MoVA reduces active computation; neither removes storage, KV-cache, runtime, or hardware costs.
What the six-model Apache 2.0 release includes
IFM announced K2 Horizon on September 3, 2026 as a connected fleet of six models: 375B-A23B, 36B-A4B, 32B, 7B, 3.7B, and 0.9B. The announcement says the models and code are released under Apache 2.0, while datasets use their applicable licenses (IFM announcement).
Six models, one fleet, uneven release maturity
The six family members are:
| Model | Architecture | Official positioning | Context stated in official materials |
|---|---|---|---|
| K2 Horizon 0.9B | Dense | Watches, glasses, constrained edge devices | 128K / 131,072 tokens |
| K2 Horizon 3.7B | Dense | Phones, fine-tuning, lightweight local work | 512K / 524,288 tokens |
| K2 Horizon 7B | Dense | Phones, local assistants, coding and agents | 512K / 524,288 tokens |
| K2 Horizon 32B | Dense | Workstations and on-premises servers | 512K / 524,288 tokens |
| K2 Horizon MoVA 36B-A4B | Sparse MoE + MoVA | Local and efficient serving | 512K / 524,288 tokens |
| K2 Horizon 375B-A23B | Sparse MoE | Enterprise and multi-accelerator deployments | 512K / 524,288 tokens |
The family shares architecture and deployment tooling, except that the 0.9B model uses a smaller vocabulary. That common base is intended to simplify migration or routing between sizes (IFM press release).
There is an important maturity qualification: the official K2-Horizon-32B card identifies the visible checkpoint as Stage1 and says the final checkpoint is still to be released. By contrast, the MoVA 36B-A4B and 375B-A23B cards describe their final checkpoints as released. “Six models announced” is accurate, but “six equally final production checkpoints” is not (32B model card, 375B model card).
What Apache 2.0 does—and does not—buy a self-hosting team
Apache 2.0 lets teams modify, redistribute, and commercially integrate the model and its code without a per-token fee. IFM says datasets follow their own terms, such as ODC-BY, and restricted sources may not be redistributed directly (IFM announcement).
Apache 2.0 removes a licensing charge, not the operating bill. GPU rental or depreciation, model storage, KV-cache capacity, runtime engineering, monitoring, and security review remain costs; the 36B serving recipe and 375B model card also show trust_remote_code=True in their examples.
The six sizes on a memory-first ledger
Parameter labels are useful for comparing model capacity, but raw weight storage is the first self-hosting constraint. The estimates below use two bytes per parameter for BF16 and one-half byte per parameter for an idealized 4-bit representation; they exclude metadata, runtime buffers, KV cache, tokenizer files, and operating-system memory.
| Model | Total parameters used for planning | Active parameters per token | Raw BF16 planning floor | Idealized 4-bit floor | Practical tier |
|---|---|---|---|---|---|
| K2 Horizon 0.9B | 0.9B | 0.9B | ~1.8 GB | ~0.45 GB | Edge and embedded experiments |
| K2 Horizon 3.7B | 3.7B | 3.7B | ~7.4 GB | ~1.85 GB | Compact local or mobile work |
| K2 Horizon 7B | 7B-class | 7B-class | ~14 GB* | ~3.5 GB* | First serious local test |
| K2 Horizon 32B | 32B | 32B | ~64 GB | ~16 GB | Workstation or server |
| K2 Horizon MoVA 36B-A4B | 36B | ~4B | ~72 GB | ~18 GB | Quantized workstation or multi-GPU serving |
| K2 Horizon 375B-A23B | 375B | ~23B | ~750 GB | ~187.5 GB | Enterprise or cluster-scale |
\*The 7B model card calls the model “7B-core,” while Hugging Face metadata displays 9B parameters. Capacity planning should use the actual repository files, not only the family label (7B model card).
The concrete repositories show why these are floors rather than promises. The 0.9B BF16 GGUF is listed at 2.16 GB, the 3.7B BF16 GGUF at 10.1 GB, the 32B Stage1 BF16 GGUF at 69.6 GB, and the MoVA 36B BF16 GGUF at 74.9 GB (0.9B GGUF, 3.7B GGUF, 32B GGUF, 36B GGUF).
The edge tiers: 0.9B, 3.7B, and 7B
0.9B and 3.7B minimize storage and suit constrained, focused workloads rather than recovery-heavy agents (0.9B model card, 3.7B GGUF card).
For a first local experiment, the 7B is the most documented option in the family: its card covers reasoning and tool-call parsers, a single-device tensor-parallel setting, and quantized variants. Its displayed benchmark table reports 70.6% on SWE-bench Verified, 39.1% on Terminal-Bench 2.1, and 25.8% on tau3-Banking, but all reported results use high reasoning effort and the card warns that protocol details can differ (7B model card).
The 7B card recommends high reasoning effort and at least 32,768 output tokens; longer reasoning increases generation time and can make a model that fits in memory expensive in wall-clock terms.
The local/server tiers: 32B and 36B-A4B
The 32B is fully dense and simpler to reason about, but its Stage1 status and official 69.6 GB GGUF are the real planning constraints (32B Stage1 GGUF).
The MoVA 36B-A4B model asks a different question: can a model with much lower active computation approach dense-model capability while retaining a larger total capacity? IFM’s GGUF benchmark table reports 26.8% on tau3-Banking and 58.6% on Terminal-Bench 2.1, where it leads the listed comparison set, but it does not lead on every science, factuality, or long-context measure (36B GGUF benchmark card).
Once weights are resident, its lower active-parameter count may improve sustained throughput, but the result depends on backend, batching, interconnect, and quantization.
The flagship tier: 375B-A23B
The official model card documents a validated SGLang configuration for K2 Horizon 375B-A23B using eight H200 GPUs, tensor parallelism of 8, expert parallelism of 8, BF16, and FlashAttention-3 (375B model card).
The total-to-active ratio can reduce computation relative to a dense 375B model, but the approximate 750GB BF16 planning floor still defines the infrastructure boundary. Artificial Analysis lists a 47 Intelligence Index score and a #11 of 112 position in its displayed class, yet reports no output-speed figure and no task-cost figure for the model (Artificial Analysis profile).
Based on the currently documented validated eight-H200 profile, treat this as a cluster-scale deployment.
MoVA changes compute economics, not the storage floor
MoVA stands for Mixture-of-Value Attention. Conventional mixture-of-experts designs usually put sparse routing in feed-forward layers; IFM describes MoVA as extending expert routing into the value component of attention while remaining compatible with techniques such as FlashAttention and grouped-query attention (IFM architecture explanation).
What the 36B-A4B label tells you
The “36B-A4B” name communicates two different quantities: roughly 36B total parameters are available, while roughly 4B are active for each token. That can reduce multiply-and-accumulate work and memory traffic for the active path, especially in workloads with sustained generation.
It does not imply that unused experts disappear. The official GGUF file is 74.9 GB at BF16, and the vLLM recipe describes a model with 37.44B stored parameters including embeddings and 5.95B active parameters per token. Those numbers are a packaging and accounting view of the same architecture, not evidence of a separate 37B model (vLLM recipe).
A useful mental model is:
- Resident capacity: storage and memory must hold the weights that may be selected.
- Active compute: each token exercises only a routed subset.
- Runtime state: KV cache, temporary buffers, batching, and framework overhead remain.
- System cost: interconnect, power, host RAM, and operational time determine the bill.
Why the 512K context headline is not a budget
The K2 Horizon cards advertise a native context of 524,288 tokens for the larger models. Yet the published vLLM recipes for both the MoVA 36B-A4B and 375B-A23B configure --max-model-len 131072, one quarter of that headline maximum (36B vLLM recipe, 375B model card).
The 131K recipes show that native 512K context is not a free serving default: longer contexts consume KV cache, reduce concurrency, and increase prompt latency.
Costed self-hosting scenarios
K2 Horizon has no transparent, universal API price to use as a baseline. The official MoVA GGUF page says no inference provider currently deploys the model, while Artificial Analysis shows $0.00 input and output prices for the 375B profile but also marks speed and cost per task as unavailable; that is not evidence of a free production endpoint (MoVA GGUF card, Artificial Analysis).
| Scenario | What it buys | Main economic risk | Verdict |
|---|---|---|---|
| 24GB-class GPU with a suitable 4-bit 36B quant | Low-cost experimentation and privacy | Little context/concurrency headroom; quant and runtime support may be immature | Best for a pilot, not a guaranteed production target |
| 32B BF16 or 36B BF16 workstation | Higher fidelity and simpler quality comparisons | 64–75GB of weights before cache and runtime memory | Usually a multi-GPU or high-memory system |
| Two-H200-style 36B serving | Matches the documented MoVA serving shape | Rental, host, storage, and utilization costs | Sensible for sustained service or controlled evaluation |
| Eight-H200 375B serving | Flagship capacity and enterprise-scale throughput | Large capital or hourly infrastructure commitment | Cluster-scale only |
A 24GB-class experiment
The idealized 4-bit floor for a 36B model is about 18GB, leaving less than 6GB on a 24GB card for quantization metadata, runtime buffers, and KV cache. That arithmetic makes a 24GB-class test plausible at moderate context, but it does not establish a universal minimum: the exact quantization, backend, offload policy, and prompt length still decide whether the run is usable.
The cited official MoVA GGUF artifact is BF16 rather than a small consumer quantization. The Hugging Face collection lists GGUF and FP8 variants across the family, but release-day conversion and compatibility work still belong in the deployment budget (K2 Horizon collection).
“I assume they are still uploading other GGUFs--all I see is a BF16 GGUF so far” — u/apoptosist in r/LocalLLaMA.
Two H200s for the documented 36B path
IFM’s MoVA vLLM recipe uses tensor parallelism of 2, expert parallelism, BF16, and a 131,072-token serving limit. Its SGLang documentation says the configuration was validated on 2× H200, which is a stronger hardware signal than the model name alone (vLLM recipe, official GGUF card).
Published provider rates show why utilization matters. DigitalOcean lists a dedicated NVIDIA H200 at $4.47 per GPU-hour and an 8× H200 configuration at $35.78 per hour; Google Cloud lists an 8× H200 A3 Ultra machine at $84.806908493 per hour, with attached vCPUs, memory, and SSD included in the machine-type price (DigitalOcean pricing, Google Cloud pricing).
At the listed per-GPU rate, two H200s imply about $8.94 per hour or $6,526 per 730-hour month before host and storage costs; use this only as a utilization-sensitive reference, not a two-GPU quote.
Eight H200s for 375B-A23B
The flagship’s official serving recipe uses eight H200s, TP=8, EP=8, and BF16. That configuration aligns with the model’s approximate 750GB raw BF16 planning floor and makes the enterprise boundary explicit (375B model card).
Google’s listed 8× H200 machine price of $84.81 per hour is about $61,909 for 730 hours, before taxes, data transfer, persistent storage, and application operations. It is an infrastructure reference, not a K2 Horizon price and not a guarantee that the published recipe reaches a particular tokens-per-second rate.
What early self-hosting evidence can—and cannot—prove
Early reports show that K2 Horizon is runnable, but mixed quantizations and runtimes do not yet establish a universal cost-performance curve.
One detailed X report gives a useful example of how much the backend can matter:
“36B-A4B MoVA does 131-142 tok/s on 2x 5090 with llama.cpp (IFM's fork, Q8_0, 131K ctx) vs 52 on vLLM...” — @abtraore_.
This useful but uncontrolled report shows why “MoVA is faster” is incomplete without naming the backend and configuration.
Reddit discussion indicates unresolved quantization, small-VRAM, comparison, and tool-call questions, not validated performance (r/LocalLLaMA thread).
For a serious purchase decision, the missing measurements are resident memory by quantization, KV-cache growth by context, prompt and generation speed, tool-call reliability, power draw, and cost per successful task under one controlled workload.
Choose by utilization, not by active-parameter marketing
The right K2 Horizon model depends on how often it will run, how much context it needs, and whether its output quality justifies the infrastructure. A short pilot should optimize for reversibility; an always-on private service should optimize for utilization and operational stability.
| Your workload | Start with | Why | Stop or upgrade when |
|---|---|---|---|
| Wearable, embedded, or narrow classifier-style task | 0.9B | Smallest footprint and 128K context claim | Tool depth or domain coverage becomes the bottleneck |
| Compact local assistant or fine-tuning experiment | 3.7B | Low storage burden with broader reasoning than 0.9B | Coding and recovery failures dominate |
| First serious local coding/agent pilot | 7B | Documents parsers, tensor parallelism, and quantized variants | Long tasks need more reliable planning or tool use |
| High-capability workstation with a dense baseline | 32B Stage1, cautiously | Dense behavior is easier to compare, but current checkpoint is not final | Final checkpoint and measured results justify the memory |
| Repeated local/server inference where active compute matters | MoVA 36B-A4B | Lower active parameter count and a documented TP=2/EP path | Context, concurrency, or runtime friction erases the efficiency gain |
| Enterprise reasoning and long-horizon agents | 375B-A23B | Highest-capacity fleet member and documented 8× H200 path | Per-task cost or utilization fails the business case |
For a first pilot, record five values before changing the model: peak VRAM/RAM, prompt length, time to first token, generated tokens per second, and cost per completed task. Keep the context limit at the documented 131,072 tokens until the workload proves that more is worth the cache and latency cost.
If the question is which family member fits a given machine, the separate K2 Horizon model sizing guide covers that narrower selection problem. This page instead prioritizes utilization and measured task cost over active-parameter labels.
K2 Horizon models FAQ
Does Apache 2.0 mean every K2 Horizon dataset is Apache 2.0?
No. IFM says the models and code use Apache 2.0, while datasets follow applicable licenses such as ODC-BY. Check each repository and dataset before redistribution or commercial training use (IFM announcement).
Does 4B active mean K2 Horizon MoVA 36B-A4B needs 4B-model memory?
No. The model activates roughly 4B parameters per token, but its official BF16 GGUF is about 74.9GB. Weight storage, KV cache, runtime buffers, quantization overhead, and concurrency determine the actual memory requirement.
Can a single 24GB GPU run K2 Horizon MoVA 36B-A4B?
A suitable 4-bit quantization may make a moderate-context experiment plausible because the idealized 36B weight floor is about 18GB. The official BF16 artifact and validated two-H200 serving path require much more headroom, so a 24GB result should be treated as a pilot configuration rather than a general production guarantee.
Is the advertised 512K context economical to serve?
Not automatically. The model cards state a 524,288-token native context, while the documented vLLM examples use 131,072 tokens; longer context increases KV-cache demand, latency, and often reduces concurrency.
Is K2 Horizon 375B-A23B a normal self-hosted model?
No. IFM documents an eight-H200 SGLang configuration, and the raw BF16 planning floor is roughly 750GB before runtime overhead. Treat it as an enterprise or cluster deployment unless a provider publishes a smaller validated configuration.
Is the $0.00 price shown for K2 Horizon 375B an actual free API?
No conclusion like that is supported. Artificial Analysis shows $0.00 input and output prices but lists speed and cost per task as unavailable, while the official model page has no Hugging Face inference provider; verify a named provider’s contract and rate card before using that figure in a budget.