🥝Kimi K2.5: Anleitung zum lokalen Ausführen
Anleitung zum Ausführen von Kimi-K2.5 auf deinem eigenen lokalen Gerät!
Kimi-K2.5 ist das neue Modell von Moonshot, das SOTA-Leistung in Vision-, Coding-, Agentic- und Chat-Aufgaben erzielt. Das 1T-Parameter-Hybridreasoning-Modell benötigt 600 GB Festplattenspeicher, während die quantisierte Unsloth Dynamic 1.8-Bit Version dies auf 240 GB reduziert (-60 % Größe): Kimi-K2.5-GGUF
Alle Uploads verwenden Unsloth Dynamic 2.0 für SOTA Aider- und 5-Shot MMLU-Leistung. Sehen Sie, wie unsere Dynamic 1–2-Bit-GGUFs bei Coding-Benchmarks.
⚙️ Empfohlene Anforderungen
Sie benötigen >240 GB Festplattenspeicher um die 1-Bit-Quantisierung auszuführen!
Für beste Leistung stellen Sie sicher, dass Ihr insgesamt verfügbarer Speicher (VRAM + Systemspeicher) die Größe der quantisierten Modell-Datei, die Sie herunterladen, übersteigt. Falls nicht, kann llama.cpp weiterhin über SSD/HDD-Offloading laufen, aber die Inferenz wird langsamer sein.
Die 1.8-Bit-(UD-TQ1_0)-Quantisierung läuft auf einer einzelnen 24-GB-GPU, wenn Sie alle MoE-Schichten in den Systemspeicher (oder eine schnelle SSD) auslagern. Mit ~256 GB RAM erwarten Sie ~10 Tokens/s. Das vollständige Kimi K2.5-Modell ist 630 GB groß und erfordert typischerweise mindestens 4× H200-GPUs.
Wenn das Modell passt, erhalten Sie >40 Tokens/s bei Verwendung einer B200.
Um das Modell in nahezu voller Präzisionauszuführen, können Sie die 4-Bit- oder 5-Bit-Quants verwenden. Sie können auch eine höhere Bit-Quantisierung verwenden, um auf der sicheren Seite zu sein.
Für starke Leistung zielen Sie auf >240 GB einheitlichen Speichers (oder kombiniert RAM+VRAM), um 10+ Tokens/s zu erreichen. Wenn Sie darunter liegen, funktioniert es zwar, aber die Geschwindigkeit wird abnehmen (llama.cpp kann weiterhin via mmap/Disk-Offload laufen) und kann von ~10 Tokens/s auf <2 Tokens/s fallen.
Wir empfehlen UD-Q2_K_XL (375 GB) als gutes Größen-/Qualitätsverhältnis. Beste Faustregel: RAM+VRAM ≈ Quant-Größe; ansonsten funktioniert es trotzdem, nur langsamer wegen Offloading.
🥝 Kimi K2.5 Anleitung ausführen
Kimi-K2.5 erfordert unterschiedliche Sampling-Parameter für verschiedene Anwendungsfälle.
Derzeit gibt es keine Vision-Unterstützung für das Modell, aber hoffentlich wird llama.cpp dies bald unterstützen.
Um das Modell in voller Präzision auszuführen, müssen Sie nur die 4-Bit- oder 5-Bit-Dynamic-GGUFs verwenden (z. B. UD_Q4_K_XL), da das Modell ursprünglich im INT4-Format veröffentlicht wurde.
Sie können eine höherbitige Quantisierung wählen, um bei kleinen Quantisierungsunterschieden auf Nummer sicher zu gehen, aber in den meisten Fällen ist dies unnötig.
Unterschiede von Kimi K2.5 zu Kimi K2 Thinking
Beide Modelle verwenden eine modifizierte DeepSeek V3 MoE-Architektur.
rope_scaling.beta_fastK2.5 verwendet 32.0 vs. K2 Thinking's 1.0.MoonViT ist der Native‑Resolution-200M-Parameter-Vision-Encoder. Er ist ähnlich dem, der in Kimi-VL-A3B-Instruct verwendet wird.
🌙 Gebrauchsanweisung:
Laut Moonshot AI sind dies die empfohlenen Einstellungen für die Kimi K2.5-Inferenz:
temperature = 0.6
temperature = 1.0
top_p = 0.95
top_p = 0.95
min_p = 0.01
min_p = 0.01
Setzen Sie die temperature 1.0 um Wiederholungen und Inkohärenz zu reduzieren.
Vorgeschlagene Kontextlänge = 98.304 (bis zu 256K)
Hinweis: Die Verwendung unterschiedlicher Tools kann unterschiedliche Einstellungen erfordern
Wir empfehlen, min_p auf 0.01 zu setzen, um das Auftreten unwahrscheinlicher Token mit niedrigen Wahrscheinlichkeiten zu unterdrücken. Und deaktivieren Sie oder setzen Sie repeat penalty = 1.0 falls nötig.
Chat-Vorlage für Kimi K2.5
Ausführen tokenizer.apply_chat_template([{"role": "user", "content": "What is 1+1?"},]) ergibt:
✨ Kimi K2.5 in llama.cpp ausführen
Für diese Anleitung werden wir die kleinste 1-Bit-Quantisierung verwenden, die 240 GB groß ist. Sie können die Quantisierungsart gerne auf 2-Bit, 3-Bit usw. ändern. Um das Modell in nahezu voller Präzisionauszuführen, können Sie die 4-Bit- oder 5-Bit-Quants verwenden. Sie können auch eine höhere Bit-Quantisierung verwenden, um auf der sicheren Seite zu sein.
Holen Sie sich das neueste
llama.cppauf GitHub hier. Sie können auch den untenstehenden Build-Anweisungen folgen. Ändern Sie-DGGML_CUDA=ONzu-DGGML_CUDA=OFFwenn Sie keine GPU haben oder nur CPU-Inferenz möchten.
Wenn Sie
llama.cppdirekt zum Laden von Modellen verwenden möchten, können Sie Folgendes tun: (:UD-TQ1_0) ist der Quantisierungstyp. Sie können auch über Hugging Face (Punkt 3) herunterladen. Das ist ähnlich wieollama run. Verwenden Sieexport LLAMA_CACHE="folder"umllama.cppzu zwingen, an einem bestimmten Ort zu speichern.
LLAMA_SET_ROWS=1 macht llama.cpp etwas schneller! Verwenden Sie es! --fit on passt Modelle automatisch optimal auf all Ihre GPUs und CPUs an.
--fit onwird das Modell automatisch an Ihr System anpassen. Wenn Sie nicht--fit onverwenden und etwa 360 GB kombinierter GPU-Speicher haben, entfernen Sie-ot ".ffn_.*_exps.=CPU"um maximale Geschwindigkeit zu erzielen.
Verwenden Sie --fit on für automatisches Anpassen auf GPUs und CPUs. Wenn dies nicht funktioniert, siehe unten:
Bitte probieren Sie -ot ".ffn_.*_exps.=CPU" aus, um alle MoE-Schichten auf die CPU auszulagern! Dies ermöglicht es effektiv, alle nicht-MoE-Schichten auf 1 GPU unterzubringen und verbessert die Generationsgeschwindigkeit. Sie können den Regex-Ausdruck anpassen, um mehr Schichten auszulagern, wenn Sie mehr GPU-Kapazität haben.
Wenn Sie etwas mehr GPU-Speicher haben, versuchen Sie -ot ".ffn_(up|down)_exps.=CPU" Dies lagert Up- und Down-Projection-MoE-Schichten aus.
Versuchen Sie -ot ".ffn_(up)_exps.=CPU" wenn Sie noch mehr GPU-Speicher haben. Dies lagert nur Up-Projection-MoE-Schichten aus.
Und schließlich lagern Sie alle Schichten via -ot ".ffn_.*_exps.=CPU" Dies verwendet den wenigsten VRAM.
Sie können auch den Regex anpassen, zum Beispiel -ot "\.(6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(gate|up|down)_exps.=CPU" bedeutet, Gate-, Up- und Down-MoE-Schichten auszulagern, aber nur ab der 6. Schicht.
Laden Sie das Modell über (nach der Installation von
pip install huggingface_hub hf_transfer). Wir empfehlen die Verwendung unserer 2-Bit-Dynamic-Quantisierung UD-Q2_K_XL, um Größe und Genauigkeit auszubalancieren. Alle Versionen unter: huggingface.co/unsloth/Kimi-K2.5-GGUF Wenn Downloads hängen bleiben, siehe Hugging Face Hub, XET-Debugging
Wenn Sie feststellen, dass Downloads bei etwa 90 bis 95 % stecken bleiben, sehen Sie bitte unseren Fehlerbehebungsleitfaden.
Führen Sie irgendeinen Prompt aus.
Bearbeiten Sie
--ctx-size 16384für die Kontextlänge. Sie können dies auch weglassen, damit die Kontextlänge automatisch über--fit on
Als Beispiel versuchen Sie: "Erstelle ein Flappy Bird-Spiel in HTML", und Sie erhalten:

✨ Deployment mit llama-server und OpenAIs Completion-Bibliothek
Die Verwendung von --kv-unified kann das Inferenz-Serving in llama.cpp beschleunigen! Siehe https://www.reddit.com/r/LocalLLaMA/comments/1qnwa33/glm_47_flash_huge_performance_improvement_with_kvu/
Nachdem Sie llama.cpp wie unter Kimi K2.5installiert haben, können Sie das Folgende verwenden, um einen OpenAI-kompatiblen Server zu starten:
Verwenden Sie dann OpenAIs Python-Bibliothek nach pip install openai :
Und wir erhalten:

Und im anderen llama-server-Fenster:

📊 Benchmarks
Weiter unten können Sie Benchmarks in Tabellenform einsehen:

Reasoning & Knowledge
HLE-Full
30.1
34.5
30.8
37.5
25.1†
-
HLE-Full (mit Tools)
50.2
45.5
43.2
45.8
40.8†
-
AIME 2025
96.1
100
92.8
95.0
93.1
-
HMMT 2025 (Feb)
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 & Video
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 (mit Tools)
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
Programmierung
SWE-Bench Verifiziert
76.8
80.0
80.9
76.2
73.1
-
SWE-Bench Pro
50.7
55.6
55.4*
-
-
-
SWE-Bench Mehrsprachig
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
-
Langer Kontext
Longbench v2
61.0
54.5*
64.4*
68.2*
59.8*
-
AA-LCR
70.0
72.3*
71.3*
65.3*
64.3*
-
Agentische Suche
BrowseComp
60.6
65.8
37.0
37.8
51.4
-
BrowseComp (mit Kontextverwaltung)
74.9
65.8
57.8
59.2
67.6
-
BrowseComp (Agentenschwarm)
78.4
-
-
-
-
-
WideSearch (Item-F1)
72.7
-
76.2*
57.0
32.5*
-
WideSearch (Item-F1 Agentenschwarm)
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*
-
Anmerkungen
*= Score von den Autoren neu bewertet (zuvor nicht öffentlich verfügbar).†= DeepSeek V3.2 Score entspricht seinem rein textbasierten Teil (wie in den Fußnoten vermerkt).-= nicht bewertet / nicht verfügbar.
Zuletzt aktualisiert
War das hilfreich?

