2026 Ollama 0.34.0 mit DeepSeek-R1: Was tun, wenn der Speicher nach Abschluss der Aufgabe nicht freigegeben wird?

Die Aufgabe ist beendet, die Modellliste ist leer, aber der Arbeitsspeicher des Mac bleibt auffällig belegt.

Schnellste Maßnahme: Erweitern Sie zunächst weder Speichergrenzen noch Kernelparameter. Prüfen Sie die Runner-Prozess-ID, den Speicherdruck und die Aktivität des Auslagerungsspeichers; verwenden Sie keep_alive=0 oder ollama stop nur an einer sicheren Auftragsgrenze als vorläufige Rückholung. Das ist keine Reparatur eines Lecks. Wenn der Speicher im Runner weiter mit jeder Anfrage wächst, wechseln Sie bei dauerhaftem Agent-Betrieb zu Prozessisolierung oder einem unabhängigen Mac-Knoten.

Zu dieser Analyse gehören:
Batch-Entwickler, die die Modellfreigabe in den Lebenszyklus eines Auftrags einbauen müssen.
KI-Agenten-Teams, die Sitzungen, Tool-Aufrufe und parallele Anfragen nicht durch eine unkontrollierte Entladung gefährden dürfen.
Technische Verantwortliche, die Kaltstartkosten, Ausfallrisiko und zusätzliche Mac-Rechenkapazität gegeneinander abwägen.

Zuletzt aktualisiert am 15.09.2026; Versions- und API-Angaben wurden anhand der offiziellen Ollama-Dokumentation, des Release-Status sowie der verlinkten Apple- und GitHub-Quellen geprüft.

Die erste Einordnung verhindert eine falsche Reparatur

Ollama 0.34.0 mit DeepSeek-R1 und „Speicher nicht freigegeben“ beschreibt noch keinen nachgewiesenen Speicherfehler. Nach Abschluss einer Anfrage kann Ollama das Modell absichtlich im Speicher halten, damit die nächste Anfrage keinen erneuten Ladevorgang auslöst. Die API-Dokumentation definiert keep_alive=0 als unmittelbare Entladung des Modells; daraus folgt aber nicht, dass ein bereits gewachsener Runner-Prozess oder ein beschädigter Metal-Zustand vollständig repariert wird. Die Semantik ist in der offiziellen Ollama-API-Dokumentation beschrieben.

Für die Diagnose müssen vier Dinge getrennt betrachtet werden:

• Modellgewichte: der Speicherbedarf der geladenen Modellstruktur;
• KV-Cache: anfragebezogener Zustand, der mit Kontext und parallelen Sequenzen wachsen kann;
• Datei-Mappings: vom Betriebssystem gemappte Dateien, deren Anzeige nicht automatisch einem dauerhaft belegten Heap entspricht;
• Runner-Heap: Speicher, der im Prozess verbleiben kann, obwohl eine Anfrage beendet wurde.

Auf einem Apple-Silicon-Mac teilen sich CPU und GPU den Unified Memory. Metal kann deshalb Arbeitsdaten im gemeinsamen Speicher verwalten, anstatt einen vollständig getrennten Grafikspeicher zu verwenden. Apple beschreibt diese Eigenschaft in der Dokumentation zu Unified Memory bei Metal-Geräten. Eine hohe Aktivitätsanzeige ist daher allein kein Beweis für ein Leck.

Entscheidend ist die zeitliche Beziehung: Bleibt der Speicher nach einer einzelnen Aufgabe stabil, handelt es sich eher um Vorhaltung oder Betriebssystem-Caching. Steigt der Runner-Heap mit jeder Anfrage weiter, obwohl Modell, Kontext und Parallelität vergleichbar bleiben, liegt ein anderer Verdacht nahe. Physischer Speichermangel und kumulierendes Prozesswachstum verlangen dann unterschiedliche Maßnahmen.

Was nach dem Auftrag tatsächlich im Speicher bleibt

Die Frage „Warum belegt Ollama nach einer abgeschlossenen Anfrage weiterhin viel Mac-Speicher?“ lässt sich nur mit mehreren Messpunkten beantworten. Die Modellliste zeigt, ob Ollama ein Modell weiterhin als laufend betrachtet. Sie zeigt jedoch nicht automatisch, ob der gesamte vom Dienst oder vom Runner belegte Speicher an macOS zurückgegeben wurde.

Für eine erste Bestandsaufnahme sollte die zuständige Person unmittelbar vor dem Auftrag, nach dem Auftrag und nach einer Wartephase dieselben Werte notieren:

ollama ps
ps aux | grep -i '[o]llama'
vm_stat

ollama ps beantwortet die Modellfrage. ps liefert Hinweise auf Dienst- und Runner-Prozesse sowie deren Prozesskennung. vm_stat zeigt Speicherseiten und hilft, Veränderungen im Systemzustand über mehrere Messungen zu vergleichen. Für den operativen Zustand ist zusätzlich die Speicheranzeige in der Aktivitätsanzeige relevant: Apple erklärt den Unterschied zwischen freiem Speicher, belegtem Speicher, Cache und Speicherdruck in der Dokumentation zur Aktivitätsanzeige.

Ein einzelner Wert direkt nach dem Ende der Anfrage ist keine belastbare Aussage. Erst die Kombination aus gleicher Runner-Prozess-ID, sinkendem oder steigendem Speicherdruck, Auslagerungsaktivität und Dienstprotokoll ergibt ein brauchbares Bild. Datei-Mappings können sichtbar bleiben, obwohl sie vom System später wiederverwendet oder ausgelagert werden. Umgekehrt kann der Runner-Prozess neu gestartet worden sein, während die Modellliste bereits wieder leer ist.

Für die Protokollierung ist die Startart wichtig:

• Bei der Ollama-App müssen die macOS-Protokolle und der aktuell laufende Dienst geprüft werden; ein zusätzlich gestarteter manueller Dienst kann die Beobachtung verfälschen.
• Bei einem manuell gestarteten Dienst muss klar sein, welches Terminal, welche Umgebungsvariablen und welche Prozesskennung zu diesem Start gehören.
• Bei einem API-Dienst sollte die Anwendung Anfragestart, Anfragenende, Modellname, keep_alive-Wert und Runner-Prozesskennung gemeinsam protokollieren.

Die offizielle Ollama-Anleitung zur macOS-Fehlersuche und Protokollauswertung ist dafür die maßgebliche Referenz. Ohne diese Zuordnung besteht die Gefahr, den Speicher des falschen Prozesses zu beobachten.

Kontextkürzung ist nicht für jede Wachstumsursache wirksam

Wenn eine Verkürzung des Kontextfensters keine nachhaltige Entlastung bringt, sollte die Untersuchung nicht bei KV-Cache-Größen stehen bleiben. Drei Variablen sind getrennt zu verändern:

1. Anzahl der Anfragen;
2. Kontextlänge je Anfrage;
3. gleichzeitige Anfragen oder Agentenläufe.

Bleibt die Speichernutzung bei langen Einzelanfragen hoch, aber stabil, spricht das eher für den erwartbaren Arbeitszustand. Steigt sie bei vielen kurzen Anfragen, obwohl der Kontext klein bleibt, rückt der Prozess-Heap in den Vordergrund. Steigt sie nur bei Parallelität, sind Warteschlange, Sequenzverwaltung oder doppelte Modellinstanzen wahrscheinlicher als ein reines Kontextproblem.

Ein öffentliches Community-Beispiel beschreibt auf macOS ein Wachstum des Metal-Runner-Prozesses, während die API-Anzeige des Modellverbrauchs vergleichsweise stabil blieb. Der betreffende offene Ollama-Issue bezieht sich jedoch auf Ollama 0.32.15 und ein anderes Modell. Er ist deshalb ein Suchhinweis, keine offizielle Bestätigung eines DeepSeek-R1- oder Ollama-0.34.0-Fehlers.

Kann keep_alive=0 ein Ollama-Speicherleck beheben?

Nein. Der Parameter kann die beabsichtigte Modellvorhaltung beenden und damit einen sauberen Vergleich ermöglichen. Er repariert aber weder einen wachsenden Heap noch einen Runner, der nach einer Metal-Fehlerbedingung nicht korrekt beendet wird. Für eine belastbare Aussage muss derselbe DeepSeek-R1-Auftragsablauf mindestens einmal mit normaler Vorhaltung und einmal mit expliziter Entladung ausgeführt werden. Nur die eigene Reproduktion zeigt, ob der konkrete Fehler mit dem Modellaufenthalt, der Anfragefolge oder dem Prozesszustand zusammenhängt.

Der sichere Vergleich zwischen API-Entladung und Modellstopp

Die API-Entladung ist für Anwendungen geeignet, die den Modelllebenszyklus selbst kontrollieren. Eine Anfrage kann beispielsweise mit einem expliziten Wert für keep_alive beendet werden:

curl http://localhost:11434/api/generate \
  -d '{
    "model": "deepseek-r1",
    "prompt": "Kurzer Prüfauftrag",
    "keep_alive": 0
  }'

Der Rückgabestatus muss zusammen mit ollama ps geprüft werden. Verschwindet das Modell aus der laufenden Modellliste, wurde die Modellvorhaltung beendet. Das beweist jedoch noch nicht, dass der Runner-Prozess beendet und der von macOS verwaltete Speicher vollständig zurückgegeben wurde. Die API-Semantik für das Entladen ist zusätzlich in der Dokumentation zum keep_alive-Verhalten festgelegt.

Für einen kontrollierten Batch-Stopp kann die Kommandozeile verwendet werden:

ollama stop deepseek-r1

Der Unterschied ist operativ relevant: Die API kann in einen bestehenden Auftragsablauf eingebaut werden, während ollama stop ein ausdrücklicher Eingriff von außen ist. In einem gemeinsam genutzten Dienst darf ein einzelner Batch-Prozess nicht eigenmächtig stoppen, was ein anderer Agent gerade benötigt.

Wie lässt sich nach dem Entladen feststellen, ob der Speicher wirklich zurückgegeben wurde?

Nicht durch die Modellliste allein. Wir empfehlen diese Reihenfolge:

1. Vor dem Entladen Modellname, Runner-Prozesskennung, Prozessspeicher und Speicherdruck protokollieren.
2. Den Abschluss der letzten Anfrage bestätigen und keine neue Anfrage starten.
3. keep_alive=0 oder ollama stop ausführen.
4. Erneut ollama ps, ps aux | grep -i '[o]llama' und vm_stat erfassen.
5. Eine definierte Wartephase einhalten und die Werte erneut aufnehmen.
6. Das Modell mit exakt demselben Prüfauftrag laden.
7. Kaltstart, Prozesskennung, Speicherdruck und Ergebnisstatus mit dem Ausgangslauf vergleichen.

Bleibt die alte Runner-Prozesskennung bestehen und wächst deren Speicher weiter, ist ein vollständiger Dienstneustart als Fehlerisolierung angemessen. Vorher müssen Protokolle und Prozessdaten gesichert werden. Ein Neustart kann die aktuelle Störung beseitigen, liefert aber keinen Beweis, dass die Ursache behoben wurde.

Der Rückholzeitpunkt muss zum Auftragsmodell passen

Jede Entladung hat einen Preis: Der nächste Auftrag muss das Modell erneut laden, die erste Antwort wartet länger, und bei Modellwechseln kann zusätzliche Koordination erforderlich sein. Ohne verifizierte Messung dürfen wir dafür keinen allgemeinen Sekundenwert oder eine feste Speicherschwelle nennen. Die richtige Einheit für die Entscheidung ist der Auftragsgrenzwert.

Für einen kurzen, voneinander unabhängigen Batch ist eine Entladung nach dem gesamten Batch meist sinnvoller als nach jeder einzelnen Anfrage. Bei einer fortlaufenden Unterhaltung zerstört eine Entladung dagegen den praktischen Sitzungszustand und erzeugt wiederholte Kaltstarts. Bei einem Agenten mit Werkzeugaufrufen sollte der Rückholpunkt erst nach Abschluss des gesamten Werkzeugzyklus liegen, nicht nach einer einzelnen Modellantwort.

Die folgende Entscheidungshilfe trennt die Optionen, ohne den sichtbaren Speicherwert als alleinige Kennzahl zu verwenden:

Die Bewertungen sind eine Betriebsentscheidung, keine gemessene Performanceangabe. Sie helfen, den Rückholpunkt an Stabilität und Wiederanlaufkosten auszurichten.

Parallele Agenten brauchen eine Entladesperre

Bei mehreren Aufrufern darf ein einzelner Auftrag nicht davon ausgehen, dass er das Modell exklusiv besitzt. Ein Agent kann noch auf ein Tool-Ergebnis warten, während ein Batch-Prozess bereits keep_alive=0 sendet. Die Folge kann ein abgebrochener Aufruf, eine doppelte Kaltladung oder eine schwer reproduzierbare Sitzung sein.

Für einen sicheren Rückholablauf gelten deshalb vier Bedingungen:

• Warteschlange leeren: Neue Aufträge werden vor der Entladung angenommen, aber nicht mehr gestartet.
• Exklusive Auftragssperre: Nur ein definierter Prozess darf den Rückholvorgang auslösen.
• Gesundheitsprüfung: Nach der Entladung muss eine harmlose API-Prüfung bestätigen, dass der Dienst antwortet.
• Fehlerwiederholung: Fehlgeschlagene Aufträge werden nur nach einer klaren Ursache und mit begrenzter Wiederholung neu eingeplant.

Beim API-Dienst sollten die Prüfungen vor allem den Status laufender Anfragen, die Runner-Prozesskennung und die Antwortzeit des Dienstes erfassen. Beim zeitgesteuerten Batch ist dagegen entscheidend, ob alle Aufträge des Loses bestätigt, gespeichert oder sauber als fehlgeschlagen markiert wurden. Ein periodisches hartes Beenden des Prozesses ist keine allgemeine Produktionslösung. Es kann als kontrollierter Wiederherstellungsschritt dienen, wenn der Dienst bereits nicht mehr gesund ist und die Ausfallfolgen bekannt sind.

Die konkrete Prüfliste für den nächsten Lauf

Diese Liste ist absichtlich auf einen einzigen reproduzierbaren Lauf zugeschnitten. Sie hilft, nicht gleichzeitig Kontext, Parallelität, Version und Entladestrategie zu verändern.

• [ ] Vor dem Start die Ollama-Startart dokumentieren: App, manuell gestarteter Dienst oder API-Prozess.
• [ ] Modellname, Auftragskennung, Kontextparameter und Parallelität notieren.
• [ ] ollama ps, Runner-Prozesskennung, Prozessspeicher und macOS-Speicherdruck erfassen.
• [ ] Einen eigenen DeepSeek-R1-Prüfauftrag mit festgelegter Anfragefolge ausführen.
• [ ] Nach dem letzten Ergebnis den Auftrag als beendet markieren und die Runner-Prozesskennung erneut erfassen.
• [ ] Prüfen, ob ollama ps das Modell weiterhin als laufend ausweist.
• [ ] Erst nach geleerter Warteschlange keep_alive=0 oder ollama stop verwenden.
• [ ] Vorher und nachher Speicherdruck, Auslagerungsaktivität, Prozessstatus und Dienstprotokoll vergleichen.
• [ ] Das Modell mit demselben Prüfauftrag erneut laden und Kaltstart sowie Ergebnisstatus protokollieren.
• [ ] Bei unverändert wachsendem Runner-Heap keinen experimentellen sysctl-Wert ohne offizielle Begründung setzen.
• [ ] Bei parallelen Aufrufern die Entladung durch Sperre, Gesundheitsprüfung und Wiederholungslogik absichern.
• [ ] Erst nach mehreren reproduzierbaren Läufen zwischen lokaler Fortsetzung, Auftragsaufteilung und isoliertem Knoten entscheiden.

Der Wechsel zu einem unabhängigen Knoten braucht klare Auslöser

Wenn ein einzelner Batch nach sauberer Entladung stabil bleibt, ist ein lokaler Betrieb weiterhin vertretbar. Wenn der Speicher jedoch bei vergleichbaren Anfragefolgen wächst, der Runner nach dem Entladen nicht verschwindet oder ein Neustart regelmäßig erforderlich wird, überschreitet das Problem den Bereich gewöhnlicher Parametereinstellung.

Für die Exit-Entscheidung sind vier Kriterien aussagekräftiger als eine einzelne Speicheranzeige:

1. Werden die Aufgaben vollständig und wiederholbar abgeschlossen?
2. Wie oft muss der Dienst wiederhergestellt oder neu gestartet werden?
3. Wie stark beeinträchtigt der Kaltstart den Gesamtauftrag?
4. Kann der betroffene Knoten ersetzt werden, ohne Sitzungen oder Auftragsdaten zu verlieren?

Daraus entstehen drei realistische Wege:

• Weiter lokal arbeiten: sinnvoll bei stabilen Einzel- oder Batch-Aufträgen mit kontrollierter Entladung.
• Aufträge aufteilen: geeignet, wenn ein langer Lauf in unabhängige Batches zerlegt werden kann und der Rückholpunkt zwischen diesen Batches liegt.
• Auf einen isolierten Mac-Knoten wechseln: sinnvoll, wenn ein dauerhaft laufender Agent, mehrere Nutzer oder ein wiederkehrender Runner-Fehler die lokale Arbeitsumgebung gefährden.

Für die Kapazitätsplanung kann die Übersicht zu Mac mini M4 und M5 als Build-Knoten bei der Einordnung eines getrennten Knotens helfen. Wer eine lokale CI- oder Entwicklungsumgebung zunächst kontrolliert abnehmen möchte, findet in der Anleitung zur Mac-Abnahme für Xcode- und CI-Aufgaben einen ergänzenden Prüfpfad. Datenschutz, Zugriffskontrolle und die Aufbewahrung von Agentenprotokollen müssen dabei getrennt geprüft werden; für die Rahmenbedingungen ist die Datenschutzerklärung von JexMac maßgeblich.

Die wirtschaftliche Entscheidung liegt zwischen Kaltstart und Ausfall

Die lokale Lösung hat klare Vorteile: keine zusätzliche Übergabe sensibler Prompts, direkter Zugriff auf vorhandene Entwicklungswerkzeuge und keine Abhängigkeit von einer externen Netzwerkverbindung. Ihre Nachteile liegen in der gemeinsamen Unified-Memory-Ressource, der möglichen Beeinträchtigung des Entwicklerarbeitsplatzes und der Tatsache, dass ein problematischer Runner denselben Rechner wie andere Aufgaben belastet.

Ein isolierter Mac-Knoten verursacht dagegen Miet- oder Betriebskosten und muss hinsichtlich Zugriff, Datenlöschung, Netzwerk und Verfügbarkeit geprüft werden. Dafür lassen sich Agentenläufe vom Arbeitsplatz trennen, fehlerhafte Prozesse gezielter ersetzen und die Kosten eines wiederholten lokalen Neustarts sichtbar machen. Für temporäre Tests oder einen begrenzten Stabilitätsvergleich kann die JexMac-Mietübersicht als Ausgangspunkt dienen; sie ersetzt keine Lastprüfung mit den eigenen Anfragen.

Wenn die aktuelle lokale Lösung nur deshalb funktioniert, weil der Dienst regelmäßig hart beendet wird, entstehen vier reale Nachteile: laufende Sitzungen können abbrechen, parallele Aufträge müssen neu eingeplant werden, Kaltstarts verlängern die Verarbeitung, und die Fehlerursache bleibt im gemeinsamen Entwicklungsrechner verborgen. In diesem Fall ist ein gemieteter, isolierter Mac von JexMac oft die sauberere Zwischenlösung als weitere nicht belegte Kernelparameter oder eine pauschale Kontextkürzung. Die Entscheidung sollte trotzdem erst nach einem eigenen „Laden – Ausführen – Entladen – erneut Laden“-Vergleich fallen.

Für den nächsten Arbeitstag genügt deshalb ein begrenzter Plan: einen repräsentativen DeepSeek-R1-Auftragsbatch aufzeichnen, die Rückholung an der Batch-Grenze testen und die Wiederherstellungskosten dokumentieren. Bleibt der Runner trotz dieser Kontrolle instabil, ist nicht die nächste Speicherzahl der wichtigste Schritt, sondern die Trennung des fehlerhaften Prozesses von den übrigen Aufgaben.