Kimi K3 avec vLLM : validation de mise en production

Le processus démarre et répond à une requête, mais le service ne passe pas encore automatiquement en production.

La validation de mise en production de Kimi K3 avec vLLM est gagnée uniquement lorsque la chaîne CUDA 13–pilote R580, la stabilité sous charge, les réutilisations du prefix caching et les appels d’outils sont tous documentés. Si la version officielle n’est pas respectée, il faut reconstruire l’environnement. Si la mémoire sature durablement, il faut revoir la topologie ou augmenter les ressources, plutôt que multiplier les ajustements isolés.

Cet article s’adresse aux ingénieurs qui ont déjà lancé Kimi K3 avec vLLM et veulent passer des essais à un service exploitable, aux responsables SRE qui doivent signer une décision de mise en ligne, ainsi qu’aux décideurs qui comparent un cluster interne, une extension temporaire ou un environnement distant.

Dernière mise à jour : 13 août 2026. Les versions et exigences ont été recoupées avec la recette officielle Kimi K3, la publication vLLM dédiée, la documentation des métriques de production et la matrice de compatibilité CUDA de NVIDIA.

Le démarrage du processus ne vaut pas validation de production

Kimi K3 est encore présenté comme une version « pre-release » dans la recette officielle vLLM. Cette recette référence un modèle multimodal MoE de 2,8 billions de paramètres, une fenêtre de contexte pouvant atteindre 1 048 576 tokens et une compatibilité vLLM indiquée à partir de la version 0.27.1+. Ces éléments définissent un périmètre technique, pas une autorisation automatique de mise en ligne. Consultez la recette officielle Kimi K3 de vLLM.

Un service qui reste actif prouve seulement que le chargement initial, le réseau et une partie du moteur fonctionnent. Une réponse HTTP 200 prouve que l’interface répond dans un cas donné. Elle ne prouve pas que :

• le conteneur utilise réellement la construction CUDA attendue ;
• le pilote visible par le conteneur est compatible avec cette construction ;
• la mémoire reste suffisante après plusieurs requêtes longues ;
• les préfixes répétés sont réellement réutilisés ;
• les appels d’outils et les sorties structurées respectent le contrat du client.

La décision doit donc être classée dans l’une des quatre catégories suivantes.

Décision	Conditions minimales	Action immédiate
Mise en production	Compatibilité confirmée, test de charge stable, cache observé, appels d’outils validés	Autoriser le trafic prévu et activer la surveillance
Observation limitée	Défaut non critique, reproductibilité connue, limite de trafic explicite	Mettre en place une limitation et une date de réexamen
Reprise de l’environnement	Version CUDA, pilote, image ou paramètres incompatibles avec la recette	Reconstruire puis refaire toute la validation
Extension de capacité	Saturation répétée malgré une configuration cohérente	Ajuster la topologie, le contexte, la concurrence ou le nombre de GPU

La conclusion doit être accompagnée des journaux de démarrage, de la configuration exacte, des courbes mémoire, des paramètres de charge et des résultats des requêtes de référence. Une simple capture d’écran du processus actif n’est pas une preuve suffisante.

Compatibilité officielle : CUDA 13 et pilote NVIDIA R580 doivent raconter la même histoire

La première vérification porte sur la chaîne complète, et non sur une seule commande. Pour CUDA 13.x, la matrice officielle de compatibilité indique un pilote minimal de branche 580 ; les pilotes plus récents peuvent également assurer la compatibilité ascendante selon les composants utilisés. Vérifiez la matrice officielle CUDA–pilotes.

La recette Kimi K3 ajoute une contrainte opérationnelle : la solution est décrite avec une construction CUDA 13 et un pilote hôte R580 ou plus récent. Cette exigence doit être vérifiée à trois niveaux :

1. Dans l’hôte : version complète du pilote, branche, état du module NVIDIA et présence éventuelle d’un Fabric Manager requis par la topologie.
2. Dans le conteneur : version des bibliothèques CUDA visibles, image utilisée, chemin des bibliothèques et accès réel aux GPU.
3. Dans les journaux vLLM : version du moteur, options activées, initialisation des périphériques, erreurs de chargement et avertissements de compatibilité.

nvidia-smi est utile, mais sa ligne « CUDA Version » ne constitue pas à elle seule la preuve que le conteneur utilise la construction attendue. La commande peut refléter la capacité annoncée par le pilote alors que l’image embarque d’autres bibliothèques ou qu’un composant du moteur a été compilé dans un environnement différent.

Élément à comparer	Preuve à conserver	Décision en cas d’écart
Image et balise vLLM	Nom exact de l’image, digest, date de récupération	Ne pas mélanger le résultat avec une autre image
Version vLLM	Sortie du paquet ou du journal de démarrage	Reprendre la recette officielle si la version est hors périmètre
Construction CUDA	Manifest de l’image, bibliothèques chargées, journal de compilation	Recréer l’image ou documenter une construction indépendante
Pilote hôte	Version complète et branche R580 ou ultérieure	Mettre à niveau avant tout test fonctionnel
Visibilité des GPU	nvidia-smi, périphériques du conteneur, journal d’initialisation	Corriger le runtime avant de mesurer les performances
Méthode de construction	Dépendances verrouillées, commit, procédure de retour arrière	Séparer ce résultat de l’acceptation de l’image officielle

Si l’équipe choisit de construire Kimi K3 dans une autre base CUDA, le résultat doit être traité comme une variante expérimentale. Il faut conserver le fichier de construction, les versions de dépendances, le commit vLLM, les options de compilation et la procédure de retour arrière. Cette variante ne doit pas être déclarée conforme à la recette officielle simplement parce qu’une requête courte aboutit.

Point de contrôle : une chaîne « image officielle + pilote compatible » et une chaîne « image personnalisée + dépendances locales » sont deux produits différents. Elles nécessitent deux fiches de validation et deux procédures de retour arrière.

Que vérifier après le démarrage réussi de Kimi K3 avec vLLM ?

Après la disponibilité du port, l’équipe doit exécuter un échantillon fixe qui ressemble aux requêtes réelles d’un Agent. Un court message sans outils est trop favorable : il évite les longues instructions système, les définitions de fonctions, les sorties structurées et les échanges répétés qui consomment davantage de mémoire.

L’échantillon de référence devrait contenir :

• une instruction système stable ;
• un schéma de plusieurs outils ;
• une requête nécessitant au moins un appel d’outil ;
• une seconde étape utilisant le résultat de cet outil ;
• une réponse structurée validée par schéma ;
• une requête multimodale si le service traite des images ;
• un cas d’erreur provoquant un retour contrôlé ou une nouvelle tentative ;
• un échange suffisamment long pour exposer la croissance du cache et de la file d’attente.

Pour chaque cas, le dossier d’acceptation doit retenir le corps de la requête, les paramètres max_tokens, la limite de contexte, la température, le schéma d’outil, le résultat brut, le résultat après parsing et la décision du client. Cette discipline permet de séparer un défaut du modèle d’un défaut du serveur HTTP, du répartiteur, du parseur JSON ou de la logique d’Agent.

Les appels d’outils demandent une attention particulière. La documentation de la pile Kimi K3 indique l’usage conjoint de --enable-auto-tool-choice, du parseur de raisonnement kimi_k3 et du parseur d’appels d’outils kimi_k3 dans les configurations concernées. Consultez les paramètres de validation des appels d’outils.

Le test est considéré comme réussi seulement si :

• le champ tool_calls est présent lorsque l’outil doit être appelé ;
• le nom de fonction correspond exactement au schéma ;
• les arguments sont du JSON valide ;
• le client peut exécuter l’outil sans transformation ambiguë ;
• la réponse finale respecte le contrat attendu ;
• une erreur d’outil déclenche le comportement de repli prévu ;
• la répétition du même scénario produit une structure compatible, même si le texte varie.

Un seul succès de démonstration ne suffit donc pas. Il faut répéter les scénarios et vérifier le contrat, pas uniquement lire le contenu produit à l’écran.

Capacité mémoire : transformer un OOM en décision exploitable

Un OOM n’est pas toujours la preuve que la machine entière est trop petite. Il peut apparaître au chargement des poids, lors d’un long préremplissage, pendant une pointe de concurrence, après l’accumulation du KV cache ou à la suite d’une configuration de parallélisme mal adaptée.

Le test de capacité doit être découpé en quatre phases :

1. Chargement à froid : démarrer le service, attendre son état prêt et enregistrer l’occupation GPU de chaque carte.
2. Contexte long : envoyer un échantillon dont la longueur se rapproche du trafic prévu, sans augmenter simultanément la concurrence.
3. Concurrence progressive : ajouter des requêtes jusqu’au niveau attendu, en surveillant les requêtes actives, celles en attente et les préemptions.
4. Fonctionnement prolongé : maintenir le trafic pendant une durée représentative afin de repérer une accumulation, une éviction excessive ou une fragmentation.

La documentation vLLM expose notamment vllm:kv_cache_usage_perc, vllm:num_requests_running, vllm:num_requests_waiting, vllm:num_preemptions, ainsi que des histogrammes de latence et de temps de file d’attente. Référez-vous à la liste officielle des métriques de production.

L’équipe doit conserver :

• la courbe de mémoire de chaque GPU avant, pendant et après l’erreur ;
• la longueur d’entrée et la longueur de sortie demandée ;
• le nombre de requêtes actives ;
• la configuration de parallélisme ;
• la limite de contexte ;
• la valeur de gpu-memory-utilization ;
• le nombre de tokens regroupés par itération ;
• l’heure exacte de l’OOM et les lignes de journal qui la précèdent.

Une saturation au démarrage appelle une reprise de la topologie ou de l’image. Une saturation uniquement sur les contextes longs peut conduire à réduire la limite de contexte ou à répartir différemment la charge. Une saturation qui survient lorsque les requêtes se chevauchent peut indiquer une capacité de cache insuffisante, une concurrence trop élevée ou une file d’attente mal contrôlée.

Il ne faut pas appliquer un seuil universel de mémoire sans tenir compte du matériel, du type de poids, du parallélisme et des requêtes. Les valeurs publiées dans une recette servent de point de départ. Elles ne remplacent pas les mesures de la configuration réellement livrée.

Kimi K3 en OOM peut-il tout de même être mis en ligne ?

Oui, uniquement dans un cas très encadré : l’OOM doit être reproduit dans une condition volontairement hors périmètre, par exemple une longueur de contexte interdite par le contrat de service, et le système doit refuser cette requête avant d’épuiser les GPU.

En revanche, un OOM sur le trafic nominal, une croissance continue de la mémoire ou une saturation qui dépend d’un niveau de concurrence normal impose un refus de mise en production. Le service peut être limité temporairement pour recueillir des données, mais il ne doit pas être présenté comme stable.

Prefix caching : présence du paramètre contre réutilisation mesurée

Pour Kimi K3, le prefix caching doit être explicitement activé selon les éléments de référence fournis par vLLM. La présence de --enable-prefix-caching dans la commande est donc un prérequis, pas la preuve que les tokens sont effectivement réutilisés.

La vérification doit utiliser deux familles de requêtes :

• requête froide : préfixe système, définitions d’outils et contexte partagé jamais envoyés auparavant ;
• requête chaude : même préfixe, avec une variation limitée dans la demande utilisateur.

Il faut conserver le résultat de la requête froide, puis envoyer la requête chaude sans modifier l’ordre, les espaces significatifs, les définitions d’outils ou les messages précédents. Une différence trop importante dans le préfixe peut empêcher une réutilisation légitime et créer un faux diagnostic de cache inactif.

Les métriques vLLM à examiner sont vllm:prefix_cache_queries, vllm:prefix_cache_hits et vllm:prompt_tokens_cached. La documentation précise également que les compteurs de cache doivent être interprétés dans le temps, plutôt qu’avec une valeur isolée. Consultez les métriques officielles du prefix caching.

Le protocole minimal comprend :

1. réinitialiser ou isoler l’instance de test ;
2. envoyer une requête froide ;
3. enregistrer la latence de préremplissage et les tokens traités ;
4. répéter le même préfixe avec une variation contrôlée ;
5. vérifier l’augmentation des requêtes de cache ;
6. vérifier que les hits et les tokens mis en cache augmentent ;
7. comparer la latence froide et chaude ;
8. répéter le test avec plusieurs sessions afin d’écarter un hasard local.

Un compteur de requêtes sans hit, ou une baisse de latence sans hausse cohérente des tokens mis en cache, ne permet pas de conclure. Les métriques doivent être reliées au contenu réellement envoyé.

La publication vLLM consacrée à Kimi K3 décrit aussi des optimisations de cache adaptées à son architecture hybride, notamment autour des états récurrents et de l’attention complète. Il faut donc éviter de transposer directement les conclusions d’un autre modèle Transformer à Kimi K3. Lisez la publication technique vLLM sur Kimi K3.

La décision finale repose sur une fiche signée, pas sur une impression

La fiche d’acceptation doit réunir quatre axes. Chaque ligne doit préciser le test, la configuration, le résultat observé, la preuve conservée et le responsable de la relecture.

• [ ] L’image, le digest et la version vLLM sont archivés.
• [ ] La construction CUDA 13 est identifiée dans l’image ou dans le processus de compilation.
• [ ] Le pilote hôte appartient à la branche R580 ou à une branche officiellement compatible.
• [ ] Les versions visibles par l’hôte et le conteneur ont été comparées.
• [ ] Les journaux de démarrage ne contiennent pas d’erreur de chargement ou de compatibilité non traitée.
• [ ] Le scénario Agent de référence contient les outils et les sorties structurées attendus.
• [ ] Les réponses ont été vérifiées par schéma, et non uniquement affichées.
• [ ] Le test de chargement à froid a été séparé du test de contexte long.
• [ ] La concurrence a été augmentée progressivement avec conservation des courbes GPU.
• [ ] Les OOM éventuels sont associés à une condition précise et à une décision corrective.
• [ ] vllm:kv_cache_usage_perc, les requêtes en attente et les préemptions ont été relevés.
• [ ] Le test froid du prefix caching et le test chaud contrôlé sont conservés.
• [ ] Les compteurs de requêtes, de hits et de tokens mis en cache sont cohérents.
• [ ] Le comportement de reprise après erreur d’outil a été testé.
• [ ] La personne qui exploite le service connaît la limite de contexte, de concurrence et le signal de retour arrière.
• [ ] Une procédure de restauration vers l’image précédente a été répétée.

La règle de décision peut être formulée simplement :

• Tous les axes passent : mise en production possible.
• Un défaut fonctionnel non critique est maîtrisé : observation limitée, avec plafond de trafic et date de réexamen.
• La chaîne CUDA, le pilote ou l’image ne respecte pas le périmètre officiel : reprise de l’environnement.
• La configuration est conforme mais la mémoire sature dans le trafic nominal : réduction contrôlée de la charge, changement de topologie ou extension de capacité.
• Le cache ne montre aucune réutilisation sur un préfixe identique : ne pas compter le gain attendu ; reprendre le paramétrage et le protocole.
• Les appels d’outils sont instables : bloquer la mise en ligne des Agents concernés, même si le texte simple fonctionne.

Après la mise en production, le premier tableau de bord doit suivre au minimum les erreurs, les requêtes réussies, la latence de bout en bout, le temps avant premier token, la file d’attente, le nombre de requêtes actives, l’utilisation du KV cache, les préemptions et les compteurs du prefix caching. Les seuils d’alerte doivent être définis à partir du test accepté, et non copiés d’un autre modèle.

Le retour arrière doit être déclenché lorsque le service reproduit un OOM dans la charge contractuelle, lorsque le temps d’attente dépasse le niveau accepté pendant une période continue, lorsque les appels d’outils produisent des JSON invalides ou lorsque les compteurs de cache s’écartent fortement du comportement validé. Une modification du conteneur, du pilote, de la topologie ou de la limite de contexte doit rouvrir la fiche d’acceptation.

Quand reconstruire, quand étendre et quand utiliser ProxyMac ?

Le choix dépend du défaut observé. Un pilote ancien ou une image incohérente appelle une reconstruction. Une mémoire insuffisante sous charge appelle une extension ou une réduction du périmètre. Un problème de parsing appelle une correction de l’interface Agent, pas l’achat immédiat de GPU supplémentaires.

Pour une équipe qui utilise déjà un environnement distant ou un poste généraliste, les limites sont souvent concrètes : versions difficiles à figer, accès GPU partagé, absence de traces complètes et coût de mobilisation d’un cluster pour chaque test de régression. Un Mac ne remplace toutefois pas un cluster NVIDIA CUDA pour servir directement Kimi K3 avec vLLM. Il est plus pertinent pour les tâches périphériques : préparation de jeux de requêtes, tests d’interface, validation de schémas d’outils, préparation audio/vidéo, contrôle d’un client Agent ou exécution d’une passerelle de test.

Dans ce cadre, la console ProxyMac peut servir à obtenir temporairement un environnement Mac isolé pour les essais côté client, tandis que le backend Kimi K3 reste hébergé sur une infrastructure NVIDIA conforme à CUDA 13 et au pilote R580. Pour les contraintes d’accès et de remise en service, l’aide ProxyMac permet de vérifier le fonctionnement de l’environnement avant de l’intégrer à la chaîne de validation.

L’avantage n’est donc pas de présenter le Mac comme une alternative artificielle au serveur CUDA. Il consiste à séparer proprement les responsabilités : le cluster NVIDIA porte l’inférence Kimi K3 ; l’environnement ProxyMac peut accélérer les tests temporaires, la préparation créative audio/vidéo et les validations d’intégration sans immobiliser la machine de production.

La fiche signée doit finalement répondre à une seule question opérationnelle : l’environnement actuel satisfait-il les exigences prouvées, ou faut-il reconstruire, limiter ou étendre avant d’accepter le trafic réel ?