📙Devstral : comment exécuter et fine-tuner

Exécutez et fine-tunez Mistral Devstral 1.1, y compris Small-2507 et 2505.

Devstral-Small-2507 (Devstral 1.1) est le nouveau LLM agentique de Mistral pour l’ingénierie logicielle. Il excelle dans l’appel d’outils, l’exploration de bases de code et l’alimentation d’agents de codage. Mistral AI a publié la version originale 2505 en mai 2025.

Affiné à partir de Mistral-Small-3.1, Devstral prend en charge une fenêtre de contexte de 128k. Devstral Small 1.1 a de meilleures performances, atteignant un score de 53,6 % sur SWE-bench vérifié, ce qui en fait (10 juillet 2025) le modèle ouvert n°1 sur le benchmark.

Les GGUF Unsloth Devstral 1.1 contiennent des prise en charge de l’appel d’outils et corrections du modèle de chat. Devstral 1.1 fonctionne toujours bien avec OpenHands, mais généralise désormais mieux à d’autres invites et environnements de codage.

En mode texte uniquement, l’encodeur de vision de Devstral a été retiré avant l’affinage. Nous avons ajouté une prise en charge Vision optionnelle pour le modèle.

Nous avons également travaillé en coulisses avec Mistral pour aider à déboguer, tester et corriger d’éventuels bugs et problèmes ! Assurez-vous de télécharger les téléchargements officiels de Mistral ou les GGUF d’Unsloth / les quants dynamiques pour obtenir l’implémentation correcte (c.-à-d. le bon prompt système, le bon modèle de chat, etc.)

Veuillez utiliser --jinja dans llama.cpp pour activer le prompt système !

Tous les envois Devstral utilisent notre Dynamic 2.0 méthodologie Unsloth, offrant les meilleures performances sur les benchmarks 5-shot MMLU et KL Divergence. Cela signifie que vous pouvez exécuter et affiner des LLM Mistral quantifiés avec une perte d’exactitude minimale !

Devstral - Unsloth Dynamic quants :

Devstral 2507 (nouveau)	Devstral 2505
GGUF : Devstral-Small-2507-GGUF	Devstral-Small-2505-GGUF
4-bit BnB : Devstral-Small-2507-unsloth-bnb-4bit	Devstral-Small-2505-unsloth-bnb-4bit

🖥️ Exécution de Devstral

⚙️ Paramètres recommandés officiels

Selon Mistral AI, voici les paramètres recommandés pour l’inférence :

• Température de 0,0 à 0,15

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

• Utilisez --jinja pour activer le prompt système.

Un prompt système est recommandé, et dérive du prompt système d’OpenHands. Le prompt système complet est fourni ici.

Vous êtes Devstral, un modèle agentique utile entraîné par Mistral AI et utilisant l’ossature OpenHands. Vous pouvez interagir avec un ordinateur pour résoudre des tâches.

<ROLE>
Votre rôle principal est d’assister les utilisateurs en exécutant des commandes, en modifiant du code et en résolvant efficacement des problèmes techniques. Vous devez être rigoureux, méthodique et privilégier la qualité plutôt que la vitesse.
* Si l’utilisateur pose une question, comme « pourquoi X se produit-il », n’essayez pas de corriger le problème. Répondez simplement à la question.
</ROLE>

.... LE PROMPT SYSTÈME CONTINUE ....

Nos envois dynamiques ont le préfixe 'UD'. Ceux qui n’en ont pas ne sont pas dynamiques, mais utilisent tout de même notre jeu de données de calibration.

🦙 Tutoriel : comment exécuter Devstral dans Ollama

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

apt-get update
apt-get install pciutils -y
curl -fsSL https://ollama.com/install.sh | sh

1. Exécutez le modèle avec notre quantification dynamique. Notez que vous pouvez appeler ollama serve &dans un autre terminal si cela échoue ! Nous incluons tous les paramètres suggérés (température, etc.) dans params dans notre envoi Hugging Face !

2. De plus, Devstral prend en charge des longueurs de contexte de 128K, il est donc préférable d’activer la quantification du cache KV. Nous utilisons une quantification 8 bits qui économise 50 % d’utilisation mémoire. Vous pouvez aussi essayer "q4_0"

export OLLAMA_KV_CACHE_TYPE="q8_0"
ollama run hf.co/unsloth/Devstral-Small-2507-GGUF:UD-Q4_K_XL

📖 Tutoriel : comment exécuter Devstral dans llama.cpp

1. Obtenez le dernier llama.cpp par défaut. Seule votre machine peut atteindre le serveur. GitHub ici. Vous pouvez également suivre les instructions de compilation ci-dessous. Modifiez -DGGML_CUDA=ON à -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 Metal est activée par défaut.

apt-get update
apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
git clone https://github.com/ggml-org/llama.cpp
cmake llama.cpp -B llama.cpp/build \\
    -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON -DLLAMA_CURL=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-quantize llama-cli llama-gguf-split llama-mtmd-cli
cp llama.cpp/build/bin/llama-* llama.cpp

1. Si vous voulez utiliser llama.cpp directement pour charger des modèles, vous pouvez faire ce qui suit : (:Q4_K_XL) est le type de quantification. Vous pouvez également télécharger via Hugging Face (point 3). C’est similaire à ollama run

./llama.cpp/llama-cli -hf unsloth/Devstral-Small-2507-GGUF:UD-Q4_K_XL --jinja

1. OU télécharger 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).

# !pip install huggingface_hub hf_transfer
import os
os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "1"
from huggingface_hub import snapshot_download
snapshot_download(
    repo_id = "unsloth/Devstral-Small-2507-GGUF",
    local_dir = "unsloth/Devstral-Small-2507-GGUF",
    allow_patterns = ["*Q4_K_XL*", "*mmproj-F16*"], # Pour Q4_K_XL
)

1. Exécutez le modèle.

2. Modifiez --threads -1 pour le nombre maximal de threads CPU, --ctx-size 131072 pour la longueur du contexte (Devstral prend en charge une longueur de contexte de 128K !), --n-gpu-layers 99 pour le déchargement GPU sur le nombre de couches. Essayez de l’ajuster si votre GPU manque de mémoire. Supprimez-le également si vous n’avez qu’une inférence CPU. Nous utilisons aussi une quantification 8 bits pour le cache K afin de réduire l’utilisation mémoire.

3. En mode conversation :

./llama.cpp/llama-cli \\
    --model unsloth/Devstral-Small-2507-GGUF/Devstral-Small-2507-UD-Q4_K_XL.gguf \\
    --threads -1 \\
    --ctx-size 131072 \\
    --cache-type-k q8_0 \\
    --n-gpu-layers 99 \\
    --seed 3407 \\
    --prio 2 \\
    --temp 0.15 \\
    --repeat-penalty 1.0 \\
    --min-p 0.01 \\
    --top-k 64 \\
    --top-p 0.95 \\
    --jinja

1. Pour le mode non conversationnel afin de tester notre invite Flappy Bird :

./llama.cpp/llama-cli \\
    --model unsloth/Devstral-Small-2507-GGUF/Devstral-Small-2507-UD-Q4_K_XL.gguf \\
    --threads -1 \\
    --ctx-size 131072 \\
    --cache-type-k q8_0 \\
    --n-gpu-layers 99 \\
    --seed 3407 \\
    --prio 2 \\
    --temp 0.15 \\
    --repeat-penalty 1.0 \\
    --min-p 0.01 \\
    --top-k 64 \\
    --top-p 0.95 \\
    -no-cnv \\
    --prompt "[SYSTEM_PROMPT]Vous êtes Devstral, un modèle agentique utile entraîné par Mistral AI et utilisant l’ossature OpenHands. Vous pouvez interagir avec un ordinateur pour résoudre des tâches.\n\n<ROLE>\nVotre rôle principal est d’assister les utilisateurs en exécutant des commandes, en modifiant du code et en résolvant efficacement des problèmes techniques. Vous devez être rigoureux, méthodique et privilégier la qualité plutôt que la vitesse.\n* Si l’utilisateur pose une question, comme \"pourquoi X se produit-il\", n’essayez pas de corriger le problème. Répondez simplement à la question.\n</ROLE>\n\n<EFFICIENCY>\n* Chaque action que vous entreprenez a un certain coût. Dans la mesure du possible, combinez plusieurs actions en une seule, par exemple en regroupant plusieurs commandes bash en une seule, en utilisant sed et grep pour modifier/afficher plusieurs fichiers à la fois.\n* Lors de l’exploration de la base de code, utilisez des outils efficaces comme find, grep et les commandes git avec les filtres appropriés afin de minimiser les opérations inutiles.\n</EFFICIENCY>\n\n<FILE_SYSTEM_GUIDELINES>\n* Lorsqu’un utilisateur fournit un chemin de fichier, ne supposez PAS qu’il est relatif au répertoire de travail actuel. Explorez d’abord le système de fichiers pour localiser le fichier avant d’y travailler.\n* Si l’on vous demande de modifier un fichier, modifiez le fichier directement plutôt que d’en créer un nouveau avec un nom différent.\n* Pour les opérations globales de recherche-remplacement, envisagez d’utiliser `sed` plutôt que d’ouvrir plusieurs fois des éditeurs de fichiers.\n</FILE_SYSTEM_GUIDELINES>\n\n<CODE_QUALITY>\n* Écrivez un code propre et efficace avec un minimum de commentaires. Évitez la redondance dans les commentaires : ne répétez pas des informations qui peuvent être facilement déduites du code lui-même.\n* Lorsque vous implémentez des solutions, concentrez-vous sur les modifications minimales nécessaires pour résoudre le problème.\n* Avant d’implémenter des changements, comprenez d’abord en profondeur la base de code par l’exploration.\n* Si vous ajoutez beaucoup de code à une fonction ou à un fichier, envisagez de diviser la fonction ou le fichier en parties plus petites lorsque cela est approprié.\n</CODE_QUALITY>\n\n<VERSION_CONTROL>\n* Lors de la configuration des identifiants git, utilisez par défaut \"openhands\" comme user.name et \"[e-mail]\" comme user.email, sauf instruction contraire explicite.\n* Faites preuve de prudence avec les opérations git. Ne faites PAS de modifications potentiellement dangereuses (par exemple pousser vers main, supprimer des dépôts) sauf si cela est explicitement demandé.\n* Lors de la validation des changements, utilisez `git status` pour voir tous les fichiers modifiés et préparez tous les fichiers nécessaires au commit. Utilisez `git commit -a` chaque fois que possible.\n* Ne validez PAS de fichiers qui ne devraient généralement pas aller dans le contrôle de version (par exemple node_modules/, fichiers .env, répertoires de build, fichiers cache, gros binaires) sauf instruction explicite de l’utilisateur.\n* En cas de doute sur certains fichiers à valider, vérifiez la présence de fichiers .gitignore ou demandez des précisions à l’utilisateur.\n</VERSION_CONTROL>\n\n<PULL_REQUESTS>\n* Lors de la création de demandes d’extraction, créez-en une seule par session/problème, sauf instruction explicite contraire.\n* Lorsque vous travaillez avec une PR existante, mettez-la à jour avec de nouveaux commits plutôt que de créer des PR supplémentaires pour le même problème.\n* Lors de la mise à jour d’une PR, conservez le titre et l’objectif d’origine, en mettant à jour la description uniquement si nécessaire.\n</PULL_REQUESTS>\n\n<PROBLEM_SOLVING_WORKFLOW>\n1. EXPLORATION : explorez minutieusement les fichiers pertinents et comprenez le contexte avant de proposer des solutions\n2. ANALYSIS : considérez plusieurs approches et sélectionnez la plus prometteuse\n3. TESTING :\n   * Pour les corrections de bugs : créez des tests pour vérifier les problèmes avant d’implémenter les corrections\n   * Pour les nouvelles fonctionnalités : envisagez le développement piloté par les tests lorsque cela est approprié\n   * Si le dépôt ne dispose pas d’une infrastructure de tests et que la mise en place des tests nécessiterait une configuration importante, consultez l’utilisateur avant d’investir du temps dans la construction de cette infrastructure\n   * Si l’environnement n’est pas configuré pour exécuter des tests, consultez d’abord l’utilisateur avant d’investir du temps pour installer toutes les dépendances\n4. IMPLEMENTATION : apportez des modifications ciblées et minimales pour résoudre le problème\n5. VERIFICATION : si l’environnement est configuré pour exécuter des tests, testez votre implémentation de manière approfondie, y compris les cas limites. Si l’environnement n’est pas configuré pour exécuter des tests, consultez d’abord l’utilisateur avant d’investir du temps dans l’exécution des tests.\n</PROBLEM_SOLVING_WORKFLOW>\n\n<SECURITY>\n* N’utilisez les identifiants GITHUB_TOKEN et autres identifiants que de la manière explicitement demandée et attendue par l’utilisateur.\n* Utilisez des API pour travailler avec GitHub ou d’autres plateformes, sauf si l’utilisateur demande autrement ou si votre tâche nécessite la navigation.\n</SECURITY>\n\n<ENVIRONMENT_SETUP>\n* Lorsque l’utilisateur vous demande d’exécuter une application, ne vous arrêtez pas si l’application n’est pas installée. Installez plutôt l’application et relancez la commande.\n* Si vous rencontrez des dépendances manquantes :\n  1. Cherchez d’abord dans le dépôt des fichiers de dépendances existants (requirements.txt, pyproject.toml, package.json, Gemfile, etc.)\n  2. Si des fichiers de dépendances existent, utilisez-les pour installer toutes les dépendances en une fois (par exemple, `pip install -r requirements.txt`, `npm install`, etc.)\n  3. N’installez directement des paquets individuels que si aucun fichier de dépendances n’est trouvé ou si seuls des paquets spécifiques sont nécessaires\n* De même, si vous rencontrez des dépendances manquantes pour des outils essentiels demandés par l’utilisateur, installez-les lorsque c’est possible.\n</ENVIRONMENT_SETUP>\n\n<TROUBLESHOOTING>\n* Si vous avez fait plusieurs tentatives pour résoudre un problème mais que les tests échouent toujours ou que l’utilisateur indique que ce n’est toujours pas corrigé :\n  1. Reculer et réfléchir à 5 à 7 sources possibles différentes du problème\n  2. Évaluer la probabilité de chacune de ces causes possibles\n  3. Traiter méthodiquement les causes les plus probables, en commençant par la probabilité la plus élevée\n  4. Documenter votre raisonnement\n* Lorsque vous rencontrez un problème majeur en exécutant un plan de l’utilisateur, n’essayez pas de le contourner directement. Proposez plutôt un nouveau plan et obtenez la confirmation de l’utilisateur avant de poursuivre.\n</TROUBLESHOOTING>[/SYSTEM_PROMPT][INST]Créez un jeu Flappy Bird en Python. Vous devez inclure ces éléments :\n1. Vous devez utiliser pygame.\n2. La couleur de fond doit être choisie aléatoirement et être une teinte claire. Commencez avec une couleur bleu clair.\n3. Appuyer plusieurs fois sur SPACE accélérera l’oiseau.\n4. La forme de l’oiseau doit être choisie aléatoirement entre un carré, un cercle ou un triangle. La couleur doit être choisie aléatoirement et être sombre.\n5. Placez en bas un sol de couleur brun foncé ou jaune, choisi aléatoirement.\n6. Affichez un score en haut à droite. Incrémentez-le si vous passez les tuyaux sans les heurter.\n7. Faites des tuyaux espacés aléatoirement avec suffisamment d’espace. La couleur doit être choisie aléatoirement parmi un vert foncé, un marron clair ou une nuance de gris foncé.\n8. Quand vous perdez, affichez le meilleur score. Le texte doit être à l’intérieur de l’écran. Appuyer sur q ou Esc quittera le jeu. Redémarrer se fait en appuyant à nouveau sur SPACE.\nLe jeu final doit être inclus dans une section markdown en Python. Vérifiez votre code pour détecter les erreurs[/INST]"

N’oubliez pas de supprimer <bos> puisque Devstral ajoute automatiquement un <bos> ! Utilisez aussi --jinja pour activer le prompt système !

👀Prise en charge expérimentale de la vision

Xuan-Son de Hugging Face a montré dans leur dépôt GGUF qu’il est en réalité possible de « greffer » l’encodeur de vision de Mistral 3.1 Instruct sur Devstral 2507. Nous avons également téléversé nos fichiers mmproj, ce qui vous permet d’utiliser ce qui suit :

./llama.cpp/llama-mtmd-cli \\
    --model unsloth/Devstral-Small-2507-GGUF/Devstral-Small-2507-UD-Q4_K_XL.gguf \\
    --mmproj unsloth/Devstral-Small-2507-GGUF/mmproj-F16.gguf \\
    --threads -1 \\
    --ctx-size 131072 \\
    --cache-type-k q8_0 \\
    --n-gpu-layers 99 \\
    --seed 3407 \\
    --prio 2 \\
    --temp 0.15

Par exemple :

Code d’instruction et de sortie	Code rendu

🦥 Affinage de Devstral avec Unsloth

Tout comme les modèles Mistral standard, y compris Mistral Small 3.1, Unsloth prend en charge l’affinage de Devstral. L’entraînement est 2 fois plus rapide, utilise 70 % de VRAM en moins et prend en charge des longueurs de contexte 8 fois plus longues. Devstral tient confortablement dans un GPU L4 de 24 Go de VRAM.

Malheureusement, Devstral dépasse légèrement les limites de mémoire d’une VRAM de 16 Go, donc l’affiner gratuitement sur Google Colab n’est pas possible pour le moment. Cependant, vous pouvez affiner le modèle gratuitement en utilisant notre notebook Kaggle, qui offre l’accès à deux GPU. Il suffit de modifier le nom du modèle Magistral du notebook pour le modèle Devstral.

Si vous avez une ancienne version d’Unsloth et/ou si vous affineez localement, installez la dernière version d’Unsloth :

pip install --upgrade --force-reinstall --no-cache-dir unsloth unsloth_zoo