Kurz gesagt: Ollama 0.32.15 entfernt einen wiederkehrenden Overhead vor der Inferenz. Der neue Cache hält aufgelöste GGUF-Modellmetadaten und Capabilities vor; laut Ollamas eigenem Benchmark sank die mittlere Time to First Token (TTFT) dabei von 994,79 auf 524,15 Millisekunden.
Der Release wurde am 19. August 2026 um 17:25 UTC veröffentlicht (19:25 Uhr CEST). Die Änderung ist klein genug, um in einem Changelog unterzugehen – aber für lokale Inferenz und API-nahe Agenten-Workloads durchaus spürbar: Sie zielt nicht auf schnellere Token-Generierung, sondern auf Arbeit, die vor jeder Anfrage unnötig wiederholt wurde.
Was sich in Ollama 0.32.15 ändert
Vor dem Patch las Ollama bei Chat- und Generate-Anfragen GGUF-Metadaten mehrfach pro Inferenzaufruf. Der zugrunde liegende Pull Request beziffert diesen Overhead auf rund 300 Millisekunden je Aufruf. Version 0.32.15 cached nun Modellmetadaten und Capabilities.
- Der Cache wird bei Änderungen am Modellmanifest automatisch invalidiert.
- Gleichzeitige Ladevorgänge werden per singleflight zusammengeführt, statt dieselbe Information mehrfach zu laden.
- Aufrufer erhalten lokale Kopien, damit gemeinsam gecachte Daten nicht mutiert werden.
- Die Logik greift bei
/api/generate,/api/chatund Embeddings.
Die Benchmark ist ein Signal, kein SLA
Ollama misst im PR mit NVIDIA aiperf, dem Modell qwen3.6:35b-a3b-mtp-q4_K_M, zehn sequenziellen Streaming-Chat-Anfragen und einem Coding-Datensatz. In genau diesem Aufbau fällt die durchschnittliche TTFT von 994,79 auf 524,15 Millisekunden – rund 47 Prozent.
Das ist keine universelle Latenzzusage. Hardware, Modellformat, Warm-/Cold-Start-Zustand, Parallelität und Request-Mix verändern die Wirkung. Auffällig ist aber, was sich nicht verändert: Die Inter-Token-Latenz liegt in den beiden Messungen nahezu gleich. Der Gewinn entsteht am Eintritt in den Request-Pfad, nicht beim Decoding.
Warum das für Teams zählt
Bei interaktiven lokalen Assistenten ist die Zeit bis zum ersten sichtbaren Token oft wichtiger als ein kleiner Durchsatzgewinn: Sie bestimmt, ob eine Antwort unmittelbar beginnt oder wie ein blockierter Service wirkt. Für Embedding-Pipelines und Tool-gestützte Agenten kann derselbe Fix zudem wiederholte Verwaltungsarbeit aus vielen kurzen Aufrufen nehmen.
Die praktische These: Erst den unnötigen Request-Overhead entfernen, dann über Modell- oder GPU-Tuning sprechen. Sonst optimiert ein Team womöglich den Decoder, während die Verzögerung davor entsteht.
Upgrade-Check
- TTFT getrennt messen: Vor und nach dem Upgrade mit identischem Modell, Prompt-Mix und Warm-up messen.
- Kurze Requests einbeziehen: Chat-Starts, Retrieval-Schritte und Embeddings profitieren typischerweise stärker sichtbar als lange Generierungen.
- Manifest-Wechsel testen: Prüfen, ob Modell-Updates und Tags in der eigenen Deployment-Automation wie erwartet eine Cache-Invalidierung auslösen.
- Keine Pauschalwerte übernehmen: Ollamas 524 ms sind ein einzelner, dokumentierter Messpunkt – kein Betriebsziel für jede Instanz.
Einordnung: Ollama 0.32.15 ist kein neues Modell und keine neue API. Es ist die seltenere, wertvollere Art von Release: Eine gezielte Korrektur im Hot Path, deren Wirkung für lokale LLM-Stacks direkt messbar sein kann.
Quellen
- Ollama v0.32.15 Release Notes – Primärquelle, veröffentlicht am 19. August 2026, 17:25 UTC.
- Ollama Pull Request #17752: Add a model metadata cache to reduce Ollama’s per-request overhead – Implementierungsdetails, Benchmark-Setup und Messwerte.
Leave a Reply