Glossaire

Définitions rapides des termes relatifs aux modèles locaux utilisés dans cette documentation. Chaque entrée pointe vers la page qui les décrit en profondeur.

​

Tokens

Il s’agit de petits morceaux de texte — comptant chacun quelques caractères ou un mot — que le modèle lit et écrit effectivement. Votre invite est découpée en tokens avant d’être traitée, et la réponse générée se compose également de tokens un par un. Consultez Comment fonctionne l’inférence.

​

Préremplissage et décodage

Préremplissage : le modèle lit l’intégralité de votre invite en une seule fois, avant de renvoyer quoi que ce soit — cette phase est limitée par le calcul et c’est ce que mesure le « temps avant le premier token ». Décodage : le modèle génère la réponse token par token — cette phase est limitée par la bande passante mémoire et c’est ce que mesure le nombre de tokens/sec. Consultez Comment fonctionne l’inférence.

​

Modèles denses et modèles à mélange d’experts (MoE)

Un modèle dense utilise l’ensemble de ses paramètres pour chaque token. Un modèle à mélange d’experts, tel que 30B-A3B, possède en tout 30B paramètres dont seuls 3B sont actifs par token ; il décode donc plus rapidement qu’un modèle dense de taille comparable, bien qu’il nécessite tout de même de la mémoire pour stocker l’ensemble des paramètres. Consultez Lire la fiche d’un modèle.

​

Précision

Précision : nombre de bits que le moteur d’exécution utilise pour stocker ou calculer chaque nombre du modèle, par exemple bf16, FP16, FP8 ou les formats 4-bit. Une précision plus faible signifie généralement moins de mémoire et des transferts de données plus rapides, mais elle peut réduire la qualité si la quantification est trop agressive. Consultez Quantification et Formats de quantification et matériel requis.

​

Cadre d’inférence

Un cadre d’inférence est le moteur de service qui charge le modèle, exécute les calculs mathématiques, gère le regroupement des requêtes et le cache KV, puis met à disposition une clé API. Ollama et LM Studio sont conçus pour un déploiement local simplifié ; vLLM, SGLang, llama.cpp, TensorRT-LLM et MLX offrent quant à eux des contrôles plus poussés sur le débit, le parallélisme et les noyaux adaptés au matériel. Consultez Service et mise à l’échelle.

​

Noyau

Un noyau désigne la routine de bas niveau exécutée sur le GPU ou le CPU pour effectuer des opérations critiques telles que la multiplication matricielle, le calcul d’attention, la déquantification ou l’échantillonnage. Les formats de quantification ne sont utiles que si le moteur d’exécution dispose de noyaux compatibles ; par exemple, NVFP4 requiert le support des Tensor Core de Blackwell, tandis que GGUF fonctionne sans difficulté via les backends de llama.cpp. Consultez Formats de quantification et matériel requis.

​

Parallélisme tensoriel (TP)

Parallélisme tensoriel : répartit les poids et les calculs d’une couche du modèle sur plusieurs GPU. Utilisez-le lorsque le modèle est trop volumineux pour un seul GPU ou lorsqu’un seul GPU ne peut pas servir suffisamment de trafic. Il réduit la pression mémoire sur chaque GPU, mais les GPU doivent se synchroniser à chaque passe avant, d’où l’importance d’interconnexions rapides. vLLM l’expose via --tensor-parallel-size ; TensorRT-LLM documente la même stratégie sous le nom TP. Consultez Service et mise à l’échelle.

​

Parallélisme de données (DP)

Parallélisme de données : exécute des copies distinctes du modèle sur des GPU ou des instances distincts afin que chaque copie puisse traiter des requêtes différentes. Il augmente le débit de requêtes lorsque le modèle tient déjà sur chaque réplica. La documentation de déploiement data-parallel de vLLM décrit cette approche comme la réplication des poids du modèle sur plusieurs instances ou GPU pour traiter des lots indépendants. Consultez Service et mise à l’échelle.

​

Parallélisme d’experts (EP)

Parallélisme d’experts : s’applique aux modèles à mélange d’experts. Au lieu de donner à chaque GPU une copie complète de chaque expert, le moteur d’exécution place différents experts sur différents GPU et achemine les tokens vers le GPU qui détient l’expert sélectionné. Cela peut améliorer la localité et le débit des grands modèles MoE, mais ajoute une surcharge de routage et de synchronisation. Consultez Service et mise à l’échelle.

​

Prédiction de plusieurs tokens (MTP)

Prédiction de plusieurs tokens : entraîne ou ajoute des têtes auxiliaires qui prédisent plus d’un token futur. Au moment de l’inférence, les moteurs d’exécution peuvent exploiter ces prédictions pour le décodage spéculatif : générer plusieurs tokens brouillons, les vérifier avec le modèle cible et conserver les tokens acceptés. Le checkpoint DeepSeek-V4-Flash-0731 actuel intègre un module de décodage spéculatif DSpark associé, que vLLM active avec method: dspark et SGLang avec DSPARK. Consultez Service et mise à l’échelle.

​

Appel de outils

Capacité d’un modèle à renvoyer une requête structurée visant à invoquer un connecteur externe ou un outil, plutôt que du simple texte, afin que les clients autonomes puissent agir en conséquence. Un appel d’outils fiable constitue un critère essentiel pour le choix de modèles de codage et d’autres clients automatisés. Consultez Quel modèle local pour quelle tâche ?.

​

Température et top-p

Paramètres d’échantillonnage qui déterminent si la sortie du modèle sera prévisible ou variée. Une température plus faible rend la sortie plus déterministe et répétitive ; une température plus élevée la rend plus variée, mais parfois moins cohérente. Le paramètre Top-p (échantillonnage par noyau) limite les choix de jetons au plus petit ensemble dont la probabilité cumulée atteint p, éliminant ainsi les options peu probables avant l’échantillonnage. Ces deux paramètres sont transmis par le client en même temps que la requête.

​

Embeddings

Représentations vectorielles numériques de texte, utilisées pour la recherche, la récupération d’informations et la comparaison de similarité, plutôt que pour générer des réponses conversationnelles. Les modèles d’embedding diffèrent des modèles de chat ; reportez-vous à Quel modèle local pour quelle tâche ? pour en comprendre l’intégration dans le choix du modèle.

​

Fenêtre de contexte

Nombre maximal de jetons qu’un modèle peut traiter simultanément dans une même conversation, incluant à la fois la requête et la réponse. Une fenêtre de contexte plus large permet d’envoyer davantage de texte, mais consomme davantage de mémoire via le cache KV. Voir Cache KV et contexte.

​

Quantification

Technique consistant à stocker les poids d’un modèle avec une précision numérique moindre afin de réduire sa taille et d’accélérer l’inférence, au détriment parfois de la qualité de la sortie. Les noms de quantification GGUF tels que Q4_K_M indiquent la largeur en bits et le type de quantification employés. Consultez Quantification.

​

Cache KV

Enregistrement continu des représentations clé/valeur créé par le modèle lors du traitement d’une conversation, évitant ainsi de traiter à nouveau les jetons précédents à chaque nouvel ajout. Sa taille dépend de la longueur du contexte et de la taille du lot, et il occupe de la mémoire en parallèle avec les poids du modèle. Voir Cache KV et contexte.

​

GGUF

Abréviation de GGML Universal File, le format de fichier utilisé par les moteurs basés sur llama.cpp (tels que Ollama et LM Studio) pour stocker les poids des modèles. On le distribue généralement sous forme de plusieurs variantes quantifiées du même modèle. Ce format succède aux anciens formats GGML/GGJT ; c’est pourquoi on trouve encore « GGML » dans certains dépôts et outils plus anciens. Consultez Lire la fiche du modèle ainsi que la spécification du format GGUF.

​

Maintenant que le vocabulaire a été abordé

Ces termes reviennent sans cesse dès que l’on déploie des modèles en local ; ajoutez cette page à vos favoris et revenez-y régulièrement. Une fois qu’un modèle fonctionne et répond aux requêtes sur localhost, l’étape suivante consiste à y accéder depuis un autre appareil.