Modellwahl
Start › 5 · Modellwahl & Bezug
Modellwahl & Bezug – vom Hub zum laufenden Modell
Die Landkarte zeigt bis hierhin was es gibt. Diese Seite zeigt den Arbeitsablauf: Wie findet man aus über einer Million Repos auf Hugging Face das eine Modell, das zur eigenen Aufgabe und zur eigenen Hardware passt – und wie lädt und prüft man es richtig?
Die sieben Schritte im Einzelnen
1 · Suchraum eingrenzen Filtern statt scrollen
Drei Filter, in dieser Reihenfolge: Task (bestimmt die Architektur), Library (GGUF = lokal lauffähig, Safetensors = volle Gewichte), Lizenz.
sentence-similarity) mit einem Generator (text-generation) verwechseln. Das sind grundverschiedene Objekte – ein Embedding-Modell erzeugt gar keinen Text.2 · Sortierkriterium bewusst wählen Downloads lügen
Downloads ist ein nachlaufender Indikator: bevorzugt, was seit Monaten in Tutorials und Docker-Images steht. In einem Feld mit 3-Monats-Zyklen führt das systematisch zu veralteten Treffern.
gewichtet die letzten Tage – zeigt den aktuellen Stand
korreliert mit Hype, nicht mit Qualität
3 · Uploader prüfen Original oder Derivat?
Zwei Klassen von Repos:
- Originale vom Labor selbst:
Qwen/,mistralai/,google/,meta-llama/ - Derivate: Quantisierungen, Feintunings, Merges
Bei Derivaten sind nur wenige Uploader verlässlich – sie quantisieren zeitnah und dokumentieren die verwendete llama.cpp-Version und die Imatrix-Kalibrierung.
TheBloke war jahrelang Standard, ist aber seit Anfang 2024 inaktiv; die dortigen Modelle sind veraltet.4 · Modellkarte lesen Model Card Vier Punkte genügen
- Prompt-Template – falsches Format ist die häufigste Ursache für „das Modell ist schlecht“.
- Kontextlänge – beworbene und real trainierte Länge weichen oft ab. Ein „128K“-Modell schwächelt real häufig ab 16–32K.
- Sprachabdeckung – viele Modelle nennen Deutsch, haben aber <1 % deutschen Trainingsanteil.
- Lizenz – Llama hat Nutzerzahl-Klauseln, Gemma eine Nutzungspolitik, Apache-2.0 ist unproblematisch.
Modellkarte (Model Card) — Die vier Zeilen, die wirklich zählen
1Begriff
Die Modellkarte ist die Beschreibungsseite eines Modells auf dem Hub – technisch die README.md im Repository. Enthält im Idealfall Lizenz, Prompt-Format, Sprachen, Trainingsdaten und Benchmarks.
2Bedeutung
Sie ist der einzige Ort, an dem die Betriebsbedingungen stehen. Wer sie überspringt, betreibt das Modell fast sicher falsch – und schiebt die schlechten Ergebnisse dann dem Modell zu.
3Funktionsweise
Vier Punkte prüfen, alles andere ist optional:
- Prompt-Template: das exakte Format mit Markierungen wie
<|im_start|>user. Jede Modellfamilie hat ein eigenes. Ollama und LM Studio setzen es meist automatisch,llama.cppdirekt nicht. - Kontextlänge: beworbene vs. tatsächlich trainierte Länge weichen oft ab – siehe Kontextfenster.
- Sprachabdeckung: Qwen und Mistral sind bei Deutsch meist stärker als US-Modelle vergleichbarer Größe.
- Lizenz: entscheidet über kommerzielle Nutzbarkeit.
4Hintergrund
Falsches Chat-Template ist die häufigste Ursache dafür, dass ein gutes Modell schlechte Ergebnisse liefert: Das Modell erkennt dann nicht, wo die Frage endet und die Antwort beginnen soll. Symptom: Es plappert weiter, beantwortet sich selbst oder bricht seltsam ab.
5Lizenzen im Vergleich
- Apache-2.0 (Qwen, Mistral Small): sehr freizügig – kommerzielle Nutzung, Veränderung, Weitergabe erlaubt. Die unkomplizierteste Variante.
- Llama-Lizenz: kein echtes Open Source. Klausel für sehr große Anbieter (ab 700 Mio. monatliche Nutzer) plus Namensnennungspflicht. Für die meisten praktisch unproblematisch, juristisch aber prüfenswert.
- Gemma Terms of Use: Google-eigene Lizenz mit einer Liste verbotener Anwendungszwecke, die auch für Weitergaben gilt.
6Vor- & Nachteile
- + Bei guten Uploadern vollständig, mit Beispielcode und Benchmark-Tabelle.
- − Qualität streut extrem: manche Karten sind leer oder aus dem Basismodell kopiert und dadurch schlicht falsch.
7Empfehlung
Wenn die Modellkarte leer ist oder das Prompt-Template fehlt: Modell überspringen. Das ist kein Qualitätsurteil über die Gewichte, sondern über die Betreuung – und undokumentierte Modelle kosten mehr Zeit, als sie sparen.
5 · Gezielt herunterladen Ein Flag spart 90 GB
Ein GGUF-Repo enthält oft 15+ Quantisierungsstufen à mehrere Gigabyte. Ohne Einschränkung lädt man 100 GB für eine 9-GB-Datei:
huggingface-cli download bartowski/Qwen3-14B-GGUF \
--include "*Q4_K_M.gguf" \
--local-dir ./models/qwen3-14b--local-dir plus HF_HOME als Umgebungsvariable auf ein größeres Volume. Für gesperrte Modelle (Llama, Gemma): Zugang auf der Modellseite beantragen, dann HF_TOKEN setzen.6 · Quantisierungsstufe wählen Der VRAM-Kompromiss
Ergänzt Quantisierung um die praktische Frage: welche Stufe?
| Stufe | Qualitätsverlust | Einsatz |
|---|---|---|
Q8_0 | vernachlässigbar | wenn VRAM reichlich |
Q6_K | minimal | guter Kompromiss |
Q4_K_M | gering, sichtbar bei Code/Mathe | Standardempfehlung |
Q3_K / IQ3 | deutlich | nur wenn nötig |
Q2 | stark | praktisch unbrauchbar |
Quantisierungsstufen richtig lesen — Was Q4_K_M, IQ3 und Imatrix bedeuten
1Begriff
Die Kürzel setzen sich zusammen: Q4 = 4 Bit pro Gewicht · _K = neueres Verfahren, das wichtige Modellteile mit höherer Präzision behält · _M = Medium (daneben _S small und _L large).
2Bedeutung
Die Stufe entscheidet, ob ein Modell überhaupt auf die Karte passt: Aus 28 GB (FP16, 14B-Modell) werden bei Q4 etwa 9 GB – der Unterschied zwischen „läuft nicht“ und „läuft auf einer normalen Grafikkarte“. Grundlagen: Quantisierung.
3Funktionsweise
Imatrix (Importance Matrix): Vor der Quantisierung schickt man Beispieltexte durchs Modell und protokolliert, welche Gewichte stark beitragen. Diese werden dann geschont. IQ-Stufen („importance-aware“) nutzen das aggressiver und sind bei sehr niedrigen Bitraten besser als klassisches Q3/Q2. Gute Uploader dokumentieren, ob und womit sie kalibriert haben.
4Hintergrund
Faustformel für den VRAM-Bedarf bei Q4_K_M: Parameter in Milliarden × 0,6 GB, plus KV-Cache – der Zwischenspeicher, den das Modell während der Verarbeitung anlegt. Er wächst mit der Kontextlänge und belegt bei langen Kontexten teils mehr als das Modell selbst.
5Alternativen
- AWQ / GPTQ: GPU-optimierte Formate für vLLM statt llama.cpp.
- MXFP4 / FP8: nativ in niedriger Präzision trainiert – Quantisierung wandert in die Architektur.
- Unquantisiert (FP16): wenn VRAM keine Rolle spielt.
6Vor- & Nachteile
- + Macht große Modelle auf Consumer-Hardware nutzbar; Q4_K_M ist ein sehr guter Kompromiss.
- − Degradation ist tückisch: Das Modell geht nicht offensichtlich kaputt – es antwortet weiter flüssig, macht aber mehr Fehler bei Logik, Rechnen und Code. Genau deshalb braucht es eigene Tests.
7Empfehlung
Mit Q4_K_M starten. Wenn Logik- oder Code-Aufgaben wackeln, erst auf Q6_K hochgehen, bevor man das Modell wechselt – oft ist nicht das Modell, sondern die Kompression das Problem.
7 · Evaluieren statt vertrauen Der eigentliche Kern
Zwei bis drei Kandidaten parallel in Ollama laden, 20–50 echte Beispiele aus dem eigenen Anwendungsfall durchlaufen, blind bewerten – also ohne zu wissen, welches Modell welche Antwort erzeugt hat.
Eigenes Eval-Set — Warum 30 selbstgebaute Testfälle jedes Leaderboard schlagen
1Begriff
Ein Eval-Set ist eine eigene Sammlung von 20–50 realistischen Testfällen aus dem eigenen Anwendungsfall – mit erwarteten oder zumindest bewertbaren Ergebnissen.
2Bedeutung
Der einzig verlässliche Vergleichsmaßstab. Aufwendig zu erstellen, aber einmalig: Danach lässt sich jedes neue Modell in Minuten gegen den bisherigen Stand prüfen – gerade bei 3-Monats-Zyklen unbezahlbar.
3Funktionsweise
Zwei bis drei Kandidaten parallel laden, dieselben Prompts durchlaufen, Ergebnisse blind bewerten – also ohne zu wissen, welches Modell welche Antwort erzeugt hat. Das schützt vor der Erwartungshaltung „das größere muss ja besser sein“. Systematisieren mit promptfoo (YAML-Konfiguration, Matrix aus Prompts × Modellen) oder RAGAS, wenn RAG im Spiel ist.
4Hintergrund
Kontamination ist das Kernproblem öffentlicher Benchmarks: Testfragen sind versehentlich in den Trainingsdaten gelandet, das Modell hat die Antworten auswendig gelernt statt sie herzuleiten – der Wert wird bedeutungslos. Zusätzlich misst MMLU Faktenwissen, nicht die Fähigkeit, deine Aufgabe zu lösen. Die Korrelation zwischen Leaderboard-Rang und Projektnutzen ist schwach.
5Alternativen & Ergänzungen
- Chatbot Arena: menschliche Paarvergleiche – näher an subjektiver Qualität als MMLU.
- MTEB: speziell für Embeddings/RAG.
- EvalPlus / BigCodeBench: für Code.
- lm-evaluation-harness: Standard-Benchmarks selbst nachrechnen.
6Vor- & Nachteile
- + Misst genau das, was zählt; deckt Template- und Quantisierungsfehler mit auf; wiederverwendbar bei jedem Modellwechsel.
- − Einmaliger Aufwand von einigen Stunden; braucht Disziplin bei der Bewertung.
7Empfehlung
Klein anfangen: 20 Fälle aus echten Anfragen der letzten Wochen, in eine Tabelle oder YAML-Datei. Das reicht bereits, um zwei Modelle sauber zu trennen – und ist mehr wert als jede Trending-Liste.
Orientierung: Was wofür? Typische Wahl je Aufgabe
| Zweck | Typische Wahl |
|---|---|
| Allround-Chat lokal | Qwen3-Familie · Llama 3.x · Mistral Small |
| Programmieren | Qwen-Coder · DeepSeek-Coder |
| RAG-Embeddings (Deutsch) | multilingual-e5 · bge-m3 · jina-embeddings-v3 |
| Reranking | bge-reranker-v2-m3 |
| Kleine Klassifikation | ModernBERT · XLM-RoBERTa (kein LLM nötig!) |
| Strukturierte Ausgabe | kleines Modell + erzwungenes JSON-Schema |
Wofür der Hub gut ist – und wofür nicht
Ehrliche Einordnung statt Plattform-Werbung. Beides zu kennen entscheidet, wann man Alternativen braucht.
- Breite – praktisch jedes offene Modell, oft ausschließlich dort. Für Nischen (deutsche Feintunings, Domänenmodelle) alternativlos.
- Versionierung – Git-basiert, jede Revision per Commit-Hash festnagelbar. Für reproduzierbare Deployments essenziell.
- Transparenz – Community-Diskussionen unter jedem Modell, oft mit Fehlermeldungen zu kaputten Quantisierungen.
- Datensätze – Standard-Fundus für Feintuning und Evaluation.
- Ökosystem – Ollama, vLLM, LM Studio, llama.cpp ziehen alle direkt vom Hub.
- Kuratierung – kein Qualitätsfilter. „Merge-Slop“ dominiert zahlenmäßig.
- Verfügbarkeit – zweistellige GB, Rate Limits ohne Konto, gelegentliche Ausfälle. Für CI-Pipelines heikel.
- Lieferketten-Sicherheit –
pickle-basierte.bin-Dateien können beliebigen Code ausführen. Nursafetensorsoder GGUF verwenden. - DSGVO – US-Unternehmen. Download unkritisch, aber bei Inference Endpoints und Spaces verlassen Nutzdaten das Haus.
- Governance – Signierung und Freigabeprozesse nur rudimentär (Enterprise Hub kostenpflichtig).
Alternativen zum Hub
| Szenario | Alternative | Wann besser |
|---|---|---|
| Nur lokal chatten | Ollama-Bibliothek | Kuratiert, ein Befehl, Template automatisch korrekt. Kleinere Auswahl – aber das Relevante ist da. |
| Grafisch ausprobieren | LM Studio | Eingebauter Modellbrowser, zeigt VRAM-Passung direkt an |
| Air-Gapped / Enterprise | Eigene Registry: Artifactory · Harbor · MinIO | Volle Kontrolle. Modelle einmal spiegeln, danach kein externer Traffic. Für DSGVO-strenge Umgebungen der saubere Weg. |
| Reproduzierbare Pipelines | Hub + Commit-Pin + lokaler Spiegel | hf_transfer für Tempo, dann in eigenen Objektspeicher |
| Chinesische Modelle | ModelScope (Alibaba) | Qwen & Verwandte teils früher verfügbar; eigene Compliance-Fragen für EU-Nutzung |
| Nur GGUF | direkt via llama.cpp / Ollama | Umgeht die Transformers-Toolchain komplett |
| Cloud statt lokal | Together · Fireworks · Groq · Azure / Bedrock | Azure/Bedrock mit EU-Regionen und AVV – compliance-seitig einfacher als HF Endpoints |
safetensors/GGUF, nie .bin aus unbekannter Quelle. ⑥ Eigenes Eval-Set aufbauen – 30 Beispiele sind mehr wert als jedes Leaderboard.