Échec de démarrage Kimi K3 vLLM : que changer ?

Symptôme : l’image officielle Kimi K3 en cu130 échoue sur un hôte NVIDIA r575, souvent avec une erreur CUDA, de pilote ou d’initialisation du moteur.

Solution la plus rapide : si l’incompatibilité cu130/r575 est confirmée et qu’une fenêtre de maintenance existe, mettez à niveau le pilote vers une branche r580 ou plus récente, avec un nœud de retour prêt. Si le cluster partagé ne peut pas changer de pilote aujourd’hui, basculez vers un environnement isolé ; ne reconstruisez cu129 qu’en solution transitoire si votre équipe sait maintenir toute la chaîne de dépendances.

Dernière mise à jour : 5 août 2026. Les informations techniques ont été vérifiées dans le recipe officiel Kimi K3 de vLLM, le billet de publication vLLM du 27 juillet 2026 et la documentation NVIDIA sur la compatibilité CUDA.

Cet article s’adresse à vous si vous exploitez un cluster r575 et devez remettre Kimi K3 en service le jour même. Il concerne aussi les responsables de plateforme qui doivent approuver une modification de pilote, ainsi que les équipes Agent qui ne veulent pas bloquer leurs essais audio, vidéo, design ou automatisation sur un problème d’infrastructure.

Le constat initial : un démarrage interrompu ne signifie pas automatiquement « mémoire insuffisante »

Un cas fréquent se déroule ainsi : vous tirez l’image dédiée à Kimi K3, le conteneur démarre, puis vLLM s’arrête pendant l’initialisation CUDA. Vous voyez parfois une erreur de compatibilité du pilote, une impossibilité de charger un noyau, un échec NCCL ou une interruption du moteur avant le chargement complet des poids.

À ce moment, ne modifiez pas encore dix paramètres de lancement. Conservez d’abord :

• le nom exact de l’image Docker et son étiquette ;
• la version de vLLM et sa provenance ;
• la sortie complète de nvidia-smi ;
• la version du pilote et sa branche ;
• le système d’exploitation de l’hôte ;
• la ligne de commande complète ;
• les journaux du conteneur depuis la première erreur ;
• la configuration du réseau inter­nœuds, de NCCL et du runtime de conteneurs.

Le recipe Kimi K3 de vLLM indique que l’image vllm/vllm-openai:kimi-k3 est construite uniquement pour CUDA 13, sous la forme cu130. Le même document demande un pilote NVIDIA r580 ou plus récent ; un hôte CUDA 12.9 associé à r575 doit donc être mis à niveau ou utiliser une construction vLLM personnalisée.

Cette distinction est importante. Une incompatibilité cu130/r575 se produit avant ou pendant l’initialisation du moteur. Un dépassement de mémoire apparaît généralement plus tard, lorsque le modèle, le cache ou les premières requêtes consomment les ressources disponibles. Les deux problèmes peuvent produire un service indisponible, mais ils ne se traitent pas de la même manière.

Le premier contrôle : cu130 contre r575

Commencez par vérifier l’environnement réel, pas celui décrit dans votre fichier de déploiement.

nvidia-smi
docker image inspect vllm/vllm-openai:kimi-k3
docker version

Dans la sortie de nvidia-smi, notez la version complète du pilote. Ne vous contentez pas de regarder la version maximale de CUDA affichée : cette valeur indique ce que le pilote annonce pouvoir prendre en charge, mais elle ne remplace pas la matrice de compatibilité.

CUDA 13.x demande une version de pilote au moins égale à 580 pour la compatibilité mineure. Les notes CUDA 13.0 indiquent également une version Linux de référence égale ou supérieure à 580.65.06. À l’inverse, CUDA 12.9 appartient encore à la plage r575 dans les tableaux NVIDIA. Cela explique pourquoi une image cu130 peut refuser un hôte r575 alors que d’autres conteneurs cu12 fonctionnent correctement sur le même cluster. Vous pouvez vérifier les seuils dans les notes de version CUDA 13.0.

Classez le diagnostic en trois niveaux :

1. Blocage de compatibilité : le journal mentionne une incompatibilité de pilote, une erreur CUDA système ou un échec lors du chargement des bibliothèques.
2. Blocage d’intégration : CUDA est initialisé, mais NCCL, le réseau, le backend MoE ou le transfert inter­nœuds échoue.
3. Blocage de capacité : le moteur démarre, puis le chargement, le contexte ou la concurrence provoque une erreur mémoire.

Ne choisissez une nouvelle stratégie d’environnement que si le premier niveau est démontré. Si CUDA s’initialise correctement, changer de pilote peut déplacer le problème sans le résoudre.

Une image cu130 peut-elle fonctionner sur r575 ?

Pour le chemin officiel documenté au 5 août 2026, vous devez considérer cu130 et r575 comme incompatibles. Le problème ne se corrige pas en ajoutant simplement un argument de contexte, en diminuant la concurrence ou en relançant le conteneur. Ces paramètres peuvent aider après l’initialisation, mais ils ne lèvent pas une incompatibilité entre la version CUDA de l’image et le pilote de l’hôte.

Si votre journal montre seulement un OOM après le chargement du modèle, ne concluez pas trop vite à un problème cu130/r575. Vérifiez d’abord que le pilote a bien été détecté, que les bibliothèques du conteneur sont accessibles et que l’échec survient au même stade sur plusieurs nœuds.

La décision du jour : mise à niveau, reconstruction ou environnement isolé

Les trois chemins ne répondent pas au même besoin. La mise à niveau corrige la cause à la source, la reconstruction cu129 conserve temporairement le socle r575 et l’environnement isolé réduit le risque sur le cluster partagé.

Faut-il mettre à niveau le pilote ou reconstruire vLLM ?

Choisissez la mise à niveau si vous pouvez réserver un nœud, arrêter ses charges, redémarrer proprement et exécuter une régression sur les workloads existants. Le bénéfice est opérationnel : vous restez sur le chemin documenté par le recipe officiel, au lieu de maintenir une variante locale.

La mise à niveau n’est toutefois pas un simple remplacement de paquet. Le pilote intervient dans :

• le runtime NVIDIA utilisé par les conteneurs ;
• les bibliothèques de communication ;
• la compatibilité avec le noyau Linux ;
• les modules nécessaires au réseau direct GPU ;
• les autres modèles déjà servis sur le cluster ;
• les outils de supervision et de réservation des GPU.

La mise à niveau devient le choix par défaut lorsque trois conditions sont réunies : la cause cu130/r575 est prouvée, une fenêtre de maintenance est approuvée et un plan de retour existe. Si l’une de ces conditions manque, ne modifiez pas immédiatement tous les nœuds.

La reconstruction cu129 est pertinente lorsque le cluster ne peut pas encore passer à r580, mais que vous possédez déjà une chaîne de compilation fiable. Vous devez alors accepter de maintenir plus qu’un simple fichier Docker : branche K3, version de PyTorch, roues adaptées, dépendances de compilation, noyaux spécialisés, FlashInfer, NCCL et procédure de reconstruction.

Le billet vLLM consacré à Kimi K3 rappelle que les dépendances sont complexes et que les images Docker constituent le chemin utilisable pour le démarrage documenté. Une reconstruction locale peut donc débloquer une validation, mais elle augmente votre surface de maintenance.

Réservez cette voie à une équipe qui sait répondre à ces questions :

• quelle révision exacte de la branche K3 a été compilée ;
• quelles versions de PyTorch et des bibliothèques CUDA sont embarquées ;
• comment reproduire l’image dans un registre interne ;
• comment comparer les résultats avec l’image officielle cu130 ;
• qui prend en charge les correctifs après une mise à jour vLLM ;
• quelle date ou quel événement déclenche l’abandon de cette variante.

Si vous ne pouvez pas répondre, cette reconstruction risque de devenir une nouvelle panne difficile à auditer. Elle doit rester une passerelle, pas votre état cible de production.

L’environnement isolé : la sortie de secours lorsque le cluster partagé ne peut pas changer

Si votre cluster partagé ne peut pas changer de pilote avant plusieurs jours, arrêtez les modifications locales. Une plateforme isolée permet de séparer le besoin urgent de validation du calendrier de gouvernance du cluster.

Pour les essais d’Agent, cette séparation est souvent plus utile qu’un contournement fragile. Vous pouvez vérifier l’appel d’outils, la sortie structurée, les entrées visuelles ou un flux audio-vers-texte sans exposer les services existants à une modification de pilote. En revanche, vous devez documenter les différences : réseau, stockage des poids, règles d’accès, latence inter­nœuds, observabilité et méthode de restauration.

Vous pouvez suivre les étapes de livraison et de connexion dans la console MacHTML, puis consulter la documentation d’aide MacHTML si votre équipe doit reproduire l’accès ou préparer un retour contrôlé.

L’environnement isolé convient particulièrement à quatre situations :

• le cluster de production est soumis à une procédure de changement longue ;
• vous devez débloquer une intégration Agent avant la prochaine fenêtre ;
• plusieurs équipes utilisent le même socle de pilote ;
• vous voulez comparer cu130, cu129 et les paramètres de service sans modifier les charges existantes.

Son défaut est clair : il faut reconstruire l’accès aux données, les secrets, les métriques, le réseau et parfois le stockage des poids. Ce travail n’est pas une disparition du problème ; c’est un déplacement contrôlé du problème vers un périmètre plus facile à restaurer.

La fenêtre de changement : une validation avant une généralisation

Avant toute modification du pilote, constituez une fiche de référence par nœud :

• état des GPU et des processus actifs ;
• version du noyau ;
• version du runtime de conteneurs ;
• version du pilote et des bibliothèques utilisateur ;
• état de NCCL sur une charge existante ;
• topologie PCIe, NVLink ou réseau utilisée par le service ;
• modèles qui doivent rester disponibles ;
• procédure de drainage et de remise en service ;
• propriétaire de la décision de retour arrière.

Ne copiez pas une commande de mise à niveau trouvée dans un forum. La syntaxe dépend de votre distribution, de votre gestionnaire de paquets, du type de pilote et de la politique du cluster. Utilisez la procédure officielle correspondant à votre plateforme, puis consignez le paquet installé, le redémarrage effectué et le résultat du contrôle.

Sur le premier nœud, exécutez une progression en cinq étapes :

1. vérifier que le pilote est visible par l’hôte ;
2. vérifier que le conteneur accède aux GPU ;
3. lancer une initialisation minimale de vLLM ;
4. charger Kimi K3 sans trafic applicatif ;
5. envoyer une requête courte avant de tester le contexte cible.

Ne passez à plusieurs nœuds qu’après la réussite de cette séquence. Si le cluster partagé ne permet pas cette progression, l’environnement isolé devient le choix le moins risqué, même s’il ne s’agit pas encore de votre architecture finale.

Le retour arrière doit être défini avant l’opération. Il doit préciser l’image précédente, le pilote précédent, les paquets à restaurer, le nœud concerné, les tests à refaire et la personne autorisée à interrompre le déploiement. Une restauration non documentée n’est pas un plan de reprise ; c’est une hypothèse.

Le redémarrage du service : prefix caching doit être vérifié séparément

Un processus qui reste en écoute sur son port n’est pas nécessairement une migration réussie. Vous devez vérifier le chargement du modèle, une requête texte, une requête multimodale si elle fait partie de votre usage, les appels d’outils et le cache de préfixe.

Le billet vLLM indique que le prefix caching est pris en charge pour le cache KV de l’attention complète et pour l’état récurrent KDA, mais qu’il est désactivé par défaut pour Kimi K3. Le paramètre --enable-prefix-caching doit donc être ajouté explicitement.

La commande de base publiée par vLLM contient notamment :

vllm serve moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --trust-remote-code \
  --load-format fastsafetensors \
  --enable-prefix-caching \
  --enable-auto-tool-choice \
  --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3

Adaptez cette commande à votre recette validée. Ne mesurez pas le cache avec deux requêtes qui ont des préfixes différents. Pour obtenir une comparaison utile :

1. choisissez un long préfixe fixe ;
2. envoyez une première requête de référence ;
3. renvoyez exactement le même préfixe avec une question différente ;
4. répétez le test après un redémarrage contrôlé ;
5. comparez les journaux et les métriques de réutilisation disponibles ;
6. notez la politique de conservation et la pression mémoire.

Un cache peut sembler inactif pour trois raisons différentes : le paramètre n’est pas activé, le préfixe varie réellement, ou l’état n’est pas conservé assez longtemps. Une faible réutilisation ne prouve donc pas que le nouveau pilote est défectueux. Elle indique qu’il faut examiner la forme des requêtes et la stratégie de rétention.

Pourquoi le prefix caching reste-t-il inactif après le démarrage ?

Vérifiez d’abord que l’argument est réellement présent dans la commande du processus, et non seulement dans un fichier de configuration qui n’est pas chargé par le conteneur. Vérifiez ensuite que les messages système, les instructions ou les blocs d’outils du préfixe restent identiques d’une requête à l’autre.

Pour un Agent, une différence minime peut empêcher la réutilisation : identifiant de session inclus dans le prompt système, horodatage, liste d’outils réordonnée, espace ajouté dans un document ou changement automatique d’un champ multimodal. Le service peut donc être correctement configuré alors que l’application ne fournit jamais deux préfixes identiques.

Enfin, comparez le comportement sous faible et forte pression. Un cache qui fonctionne sur deux requêtes isolées peut être évincé lorsque le nombre de sessions augmente. Cette observation relève de la capacité et de la politique de rétention, pas nécessairement du pilote.

La première charge : séparer capacité, communication et application

Après le démarrage, augmentez la charge par paliers. Ne commencez pas directement par votre scénario Agent complet avec outils, vision, contexte long et plusieurs utilisateurs.

Conservez un journal pour chaque palier :

• chargement du modèle sans requête ;
• requête texte courte ;
• requête avec le contexte cible ;
• répétition avec préfixe partagé ;
• plusieurs requêtes concurrentes ;
• appel d’outil et sortie structurée ;
• entrée visuelle ou audio si nécessaire ;
• trafic inter­nœuds et volume représentatif.

Le recipe officiel mentionne une base matérielle minimale de 8 GPU GB300 pour le chemin NVIDIA dédié, tandis que le billet vLLM décrit aussi des configurations multi­nœuds et d’autres générations de GPU. Ces indications ne constituent pas une promesse de performance pour votre cluster : elles servent à vérifier que votre architecture ne s’écarte pas du chemin de validation publié.

Si vous obtenez une erreur de mémoire après le chargement, ouvrez une piste capacité séparée. Examinez la longueur maximale, le nombre de requêtes simultanées, la taille du cache et la répartition tensorielle. Si vous obtenez une erreur NCCL ou une interruption réseau, ouvrez une piste communication. Le recipe recommande des réglages différents selon que le trafic passe par RDMA ou NVLink, ainsi que des options spécifiques pour certains échecs d’enregistrement mlx5.

Ne déclarez pas la mise à niveau du pilote responsable d’un OOM apparu uniquement lorsque vous avez augmenté le contexte ou la concurrence. Le changement de pilote peut avoir corrigé le blocage initial, tandis que la nouvelle erreur révèle une limite indépendante.

La décision après observation : conserver, isoler ou revenir

À la fin de la période d’observation, rédigez une décision courte et vérifiable. Elle doit répondre à quatre questions :

• le démarrage est-il reproductible sur le même type de nœud ;
• le prefix caching produit-il une réutilisation démontrable ;
• les appels Agent restent-ils corrects, y compris les sorties d’outils ;
• la maintenance est-elle acceptable pour votre équipe ?

Utilisez cette liste avant de fermer l’incident :

• [ ] L’image, la version vLLM et la commande ont été archivées.
• [ ] La branche de pilote et la version CUDA de l’hôte sont documentées.
• [ ] Le premier nœud a passé un démarrage à froid.
• [ ] Une requête courte et une requête représentative ont réussi.
• [ ] Les tests inter­nœuds ont été exécutés si le service en dépend.
• [ ] Le paramètre --enable-prefix-caching est présent dans la configuration retenue.
• [ ] Deux requêtes avec un préfixe identique ont fourni une preuve de réutilisation.
• [ ] Les appels d’outils et les sorties structurées ont été vérifiés.
• [ ] Le plan de retour au pilote précédent est encore exécutable.
• [ ] La date de fin de l’environnement temporaire est écrite dans le ticket de changement.

La conclusion est généralement l’une des trois suivantes. Vous conservez r580 si les charges existantes et Kimi K3 passent la régression. Vous maintenez l’environnement isolé si le cluster partagé ne peut pas absorber le changement ou si la validation applicative doit continuer sans attendre. Vous revenez au socle r575 si la modification introduit une régression critique et si Kimi K3 n’est pas encore une charge prioritaire.

Le choix d’environnement : vitesse de récupération contre dette d’exploitation

L’environnement actuel a souvent trois défauts dans ce scénario : il impose un calendrier de maintenance collectif, il mélange les dépendances de plusieurs modèles et il rend le retour arrière coûteux lorsque le nœud héberge déjà des charges importantes. Une reconstruction cu129 ajoute une autre dette : vous devenez responsable de la compatibilité d’une chaîne que le recipe officiel ne fournit pas directement.

Si votre objectif immédiat est de terminer une validation Kimi K3 ou une intégration Agent, la location d’un environnement MacHTML isolé peut être plus simple à justifier qu’une modification précipitée du cluster. Vous séparez le test du pilote r575, vous conservez votre procédure de retour et vous pouvez décider ensuite si la migration permanente mérite une fenêtre de changement. Pour examiner les modalités disponibles sans confondre une plateforme temporaire avec votre architecture de production, consultez les offres MacHTML adaptées à votre région.

Ce choix ne convient pas à tous les cas. Un service stable à forte charge, avec des exigences de réseau privé, de stockage local ou d’interfaces physiques, peut nécessiter un cluster détenu en propre. En revanche, pour une validation temporaire, une démonstration client, un prototype audio ou vidéo, une campagne de tests Agent ou une comparaison de versions, l’isolement réduit le risque principal : continuer à modifier un cluster partagé alors que la cause du blocage est déjà connue.

Pour aller plus loin: Déployer Kimi K3 en local : prérequis et procédure de validation Choisir une API Kimi K3 principale et une solution de secours