Pourquoi mon LLM auto-hébergé ralentit avec 5 utilisateurs

Pourquoi un LLM auto-hébergé ralentit-il quand davantage d’utilisateurs se connectent ?

Lorsqu’un LLM auto-hébergé se bloque avec 5 utilisateurs simultanés, la cause habituelle est que le serveur est configuré pour générer une seule réponse à la fois. Les quatre autres attendent donc dans une file. La documentation d’Ollama est claire au sujet de sa valeur par défaut : OLLAMA_NUM_PARALLEL correspond au « nombre maximal de requêtes parallèles que chaque modèle traite simultanément, valeur par défaut : 1 ». Rien n’est cassé, et le logiciel de serving peut traiter plusieurs requêtes à la fois. Quatre de vos cinq utilisateurs attendent leur tour parce qu’un paramètre l’impose.

La solution consiste rarement à utiliser une machine plus puissante. Il faut un moteur de serving capable de faire passer de nombreuses requêtes dans le modèle lors du même forward pass, ainsi que suffisamment de mémoire disponible pour conserver la conversation de chaque utilisateur pendant ce traitement. Ces deux éléments sont importants. C’est le second qui détermine réellement votre limite.

Les deux phases de chaque requête

Le prefill lit l’intégralité du prompt en une seule fois et construit le cache d’attention correspondant. Tous les tokens du prompt traversent le modèle ensemble. Le prefill consiste donc en une grande multiplication matricielle et dépend du débit de calcul. Le decode génère ensuite la réponse un token à la fois. À chaque token, l’intégralité des poids du modèle doit de nouveau être lue depuis la mémoire, alors que les calculs effectués sur ce seul token sont minimes. Le decode dépend donc de la bande passante mémoire.

Cette asymétrie explique pourquoi le batching fonctionne. Pour le decode d’un utilisateur, supposons que 5 GB de poids soient lus par token, tandis que la plupart des unités de calcul restent inactives. Ajoutez une deuxième requête : le moteur lit une seule fois les mêmes 5 GB, puis calcule deux tokens à partir de ces données. Le deuxième utilisateur ajoute presque aucun temps de traitement. Traiter les requêtes strictement l’une après l’autre fait perdre cet avantage.

Deux valeurs déterminent ce que ressent l’utilisateur. Le TTFT (time to first token) correspond au temps d’attente dans la file, ajouté au temps de prefill. L’ITL (inter-token latency) est l’intervalle entre les tokens transmis en streaming. Il dépend du decode. Un serveur lent l’est généralement sur l’une de ces deux valeurs, et les corrections ne sont pas les mêmes. Il est utile de déterminer laquelle pose problème avant de modifier un paramètre. mesurer séparément le prefill et le decode permet de le vérifier.

Le batching statique fait attendre tout le monde jusqu’à la réponse la plus lente

Le batching statique est la version naïve. C’est ce que vous obtenez lorsque vous regroupez vous-même les requêtes dans le code de l’application. Le moteur collecte N requêtes, les exécute ensemble et conserve chaque slot jusqu’à la fin de la génération la plus longue du groupe.

Un utilisateur qui demande un résumé de 1,200 tokens bloque quatre réponses d’une ligne dans le batch, car celui-ci ne libère aucun slot avant la fin de son membre le plus lent.

Cela entraîne deux coûts. Les séquences terminées continuent d’occuper des slots sans effectuer de calcul utile. Le débit effectif diminue donc lorsque la longueur des sorties varie, ce qui est fréquent pour les conversations. Une requête qui arrive juste après la formation du batch doit attendre que celui-ci soit entièrement traité avant même de commencer le prefill. Son TTFT dépend donc du long texte généré pour un autre utilisateur.

Le continuous batching admet et retire les requêtes à chaque token

Le continuous batching planifie les requêtes au niveau d’une seule étape de décodage. Après chaque étape, le scheduler retire les séquences qui viennent d’émettre leur token d’arrêt, puis admet les requêtes en attente dans les slots disponibles. Une réponse qui se termine à l’étape 40 libère son slot à l’étape 40, et non à la fin du batch.

Ce mécanisme n’a rien d’inhabituel. llama-server documente -cb, --cont-batching comme « whether to enable continuous batching (a.k.a dynamic batching) (default: enabled) », mentionne « Parallel decoding with multi-user support » parmi ses fonctionnalités et, depuis une modification fusionnée en novembre 2025, démarre par défaut avec 4 slots (-np vaut -1 par défaut, soit auto). vLLM repose sur ce principe. Ollama traite également les requêtes en parallèle. La configuration par défaut limite simplement leur nombre à un, ce qui explique pourquoi tant de personnes concluent que leur matériel ne gère pas la concurrence alors que leur configuration l’interdisait.

Les résultats publiés sur le continuous batching sont généralement mesurés sur des cartes de datacenter disposant à la fois de puissance de calcul inutilisée et de dizaines de gigaoctets pour le cache. La tendance de ces résultats reste valable sur votre machine. En revanche, leur ampleur ne se transpose pas directement. La section consacrée à la mémoire ci-dessous en explique la raison.

Le prefill concurrence avec le décodage pour les mêmes ressources de calcul

Lorsqu’une nouvelle requête arrive alors que quatre réponses sont en cours de streaming, son prompt doit d’abord être traité en prefill, une opération qui sollicite fortement le calcul. Si le scheduler réserve une étape entière à ce prefill, les quatre utilisateurs ne reçoivent aucun token pendant cette étape. Avec un prompt long, toutes les fenêtres ouvertes marquent alors une pause visible. C’est ce que l’on appelle un ralentissement du serveur lorsqu’un autre utilisateur clique sur Envoyer.

Le chunked prefill découpe un prompt long en morceaux et intègre chaque morceau à la même étape que les décodages en cours. Le guide de réglage de vLLM décrit directement ce compromis : des budgets de chunks plus petits « offrent un meilleur ITL, car moins de prefills ralentissent les décodages », tandis que des valeurs plus élevées « offrent un meilleur time to first token (TTFT), car davantage de tokens de prefill peuvent être traités dans un batch ». Il faut choisir quelle expérience protéger : celle de la personne qui attend le début de la réponse, ou celle des utilisateurs qui regardent le texte s’afficher en streaming.

La longueur du prompt détermine l’ampleur du problème. Un prompt de 6,000 tokens suivi d’une réponse de 200 tokens représente 6,000 tokens de travail de prefill pour seulement 200 étapes de décodage. Le chat augmenté par récupération et les prompts système longs vous placent tous deux dans ce cas. Le prefill n’est alors plus négligeable : c’est lui que les utilisateurs attendent. Le prefix caching est utile lorsque la partie longue se répète : vLLM expose --enable-prefix-caching, qui réutilise le cache d’un préfixe de prompt partagé au lieu de le recalculer pour chaque requête.

La mémoire qui arrive à saturation en premier est le cache KV

Chaque token de chaque conversation active laisse un vecteur de clé et un vecteur de valeur dans chaque couche du modèle. C’est le cache KV (cache clé/valeur). Il évite au décodage de recalculer l’intégralité du prompt pour chaque nouveau token. Le nombre de valeurs mises en cache par token est fixé par la structure du modèle : 2 (une clé et une valeur) multiplié par le nombre de couches, le nombre de têtes clé/valeur et la dimension des têtes. Relevez ces valeurs dans le config.json du modèle. Multipliez-les par le nombre d’octets par valeur pour obtenir la taille. Ce dernier facteur dépend d’un paramètre d’exécution et ne fait pas partie du modèle : llama-server stocke le cache en f16 (2 octets) par défaut et accepte des types plus compacts, comme q8_0, via -ctk et -ctv.

Faites le calcul une fois : la limite devient prévisible. Un modèle 8B courant avec 36 couches, 8 têtes clé/valeur et une dimension de tête de 128, qui stocke le cache sur 16 bits, consomme 2 36 8 128 2 octets par token. Cela représente 147,456 octets, soit environ 144 KiB. Une conversation de 8,192 tokens nécessite donc environ 1.2 GB de cache. Cinq conversations nécessitent environ 6 GB, en plus des poids. C’est la vraie réponse à la question du nombre d’utilisateurs que la machine peut prendre en charge.

La concurrence multiplie la taille du contexte, et les outils l’indiquent explicitement. La FAQ d’Ollama précise : « Le traitement parallèle des requêtes pour un modèle donné augmente la taille du contexte en fonction du nombre de requêtes parallèles. Par exemple, un contexte de 2K avec 4 requêtes parallèles donne un contexte de 8K et nécessite une allocation mémoire supplémentaire. » La RAM nécessaire évolue selon OLLAMA_NUM_PARALLEL multiplié par OLLAMA_CONTEXT_LENGTH. Dans llama-server, le nombre de slots automatique par défaut exécute tous les slots dans un seul buffer KV unifié. L’ensemble du contexte -c forme donc un pool unique dans lequel les slots puisent. Définissez vous-même -np : le buffer unifié est alors désactivé, sauf si vous passez également --kv-unified. Le contexte demandé avec -c est alors réparti entre les -np slots. Augmenter uniquement le nombre de slots réduit donc la taille de contexte disponible pour chaque requête. Consultez le contexte par slot dans le journal de démarrage au lieu de le supposer.

vLLM préalloue la mémoire. --gpu-memory-utilization (0.92 par défaut) correspond à « la fraction de la mémoire GPU à utiliser pour l’exécuteur du modèle ». Sauf si vous définissez --kv-cache-memory-bytes, vLLM déduit la taille du cache KV à partir de cette fraction. Le budget restant après la prise en compte des poids et de la mémoire de travail mesurée du moteur devient le pool KV paginé. Lorsque ce pool est épuisé, le scheduler évince une requête au lieu de l’échouer :

WARNING 05-09 00:49:33 scheduler.py:1057] Sequence group 0 is preempted by PreemptionMode.RECOMPUTE mode because there is not enough KV cache space.

Dans le moteur V1 de vLLM, le mode de préemption par défaut est RECOMPUTE. Une requête évincée perd donc son cache et effectue à nouveau le prefill lorsqu’elle est admise de nouveau. Ce travail est effectué deux fois. La documentation avertit que « la préemption et le recalcul peuvent dégrader la latence de bout en bout ». Cette ligne de journal explique mieux que toute autre pourquoi un utilisateur a attendu beaucoup plus longtemps que les autres alors que votre moyenne semblait correcte. Définissez disable_log_stats=False pour journaliser le compteur cumulé, ou consultez le compteur de préemption dans les métriques Prometheus exposées par vLLM.

Ce qui change avec 2, 5 et 20 utilisateurs simultanés

Deux utilisateurs. La différence est presque invisible sur un GPU disposant de suffisamment de cache, car le deuxième flux de décodage s’exécute avec le premier pour un surcoût très faible. Sur un VPS limité au CPU avec 4 à 8 GB de RAM, ce n’est pas gratuit : les deux flux partagent les mêmes quelques vCPU et la même bande passante mémoire. Chaque utilisateur obtient donc environ la moitié des tokens par seconde, tandis que la demande de cache double avec un budget beaucoup plus faible.

Cinq utilisateurs. C’est à ce stade que les valeurs par défaut ne suffisent plus et que le problème commence par devenir un problème de file d’attente. Avec OLLAMA_NUM_PARALLEL à 1, quatre personnes attendent celle qui a demandé la réponse la plus longue. Chacune retrouve une vitesse normale dès que son tour arrive. Augmenter le nombre de traitements parallèles change la nature du problème : cinq slots avec un contexte de 8K représentent un cache de 40K tokens à placer. S’il ne tient pas dans la VRAM, le moteur décharge des couches vers la RAM du système. S’il ne tient pas dans la RAM, la machine utilise le swap et le nombre de tokens par seconde s’effondre.

Vingt utilisateurs. Vingt personnes dans une interface de chat ne génèrent généralement pas vingt requêtes simultanées. C’est le point le plus important à comprendre avant d’acheter du matériel. Une personne lit une réponse et réfléchit pendant 20 à 60 secondes entre deux tours. La majeure partie de sa session est donc inactive. Vingt agents, ou vingt tâches de synthèse de documents, représentent vingt flux réels sans aucun temps d’inactivité. Il faut alors une autre machine. Un développeur qui a dirigé un agent de programmation vers son propre serveur Ollama est plus proche du deuxième cas que du premier, car l’agent envoie des requêtes aussi longtemps que la tâche s’exécute et ne laisse pas les pauses de lecture d’une personne.

Vos utilisateurs sont-ils réellement concurrents, ou seulement connectés ?

Commencez par calculer le nombre de requêtes en cours avant de dimensionner quoi que ce soit. Le calcul est simple : le nombre de requêtes en cours correspond au nombre d’utilisateurs multiplié par le nombre de secondes nécessaires pour générer une réponse, puis divisé par le nombre de secondes entre deux tours.

1. Mesurez d’abord votre débit sur un flux unique, pour le prefill comme pour le decode. Ne reprenez pas une valeur mesurée sur la carte de quelqu’un d’autre : mesurez les tokens par seconde sur votre propre machine et utilisez le résultat obtenu.
2. Estimez le cycle d’utilisation. Avec 20 utilisateurs de chat, 12 secondes de génération par tour et un tour toutes les 90 secondes, le calcul est 20 * 12 / 90, soit environ 2.7 requêtes en cours.
3. Définissez un nombre de slots légèrement supérieur, puis vérifiez-le par rapport à la mémoire : le nombre de slots multiplié par le contexte par requête doit tenir dans le nombre de tokens de cache réellement disponible.
4. Gardez une file d’attente courte afin que les dépassements échouent rapidement et de manière visible.

Le nombre de tokens de cache disponibles correspond à la mémoire libre après chargement des poids, divisé par le coût par token indiqué dans la section précédente. Une carte de 24 GB exécutant un modèle 8B en 16-bit consomme environ 16 GB pour les poids. Elle dispose donc au maximum d’environ 6 GB de cache utilisable avec l’utilisation par défaut, et d’un peu moins une fois la mémoire de travail réservée. Cela correspond à environ cinq conversations de 8K. Pour en gérer davantage, réduisez le contexte par requête ou stockez le cache en 8-bit (llama-server prend --cache-type-k q8_0). Ces deux options augmentent la concurrence en échange d’une contrepartie. Il est utile de lire une analyse honnête de ce compromis avant d’investir dans le matériel : à partir de quand un GPU VPS devient rentable par rapport aux tokens d’API.

Quand les valeurs par défaut d’Ollama ne suffisent plus

Augmentez le nombre d’exécutions parallèles dans l’unité de service, car une variable exportée dans un shell ne sera pas transmise à un démon géré par systemd.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_MAX_QUEUE=64"

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment
ollama ps

systemctl show doit afficher les trois variables que vous venez de définir. Si ce n’est pas le cas, le drop-in n’a pas été enregistré et aucune autre action ne pourra résoudre le problème. ollama ps liste ensuite le modèle chargé avec une taille supérieure à celle de ses seuls poids, car quatre emplacements de 8,192 tokens réservent 32,768 tokens de cache en plus. Une colonne PROCESSOR indiquant qu’une partie du modèle se trouve sur le CPU alors que vous attendiez un chargement complet sur le GPU signifie que vous avez demandé plus de cache que la carte n’en avait de disponible. Réduisez l’une des deux valeurs. Réduire le contexte est généralement le choix le plus sûr, mais une fenêtre trop petite tronque silencieusement les longues requêtes au lieu de générer une erreur. Il est donc préférable de dimensionner num_ctx délibérément plutôt que de le réduire jusqu’à ce que le modèle tienne.

La valeur par défaut de la file d’attente mérite un second examen. Ollama met en file d’attente jusqu’à OLLAMA_MAX_QUEUE requêtes, et « la valeur par défaut est 512 ». Au-delà, il répond « avec une erreur 503 indiquant que le serveur est surchargé ». Une file d’attente de 512 requêtes sur une machine qui en traite quatre à la fois est une promesse impossible à tenir, car le client en position 300 expire bien avant son tour. Une file d’attente courte renvoie une erreur que votre application peut réessayer ou signaler, ce qui vaut mieux qu’un indicateur de chargement qui ne se termine jamais.

Testez réellement le comportement. Envoyez deux requêtes au même moment depuis deux terminaux et surveillez-les toutes les deux. Si la seconde ne produit rien avant la fin de la première, le paramètre d’exécution parallèle n’a pas été pris en compte.

Quand un véritable moteur d’inférence commence à être rentable

vLLM justifie sa configuration supplémentaire lorsque vous disposez d’un GPU avec de la marge et de plus d’environ quatre requêtes réellement en cours de traitement. Son ordonnanceur travaille token par token, son cache est paginé afin de réutiliser les fragments libres, et il transforme la VRAM disponible en concurrence au lieu de la laisser inutilisée. En octobre 2026, l’installation et le lancement documentés sur GPU tiennent en trois commandes. vllm download-kernels récupère les kernels précompilés que vLLM devrait sinon télécharger et compiler au démarrage :

uv pip install vllm --torch-backend=auto
vllm download-kernels
vllm serve Qwen/Qwen2.5-1.5B-Instruct

curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "Qwen/Qwen2.5-1.5B-Instruct",
        "messages": [{"role": "user", "content": "Say hello."}]
    }'

Une réponse contenant un tableau choices signifie que le serveur est opérationnel et que le modèle est chargé. En charge, les deux paramètres importants sont --max-num-seqs, le « nombre maximal de séquences à traiter au cours d’une même itération », et --max-num-batched-tokens, le « nombre maximal de tokens pouvant être traités au cours d’une même itération ». Le premier limite la concurrence. Le second correspond au budget de prefill par blocs décrit précédemment.

En dessous d’environ quatre requêtes en cours de traitement, vLLM ajoute de la complexité pour un gain limité. Un GPU n’est plus nécessaire : en octobre 2026, le guide d’installation CPU documente « l’inférence et le serving de modèles de base » sur les processeurs x86 et Arm, avec des wheels x86 précompilées depuis la version 0.17.0 et une image Docker CPU. Ses habitudes de consommation mémoire restent toutefois les mêmes. Sur CPU, il applique la même fraction d’utilisation de 0.92 à la RAM système et attribue au cache KV ce que les poids laissent disponible. Par défaut, il réclame donc la majeure partie de la mémoire de la machine au démarrage, sauf si vous limitez le cache avec --kv-cache-memory-bytes. Ce compromis est inadapté à un VPS de 4 à 8 GB. Dans ce cas, choisissez plutôt un modèle plus petit avec un contexte plus court et une file d’attente que vous contrôlez. différences entre Ollama et vLLM comme moteurs de serving détaille ce choix, et exécuter Qwen 3 8B sur un VPS montre les ressources nécessaires pour un modèle de taille moyenne avant d’ajouter un seul utilisateur supplémentaire.

Le compromis que la sagesse populaire passe sous silence

Le continuous batching augmente le débit total et améliore généralement la latence médiane, car une requête en attente démarre plus tôt. La latence de queue évolue dans l’autre sens, mais cette moitié du problème est rarement mentionnée.

Chaque séquence supplémentaire dans une étape ajoute un peu de travail. L’ITL augmente donc pour tout le monde à mesure que le batch se remplit. Le prefill d’une nouvelle requête consomme une partie d’une étape qui aurait sinon été disponible pour les utilisateurs en streaming. Sous pression sur le cache, le scheduler préempte des requêtes, ce qui renvoie une requête partiellement générée au début de son prefill.

Une interface de chat expose les latences de queue, pas les moyennes. Un flux qui s’interrompt pendant deux secondes au milieu d’une phrase semble défaillant, même si le temps total jusqu’à la fin est bon. Mesurez le TTFT au p95 et l’ITL au p95 avec la charge prévue, et considérez la moyenne des tokens par seconde comme une mesure de capacité, pas comme une description de l’expérience utilisateur.

Le réglage pratique en découle. Limitez légèrement la concurrence en dessous de ce que la mémoire permet, afin que le moteur n’ait jamais besoin de préempter. Une file d’attente courte et prévisible vaut mieux qu’un batch profond qui sature, car un utilisateur qui attend quatre secondes puis reçoit un flux régulier sera plus satisfait qu’un utilisateur dont la réponse démarre immédiatement mais s’interrompt deux fois.

Que vérifier lorsque le service est lent

Chaque utilisateur obtient un débit normal, mais l’attente est longue. Il s’agit d’une file d’attente, pas d’un problème de vitesse. Vérifiez d’abord le paramètre de parallélisme. Le modèle traite correctement les requêtes, une par une.

Ollama renvoie HTTP 503. La file d’attente est pleine. Soit la machine est réellement à sa capacité maximale, soit OLLAMA_MAX_QUEUE est volontairement faible pour limiter la charge, ce qui est précisément son rôle.

Le nombre de tokens par seconde s’effondre sous la charge sur une machine équipée d’un CPU. Exécutez vmstat 1 pendant le problème. Des valeurs non nulles dans les colonnes si et so indiquent que la machine utilise le swap. Les poids sont donc lus sur le disque à chaque token. Aucune modification de configuration ne peut résoudre ce problème. Utilisez un modèle plus petit ou réduisez le nombre de slots.

Un utilisateur sur dix attend beaucoup plus longtemps que les autres. Recherchez preempted dans le journal vLLM. La préemption et le recalcul associé sont généralement en cause. Cela signifie que le cache est surchargé pour la longueur de contexte autorisée.

Le TTFT est mauvais alors que le serveur est inactif. Il s’agit du prefill, pas de la concurrence. Les prompts longs nécessitent un temps de traitement réel avant l’apparition du premier token. Vérifiez donc la taille des prompts et le prefix caching avant d’examiner le matériel. Si la longue attente ne concerne que le premier utilisateur après une période d’inactivité et que tous les suivants n’ont aucun problème, il ne s’agit pas du prefill. Ollama a probablement déchargé le modèle, puis relu les poids depuis le disque. Vous pouvez écarter cette cause en conservant le modèle en mémoire entre les requêtes.

FAQ

Pourquoi mon LLM auto-hébergé ralentit-il lorsqu’une deuxième personne l’utilise ?

Le plus souvent, il ne ralentit pas du tout. La deuxième requête est mise en file d’attente. Ollama est livré avec OLLAMA_NUM_PARALLEL à 1, donc la deuxième requête attend que la première émette son dernier token. Distinguez les deux cas en mesurant le flux d’un utilisateur pendant qu’un autre attend : si le débit de tokens par seconde est normal une fois le traitement commencé, vous avez une file d’attente et augmenter le nombre de traitements parallèles résout le problème. Si les deux flux avancent à mi-vitesse, vous partagez réellement la bande passante mémoire, qui constitue alors une limite matérielle.

Combien d’utilisateurs simultanés un petit GPU peut-il servir ?

Comptez la mémoire, pas les utilisateurs. Il faut d’abord charger les poids, puis le cache KV, qui consomme 2 fois le nombre de couches fois le nombre de têtes key/value fois la dimension des têtes fois le nombre d’octets, par token et par conversation active. Un modèle 8B classique avec 36 couches, 8 têtes key/value et une dimension de tête de 128 consomme environ 144 KiB par token en 16 bits. Une conversation de 8,192 tokens nécessite donc environ 1.2 GB. Une carte de 24 GB qui contient ce modèle en 16 bits dispose d’au plus environ 6 GB pour le cache, soit environ cinq conversations avec un contexte complet, ou davantage si vous réduisez le contexte.

Le continuous batching ralentit-il la réponse de chaque utilisateur ?

La latence médiane s’améliore généralement, car les requêtes n’attendent plus la fin d’un batch complet. La latence de queue augmente. Chaque séquence supplémentaire ajoute du travail à chaque étape de décodage, le prefill d’une nouvelle requête prend une partie d’une étape aux utilisateurs dont le flux est en cours, et une requête préemptée doit effectuer son prefill deux fois. Mesurez la latence inter-token p95, pas la moyenne, car une fenêtre de chat rend les pauses évidentes, contrairement aux moyennes qui les masquent.

Dois-je augmenter OLLAMA_NUM_PARALLEL ou passer à vLLM ?

Commencez par augmenter le nombre de traitements parallèles. C’est gratuit et cela nécessite un seul fichier drop-in. Cela résout le cas courant où quatre personnes attendent derrière une longue réponse. La mémoire est la limite : les requêtes parallèles multiplient le contexte à conserver, surveillez donc le transfert de couches vers le CPU. Passez à vLLM lorsque votre GPU dispose de VRAM disponible et que plus d’environ quatre requêtes sont réellement en cours, car c’est à partir de ce seuil que le cache paginé et la planification par token apportent davantage qu’ils ne coûtent.

Davantage de cœurs CPU peuvent-ils accélérer un serveur LLM lent ?

Pas pour la partie qui est la plus visible pour les utilisateurs. Le décodage lit le modèle complet en mémoire pour chaque token. Il est donc limité par la bande passante de la RAM, et des cœurs supplémentaires ne servent plus une fois cette bande passante saturée. Le prefill évolue avec le nombre de cœurs, qui réduisent donc le délai avant le premier token pour les longs prompts. Sur un VPS de 4 à 8 GB, la contrainte principale est généralement la capacité mémoire. La solution efficace consiste alors à utiliser un modèle plus petit ou un contexte plus court, plutôt qu’à ajouter des vCPU.