Ollama läuft jetzt auf Apple Silicon auf Basis von MLX

• Eine Preview-Version von Ollama auf Basis des Apple-MLX-Frameworks wurde veröffentlicht und bietet Leistungssteigerungen durch Nutzung der Unified-Memory-Architektur von Apple Silicon
• Über den GPU Neural Accelerator der Chips der M5-Serie werden sowohl TTFT (Time to First Token) als auch die Token-Generierungsgeschwindigkeit verbessert
• Mit Unterstützung für das NVFP4-Format werden Speicherbandbreite und Speicherbedarf reduziert, während die Modellgenauigkeit erhalten bleibt; außerdem lassen sich mit NVIDIA Model Optimizer optimierte Modelle ausführen
• Durch Cache-Wiederverwendung und intelligente Cache-Richtlinien steigen Speichereffizienz und Antwortgeschwindigkeit zwischen Gesprächen, und die Cache-Trefferquote bei gemeinsam genutzten Prompts verbessert sich
• Künftig sollen mehr Modelle und eine Importfunktion für benutzerdefinierte Modelle hinzukommen, um die unterstützten Architekturen zu erweitern

---

Preview von Ollama auf Basis von MLX auf Apple Silicon

• Eine neue Preview-Version von Ollama auf Basis von Apples MLX-Framework wurde veröffentlicht
  • Damit lassen sich auf macOS persönliche Assistenten (OpenClaw) oder Coding-Agenten (Claude Code, OpenCode, Codex usw.) schneller ausführen
  • Leistungsverbesserungen durch Nutzung der Unified-Memory-Architektur von Apple Silicon

• Leistungssteigerungen auf Apple Silicon

  • Ollama läuft auf Apples MLX-Machine-Learning-Framework und beschleunigt mit dem GPU Neural Accelerator der Chips M5, M5 Pro und M5 Max sowohl TTFT (Time to First Token) als auch die Token-Generierungsgeschwindigkeit
  • Bei einem Test am 29. März 2026 wurde Alibabas Modell Qwen3.5-35B-A3B (NVFP4-Quantisierung) mit der bisherigen Ollama-Implementierung (Q4_K_M) verglichen
  • Ollama Version 0.19 erreichte bei int4-Ausführung 1851 token/s Prefill und 134 token/s Decode

• NVFP4-Unterstützung

  • Unterstützung für NVIDIAs NVFP4-Format erreicht sowohl den Erhalt der Modellgenauigkeit als auch eine Reduzierung von Speicherbandbreite und Speicherbedarf
  • Konsistenz der Ergebnisse zwischen Inferenzumgebungen mit NVFP4 und Produktionsumgebungen wird sichergestellt
  • Mit NVIDIAs Model Optimizer optimierte Modelle können ausgeführt werden
  • Je nach Design und Einsatzzweck von Ollamas Forschung und Hardware-Partnern sollen künftig auch weitere Präzisionen hinzugefügt werden

• Verbesserungen am Cache-System

  • Durch Cache-Wiederverwendung sinkt der Speicherverbrauch zwischen Gesprächen, und bei gemeinsam genutzten System-Prompts verbessert sich die Cache-Trefferquote
  • Intelligente Checkpoints reduzieren den Prompt-Durchsatz und verbessern die Antwortgeschwindigkeit
  • Durch intelligente Cache-Eviction-Richtlinien bleiben gemeinsam genutzte Präfixe länger erhalten, selbst wenn ältere Branches gelöscht werden

• So geht der Einstieg

  • Ollama 0.19 herunterladen
  • Das neue Modell Qwen3.5-35B-A3B wurde mit Sampling-Parametern für Coding-Aufgaben abgestimmt
  • Erforderlich ist ein Mac mit 32 GB oder mehr Unified Memory
  • Ausführungsbeispiele:
    • Claude Code: ollama launch claude --model qwen3.5:35b-a3b-coding-nvfp4
    • OpenClaw: ollama launch openclaw --model qwen3.5:35b-a3b-coding-nvfp4
    • Modell-Chat: ollama run qwen3.5:35b-a3b-coding-nvfp4

• Ausblick

  • Unterstützung für weitere Modelle geplant
  • Geplante Ergänzung einer Importfunktion für benutzerdefinierte Modelle auf Basis der unterstützten Architekturen
  • Die Liste der unterstützten Architekturen wird fortlaufend erweitert

• Dank

  • An das MLX-Contributor-Team für die Entwicklung des Beschleunigungs-Frameworks
  • An das NVIDIA-Team für NVFP4-Quantisierung, Modelloptimierung, MLX-CUDA-Unterstützung, Ollama-Optimierung und Tests
  • An die GGML- und llama.cpp-Teams für den Aufbau lokaler Frameworks und der Community
  • An das Alibaba-Qwen-Team für die Bereitstellung von Open-Source-Modellen und die Zusammenarbeit

[GN⁺]

Hacker-News-Kommentare

• Mein "apfel" ist eine CLI für Apples lokale On-Device-Foundation-Models
  Es gibt zwar ein 4k-Kontextlimit und überzogene Guardrails, die sogar Farbbeschreibungen blockieren, aber es fühlt sich extrem mächtig an, dass man es direkt aus Bash-Skripten ohne externe Aufrufe nutzen kann

  • Ehrlich gesagt kann ich kaum glauben, dass Apple das in diesem Zustand veröffentlicht hat
    Ich hatte mich auch darauf gefreut, war nach der Nutzung aber sehr enttäuscht. Inzwischen bin ich fast erleichtert, dass Apple offenbar vollständig in Richtung Gemini umgeschwenkt ist
  • Tolles Projekt. Gibt es vielleicht auch Pläne für eine Homebrew-Distribution?

• Ich denke, On-Device-LLMs sind die Zukunft
  Die Sicherheit ist höher, der Stromverbrauch geringer als in Rechenzentren, und das Problem der Inferenznachfrage lässt sich ebenfalls abmildern. Die meisten Nutzer brauchen ohnehin keine Performance auf dem allerneuesten Stand

  • Die Sicherheit ist zwar höher, aber die Effizienz des Angebots könnte sich eher verschlechtern
    Rechenzentren sind dank GPU-Batching und hoher Auslastung fast 100-mal effizienter als private PCs
  • Aus Unternehmenssicht kann ein zentralisiertes Rechenzentrumsmodell weiterhin sinnvoll sein
    Ein hybrider Ansatz wirkt aber vielversprechend, bei dem lokale Modelle einfache Anfragen bearbeiten und komplexe in die Cloud weiterleiten
  • Ich habe kürzlich auf einem M4 MBP llama.cpp installiert und experimentiere mit lokalen Modellen
    Es hat eine integrierte ChatGPT-ähnliche Oberfläche und ist praktisch für schnelle Tests. Selbst mit 16 GB RAM laufen einige Modelle ziemlich ordentlich
    Zum Beispiel ist Qwen 3.5 9B stark zensiert, während die uncensored Version im Gegenteil fast zu frei ist, was das Austarieren interessant macht
  • Mit SSD-Offloading lassen sich sogar SOTA-Modelle auf Consumer-PCs ausführen
    Allerdings ist die SSD-Bandbreite der Flaschenhals, daher ist möglichst viel RAM für den Cache hilfreich. Wenn man auf Antworten warten kann, ist das durchaus praktikabel
  • Ich betreibe seit fünf Jahren digitales Journaling und habe diese Entwicklung vorausgesehen
    Kürzlich habe ich mit Qwen 3.5 4B und 27B eine graphRAG-App gebaut, und die Trennung von kleineren Tasks und Frage-Antwort-Aufgaben funktioniert ziemlich gut
    Ich habe MLX verwendet, und beim Batch-Processing der Entitätsextraktion fühlte es sich deutlich schneller an

• Schön zu sehen, dass sich die Ollama-Inferenz auf dem Mac dank MLX stark verbessert hat
  Vor allem die SSD-KV-Caching-Funktion von omlx.ai war ein Gamechanger
  Selbst wenn eine Session aus dem Speicher verschwindet, muss man nicht erneut prefilling durchführen, und dank der schnellen Prefill-Geschwindigkeit des M5 Max bleibt mehr Zeit für die Generierung

• Ich betreibe qwen 70b 4-bit auf einem M2 Max mit 96 GB mit llama.cpp
  Für Alltagsaufgaben ist es stabil genug. Früher hat Ollama wohl llama.cpp über die Shell aufgerufen, aber mit dem jetzigen nativen Wechsel zu MLX dürfte die Speichereffizienz besser werden
  Ich will es bei großen Modellen mit dem GGUF-Pfad vergleichen

  • Mich würde interessieren, wie hoch die Token-Generierungsrate pro Sekunde ist
  • Beim initialen Launch wurden einige GGUF-Modelle überschrieben, wodurch Downloads auf Nicht-Apple-Silicon-Plattformen blockiert wurden. Hoffentlich wird das bald behoben

• Ich frage mich, warum man überhaupt noch Ollama verwendet
  Lemonade oder llama.cpp sind besser optimiert und ähnlich benutzerfreundlich

• Ich frage mich, ob es Nicht-Mac-Alternativen gibt, mit denen sich lokale Modelle mit einer Leistung auf Mac-Niveau betreiben lassen

  • Nicht auf vergleichbarem Niveau. Auf PCs braucht man GPUs der Klasse 5090, aber sowohl die Token-Effizienz pro Kosten als auch die Energieeffizienz von Apple Silicon sind deutlich besser

• Mich würde interessieren, wie es im Vergleich zur neuesten MLX-Inferenz-Engine optiq aussieht
  optiq unterstützt Turboquantization

• Mich interessiert der Leistungsvergleich zwischen llama.cpp und MLX

  • MLX ist etwas schneller, benötigt aber etwas mehr RAM
    In den meisten Fällen ist der Geschwindigkeitsgewinn den Aufpreis aber wert

• Ich warte auf den Tag, an dem man mit nur 16 GB RAM unter macOS bequem Claude Code mit einem lokalen LLM nutzen kann

  • Ich habe gehört, dass derzeit mindestens 32 GB nötig sind, frage mich aber, wie nah wir diesem Punkt inzwischen gekommen sind