Silicon

HBM

Mémoire à haute bande passante, empilée au plus près du die GPU. C'est elle (et non les FLOPS) qui fixe le plafond de débit en génération LLM.

Approfondir : HBM et NVLink →
NVLink

Interconnexion propriétaire NVIDIA reliant plusieurs GPU à très haute bande passante. Dès qu'un modèle déborde un GPU, NVLink devient un prolongement de la mémoire.

Approfondir : HBM et NVLink →
Bande passante mémoire

Le débit auquel un GPU lit sa mémoire. En inférence autorégressive, c'est le facteur limitant : chaque token relit l'intégralité des poids et du KV cache.

Approfondir : HBM et NVLink →
Tensor Core

Unités de calcul matriciel spécialisées des GPU NVIDIA. Leur génération détermine les formats numériques pris en charge, et donc le débit réellement accessible.

Approfondir : H100 vs B100 →
FP8

Format à virgule flottante sur 8 bits. Format de travail polyvalent de l'inférence et de l'entraînement, pris en charge de Hopper à Blackwell.

Approfondir : FP8, FP6, FP4 →
FP4 (MXFP4 / NVFP4)

Format à virgule flottante sur 4 bits, frontière 2026 de l'inférence à haut débit. Les variantes à blocs partagent une échelle par groupe de valeurs.

Approfondir : FP8, FP6, FP4 →
Blackwell

Architecture GPU NVIDIA succédant à Hopper. Apporte le FP4 natif, davantage de mémoire HBM3e et un moteur Transformer de 2ᵉ génération.

Approfondir : H100 vs B100 →
Hopper

Architecture GPU NVIDIA de la génération H100 / H200 (2022-2024). Introduit le Transformer Engine et le FP8.

Approfondir : H100 vs B100 →
HBM3e

Variante haute fréquence de HBM3 qu'on retrouve sur H200 et B200. Même organisation, bande passante par stack supérieure (~5 TB/s).

Approfondir : HBM et NVLink →
CoWoS

Packaging avancé de TSMC qui empile HBM et die GPU sur un substrat silicium. Capacité de production réservée jusqu'à mi-2027, goulot physique de toute l'industrie.

Approfondir : MI355X vs B200 →
SM

Streaming Multiprocessor : unité de calcul d'un GPU NVIDIA. Contient des CUDA cores, des Tensor cores et de la mémoire partagée locale.

Approfondir : H100 vs B100 →
VRAM

Vidéo-RAM, la mémoire embarquée du GPU. Sa capacité (24, 80, 192 Go) détermine quel modèle peut tenir sur une carte donnée.

Approfondir : RTX 5090 vs H100 →
GDDR7

Mémoire grand public des GPU consumer 2025+ (RTX 5090 : 32 Go GDDR7). Beaucoup moins chère que HBM par Go, mais plus lente.

Approfondir : RTX 5090 vs H100 →
TFLOPS

Mille milliards d'opérations flottantes par seconde. À comparer prudemment : un TFLOPS « pic » (sparsité ou format optimisé) n'est jamais le débit soutenu.

Approfondir : H100 vs B100 →
Sparsité 2:4

Schéma où 2 valeurs sur 4 dans une matrice sont nulles, exploitable par les Tensor cores pour doubler le TFLOPS sur le papier. Très peu de charges d'inférence en profitent réellement.

Approfondir : H100 vs B100 →
Transformer Engine

Bibliothèque NVIDIA qui choisit dynamiquement le format numérique (FP8, FP16) couche par couche, selon la sensibilité du calcul.

Approfondir : FP8, FP6, FP4 →
NVSwitch

Commutateur NVLink qui permet à 8 GPU (ou plus) de partager leur mémoire à pleine bande passante. Cœur des nœuds DGX et HGX.

Approfondir : HBM et NVLink →
BF16

BFloat16 : 16 bits avec 8 bits d'exposant comme FP32. Domaine numérique plus large que FP16, précision moindre, quasi-standard de l'entraînement moderne.

Approfondir : FP8, FP6, FP4 →
CUDA

Plateforme propriétaire NVIDIA pour le calcul GPU. Verrou écosystémique principal de NVIDIA, plus important encore que l'avance silicium.

Approfondir : CUDA vs ROCm →
ROCm

Pile logicielle GPU d'AMD, équivalent fonctionnel de CUDA. Couvre PyTorch, vLLM, llama.cpp en parité fonctionnelle depuis ROCm 7+.

Approfondir : CUDA vs ROCm →

Runtimes

KV cache

La mémoire de l'historique d'un LLM : un vecteur clé et un vecteur valeur par token déjà vu, à chaque couche. Croît linéairement avec le contexte et le batch.

Approfondir : KV cache →
PagedAttention

Gestion du KV cache par blocs de taille fixe, comme la mémoire virtuelle d'un système d'exploitation. Élimine la fragmentation ; introduite par vLLM.

Approfondir : KV cache →
Prefix caching

Réutilisation du KV cache d'un préfixe commun (system prompt, exemples few-shot) au lieu de le recalculer à chaque requête.

Approfondir : KV cache →
Quantification (GGUF)

Réduction du nombre de bits par poids pour faire tenir un modèle en mémoire. En local, Q4_K_M reste le compromis de référence entre taille et qualité.

Approfondir : llama.cpp et GGUF →
Batching continu

Ordonnancement à l'itération qui ajoute et retire des requêtes du batch en continu, au lieu d'attendre qu'un batch entier se termine. Cœur du débit de vLLM.

Approfondir : vLLM vs llama.cpp vs TensorRT-LLM →
Prefill / Decode

Les deux phases d'une requête LLM : le prefill traite le prompt d'un coup (intensif en calcul), le decode génère token par token (limité par la mémoire).

Approfondir : HBM et NVLink →
vLLM

Runtime d'inférence haute performance issu de Berkeley. Standard du débit serveur grâce à PagedAttention et au batching continu.

Approfondir : vLLM vs llama.cpp vs TensorRT-LLM →
llama.cpp

Runtime C++ portable pour l'inférence locale. Format GGUF, quantification fine, mmap : conçu pour faire tourner un LLM sur un laptop.

Approfondir : llama.cpp et GGUF →
TensorRT-LLM

Runtime NVIDIA optimisé pour Hopper et Blackwell. Performance maximale sur ces silicons, au prix de la portabilité.

Approfondir : vLLM vs llama.cpp vs TensorRT-LLM →
GGUF

Format de fichier de llama.cpp pour les modèles quantifiés. Conçu pour le mmap : un seul fichier, immédiatement prêt à servir.

Approfondir : llama.cpp et GGUF →
MoE

Mixture of Experts : architecture où un sous-ensemble seulement des paramètres est activé par token. Mixtral 8x7B, DeepSeek-V3.

Approfondir : vLLM vs llama.cpp vs TensorRT-LLM →
Tensor parallelism

Découpe une matrice de poids sur plusieurs GPU qui calculent en parallèle puis fusionnent. Réduit la latence d'une seule requête.

Approfondir : HBM et NVLink →
Pipeline parallelism

Place différentes couches du modèle sur différents GPU. Réduit la mémoire par GPU mais introduit une bulle de pipeline.

Approfondir : HBM et NVLink →
Speculative decoding

Un petit modèle de brouillon propose plusieurs tokens à l'avance ; le grand modèle les vérifie en parallèle. Gain de latence sans perte de qualité.

Approfondir : vLLM vs llama.cpp vs TensorRT-LLM →
Flash Attention

Implémentation fusionnée de l'attention qui évite de matérialiser la matrice intermédiaire en HBM. Sans perte de précision, gain de mémoire et de vitesse.

Approfondir : KV cache →
Chunked prefill

Découpe la phase de prefill d'un long prompt en morceaux qui s'entrelacent avec le decode d'autres requêtes. Améliore le débit serveur.

Approfondir : vLLM vs llama.cpp vs TensorRT-LLM →

Edge AI

NPU

Circuit dédié à l'inférence de réseaux de neurones. Très efficace en énergie sur les opérateurs câblés, rigide en dehors de ce périmètre.

Approfondir : NPU vs GPU à l’edge →
Mémoire unifiée

Architecture où CPU et GPU partagent la même RAM physique, courante en embarqué (Jetson). Évite les copies, mais impose une enveloppe mémoire commune à tout le système.

Approfondir : Jetson Orin et edge AI →
TOPS

Trillions d'opérations par seconde, la métrique marketing des accélérateurs edge. Utile comme ordre de grandeur, trompeuse comme unique critère de choix.

Approfondir : Jetson Thor, Hailo-10H, Coral →
Jetson Orin

Module embarqué NVIDIA basé sur Ampere. 8/32/64 Go de mémoire unifiée, jusqu'à 275 TOPS. Standard de l'inférence edge en 2023-2025.

Approfondir : Jetson Orin et edge AI →
Jetson Thor

Successeur d'Orin basé sur Blackwell. Jusqu'à 128 Go de mémoire unifiée, palier inédit pour faire tourner des LLM ~30B à l'edge.

Approfondir : Jetson Thor, Hailo-10H, Coral →
Hailo

Famille de NPU israéliens dédiés à l'inférence basse consommation. Le Hailo-10H fait tourner des petits LLM à ~2,5 W.

Approfondir : Jetson Thor, Hailo-10H, Coral →
Coral

Ancienne famille de TPU Edge de Google, désormais abandonnée. À ne plus recommander pour un nouveau projet en 2026.

Approfondir : Jetson Thor, Hailo-10H, Coral →
INT8

Quantification à 8 bits entiers, format de prédilection des NPU edge. Bon compromis qualité/énergie sur les modèles stables.

Approfondir : NPU vs GPU à l’edge →

Coûts & système

Coût par token

Le coût réel de l'inférence : location ou amortissement du GPU, électricité, exploitation, divisés par les tokens réellement produits. L'utilisation en est le facteur dominant.

Approfondir : Coût d’inférence LLM →
LLMflation

La chute du coût de l'inférence pour une capacité équivalente : environ 10× par an entre 2021 et 2025, en ralentissement vers ~3–5× par an.

Approfondir : Coût d’inférence LLM →
eBPF

Mécanisme du noyau Linux permettant d'exécuter des programmes vérifiés attachés à des événements système. Outil d'observabilité du côté hôte d'une stack d'inférence.

Approfondir : eBPF et perf →
TCO

Total Cost of Ownership : tout ce que coûte une infra, pas seulement la facture du jour : matériel, électricité, refroidissement, ingénierie, opportunité.

Approfondir : Coût d’inférence LLM →
GPU cloud

Location de capacité GPU à l'heure ou à l'engagement. Marché en pénurie depuis 2024, prix divergents par référence et fournisseur.

Approfondir : GPU cloud en France et en Europe →
Cloud souverain

Fournisseur dont les machines et la juridiction sont hors de portée du droit extraterritorial américain (Cloud Act). En Europe : Scaleway, OVHcloud.

Approfondir : GPU cloud en France et en Europe →
Spot instance

GPU cloud à prix cassé, réquisitionnable à tout moment par le fournisseur. Utile pour l'entraînement tolérant, dangereux pour l'inférence en production.

Approfondir : GPU cloud en France et en Europe →
Throughput vs Latence

Le compromis fondamental du serving : un gros batch maximise les tokens/s mais alourdit la latence individuelle. Aucun runtime ne contourne ce dilemme.

Approfondir : vLLM vs llama.cpp vs TensorRT-LLM →
NUMA

Non-Uniform Memory Access : architectures multi-socket où l'accès RAM coûte selon le socket auquel le thread est rattaché. Diagnostiquer via eBPF avant d'optimiser.

Approfondir : eBPF et perf →