Votre feuille de route IA face au goulot d’étranglement de la RAM : le playbook 2026 pour CTO

Votre feuille de route IA s’effondre là où commence la mémoire. Ce n’est pas un effet d’annonce : plusieurs rapports indiquent que l’offre de RAM et de HBM restera tendue, et les analyses d’imagerie satellite pointent des retards de plusieurs mois pour la mise en service de nouvelles capacités de centres de données. Si votre plan suppose une mémoire GPU élastique, vous passerez 2026 au purgatoire de l’approvisionnement pendant que vos concurrents livreront des expériences sur appareil (on-device), quantifiées et optimisées pour la mémoire.

Ce n’est pas une histoire de rareté des GPU. C’est pire : une histoire de goulot d’étranglement mémoire. Des FLOPS, on peut parfois en louer. De la mémoire, beaucoup moins. La bonne nouvelle : on peut concevoir autour de cette contrainte. Voici un playbook pratique, guidé par les chiffres, pour livrer des fonctionnalités IA avec des contraintes RAM dures.

La contrainte à respecter : la mémoire prime sur les FLOPS

La plupart des échecs des LLM en production se ramènent à la mémoire, pas au calcul brut. L’inférence vit et meurt selon deux facteurs :

• Mémoire des poids : paramètres du modèle (plus les surcoûts d’exécution/fragmentation)
• Mémoire du cache KV : l’historique d’attention stocké par token, par couche, par séquence

Quelques calculs « à la louche » transforment les débats de design en décisions. Prenons comme guide une géométrie de type Llama :

• Poids : FP16 ≈ 2 octets/paramètre. 7B ≈ 14 GB ; INT8 ≈ 7 GB ; INT4 ≈ 3.5 GB
• Cache KV par token ≈ 2 × hidden_size × n_layers × bytes_per_element

Pour un modèle de classe 7B (hidden≈4096, layers≈32) :

• KV en FP16 par token : 2 × 4096 × 32 × 2 octets ≈ 524 KB/token
• Avec un contexte 4K : ≈ 2.0 GB par séquence active
• En KV 8 bits : ≈ 1.0 GB ; en KV 4 bits : ≈ 0.5 GB

Vérification terrain : un modèle 7B INT4 (≈3.5 GB de poids) avec une seule séquence 4K et un KV en FP16 brûle déjà ≈5.5–6.5 GB au total après overhead. La simultanéité fait exploser linéairement la mémoire du KV. Seize séquences 4K concurrentes ? Vous regardez ≈32 GB de cache KV rien que pour cela, avant même les poids. Voilà pourquoi votre carte 24 GB sature alors que votre profileur indique que les SM sont inactifs.

Un cadre de budgétisation mémoire à confier à vos équipes

Avant de discuter des familles de modèles, faites ceci pour chaque charge de travail :

1. Fixez des SLO de qualité et de latence cibles (ex. p95 TTFB ≤ 300 ms, latence p95 ≤ 2.5 s, sortie 200 tokens en moyenne).
2. Estimez le pic de séquences simultanées par GPU pour ces SLO (soyez honnête sur les pics de trafic).
3. Choisissez une variante de modèle et un plan de quantification (poids en INT4/8, KV en 8/4 bits).
4. Calculez mémoire des poids + mémoire du KV + 15–25% de marge pour l’exécution/la fragmentation.
5. Si ça ne tient pas : réduisez le contexte, quantifiez le KV, changez de runtime ou réduisez la simultanéité.

Faites une seule feuille de calcul avec une ligne par endpoint et des colonnes pour les éléments ci-dessus. Si votre budget ne passe pas, votre feuille de route non plus.

Exemple chiffré : endpoint de chat 7B

• Modèle : 7B INT4 (≈3.5 GB)
• Contexte : 4K ; KV en 8 bits (≈1.0 GB par séquence active)
• Objectif de simultanéité par GPU : 12
• Sous-total KV : ≈12 GB ; + poids : ≈3.5 GB ; overhead 20% : ≈3.1 GB
• Total : ≈18.6 GB

Cela peut tenir sur une carte 24 GB avec un runtime soigné (KV paginé, faible fragmentation). La même configuration en KV FP16 serait ≈30+ GB et ne tiendrait pas. Ce seul réglage (quantification du KV) fait la différence entre livrer maintenant et attendre six mois des GPU plus gros.

Exemple chiffré : résumeur RAG 13B

• Modèle : 13B INT4 (≈6.5–7.0 GB)
• Contexte : 8K ; KV en 4 bits (≈0.8 MB/token) → ≈3.2 GB par séquence
• Simultanéité : 6
• Sous-total KV : ≈19.2 GB ; poids : ≈7 GB ; overhead 20% : ≈5.2 GB
• Total : ≈31.4 GB

Vous êtes désormais en territoire 40 GB+. Options : réduire le contexte à 4K (≈16 GB de KV), utiliser la recherche pour garder des prompts compacts, ou répartir sur deux GPU plus petits via parallélisme tensoriel/de séquence (en acceptant la surcharge réseau et la gigue).

Leviers d’ingénierie pour réduire la mémoire sans tuer la qualité

Pas de solution miracle ; c’est une pile de leviers. Votre objectif est de combiner suffisamment de gains de 1.2–2.0x pour dégager la marge nécessaire.

Quantifier la bonne chose de la bonne manière

• Poids : l’INT4 (AWQ/GPTQ/SpQR) réduit la mémoire de 3–4x avec une perte de qualité minimale sur 7B/13B. Validez sur votre banc d’éval, pas seulement sur des captures MT-Bench.
• KV : 8 bits est souvent sans perte perceptible ; 4 bits peut convenir pour l’assistance/le chat mais peut dégrader le code ou les maths. Testez par endpoint.
• Activations (entraînement/affinage) : FP8/INT8 + checkpointing d’activations sont indispensables si vous n’êtes pas sur des cartes de 80 GB+.

Maîtriser le contexte, ne pas le vénérer

• Le KV domine la mémoire sur les longs contextes. Si vous utilisez rarement 32K, limitez par défaut à 4–8K et exigez une intention explicite pour aller plus loin.
• Utilisez le RAG pour rester court : la recherche et la synthèse avant la génération valent mieux que balancer 100K tokens de documents bruts dans le prompt.
• Le streaming de la réponse n’économise pas la mémoire ; il n’améliore que la latence perçue. Faites-le, mais ne le confondez pas avec un correctif.

Utiliser des runtimes impitoyables avec la mémoire

• vLLM ou SGLang : l’attention paginée et le batching continu augmentent le débit et limitent la fragmentation du KV ; des équipes terrain rapportent 1.5–3x tokens/sec/GPU vs une inférence PyTorch naïve.
• TensorRT-LLM ou MLC/llama.cpp pour les cibles quantifiées/Metal/WebGPU quand c’est pertinent.
• Surveillez le comportement de l’allocateur. Une « taxe » de fragmentation de 20% est courante ; >30% est un bug à corriger, pas un coût inévitable.

Décodage spéculatif et distillation

• Le décodage spéculatif avec un petit modèle « brouillon » offre souvent des gains de 1.3–1.8x en temps mur sans augmenter beaucoup la mémoire. Couplez un 3B d’ébauche avec votre 7–13B cible.
• Distillez des variantes spécifiques à la tâche : pour la classification/l’extraction, un modèle 1–3B suffit largement et réduit fortement poids et KV.

Affiner des adaptateurs, pas des modèles complets

• La mémoire d’un affinement complet = poids + gradients + états d’optimiseur + activations. Avec Adam, les états de l’optimiseur ajoutent à eux seuls 2x les paramètres. Au total, vous avez 12–20x le volume de paramètres en mémoire vive. Soit 160–280 GB pour une étape d’entraînement d’un 7B en FP16.
• LoRA/QLoRA ramène cela à quelques GB d’appoint et vous laisse conserver les poids de base quantifiés.

Choix d’architecture système qui débloquent de la capacité

Exploiter l’inférence sur appareil et dans le navigateur

Les applications IA débarquent sur le PC pour une raison : la mémoire côté client est pour vous gratuite et abondante. Exploitez-la.

• Apple Silicon (M3/M4) avec Metal et WebGPU peut exécuter des modèles 1–3B à des vitesses utilisables ; des démos récentes montrent une inférence GPU zero-copy depuis WebAssembly sur Apple Silicon, ce qui élimine toute une classe de copies hôte‑périphérique inutiles.
• Livrez des paliers « assist » qui s’appuient par défaut sur un petit modèle sur appareil et ne délèguent au serveur qu’en fonction de la confiance/routage. 30–50% des requêtes peuvent rester locales si vous le prévoyez.
• WebLLM/MLC + modèles quantifiés dans le navigateur sont le nouveau standard pour une UX à faible latence où la confidentialité est un atout, pas une contrainte.

Élargir votre cible matérielle

• N’attendez pas un seul SKU de GPU. Supportez NVIDIA (A100/H100/L40S), AMD (MI300/Strix Halo iGPU pour l’edge) et Apple Silicon via des runtimes portables.
• ROCm a mûri ; à l’échelle 7–13B, c’est viable en production. Validez les kernels critiques (FlashAttention, fused ops) avant de vous engager.

Shard avec intelligence, pas héroïsme

• Le parallélisme tensoriel/de séquence sur deux GPU de taille moyenne vaut mieux qu’attendre des mois des cartes 80 GB. Budgétez 10–20% de perte de débit due au surcoût d’interconnexion.
• La pagination du KV vers la RAM CPU peut relever les plafonds de simultanéité au prix d’une latence accrue. Utilisez‑la pour les endpoints batch/arrière‑plan, pas pour le chat.

Approvisionnement : comptez 6–9 mois pour une capacité « facile »

Entre les contraintes de HBM et les retards d’alimentation/refroidissement, partez du principe que :

• Les GPU cloud à grande mémoire à la demande sont élastiques mais peu fiables à grande échelle. Réservez de la capacité ou diversifiez régions/fournisseurs.
• Les instances spot/marchés paraissent bon marché sur le papier ; modélisez les taux de préemption dans vos SLO et bâtissez des chemins de checkpoint/reprise.
• Les délais en colocation peuvent dépasser deux trimestres. Achetez d’abord pour la densité de puissance (kW/rack), puis pour l’I/O réseau, puis les GPU. La mémoire n’est utile que si vous pouvez la nourrir.

Par mesure de bon sens, modélisez votre coût effectif par million de tokens sortants à des SLO p95 sur trois scénarios : cloud à la demande, cloud réservé et hybride (edge + GPU cloud plus petits). Beaucoup d’équipes constatent 20–40% d’économies en hybride simplement en déportant les requêtes « faciles » vers l’edge/on-device et en dimensionnant correctement le contexte côté serveur.

Observabilité : faire de la mémoire un SLI de premier rang

Vos tableaux de bord ne doivent pas s’arrêter aux tokens/sec et à la latence. Suivez la mémoire là où ça compte :

• Octets KV de pointe par requête et résidence en mémoire des poids
• Fragmentation de l’allocateur et RSS de pointe
• Taille de lot, simultanéité effective et distributions des longueurs de contexte
• Tokens/sec par GPU et time-to-first-token (TTFB) aux p50/p95

Standardisez les unités pour éviter la soupe de dashboards. Requêtes par seconde (r/s), tokens par seconde (tok/s), octets ; évitez les abréviations maison. Vos SRE et votre équipe finance vous remercieront.

Gouvernance : livrer des fonctionnalités qui respectent le budget

• Introduisez des « budgets de contexte » par endpoint : ex. 4K par défaut, 8K sur justification, 32K réservé aux plans admin/entreprise.
• Mettez en place un admission control sur la simultanéité par GPU. Si votre budget est 12 séquences/GPU, coupez à 12, pas à 20. Une latence en dents de scie est pire qu’un 429 avec retry-after.
• Rendez les dégradations explicites : repli sur petit modèle, « résumer puis générer », ou délégation serveur.

Un plan de 90 jours pour dérisquer votre feuille de route IA

Semaines 1–2 : inventaire et bases

• Dressez la liste de chaque endpoint IA et job batch. Pour chacun : modèle, quantification, contexte, simultanéité, SLO.
• Instrumentez la mémoire de pointe et l’usage du KV par requête en staging. Ne devinez pas.

Semaines 3–4 : prototyper la pile mémoire

• Construisez deux pipelines de référence par classe de charge : (a) vLLM + poids INT4 + KV 8 bits ; (b) llama.cpp/MLC pour on-device/web avec un modèle distillé 1–3B.
• Comparez qualité et latence sur vos jeux d’éval. Fixez les valeurs par défaut.

Semaines 5–6 : contrôles de contexte et de routage

• Faites respecter les budgets de contexte, ajoutez un prétraitement de retrieval, et raccordez un routage basé sur la confiance vers les petits modèles sur appareil.
• Implémentez le décodage spéculatif pour votre endpoint de chat le plus chargé. Validez l’absence de régression de qualité.

Semaines 7–10 : industrialiser

• Déployez vLLM/SGLang avec paged attention pour les endpoints serveur. Verrouillez la fragmentation de l’allocateur sous 25%.
• Fixez des plafonds de simultanéité et des seuils d’auto-scaling en fonction de la mémoire mesurée, pas seulement de l’utilisation CPU/GPU.
• Publiez les SLO et formez le support à la politique de dégradation.

Semaines 11–12 : diversification fournisseurs et régions

• Réservez de la capacité où nécessaire ; validez les voies AMD/Apple Silicon pour réduire le risque fournisseur.
• Organisez un game day de bascule. Mesurez le coût de la préemption et de la reprise. Corrigez ce qui casse.

Ce qu’attendre d’un partenaire nearshore dans un monde contraint par la mémoire

Si vous faites appel à un partenaire, exigez la maîtrise de la mémoire. Concrètement, demandez :

• Des déploiements avérés avec poids INT4/8 et KV 8/4 bits sans effondrement de la qualité
• Une expérience de vLLM/SGLang, TensorRT-LLM, et WebGPU/Metal pour on-device
• Un vrai banc d’évaluation (métriques spécifiques aux tâches, pas seulement des leaderboards génériques)
• Des playbooks opérationnels pour plafonds de simultanéité, dégradation et observabilité

Une équipe basée au Brazil, très à l’aise avec Apple Silicon, peut avancer vite sur les parcours on-device/navigateur — nombre de devs seniors livrent déjà des workloads Metal/WebGPU et testent par défaut sur des laptops série M. L’avantage en ce moment n’est pas seulement le coût — c’est le temps de cycle. Vous voulez une équipe qui traite la mémoire comme une contrainte produit, pas comme un ticket à ouvrir auprès de l’infra.

L’essentiel

Les pénuries de HBM/RAM et les retards des centres de données ne disparaîtront pas à votre échéance. Les entreprises qui gagneront en 2026 se comporteront comme des ingénieurs systèmes : elles mesureront la mémoire, la budgéteront et concevront des fonctionnalités autour d’elle. Si vous faites cela, vous n’avez pas besoin d’un miracle côté GPU pour livrer. Il vous faut une feuille de calcul, un runtime impitoyable, et la volonté de couper le contexte quand il ne paie pas.

Points clés

• La mémoire, pas le calcul, est votre contrainte de production principale. Budgétez poids + KV + overhead par endpoint avant de discuter des familles de modèles.
• Quantifiez à la fois les poids (INT4/8) et le KV (8/4 bits). Ces deux curseurs peuvent à eux seuls transformer un « ne tient pas » en « ça livre ce trimestre ».
• Limitez le contexte par défaut et utilisez le retrieval pour rester court. Les prompts longs sont une habitude coûteuse, pas une nécessité.
• Adoptez des runtimes impitoyables avec la mémoire (vLLM/SGLang) et surveillez la fragmentation de l’allocateur comme le lait sur le feu.
• Déportez sur on-device/web dès que possible. La mémoire côté client est gratuite pour vous et abondante.
• Comptez 6–9 mois pour ajouter une capacité fiable ; diversifiez fournisseurs et régions dès maintenant.
• Faites de la mémoire un SLI de premier rang : suivez les octets KV, la fragmentation et le p95 TTFB/tokens/sec.
• Choisissez des partenaires qui ont livré des systèmes quantifiés et « memory-aware » — pas juste des slides.