FPGA vs GPU pour les charges de travail IA

Le comparatif FPGA vs GPU est l'un des plus singuliers dans le domaine du matériel pour l'IA.

Tous deux peuvent accélérer les réseaux de neurones.

Tous deux peuvent être installés sur des cartes PCIe.

Tous deux peuvent effectuer d'énormes quantités de calculs parallèles.

Mais ils parviennent à ce résultat par des voies fondamentalement différentes.

Un GPU vous fournit une architecture de processeur et vous permet de programmer ce qui s'y exécute.

Un FPGA vous fournit une logique programmable et vous permet de configurer une partie de l'architecture matérielle elle-même.

Cette différence compte bien plus qu'un chiffre de TOPS.

Un GPU est généralement plus simple à utiliser lorsque les modèles changent, que les frameworks sont importants, que l'entraînement est impliqué ou que vous avez besoin de grandes quantités de mémoire et de calcul parallèle généraliste.

Un FPGA devient intéressant lorsque la charge de travail est suffisamment stable pour que vous puissiez transformer son calcul en un pipeline matériel soigneusement conçu, surtout lorsque la latence, le transfert de données, une précision numérique inhabituelle, la consommation électrique, l'intégration de capteurs ou un comportement déterministe sont essentiels.

Aucun des deux n'est universellement plus rapide.

La vraie question est :

Votre charge de travail IA bénéficie-t-elle davantage d'un logiciel programmable s'exécutant sur un processeur parallèle généraliste, ou d'un matériel configuré autour de la charge de travail elle-même ?

FPGA vs GPU en un coup d'œil

‍

‍

Une implémentation FPGA mal conçue peut être moins performante qu'un GPU.

Un GPU mal utilisé peut être moins performant qu'un FPGA soigneusement conçu.

La charge de travail et l'implémentation déterminent le résultat.

Qu'est-ce qu'un GPU ?

Un processeur graphique est un processeur hautement parallèle.

Son architecture matérielle est gravée dans la puce. Les développeurs écrivent ensuite des logiciels qui mappent les calculs sur cette architecture.

Le modèle de programmation CUDA actuel de NVIDIA décrit les GPU comme des processeurs conçus pour exécuter des milliers de threads en parallèle, sacrifiant une partie des performances par thread au profit d'un débit global bien supérieur.

Cette architecture fonctionne bien pour les opérations pouvant être divisées en un grand nombre de calculs similaires.

Les réseaux de neurones modernes en contiennent une multitude.

C'est pourquoi les GPU sont devenus essentiels pour :

• l'entraînement au deep learning ;
• l'inférence de LLM ;
• la génération d'images ;
• la vision par ordinateur ;
• le calcul scientifique ;
• le rendu ;
• la simulation ;
• d'autres charges de travail hautement parallèles.

La structure interne du GPU reste identique lorsque vous passez d'une application à une autre.

C'est le logiciel qui change.

Qu'est-ce qu'un FPGA ?

FPGA signifie « field-programmable gate array » (réseau de portes programmables in situ).

Un FPGA contient des blocs logiques programmables, des interconnexions, des ressources mémoire, des ressources de traitement du signal numérique et d'autres composants qui peuvent être configurés après la fabrication de la puce.

Au lieu de simplement indiquer à des cœurs de processeur fixes quelles instructions exécuter, une conception FPGA permet de créer un chemin de données matériel personnalisé.

La documentation actuelle de Vitis HLS d'AMD exprime clairement la distinction : contrairement à un processeur exécutant un programme, un FPGA peut être configuré en un circuit matériel personnalisé qui réagit à ses entrées comme le ferait un matériel dédié.

Cette configuration matérielle est généralement représentée par un flux binaire (bitstream) chargé sur le FPGA.

Modifiez le flux binaire et vous pouvez changer le fonctionnement de la logique programmable.

La puce physique reste la même.

La conception matérielle implémentée change.

La différence fondamentale réside dans la programmabilité logicielle par rapport à la reconfiguration matérielle

C'est la distinction qu'il faut retenir.

Sur un GPU, vous demandez généralement :

Comment puis-je adapter cet algorithme au processeur ?

Sur un FPGA, vous pouvez demander :

En quel pipeline matériel cet algorithme doit-il se transformer ?

Cela confère au FPGA une liberté inhabituelle.

Supposons qu'une application d'IA doive :

1. réception des données de la caméra ;
2. conversion du format de pixel ;
3. redimensionnement de l'image ;
4. exécution d'un réseau de neurones ;
5. filtrage des détections ;
6. encodage du résultat ;
7. envoi via une interface personnalisée.

Un GPU peut effectuer une grande partie de ce travail.

Un concepteur FPGA peut potentiellement intégrer plusieurs étapes dans un pipeline matériel en flux continu, où les données passent directement d'une opération à la suivante.

Aucun ordonnanceur d'instructions général n'a besoin de coordonner chaque étape de la même manière.

Aucun résultat intermédiaire ne doit nécessairement transiter par la mémoire conventionnelle entre chaque opération.

Cela peut s'avérer très efficace lorsque le flux de travail est connu à l'avance.

Les GPU sont flexibles au niveau logiciel

Le GPU emprunte une autre voie.

Vous conservez l'architecture du processeur et modifiez le logiciel.

Un développeur PyTorch peut remplacer un modèle par un autre sans concevoir de nouveau circuit.

Un développeur CUDA peut lancer un noyau différent.

Une équipe dédiée à l'inférence peut passer d'un moteur de service à un autre.

Le même matériel peut exécuter :

• un modèle Llama le matin ;
• génération d'images l'après-midi ;
• un rendu Blender pendant la nuit ;
• une simulation le lendemain.

Cette flexibilité est l'une des raisons pour lesquelles les GPU restent si utiles, même lorsqu'un processeur plus spécialisé pourrait les surpasser sur une opération précise.

Nous avons exploré ce même modèle dans notre guide des accélérateurs d'IA: la spécialisation peut améliorer l'efficacité, mais la flexibilité devient précieuse lorsque les charges de travail évoluent.

Les FPGA se situent entre les GPU et les ASIC d'une manière significative

Un modèle mental utile est :

GPU → FPGA → ASIC

à mesure que l'on se dirige vers du matériel de plus en plus spécifique à une charge de travail.

Ce n'est pas une taxonomie stricte, mais elle illustre un compromis important.

GPU

L'architecture matérielle est fixe.

Vous modifiez le logiciel rapidement.

FPGA

Les ressources programmables de la puce sont fixes, mais vous pouvez les reconfigurer en différentes conceptions matérielles après la fabrication.

Modifier l'implémentation est possible, mais le processus de développement est beaucoup plus lourd que la simple recompilation d'un logiciel classique.

ASIC

La conception matérielle est figée lors de la fabrication de la puce.

Un ASIC peut être optimisé en profondeur pour une charge de travail spécifique, mais modifier le matériel implique généralement la conception d'une nouvelle puce.

Le FPGA offre donc un avantage inhabituel :

une spécialisation au niveau matériel sans engagement définitif envers une architecture fixe.

Cela s'avère précieux lorsque la charge de travail est stable aujourd'hui, mais susceptible d'évoluer au cours du cycle de vie du produit.

Reconfigurable ne signifie pas facile à modifier

Ce point est étonnamment souvent oublié.

Un FPGA est plus reconfigurable qu'un ASIC.

Un GPU est généralement plus simple à reprogrammer.

Modifier la charge de travail d'un GPU peut impliquer de modifier du code Python ou C++, de recompiler un noyau ou de charger un autre modèle.

Modifier la conception d'un FPGA peut impliquer :

• la modification de la logique matérielle ;
• la synthèse de la conception ;
• le placement et le routage de la logique ;
• la vérification des contraintes temporelles ;
• la vérification des interfaces ;
• la génération d'un nouveau flux binaire (bitstream) ;
• le test du résultat sur le matériel.

Les outils modernes allègent cette charge, mais ils ne suppriment pas la complexité matérielle sous-jacente.

La solution actuelle d'AMD Vitis HLS permet de synthétiser des fonctions C ou C++ en matériel RTL, réduisant ainsi la nécessité d'écrire chaque conception directement en Verilog ou VHDL. La conception générée devient tout de même une logique matérielle qui doit être implémentée dans la structure du FPGA.

Il s'agit d'un cycle de développement beaucoup plus lourd que la modification d'un modèle PyTorch sur un GPU.

Pourquoi utiliser un FPGA pour l'IA ?

Ce travail supplémentaire doit apporter une valeur ajoutée.

Plusieurs caractéristiques peuvent le justifier.

Flux de données personnalisé

Vous pouvez construire le matériel autour de la séquence exacte d'opérations que l'application exécute.

Parallélisme de pipeline

Différentes étapes de traitement peuvent fonctionner simultanément sur différentes données.

Latence prévisible

Un pipeline matériel dédié permet d'éviter une partie de la variabilité de planification présente dans les systèmes informatiques plus généraux.

Précision numérique personnalisée

Le matériel peut être conçu avec des largeurs numériques adaptées à l'application plutôt que de se limiter aux formats imposés par une architecture GPU fixe.

Intégration directe des E/S

Les FPGA peuvent se connecter étroitement aux caméras, capteurs, réseaux, bus industriels et autres interfaces.

Reconfiguration

Contrairement à un ASIC, la conception matérielle peut être mise à jour après le déploiement.

Ces points forts expliquent pourquoi les FPGA sont utilisés depuis longtemps dans les réseaux, les télécommunications, les systèmes industriels, le trading financier, le traitement du signal et d'autres applications où les chemins de données et la latence sont critiques.

L'IA peut devenir une étape supplémentaire dans ces pipelines.

Les systèmes d'IA sur FPGA actuels sont de plus en plus hétérogènes

Il devient difficile de qualifier le matériel d'IA moderne basé sur les FPGA de simple « FPGA ».

Les SoC adaptatifs Versal actuels d'AMD peuvent combiner :

• une logique programmable ;
• des cœurs de processeur ;
• des matrices de moteurs d'IA dédiés ;
• de la mémoire et des entrées/sorties ;
• de la propriété intellectuelle d'accélération.

Vitis AI 6.2 est une plateforme de développement d'inférence IA spécifiquement conçue pour les SoC adaptatifs AMD, comprenant un compilateur, un environnement d'exécution, des outils de quantification et une propriété intellectuelle de NPU pouvant fonctionner parallèlement à la logique programmable.

Cela crée une subtilité taxonomique importante.

Un NPU peut être implémenté au sein d'un FPGA ou d'un système de calcul adaptatif.

Par conséquent, demander « FPGA ou NPU ? » ne désigne pas toujours des matériels mutuellement exclusifs.

Les catégories d'accélérateurs d'IA se chevauchent, car les fournisseurs combinent de plus en plus plusieurs approches au sein d'un même système.

FPGA contre GPU pour l'inférence IA

L'inférence est le domaine où l'IA sur FPGA présente l'argument pratique le plus solide.

Une fois qu'un modèle est entraîné, ses calculs deviennent plus prévisibles.

Si le modèle reste stable, les ingénieurs peuvent optimiser le pipeline matériel autour de :

• couches connues ;
• formes de tenseurs connues ;
• précision numérique sélectionnée ;
• flux d'entrée connus ;
• exigences de latence fixes.

C'est particulièrement intéressant lorsque l'IA n'est qu'une partie d'un pipeline temps réel plus vaste.

Un système vidéo peut avoir besoin de :

capturer → décoder → redimensionner → inférer → filtrer → transmettre

en continu.

Un FPGA peut potentiellement intégrer une grande partie de ce pipeline directement dans le matériel.

Un GPU peut certainement accélérer l'étape du réseau de neurones, et peut-être d'autres étapes également, mais les données peuvent transiter par un système de calcul et de mémoire plus généraliste.

L'approche la plus performante dépend entièrement de l'implémentation.

L'inférence sur GPU est plus simple lorsque les modèles évoluent fréquemment

Imaginez maintenant que le modèle change tous les mois.

Aujourd'hui, c'est YOLO.

Le mois prochain, ce sera un détecteur basé sur les transformers.

Puis un modèle vision-langage remplacera les deux.

L'équipe FPGA devra peut-être reconcevoir, compiler, valider et optimiser son implémentation matérielle à maintes reprises.

L'équipe GPU charge simplement un autre modèle pris en charge.

C'est toute la différence entre adaptabilité matérielle et agilité logicielle.

Les FPGA sont adaptables.

Les GPU sont souvent plus agiles.

Pour l'IA en production où les architectures de modèles évoluent rapidement, l'agilité peut s'avérer plus précieuse qu'une optimisation au niveau matériel.

C'est pourquoi accélérateurs d'IA spécialisés vs GPU pour l'inférence devient essentiellement une question économique dès lors que les deux systèmes peuvent exécuter le modèle.

FPGA vs GPU pour l'entraînement en IA

Pour l'entraînement en deep learning classique, les GPU constituent généralement le choix le plus pratique.

L'entraînement nécessite :

• calcul direct ;
• rétropropagation ;
• gradients ;
• mises à jour de l'optimiseur ;
• une grande capacité mémoire ;
• des graphes de calcul dynamiques ;
• une intégration aux frameworks ;
• exécution distribuée ;
• débogage et profilage approfondis.

Les écosystèmes GPU sont construits autour de ces exigences depuis des années.

CUDA prend en charge un parallélisme massif au niveau des threads, tandis que des frameworks comme PyTorch peuvent envoyer des opérations de modèle vers des noyaux GPU sans que les développeurs aient besoin de concevoir des circuits matériels.

L'entraînement sur FPGA est techniquement possible et demeure un domaine de recherche et d'ingénierie spécialisée.

Il est beaucoup moins courant en tant que plateforme d'entraînement généraliste.

La pile actuelle AMD Vitis AI est elle-même positionnée principalement autour de l'inférence IA sur des SoC adaptatifs et du matériel lié aux FPGA plutôt que comme un environnement d'entraînement grand public.

Pour la plupart des équipes se demandant quel matériel utiliser pour le développement de modèles, le GPU est le point de départ le plus sûr.

Notre guide sur le matériel d'entraînement vs inférence explique pourquoi ces deux étapes imposent des exigences si différentes.

FPGA vs GPU pour la vision par ordinateur

La vision par ordinateur est l'un des cas d'usage les plus naturels pour l'IA sur FPGA.

Les données de caméra sont intrinsèquement un flux.

Les pixels arrivent dans un ordre prévisible.

Plusieurs opérations peuvent potentiellement former un pipeline :

• acquisition d'image ;
• dématriçage ;
• conversion de couleur ;
• redimensionnement ;
• filtrage ;
• extraction de caractéristiques ;
• inférence par réseau de neurones ;
• filtrage de détection ;
• encodage de sortie.

Un FPGA peut gérer certaines de ces étapes sans avoir à renvoyer systématiquement les données intermédiaires vers un processeur généraliste.

Cela s'avère particulièrement utile dans la vision embarquée, la robotique, l'inspection industrielle et d'autres systèmes où la caméra et le matériel d'inférence partagent une même plateforme physique.

Un GPU devient intéressant lorsque :

• les modèles changent fréquemment ;
• plusieurs modèles volumineux fonctionnent simultanément ;
• les charges de travail nécessitent une mémoire importante ;
• d'autres calculs GPU sont requis ;
• la vitesse de développement est primordiale ;
• le système utilise déjà des frameworks orientés GPU.

Il n'existe pas de solution universelle en vision par ordinateur.

FPGA vs GPU pour l'IA en périphérie (Edge AI)

Le déploiement en périphérie est un autre domaine de prédilection pour les FPGA.

Un système physique fixe peut nécessiter :

• latence faible et prévisible ;
• puissance limitée ;
• interfaces de capteurs inhabituelles ;
• plusieurs flux d'entrée ;
• années de déploiement ;
• fonctionnement hors ligne.

C'est précisément dans ce type d'environnement qu'il peut être judicieux de concevoir un pipeline personnalisé.

Un FPGA peut être placé directement entre les capteurs et le reste de l'ordinateur, traiter les données dès leur arrivée et accélérer certaines opérations sans nécessiter un GPU généraliste imposant.

L'inconvénient est l'engagement.

Une fois qu'un parc a été conçu autour d'une plateforme FPGA et d'une pile logicielle spécifiques, modifier la charge de travail IA peut nécessiter un travail d'ingénierie considérable.

Un GPU embarqué sacrifie une partie de la spécialisation matérielle au profit d'un environnement de modèles plus large.

Notre guide du matériel d'IA en périphérie aborde ce compromis sous l'angle du déploiement.

FPGA vs GPU pour l'inférence LLM

C'est là que le GPU dispose actuellement de l'argument généraliste le plus convaincant.

Les grands modèles de langage nécessitent :

• une mémoire modèle importante ;
• une bande passante mémoire élevée ;
• des opérations matricielles efficaces ;
• mémoire KV-cache croissante ;
• prise en charge de l'évolution rapide des architectures de modèles ;
• noyaux d'attention optimisés ;
• quantification ;
• logiciel de déploiement ;
• traitement par lots et concurrence.

Le logiciel GPU a évolué rapidement pour répondre à ces besoins.

Les implémentations FPGA peuvent tirer parti d'une précision personnalisée et de pipelines spécialisés, et des travaux actifs sont en cours concernant l'accélération des transformeurs et des LLM sur du matériel reconfigurable.

Mais un système LLM utile doit résoudre bien plus qu'une simple multiplication de matrices.

Le modèle complet doit tenir en mémoire ou être partitionné.

L'attention doit fonctionner.

La mémoire KV-cache doit être gérée.

Les nouvelles architectures nécessitent un support logiciel ou matériel.

Le déploiement doit être mis à l'échelle.

Pour la plupart des équipes expérimentant avec les LLM, la charge de développement liée à un FPGA l'emporte sur ses avantages potentiels en matière de spécialisation.

L'équation pourrait changer pour une charge de travail d'inférence importante et fixe, où les ingénieurs peuvent justifier la conception de matériel autour d'une famille de modèles spécifique.

C'est le même schéma que celui observé dans Accélérateurs IA vs GPU pour l'inférence.

Architecture mémoire FPGA vs GPU

La mémoire peut modifier le résultat avant même que la puissance de calcul n'entre en jeu.

Un GPU discret fournit généralement une mémoire d'accélération dédiée rattachée à une hiérarchie mémoire fixe.

Les GPU haut de gamme modernes offrent une VRAM importante et une bande passante élevée, ce qui les rend adaptés aux grands réseaux de neurones.

Les cartes FPGA sont beaucoup plus variées.

Un système peut inclure :

• de la mémoire bloc sur puce ;
• de l'UltraRAM ou une mémoire intégrée équivalente ;
• de la DDR externe ;
• de la HBM sur certaines plateformes d'accélération ;
• de la mémoire hôte accessible via PCIe.

L'avantage du FPGA réside dans la possibilité de concevoir le chemin de données en fonction de la manière dont les informations circulent à travers ces ressources.

La contrainte est la capacité.

Les grands réseaux de neurones ne peuvent pas tenir entièrement dans de petites mémoires sur puce.

La conception peut nécessiter le streaming des poids ou des activations depuis une mémoire externe, et la bande passante devient alors un facteur limitant, tout comme sur les GPU.

L'idée selon laquelle « les FPGA évitent le goulot d'étranglement de la mémoire » est donc trop générale.

Ils peuvent réduire les transferts de mémoire inutiles au sein d'un pipeline bien conçu.

Ils ne peuvent pas faire disparaître de grandes quantités de données de modèle.

C'est au niveau du transfert de données que les FPGA deviennent intéressants

Un système informatique général suit souvent un schéma tel que :

chargement → calcul → écriture → chargement → calcul → écriture

entre les étapes de traitement.

Un chemin de données FPGA personnalisé peut parfois maintenir un flux de données direct d'une opération à la suivante.

Imaginez :

caméra → filtre → redimensionnement → inférence → seuillage → paquet réseau

implémenté sous forme d'étapes de streaming connectées.

Chaque étape peut commencer à travailler avant que l'étape précédente n'ait fini de traiter l'image entière.

Cela permet de réduire la mise en mémoire tampon et d'obtenir une latence de pipeline faible et prévisible.

C'est l'une des raisons fondamentales pour lesquelles les FPGA restent précieux, même lorsque les GPU affichent des capacités de calcul théoriques bien supérieures.

Parfois, l'objectif d'optimisation n'est pas de :

effectuer plus d'opérations arithmétiques

mais de :

déplacer moins de données et éviter une planification inutile.

Les GPU l'emportent lorsque la densité arithmétique est le problème principal

D'autres charges de travail sont très différentes.

Supposons que vous deviez multiplier d'énormes tenseurs dans un grand modèle sans exigences d'E/S particulières.

Cette charge de travail correspond naturellement au matériel GPU.

Le GPU dispose de :

• grandes capacités de calcul parallèle ;
• matériel optimisé pour les matrices ;
• une bande passante mémoire élevée ;
• bibliothèques de noyau matures ;
• intégration poussée avec les frameworks d'IA.

La conception d'un pipeline FPGA personnalisé peut représenter une charge d'ingénierie considérable sans pour autant résoudre un problème que le GPU gère déjà efficacement.

L'architecture doit s'adapter au goulot d'étranglement.

La précision numérique des FPGA peut être d'une flexibilité inhabituelle

L'un des avantages techniques les plus intéressants du FPGA est le contrôle sur la représentation des données.

Un processeur fixe impose les formats numériques implémentés par ses concepteurs matériels.

Cela peut inclure :

• FP32 ;
• BF16 ;
• FP16 ;
• FP8 ;
• INT8 ;
• INT4 ;
• FP4 ;
• d'autres formats spécifiques aux fournisseurs.

Une conception FPGA permet de créer des opérations arithmétiques basées sur des largeurs de bits personnalisées lorsque l'application le permet.

Peut-être qu'un pipeline d'inférence particulier fonctionne bien avec :

• des valeurs sur 7 bits ;
• des valeurs sur 5 bits ;
• représentations en virgule fixe inhabituelles ;
• largeurs mixtes entre les couches.

Le matériel peut potentiellement être conçu autour de ces exigences précises.

Cela permet de réduire l'utilisation des ressources et les transferts de données.

La contrepartie est l'effort d'ingénierie nécessaire.

Les utilisateurs de GPU choisissent généralement parmi des formats optimisés déjà pris en charge par le matériel et les bibliothèques.

Les équipes travaillant sur FPGA peuvent bénéficier d'un contrôle plus fin, tout en assumant la responsabilité de sa mise en œuvre.

La quantification peut favoriser les deux architectures de manières différentes

La quantification aide aussi les GPU.

Les GPU modernes intègrent du matériel dédié aux calculs d'IA en basse précision, et les moteurs d'inférence optimisés peuvent exploiter les formats INT8, INT4, FP8, FP4 et d'autres formats pris en charge.

La différence réside dans le choix.

Un GPU propose un ensemble prédéfini de chemins numériques rapides.

Un FPGA offre au concepteur une plus grande liberté pour en créer un.

Cela signifie qu'une précision personnalisée ne rend pas automatiquement le FPGA meilleur.

Si un GPU dispose déjà d'un noyau optimisé pour le format dont votre modèle a besoin, l'utiliser peut s'avérer bien plus simple.

Consultez notre guide de quantification LLM pour comprendre pourquoi une précision plus faible affecte simultanément la mémoire, la bande passante, la qualité et les exigences matérielles.

Latence FPGA vs GPU

Une affirmation courante est la suivante :

FPGA pour la latence, GPU pour le débit.

Il y a une part de vérité là-dedans.

C'est toutefois trop simpliste.

Les FPGA peuvent être excellents pour les pipelines de streaming à faible latence, car les étapes de traitement peuvent être implémentées sous forme de matériel dédié avec un flux de données prévisible.

AMD commercialise actuellement du matériel d'accélération Alveo spécifiquement pour les applications déterministes à faible latence, comme les systèmes financiers, ce qui montre qu'il s'agit toujours d'un cas d'usage central pour les FPGA et le calcul adaptatif.

Les GPU peuvent également atteindre une faible latence.

Le résultat dépend de :

• la taille de la charge de travail ;
• la surcharge liée au lancement du noyau ;
• le traitement par lots ;
• le transfert de mémoire ;
• la pile logicielle ;
• l'utilisation du GPU ;
• la planification ;
• l'application environnante.

Pour un grand réseau de neurones, les ressources de calcul optimisées bien plus importantes du GPU peuvent surpasser tout avantage lié au pipeline.

Pour une petite charge de travail en streaming avec un chemin critique à la microseconde, le FPGA peut s'avérer bien plus naturel.

Évaluez l'application de bout en bout.

Débit FPGA vs GPU

Les GPU excellent souvent lorsqu'il y a suffisamment de travail parallèle pour occuper leurs ressources de calcul.

Regroupez plusieurs entrées et le GPU pourra appliquer les mêmes noyaux à de nombreux exemples.

Cela rend les GPU particulièrement efficaces pour :

• les grands lots d'entraînement ;
• l'inférence par lots ;
• les opérations sur de grandes matrices ;
• le déploiement de modèles à haut volume.

Un FPGA peut également atteindre un débit élevé en utilisant le pipelining, permettant ainsi à de nouvelles entrées d'être traitées avant que les précédentes n'aient parcouru l'intégralité du pipeline.

Les mécanismes diffèrent.

Le débit d'un GPU provient souvent du parallélisme massif des données.

Le débit d'un FPGA peut provenir du pipelining personnalisé profond et des chemins de données matériels parallèles.

La charge de travail détermine quelle solution est la plus adaptée.

La latence d'un FPGA peut être plus prévisible

La latence moyenne et la latence déterministe sont des exigences différentes.

Un système peut ne pas se soucier du fait qu'une inférence prenne 1,0 ms ou 1,2 ms.

Il peut en revanche être très sensible au fait qu'elle prenne occasionnellement 8 ms.

Les pipelines matériels peuvent offrir une exécution prévisible car le chemin de données et le calendrier sont largement intégrés à la conception.

Cela rend les FPGA attrayants pour les applications où le timing est un élément essentiel de la précision.

En voici quelques exemples :

• le contrôle industriel ;
• la mise en réseau ;
• les télécommunications ;
• les systèmes financiers ;
• certaines applications robotiques ;
• le traitement de données de capteurs.

La plupart des applications d'IA sur le Web n'ont pas des exigences de timing aussi strictes.

Pour elles, la programmabilité des GPU peut s'avérer bien plus précieuse.

Efficacité énergétique : FPGA vs GPU

Une autre affirmation courante est que les FPGA sont plus économes en énergie que les GPU.

C'est possible.

Mais ne considérez pas cela comme une loi architecturale.

Un FPGA conçu pour une charge de travail spécifique et limitée peut éviter toute activité matérielle ou mémoire inutile.

Cela permet d'améliorer le rendement énergétique par tâche.

Un GPU exécutant une charge de travail parfaitement adaptée à son matériel matriciel dédié peut également être très efficace.

Un FPGA mal utilisé peut gaspiller des ressources.

Un GPU fortement sollicité peut terminer son travail si rapidement que sa consommation énergétique totale par tâche devient compétitive.

Mesurez :

joules par inférence

ou :

travail utile par watt selon la latence requise

plutôt que de comparer uniquement la puissance de la carte.

Le guide TOPS vs FLOPS explique pourquoi les spécifications de puissance et de calcul de crête doivent être associées à une charge de travail.

Le développement FPGA exige un état d'esprit différent

Le développement GPU peut devenir étonnamment accessible.

Un data scientist peut écrire du code PyTorch standard et laisser le framework envoyer les opérations sur tenseurs aux kernels GPU.

Le développeur n'a peut-être jamais besoin d'écrire du CUDA directement.

Le développement FPGA a traditionnellement nécessité une maîtrise des langages de description matérielle tels que :

• Verilog ;
• SystemVerilog ;
• VHDL.

La synthèse de haut niveau a rendu l'environnement plus accessible.

L'outil Vitis HLS actuel d'AMD peut synthétiser des fonctions C et C++ en RTL, et Vitis propose des flux de développement de plus haut niveau pour les FPGA et l'accélération par calcul adaptatif.

Mais les développeurs logiciels doivent toujours prendre en compte des concepts matériels :

• le pipelining ;
• le parallélisme ;
• interfaces mémoire ;
• timing ;
• utilisation des ressources ;
• domaines d'horloge ;
• largeurs de données ;
• latence.

Le C++ est le langage d'entrée.

Le résultat reste du matériel.

La compilation n'offre pas la même expérience

La compilation de logiciels GPU peut prendre quelques secondes ou quelques minutes.

La mise en œuvre d'une conception FPGA comprend la synthèse matérielle ainsi que le placement et le routage physiques.

Les outils doivent déterminer l'emplacement de la logique sur la puce et le cheminement des signaux tout en respectant les contraintes de timing.

Cela peut ralentir considérablement les itérations.

C'est un enjeu commercial important.

Supposons qu'une implémentation GPU coûte 10 % de plus à exploiter.

Si la version FPGA prend des mois de plus à concevoir et nécessite des ingénieurs spécialisés, les économies matérielles doivent permettre de rentabiliser ce coût de développement.

Un benchmark qui compare uniquement les watts ou les images par seconde ignore le poste de dépense le plus important.

L'ingénierie FPGA fait partie du coût du FPGA

C'est le thème récurrent du matériel spécialisé.

Le coût réel comprend :

matériel + logiciel + ingénierie + intégration + tests + maintenance

Un GPU peut coûter plus cher à l'unité tout en étant plus économique au final, car l'application est mise en production plus rapidement.

Un FPGA peut s'avérer nettement plus rentable lorsque :

• la charge de travail est stable ;
• le matériel est utilisé pendant des années ;
• le taux d'utilisation est élevé ;
• les volumes sont importants ;
• les exigences en matière de latence sont strictes ;
• l'intégration personnalisée apporte une réelle valeur ajoutée.

C'est pourquoi les FPGA conservent leur succès dans les systèmes spécialisés plutôt que de remplacer les GPU de manière générale.

Un FPGA peut réduire le nombre de puces distinctes

L'un des avantages moins évidents en périphérie est l'intégration.

Supposons qu'un système nécessite actuellement du matériel séparé pour :

• l'interface de capteur ;
• le traitement du signal ;
• la conversion de format ;
• l'inférence IA ;
• la gestion de protocoles personnalisés.

Un système adaptatif ou basé sur FPGA suffisamment performant peut regrouper plusieurs étapes au sein d'un seul composant.

Cela permet de réduire :

• complexité de la carte ;
• transfert de données ;
• latence ;
• nombre de composants.

Cet avantage au niveau du système peut s'avérer plus important que la simple performance d'un noyau de réseau neuronal face à un benchmark GPU.

C'est aussi pourquoi évaluer l'IA sur FPGA uniquement via le nombre d'« images par seconde » peut occulter le principal atout de cette architecture.

Les GPU peuvent consolider les charges de travail d'une autre manière

Les GPU consolident différemment.

Un seul GPU peut exécuter de nombreux types de logiciels.

Le même appareil peut gérer :

• plusieurs modèles d'IA ;
• le rendu ;
• le traitement vidéo ;
• la simulation ;
• le calcul personnalisé.

Ainsi, le FPGA peut consolider un pipeline matériel.

Le GPU peut consolider un ensemble de charges de travail logicielles.

Which kind of consolidation matters depends on the system you are building.

FPGA vs GPU for changing workloads

This is one of the easiest decisions.

If you genuinely do not know what the hardware will run next year, choose flexibility.

A GPU allows far quicker movement among model architectures and software stacks.

An FPGA can be reconfigured, but every new hardware implementation still needs design and validation.

Rapid AI model development therefore tends to favor GPUs.

Stable embedded products can favor FPGAs.

Time horizon matters.

FPGA vs GPU for fixed workloads

Now reverse the situation.

The model:

• is validated;
• will stay deployed for five years;
• receives a known input shape;
• uses known precision;
• has strict latency requirements;
• runs continuously.

This is the environment where FPGA optimization becomes much easier to justify.

The engineering cost is paid once.

The optimized hardware executes the workload repeatedly.

Specialization gets time to repay itself.

FPGA vs GPU vs NPU

The cluster now gives us three levels of specialization to compare.

‍

‍

An NPU may itself be implemented within an FPGA-based or adaptive-compute platform, so these categories can overlap.

The CPU vs GPU vs NPU guide covers the three processor classes most users encounter directly.

This FPGA comparison deals with a deeper hardware-design choice.

FPGA accelerator card vs GPU card

At the server level, both can appear as PCIe cards.

AMD Alveo is one example of an FPGA/adaptive-compute accelerator-card family. AMD's current Vitis development flow supports software running on an x86 host while kernels execute on FPGA hardware attached through PCIe.

A GPU card follows the same broad host-plus-accelerator layout but exposes a fixed GPU architecture instead of programmable logic.

That means buying a PCIe accelerator card tells you almost nothing about the processor inside.

Our AI accelerator card guide covers this distinction across FPGA, GPU, NPU, and ASIC hardware.

Can you rent an FPGA in the cloud?

Yes.

Cloud FPGA access exists, just as cloud GPU access does.

AWS currently lists EC2 F2 accelerated-computing instances containing Xilinx Virtex UltraScale+ FPGAs, including configurations with one, two, or eight FPGA accelerators.

This is useful because FPGA development no longer necessarily requires buying the target card before experimentation starts.

The economic problem remains different from GPU rental.

You still need an FPGA design.

Cloud access removes hardware ownership.

It does not remove hardware engineering.

Cloud GPU access solves a different problem

Renting a GPU gives you a familiar programmable compute environment without buying the GPU.

You can install:

• PyTorch;
• CUDA libraries;
• vLLM;
• model code;
• containers;
• custom kernels.

Then change them whenever the experiment changes.

That makes cloud GPUs useful at an earlier, less settled stage of AI development.

An FPGA becomes more compelling after enough of the problem has stopped changing to justify hardware design.

When an FPGA is the stronger starting point

Consider FPGA hardware seriously when several of these conditions apply:

• latency needs to be highly predictable;
• data arrives as a continuous stream;
• the system interfaces directly with sensors or networks;
• unusual I/O protocols matter;
• preprocessing and inference belong in one pipeline;
• custom numerical precision is valuable;
• the model is stable;
• the workload will run for years;
• edge power constraints matter;
• hardware reconfiguration is more valuable than model agility;
• you have FPGA engineering expertise.

Those conditions often appear together in embedded and industrial systems.

When a GPU is the stronger starting point

Choose a GPU first when:

• the model is changing;
• training is involved;
• you are comparing model families;
• large memory is required;
• you need PyTorch or CUDA-oriented tooling;
• custom GPU kernels already exist;
• several unrelated workloads share the hardware;
• rapid development matters;
• LLM serving is the primary problem;
• workloads are temporary or bursty;
• your team does not have FPGA engineering expertise.

This describes a large share of modern AI development.

FPGA vs GPU decision matrix

‍

‍

Several rows deliberately contain more than one answer.

That is where benchmarking begins.

How to benchmark FPGA vs GPU properly

Do not compare vendor peak numbers.

Build the same workload.

Use the same model

L'architecture doit rester identique dans la mesure du possible.

Maintenez une qualité constante

Si une implémentation utilise une quantification plus lourde, vérifiez que le modèle résultant atteint toujours l'objectif de précision fixé.

Incluez le prétraitement

L'avantage d'un FPGA peut en partie se situer en dehors du réseau de neurones.

Supprimer ces étapes du benchmark peut masquer la raison pour laquelle vous l'aviez envisagé au départ.

Incluez les transferts hôtes

Mesurez le coût du transfert de données entre le processeur, l'accélérateur et la mémoire.

Mesurez la latence de bout en bout

Ne rapportez pas uniquement la latence du noyau si l'application nécessite un temps de réponse complet.

Mesurez le débit

Utilisez des flux, des lots ou des taux de requête réalistes.

Mesurez la latence de queue

Les applications déterministes se soucient du comportement dans le pire des cas, pas seulement des moyennes.

Mesurez la consommation électrique

Utilisez l'énergie par charge de travail terminée dans la mesure du possible.

Incluez le coût de développement

Estimez l'ingénierie nécessaire pour construire et maintenir les deux implémentations.

Testez également le modèle suivant

Si la feuille de route du produit inclut déjà une autre architecture, identifiez les problèmes de migration avant de vous engager sur le matériel.

Évaluez les systèmes d'IA plutôt que les unités arithmétiques

La suite actuelle de benchmarks d'inférence de MLPerf mesure des systèmes matériels et logiciels complets exécutant des modèles définis dans des scénarios spécifiés, ce qui est une approche plus pertinente que la simple comparaison du débit théorique des puces.

Le même principe devrait guider les comparaisons de FPGA.

Un FPGA peut paraître extraordinaire sur un benchmark de noyau personnalisé.

Un GPU peut paraître extraordinaire sur une multiplication de grandes matrices.

Votre produit n'exécute aucun de ces benchmarks.

Il exécute votre produit.

Où se situe Hivenet dans le choix entre FPGA et GPU

Hivenet ne propose pas d'instances FPGA.

Cela signifie qu'il existe des charges de travail pour lesquelles l'infrastructure GPU de Hivenet n'est pas la solution adaptée.

Si vous développez un produit industriel sur cinq ans autour d'un pipeline de vision fixe avec des exigences d'E/S en temps réel strictes, un FPGA ou un SoC adaptatif peut réellement être plus judicieux.

Si vous êtes encore en phase de recherche sur le modèle à adopter, la situation change.

Calculez avec Hivenet fournit une infrastructure GPU et CPU programmable qui peut être modifiée en fonction de l'évolution de la charge de travail.

Cela le rend utile pour :

• le développement de modèles ;
• les expériences en IA ;
• le réglage fin ;
• les tests de quantification ;
• la vision par ordinateur ;
• Inférence LLM ;
• traitement par lots ;
• charges de travail qui n'ont pas encore nécessité de spécialisation matérielle.

La bibliothèque de benchmarks suit le même principe de priorité à la charge de travail appliqué à l'ensemble de ce cluster : testez le système que vous comptez réellement exploiter.

Si vous n'avez pas besoin de contrôler l'infrastructure, l' API d'inférence Hivenet remonte dans la pile technologique pour offrir à l'application un point de terminaison de modèle géré.

Ce sont des réponses différentes pour des niveaux de certitude différents.

Un parcours de développement logique consiste souvent à commencer par le GPU, puis à passer au FPGA

Rien n'oblige à ce que le premier choix matériel soit le dernier.

Une approche pragmatique peut ressembler à ceci :

1. Développer le modèle sur un GPU.
2. Vérifier la qualité.
3. Profiler la charge de travail.
4. Le quantifier et l'optimiser.
5. Établir les exigences de latence.
6. Identifier les goulots d'étranglement liés au prétraitement et au transfert de données.
7. Observer si le modèle se stabilise.
8. Déterminez si du matériel personnalisé apporterait un gain significatif.
9. Portez le pipeline mature sur du matériel FPGA si la rentabilité le justifie.

Cela permet au modèle d'évoluer avant que le matériel ne soit figé.

Si la version FPGA ne s'avère finalement pas rentable, vous aurez tout de même déployé une solution fonctionnelle sur GPU.

Si elle l'est, vous disposez désormais de mesures indiquant à l'équipe matérielle ce qu'il faut optimiser.

FAQ sur les FPGA et les GPU

Quelle est la principale différence entre un FPGA et un GPU ?

Un GPU possède une architecture de processeur parallèle fixe que les développeurs programment via des logiciels. Un FPGA contient une logique programmable qui peut être configurée en circuits matériels personnalisés après la fabrication.

Un FPGA est-il plus rapide qu'un GPU ?

Parfois, pour une charge de travail spécifique. Les FPGA excellent dans les pipelines de streaming personnalisés et le traitement déterministe à faible latence. Les GPU offrent un débit bien supérieur pour les charges de travail adaptées à leur architecture parallèle. Comparez l'application complète plutôt que la catégorie de processeur.

Un GPU est-il meilleur qu'un FPGA pour l'IA ?

Pour le développement général en IA, l'entraînement, les grands modèles de langage et les charges de travail changeantes, les GPU sont généralement plus simples et plus flexibles. Les FPGA peuvent être mieux adaptés aux pipelines d'inférence fixes nécessitant des entrées/sorties spécialisées, une précision personnalisée ou des contraintes de latence strictes.

Un FPGA peut-il exécuter de l'IA ?

Oui. Les FPGA peuvent implémenter des accélérateurs de réseaux neuronaux et des pipelines d'inférence complets. La plateforme Vitis AI actuelle d'AMD cible l'inférence IA sur les SoC adaptatifs et le matériel programmable associé.

Un FPGA peut-il entraîner des réseaux neuronaux ?

C'est techniquement possible, mais l'entraînement sur FPGA est beaucoup moins courant que sur GPU. Les outils et déploiements d'IA orientés FPGA privilégient généralement l'inférence, tandis que les GPU bénéficient d'un écosystème d'entraînement beaucoup plus vaste.

Un FPGA est-il adapté à l'inférence de LLM ?

Il peut être utilisé pour l'inférence de LLM, notamment dans le cadre de recherches personnalisées ou de déploiements spécialisés. Pour le développement et le service de LLM généralistes, les GPU offrent actuellement une meilleure prise en charge des modèles, des options de mémoire étendue et des logiciels de service matures.

Pourquoi les FPGA sont-ils efficaces pour la faible latence ?

Une charge de travail peut être implémentée sous forme de pipeline matériel personnalisé avec un flux de données prévisible, plutôt que d'être entièrement gérée par un processeur généraliste. Cela permet d'obtenir une latence faible et déterministe pour les charges de travail appropriées.

Les FPGA sont-ils plus économes en énergie que les GPU ?

Ils peuvent l'être pour des pipelines matériels étroitement adaptés à une charge de travail fixe. Il n'existe pas d'avantage universel. Mesurez l'énergie par tâche accomplie dans des conditions de latence et de qualité équivalentes.

Un FPGA est-il un accélérateur d'IA ?

Un FPGA peut devenir un accélérateur d'IA lorsque sa logique programmable est configurée pour accélérer les opérations d'apprentissage automatique. Les cartes FPGA constituent une catégorie couverte dans notre guide des cartes accélératrices d'IA.

Un FPGA est-il un NPU ?

Pas intrinsèquement. Un FPGA est un matériel reconfigurable. Un NPU est un matériel conçu autour du traitement des réseaux neuronaux. La fonctionnalité NPU peut être implémentée au sein d'un FPGA ou d'une plateforme de calcul adaptatif, les catégories peuvent donc se chevaucher.

Un FPGA est-il un ASIC ?

Non. Un ASIC possède une conception matérielle figée lors de sa fabrication. Un FPGA peut être reconfiguré après sa fabrication. Tous deux peuvent implémenter des chemins de données matériels spécialisés.

Un FPGA utilise-t-il CUDA ?

Non. CUDA est la plateforme de calcul GPU de NVIDIA. Le développement FPGA utilise différentes chaînes d'outils telles qu'AMD Vivado et Vitis, des langages de description matérielle, le HLS ou des frameworks spécifiques aux fournisseurs.

Peut-on programmer un FPGA en C++ ?

Oui, grâce à des outils de synthèse de haut niveau. AMD Vitis HLS, par exemple, peut synthétiser des fonctions C et C++ en RTL pour une implémentation dans la logique programmable du FPGA.

Le développement FPGA est-il plus difficile que le développement GPU ?

Généralement, oui. Les outils HLS modernes ont rendu le développement FPGA plus accessible, mais les développeurs doivent toujours prendre en compte l'architecture matérielle, le timing, les pipelines, les interfaces mémoire et l'utilisation des ressources. Le développement d'IA sur GPU via des frameworks peut souvent se faire sans conception matérielle directe.

Les FPGA sont-ils adaptés à l'IA en périphérie (edge AI) ?

Ils peuvent être excellents pour les systèmes en périphérie qui combinent l'inférence de réseaux neuronaux avec le traitement de capteurs, des entrées/sorties personnalisées, une faible latence et des charges de travail stables. Les GPU et les NPU peuvent être des choix plus simples lorsque la flexibilité du modèle est primordiale.

Dois-je acheter un FPGA ou louer un GPU ?

Basez votre décision sur la charge de travail. Un pipeline stable et pérenne avec des exigences spécialisées peut justifier le développement et l'acquisition d'un FPGA. La location de GPU est généralement plus simple pour l'expérimentation, l'entraînement, le calcul temporaire, les changements de modèles et les applications nécessitant un environnement logiciel étendu.

Les GPU et les FPGA optimisent différents types de liberté

La différence entre un FPGA et un GPU est plus profonde qu'une simple question de vitesse.

Un GPU offre aux développeurs une liberté logicielle.

Le matériel reste fixe, mais le même processeur peut exécuter une collection d'applications et de modèles en constante évolution.

Un FPGA offre aux ingénieurs une liberté matérielle.

La structure programmable peut devenir un pipeline personnalisé conçu autour de l'application elle-même.

Ces libertés ont des coûts différents.

Le logiciel GPU évolue rapidement.

La conception matérielle d'un FPGA peut prendre beaucoup plus de temps à construire et à vérifier.

Le GPU repose sur une architecture générale qui peut inclure des ressources dont votre charge de travail n'a pas besoin.

Le FPGA permet d'éliminer une partie de cette généralité pour créer exactement le chemin de traitement requis par la charge de travail.

La décision devient donc plus facile une fois que l'avenir de la charge de travail est plus clair.

Si le modèle est amené à changer, gardez une flexibilité matérielle grâce au logiciel.

Si le pipeline est stabilisé et que la latence, les entrées/sorties, le transfert de données, la consommation énergétique ou une précision personnalisée justifient une optimisation plus poussée, le FPGA mérite d'être sérieusement envisagé.

La spécialisation doit intervenir une fois que vous avez identifié ce qui mérite d'être spécialisé.

Ce principe s'applique désormais à l'ensemble du cluster.

Poursuivez avec NPU vs GPU pour les charges de travail IA, ce qu'est un NPU, le guide pratique des accélérateurs d'IA, CPU vs GPU vs NPU, accélérateurs d'IA vs GPU pour l'inférence, matériel d'IA en périphérie, TOPS vs FLOPS, matériel d'entraînement vs d'inférence, et le guide des cartes accélératrices d'IA.

‍