261 Euro eigene KI-Strecke statt 7.640 Euro API — ein Monat Agentenbetrieb

Wer gerade über agentische Coding-Modelle schreibt, tut das gern in Superlativen. Jemand postete neulich „900 Token pro Sekunde" und ein paar Sätze über Souveränität darüber. Die Zahl ist nicht falsch, sie ist nur eine andere Rechnung als die, die uns interessiert: Sie zählt das Aggregat über drei parallele Agents, auf einem Modell mit deutlich weniger aktiven Parametern je Token.

Uns interessiert die Frage dahinter: Was läuft bei uns wirklich über so eine Strecke, was für Tokens sind das, und was kostet der Monat? Wir haben einen Tag-production mitgeschnitten statt ein Rechenbeispiel zu erfinden. Alle Zahlen hier stammen aus den Spend-Logs unseres Gateways, den Zählern der Inferenz-Engine und dem Harness selbst — Messfenster jeweils dazugeschrieben.

Die Strecke: Agenten oben, Modell im Haus

Drei Arten von Konsumenten hängen an derselben Strecke:

• Windows-Server mit VS Code. Auf der ERP-Box läuft DeepSeek Harness als VS-Code-Extension, und zwar direkt auf dem Windows Server: Die Extension meldet extensionKind: ["workspace"], läuft also im Remote-Extension-Host und braucht den Zielrechner — ein win32-x64-VSIX auf dem Server, nicht auf dem Laptop. Wichtig am Mechanismus: Die Extension hat keinen eigenen Modellzugang, sie zeigt mit dem Provider-Slug litellm auf unser hausinternes Gateway (dsh und vision, Kapazität von Hand auf 245.760 / 16.384 gesetzt, weil die Kontext-Tabelle der Extension unser Modell nicht kennt). Kein Modell, kein Cloud-Key, keine Belege nach außen — außer man vergibt den Provider-Switch: Bleibt die Kopfzeile des Panels auf deepseek-official, geht der Request tatsächlich zu api.deepseek.com, samt Key und Prompt. Sichtbar wird das als „Authentication Fails", und nur deshalb ist es eine Fehlermeldung, die wir bekommen wollen.
• Der Browser. Dieselbe Harness gibt es als Web-Oberfläche — Terminaleingaben, Dateibearbeitung, Kanban, Token-Nutzung, alles im Browser, davor ein Keycloak-Login. Von dort geht der Agent per SSH in die Firma: 59 Hosts in der SSH-Config, Proxmox, Unifi, Backup, Mail, Datenbanken, die GPU-Boxen. Genau das ist der Arbeitsmodus, den vor zwei Jahren niemand einem lokalen Modell zugetraut hätte.
• Geplante Läufe. Nachtlauf, Wochenlauf, Audit-Läufe, Belegextraktion, Sentiment-Scorer. Alle über dasselbe Gateway, damit man später sehen kann, wer was verbraucht hat.

Zwischen allen Konsumenten steht ein LiteLLM-Gateway. Nicht aus Sentiment, sondern aus zwei harten Gründen: vLLM kann keine Zuordnung pro Konsument (nur engine-weite Zähler), und ohne Gateway gibt es keinen Grund, pro Tool einen eigenen Key zu ziehen. Der Router läuft absichtlich nur auf Loopback, die öffentliche Seite ist ein kleiner Auto-Router davor. Unbekannte Modellnamen scheitern seit einem halben Jahr laut — die Wildcard-Lane, die früher auf jeden erfundenen Namen mit HTTP 200 geantwortet hat, ist raus. In den Logs standen danach wochenlang Anfragen wie gpt-4o und lane-that-does-not-exist von Tools, die sich Namen ausgedacht haben.

# LiteLLM, gekürzt — eine Lane, dazu die Kappen, die der Harness respektiert
- model_name: dsh
  litellm_params:
    model: openai/flashnext-hybrid
    api_base: http://<gpu-host>:8000/v1
    api_key: <gateway-key>
    drop_params: true
  model_info:
    max_input_tokens: 245760
    max_output_tokens: 16384

Das Modell und was die vier Karten wirklich tun

Produktiv läuft Qwen3.8-Flash-Next als Hybrid-Checkpoint: ein Mixtral-artiges MoE mit 125 Milliarden Parametern und rund 6 aktiven je Token, dazu eine 51-Milliarden-N-Gram-Embedding-Tabelle (PLE), die im CPU-RAM ausgelagert ist, weil 47 GiB nicht in vier Verbraucherkarten passen. Die Experten sind NVFP4 quantisiert — sm_120 kann das nativ, und unser Abbild erzwingt den Native-FP4-MoE-Kernel über --moe-backend flashinfer_cutlass. Diesen Flag nicht „aufräumen": Die automatische Backend-Wahl von vLLM kennt SM120 für NVFP4 nicht und würde still auf Marlin zurückfallen.

# Start auf der GPU-Box, gekürzt — So läuft die Lane seit Anfang September
docker run -d --gpus all --shm-size 16g -p 8000:8000 \
  -e VLLM_PLE_CPU_OFFLOAD=1 \
  vllm-flashnext-hybrid:kvq-fp8 \
  /models/flashnext-hybrid/merged \
  --tensor-parallel-size 4 --enable-expert-parallel \
  --moe-backend flashinfer_cutlass \
  --max-model-len 262144 --max-num-seqs 8 \
  --gpu-memory-utilization 0.92 --kv-cache-dtype fp8_e4m3 \
  --reasoning-parser qwen3 --tool-call-parser qwen3_xml \
  --enable-auto-tool-choice --enable-prompt-tokens-details

Der KV-Pool ist die Zahl, die den Unterschied macht. Agenten-Sitzungen sind lang: rund 38.000 Prompt-Tokens im Mittel pro Anfrage sind bei uns Normalbetrieb, und wer 262k-Kontext nicht im KV unterbringen kann, verdrängt und rechnet von vorn. FP8-KV hat uns den Pool fast verdoppelt — bei identischem Verbrauch, weil der KV-Cache nach dem Start ohnehin fast alles übrig gebliebene VRAM nimmt. Der Preis ist die Nebenläufigkeit: Unser Vorgänger, ein dichtes 27B in FP8, fuhr auf demselben Blei das Doppelte an gleichzeitigen Anfragen bei gleichem Kontext. Wir haben für Kontextlänge und Werkzeugzuverlässigkeit Nebenläufigkeit eingetauscht — und sagen das offen, weil im laufenden Betrieb der Slot-Deckel der Engpass war, nie das Modell. Das Qualitätsgate dazu (Needle-in-a-Haystack bis 180k, vier parallele 128k-Sitzungen, Tool-Calls, Reasoning) haben wir vor der Umstellung gegen BF16 laufen lassen: identisch.

Die Token-Rechnung: 111:1 und ein Cache, der fast alles trifft

Ein Tag Produktion am Gateway, alle Lanes, 15.914 Anfragen:

Nach Lane aufgeschlüsselt (dasselbe Fenster):

Zwei Beobachtungen, die uns wichtiger sind als jede Benchmarkzahl:

Die 10.469 Embedding-Anfragen machen 66 % aller Anfragen, aber nur 3 % der Tokens. Wer seine Kosten an Anfragen festmacht, versteht diese Strecke falsch.

Agentenlast ist Cache-förmig. Der Prefix-Cache von vLLM trifft, weil der Agent seinen Kontext von Schritt zu Schritt fast unverändert weiterschickt: Werkzeugdefinitionen, AGENTS.md, dieselben Dateien. Engine-seitig heißt das 94,17 % von 103,4 Millionen abgefragten Token seit dem letzten Start — der Zähler der Engine arbeitet token-basiert, nicht pro Anfrage —, gateway-seitig 90,6 % der Prompt-Tokens über einen ganzen Tag. Die Lücke zwischen den beiden Zahlen ist der Anteil kleiner, sich nicht wiederholender Anfragen — Embeddings, Testläufe, Kaltstarts.

Über dreißig Tage hinweg sind das 2,70 Milliarden Tokens bei 209.622 Anfragen auf zehn Modell-Lanes, an 30 von 30 Tagen.

Tempo: gemessen, nicht projiziert

Dekodierung ist der Wert, den jede Anzeige zeigt und der am wenigsten über die Arbeitsgeschwindigkeit aussagt. Unsere Messwerte:

Dazu die Zeitanteile aus einem 21-Stunden-Protokoll mit 1.901 Anfragen: 0,6 Sekunden bis zum ersten Token im Schnitt, 0,44 Sekunden Vorrechnen bei einem Cache-Treffer, 7,6 Sekunden Dekodieren pro Anfrage. Bei einem Modell, das 6 Milliarden aktive Parameter je Token bewegt, ist das für einen interaktiven Agenten brauchbar. Wo die Zeit wirklich hingeht, zeigt die Sitzung, die diesen Beitrag geschrieben hat: 30 Minuten Modellzeit gegen gut 5 Minuten Werkzeugzeit, 143 Schritte, 19,5 Millionen Eingabe- gegen 116 Tausend Ausgabe-Token, Cache-Trefferquote 97 %. Der Engpass ist das Modell selbst — nicht SSH, nicht das Werkzeug.

Wir haben uns bei dieser Messung auch selbst korrigiert. In unserem eigenen Bankmark-Log vom August steht eine Spalte „gemessen gesamt" mit Werten um 100 Token/s, die jahrelang als Referenz kursierte. Sie hat Vorrechnen mitgezählt — bei einer Produktions-Promptgröße von 62.000 Token gegen 64 Antwort-Tokens in diesem Test misst sie den Vorrechenvorgang, nicht die Dekodierung. Wir zitieren sie nicht mehr. Zweite Lehre: 78 Engine-Schritte pro Sekunde bei exakt 1 Token pro Schritt ist der Beweis, dass der prädiktive Spezialpfad (MTP) bei uns nicht aktiv ist, obwohl der Build ihn registriert. Er ist angelehnt, weil es dafür einen offenen Upstream-Fehler auf unserer Karten-Generation gibt (#55357: phasenweise 0% Annahme der Entwürfe, dazu Denkblöcke, die sich wiederholen) und Nvidias eigene Messung auf vier H100 negativ ausfiel (≈36% Annahme, 8–36% weniger Durchsatz, bis zu 173% schlechtere Latenz pro Token). Ein Gewinnknopf ist das nicht, eher eine offene Versuchstür.

Was derselbe Monat in der API gekostet hätte

Hier ist die Rechnung, die alle wollen — mit ihren Annahmen direkt darunter, damit man sie zerpflücken kann.

Drei Dinge an dieser Rechnung sind ehrlich zu sagen. Erstens: Die API-Varianten sind nicht unsere Zahlen, sondern Listenpreis (claude.com/pricing, abgerufen am 10. September 2026) × unser Token-Mix. Wir haben keinen Kopf-an-Kopf-Lauf gegen Claude Sonnet 5 gefahren, dazu fehlt uns im Bestand ein API-Key, und ohne denselben Prompt an beiden Enden ist jeder „Qualitätsvorteil" eine Meinung. Zweitens: Die cache-freundlichste Variante setzt voraus, dass der Anbieter die Wiederholungen genauso sauber wiedererkennt wie unser automatischer Prefix-Cache — Prompt-Caching will dort mit Bruchpunkten gepflegt werden, und die Cache-Verweildauer ist kurz. Bei 37.900 Prompt-Tokens pro Anfrage ist genau dieses Verhalten der ganze Einsatz. Drittens: Unsere 261 Euro sind nur die GPU-Box. Gateway-Host, Embedding-Karte, storage, Backup und die Arbeitszeit für den Betrieb stecken da nicht drin — und die Betriebszeit ist der Grund, warum so etwas nicht jeder hat, nicht der Strom.

Der Satz, den wir daraus ziehen, ist klein und pragmatisch: Solange unser Verkehr diese Form hat — langer, sich wiederholender Kontext, wenig Ausgabe — ist der Randpreis pro Aufgabe bei uns nahe null. Genau deshalb können wir Aufgaben laufen lassen, die sich pro Task nie amortisiert hätten: der Wochenlauf, der jede Nacht durch 40 Rechner geht, der Scorer, der Belege prüft, der Audit-Lauf, der sich selbst meldet, wenn er etwas findet.

Ersetzt das Claude Sonnet 5? Die ehrliche Antwort

Für die Arbeit, die wir tatsächlich machen: überwiegend ja. Und „überwiegend" ist hier kein Werbewort, sondern die Stelle, an der wir weiter bezahlen würden, wenn es sein müsste.

Was dafür spricht, aus dem Betrieb statt aus Benchmarks:

• Volumen und Art der Arbeit. 464 Millionen Prompt-Tokens am Tag allein auf der Agent-Lane, davon 93,5 % Cache-Treffer — das sind lange Mehrschritt-Aufgaben über SSH, Dateien, Konfiguration, Protokolle, keine Zeilenergänzungen.
• Werkzeugzuverlässigkeit. tool_calls kommen sauber und mit korrektem finish_reason zurück; erzwungene Tool-Calls funktionieren; das Chat-Template öffnet keinen Denkblock, wenn man ihn nicht will. Vor zwei Jahren war das der häufigste Grund, warum lokale Modelle im Agentenbetrieb ausgefallen sind.
• Prüfreihen an echten Aufgaben. An 24 echten ERP-Belegen mit unverändertem Produktions-Prompt lag ein MoE mit 3 Milliarden aktiven Parametern gegen ein dichtes 27-Milliarden-Modell qualitativ gleichauf — gleiche Positionen, gleiche Rechenprobe, bei unserem kritischsten Feld (Regelbruch Lieferadresse) sogar besser: 5,0 % statt 17,4 %. Ein anderes Mal: 21 Prüfaufgaben (Arithmetik, Follow-the-Instruction, Tool-Calls, Needle über 32k), 19 von 21 für unser damaliges Modell, 18 für den Kandidaten.

Was dagegen spricht und es auch weiterhin tun wird:

• Planung über sehr lange Horizonte. Frontier-Modelle zerlegen eine zwanzigstufige Aufgabe zuverlässiger in richtige Zwischenschritte. Unsere Gegenmaßnahme ist kein Modell, sondern Zucht: Projektregeln, Wiederholungsverbote für verbrauchte Anweisungen, Prüfschritte, harte Ausstiegsbedingungen. Hilft messbar — ersetzt aber nicht die Qualität des ersten Entwurfs.
• Nichtdeterminismus bei Temperatur 0. Unser Build kann bei temp = 0 einen Denkblock liefern und den Antworttext leer lassen. Für Extraktion, die in ein ERP schreibt, ist das ein Produktionsrisiko, und es ist bis heute nicht stromaufwärts gefixt.
• Harte Deckel. Acht gleichzeitige Anfragen, kein automatischer Ausweichpfad auf die zweite Box, die Ausweichspur will vom Client selbst gewählt sein. Ein Ausfall der GPU-Box ist ein Ausfall der KI, nicht ein Umschalten.
• Sonderstrecken bleiben Sonderstrecken. Beleglesen, OCR, Neubewertung von Dokumenten laufen über eigene Modelle und eigene Dienste, nicht über die Chat-Lane.

Unsere Antwort auf die Frage lautet deshalb nicht „ ersetzen", sondern: Wir haben die lastinternen, wiederholenden, datenschutzkritischen Aufgaben abgezogen, und das ist der Teil, der in der API am meisten gekostet hätte. Was bleibt, sind die seltenen Momente, in denen ein Modell einen Denkfehler nicht selbst bemerkt. Die kaufen wir uns weiter mit Kontrolle und Prüfschritten — und nicht mit Token-Preisen.

Was wir beim nächsten Mal anders machen

• MTP aktiv testen, statt es liegen zu lassen. Der Build kann es, niemand hat es je versucht. Notfalls mit dem Wissen, dass es ein Verlust sein kann — der Upstream-Thread dazu: vllm#55357.
• Bankmarks mit Vorrechnen und Dekodieren getrennt ausgeben. Wir haben uns von einer eigenen Zahl drei Wochen in die Irre führen lassen.
• Slots hoch, bevor der Speicher knapp wird. Der Engpass ist aktuell der Slot-Zähler, nicht der KV-Pool. Solange die Auslastung unter 30 % bleibt, sind 16 Slots der billigste Gewinn des Quartals.
• NVFP4-Key-Value bewusst nicht. Der Sprung auf das Dreifache des Pools war verlockend, die gemessene Verschlechterung bei der Verwirrtheit und doppeltes Vorrechnen waren es uns nicht wert.

Fazit

Zwischen „wir brauchen einen Cloud-Key" und „wir haben eine KI-Fabrik" liegt ein Gateway, ein Container und eine sehr unspektakuläre Wahrheit: Der Großteil moderner Agenten-Tokens ist Wiederholung. Wer diese Wiederholung im Haus behält, bekommt damit Tempoklassen, die ihn nicht jucken müssen, Datenhoheit als Nebenprodukt und eine Rechnung, die im Wesentlichen aus der Abschreibung einer Grafikkarte besteht.

Wer eine comparable Strecke plant, fängt nicht beim Modell an, sondern beim Gateway: messen, welche Lane wer warum nutzt. Erst dann weiß man, ob das Modell überhaupt das Problem ist. In unserem Fall war es das seit Monaten nicht mehr — das Problem hieß KV-Pool, Backend-Flag und Slot-Deckel.

Verwandte Beiträge: vLLM auf eigener Hardware, vLLM oder llama.cpp, Coding-Agenten auf Windows-Servern im Vergleich, MCP-Server im Eigenbetrieb, EU AI Act und lokale KI.