Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Inférence et orchestration du processeur

Présentation de

Les instances de processeur constituent une option de calcul de premier ordre pour un large éventail de charges de travail d'IA sur Amazon EKS. Qu'il s'agisse de petits modèles linguistiques (SLM), d'inférence ML classique, de pipelines de données ou d'orchestration d'agents, les processeurs offrent un excellent rapport prix/performances, une large disponibilité des capacités et une sémantique de planification Kubernetes familière.

Le processeur et le processeur graphique sont complémentaires et non compétitifs. À mesure que les pipelines d'IA agentic deviennent de plus en plus complexes, la surface de charge du processeur augmente avec eux : chaque appel d'inférence est entouré d'exécution d'outils, d'assemblage de contexte, de recherche vectorielle, de garde-fous et d'une logique d'orchestration qui s'exécutent tous sur le processeur. Nous recommandons de concevoir des architectures qui utilisent délibérément les deux types de calcul, en plaçant chaque charge de travail sur le niveau où elle offre le meilleur rapport coût-performance.

Toutes les charges de travail n'ont pas besoin d'un GPU. Le routage, la classification, la récupération, l'intégration, l'orchestration et une part croissante de l'inférence de modèles de langage fonctionnent tous efficacement sur le processeur. Current-generation Les instances de processeur sur arm64 et x86 offrent un excellent rapport prix/performances pour l'inférence ML. Combiné à la consolidation des nœuds de Karpenter, à la mise à l'échelle axée sur les événements de KEDA et au service de modèles quantifiés, cela fournit une pile prête à la production que les équipes de plateforme peuvent exploiter sans expertise approfondie en matière de GPU.

Ce guide est destiné aux personnes suivantes :

Ce que vous allez apprendre :

Pourquoi choisir des processeurs pour les charges de travail basées sur l'IA ?

Les pipelines d'IA de production répartissent le travail sur de nombreux niveaux de calcul. Les processeurs gèrent le routage, la classification, la récupération, l'orchestration et une part croissante de l'inférence. Current-generation Les instances de processeur offrent un excellent rapport prix/performances et une planification Kubernetes familière, ce qui en fait une option pratique pour de nombreuses charges de travail liées à l'IA.

Trois facteurs font du processeur un atout pour ces charges de travail :

Disponibilité des capacités

Les instances GPU nécessitent souvent des réservations de capacité des semaines à l'avance. Les instances de processeur sont largement disponibles dans toutes les régions AWS, sans plug-in d'appareil spécialisé, sans configuration DRA ni partitionnement MIG. Lorsque vous devez évoluer rapidement, la capacité du processeur est l'option la plus facilement disponible.

Économie

Current-generation Les instances de processeur offrent un excellent rapport prix/performances pour l'inférence ML. Pour les équipes chargées des FinOps révisions ou de la gestion de clusters multi-locataires, la différence de coût entre le processeur et le processeur graphique est significative, en particulier pour les SLM quantifiés où l'accélération du GPU génère des rendements décroissants. Nous vous recommandons d'effectuer des analyses comparatives entre les familles d'instances disponibles (Graviton, AMD, Intel) afin de déterminer le meilleur coût par jeton pour votre charge de travail.

Simplicité opérationnelle

Les pods CPU utilisent la planification Kubernetes standard (requests,, affinité des nœudslimits, propagation de la topologie). Aucun plug-in d'appareil, aucun planificateur personnalisé, aucun type de nvidia.com/gpu ressource. Les équipes qui souhaitent exécuter des charges de travail basées sur l'IA sans expertise approfondie en matière de GPU peuvent atteindre une production plus rapide sur le processeur.

Augmentation de la surface du processeur dans les pipelines agentic

Dans les pipelines d'IA agentic, chaque appel d'inférence du GPU est entouré par le travail du processeur : exécution de l'outil, assemblage du contexte, recherche vectorielle, intégration de recherches, garde-corps, validation des réponses, gestion de la mémoire et logique d'orchestration. À mesure que les agents deviennent de plus en plus complexes (plus d'outils, chaînes plus longues, raisonnement en plusieurs étapes), les charges de travail du processeur augmentent de manière très linéaire. Des protocoles tels que le MCP (Model Context Protocol) amplifient encore cela : chaque appel d'outil MCP déclenche la récupération, la transformation et le formatage des données qui s'exécutent entièrement sur le processeur.

CPU vs GPU/Trainium : quand choisir chacun

Cadre décisionnel concernant la charge de travail

Le choix du calcul adapté à une charge de travail basée sur l'IA se résume à quatre dimensions :

Utilisez le tableau ci-dessous comme matrice de décision.

Flux de travail de référence rapide

Avant de passer à une famille d'instances, nous vous recommandons d'exécuter un test de performance structuré comparant vos familles de processeurs candidates (arm64 et x86) au GPU sur une seule métrique comparable : le coût pour 1 000 requêtes avec votre latence p95 cible. Déployez un nœud par famille avec une configuration de modèle identique (même quantification, même taille de contexte, même nombre de threads), testez la charge de chacun et comparez. Si une instance de processeur répond à votre SLO p95, elle gagnera probablement en termes de coûts. S'il échoue légèrement, essayez la dernière génération de cette famille avant de passer au GPU. Si la latence est encore trop élevée par rapport à votre objectif de simultanéité, c'est le signal pour déplacer la charge de travail vers le GPU.

Schémas de production

Modèle 1 : Agentic AI — SLM Pre-Filter sur le processeur avec escalade LLM

La plupart des flux de travail des agents exécutent les mêmes schémas restreints à plusieurs reprises : classification de la demande, sélection d'un outil, extraction de données structurées, validation d'une réponse. Ces tâches ne nécessitent pas de modèle de paramètres 70B.

Les recherches sur les SLM (ar Xiv:2506.02153) démontrent que les modèles dont les paramètres sont inférieurs à 10 milliards de dollars, lorsqu'ils sont spécialisés pour un domaine, peuvent égaler ou dépasser les grands LLM sur des sous-tâches limitées, tout en s'exécutant efficacement sur le processeur à un coût et une latence nettement inférieurs. Lorsqu'un modèle est affiné pour un domaine spécifique, son encombrement réduit peut le rendre plus précis et moins coûteux que le recours à un LLM à usage général.

Dans ce modèle, un SLM sur CPU gère la majorité des demandes de bout en bout. Une couche de routage (également exécutée sur le processeur) ne transmet que les cas véritablement complexes à un GPU-hosted LLM.

Composants exécutés sur le processeur :

Composants sur GPU/Trainium :

Pourquoi ce modèle fonctionne : Dans de nombreux flux de travail agentiques, 60 à 80 % des demandes sont classifiables ou extractibles par un SLM. Pour chaque appel LLM que vous évitez, vous évitez également le travail du processeur associé à l'assemblage d'une grande fenêtre contextuelle, à l'exécution de garde-fous en cas de réponse longue et à la gestion d'états complexes. Le niveau CPU évolue indépendamment du niveau GPU.

Les catégories de charge de travail du processeur dans un pipeline agentic typique incluent : l'exécution des outils (appels au serveur MCP, appels d'API, requêtes de base de données), l'assemblage du contexte, la recherche vectorielle et l'intégration de recherches, la logique d'orchestration et de planification, les garde-fous et le filtrage de sécurité, la validation et le formatage des réponses, la mémoire des agents et la gestion des états, et. logging/observability

Ce modèle s'adapte également à un cycle de vie précis : collectez les données de domaine sur les nœuds du processeur, affinez sur le processeur graphique, puis déployez le modèle quantifié sur le processeur à des fins d'inférence à un coût nettement inférieur à celui d'un point de terminaison LLM. Une étude menée par LoRa Land (ar Xiv:2405.00732) montre que les modèles 7B affinés sont plus performants GPT-4 que la majorité des tâches spécifiques au domaine testées, ce qui rend la solution « peaufiner un petit modèle et l'exécuter sur le processeur » viable pour de nombreux cas d'utilisation en production.

Schéma 2 : High-Density CPU Model Farm

Les pipelines de production ML déploient régulièrement des centaines ou des milliers de modèles plus petits : des intégrations, des recommandations, des classificateurs, des évaluateurs et des modèles de vision par BERT-based ordinateur. Légers individuellement, ces modèles deviennent chers lorsque chacun dispose de ses propres ressources GPU.

Nous recommandons un service de processeur haute densité (regroupement de plusieurs modèles par nœud en utilisant TorchServe ou Triton sur le processeur), Karpenter gérant le cycle de vie des nœuds et adaptant KEDA en fonction de la charge observée.

Ce modèle s'applique naturellement aux architectures RAG : l'intégration de la génération, du découpage des documents et de la récupération s'exécutent de manière rentable sur OpenSearch les nœuds du processeur, fournissant les résultats à un GPU-hosted LLM uniquement pour l'étape de génération finale. Le parc de processeurs gère le volume ; le GPU gère la complexité.

Pour les secteurs réglementés (services financiers, santé, administration), ce schéma est particulièrement convaincant : des centaines de modèles spécialisés s'exécutent en VPC sur processeur, avec des pistes d'audit complètes et des données qui ne quittent jamais le compte. L'exigence de conformité pour l'inférence autogérée s'aligne naturellement sur l'avantage en termes de coûts du processeur pour les modèles inférieurs à 8B.

Bonnes pratiques d'optimisation

Quantification

Il n'est pas pratique d'exécuter un modèle 7B avec un BF16 complet sur le processeur ; l'exécuter au quatrième trimestre de quantification est viable et rentable. Comprendre pourquoi la quantification est utile pour le processeur est essentiel pour prendre de bonnes décisions en matière d'infrastructure.

Pourquoi la quantification est importante pour l'inférence du processeur. L'inférence du processeur est liée à la bande passante mémoire et non au calcul. Pendant la phase de décodage (génération de jetons un par un), les poids complets du modèle sont lus dans la RAM pour chaque jeton produit. Le processeur passe le plus clair de son temps à attendre que les données arrivent de la mémoire, sans faire de calculs. Un modèle 7B au BF16 coûte environ 14 Go ; au Q4_K_M, il se réduit à environ 4 Go. Comme le principal obstacle consiste à déplacer des octets de la RAM vers les cœurs du processeur, un modèle 3,5 fois plus petit lit 3,5 fois plus vite, ce qui se traduit presque directement par une génération de jetons 3,5 fois plus rapide. C'est pourquoi la quantification est l'optimisation la plus efficace pour l'inférence du processeur, et pourquoi les nouvelles générations de processeurs dotées d'un plus grand nombre de canaux de mémoire produisent une inférence plus rapide, même à la même vitesse d'horloge.

Nous vous recommandons de créer votre moteur d'inférence avec des backends optimisés pour l'architecture (ARM NEON/SVE2 pour arm64, AVX-512/AMX pour x86), de définir un nombre de threads égal au nombre de vCPU et de sélectionner les formats de quantification Q4_K_M ou Q8_0.

Pour les modèles inférieurs à 2 Go, le processeur gagne en termes de rapport prix/performances par rapport au GPU. Ces modèles sont suffisamment petits pour que l'accélération du processeur graphique présente un avantage minimal alors que le coût horaire est nettement plus élevé. Si votre charge de travail peut utiliser un modèle inférieur à 2 B, le processeur est la valeur par défaut recommandée.

Architecture-specific optimisations : sur arm64, les instances Graviton de la génération actuelle prennent en charge SVE2. Construisez votre moteur d'inférence avec le -march drapeau approprié pour votre cible. Sur x86, les instances AMD EPYC sont compatibles AVX-512, et les instances Intel Xeon ajoutent AMX pour l'accélération matricielle. L'inférence étant limitée à la bande passante mémoire, les nouvelles générations de processeurs dotées d'un plus grand nombre de canaux de mémoire DDR5 produisent une inférence plus rapide, même à la même vitesse d'horloge. Lorsque vous choisissez un type d'instance, privilégiez la bande passante mémoire par rapport au nombre de cœurs.

Dimensionnement de la fenêtre contextuelle : pour les charges de travail de classification et de routage, les entrées sont généralement inférieures à 200 jetons et les sorties sont de 2 à 3 jetons. La définition d'une petite fenêtre contextuelle (par exemple, 512 jetons) au lieu de la valeur par défaut 2048 réduit l'utilisation de la mémoire cache en kilo-volts et améliore la latence par requête. N'augmentez la fenêtre contextuelle que si vos entrées sont vraiment longues.

Flash Attention : activez Flash Attention si votre moteur d'inférence le prend en charge. Flash Attention réduit l'utilisation de la mémoire pour le calcul de l'attention en évitant de matérialiser la matrice d'attention complète. Sur le processeur, l'avantage est moindre que sur le GPU, mais cela permet tout de même d'obtenir des entrées plus longues.

Bin-packing pour une portion dense

Pour les modèles classiques de machine learning et d'intégration (généralement < 500 Mo chacun), l'objectif est de maximiser la densité de pods par nœud avec une latence de queue stable. Deux facteurs déterminent si vous y parvenez : des demandes de ressources précises et un threading contrôlé.

Basez-vous requests sur l'utilisation observée du p50-p90 sous une charge réaliste. Utilisez Goldilocks, les recommandations VPA ou les histogrammes Prometheus issus d'un test de charge. Les valeurs par défaut sont presque toujours erronées dans les deux sens.

Les bibliothèques ML (PyTorchONNX Runtime, MKL, OpenBLAS) génèrent autant de threads qu'elles peuvent voir de vCPU sur le nœud, et non les processeurs alloués au pod. Sur un nœud dense de 20 pods, chaque pod essaie de générer 32 threads. Le nœud se bloque lors du changement de contexte et des pics de latence p99. Corrigez ce problème de manière explicite :

env:
  - name: OMP_NUM_THREADS
    value: "2"          # match your cpu request (2000m = 2 threads)
  - name: MKL_NUM_THREADS
    value: "2"
  - name: OPENBLAS_NUM_THREADS
    value: "2"
  - name: INTRA_OP_NUM_THREADS    # PyTorch / ONNX Runtime
    value: "2"
  - name: NUM_INTER_THREADS
    value: "1"          # keep inter-op parallelism minimal

Définissez chaque valeur égale ou inférieure à votre demande de processeur. Pour les pods à 4 cœurs ou plus, utilisez une valeur de référence à partir de 2 à 4 threads. De nombreux petits modèles fonctionnent mieux avec moins de threads grâce à l'efficacité du cache. Si vous utilisez le HPA avec de nombreuses capsules fines, 1 à 2 fils par capsule l'emportent presque toujours.

Planification et optimisation des coûts

Deux pratiques combinées permettent de réduire de manière significative les coûts d'inférence du processeur : les instances Spot avec consolidation Karpenter et les images de conteneurs à arches multiples.

La consolidation de Karpenter fonctionne bien pour l'inférence du processeur, car les modules d'inférence sans état situés derrière une file d'attente ou un équilibreur de charge tolèrent les interruptions de manière harmonieuse. Configurez la consolidation pour agir sur les nœuds sous-utilisés avec un budget qui limite les interruptions simultanées (par exemple, 20 % des nœuds à la fois) afin d'éviter les baisses de capacité lors de la réduction d'échelle. Les nodePool spécifications de Karpenter vous permettent de combiner Spot et On-Demand capacité dans un seul pool, avec Spot comme option préférée et On-Demand comme solution de secours.

La création d'images multi-arches (arm64etamd64) permet de débloquer davantage cela. Les deux architectures étant disponibles, Karpenter peut choisir parmi une gamme complète de familles d'instances (Graviton, AMD, Intel) en fonction du prix et de la disponibilité en temps réel. Cela est particulièrement utile pour les charges de travail ponctuelles où la diversification entre les types d'instances et les architectures réduit la fréquence des interruptions. Utilisez docker buildx un pipeline CI avec des versions multiplateformes pour produire un manifeste unique couvrant les deux architectures.

Optimisation du démarrage des conteneurs

Lorsque Karpenter provisionne un nouveau nœud (mise à l'échelle, remplacement de Spot), le moteur d'exécution du conteneur doit extraire l'image d'inférence avant que le pod ne puisse démarrer. Pour les images d'inférence de plusieurs Go, cela peut ajouter 30 à 60 secondes au démarrage du pod.

Nous recommandons d'utiliser Bottlerocket comme système d'exploitation du nœud pour les charges de travail d'inférence, en combinaison avec le snapshotter SOCI en mode parallèle. pull/unpack SOCI remplace l'extraction de couches séquentielle par défaut par des téléchargements parallèles basés sur des segments, ce qui réduit considérablement le temps d'extraction des images pour les images de grande taille. Il n'est pas nécessaire de modifier les images de vos conteneurs.

Pour obtenir des conseils de configuration détaillés, consultez la section Performances de ce guide, qui couvre la configuration SOCI, le pré-extraction des snapshots EBS et les stratégies de cache d'exécution des conteneurs.

Observabilité

Sans observabilité au niveau de la couche du modèle, vous effectuez une mise à l'échelle à l'aveuglette. Nous recommandons d'exposer les métriques Prometheus pour chaque service d'inférence et de les utiliser pour piloter à la fois le dimensionnement et les tableaux de bord opérationnels de KEDA.

La plupart des serveurs d'inférence (llama.cpp, vLLM, Triton TorchServe) exposent les Prometheus-compatible métriques sur un point de terminaison. /metrics Les noms des métriques varient selon le serveur, mais les concepts sont les mêmes.

Indicateurs clés à utiliser :

Autoscaling : mise à l'échelle en fonction de la profondeur de la file d'attente, et non de l'utilisation

L'utilisation du processeur est une mesure de saturation. Il atteint un pic une fois que la latence s'est déjà dégradée. Au moment où le dimensionnement automatique basé sur l'utilisation réagit, les utilisateurs attendent déjà.

La profondeur de la file d'attente (demandes deferred/waiting) est un indicateur avancé. Elle augmente avant que la latence ne se dégrade, car les demandes commencent à être mises en file d'attente lorsque tous les créneaux de traitement sont occupés. L'augmentation de la profondeur des files d'attente signifie que de nouvelles répliques sont mises en service alors que les répliques existantes répondent toujours normalement.

KEDA permet de combiner plusieurs métriques en une seule formule de mise à l'échelle en utilisant scalingModifiers (nécessite KEDA 2.12+). Le modèle recommandé pour les charges de travail d'inférence consiste à combiner les demandes en cours d'attente avec les demandes en file d'attente, en pondérant fortement la métrique de la file d'attente :

advanced:
  scalingModifiers:
    formula: "running + (waiting * 10)"
    target: "25"
    activationTarget: "5"

La formule running + (waiting * 10) signifie que même 3 demandes en file d'attente portent la métrique combinée à 55, bien au-dessus de l'objectif de 25. La mise à l'échelle commence avant que la latence ne se dégrade. Le 5 empêche le bruit activationTarget de déclencher des événements inutiles de mise à l'échelle à partir de zéro.

Évaluation de la qualité des modèles pour les charges CPU-First de travail

Le déploiement d'un SLM quantifié sur le processeur est une décision de coût et de latence. Cela n'a de sens que si le modèle produit toujours des résultats corrects et utiles pour votre charge de travail.

Les modèles plus petits ou la quantification réduisent les coûts de calcul, mais peuvent réduire la qualité. L'impact varie. Les charges de travail qui fonctionnent bien sur le processeur (classification, extraction, routage, synthèse, intégration) conservent souvent une bonne qualité dans la B-7B gamme 3 avec une quantification et des instructions appropriées.

Ce qu'il faut évaluer

Les différentes charges de travail se dégradent de différentes manières :

Un flux de travail d'évaluation pratique

Nous vous recommandons de créer un contrôle qualité avant la production, de la même manière que vous exécuteriez un test de charge avant de choisir un type d'instance. Le flux de travail comporte quatre étapes :

Comment retrouver la qualité

Si le modèle fonctionne mal, essayez les solutions suivantes par ordre d'effort :

Références