Wie man eine Modellkarte liest

Eine Modellkarte ist die README.md in einem Hugging Face-Modell-Repository, und hier sollten Sie nachschauen, bevor Sie etwas herunterladen. Die meisten Karten sind lang – diese Seite erklärt Ihnen, welche Felder für das lokale Ausführen des Modells wichtig sind und welche Sie überfliegen können. Die eigenen Richtlinien von Hugging Face dazu, was eine Karte enthalten sollte, finden Sie in der Dokumentation zu Hub-Modellkarten. In der Praxis entscheiden jedoch nur wenige Felder darüber, ob ein Modell zu Ihrer Hardware passt.

​

Parameteranzahl

Normalerweise im Modellnamen selbst (7B, 30B) oder oben auf der Karte angegeben. Dies ist der wichtigste Faktor für den Speicherbedarf – siehe Speicher und Auslagerung, um zu erfahren, wie sich die Parameteranzahl in eine VRAM-Zahl umrechnet.

​

Architektur: dicht vs. Mixture-of-Experts

Prüfen Sie, ob die Karte das Modell als dicht (dense) oder als Mixture-of-Experts (MoE) beschreibt. Ein dichtes Modell führt jeden Parameter für jedes Token aus. Ein MoE-Modell – benannt wie 30B-A3B, was 30B Gesamtparameter mit 3B aktiven Parametern bedeutet – führt nur eine Teilmenge der “Experten”-Parameter pro Token aus, sodass es schneller decodiert als ein dichtes Modell derselben Gesamtgröße. Der Haken: Sie benötigen dennoch genug Speicher, um alle Parameter zu halten, nicht nur die aktiven, da jedes Token zu einem anderen Experten weitergeleitet werden kann. Suchen Sie auf der Karte nach beiden Zahlen: Gesamtparameter (was Sie speichern müssen) und aktive Parameter (was die Geschwindigkeit pro Token bestimmt).

​

Kontextlänge

Die maximale Anzahl von Tokens, die das Modell in einer einzigen Konversation halten kann, normalerweise als etwas wie “128K Kontext” oder max_position_embeddings in der Konfiguration aufgeführt. Dies ist doppelt wichtig: Es begrenzt, wie viel Sie dem Modell auf einmal senden können, und es bestimmt direkt Ihre Obergrenze für den KV-Cache-Speicher. Siehe KV-Cache und Kontext, warum längerer Kontext mehr VRAM kostet.

​

Lizenz

Prüfen Sie das Lizenzfeld, bevor Sie etwas auf Basis eines Modells aufbauen – es bestimmt, ob Sie Ausgaben kommerziell nutzen, Fine-Tunes weiterverteilen oder das Modell überhaupt in einem Produkt ausführen dürfen. Lizenzen variieren stark zwischen Familien: Einige sind vollständig permissiv (Apache 2.0, MIT), andere haben Nutzungsbeschränkungen oder erfordern eine Quellenangabe. Dies ist Metadaten, die Hugging Face direkt auf der Karte gemäß seiner Dokumentation zu Modellkarten anzeigt.

​

Dateien und Repos: safetensors vs. GGUF

Ein einzelnes Modell wird oft über mehrere Repositories oder Dateiformate veröffentlicht:

• safetensors-Dateien sind die ursprünglichen (oder konvertierten) Gewichte, typischerweise in voller Präzision (FP16/BF16) oder begleitet von anderen quantisierten Formaten. Diese laden Backends wie vLLM typischerweise.
• GGUF-Dateien sind das Format, das llama.cpp-basierte Backends (einschließlich Ollama und LM Studio) laden. Ein GGUF-Repo bietet normalerweise mehrere quantisierte Varianten desselben Modells als separate Dateien an.

Ein Dateiname wie …Q4_K_M.gguf verrät Ihnen auf einen Blick drei Dinge: Es ist eine Q4 (4-Bit)-Quantisierung, aus der K-Quant-Familie, am M (mittel) Größen-/Qualitätspunkt innerhalb dieser Familie. Siehe Quantisierung, wie Sie den Rest des Namensschemas lesen und eine Variante auswählen.

​

Chat-Vorlage

Die meisten instruction-tuned Modelle erwarten Prompts, die in einer bestimmten Chat-Vorlage verpackt sind (spezielle Tokens, die System-/Benutzer-/Assistenten-Turns markieren). Backends, die das Modell bereitstellen – Ollama, llama.cpp, vLLM – wenden typischerweise die korrekte Vorlage automatisch aus den mit dem Modell gebündelten Metadaten an, aber wenn Sie rohe Prompts selbst erstellen, prüfen Sie die Karte auf das erwartete Format. Die Verwendung der falschen Vorlage verschlechtert die Ausgabequalität stillschweigend, ohne einen Fehler zu werfen.

​

Beabsichtigte Verwendung

Karten geben typischerweise an, wofür das Modell optimiert wurde – allgemeiner Chat, Programmierung, Reasoning, Befehlsbefolgung – und manchmal, wofür es als schwach bekannt ist. Dies ist einen Überflug wert, bevor Sie Hardware für ein Modell commiten, das sich als schlecht für Ihre Aufgabe eignet; siehe Welches lokale Modell für welche Aufgabe?, um Modelle systematischer auf Aufgaben abzustimmen.

​

Was zählt, sobald Sie es über Tokios bereitstellen

Wenn Sie ein lokales Modell als Tokios-Deployment registrieren, übersetzen sich zwei Modellkarten-Felder direkt in Setup-Entscheidungen:

• Upstream-Modell-ID vs. Deployment-Name. Die ID, die Ihr Backend bereitstellt (zum Beispiel ein Ollama-Tag oder ein Pfad, mit dem ein llama.cpp-Server gestartet wurde), ist anders als der öffentliche Deployment-Name, den Sie ihm in Tokios geben werden – die Karte sagt Ihnen das Erstere, Sie wählen das Letztere.
• Kontextlänge und Lizenz gelten als Einschränkungen dafür, wie Sie das Deployment nutzen können, unabhängig davon, welcher Client es aufruft.

​

Tiefer einsteigen

​

Sobald Sie eines ausgewählt haben und es läuft

Das Lesen der Karte sagt Ihnen, was das Modell kann. Sobald Sie es heruntergeladen haben und es auf localhost auf Anfragen antwortet, ist der nächste Schritt, es erreichbar zu machen.