Woher Modelle kommen

In Kapitel 01 liegt ein Modellordner aufgeschlagen, und es geht um das, was in den Dateien steht. Dieses Kapitel fragt, von wem die Dateien kommen und unter welchen Bedingungen Sie sie benutzen dürfen. Das durchgehende Beispiel ist Llama 3.1 8B Instruct von Meta. An ihm zeigt sich alles, worum es hier geht. Es hat eine Lizenz mit Bedingungen und eine Zugangssperre, zwei Dateiformate im selben Ordner und eine große Zahl von Derivaten.

Ein Modell, über zehntausend Derivate

Meta hat Llama 3.1 am 23.07.2024 veröffentlicht, in drei Größen mit 8, 70 und 405 Milliarden Parametern. Jede Größe gibt es nach der Modellkarte (externe Seite, github.com) zweimal: als pretrained-Modell, das Text fortsetzt, und als Instruct-Modell, das auf Anweisungen antwortet.

Bei Hugging Face zeigt die Seite eines Modells einen Model tree. Er listet die Repositories, die dieses Modell als Ursprung angeben. An den beiden Repositories von Llama 3.1 8B, pretrained und Instruct, hingen am 19.10.2026 in erster Generation 10.532 verschiedene Repositories, gezählt über die Schnittstelle von Hugging Face (externe Seite, huggingface.co). Fast alle stammen von Dritten: von Firmen, Forschungsgruppen und Einzelnen, die das Modell weitertrainiert, verkleinert oder mit anderen verrechnet haben. Solche Repositories heißen in diesem Kapitel Derivate.

Bei anderen Familien sieht es ähnlich aus. Hugging Face zählt in einem Bericht vom August 2026 (externe Seite, huggingface.co) 151.448 Derivate auf der Grundlage von Qwen-Modellen. Von 28.531 Umwandlungen der Qwen-Modelle ins Format GGUF hat Qwen selbst 54 veröffentlicht. Beide Zahlen sind eine Selbstauskunft der Plattform über ihren eigenen Bestand.

Wer eine Modelldatei herunterlädt, hat sie deshalb meist aus zweiter Hand. Wer sie hochgeladen hat, was er daran verändert hat und welche Lizenz gilt, steht an verschiedenen Stellen. Dieses Kapitel zeigt, an welchen.

Zwei Wege zum Nutzer: eine Schnittstelle oder eine Datei

Ein geschlossenes Modell erreicht Sie über eine Schnittstelle. Sie schicken eine Anfrage an den Anbieter, die Antwort kommt zurück, und die Gewichte bleiben bei ihm. Ein Modell mit offenen Gewichten erreicht Sie als Datei. Sie laden sie herunter und führen sie selbst aus, oder ein Betreiber Ihrer Wahl tut es.

Wo das geschieht und was es an Hardware verlangt, steht in Beurteilen und Einordnen, Kapitel 01. Dort steht auch, dass offen und lokal zwei verschiedene Eigenschaften sind. Bei Llama 3.1 gilt das schon für Metas eigene Dateien: Sie lassen sich erst herunterladen, wenn Meta den Zugang freigegeben hat. Davon handelt der Abschnitt über Hugging Face.

Die Lizenz sagt, was Sie mit der Datei dürfen

Mit der Datei kommt eine Lizenz. Sie regelt, wofür Sie das Modell einsetzen dürfen, ob Sie es verändern und ob Sie es weitergeben dürfen. Drei Stufen lassen sich unterscheiden.

• Frei. Die Lizenzen Apache 2.0 und MIT (externe Seite, opensource.org) erlauben Nutzung, Änderung, Weitergabe und Verkauf. Apache 2.0 (externe Seite, apache.org) enthält zusätzlich eine Patentlizenz jedes Beitragenden. Unter Apache 2.0 stehen etwa gpt-oss (externe Seite, openai.com) von OpenAI, dort ergänzt um eine eigene Nut­zungs­richt­linie, und Gemma 4 (externe Seite, ai.google.dev) von Google.
• Frei mit Schwellen. Die Lizenz von Llama 3.1 (externe Seite, github.com) erlaubt den Einsatz und verlangt bei der Weitergabe unter anderem einen Hinweis auf Llama und das Wort Llama am Anfang des Modellnamens. Wer am Erscheinungstag über 700 Millionen monatlich aktive Nutzer hatte, braucht eine eigene Lizenz von Meta. Die Lizenz von Kimi K3 (externe Seite, huggingface.co) setzt die Schwelle beim Umsatz: Bietet ein Lizenznehmer Modelle als Dienst an und setzt er mit seinen verbundenen Unternehmen in zwölf Monaten über 20 Millionen US-Dollar um, braucht er eine eigene Vereinbarung.
• Nichtkommerziell. Die Forschungslizenz von Qwen (externe Seite, huggingface.co) erlaubt Nutzung, Änderung und Weitergabe allein zu nicht­kom­mer­zi­ellen Zwecken.

Die Stufe hängt an der Veröffentlichung, und Meta zeigt das an sich selbst. Llama 3.1 erschien 2024 unter Metas eigener Community License. Im August 2026 folgte Muse Glimmer (externe Seite, huggingface.co) unter Apache 2.0, im Oktober 2026 Muse Spark Open (externe Seite, huggingface.co) unter einer dritten Lizenz, der Muse Model License. Das sind drei Lizenzformen in 27 Monaten. Für die Auswahl folgt daraus: Geprüft wird jede Veröffentlichung für sich. Die zweite Ebene stellt die Lizenzfamilien nebeneinander.

Hugging Face ist das Lager, die Modellkarte das Etikett

Die meisten offenen Modelle liegen bei Hugging Face (externe Seite, huggingface.co). Die Plattform beschreibt sich als den Ort, an dem die Fachgemeinde des maschinellen Lernens gemeinsam an Modellen, Datensätzen und Anwendungen arbeitet. Jedes Modell liegt dort in einem Repository, einem Ordner mit Ver­si­ons­ge­schichte.

Der Eigentümer der Plattform wechselt womöglich. Nvidia hat am 02.09.2026 einen Vertrag über die Übernahme geschlossen. Nach seiner Pflichtmitteilung an die US-Börsenaufsicht (externe Seite, sec.gov) soll sie in der ersten Hälfte 2027 abgeschlossen sein, vorbehaltlich der behördlichen Genehmigungen.

Zu jedem Repository gehört eine Modellkarte: eine Textseite mit einem Kopf aus Metadaten. Für die Herkunft zählen drei Felder dieses Kopfs.

• Die Lizenz. Eine Kennung wie apache-2.0 oder llama3.1. Nach der Doku von Hugging Face (externe Seite, github.com) setzt sie jeder für sein eigenes Repository. Bei einer Lizenz außerhalb der Liste steht dort other, und die Doku bittet, den Lizenztext als Datei LICENSE danebenzulegen.
• Die Sperre. Ein Hersteller kann den Zugang an eine Zustimmung knüpfen. Bei Llama 3.1 8B Instruct gibt Meta jeden Zugang von Hand frei, Stand 19.10.2026.
• base_model. Das Feld nennt das Modell, aus dem dieses entstanden ist. Aus diesen Einträgen baut Hugging Face den Model tree.

Was eine Modellkarte über Fähigkeiten und Prüfungen sagt und worin sie sich von der Systemkarte eines geschlossenen Modells unterscheidet, steht in Beurteilen und Einordnen, Kapitel 07. Hier zählt sie als Herkunftsnachweis. Ausgefüllt wird sie von dem, der hochlädt, und die zweite Ebene zeigt, was daraus folgt.

Eine Familie hat Eltern und Kinder

Am Anfang einer Modellfamilie steht das pretrained-Modell. Es hat an großen Textmengen gelernt, Text fortzusetzen. Daraus stimmt der Hersteller das Instruct-Modell ab, das auf Anweisungen antwortet. Bei Llama 3.1 8B liegen beide als eigene Repositories bei Meta. Was danach kommt, stammt meist von Dritten, und der Model tree sortiert es in vier Arten:

• Adapter. Eine kleine Zusatzdatei, die neben die unveränderten Gewichte gelegt wird, meist mit LoRA trainiert.
• Fine-Tune. Eine vollständige Kopie mit weitertrainierten Gewichten.
• Merge. Die Gewichte mehrerer Modelle, zu einem neuen verrechnet, ohne weiteres Training.
• Quantisierung. Dieselben Gewichte, mit weniger Bit je Zahl gespeichert, oft im Dateiformat GGUF.

Metas Instruct-Modell zählt selbst unter den 1.507 Fine-Tunes des pretrained-Modells. Enkel, also Derivate von Derivaten, sind in keiner der Zahlen enthalten. An beiden Knoten bilden die Fine-Tunes die größte Gruppe und die Merges die kleinste. Wie Fine-Tuning und LoRA arbeiten, steht in Beurteilen und Einordnen, Kapitel 02.

Eine weitere Herkunft fehlt im Model tree. Ein Modell kann aus den Ausgaben eines anderen lernen, ohne dessen Gewichte zu übernehmen. Meta erlaubt das in der Modellkarte (externe Seite, github.com) ausdrücklich, für synthetische Trainingsdaten und für Destillation. Davon handelt Kapitel 03. Wie Hersteller selbst kleine Modelle aus großen ableiten, steht in KI jenseits der Sprachmodelle, Kapitel 10.

Mit solchen Ausgaben kann auch eine politische Haltung von einem Modell ins nächste gelangen. Die zweite Ebene zeigt Messungen dazu, an offenen Modellen und an ihren Trainingsdaten.

Offen heißt bei KI mehr als bei Software

Für Software ist geklärt, was Open Source heißt. Die Definition der Open Source Initiative und was sie einer Lizenz abverlangt, zeigt die dritte Ebene von Automatisierung mit KI, Kapitel 03. Für KI-Systeme hat dieselbe Organisation am 28.10.2024 eine eigene Definition (externe Seite, opensource.org) vorgelegt. Danach muss jeder das System für jeden Zweck nutzen dürfen, ohne um Erlaubnis zu fragen. Dazu verlangt sie drei Bestandteile: die Parameter, also die Gewichte, und den Code. Der dritte sind Angaben über die Trainingsdaten, so genau, dass eine Fachperson ein im Wesentlichen gleichwertiges System bauen könnte.

An dieser Definition gemessen liegen zwei Familien weit auseinander. Ai2 nennt für Olmo 3.1 (externe Seite, huggingface.co) die Datensätze für Vortraining und Nachtraining beim Namen und gibt Code und Zwischenstände heraus. Die Reihe OLMo steht auf der Liste, die Freiwillige in der Prüfphase der OSI (externe Seite, opensource.org) als bestanden geführt haben, Llama 2 auf der Liste der durchgefallenen. Eine Zertifizierung ist das nach der OSI ausdrücklich nicht. Zu den Trainingsdaten von Llama 3.1 nennt Metas Modellkarte rund 15 Billionen Token aus öffentlich verfügbaren Quellen und den Stichtag Dezember 2023. Einen Datensatz nennt sie beim Namen an keiner Stelle.

Offene Gewichte sind damit eine Eigenschaft der Datei. Ob ein Modell im Sinn der OSI offen ist, hängt zusätzlich an Code, Datenangaben und Lizenz. Die zweite Ebene geht die Definition Punkt für Punkt durch.

Vier Fragen an jede Datei

1. Wer hat sie hochgeladen? Der Name vor dem Schrägstrich sagt es, bei Metas Original meta-llama. Steht dort ein anderer Name, hat jemand anderes sie hochgeladen. Auch Meta nutzt mehr als einen Namen, für die Muse-Modelle meta-models.
2. Welche Lizenz gilt, und für welche Größe? In derselben Familie kann jede Größe eine andere Lizenz haben. Bei Qwen 2.5 steht das Modell mit 3 Milliarden Parametern unter einer Forschungslizenz, das mit 7 Milliarden unter Apache 2.0. Die Diktier-App aus einem Beitrag hat das kleinere deshalb aussortiert.
3. Welches Format? Eine Datei im Format safetensors enthält einen Kopf und Zahlen. Dateien im Pickle-Format, etwa PyTorch-Checkpoints mit der Endung .pth, können beim Laden Code ausführen. Die dritte Ebene zeigt, wie das geht.
4. Wie heißt der Ursprung, und stimmt die Angabe? Das Feld base_model setzt der, der hochlädt. Die zweite Ebene zeigt zwei Fälle, in denen der Model tree deshalb danebenliegt.

Der Überblick hat drei Stufen von Lizenzen und den Model tree von Hugging Face vorgestellt. Diese Ebene liest die Texte dahinter. Sie zeigt, was die Lizenz von Llama 3.1 verlangt, wie sich die Lizenzfamilien unterscheiden und welche Bedingungen ein Derivat mitbekommt. Danach geht es um die Frage, wie verlässlich die Herkunftsangaben bei Hugging Face sind. Am Ende steht, was offen bei einem KI-Modell nach der Definition der Open Source Initiative heißt.

Was in der Lizenz von Llama 3.1 steht

In der Llama 3.1 Community License (externe Seite, github.com) entscheiden vier Stellen über den Einsatz.

Die Weitergabe, Abschnitt 1.b.i. Wer die Llama-Materialien weitergibt oder ein Produkt, das sie enthält, legt eine Kopie der Lizenz bei. Dazu zeigt er gut sichtbar an, dass das Produkt mit Llama gebaut ist. Abschnitt 1.b.iii verlangt dazu in jeder weitergegebenen Kopie der Llama-Materialien eine Textdatei Notice mit einem festen Hinweis auf die Lizenz.

Für Modelle steht im selben Absatz eine Namenspflicht. Wer mit Llama oder mit dessen Ausgaben ein Modell erstellt, trainiert oder verbessert und es weitergibt oder anderen zugänglich macht, setzt das Wort Llama an den Anfang des Modellnamens. Die Ausgaben sind ausdrücklich genannt. Auch ein Modell, das nur aus Antworten von Llama gelernt hat, fällt also unter diese Pflicht, sobald es weitergegeben oder zugänglich gemacht wird.

Die Schwelle, Abschnitt 2. Hatten die Produkte und Dienste eines Lizenznehmers am Erscheinungstag von Llama 3.1 im Vormonat über 700 Millionen monatlich aktive Nutzer, braucht er eine eigene Lizenz. Ob Meta sie erteilt, liegt in Metas Ermessen.

Gezählt wird über alle Produkte des Lizenznehmers und seiner verbundenen Unternehmen. Stichtag ist der Erscheinungstag, der 23.07.2024. Einen späteren Zeitpunkt nennt die Klausel an keiner Stelle.

Die Nut­zungs­richt­linie, Abschnitt 1.b.iv. Die Lizenz bindet Metas Nut­zungs­richt­linie ein, die Acceptable Use Policy. Sie wird damit Teil des Vertrags. Was die Richtlinie verbietet, verbietet also die Lizenz.

Das Ende, Abschnitt 6. Endet die Lizenz, etwa nach einem Verstoß, löscht der Lizenznehmer die Llama-Materialien und stellt ihre Nutzung ein. Was mit Kopien geschieht, wenn ein Original verschwindet, zeigt die dritte Ebene.

Mit den Nachfolgern kam eine Klausel zu Europa hinzu. Sie betrifft Personen mit Wohnsitz und Firmen mit Hauptsitz in der Europäischen Union. Die Nut­zungs­richt­linie zu Llama 3.2 (externe Seite, github.com) gewährt ihnen für die multimodalen Modelle die Rechte aus Abschnitt 1(a) der Lizenz nicht, Endnutzer eines Produkts mit einem solchen Modell ausgenommen.

Dieselbe Klausel steht bis auf die Versionsnummer wortgleich in der Richtlinie zu Llama 4 (externe Seite, github.com). Sie betrifft die multimodalen Modelle, die auch Bilder verarbeiten. Die Modelle von Llama 3.1 verarbeiten nur Text, und die Richtlinie zu Llama 3.1 enthält keine solche Klausel, geprüft am 19.10.2026.

Muse Spark Open ist ebenfalls multimodal. Hugging Face führt es unter der Aufgabe Image-Text-to-Text, also mit Bild und Text als Eingabe. Seine Lizenz (externe Seite, huggingface.co) räumt die Rechte jeder Person ein, die das Modell erhält, und nimmt die Nut­zungs­richt­linie als Anhang A auf. Für Lizenznehmer in Europa ist Meta Platforms Ireland der Vertragspartner, geprüft am 24.10.2026.

Vier Lizenzfamilien

Die Lizenzen offener Modelle lassen sich in vier Familien ordnen. Eine Lizenz kann Züge von zwei Familien haben: Die Lizenz von Llama hat eine Schwelle und bindet zugleich Nutzungsverbote ein.

Frei. Die Apache-Lizenz 2.0 (externe Seite, apache.org) erlaubt Nutzung, Änderung und Weitergabe. In Abschnitt 3 räumt jeder Beitragende eine Patentlizenz ein, unbefristet, weltweit und gebührenfrei. Die MIT-Lizenz (externe Seite, opensource.org) zählt Nutzung, Kopie, Änderung, Zusammenführung, Veröffentlichung, Weitergabe, Unterlizenzierung und Verkauf auf und verlangt den Hinweis auf das Urheberrecht. Eine Patentklausel hat sie an keiner Stelle. Unter Apache 2.0 stehen gpt-oss (externe Seite, openai.com), dort ergänzt um eine eigene Nut­zungs­richt­linie, Gemma 4 (externe Seite, ai.google.dev) und Mixtral (externe Seite, arxiv.org).

Frei mit Schwellen. Diese Lizenzen erlauben den Einsatz und setzen eine Grenze, ab der eine eigene Vereinbarung nötig wird. Bei Llama 3.1 ist es die Nutzerzahl am Erscheinungstag. Die Lizenz von Qwen2.5-72B (externe Seite, huggingface.co) zählt ebenfalls Nutzer: Wer das Modell kommerziell einsetzt und mehr als 100 Millionen monatlich aktive Nutzer hat, fragt bei Alibaba eine eigene Lizenz an. Die Lizenz von Kimi K3 (externe Seite, huggingface.co) verlangt eine eigene Vereinbarung, wenn der Lizenznehmer Modelle als Dienst anbietet und mit seinen verbundenen Unternehmen in zwölf Monaten über 20 Millionen US-Dollar umsetzt. Gezählt wird der Umsatz des ganzen Unternehmens, auch aus anderen Geschäften. Die Lizenz von Qwen3.8-Max (externe Seite, huggingface.co) zieht die Grenze für Modelldienste und Arbeits­as­sis­tenten bei 50 Millionen US-Dollar, ebenfalls über das ganze Unternehmen gerechnet. Metas Muse Model License (externe Seite, huggingface.co) für Muse Spark Open setzt sie wie Kimi K3 bei 20 Millionen US-Dollar in zwölf Monaten an. Interne Nutzung, Forschung und jedes andere Geschäft als der Modelldienst sind dort ausgenommen.

Mit vererbten Nutzungsverboten. Die RAIL-Lizenz des Modells BLOOM (externe Seite, huggingface.co) vom 19.05.2022 erlaubt Nutzung und Weitergabe und hängt eine Liste von Verboten an. Wer das Modell oder ein Derivat weitergibt, muss diese Verbote als durchsetzbare Bestimmung in seinen eigenen Vertrag aufnehmen und die Empfänger darauf hinweisen. Die Nut­zungs­be­din­gungen von Gemma (externe Seite, gemma.ai) verlangen in Abschnitt 3.1 dasselbe. Der Absatz folgt nach eigenem Vergleich fast Wort für Wort dem Muster von BLOOM. Die Bedingungen gelten für die Gemma-Modelle bis Gemma 3; Gemma 4 steht unter Apache 2.0.

Nichtkommerziell. Die Forschungslizenz von Qwen (externe Seite, huggingface.co) für Qwen2.5-3B-Instruct erlaubt Nutzung, Weitergabe und Änderung allein für nichtkommerzielle Zwecke, also Forschung oder Erprobung. Unter derselben Lizenzform steht das Bildmodell Qwen-Image 2.1 (externe Seite, huggingface.co). Das Zeitreihenmodell TimesFM 3.0 (externe Seite, huggingface.co) hat eine eigene nichtkommerzielle Lizenz. Die Lizenz von FLUX 3 Action (externe Seite, huggingface.co) erlaubt Firmen mit weniger als 5 Millionen US-Dollar Jahresumsatz auch die kommerzielle Nutzung und steht damit zwischen zwei Familien.

Die Lizenz gehört zur Veröffentlichung

Ein Lizenzfeld hängt an einem Repository. Ein Hersteller kann für jedes Modell eine andere wählen, und die großen tun es. Meta hat in 27 Monaten drei Formen benutzt:

• im Juli 2024 die eigene Community License für Llama 3.1;
• im August 2026 Apache 2.0 für Muse Glimmer (externe Seite, huggingface.co);
• im Oktober 2026 die Muse Model License für Muse Spark Open.

Ihre Schwelle setzt die jüngste der drei wie Kimi K3 beim Umsatz an.

Das Datum der Anlage ist eine andere Angabe als das Datum der Veröffentlichung. Das Repository von Llama 3.1 8B Instruct entstand am 18.07.2024, das des pretrained-Modells am 14.07.2024. Erschienen ist Llama 3.1 nach der Modellkarte (externe Seite, github.com) am 23.07.2024. Bei Muse Spark Open wurde das Repository am 15.09.2026 angelegt, und die Lizenz nennt den 15.10.2026 als Erscheinungstag.

Bei anderen Herstellern sieht es so aus, gemessen über die Schnittstelle von Hugging Face am 19.10.2026:

Die Zeile zu Qwen2.5-72B-Instruct ist am 23.10.2026 gemessen.

Google hat zwei Formen benutzt, die eigenen Bedingungen für Gemma 3 und Apache 2.0 für Gemma 4. Bei Qwen unterscheiden sich drei Größen derselben Generation: Das Modell mit 3 Milliarden Parametern steht unter der Forschungslizenz, das mit 7 Milliarden unter Apache 2.0. Für das mit 72 Milliarden gilt die Qwen License mit ihrer Schwelle bei 100 Millionen Nutzern. Die Lizenzprüfung gilt deshalb der einzelnen Datei, mit ihrer Größe und ihrer Fassung.

Ein Derivat bekommt die Bedingungen des Ursprungs mit

Was ein Derivat mitbekommt, legt die Lizenz des Ursprungs fest. Zwei Lizenzen regeln das ausführlich.

Die Nut­zungs­be­din­gungen von Gemma definieren in Abschnitt 1.1 (e), was als Derivat gilt. Dazu zählt jedes Modell, das Muster aus den Gewichten oder den Ausgaben von Gemma übernimmt, damit es ähnlich wie Gemma arbeitet. Die Definition nennt die Destillation ausdrücklich, auch über synthetische Trainingsdaten, die Gemma erzeugt hat. Ein Modell, das aus Antworten von Gemma lernt, um ähnlich wie Gemma zu arbeiten, ist nach diesen Bedingungen also ein Derivat von Gemma. Die Antworten selbst nehmen die Bedingungen ausdrücklich von der Definition aus. Wie solches Lernen funktioniert, zeigt Kapitel 03.

Abschnitt 3.2 derselben Bedingungen geht weiter. Soweit das Recht es zulässt, behält sich Google vor, die Nutzung von Gemma und seinen Derivaten einzuschränken, auch aus der Ferne, wenn es begründet von einem Verstoß ausgeht.

Bei Llama gilt die Namenspflicht aus Abschnitt 1.b.i für jedes weitergegebene oder zugänglich gemachte Modell, das mit Llama oder seinen Ausgaben entstanden ist. Die Modellkarte von Llama 3.1 erlaubt die Destillation zugleich ausdrücklich. Muse Spark Open nennt in seiner Lizenz Fine-Tuning, Destillation und Merge als erlaubte Wege.

In Beurteilen und Einordnen, Kapitel 02 steht, dass eine abgestimmte Fassung bei offenen Gewichten mit Ihnen umzieht, wenn Sie den Betreiber wechseln. Mit ihr zieht die Lizenz des Ursprungs um. Wer ein Fine-Tune von Llama weitergibt, legt nach Abschnitt 1.b die Lizenz und die Datei Notice bei und setzt das Wort Llama an den Anfang des Namens.

Die Sperre gilt dem Original

Ein Hersteller kann sein Repository bei Hugging Face sperren. Nach der Doku zu gesperrten Modellen (externe Seite, github.com) teilen Nutzer dann ihren Benutzernamen und ihre E-Mail-Adresse mit dem Hersteller, bevor sie die Dateien bekommen. Standardmäßig wird der Zugang auf Anfrage sofort erteilt. Meta hat für Llama 3.1 8B (externe Seite, huggingface.co) auf Freigabe von Hand umgestellt, beim pretrained-Modell wie beim Instruct-Modell.

Die Sperre ist eine Einstellung des einzelnen Repositorys. Kopien in anderen Repositories haben ihre eigene. Eine eigene Messung der Dateiköpfe (externe Seite, huggingface.co) vom 19.10.2026 hat vier Quantisierungen von Llama 3.1 8B Instruct im Format GGUF untersucht. Alle vier waren ohne Sperre abrufbar: die Repositories von lmstudio-community, bartowski und unsloth bei Hugging Face und das Modell llama3.1:8b im Katalog von Ollama.

Die Lizenz nennen drei der vier Dateien selbst, im Feld general.license mit der Kennung llama3.1. In der Datei von unsloth fehlt das Feld. Ollama liefert den Lizenztext samt Nut­zungs­richt­linie als eigenen Teil des Pakets mit, 12.320 Byte groß. In den drei Repositories bei Hugging Face liegt weder eine Datei LICENSE noch eine Datei NOTICE. Den Lizenztext enthält nur die Modellkarte von bartowski, in ihren Metadaten. Ob das den Pflichten aus Abschnitt 1.b.i genügt, ist eine Rechtsfrage. Gemessen ist hier, was in den Dateien und Repositories steht.

Der Model tree ist eine Selbstauskunft

Der Model tree entsteht aus dem Feld base_model. Die Doku zu Modellkarten (externe Seite, github.com) beschreibt es als Angebot: Wer ein Fine-Tune, einen Adapter oder eine Quantisierung hochlädt, kann das Ursprungsmodell in den Metadaten nennen. Die Art der Beziehung leitet der Hub selbst ab, als Adapter, Merge, Quantisierung oder Fine-Tune. Festlegen lässt sie sich mit einem zweiten Feld, base_model_relation.

Beides hat Folgen. Zwei davon sind am Beispiel gemessen, am 19.10.2026.

• Eine falsche Art. Das Repository shenzhi-wang/Llama3.1-8B-Chinese-Chat ist nach seiner eigenen Karte ein Fine-Tune von Metas Instruct-Modell, abgestimmt mit dem Verfahren ORPO. Der Hub führt es in der Liste der Quantisierungen (externe Seite, huggingface.co). Das Repository enthält zusätzlich GGUF-Dateien, vermutlich ist das der Grund. Ein Feld base_model_relation steht nicht in der Karte.
• Eine fehlende Generation. Das Repository QuantFactory/Llama3.1-8B-Chinese-Chat-GGUF nennt im Text der Karte als Ursprung das Fine-Tune von shenzhi-wang. In den Metadaten steht Metas Instruct-Modell. Die Karte wurde samt den Metadaten ihres Vorgängers kopiert, und im Model tree fehlt dadurch eine Stufe.

Der Model tree zeigt also, was die Hochladenden eingetragen haben, sortiert nach einer Regel des Hubs. Der Text der Karte ist eine zweite Quelle, und beide können einander widersprechen. Wie man einen Ursprung Schritt für Schritt prüft, zeigt die dritte Ebene.

Gewichte, Code, Daten: drei Dinge, die offen sein können

Die Open Source Initiative hat am 28.10.2024 die Open Source AI Definition 1.0 (externe Seite, opensource.org) veröffentlicht. Sie verlangt vier Freiheiten: das System für jeden Zweck zu nutzen, ohne um Erlaubnis zu fragen, es zu untersuchen, es zu verändern und es weiterzugeben. Dafür braucht es drei Bestandteile.

• Angaben zu den Daten. Die Definition verlangt so genaue Angaben über die Trainingsdaten, dass eine Fachperson ein im Wesentlichen gleichwertiges System bauen kann. Für öffentlich verfügbare und bei Dritten beziehbare Trainingsdaten verlangt sie eine Liste mit der Bezugsquelle, auch wenn der Bezug Geld kostet.
• Den Code für Training und Betrieb.
• Die Parameter, also die Gewichte.

Die Anforderung gilt auch, wenn jemand nur Gewichte veröffentlicht. Wer sie als Open-Source-Gewichte bezeichnen will, muss nach der Definition die Angaben zu den Daten und den Code mitliefern.

In einer Prüfphase (externe Seite, opensource.org) haben Freiwillige einzelne Modelle an der Definition gemessen. Bestanden haben Pythia, OLMo, Amber, CrystalCoder und T5. Durchgefallen sind Llama 2, Grok, Phi-2 und Mixtral, weil Bestandteile fehlten oder die Verträge den Grundsätzen widersprachen. Einige weitere, darunter BLOOM, würden nach der FAQ wahrscheinlich bestehen, wenn sie ihre Lizenz änderten. Die OSI betont, dass diese Listen keine Zertifizierung sind, und einzelne Systeme prüft sie nach eigener Aussage selbst nicht.

Mixtral ist dabei der auf­schluss­reichste Fall. Die Gewichte stehen unter Apache 2.0, einer Lizenz, die auf der Liste der OSI (externe Seite, opensource.org) steht. Die FAQ nennt die Gründe nur zusammengefasst, mit „und/oder“. Nach eigener Ableitung liegt für Mixtral der erste Grund nahe: Es fehlten Bestandteile. Eine freie Lizenz im Lizenzfeld reicht nach dieser Definition für ein offenes Modell also nicht aus.

Für Open Weights (externe Seite, opensource.org) hat die OSI eine eigene Seite. Sie versteht darunter die fertigen Gewichte eines trainierten Netzes, denen nach ihrer Lesart Trainingscode, Trainingsdaten und vollständige Datenangaben fehlen. Den Nutzen für andere sieht sie, wenn die Gewichte unter einer von ihr anerkannten Lizenz geteilt werden. Die Lizenz von Llama 3.1 steht nicht auf ihrer Liste. Diese Seite benutzt offene Gewichte im Sinn ihres Glossars: Die gelernten Zahlen eines Modells stehen zum Herunterladen bereit.

Wie weit zwei Familien auseinanderliegen, zeigen ihre Herkunftsketten. Die Modellkarte von Olmo 3.1 (externe Seite, huggingface.co) nennt die Datensätze für Vor- und Nachtraining beim Namen, Dolma 3 und Dolci. Ai2 gibt Code, Zwischenstände und die Einzelheiten des Trainings heraus. Über das Feld base_model lässt sich jede Stufe zurückverfolgen, gemessen am 19.10.2026: Olmo-3.1-32B-Instruct, davor eine Stufe mit DPO, davor eine mit überwachtem Fine-Tuning, davor das pretrained-Modell Olmo-3-1125-32B. Jede Stufe liegt als eigenes Repository vor, und die Seite des pretrained-Modells verlinkt den Datensatz, der heute als allenai/dolma3_mix-6T abrufbar ist.

Bei Llama 3.1 liegen zwei Stufen als Repository vor. Im Model tree folgt das Instruct-Modell direkt auf das pretrained-Modell. Zu den Daten nennt die Modellkarte (externe Seite, github.com) rund 15 Billionen Token aus öffentlich verfügbaren Quellen mit Stichtag Dezember 2023, für das Fine-Tuning dazu öffentliche Anwei­sungs­da­ten­sätze und über 25 Millionen synthetisch erzeugte Beispiele. Einen Datensatz nennt sie beim Namen an keiner Stelle.

Eine politische Haltung wandert über die Trainingsdaten

Offene Modelle aus China antworten auf politische Fragen anders als Modelle aus anderen Ländern. Jennifer Pan (Stanford) und Xu Xu (Princeton) haben neun Modelle mit 145 politischen Fragen auf Chinesisch und Englisch geprüft (Studie in PNAS Nexus (externe Seite, pmc.ncbi.nlm.nih.gov)). Die vier Modelle aus China verweigerten die Antwort deutlich häufiger, antworteten kürzer und öfter ungenau. BaiChuan verweigerte 60 Prozent der Fragen. Eine Ursache belegt die Studie nach eigener Aussage nicht.

Für Dienste, die generative KI in China der Öffentlichkeit anbieten, gelten seit dem 15.08.2023 vorläufige Maßnahmen (externe Seite, cac.gov.cn) der Internetaufsicht und sechs weiterer Behörden. Sie verlangen, an den sozialistischen Kernwerten festzuhalten. Ausgenommen ist, wer keinen solchen Dienst für die Öffentlichkeit in China anbietet.

Aleph Alpha hat im September 2026 sechs offene Modelle aus China mit 967 politisch heiklen Aufträgen geprüft (Bericht (externe Seite, aleph-alpha.com)). Ausgewogen antworteten sie bei 17 bis 41 Prozent. Erzeugt hat die Aufträge ein Modell, und bewertet hat ebenfalls eines, GPT-OSS 120B. Den Benchmark hat Aleph Alpha nicht veröffentlicht. Das Unternehmen baut selbst Modelle, die es souverän nennt, und empfiehlt für sie genau diese Prüfung.

In derselben Messung antwortete Nemotron Cascade 2 von NVIDIA zu 75 Prozent ausgewogen. In den veröffentlichten Daten seines Fine-Tunings fand Aleph Alpha rund 3.500 von 9,3 Millionen Chat-Zeilen mit Positionen der Kommunistischen Partei Chinas. Die meisten Antworten dieser Daten hat laut NVIDIAs Bericht (externe Seite, arxiv.org) GPT-OSS-120B erzeugt, beteiligt waren auch DeepSeek-V3 und Qwen3. Prüfen ließ sich das nur, weil die Daten offen liegen.

Wie weit eine Haltung mitwandert, hängt an den Daten. Eine Untersuchung an DeepSeek-R1 (R1dacted (externe Seite, arxiv.org)) fand bei DeepSeeks eigenen destillierten Schülern die üblichen Formen der Zensur nur in sehr wenigen Fällen. Danach mischten die Verfasser 30 zensierende Beispiele in einen Datensatz von 1.000 Beispielen und trainierten damit einen eigenen Schüler. Er zensierte beim Thema Taiwan 95,5 Prozent der Testfragen. Wie solche Schüler entstehen und was der Versuch sonst an ihm verändert hat, steht in der dritten Ebene von Kapitel 03.

Der Überblick endet mit vier Fragen an jede Datei. Diese Ebene beantwortet zwei davon technisch: was der Rechner beim Laden einer Modelldatei ausführt und woran sich der Ursprung einer Datei erkennen lässt. Gemessen wird an Llama 3.1 8B Instruct, am Original bei Meta und an vier Quantisierungen von Dritten.

Beim Laden einer Pickle-Datei läuft Code

Pickle ist das eingebaute Verfahren von Python, um Objekte in einer Datei zu speichern. Auch PyTorch-Checkpoints wie die Datei consolidated.00.pth in Metas Ordner sind so gespeichert. Die Python-Doku (externe Seite, docs.python.org) warnt in einem Kasten: Präparierte Pickle-Daten können beim Laden beliebigen Code ausführen. Sie rät, nur Daten aus ver­trau­ens­wür­diger Quelle zu laden.

Die Mechanik beschreibt die Doku von Hugging Face (externe Seite, github.com). Eine Pickle-Datei ist eine Folge von Anweisungen, die beim Laden abgearbeitet werden. Die Anweisungen GLOBAL und STACK_GLOBAL holen eine Funktion aus einem beliebigen Modul, REDUCE ruft sie mit Argumenten auf. Damit kann eine Modelldatei beim Laden jedes Programm auf dem Rechner starten. Hugging Face durchsucht hochgeladene Pickle-Dateien nach solchen Anweisungen und sagt selbst, dass der Scanner nicht jeden Fall findet.

Seit PyTorch 2.6, erschienen am 29.01.2025, lädt torch.load standardmäßig mit weights_only=True. Nach den Ände­rungs­hin­weisen (externe Seite, github.com) ruft dann ein eingeschränkter Unpickler nur die Funktionen und Klassen auf, die für Gewichte und einfache Datentypen nötig sind. Wer weights_only=False setzt, hebt diese Einschränkung auf. Auch mit dieser Voreinstellung rät PyTorch, nur vertrauenswürdige Checkpoints zu laden und für fremde Dateien Formate wie safetensors zu nehmen.

Dass die Gefahr praktisch besteht, belegt ein Bericht des Sicher­heits­an­bie­ters JFrog (externe Seite, jfrog.com) vom 27.02.2024. JFrog fand bei Hugging Face rund 100 Modelle, die beim Laden Schadcode ausführen. Dazu der Vorbehalt: JFrog verkauft Prüfwerkzeuge für genau diesen Fall. Neben Pickle-Dateien nennt der Bericht Modelle im Format Keras als zweiten Träger. Ein Format ohne Pickle schützt also nur, wenn es selbst keinen Code vorsieht.

Metas Ordner liefert die Gewichte in zwei Formaten

Das Repository von Llama 3.1 8B Instruct (externe Seite, huggingface.co) liefert beide Formate nebeneinander, gemessen am 19.10.2026:

Das Modell hat 8.030.261.248 Parameter, alle im Datentyp BF16 mit zwei Byte je Zahl. Das ergibt 16.060.522.496 Byte reine Zahlen. Die safetensors-Dateien liegen 33.880 Byte darüber, die Pickle-Datei 95.096 Byte. Beide Größen passen zu denselben Gewichten mit wenig Verwaltung drumherum.

Eine Datei im Format safetensors (externe Seite, github.com) beginnt mit acht Byte für die Länge des Kopfs. Danach folgt der Kopf als JSON, dahinter stehen nur noch Zahlen. Einen Teil, der beim Laden ausgeführt würde, sieht das Format an keiner Stelle vor. Wie man den Kopf mit zwei Range-Requests liest, ohne die Gigabyte dahinter zu laden, steht in Kapitel 01. Wer nur die safetensors-Dateien braucht, lässt beim Herunterladen den Ordner original/ aus.

Hinter Q4_K_M stehen drei Rezepte

Q4_K_M ist eine Quan­ti­sie­rungs­stufe von llama.cpp, die Typen mischt. Die meisten Tensoren stehen im Typ Q4_K mit gut 4 Bit, einige im Typ Q6_K mit gut 6 Bit, 66 kleine in voller Genauigkeit. Unter diesem Namen bieten viele Repositories Llama 3.1 8B Instruct an. Für vier Dateien, drei bei Hugging Face und eine bei Ollama, zeigt eine eigene Messung (externe Seite, huggingface.co), was darin steht. Gelesen wurden je die ersten 12 MB per Range-Request, und darin der Kopf nach der GGUF-Spezifikation, darunter das Lizenzfeld general.license. Gemessen ist damit nur der Kopf.

Gemeinsam ist allen vier das Format GGUF in Version 3, mit 292 Tensoren und dem Dateityp 15 für Q4_K_M. In allen vier stehen 66 Tensoren in F32, 193 in Q4_K und 33 in Q6_K. Trotzdem hat jede Datei eine eigene Prüfsumme nach SHA-256. Drei Unterschiede zeigt der Kopf:

• Die Kalibrierung. llama.cpp kann vor dem Quantisieren eine Importance Matrix (imatrix) berechnen. Die Doku des Werkzeugs (externe Seite, github.com) beschreibt sie als Matrix aus einem Modell und einem Textdatensatz, die beim Quantisieren die Qualität verbessern kann. Ollama hat ohne sie quantisiert. lmstudio-community und bartowski haben denselben Kalibriertext benutzt, unsloth einen eigenen, mit 689 statt 125 Abschnitten.
• Die Zuordnung der Typen. Bei unsloth haben 16 Tensoren einen anderen Typ. In 8 Blöcken sind die Typen von attn_v und ffn_down vertauscht, Q4_K gegen Q6_K. Die Summen je Typ bleiben dabei gleich.
• Die Metadaten. In der Datei von unsloth fehlt das Lizenzfeld. Dafür nennt sie sich selbst als Quantisierer, mit ihrem Konto bei Hugging Face, und setzt ein Padding-Token, padding_token_id mit dem Wert 128004.

Daraus ergeben sich drei Rezepte: ohne Kalibrierung, mit dem Kalibriertext von lmstudio-community und bartowski und mit dem eigenen Datensatz von unsloth. Der Name der Stufe verrät davon nichts. Ob die Unterschiede beim Antworten messbar sind, sagt der Kopf ebenso wenig; dazu braucht es eine Messung an der eigenen Aufgabe.

Die größte der vier Dateien hat 4.920.739.232 Byte. Mal 8 und geteilt durch 8.030.261.248 Parameter ergibt das 4,90 Bit je Parameter. Die Datei wiegt 30,6 Prozent der safetensors-Fassung in BF16. Wie sich die Bit je Parameter in eine Dateigröße übersetzen, steht in der dritten Ebene von Beurteilen und Einordnen, Kapitel 01.

Im selben Kapitel steht, dass Ollama und LM Studio GGUF-Dateien ausführen. Die Dateien hinter einem Namen wie Q4_K_M sind trotzdem verschieden. Eine Umwandlung kann auch Teile weglassen. Der Beitrag über lokale Modelle und ihr Tempo fand in vier GGUF-Dateien aus der Sammlung, die LM Studio vorschlägt, keinen der MTP-Köpfe, mit denen ein Modell schneller antworten kann.

Die Herkunftsfelder von GGUF bleiben leer

Die Spezifikation von GGUF (externe Seite, github.com) sieht für die Herkunft eigene Felder vor. Unter general.base_model.* steht das Modell, aus dem die Datei entstanden ist, unter general.source.* die Quelle, aus der sie umgewandelt wurde. Die Spezifikation begründet das mit der Rückverfolgung: Wird ein Modell verändert, soll sich das Original wiederfinden lassen.

Gemessen an den vier Dateien oben ist das Ergebnis eindeutig: Keine füllt eines dieser Felder. Drei nennen nur den Modellnamen. Die Datei von unsloth nennt dazu sich selbst als Quantisierer und ihr Konto bei Hugging Face. Aus welcher Datei umgewandelt wurde, steht in keinem Kopf, nur in den Metadaten des Repositorys. Wer eine GGUF-Datei weitergibt, ohne das Repository zu nennen, gibt sie ohne Herkunft weiter.

Ein Derivat lässt sich in fünf Schritten zurückverfolgen

Die zweite Ebene hat gezeigt, dass der Model tree auf Angaben der Hochladenden beruht. Wer wissen will, woher eine Datei stammt, prüft deshalb mehrere Stellen gegeneinander. Das Beispiel ist das Repository QuantFactory/Llama3.1-8B-Chinese-Chat-GGUF, geprüft am 19.10.2026.

Schritt 3 widerspricht Schritt 1. Die Karte wurde samt Metadaten von ihrem Vorgänger kopiert. Im Model tree fehlt dadurch eine Generation, und das Fine-Tune dazwischen taucht dort nur als Quantisierung auf. Die Doku zu Modellkarten (externe Seite, github.com) erklärt, warum das möglich ist: Das Feld ist freiwillig, und die Art leitet der Hub ab, solange base_model_relation sie nicht festlegt.

Für die Lizenz zählt der Anfang der Kette. Hier steht Metas Instruct-Modell und damit die Lizenz von Llama 3.1 (externe Seite, github.com). Abschnitt 1.b.i nennt ausdrücklich auch Modelle, die mit Llama oder seinen Ausgaben entstanden sind und weitergegeben oder zugänglich gemacht werden.

Welche Kinder ein Modell hat, liefert die Schnittstelle in umgekehrter Richtung: api/models?filter=base_model:<art>:<repo> listet sie seitenweise. So sind die Zahlen der ersten Ebene gezählt.

Kopien überdauern das Original

Abschnitt 6 der Lizenz von Llama verpflichtet den Lizenznehmer, dessen Lizenz endet, die Materialien zu löschen. Ein Hersteller kann sein eigenes Repository löschen oder sperren. Die Kopien liegen in anderen Repositories, bei anderen Konten und in anderen Formaten.

Wie viele Kopien entstehen und wie gut sie das Original überleben, hat eine Arbeit von 10a Labs an entsperrten offenen Modellen (externe Seite, arxiv.org) untersucht. Sie ist ein Vorabdruck ohne Begutachtung, und die Repositories hat dort ein Sprachmodell eingeordnet, GPT-5. Nach ihrem Abstract zählte sie für den Zeitraum von Januar 2024 bis März 2026 insgesamt 3.471 ursprüngliche entsperrte Modelle und 8.164 komprimierte Wei­ter­ver­tei­lungen. Drei Akteure stehen für 52 Prozent dieser Wei­ter­ver­tei­lungen. Einmal quantisiert und über Konten, Formate und Kataloge wie den von Ollama gespiegelt, bleiben die Modelle nach der Arbeit erhalten, auch wenn das Original verschwindet.

Ein solches Entsperren beschreibt Conversational AI, Kapitel 07 in der zweiten Ebene: Die Abliteration rechnet die Ablehnung aus den Gewichten heraus, und heraus kommt ein neues Modell, das sich weitergeben lässt. Für den Einsatz heißt das: Wer ein Modell aus fremder Hand verwendet, prüft seine Herkunft vor dem Einsatz. Löscht der Hersteller sein Repository, bleibt die eigene Kopie auf der Platte; welche Pflichten dann gelten, steht im Lizenztext.

Lizenzfeld, Downloadzahl und Derivatzahl lesen

Drei Angaben bei Hugging Face sehen aus wie eine Antwort und brauchen eine Einordnung.

Das Lizenzfeld. Steht dort apache-2.0, erlaubt die genannte Lizenz Nutzung und Weitergabe. Das Feld setzt der Hochladende, und bei einem Derivat gilt zusätzlich die Lizenz des Ursprungs. Ob das Modell nach der Definition der OSI offen ist, hängt zusätzlich an Code und Angaben zu den Daten. Mixtral (externe Seite, arxiv.org) steht unter Apache 2.0 und ist in der Prüfphase der OSI (externe Seite, opensource.org) durchgefallen, wie die zweite Ebene zeigt.

Die Downloadzahl. Nach der Doku von Hugging Face (externe Seite, github.com) zählt bei GGUF jede einzelne Datei als Download, weil jede für sich vollständig ist. Bei anderen Repositories zählt eine Anfrage an eine festgelegte Datei wie config.json. Downloadzahlen eines GGUF-Repositorys und seines Originals zählen damit Anfragen an verschiedene Dateien. Wer ein ganzes GGUF-Repository klont, zählt mehrfach; die meisten laden nach der Doku aber eine einzelne Datei. Ein Vergleich der beiden braucht diesen Vorbehalt.

Die Zahl der Derivate. Der Bericht von Hugging Face (externe Seite, huggingface.co) vom August 2026 ist eine Selbstauskunft der Plattform. Er wertet die Zahl der Derivate als Zeichen dafür, wie viel auf einem Modell weitergebaut wird. Seine Angaben zur Methode warnen davor, die Zahlen als direktes Maß für Qualität, Verbreitung im Geschäft oder Marktanteil zu lesen. Auch die Rangfolge hängt an der Zählweise: Bei allen Derivaten zusammen liegt Qwen nach dem Bericht vorn, bei den GGUF-Repositories liegt Llama knapp vorn.

Am Aufwand lässt sich die Verteilung im Model tree ebenso wenig ablesen. Ein Merge ist billig herzustellen: Nach der Beschreibung von mergekit (externe Seite, github.com) läuft er ganz auf dem Prozessor oder mit einer Grafikkarte ab 8 GB Speicher. Trotzdem bilden die Merges an beiden Knoten von Llama 3.1 8B die kleinste Gruppe, mit 105 und 71.