Claude Code mit lokalen LLMs im Homelab betreiben

Claude Code auf lokalen LLMs im Homelab: Kaufberatung und Setup-Ratgeber 2026

Lesezeit: ca. 13 Minuten

Claude Code ist ein Kommandozeilen-Werkzeug, das seine Intelligenz aus einem Sprachmodell zieht — normalerweise aus Anthropics Cloud-Modellen gegen API-Gebühr. Weniger bekannt ist, dass sich das CLI von diesem Backend entkoppeln lässt: Du kannst es auf einen lokalen Modell-Server im eigenen Homelab zeigen und damit ohne API-Kosten arbeiten, ohne dass ein Zeichen deines Codes das Haus verlässt. Der Preis dafür ist Rechenleistung bei dir zu Hause und ein Modell, das nicht an die Cloud-Spitzenmodelle heranreicht.

Die Bausteine sind Stand August 2026 ausgereift: Ollama und llama.cpp als lokale Inferenz-Server, dazu spezialisierte Coding-Modelle im GGUF-Format. Als Hardware-Basis dominieren gebrauchte NVIDIA-Karten mit 24 GB VRAM sowie Systeme mit Unified Memory.

Ein Wort zur Preislage vorab: Der Hardware-Markt ist im August 2026 durch die anhaltende Speicherknappheit stark verzerrt. Jede Preisangabe ist als grobe Ordnung zu lesen und am Kauftag gegenzuprüfen. Dieser Ratgeber für aimageddon.de sortiert die Faktenlage: welche Hardware wirklich reicht, welche Modelle taugen, wie du die Verbindung herstellst — und wo die Grenzen liegen.

Warum lokale LLMs für Claude Code?

Datenschutz und Kostenkontrolle

Der stärkste Grund ist der Datenschutz. Wer an fremdem Code, internen Repositories oder Projekten mit sensiblen Daten arbeitet, schickt bei der Cloud-Nutzung jeden Prompt und jeden Datei-Ausschnitt an einen externen Anbieter. Im Homelab bleibt alles auf der eigenen Maschine — kein Upload, im Extremfall komplett offline betreibbar. Genau das macht das Setup für Firmen interessant, die DSGVO-Anforderungen sauber einhalten wollen.

Der zweite Grund ist die Kostenstruktur. Cloud-Modelle rechnen pro Token ab; bei intensiver Agent-Nutzung mit vielen Datei-Zugriffen summiert sich das. Ein lokales Modell verursacht nach der Anschaffung nur noch Stromkosten. Ob sich das rechnet, hängt stark vom Nutzungsvolumen ab — bei gelegentlicher Nutzung amortisiert sich eine 24-GB-Karte kaum. Rechne realistisch mit Anschaffung, Stromverbrauch unter Last und der Zeit fürs Einrichten. Die vollständige Rechnung steht in unserem Vergleich Homelab-KI-Server bauen oder kaufen.

Realistische Erwartungen

Hier ist Nüchternheit wichtig, weil viele Anleitungen das lokale Setup als vollwertigen Ersatz verkaufen. Das ist es nicht: Die Intelligenz kommt vom Modell, nicht vom CLI. Claude Code ist die Hülle — ein lokales 32-B-Modell spielt nicht in der Liga der Cloud-Spitzenmodelle.

Für Routine-Aufgaben auf überschaubaren, eigenen Repos kann ein gutes lokales Coding-Modell reichen: Boilerplate schreiben, einzelne Funktionen refactoren, Tests generieren, Fehlermeldungen erklären. Deutlich ab fallen lokale Modelle bei komplexen Multi-File-Änderungen, bei langem Kontextverständnis über viele Dateien hinweg und bei zuverlässigem Tool-Calling in Agent-Workflows. Wer das Setup als brauchbaren Assistenten für Routine begreift, wird nicht enttäuscht.

Hardware-Anforderungen fürs Homelab

VRAM ist der Flaschenhals

Über die Frage, welche Modelle du laden kannst, entscheidet der Grafikspeicher — die reine Rechenleistung ist zweitrangig. Ein Modell muss vollständig in den VRAM passen, sonst lagert es in den langsamen System-RAM aus, und die Geschwindigkeit bricht ein.

Die praktische Einstiegsklasse sind Karten mit 24 GB VRAM. Die gebrauchte RTX 3090 gilt seit Jahren als Preis-Leistungs-Empfehlung, die RTX 4090 ist schneller und teurer — die 24-GB-Grenze ist bei beiden dieselbe. Mit 24 GB laufen Coding-Modelle bis rund 32 Milliarden Parameter in quantisierter Form flüssig. Wer mehr will, kombiniert mehrere Karten: Das verdoppelt den nutzbaren VRAM, erhöht aber Anschaffung, Stromverbrauch und Komplexität deutlich. Wie sich das gegen kompakte Alternativen rechnet, steht in unserem Vergleich Mini-PC gegen Desktop-GPU.

Alternativen mit Unified Memory

Daneben haben sich Systeme etabliert, bei denen CPU und GPU sich einen großen Speicher teilen. Apples Mac Studio lässt sich in der Ultra-Ausbaustufe mit bis zu 512 GB konfigurieren; schon kleinere Ausbaustufen reichen für große Coding-Modelle.

Auf der PC-Seite ist die GB10-Plattform von NVIDIA interessant, weil sie unter vielen Namen verkauft wird: als DGX Spark, Asus Ascent GX10, Lenovo ThinkStation PGX, Dell Pro Max, HP ZGX Nano und weitere. Chip, Speicher und Software-Stack sind dabei identisch — 128 GB Unified Memory bei rund 273 GB/s, Preise ab etwa 3.000 US-Dollar. Wer diese Geräte vergleicht, vergleicht also Gehäuse, Kühlung und Preis, nicht Leistung.

Der Trade-off ist bei allen Unified-Memory-Systemen ähnlich: viel Speicher, aber nicht die Bandbreite dedizierter Grafikkarten. Zur Einordnung: Eine Consumer-GPU der Oberklasse liegt jenseits von 1.000 GB/s, Apple Silicon in der Ultra-Stufe bei rund 800, die GB10-Systeme bei 273. Für große Modelle bei moderater Geschwindigkeit sind sie stark; für maximale Tokens pro Sekunde bleibt die GPU vorn.

Passende Modelle für Coding-Aufgaben

Die üblichen Kandidaten

Bei den Modellen haben sich einige Familien als Standard herausgebildet. Die Qwen-Coder-Reihe gilt als eine der stärksten offen verfügbaren Coding-Linien: Qwen2.5-Coder kommt in Größen von 0,5B bis 32B, wobei die 32B-Variante die typische Wahl für eine 24-GB-Karte ist. Mit Qwen3-Coder gibt es eine neuere Generation, unter anderem als 30B-Variante mit Mixture-of-Experts-Architektur. DeepSeek-Coder und Codestral von Mistral runden das Feld ab.

Ein Hinweis zu MoE-Modellen, der beim Speicherplanen wichtig ist: Bei ihnen sind pro Token nur wenige Milliarden Parameter aktiv, aber alle müssen im Speicher liegen. Die aktiven Parameter senken die Bandbreitenlast, nicht den Speicherbedarf.

Prüf bei jedem Modell vor dem Einsatz die Lizenz: „Open Source“ ist bei KI-Modellen kein einheitlicher Begriff. Manche Lizenzen schränken kommerzielle Nutzung ein oder enthalten Zusatzbedingungen. Community-Quantisierungen können zudem eigene Lizenzen haben, die von der des Basismodells abweichen.

Quantisierung: der Trade-off

Modelle werden lokal fast immer im GGUF-Format geladen. Entscheidend ist die Quantisierung — sie bestimmt, wie viel VRAM ein Modell belegt und wie gut es antwortet.

Die Faustregel: Q4 halbiert grob den Speicherbedarf gegenüber Q8 und macht größere Modelle erst auf 24-GB-Karten lauffähig, kostet aber etwas Qualität. Für die meisten Homelab-Setups ist eine mittlere Q4- bis Q5-Quantisierung eines größeren Modells der beste Kompromiss — ein größeres Modell in Q4 schlägt in der Praxis oft ein kleineres in Q8. Unterhalb von Q4 fangen Modelle dagegen an, bei Code spürbar Fehler zu machen.

Wichtige Einschränkung: Bei quantisierungsbewusst trainierten Modellen — mehrere aktuelle Releases nutzen nativ 4-Bit-artige Formate — führt jede Faustregel in die Irre. Dort kann die tatsächliche Dateigröße um den Faktor zwei danebenliegen. Verlass dich auf die Größenangabe im Repository, nicht auf die Rechnung.

Backend einrichten

Ollama installieren

Für den Einstieg ist Ollama das komfortabelste Backend. Es kapselt llama.cpp, kümmert sich um Download und Speicherverwaltung und stellt einen lokalen Server bereit. Nach der Installation lädst du ein Modell mit einem Befehl, etwa ollama pull qwen2.5-coder:32b. Auf einem Linux-Homelab-Server lässt sich Ollama als Systemdienst einrichten, sodass er nach einem Neustart automatisch bereitsteht.

Wer mehr Kontrolle will — über KV-Cache, Flash Attention oder exakte Quantisierungsvarianten — nutzt llama.cpp direkt. Für den Anfang genügt Ollama.

Endpoint testen, bevor Claude Code ins Spiel kommt

Ollama läuft standardmäßig auf Port 11434 und bietet unter http://localhost:11434/v1/chat/completions eine OpenAI-kompatible API. Teste diesen Endpoint isoliert mit einem einfachen curl-Aufruf, bevor du weitergehst. Bekommst du eine sinnvolle Antwort, steht das Backend — und du weißt bei späteren Problemen, dass sie nicht dort liegen.

Betreibst du das Setup über das Netzwerk, setze OLLAMA_HOST=0.0.0.0:11434, damit der Dienst nicht nur auf localhost lauscht, und gib den Port im LAN frei.

Claude Code mit dem lokalen Endpoint verbinden

Die entscheidende Voraussetzung

Hier liegt der Punkt, an dem die meisten ersten Versuche scheitern — und er wird selten klar benannt: Der Endpoint muss das Anthropic-API-Format sprechen. Claude Code erwartet das Messages-Format; Ollama liefert von Haus aus das OpenAI-Format. Deshalb brauchst du entweder einen Übersetzungs-Proxy dazwischen oder ein Backend, das die Anthropic-API nativ bedient.

Der zweite Weg ist inzwischen die elegantere Lösung: vLLM etwa bietet eine dokumentierte Claude-Code-Integration und lässt sich direkt als Ziel eintragen. Wer ohnehin auf einem Linux-Server mit NVIDIA-Hardware arbeitet, spart sich damit den Proxy komplett.

Konfiguration über settings.json statt Shell-Export

Die Verbindung läuft über Umgebungsvariablen. Statt sie flüchtig im Shell-Profil zu setzen, ist der portable Weg ein env-Block in ~/.claude/settings.json — diese Konfiguration überlebt Shell-Wechsel und lässt sich im Team teilen. Relevant sind:

• ANTHROPIC_BASE_URL — zeigt statt auf Anthropics Cloud auf deinen lokalen Server.
• ANTHROPIC_AUTH_TOKEN — ein beliebiger Platzhalter, da der lokale Server keine echte Authentifizierung verlangt. Diese Variable setzt den Bearer-Token im Authorization-Header und ist nicht dasselbe wie ANTHROPIC_API_KEY.
• Die Modell-Zuweisungen — hier hat sich der Standard geändert: Statt einer einzelnen Modellvariablen weisen aktuelle Setups die Modell-Stufen einzeln zu, etwa über ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL und ANTHROPIC_DEFAULT_HAIKU_MODEL. Bei einem lokalen Setup trägst du dort schlicht überall denselben Modellnamen ein.

Der häufigste Folgefehler ist ein Modellname, der nicht mit dem geladenen Modell übereinstimmt, oder eine Base-URL mit falschem Pfad. Beides führt zu Fehlermeldungen, die schwer zu deuten sind — deshalb der isolierte Endpoint-Test vorher.

Ein Performance-Detail, das kaum jemand kennt

Claude Code fügt jeder Anfrage einen wechselnden Hash im System-Prompt hinzu. Für lokale Backends ist das ein Problem: Weil sich der Prompt bei jedem Aufruf ändert, greift das Prefix-Caching nicht mehr, und die Verarbeitung wird deutlich langsamer. Neuere vLLM-Versionen fangen das automatisch ab; bei älteren hilft der Eintrag "CLAUDE_CODE_ATTRIBUTION_HEADER": "0" im env-Block der settings.json. Wenn dein lokales Setup unerklärlich zäh wirkt, ist das ein lohnender Prüfpunkt.

Kontextfenster: die häufigste Abbruchursache

Der zweite kritische Punkt ist das Kontextfenster. Claude Code ist auf die großen Kontextlängen der Cloud-Modelle ausgelegt und füllt den Kontext mit Datei-Inhalten, Verlauf und Werkzeug-Ausgaben. Die Standard-Kontextlänge vieler Ollama-Modelle liegt dagegen nur bei 2.048 bis 4.096 Token — viel zu wenig.

Genau diese Context-Length-Falle ist die häufigste Ursache dafür, dass ein lokales Setup scheinbar grundlos abbricht oder Unsinn produziert. Erhöhe die Kontextlänge im Backend, etwa über OLLAMA_CONTEXT_LENGTH oder einen num_ctx-Parameter im Modelfile, so weit, wie dein VRAM es zulässt. Mehr Kontext kostet zusätzlichen Speicher — hier konkurrieren Modellgröße und Kontextlänge direkt miteinander.

Tool-Calling prüfen

Claude Code arbeitet agentisch und ruft Werkzeuge auf, um Dateien zu lesen, zu schreiben und Befehle auszuführen. Nicht jedes lokale Modell beherrscht das Format zuverlässig — und ob es funktioniert, hängt nicht nur am Modell, sondern auch am Chat-Template und am Parser der Laufzeit. Dieselbe Quantisierung kann sich unter zwei Backends unterschiedlich verhalten.

Teste das Tool-Calling deshalb an eigenen Beispielen, und zwar auf genau der Runtime, die du später nutzt. Ein Test auf einer anderen Plattform sagt darüber wenig aus. Bei anderen Modellen bricht der Agent-Workflow ab, obwohl der reine Chat gute Antworten liefert.

Performance optimieren und Grenzen kennen

Tokens pro Sekunde steigern

Flash Attention ist eine speichereffizientere Berechnung des Attention-Mechanismus und in llama.cpp wie Ollama aktivierbar. Die KV-Cache-Quantisierung senkt den Speicherbedarf pro Token und schafft Raum für längeren Kontext — wieder gegen ein wenig Qualität.

Der größte Hebel bleibt aber, das Modell vollständig im VRAM zu halten. Sobald Teile in den System-RAM ausgelagert werden, fällt die Geschwindigkeit drastisch. Lieber ein etwas kleineres oder stärker quantisiertes Modell wählen, das sicher hineinpasst. Welche Fehler beim Speicher am meisten Leistung kosten, steht in unserem Beitrag zu den fünf RAM-Fehlern bei lokalen KI-Modellen.

Typische Fehlerquellen

Praktische Handlungsempfehlungen August 2026

• Zuerst den Bedarf klären, dann Hardware kaufen. Wer nur gelegentlich Boilerplate generiert, fährt mit dem Cloud-Zugang günstiger. Eine 24-GB-Karte lohnt sich bei täglichem Dauereinsatz oder klaren Datenschutz-Vorgaben.
• Backend nach Format wählen, nicht nach Bequemlichkeit. Ein Anthropic-kompatibles Backend erspart dir den Übersetzungs-Proxy — das ist die größte Vereinfachung im ganzen Setup.
• Endpoint isoliert testen, bevor Claude Code ins Spiel kommt. Ein curl-Aufruf trennt Backend-Probleme sauber von Client-Problemen.
• Kontextlänge bewusst hochsetzen. Die Standardwerte sind zu klein; das behebt die häufigste Abbruchursache.
• Konfiguration in settings.json ablegen statt im Shell-Profil — portabel, teilbar und über Shell-Wechsel hinweg stabil.
• Bei zähem Verhalten den Attribution-Header prüfen. Das Prefix-Caching-Problem ist ein bekannter, leicht behebbarer Bremsklotz.
• Tool-Calling auf der Zielruntime testen, bevor du das Setup produktiv nutzt.
• Lizenz vor dem geschäftlichen Einsatz prüfen — beim Modell und bei der Quantisierung.

Fazit

Das lokale Setup funktioniert, aber es steht und fällt mit drei Details, die in den meisten Anleitungen fehlen: dem API-Format des Backends, der Kontextlänge und dem Tool-Calling. Wer diese drei vorab klärt, hat in einem Abend ein laufendes System. Wer sie überspringt, sucht tagelang.

Bei der Hardware bleibt die Rechnung unromantisch. 24 GB VRAM sind die sinnvolle Einstiegsklasse, Unified-Memory-Systeme bieten mehr Speicher bei geringerer Bandbreite, und keine dieser Optionen amortisiert sich bei gelegentlicher Nutzung. Der überzeugende Grund für lokal ist nicht der Preis, sondern die Datenhoheit.

Und der wichtigste Satz zum Schluss: Die Intelligenz kommt vom Modell. Claude Code lokal zu betreiben macht das CLI nicht schlechter — es macht nur sichtbar, wie viel von der gewohnten Qualität am Modell dahinter hängt.

Quellen und weiterführende Informationen

• Anthropic Claude Code Dokumentation (docs.claude.com/en/docs/claude-code/overview) — offizielle Referenz zu Konfiguration, Umgebungsvariablen und settings.json.
• vLLM-Projektdokumentation (docs.vllm.ai) — dokumentierte Claude-Code-Integration inklusive der Variablenbelegung und des Hinweises zum Attribution-Header und Prefix-Caching.
• Ollama (ollama.com und github.com/ollama/ollama) — Dokumentation zu Modellverwaltung, OLLAMA_HOST, Kontextlänge und OpenAI-kompatibler API.
• llama.cpp (github.com/ggml-org/llama.cpp) — GGUF-Format, Quantisierungsstufen, KV-Cache und Flash Attention.
• Hugging Face (huggingface.co) — Modellkarten mit tatsächlichen Dateigrößen je Quantisierungsstufe sowie den jeweiligen Lizenzbedingungen.
• NVIDIA und Apple — Herstellerangaben zu Speicherausstattung und Bandbreite der genannten Plattformen.

Haftungsausschluss

Allgemeiner Hinweis: Dieser Artikel auf aimageddon.de dient der allgemeinen Information rund um den Betrieb von Claude Code mit lokalen Sprachmodellen im Homelab. Er ersetzt keine individuelle technische oder rechtliche Beratung; passe alle beschriebenen Konfigurationen an deine eigene Infrastruktur an. Wir prüfen die beschriebenen Setups nicht in einem eigenen Labor, sondern werten offizielle Dokumentationen und öffentlich verfügbare Berichte aus. Software-Ökosysteme rund um lokale Sprachmodelle und die Nutzungsbedingungen der genannten Werkzeuge entwickeln sich schnell — einzelne Angaben können kurz nach Erscheinen überholt sein. Maßgeblich ist die jeweils aktuelle offizielle Dokumentation.

Zu Leistung, Modellen und Lizenzen: Lokale Sprachmodelle sind auf erhebliche Hardwareressourcen angewiesen; ob eine bestimmte Grafikkarte oder Speicherkonfiguration für deinen Anwendungsfall ausreicht, hängt von Modellgröße, Quantisierung, Kontextlänge und Backend ab. Genannte Größenordnungen sind Orientierung, keine garantierten Werte. Lokale Modelle erzeugen mitunter fehlerhafte oder unvollständige Ausgaben — prüfe generierte Inhalte kritisch, bevor du auf ihrer Grundlage Entscheidungen triffst oder sie weitergibst. Modelllizenzen und die Lizenzen von Community-Quantisierungen können voneinander abweichen und die kommerzielle Nutzung einschränken; prüfe beide im Original. Der Betrieb lokaler Modelle kann einen Datenschutzvorteil gegenüber Cloud-Diensten bieten, entbindet aber nicht von den Anforderungen der DSGVO beim Umgang mit personenbezogenen Daten.

Verbraucherrechte beim Hardwarekauf: Erwirbst du Hardware im Fernabsatz, steht dir nach § 312g BGB ein vierzehntägiges Widerrufsrecht zu; seit dem 19. Juni 2026 müssen Unternehmen dafür nach § 356a BGB eine elektronische Widerrufsfunktion bereitstellen. § 312k BGB verpflichtet Anbieter laufender Dienste — etwa Cloud-API-Zugänge — zu einer leicht zugänglichen Kündigungsschaltfläche. Bei Sachmängeln greifen §§ 437 und 438 BGB mit zweijähriger Frist, § 477 BGB kehrt in den ersten zwölf Monaten die Beweislast zugunsten der Käuferseite um, und die Verbrauchsgüterkauf-Richtlinie (EU) 2019/771 harmonisiert diese Rechte unionsweit. Für beworbene Preissenkungen gilt § 11 PAngV mit dem 30-Tage-Tiefstpreis; §§ 5, 5a und 5b UWG untersagen irreführende Angaben und die Verschleierung kommerzieller Inhalte.

Affiliate und Marken: Dieser Blog nimmt am Amazon-Partnerprogramm sowie am Awin-Netzwerk teil; entsprechend gekennzeichnete Links können beim Kauf zu einer Provision führen, ohne dass dir Mehrkosten entstehen. Die inhaltliche Einordnung bleibt davon unberührt. Alle genannten Markennamen sind eingetragene Warenzeichen der jeweiligen Inhaber und werden ausschließlich zur sachlichen Information verwendet.

👉 Homelab-KI-Server auf Amazon ansehen

👉 Mini-PC auf Amazon ansehen

👉 Desktop-GPU auf Amazon ansehen