Cessez de jouer l’avenir de l’entreprise sur CUDA : le playbook 2026 du CTO pour la portabilité de l’IA

Si votre feuille de route IA suppose NVIDIA pour toujours, vous n’êtes qu’à une réunion fournisseur d’un incident au niveau du conseil. Le rapport performance/prix s’améliore vite, la disponibilité est erratique, et même les éditeurs de modèles explorent leurs propres puces. Anthropic discuterait d’un accélérateur sur mesure avec Samsung ; parallèlement, une nouvelle vague de billets montre un gain de performance/prix quasiment mensuel. L’enjeu n’est pas de savoir qui “gagne”. L’enjeu, c’est que vous ne pouvez pas vous le permettre. Votre pile doit tourner là où le silicium bon marché et disponible se trouvera le trimestre prochain.

Le marché du matériel vient de se décommoditiser — à nouveau

Il y a deux ans, “GPU” signifiait CUDA, et CUDA signifiait NVIDIA. En 2026, vous avez des choix — et c’est précisément pourquoi vous avez besoin d’un plan de portabilité.

• NVIDIA H100 : Référence pour le débit et la maturité de l’écosystème. 80–94 Go de HBM, kernels matures (FlashAttention, Triton), large disponibilité en cloud. Les machines 8x à la demande se situent généralement de la haute dizaine au bas de la centaine d’USD/heure selon la région et les engagements.
• AMD MI300X : 192 Go de HBM par GPU, c’est le fait marquant. Cette marge mémoire autorise des batchs plus gros, des contextes plus longs et moins de bricolage de sharding de tenseurs. ROCm a suffisamment mûri pour que les piles d’inférence grand public soient viables, pas des projets de labo.
• Intel Gaudi (Gaudi2/3) : Un rapport prix/perf étonnamment compétitif dans certains clouds, un excellent débit en BF16, une histoire d’interconnexion alternative, et un fournisseur motivé à faire des remises.
• Google TPU (v5e/v5p) : Toujours pertinent pour l’entraînement à grande échelle et pour l’inférence si vous pouvez vivre dans GCP et bien cibler XLA.
• Edge et sur appareil : Apple Silicon (Metal), GPU de classe Vulkan, et CPU avec AVX-512 ou AMX. Pas votre bête de somme pour l’entraînement — mais crucial pour l’inférence privée et à faible latence quand les données ne peuvent pas quitter l’appareil.

La mémoire, pas les flops, est généralement le facteur limitant en inférence. Les 192 Go du MI300X permettent de garder l’hébergement multi‑tenant honnête en évitant le sharding “Frankenstein”. La maturité des kernels du H100 l’emporte souvent en tokens/s bruts. Les TPU peuvent paraître excellents jusqu’à tomber sur une op non prise en charge. Vos coûts varient avec la taille de batch, la longueur de contexte et la présence (ou l’absence) d’un bon kernel d’attention fusionnée pour votre modèle exact. C’est pourquoi la portabilité bat le partisanisme fournisseur.

Ce que “portable” signifie vraiment pour un CTO

La plupart des équipes pensent que la portabilité, c’est “on peut exporter en ONNX”. C’est l’étape 1, pas la destination. La vraie portabilité couvre six couches. Auditez chacune.

• Format des poids : safetensors pour la sûreté et la vitesse ; chemins de compilation ONNX ou OpenXLA pour des cibles larges ; GGUF pour CPU/edge via llama.cpp.
• IR de graphe : ONNX ou StableHLO/XLA vous permettent de retargeter sans rester éternellement en PyTorch eager. TVM/IREE peut compiler vers Vulkan/Metal/ROCm/CUDA pour des chemins non‑NVIDIA.
• Runtime : vLLM, Text Generation Inference (TGI), llama.cpp ou MLC LLM. Choisissez au moins deux options avec des dépendances de backend différentes.
• Kernels : FlashAttention, Triton, MLP fusionnés. Ils sont souvent CUDA-first. Vous avez besoin d’équivalents ROCm ou HIP, ou d’un compilateur IR qui fusionne suffisamment bien les ops sans CUDA sur mesure.
• Quantification et agencement mémoire : FP16/BF16 comme dénominateur commun ; INT8/INT4 (AWQ, GPTQ, SmoothQuant) augmentent le débit mais réduisent la portabilité, sauf si vous choisissez des méthodes prises en charge sur plusieurs backends.
• Couche de serving et ordonnanceur : le continuous batching et la paged attention (p. ex., dans vLLM) font baisser les coûts mais peuvent être sensibles au backend. Votre couche de serving doit exposer la même API sur tous les matériels.

Un cadre de décision pour 2026 : choisissez votre voie de portabilité

Voie 1 : double source d’inférence (CUDA + ROCm) pour 80 % des cas d’usage

Si vous exécutez des modèles de classe 7B–70B pour le chat, la génération augmentée par recherche et le code, c’est le choix pragmatique par défaut. Gardez NVIDIA en premier pour la maturité des kernels, et maintenez AMD comme seconde source entièrement validée et apte à la production.

• Runtime : vLLM comme pile de serving principale. Il prend en charge CUDA et de plus en plus ROCm, offre un continuous batching performant et s’intègre proprement aux tokenizers et aux API au format OpenAI.
• Fallback : TGI ou llama.cpp pour certains modèles ou des recours CPU/Metal.
• Quantification : Maintenez deux variantes homologuées par modèle : BF16/FP16 et INT8. Traitez l’INT4 comme opportuniste jusqu’à preuve de stabilité sur vos backends non‑CUDA.
• Infra : Conservez deux images conteneur de référence (“golden”) : l’une avec CUDA et les libs du fournisseur, l’autre avec ROCm. Figez les versions des toolkits pilotes et publiez des SBOM.

Quand choisir : vous voulez acheter ce qui est sur le marché spot le trimestre prochain, pas ce que votre feuille de route supposait l’an dernier. Vous devez réduire de 20–40 % le coût d’inférence sans réentraîner les modèles ni réécrire la logique métier.

Voie 2 : compilation IR‑first (ONNX/OpenXLA + IREE/TVM) pour l’edge et les accélérateurs exotiques

Si vous livrez de l’inférence mobile ou embarquée, ou si vous voulez de l’optionalité entre TPU et futurs siliciums sur mesure, investissez dans l’IR‑first. Vous sacrifierez un peu de débit absolu pour la liberté de retargeter rapidement.

• Pile de compilation : exportez vers ONNX ou StableHLO, puis compilez avec IREE ou TVM vers Vulkan, Metal, CUDA ou ROCm.
• Runtime : MLC LLM pour un chemin “batteries incluses” vers mobiles et desktops ; il s’appuie sur TVM pour plusieurs backends.
• API : figez votre API publique au niveau de la couche de serving. Gardez les choix de compilateur invisibles pour les équipes produit.

Quand choisir : vous devez exécuter sur appareil pour la confidentialité ou la latence, ou vous anticipez des accélérateurs non‑GPU dans votre pipeline d’achats. Vous voulez un chemin de code unique pour Vulkan/Metal/ROCm/CUDA.

Voie 3 : filet de sécurité CPU‑first pour SLO et DR

Il y aura des jours sans GPU. Une voie CPU robuste maintient vos P99 et SLA honnêtes lors des chocs d’approvisionnement GPU, des mises à niveau ou des incidents de sécurité.

• Runtime : llama.cpp ou MLC LLM ciblant le CPU, avec des poids GGUF. Ciblez AVX-512 ou AMX lorsque disponible.
• Périmètre : modèles plus petits (3B–7B) avec des fine‑tunes spécifiques aux tâches pour une qualité “suffisante” quand les GPU sont indisponibles.
• Usage : capacité canari et d’urgence, plus inférence privée sur appareil pour les segments régulés.

Les deux seuls chiffres qui comptent : coût par 1 000 tokens et latence du premier token

Ignorez les comparaisons génériques en “TFLOPs”. Vos clients ressentiront deux choses : le temps avant l’apparition du premier token, et le coût de chaque millier de tokens à vos SLO.

• Coût par 1 000 tokens : approximez comme (prix instance $/heure) divisé par (tokens/seconde × 3 600) pour un contexte/profondeur de batch fixés. Le continuous batching fait pencher la balance en votre faveur ; les invites courtes et interactives, non.
• Latence du premier token (FTL) : pilotée par l’ordonnanceur, la taille du modèle, les kernels fusionnés et les mouvements mémoire. Une pile CUDA avec FlashAttention mature peut battre une pile ROCm à plus grande mémoire en FTL, même si le débit total est comparable.

La conclusion : avec le bon batching et les bons kernels, le coût interne par 1 000 tokens pour un modèle 7B peut tomber sous le centime sur H100 comme sur MI300X. Les API cloud facturent encore une prime par 1 000 tokens pour la simplicité et la disponibilité. Votre plan de portabilité est le levier qui vous permet de capter ce delta — quand un autre fournisseur est moins cher ce trimestre.

Auditez vos hypothèses CUDA en une après‑midi

Avant de parler multi‑fournisseur, prouvez que vous n’êtes pas figés sur CUDA. Confiez à un senior cette checklist et exigez un compte rendu d’ici la fin de journée.

• Grep du code : recherchez les imports explicitement CUDA‑only (torch.cuda, cupy, kernels triton), des chaînes d’appareil en dur, et des images de base nvidia/cuda dans les Dockerfiles.
• Wheel lock : listez les wheels épinglées. Si vous avez épinglé torch et xformers sur des builds CUDA, notez les équivalents ROCm et si votre résolveur Python peut les permuter proprement.
• Ops custom : inventoriez les extensions Triton ou CUDA. Pour chacune, identifiez la parité ROCm/HIP ou une alternative via compilateur IR.
• Kernels : confirmez votre histoire de kernel d’attention des deux côtés. Une parité de type FlashAttention existe sur ROCm désormais, mais toutes les variantes de modèles ne sont pas couvertes.
• Serving : votre binaire de serving peut‑il tourner sur ROCm aujourd’hui ? Sinon, qu’est‑ce qui manque — kernel, driver ou packaging ?
• CI : avez‑vous ne serait‑ce qu’un job ROCm ? Si la réponse est “non”, vous avez répondu à votre question de portabilité.

Construisez un banc de test de portabilité — une bonne fois

La portabilité n’est pas une slide ; c’est une suite de tests. Traitez‑la comme de l’ingénierie de release.

• Bundle de modèle standard : archivez (zip) les poids (safetensors), le tokenizer, les modèles d’invite et un manifeste consignant la quantification et les sorties attendues pour des invites de référence.
• Golden prompts : 100–200 invites qui exercent vos charges réelles : chats courts, contextes 8–32K, RAG avec longs contextes, complétion de code, streaming.
• Métriques : pour chaque backend, relevez les tokens/s en régime établi, la latence du premier token, la VRAM et l’utilisation vCPU. Déduisez le $/1 000 tokens selon vos prix d’instance réels.
• Conteneurs : publiez des images artifactées par backend : CUDA, ROCm, CPU/Metal. Figez les combinaisons drivers/toolkits. Incluez des SBOM et des scans de CVE connues.
• Validez sur les chiffres : une PR échoue si un backend régresse de >10 % sur le coût ou la FTL sans dérogation. Intégrez ces garde‑fous à votre CD.

Piles de serving qui survivent sur plusieurs matériels

Choisissez-en deux, pas une.

• vLLM : batching à haut débit, trajectoire multi‑backend (CUDA d’abord, ROCm de plus en plus viable) et API au format OpenAI. Excellent choix par défaut pour l’inférence serveur.
• TGI : trajectoire CUDA solide, histoire ROCm raisonnable pour de nombreux modèles, forte intégration Hugging Face. Bonne seconde source.
• llama.cpp : le couteau suisse. Backends CPU, Metal, Vulkan avec GGUF. Débit plus faible, mais inestimable comme fallback et pour l’edge.
• MLC LLM : la meilleure façon de livrer sur mobile et divers GPU desktop via TVM. Utile quand votre roadmap produit exige du on‑device.

Quoi que vous choisissiez, stabilisez votre API publique et l’auth devant ces piles. Votre app ne doit ni savoir ni se soucier du backend actif cette semaine.

Quantification sans mauvaises surprises

• Standardisez sur BF16/FP16 pour la base et INT8 pour le débit. Traitez l’INT4 comme un niveau d’optimisation avec des tests d’acceptation explicites pour la précision et les taux d’hallucination.
• Choisissez des méthodes qui voyagent : SmoothQuant et AWQ sont largement prises en charge ; les variantes GPTQ peuvent être fragiles selon le backend.
• Testez les longs contextes : la quantification interagit mal avec l’attention à long contexte dans certains kernels. Incluez des tests 32K+ dans votre banc si votre produit le prend en charge.

Entraînement et fine‑tuning : soyez lucides sur le périmètre

La portabilité pour le pré‑entraînement complet relève du budget recherche. Pour les startups et scale‑ups, limitez‑vous à l’inférence et aux réglages efficaces en paramètres.

• Les fine‑tunes LoRA/QLoRA sur CUDA comme sur ROCm sont viables en 2026. Prévoyez de les exécuter là où la capacité est disponible, mais gardez d’abord votre serving portable.
• Gaudi et TPU peuvent être d’excellentes options d’entraînement. Ne laissez simplement pas leur avantage à l’entraînement vous forcer à servir exclusivement dessus si vos unit economics réclament plus tard H100 ou MI300X.

La sécurité et l’opérabilité ne sont pas optionnelles

Multi‑backend rime avec multi‑drivers et multi‑runtimes exposés. Renforcez l’hygiène.

• Drivers : utilisez des conteneurs de drivers maintenus par le fournisseur ou des modules noyau avec suivi des CVE connues. N’installez pas de drivers ad hoc sur les hôtes.
• Repro : builds hermétiques avec compilateurs figés (Triton, TVM) et wheels vérifiées. Générez des SBOM et des attestations.
• Isolation : pour les nœuds multi‑tenant, utilisez MIG sur NVIDIA et l’isolation cgroup partout. Ne laissez pas un kernel panic dans un runtime en mettre un autre à terre.
• Observabilité : exportez des compteurs matériels (bande passante HBM, occupation des SM), pas seulement des tokens/s. Alertez sur les régressions de latence du premier token, pas seulement sur le throughput p95.

Qui s’en charge ? Constituez une équipe “deux pizzas” orientée compilateurs

Si vous centralisez tout le travail IA sur vos feature teams, la portabilité meurt de mille TODO. Dédiez 2–3 ingénieurs dont le métier est de faire tourner les modèles partout.

• Compétences : capture de graphe PyTorch 2.x, Triton, FlashAttention, bases ROCm/HIP, ONNX/XLA et un compilateur IR (TVM ou IREE).
• Mandat : posséder le banc de portabilité, les bundles de modèles de référence, les images conteneur et les garde‑fous de perf. Posséder les benchmarks fournisseurs et les entrées pour les achats.
• Cadence : un “futures day” trimestriel pour tester de nouveaux SKU et clouds, avec recommandation écrite buy/no‑buy fondée sur le $/1 000 tokens et la FTL.

Angle nearshore : utilisez la géographie à votre avantage

Si vous êtes basés aux États‑Unis, une cellule nearshore au Brazil vous donne 6–8 heures de recouvrement et un accès à des capacités alternatives. En 2026, MI300X et Gaudi apparaissent souvent d’abord dans des régions hors US et des clouds régionaux. Profitez de cet arbitrage.

• Topologie : gardez le trafic interactif dans la région (US‑East/West) pour protéger la latence P95. Routez l’inférence batch et les fine‑tunes vers la région la moins chère — Amérique du Sud, Europe, où que le marché spot vous sourie.
• Ops : l’équipe nearshore fait tourner le banc de portabilité et certifie les nouvelles régions/matériels pendant que votre équipe cœur livre des fonctionnalités.

La provocation

La portabilité n’est pas un idéal académique. C’est le mécanisme qui vous permet d’acheter ce qui est bon marché et disponible le trimestre prochain sans réécrire votre produit ni renégocier vos SLA. NVIDIA sera peut‑être encore votre meilleure option la plupart du temps. Tant mieux — un plan de portabilité facilite la démonstration chiffrée auprès des achats. Et quand ce ne sera pas le cas, vous ne serez pas l’entreprise qui paie 30 % de plus parce que sa base de code ne sait pas épeler ROCm.

Un plan d’action sur 30 jours

• Semaine 1 : lancez l’audit CUDA. Produisez une liste d’écarts d’une page. Montez un second backend (ROCm ou CPU) dans la CI.
• Semaine 2 : construisez le banc de portabilité : bundles de modèles de référence, invites et garde‑fous de perf. Conteneurisez les images CUDA et ROCm avec leurs SBOM.
• Semaine 3 : certifiez deux runtimes (p. ex., vLLM sur CUDA et ROCm, llama.cpp sur CPU/Metal). Générez le premier rapport $/1 000 tokens et FTL sur le matériel que vous pouvez louer cette semaine.
• Semaine 4 : présentez une note d’achats avec trois options : “Rester”, “Basculer 25 % vers AMD” et “Ajouter un fallback CPU”. Incluez coût, risque et calendrier. Décidez et exécutez.

Points clés

• Le rapport performance/prix évolue au trimestre ; ne liez pas votre courbe de coûts à la roadmap d’un seul fournisseur.
• La vraie portabilité couvre poids, IR, runtime, kernels, quantification et serving — pas juste “on peut exporter en ONNX”.
• Choisissez deux piles de serving et deux backends. vLLM + CUDA/ROCm, avec llama.cpp comme filet de sécurité CPU/Metal, couvrent la plupart des besoins.
• Mesurez ce qui compte : coût par 1 000 tokens et latence du premier token sur vos charges réelles.
• Quantifiez délibérément : gardez FP16/BF16 et INT8 comme niveaux homologués ; traitez l’INT4 comme optionnel jusqu’à preuve de parité hors CUDA.
• Constituez une petite “compiler team” pour posséder le banc de portabilité, les garde‑fous CI et les benchmarks fournisseurs.
• Utilisez des capacités nearshore pour qualifier de nouveaux matériels et exploiter l’arbitrage régional des prix sans sacrifier la latence des utilisateurs US.