TensorRT-LLM 1.4 RC modifie les valeurs par défaut du cache KV
La version candidate TensorRT-LLM v1.4.0rc1 de NVIDIA du 22 octobre active par défaut le gestionnaire de cache KV V2 et le transcepteur Python, et étend la prise en charge des modèles et du service. Deux problèmes connus sont distincts : l'annulation d'un flux sur A100 peut affecter les requêtes suivantes ; l'exemple de service avec schéma JSON et Qwen3 peut produire une sortie sans limite. Avant la production, il faut tester séparément le transfert du cache, l'annulation et la limite de sortie structurée.
La version candidate de TensorRT-LLM 1.4.0 nécessite une mise à niveau progressive
NVIDIA a publié la version candidate open source TensorRT-LLM `v1.4.0rc1` le 22 octobre UTC. Les notes de version couvrent la prise en charge des modèles, les API de service, la gestion du cache KV, les chemins de décodage et les optimisations spécifiques au matériel. Une version candidate est une cible d’intégration utile pour les équipes qui ont besoin d’un de ces changements, mais ce n’est pas la même chose qu’une version de production largement éprouvée. Les notes elles-mêmes signalent les problèmes connus. L’une concerne les requêtes de streaming annulées avec un service désagrégé et l’émetteur-récepteur de cache Python KV par défaut sur A100 ; un autre dit qu'un exemple de service de schéma JSON peut renvoyer une sortie illimitée avec les modèles Qwen3. Ces mises en garde devraient faire partie de tout plan d’évaluation et non être enfouies derrière la liste des fonctionnalités.
Les valeurs par défaut du cache sont un changement de compatibilité
Les notes marquent deux modifications de l'API comme étant en rupture : le gestionnaire de cache KV V2 et l'émetteur-récepteur de cache Python KV deviennent les valeurs par défaut et les champs "LlmRequest" inutilisés sont supprimés. Un service mis à niveau depuis une version antérieure peut donc changer de comportement même si son propre fichier de configuration ne le fait pas. Les équipes utilisant la séparation de pré-remplissage et de décodage, l’annulation ou un connecteur de cache externe doivent tester ces chemins explicitement. NVIDIA ajoute un connecteur Mooncake pour le gestionnaire de cache KV V2, une API de prêt pour les backends de transfert, le streaming d'événements KV natif et l'exposition de la charge de routage. Ce sont des primitives utiles pour les opérateurs qui ont besoin de placer du travail et de déplacer l'état entre les travailleurs, mais la page de version ne prouve pas un gain de débit pour chaque topologie.
La question spécifique de l’annulation illustre le risque d’une transition d’état cachée. Un client peut fermer un flux après avoir reçu suffisamment de sortie ; le serveur a toujours un état de cache et un travail de transfert à réconcilier. Si un émetteur-récepteur tombe en panne après cette annulation, les requêtes de génération ultérieure peuvent être affectées. Un test de charge contrôlé doit mélanger les achèvements normaux avec des déconnexions délibérées des clients, inspecter les taux d'erreur et le nettoyage du cache, et répéter sur le même matériel et le même mode de service prévus pour le déploiement. Un simple test de latence à une requête manquerait ce mode de défaillance. Le problème est signalé comme observé sur l’A100, il ne doit donc pas être déclaré comme universel sur tous les GPU.
La prise en charge des modèles et de la précision s'étend
La version ajoute la prise en charge des points de contrôle DeepSeek-V4.1-Flash et NVFP4 GLM-5.3-Flash, ainsi qu'une cible expérimentale Modeling V2 pour Qwen3.8-Flash-Next NVFP4. Il mentionne également les points de contrôle de brouillon DFlash pour LiLiCorr et modifie le comportement de repli pour Nemotron-H NVFP4 sur Hopper. Chaque entrée est une revendication de compatibilité pour un format de modèle et un chemin d'exécution particuliers. Cela ne signifie pas que les résultats ou les performances du modèle sont identiques quelle que soit la précision. Les équipes doivent vérifier la licence d'un point de contrôle, le tokenizer, le modèle de discussion, la tolérance numérique et la qualité de sortie représentative avant de remplacer un déploiement connu en bon état. La quantification peut réduire la mémoire ou améliorer le débit tout en modifiant le comportement des cas extrêmes, en particulier dans les sorties longues ou structurées.
NVIDIA répertorie également les options de précision RoPE dans la compression de page froide NVFP4, un niveau de cache hôte progressivement rempli et les paramètres de rééquilibrage pour les pools de cache V2. Ces boutons exposent les compromis en matière de ressources auxquels un cluster de service occupé est confronté : mémoire GPU, mémoire hôte, temps de transfert et latence de réponse. Une mesure utile rapporte les quatre, avec p50 et la latence de queue sous la même distribution de longueur d'invite. Les notes de version mentionnent de nombreux chemins matériels, notamment la prise en charge de Rubin, le travail Blackwell CuTe DSL et les variantes d'attention. Ils doivent être traités comme des développements spécifiques à l'architecture jusqu'à ce qu'ils soient testés sur les machines prévues. Un titre concernant une famille de GPU ne doit pas être copié dans le budget d’une autre.
La sortie structurée et le déterminisme nécessitent leurs propres tests
La mise en garde de l'exemple de schéma JSON pour Qwen3 est importante pour les systèmes d'agent qui attendent des réponses limitées lisibles par machine. Une fonctionnalité de schéma n'est pas utile sur le plan opérationnel si un client peut attendre indéfiniment ou accepter un objet tronqué sans s'en apercevoir. La version ajoute également le décodage déterministe FP32 GVR V2 top-K et honore les graines par requête dans certains chemins d'échantillonnage par lots. Le comportement déterministe s'étend à ces chemins indiqués, et non à une promesse générale selon laquelle chaque exécution distribuée reproduira octet par octet. Les équipes doivent définir des plafonds de réponse, valider les résultats analysés, enregistrer les paramètres de modèle et de décodage et comparer les exécutions répétées selon le plan de traitement par lots exact utilisé en production.
Une décision pour les lecteurs du 25 octobre
Si la pile actuelle est stable et qu’aucune des nouvelles fonctionnalités de modèle ou de cache n’est nécessaire, la version candidate peut rester une cible d’évaluation. Si un point de contrôle ou un connecteur nécessaire l'exige, effectuez la mise à niveau sur un service isolé et collectez un profil avant et après couvrant l'annulation, le transfert de pré-remplissage/décodage, la sortie structurée, la qualité et l'utilisation des ressources. Conservez un chemin de rétrogradation testé pour le comportement de la configuration et du cache. Il s’agit d’une recommandation éditoriale issue de la liste de modifications et de problèmes publiée, et non d’une affirmation selon laquelle le candidat n’est pas en sécurité partout. Le résumé du 25 octobre présente la version originale du 22 octobre avec ses limitations intactes ; aucune disponibilité finale de la version 1.4.0 n'est implicite.
Sources
FAQ
Qu'est-ce qui se passe dans TensorRT-LLM v1.4.0rc1 ?
NVIDIA marque le nouveau gestionnaire de cache KV V2 par défaut et l'émetteur-récepteur de cache KV Python comme modifications importantes, ainsi que la suppression des champs de requête inutilisés. Un déploiement peut donc changer de comportement sans modifier sa propre configuration. Les équipes doivent organiser des tests de transfert de cache, d'annulation et de restauration par rapport à leur topologie de service exacte avant de promouvoir une version candidate.
Quels problèmes connus la version candidate révèle-t-elle ?
Les notes indiquent que les demandes de streaming annulées peuvent entraîner des erreurs de transfert de cache KV dans le service désagrégé avec l'émetteur-récepteur Python par défaut, observées sur A100. Ils signalent également un exemple de schéma OpenAI JSON qui peut renvoyer une sortie illimitée avec les modèles Qwen3. Il s’agit d’avertissements limités et non d’une preuve que chaque appel de GPU ou de schéma échoue.
La prise en charge d’un nouveau modèle garantit-elle de meilleures performances d’inférence ?
La version ajoute des points de contrôle nommés et des chemins de précision, y compris les variantes DeepSeek-V4.1-Flash et NVFP4, mais la prise en charge ne constitue pas une référence universelle. Une équipe doit vérifier la compatibilité du tokenizer, la qualité de sortie, l’utilisation de la mémoire et la latence finale sur sa propre charge de travail. La quantification ou un nouveau chemin de cache peuvent modifier à la fois la vitesse et le comportement dans les cas extrêmes.