🌠QwQ-32B : comment l'exécuter efficacement

Comment exécuter efficacement QwQ-32B avec nos corrections de bugs et sans générations sans fin + GGUF.

Qwen a publié QwQ-32B - un modèle de raisonnement avec des performances comparables à DeepSeek-R1 sur de nombreux benchmarks. Cependant, les gens ont rencontré des générations infinies, de nombreuses répétitions, des problèmes de token <think> et des problèmes de fine-tuning. Nous espérons que ce guide vous aidera à déboguer et à corriger la plupart des problèmes !

Nos téléchargements du modèle avec nos correctifs fonctionnent très bien pour le fine-tuning, vLLM et Transformers. Si vous utilisez llama.cpp et des moteurs qui utilisent llama.cpp comme backend, suivez nos instructions ici pour corriger les générations infinies.

Téléchargements Unsloth de QwQ-32B avec nos correctifs :

⚙️ Paramètres officiels recommandés

Selon Qwen, voici les paramètres recommandés pour l'inférence :

  • Température de 0,6

  • Top_K de 40 (ou 20 à 40)

  • Min_P de 0,00 (facultatif, mais 0,01 fonctionne bien, la valeur par défaut de llama.cpp est 0,1)

  • Top_P de 0.95

  • Pénalité de répétition de 1.0. (1.0 signifie désactivé dans llama.cpp et transformers)

  • Modèle de chat : <|im_start|>user\nCréer un jeu Flappy Bird en Python.<|im_end|>\n<|im_start|>assistant\n<think>\n

👍 Paramètres recommandés pour llama.cpp

Nous avons remarqué que beaucoup de personnes utilisent un pénalité de répétition supérieure à 1.0. Par exemple 1.1 à 1.5. Cela interfère en fait avec les mécanismes d'échantillonnage de llama.cpp. Le but d'une pénalité de répétition est de pénaliser les générations répétées, mais nous avons constaté que cela ne fonctionne pas comme prévu.

Désactiver pénalité de répétition fonctionne aussi (c.-à-d. le régler à 1.0), mais nous avons trouvé son utilisation utile pour pénaliser les générations infinies.

Pour l'utiliser, nous avons constaté que vous devez également modifier l'ordre des échantillonneurs dans llama.cpp avant d'appliquer pénalité de répétition, sinon il y aura des générations infinies. Ajoutez donc ceci :

Par défaut, llama.cpp utilise cet ordre :

Nous réorganisons essentiellement temperature et dry, et déplaçons min_p vers l'avant. Cela signifie que nous appliquons les échantillonneurs dans cet ordre :

Si vous rencontrez encore des problèmes, vous pouvez augmenter--repeat-penalty 1.0 à 1.2 ou 1.3.

Avec l'aimable autorisation de @krist486 pour avoir attiré mon attention sur les directives d'échantillonnage de llama.cpp.

☀️ Pénalité de répétition Dry

Nous avons étudié l'utilisation de la pénalité dry comme suggéré dans https://github.com/ggml-org/llama.cpp/blob/master/examples/main/README.md en utilisant une valeur de 0.8, mais nous avons en fait constaté que cela provoquait plutôt des problèmes de syntaxe, en particulier pour le code. Si vous rencontrez encore des problèmes, vous pouvez augmenterla pénalité dry à 0.8.

Utiliser notre ordre d'échantillonnage inversé peut également aider si vous décidez d'utiliser la pénalité dry.

🦙 Tutoriel : comment exécuter QwQ-32B dans Ollama

  1. Installez ollama si vous ne l’avez pas déjà fait !

  1. Lancez le modèle ! Notez que vous pouvez appeler ollama servedans un autre terminal si cela échoue ! Nous incluons tous nos correctifs et paramètres suggérés (temperature, min_p, etc.) dans param dans notre téléchargement Hugging Face !

📖 Tutoriel : comment exécuter QwQ-32B dans llama.cpp

  1. Obtenez la dernière version llama.cpp sur GitHub ici. Vous pouvez également suivre les instructions de compilation ci-dessous. Changez -DGGML_CUDA=ON en -DGGML_CUDA=OFF si vous n’avez pas de GPU ou si vous souhaitez simplement une inférence CPU. Pour les appareils Apple Mac / Metal, définissez -DGGML_CUDA=OFF puis continuez comme d'habitude - la prise en charge de Metal est activée par défaut.

  1. Téléchargez le modèle via (après avoir installé pip install huggingface_hub hf_transfer ). Vous pouvez choisir Q4_K_M, ou d’autres versions quantifiées (comme BF16 en précision complète). Plus de versions sur : https://huggingface.co/unsloth/QwQ-32B-GGUF

  1. Exécutez le test Flappy Bird d'Unsloth, qui enregistrera la sortie dans Q4_K_M_yes_samplers.txt

  2. Modifier --threads 32 pour le nombre de threads CPU, --ctx-size 16384 pour la longueur du contexte, --n-gpu-layers 99 pour le déchargement GPU, selon le nombre de couches. Essayez de l’ajuster si votre GPU manque de mémoire. Supprimez-le aussi si vous n'avez qu'une inférence CPU.

  3. Nous utilisons --repeat-penalty 1.1 et --dry-multiplier 0.5 que vous pouvez ajuster.

L’entrée complète de notre https://unsloth.ai/blog/deepseekr1-dynamic article de blog 1.58bit est :

Le début et la fin de la sortie finale Python après suppression des parties de réflexion :

Sortie Python finale complète (parties de réflexion supprimées) :
  1. Lorsque nous l'exécutons, nous obtenons un jeu jouable !

  1. Maintenant essayez la même chose sans nos correctifs ! Supprimez donc --samplers "top_k;top_p;min_p;temperature;dry;typ_p;xtc" Cela enregistrera la sortie dans Q4_K_M_no_samplers.txt

Vous obtiendrez quelques boucles, mais une syntaxe Python problématiquement incorrecte et bien d'autres problèmes. Par exemple, ce qui suit semble correct, mais est faux ! C.-à-d. ligne 39 pipes.clear() ### <<< NameError: name 'pipes' is not defined. Did you forget to import 'pipes' ?

  1. Si vous utilisez --repeat-penalty 1.5, c'est encore pire et plus évident, avec une syntaxe totalement incorrecte en fait.

  1. Vous vous demandez peut-être si c'est Q4_K_M ? B16, c.-à-d. la pleine précision devrait bien fonctionner, non ? Incorrect - les sorties échouent à nouveau si nous n'utilisons pas notre correctif --samplers "top_k;top_p;min_p;temperature;dry;typ_p;xtc" lors de l'utilisation d'une pénalité de répétition.

🌄 Ça ne marche toujours pas ? Essayez Min_p = 0.1, Temperature = 1.5

Selon l'article sur Min_p https://arxiv.org/pdf/2407.01082, pour des sorties plus créatives et diversifiées, et si vous voyez encore des répétitions, essayez de désactiver top_p et top_k !

Une autre approche consiste à désactiver min_p directement, puisque llama.cpp utilise par défaut min_p = 0.1!

🤔 le token <think> n'est pas affiché ?

Certaines personnes signalent que, comme <think> est ajouté par défaut dans le modèle de chat, certains systèmes n'affichent pas correctement les traces de réflexion. Vous devrez modifier manuellement le modèle Jinja de :

vers un autre en supprimant le <think>\n à la fin. Le modèle devra maintenant ajouter manuellement <think>\n pendant l'inférence, ce qui peut ne pas toujours réussir. DeepSeek a également modifié tous les modèles pour ajouter par défaut un <think> token afin de forcer le modèle à passer en mode raisonnement.

Alors changez {%- if add_generation_prompt %} {{- '<|im_start|>assistant\n<think>\n' }} {%- endif %} en {%- if add_generation_prompt %} {{- '<|im_start|>assistant\n' }} {%- endif %}

c.-à-d. supprimez <think>\n

Modèle jinja complet avec la partie <think>\n supprimée

Notes supplémentaires

Nous avons d'abord pensé peut-être :

  1. La longueur de contexte de QwQ n'était pas nativement de 128K, mais plutôt de 32K avec l'extension YaRN. Par exemple, dans le fichier readme de https://huggingface.co/Qwen/QwQ-32B, nous voyons :

Nous avons essayé de remplacer la gestion YaRN de llama.cpp, mais rien n'a changé.

  1. Nous avons aussi pensé que peut-être l'epsilon de la couche RMS Layernorm était गलत - pas 1e-5 mais peut-être 1e-6. Par exemple ceci a rms_norm_eps=1e-06, tandis que ceci a rms_norm_eps=1e-05 . Nous l'avons aussi remplacé, mais cela n'a pas fonctionné :

  1. Nous avons également testé si les identifiants du tokenizer correspondaient entre llama.cpp et les Transformers normaux, avec l'aimable autorisation de @kalomaze. Ils correspondaient, donc ce n'était pas le coupable.

Nous présentons nos résultats expérimentaux ci-dessous :

Précision BF16 complète sans correction d'échantillonnage
Précision BF16 complète avec correction d'échantillonnage
Précision Q4_K_M sans correction d'échantillonnage
Précision Q4_K_M avec correction d'échantillonnage

✏️ Correctifs de bug du tokenizer

🛠️ Quantifications dynamiques 4 bits

Nous avons également téléchargé des quantifications dynamiques 4 bits qui améliorent la précision par rapport aux quantifications 4 bits naïves ! Nous joignons l'analyse du graphique d'erreur de quantification QwQ pour les erreurs de quantification des activations et des poids :

Nous avons téléchargé des quantifications dynamiques 4 bits vers : https://huggingface.co/unsloth/QwQ-32B-unsloth-bnb-4bit

Depuis vLLM 0.7.3 (20 février 2025) https://github.com/vllm-project/vllm/releases/tag/v0.7.3, vLLM prend désormais en charge le chargement des quantifications dynamiques 4 bits d'Unsloth !

Tous nos GGUF se trouvent à https://huggingface.co/unsloth/QwQ-32B-GGUF!

Mis à jour

Ce contenu vous a-t-il été utile ?