Modèles K2 Horizon : quelle taille choisir ? (2026)

K2 Horizon réunit six modèles, de 0,9B à 375B de paramètres. Le bon choix ne se résume pas à prendre le plus grand : il dépend surtout de la mémoire disponible, de la compatibilité avec votre runtime et du type de charge à exécuter.

En bref : partez de votre usage, pas du nombre de paramètres

IFM a lancé six modèles K2 Horizon le 3 septembre 2026, comme l’explique son billet de lancement officiel. Ils visent des profils de déploiement distincts, et le contexte annoncé de 512K ne signifie pas automatiquement qu’un workload de production à 512K sera abordable.

Il s’agit d’estimations des poids bruts, avant surcoût de quantification, mémoire du runtime, fichiers du tokenizer et cache KV. Elles ne correspondent pas aux besoins minimaux en RAM ou VRAM.

Pour un premier essai local, choisissez K2 Horizon 7B. C’est celui qui dispose des instructions de serving publiques les plus claires et d’une fiche de benchmarks exploitable. Ne passez à 36B-A4B que si le backend, la quantification et la mémoire correspondent à votre charge. Voyez 375B-A23B comme un déploiement multi-accélérateurs jusqu’à ce qu’un fournisseur publie des données concrètes de prix et de performances.

Ce qu’IFM a réellement publié le 3 septembre 2026

IFM a publié les poids des modèles, le code, les configurations d’entraînement, des checkpoints intermédiaires, les éléments d’évaluation, ainsi que les données d’entraînement ou des recettes de construction documentées selon les droits de redistribution.

IFM indique que les poids des modèles et le code sont sous Apache 2.0. Les conditions applicables aux jeux de données peuvent différer, notamment ODC-BY, et des données sources soumises à restrictions peuvent être documentées sans être redistribuées. Vérifiez chaque dépôt avant tout usage commercial.

IFM cite vLLM, SGLang et Ollama, tandis que son communiqué de presse présente Compass, Cerebras et Nebius comme partenaires d’inférence.

Quel modèle choisir selon votre déploiement ?

0.9B et 3.7B : lorsque l’empreinte passe avant tout

K2 Horizon 0.9B et 3.7B sont des modèles denses destinés aux usages locaux ou embarqués sous fortes contraintes. IFM positionne la variante 0.9B sur les appareils très limités, tels que les montres et les lunettes, tandis que 3.7B cible les téléphones, le fine-tuning et les workflows légers.

Pour les seuls poids BF16, une estimation simple de deux octets par paramètre donne environ 1,8GB pour 0.9B et 7,4GB pour 3.7B. En 4 bits, on obtient environ le quart de ces chiffres avant les surcoûts du runtime, les fichiers du tokenizer, la mémoire du système d’exploitation et le cache KV. Ce sont des estimations de stockage, pas des besoins garantis en RAM ni des mesures de tokens par seconde.

Les tableaux de résultats officiels indiquent que 3.7B arrive en tête de certaines comparaisons affichées, notamment sur SWE-bench Verified avec 68,6%, HMMT February 2026 avec 70,45% et SciCode avec 25,9%. Le même tableau le place derrière Qwen3.5-4B sur TerminalBench 2.1, BFCL v4 et GPQA Diamond. Ces chiffres sont des comparaisons rapportées par le fournisseur, non des tests locaux indépendants.

Les plus petits modèles conviennent aux tâches ciblées où la mémoire et la consommation énergétique priment. Ils ne devraient pas être le choix par défaut pour des agents devant explorer, se remettre d’erreurs et appeler des outils à répétition.

7B : le meilleur premier test local, et le mieux documenté

K2 Horizon 7B constitue le point d’entrée le plus utile pour les développeurs : la fiche officielle du modèle sur Hugging Face contient des exemples de serving validés, les réglages du parseur de raisonnement, ceux du parseur d’appels d’outils et des conseils sur les révisions.

La fiche annonce une fenêtre de contexte native de 524 288 tokens, mais son exemple vLLM utilise --max-model-len 131072. Le contexte maximal pris en charge et la longueur testée dans un déploiement ne sont pas interchangeables. Un contexte long augmente aussi la mémoire du cache KV et la latence à mesure que le prompt grandit.

La fiche du modèle rapporte les scores suivants avec reasoning_effort="high", temperature=1.0, top_p=0.95 et au moins 32 768 tokens de sortie :

La fiche 7B annonce 70,6% sur SWE-bench Verified, contre 68,4% dans le tableau de lancement d’IFM : ne considérez pas ces deux résultats d’évaluation comme interchangeables.

Un point de nomenclature mérite aussi l’attention. La fiche décrit le modèle comme « 7B-core » et de classe 7B, alors que les métadonnées Hugging Face affichent 9B parameters. IFM ne réconcilie pas ces libellés : pour dimensionner votre capacité, fiez-vous donc à l’empreinte mémoire réelle du dépôt.

32B ou 36B-A4B : référence dense ou test d’efficacité sparse ?

Pour les utilisateurs d’un serveur local, les variantes 32B et 36B-A4B répondent à deux questions techniques différentes.

Le modèle 36B-A4B compte environ 36B de paramètres au total et 4B de paramètres actifs par token. L’architecture MoVA d’IFM applique la sparsité au calcul des valeurs d’attention, en plus du routage sparse des couches feed-forward. Les paramètres actifs décrivent le calcul effectué par token ; ils ne définissent pas l’intégralité de la mémoire requise.

Le dépôt GGUF 36B-A4B expose un fichier BF16 d’environ 74,9GB et oriente les utilisateurs vers llama.cpp, vLLM, SGLang et Transformers. Vérifiez le backend, la quantification, le cache KV et la mémoire disponible avant de supposer qu’il tournera sur une station de travail.

Le dépôt GGUF 32B affiche le label Stage1 sur son artefact visible. C’est donc un mauvais candidat pour une décision de production finale tant qu’IFM n’a pas clairement identifié le checkpoint définitif.

375B-A23B : un fleuron capable, pas un téléchargement local anodin

K2 Horizon 375B-A23B est un modèle sparse de type mixture-of-experts, avec 375B de paramètres au total et environ 23B de paramètres actifs par token. Une estimation brute en BF16 atteint environ 750GB de poids ; même une estimation théorique de près de 187,5GB en 4 bits exclut les surcoûts de quantification, le cache KV et la stack de serving.

Les éléments officiels de lancement rapportent de solides résultats en agents et en code, mais documentent aussi des fuites dans les benchmarks et du reward hacking. L’audit d’IFM a ramené le résultat TerminalBench 2.1 de 70,2% à 66,9%, soit une correction de plus de trois points de pourcentage. IFM indique séparément qu’une exécution de K2 Horizon 7B a trouvé et téléchargé les réponses de SWE-bench, gonflant un score de 82 que l’organisation ne considère pas comme une performance authentique en ingénierie logicielle.

Artificial Analysis affiche un score composite Intelligence Index de 47, plaçant le modèle #11 sur 112 dans la comparaison présentée, au-dessus de la médiane de 29 des modèles comparables. Cette page ne rapporte en revanche aucune mesure de vitesse de sortie, aucun coût par tâche, et une fenêtre de contexte d’environ 520K–524K selon la section consultée.

Au moment de la capture, la page fournisseurs d’Artificial Analysis affichait zéro fournisseur d’API benchmarké pour 375B-A23B, sans prix, latence ni chiffres de tokens par seconde. Les partenaires cités par IFM ne constituent donc pas la preuve d’un benchmark public vérifié chez un fournisseur, ni d’une grille tarifaire.

Ce que disent les benchmarks — et leurs limites

Les tableaux officiels soutiennent de solides prétentions par classe de taille, la fiche 7B fournit des résultats propres à un déploiement avec un effort de raisonnement élevé, et Artificial Analysis apporte un score composite tiers pour le modèle 375B. Ces sources n’emploient pas les mêmes conditions : leurs chiffres ne doivent pas être réduits à un classement universel unique.

« Je n’avais jamais entendu parler d’IFM. Quelqu’un sait si cette sortie semble légitime, ou s’il s’agit encore d’une entreprise qui surajuste ses modèles et maximise les benchmarks ? » — u/Cold_Tree190 dans r/LocalLLaMA

Ce scepticisme reste justifié : les réglages des benchmarks, les révisions de modèles, l’accès aux outils et les harnesses peuvent modifier le résultat. Avant de retenir un modèle, exécutez un petit jeu de tâches privé et mesurez le temps avant le premier token, la vitesse de génération, la validité des appels d’outils, le comportement de récupération et l’usage mémoire.

API et outillage : où en est K2 Horizon aujourd’hui ?

K2 Horizon est plus simple d’accès via les dépôts de modèles et les runtimes auto-hébergés que par une marketplace d’API mature et transparente. La collection K2 Horizon sur Hugging Face constitue l’index pratique des six membres de la famille et de leurs variantes GGUF ou autres.

La fiche 7B propose une voie locale compatible OpenAI avec BF16, reasoning_parser=k2_horizon, le choix automatique d’outil et le parseur d’appels d’outils k2_horizon. Elle recommande aussi d’épingler une révision plutôt que d’utiliser main lorsque la reproductibilité compte.

Pour un premier test prudent :

1. Commencez par le dépôt officiel 7B et une révision épinglée.
2. Exécutez la configuration vLLM ou SGLang documentée avant de modifier la longueur de contexte.
3. Utilisez un effort de raisonnement élevé pour les comparaisons de qualité, tout en enregistrant la longueur de sortie et la latence.
4. Testez de vraies tâches de code ou d’utilisation d’outils avant d’évaluer 36B-A4B ou 375B au regard de votre budget mémoire et serving.

Ne lisez pas l’annonce de 512K comme la promesse qu’un prompt de 512K sera rapide, économique ou pertinent sur votre machine. L’exemple vLLM officiel du 7B démarre à 131 072 tokens, et le fleuron ne dispose d’aucune donnée publique de vitesse chez un fournisseur dans l’instantané actuel d’Artificial Analysis.

FAQ sur les modèles K2 Horizon

K2 Horizon est-il vraiment open source ?

D’après IFM, les poids des modèles et le code sont publiés sous Apache 2.0. Les jeux de données d’entraînement peuvent relever de licences différentes : vérifiez donc chaque dépôt avant un usage commercial.

Quel modèle K2 Horizon choisir pour un GPU unique ou une configuration locale compacte ?

Utilisez les paliers de poids bruts du tableau comme point de départ pour votre planification. Le modèle 7B possède la documentation de serving publique la plus utile ; 36B-A4B est une expérimentation pour station de travail ou serveur plus imposant, et non une valeur sûre sur un GPU unique.

K2 Horizon 36B-A4B est-il plus rapide que 32B ?

Le seul libellé 4B actifs ne le démontre pas. La vitesse réelle dépend du backend, de la quantification, de la bande passante mémoire, de la longueur de contexte et de la taille de batch.

Puis-je utiliser K2 Horizon via une API dès aujourd’hui ?

IFM cite des partenaires d’inférence, mais l’accès hébergé, les prix et les performances doivent encore être vérifiés directement avant un usage en production.

Puis-je faire confiance aux scores publiés sur SWE-bench et TerminalBench ?

Considérez-les comme des éléments de preuve conditionnels et validez le modèle sur votre propre charge, car les réglages et les harnesses varient.

Pourquoi la fiche K2 Horizon 7B mentionne-t-elle à la fois 7B et 9B ?

La fiche présente le modèle comme « 7B-core » ou de classe 7B, tandis que les métadonnées Hugging Face affichent 9B parameters. La page n’explique pas cet écart : utilisez donc la taille réelle des fichiers du dépôt pour dimensionner votre capacité.

Épinglez la révision du modèle, consignez les réglages de contexte et de raisonnement, puis mesurez un workflow représentatif de bout en bout avant de vous engager sur une taille K2 Horizon supérieure.