Quelles fonctionnalités permettent le basculement du GPU vers le CPU dans un service d’IA local ?

Le basculement du GPU vers le CPU ne fonctionne que lorsque le service prévoit un chemin d’exécution secondaire compatible avant que l’épuisement de la mémoire n’interrompe une requête active.

Un serveur d’IA domestique peut exécuter la transcription, la recherche d’images et un LLM sur un même accélérateur jusqu’à ce qu’un long prompt fasse dépasser à la mémoire sa limite de sécurité. Se contenter d’intercepter une erreur de mémoire insuffisante arrive trop tard si l’état du modèle est incohérent. Un basculement fiable combine le contrôle d’admission, des poids compatibles pour le CPU, un état de requête transférable, des files d’attente limitées, des signaux d’état et une politique claire de service dégradé.

Le contrôle d’admission détecte la pression avant l’échec de l’allocation

La passerelle estime les poids du modèle, la croissance du cache KV, les tenseurs temporaires, la taille des lots et la fragmentation de la mémoire avant d’accepter une requête GPU. Une marge de sécurité réservée protège les noyaux et les charges concurrentes, tandis qu’un seuil de pression détermine s’il faut retarder, réduire, déporter ou router la requête.

La mémoire KV paginée traite la mémoire du GPU comme des blocs paginés afin de réduire la fragmentation et de partager plus efficacement la capacité du cache KV. Cela augmente le plafond d’exploitation sûr, mais ne crée pas une mémoire illimitée et ne remplace pas une route de dépassement explicite.

Une véritable décision de basculement utilise à la fois la consommation prévue et la consommation observée. Les seules mesures de mémoire disponible peuvent être trompeuses, car les allocateurs mis en cache, les noyaux en attente et la réservation d’un autre service peuvent occuper de l’espace après la vérification, mais avant l’allocation suivante.

Le chemin CPU doit reconstruire un état du modèle compatible

L’exécution sur CPU nécessite le même tokenizer, la même révision du modèle, la même sémantique de quantification, le même modèle de prompt, les mêmes paramètres d’échantillonnage et les mêmes règles d’arrêt que le chemin GPU. Le service peut conserver une réplique CPU prête à l’emploi, projeter les poids en mémoire ou les charger à la demande en fonction de son budget de temps de récupération.

L’inférence hybride CPU-GPU démontre une inférence hybride qui exploite la parcimonie prévisible des activations entre le CPU et le GPU sur du matériel grand public. Sa conception montre que la participation du CPU peut être planifiée comme un mode d’exécution, plutôt que considérée uniquement comme une copie d’urgence.

Les requêtes ayant déjà généré des tokens sont plus difficiles à déplacer, car leur cache KV et leur état aléatoire doivent être transférés ou recalculés. De nombreux services domestiques devraient donc basculer aux limites des requêtes et effectuer une nouvelle tentative idempotente, au lieu de promettre une migration transparente en cours de génération.

L’état de santé, les files d’attente et le mode dégradé limitent les conséquences

Un disjoncteur marque le GPU comme indisponible après des erreurs d’allocation répétées, des redémarrages du pilote ou des échecs des contrôles d’état. Les nouvelles tâches sont placées dans une file CPU distincte, avec une concurrence réduite, des limites de contexte plus courtes ou un modèle de secours plus petit afin que les requêtes lentes ne saturent pas l’hôte.

Le placement d’inférence par niveaux coordonne le placement sur le CPU, le GPU et le stockage afin d’exécuter des modèles dépassant la mémoire de l’accélérateur. Les résultats illustrent l’écart important de latence entre le fait de tenir dans une mémoire rapide et le recours à des niveaux plus lents. Cette distinction reste visible lors des tests domestiques ultérieurs.

La limite de défaillance consiste à prétendre que le basculement vers le CPU préserve le même niveau de service. Un modèle qui prend 20 secondes sur GPU peut prendre plusieurs minutes sur CPU, et les noyaux non pris en charge peuvent ne pas fonctionner du tout. L’interface doit exposer le modèle de secours, les limites, le délai estimé et l’annulation, plutôt que de rester silencieuse.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Valider le basculement sous une pression mémoire contrôlée

Rejouez des prompts courts, des prompts longs, des requêtes concurrentes et une autre charge GPU tout en réduisant progressivement la mémoire disponible. Déclenchez un routage avant admission, un échec d’allocation avant la génération, un redémarrage du pilote et une annulation pendant la file CPU. Le résultat intermédiaire doit rester inspectable avant que l’automatisation ne poursuive.

Comparez les résultats avec la limite de basculement décrite dans le basculement en cas de mémoire GPU pleine. Consignez le taux de réussite, les effets secondaires dupliqués, l’équivalence des tokens lorsque cela est attendu, la latence p95, l’ancienneté de la file, la mémoire vive de l’hôte, le temps de récupération et l’indication ou non du mode dégradé à l’utilisateur.

Ne validez que lorsqu’aucune requête acceptée ne disparaît et que le routage vers le CPU ne peut pas épuiser la mémoire système. Si une migration en cours de requête modifie la sortie ou répète une action d’outil, limitez le basculement aux points de contrôle sûrs et renvoyez une erreur reprenable pour tout le reste.