Der Großteil der Diskussion über lokale LLMs 2026 dreht sich um ihren Einsatz für Chat-Zwecke — eine Datenschutzalternative zu Cloud-Assistenten. Das ist ein valides Use-Case. Es ist nicht der, der mein Engineering im letzten Jahr geprägt hat. Mein lokaler LLM-Stack — Ollama + llama.cpp + vLLM + Open WebUI + ein paar unterstützende Teile — ist in meine eigentliche Engineering-Pipeline verdrahtet, zusammen mit Postgres und Redis, und macht echte Arbeit an echten Tasks, die sonst API-Credits kosten würden oder gratis wären, aber mit schlechterer Qualität liefern.

Die Form des Stacks

Die Architektur ist weniger exotisch als sie klingt:

  • Ollama ist der tägliche Treiber. Läuft auf der GPU meines Homelabs, exponiert eine OpenAI-kompatible API und bedient jeden lokal gerouteten Inference-Request, den ich beim Coden und Skripten mache. Modelle werden on demand gepullt; eine Handvoll bleibt heiß. Das Interface ist so einfach, dass die meisten meiner Tool-Integrationen es als “einen weiteren OpenAI-Endpoint, mit einer anderen Base-URL” behandeln.
  • llama.cpp ist der CPU-Klassen-Fallback. Wenn ich auf einem Laptop ohne GPU- Zugang bin oder wenn ich ein kleines Modell für einen geskripteten Task laufen will, bei dem Latency kein Problem ist, läuft llama.cpp. Die Überschneidung mit Ollama ist absichtlich — llama.cpp ist lower-level, und ich benutze es, wenn ich präzise Kontrolle über Quantisierung, Context-Length oder Sampling-Parameter will.
  • vLLM ist die Serving-Schicht für alles, was echten Durchsatz will. Batch- Inference-Tasks, Evaluation-Runs, synthetische Datengenerierung für Tests — vLLM macht sie in einem Bruchteil der Wall-Time, die Ollama brauchen würde, weil das seine Optimierung ist.
  • Open WebUI ist die menschenzugewandte Oberfläche. Wenn ich mit einem lokalen Modell chatten, Outputs nebeneinander vergleichen oder eine Multi-Turn-Konversation führen will, die zu lässig für ein Script ist, gehe ich dahin.
  • LM Studio und Jan füllen gelegentlich ähnliche Lücken; ich halte sie installiert, benutze sie aber seltener als die obigen.

Das Ganze sitzt auf einem Homelab-Rechner mit einer GPU, die weniger kostet als ein Monat API-Ausgaben. Die Wirtschaftlichkeit kehrt sich schnell um, wenn man echtes Inference-Volumen betreibt.

Wofür ich es tatsächlich benutze

Die Tasks, die einen permanenten Slot im lokalen Stack verdient haben, in ungefähr der Reihenfolge, in der sie feuern:

1. Review-Pre-Pass auf Commits

Vor jedem substantiellen Commit führt ein lokales Modell einen strukturierten Review- Pass durch: “Lies das Diff, liste alles auf, was seltsam aussieht, bewerte nach Schweregrad.” Das Ziel ist nicht, Review zu ersetzen — es ist, die offensichtlichen Dinge zu fangen, bevor ich den PR öffne, damit menschliches Review nicht mit stilistischen Fehlern oder fehlendem Error-Handling verbracht wird. Das lokal zu betreiben ist kostenlos; es auf einer Cloud-API für jeden Commit zu betreiben wäre teuer und langsamer.

2. Synthetische Daten für Tests

Unit-Tests brauchen oft erfundene Payloads: User-Records, Produktkataloge, Log- Zeilen, Event-Shapes. Ein lokales Modell generiert diese günstig, deterministisch mit einem Seed, und ohne Daten an einen Drittanbieter-Service zu schicken. Ich pflege Seed-Skripte im Test-Tree neben den Fixtures, die sie produzieren.

3. Code-Erklärung

Wenn ich eine unbekannte Codebase erkunde — ein fremdes OSS-Projekt, ein neues Framework — gibt mir ein lokales Modell einen ersten Pass von “was macht diese Datei, auf Deutsch.” Es ist nicht autoritativ; es ist eine Ausgangskarte. Ich lese dann den Code und korrigiere mein mentales Modell, wo das LLM falsch lag. Die Kombination ist schneller als beides allein.

4. Doc-Drafts

Einen README, ein Runbook oder einen Post-Mortem zu schreiben beginnt meistens mit einem strukturierten Prompt und einer First-Draft-Generierung, gefolgt von erheblicher menschlicher Bearbeitung. Das lokale Modell bringt mich in Sekunden über das Blank- Page-Problem hinaus; die Bearbeitung ist der Ort, wo ich die Urheberschaft verdiene. Dieser Post hat so angefangen.

5. Research-Destillation

Ich füttere dem Modell eine Reihe von Bookmarks oder Links und bitte um eine Synthese. Die Synthese ist selten gut genug, um direkt darauf zu handeln — aber oft gut genug, um zu wissen, welche drei Links es wert sind, vollständig zu lesen. Das ist das günstigste Research-Priorisierungs-Tool, das ich je hatte.

Was es nicht gut macht

Ein paar Kategorien, in denen lokale Modelle noch immer den Cloud-Frontier verlieren — und das ist nicht knapp:

  • Long-Horizon-Reasoning-Tasks. Die größeren Frontier-Modelle sind wirklich besser darin, einen komplexen Multi-Step-Plan zu halten. Lokale 70B+-Modelle können das annähern; lokale 30B-Modelle können es nicht wirklich.
  • Schreiben in mehreren Sprachen mit konsistenter Stimme. Lokale Modelle tendieren dazu, die Stimme über Übersetzungen hinweg zu glätten. Die Flagship-Cloud-Modelle bewahren sie besser. (Das ist sehr relevant für die dreisprachige Version genau dieser Site.)
  • Code-Generierung auf unbekannten Frameworks. Frontier-Modelle haben mehr vom Long-Tail gesehen. Lokale Modelle, die auf älteren Snapshots trainiert sind, können bei z.B. Astro-6-Konventionen stolpern.

Der richtige Split ist: Benutze den lokalen Stack für hochvolumige, low-horizon, kostensensitive Tasks. Benutze die Frontier-API für Tiefe und Neuheit. Die meisten Engineering-Teams 2026 nutzen eines oder das andere. Beide zu betreiben, absichtlich, mit dem richtigen Split, ist der echte Unlock.

Die Kosten-Kalkulation

Ein grober Monat meiner Nutzung:

  • Lokaler Inference: Tausende von Requests. Stromkosten: trivial. GPU-Abschreibung: bedeutsam, aber über ein Jahr oder mehr amortisiert.
  • Cloud-Frontier-API: Dutzende bis Hunderte von Requests, meistens die “wirklich harten”. Kosten: bedeutsam, aber begrenzt.

Ohne den lokalen Stack würden die Cloud-Ausgaben 10–30× höher sein. Mit ihm sind die Cloud-Ausgaben für Dinge, bei denen diese Ausgaben klar ihren Wert erbringen. Das ist die Art von Zweischicht-Muster, das im Nachhinein offensichtlich wirken wird — und das gerade von den meisten Teams verschlafen wird.

Die Fulcrum-Verbindung

Ein guter Teil meiner lokalen Stack-Nutzung läuft durch meine eigene Agent- Control-Plane (Fulcrum). Agent-Runs, die schnelles Feedback brauchen, werden zu lokalen Modellen geroutet; solche, die Tiefe brauchen, werden zur Cloud geroutet. Die Routing-Policy ist in der Control-Plane, nicht in einzelnen Tools — was bedeutet, dass die “welches Modell?”-Frage einmal, per Konfiguration, gelöst wird statt pro Task neu gelernt zu werden.

Wenn du deinen eigenen lokalen Stack 2026 aufbaust, ist das Ding, das du zuerst bauen solltest, nicht die Inference-Schicht — das ist einfach, Ollama erledigt es. Baue die Routing-Schicht: das Ding, das pro Task entscheidet, welches Modell aufzurufen ist. Da lebt die Engineering-Disziplin. Da kommen die 10×-Kosteneinsparungen her. Das ist das Ding, über das noch niemand redet — und das das Ding sein wird, das in 18 Monaten am meisten zählt.