Kapitel 14 — Benchmarking, Testen und Performance

Fünfzehnter und letzter Beitrag der kapitelweisen Tour durch LLM Primer IV: Designing AI Cognition with MCP. Darin: die Architektur muss endlich die unsentimentale Frage beantworten — funktioniert das System wirklich? — und die Antwort kommt über echte Benchmarks, zwei systemische Fehlermodi und eine Zehnfach-Durchsatzklippe, die die meisten Teams am Tag des Produktions-Rollouts entdecken.

Warum dieses Kapitel existiert

Ein Protokoll, das sorgfältig entworfen, sicher gehärtet und sauber in ein Framework verpackt wurde, muss immer noch die unsentimentale Frage beantworten: funktioniert das System wirklich? Löst der Agent die Aufgaben, für die er gebaut wurde? Hält er Stand, wenn die Last verdoppelt wird? Wo sind die Performance-Klippen, die elegante Degradation in einen Ausfall verwandeln? Die früheren Kapitel handelten davon, die Architektur richtig zu bekommen; dieses handelt davon zu messen, ob die Architektur, einmal gebaut, liefert. Es geht den MCP-Universe-Benchmark durch — das erste öffentliche Test-Harness, das echte LLMs gegen echte MCP-Server fährt — die zwei systemischen Fehlermodi, die der Benchmark aufdeckte, und die Minderungen, die zu wirken begonnen haben, und die Durchsatzseite, auf der die Lücke zwischen einem gut konstruierten Session-Pool und dem naiven Pro-Request-Muster eine Größenordnung beträgt.

14.1 MCP-Universe: Agenten an echten Servern messen

Den größten Teil von 2024 und Anfang 2025 lebte öffentliche Agentenevaluation an einem seltsamen Ort. Tool-Use-Benchmarks maßen, ob Modelle syntaktisch korrekte Aufrufe gegen synthetische APIs emittieren. Agenten-Benchmarks maßen Aufgabenerfüllung in sandboxed Umgebungen. Was fehlte, war ein Benchmark, der Modelle gegen echte MCP-Server mit echter Authentifizierung, echten Rate-Limits, echten Schemata, die abdriften, und echten Tools fuhr, die gelegentlich leere Ergebnisse liefern. MCP-Universe, 2025 von Salesforce AI Research veröffentlicht, war der erste ernsthafte Versuch. Sechs Evaluations-Domänen über elf echte produktive MCP-Server — Google Maps, GitHub, Yahoo Finance, Blender, Playwright, echte Suchmaschinen — und 231 Aufgaben, jede mit einem automatisierten Evaluator, der prüft, ob der Endzustand dem erwarteten Ergebnis entspricht, statt zu prüfen, ob das Modell unterwegs die „richtigen" Tool-Aufrufe emittiert.

Das Headline-Ergebnis hat sich über Modell-Refreshes gehalten. Claude 3.5 Sonnet, das auf synthetischen Benchmarks in den Achtzigern scort, erreichte nur die niedrig-bis-mittleren Vierziger auf MCP-Universe insgesamt. GPT-4o, Gemini 1.5 Pro und die Llama-3-70B-Varianten clusterten im ähnlichen Bereich. Die Lücke zwischen Closed-Course-Tool-Use-Leistung und realer MCP-Leistung lag bei etwa vierzig absoluten Punkten, und Skala allein schloss sie nicht. Die Fehler clustern in wiedererkennbare Kategorien: Long-Context-Degradation, während Tool-Ausgaben das Fenster füllen; Unknown-Tool-Exploration, während das Modell unbekannte Schemata fehlinterpretiert; Koordination über Server, in der Ausgabeformate nicht passen und keine semantische Brücke existiert; und aufgabenspezifisches Reasoning, in dem das Modell das richtige Tool wählt, korrekt aufruft, die richtige Antwort zurückbekommt und trotzdem zum falschen Endschluss kommt, weil es die Tool-Ausgabe nicht ins breitere Reasoning integriert hat. Die strukturellen Entscheidungen, die MCP-Universe zu einem ernsten Instrument machen, sind ausführungsbasierte Evaluation (Aufrufe gegen echte Server fahren, kein Vergleich mit Referenz-Trace), Echtzeitdaten (Live-Marktdaten, mit Evaluator, der verfolgt, was die Antwort zur Laufzeit war) und mehrturn Evaluation (den Endzustand benoten, nicht jeden Schritt). Ein nützlicher Nebeneffekt: der Benchmark wirkt als indirektes Qualitätssignal aufs Server-Design, und Server-Autoren, denen Agentenleistung wichtig ist, haben nun ein öffentliches Ziel.

14.2 Die zwei systemischen Herausforderungen und was funktioniert

Long-Context-Degradation und Unknown-Tool-Exploration sind die zwei Fehlermodi, groß genug für sorgfältige Behandlung, weil die Minderungen nicht offensichtlich sind. Long-Context-Degradation in MCP-Agenten hat eine spezifische Form: der Kontext füllt sich mit Tool-Ausgaben, die alle in einem Sinn relevant sind — jede war Ergebnis eines Aufrufs, den das Modell wählte — aber jede ist umfangreich, und die tatsächlich tragende Tatsache darin ist klein. Die Minderungen wirken auf der Ebene der Informationspräsentation. Tool-Result-Summarisation lässt ein günstiges Modell (Haiku, GPT-4o-mini, Gemini Flash) über rohe Tool-Ausgabe laufen, bevor das Ergebnis im Kontext des Agenten landet; produktive Deployments berichten Zwei- bis Dreifach-Verbesserung der Long-Context-Abschlussraten, und Pro-Aufruf-Kosten werden durch das günstige Modell dominiert. Strukturierte Tool-Ausgabe mit einem summary-Feld neben der JSON-Payload — in der 2025er Protokollrevision formalisiert — leistet ähnliche Arbeit ohne den zusätzlichen Modellaufruf. Kontextverdichtung auf der Agentenschleife, gepaart mit einem agent-geführten Scratchpad, der die Verdichtung wörtlich überlebt, deckt den Fall ab, dass die Konversation selbst zu lang geworden ist; produktive Deployments lösen Verdichtung alle zwanzig bis vierzig Schritte aus und erhalten etwa ein Drittel des ursprünglichen Kontexts.

Unknown-Tool-Exploration hat eine andere Form. Verbindet sich ein Agent mit einem Server mit Tools, auf denen er nicht trainiert wurde, scheitern die ersten Aufrufe des Modells oft — falsche Typen, falsche Reihenfolge, manchmal falsches Tool. Die Minderung ist eine Explorationsphase vor der Hauptschleife: das Framework lässt das Modell jede Tool-Beschreibung lesen, zusammenfassen, was sie tut, eine Beispielaufrufung erzeugen und Parameter markieren, bei denen es unsicher ist. Die resultierende Notiz wird dem Kontext des Agenten vorangestellt. Die Kosten sind ein paar günstige Aufrufe zum Sessionstart; der Gewinn sind zwanzig bis dreißig Prozentpunkte Abschluss-Verbesserung auf Benchmarks wie MCP-Universe und ein auditierbares Protokoll des erklärten Verständnisses des Agenten, das hilft, spätere Fehler zuzuordnen. Das Muster erweitert sich auf geänderte Tools: hash die Tool-Oberfläche bei der Verbindung, fahr das Warm-up bei Hash-Wechsel, und der Silent-Drift-Fehlermodus (Server upgedated, Agenten scheitern wochenlang, bevor jemand es merkt) verschwindet. Ein dritter verwandter Punkt, der Namen verdient: Tool-Beschreibungsqualität. Viele Server lieferten Beschreibungen, die für menschliche Entwickler geschrieben waren — knapp, fachjargonbeladen, kontextabhängig. Server, die sie umschrieben, als seien sie für einen Praktikanten, der das System nie gesehen hat, zeigen messbare Verbesserungen bei gleichen Modellen ohne Agentencode-Änderung. Das einzige Fenster des Modells auf das Tool ist die Beschreibung, und eine Beschreibung, die nicht allein steht, produziert ein Modell, das das Tool nicht nutzen kann.

14.3 Die Session-Pool-Durchsatzklippe

Korrektheit ist die halbe Geschichte; die Produktionsrealität ist, dass die Designentscheidungen, die einen Agenten schnell machen, oft Korrektheitsimplikationen haben und umgekehrt. Das einzelne größte Durchsatzproblem in 2025–2026er MCP-Deployments ist die Lücke zwischen zwei Arten, Streamable-HTTP-Sessions zu verwalten, und die Lücke beträgt etwa zehn zu eins. Session-per-Request öffnet eine neue Session pro Agentenrequest, fährt Tool-Aufrufe darin und schließt sie beim Abschluss. Geteilter-Session-Pool hält einen Pool langlebiger Sessions und ordnet jeden Request einer aus dem Pool zu. Die Durchsatz-Differenz auf einem Standardserver mit repräsentativer Last landet konsistent um das Zehnfache — grob dreißig Requests pro Sekunde für Session-per-Request, grob 290 bis 300 für den Pool, auf Commodity-Hardware. Teams, die die Lücke nicht kennen, entdecken sie hart: Staging läuft sauber, der Produktionsrollout trifft eine Wand an der Requestrate, an der Session-Creation-Overhead dominiert.

Der Mechanismus ist geradeaus. Session-Erzeugung ist teuer — Zustandsallokation, Capability-Verhandlung, Credential-Validierung, Cleanup-Registrierung, strukturiertes Logging — und der MCP-Level-Handshake fügt Protokoll-Round-Trips hinzu, die der Transport nicht vermeiden kann. Session-per-Request zahlt diese Kosten bei jedem einzelnen Request; der Pool zahlt sie einmal pro Session und amortisiert. Die Implementierungsdetails, die entscheiden, ob der Pool praktisch funktioniert: Isolation (per-request Zustand ist ein Sub-Kontext in der Session, per Request erzeugt und zerstört, während per-session Zustand geteilt wird), Pool-Sizing (die p95-Concurrency mit Autoscaling für Bursts), Health-Checking (Hintergrundprüfungen auf Idle-Sessions, schnelle Prüfungen bei Zuweisung) und Request-Affinität über Sticky Sessions für Tools, deren Zustand mehrere Aufrufe überspannt. Darübergelegt produziert HTTP/2- oder HTTP/3-Connection-Multiplexing — eine zugrundeliegende Verbindung trägt viele parallele Streams — die zitierten Durchsatzzahlen; entweder Pool-Schicht allein produziert eine deutlich kleinere Verbesserung. Die Tail-Latenz-Dimension zählt auch: der Session-per-Request-Server hat lange Tail-Latenzen aus unglücklichen Momenten während der Erzeugung, der Pool hat enge, weil Erzeugungskosten asynchron neben dem Request-Hot-Path liegen. P99 verbessert sich typisch um den Drei- bis Vierfachen — ein größerer Gewinn als beim Durchsatz, und der, der die Nutzererfahrung tatsächlich prägt.

14.4 Was die Reihe gebaut hat

Die vier Bände haben einen bewussten Bogen durchschritten. Band I ging um das Innere des Modells. Band II um Prompts und Reasoning. Band III um Retrieval-Augmented Generation. Dieser Band ging um Agenten und Werkzeuge, organisiert um MCP, weil MCP das technische Substrat ist, das die Agentenarchitektur kohärent gemacht hat. Drei Fäden ziehen sich durch. Der erste ist die Trennung von Kognition und Operation: das Modell ist die kognitive Schicht, das Framework und die MCP-Server sind die operative, und die meisten Produktionsfehler kommen daher, die beiden zusammenzukollabieren. Der zweite ist das endliche Kontextbudget: Kontext ist eine knappe Ressource, und die architektonischen Wahlen, die verlässliche Agenten produzieren, sind die, die diese Knappheit respektieren. Der dritte ist das Protokoll-als-Grenze: MCP ist nicht nur ein Wireformat, sondern eine Grenze, über die Capabilities fließen, an der Vertrauen ausgehandelt werden muss und an der zukünftige Evolution weitergehen wird. Ein Protokoll, das unter Engineering-Druck Stand hält, wird Infrastruktur; MCP scheint das zu tun.

Was Band IV vorbereitet

Dies ist das letzte Kapitel des Bandes, also bereitet es nicht das nächste Kapitel vor, sondern den nächsten Band. Band V — Reale LLM-Anwendungen entwickeln — nimmt die Fundamente aus Band I bis IV und setzt sie zu spezifischen Anwendungsarchetypen zusammen: Assistenten fürs Software-Engineering, Agenten für Business-Automation, Copilots in vertikalen Anwendungen, autonome Forschungswerkzeuge. Die Behandlung wird weniger über zugrundeliegende Mechanismen handeln (die die vorherigen Bände abgedeckt haben) und mehr über die Engineering-Wahlen auf Anwendungsebene — wie man eine LLM-Anwendung scopet, sodass sie verlässlich Wert liefert, wie man sie in Produktion evaluiert, wie man den Lebenszyklus von Prompts, Tools und Gedächtnis verwaltet, während die Anwendung sich weiterentwickelt. Wer Band V beendet, ist den Weg von einem einzelnen Attention-Head zu einer deployten Anwendung gegangen, die einen Agenten über einen echten MCP-Server-Stack auf realer Infrastruktur fährt, mit dem Engineering-Urteil zu wissen, warum jede Schicht so gebaut wurde, wie sie ist.

Die Reihe geht weiter in LLM Primer V — Reale LLM-Anwendungen entwickeln.