Référence des paramètres d'inférence des LLMs agissants pour Qwen et Gemma

Cette page est une référence pratique pour l’optimisation de l’inférence des LLMs agents (température, top_p, top_k, pénalités, et comment ils interagissent dans les flux de travail multi-étapes et intensifs en outils).

Elle s’inscrit aux côtés du centre d’ingénierie des performances des LLMs et correspond parfaitement à une approche d’hébergement et de service des LLMs—le débit et la planification dominent encore lorsque le modèle est sous-alimenté, mais un échantillonnage instable entraîne des retours et des tokens de sortie avant même que le GPU ne soit saturé.

Cette page consolide :

• les paramètres recommandés par les fournisseurs
• les valeurs par défaut intégrées des GGUF et des API
• les conclusions de la communauté issues du monde réel
• les optimisations des flux de travail agencés

Actuellement, elle se concentre sur :

• Qwen 3.6 (dense et MoE)
• Gemma 4 (dense et MoE)

Si vous utilisez des agents terminaux tels qu’OpenCode, associez cette référence à le comportement des LLMs locaux dans OpenCode afin que les résultats au niveau de la charge de travail et les valeurs par défaut de l’échantillonneur restent alignés.

L’objectif est simple :

Fournir un endroit unique pour configurer les modèles pour les boucles d’agents, le codage et le raisonnement multi-étapes.

---

Tableau de référence TLDR - Tous les modèles (valeurs par défaut agencées)

Modèle	Mode	temp	top_p	top_k	presence_penalty
Qwen 3.5 27B	réflexion général	1.0	0.95	20	0.0
Qwen 3.5 27B	codage	0.6	0.95	20	0.0
Qwen 3.5 35B MoE	réflexion	1.0	0.95	20	1.5
Qwen 3.5 35B MoE	codage	0.6	0.95	20	0.0
Gemma 4 31B	général	1.0	0.95	64	0.0
Gemma 4 31B	codage	1.2	0.95	65	0.0
Gemma 4 26B MoE	général	1.0	0.95	64	0.0
Gemma 4 26B MoE	codage	1.2	0.95	65	0.0

---

Ce que signifie réellement “l’inférence agencée”

La plupart des guides de paramètres supposent :

• le chat
• la complétion en un seul tir
• l’interaction humaine

Les systèmes agencés sont différents.

Ils nécessitent :

• un raisonnement multi-étapes
• l’appel d’outils
• des sorties cohérentes
• une faible propagation des erreurs

Cela change les priorités de réglage.

Changement fondamental

Cas d’utilisation	Priorité
Chat	qualité du langage naturel
Créatif	diversité
Agencé	cohérence + stabilité du raisonnement

---

Réglage de Qwen 3.6

L’importance du Dense vs MoE

Qwen est l’une des rares familles où :

Le MoE nécessite des pénalités différentes

Dense (27B)

• stable
• prévisible
• pas de complexité de routage

Recommandé :

• presence_penalty = 0.0

---

MoE (35B-A3B)

• routage des experts par token
• risque de boucles de répétition

Recommandé :

• presence_penalty = 1.5 (général)
• 0.0 pour le codage

Pourquoi c’est important

Les modèles MoE peuvent rester coincés en réutilisant les mêmes experts.

La pénalité de présence aide à :

• diversifier les chemins des tokens
• améliorer l’exploration du raisonnement

---

Configuration de codage agencé pour Qwen

C’est là que la plupart des gens se trompent.

Configuration correcte

• temperature = 0.6
• top_p = 0.95
• top_k = 20
• presence_penalty = 0.0

Pourquoi une température basse fonctionne

Les agents de codage ont besoin de :

• des sorties déterministes
• d’appels d’outils répétables
• d’un formatage stable

Une température plus élevée :

• brise le JSON
• introduit des API hallucinées
• augmente les retours

---

Réglage de Gemma 4

Gemma se comporte différemment.

Pas de valeurs par défaut officielles

• les fiches modèles sont vides
• les configurations sont implicites
• le réglage réel vient de :
  • Google AI Studio
  • les valeurs par défaut GGUF
  • les benchmarks communautaires

---

La découverte contre-intuitive

Gemma 4 performe mieux avec une température plus élevée.

Comportement observé

Temp	Résultat
0.5	raisonnement médiocre
1.0	ligne de base stable
1.2 à 1.5	meilleures performances de codage

Cela contredit les conseils standards.

---

Pourquoi une température élevée fonctionne ici

Hypothèse :

• la distribution d’entraînement favorise l’exploration
• le mode de raisonnement dépend de la diversité
• le modèle compense le manque de contrôle explicite de la chaîne de pensée

Résultat :

une température plus élevée améliore l’espace de recherche de solutions

---

Configuration de codage agencé pour Gemma

Recommandé :

• temperature = 1.2
• top_p = 0.95
• top_k = 65
• penalties = 0.0

Important

N’appliquez pas aveuglément la règle traditionnelle de “température basse pour le code”.

Gemma est une exception.

---

Mode de réflexion et systèmes d’agents

Qwen et Gemma prennent en charge les modes de raisonnement.

Pourquoi c’est important

Les boucles d’agents nécessitent :

• un raisonnement intermédiaire
• la récupération d’erreurs
• la planification multi-étapes

Règle pratique

Activez toujours le mode de réflexion pour :

• les agents de codage
• l’utilisation d’outils
• les tâches multi-étapes

---

Stratégie de paramètres par cas d’utilisation

Agents de codage

• privilégier le déterminisme
• minimiser les pénalités
• échantillonnage stable

Agents de raisonnement

• température modérée
• permettre l’exploration
• préserver la structure

Appel d’outils

• formatage strict
• faible aléatoire
• motifs de tokens cohérents

Le schéma et les outils JSON sont orthogonaux aux logits ; combinez ces règles d’échantillonnage avec les modèles de sortie structurée pour Ollama et Qwen3 afin que les validateurs voient moins de retours.

---

Valeurs par défaut des fournisseurs vs Réalité

Les valeurs par défaut des fournisseurs sont :

• sûres
• génériques
• non optimisées

Les découvertes de la communauté montrent souvent :

• de meilleures performances
• un réglage spécifique à la tâche
• des ajustements conscients de l’architecture

Exemple

Gemma :

• officiel : aucune guidance
• communauté : une température élevée améliore le codage

Qwen :

• officiel : sections incohérentes
• communauté : les valeurs standardisées convergent

---

Notes de déploiement pratiques

Sous concurrence, la file d’attente et les divisions de mémoire interagissent avec les retours autant que l’échantillonnage—lisez comment Ollama gère les requêtes parallèles en plus des préréglages ci-dessus.

Ollama

• fonctionne bien pour les deux familles
• vérifier la compatibilité GPU
• les valeurs par défaut peuvent différer de la référence

---

vLLM

• prend en charge l’échantillonnage avancé
• stable pour la production
• utiliser des paramètres explicites

---

llama.cpp

• nécessite un ordonnancement des échantillonneurs
• toujours activer jinja pour les modèles modernes
• une chaîne d’échantillonneurs incorrecte réduit la qualité de la sortie

---

Points clés

• il n’existe pas de jeu de paramètres universel
• l’architecture importe plus que la taille du modèle
• les systèmes agencés nécessitent un réglage différent du chat
• les benchmarks communautaires sont souvent en avance sur les fournisseurs

---

Opinion finale

La plupart des guides de paramètres sont dépassés.

Ils supposent :

• l’utilisation en chat
• une température basse pour le code
• des configurations statiques

Les modèles modernes brisent ces hypothèses.

Si vous construisez des systèmes agencés :

considérez l’optimisation de l’inférence comme un problème de conception système de premier ordre

Et non comme un simple fichier de configuration.

---

Orientation future

Cette référence évoluera vers :

• des analyses approfondies par modèle
• des configurations spécifiques aux agents
• un réglage soutenu par des benchmarks

Parce que :

l’inférence est là où la capacité du modèle devient la performance du système