🥝Kimi K2.5 : Guide d'exécution locale
Guide sur l'exécution de 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 hybride de raisonnement de 1T paramètres nécessite 600 Go d'espace disque, tandis que le Unsloth Dynamic 1.8-bit la version quantifiée réduit cela à 240 Go (-60% de taille): Kimi-K2.5-GGUF
Tous les téléversements utilisent Unsloth Dynamic 2.0 pour des performances SOTA sur Aider et MMLU en 5-shot. Voyez comment nos GGUFs dynamiques 1–2 bits se comportent sur benchmarks de codage.
⚙️ Exigences recommandées
Vous avez besoin de >240 Go d'espace disque pour exécuter la quantification 1-bit !
La seule exigence est espace disque + RAM + VRAM ≥ 240 Go. Cela signifie que vous n'avez pas besoin d'avoir autant de RAM ou de VRAM (GPU) pour exécuter le modèle, mais ce sera beaucoup plus lent.
La quantification 1,8-bit (UD-TQ1_0) fonctionnera sur un seul GPU 24 Go si vous déchargez toutes les couches MoE vers 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 quantifications 4-bit ou 5-bit. Vous pouvez utiliser n'importe quel niveau supérieur juste pour être sûr.
Pour de bonnes performances, visez >240 Go de mémoire unifiée (ou RAM+VRAM combinés) pour atteindre >10 tokens/s. Si vous êtes en dessous, ça fonctionnera mais la vitesse diminuera (llama.cpp peut encore fonctionner via mmap/déchargement sur disque) et peut passer d'environ 10 tokens/s à <2 tokens/s.
Nous recommandons UD-Q2_K_XL (375 Go) comme bon compromis taille/qualité. Règle empirique : RAM+VRAM ≈ la taille de la quantification ; sinon ça fonctionnera toujours, juste plus lent à cause du déchargement.
🥝 Guide d'exécution de Kimi K2.5
Kimi-K2.5 requiert des paramètres d'échantillonnage différents selon les cas d'utilisation.
Actuellement il y a pas de prise en charge de la 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 besoin d'utiliser que les GGUF dynamiques 4-bit ou 5-bit (par ex. UD_Q4_K_XL) parce que le modèle a été initialement publié en format INT4.
Vous pouvez choisir une quantification en bits plus élevée juste par précaution en cas de petites différences de quantification, mais dans la plupart des cas cela est inutile.
Différences entre Kimi K2.5 et 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 natif en résolution de 200M 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 :
température = 0.6
temperature = 1.0
top_p = 0.95
top_p = 0.95
min_p = 0.01
min_p = 0.01
Réglez la température 1.0 pour réduire les répétitions 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 régler min_p à 0,01 pour supprimer l'apparition de tokens improbables avec de faibles probabilités. Et désactiver ou régler 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 quantifications 4-bit ou 5-bit. Vous pouvez utiliser n'importe quel niveau supérieur juste pour être sûr.
Obtenez le dernier
llama.cppsur GitHub ici. Vous pouvez suivre les instructions de compilation ci-dessous également. Changez-DGGML_CUDA=ONen-DGGML_CUDA=OFFsi vous n'avez pas de GPU ou si vous voulez simplement une inférence CPU.
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). C'est similaire àollama run. Utilisezexport LLAMA_CACHE="folder"pour forcerllama.cpppour enregistrer à un emplacement spécifique.
LLAMA_SET_ROWS=1 rend llama.cpp un peu plus rapide ! Utilisez-le ! --fit on adapte automatiquement les modèles de façon optimale sur tous vos GPU et CPU.
--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 vers le CPU ! Cela vous permet effectivement de faire tenir 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" Cela 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 ne décharge que 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 le 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 MoE gate, up et down 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 vous constatez que les téléchargements se bloquent à 90 à 95% environ, veuillez consulter notre guide de dépannage.
Exécutez n'importe quel prompt.
éditer
--ctx-size 16384pour la longueur de contexte. Vous pouvez aussi omettre ceci pour une découverte automatique de la longueur de contexte via--fit on
Par exemple essayez : "Créer un jeu Flappy Bird en HTML", et vous obtiendrez :

✨ Déployer avec llama-server et la librairie de complétions d'OpenAI
L'utilisation de --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é dans Kimi K2.5, vous pouvez utiliser ce qui suit pour lancer un serveur compatible OpenAI :
Puis utilisez la bibliothèque Python d'OpenAI après pip install openai :
Et nous obtenons :

Et dans l'autre écran llama-server :

📊 Benchmarks
Vous pouvez voir ci-dessous des benchmarks au format tableau :

Raisonnement & 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
-
Qwen3.5-397B-A17B
87.1
86.7*
89.3*
90.1
85.0
-
Image & Vidéo
MMMU
78.5
79.5*
74.0
81.0
-
69.3
CharXiv (RQ)
77.5
82.1
67.2*
81.4
-
66.1
MMMU-Pro
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*
AI2D_TEST
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
MMBench (EN-DEV-v1.1)
71.2
55.8*
69.7*
69.7*
-
56.8*
WorldVQA
46.3
28.0
36.8
47.4
-
23.5
VideoMME (sans sous.)
86.6
85.9
84.4*
87.6
-
80.0
LVBench
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*
MVBench
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
-
MultiChallenge
Longbench v2
61.0
54.5*
64.4*
68.2*
59.8*
-
Long Contexte
70.0
72.3*
71.3*
65.3*
64.3*
-
Recherche agentique
BrowseComp
60.6
65.8
37.0
37.8
51.4
-
BrowseComp (avec 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*
-
WideSearch
57.4
45.0
47.7*
45.5*
49.5*
-
Terminal Bench 2
*= score réévalué par les auteurs (pas disponible publiquement auparavant).†= 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 ?

