NVIDIA Snapshot réduit le démarrage des charges de travail GPU de plusieurs minutes à quelques secondes

NVIDIA a publié Snapshot, un système open source de point de contrôle et de restauration conçu pour accélérer les charges de travail GPU sur Kubernetes. Publiée le 10 novembre 2026, cette solution capture l'état entièrement initialisé de la mémoire CPU et GPU, permettant aux répliques d'inférence de démarrer en quelques secondes plutôt qu'en plusieurs minutes. Elle s'attaque au goulot d'étranglement des démarrages à froid dans le service de grands modèles de langage, où l'initialisation des poids et la compilation des noyaux retardent souvent la montée en charge.

Ce qui s'est passé

Le problème central résolu par Snapshot est la latence liée à la mise en ligne de nouvelles répliques d'inférence. Lorsque la demande augmente ou qu'un nœud tombe en panne, les équipes d'infrastructure doivent approvisionner de nouveaux pods. Ce processus, connu sous le nom de démarrage à froid, implique le chargement des images de conteneurs, le démarrage du moteur d'inférence, la lecture des poids du modèle dans la mémoire GPU, la compilation du code avec des outils comme torch.compile, et la capture des graphes CUDA. Pour les grands modèles, cette séquence peut prendre plusieurs minutes, pendant lesquelles les GPU disponibles restent inactifs au lieu de traiter les requêtes.

Snapshot modifie ce flux de travail en traitant la charge de travail initialisée comme un artefact réutilisable. Une fois qu'un pod est entièrement prêt, Snapshot capture son état mémoire complet. Lorsqu'une nouvelle réplique est nécessaire, le système restaure cet état directement sur du matériel compatible. Cela évite le travail lourd lié au chargement des poids et à la compilation. Le système prend en charge des stratégies de parallélisme complexes, notamment le parallélisme tensoriel, le parallélisme de données et d'experts, ainsi que le parallélisme de contexte de décodage. Il gère des points de contrôle jusqu'à 1 To sur huit GPU, ce qui le rend adapté aux grands modèles à mélange d'experts (mixture-of-experts).

Les premiers adoptants ont signalé des améliorations significatives. Crusoe, contributeur au projet, a réduit le temps de préparation des pods GLM-5.3 d'environ huit minutes à 31 secondes sur du matériel NVIDIA HGX B300. De même, Saturn Cloud a réduit les temps de démarrage de vLLM d'une plage de deux à 8,5 minutes à six à 34 secondes. Ces résultats démontrent que la technologie est viable pour les environnements de production nécessitant des capacités rapides de montée en charge à partir de zéro.

Comment cela fonctionne

Snapshot opère via deux actions principales : le point de contrôle (checkpoint) et la restauration (restore). Les deux sont gérés via des ressources personnalisées Kubernetes. Pour créer un point de contrôle, les utilisateurs définissent une ressource PodSnapshot pour un pod en cours d'exécution, ou un SnapshotJob pour effectuer un point de contrôle dès qu'un pod devient prêt. Le système met brièvement la charge de travail en pause pour capturer l'état de la mémoire CPU et GPU dans un artefact portable. Cet artefact inclut les poids du modèle initialisés, les noyaux compilés et les tampons d'exécution, mais exclut le cache clé-valeur, qui est vidé avant la capture.

La restauration est déclenchée en ajoutant une annotation spécifique, nvidia.com/restore-from, à la spécification d'un nouveau pod. L'agent Snapshot sur le nœud cible localise l'artefact et commence le processus de restauration. Cela implique l'utilisation de Checkpoint/Restore in Userspace (CRIU) pour recharger l'état du processus CPU et d'un mécanisme de restauration CUDA spécialisé pour copier l'état GPU dans la mémoire vidéo. La charge de travail effectue ensuite une poignée de main rapide pour s'adapter au nouveau nœud et reprendre le service. Ce processus saute entièrement les phases initiales de démarrage du moteur, de chargement des poids et de capture du graphe.

Détails clés

• Les temps de restauration varient de 3,6 à 42,7 secondes selon les configurations testées, représentant une accélération de 8x à 36x par rapport aux démarrages à froid.
• La création d'un point de contrôle prend entre 15 secondes et 5,5 minutes, selon la taille du modèle, mais ce coût est amorti sur plusieurs restaurations.
• Le temps combiné pour le point de contrôle et la restauration est inférieur à celui d'un seul démarrage à froid dans toutes les configurations testées.
• Pour les grands modèles à mélange d'experts sur huit GPU, la restauration de l'état GPU représente 18 à 29 secondes du temps total de restauration.
• La restauration du processus CPU via CRIU prend 4,2 à 10,8 secondes, indiquant que le transfert de l'état GPU est le facteur dominant lors des grandes restaurations.
• Le système prend en charge vLLM 0.31.0, SGLang 0.5.21 et NVIDIA TensorRT LLM 1.3.0 sur les GPU NVIDIA B200 avec stockage VAST NFS.

Pourquoi c'est important

Pour les équipes d'ingénierie construisant des infrastructures IA, l'écart entre l'approvisionnement d'un GPU et le traitement du trafic est une fuite majeure d'efficacité. Les démarrages à froid obligent les équipes à surprovisionner la capacité pour gérer les pics soudains, car elles ne peuvent pas compter sur une montée en charge rapide. En réduisant le temps de démarrage à moins de 45 secondes, Snapshot permet des politiques d'autoscaling plus agressives. Cela signifie que les clusters peuvent rester plus légers pendant les périodes de faible demande et s'étendre rapidement lorsque le trafic augmente, améliorant ainsi l'utilisation globale des ressources et réduisant les coûts cloud.

De plus, cette technologie simplifie la récupération après pannes. Si un nœud tombe en panne, le remplacement de la capacité perdue ne nécessite plus d'attendre plusieurs minutes pour que les nouveaux pods s'initialisent. Les pods restaurés sont immédiatement prêts à accepter les requêtes, maintenant plus efficacement les accords de niveau de service (SLA). Ceci est particulièrement critique pour les grands modèles à mélange d'experts, où la complexité d'initialisation croît avec la taille du modèle. La capacité d'effectuer des points de contrôle et de restaurer des états de plusieurs téraoctets rend la gestion de ces modèles massifs opérationnellement plus faisable.

Ce que vous pouvez faire

• Visitez le dépôt NVIDIA Snapshot pour accéder aux instructions d'installation et aux guides d'utilisation pour votre cluster Kubernetes.
• Consultez le guide utilisateur NVIDIA Dynamo pour apprendre comment intégrer Snapshot avec les workers d'inférence pour une restauration automatisée.
• Testez les exemples fournis pour vLLM, SGLang et TensorRT LLM afin d'évaluer la compatibilité avec votre stack actuel.
• Assurez-vous que votre matériel répond aux exigences, notamment en faisant correspondre les modèles de GPU et les pilotes entre les nœuds de point de contrôle et de restauration.
• Rejoignez l'espace de travail Slack NVIDIA Dynamo et participez au canal #snapshot-dev pour discuter des défis d'intégration.
• Effectuez des benchmarks sur vos charges de travail spécifiques pour déterminer la fréquence optimale de point de contrôle basée sur la fenêtre de création de 15 secondes à 5,5 minutes.