Les paramètres moteur qui comptent

La plupart des défauts moteurs sont sains pour une démo et faux pour l'usage réel. Trois ou quatre réglages changent les résultats : longueur de contexte, délestage GPU, type de cache KV et flash attention. Tout le reste est du réglage à la marge. Cette page utilise les noms d'options de llama.cpp, avec les équivalents Ollama à la fin — les concepts passent à tous les moteurs.

Longueur de contexte : le piège du défaut silencieux

Les moteurs livrent des défauts prudents : llama.cpp historiquement 512 puis 4096, Ollama 2048–4096 selon la version (à ce jour OLLAMA_CONTEXT_LENGTH tombe autour de 4k). Pendant ce temps, votre modèle peut supporte nativement 32k–128k. Collez un document de 20k jetons dans un contexte 4k et l'une de deux choses arrive, toutes deux mauvaises : une erreur franche (« la requête dépasse le contexte disponible ») ou une troncature silencieuse des plus anciens messages. Aucun des deux messages ne s'explique de lui-même à un débutant.

Exemple détaillé : vous chargez un contrat de ~12k jetons plus une question, dans une fenêtre 4096 par défaut. Le moteur garde le matériau le plus récent, abandonne le début du document, et le modèle répond avec assurance aux questions sur la mauvaise moitié du fichier. On croit à un modèle stupide ; c'est un prompt tronqué.

Le correctif est mécanique : passez la taille de contexte explicitement à chaque lancement, calibrée sur vos vrais prompts plus la sortie attendue, puis vérifiez que le log de démarrage montre n_ctx = 16384 (ou votre choix). Note coréenne : le texte coréen se tokenise souvent moins densément que l'anglais dans le même tokenizer — une page de coréen peut coûter plus de jetons qu'une page d'anglais (voir jetons) — donc la pression de contexte arrive plus tôt que prévu.

# le piège : les défauts diffèrent par moteur et par version
llama-server -m model.gguf                  # démarre avec n_ctx = 4096 environ

# le correctif : explicite, et vérifié dans le log de démarrage
llama-server -m model.gguf -c 16384         # le log affiche : n_ctx = 16384

Délestage GPU : n_gpu_layers

-ngl / --n-gpu-layers fixe combien de couches du transformer vivent sur le GPU ; utilisez un grand nombre comme 99 (ou -1 où c'est supporté) pour dire « toutes ». Le symptôme du délestage partiel est distinctif : 3–10 tok/s sur une machine avec un GPU correct. Vérifiez avec la ligne de log de chargement, p. ex. offloaded 33/33 layers to GPU. Si la VRAM ne peut pas tenir modèle plus cache KV, les options honnêtes sont un quant plus petit, un cache KV quantifié, ou moins de couches délestées — mais sachez que chaque couche laissée sur CPU traîne toute la boucle au rythme CPU (voir vitesse). Délester à moitié un modèle qui tient presque est habituellement pire qu'un pas de quant vers le bas.

Vérifiez aussi dans l'autre sens : -ngl 0 force le CPU pur, et si ça tourne à la même vitesse que votre config « GPU », le GPU ne faisait rien.

Threads (mode CPU uniquement)

En mode CPU, réglez -t sur le nombre de cœurs physiques, pas de threads SMT : sur une puce 8 cœurs/16 threads, utilisez 8. Plus de threads que de cœurs physiques crée de la contention et ralentit le décodage. Le traitement du prompt a une option séparée (--threads-batch) ; la même règle s'applique.

Mémoire : mmap et --mlock

llama.cpp mmappe le fichier modèle par défaut : le démarrage est rapide et les couches intactes ne coûtent pas de RAM. La contrepartie est que l'OS peut évincer des pages sous pression mémoire, provoquant des pauses mystérieuses des heures après le début d'une session. --mlock épingle le modèle pour qu'il ne puisse pas être évincé — utile sur des machines chargées, au prix de verrouiller des gigaoctets loin de tout le reste. Ollama gère cela en interne ; les utilisateurs de llama.cpp brut sur machines partagées devraient connaître l'option.

Flash attention

-fa / --flash-attn réduit le trafic mémoire dans l'étape d'attention et est activé (ou auto) par défaut dans les versions récentes de llama.cpp. Elle compte le plus en long contexte, et la quantification du cache V l'exige dans les versions actuelles. Si une version fraîche se comporte mal sur votre backend GPU, c'est la première option à basculer — et sur toute version récente, la première chose à vérifier est qu'elle ne s'est pas éteinte en silence.

Quantification du cache KV

--cache-type-k q8_0 --cache-type-v q5_0 stocke le cache KV en 8 bits/5 bits au lieu de flottants 16 bits, coupant la mémoire KV environ de moitié ou mieux à un coût de qualité mineur — donc plus de contexte dans la même VRAM. Ce qu'est le cache KV et les maths de taille exactes : cache KV.

Gain typique : K q8_0 plus V q5_0 divise à peu près la taille KV par deux avec un changement à peine visible sur les tâches de chat — vérifiez sur vos propres charges avant d'y croire.

Taille de lot de prompt

-b / --batch-size est la taille de morceau du préremplissage (traitement du prompt). De plus gros lots signifient un temps jusqu'au premier jeton plus court sur les longs prompts, au prix d'un peu de VRAM de pointe. Si les longs collages semblent lents à démarrer, montez-le avant d'incriminer le modèle.

Étirer le contexte : rope scaling et YaRN

--rope-scaling yarn --rope-factor 2.0 étire un modèle natif 32k vers 64k en rééchelonnant les fréquences positionnelles. Ça marche, avec une pente de qualité : la dégradation est faible près de la fenêtre native et croît à mesure que vous étirez au-delà. Pour ce qui compte, préférez un modèle dont le contexte natif couvre déjà votre besoin à étirer une fenêtre plus petite (voir choisir un modèle).

À ce jour, Ollama n'expose pas le rope scaling dans son Modelfile ; les expériences de contexte étiré passent par le lancement direct de llama.cpp.

Une ligne de lancement annotée

llama-server -m qwen3-8b-q4_k_m.gguf --host 127.0.0.1 --port 8080 -c 16384 -ngl 99 -fa on -b 2048 --cache-type-k q8_0 --cache-type-v q5_0

Équivalents Ollama

# par modèle, dans un Modelfile :
PARAMETER num_ctx 16384
PARAMETER num_gpu 99

# ou globalement, avant le démarrage du service :
export OLLAMA_CONTEXT_LENGTH=16384
export OLLAMA_FLASH_ATTENTION=1
export OLLAMA_KV_CACHE_TYPE=q8_0

Ollama journalise un avertissement quand une requête dépasse num_ctx — lisez le log une fois après avoir changé l'un de ces réglages. Les changements via variables d'env exigent un redémarrage du service.

Pour voir ce qu'Ollama a réellement appliqué : ollama show model --modelfile affiche les paramètres résolus, et OLLAMA_DEBUG=1 fait journaliser au service le vrai contexte et les comptes de délestage.

Les échantillonneurs ne sont pas des réglages moteur

Température, top-p, pénalité de répétition — ceux-là façonnent quel jeton est choisi, pas la vitesse ni ce qui tient en mémoire. Ils vivent dans échantillonnage. Si la sortie est bizarre mais que vitesse et mémoire vont bien, vous voulez cette page-là, pas celle-ci.

La règle

Réglez le contexte explicitement. Vérifiez avec une ligne de log — n_ctx = ... et offloaded N/N layers — à chaque changement de configuration de lancement. Les défauts sont accordés pour que la première démo démarre, pas pour que votre charge soit servie.

llm_load_tensors: offloaded 33/33 layers to GPU
n_ctx = 16384

Les deux lignes s'affichent quelques secondes après le lancement. Cherchez-les une fois et la configuration cesse d'être du folklore.

Voir aussi : vitesse · cache KV · échantillonnage · servir un endpoint