Den Hub lesen lernen

Eine Modellseite auf dem Hub sieht aus wie eine Produktseite. Sie ist keine. Sie ist die README eines Git-Repositories, und alles darauf hat jemand von Hand hineingeschrieben - inklusive der Behauptungen.

Dieses Kapitel bringt dir bei, sie zu lesen, ohne dich anzumelden. Am Ende hast du drei Modelle für dieselbe Aufgabe nebeneinander stehen und eine Entscheidung getroffen, die du begründen kannst.

Ein Repo, kein Download

Ruf eine beliebige Modellseite auf, zum Beispiel Qwen/Qwen2.5-0.5B-InstructExtern - Öffnet in neuem Tab. Der Name hat immer dieselbe Form:

Qwen  /  Qwen2.5-0.5B-Instruct
 ↑              ↑
 Namensraum     Repo-Name
 (Person        (Modellfamilie, Größe, Variante)
  oder Organisation)

Das ist derselbe Aufbau wie bei GitHub, und es ist kein Zufall: Darunter liegt ein echtes Git-Repository. Der Reiter Files and versions zeigt den Dateibaum, der Reiter Commits den Verlauf. Du kannst das Repo klonen, Branches sehen, einen alten Stand auschecken. Große Dateien werden dabei nicht über Git selbst übertragen - dazu mehr im nächsten Kapitel.

Die Startseite ist die README.md des Repos, hier Model Card genannt. Ganz oben in dieser Datei steht ein YAML-Block, den du auf der Webseite nicht als Text siehst, sondern als die Etiketten links und rechts: Aufgabe, Sprache, Lizenz, Basismodell.

Die vier Dinge, die du zuerst ansiehst

Erstens: der Task-Tag. Links oben, zum Beispiel Text Generation oder Text Classification. Er bestimmt, ob das Modell überhaupt das tut, was du willst. Der häufigste Anfängerfehler ist ein anderer und subtiler: Base gegen Instruct. Ein Modellname ohne -Instruct, -Chat oder -it ist meist ein Basismodell - es setzt Text fort, statt Anweisungen zu befolgen. Wer ein Basismodell etwas fragt, bekommt oft die nächste plausible Frage zurück statt einer Antwort und hält das Modell für kaputt.

Zweitens: das Lizenzfeld. Rechts in der Seitenleiste, ein einzelnes Wort wie apache-2.0. Es entscheidet, ob du das Modell kommerziell einsetzen darfst.

Drittens: die Dateiliste. Unter Files and versions steht, was du wirklich bekommst. Achte auf die Endungen: .safetensors ist das gute Format, .bin und .pt sind das alte. Warum das ein Sicherheits- und kein Geschmacksthema ist, steht in Kapitel 03. .gguf ist die quantisierte Variante für llama.cpp und Ollama. Wenn ein Repo nur .bin anbietet, ist das ein Hinweis - meist auf Alter, manchmal auf mehr.

Viertens: Zahlen und Datum. Rechts stehen Downloads des letzten Monats und Likes, im Commit-Verlauf steht, wie alt das Repo ist. Diese beiden Angaben zusammen sind dein Vertrauensmaß - und der nächste Abschnitt erklärt, warum jede für sich wertlos ist.

Woran du ein faules Repo erkennst

Der Hub ist offen. Jeder kann in zehn Sekunden ein Repo anlegen, das meta-llama-3-8b-instruct-fixed heißt. Es hat dokumentierte Vorfälle gegeben: gefälschte Repos mit künstlich aufgeblähten Zahlen, in einem berichteten Fall rund 244.000 Downloads innerhalb von 18 Stunden.

Genau da liegt der Prüfstein. Downloadzahlen sind eine Zeitreihe, keine Zahl. Ein Repo, das vor drei Tagen angelegt wurde und eine sechsstellige Downloadzahl trägt, behauptet etwas, das physikalisch schwer geht. Eine hohe Zahl bei einem zwei Jahre alten Repo einer bekannten Organisation ist etwas ganz anderes als dieselbe Zahl bei einem Repo, das gestern entstand.

Die Prüfliste, die du dir angewöhnen solltest:

• Wer ist der Namensraum? Ist es die Organisation, die das Modell gebaut hat, oder ein Privatkonto, das den Namen nur enthält? meta-llama/… ist Meta. superuser42/llama-3-8b-instruct ist es nicht.
• Wie alt ist das Repo gegenüber seinen Zahlen? Der Commit-Verlauf beantwortet das in zwei Klicks.
• Ist die Model Card geschrieben oder generiert? Fehlende Angaben zu Trainingsdaten, Grenzen und beabsichtigtem Einsatz sind ein Warnsignal - und seit den Transparenzpflichten des EU AI Act für allgemeine KI-Modelle (in Kraft seit dem 2. August 2025) sind Model Cards genau das Werkzeug, mit dem seriöse Anbieter diese Pflichten erfüllen. Eine leere Karte ist also nicht nur unhöflich.
• Passen Dateien und Beschreibung zusammen? Ein Repo, das sich als 7B-Modell beschreibt und 300 MB Dateien hat, ist keins.

Suchen wie jemand mit einer Anforderung

Die Modellsuche unter huggingface.co/modelsExtern - Öffnet in neuem Tab kann mehr als das Suchfeld. Die Filter links sind der eigentliche Zugang:

• Tasks - was das Modell tun soll (Text Generation, Summarization, Automatic Speech Recognition …)
• Languages - hier de für deutschsprachige Modelle
• Licenses - hier apache-2.0, wenn du kommerziell arbeitest
• Libraries - transformers, gguf, diffusers …

Diese Filter schreiben sich in die URL, das heißt: Eine gefundene Kombination kannst du als Lesezeichen behalten und in ein halbes Jahr wieder aufrufen.

Sortieren kannst du nach Trending, Most downloads, Most likes und Recently updated. Für einen produktiven Einsatz ist „Most downloads“ der brauchbarste Einstieg - aber eben nur der Einstieg, siehe oben.

Der Meilenstein

Nimm dir eine echte Aufgabe. Wenn dir keine einfällt, nimm diese: ein Modell, das deutschsprachige Kundenmails in „Beschwerde“ und „keine Beschwerde“ einsortiert, auf einem Rechner ohne GPU, kommerziell einsetzbar.

Filtere danach, öffne drei Kandidaten und fülle diese Tabelle aus - in einer Datei, nicht im Kopf:

| Modell | Lizenz | Format | Repo-Alter | Downloads/Monat | Base/Instruct | Größe |
|--------|--------|--------|------------|-----------------|---------------|-------|
|        |        |        |            |                 |               |       |

Darunter schreibst du drei Sätze: Für welches du dich entscheidest, warum, und was dich an den anderen beiden gestört hat.

Das ist keine Fleißaufgabe. Es ist die Übung, die dich davor bewahrt, in einem halben Jahr ein Modell im Produktivbetrieb zu haben, dessen Lizenz niemand gelesen hat.