CUDA ou OpenCL : choisir l'accélération embarquée en 2026

Choisir entre CUDA et OpenCL pour un projet d'IA embarquée, c'est d'abord choisir un silicium : le framework d'accélération découle du processeur, pas l'inverse. Chez AESTECHNO, bureau d'études électronique à Montpellier, nous avons livré au premier trimestre 2026 un projet sur module NVIDIA Jetson Orin NX dont l'architecture engageait toute la pile CUDA. Voici notre grille d'arbitrage.

Le vrai choix au démarrage : le silicium avant l'API

Le choix d'un framework d'accélération GPU est la décision logicielle qui découle du processeur retenu pour un produit embarqué. CUDA n'existe que sur silicium NVIDIA, tandis qu'OpenCL et SYCL visent un parc hétérogène (GPU de SoC, FPGA, CPU multicoeur). Choisir le calcul accéléré, c'est donc d'abord choisir une cible matérielle, puis seulement ensuite l'API qui l'exploite.

Beaucoup d'équipes abordent la question dans le mauvais sens. Elles comparent CUDA et OpenCL sur le papier (performance, écosystème, courbe d'apprentissage) avant d'avoir verrouillé la cible silicium. Or, dans la pratique d'un produit industriel, la séquence est inverse : le cahier des charges fixe une enveloppe de puissance, un budget thermique, une cible d'inférences par seconde et une durée de vie produit. Ces contraintes orientent vers une famille de processeurs, et cette famille rend l'arbitrage API presque automatique. Un module Jetson impose CUDA. Un GPU Mali dans un SoC NXP i.MX 8M Plus impose OpenCL. Un FPGA Xilinx ouvre la voie OpenCL ou HLS. Un NPU Hailo ou un accélérateur ethos-U impose le SDK du fondeur.

Un sous-arbitrage de la décision d'architecture

On ne choisit pas librement son framework de calcul : le vrai degré de liberté se situe en amont, au moment de sélectionner le processeur. Une fois ce choix gravé dans le routage du PCB, l'API est largement déterminée. C'est pourquoi nous traitons CUDA contre OpenCL comme un sous-arbitrage d'une décision d'architecture plus large, au même titre que notre méthode pour choisir entre SoC, SoM, SBC et custom.

CUDA en bref : l'écosystème qui a gagné le edge AI

CUDA est la plateforme de calcul parallèle propriétaire de NVIDIA, qui expose les coeurs GPU et les Tensor Cores via un modèle de programmation C/C++ étendu. Sur l'embarqué, elle s'appuie sur la pile JetPack (pilotes, cuDNN, TensorRT) et constitue l'écosystème logiciel le plus mûr pour l'inférence en périphérie, du Jetson Orin Nano au module AGX Orin.

La force de CUDA n'est pas le langage, c'est tout ce qui gravite autour. Les bibliothèques optimisées (cuDNN pour les réseaux de neurones, TensorRT pour l'optimisation et la quantification, cuBLAS, NPP pour le traitement d'image) couvrent la quasi-totalité des besoins d'un projet de vision ou d'IA embarquée. Le module Jetson Orin NX 16 Go embarque 2048 coeurs CUDA et 64 Tensor Cores de troisième génération.

Jetson Orin NX : la cible type

Le Jetson Orin NX est la cible type : architecture Ampere gravée en 5 nm chez TSMC, 16 Go de LPDDR5, mémoire normalisée par le JEDEC, à environ 102 Go/s. Selon NVIDIA, le module atteint jusqu'à 100 TOPS en INT8 (mode sparse) dans une enveloppe de 10 à 25 W, et jusqu'à 157 TOPS avec le mode Super de JetPack 6.2, qui réclame un refroidissement actif capable d'évacuer 40 W.

Pour une équipe qui doit livrer un démonstrateur d'inférence en quelques semaines, cet écosystème raccourcit massivement le time-to-market. On part d'un modèle PyTorch ou ONNX, on l'optimise avec TensorRT, et on tourne sur cible sans réécrire les noyaux de calcul. C'est précisément ce qui a fait de CUDA le standard de facto du déploiement d'IA industrielle embarquée, malgré son caractère fermé.

OpenCL en bref : le standard ouvert et hétérogène

OpenCL (Open Computing Language) est un standard ouvert, maintenu par le Khronos Group, qui décrit un modèle de calcul parallèle portable sur un parc matériel hétérogène : GPU de toutes marques, CPU multicoeur, FPGA et certains DSP. Un même noyau OpenCL peut, en théorie, s'exécuter sur un GPU AMD, un GPU Mali de SoC ou un FPGA Xilinx, sans réécriture du code de calcul.

L'argument central d'OpenCL est l'indépendance fournisseur. Là où CUDA vous lie à NVIDIA, OpenCL cible le silicium que vous voulez, ce qui en fait l'option naturelle dès que le projet ne tourne pas sur Jetson. Dans nos projets RF et conception de cartes FPGA, l'accélération de traitement du signal passe historiquement par OpenCL ou par la synthèse haut niveau (HLS) sur Xilinx, pas par CUDA. De même, un produit basé sur un SoC à GPU Mali ou Adreno exploitera l'accélération via OpenCL ou Vulkan, jamais via CUDA. Un Raspberry Pi, par exemple, expose son GPU VideoCore par des chemins OpenCL et Vulkan, et reste fermé à CUDA.

Le revers : plus de code d'infrastructure

Le revers est connu : OpenCL demande davantage de code d'infrastructure (sélection de plateforme, création de contexte, file de commandes, compilation des noyaux à l'exécution) et son écosystème de bibliothèques IA prêtes à l'emploi reste très en retrait de celui de CUDA. La portabilité du code source ne garantit pas la portabilité des performances : un noyau réglé pour un GPU donné demande souvent un nouveau réglage sur un autre. C'est le compromis fondateur, une liberté matérielle payée par un effort d'ingénierie supérieur.

CUDA contre OpenCL : la comparaison qui compte

La comparaison utile ne porte pas sur la syntaxe des noyaux, qui se ressemble beaucoup, mais sur l'écosystème, la pérennité et le coût d'intégration. Le tableau ci-dessous résume les sept critères que nous pondérons systématiquement en phase de spécification, avant d'écrire la moindre ligne de code de calcul.

Le tableau oppose deux logiques. CUDA l'emporte sur les bibliothèques IA (cuDNN, TensorRT, cuBLAS), sur l'outillage de profilage Nsight et sur la courbe d'apprentissage, mais il ne cible que les GPU NVIDIA et impose un verrouillage fort sur dix ans. OpenCL, standard ouvert Khronos, vise des GPU multi-marques, des CPU, des FPGA et des DSP, avec une seconde source ouverte, au prix de bibliothèques fragmentées et d'un code hôte plus verbeux.

Au niveau du noyau de calcul lui-même, les deux modèles sont proches, comme le montre cet additionneur de vecteurs. La différence ne se joue pas là, mais dans le code hôte : une dizaine de lignes côté CUDA pour lancer le noyau, contre cinquante à quatre-vingts lignes côté OpenCL pour sélectionner la plateforme, créer le contexte, la file de commandes, compiler le programme et gérer les tampons.

// Noyau CUDA
__global__ void add(const float* a, const float* b, float* c, int n) {
  int i = blockIdx.x * blockDim.x + threadIdx.x;
  if (i < n) c[i] = a[i] + b[i];
}
// Noyau OpenCL equivalent
__kernel void add(__global const float* a, __global const float* b,
__global float* c, const int n) {
int i = get_global_id(0);
if (i < n) c[i] = a[i] + b[i];
}

L'état réel en 2026 : OpenCL a stagné, SYCL a pris le relais

L'état du paysage en 2026 est le contexte que tout arbitrage honnête doit intégrer : OpenCL n'a plus la dynamique de la décennie précédente, et plusieurs technologies se sont partagées ses cas d'usage. Réduire la décision à un duel CUDA contre OpenCL revient à raisonner avec une carte d'il y a dix ans, alors que le terrain a profondément changé.

OpenCL reste vivant mais figé. Selon Khronos, la version 3.0 a rendu optionnelles la plupart des fonctionnalités introduites en 2.x : un aveu tacite de fragmentation, qui ramène le socle commun garanti au niveau d'OpenCL 1.2. En parallèle, SYCL s'est imposé comme l'héritier moderne. SYCL 2020 s'est découplé d'OpenCL et peut désormais cibler CUDA, HIP et Vulkan comme back-ends, tout en restant du C++ standard pur, conforme à la norme ISO/IEC 14882. L'implémentation oneAPI d'Intel (DPC++) et l'implémentation libre AdaptiveCpp, hébergée sur GitHub, en sont les deux porte-drapeaux, avec une trajectoire de convergence annoncée jusqu'en 2027.

Une gouvernance recomposée : UXL Foundation, ROCm et Vulkan

La gouvernance s'est elle aussi recomposée. La UXL Foundation, hébergée par la Linux Foundation, pilote désormais l'évolution de oneAPI et a signé un accord de liaison avec le Khronos Group pour rapprocher les deux écosystèmes ouverts. Selon AMD, la pile ROCm et son interface HIP offrent un chemin de portage quasi automatique depuis CUDA, et AdaptiveCpp s'appuie sur HIP pour viser à la fois ROCm et CUDA. Enfin, Vulkan compute est devenu une voie de calcul GPU portable crédible sur mobile et embarqué, là où OpenCL n'est pas disponible.

Pour l'inférence pure, un troisième acteur change la donne : les moteurs d'exécution spécialisés. TensorRT chez NVIDIA, TVM en open source, ou les compilateurs ONNX Runtime abstraient le framework de bas niveau. Sur Jetson, on ne code presque jamais du CUDA à la main pour de l'inférence : on passe par TensorRT, qui génère les noyaux optimisés. Et lorsque la charge ne tient pas sur GPU, des accélérateurs dédiés comme Google Coral, bâti sur un Tensor Processing Unit (TPU), Intel Movidius Myriad ou Hailo prennent le relais via leur propre SDK, souvent couplé à TensorFlow Lite. La vraie question de 2026 n'est donc pas tant CUDA ou OpenCL que celle-ci : framework propriétaire intégré contre pile ouverte portable, à quel horizon de maintenance.

Verrouillage NVIDIA contre standard ouvert : l'arbitrage à dix ans

Le verrouillage fournisseur (vendor lock-in) désigne la dépendance technique et commerciale d'un produit à un seul fournisseur de silicium, dont on ne peut plus sortir sans réécrire une part substantielle du logiciel. Choisir CUDA, c'est accepter ce verrouillage en échange d'un écosystème supérieur ; choisir une pile ouverte, c'est payer un surcoût d'ingénierie pour préserver une seconde source.

Sur un produit grand public à durée de vie courte, le verrouillage CUDA est rarement un problème : la performance et le time-to-market priment, et le produit aura été renouvelé avant que la dépendance ne coûte cher. Sur un équipement industriel ou médical pensé pour dix à quinze ans de série, le calcul change. Une rupture d'approvisionnement, un changement de politique tarifaire NVIDIA, ou une obsolescence de module peuvent forcer un changement de plateforme, et tout le code CUDA, cuDNN et TensorRT devra alors être réécrit.

La seconde source, du processeur au framework

Cette logique de seconde source est celle que nous appliquons au choix de l'application processor, détaillée dans notre méthode pour arbitrer SoC, SoM et custom, et dans notre stratégie face aux pénuries de composants.

À l'inverse, une architecture bâtie sur SYCL ou OpenCL conserve un chemin de repli. Le code de calcul, écrit en standard ouvert, peut viser un autre GPU ou un FPGA moyennant un effort de reprofilage, sans réécriture complète. Cette résilience a un coût immédiat (moins de bibliothèques prêtes, plus de code d'infrastructure) mais protège le programme sur la durée. L'arbitrage se résume à une question de pondération : combien vaut la portabilité future face à la productivité présente, sur l'horizon de vie réel du produit.

Retour terrain : Jetson Orin NX et le coût assumé du verrouillage CUDA

Au premier trimestre 2026, sur un projet client industriel sous accord de confidentialité, nous avons livré un projet sur module Jetson Orin NX avec une couche Board Support Package (BSP) entièrement personnalisée, développée sous Yocto plutôt que Buildroot, sur une base noyau Linux LTS suivie sur kernel.org (layers custom, configuration kernel, device tree, rootfs). Le choix du Jetson engageait mécaniquement toute la pile CUDA et TensorRT : c'est le compromis que nous avons documenté et assumé avec le client.

Sur un Orin NX en boîtier industriel, la vraie contrainte n'est souvent pas le nombre de TOPS, mais le budget thermique. Malgré la tentation de viser le mode Super à 40 W pour afficher 157 TOPS, nous recommandons de figer l'enveloppe de puissance d'abord, puis de quantifier le modèle avec TensorRT en INT8, ce qui réduit d'environ 75% l'empreinte mémoire face au format flottant 32 bits IEEE 754 et aide à faire entrer le réseau dans ce budget.

Quand le verrouillage CUDA reste acceptable

Comme pour le portage de distributions Linux embarqué et la conception produit industriel, le verrouillage CUDA est acceptable quand la roadmap reste NVIDIA sur dix ans, et risqué dès qu'une seconde source non-NVIDIA est exigée : c'est en phase de spécification qu'une pile SYCL mérite d'être évaluée face à CUDA.

Notre grille de décision : quel framework pour quel projet

La grille de décision est l'arbre de questions filtres qui transforme les contraintes projet en choix de framework défendable. Elle part toujours du silicium ciblé, puis affine selon la nature de la charge (inférence pure ou calcul générique) et selon l'horizon de portabilité exigé par la durée de vie produit.

Première question : le produit tourne-t-il sur silicium NVIDIA Jetson ? Si oui, et que la charge est de l'inférence, la réponse est TensorRT sur CUDA, sans hésitation, car aucun écosystème embarqué n'égale sa maturité. Si la cible est un GPU de SoC (Mali, Adreno), un FPGA ou un CPU multicoeur, la voie ouverte s'impose : OpenCL pour l'existant, SYCL pour le neuf, car SYCL offre un C++ moderne tout en gardant un back-end OpenCL. Si la charge est exclusivement de l'inférence de réseaux de neurones sur un NPU dédié (Hailo, ethos-U, NXP), ni CUDA ni OpenCL ne s'appliquent : c'est le SDK du fondeur qui prime.

Deuxième filtre : l'horizon de portabilité

Deuxième filtre, l'horizon de portabilité. Même sur Jetson, si le cahier des charges exige une seconde source non-NVIDIA à dix ans, nous recommandons d'isoler la logique métier de la couche d'accélération dès la conception, et d'évaluer SYCL comme couche d'abstraction. Ce découplage ne coûte pas cher s'il est pensé en amont, et il coûte très cher s'il est ajouté après. La grille complète tient en quatre questions, comme le montre l'arbre ci-dessous.

En résumé

Le choix CUDA contre OpenCL est en réalité une conséquence du silicium retenu, et un arbitrage entre productivité immédiate et portabilité à dix ans. CUDA gagne sur Jetson et sur l'écosystème ; la pile ouverte gagne dès que la seconde source ou un parc hétérogène entrent en jeu. La décision se prend en phase de spécification, pas après le routage.

• Silicium d'abord : le processeur ciblé détermine l'API ; Jetson impose CUDA, un GPU de SoC ou un FPGA imposent OpenCL ou SYCL, un NPU impose le SDK du fondeur.
• Écosystème : CUDA domine grâce à cuDNN et TensorRT ; OpenCL reste fragmenté et figé sur sa version 3.0.
• 2026 : SYCL 2020 et oneAPI sous la UXL Foundation sont les héritiers portables, avec ROCm/HIP et Vulkan compute en compléments.
• Verrouillage : CUDA lie le produit à NVIDIA pour dix ans ; acceptable sur produit court, risqué sur équipement industriel longue vie.
• Méthode AESTECHNO : figer l'enveloppe de puissance, qualifier le silicium sur banc, puis découpler la couche d'accélération si une seconde source est exigée.

Questions fréquentes

CUDA est-il toujours plus rapide qu'OpenCL en 2026 ?

Sur silicium NVIDIA, CUDA est généralement plus performant à effort égal, car les bibliothèques cuDNN et TensorRT sont réglées au plus près de l'architecture Ampere des Jetson Orin. OpenCL peut atteindre des performances comparables sur le même GPU, mais demande un effort d'optimisation supérieur et un écosystème de bibliothèques moins fourni. Hors NVIDIA, la comparaison n'a pas de sens : CUDA n'existe pas, et OpenCL ou SYCL sont les seules options portables disponibles.

Faut-il encore apprendre OpenCL ou directement SYCL ?

Pour un projet neuf qui vise la portabilité, SYCL 2020 est le meilleur point d'entrée : c'est du C++ standard moderne, il cible CUDA, HIP, OpenCL et Vulkan en back-end, et il bénéficie de l'élan de la UXL Foundation et d'Intel oneAPI. OpenCL reste pertinent pour maintenir une base de code existante ou cibler un FPGA dont le flot HLS s'appuie dessus. Apprendre SYCL donne accès à OpenCL par-dessous, l'inverse n'est pas vrai.

Sur un Jetson Orin NX, code-t-on vraiment en CUDA à la main ?

Rarement pour de l'inférence. Le flux habituel part d'un modèle PyTorch ou ONNX, que l'on optimise et quantifie avec TensorRT ; ce dernier génère les noyaux CUDA optimisés sans écriture manuelle. On écrit du CUDA à la main pour du pré-traitement ou du post-traitement spécifique (traitement d'image, opérateurs custom non couverts par TensorRT). Le module Orin NX 16 Go offre jusqu'à 100 TOPS INT8 dans une enveloppe de 10 à 25 W, ce qui couvre la plupart des charges de vision embarquée.

OpenCL est-il en train de mourir ?

OpenCL n'est pas mort, mais il est figé. La version 3.0 a rendu optionnelles la plupart des fonctionnalités de la branche 2.x, ramenant le socle garanti à OpenCL 1.2. Le Khronos Group concentre désormais son énergie sur SYCL, qui s'est découplé d'OpenCL tout en pouvant l'utiliser comme back-end. Pour un nouveau développement, mieux vaut viser SYCL ; pour maintenir l'existant ou cibler certains FPGA, OpenCL reste utile et supporté.

Comment éviter le verrouillage CUDA sur un produit longue vie ?

En découplant la logique métier de la couche d'accélération dès la conception, et en évaluant SYCL comme couche d'abstraction au-dessus de CUDA. Cette architecture permet de basculer plus tard vers un GPU AMD via ROCm/HIP ou vers un autre silicium sans réécrire toute l'application. Le surcoût est faible s'il est pensé en amont, élevé s'il est ajouté après. C'est la même logique de seconde source que nous appliquons au choix de l'application processor sur nos projets industriels.

Articles connexes

• Processeurs NVIDIA Jetson pour l'IA embarquée : la plateforme qui engage la pile CUDA.
• Déploiement d'IA industrielle embarquée : du modèle entraîné à la cible en production.
• Conception de cartes FPGA : la voie OpenCL et HLS pour le traitement du signal.
• SoC, SoM, SBC ou custom : la décision d'architecture matérielle qui précède le choix du framework.
• Pénurie de semi-conducteurs : pourquoi la seconde source structure le choix de silicium.