Le CPU est de retour : quand exécuter des LLM sur des serveurs classiques en 2026

Vous n’avez pas besoin d’un GPU pour chaque fonctionnalité d’IA. C’était vrai en 2023, c’est cruellement vrai en 2026. La semaine dernière, un développeur a fait tourner un modèle 26B sur un Xeon vieux de dix ans et a obtenu ~5 jetons/s — pas un niveau production, mais la démonstration est là : le plancher de l’inférence sur CPU ne cesse de monter. En parallèle, une nouvelle vague d’articles et de billets éditeurs plaide pour du flash à large bande passante comme magasin de poids. Traduction : le calcul n’est plus votre seul levier ; la bande passante mémoire et la localité comptent tout autant.

Si vous êtes CTO et que vous devez livrer, ce trimestre, de l’IA fiable et maîtrisée en coûts dans votre produit, gardez une règle simple : des GPU pour ce qui en a réellement besoin. Tout le reste tourne sur les CPU que vous savez déjà dimensionner, sécuriser et acheter à des prix raisonnables.

La version courte : où le CPU gagne, où il ne gagne pas

• Le CPU gagne quand vos modèles sont petits (1B–8B), vos sorties sont courtes (≤150 jetons), votre concurrence de pointe est irrégulière ou faible, et votre SLO tolère 500–1500 ms jusqu’au premier jeton significatif.
• Le GPU gagne quand vous poussez des contextes longs (≥16k), des générations longues (≥300 jetons), un RPS élevé et soutenu, de la vision/multimodal, ou du fine-tuning/de l’entraînement.

Tout le reste est gris. Voici un cadre de décision pour supprimer le hasard.

Un cadre décisionnel sans concessions (cinq chiffres suffisent)

Avant de choisir un matériel ou un modèle, répondez à ceci avec de vrais journaux, pas à l’intuition :

1. Longueur de contexte : quel est votre 95e percentile (invite + contexte récupéré) en jetons ?
2. Longueur de sortie : quel est votre 95e percentile de jetons générés ?
3. Concurrence de pointe : combien de générations concurrentes au pic métier ?
4. SLO de latence : temps au premier jeton et temps au dernier jeton que vous devez garantir.
5. Seuil de qualité : quel taux de réussite minimal par rapport à la vérité terrain accepterez-vous (par tâche) — et un modèle 8B ou 4B l’atteint-il ?

Appliquez ensuite des seuils :

• Si contexte ≤8k, sortie ≤150 jetons et concurrence de pointe ≤10 par instance de modèle : le CPU est viable, souvent moins cher et plus simple. Commencez avec un modèle 8B ou 3B distillé en quantification 4 bits.
• Si l’un des éléments ci-dessus est dépassé par 2× : partez du principe GPU, sauf si la qualité reste acceptable avec un modèle plus petit et des invites plus serrées.
• Si les sorties sont « explosives mais brèves » (routage, classification, planification d’appels d’outils, modération, invites système, réécriture/normalisation) : le CPU gagne presque toujours, car des GPU à l’arrêt brûlent de l’argent.

Vous remarquerez que ce n’est pas une histoire de benchmarks éditeurs. C’est une histoire de vos jetons, de vos SLO et de votre courbe de concurrence.

Qu’est-ce qui a changé depuis 2024 pour rendre l’inférence sur CPU crédible ?

• Meilleure quantification : des schémas en 4 bits et en précision mixte avec échelles par groupe conservent la qualité tout en réduisant fortement la bande passante mémoire. La fiabilité des appels d’outils n’est plus automatiquement sacrifiée si vous choisissez le bon schéma et le validez.
• Décodage spéculatif : des modèles « draft » minuscules (1B–3B) prédisent plusieurs jetons, et le modèle cible vérifie. Sur CPU, c’est un gain effectif de 1,2× à 2× selon la forme de l’invite et le taux d’acceptation.
• Les bibliothèques sont devenues sérieuses : llama.cpp a comblé beaucoup d’écarts de performance sur AVX2/AVX-512/NEON/SVE et prend en charge des poids mappés en mémoire ; MLC LLM a relevé le plancher sur Arm et des environnements hétérogènes.
• Les CPU sont devenus larges et bon marché : les gammes Sapphire Rapids et Bergamo ont apporté plus de cœurs, de plus gros L3 et des canaux mémoire plus rapides. Les instances CPU dans le cloud restent tarifées comme, eh bien, des CPU — pas comme des expositions d’art HBM.

Et oui, cette démo sur Hacker News d’un modèle 26B à ~5 jetons/s sur un vieux Xeon est un coup de pub. Mais l’idée tient : si un CPU de musée peut faire ça, un CPU moderne peut porter beaucoup de vraie charge.

Un calcul de TCO acceptable

Vous n’avez pas besoin de chiffres parfaits pour choisir une architecture ; vous avez besoin d’ordres de grandeur. Voici une manière de modéliser sans acrobaties Excel :

1. Choisissez une taille de modèle candidate (3B, 8B). Validez la qualité sur un jeu d’éval de 100–200 échantillons pour vos tâches réelles (appels d’outils, réponses courtes, routage). Si le taux de réussite est à ±3–5 points de votre référence GPU actuelle, gardez-la.
2. Mesurez trois éléments sur du matériel réel : le débit de préremplissage (jetons/s) pour votre longueur d’invite moyenne, le débit de génération pour votre longueur de sortie moyenne, et le temps au premier jeton. Faites-le sur une machine 8–32 vCPU alignée sur votre classe de production (Intel AVX-512 ou AMD Zen 4/4c). Reproduisez sur un A10/A100/L4 unique si vous en avez un.
3. Calculez les instances requises : Instances = ceil((générations concurrentes au pic × jetons de sortie moyens / débit de génération) / SLO). Soyez conservateur sur le débit ; prenez votre p50 ou p75, pas le p99 des bons jours.
4. Comparez l’économie unitaire : multipliez les instances par le coût horaire. Sur CPU, vous aurez probablement un autoscaling plus simple et du scale-to-zero, alors que les GPU punissent souvent avec de longs warmups et des allocations orphelines.

À titre de référence, les instances CPU cloud restent 3–6× moins chères à l’heure que les instances mono-GPU. Si votre charge est inactive 80% de la journée et génère ≤100 jetons par requête, un pool CPU avec scale-to-zero agressif battra presque toujours un GPU « au parking », même si le GPU est 2–4× plus rapide en débit en régime établi.

Les meilleurs cas d’usage de l’inférence 100% CPU en 2026

1) Routage, classification et application de politiques

Modération, masquage de PII, routage d’outils, classification d’intention et contrôles d’autorisations préfèrent des sorties courtes et des invites serrées. Un modèle 1,5B–3B ajusté par instruction en 4 bits atteint souvent une précision à quelques points de votre 7B/8B de référence. La latence reste sous la seconde sur un serveur moderne 16–32 vCPU. Vos GPU ne doivent pas brûler des cycles pour du gardiennage.

2) Planificateurs d’appels d’outils et contrôleurs d’agents

Les étapes de planification ont rarement besoin de longues générations. Elles ont besoin de fiabilité. Un modèle compact plus un schéma d’appels de fonctions strict tourne sereinement sur CPU, vos GPU coûteux étant réservés aux tâches lourdes comme la synthèse de code ou le raisonnement à grand contexte. Si vous allez vers des agents, les CPU sont votre plan de contrôle.

3) Chat à pics marqués et faible taux d’utilisation

Bots internes de support qui voient des pointes aux heures de bureau puis restent quasi inactifs ? L’autoscaling sur CPU gagne. Ajoutez du décodage spéculatif pour rogner la latence et fixez un SLO du type « premier jeton en ≤700 ms, diffusion à ≥10 jetons/s ». Le streaming masque une partie de l’écart de débit brut face aux GPU.

4) Exigences locales et on-prem

Tout le monde ne veut pas expédier des PII au-delà des frontières vers une région GPU. Pour Brazil (LGPD) et la résidence des données dans l’EU, il est bien plus facile d’acheter de la capacité CPU dans le pays — en bare metal ou dans une région cloud grand public — que de chasser des GPU là où les régulateurs veulent que vos charges s’exécutent. Votre équipe nearshore peut gérer ; votre auditeur dormira mieux.

5) Inférence en périphérie pour apps mobiles et desktop

Les portables, stations de travail et serveurs compacts (NUC, EPYC mono-socket) peuvent faire tourner confortablement des modèles 1–4B pour des fonctionnalités hors ligne ou privacy-first. Si vous avez déjà investi dans l’inférence sur device côté mobile, appliquez la même logique à votre parc desktop d’entreprise.

Où le CPU va vous décevoir

• Génération longue : rapports, contenus marketing, réponses de plusieurs milliers de jetons. Vous exploserez vos SLO ou devrez provisionner un nombre absurde de cœurs.
• Grandes fenêtres de recherche : des contextes 16k–200k exigent de la bande passante mémoire et une taille de lot effective que le CPU ne peut pas égaler sans compromis douloureux.
• Vision/multimodal : quelques cas étroits marchent sur CPU, mais votre latence et vos coûts explosent vite. Préservez votre santé mentale ; utilisez un GPU.
• Fine-tuning et adapters : l’entraînement appartient aux GPU. Point.

Une pile d’inférence CPU pragmatique qui ne vous surprendra pas

Modèles et runtimes

• Taille de modèle : commencez avec des variantes 3B–8B ajustées par instruction. Si le 8B échoue vos évals de >5 points, ne forcez pas le CPU ; faites monter cette charge sur un GPU.
• Runtime : llama.cpp pour la portabilité et des optimisations CPU agressives ; MLC LLM pour Arm et un packaging unifié multi‑devices ; Ollama pour une intégration rapide (testez puis durcissez pour la prod).
• Quantification : utilisez du 4 bits poids-seuls avec échelles groupées (p. ex., q4_k_m). Rejouez votre suite d’éval après quantification ; les appels d’outils et sorties JSON sont les plus sensibles.
• Décodage spéculatif : associez un modèle « draft » 1–3B à votre cible 3–8B. Validez le taux d’acceptation sur vos invites ; 40–70% d’acceptation peuvent réduire la latence de 20–40% sans dérive de qualité.

Matériel et OS

• Familles de CPU : favorisez Intel AVX-512 (Sapphire Rapids) ou AMD Zen 4/4c (Genoa/Bergamo) avec un grand L3 et 8+ canaux mémoire. Arm (Graviton3/4) est convaincant en coût/watt si le chemin NEON/SVE de votre runtime est mature.
• Mémoire : la capacité d’abord. Un modèle 8B en 4 bits pèse ~4–6 Go pour les poids, mais prévoyez 3× de marge pour le KV cache et le batching. Si vous exécutez plusieurs workers, mappez en mémoire le même fichier de poids pour partager les pages entre processus.
• NUMA et pinning : épinglez les threads par socket. Utilisez numactl et cpusets. Désactivez l’oversubscription ; fixez les threads du runtime sur des cœurs physiques, pas des vCPU. Testez avec et sans SMT (hyper-threading) ; les résultats varient selon la micro‑architecture.
• Huge pages et mmap : appuyez les poids sur de grandes pages quand c’est disponible. Forcez le chargement des pages au démarrage pour éviter les surprises de page faults à la première requête. Mappez en mémoire des poids en lecture seule pour qu’ils soient partagés entre plusieurs workers.

Serving et autoscaling

• Pools par modèle : ne multiplexez pas plusieurs modèles dans un même process. Un modèle par worker, un worker par jeu de cœurs épinglés. L’échelle horizontale est votre amie.
• Autoscaling conscient de la file : scalez en fonction des requêtes en cours et des jetons en cours, pas seulement du CPU%. HPA/KEDA avec des métriques custom conviennent ; gardez le cool-down de montée sous 30 s pour absorber les pics.
• Démarrages tièdes : le chargement des poids via mmap est rapide, mais la résidence des pages n’est pas gratuite. Gardez une petite réserve de workers chauds par modèle pour protéger vos p95.
• Streaming : diffusez toujours les jetons au client. Cela masque l’écart de débit brut et respecte confortablement les SLO de « temps au premier jeton ».

Observabilité qui a du sens

• Comptabilité des jetons : émettez les jetons d’invite, de sortie, le temps au premier jeton et les jetons/s. Distinguez les débits de préremplissage et de génération.
• Dérive de qualité : évals nocturnes sur un jeu de test fixe. Suivez les deltas de taux de réussite quand vous changez la quantification, les drapeaux du runtime ou les options du compilateur.
• Contrôle d’admission : si la profondeur de file dépasse N, rejetez des requêtes ou routez vers un pool GPU. Être honnête vaut mieux que violer vos SLO.

Sécurité et conformité : les CPU simplifient l’exécution dans le pays

La rareté des GPU a créé un schéma malsain : expédier les données là où il y a des GPU. Si vous avez des contraintes LGPD, HIPAA ou SOC2 — et beaucoup d’entre vous en ont — les régions CPU et le bare metal sont triviaux à obtenir dans le pays (Brazil, EU ou certains États américains). Vous obtenez :

• Des achats plus courts : la capacité CPU est partout ; vos cycles d’achat et de revue sécurité se comptent en semaines, pas en trimestres.
• Une attestation plus simple : moins de dispersion fournisseurs et moins d’accélérateurs « boîtes noires » à expliquer aux auditeurs.
• Des opérations nearshore : un pod basé au Brazil peut faire tourner et durcir votre cluster d’inférence CPU avec 6–8 heures de recouvrement quotidien et un run-rate sensiblement plus bas qu’une équipe US.

Comment piloter en 30 jours sans dérailler votre roadmap

1. Semaine 1 : choisissez deux charges qui correspondent aux sweet spots (p. ex., modération et routage d’outils). Figez un jeu d’éval de 100–200 échantillons avec vérité terrain.
2. Semaine 2 : mettez en place un pool CPU (16–32 vCPU, 64–128 Go de RAM). Déployez llama.cpp ou MLC avec un 8B et un 3B candidats, tous deux en 4 bits. Ajoutez streaming + métriques pour les jetons et la latence.
3. Semaine 3 : faites un A/B/C par rapport à votre chemin actuel appuyé par GPU. Si le chemin CPU est à ±3–5 points de qualité et sous votre SLO, poursuivez. Sinon, réduisez le modèle ou serrez les invites ; si ça échoue encore, déclarez « GPU requis » et passez à la suite.
4. Semaine 4 : mettez en production avec autoscaling basé sur la file, contrôle d’admission et une route d’overflow GPU pour les pointes. Définissez des alertes sur les régressions de jetons/s et les erreurs de schéma induites par la quantification.

Pièges courants (et comment les éviter)

• Penser que CPU == mauvaise qualité : c’est votre banc d’éval qui tranche. Beaucoup de modèles 3B–8B passent très bien sur des tâches étroites avec les bonnes invites et la bonne quantification.
• Ignorer la bande passante mémoire : l’inférence CPU est souvent bornée par la mémoire. Favorisez des pièces avec plus de canaux mémoire et un L3 plus grand ; gardez des tailles de lot réalistes.
• Sur-optimiser les threads : plus de threads n’assurent pas plus de jetons/s. Trouvez le coude de la courbe pour votre CPU ; épinglez et arrêtez.
• Ne pas tester les appels de fonctions sous quantification : les schémas JSON et les appels d’outils sont fragiles quand vous serrez la précision. Validez et, si besoin, sur-quantifiez la tête de sortie ou utilisez du décodage contraint.
• Oublier le scale-to-zero : le gain économique des CPU s’effondre si vous laissez des pools tièdes toute la journée pour des charges qui ne montent que 10 minutes par heure. Réglez-le finement.

Et le « flash à large bande passante » pour les poids ?

Vous verrez des propositions de niveaux NVRAM/NVMe vendus comme quasi-HBM pour les poids de modèles. C’est utile, avec des réserves :

• Aide au cold start : des magasins de poids appuyés par flash réduisent les temps de chargement à froid pour des modèles multi‑Go à travers les workers. À combiner avec mmap pour partager les pages.
• Pas de miracle : la génération reste bornée par la SRAM/DRAM. Une fois chaud, les poids doivent être en RAM. N’attendez pas du flash qu’il augmente les jetons/s en régime établi.
• L’endurance compte : nous avons vu des équipes user prématurément leurs SSD en thrashant des poids. Épinglez les modèles populaires ; faites tourner la longue traîne parcimonieusement.

Utilisez le flash pour améliorer la fluidité opérationnelle, pas pour prétendre que votre CPU est un GPU.

Oui, mélangez les architectures

Le schéma gagnant en 2026 ressemble à ceci :

• Pool CPU pour le routage, les filtres, les planificateurs, les générations courtes et le trafic on‑prem/dans le pays.
• Pool GPU pour les contextes longs, les longues sorties, le multimodal et toute tâche qui échoue votre seuil CPU à l’éval.
• Routage de débordement pour que les files CPU puissent se déverser vers le GPU pendant les pointes, avec des plafonds budgétaires stricts pour éviter les mauvaises surprises.

Ce n’est pas du dogme. C’est juste de la marge. Vous gardez la qualité où vous en avez besoin et vous rachetez du coût et de la simplicité partout ailleurs.

Si vous voulez de l’aide

DHD Tech construit et opère des pools d’inférence CPU pour des startups US avec des pods basés au Brazil. Nous mettrons en place votre banc d’éval, dimensionnerons les modèles, durcirons la pile de serving et câblerons l’autoscaling avec des bascules propres vers l’overflow GPU — pour que vous arrêtiez de payer des accélérateurs qui restent inactifs 18 heures par jour.

À retenir

• Ne partez pas par défaut sur des GPU. Si contexte ≤8k, sortie ≤150 jetons et concurrence de pointe modérée, les CPU gagnent probablement.
• La quantification et le décodage spéculatif ont rendu l’inférence CPU pratique pour des modèles 1B–8B sans saccager la qualité.
• Mesurez les jetons/s en préremplissage/génération et le temps au premier jeton sur VOS invites ; laissez votre banc d’éval décider.
• Utilisez le CPU pour le routage, les politiques, les planificateurs, le chat à bursts et les workloads dans le pays ; gardez les GPU pour le long, le lourd ou le multimodal.
• Architectez avec des poids mappés (mmap), de l’épinglage de threads, de l’autoscaling basé file et du streaming. Ajoutez un overflow GPU pour les pointes.
• Le flash aide au cold start, pas au débit établi. N’épuisez pas l’endurance des SSD en thrashant les poids.
• Des opérations CPU nearshore sont faciles à staffer et à auditer. Vous livrerez plus vite et dépenserez moins.