Skip to main content
PromptQuorum
Accueil/LLM locaux avancés/Silicium IA embarquée pour LLM locaux 2026 : ce qui tient vraiment dans un produit
Mobile & Edge LLMs

Silicium IA embarquée pour LLM locaux 2026 : ce qui tient vraiment dans un produit

·13 min de lecture·Par Hans Kuepper · Fondateur de PromptQuorum, outil de dispatch multi-modèle · PromptQuorum

Le déploiement d'un LLM embarqué optimise le joule par token face à un point de conception thermique, pas les tokens par seconde face à la VRAM. Un modèle 1,5B à 9,45 tok/s dans une enveloppe de 2,1 W sur silicium dédié est un résultat médiocre sur bureau et excellent en embarqué — la question est de savoir s'il tient dans la puissance restante du produit, pas s'il est rapide.

Spécifier le calcul d'un produit embarqué est un problème différent du choix d'un GPU de bureau. Un budget de puissance et un objectif de nomenclature remplacent les tokens par seconde comme critère décisif — et la configuration gagnante est souvent un petit modèle sur un NPU dédié, pas un plus grand modèle sur un GPU.

Silicium IA embarquée pour LLM locaux 2026 : ce qui tient vraiment dans un produit

Points clés

  • Le déploiement embarqué optimise le joule par token face à un point de conception thermique — pas les tokens par seconde face à la VRAM, la métrique de bureau.
  • Un modèle 1,5B à 9,45 tok/s pour 2,1 W (Hailo-10H, selon les données publiées par Hailo) est un excellent résultat en embarqué, alors qu'il serait médiocre sur bureau.
  • Quatre classes de matériel couvrent la plupart des produits : boîtier SBC + NPU, accélérateur dédié M.2, SoC embarqué intégré, module GPU embarqué — adaptées au budget de puissance, pas à la taille brute du modèle.
  • Le NVIDIA Jetson AGX Thor (T5000) délivre 2 070 TFLOPS FP4 sparse pour 40–130 W avec 128 Go de LPDDR5X à 273 Go/s, selon la fiche NVIDIA — le haut de gamme de la classe GPU embarquée.
  • La bande passante mémoire, pas la capacité mémoire, limite la vitesse de génération des tokens — une carte avec plus de DRAM à Go/s égal ne génère pas de tokens plus vite.
  • La plage de température industrielle et le cycle de vie de la puce doivent être confirmés avant le choix du modèle, pas après — une puce au cycle de vie de 3 ans ne peut pas équiper un produit garanti 10 ans.
  • De nombreuses chaînes d'outils NPU n'acceptent qu'un ensemble fixe de schémas de quantification, donc les contraintes du compilateur de la cible doivent orienter le plan de quantification, pas l'inverse.

Quelles sont les quatre classes de matériel IA embarquée ?

Quatre classes de matériel couvrent presque tous les déploiements de LLM embarqués, et choisir la mauvaise classe coûte plus de temps d'ingénierie que choisir le mauvais modèle. Chaque classe se situe à un point différent de la courbe puissance/flexibilité. Faire correspondre la classe au budget de puissance et à l'exigence de durée de vie du produit vient avant de comparer les puces individuelles au sein de cette classe.

📍 En une phrase

Le matériel IA embarquée se répartit en quatre classes — boîtier SBC + NPU, accélérateur M.2 dédié, SoC embarqué intégré et module GPU embarqué — adaptées au budget de puissance du produit plutôt qu'à la taille brute du modèle.

💬 En termes simples

Un boîtier SBC + NPU est bon marché et flexible mais chauffe dans un boîtier scellé. Un accélérateur M.2 dédié fait une seule tâche à très faible puissance. Un SoC intégré est un ordinateur complet sur une puce, dimensionné pour la robotique et les caméras. Un module GPU embarqué comprime une puissance de classe bureau dans un produit.

  • Boîtier SBC + NPU — un ordinateur monocarte polyvalent (classe Raspberry Pi 5) associé à une carte accélératrice NPU additionnelle. Coût de nomenclature le plus bas, pile logicielle la plus flexible, performance thermique soutenue la plus faible une fois scellé dans un boîtier sans flux d'air.
  • Module accélérateur dédié (M.2) — une puce d'inférence à fonction fixe comme le Hailo-10H, ajoutée à une carte porteuse existante via un connecteur M.2/PCIe. Exécute une seule tâche — l'inférence quantifiée — à très faible puissance ; ce n'est pas une plateforme de calcul générale et elle ne peut exécuter aucun système d'exploitation.
  • SoC embarqué intégré — une puce unique combinant CPU, GPU ou NPU et E/S sur un même die, dimensionnée pour une enveloppe de puissance donnée. La famille NVIDIA Jetson Orin (Orin Nano Super, Orin NX, AGX Orin) et le Rockchip RK3588 sont le choix par défaut pour les produits de robotique et de caméra en volume.
  • Module GPU embarqué — un GPU de classe discrète miniaturisé en module pour le haut de gamme du calcul embarqué, comme le NVIDIA Jetson AGX Thor (T5000). Utilisé quand le produit exige réellement un débit de classe bureau — perception multi-caméras, robotique humanoïde — dans un budget de puissance et thermique embarqué.

Quelles sont les trois contraintes ignorées par les guides matériel de bureau ?

Les guides LLM locaux de bureau optimisent la capacité VRAM et le pic de tokens par seconde ; les produits embarqués sont soumis à trois contraintes différentes qu'un benchmark de bureau n'a jamais à prendre en compte.

  • Point de conception thermique, pas spécification crête. Le TOPS annoncé sur une fiche technique suppose généralement un flux d'air que la plupart des boîtiers scellés et sans ventilateur n'ont pas. Ce qui compte, c'est le débit soutenu à 70 °C ambiants dans le boîtier réel — sous limitation thermique, le débit réel peut se situer bien en dessous du pic de la fiche technique.
  • La bande passante mémoire, pas la capacité mémoire, fixe la vitesse de génération. La génération de tokens (phase de décodage) est limitée par la bande passante : le débit de décodage est à peu près borné par la bande passante mémoire en Go/s divisée par les octets lus par token. Une carte avec plus de DRAM mais la même bande passante ne génère pas de tokens plus vite — c'est pourquoi l'empreinte de 1,2 Go et le cache KV de 2 048 tokens du Hailo-10H à 2,1 W en moyenne constituent un point de conception très différent de la marge VRAM d'un GPU de bureau.
  • Plage de température industrielle et cycle de vie de la puce, pas des tableaux de benchmark. Les SoC grand public sont couramment approvisionnés sur des cycles de conception de 2 à 3 ans. Un produit engagé sur une durée de vie de 10 ans a besoin d'une puce avec un engagement d'approvisionnement correspondant et une plage de fonctionnement étendue — une puce qui ne peut plus être approvisionnée en année quatre force une refonte matérielle à mi-vie, quelle que soit la qualité d'exécution du modèle cible au premier jour.

Comment spécifier le calcul embarqué pour un produit ?

Fixez le budget de puissance et l'exigence de durée de vie avant d'évaluer une puce précise. Les étapes ci-dessous suivent l'ordre qui évite la reprise la plus fréquente : choisir un modèle d'abord, puis découvrir qu'il ne tient pas dans le budget de puissance ou de cycle de vie.

  1. 1
    Définir d'abord le budget de puissance, pas le modèle
    Why it matters: Les produits embarqués ont une enveloppe thermique ou de puissance fixe — capacité de batterie, ligne PoE partagée, limite de refroidissement passif — et le modèle doit tenir dans ce qui reste après les capteurs, radios et actionneurs.
  2. 2
    Fixer un objectif de joules par token, pas de tokens par seconde
    Why it matters: Un chiffre de tokens/s sans contexte de puissance ne se compare pas d'une classe d'accélérateur à l'autre. Le joule par token est le chiffre qui détermine réellement l'autonomie de la batterie ou la marge thermique du produit fini.
  3. 3
    Séparer bande passante et capacité mémoire dans le cahier des charges
    Why it matters: La vitesse de génération est bornée par les Go/s vers les poids et le cache KV, pas par la quantité de DRAM sur la carte. Un tampon plus grand qui ne peut pas être lu assez vite n'augmente pas le débit de décodage.
  4. 4
    Confirmer la plage de température industrielle et le cycle de vie d'approvisionnement avant le modèle, pas après
    Why it matters: Une puce avec un engagement d'approvisionnement de 3 ans ne peut pas équiper un produit avec un engagement de service de 10 ans, quelle que soit la qualité d'exécution du modèle cible en laboratoire.
  5. 5
    Confirmer les schémas de quantification réellement acceptés par la chaîne d'outils NPU
    Why it matters: De nombreux compilateurs NPU embarqués ne supportent qu'un ensemble fixe de schémas de quantification des poids, activations et cache KV. Vérifiez cela auprès du compilateur avant de vous engager sur un modèle, pas après un échec de compilation.
  6. 6
    Restreindre les candidats via le sélecteur interactif ci-dessous, puis valider sur silicium réel
    Why it matters: Un filtre puissance / taille de modèle / vidéo / plage de température restreint le champ à une liste courte en quelques minutes. Seules des mesures sur l'accélérateur réel, dans le boîtier réel, confirment les joules par token pour votre produit.

Trouver le matériel embarqué adapté à votre produit

C'est le moyen le plus rapide de transformer un budget de puissance et une taille de modèle cible en une liste courte. Réglez l'enveloppe de puissance, la taille du modèle en milliards de paramètres, et si le produit a besoin d'ingestion vidéo ou d'une plage de température industrielle — le tableau ci-dessous indique alors quelles classes de plateforme méritent d'être benchmarkées ensuite.

Platforms that fit

PlatformPowerFits up toNote
NVIDIA Jetson Orin Nano Super725 W8BEntry dev kit; natural upgrade from a Raspberry Pi
NVIDIA Jetson Orin NX1040 W13BMid-tier module, up to 157 TOPS
NVIDIA Jetson AGX Orin 64GB1560 W34B275 TOPS; current volume robotics workhorse

Comment les puces IA embarquées se comparent-elles en puissance et calcul ?

Spécifications documentées par les fabricants pour les plateformes citées dans ce guide, vérifiées auprès de la documentation constructeur primaire au 02/09/2026. Les valeurs marquées « rapportées » proviennent de sources secondaires plutôt que d'une fiche technique constructeur primaire et sont présentées avec cette réserve — à confirmer auprès de votre propre contact fournisseur.

Plateforme
Classe
Calcul IA crête
Puissance (TDP)
Mémoire / BP
Jetson AGX Thor (T5000)Module GPU embarqué2 070 TFLOPS FP4 sparse40–130 W128 Go LPDDR5X, 273 Go/s
Jetson AGX Orin 64GBSoC embarqué intégré275 TOPS15–60 W64 Go LPDDR5
Jetson Orin NXSoC embarqué intégré~157 TOPS (rapporté)10–40 W8/16 Go LPDDR5
Jetson Orin Nano SuperSoC embarqué intégré~67 TOPS (rapporté)7–25 W8 Go LPDDR5
Hailo-10HAccélérateur dédié (M.2)Inférence à fonction fixe< 5 W (format M.2)1,2 Go empreinte (mesurée)
Rockchip RK3588SBC + NPU6 TOPS (NPU 3 cœurs)Niveau carte, quelques WPartagée avec le SBC hôte
Ambarella série NSoC vision intégréNon communiquéNon communiquéLancement CES 2026, multi-capteurs + IA générative
Qualcomm série QRBSoC embarqué intégréSelon plateformeSelon plateformeDominant dans les drones — voir article associé

Le Jetson AGX Thor dispose aussi d'un port QSFP 4×25GbE et prend en charge jusqu'à 32 caméras MIPI CSI-2 ; NVIDIA annonce jusqu'à 7,5 fois le calcul IA et 3,5 fois l'efficacité énergétique par rapport au Jetson AGX Orin. Ces deux chiffres proviennent de la comparaison de NVIDIA elle-même, pas d'un benchmark indépendant réalisé pour cet article.

À quoi ressemble vraiment un modèle 1,5B sur silicium dédié ?

Hailo a publié un résultat mesuré pour Qwen2-1.5B-Instruct sur le Hailo-10H qui illustre toute la thèse de ce guide : 9,45 tokens par seconde à 2,1 W en moyenne. Selon les critères de bureau, 9,45 tok/s pour un modèle 1,5B n'a rien d'exceptionnel. Selon les critères embarqués — un module M.2 sous 5 W consommant à peine plus que la veille d'un chargeur de téléphone — c'est la différence entre un produit qui tient sur une petite batterie et un autre qui a besoin d'un boîtier plus grand et d'un ventilateur.

Les chiffres ci-dessous sont les données de benchmark publiées par Hailo lui-même, pas une mesure indépendante réalisée pour cet article — à citer comme documentées par le fournisseur dans un cahier des charges.

Mesure
Valeur
ModèleQwen2-1.5B-Instruct
Débit9,45 tok/s
TTFT (96 tokens en entrée)289 ms
Puissance moyenne2,1 W
Empreinte mémoire1,2 Go
Cache KV2 048 tokens (~1 536 mots)
Quantification des poids4 bits symétrique, par groupe
Quantification des activations8 bits asymétrique, par tenseur
Quantification du cache KV8 bits asymétrique, par tenseur
Support runtime / OSHailoRT — Linux, Windows, Android

HailoRT est disponible sous Linux, Windows et Android, et le module lui-même a un format M.2 sous 5 W — le point de comparaison pertinent pour un produit contraint en batterie ou en PoE, pas un classement de tokens/s de bureau.

Comment quantifier un modèle pour une cible NPU embarquée ?

Les chaînes d'outils NPU embarquées acceptent généralement un ensemble fixe et réduit de schémas de quantification par rapport à une pile d'inférence de bureau ; le compilateur de la cible doit donc déterminer le plan de quantification, pas l'inverse. Confirmez le schéma accepté avant de choisir un modèle, pas après un échec de compilation.

La quantification statique fixe à l'avance l'échelle et le point zéro des poids et activations à partir d'un jeu de calibration — c'est ce qu'exigent la plupart des compilateurs NPU à fonction fixe, car cela évite au chip le coût d'exécution du calcul des paramètres de quantification à la volée. La quantification dynamique calcule ces paramètres au moment de l'inférence et est plus flexible, mais peu de compilateurs NPU embarqués la supportent, car elle ajoute une latence que le pipeline à fonction fixe est justement conçu pour éviter.

La quantification des activations par tenseur (un seul facteur d'échelle pour tout un tenseur d'activation, comme dans la configuration Qwen2-1,5B publiée par Hailo en 8 bits asymétrique) est le défaut embarqué courant : elle coûte moins cher à appliquer pour le NPU qu'un schéma par canal, pour une perte de précision modeste généralement acceptable pour les prompts courts et spécifiques à une tâche typiques d'un produit embarqué.

Un cache KV quantifié — 8 bits asymétrique par tenseur dans l'exemple Hailo-10H ci-dessus — réduit la mémoire que l'accélérateur doit conserver et relire pour chaque token généré, ce qui relève directement le plafond de tokens/s décrit dans la contrainte de bande passante mémoire ci-dessus. Voir comment fonctionne la quantification des LLM et ce que chaque format change réellement pour la mécanique sous-jacente de la quantification des poids, activations et cache KV, commune aux cibles de bureau et embarquées.

Que faut-il acheter pour prototyper un produit IA embarquée ?

Prototypez sur un kit de développement de la même classe matérielle que celle visée pour la production, pas sur un boîtier GPU de bureau — le comportement thermique et de puissance de la classe de production est précisément ce qu'un banc de bureau ne peut pas vous montrer.

  • Kits de développement NVIDIA Jetson — le moyen standard de prototyper les classes SoC embarqué intégré et module GPU embarqué avant de s'engager sur une carte porteuse de production. Vérifiez la disponibilité et les prix actuels directement auprès de NVIDIA ou d'un distributeur agréé ; les références et prix précis changent trop souvent pour être indiqués ici de façon fiable.
  • Modules accélérateurs Hailo M.2 — le moyen standard de prototyper la classe accélérateur dédié sur une carte porteuse existante disposant déjà d'un connecteur M.2/PCIe libre. Vérifiez la disponibilité actuelle directement auprès de Hailo ou d'un distributeur agréé.
  • Raspberry Pi AI HAT+ — le moyen standard de prototyper à moindre coût la classe boîtier SBC + NPU avant de décider si le produit a réellement besoin d'une classe de calcul supérieure. Vérifiez les prix et la disponibilité actuels directement auprès de Raspberry Pi ou d'un revendeur agréé.
  • Cartes porteuses et boîtiers industriels — nécessaires dès qu'un prototype passe du banc de laboratoire vers la plage de température étendue et la tenue aux vibrations qu'exige un produit en production ; à spécifier auprès d'un fournisseur embarqué industriel, pas d'une carte porteuse grand public, dès que le calendrier produit l'exige.

Quand l'inférence embarquée est-elle un mauvais choix ?

L'inférence embarquée est le mauvais choix par défaut dans trois situations produit courantes — la forcer quand même coûte généralement plus de temps d'ingénierie qu'elle n'en économise en latence ou en confidentialité.

  • Charges de travail sporadiques avec de longues périodes d'inactivité. Si le produit n'a besoin d'inférence qu'occasionnellement et dispose d'une connectivité fiable le reste du temps, le budget fixe de puissance et de nomenclature d'un silicium embarqué dédié est dépensé à maintenir une capacité rarement utilisée — un appel cloud pendant la fenêtre active est généralement plus économique sur la durée de vie du produit.
  • Tâches exigeant réellement un raisonnement de pointe. Un modèle assez petit pour tenir dans un budget de puissance embarqué n'égalera pas un grand modèle hébergé sur un raisonnement ouvert, une planification à plusieurs étapes ou des connaissances générales étendues — le silicium embarqué est le bon choix pour une tâche étroite et bien spécifiée, pas pour un assistant généraliste.
  • Produits avec connectivité fiable et sans contrainte de confidentialité ou de latence. Si rien dans le produit n'exige que les données restent sur l'appareil et que rien n'exige une réponse sous 100 ms sans aller-retour réseau, l'argument en faveur du budget de puissance et de coût du silicium embarqué s'affaiblit nettement — vérifiez que la contrainte est réelle avant de concevoir autour d'elle.

Quelle réglementation s'applique aux machines pilotées par IA en 2026 ?

Le règlement européen sur les machines (2023/1230), applicable à partir de janvier 2027, classe les fonctions de sécurité pilotées par IA dans les machines comme à haut risque — ce qui recoupe directement l'AI Act européen pour tout produit embarqué où une sortie de LLM ou de VLM peut affecter une fonction de sécurité physique. Ceci est une information générale, pas un conseil juridique ; confirmez l'applicabilité à un produit précis auprès d'un conseil réglementaire qualifié avant toute mise sur le marché.

Le déclencheur pratique est étroit mais important : si un résultat d'inférence embarquée (une classification d'objet, une décision de planification, une alerte d'analyse vidéo) alimente une fonction de commande liée à la sécurité d'une machine, les exigences essentielles de santé et de sécurité du règlement machines et la classification à haut risque de l'AI Act peuvent s'appliquer conjointement. Un produit qui n'utilise l'inférence embarquée que pour une fonction non liée à la sécurité (une interface vocale, un tableau de bord analytique) se situe hors de ce recoupement précis, bien que d'autres obligations de l'AI Act puissent encore s'appliquer selon le cas d'usage.

C'est une dimension de conformité qu'un guide LLM local de bureau n'a jamais à traiter, car une application de bureau n'est, par définition, pas une machine dotée d'une fonction de sécurité. L'intégrer tôt dans le cahier des charges matériel — plutôt que de l'ajouter après coup à une conception déjà figée — est la leçon pratique pour les produits concernés.

La CNIL recommande par ailleurs le recours à l'IA locale lors du traitement de données professionnelles sensibles (financières, médicales, juridiques), ce qui renforce l'intérêt du silicium embarqué au-delà du seul angle sécurité-machine pour les produits traitant ce type de données.

Questions fréquemment posées

Quelle est la différence essentielle entre le choix matériel pour LLM de bureau et embarqué ?

Le choix de bureau optimise les tokens par seconde face à la VRAM disponible. Le choix embarqué optimise les joules par token face à un point de conception thermique et un budget de puissance fixes — le modèle doit tenir dans la puissance restante du produit, pas l'inverse.

Un petit modèle sur un NPU dédié est-il vraiment meilleur qu'un plus grand sur un GPU ?

Pour un budget de puissance fixe, souvent oui. Un modèle 1,5B à 9,45 tok/s pour 2,1 W sur le Hailo-10H, selon le benchmark publié par Hailo, est un résultat médiocre sur bureau et excellent en embarqué — la comparaison n'a de sens qu'une fois la contrainte de puissance fixée.

Qu'est-ce qu'un point de conception thermique et pourquoi compte-t-il pour les LLM embarqués ?

C'est la condition de fonctionnement soutenue — typiquement la température ambiante dans un boîtier scellé, souvent sans ventilateur — à laquelle une puce doit délivrer sa performance annoncée, par opposition au pic de fiche technique mesuré avec un flux d'air que la plupart des produits n'ont pas. Le débit réel sous limitation thermique peut être bien inférieur à ce pic.

Pourquoi la bande passante mémoire compte-t-elle plus que la capacité mémoire pour la génération de tokens ?

La génération de tokens est limitée par la bande passante : la vitesse de décodage est à peu près bornée par la bande passante mémoire en Go/s divisée par les octets lus par token. Une carte avec plus de DRAM à Go/s égal ne génère pas de tokens plus vite — c'est la bande passante, pas la capacité, qui fixe le plafond.

Qu'est-ce qu'une plage de température industrielle et pourquoi compte-t-elle pour le cycle de vie du produit ?

C'est une plage de fonctionnement étendue (bien au-delà des 0–40 °C habituels du grand public) pour laquelle une puce est qualifiée et approvisionnée sur un engagement pluriannuel. Une puce grand public, couramment approvisionnée sur un cycle de 2 à 3 ans, ne peut pas équiper un produit garanti 10 ans sans forcer une refonte matérielle à mi-vie.

Quelle puissance consomme le Hailo-10H en exécutant un petit LLM ?

Selon les données publiées par Hailo, le Hailo-10H consomme en moyenne 2,1 W en exécutant Qwen2-1.5B-Instruct à 9,45 tok/s, avec une empreinte mémoire de 1,2 Go et un cache KV de 2 048 tokens, dans un format M.2 sous 5 W.

Quel calcul délivre le NVIDIA Jetson AGX Thor ?

Selon la fiche technique NVIDIA, le Jetson AGX Thor (T5000) délivre 2 070 TFLOPS FP4 sparse (1 035 TFLOPS FP4 dense, 517 TFLOPS FP8 dense) pour 40–130 W, avec 128 Go de mémoire LPDDR5X à 273 Go/s sur un bus 256 bits.

Faut-il quantifier les poids, les activations ou le cache KV pour un NPU embarqué ?

Généralement les trois, dans le schéma accepté par le compilateur du NPU cible. La quantification statique des activations par tenseur et un cache KV quantifié sont les défauts embarqués courants, car la plupart des chaînes d'outils NPU à fonction fixe ne supportent qu'un ensemble limité et fixe de schémas — confirmez le schéma accepté avant de choisir un modèle.

Quand ne faut-il pas du tout utiliser l'inférence embarquée ?

Évitez l'inférence embarquée pour les charges sporadiques et peu fréquentes avec connectivité fiable, pour les tâches exigeant réellement un raisonnement de pointe au-delà de ce qu'un modèle de taille embarquée peut délivrer, et pour les produits sans réelle contrainte de confidentialité ou de latence imposant que les données restent sur l'appareil.

Comment commencer à spécifier le calcul embarqué pour un nouveau produit ?

Définissez le budget de puissance et la durée de vie requise avant d'évaluer une puce précise, fixez un objectif de joules par token plutôt que de tokens par seconde, confirmez la bande passante mémoire et la plage de température industrielle par rapport aux contraintes du produit, puis utilisez le sélecteur interactif de cette page pour restreindre les candidats avant de benchmarker du silicium réel.

← Retour aux LLM locaux avancés