Route AI tasks across K2 Horizon's 0.9B-375B fleet
Route each AI task to the K2 Horizon checkpoint whose active parameters, context, and serving cost fit the workload, then prove it with open-weight evals.
Choosing a model size is a cost trade-off: more active parameters buy capability, and each token pays for the compute that activates them. A 23B-active token does about 5.75 times the active-parameter work of a 4B-active token. IFM introduced K2 Horizon on September 3, 2026 as a six-model fleet spanning 0.9B to 375B parameters, and the 375B-A23B checkpoint debuted with parsers for reasoning and tool calls built for agent workflows, terminal operations, and extended reasoning. Treat the lineup as a routing menu, not a single product.
Classify the workload before naming a checkpoint
Start with a workload ticket: context length, tool or agentic complexity, latency target, and budget. Do not put a model name in the ticket. The ticket is the unit of review for routing changes. Collect examples from production traffic, then label each prompt, tool call, and expected output by context length, tool complexity, and latency sensitivity. A slow answer can break an agent workflow even when the content is correct, so the ticket must name a latency class before any checkpoint is chosen.
Map the ticket to the smallest checkpoint that clears the eval bar. The size ladder is the rule a new engineer can read without asking why the big model was chosen:
- Short, low-tool tasks: 0.9B tier.
- Local or on-prem work: 36B-A4B tier.
- Long-context agentic work: 375B-A23B tier.
Keep the mapping reversible. If the small checkpoint fails, record the failure mode and promote only the work that needs the larger checkpoint. The promotion rule should name the task class, not the model family. Choosing by total parameters is the common failure: a large total model can cost less per token than a dense model if only a small active count runs.
Price tokens by active parameters, not total size
Estimate cost per token from active parameters, context length, batch size, and your GPU-hour rate. Put the formula in the ticket: active parameters times tokens, divided by throughput, then multiplied by your dollar rate. The formula is the number the team can defend in review. Separate prefill from decode. Long context can make prefill dominate, while short repeated prompts can make decode dominate, so the ticket gains a prefill estimate and a decode estimate.
The 375B-A23B is a sparse MoE model with 375B total parameters, 23B active parameters per token, and a native 524,288-token context. The 36B-A4B sparse model is aimed at local hosting and on-premise server deployments. The K2 Horizon fleet uses dynamic routing to assign work to the model with the best cost-effectiveness. The fleet uses a value-attention mixture design that strengthens reasoning without increasing compute. Do not let total parameters set the price. A sparse model can have a large total count and a small active count, so token cost follows the active count, while longer prompts can still increase memory and prefill work.
Prove the route with open-weight evals
Run reproducible evals from open weights and training data before you promote a model. The eval package lists task set, checkpoint, prompt format, score, and cost per token. Keep the run with the ticket. The lineup is a set of fully open models, with weights, code, training data, and methodologies available for inspection, reproduction, and adaptation. Use the 375B-A23B reasoning and tool-call parsers in the eval harness when the workload is agentic.
Store the eval artifacts with the routing rule so a new engineer can rerun the eval without guessing. Check the tool-call format before scoring. If the parser expects a different shape, the eval measures formatting, not reasoning. The eval should show a clean parse rate and a task score.
Score the candidate on the exact workload, not a generic leaderboard. The comparison should show the chosen checkpoint winning on the task, latency target, and cost target. If it fails, move to the next checkpoint and rerun the eval. Instrument the routing decision after launch. The live metric set shows task class, checkpoint, latency, and cost per token. Review the metric set when the workload changes. Keep the metric set small enough to read in an incident.