Lokale LLM-Inferenz mit dem Mac Mini: Unsere Evaluation und wo es passt

Jedes KI-Tool, das Ihr Team nutzt - Coding-Agenten, Chatbots, Workflow-Automatisierungen - sendet Daten an fremde Server. Jeden Prompt, jedes Code-Snippet, jedes interne Dokument. Für viele Unternehmen ist das in Ordnung. Für andere ist es ein Ausschlusskriterium.

Wir haben uns verschiedene Ansätze angeschaut - von reinen Cloud-APIs über hybride Setups bis hin zu komplett selbst gehosteter Inferenz. Was wir dabei gelernt haben: Es hängt stark vom Use Case ab. Dieser Post beschreibt einen Ansatz, den wir als Proof of Concept evaluiert haben: ein lokaler LLM-Endpunkt auf Apple-Silicon-Hardware. Für einzelne Entwickler oder kleine Teams, die ohne großen Vorabaufwand experimentieren wollen, ist das ein guter Einstieg. Wer aber ein wachsendes Team hat, bei dem Agentic Coding zum zentralen Workflow wird oder mehrere Entwickler gleichzeitig intensiv arbeiten, wird mit diesem Ansatz schnell an Grenzen stoßen.

Das Problem mit reiner Cloud-KI

Cloud-KI-APIs sind bequem. Sie sind aber auch:

• Ein Datenschutzproblem: Ihr Code, Ihre Prompts und internen Daten verlassen mit jeder Anfrage Ihr Netzwerk
• Unvorhersehbar teuer: Die Kosten skalieren linear mit der Nutzung, und sobald ein Team KI-Tooling einführt, wächst die Nutzung schnell
• Eine Compliance-Frage: Je nach Branche erfordert das Senden von Daten an Drittanbieter-APIs eine rechtliche Prüfung oder ist möglicherweise gar nicht erlaubt
• Externe Abhängigkeit: Große Cloud-Anbieter sind in der Regel sehr zuverlässig - aber Verfügbarkeit, Rate-Limits und API-Änderungen liegen außerhalb eurer Kontrolle. Bei selbst gehosteter Inferenz habt ihr die Dinge selbst in der Hand.

Nichts davon bedeutet, dass Cloud-KI schlecht ist. Es bedeutet, dass die ausschließliche Abhängigkeit davon Risiken schafft, die es wert sind, verstanden zu werden.

Mac Mini als Evaluierungsoption: Was Apple Silicon interessant macht

Bei der Evaluation lokaler Inferenz-Hardware schauen sich viele Teams zuerst GPU-Server an - verständlicherweise, denn das war lange der Standard. Mittlerweile gibt es aber interessante Alternativen. Eine davon ist Apple Silicon, und zwar aus einem architektonischen Grund, der für LLM-Inferenz relevant ist.

Der Mac Mini mit Apple Silicon (M-Serie) ist für diesen Anwendungsfall interessant wegen Apples Unified-Memory-Architektur: CPU und GPU teilen sich denselben RAM-Pool. Für LLM-Inferenz ist das wichtig - die Modellgewichte müssen für die GPU zugänglich sein, und bei herkömmlicher Hardware bedeutet das dediziertes VRAM. Bei Apple Silicon sind die 32GB Unified Memory Ihr VRAM.

Leistungsbenchmarks

Auf unserem Mac Mini M4 mit 32GB RAM mit Ollama:

Alle vier Modelle zusammen belegen unter 14GB Speicherplatz und passen bequem in 32GB Unified Memory. Selbst die größeren 7B-Modelle erzeugen Ausgabe schneller als man lesen kann.

Generell können sogar noch größere Modelle ohne Probleme genutzt werden. Der Mac Mini M4 mit 32GB kann problemlos Modelle mit bis zu 20B Parametern verarbeiten (es funktionieren auch Modelle mit mehr Parametern wie Qwen3 Coder 30B), solange sie für Inferenz optimiert sind und in die Speichergrenzen passen.

Ollama als KI-Engine: Eine Option unter mehreren

Für das lokale Serving von Modellen gibt es verschiedene Ansätze - llama.cpp für maximale Kontrolle auf niedrigem Level, LM Studio für eine GUI-gestützte Nutzung, oder Frameworks wie vLLM für produktivere Deployments. Wir haben einige davon evaluiert und sind für unser Setup bei Ollama gelandet - vor allem weil der Einrichtungsaufwand minimal ist. Wenn Sie einen tieferen Einblick in Ollamas neueste Features wollen, haben wir das in unserem Ollama-2025-Updates-Post behandelt.

Das Schlüsselmerkmal für dieses Setup: Ollama bietet eine OpenAI-kompatible API unter http://localhost:11434/v1. Das bedeutet, jedes Tool, das das OpenAI-API-Format spricht - Coding-Agenten, IDE-Erweiterungen, Workflow-Automatisierungsplattformen, eigene Skripte - kann sich ohne Anpassung mit Ihrem Mac Mini verbinden.

Einrichtung

Die Einrichtung von Ollama ist einfach: Wir installieren Ollama und laden ein paar Modelle herunter:

1# Ollama installieren (macOS)
2curl -fsSL https://ollama.com/install.sh | sh
3
4# Modelle für verschiedene Anwendungsfälle herunterladen
5ollama pull qwen2.5-coder:7b    # Primäres Coding-Modell
6ollama pull mistral:latest       # Allgemein
7ollama pull gemma3:latest        # Allgemein, schnell
8ollama pull qwen2.5-coder:1.5b  # Leichtgewichtig, schnelles Coding

Um Ollama im Netzwerk verfügbar zu machen (nicht nur localhost), setzen wir die Host-Bindung:

1# In ~/.zshrc oder als launchd-Umgebungsvariable
2export OLLAMA_HOST=0.0.0.0

Dann starten wir Ollama neu, und es hört nun auf allen Interfaces auf Port 11434.

Erreichbar machen: Headscale-VPN

OLLAMA_HOST=0.0.0.0 macht Ollama im lokalen Netzwerk verfügbar. Aber wir wollen es nicht im öffentlichen Internet haben - es gibt keine eingebaute Authentifizierung, und einen ungeschützten API-Endpunkt zu exposen ist ein Sicherheitsrisiko.

Die Lösung, die wir gewählt haben: ein Mesh-VPN als vertrauenswürdiger Perimeter. Wer sagt, dass er im Netzwerk ist, hat sich bereits authentifiziert. Konkret: Headscale - die Open-Source, selbst gehostete Implementierung des Tailscale-Koordinationsservers.

Sicherheitshinweis: Das VPN als vertrauenswürdiger Perimeter funktioniert gut für eingeschränkte Umgebungen und erste Schritte. Für produktionsnahe Setups empfehlen sich zusätzlich RBAC und TLS auf API-Ebene (z.B. via nginx oder ein API-Gateway) sowie granulare Access Control Lists auf Tailscale/Headscale-Ebene.

Wie es funktioniert

Tailscale erstellt ein Peer-to-Peer-VPN (ein "Tailnet") mit WireGuard-Verschlüsselung. Geräte im Tailnet können sich direkt erreichen, ohne Port-Forwarding, Firewall-Regeln oder das Exposen von Diensten im Internet.

Headscale ersetzt Tailscales Cloud-basierten Koordinationsserver durch einen selbst gehosteten. Der Koordinationsserver kümmert sich um Geräteregistrierung und Schlüsselaustausch - er sieht nie den tatsächlichen Datenverkehr (der fließt direkt zwischen den Geräten via WireGuard).

Das Setup:

1. Headscale betreiben auf einem kleinen Server (ein VPS mit öffentlicher IP funktioniert gut)
2. Tailscale-Client installieren auf dem Mac Mini und jedem Rechner der Teammitglieder
3. Clients auf den Headscale-Server verweisen statt auf Tailscales Cloud
4. Der Mac Mini bekommt eine stabile Tailscale-IP (z.B. 100.64.0.10)

Jetzt kann jedes Teammitglied Ollama unter http://100.64.0.10:11434 erreichen - verschlüsselt, authentifiziert und unsichtbar für das öffentliche Internet.

Tailscale vs. Headscale

Wenn das Selbst-Hosten des Koordinationsservers nach mehr Aufwand klingt als gewünscht, ist Tailscales Cloud-Service eine völlig valide Alternative. Er ist kostenlos für den persönlichen Gebrauch und vernünftig bepreist für Teams. Der Kompromiss: Geräte-Metadaten (nicht der Datenverkehr) laufen über Tailscales Server.

Wir nutzen Headscale bei Infralovers, weil wir die volle Kontrolle über die Koordinationsschicht bevorzugen. Aber für kleinere Teams oder schnelle Setups bringt Tailscales gehostete Option Sie in Minuten zum Laufen.

Was dieses Setup für uns löst - und was nicht

Für unsere konkreten Anforderungen bringt dieses Setup folgende Vorteile:

• Datenschutz: Prompts und Code verlassen nie unser Netzwerk. Kein Dritter sieht unsere Daten.
• Kostenvorhersehbarkeit: Einmalige Hardwarekosten. Keine Per-Token-Abrechnung, keine Überraschungsrechnungen.
• Niedrige Latenz: Lokale Netzwerk-Roundtrips werden in einstelligen Millisekunden gemessen.
• Compliance-freundlich: Einfacher, Anforderungen an Datenresidenz zu erfüllen, wenn Daten On-Premise bleiben.
• Immer verfügbar: Keine Abhängigkeit von externer API-Verfügbarkeit oder Rate-Limits.

Wo dieses Setup an Grenzen stößt

Dies ist keine Wunderlösung. Wir tauschen die Vorteile von Cloud-KI gegen die Einschränkungen lokaler Modelle:

• Genauigkeit: Lokale und Open-Source-Modelle sind nicht so leistungsfähig wie neuste GPT- oder Claude-Opus-Modelle. Für komplexes Reasoning, neuartige Architekturentscheidungen oder Aufgaben, die von Frontier-Modellen profitieren, sind Cloud-APIs weiterhin besser.
• Gleichzeitige Nutzer: Mit 32GB RAM und mehreren verfügbaren Modellen gibt es ordentlich Spielraum - aber starke gleichzeitige Nutzung kann dennoch zu Verlangsamungen oder Modell-Entladungen führen.
• Betriebsverantwortung: Wir besitzen die Hardware, die Updates und die Verfügbarkeit. Wenn Ollama eine neue Version veröffentlicht oder ein Modell aktualisiert werden muss, liegt das bei uns.
• Kontextfenster: Ollama hat Standard-Kontextfenster, basierend auf unserem verfügbaren VRAM. Wir können das erhöhen, aber größere Kontexte verbrauchen mehr Speicher.

Fazit

Für uns hat sich gezeigt: Es geht nicht um "lokal vs. Cloud", sondern um hybrid - lokal für routinemäßige, hochvolumige Aufgaben, bei denen Datenschutz und Kosten eine Rolle spielen, Cloud für die Fälle, bei denen Frontier-Modellqualität wirklich einen Unterschied macht.

Ob dieser Ansatz für euer Team passt, hängt von euren konkreten Anforderungen ab - Teamgröße, Nutzungsverhalten, Compliance-Anforderungen und wie viel Betriebsverantwortung ihr übernehmen wollt. Wir sehen dieses Setup als eine Option im Werkzeugkasten, nicht als Universallösung.