Gleicher Name, neuer Digest: Wie Ollama ein Modell ablegt

Am 28. Oktober 2026 meldete ein Wächter, der jeden Morgen die lokal genutzten Modelle prüft, zwei Auffälligkeiten. Die Modelle gemma4:26b und gemma4:31b hatten über Nacht einen neuen Digest bekommen, bei unverändertem Namen. Und beide antworteten in seiner Funktionsprobe deutlich schneller als am Vortag: das 26B in 11,0 statt 17,9 Sekunden, das 31B in 10,6 statt 24,1.

Ein Blick in die Ablage zeigte, dass sich mehr geändert hatte als eine Zahl. Jetzt bestand das 26B aus 1162 einzelnen Dateien, eine je Tensor, und lief über einen anderen Unterbau. Das Serverprotokoll von Ollama zeigt, was vorher da war. Am selben Nachmittag lud es die alte Fassung über llama.cpp, aus genau den Dateien, die die Registry heute als GGUF-Variante für alle anderen Rechner führt.

Dieser Beitrag geht der Sache von Grund auf nach. Er erklärt, wie Ollama ein Modell ablegt und was ein Digest und ein Manifest sind. Er vergleicht die beiden Formate, beschreibt, wie Quantisieren funktioniert, und misst das Tempo beider Varianten. Gemessen ist auf einem MacBook Pro mit M4 Max und 64 GB Arbeitsspeicher, mit Ollama 0.40.15, am 09.11.2026.

Ein Name zeigt seit Ende Oktober auf zwei Varianten

Der Befund in einem Satz: Ollama liefert Gemma 4 für Apple-Rechner neu verpackt und neu quantisiert aus, für alle anderen Rechner als GGUF-Datei in Q4_K_M. Beide Formen stehen unter demselben Namen. Welche ein Rechner bekommt, entscheidet Ollama beim Herunterladen.

Quelle: eigene Auswertung der Manifeste aus der Registry (externe Seite, registry.ollama.ai) und der Ablage am Gerät, 09.11.2026.

Damit unterscheiden sich die Varianten in drei Dingen:

• in der Verpackung, also wie die Zahlen auf der Platte liegen,
• in der Quantisierung, also mit wie vielen Bit jede Zahl gespeichert ist,
• im Runner, dem Programmteil, das die Zahlen beim Antworten durchrechnet. Bei der einen Variante ist es llama.cpp, bei der anderen MLX, Apples eigenes Rechenframework für maschinelles Lernen.

Der Beitrag erklärt alle drei einzeln. Zuerst kommt die Ablage, denn an ihr lässt sich alles Weitere ablesen.

Ollama legt ein Modell ab wie ein Container-Image

Ollama verwaltet diese Teile so, wie Docker und andere Container-Werkzeuge ihre Images verwalten. Es übernimmt sogar deren Dateiformate. Das Prinzip hat drei Ebenen:

1. Ein Name zeigt auf ein Manifest.
2. Das Manifest zählt die Blobs auf.
3. Jeder Blob ist eine Datei, deren Name ihre eigene Prüfsumme ist.

seitlich verschiebbar

eigene Darstellung nach der Ablage am MacBook Pro, Ollama 0.40.15, Stand 09.11.2026

Der Name führt zu einer Manifest-Liste

Auf einem Mac liegen alle Modelle unter ~/.ollama/models. Der Name gemma4:26b entspricht dort einem Eintrag im Ordner manifests-v2:

~/.ollama/models/manifests-v2/ollama.com/library/gemma4/26b
  -> ../../../../blobs/sha256-ed3c4359df980cb0b74949ea6a8a5089a6ec87fbfe2bbe21d0529fc9f4c7013c

Der Eintrag ist ein symbolischer Verweis auf eine Datei im Ordner blobs. Sie ist 470 Byte groß und vollständig lesbar:

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.ollama.manifest.list.v2+json",
  "manifests": [
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "digest": "sha256:001e5dafc3c77684c2307ebc6ab8e336e10c9b18eca52acf547d72fc83c3ca8c",
      "runner": "llamacpp",
      "format": "gguf"
    },
    {
      "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
      "digest": "sha256:48eb98ec778c163d87f69d735fcdd79e345063af9af4685613fd018ae5debf5e",
      "runner": "mlx",
      "format": "safetensors"
    }
  ]
}

Das ist eine Manifest-Liste. Sie nennt zwei Manifeste, je eines für eine Variante, und schreibt an jedes, welcher Runner es ausführt und in welchem Format es vorliegt. Das Vorbild ist der Image Index (externe Seite, github.com) der Container-Welt, dort wählt ein Rechner nach Prozessor und Betriebssystem die passende Fassung eines Images. Ollama wählt nach dem Runner. Im Quelltext (externe Seite, raw.githubusercontent.com) steht die Reihenfolge: Ein Mac mit Apple-Chip bevorzugt MLX, dann llama.cpp, dann Ollamas eigene Engine. Jeder andere Rechner bevorzugt llama.cpp. Dass auf Apple-Chips MLX vorn steht, kündigen schon die Release Notes zu 0.40 (externe Seite, github.com) an: Dort läuft jede Bauform, die MLX unterstützt, automatisch darüber.

Daneben steht unter manifests/registry.ollama.ai/library/gemma4/26b eine zweite Datei mit dem vollständigen Manifest der gewählten Variante. Ollama schreibt sie nach dem Herunterladen als Rückfall-Anker. Eine ältere Fassung, die keine Manifest-Listen kennt, kann das Modell darüber laden. An die Layer dieser Datei hängt Ollama außerdem die Manifest-Liste und das gewählte Manifest an. So löscht die Spei­cher­be­rei­ni­gung der älteren Fassung diese beiden Blobs nicht. Das steht im Quelltext der Manifestablage (externe Seite, raw.githubusercontent.com) und im Quelltext des Servers (externe Seite, raw.githubusercontent.com). Ob dieser Anker dauerhaft bleibt, sagt der Quelltext nicht. Für die Sicherungen, die Ollama beim Aufrüsten älterer Modelle anlegt, sagen die Release Notes zu 0.40.2 (externe Seite, github.com): Sie bleiben nur vorübergehend auf der Platte, und eine künftige Fassung soll sie automatisch entfernen.

Das Manifest zählt die Teile auf

Das Manifest der MLX-Variante ist 252.937 Byte groß, weil es 1175 Einträge hat. Sein Anfang:

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
  "config": {
    "mediaType": "application/vnd.docker.container.image.v1+json",
    "digest": "sha256:3a77d9b825b3c48b651f4e52e2e17abf3f3ea96923972776ad8424dc089da0c5",
    "size": 419
  },
  "layers": [
    {
      "mediaType": "application/vnd.ollama.image.tensor",
      "digest": "sha256:1483d6c2dfab956ed72f3582b6a7230213e366a7c9661579e83202e7e9dadb8d",
      "size": 761266456,
      "name": "model.language_model.embed_tokens.weight"
    }
  ]
}

Der Ausschnitt zeigt von den 1175 Einträgen unter layers nur einen. Das Schema folgt der Manifest-Spezifikation von Docker (externe Seite, github.com): ein Verweis auf eine Konfiguration (config) und eine Liste von Schichten (layers). Jeder Eintrag nennt einen Medientyp, eine Größe und einen Digest. Ollama ergänzt bei Tensoren und JSON-Dateien das Feld name, das die Spezifikation für Schichten nicht vorsieht. Außerdem nutzt es eigene Medientypen, und an ihnen lässt sich die Art eines Teils ablesen:

Die GGUF-Variante kommt mit sechs Einträgen aus. Der Medientyp model steht für das Sprachmodell (17,07 GB), projector für den Bildteil (1,19 GB) und draft für ein kleines Entwurfsmodell (0,46 GB). Dazu kommen Vorlage, Lizenz und Parameter. Ein klassisch abgelegtes Modell wie qwen3:30b hat sogar nur fünf.

Der Config-Blob beschreibt das Modell

Der Eintrag unter config zeigt auf eine 419 Byte kleine Datei, die das Paket als Ganzes beschreibt:

{
  "model_format": "safetensors",
  "generation_defaults": { "temperature": 1, "top_k": 64, "top_p": 0.95 },
  "renderer": "gemma4",
  "parser": "gemma4",
  "requires": "0.34.1",
  "capabilities": ["completion", "vision", "tools", "thinking"],
  "draft": {
    "model_format": "safetensors",
    "architecture": "Gemma4AssistantForCausalLM",
    "tensor_prefix": "draft.",
    "config": "draft/config.json"
  }
}

Der Ausschnitt lässt vier leere Felder weg. Vier Angaben darin erklären viel:

• requires nennt die älteste Ollama-Fassung, die das Paket ausführen kann. Beim Herunterladen liest Ollama zuerst den Config-Blob und vergleicht die Angabe mit der eigenen Fassung. Ist die eigene älter, bricht der Download mit einer Fehlermeldung ab, bevor die Teile des Modells geladen werden. So steht es im Quelltext (externe Seite, raw.githubusercontent.com) von 0.40.15.
• renderer und parser ersetzen die Gesprächsvorlage. Bei qwen3:30b baut eine 1506 Byte lange Vorlage den Text zusammen, den das Modell sieht. Bei Gemma 4 übernimmt das Programmcode in Ollama, und ein zweites Stück Code zerlegt die Antwort in Denkspur, Text und Werkzeugaufrufe. Die Vorlage im Paket ist dann wirkungslos. Sie besteht deshalb nur noch aus {{ .Prompt }}.
• capabilities sagt, was das Modell kann: Text, Bilder, Werkzeuge und eine Denkspur. Die Denkspur ist voreingestellt eingeschaltet, das zeigt ollama show.
• draft verweist auf ein zweites, kleines Modell im selben Paket. Seine Tensoren beginnen mit der Vorsilbe draft. und liegen zwischen denen des großen Modells. Wozu es dient, steht im Abschnitt über das Tempo.

Jeder Teil heißt nach seiner Prüfsumme

In der Container-Welt heißt diese Prüfsumme Digest. Die OCI-Spezifikation (externe Seite, github.com) beschreibt ihn als Kennung des Inhalts, gebildet als kol­li­si­ons­re­sis­tente Prüfsumme über die Bytes, und empfiehlt SHA-256. Geschrieben wird er als Verfahren, Doppelpunkt, Summe: sha256:b507b9c2…. Ollama legt jeden Blob unter genau diesem Namen ab, mit einem Bindestrich statt des Doppelpunkts. So steht es im Quelltext der Ablage (externe Seite, raw.githubusercontent.com).

Am kleinsten Blob von Gemma 4 lässt sich das nachrechnen. Die Vorlage ist 13 Byte lang:

$ printf '{{ .Prompt }}' | shasum -a 256
b507b9c2f6ca642bffcd06665ea7c91f235fd32daeefdf875a0f938db05fb315  -

$ ls ~/.ollama/models/blobs/ | grep b507b9c2
sha256-b507b9c2f6ca642bffcd06665ea7c91f235fd32daeefdf875a0f938db05fb315

$ printf '{{ .Prompt }} ' | shasum -a 256
5b16913cae6cfcf7452f2c2707b065f75823a00e452913eaea74028d5d4dd85d  -

Ein angehängtes Leerzeichen gibt eine Summe, die mit der ersten nichts mehr gemein hat. Für die Manifeste gilt dasselbe. Ollama behandelt ein Manifest selbst als Blob, und sein Digest ist die Prüfsumme über seine JSON-Bytes. Auch die Manifest-Liste von oben heißt deshalb sha256-ed3c4359…, und shasum -a 256 auf die Datei ergibt genau diese Zahl. Die Kennung, die ollama list neben jedem Modell zeigt, sind die ersten zwölf Zeichen des Digests der gewählten Variante, hier 48eb98ec778c.

Daraus folgt eine Kette. Der Name zeigt auf die Liste, die Liste nennt die Digests zweier Manifeste, jedes Manifest nennt die Digests seiner Blobs. Ändert sich irgendwo unten ein Byte, ändert sich der Digest dieses Blobs, damit der Text des Manifests, damit dessen Digest, damit der Text der Liste. Beim Herunterladen rechnet Ollama die Summe jedes geladenen Blobs nach. Stimmt sie nicht, löscht es die Datei und meldet einen Fehler. Dafür gibt es zwei Wege im Quelltext: einen für Modelle mit einzelnen Tensoren im Quelltext des Herunterladens (externe Seite, raw.githubusercontent.com) und einen für alle anderen im Quelltext des Servers (externe Seite, raw.githubusercontent.com). Ein Blob, der schon auf der Platte liegt, wird nicht noch einmal geladen und dabei nicht erneut geprüft. Ein Manifest prüft Ollama zusätzlich bei jedem Lesen von der Platte gegen seinen Digest, so steht es im Quelltext der Manifestablage (externe Seite, raw.githubusercontent.com).

Gleiche Teile liegen nur einmal auf der Platte

Weil der Name einer Datei aus ihrem Inhalt folgt, liegt gleicher Inhalt automatisch nur einmal vor. Ein Modell, das einen vorhandenen Blob braucht, verweist einfach auf dieselbe Datei. Am Gerät lässt sich das zählen:

Die beiden MLX-Varianten teilen sich unter anderem Teile des Bild­ver­ständ­nisses, das Vokabular des Entwurfsmodells und die Lizenzdatei. Zwei Verpackungen desselben Modells teilen sich fast nichts. Sogar die Lizenz liegt doppelt vor: derselbe Text von Apache 2.0 mit 11.358 Byte in der GGUF-Variante und mit 10.170 Byte in der MLX-Variante. Gelöscht wird ein Blob erst, wenn kein Manifest mehr auf ihn verweist. So steht es im Quelltext (externe Seite, raw.githubusercontent.com) für den Befehl ollama rm.

Ein neuer Digest meldet geänderte Bytes, den Grund zeigt das Manifest

Ein Name wie gemma4:26b ist in der Registry ein beweglicher Zeiger. Lädt Ollama ihn neu herunter, zeigt er danach auf das, was die Registry jetzt unter diesem Namen führt. Der Digest dagegen ist an einen Inhalt gebunden. Ein neuer Digest bei gleichem Namen sagt deshalb nur, dass irgendwo ein Byte anders ist. Dafür gibt es mehrere Gründe, und das Manifest zeigt, welcher vorliegt:

Behobene Umwandlungen kommen bei neuen Modellen in den ersten Wochen häufig vor. Bei Gemma 4 trafen auf dem Mac die ersten beiden Gründe zusammen: eine neue Verpackung und eine neue Quantisierung. Für alle anderen Rechner hat sich an den Gewichten nichts geändert. Das zeigt das Serverprotokoll vom 28.10.2026. Die alte Fassung startete dort mit den Blobs a8bdd07a… für das Modell, 7e78b02d… für den Bildteil und 491f38af… für das Entwurfsmodell. Genau diese drei Blobs nennt heute das GGUF-Manifest der Liste, mit "file_type": "Q4_K_M" im Config-Blob. Neu ist also die Liste darüber und die zweite Variante darin.

seitlich verschiebbar

eigene Darstellung nach der Registry und der Ablage am Gerät, Stand 09.11.2026

Gemma 4 liegt in zwei Verpackungen vor

GGUF bündelt Kopf und Gewichte in einer Datei

GGUF ist das Dateiformat von llama.cpp, einem Programm, um Sprachmodelle auf eigenen Rechnern auszuführen. Laut Spezifikation (externe Seite, github.com) ist es für Programme gedacht, die auf der Rechenbibliothek GGML aufbauen. Eine einzige Datei soll alles enthalten, was zum Laden eines Modells nötig ist. Sie ist so aufgebaut:

1. die vier Zeichen GGUF, eine Versionsnummer und die Zahl der Tensoren,
2. Metadaten als Paare aus Schlüssel und Wert, etwa Bauform, Vokabular, Gesprächsvorlage und Zahl der Schichten,
3. je Tensor ein Eintrag mit Name, Form, Datentyp und Lage in der Datei,
4. die Zahlen selbst, auf feste Grenzen ausgerichtet.

Die Ausrichtung erlaubt es, die Datei direkt in den Speicher abzubilden, statt sie zu kopieren.

Die Modelldatei der 26B-Variante lässt sich mit wenigen Zeilen Python nach der Spezifikation auslesen. Sie hat 658 Tensoren und 56 Metadaten, darunter general.architecture = gemma4, 30 Schichten, 128 Experten, von denen 8 je Token rechnen, und general.file_type = 15. Die Zahl 15 steht für Q4_K_M. Neben den 8 gewählten Experten nennt Googles Modellkarte (externe Seite, ai.google.dev) einen geteilten Experten.

Ollamas safetensors legt jeden Tensor in einen eigenen Blob

safetensors ist das Format, in dem Hersteller wie Google ihre Gewichte bei Hugging Face veröffentlichen. Die Beschreibung (externe Seite, github.com) ist kurz: 8 Byte nennen die Länge eines Kopfes, dann folgt der Kopf als JSON, dann folgen die rohen Zahlen. Der Kopf sagt je Tensor, welchen Datentyp er hat, welche Form und an welcher Stelle seine Bytes stehen. Das Format kann keinen ausführbaren Code enthalten. Genau dafür wurde es entworfen.

Ein Hersteller verteilt seine Gewichte auf wenige große safetensors-Dateien. Ollama zerlegt sie für die MLX-Variante so, dass jeder Tensor ein eigener Blob ist. Einer der 1236 Blobs des 31B ist 65.028.524 Byte groß, sein Kopf 416 Byte:

$ head -c 8 sha256-… | xxd
00000000: a001 0000 0000 0000                      ........

{
  "__metadata__": { "quant_type": "nvfp4" },
  "model.language_model.layers.0.mlp.down_proj.weight": {
    "dtype": "U32", "shape": [5376, 2688], "data_offsets": [0, 57802752]
  },
  "model.language_model.layers.0.mlp.down_proj.weight.global_scale": {
    "dtype": "F32", "shape": [], "data_offsets": [65028096, 65028100]
  },
  "model.language_model.layers.0.mlp.down_proj.weight.scale": {
    "dtype": "U8", "shape": [5376, 1344], "data_offsets": [57802752, 65028096]
  }
}

Die ersten acht Byte ergeben, von hinten gelesen, die Zahl 0x1a0, also 416. Danach steht ein Tensor in drei Teilen:

• Die Gewichte liegen als U32 vor, als ganze Zahlen mit 32 Bit. Jede davon enthält acht Werte zu je 4 Bit, 2688 mal 8 ergibt 21.504 Werte je Zeile.
• Die Blockskalen (.scale) haben 8 Bit, eine je 16 Werte. 21.504 durch 16 ergibt 1344.
• Die Tensorskala (.global_scale) hat 32 Bit und gilt für den ganzen Tensor.

Das Feld quant_type nennt das Verfahren dahinter: NVFP4. Wie die drei Teile zusammenwirken, erklärt der nächste Abschnitt.

seitlich verschiebbar

eigene Darstellung nach der GGUF-Spezifikation, der safetensors-Beschreibung und einem Blob von gemma4:31b, Stand 09.11.2026

Beide nebeneinander

Für Ollama hat die feine Zerlegung einen praktischen Vorteil. Ändert sich ein einzelner Tensor, muss nur dieser Blob neu heruntergeladen werden, und gleiche Tensoren zweier Modelle liegen nur einmal vor. Welche Engine welches Format liest, ordnet Nutzung und Anpassung von LLMs, Kapitel 05 über mehrere Programme hinweg ein.

Vier Bit je Gewicht reichen, wenn jeder Block eine eigene Skala hat

Die Gewichte von Gemma 4 veröffentlicht Google in BF16, also mit 16 Bit je Zahl. Das 31B mit 30,7 Milliarden Parametern wöge so rund 61 Gigabyte und ließe vom Arbeitsspeicher des Messgeräts mit 64 GB wenig übrig. Beide Varianten bei Ollama sind deshalb quantisiert: Jede Zahl wird gröber gespeichert, im Mittel mit etwas über 4 Bit. Das spart Platz und beim Antworten auch Zeit, wie der Abschnitt über das Tempo zeigt. Es kostet Genauigkeit, und die Kunst besteht darin, möglichst wenig davon zu verlieren.

Runden auf ein grobes Raster

Die einfachste Form geht in drei Schritten. Man sucht in einer Reihe von Zahlen den betragsgrößten Wert. Man teilt alle Zahlen durch eine Skala, sodass der größte Wert auf den Rand des Rasters fällt. Und man rundet jede Zahl auf die nächste Rasterstufe. Gespeichert werden die Stufen und die Skala. Beim Rechnen wird jede Stufe wieder mit der Skala malgenommen.

Ein Beispiel mit vier Zahlen und einem Raster aus ganzen Zahlen von −7 bis 7: Die Werte seien 0,021, −0,014, 0,003 und 0,035. Der größte Betrag ist 0,035, die Skala also 0,035 durch 7 gleich 0,005. Geteilt und gerundet ergeben sich 4, −3, 1 und 7. Zurückgerechnet sind das 0,020, −0,015, 0,005 und 0,035. Der größte Fehler liegt bei 0,002 und entsteht beim kleinen Wert 0,003: Er macht zwei Drittel dieses Werts aus. Beim größten Wert ist der Fehler null, bei den beiden anderen 0,001.

Das Problem steckt im größten Wert. Ein einzelner Ausreißer zieht die Skala hoch, und alle kleinen Zahlen landen auf wenigen Stufen nahe null. Deshalb bekommen kleine Blöcke von 16 bis 256 Zahlen je eine eigene Skala. Die Verfahren unterscheiden sich darin, wie groß ein Block ist, wie die Skala gespeichert wird und welches Raster die Werte haben.

Q4_0 teilt die Gewichte in Blöcke zu 32

Q4_0 gehört zu den Verfahren, die llama.cpp schon vor den k-quants von 2023 hatte, wie der Pull Request der k-quants (externe Seite, github.com) sie nennt. Im Quelltext von GGML (externe Seite, github.com) hat ein Block 32 Gewichte. Er speichert eine Skala in 16 Bit und 16 Byte für die Werte, je zwei Werte zu 4 Bit in einem Byte. Das sind 18 Byte für 32 Gewichte, also 4,5 Bit je Gewicht. Beim Zurückrechnen zieht GGML von jedem 4-Bit-Wert 8 ab und multipliziert mit der Skala, so steht es in der Funktion zum Zurückrechnen (externe Seite, raw.githubusercontent.com). Die Werte sind also ganze Zahlen von −8 bis 7, das Raster ist gleichmäßig.

Die k-quants fassen 256 Werte zu einem Superblock

2023 führte llama.cpp die sogenannten k-quants (externe Seite, github.com) ein. Sie fassen 256 Gewichte zu einem Superblock zusammen. Bei Q4_K besteht er aus acht Blöcken zu 32, und jeder Block hat eine eigene Skala und einen eigenen Mindestwert. Die Skalen selbst werden noch einmal mit 6 Bit quantisiert, relativ zu einer Skala des Superblocks. So kommt Q4_K auf 4,5 Bit je Gewicht, Q6_K mit Blöcken zu 16 auf 6,5625.

Q4_K_M bezeichnet eine Mischung dieser Typen. Der Name steht für das Rezept, nach dem llama.cpp die Tensoren eines Modells auf Typen verteilt. Laut Quelltext (externe Seite, github.com) bekommen zwei Arten von Tensoren in etwa der Hälfte der Schichten Q6_K: die Werte der Aufmerksamkeit und die Abwärtsprojektion. Die Ausgabematrix bekommt ebenfalls Q6_K, der Rest Q4_K. Wer den Datentyp jedes Tensors ausliest, sieht, wie verschieden dieses Rezept ausfallen kann:

Quelle: eigene Auslesung der GGUF-Köpfe nach der Spezifikation, 09.11.2026.

Beim 31B ist das das bekannte Bild. Beim 26B liegt unter derselben Bezeichnung weniger als die Hälfte der Bytes in Q4_K, der Rest in 5 bis 8 Bit. Der Grund liegt in der Bauform als Mixture of Experts. Bei 128 Experten machen sie fast alle Gewichte aus. Alles außerhalb der Experten ist klein und rechnet bei jedem Token mit, also kostet es wenig Platz, diesen Teil in 8 Bit zu speichern. Am Namen Q4_K_M lässt sich das nicht ablesen, das zeigt erst der Blick in die Datei.

Microscaling gibt jedem Block eine Zweierpotenz

Ein zweiter Weg kommt aus der Hardware-Industrie. Die Microscaling-Spezifikation (externe Seite, opencompute.org) der Open Compute Project Foundation von 2023 legt Formate fest, die Grafikchips direkt rechnen können. Mitgeschrieben haben unter anderem AMD, Arm, Intel, Microsoft, NVIDIA und Qualcomm. Für die Werte nehmen die Formate kleine Gleitkommazahlen:

• MXFP4 mit E2M1, also den Werten von 0 bis 6 aus dem Kasten oben,
• MXFP8 mit E4M3 oder E5M2.

Je 32 Werte teilen sich eine Skala im Format E8M0. Das ist ein reiner Exponent ohne Mantisse, die Skala ist also immer eine Zweierpotenz. MXFP4 kommt damit auf 4,25 Bit je Wert, MXFP8 auf 8,25.

Gleitkommawerte haben ein ungleichmäßiges Raster: dicht bei null, grob am Rand. Das passt zu Gewichten, denn die meisten liegen nahe null und nur wenige weit draußen.

seitlich verschiebbar

eigene Darstellung nach dem GGML-Quelltext, der OCP-Microscaling-Spezifikation v1.0 und NVIDIAs Beschreibung von NVFP4

NVFP4 halbiert den Block und verfeinert die Skala

NVFP4 ist NVIDIAs Weiterentwicklung, eingeführt 2025 mit der Chipgeneration Blackwell. Laut NVIDIA (externe Seite, developer.nvidia.com) nutzt sie dieselben Werte E2M1 wie MXFP4, mit drei Unterschieden:

1. Ein Block umfasst 16 Werte statt 32. Ein Ausreißer verdirbt also nur halb so viele Nachbarn.
2. Die Skala jedes Blocks ist eine Zahl in E4M3 statt einer Zweierpotenz. Sie kann also auch 1,25 oder 0,875 sein und passt sich enger an den Block an.
3. Weil E4M3 nur einen kleinen Wertebereich hat, kommt eine zweite Skala in 32 Bit für den ganzen Tensor dazu.

Das ergibt 4 Bit je Wert plus 8 Bit Skala je 16 Werte, also 4,5 Bit je Wert. Genau diese drei Teile stehen im Blob von oben: die Werte als U32, die Blockskalen als U8 und die Tensorskala als F32.

NVIDIAs Chips der Blackwell-Reihe rechnen NVFP4 in eigenen Rechenwerken. Auf Apples Grafikchips gehen die Rechenkerne von MLX (externe Seite, github.com) einen Umweg. Sie wandeln jeden 4-Bit-Wert per Bitverschiebung in eine Zahl mit 16 Bit um und multiplizieren erst dann. MLX kann in NVFP4 quantisieren und zurückrechnen seit Fassung 0.30.0, so steht es in den Release Notes (externe Seite, github.com). Die Doku (externe Seite, ml-explore.github.io) in Fassung 0.32.4 führt NVFP4 heute neben MXFP4, MXFP8 und dem älteren Verfahren mit ganzen Zahlen (affine). Für das Tempo zählt trotzdem vor allem, dass weniger Bytes aus dem Speicher gelesen werden.

Einen echten Block selbst quantisieren

Das folgende Modul nimmt zwei Blöcke zu je 32 echten Gewichten aus Gemma 4 31B. Es zeigt, was jedes der drei Verfahren daraus macht: welche Codes gespeichert werden, welche Werte beim Rechnen zurückkommen und wie groß der Fehler ist. Der zweite Block enthält einen Ausreißer. An ihm wird sichtbar, warum NVFP4 kleinere Blöcke nimmt.

Im gewöhnlichen Block liegt der mittlere Fehler bei NVFP4 bei 0,00115. Q4_0 kommt auf 0,00211, MXFP4 auf 0,00239. Im Block mit dem Ausreißer wachsen alle drei, NVFP4 bleibt mit 0,00169 am kleinsten. Dafür sorgen die beiden Skalen dieses Blocks: Die Hälfte mit dem Ausreißer bekommt eine grobe, die andere eine feine.

Die Codes für NVFP4 stammen aus Ollamas Datei auf dem Messgerät. Rechnet man denselben Block nach NVIDIAs Vorschrift selbst, kommen bitgenau dieselben Codes und Skalen heraus. Die Werte für Q4_0 und MXFP4 sind nach den Vorschriften von GGML und der Microscaling-Spezifikation nachgerechnet.

Was in Gemma 4 steckt

Die MLX-Varianten sind nicht einheitlich quantisiert. Der Kopf jedes Blobs nennt das Verfahren, und ausgezählt ergibt sich:

Quelle: eigene Auszählung der Blob-Köpfe, 09.11.2026.

Beim 26B folgt die MLX-Variante damit derselben Idee wie Q4_K_M. Einige Tensoren bekommen mehr Bit, die Masse der Experten bekommt 4 Bit. Die Datei hf_quant_config.json im Paket nennt als Werkzeug NVIDIAs Model Optimizer in einer Vorabfassung 0.47 und als Verfahren MIXED_PRECISION. Wer genau die Datei erzeugt hat, sagt das Paket nicht. Die NVFP4-Fassungen, die NVIDIA selbst bei Hugging Face anbietet, nennen andere Werkzeugfassungen und andere Einstellungen.

Die MLX-Variante antwortet schneller, der Wächter hat vor allem das Laden gemessen

Weniger Bytes je Token heißt also schnellere Antworten. Das MacBook Pro mit M4 Max hat laut Apple (externe Seite, support.apple.com) eine Spei­cher­band­breite von 546 GB/s. Beim dichten 31B liest jedes Token das ganze Sprachmodell, ohne Bildteil und Entwurfsmodell. In der MLX-Variante sind das 17,27 GB, in der GGUF-Variante 18,67 GB. Daraus folgen als Obergrenze 31,6 und 29,2 Token je Sekunde. Die Bytes allein erklären also höchstens einen Unterschied von acht Prozent.

Die Messung

Gemessen habe ich beide Varianten beider Modelle im selben Ollama, im Wechsel. Es gab drei Aufgaben: eine Erklärung, ein Stück Programmcode, einen kurzen Brief. Jede Antwort hatte bis zu 400 Token, bei Temperatur 0 und ohne Denkspur. Das Feld runner der Pro­gramm­schnitt­stelle (externe Seite, raw.githubusercontent.com) wählt die Variante. Ollama gibt für jeden Aufruf getrennt an, wie lange das Laden, das Einlesen und das Antworten gedauert haben. Neben der Messung liefen andere Programme. Die Systemlast (Load Average) lag bei diesem Vergleich zwischen 4,4 und 10,3.

Mediane aus 12 Läufen beim Antworten und 4 beim Einlesen. Eigene Messung, 09.11.2026, Ollama 0.40.15.

Aus den Medianen ohne Rundung folgt: Die MLX-Variante antwortet beim 26B um 28 Prozent schneller (115,8 gegen 90,6), beim 31B um 21 Prozent (30,6 gegen 25,3). Beim Einlesen liegt sie mit 9 und 4 Prozent nur knapp vorn. Zwischen den Läufen lagen Höchst- und Tiefstwert bis zu 57 Prozent des Medians auseinander (31B in MLX). Für sich genommen ist deshalb jeder einzelne Lauf wenig wert.

Das Entwurfsmodell hilft, beim 26B vor allem der GGUF-Variante

Beide Varianten bringen ein kleines Entwurfsmodell mit, bei Google „Gemma 4 MTP“ genannt. Google hat diese Entwurfsmodelle am 16.04.2026 veröffentlicht (externe Seite, ai.google.dev), gut zwei Wochen nach den Modellen selbst. Es nutzt ein Verfahren namens Speculative Decoding: Das kleine Modell schlägt mehrere Token vor, und das große prüft sie in einem einzigen Lesedurchgang. Stimmen die Vorschläge, liefert ein Lesen mehrere Token. Am Ergebnis ändert das nichts, weil das große Modell jeden Vorschlag bestätigt oder verwirft. Ollama schaltet das Verfahren seit Fassung 0.31.1 auf dem Mac selbst ein. Wie viele Token es vorschlagen lässt, stellt es nach den Release Notes (externe Seite, github.com) ebenfalls selbst ein.

Abschalten lässt es sich für eine Messung auf zwei Wegen. In der MLX-Variante fällt es weg, sobald die Anfrage Wahr­schein­lich­keiten je Token anfordert, so steht es im Quelltext (externe Seite, raw.githubusercontent.com). In der GGUF-Variante setzt der Parameter draft_num_predict auf 0 die Zahl der Vorschläge auf null. Damit lassen sich Engine und Entwurfsmodell getrennt messen:

Mediane aus 6 Läufen je Zelle, eigene Messung, 09.11.2026. Die Läufe des 31B liefen unter deutlich höherer Systemlast als alle anderen, zwischen 15,5 und 42,5. Ihre Werte sind deshalb unsicherer als die des 26B.

Aus der Tabelle folgt:

• Beim 31B, dem dichten Modell, steigert das Entwurfsmodell das Tempo in beiden Varianten um mehr als die Hälfte. Der Faktor beträgt 1,7 bei MLX und 1,9 bei GGUF. Mit ihm liegt die MLX-Variante bei 31,1 Token je Sekunde und damit knapp unter der Obergrenze von 31,6, die ohne Entwurf gilt. Ohne Entwurf erreicht MLX 59 Prozent davon (18,7 von 31,6), die GGUF-Variante 44 Prozent (12,8 von 29,2).
• Beim 26B, dem Modell aus Experten, bringt das Entwurfsmodell der MLX-Variante fast nichts. Google erklärt das in der Doku zu MTP (externe Seite, ai.google.dev). Beim 26B A4B kann jedes Token andere Experten wählen, also holt das Prüfen der Vorschläge zusätzliche Gewichte aus dem Speicher. Bei einer Anfrage zur Zeit bringe der Entwurf auf Geräten ohne gute Parallelität womöglich keinen Gewinn. Die Messung zeigt genau das für MLX.
• Ohne Entwurfsmodell rechnet MLX das 26B 2,4-mal so schnell wie llama.cpp. Je Token liest die MLX-Variante grob 2,7 GB. Die GGUF-Variante liest wegen ihrer 8-Bit-Anteile grob 3,4 GB. Das erklärt einen Faktor von 1,3, den Rest liefert die Engine selbst. MLX nutzt hier knapp die Hälfte der Bandbreite, llama.cpp in Ollama ein Viertel. Beide Anteile sind eine grobe Rechnung aus Dateigrößen und Expertenzahl.

Am 30.05.2026 fand eine Messung auf demselben Gerät das Gegenteil. Ein Modell lief dort über MLX langsamer als über llama.cpp, nachzulesen in Elf Wege, ein lokales Modell schneller zu machen. Gemessen war damals ein anderes Modell mit anderen Programmen. Ollama hat seine Anbindung an MLX seither in vielen Fassungen überarbeitet. Ein Vergleich zweier Engines gilt deshalb für Fassung, Modell und Gerät, an denen er gemessen ist.

seitlich verschiebbar

eigene Darstellung; Bandbreite laut Apple, Bytes je Token und Tempo aus eigener Messung am 09.11.2026

Das Laden erklärt die Zeiten des Wächters

Die Funktionsprobe des Wächters misst etwas anderes als Token je Sekunde. Sie schickt eine Aufgabe über eine Zwischenschicht an Ollama und stoppt die Zeit bis zur fertigen Antwort, einmal je Modell. In dieser Zeit steckt auch das Laden, falls das Modell gerade nicht im Speicher liegt. Und das Laden unterscheidet die Varianten am deutlichsten:

Eigene Messung, je 4 Läufe, 09.11.2026. Die Zeiten hängen davon ab, ob das Betriebssystem die Dateien noch im Speicher hält.

Beim 31B dauert das Laden der GGUF-Variante 2 bis 7 Sekunden länger als das der MLX-Variante. Rechnet man den ersten Aufruf dazu, bei dem die GGUF-Variante weitere 12,0 bis 13,5 Sekunden braucht, sind es 13,9 bis 20,5 Sekunden. Der Wächter maß 24,1 gegen 10,6 Sekunden, ein Unterschied von 13,5. Das liegt knapp unter dieser Spanne und passt zur Annahme, dass er beide Male ein ungeladenes Modell traf. Protokolliert ist das nicht.

Woran die Zahlen hängen

Die Ergebnisse waren in beiden Varianten inhaltlich gleichwertig, bei der Funktionsprobe des Wächters wie in den eigenen Läufen. Das spricht für einen schnelleren Ausführungsweg bei gleichem Modell. Wortgleich sind die Antworten trotzdem selten: Die Gewichte sind verschieden gerundet, und die Zahl der Antworttoken wich je Aufgabe um einige Prozent ab. Ob die eine Variante besser antwortet als die andere, hat diese Messung nicht untersucht. Sie lief an einem Tag, auf einem Gerät, mit wenigen Läufen je Zelle und neben anderer Last. Wer die Zahlen übernehmen will, misst auf dem eigenen Gerät nach.

So sehen Sie selbst nach

Alles, was dieser Beitrag beschreibt, lässt sich auf dem eigenen Rechner mit Bordmitteln prüfen. Den Steckbrief eines Modells zeigt Ollama selbst:

$ ollama show gemma4:26b
  Model
    architecture         gemma4
    parameters           26.2B
    quantization         nvfp4
    requires             0.34.1
    renderer             gemma4-large
    parser               gemma4
    runner               mlx
    available runners    mlx:sha256:48eb98ec778c,
                           llamacpp:sha256:001e5dafc3c7

Die Ausgabe ist gekürzt. Die Zeile available runners nennt beide Varianten mit dem Anfang ihres Digests. Das Manifest und seine Teile lassen sich direkt lesen:

# which list does the name point to?
readlink ~/.ollama/models/manifests-v2/ollama.com/library/gemma4/26b

# how many parts, of which kind?
cd ~/.ollama/models/blobs
jq -r '.layers[].mediaType' sha256-48eb98ec… | sort | uniq -c

# does the file match its name?
shasum -a 256 sha256-ed3c4359…

Die andere Variante holt ein versteckter Schalter dazu, der in der Hilfe nicht erscheint und im Quelltext (externe Seite, raw.githubusercontent.com) steht: ollama pull gemma4:26b --runner llamacpp. Danach liegen beide Varianten nebeneinander, und der Name zeigt auf einem Mac weiter auf MLX. Das kostet hier 18,7 GB zusätzlich.

So hat es auch der Wächter gemacht, der diesen Beitrag ausgelöst hat. Er kopiert jedes Modell vor dem Neuladen und löscht die Kopie nach einer Woche, wenn das neue sich bewährt hat. Was sich zwischen beiden Fassungen geändert hat, hält er seit diesem Fall vor dem Löschen fest: Format, Quantisierung, Runner und Größe.