Text-generation-webUI est une interface utilisateur basée sur Gradio qui facilite l’utilisation de modèles de langage pour générer du texte. Voyons à quoi peuvent bien servir toutes ces options pour la gestion de notre model de langage GGML
Le paramètre « n-gpu-layers » offre un contrôle précieux sur le nombre de couches du modèle qui sont stockées dans la mémoire VRAM en complément de la mémoire RAM. Cette option vise à optimiser la vitesse d’inférence du modèle en exploitant la rapidité de la VRAM. Il est important de noter que chaque couche supplémentaire requiert une allocation légèrement plus importante de mémoire. Par exemple, en fixant « n-gpu-layers » à 16, vous réservez 8 Go de VRAM, tandis que l’augmentation de ce paramètre à 22 vous alloue 12 Go de VRAM.
Si votre modèle peut être entièrement chargé dans la VRAM, il peut être avantageux d’opter pour une version GPTQ du modèle, qui tire pleinement parti de votre carte graphique. Cependant, la combinaison de la mémoire RAM et de la VRAM (GGML : RAM + VRAM) se révèle particulièrement utile pour augmenter la vitesse d’inférence sur des modèles trop volumineux pour être stockés uniquement dans la VRAM, tels que les modèles de 34 milliards de paramètres ou plus (model-34b / model-65b).
« n_ctx
» est le paramètre qui définit la taille maximale du contexte que le modèle de langage peut considérer lors du traitement d’une réponse. Il inclut à la fois la question et la réponse. La valeur par défaut est généralement de 2048 tokens. Modifier n_ctx
peut influencer la vitesse de génération, il est donc essentiel de rester dans les limites de contexte du modèle pour une performance optimale.
Un thread représente une séquence d’instructions que le processeur (ou cœur) peut exécuter. il est configuré par défaut au nombre de 4 quand le paramètre n’est pas défini. C’est un élément à prendre en compte lorsqu’il s’agit de déterminer la vitesse d’inférence d’un modèle de langage. En ajustant le nombre de threads lors de l’inférence d’un modèle, vous pouvez influencer sa vitesse de traitement. Cependant, l’augmentation du nombre de threads ne conduit pas toujours à une amélioration linéaire des performances. Il existe souvent un point de rendement décroissant où l’ajout de threads supplémentaires n’entraîne pas nécessairement une accélération significative (parfois c’est même l’inverse : baisse de performance). Le nombre de threads optimal dépend du matériel de votre ordinateur, du modèle que vous utilisez et de la charge de travail spécifique. Expérimenter avec différents réglages de thread peut vous aider à optimiser les performances.
Le paramètre --n_batch
dans lama.cpp, également connu sous le nom de --batch-size
, détermine le nombre de jetons d’invite (votre demande) qui sont regroupés en un seul lot (batch) lors de l’utilisation de l’outil llama_eval
. En d’autres termes, il définit combien de jetons de votre requête sont traités simultanément par le modèle.
Par exemple, si vous avez une requête qui contient 8 jetons (mots, symboles, etc.) et que vous avez défini --n_batch
sur 4, le modèle traitera cette requête en deux morceaux de 4 jetons chacun. Cela peut être plus efficace dans certains cas, car cela permet de traiter des données en plus gros morceaux, ce qui peut accélérer le traitement.
Cependant, il est important de noter que la valeur de --n_batch
peut influencer la capacité du modèle à comprendre et à mémoriser des informations. Mais il semblerait que ce soit plutôt à cause d’un bug car il n’est pas censé modifier la qualité de sortie.
GGML uniquement (non utilisé par GGUF) : attention aux requêtes groupées. Doit être 8 pour lama-2 70b.
cette « Grouped-Query Attention » est comme une manière pour l’IA de se concentrer sur certaines parties des informations qu’elle reçoit. C’est un peu comme si vous lisiez un livre et que vous vouliez vous concentrer sur certaines phrases ou mots importants. L’IA veut faire cela de manière intelligente.
Maintenant, il y a deux façons différentes dont elle peut le faire. La première façon est un peu rapide mais pas très précise, comme si vous lisiez rapidement un texte sans vraiment le comprendre en détail. La deuxième façon est plus précise, comme si vous lisiez lentement et attentivement chaque mot.
Le but est de trouver un équilibre entre la rapidité et la précision. C’est comme si vous vouliez lire rapidement, mais aussi comprendre vraiment ce que vous lisez. C’est là que cette « Grouped-Query Attention » intervient. Elle essaie de trouver cet équilibre en se basant sur deux façons différentes de se concentrer.
Le paramètre --n_gqa
est simplement une manière de dire à l’IA comment elle devrait faire cela. Pour certains modèles, comme lama-2 70b, il est recommandé de le régler sur 8, ce qui signifie qu’elle devrait utiliser une méthode spéciale pour bien équilibrer la rapidité et la précision.
(pas encore d’information)
(pas encore d’information)
(pas encore d’information)
Utilise la version uniquement CPU pour lama-cpp-python au lieu d’utiliser la version accélérée par GPU.
Le paramètre --no-mmap
contrôle si le modèle utilise la mémoire mmap ou non.
Mmap est une technique qui permet de gérer la mémoire de manière efficace en chargeant des parties du modèle en mémoire uniquement lorsque cela est nécessaire, plutôt que de tout charger en une seule fois. Cela peut être utile si vous avez une quantité limitée de mémoire disponible, car cela permet d’exécuter des modèles plus gros.
Cependant, si vous avez suffisamment de mémoire pour charger le modèle complet en une seule fois, l’utilisation de mmap peut en fait ralentir les performances. Dans ce cas, vous pouvez utiliser --no-mmap
pour désactiver cette fonctionnalité et charger le modèle entier en mémoire dès le départ, ce qui peut améliorer les performances.
Force le système à maintenir constamment le modèle chargé en mémoire RAM sans le décharger. Le déchargement peut parfois entraîner un temps d’attente pour récupérer des réponses. Cette option pourrait être intéressante si vous envisagez de créer un service dédié sur un serveur.