Apprendre

Le glossaire de l'infrastructure IA

Des définitions claires et techniques des concepts derrière les coûts de l'infrastructure IA - et ce que chacun implique pour ta facture, ton choix de GPU et ton architecture.

Commencer ici

Token Prix blended (mixte)Fenêtre de contexte Tokens par seconde Cache KV Quantization VRAM GPU-heure Self-hosting Seuil de rentabilité Mise en cache du prompt Batching continu LoRA Mélange d’experts (MoE)

LLM & API 11

API BatchUn mode asynchrone proposé par la plupart des fournisseurs de LLM : tu soumets un fichier de requêtes, tu récupères les résultats dans un délai (souvent 24 h), et tu paies environ 50 % du tarif au token normal.Prix blended (mixte)Un prix unique par million de tokens qui combine entrée et sortie selon un ratio supposé, pour classer les modèles dans une seule colonne. Obolith pondère l'entrée 3x la sortie.Tarif entrée en cacheUne remise sur les tokens d'entrée qui se répètent entre appels - prompt système stable, exemples, long document. Le préfixe en cache est facturé à ~10-25 % du tarif d'entrée normal.Fenêtre de contexteLe nombre maximum de tokens qu'un modèle peut traiter d'un coup - prompt et réponse combinés. De 8K à plus d'1M de tokens selon les modèles.Coût par million de tokensL'unité standard du prix des API LLM. Indiquée séparément pour l'entrée et la sortie, en USD par 1 000 000 de tokens.EmbeddingUne liste de nombres (un vecteur) qui représente le sens d'un texte, de sorte que des sens proches soient proches. La brique de base de la recherche sémantique et du RAG.Tokens d'entréeLes tokens que tu envoies au modèle : prompt système, historique, contexte récupéré, message utilisateur. En général la moitié la moins chère de la facture.Tokens de sortieLes tokens qu'un modèle génère dans sa réponse. En général la moitié chère de la facture - 2 à 5 fois le prix d'entrée - car chacun demande une passe complète du modèle.Mise en cache du promptRéutiliser l'état déjà calculé d'un préfixe de prompt répété au lieu de le recalculer à chaque appel. Sur les API ça se traduit par un tarif « cache read » réduit ; en self-host c'est une fonction du serveur (prefix caching).RAG (génération augmentée par récupération)Répondre avec un LLM en récupérant d'abord des extraits pertinents de tes propres données pour les mettre dans le prompt. Moins cher et plus à jour que de tout mettre dans une énorme fenêtre de contexte.TokenL'unité que lit et écrit un LLM. Environ 3-4 caractères d'anglais, soit ~0,75 mot. Toute facture d'API se compte en tokens.

Inférence 17

Démarrage à froidLe délai quand un endpoint serverless ou scalé à zéro doit charger un modèle en mémoire GPU avant de répondre à la première requête. De quelques secondes à quelques minutes pour les gros modèles.ConcurrenceLe nombre de requêtes qu'un modèle traite en même temps. Plus de concurrence augmente le débit et l'efficacité économique, mais c'est plafonné par la VRAM car chaque requête en cours a besoin de son propre cache KV.Fenêtre de contexteLe nombre maximum de tokens qu'un modèle peut traiter d'un coup - prompt et réponse combinés. De 8K à plus d'1M de tokens selon les modèles.Batching continuUne technique de serveur d'inférence qui ajoute et retire des requêtes du batch en cours token par token, au lieu d'attendre qu'un batch entier finisse. Multiplie le débit GPU par plusieurs à latence égale.InférenceFaire tourner un modèle déjà entraîné pour obtenir une réponse, par opposition à l'entraîner. Se divise en une phase prefill (lire le prompt) et une phase decode (écrire la réponse token par token).Cache KVUne mémoire qui stocke les clés et valeurs d'attention de chaque token déjà traité, pour éviter de les recalculer à chaque nouveau token de sortie. Elle vit en VRAM et grossit avec la longueur du contexte et la concurrence.LatenceLe temps total entre la requête et la réponse complète. Pour un LLM, c'est ~TTFT + (tokens de sortie / tokens par seconde), plus le réseau.Mélange d’experts (MoE)Une architecture où chaque token n'est routé que vers quelques-uns de nombreux sous-réseaux « experts ». Le nombre total de paramètres est énorme, mais le calcul par token est faible - d'où le faible coût de service de ces modèles.Multi-GPURépartir un modèle sur plusieurs GPU quand il ne rentre pas dans un seul. Ajoute du coût et de la communication, et exige une interconnexion rapide comme NVLink pour rester efficace.QuantizationStocker les poids d'un modèle (et parfois les activations ou le cache KV) à plus basse précision - 8 bits, 4 bits - pour réduire la mémoire et accélérer la génération, en général avec un léger coût en qualité.Self-hostingFaire tourner un modèle open-weight sur des GPU que tu loues ou possèdes, au lieu d'appeler l'API d'un fournisseur. Tu échanges une facture au token contre une facture à l'heure plus de l'ingénierie.Inférence serverlessUn endpoint GPU hébergé qui s'adapte à ton trafic, jusqu'à zéro. Tu paies à la requête ou à la seconde de calcul, pas une machine allumée en permanence - au prix de démarrages à froid.Décodage spéculatifUne astuce de vitesse : un petit modèle rapide propose plusieurs tokens, le grand modèle les vérifie tous en une passe et garde ceux avec lesquels il est d'accord. Génération 2-3x plus rapide, sortie identique.DébitLa quantité de travail d'un système par unité de temps - requêtes par seconde, ou tokens par seconde tous utilisateurs confondus. Le nombre qui décide de l'efficacité économique en self-hosting.Temps jusqu'au premier token (TTFT)Le temps d'attente entre l'envoi d'une requête et l'apparition du premier mot. Dominé par la phase de prefill, il croît donc avec la longueur du prompt.Tokens par secondeLa vitesse à laquelle un modèle génère de la sortie une fois lancé. Fixe la durée d'une réponse complète et, sur un GPU self-hosté, détermine le coût au token.VRAMLa mémoire dédiée d'un GPU. Elle doit contenir les poids du modèle, le cache KV de chaque requête en cours, et les activations. Quand elle est pleine, il faut un GPU plus gros, plus de GPU, ou un modèle plus petit.

GPU & matériel 9

FP16 / BF16Des formats flottants 16 bits. La précision par défaut pour servir les grands modèles : ~2 octets par paramètre. Le BF16 échange des bits de mantisse contre de la plage et est le standard côté entraînement.FP8Flottant 8 bits. Divise par deux la mémoire face au 16 bits tout en gardant une plage flottante, donc perte de qualité en général plus faible que l'INT8 entier. Exige un support matériel (Hopper, Blackwell, MI300).GPUUn processeur à des milliers de cœurs parallèles et une mémoire embarquée très rapide. Le cheval de bataille de l'entraînement comme de l'inférence des grands modèles.GPU-heureL'unité de location de calcul GPU : le coût d'un GPU pendant une heure. Obolith ramène chaque offre au prix par GPU-heure pour comparer équitablement les instances multi-GPU.HBMHigh Bandwidth Memory - la mémoire empilée utilisée comme VRAM sur les GPU data-center. C'est sa bande passante (To/s), pas sa capacité, qui fixe la vitesse de génération d'un LLM.Cache KVUne mémoire qui stocke les clés et valeurs d'attention de chaque token déjà traité, pour éviter de les recalculer à chaque nouveau token de sortie. Elle vit en VRAM et grossit avec la longueur du contexte et la concurrence.Multi-GPURépartir un modèle sur plusieurs GPU quand il ne rentre pas dans un seul. Ajoute du coût et de la communication, et exige une interconnexion rapide comme NVLink pour rester efficace.QuantizationStocker les poids d'un modèle (et parfois les activations ou le cache KV) à plus basse précision - 8 bits, 4 bits - pour réduire la mémoire et accélérer la génération, en général avec un léger coût en qualité.VRAMLa mémoire dédiée d'un GPU. Elle doit contenir les poids du modèle, le cache KV de chaque requête en cours, et les activations. Quand elle est pleine, il faut un GPU plus gros, plus de GPU, ou un modèle plus petit.

Performance 10

Optimisation 11

API BatchUn mode asynchrone proposé par la plupart des fournisseurs de LLM : tu soumets un fichier de requêtes, tu récupères les résultats dans un délai (souvent 24 h), et tu paies environ 50 % du tarif au token normal.Tarif entrée en cacheUne remise sur les tokens d'entrée qui se répètent entre appels - prompt système stable, exemples, long document. Le préfixe en cache est facturé à ~10-25 % du tarif d'entrée normal.Batching continuUne technique de serveur d'inférence qui ajoute et retire des requêtes du batch en cours token par token, au lieu d'attendre qu'un batch entier finisse. Multiplie le débit GPU par plusieurs à latence égale.FP16 / BF16Des formats flottants 16 bits. La précision par défaut pour servir les grands modèles : ~2 octets par paramètre. Le BF16 échange des bits de mantisse contre de la plage et est le standard côté entraînement.FP8Flottant 8 bits. Divise par deux la mémoire face au 16 bits tout en gardant une plage flottante, donc perte de qualité en général plus faible que l'INT8 entier. Exige un support matériel (Hopper, Blackwell, MI300).INT4Quantization entière 4 bits. Réduit la taille du modèle à ~un quart du 16 bits. Gros gain de coût, mais perte de qualité plus perceptible et variable selon le modèle - à tester avant de s'y fier.INT8Quantization entière 8 bits. Divise ~par deux la taille du modèle face au 16 bits avec une perte de qualité faible, souvent négligeable pour du chat. Largement supporté.Mélange d’experts (MoE)Une architecture où chaque token n'est routé que vers quelques-uns de nombreux sous-réseaux « experts ». Le nombre total de paramètres est énorme, mais le calcul par token est faible - d'où le faible coût de service de ces modèles.Mise en cache du promptRéutiliser l'état déjà calculé d'un préfixe de prompt répété au lieu de le recalculer à chaque appel. Sur les API ça se traduit par un tarif « cache read » réduit ; en self-host c'est une fonction du serveur (prefix caching).QuantizationStocker les poids d'un modèle (et parfois les activations ou le cache KV) à plus basse précision - 8 bits, 4 bits - pour réduire la mémoire et accélérer la génération, en général avec un léger coût en qualité.Décodage spéculatifUne astuce de vitesse : un petit modèle rapide propose plusieurs tokens, le grand modèle les vérifie tous en une passe et garde ceux avec lesquels il est d'accord. Génération 2-3x plus rapide, sortie identique.

Infrastructure cloud 9

API vs self-hostingLa décision d'infrastructure centrale pour qui fait tourner des LLM à l'échelle : payer au token chez un fournisseur, ou payer à l'heure des GPU que tu opères. La réponse dépend du volume, de l'utilisation et du besoin de contrôle.Démarrage à froidLe délai quand un endpoint serverless ou scalé à zéro doit charger un modèle en mémoire GPU avant de répondre à la première requête. De quelques secondes à quelques minutes pour les gros modèles.Egress (sortie de données)Les frais que facturent les clouds pour faire sortir des données de leur réseau vers internet. Le stockage est peu cher ; c'est ressortir les données qui fait gonfler la facture de stockage objet.GPU-heureL'unité de location de calcul GPU : le coût d'un GPU pendant une heure. Obolith ramène chaque offre au prix par GPU-heure pour comparer équitablement les instances multi-GPU.Instance on-demandUn GPU cloud loué à l'heure ou à la seconde sans engagement, au tarif standard. Disponible immédiatement, facturé seulement pendant qu'il tourne, mais le plus cher à l'heure.Self-hostingFaire tourner un modèle open-weight sur des GPU que tu loues ou possèdes, au lieu d'appeler l'API d'un fournisseur. Tu échanges une facture au token contre une facture à l'heure plus de l'ingénierie.Inférence serverlessUn endpoint GPU hébergé qui s'adapte à ton trafic, jusqu'à zéro. Tu paies à la requête ou à la seconde de calcul, pas une machine allumée en permanence - au prix de démarrages à froid.Instance spotDe la capacité GPU cloud excédentaire vendue à forte remise (souvent 50-80 % sous l'on-demand) que le fournisseur peut reprendre avec peu de préavis. Bien pour du travail interruptible, risqué pour du serving en direct.Taux d'utilisationLa part du temps où un GPU loué fait un travail utile plutôt que de rester au repos. Le nombre qui décide si le self-hosting bat une API.

Entraînement & fine-tuning 7

Epoch (époque)Un passage complet du jeu d'entraînement dans le modèle. Les fine-tunes font généralement 1 à 4 epochs ; chaque epoch en plus multiplie le coût GPU du run et, au-delà d'un certain point, provoque du surapprentissage.Fine-tuningPoursuivre l'entraînement d'un modèle existant sur tes propres exemples pour l'adapter à une tâche, un style ou un format. Moins cher et plus rapide que partir de zéro ; reste un coût GPU payé une fois par run.Fine-tuning completUn fine-tuning qui met à jour tous les poids du modèle, pas un petit adaptateur. Plafond de qualité le plus haut, mais demande plusieurs fois la taille du modèle en VRAM et généralement un nœud multi-GPU.LoRALow-Rank Adaptation : un fine-tuning qui gèle le modèle de base et entraîne à la place une petite paire de matrices par couche. ~0,1-1 % de paramètres entraînables, donc ça tient sur un seul GPU et tourne en minutes à heures.Multi-GPURépartir un modèle sur plusieurs GPU quand il ne rentre pas dans un seul. Ajoute du coût et de la communication, et exige une interconnexion rapide comme NVLink pour rester efficace.Alignement par préférence (RLHF, DPO)Une seconde étape d'entraînement qui apprend au modèle laquelle de deux réponses les gens préfèrent, plutôt qu'une seule réponse cible. RLHF utilise un modèle de récompense + de l'apprentissage par renforcement ; DPO le fait directement et à bas coût.QLoRALoRA par-dessus un modèle de base quantifié en 4 bits. Réduit la VRAM nécessaire au fine-tuning d'un facteur ~3-4, donc un modèle 70B se tune sur un seul GPU de 48 Go au lieu d'un nœud multi-GPU.

Embeddings & bases vectorielles 5

Découpage (chunking)Découper les documents en passages plus courts avant de les embedder pour du RAG. La taille des chunks arbitre entre précision de récupération et complétude du contexte, et affecte directement le nombre de vecteurs et le coût.EmbeddingUne liste de nombres (un vecteur) qui représente le sens d'un texte, de sorte que des sens proches soient proches. La brique de base de la recherche sémantique et du RAG.Modèle d'embeddingsUn modèle spécialisé dans la production d'embeddings plutôt que la génération de texte. Choisi sur la qualité de retrieval (score MTEB), les dimensions du vecteur, la longueur d'entrée max et le prix.RAG (génération augmentée par récupération)Répondre avec un LLM en récupérant d'abord des extraits pertinents de tes propres données pour les mettre dans le prompt. Moins cher et plus à jour que de tout mettre dans une énorme fenêtre de contexte.Base de données vectorielleUne base conçue pour stocker des embeddings et trouver rapidement les plus proches d'un vecteur de requête. Le poste de coût récurrent d'un système RAG.

Stockage 2

Egress (sortie de données)Les frais que facturent les clouds pour faire sortir des données de leur réseau vers internet. Le stockage est peu cher ; c'est ressortir les données qui fait gonfler la facture de stockage objet.Base de données vectorielleUne base conçue pour stocker des embeddings et trouver rapidement les plus proches d'un vecteur de requête. Le poste de coût récurrent d'un système RAG.

Économie & prix 22

API vs self-hostingLa décision d'infrastructure centrale pour qui fait tourner des LLM à l'échelle : payer au token chez un fournisseur, ou payer à l'heure des GPU que tu opères. La réponse dépend du volume, de l'utilisation et du besoin de contrôle.API BatchUn mode asynchrone proposé par la plupart des fournisseurs de LLM : tu soumets un fichier de requêtes, tu récupères les résultats dans un délai (souvent 24 h), et tu paies environ 50 % du tarif au token normal.Prix blended (mixte)Un prix unique par million de tokens qui combine entrée et sortie selon un ratio supposé, pour classer les modèles dans une seule colonne. Obolith pondère l'entrée 3x la sortie.Seuil de rentabilitéLe volume ou le taux d'utilisation où deux options coûtent pareil - typiquement API vs self-hosting, ou louer vs acheter un GPU. En dessous, une option gagne ; au-dessus, l'autre.Tarif entrée en cacheUne remise sur les tokens d'entrée qui se répètent entre appels - prompt système stable, exemples, long document. Le préfixe en cache est facturé à ~10-25 % du tarif d'entrée normal.ConcurrenceLe nombre de requêtes qu'un modèle traite en même temps. Plus de concurrence augmente le débit et l'efficacité économique, mais c'est plafonné par la VRAM car chaque requête en cours a besoin de son propre cache KV.Coût par million de tokensL'unité standard du prix des API LLM. Indiquée séparément pour l'entrée et la sortie, en USD par 1 000 000 de tokens.Egress (sortie de données)Les frais que facturent les clouds pour faire sortir des données de leur réseau vers internet. Le stockage est peu cher ; c'est ressortir les données qui fait gonfler la facture de stockage objet.GPU-heureL'unité de location de calcul GPU : le coût d'un GPU pendant une heure. Obolith ramène chaque offre au prix par GPU-heure pour comparer équitablement les instances multi-GPU.Tokens d'entréeLes tokens que tu envoies au modèle : prompt système, historique, contexte récupéré, message utilisateur. En général la moitié la moins chère de la facture.Mélange d’experts (MoE)Une architecture où chaque token n'est routé que vers quelques-uns de nombreux sous-réseaux « experts ». Le nombre total de paramètres est énorme, mais le calcul par token est faible - d'où le faible coût de service de ces modèles.Instance on-demandUn GPU cloud loué à l'heure ou à la seconde sans engagement, au tarif standard. Disponible immédiatement, facturé seulement pendant qu'il tourne, mais le plus cher à l'heure.Tokens de sortieLes tokens qu'un modèle génère dans sa réponse. En général la moitié chère de la facture - 2 à 5 fois le prix d'entrée - car chacun demande une passe complète du modèle.Mise en cache du promptRéutiliser l'état déjà calculé d'un préfixe de prompt répété au lieu de le recalculer à chaque appel. Sur les API ça se traduit par un tarif « cache read » réduit ; en self-host c'est une fonction du serveur (prefix caching).RAG (génération augmentée par récupération)Répondre avec un LLM en récupérant d'abord des extraits pertinents de tes propres données pour les mettre dans le prompt. Moins cher et plus à jour que de tout mettre dans une énorme fenêtre de contexte.Self-hostingFaire tourner un modèle open-weight sur des GPU que tu loues ou possèdes, au lieu d'appeler l'API d'un fournisseur. Tu échanges une facture au token contre une facture à l'heure plus de l'ingénierie.Inférence serverlessUn endpoint GPU hébergé qui s'adapte à ton trafic, jusqu'à zéro. Tu paies à la requête ou à la seconde de calcul, pas une machine allumée en permanence - au prix de démarrages à froid.Instance spotDe la capacité GPU cloud excédentaire vendue à forte remise (souvent 50-80 % sous l'on-demand) que le fournisseur peut reprendre avec peu de préavis. Bien pour du travail interruptible, risqué pour du serving en direct.DébitLa quantité de travail d'un système par unité de temps - requêtes par seconde, ou tokens par seconde tous utilisateurs confondus. Le nombre qui décide de l'efficacité économique en self-hosting.TokenL'unité que lit et écrit un LLM. Environ 3-4 caractères d'anglais, soit ~0,75 mot. Toute facture d'API se compte en tokens.Tokens par secondeLa vitesse à laquelle un modèle génère de la sortie une fois lancé. Fixe la durée d'une réponse complète et, sur un GPU self-hosté, détermine le coût au token.Taux d'utilisationLa part du temps où un GPU loué fait un travail utile plutôt que de rester au repos. Le nombre qui décide si le self-hosting bat une API.