IFM Releases K2 Horizon, Six Apache 2.0 Models From 0.9B to 375B

Patrick Rho · AI Research

IFM Releases K2 Horizon: Six Apache 2.0 Models From 0.9B to 375B covers the model fleet released by IFM, the frontier lab that MBZUAI launched in May 2025. The announcement reduces to a single claim. Six models spanning 0.9B to 375B ship under the Apache 2.0 license, and the pretraining corpus ships with them. The original piece is linked under the title.

The usual open model announcement ends with one checkpoint and one benchmark table. K2 Horizon does not follow that grammar. Six models plus the corpus used to train them make this a different kind of statement from the start. That is why I opened the story. The lineup interested me more than any single number.

Why I did not scroll past this announcement

When I look at a model release, I try not to start with the parameter count. Counts are easy to remember and explain little. I start with who released it, why, and in what bundle. IFM is the frontier lab set up by MBZUAI, and K2 Horizon reads like its first large scale public move. For a first move, shipping six sizes at once instead of a single flagship caught my attention.

What interests me more is the spacing between the sizes. The lineup reads 0.9B, 3.7B, 7B, 32B, plus 36B-A4B and 375B-A23B that look like mixture of experts designs. That spectrum stretches from sizes you can run on a device all the way to data center scale. A spread like that rarely happens by accident. It signals a training pipeline that was planned from the beginning to serve several deployment points.

This is where I would be careful not to over-read the material. From the supplied coverage alone I cannot pin down the data mixture or the evaluation scores of each model. What I have is the model list, the license, the fact that the corpus ships with the weights, and the launch date. So this piece does not rank the models by performance. It follows what the release structure itself means, and what choices it hands to engineers and researchers.

Shipping a fleet instead of a checkpoint

Most open model launches consist of one checkpoint and one benchmark table. That format makes comparison easy, and it hides plenty. A table rarely shows at which size a capability appears, what breaks when you step down in size, or whether the training pipeline holds across sizes at all.

A fleet release touches that blind spot directly. With six sizes out at the same time, researchers can compare behavior across the range by hand. You can check what the 0.9B model grasps and how the 32B model differs, and where the steps in capability show up, using your own prompts and your own data. Checking with your own setup differs from reading a curve in a report.

From a systems perspective, the next question is obvious. Do these six really come from the same recipe, or are they separate models under one name. Fleet comparison carries weight when the corpus and the training procedure are shared. When the procedures differ, a size comparison turns into a recipe comparison. That is why the line about shipping the corpus caught my eye. It reads like an offer to hand over the material needed to check the premise of the comparison.

The answer already sits inside the model names

Let me write the list out again. 375B-A23B, 36B-A4B, 32B, 7B, 3.7B, 0.9B. The tags A23B and A4B on the first two names look like active parameter counts. They state how much of the model participates in computation for one step of inference, 23B and 4B respectively. This notation is common for mixture of experts structures.

The distinction confuses newcomers and clicks fast once you serve such a model. Total parameters resemble the size of the vessel holding what the model remembers. Active parameters resemble the compute cost of processing one token. Before reacting to the 375B figure, the right questions are how much memory the model occupies and how much compute each token draws. The A23B tag answers that question in advance, inside the name.

I think the more telling result is the structure behind the number. Mixture of experts trades large memory against modest compute. It keeps a large store of memory and wakes only part of it per step. Routing is the new work that comes with the trade. Every layer picks which experts receive each token. When routing works, efficiency rises. When it drifts and piles work onto a few experts, training turns unstable. The 23B and 4B figures carry traces of those structural choices.

What the Apache 2.0 choice changes in practice

That all six models ship under Apache 2.0 is the plainest sentence in this announcement. The license looks like an attachment in many open weight releases, yet for teams building products the license acts as a design constraint. Whether commercial use is allowed, which obligations attach when you redistribute modified versions, and how the patent provisions read all feed straight into schedules and legal review.

Apache 2.0 is a permissive license that practitioners handle routinely. Unlike releases limited to research use, it broadly permits putting the models inside commercial products, modifying them, and redistributing the result. So the choice widens the readership. Readers include not only people who read reports but people who will deploy the models. Startups can prototype on top, companies can drop the models into internal evaluation pipelines, and device makers can start from the small sizes. That sequence follows naturally.

A permissive license does not dissolve operating costs. Handing over a large model does not let the receiving team serve it right away. Memory capacity and bandwidth, quantization and distributed serving all remain as practical barriers. The license opens the door, and each organization climbs the stairs behind it on its own. Releasing several sizes together seems to overlap with that reality. It lets each team pick the step it can stand on after the door opens.

Putting the corpus next to the weights carries weight

The line that stopped me in this announcement says the pretraining corpus ships with the models. Releasing weights hands over the product, while releasing the corpus opens the process. When you can see what the models trained on, you can check questions of data mixture and filtering, deduplication and quality control with your own hands instead of taking someone's word.

For researchers, the corpus is the starting point of reproducibility. Knowing which domains run strong and which run thin gives you language to interpret failure. When performance drops in some language, you can form hypotheses about whether the structure or the data distribution caused it. Discussions of safety and bias drift in the air without knowledge of the training mix. With the corpus, the discussion lands on solid ground.

When my team and I look at a new architecture, we do not stop at benchmark figures. We look at what changed in substance and what cost structure the change creates in a system. A corpus release fits that habit. It invites readers to handle the raw material instead of copying numbers. A corpus does not let everyone retrain from scratch, since the compute cost of large scale training stays steep. Still, knowing the composition changes the depth of interpretation by a wide margin.

Small models refuse to be miniature copies

Seeing sizes like 0.9B and 3.7B, it is tempting to treat them as slimmed down versions of the large model. The surface looks simple. The reality differs. Small models live in different places. They run directly in constrained settings like laptops and phones, browsers and edge servers. There, latency limits and memory ceilings decide whether a product survives.

Small sizes inside the fleet lower the cost of trying things out. Teams that cannot host 375B directly can still build the pipeline on 0.9B or 3.7B first. Prompt formats and evaluation harnesses get refined at small scale before moving up. You absorb failure where failure costs little. That ordering matters a lot in daily practice.

The middle sizes, 7B and 32B, sit where a single GPU or a small node can still handle them. Fine tuning and alignment work plus domain adaptation mostly happen in that band. When the middle sizes belong to the same family, ideas verified at small scale move up smoothly, and refinements from the middle get compared against large scale inference. That is where the word fleet earns its place. Each vessel covers different water under the same flag.

Scores tell less than structure

When a model announcement lands, most readers hunt for the benchmark table first. I read tables too. I try to read them as a list of questions rather than a verdict. Which tasks improved, which stayed flat, and whether the evaluation setup stayed fair all matter more than the headline figure. With six sizes like K2 Horizon, the shape of the curve across sizes says more than any single score.

Suppose tasks of some kind stay unsolved at small sizes and start resolving past a certain size. That point likely marks where structure and training meet. Suppose other tasks stay flat no matter how far the size grows. Then the data mix or the training objective becomes the suspect. Such reading needs several sizes viewed through the same lens. A fleet release changes how we read evaluations at exactly this point.

This is where I would be careful not to over-read the experiment. Size comparison means something only when the harness, the prompts, and the sampling setup stay fixed. When setups differ, you cannot tell a size effect apart from a setup effect. So I plan to watch the reproduction reports the community will publish. Once results for all six sizes under shared conditions pile up, those curves will say more than the announcement prose.

The arithmetic that happens on the serving rack

How would you actually serve this. Faced with that question, the MoE notation reads differently. That 375B must sit in memory states one constraint, and that roughly 23B participates per token states another. Memory capacity follows the full figure, while speed and cost follow the active figure. Estimates go wrong unless both figures stay in view.

MoE serving often snags on where expert weights live and how they travel. Keeping every expert resident in GPU memory runs fast and costs plenty of memory. Fetching experts on demand saves memory and adds bandwidth pressure plus latency. Batch size, concurrent requests, and sequence length shift the sweet spot. A mid sized MoE like 36B-A4B gives a fine testbed for that tradeoff. Teams can refine routing and batching plus cache strategy there before stepping up to the giant MoE.

The dense looking sizes, 32B, 7B, 3.7B, 0.9B, estimate more directly. Memory footprint and per token compute follow familiar arithmetic. Familiar tools like quantization and distillation plus inference engine tuning apply without surprise. Viewed together, the fleet forms layers of options. Small dense models cover interactive latency needs, the large MoE covers the quality ceiling, and the middle sizes fill the gap. A single model release rarely reveals that layout. A fleet release brings it along naturally.

What a one line summary drops

Compressed to one line, this story becomes six open models out. That sentence is accurate. It also erases half the character of the event. What shipped here is a bundle of options rather than a scoreboard, and verification material came with the bundle. Scores alone would line the models up by size. Options place each model where it stands.

The launch date deserves attention too. IFM is the frontier lab that MBZUAI launched in May 2025. A first large release from a new organization reads as a technical statement and a declaration of how the lab works. The release structure shows what it prioritizes and what relationship it wants with the research community. Putting the corpus in the package reads like a move weighted toward open verification rather than closed display.

What I would watch next is how that declaration continues. The question is whether the fleet stays a one time event or grows into a stream of shared recipes, harnesses, and follow up improvements. The value of an open release often settles months later, in reproductions and derivative work rather than day one figures. When someone starts at 0.9B and grows to 32B, and when reports dissecting routing behavior in 36B-A4B accumulate, the fleet will reach full meaning.

Questions the fleet leaves behind

Every announcement leaves questions, and the leftovers hold the substance. I wrote down four groups around K2 Horizon. First, how much of the recipe the six sizes share. When the data mix, the training schedule, and the alignment stages stay shared, the size curve reads cleanly. When the shared scope differs, the reading must change accordingly.

Second, the routing design of the two MoE models. Expert counts and selection methods plus load balancing determine practical efficiency, and whether routing stabilizes late in training decides reliability. The active parameter figures in the names describe the outcome side. The process side needs separate checking. Third, the composition and the scope of the corpus. Whether it covers everything or a portion, what state the filtering and preprocessing sit in, and whether reuse terms match the weights in spirit all set the width of follow up research.

Fourth, the practical range of the small sizes. I hope reports on where 0.9B and 3.7B hold up and where they collapse arrive soon. Once a failure map of small models exists, teams can separate cases that need the large model from cases where the small model suffices. That separation lets each organization decide on quality against cost. One announcement cannot answer all of it, yet clear questions pull reproductions toward answers.

Reproduction matters more than the scoreboard from here

To sum up my reading, a new organization called IFM under MBZUAI bundled six sizes under Apache 2.0 and placed the pretraining corpus inside the release scope alongside the weights. The list runs 375B-A23B, 36B-A4B, 32B, 7B, 3.7B, 0.9B. The first two read like mixture of experts structures given the active parameter notation. Unlike a typical single checkpoint release, the package aims at several deployment points at once.

One thought stays with me from this package. The center of evaluation gravity should move from the scores in the announcement to reproductions by the community. With six sizes and the corpus in hand, each team can draw the curve under its own tasks and conditions. As those curves accumulate, we will learn whether this fleet was designed well. I plan to follow how pipelines refined at small scale carry over to large scale, and how operating instincts around the two MoE variants settle. Once reproduction reports gather, I will unpack the behavioral differences across sizes in a more hands on way.