Warum überhaupt lokal
Die Cloud-APIs sind ausgezeichnet und werden immer günstiger. Das Argument für lokale Modelle lautet also nicht „billigere Tokens“. Es sind drei andere Dinge.
Die Daten bleiben, wo sie sind. Quellcode, Kundentickets, Verträge, medizinische oder finanzielle Daten: Für viele europäische Teams lautet die Frage nicht, ob ein Anbieter vertrauenswürdig ist, sondern ob die Daten das Haus überhaupt verlassen dürfen. Ein Modell auf eigener Hardware macht aus einer Compliance-Diskussion ein Nicht-Thema.
Die Kosten werden flach. Ein Agent, der das Repository liest, Tests ausführt und Dateien umschreibt, verbrennt Tokens in Millionen. Bei einer abgerechneten API ist das ein variabler Posten, den man überwachen muss. Auf einer Karte, die man ohnehin besitzt, ist es Strom.
Die Latenz gehört einem selbst. Klassifikation, Routing, Extraktion und „ist dieses Ticket dringend“-Aufrufe sind klein und häufig. Lokal bedient antworten sie in zweistelligen Millisekunden und stehen nie hinter fremdem Traffic in der Schlange.
Das ehrliche Gegengewicht: Die besten frei verfügbaren Modelle liegen bei schwerem Schlussfolgern hinter der Spitze, und eine einzelne GPU hat eine harte Durchsatzgrenze. Lokale KI ist ein Werkzeug für eine bestimmte Klasse von Arbeit, kein Ersatz für alles.
Wie ein vernünftiger Aufbau aussieht
Man braucht keinen Cluster. Eine Maschine mit moderner GPU und 24 bis 48 GB VRAM deckt erstaunlich viel ab. Bei uns läuft darauf ein Inferenz-Server mit OpenAI-kompatiblem Endpunkt, sodass jedes Werkzeug, das mit OpenAI spricht, durch Ändern einer einzigen URL dorthin zeigen kann.
- Ein allgemeines Modell der 27B-Klasse für Coding-Agenten, Entwürfe und alles, was Urteilsvermögen braucht. Das ist das Arbeitstier, und es bleibt geladen.
- Ein kleines, schnelles Modell (8B oder kleiner) für Klassifikation, Routing und strukturierte Extraktion, wo Tempo wichtiger ist als Tiefe.
- Ein Embedding-Modell für die Suche über Dokumentation, Tickets und Notizen.
- Coding-Agenten auf der Kommandozeile, an den lokalen Endpunkt gebunden. Wir haben dasselbe Agenten-Setup auf ein Dutzend Maschinen ausgerollt und jede einzelne mit einer echten Prompt-Antwort-Runde belegt – nicht mit einer Konfigurationsdatei, die richtig aussah.
Das ist die ganze Architektur. Alles Weitere handelt davon, was passiert, sobald echte Last darauf trifft.
Was die Hardware tatsächlich liefert
Zuerst die Zahlen, denn „schnell genug“ ist keine Zahl. Unsere Inferenz-Maschine läuft mit zwei Consumer-Karten RTX 3090 (2 × 24 GB). Gemessen am 2. September 2026 mit den Zählern der Laufzeit selbst, nicht mit der Stoppuhr:
- Modell der 27B-Klasse, 4-Bit-quantisiert, dauerhaft geladen mit 262k Kontextfenster: 52 bis 59 Tokens pro Sekunde erzeugter Text bei kurzem Prompt. Das ist schneller, als die meisten Menschen lesen, und für einen interaktiven Coding-Agenten bequem schnell.
- Prompt-Verarbeitung desselben Modells: rund 940 Tokens pro Sekunde bei einem Prompt von 1.600 Tokens. Ein Repository-Auszug von 20.000 Tokens ist in etwa zwanzig Sekunden verdaut, bevor das erste Antwort-Token erscheint.
- Speicher: dieses geladene Modell belegt 24,5 GB VRAM, verteilt über beide Karten, der Großteil davon reserviert für das überdimensionierte Kontextfenster (siehe Lektion 02).
Dieselbe Messrunde lieferte eine ungeplante Vorführung von Lektion 01: Als wir neben dem geladenen 27B-Modell ein kleines 8B-Modell messen wollten, fand die Laufzeit dafür nur noch 3 GB freien VRAM, lagerte den Rest in den Hauptspeicher aus, und der Benchmark lief nach vier Minuten in den Timeout. Das große Modell hat davon nichts gemerkt. Das kleine war unbenutzbar. Nirgends im Protokoll stand „Verdrängung“.
Jede Lektion auf dieser Liste wurde durch Messen gelernt, nicht durch Lesen eines Datenblatts. Der Aufbau, der „funktionieren müsste“, und der, der es tut, sind selten derselbe.
VRAM ist ein gemeinsames Budget, und es warnt nicht
Lädt man ein 27B-Modell neben ein paar kleinen, verdrängt die Laufzeit die kleinen still in den CPU-Speicher, sobald das große den Platz braucht. Nichts schlägt fehl. Die kleinen Modelle fallen nur von hunderten Tokens pro Sekunde auf etwa 0,2, und jeder Aufruf, der von ihnen abhing, läuft zehn Sekunden später in einen Timeout. Beim ersten Mal sah das aus wie ein Netzwerkproblem.
Die Lösung ist unspektakulär: festlegen, welches Modell das warme ist, es fixieren, einen Watchdog auf die Laufzeit setzen, der prüft, was tatsächlich im Speicher liegt, und große Batch-Jobs so planen, dass sie nicht mit interaktiver Nutzung kollidieren. VRAM behandelt man wie einen Verbindungs-Pool einer Produktionsdatenbank.
Das Kontextfenster richtig dimensionieren – oder bei jedem Aufruf dafür zahlen
Moderne Modelle werben mit riesigen Kontextfenstern, und die Werkzeuge konfigurieren sie bereitwillig als Standard. Wir haben einen Agenten mit 262.000 Token Kontext betrieben, weil das die Zahl im Model-Card war. Die Kürzung auf 64.000, immer noch weit mehr, als die Last brauchte, machte den Prefill 86 Prozent schneller. Das Modell wurde nicht schlechter. Es hörte nur auf, Speicher und Rechenzeit für ein Fenster zu reservieren, das niemand füllte.
Den Kontext pro Anwendungsfall setzen. Ein Router braucht ein paar tausend Token. Ein Coding-Agent braucht zehntausende. Fast nichts braucht das Maximum.
Clients kennen die Grenze nicht, also wird still abgeschnitten
Verwandt und gemeiner: Die meisten Client-Werkzeuge fragen den Server nicht nach dem Kontextlimit. Wächst ein Gespräch darüber hinaus, wird der Prompt vorne abgeschnitten, und das Modell verliert genau den Teil, der die Systemanweisungen trug. Der Agent wirft keinen Fehler. Er verhält sich, als hätte man ihm die Regeln nie gesagt.
Das Limit dort durchsetzen, wo man es sieht, am Gateway oder im Agenten-Harness, und Prompt-Größen protokollieren. Eine Kurve der Tokens pro Anfrage über die Zeit verrät dieses Problem Tage, bevor ein Nutzer es tut.
Beim Empfänger prüfen, nie beim Sender
Ein Rollout über viele Maschinen bietet viele Gelegenheiten, falsch zu liegen: eine alte Node-Laufzeit, die das Agenten-CLI stillschweigend ablehnt, eine Umgebungsvariable, die gesetzt, aber nicht exportiert wurde, ein Hostname, der auf einem Host anders auflöst. Der einzige Rollout-Status, dem wir trauen, ist eine erfolgreiche Prompt-Antwort auf jeder Maschine, mit Zeitstempel festgehalten. Konfiguration, die „angewendet wurde“, ist eine Absicht, kein Zustand.
Hybride Suche schlägt reine Vektoren, und sie ist günstiger
Für die Suche über interne Dokumentation kombinieren wir klassische Stichwortsuche (BM25) mit Embeddings und verschmelzen die beiden Rankings. Verglichen damit, ganze Dokumente in Prompts zu kippen, hat das die Tokens pro Antwort um rund 60 Prozent gesenkt und dabei bessere Passagen geliefert – weil exakte Bezeichner, Hostnamen und Fehlermeldungen Dinge sind, die Stichwortsuche findet und Embeddings verwischen.
Die Schwachstelle kennen: Retrieval ist gut bei „wo wird X beschrieben“ und schlecht bei „wo fehlt X“. Abwesenheit ist keine Passage, die man ranken kann.
Früh entscheiden, ob man ein Gateway will
Sobald drei Teams und ein Dutzend Werkzeuge mit denselben Modellen sprechen, steht eine Wahl an: ein zentrales KI-Gateway, das Routing, Schlüssel, Rate-Limits und Protokollierung übernimmt, oder überall direkte Endpunkte. Beides funktioniert. Was nicht funktioniert, ist in das Zweite hineinzudriften und später festzustellen, dass niemand sagen kann, welches Werkzeug welchen Prompt geschickt hat. Die Entscheidung treffen, solange sie noch billig ist.
Wann lokal das falsche Werkzeug ist
Ehrlich mit den Grenzen umgehen. Zum Spitzenmodell greifen, wenn die Aufgabe tiefes, mehrstufiges Schlussfolgern braucht, wenn hunderte gleichzeitige Nutzer bedient werden müssen, oder wenn niemand im Team um zwei Uhr nachts eine GPU-Kiste betreiben sollte. Das Muster, das bei uns am besten funktioniert, ist nicht „lokal oder Cloud“, sondern lokal zuerst, Cloud für die schweren zehn Prozent – mit aufgeschriebener Routing-Regel und einer expliziten Datengrenze für beide Wege.
Eine Checkliste vor dem Start
- Welche Daten dürfen das Netz nie verlassen? Aufschreiben; das entscheidet die Architektur.
- Welche drei Workloads rechtfertigen die Hardware heute? Keine Vision, drei konkrete Aufgaben.
- Wer betreibt die Maschine, inklusive Updates, Monitoring und dem Anruf um zwei Uhr nachts?
- Wie lautet die gemessene Basis: Tokens pro Sekunde, Prefill-Zeit, Speicher pro Modell?
- Wie fällt stilles Abschneiden, Modell-Verdrängung und Drift auf?
- Wo verläuft die Grenze zur Cloud, und wer darf sie überschreiten?
Sie denken über Modelle im eigenen Haus nach?
Wir helfen Teams, die Hardware zu dimensionieren, Modelle auszuwählen, Agenten und Suche in bestehende Produkte zu verdrahten und das Monitoring aufzusetzen, das das Ganze ehrlich hält. Hands-on, mit funktionierendem Code am Ende.
Gespräch anfragen →