Kimi K3 et Qwen3.8 : quelle VRAM en auto-hébergement ?

Le modèle se charge, puis le premier appel fait tomber le service faute de KV Cache, de marge mémoire ou de communication inter-nœuds.

La solution la plus sûre consiste à ne pas acheter sur la seule taille quantifiée des poids : l’auto-hébergement de Kimi K3, Qwen3.8 ou DeepSeek V4 ne devient rationnel que si la charge est durablement élevée, les données doivent rester dans un périmètre contrôlé et l’équipe sait exploiter un déploiement distribué. Pour une phase de validation ou une charge irrégulière, le meilleur choix est généralement un fonctionnement à deux voies : API pour la production variable, capacité louée à court terme pour tester le modèle et les agents.

Cette analyse s’adresse aux équipes AI Agent qui cherchent à réduire leur coût d’appel, aux responsables de plateformes d’inférence qui doivent transformer le contexte et la concurrence en capacité réelle, ainsi qu’aux acheteurs qui hésitent entre cluster, location de serveurs spécialisés et API.

La première décision porte sur les preuves, pas sur la VRAM

Un modèle ne doit entrer dans une liste d’achat que si quatre éléments sont confirmés :

• les poids complets sont disponibles dans un format exploitable ;
• la licence autorise l’usage prévu ;
• le moteur d’inférence possède un chemin de prise en charge documenté ;
• une procédure de chargement et de reprise a été validée.

Kimi K3 franchit aujourd’hui cette première étape. Sa fiche officielle le décrit comme un modèle MoE multimodal de 2,8 billions de paramètres, avec 104 milliards de paramètres activés, 93 couches, une fenêtre de contexte de 1 048 576 tokens et des poids en MXFP4 avec activations MXFP8. La même fiche indique que 16 experts sur 896 sont sélectionnés par token. Ces données servent à construire une estimation, mais elles ne constituent pas une configuration matérielle minimale garantie. (huggingface.co)

Consulter la fiche officielle de Kimi K3 permet également de vérifier le moteur recommandé, le nom des fichiers, la licence et les exemples de lancement. La présence d’une commande de service ne remplace toutefois pas un test de stabilité avec la charge réelle d’une équipe.

DeepSeek V4 est mieux documenté sur le plan institutionnel. Sa fiche officielle distingue une variante Pro de 1,6 billion de paramètres, dont 49 milliards activés par token, et une variante Flash de 285 milliards, dont 13 milliards activés. Les deux sont annoncées avec un contexte de 1 million de tokens, sous licence MIT pour les éléments distribués dans les dépôts ouverts. La fiche précise cependant que le matériel nécessaire doit être vérifié dans la fiche technique propre à chaque dépôt. (fe-static.deepseek.com)

Pour Qwen3.8, la règle de décision doit être plus stricte. Tant que le dépôt officiel ne fournit pas simultanément les poids, le fichier de configuration, la licence, le format de quantification et une procédure de déploiement stable, le modèle reste dans une liste de validation. Il ne doit pas servir à justifier l’achat d’un cluster. Le dépôt public de la série Qwen3 documente les familles disponibles et les chemins d’inférence, mais une mention communautaire ou une page de prévisualisation ne suffit pas à confirmer un checkpoint Qwen3.8 téléchargeable. (github.com)

Cette distinction évite un piège courant : confondre « modèle annoncé », « modèle accessible par API » et « poids complets prêts à servir ».

Kimi K3 et Qwen3.8 en auto-hébergement : quelle VRAM calculer ?

La mémoire des poids est seulement le premier terme. Une estimation exploitable doit séparer les variables :

VRAM totale =
  poids réellement chargés
+ métadonnées de quantification
+ couches non quantifiées
+ KV Cache
+ activations et tampons d’exécution
+ communications parallèles
+ fragmentation
+ marge de panne et de montée en charge

Pour les poids, la formule de départ est :

Mémoire des poids ≈
  nombre total de paramètres × bits par paramètre / 8

Cette formule doit utiliser le nombre total de paramètres résidents, pas le nombre de paramètres activés. Dans un MoE, seuls certains experts participent à chaque token, mais les experts nécessaires au service doivent rester chargés ou être accessibles dans la hiérarchie mémoire. Les paramètres activés renseignent principalement la quantité de calcul par token. Ils ne permettent pas, seuls, de dimensionner la capacité de stockage des poids.

La quantification complique encore le calcul. Un fichier MXFP4 ou un autre format à faible précision embarque des échelles, des groupes, des métadonnées et parfois des couches conservées dans une précision supérieure. La taille du fichier téléchargé n’est donc pas une garantie de la VRAM disponible après initialisation du moteur.

Le KV Cache doit être calculé séparément :

KV Cache ≈
  nombre de couches
× dimensions des clés et valeurs
× longueur de contexte
× nombre de séquences simultanées
× octets par valeur

La forme exacte dépend de l’architecture d’attention, du nombre de têtes, du partage des clés et valeurs, de la compression éventuelle et du type de cache. Pour un agent qui lit de longs dépôts, conserve des traces d’outils ou traite des images, la longueur de contexte et le nombre de séquences actives peuvent devenir plus déterminants que les seuls poids.

Les moteurs modernes exposent généralement la capacité effective du cache après initialisation. La documentation de vLLM montre par exemple une sortie indiquant le nombre total de tokens stockables dans le KV Cache et une estimation de la concurrence pour une longueur de requête donnée. Cette mesure est plus utile qu’une simple addition de fichiers, car elle intègre le comportement réel du moteur. (docs.vllm.ai)

Variable	Ce qu’il faut mesurer	Erreur fréquente
Poids	Paramètres totaux, précision réelle, couches non quantifiées	Utiliser les paramètres activés
KV Cache	Couches, dimension, précision, contexte, séquences	Le mélanger avec la mémoire des poids
Exécution	Activations, graphes, tampons, compilateurs	Supposer que toute la VRAM libre est utilisable
Parallélisme	Réplication, partition, communication inter-nœuds	Diviser la taille du modèle par le nombre de GPU
Résilience	Réserve de capacité, reprise, nœud indisponible	Dimensionner pour un seul lancement réussi

Pour Kimi K3, la présence d’une architecture d’attention propriétaire et d’un composant visuel de 401 millions de paramètres impose de vérifier séparément le chemin multimodal. Un scénario de transcription audio, de montage vidéo assisté ou d’analyse d’images peut donc consommer une enveloppe différente d’un simple échange textuel. (huggingface.co)

Les paramètres activés ne répondent pas à la question d’achat

Le raisonnement « Kimi K3 n’active que 104 milliards de paramètres, donc il suffit de prévoir la mémoire de 104 milliards » est faux pour trois raisons.

Premièrement, les experts résident dans le système de poids. Deuxièmement, l’aiguillage des tokens doit accéder aux experts concernés avec une latence acceptable. Troisièmement, plusieurs requêtes simultanées peuvent sélectionner des experts différents, ce qui augmente la pression sur les transferts et les tampons.

Le même principe s’applique à DeepSeek V4. Les 49 milliards ou 13 milliards activés décrivent le calcul par token selon la variante officielle, mais non la capacité nécessaire pour charger l’ensemble du checkpoint. La fiche officielle confirme d’ailleurs l’existence de deux canaux distincts, déploiement ouvert et API, ce qui permet de comparer les options sans présenter l’auto-hébergement comme la seule voie possible. (fe-static.deepseek.com)

Pour Qwen3.8, aucun calcul d’achat ne devrait être publié à partir d’un nombre circulant dans une discussion communautaire. Tant que le champ officiel du modèle, la précision et la licence ne sont pas vérifiés, il faut laisser ces cellules vides dans le tableau de capacité.

Du modèle chargé au service utilisable

Un chargement réussi ne prouve pas que le système peut servir une équipe. Trois indicateurs doivent être testés ensemble :

• délai avant le premier token ;
• débit de génération sous concurrence ;
• comportement lorsque le contexte s’allonge ou qu’un agent enchaîne plusieurs outils.

Un test limité à une question courte favorise artificiellement les configurations trop justes. Un agent de développement peut ouvrir un dépôt, appeler une commande, relire une sortie, produire un correctif, exécuter une nouvelle commande et conserver toute la trace dans la même session. Le profil mémoire est alors très différent d’un échange isolé.

La stratégie de parallélisme modifie aussi le résultat. Le parallélisme tensoriel répartit les opérations d’une couche entre accélérateurs. Le parallélisme pipeline répartit les couches entre nœuds. Le parallélisme expert distribue les experts MoE et peut éviter de traiter un modèle géant comme un modèle dense classique.

La documentation de déploiement distribué indique qu’un modèle trop grand pour un nœud peut combiner parallélisme tensoriel et pipeline. Elle précise aussi que les répartitions inégales peuvent favoriser le pipeline, notamment lorsque l’interconnexion ne fournit pas la bande passante attendue pour le tensoriel. (docs.vllm.ai)

Pour un MoE, la documentation dédiée au parallélisme expert distingue les couches d’experts, réparties sur le groupe EP, et les couches d’attention, qui peuvent être répliquées ou partitionnées selon la configuration. Elle donne également l’exemple d’un groupe EP calculé à partir de la taille tensorielle et de la réplication des données. (github.com)

Charge à tester	Mesure minimale	Décision associée
Dialogue court	Premier token et débit avec plusieurs requêtes	Vérifier la réactivité de base
Contexte long	Occupation du KV Cache et taux d’éviction	Vérifier la marge mémoire
Agent avec outils	Latence d’un cycle complet et stabilité après plusieurs appels	Vérifier la valeur applicative
Audio, image ou vidéo	Mémoire du composant multimodal et temps de prétraitement	Vérifier le scénario créatif
Reprise après incident	Temps de rechargement et conservation de la file	Vérifier l’exploitation réelle

Le coût dépend davantage de l’utilisation que du prix du GPU

Le coût d’un auto-hébergement doit être écrit comme une équation, sans préremplir de montant non vérifié :

Coût mensuel complet =
  location ou amortissement des accélérateurs
+ hôtes, stockage et réseau
+ électricité et refroidissement
+ ingénierie de déploiement
+ surveillance et astreinte
+ validation des nouvelles versions
+ capacité de secours
+ coût des périodes d’inactivité

Le coût API suit une autre structure :

Coût API =
  tokens d’entrée facturés
+ tokens de sortie facturés
+ appels de reprise
+ stockage ou récupération de contexte
+ éventuels frais de réseau et d’orchestration

Les tarifs doivent être pris sur la page officielle du fournisseur au moment du calcul. Si le tarif, la remise de cache ou la facturation des entrées longues ne sont pas confirmés, il vaut mieux conserver la variable que publier un montant fragile.

Option	Avantage principal	Coût caché	Condition de choix
Cluster acheté	Capacité contrôlée et données dans le périmètre interne	Immobilisation, maintenance, panne et sous-utilisation	Charge stable et équipe d’exploitation disponible
Accélérateurs loués	Validation rapide sans achat immédiat	Livraison, stockage, réseau et durée minimale	Besoin de test ou de montée en charge temporaire
API	Capacité élastique et faible effort matériel	Dépendance au tarif, au débit et aux politiques du fournisseur	Charge variable ou modèle encore en sélection
Double voie	Production flexible et validation indépendante	Deux chaînes à maintenir	Phase de transition ou forte incertitude

Le point d’équilibre doit donc utiliser le taux d’utilisation réel :

Coût par token interne =
  coût mensuel complet / tokens effectivement servis

Le dénominateur ne doit pas être la capacité théorique. Une grappe capable de répondre à une charge maximale mais inactive la majorité du temps peut coûter davantage qu’une API, même si son coût marginal calculé sur un pic semble inférieur.

Une procédure de validation en sept étapes

1. Figer le scénario d’usage.
   Séparez dialogue, génération de code, recherche documentaire, appels d’outils, traitement d’images et flux audio ou vidéo. Un modèle destiné à un agent de montage n’a pas le même profil qu’un assistant textuel.

2. Vérifier les sources officielles.
   Archivez la fiche du modèle, le fichier de configuration, la licence, les versions des poids et la documentation du moteur. Pour Qwen3.8, toute information absente reste « à confirmer ».

3. Calculer les poids par précision.
   Faites un scénario par format disponible. Ajoutez les échelles de quantification, les couches non quantifiées et les composants multimodaux.

4. Calculer le KV Cache par charge.
   Utilisez plusieurs longueurs de contexte et plusieurs nombres de séquences. Ne retenez pas uniquement la configuration qui tient avec une requête.

5. Lancer un test de chargement reproductible.
   Conservez l’image logicielle, les paramètres du moteur, le type de parallélisme et les journaux. Le résultat doit pouvoir être reproduit après une mise à jour.

6. Tester la charge utile.
   Mesurez le premier token, le débit, les erreurs, l’occupation mémoire et les files d’attente sur dialogue court, contexte long et agent avec outils.

7. Comparer avec l’API et la location.
   Utilisez le même volume d’entrée, de sortie, de contexte et de requêtes répétées. Décidez ensuite entre auto-hébergement, location, API ou double voie.

La ligne d’abandon doit être écrite avant l’achat

L’auto-hébergement doit être abandonné si l’un des critères suivants apparaît :

• le modèle chargé ne tient pas le contexte requis avec la marge prévue ;
• le premier token ou le débit ne respecte pas l’objectif de service ;
• le framework impose une version instable ou un contournement non maintenable ;
• le réseau inter-nœuds annule le gain du parallélisme ;
• la surveillance, les mises à jour et la reprise dépassent les ressources de l’équipe ;
• le délai d’extension est incompatible avec les pics d’activité ;
• l’utilisation prévue est trop irrégulière pour amortir la capacité.

Un cas fréquent concerne une équipe d’agents qui traite de petits volumes en semaine, puis quelques campagnes vidéo ou de recherche très intenses. Un cluster permanent paraît séduisant pour les pics, mais reste sous-utilisé entre deux campagnes. La location courte permet de tester le flux complet ; l’API absorbe les périodes creuses. Cette combinaison produit souvent une décision plus robuste qu’un achat fondé sur un seul scénario maximal.

Le cloud Mac ne remplace pas un cluster d’inférence pour Kimi K3, Qwen3.8 ou DeepSeek V4. Il est plus pertinent comme environnement distant pour développer les agents, préparer les scripts, contrôler les dépôts, tester les interfaces audio et vidéo ou surveiller un déploiement existant. Les équipes peuvent consulter la console ProxyMac pour organiser cet environnement de travail, tout en séparant clairement le poste de développement de la capacité qui porte réellement le modèle.

Le choix final doit tenir sur une feuille de décision

Critère	Auto-héberger	Louer temporairement	API	Double voie
Charge stable et élevée	Oui	Parfois	À comparer	Oui
Charge imprévisible	Risqué	Oui	Oui	Oui
Données strictement internes	Oui	Selon contrat et isolation	À vérifier	Selon flux
Modèle encore incomplet	Non	Oui, pour valider	Oui	Oui
Équipe distribuée expérimentée	Requis	Recommandé	Non requis	Recommandé
Besoin de tester un agent audio ou vidéo	Après validation	Très adapté	Adapté	Très adapté
Besoin d’une décision rapide	Rarement	Oui	Oui	Oui

La conclusion est donc conditionnelle mais opérationnelle :

• Auto-hébergement si la charge est stable, le modèle est officiellement distribuable, les objectifs de service sont atteints et l’équipe possède la capacité d’exploitation.
• Location si le modèle doit être testé, si le besoin est temporaire ou si le cluster n’est pas encore justifié.
• API si la charge varie, si le modèle change encore ou si l’exploitation distribuée n’est pas une compétence disponible.
• Double voie si la production doit rester flexible pendant que l’équipe valide les poids, le contexte, les agents et le coût réel.

Avant de signer un achat, l’équipe peut copier le tableau des variables dans son propre modèle financier, avec ses tokens d’entrée, ses sorties, son contexte moyen, sa concurrence et son taux d’utilisation. Si le résultat reste proche du point d’équilibre, une capacité louée sur une courte période permet de vérifier les scripts de déploiement, la chaîne de supervision et les agents dans des conditions réelles.

C’est aussi là que l’auto-hébergement classique montre ses limites : immobilisation du matériel, sous-utilisation entre les pics, dépendance à une équipe d’astreinte et extension parfois lente. Pour le développement distant, les essais créatifs et l’exploitation d’outils autour du modèle, louer un environnement Mac via ProxyMac peut être plus simple que maintenir une station dédiée. Les conditions d’usage et les limites de service doivent être vérifiées dans les conditions ProxyMac, tandis que les flux contenant des données sensibles doivent être examinés avec la politique de confidentialité ProxyMac.