Verwendet ihr lokal offene LLMs und Coding-Assistenten? Teilt bitte euer Setup
(news.ycombinator.com)- Ein Ask HN-Thread, in dem Hacker-News-Nutzer gefragt werden, wie sie offene LLMs und Coding-Assistenten lokal einsetzen und auf welcher Laptop-Hardware
- Welche Modelle sie verwenden (z. B. Ollama, LM Studio usw.) und welche Open-Source-Coding-Assistenten/Integrationslösungen (z. B. VS Code-Plugins) sie nutzen
- Welche Laptop-Hardware (CPU, GPU/NPU, Arbeitsspeicher, dedizierte GPU oder integrierte GPU, OS) sie einsetzen und welche Leistung sie damit im Workflow erzielen
- Für welche Aufgaben sie das nutzen (Code-Vervollständigung, Refactoring, Debugging, Code-Review) und wie stabil es ist (was gut funktioniert und wo die Grenzen liegen)
-
1) MacBook Pro / Mac Studio (M2~M4 Max, 64~128GB) + LM Studio/Ollama + VS Code Continue
- Vorteile
- Dank des einheitlichen Speichers bei Macs laufen Qwen3-Coder-30B-A3B, gpt-oss-20b und sogar Gemma 27B einfach lokal, sodass ein Workflow wie „Code einlesen → zusammenfassen → kleine Änderungen“ möglich ist
- Wenn nur die LM Studio API oder Ollama serve läuft, können VS Code Continue.dev, Zed und JetBrains sofort darauf zugreifen, was praktisch eine Claude-Code-ähnliche UX ermöglicht
- Die für Macs typische geringe Latenz sorgt dafür, dass Code-Vervollständigung und Kommentarerzeugung bei etwa 50~80 tok/s nicht allzu zäh wirken
- Dass es auch im Flugzeug, im Zug oder offline funktioniert, ist ein großer Vorteil und eignet sich gut dafür, „Firmen-Code nicht nach außen gelangen zu lassen“
- Nachteile
- Ab Modellen über 20B gibt es Hitze- und Lüftergeräuschprobleme, und selbst ein M4 Max mit 128GB stößt bei 120B an Grenzen oder wird langsam
- Agenten-Szenarien wie „so lange mit bash-in-a-loop weitermachen wie Claude 4.5 Sonnet“ sind noch nicht ausreichend abgedeckt
- MacBooks mit 24GB oder 32GB haben nur wenig VRAM-Zuweisung, sodass man letztlich auf 7B~12B zurückgehen muss; bei großem Kontext werden sie sofort langsamer
- Vorteile
-
2) Desktop/Workstation mit RTX 3090·4090·Pro 6000, Laptop nur als dünner Client
- Vorteile
- Man kann llama.cpp / vLLM / Ollama komplett durchprobieren, und selbst gpt-oss-120B lässt sich „langsam, aber tatsächlich“ ausführen
- In VS Code laufen Continue oder llama-vscode auf dem Laptop, während das Modell auf einer Maschine zu Hause inferiert; dadurch gibt es kaum Last bei Akku oder Wärmeentwicklung auf dem Laptop
- Mit einer RTX 3090 24GB liefern gpt-oss-20B, Qwen2.5/3 Coder 14~30B brauchbare Token-Geschwindigkeiten für die Praxis, sodass Autocomplete plus kurzes Refactoring gut machbar sind
- Viele betreiben zu Hause Open WebUI + Ollama und verbinden sich per VPN/Tailscale, sodass auch remote eine private Umgebung erhalten bleibt
- Nachteile
- Bei GPU-VRAM von 24GB oder weniger muss man 120B stark quantisieren, wodurch die Qualität sichtbar sinkt
- vLLM liefert zwar gute Performance, aber Installation und Build sind mühsam; so sehr, dass man sinngemäß hört, man solle es „mit einem aktualisierten Runner noch einmal versuchen“
- Praktisch keine Portabilität; wer „wirklich alles auf nur einem Laptop erledigen“ will, für den passt dieses Setup nicht
- Vorteile
-
3) gpt-oss-120B-zentriertes Setup (Aider, Codex, lokale Agenten)
- Vorteile
- Mehrere Leute meinten sinngemäß, dass dies von allem, was sie lokal ausprobiert haben, GPT-5 am nächsten kommt, insbesondere bei der Genauigkeit bei Coding-Tasks
- In Verbindung mit offenen Coding-Assistenten wie Aider, Codex oder roocode funktionieren Experimente, bei denen Review → Änderung → Test → Commit in einem Durchlauf erledigt wird, tatsächlich
- Es wurden Tipps geteilt, wie man in llama.cpp mit CPU+GPU-Hybridladung sogar bei 8GB VRAM noch irgendwie arbeiten kann, sodass die Hardwareanforderungen flexibler sind als gedacht
- Nachteile
- Das Hauptproblem ist die Geschwindigkeit. Während ChatGPT dieselben 50 Fragen in 6 Minuten erledigt, kann ein 120B-Modell über 1 Stunde daran kauen; das ist also eher etwas für Leute, die Wartezeit akzeptieren
- Bei Tools wie Codex muss man Inference-Parameter hart codieren, damit es nicht hängen bleibt, und AGENTS.md muss sehr ausführlich sein, damit es halbwegs wie ein Mensch arbeitet
- Auf einem Laptop allein ist ein Dauerbetrieb wegen Wärme, Stromverbrauch und Speicher kaum praktikabel; realistisch ist eher ein Laptop, der sich mit einer entfernten GPU verbindet
- Vorteile
-
4) AMD Strix Halo / Ryzen AI / Framework 128GB mit viel RAM + llama.cpp/Continue.dev
- Vorteile
- Mit 128GB RAM ist Qwen3 Coder 30B praxisnah nutzbar, und ein hybrides Setup ist möglich, bei dem nur nötige Layer auf GPU/NPU liegen und der Rest im RAM läuft
- Laut Berichten war das eine realistische Option für Situationen wie „Der Code darf das Unternehmen nicht verlassen“ oder „Mit AMD sind Cloud-Treiber noch nicht besonders gut“
- Konstruktionen wie ein einfacher llama.cpp-Server à la lemonade-server, der beim Booten automatisch startet und auf den sich der Editor übers Netzwerk verbindet, funktionieren gut
- Nachteile
- Unter Linux gibt es Berichte, dass Energiesparen/Kamera/Treiber noch nicht ganz rund laufen, und teils musste man auf Kernel 6.18 schauen
- Die NPU-Leistung liegt nicht auf NVIDIA-Niveau, sodass „Agenten auf Frontier-Niveau“ unrealistisch sind; am Ende bleibt es bei 20~30B als „Assistent“
- Informationen für AMD muss man sich oft über GitHub-Repos oder Foren zusammensuchen; die Informationsdichte ist geringer als bei Mac oder NVIDIA
- Vorteile
-
5) Normale Laptops mit 16~32GB (MacBook Air, M2/M3 Pro mit wenig RAM) + 7B~12B-Modelle nur für FIM-Autocomplete
- Vorteile
- Schon mit qwen2.5-coder:7b, mistral 7b instruct, gemma3:12b bekommt man Dinge wie „Schreib diese Zeile weiter“ oder „Wie war nochmal diese SQL-Syntax?“ sofort
- Mit dem llama-vscode-Plugin oder Continue.dev läuft Autocomplete auch ohne Internet weiter, sodass der Arbeitsfluss nicht unterbrochen wird
- Die Hardwarebelastung ist gering, es gibt kaum Hitze oder Lüftergeräusche, und auch der Akku wird nicht schnell leer
- Nachteile
- Sobald der Kontext etwas länger wird, steigt der Unsinnsanteil sofort; Dinge wie Refactoring oder das Erzeugen von Testcode, bei denen mehrere Dateien gleichzeitig verstanden werden müssen, sind nahezu unmöglich
- Die meisten betonten klar: „Das ist kein Ersatz für Cloud-Modelle, sondern nur für Autocomplete.“
- Weil man die Modelle stark auf 4 Bit herunterdrücken muss, ist die Modellauswahl eingeschränkt
- Vorteile
-
6) Komplett offline / Privacy-first-Setup (Ollama + Open WebUI + VPN)
- Vorteile
- Wenn zu Hause ein Mac Studio M4 Max 128GB oder ein Desktop mit Ollama + Open WebUI läuft, ist von draußen per VPN über Laptop oder Smartphone trotzdem alles lokal
- Nutzer dieses Setups nannten als Stärke Dinge wie „Ich nutze jetzt kaum noch ChatGPT“ und „Weil sich die Versionen nicht ändern, gehen feinjustierte Prompts nicht kaputt“
- Innerhalb von Unternehmen ist dies das am leichtesten erklärbare Setup, wenn gefordert wird, dass „kein Code zum Training verwendet werden darf“
- Nachteile
- Man muss Modell-Upgrades oder -Wechsel selbst durchführen; anders als in der Cloud wird es nicht „von allein intelligenter“
- Wenn die GPU schwach ist, werden Modelle über 20B sofort langsam; dann muss man doch Hardware nachrüsten, und genau dann kommt der Gedanke auf: „Warum habe ich das nicht einfach in der Cloud gemacht?“
- Vorteile
-
7) Gemeinsames Fazit
- Mit nur einem Laptop ist es derzeit noch schwer, Claude Code / GPT-5 + Agenten zu ersetzen; lokal passt am besten zu kurzer Code-Erzeugung, Hilfestellung, Zusammenfassungen und Autocomplete
- Häufig genannt wurden deshalb entweder „Laptop ↔ großer Rechner zu Hause“ oder „Mac 128GB, dafür nur 20~30B schnell“
- Trotzdem sagten im Grunde alle dasselbe: Wenn Privacy, nahezu keine Latenz und stabile Versionen wichtig sind, ist lokal auch jetzt noch die richtige Antwort
6 Kommentare
Statt ein VPN zu verwenden, scheint es besser zu sein, ein Bearer-Token einzurichten und SSH-Tunneling zu nutzen.
Ich denke, dass sich der Einstieg ins Self-Hosting von LLMs wegen der hohen Vorabinvestitionen in den nächsten fünf Jahren weiterhin wirtschaftlich nicht rechnen wird. In 3 bis 5 Jahren, wenn es für Code-Autovervollständigung ausreichend schnelle Hardware mit attraktivem Preis-Leistungs-Verhältnis gibt, werde ich das Thema noch einmal prüfen.
Geprüfte Konfigurationen
Hacker-News-Kommentare
Ich wollte selbst mit KI herumexperimentieren und habe mir deshalb einen gebrauchten Dell Precision 3620 Tower i7-7700 gekauft.
Ich habe den RAM aufgerüstet und auch das Netzteil ausgetauscht, um eine RTX 3060 als GPU einzubauen.
Dann habe ich Ubuntu Server installiert, den Rechner als k3s-Cluster-Knoten zu Hause eingerichtet und lasse dort Ollama und OpenWebUI laufen.
Hauptsächlich nutze ich ihn für KI-Tagging und Zusammenfassungen in Karakeep, aber auch zur Analyse einer Einfahrtskamera, die per Python-Code Lieferfahrzeuge erkennt.
Ich betreibe Ollama CPU-basiert auf einem Dell Precision T710 (Xeon E6320, 120GB RAM, RAID5 SSD 240TB), ganz ohne GPU.
Ich arbeite an einem Projekt, das die Wahlgesetze aller 50 Bundesstaaten per RAG indexiert, um Begriffsinkonsistenzen und Halluzinationsprobleme zu visualisieren.
Das Ziel ist, Integritätslücken in Wahlverfahren zu identifizieren.
Die dazugehörige Mindmap gibt es hier: Election Frauds v1.4 Mindmap PDF
Ich nutze lokale LLMs zum Coden, aber auf einem Laptop könnte ich mir das nicht vorstellen.
Ich verwende einen GPU-Server und wechsle dort die Modelle mit llama.cpp + llama-swap.
Mein bisher zufriedenstellendstes Setup ist die Kombination Aider + gpt-oss-120b.
Mit Ryzen AI Max+ und 128GB RAM würde es wohl auch gehen, aber Nicht-NVIDIA-Hardware ist extrem langsam.
Über OpenRouter kann man außerdem nur Anbieter ohne Datenspeicherung auswählen.
Trotzdem sind GPT5 oder Claude deutlich schneller und günstiger als lokal.
ChatGPT kam in 6 Minuten auf 46/50, gpt-oss-120b in 1 Stunde auf 47/50.
Das lief auf einem System mit i7 + 64GB RAM + GPU mit 8GB VRAM.
Wenn man auf dem Mac einen lokalen Code-Agenten laufen lassen will, geht das so:
npm install -g @openai/codexbrew install ollama; ollama serveollama pull gpt-oss:20bcodex --oss -m gpt-oss:20bEs funktioniert ohne Internet und benötigt einen Mac ab M1 + 24GB GPU-Speicher.
Das 120b-Modell liefert 1,5-mal so viel Leistung wie 20b, verlangt aber die 5-fachen Anforderungen.
Auf einem MacBook Pro 64GB betreibe ich Qwen3-Coder-30B-A3B Q4 quant mit llama.cpp.
In VSCode nutze ich continue.dev und halte den System-Prompt kurz.
Ich erreiche 50 Token pro Sekunde bei der Generierung und 550 Token Verarbeitungsrate.
Bei kurzen, klaren Aufgaben ist die Qualität ähnlich wie bei Frontier-Modellen.
Da es auch offline schnell und stabil läuft, bin ich sehr zufrieden.
Für komplexere Aufgaben nutze ich die APIs von Claude oder Deepseek.
Wenn man einen Mac kauft, würde ich mindestens ein Pro-Modell empfehlen.
Das Air hat keinen Lüfter und bekommt die Wärme nicht in den Griff; ich halte ein Studio für die bessere Wahl als einen Mac mini.
Mit der App TG Pro kann man die Lüfter aggressiver regeln (ca. 20 $).
Auf einem MacBook Pro mit M4 Pro + 24GB RAM betreibe ich das GPT OSS 20B-Modell, aber das Kontextfenster ist klein.
Mit einem 128GB-Modell könnte man vermutlich den ganzen Tag offline coden.
Ich nutze ein Apple M4 Max 128GB zusammen mit einem GPD Win 4 (Ubuntu 24.04) über USB-C.
Mit Claude Code, RA.Aid und llama.cpp verteile ich die Arbeit über einen Agent Organizer.
Claude automatisiert dabei alles von der Architekturplanung bis zum Code-Review.
Wer sich für LLM-Workstations interessiert, dem kann ich den YouTube-Kanal von Alex Ziskind empfehlen ( @AZisk ).
Dort gibt es verschiedene Reviews zu lokalen LLM-Workstations.
Die Präsentation ist sauber und die Ratschläge sind praxisnah.
Auf einem MacBook Pro M4 Max 128GB nutze ich hauptsächlich LMStudio und Ollama.
Die Modelle sind qwen3-coder-30b A3B Instruct 8-bit MLX und gpt-oss-120b-MXFP4-Q8.
Für groß angelegte Code-Generierung gibt es Grenzen, aber für lokale Repo-Zusammenfassungen und Dokumentation reicht es völlig aus.
Die zugehörigen Communities sind ebenfalls sehr aktiv.
Für die Erstellung von READMEs bevorzuge ich gemma3-27b-it-qat und gpt-oss-120b.
Auf einem MacBook Pro M1 Pro 32GB + Asahi Linux betreibe ich Qwen3:32b über die CLI.
Ich nutze es für Hilfe bei ARMv8-Assembler und SoC-bezogenen Themen.
Die Geschwindigkeit liegt nur etwas unter meinem Lesetempo und ist damit gut brauchbar.
Ich habe gehört, dass Qwen3-coder schneller ist, und finde das interessant.
Ich bevorzuge eine vollständig lokale Umgebung ohne Cloud oder Agenten-Integration.
Da sich Ollama von seinem Offline-Fokus entfernt, will ich jetzt zu llama.cpp wechseln.
Wegen des anderen Modellformats bin ich unsicher, ob ich meine Ollama-Modelle direkt weiterverwenden kann.
[Hinweis] Unter Linux ist der Stromverbrauch hoch, daher sollte man es unbedingt am Netz betreiben.
Für allgemeine Aufgaben ist es weniger intelligent, aber bei coding-zentrierten Aufgaben effizienter.
Je mehr ich lese … desto eher denke ich, dass es überraschenderweise doch eine Nachfrage nach DGX SPARK geben könnte? Anfangs dachte ich noch: Das Ding hat ein miserables Preis-Leistungs-Verhältnis, warum sollte man das kaufen! Aber,
Wegen der unternehmensinternen Sicherheitsrichtlinien nutzen wir externe LLM-APIs überhaupt nicht und verwenden stattdessen das auf
vllmbasierendegpt oss, das uns die firmeninterne Abteilung für Cloud-Management bereitstellt.Als lokal lässt sich das wohl nur schwer eindeutig bezeichnen.