Warum ich mir absichtlich Grenzen auferlege

Ich habe Claude API-Zugang. Claude Team. Ich laufe praktisch nie gegen ein Context-Limit, das mich wirklich bremst. 150.000 Tokens? Kein Problem. Parallele Sessions, lange Dokumente, verkettete Tool-Calls – ich merke das alles schlicht nicht, weil das System es einfach schluckt.

Das ist ein Luxus. Und wie die meisten Luxusgüter hat er einen versteckten Preis: Er macht blind.

Der Abend, an dem ich gegen eine Wand gelaufen bin

Ich habe mich letzte Woche hingesetzt und ein lokales LLM-Setup aufgebaut – LM Studio mit einem 35B-Parameter-Modell (MLX, 4bit, Apple Silicon), dahinter LibreChat als Frontend, dazu mein eigener MCP-Server für Agira und Zenico, meine selbst entwickelten Projektmanagement-Tools.

Nicht weil ich plane, Claude zu ersetzen. Sondern zur Evaluierung – für ein Kundenprojekt, bei dem lokale Inferenz eine Rolle spielen könnte.

Was passiert ist, war lehrreicher als erwartet.

Ich rufe list_projects auf. Mein Tool gibt wie gewohnt eine vollständige Projektliste zurück – inklusive aller Beschreibungen, Architektur-Notizen, Technologie-Stack-Dokumentation, Status-Felder, alles. So wie ich es immer gebaut hatte, weil es "einfach funktioniert".

Beim dritten verketteten Tool-Call fiel das System in eine generische Antwort zurück. Kein Fehler, keine Fehlermeldung. Einfach: "Hallo! Wie kann ich Ihnen helfen?"

Das Debug-Log hatte die Antwort: Der Prompt war auf 108.707 Tokens angewachsen. Die Engine hatte 95.587 Tokens aus der Mitte entfernt – darunter meine ursprüngliche Frage.

Was das eigentlich war

Kein Bug in LM Studio. Kein Konfigurationsfehler. Physik.

Ein 35B-Modell auf einem MacBook Pro mit 48 GB Unified Memory verbraucht ~20 GB allein für die Modellgewichte. Der KV-Cache für den Context kommt obendrauf. Irgendwo bei 32k Tokens ist Schluss, danach beginnt die Engine zu truncaten.

Das Interessante war nicht das technische Problem selbst. Das Interessante war, was das sichtbar gemacht hat.

Mein list_projects-Tool gibt für jedes Projekt die vollständige description zurück – ein Markdown-Block mit Architektur-Konzept, Technologie-Stack, Datenmodell-Beschreibung. Das ist für einen einzelnen Projektaufruf in Claude Chat völlig unsichtbar: 8.000 Tokens hier, 12.000 dort, Cloud schluckt es, fertig.

Lokal, mit einem 32k-Fenster und drei verketteten Calls, zerschießt es mir den gesamten Kontext.

Die eigentliche Erkenntnis

Das Tool war falsch designed. Nicht kaputt – falsch designed. Und das war mir nie aufgefallen, weil mir nie jemand eine Rechnung präsentiert hat.

list_projects für eine Übersicht braucht: id, name, status, progress. Fertig. Vier Felder.

get_project_details für einen konkreten Drill-Down braucht: alles.

Das ist kein Hexenwerk. Das ist Standard-API-Design, das ich bei jedem REST-Service selbstverständlich anwende. Bei meinen eigenen MCP-Tools hatte ich es schlicht vergessen – weil es nie wehgetan hat.

Warum das für Skalierung relevant ist

Ich baue derzeit Systeme, die irgendwann nicht für mich allein laufen, sondern für Organisationen mit 350 Nutzern.

Bei 350 Nutzern mit durchschnittlich 5–10 Tool-Calls pro Tag, von denen jeder unnötigerweise 8.000–12.000 Tokens für Context lädt, den niemand braucht: Das ist keine theoretische Kostenoptimierung mehr. Das ist die Differenz zwischen einem akzeptablen und einem nicht akzeptablen Monatsbudget – realistisch im vierstelligen Bereich.

Großzügige Flatrate-Zugänge verschleiern diese Strukturfehler vollständig. Bis jemand anderes die Rechnung bekommt.

Was lokale Modelle tatsächlich leisten – und was nicht

Zur Klarheit: Ein lokales 35B-Modell auf einem MacBook Pro ist kein Claude-Ersatz. Es ist nicht mal annähernd konkurrenzfähig, wenn man gewohnt ist, mit 150k-Token-Kontexten zu arbeiten. Die Hardware-Physik ist eindeutig.

Aber das war auch nie der Punkt.

Lokale Modelle als Evaluierungsumgebung sind eine andere Sache. Sie zwingen zur Konfrontation mit Kosten, die sonst unsichtbar bleiben. Sie machen Designfehler spürbar, die im Cloud-Kontext nie auffallen. Und sie liefern fundierte Grundlagen für Kundenberatung – nicht aus der Theorie, sondern aus dem direkten Erleben: "Ich habe das selbst aufgebaut, ich weiß genau, wo die Grenzen sind und warum."

Für eine Organisation mit moderaten Anforderungen kann ein lokales Setup mit einem 14B-Modell vollkommen ausreichend sein. Für dieselbe Organisation mit schlecht designten Tools, die unkomprimierte Payloads zurückwerfen, wird es das nie sein – egal wie viel RAM im Gerät steckt.

Der Unterschied liegt nicht in der Hardware. Er liegt im Design.

Fazit

Ich bin verwöhnt. Das ist keine Beschwerde.

Aber verwöhnt zu sein bedeutet auch: man stellt bestimmte Fragen schlicht nicht, weil die Antwort nie relevant war. "Brauche ich hier wirklich alle Felder?" ist eine Frage, die mir im Cloud-Betrieb nie in den Sinn gekommen wäre.

Das lokale Setup hat sie erzwungen. Und das war den Aufwand wert – nicht trotz der Einschränkungen, sondern wegen ihnen.

Manchmal ist die wertvollste Umgebung nicht die komfortabelste.