Ollama 0.34.1: MLX-Import verlässt den Experimentstatus
Das Release entfernt den Experimentstatus für MLX-Safetensors, verlangt für GGUF nun llama.cpp-Werkzeuge und drückt einen kalten /api/tags-Aufruf auf 294 ms.
Kurz gesagt
Ollama 0.34.1 stuft das Anlegen von Modellen aus MLX-Safetensors als nicht mehr experimentell ein und verweist die GGUF-Erstellung auf die Werkzeuge von llama.cpp.
Auf einen Blick
- MLX-Safetensors: ollama create gilt in Version 0.34.1 nicht mehr als experimentell.
- GGUF: Konvertierung und Quantisierung von Safetensors laufen jetzt über llama.cpp-Werkzeuge.
- /api/tags: kalt von 3,1 Sekunden auf 294 Millisekunden im Test des Projekts, Modellfähigkeiten einheitlich gemeldet.
- Wiederholungsschleifen: Abbruch erst ab 100 identischen Token, gegen Fehlalarme etwa bei OCR.
- typical_p abgekündigt: bei neuen Modellen nicht mehr setzbar, bestehende GGUF-Modelle behalten die Unterstützung.
Ollama 0.34.1 stuft das Anlegen von Modellen aus MLX-Safetensors als nicht mehr experimentell ein und verweist die GGUF-Erstellung auf die Werkzeuge von llama.cpp. Das Release erschien am 14. September 2026 als Nachfolger von Version 0.34.0.
MLX ohne Sternchen
Wer auf Apple Silicon arbeitet, konnte Safetensors-Gewichte im MLX-Format bereits über ollama create einlesen — bislang mit dem ausdrücklichen Vermerk, die Funktion sei experimentell. Dieser Vorbehalt entfällt. Zusätzlich nennen die Release-Notes eine verbesserte Speicherverwaltung für MLX auf Apple Silicon.
GGUF wandert zu llama.cpp
In die Gegenrichtung geht das verbreitetere GGUF-Format. Wer daraus neue Modelle erzeugt, muss Safetensors künftig mit den Werkzeugen von llama.cpp konvertieren und quantisieren; Ollama nimmt diesen Schritt nicht mehr selbst ab. Am Betrieb bereits vorhandener GGUF-Modelle ändert sich dadurch nichts.
3,1 Sekunden auf 294 Millisekunden
Der Endpunkt /api/tags gibt die lokal verfügbaren Modelle aus und ist damit der erste Aufruf, den Oberflächen und Skripte beim Start absetzen. Bei einer großen Modellbibliothek sank der kalte Aufruf im Test des Projekts von 3,1 Sekunden auf 294 Millisekunden, rund um den Faktor zehn. Die gemeldeten Modellfähigkeiten sollen jetzt zudem einheitlich ausfallen.
Abbruchlogik und ein abgekündigter Parameter
Die Erkennung endloser Token-Wiederholungen greift erst nach 100 identischen Token. Der höhere Schwellwert soll Fehlalarme senken, wie sie etwa bei OCR-Ausgaben auftreten, in denen sich Zeichenfolgen legitim wiederholen. Der Sampling-Parameter typical_p ist abgekündigt: Bei neu erstellten Modellen lässt er sich nicht mehr setzen, bestehende GGUF-Modelle unterstützen ihn weiterhin. Dazu kommen aktualisierte Stände von MLX und llama.cpp.
Was die Notes offenlassen
Die Release-Notes nennen weder die Hardware noch die Größe der Modellbibliothek, an der die 3,1 Sekunden gemessen wurden. Der Wert lässt sich deshalb nicht auf die eigene Installation übertragen. Auch für die verbesserte MLX-Speicherverwaltung fehlt jede Messgröße, und ob typical_p in einer späteren Version vollständig entfernt wird, steht dort nicht.
Häufige Fragen
Ist der Modellimport aus MLX-Safetensors jetzt stabil?
Die Release-Notes streichen die Kennzeichnung als experimentell. Eine Stabilitätszusage über diese Formulierung hinaus geben sie nicht.
Wie erstelle ich nach dem Update ein GGUF-Modell?
Safetensors zuerst mit den Werkzeugen von llama.cpp konvertieren und quantisieren, das Ergebnis dann in Ollama einbinden. Vorhandene GGUF-Modelle laufen unverändert.
Warum bricht Ollama Wiederholungen jetzt später ab?
Die Abbruchlogik verlangt 100 identische Token statt eines niedrigeren Werts, weil legitime Wiederholungen etwa in OCR-Ausgaben sonst als Endlosschleife gewertet wurden.
