Modèles K2 Horizon : Apache 2.0, MoVA et coût de l’auto-hébergement

Une gamme de six modèles, de 0.9B à 375B, donne l’impression de couvrir tous les scénarios de déploiement. En pratique, l’équation économique est moins simple. La licence Apache 2.0 de K2 Horizon supprime les frais de licence du modèle ; MoVA réduit le calcul actif ; ni l’une ni l’autre n’éliminent les coûts de stockage, de cache KV, de runtime ou de matériel.

Les six modèles publiés sous Apache 2.0

IFM a annoncé K2 Horizon le 3 septembre 2026 comme une famille cohérente de six modèles : 375B-A23B, 36B-A4B, 32B, 7B, 3.7B et 0.9B. Selon l’annonce, les modèles et leur code sont publiés sous Apache 2.0, tandis que les jeux de données restent soumis à leurs licences respectives (annonce d’IFM).

Une même famille, mais des versions pas toutes au même stade

Les six membres de la gamme sont les suivants :

À l’exception du 0.9B, qui s’appuie sur un vocabulaire plus réduit, la famille partage son architecture et ses outils de déploiement. Cette base commune doit faciliter la migration ou le routage entre les différentes tailles (communiqué de presse d’IFM).

Une réserve importante concerne la maturité des sorties : la fiche officielle de K2-Horizon-32B présente le checkpoint disponible comme un Stage1 et précise que le checkpoint final reste à publier. À l’inverse, les fiches des MoVA 36B-A4B et 375B-A23B indiquent que leurs checkpoints finaux sont disponibles. Dire que « six modèles ont été annoncés » est donc exact ; dire qu’il existe « six checkpoints de production tous aussi finalisés » ne l’est pas (fiche du modèle 32B, fiche du modèle 375B).

Ce qu’Apache 2.0 apporte réellement à une équipe d’auto-hébergement

Apache 2.0 autorise les équipes à modifier, redistribuer et intégrer commercialement le modèle et son code sans frais par token. IFM précise que les jeux de données sont régis par leurs propres conditions, par exemple ODC-BY, et que les sources restreintes ne peuvent pas forcément être redistribuées directement (annonce d’IFM).

Apache 2.0 efface le coût de licence, pas la facture d’exploitation. Location ou amortissement des GPU, stockage des modèles, capacité de cache KV, ingénierie du runtime, supervision et audit de sécurité restent à financer ; les exemples de la recette de serving 36B et de la fiche du modèle 375B utilisent également trust_remote_code=True.

Comparer les six tailles en partant de la mémoire

Le nombre de paramètres aide à situer la capacité d’un modèle, mais le stockage brut des poids est la première contrainte en auto-hébergement. Les estimations ci-dessous retiennent deux octets par paramètre en BF16 et un demi-octet dans une représentation 4 bits idéalisée ; elles excluent les métadonnées, les buffers du runtime, le cache KV, les fichiers de tokenizer et la mémoire du système d’exploitation.

\*La fiche du 7B qualifie le modèle de « 7B-core », alors que les métadonnées Hugging Face affichent 9B paramètres. Le dimensionnement doit s’appuyer sur les fichiers réels du dépôt, et pas seulement sur le nom de la famille (fiche du modèle 7B).

Les dépôts concrets montrent pourquoi il s’agit de planchers et non de promesses. Le GGUF BF16 du 0.9B est affiché à 2.16 GB, celui du 3.7B à 10.1 GB, le GGUF BF16 Stage1 du 32B à 69.6 GB et le GGUF BF16 du MoVA 36B à 74.9 GB (GGUF 0.9B, GGUF 3.7B, GGUF 32B, GGUF 36B).

Les petits modèles : 0.9B, 3.7B et 7B

Les 0.9B et 3.7B réduisent au minimum le besoin en stockage. Ils conviennent davantage à des tâches ciblées et contraintes qu’à des agents complexes appelés à se reprendre après des échecs (fiche du modèle 0.9B, fiche GGUF 3.7B).

Pour une première expérimentation locale, le 7B est l’option la mieux documentée de la famille : sa fiche détaille les parseurs de raisonnement et d’appels d’outils, un réglage de tensor parallelism sur un seul appareil et des variantes quantifiées. Le tableau de benchmarks affiché rapporte 70.6% sur SWE-bench Verified, 39.1% sur Terminal-Bench 2.1 et 25.8% sur tau3-Banking, mais tous les résultats reposent sur un effort de raisonnement élevé et la fiche prévient que les détails de protocole peuvent varier (fiche du modèle 7B).

La fiche du 7B recommande un effort de raisonnement élevé ainsi qu’au moins 32,768 tokens de sortie. Un raisonnement plus long augmente le temps de génération et peut rendre coûteux en temps réel un modèle pourtant compatible avec la mémoire disponible.

Pour station de travail ou serveur : 32B et 36B-A4B

Le 32B est entièrement dense, donc plus simple à anticiper, mais son statut Stage1 et son GGUF officiel de 69.6 GB sont les contraintes déterminantes pour le dimensionnement (GGUF 32B Stage1).

Le MoVA 36B-A4B pose une autre question : un modèle qui mobilise beaucoup moins de calcul actif peut-il s’approcher des capacités d’un dense tout en conservant une capacité totale plus élevée ? Le tableau de benchmarks du GGUF d’IFM affiche 26.8% sur tau3-Banking et 58.6% sur Terminal-Bench 2.1, où il arrive en tête du groupe comparé, mais il ne domine pas tous les indicateurs scientifiques, factuels ou de long contexte (fiche de benchmarks du GGUF 36B).

Une fois les poids chargés en mémoire, son faible nombre de paramètres actifs peut améliorer le débit soutenu. Le résultat dépend toutefois du backend, du batching, de l’interconnexion et de la quantification.

Le modèle phare : 375B-A23B

La fiche officielle documente une configuration SGLang validée pour K2 Horizon 375B-A23B : huit GPU H200, tensor parallelism à 8, expert parallelism à 8, BF16 et FlashAttention-3 (fiche du modèle 375B).

Le ratio entre paramètres totaux et actifs peut réduire le calcul par rapport à un modèle dense de 375B, mais le plancher de planification d’environ 750GB en BF16 reste la frontière matérielle. Artificial Analysis lui attribue un score Intelligence Index de 47 et une 11e place sur 112 dans la catégorie affichée, sans indiquer de vitesse de sortie ni de coût par tâche (profil Artificial Analysis).

Au vu du profil validé actuel sur huit H200, il faut le considérer comme un déploiement à l’échelle d’un cluster.

MoVA réduit le calcul, pas le plancher de stockage

MoVA signifie Mixture-of-Value Attention. Les architectures classiques de mixture-of-experts appliquent généralement le routage clairsemé aux couches feed-forward ; IFM explique que MoVA étend ce routage d’experts à la composante value de l’attention, tout en restant compatible avec des techniques telles que FlashAttention et grouped-query attention (explication de l’architecture par IFM).

Ce que signifie réellement l’étiquette 36B-A4B

Le nom « 36B-A4B » indique deux mesures différentes : environ 36B paramètres sont disponibles au total, tandis qu’environ 4B sont activés pour chaque token. Cela peut réduire les opérations multiply-and-accumulate et le trafic mémoire sur le chemin actif, en particulier lors de générations soutenues.

Pour autant, les experts non sollicités ne disparaissent pas. Le fichier GGUF officiel occupe 74.9 GB en BF16, et la recette vLLM décrit un modèle de 37.44B paramètres stockés, embeddings compris, pour 5.95B paramètres actifs par token. Ces chiffres correspondent à une vision de packaging et de comptabilisation de la même architecture, pas à l’existence d’un modèle distinct de 37B (recette vLLM).

Le bon modèle mental est le suivant :

1. Capacité résidente : le stockage et la mémoire doivent contenir les poids susceptibles d’être sélectionnés.
2. Calcul actif : chaque token n’utilise qu’un sous-ensemble routé.
3. État du runtime : cache KV, buffers temporaires, batching et surcharge du framework restent présents.
4. Coût système : interconnexion, énergie, RAM hôte et temps d’exploitation composent la facture.

Pourquoi le 512K de contexte n’est pas un budget de serving

Les fiches K2 Horizon annoncent un contexte natif de 524,288 tokens pour les modèles les plus grands. Pourtant, les recettes vLLM publiées pour les MoVA 36B-A4B et 375B-A23B règlent --max-model-len 131072, soit un quart de ce maximum mis en avant (recette vLLM 36B, fiche du modèle 375B).

Ces recettes à 131K montrent que le contexte natif de 512K n’est pas un réglage de serving gratuit : les contextes plus longs consomment du cache KV, réduisent la concurrence et allongent la latence des prompts.

Scénarios chiffrés d’auto-hébergement

K2 Horizon ne dispose d’aucun tarif d’API universel et transparent qui puisse servir de référence. La page officielle du GGUF MoVA indique qu’aucun fournisseur d’inférence ne déploie actuellement le modèle, tandis qu’Artificial Analysis affiche des prix d’entrée et de sortie à $0.00 pour le profil 375B tout en signalant que la vitesse et le coût par tâche ne sont pas disponibles ; cela ne prouve pas l’existence d’un endpoint de production gratuit (fiche du GGUF MoVA, Artificial Analysis).

Expérimenter avec un GPU de classe 24GB

Le plancher 4 bits idéalisé d’un modèle 36B est d’environ 18GB, ce qui laisse moins de 6GB sur une carte 24GB pour les métadonnées de quantification, les buffers du runtime et le cache KV. Ce calcul rend un test sur GPU de classe 24GB plausible avec un contexte modéré, mais ne définit pas un minimum universel : la quantification exacte, le backend, la politique d’offload et la longueur des prompts déterminent encore si l’exécution reste exploitable.

L’artefact GGUF MoVA officiel cité est en BF16, et non dans une petite quantification grand public. La collection Hugging Face liste des variantes GGUF et FP8 dans l’ensemble de la gamme, mais le travail de conversion et de compatibilité au jour de la sortie doit encore entrer dans le budget de déploiement (collection K2 Horizon).

« I assume they are still uploading other GGUFs--all I see is a BF16 GGUF so far » — u/apoptosist dans r/LocalLLaMA.

Deux H200 pour le chemin 36B documenté

La recette vLLM MoVA d’IFM utilise un tensor parallelism de 2, l’expert parallelism, BF16 et une limite de serving de 131,072 tokens. Sa documentation SGLang précise que la configuration a été validée sur 2× H200, un signal matériel plus solide que le seul nom du modèle (recette vLLM, fiche officielle du GGUF).

Les tarifs publiés par les fournisseurs illustrent l’importance du taux d’utilisation. DigitalOcean affiche un NVIDIA H200 dédié à $4.47 par GPU-heure et une configuration 8× H200 à $35.78 par heure ; Google Cloud affiche une machine A3 Ultra avec 8× H200 à $84.806908493 par heure, les vCPU, la mémoire et le SSD attachés étant inclus dans le prix du type de machine (tarifs DigitalOcean, tarifs Google Cloud).

Au tarif unitaire affiché, deux H200 représentent environ $8.94 par heure, soit $6,526 pour un mois de 730 heures, avant les coûts d’hôte et de stockage ; cette valeur n’est qu’un repère sensible au taux d’utilisation, pas un devis pour deux GPU.

Huit H200 pour 375B-A23B

La recette de serving officielle du modèle phare repose sur huit H200, TP=8, EP=8 et BF16. Cette configuration correspond au plancher brut d’environ 750GB en BF16 et matérialise clairement le seuil d’entrée entreprise (fiche du modèle 375B).

Le prix affiché par Google pour une machine 8× H200, $84.81 par heure, représente environ $61,909 pour 730 heures, avant taxes, transfert de données, stockage persistant et exploitation applicative. C’est une référence d’infrastructure, pas un prix K2 Horizon ni la garantie que la recette publiée atteindra un débit donné en tokens par seconde.

Ce que les premiers retours d’auto-hébergement prouvent — et ne prouvent pas

Les premiers rapports indiquent que K2 Horizon peut s’exécuter, mais la diversité des quantifications et des runtimes ne permet pas encore d’établir une courbe coût-performance universelle.

Un rapport détaillé sur X illustre utilement l’influence du backend :

« 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_.

Ce retour utile, mais non contrôlé, montre pourquoi affirmer que « MoVA est plus rapide » ne veut rien dire sans préciser le backend et la configuration.

Les échanges sur Reddit font état de questions encore ouvertes autour de la quantification, des petites VRAM, des comparaisons et des appels d’outils ; ils ne constituent pas une validation des performances (discussion r/LocalLLaMA).

Pour prendre une décision d’achat sérieuse, les mesures qui manquent sont la mémoire résidente selon la quantification, la croissance du cache KV avec le contexte, la vitesse de prompt et de génération, la fiabilité des appels d’outils, la consommation électrique et le coût par tâche réussie dans une même charge de travail contrôlée.

Choisir selon l’utilisation réelle, pas selon le marketing des paramètres actifs

Le bon modèle K2 Horizon dépend de sa fréquence d’utilisation, du contexte requis et de la capacité de ses sorties à justifier l’infrastructure. Un pilote court doit privilégier la réversibilité ; un service privé permanent doit privilégier l’utilisation effective et la stabilité opérationnelle.

Pour un premier pilote, relevez cinq valeurs avant de changer de modèle : VRAM/RAM maximale, longueur du prompt, temps jusqu’au premier token, tokens générés par seconde et coût par tâche terminée. Conservez la limite de contexte documentée de 131,072 tokens jusqu’à ce que la charge de travail démontre qu’aller plus loin justifie le coût en cache et en latence.

Si la question est de savoir quel membre de la famille convient à une machine donnée, le guide de dimensionnement des modèles K2 Horizon traite ce choix plus précis. Cette page privilégie plutôt le taux d’utilisation et le coût mesuré par tâche que les étiquettes de paramètres actifs.

FAQ sur les modèles K2 Horizon

Apache 2.0 signifie-t-il que tous les jeux de données K2 Horizon sont sous Apache 2.0 ?

Non. IFM indique que les modèles et le code utilisent Apache 2.0, tandis que les jeux de données suivent leurs licences applicables, comme ODC-BY. Vérifiez chaque dépôt et chaque jeu de données avant toute redistribution ou utilisation pour un entraînement commercial (annonce d’IFM).

4B actifs veut-il dire que K2 Horizon MoVA 36B-A4B demande la mémoire d’un modèle 4B ?

Non. Le modèle active environ 4B paramètres par token, mais son GGUF officiel en BF16 pèse environ 74.9GB. Le stockage des poids, le cache KV, les buffers du runtime, la surcharge de quantification et la concurrence déterminent le besoin mémoire réel.

Un seul GPU 24GB peut-il faire tourner K2 Horizon MoVA 36B-A4B ?

Une quantification 4 bits adaptée peut rendre une expérimentation à contexte modéré plausible, puisque le plancher de poids idéalisé pour 36B est d’environ 18GB. L’artefact officiel BF16 et le chemin de serving validé sur deux H200 demandent bien davantage de marge ; un résultat sur 24GB doit donc être vu comme une configuration pilote, et non comme une garantie générale de production.

Le contexte 512K annoncé est-il économique à servir ?

Pas automatiquement. Les fiches des modèles indiquent un contexte natif de 524,288 tokens, tandis que les exemples vLLM documentés utilisent 131,072 tokens ; un contexte plus long accroît le besoin en cache KV, la latence et réduit souvent la concurrence.

K2 Horizon 375B-A23B est-il un modèle normal à auto-héberger ?

Non. IFM documente une configuration SGLang sur huit H200, et le plancher de planification BF16 brut atteint environ 750GB avant la surcharge du runtime. Traitez-le comme un déploiement entreprise ou cluster, sauf si un fournisseur publie une configuration plus petite et validée.

Le prix $0.00 affiché pour K2 Horizon 375B correspond-il à une API réellement gratuite ?

Aucune conclusion de ce type n’est étayée. Artificial Analysis affiche des prix d’entrée et de sortie à $0.00, mais indique que la vitesse et le coût par tâche ne sont pas disponibles, tandis que la page officielle du modèle ne propose aucun fournisseur d’inférence Hugging Face ; vérifiez le contrat et la grille tarifaire d’un fournisseur identifié avant d’intégrer ce chiffre à un budget.