KI-Agenten-Hardware: warum agentische KI mehr GPU braucht als Chat und wie Sie einen On-Premise-Server auslegen

Warum KI-Agenten mehr GPU brauchen als Chat

KI-Agenten brauchen mehr GPU als Chat, weil eine Agentenaufgabe aus einer Kette von Modellaufrufen besteht. Ein Agent ruft das Modell auf, führt ein Tool aus, fügt das Ergebnis seinem Kontext hinzu und ruft das Modell erneut auf, und jeder Aufruf sendet den System-Prompt, die Tool-Definitionen und den gesamten bisherigen Verlauf. Eine Aufgabe verarbeitet daher ein Vielfaches der Token einer Chat-Runde, hält während ihrer Laufzeit einen längeren KV-Cache und lässt den Nutzer auf die Summe aller Schritte warten statt auf eine Antwort.

Anthropics Engineering-Blog vom 13. Juni 2025 schreibt, in Anthropics Daten „nutzen Agenten typischerweise etwa 4× mehr Token als Chat-Interaktionen“. Derselbe Beitrag setzt Multi-Agenten-Systeme bei etwa dem 15-Fachen der Token von Chats an. Die Dokumentation von NVIDIA Dynamo zu agentischer Inferenz, aktualisiert am 2. Oktober 2026, schreibt, Coding-Agenten machten „Hunderte API-Aufrufe je Coding-Sitzung, jeder mit dem vollständigen Gesprächsverlauf“.

Diese Zahlen stammen von Cloud-Diensten, deshalb nutzt der nächste Abschnitt ein Beispiel mit angenommenen Werten. Wie Sie einen Agenten mit vLLM oder Ollama verbinden, beschreibt unser Leitfaden zu KI-Agenten mit n8n auf einem privaten LLM.

Modellaufrufe und Token je Agentenaufgabe: ein veranschaulichendes Beispiel

Das Beispiel vergleicht eine Chat-Runde mit einer Aufgabe eines Helpdesk-Agenten, der ein Ticket liest, zwei Systeme abfragt und eine Antwort entwirft. Jeder Wert darin ist eine Annahme zur Veranschaulichung, keine Messung. Die Chat-Runde sendet einen System-Prompt mit 1.000 Token, 2.000 Token des bisherigen Gesprächs und eine Frage mit 500 Token, und das Modell antwortet mit 500 Token.

Der Agent startet mit 6.000 Token System-Prompt und Tool-Definitionen plus einer Anfrage mit 500 Token. Er macht 8 Modellaufrufe, innerhalb des Standardwerts von 10, den der AI Agent von n8n je Prompt zulässt. Jeder Aufruf erzeugt 300 Token Reasoning und einen Tool-Aufruf, und jedes der 7 Tool-Ergebnisse fügt 1.500 Token hinzu. Der erste Aufruf sendet 6.500 Token und der achte 19.100, die Aufgabe sendet also insgesamt 102.400 Eingabe-Token.

Beispiel zur Veranschaulichung: Alle Werte sind Annahmen, keine Messungen; Verhältnisse nach unserer Rechnung. Standardwert für „Max Iterations“ aus der Dokumentation von n8n; KV-Cache mit 36 KiB je Token in 16 Bit für gpt-oss-120b, wie in unserem Leitfaden zur Auslegung eines privaten ChatGPT-Servers.

Das Verhältnis von etwa 29 im Beispiel liegt weit über Anthropics 4, weil die beiden Zahlen Verschiedenes zählen. Anthropic gibt nicht an, ob eine Chat-Interaktion in seinen Daten eine Runde oder ein ganzes Gespräch ist und wie gecachte Token zählen. Das Beispiel stellt eine Chat-Runde einer ganzen Aufgabe gegenüber und zählt jedes gesendete Token, einschließlich der 6.000 Token System-Prompt und Tool-Definitionen, die bei allen 8 Aufrufen erneut gesendet werden. Nach Prefix Caching sinkt das Verhältnis auf etwa 19, und ein Chat über mehrere Runden würde es weiter senken. Keines der beiden Verhältnisse lässt sich auf Ihren Workflow übertragen; zählen Sie Aufrufe und Token je Aufgabe deshalb im Gateway-Log eines Piloten.

Prefill-Last und Prefix Caching für Agenten

Eingabe-Token werden im Prefill verarbeitet, der Rechenarbeit ist und die Zeit bis zum ersten Token bestimmt, während die Generierung durch die Speicherbandbreite begrenzt ist; ein Agent verschiebt die Last deshalb zum Prefill. Im Beispiel sendet er 43 Eingabe-Token für jedes erzeugte Token, gegenüber 7 in der Chat-Runde.

Prefix Caching spart den größten Teil dieser Arbeit ein. Laut der Dokumentation von vLLM „speichert“ Automatic Prefix Caching „den KV-Cache vorhandener Anfragen zwischen, sodass eine neue Anfrage den KV-Cache direkt wiederverwenden kann, wenn sie dasselbe Präfix hat“. vLLMs Blog vom 27. Januar 2025 kündigte an: „Wir aktivieren Prefix Caching in V1 jetzt standardmäßig.“ Die Grenze nennt dieselbe Dokumentation: APC „verkürzt nicht die Zeit für die Erzeugung neuer Token (die Decoding-Phase)“.

Sind alle früheren Schritte noch im Cache, berechnet jeder Aufruf des Beispiels nach einem ersten Aufruf mit 6.500 Token nur das neue Tool-Ergebnis und die vorherige Ausgabe, 1.800 Token. Das ergibt etwa 19.100 zu berechnende Token statt 102.400; rund 81 Prozent der Eingabe kommen also aus dem Cache. Für einen gehosteten Coding-Agenten auf einer verwalteten Cloud-API, keinen Dynamo-Test, schreibt die Dynamo-Dokumentation von NVIDIA, dass nach dem ersten Aufruf „jeder weitere Aufruf an denselben Worker zu 85 bis 97 % den Cache trifft“.

Der Cache wird für einen wartenden Agenten nicht reserviert. Die Design-Notizen von vLLM beschreiben, dass die Blöcke einer abgeschlossenen Anfrage nur so lange wiederverwendbar bleiben, bis vLLM sie verdrängt, die am längsten nicht genutzten zuerst, um Platz für neue Arbeit zu schaffen; die Blöcke eines wartenden Agenten konkurrieren also mit jeder anderen Anfrage. Die Dynamo-Dokumentation von NVIDIA warnt: „Eine Tool-Pause von 2 bis 30 Sekunden kann das gesamte Präfix eines Agenten aus dem Cache fallen lassen und erzwingt bei der Fortsetzung eine vollständige Neuberechnung.“

Die Latenz summiert sich über die Schritte eines Agenten

Ein Chat-Nutzer sieht Text nach einer Zeit bis zum ersten Token und liest, während die Antwort gestreamt wird. Das Ergebnis eines Agenten kommt erst nach dem letzten Schritt, und jeder Schritt fügt Warteschlange, Prefill, Generierung und die Laufzeit des Tools hinzu.

Mit Beispielwerten von 6 Sekunden je Modellaufruf und 2 Sekunden je Tool brauchen die 8 Aufrufe und 7 Tools des Beispiels 62 Sekunden. Unser Leitfaden zu einem privaten Coding-Assistenten nennt NVIDIAs gemessene Agentenaufgaben mit Prompts von 32K Token auf einem DGX Spark.

In NVIDIAs Blog vom 8. Mai 2026 erreichte ein Prompt mit 52K Token und stabilem Präfix sein erstes Token nach 168 ms auf einer B200-GPU. Ein sitzungsbezogener Header, der sich innerhalb des Präfixes desselben Prompts änderte, erhöhte diesen Wert auf 912 ms, weil er die Wiederverwendung des gecachten Präfixes verhinderte.

Tool-Definitionen, MCP und das Prompt-Präfix

Jedes Tool, das der Agent aufrufen darf, wird in seinem Prompt mit einem Namen, einer Beschreibung und einem JSON Schema für seine Argumente beschrieben, wie das Model Context Protocol sie definiert. Anthropics Engineering-Blog vom 4. November 2025 vermerkt, dass „die meisten MCP-Clients alle Tool-Definitionen vorab direkt in den Kontext laden“ und dass Tool-Beschreibungen Kontext belegen und dabei „Antwortzeit und Kosten erhöhen“. In seinem Beispiel-Workflow senkte die Darstellung der Tools als Code, den der Agent erst bei Bedarf lädt, den Token-Verbrauch von 150.000 auf 2.000.

Revision 2026-07-28 der MCP-Spezifikation fordert Server auf, Tools in deterministischer Reihenfolge zurückzugeben, was „die Trefferquote des Prompt-Caches des LLM verbessert, wenn Tools im Modellkontext enthalten sind“. Geben Sie jedem Agenten nur die Tools, die seine Aufgabe braucht, was das MCP Client Tool von n8n je Server erlaubt, halten Sie Reihenfolge und Beschreibungen fest und setzen Sie alles, was sich je Sitzung ändert, hinter den stabilen Teil des Prompts. Wie Sie die Server absichern, beschreibt unser Leitfaden zur Sicherheit von MCP-Servern.

Hebel, die die GPU-Last von Agenten senken

Quellen abgerufen am 10. Oktober 2026; „latest“-Dokumentation von vLLM, aktuelles Release 0.31.0. Wirkungen so, wie jede Quelle sie beschreibt, ohne gemessene Gewinne für Ihren Workload.

Bei mehreren Kopien eines Modells hinter einem Load Balancer warnt die Dynamo-Dokumentation: „Ohne Cache-bewusstes Routing hat Runde 2 eines Gesprächs eine Chance von ~1/N, auf demselben Worker zu landen wie Runde 1“, wobei N die Zahl der Worker ist. Session-Affinität am Load Balancer oder ein KV-bewusster Router wie der von Dynamo hält einen Agenten auf einer Kopie. Offloading hält verdrängte Blöcke für eine zurückkehrende Anfrage im Host-Speicher vor, etwa für einen Agenten, der von einem Tool zurückkommt; unser Leitfaden zur Long-Context-LLM-Hardware beschreibt die Optionen von vLLM und LMCache.

Die Structured Outputs von vLLM mit den Backends xgrammar oder guidance beschränken eine Antwort auf ein JSON-Schema, eine Regex, eine Auswahlliste oder eine Grammatik. Für Tool-Aufrufe im Auto-Modus wendet die Tool-Calling-Dokumentation von vLLM vom 8. Oktober 2026 solche Einschränkungen nur an, wenn ein Tool strict: true setzt oder der Server --tool-strict-level anhebt; andernfalls „extrahiert vLLM Tool-Aufrufe aus dem Rohtext, sodass Argumente gelegentlich fehlerhaft sein können“. Ein Aufruf, der sich parsen lässt, überlässt die Wahl des Tools trotzdem dem Modell. Ein Positionspapier auf arXiv, erstmals eingereicht am 2. Juni 2025, argumentiert, kleine Sprachmodelle seien „ausreichend leistungsfähig, von Natur aus besser geeignet und zwangsläufig wirtschaftlicher für viele Aufrufe in agentischen Systemen“. Schritte für Routing, Klassifizierung und Extraktion können auf einem kleinen Modell laufen.

Einen GPU-Server für agentische Workloads auslegen

Die Last von Agenten wird in Aufrufen und Token gezählt, nicht in Nutzern. Unser Leitfaden zur Auslegung eines privaten ChatGPT-Servers nach Unternehmensgröße rechnet Anfragen mit dem Gesetz von Little in Anfragen in Bearbeitung um, und dieselbe Methode gilt für Agentenaufgaben.

1. Aufgaben: Zählen Sie die Agentenaufgaben in der Spitzenstunde je Workflow, aus einem Piloten oder als gekennzeichnete Schätzung.
2. Aufrufe und Token: Entnehmen Sie dem Gateway-Log die Modellaufrufe je Aufgabe, die Eingabe- und Ausgabe-Token je Aufruf und den Kontext im letzten Schritt.
3. Token-Last: Multiplizieren Sie Aufgaben mit Token für die stündliche Eingabe, die Eingabe nach Treffern im Prefix-Cache und die Ausgabe.
4. Sitzungen: Multiplizieren Sie Aufgaben pro Sekunde mit der Dauer einer Aufgabe für die mittlere Zahl offener Agentensitzungen, wenden Sie einen Spitzenfaktor an und multiplizieren Sie mit dem KV-Cache im letzten Schritt, dem Speicher, der ihre Präfixe zwischen den Aufrufen im Cache hält.
5. Test: Testen Sie die infrage kommende GPU unter Last mit aufgezeichneten Aufgaben bei aktivem Prefix Caching und prüfen Sie die Zeit bis zum ersten Token je Schritt und die Dauer der Aufgabe gegen Ihr Ziel.

Mit der Beispielaufgabe ergeben 120 Aufgaben in der Spitzenstunde 960 Modellaufrufe, 12,3 Millionen gesendete Eingabe-Token, etwa 2,3 Millionen nach Cache-Treffern zu berechnende Token und 288.000 Ausgabe-Token. Bei 62 Sekunden je Aufgabe sind im Mittel etwa 2 Sitzungen offen und bei einem Spitzenfaktor von 2 etwa 4. Ihr Cache von etwa 2,8 GiB für gpt-oss-120b ist ein kleiner Teil einer Karte; hier entscheidet also die Zeit je Schritt über die Hardware, nicht der Speicher.

Wir bauen Inferenz-Server, ausgelegt nach Modellgröße und gleichzeitigen Nutzern. Schicken Sie uns die Aufgaben je Spitzenstunde, die Aufrufe je Aufgabe und das Modell über das Formular unten, und wir antworten innerhalb eines Werktages mit Konfiguration und Angebot.

Welche GPUs sich für KI-Agenten On-Premise eignen

Für einen Piloten betreibt ein DGX Spark (Founders Edition) mit 128 GB ein Modell wie gpt-oss-120b und den Workflow auf dem Schreibtisch. Für die Produktion trägt ein Server mit Karten vom Typ RTX PRO 6000 Server Edition eine Kopie dieses Modells je Karte. Nach der Schätzung in unserem Leitfaden zur Auslegung eines privaten ChatGPT-Servers behält eine Karte neben diesem Modell etwa 22,2 GiB für den Cache, Platz für etwa 33 Sitzungen mit den 19.400 Token des Beispiels.

Die H200 NVL lässt neben demselben Modell etwa 62,5 GiB frei, genug für etwa 93 solche Sitzungen. Ihre Speicherbandbreite von 4,8 TB/s, gegenüber 1.597 GB/s bei der RTX PRO 6000 Server Edition laut NVIDIAs Spezifikationen, verkürzt den Generierungsteil jedes Schritts. NVLink-Bridges verbinden zwei oder vier H200 NVL, wenn ein größeres Modell aufgeteilt werden muss.

Kleine Modelle für Routing, Embeddings und Reranking passen auf eine MIG-Instanz mit 24 GB einer RTX PRO 6000 oder auf eine L4, außerhalb des Batches des Hauptmodells. Wo Agenten Geschäftsprozesse ausführen, beseitigen zwei Server, von denen jeder die Spitze trägt, den Single Point of Failure, mit Session-Affinität, damit jeder Agent seinen Cache behält.

Unsere Leistung Private AI/ML umfasst Agenten-Workflows und ITOps-Automatisierung mit n8n und Ansible. Beschreiben Sie den ersten Agenten-Workflow, den Sie betreiben möchten, und die Tools, die er aufrufen wird, im Formular unten.

Was wir liefern

Wir liefern die DGX Spark Founders Edition, die RTX PRO 6000 als Workstation, Max-Q und Server Edition, die H200 NVL mit NVLink-Bridges sowie die L4, die L40S und kleinere RTX-PRO-Karten für Routing- und RAG-Modelle. Sie kommen als Karten oder in nach Auftrag gebauten KI-Servern mit 2 bis 8 GPUs je Knoten, im Burn-in getestet, mit Herstellergarantie, unter einem EU-Vertrag und auf einer Rechnung. Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Modelle, Agenten-Workflows und die Plattform darüber sind unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ