🥝Kimi K2.5 : guide pour exécuter localement
Guide pour exécuter Kimi-K2.5 sur votre propre appareil local !
Kimi-K2.5 est le nouveau modèle de Moonshot qui atteint des performances SOTA en vision, codage, tâches agentiques et de chat. Le modèle de raisonnement hybride d’1T de paramètres nécessite 600 Go d’espace disque, tandis que le Unsloth Dynamique 1,8 bits version réduit cela à 240 Go (-60 % de taille): Kimi-K2.5-GGUF
Tous les téléchargements utilisent Unsloth Dynamic 2.0 pour des performances SOTA Aider et MMLU 5-shot. Voyez comment nos GGUFs Dynamiques 1–2 bits performent sur benchmarks de codage.
⚙️ Exigences recommandées
Vous avez besoin de >240 Go d’espace disque pour exécuter la quantification 1-bit !
Pour de meilleures performances, assurez-vous que votre mémoire totale disponible (VRAM + RAM système) dépasse la taille du fichier de modèle quantifié que vous téléchargez. Sinon, llama.cpp peut toujours fonctionner via déchargement sur SSD/HDD, mais l'inférence sera plus lente.
La quantification 1,8 bit (UD-TQ1_0) fonctionnera sur un seul GPU 24 Go si vous déchargez toutes les couches MoE sur la RAM système (ou un SSD rapide). Avec ~256 Go de RAM, attendez-vous à ~10 tokens/s. Le modèle complet Kimi K2.5 fait 630 Go et nécessite généralement au moins 4× GPU H200.
Si le modèle tient, vous obtiendrez >40 tokens/s en utilisant un B200.
Pour exécuter le modèle en quasi pleine précision, vous pouvez utiliser les quants 4-bit ou 5-bit. Vous pouvez utiliser n’importe quel bit supérieur pour être en sécurité.
Pour de bonnes performances, visez >240 Go de mémoire unifiée (ou RAM+VRAM combinées) pour atteindre >10 tokens/s. Si vous êtes en dessous, cela fonctionnera mais la vitesse chutera (llama.cpp peut toujours fonctionner via mmap/déchargement sur disque) et peut passer d’environ ~10 tokens/s à <2 token/s.
Nous recommandons UD-Q2_K_XL (375 Go) comme bon compromis taille/qualité. Règle générale : RAM+VRAM ≈ taille du quant ; sinon cela fonctionnera toujours, juste plus lent à cause du déchargement.
🥝 Guide d’exécution Kimi K2.5
Kimi-K2.5 nécessite différents paramètres d’échantillonnage selon les cas d’utilisation.
Actuellement il y a pas de support vision pour le modèle mais espérons que llama.cpp le prendra en charge bientôt.
Pour exécuter le modèle en pleine précision, vous n’avez qu’à utiliser les GGUF Dynamiques 4-bit ou 5-bit (par ex. UD_Q4_K_XL) car le modèle a été initialement publié au format INT4.
Vous pouvez choisir une quantification avec plus de bits par précaution en cas de petites différences de quantification, mais dans la plupart des cas cela est inutile.
Différences de Kimi K2.5 par rapport à Kimi K2 Thinking
Les deux modèles utilisent une architecture MoE DeepSeek V3 modifiée.
rope_scaling.beta_fastK2.5 utilise 32.0 contre 1.0 pour K2 Thinking.MoonViT est l’encodeur vision en résolution native de 200M de paramètres. Il est similaire à celui utilisé dans Kimi-VL-A3B-Instruct.
🌙 Guide d’utilisation :
Selon Moonshot AI, voici les paramètres recommandés pour l’inférence de Kimi K2.5 :
temperature = 0.6
temperature = 1.0
top_p = 0.95
top_p = 0.95
min_p = 0.01
min_p = 0.01
Définir la temperature 1.0 pour réduire la répétition et l’incohérence.
Longueur de contexte suggérée = 98 304 (jusqu’à 256K)
Remarque : L’utilisation d’outils différents peut nécessiter des paramètres différents
Nous recommandons de définir min_p à 0.01 pour supprimer l’apparition de tokens improbables avec de faibles probabilités. Et désactiver ou définir repeat penalty = 1.0 si nécessaire.
Modèle de chat pour Kimi K2.5
Exécution de tokenizer.apply_chat_template([{"role": "user", "content": "What is 1+1?"},]) donne :
✨ Exécuter Kimi K2.5 dans llama.cpp
Pour ce guide nous exécuterons la plus petite quantification 1-bit qui fait 240 Go. N’hésitez pas à changer le type de quantification en 2-bit, 3-bit etc. Pour exécuter le modèle en quasi pleine précision, vous pouvez utiliser les quants 4-bit ou 5-bit. Vous pouvez utiliser n’importe quel bit supérieur pour être en sécurité.
Obtenez la dernière
llama.cppsur GitHub ici. Vous pouvez également suivre les instructions de compilation ci-dessous. Changez-DGGML_CUDA=ONen-DGGML_CUDA=OFFsi vous n'avez pas de GPU ou si vous voulez seulement une inférence CPU. Pour appareils Apple Mac / Metal, définissez-DGGML_CUDA=OFFpuis continuez comme d'habitude - le support Metal est activé par défaut.
Si vous voulez utiliser
llama.cppdirectement pour charger des modèles, vous pouvez faire ce qui suit : (:UD-TQ1_0) est le type de quantification. Vous pouvez aussi télécharger via Hugging Face (point 3). Ceci est similaire àollama run. Utilisezexport LLAMA_CACHE="dossier"pour forcerllama.cppà sauvegarder dans un emplacement spécifique.
LLAMA_SET_ROWS=1 rend llama.cpp un peu plus rapide ! Utilisez-le ! --fit on ajuste automatiquement les modèles sur tous vos GPU et CPU de façon optimale.
--fit onadaptera automatiquement le modèle à votre système. Si vous n’utilisez pas--fit onet que vous avez environ 360 Go de mémoire GPU combinée, retirez-ot ".ffn_.*_exps.=CPU"pour obtenir la vitesse maximale.
Utilisez --fit on pour l’ajustement automatique sur GPU et CPU. Si cela ne fonctionne pas, voyez ci‑dessous :
Veuillez essayer -ot ".ffn_.*_exps.=CPU" pour décharger toutes les couches MoE sur le CPU ! Cela vous permet effectivement de placer toutes les couches non-MoE sur 1 GPU, améliorant les vitesses de génération. Vous pouvez personnaliser l’expression regex pour décharger plus de couches si vous disposez de plus de capacité GPU.
Si vous avez un peu plus de mémoire GPU, essayez -ot ".ffn_(up|down)_exps.=CPU" Ceci décharge les couches MoE de projection up et down.
Essayez -ot ".ffn_(up)_exps.=CPU" si vous avez encore plus de mémoire GPU. Cela décharge uniquement les couches MoE de projection up.
Et enfin déchargez toutes les couches via -ot ".ffn_.*_exps.=CPU" Ceci utilise le moins de VRAM.
Vous pouvez aussi personnaliser la regex, par exemple -ot "\.(6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(gate|up|down)_exps.=CPU" signifie décharger les couches gate, up et down MoE mais seulement à partir de la 6e couche.
Téléchargez le modèle via (après avoir installé
pip install huggingface_hub hf_transfer). Nous recommandons d’utiliser notre quant dynamique 2bit UD-Q2_K_XL pour équilibrer taille et précision. Toutes les versions sur : huggingface.co/unsloth/Kimi-K2.5-GGUF Si les téléchargements se bloquent, voyez Hugging Face Hub, débogage XET
Si vous constatez que les téléchargements se bloquent à 90–95 % environ, veuillez consulter notre guide de dépannage.
Exécutez n’importe quelle invite.
Éditez
--ctx-size 16384pour la longueur de contexte. Vous pouvez aussi l’omettre pour découverte automatique de la longueur de contexte via--fit on
À titre d’exemple essayez : "Create a Flappy Bird game in HTML", et vous obtiendrez :

✨ Déployer avec llama-server et la bibliothèque de complétions d’OpenAI
En utilisant --kv-unified peut accélérer le service d’inférence dans llama.cpp ! Voir https://www.reddit.com/r/LocalLLaMA/comments/1qnwa33/glm_47_flash_huge_performance_improvement_with_kvu/
Après avoir installé llama.cpp comme indiqué Kimi K2.5, vous pouvez utiliser ce qui suit pour lancer un serveur compatible OpenAI :
Ensuite utilisez la bibliothèque Python d’OpenAI après pip install openai :
Et nous obtenons :

Et dans l’autre écran llama-server :

📊 Références de performance
Vous pouvez voir ci‑dessous davantage de benchmarks au format tableau :

Raisonnement et Connaissance
HLE-Full
30.1
34.5
30.8
37.5
25.1†
-
HLE-Full (avec outils)
50.2
45.5
43.2
45.8
40.8†
-
AIME 2025
96.1
100
92.8
95.0
93.1
-
HMMT 2025 (févr.)
95.4
99.4
92.9*
97.3*
92.5
-
IMO-AnswerBench
81.8
86.3
78.5*
83.1*
78.3
-
GPQA-Diamond
87.6
92.4
87.0
91.9
82.4
-
MMLU-Pro
87.1
86.7*
89.3*
90.1
85.0
-
Image et Vidéo
MMMU-Pro
78.5
79.5*
74.0
81.0
-
69.3
CharXiv (RQ)
77.5
82.1
67.2*
81.4
-
66.1
MathVision
84.2
83.0
77.1*
86.1*
-
74.6
MathVista (mini)
90.1
82.8*
80.2*
89.8*
-
85.8
ZeroBench
9
9*
3*
8*
-
4*
ZeroBench (avec outils)
11
7*
9*
12*
-
3*
OCRBench
92.3
80.7*
86.5*
90.3*
-
87.5
OmniDocBench 1.5
88.8
85.7
87.7*
88.5
-
82.0*
InfoVQA (val)
92.6
84*
76.9*
57.2*
-
89.5
SimpleVQA
71.2
55.8*
69.7*
69.7*
-
56.8*
WorldVQA
46.3
28.0
36.8
47.4
-
23.5
VideoMMMU
86.6
85.9
84.4*
87.6
-
80.0
MMVU
80.4
80.8*
77.3
77.5
-
71.1
MotionBench
70.4
64.8
60.3
70.3
-
-
VideoMME
87.4
86.0*
-
88.4*
-
79.0
LongVideoBench
79.8
76.5*
67.2*
77.7*
-
65.6*
LVBench
75.9
-
-
73.5*
-
63.6
Codage
SWE-Bench Vérifié
76.8
80.0
80.9
76.2
73.1
-
SWE-Bench Pro
50.7
55.6
55.4*
-
-
-
SWE-Bench Multilingue
73.0
72.0
77.5
65.0
70.2
-
Terminal Bench 2.0
50.8
54.0
59.3
54.2
46.4
-
PaperBench
63.5
63.7*
72.9*
-
47.1
-
CyberGym
41.3
-
50.6
39.9*
17.3*
-
SciCode
48.7
52.1
49.5
56.1
38.9
-
OJBench (cpp)
57.4
-
54.6*
68.5*
54.7*
-
LiveCodeBench (v6)
85.0
-
82.2*
87.4*
83.3
-
Contexte long
Longbench v2
61.0
54.5*
64.4*
68.2*
59.8*
-
AA-LCR
70.0
72.3*
71.3*
65.3*
64.3*
-
Recherche agentique
BrowseComp
60.6
65.8
37.0
37.8
51.4
-
BrowseComp (gestion du contexte)
74.9
65.8
57.8
59.2
67.6
-
BrowseComp (essaim d'agents)
78.4
-
-
-
-
-
WideSearch (item-f1)
72.7
-
76.2*
57.0
32.5*
-
WideSearch (item-f1 Essaim d'agents)
79.0
-
-
-
-
-
DeepSearchQA
77.1
71.3*
76.1*
63.2*
60.9*
-
FinSearchCompT2&T3
67.8
-
66.2*
49.9
59.1*
-
Seal-0
57.4
45.0
47.7*
45.5*
49.5*
-
Notes
*= score réévalué par les auteurs (précédemment non disponible publiquement).†= le score DeepSeek V3.2 correspond à son sous-ensemble texte uniquement (comme indiqué en note de bas de page).-= non évalué / non disponible.
Mis à jour
Ce contenu vous a-t-il été utile ?

