33 Punkte von GN⁺ 25 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Zusammenfassung der Schritte, um Ollama und das Gemma-4-Modell auf einem Mac mini mit Apple Silicon so zu konfigurieren, dass sie automatisch starten und im Speicher verbleiben
  • Mit Homebrew, Launch Agent und Umgebungsvariablen wird das Modell auch nach einem Neustart automatisch geladen; das 8B-Modell läuft mit etwa 9,6 GB Speicher stabil
  • Ollama v0.19 oder neuer unterstützt das MLX-Backend und das NVFP4-Format, was die Inferenzleistung in Apple- und NVIDIA-Umgebungen verbessert
  • Das 26B-Modell wird wegen seines hohen Speicherverbrauchs nicht empfohlen; das 8B-Modell ist für den praktischen Einsatz besser geeignet
  • Über die lokale API sind OpenAI-kompatible Chat-Completion-Anfragen möglich, was hilfreich für den Aufbau einer dauerhaften lokalen LLM-Service-Umgebung auf dem Mac mini ist

Vorbereitung

  • Ein Mac mini auf Basis von Apple Silicon (M1–M5) wird benötigt
  • Für den Betrieb des Modells Gemma 4 (8B) werden mindestens 16 GB Unified Memory empfohlen
  • Eine macOS-Umgebung mit installiertem Homebrew wird benötigt

Schritt 1 — Ollama installieren

  • Installation der Ollama-macOS-App mit dem Homebrew-Cask

    brew install --cask ollama-app
    
  • Nach der Installation befindet sich Ollama.app unter /Applications/, die CLI unter /opt/homebrew/bin/ollama

  • Enthält automatische Updates und das MLX-Backend

Schritt 2 — Ollama starten und prüfen

  • Ollama-App starten

    open -a Ollama
    
  • Nach dem Erscheinen des Symbols in der Menüleiste warten, bis der Server initialisiert ist

  • Laufenden Status prüfen

    ollama list
    

Schritt 3 — Gemma-4-Modell herunterladen

  • Modell herunterladen

    ollama pull gemma4
    
  • Nach dem Download von etwa 9,6 GB mit ollama list prüfen

  • Das 26B-Modell belegt den Großteil von 24 GB Arbeitsspeicher und führt zu einer geringeren Systemreaktionsfähigkeit

    • Es wird empfohlen, das Standardmodell 8B (Q4_K_M-Quantisierung) zu verwenden

Schritt 4 — Modell testen und GPU-Beschleunigung prüfen

  • Modell testen

    ollama run gemma4:latest "Hello, what model are you?"
    
  • Status der GPU-Beschleunigung prüfen

    ollama ps
    
    • Beispiel: CPU/GPU-Verhältnis 14 %/86 %

Schritt 5 — Autostart und Modell-Persistenz einrichten

  • 5a. Ollama-App automatisch starten

    • Auf das Symbol in der Menüleiste klicken → Launch at Login aktivieren
    • Oder manuell unter System Settings > General > Login Items hinzufügen
  • 5b. Gemma 4 automatisch vorladen

    • Nach dem Start von Ollama einen Launch Agent erstellen, der das Modell automatisch lädt und alle 5 Minuten aktiv hält

      cat << 'EOF' > ~/Library/LaunchAgents/com.ollama.preload-gemma4.plist
      ...
      EOF
      
    • Agent laden

      launchctl load ~/Library/LaunchAgents/com.ollama.preload-gemma4.plist
      
    • Sendet alle 5 Minuten einen leeren Prompt, um das Modell im Speicher zu halten

  • 5c. Modell unbegrenzt geladen halten

    • Standardmäßig wird das Modell nach 5 Minuten Inaktivität entladen

    • Unbegrenztes Beibehalten einstellen

      launchctl setenv OLLAMA_KEEP_ALIVE "-1"
      
    • Für die Beibehaltung auch nach einem Neustart zu ~/.zshrc hinzufügen

Schritt 6 — Konfiguration prüfen

  • Prüfen, ob der Ollama-Server läuft

    ollama list
    
  • Prüfen, ob das Modell in den Speicher geladen ist

    ollama ps
    
  • Prüfen, ob der Launch Agent registriert ist

    launchctl list | grep ollama
    
  • Beispiel für die erwartete Ausgabe

    gemma4:latest ... 9.6 GB 14%/86% CPU/GPU 4096 Forever
    

API-Zugriff

Nützliche Befehle

Befehl Beschreibung
ollama list Liste der heruntergeladenen Modelle
ollama ps Laufende Modelle und Speichernutzung
ollama run gemma4:latest Interaktive Ausführung
ollama stop gemma4:latest Modell entladen
ollama pull gemma4:latest Auf die neueste Version aktualisieren
ollama rm gemma4:latest Modell löschen

Ollama entfernen und Autostart deaktivieren

launchctl unload ~/Library/LaunchAgents/com.ollama.preload-gemma4.plist
rm ~/Library/LaunchAgents/com.ollama.preload-gemma4.plist
brew uninstall --cask ollama-app

Wichtige Verbesserungen in Ollama v0.19+ (31. März 2026)

  • MLX-Backend (Apple Silicon)

    • Verwendet automatisch das Apple-MLX-Framework, um die Inferenzgeschwindigkeit zu erhöhen
    • Chips der M5-Reihe unterstützen zusätzliche Beschleunigung durch den GPU Neural Accelerator
    • Auch Chips bis einschließlich M4 profitieren von allgemeinen Geschwindigkeitsverbesserungen auf MLX-Basis
  • NVFP4-Format (NVIDIA)

    • Das NVFP4-Format reduziert Speicherbandbreite und Speicherplatz bei gleichbleibender Genauigkeit
    • Kompatibel mit Modellen, die mit NVIDIA-Tools zur Modelloptimierung erzeugt wurden
  • Verbesserungen beim Caching (Coding- und Agent-Aufgaben)

    • Reduzierter Speicherverbrauch: effizienter durch Wiederverwendung des Caches zwischen Gesprächen
    • Intelligente Checkpoints: geringerer Prompt-Durchsatz und schnellere Antwortzeiten
    • Intelligente Cache-Entfernung: bessere Effizienz bei verzweigten Aufgaben durch Beibehaltung gemeinsamer Präfixe

Zusätzliche Hinweise

  • Das Modell Gemma 4 (8B) verwendet etwa 9,6 GB Speicher
    • Auf einem Mac mini mit 24 GB bleiben etwa 14 GB frei
  • Das 26B-Modell benötigt etwa 17 GB und verursacht System-Swap sowie langsamere Reaktionszeiten
    • Das 8B-Modell bietet stabile Leistung

Referenzlinks

1 Kommentare

 
GN⁺ 25 일 전
Hacker-News-Kommentare
  • Wer zum ersten Mal direkt nach Release ein Open-Weight-Modell nutzt, sollte wissen, dass es bei der frühen Implementierung und Quantisierung fast immer Bugs gibt.
    Da jedes Projekt hastig versucht, pünktlich zum Releasetag Support bereitzustellen, können die Ergebnisse fehlerhaft sein.
    Bereits jetzt wurden mehrere Probleme in der Tokenizer-Implementierung entdeckt, und auch Quantisierung mit imatrix kann problematisch sein.
    In den kommenden Wochen wird es viele Beiträge geben wie „Tool-Calling funktioniert nicht und das Modell ist unbrauchbar“. Tatsächlich nutzen diese Leute einfach eine kaputte Implementierung.
    Wer Cutting-Edge-Modelle einsetzen will, muss den Inference-Engine-Stack häufig aktualisieren und darauf vorbereitet sein, Quantisierungsvarianten bei Änderungen erneut herunterzuladen.
    Durch den Wettlauf, pünktlich zum Release fertig zu werden, läuft es oft nach dem Muster „sobald Ausgabetokens erscheinen, wird ausgeliefert“ – eine saubere Validierung der Genauigkeit kommt erst später.

    • Ich frage mich, welche Inference Engine man unter Linux mit einer 4090 nutzen sollte.
      Ich habe häufig Probleme damit, dass Tool-Calling nicht funktioniert, und weiß nicht, ob das am Modell oder an Ollama liegt.
  • Ich überlege, einen Mac mini zu kaufen und Modelle lokal laufen zu lassen.
    Ich nutze Claude hauptsächlich für Entwicklungsarbeit und Homelab-Projekte und würde gern wissen, ob Open Models inzwischen dafür brauchbar sind oder ob es besser ist, das 20-Dollar-Abo weiterlaufen zu lassen.

    • Für kleine Aufgaben geht es, aber wenn man es wie Claude nutzen will, wird man wahrscheinlich enttäuscht sein.
      Bevor du Hardware kaufst und selbst hostest, würde ich empfehlen, es zuerst über einen Hosting-Service auszuprobieren. So bekommt man ein Gefühl für die Grenzen des Modells.
    • Ich nutze Open Models seit dem Llama-Leak. Sie werden stetig besser, und es ist schon cool, lokal ohne Internet einen Wissensblock laufen lassen zu können.
      Man sollte die Erwartungen aber niedrig halten. Egal, was Benchmarks sagen – mit Sonnet oder Opus ist das nicht vergleichbar.
    • Am besten testet man es selbst, indem man einfach 10 Dollar OpenRouter-Guthaben verbraucht. Meiner Erfahrung nach fehlt noch viel, aber gelegentlich mal wieder reinzuschauen macht Spaß.
    • gpt-oss-20B hatte eine ziemlich ordentliche Agenten-Performance, ist aber mit den kostenpflichtigen Claude-Code-Modellen nicht vergleichbar. Ich habe gehört, dass 120B deutlich besser sein soll.
  • Ich habe es auf einem MacBook Pro M4 (36GB) in LM Studio mit dem Open-Code-Frontend getestet, aber Tool-Calling ist ständig fehlgeschlagen, sodass ich wieder zu Qwen zurückgegangen bin.
    Mich würde interessieren, ob jemand in einer ähnlichen Umgebung Erfolg hatte.

    • Fehlgeschlagenes Tool-Calling liegt an der Implementierung der Inference Engine oder an der Quantisierung. Ich würde empfehlen, es in ein paar Tagen nach einem Update erneut zu versuchen. Das passiert bei praktisch jedem Release eines Open Models.
    • Bei mir ist auf einem M5 (32GB) beim Start von LM Studio der Rechner eingefroren, sodass ich neu starten musste.
      Aber gemma-4-26B-A4B-it-GGUF:Q4_K_M lief in llama.cpp problemlos. Sowohl die Geschwindigkeit (38 Token pro Sekunde) als auch die Qualität waren beeindruckend.
    • Ich hatte dasselbe Problem. In der Q_8-Version von LM Studio geriet das Modell in einen Loop-Modus und wiederholte ständig Befehle.
    • Anderen zufolge muss man sowohl die Main- als auch die Runtime-Version aktualisieren.
    • Ich habe fehlgeschlagenes Tool-Calling auch auf einem Ubuntu-Server (charmbracelet/crush) bestätigt.
  • Ich suche ein Open Model als Ersatz für Claude Sonnet 4.5.
    Ich frage mich, ob es unter den Modellen von Ollama Cloud oder OpenRouter.ai etwas gibt, das als Ersatz taugt.
    Mich interessieren eher reale Nutzungserfahrungen von Entwicklern als Benchmarks.

    • Kurz gesagt gibt es kein Modell, das Sonnet oder Opus ersetzt. Auch die GPT-Codex-Familie ist weiterhin hervorragend.
      Ich habe MiniMax, GLM, Qwen, Kimi und andere ausprobiert, aber bei komplexen Aufgaben stoßen sie alle deutlich an ihre Grenzen.
    • GLM5 und KimiK2.5 fühlen sich für mich als ziemlich nahe Alternativen zu Sonnet an.
  • Mich würde interessieren, ob jemand das auf einem M5 Air (32GB, 10 Kerne) mit einem oMLX-Build ausprobiert hat, inklusive Tool-Calling.

    • Release v0.3.2 hat nur teilweisen Support. Textgenerierung funktioniert, aber die Verarbeitung spezieller Tokens ist noch unvollständig.
      Ich teste gerade selbst, wie man Tool-Calling und Support für <|channel> thinking ergänzt.
    • Ich habe gehört, dass jemand Gemma 4 E4B unter MLX ausgeführt hat (Link).
  • Es ist seltsam, dass die Schritte für „Gemma 4 12B“ mitten drin plötzlich zu 26B wechseln.
    Außerdem zeigt ollama ps „14%/86% CPU/GPU“ an – heißt das nicht, dass die GPU-Performance schlecht ist?

    • Beim Mac mini teilen sich CPU und GPU den Speicher, daher würde ich dieses Verhältnis wohl ignorieren.
  • Ein 26B-Modell lokal zu betreiben ist beeindruckend, aber die Latenz ist so hoch, dass es für alles außer Chat kaum taugt.
    Wir haben unsere Bildgenerierungs-Workloads von lokaler Inferenz auf API-Aufrufe umgestellt. Cold Starts und Generierungszeiten waren einfach zu lang.
    Lokal ist gut zum Experimentieren, aber für Produktions-Workloads mit festen Laufzeitvorgaben ist eine API weiterhin im Vorteil.
    Beim Umgang mit datenschutzsensiblen Daten ist ein lokales Setup allerdings sehr nützlich.

  • Ich frage mich, warum so viele Leute Ollama verwenden. Ich habe es ausprobiert, aber es wirkte auf mich zu stark vereinfacht.
    Inzwischen scheint Unsloth Studio für Einsteiger der bessere Standard zu sein.

    • Ollama ist einfach zugänglich, weil ein einziges ollama pull reicht, um ein Modell zu laden.
      Man muss nicht selbst auf Hugging Face nach Modellnamen und Versionen suchen.
      Wenn man tiefer einsteigen will, muss man aber am Ende trotzdem die Server-Architektur lernen.
    • Ollama hatte früh einen First-Mover-Vorteil. Damals war es eine Hürde, llama.cpp selbst zu bauen.
      Heute würde ich eher LM Studio empfehlen. Mich würde interessieren, was Unsloth Studio anders macht.
    • Ich verstehe nicht, warum LM Studio nicht viel öfter erwähnt wird. Ich bin vor ein paar Monaten umgestiegen und finde es deutlich besser.
    • Die Popularität von Ollama kommt durch den Werbeeffekt. Es wurde auf Reddit, Discord und anderswo als „einfaches Frontend für llama.cpp“ vermarktet.
      Wenn man wirklich gewinnen will, muss man Ollama löschen und direkt zu llama.cpp gehen.
    • Ich würde eher das Gegenteil fragen – was genau ist denn das Problem mit Ollama?
      Es läuft auch mit einer 16GB-GPU gut und taugt als Backend für Experimente mit anderen Frontends völlig aus.
  • Ich frage mich, ob man dieses Modell fürs lokale Coding nutzen kann und welche IDE oder Harness damit kompatibel sind.

    • Die meisten Harnesses können lokal fürs Coding genutzt werden, wenn man einfach einen OpenAI-kompatiblen API-Endpunkt angibt.
      Allerdings hat die neueste Codex-Version Kompatibilitätsprobleme mit llama.cpp bei der API-Kompatibilität.
      Ich bevorzuge Pi. Es ist minimalistisch und gut erweiterbar. Claude Code, OpenCode und andere werden ebenfalls häufig genutzt.
    • Es muss Tool-Calling unterstützen, und viele quantisierte GGUFs tun das nicht.
      Um das zu lösen, habe ich einen Proxy namens Petsitter gebaut, der die Funktionen zwischen Inference Engine und Harness emuliert.
      GitHub-Link
      Man setzt Petsitter auf Ollama und darüber dann das Agent-Harness.
      Die neueste Ollama-Version unterstützt bereits "completion", "vision", "audio", "tools", "thinking".
  • Um dieses Modell gestern Nacht zu nutzen, musste man noch die Ollama-v0.20-Prerelease installieren. Deshalb bin ich nicht sicher, ob der aktuelle Guide wirklich korrekt ist.