KI-Coding-Assistenten: Warum klassisches LLM-Hosting nicht mehr ausreicht

Die Schlacht der KI-Coding-Assistenten ist in eine neue Runde gegangen. Mit Claude Code, Codex und Gemini CLI haben Entwickler weltweit echte Erfahrungen gesammelt. Die Frage ist nicht mehr, ob diese Tools funktionieren – sondern wie man sie skalierbar betreibt, ohne dabei das Budget zu sprengen oder Latenzzeiten zu produzieren, die Entwickler zur Weißglut treiben.

Ein aktuelles Forschungsprojekt der University of Washington liefert jetzt handfeste Daten. Die Ergebnisse dürften viele überraschen: Eure bestehende LLM-Serving-Infrastruktur ist höchstwahrscheinlich nicht für diese Workloads optimiert.

Warum Coding-Agents anders funktionieren

Das klingt trivial, aber es muss trotzdem gesagt werden: Coding-Agents beantworten keine Fragen. Sie führen Pläne aus. Wenn Du einen KI-Assistenten bittest, ein Feature zu implementieren oder einen Bug zu fixen, startest Du einen autonomen Workflow. Das Modell denkt nach, führt Shell-Befehle aus, liest und modifiziert Dateien, führt Tests durch und iteriert – solange, bis es zufrieden ist oder bis Du abbrichst.

Die Forschenden haben über 4.300 reale Nutzungssitzungen analysiert, insgesamt etwa 55 Milliarden Tokens. Die Muster sind bemerkenswert. Jede Nutzeranfrage löst im Schnitt 8,8 LLM-Tool-Zyklen aus. Für jede Frage eines Entwicklers gibt es also fast neun Runden, in denen das Modell generiert und dann Tools ausführt. Das Modell redet nicht nur – es arbeitet.

Und hier wird es richtig interessant: 88 Prozent aller LLM-Inferenzrunden entstehen nicht durch Nutzereingaben, sondern durch Tool-Ergebnisse. Das hat gewaltige Auswirkungen auf die Throughput-Planung. Traditionelle Chatbots funktionieren nach dem Frage-Antwort-Prinzip mit gelegentlichen Nachfragen. Coding-Agents sind dagegen langlebige, autonome Prozesse mit häufigem Kontextwechsel zwischen Generierung und Ausführung.

Das Cache-Problem, das niemand kommen sah

Eine Zahl, die jeden Infrastructure Engineer aufhorchen lassen sollte: Inputs überwiegen Outputs im Verhältnis 294:1. In den analysierten Traces lasen die Modelle 52,56 Milliarden gecachte Input-Tokens und prefillten 2,34 Milliarden neue. Die generierten Output-Tokens beliefen sich jedoch nur auf 186,9 Millionen.

Ein typischer Zyklus arbeitet auf einem 32K- bis 256K-Token-Präfix und fügt nur wenige Hundert bis wenige Tausend Tokens hinzu, bevor ein paar Hundert dekodiert werden.

Das erzeugt ein völlig anderes Performance-Profil. Traditionelle Sprachmodell-Inferenz konzentriert sich auf Generation-Throughput – wie viele Tokens pro Sekunde können wir produzieren? Bei Coding-Agents ist der Flaschenhals aber oft nicht die Dekodiergeschwindigkeit. Es geht um Time-to-First-Token nach Tool-Ausführung.

Das Team fand heraus, dass Codex' TTFT für jeden Schritt bei etwa 3,1 Sekunden liegt. Das sind rund 25 Prozent der gesamten Generierungszeit eines Zyklus. Bei neun Runden pro Anfrage summiert sich das schnell.

Auch das Caching ist komplexer als gedacht. Input-Caching hilft bei den massiven Kontexten, die Coding-Agents mitschleppen. Aber die Prefill-Workload teilt sich zwischen gecachten und neuen Tokens, die echte Berechnung brauchen. Kurze, inkrementelle Prefills nach Tool-Ausführung haben andere Performance-Charakteristika als der initiale Long-Context-Load. Serving-Systeme müssen beides effizient handhaben.

Shell-Befehle sind immer noch der Boss

Wenn Du dachtest, Coding-Agents würden hauptsächlich komplexe Refactorings und ausgefeiltes Reasoning betreiben – naja, nicht ganz. Von den 433.000 Tool-Aufrufen in den Traces waren 76 Prozent Shell- oder Kommandoausführungen. Builds starten, Tests laufen lassen, Git-Operationen, Dateimanipulationen über CLI-Tools. Das un Glamouröse, das den tatsächlichen Entwicklungsalltag ausmacht.

Datei-Änderungen kamen auf 11 Prozent, Datei-Lesezugriffe und Suchen auf 9 Prozent. Planung, Sub-Agent-Delegation und Web-Lookups bildeten den Rest.

Diese Konzentration auf Shell-Befehle hat mehrere Konsequenzen. Erstens sind das langschwanzige Operationen: Ein einfaches ls ist schnell, aber eine vollständige Test-Suite oder das Kompilieren eines großen Codebase kann Minuten dauern. Die Latenzverteilung erstreckt sich über vier Größenordnungen. Capacity Planning wird dadurch zum Albtraum.

Zweitens variiert das Tool-Vokabular zwischen Agents. Claude Code nutzte 54 verschiedene Tools, Codex 31. Beide konzentrierten aber den Großteil ihres Volumens auf dieselben Kern-Tools – Shell, Dateiänderungen, Dateilesen. Das deutet darauf hin, dass die Optimierung für diese Hochfrequenz-Tools überproportionale Verbesserungen bringen könnte.

Was das für Deine Infrastruktur bedeutet

Wenn Du AI-gestützte Entwicklungstools baust oder betreibst, liefert diese Forschung mehrere konkrete Ansatzpunkte.

Denke in Workflows, nicht in Requests. Deine Serving-Infrastruktur muss die autonome, mehrstufige Natur von Coding-Agents berücksichtigen. Das bedeutet länger laufende Request-Kontexte, ausgefeilteres State-Management und Batch-Scheduling, das zusammenhängende Tool-Aufrufe gruppiert.

Optimiere für die Leerlaufzeiten. Nutzer verbringen durchschnittlich 46,7 Minuten zwischen Anfragen, obwohl die mediane Denkzeit nur 1,4 Minuten beträgt. Die Verteilung ist extrem heavy-tailed – manche Entwickler iterieren schnell, andere starten eine Anfrage und kommen Stunden später zurück. Schlaue Prefetching- und Re-Prefill-Strategien während dieser Leerlaufzeiten könnten die wahrgenommene Latenz drastisch reduzieren, ohne die Compute-Kosten zu erhöhen.

Trenne Prefill und Decode. Das 294:1-Verhältnis bedeutet, dass Deine Prefill-Berechnung wahrscheinlich Deine dominanten Kosten verursacht. Inkrementelle Prefills nach Tool-Ausführung brauchen andere Optimierungen als initialer Kontext-Load. Erwäge separate Resource-Pools oder Scheduling-Policies für diese unterschiedlichen Workload-Typen.

Vergiss die Tool-Ausführungs-Infrastruktur nicht. Wenn 76 Prozent der Agent-Aktivität Shell-Befehle sind, werden Container-Orchestrierung, Filesystem-Zugriffsmuster und Build-Tool-Caching zu erstklassigen Anliegen für das AI-Agent-Serving. Die Modell-Inferenz ist nur ein Teil der Pipeline.

Blick nach vorn

Das TraceLab-Team hat ihre Trace-Sammlung und Analyse-Pipeline als Open Source veröffentlicht. Infrastructure-Teams können jetzt eigene Traces generieren und für echte Nutzungsmuster optimieren – statt für synthetische Benchmarks. Solche Realwelt-Daten sind genau das, was der AI-Infrastruktur-Bereich braucht, während er sich von "mach es irgendwie" zu "mach es skalierbar" weiterentwickelt.

Für die NameOcean Vibe Hosting Community zeigen diese Erkenntnisse, warum wir in Infrastruktur investieren, die über einfache GPU-Zuweisung hinausgeht. KI-Coding-Assistenten zu betreiben ist nicht nur eine Frage roher Rechenleistung – es geht darum, die einzigartigen Eigenschaften agentischer Workloads zu verstehen und Systeme zu bauen, die mit der autonomen, mehrstufigen, tool-lastigen Realität umgehen können.

Die Ära der Coding-Agents hat gerade erst begonnen. Die Infrastruktur-Entscheidungen, die wir heute treffen, werden bestimmen, wie effizient diese Tools Entwickler in den kommenden Jahren unterstützen.