Passer au contenu principal
Chaque réponse d’un modèle local suit le même cycle aller-retour : votre texte est converti en jetons, le modèle lit l’intégralité de l’invite en une seule fois, puis rédige la réponse jeton par jeton. Comprendre ces étapes explique deux problèmes auxquels tout utilisateur de modèle local est confronté : pourquoi une longue invite prend un moment pour « réfléchir » avant l’apparition du premier mot, et pourquoi la vitesse de génération dépend de la mémoire, et non uniquement de la puissance de calcul brute. Cette page est le 101 du reste du parcours Concepts. Si vous ne devez lire qu’une seule page ici, lisez celle-ci.

​
Étape 1 : tokenisation

Avant que le modèle ne voie quoi que ce soit, votre invite est divisée en jetons — de petits morceaux de texte, correspondant à peu près à quelques caractères ou à une partie de mot chacun. La tokenisation est déterministe et quasi instantanée ; il s’agit simplement d’une recherche dans le vocabulaire du modèle. Le modèle ne voit jamais le texte brut, uniquement une séquence d’identifiants de jetons.

​
Étape 2 : préremplissage (limité par le calcul)

Préremplissage (prefill) correspond à la lecture de l’intégralité de votre invite par le modèle — chaque jeton que vous avez envoyé, en un seul passage — avant qu’il n’écrive un seul mot en retour. Cette étape est limitée par le calcul : le GPU effectue de lourds calculs matriciels sur l’ensemble de l’invite en une seule fois, ce qui évolue en fonction de la puissance de traitement disponible. Le préremplissage a deux effets importants à connaître :
  • C’est ce sur quoi vous attendez lorsque le démarrage d’une réponse est lent. Le délai entre l’envoi d’une invite et l’apparition du premier jeton est appelé temps jusqu’au premier jeton (TTFT), et il correspond presque entièrement au temps de préremplissage.
  • Il construit le cache KV — un enregistrement continu de l’invite afin que le modèle n’ait pas à la retraiter pour chaque jeton suivant. Consultez Cache KV et contexte pour connaître le coût de ce cache en mémoire.
Des invites plus longues signifient plus de travail de préremplissage, ce qui se traduit par un TTFT plus long.

​
Étape 3 : décodage (limité par la bande passante mémoire)

Une fois le préremplissage terminé, le modèle commence le décodage : il génère la réponse un jeton à la fois. Chaque nouveau jeton est ajouté à la séquence, et le jeton suivant est prédit à partir de tout ce qui a été généré jusqu’alors. Le décodage se comporte très différemment du préremplissage. À chaque étape, le modèle doit lire ses poids (ou, pour un modèle à mélange d’experts, uniquement les experts actifs) ainsi que l’intégralité du cache KV depuis la mémoire. Comme très peu de nouveaux calculs sont effectués par jeton par rapport à la quantité de données qui doivent être déplacées, le décodage est limité par la bande passante mémoire — il est limité par la vitesse à laquelle les données peuvent voyager de la mémoire vers les unités de calcul, et non par la quantité de puissance de calcul brute disponible. C’est ce que mesurent les jetons par seconde, et c’est pourquoi :
  • Un GPU avec moins de puissance de calcul mais une mémoire plus rapide peut surpasser une puce « plus rapide » dotée d’une mémoire plus lente en décodage.
  • Un contexte plus long ralentit le décodage, car il y a plus de cache KV à lire à chaque étape, en plus de consommer davantage de mémoire (voir Cache KV et contexte).

​
Étape 4 : diffusion en continu des jetons

Au fur et à mesure que le modèle produit chaque jeton, celui-ci est décodé en texte et diffusé en continu au client immédiatement — c’est pourquoi vous voyez les réponses apparaître mot par mot plutôt que toutes d’un coup. Si vous utilisez Tokios, ce flux voyage depuis votre backend local à travers le connecteur et la passerelle jusqu’à l’application ou l’agent qui a envoyé la requête ; consultez Comment Tokios achemine les requêtes pour cette partie du trajet.

​
Répartition en mémoire

Tout ce qui précède se produit par rapport à trois éléments résidant dans la VRAM (ou la mémoire unifiée) : Les poids constituent le plancher — vous ne pouvez pas exécuter le modèle sans les charger entièrement (ou les décharger partiellement ; voir Mémoire et déchargement). Le cache KV est la partie qui grandit à mesure que votre conversation ou document s’allonge, ce qui explique pourquoi « cela fonctionnait avec une courte invite mais a épuisé la mémoire avec une longue invite » est un mode de défaillance si courant.
Cette page couvre la mécanique. Pour les calculs de taille — combien de gigaoctets un modèle et un contexte donnés nécessitent réellement — consultez Mémoire et déchargement et le guide d’ajustement du modèle sur GPU.

​
Approfondir

Cache KV et contexte

Pourquoi un contexte plus long coûte plus cher en mémoire et ralentit le décodage.

Mémoire et déchargement

Formules de dimensionnement et ce qui se passe lorsqu’un modèle ne tient pas entièrement.

Quantification

Comment la réduction de la précision des poids modifie à la fois la mémoire et la vitesse.

Lire une fiche modèle

Où trouver l’architecture et la longueur de contexte d’un modèle avant de l’exécuter.

​
Une fois que vous comprenez comment cela s’exécute

Tout ce qui précède se produit sur votre machine, avec un modèle s’exécutant sur localhost. Une fois à l’aise avec cela, la question suivante est de savoir comment y accéder depuis un autre endroit que votre propre machine.

Donnez à votre modèle local un point de terminaison stable

Tokios ne choisit, n’héberge ni n’affine votre modèle — une fois qu’il s’exécute localement, Tokios le transforme en un point de terminaison stable et authentifié que vous pouvez appeler depuis n’importe où.