Das CrewAI-README sagt „5,76x schneller als LangGraph". Ein unabhängiger Benchmark von AIMultiple setzt CrewAI im gleichen Vergleich ans Ende — dreimal langsamer als LangChain. Beide Zahlen sind echt. Sie messen verschiedene Dinge, und die Lücke zwischen dem, was gemessen wird, und dem, was Leser daraus schließen, leistet den Großteil der Arbeit. Hier geht es darum, Framework-Benchmarks skeptisch zu lesen, am CrewAI-Fall durchgerechnet.
Wenn du in den letzten achtzehn Monaten auf der CrewAI-GitHub-Seite gelandet bist, sticht eine Behauptung ins Auge: „CrewAI zeigt signifikante Performance-Vorteile gegenüber LangGraph und ist in bestimmten Fällen wie diesem QA-Task-Beispiel 5,76x schneller."
Fünfeinhalbmal schneller. Klingt nach einem Grund, morgen das Framework zu wechseln.
Nur: Es stimmt so nicht. Nicht in der Form, wie du es vermutlich verstehst.
Die Zahl ist echt. Der Test, der sie hervorgebracht hat, existiert. Aber was „schneller" in diesem Satz bedeutet, ist nicht das, was die meisten Leser annehmen. Und die Lücke zwischen dem, was gemessen wurde, und dem, was Leser daraus machen, leistet richtig viel Arbeit — wahrscheinlich mehr Arbeit, als irgendein Marketing-Team einer einzelnen Zahl jemals überlassen sollte.
Hier geht es darum, Framework-Benchmarks skeptisch zu lesen, mit dem CrewAI-vs-LangGraph-Fall als Anschauungsbeispiel. Wenn du 2026 ein Multi-Agent-Orchestration-Framework wählst, ist das relevant. Wenn du AI-Engineering unterrichtest, ist es noch relevanter, weil die Fähigkeit, einen irreführenden Benchmark zu erkennen, eine Karriere-Fertigkeit ist.
Was die CrewAI-Seite tatsächlich sagt
Das README ist vorsichtig formuliert. „5,76x schneller in bestimmten Fällen wie diesem QA-Task-Beispiel (siehe Vergleich)." Der Link zeigt auf ein Repository, in dem beide Frameworks dieselbe Question-Answering-Aufgabe lösen. CrewAI ist in diesem konkreten Szenario schneller fertig. Nimm die rohen Zahlen und teile — 5,76x.
So weit, so nachvollziehbar. Niemand erfindet Daten. Die Stoppuhr lügt nicht.
Das Problem ist, was „dieses QA-Task-Beispiel" eigentlich misst. Denn ein Multi-Agent-Framework kann auf mindestens vier verschiedene Arten „schneller" sein, und die sind nicht austauschbar.
Die vier Geschmacksrichtungen von „schneller"
Framework A kann schneller als Framework B sein in:
Entwicklungs-Geschwindigkeit — wie lange ein Mensch braucht, um die erste funktionierende Version zu schreiben. Gemessen in Codezeilen, Setup-Zeit, Stunden bis zum ersten grünen Test.
Ausführungs-Geschwindigkeit — wie lange das Framework zur Laufzeit braucht, um eine Aufgabe abzuschließen, sobald sie geschrieben ist. Gemessen in Wall-Clock-Sekunden pro Run.
Token-Effizienz — wie viele Tokens pro Arbeitseinheit verbraucht werden. Relevant, weil Tokens Geld und Context-Window-Plätze kosten.
Skalierungsverhalten — wie Latenz und Kosten wachsen, wenn du mehr Agents, Tools oder Iterationen hinzufügst. Ein Framework, das mit drei Agents schnell ist, kann bei zehn abstürzen.
Das sind nicht dieselbe Dimension. Ein Framework kann in einer dominieren und in einer anderen verlieren. Die meisten Leser parsen „5,76x schneller" intuitiv als Ausführungs-Geschwindigkeit, weil das in fast jedem anderen Kontext gemeint wäre. Bei Frameworks ist es das meistens nicht.
Was der unabhängige Benchmark gefunden hat
Der sauberste unabhängige Test, den ich gesehen habe, ist AIMultiples Benchmark von Anfang dieses Jahres. Sie haben vier Frameworks laufen lassen — LangChain, LangGraph, AutoGen, CrewAI — über fünf Aufgaben, insgesamt zweitausend Runs. Gleiche Probleme, gleiche Modelle, Stoppuhr an, Methodik veröffentlicht.
CrewAI wurde Letzter. Nicht knapp. Ihre Zusammenfassung: „CrewAI zieht das schwerste Gesamtprofil." Bei einem Single-Tool-Call-Task — der denkbar einfachsten Arbeit — hat CrewAI rund dreimal so viele Tokens wie LangChain verbraucht und dreimal so lange gebraucht. LangGraph war in ihrem Orchestrierungs-Benchmark 2,2x schneller als CrewAI.
Gleiche Framework-Familien. Gegenteilige Schlussfolgerung. Was ist passiert?
Die Auflösung
Wenn man beide Aussagen sauber weiterverfolgt, passen sie zusammen.
CrewAIs 5,76x ist echt — für Entwicklungs-Geschwindigkeit. Das Framework ist berüchtigt dafür, schnell prototypisierbar zu sein: rollenbasierte Agents, die du in einfacher Sprache beschreibst, minimales State-Management, zwanzig Zeilen Python für einen laufenden Crew. Mehrere unabhängige Reviewer bestätigen das Muster: CrewAI-Prototypen versenden sich mit etwa 40 Prozent weniger Code als LangGraph-Äquivalente. Von der Idee zum funktionierenden Prototyp geht tatsächlich schnell.
Der AIMultiple-Benchmark ist auch echt — für Ausführungs-Geschwindigkeit. Sobald beide Frameworks laufen, greift CrewAIs „Managerial Overhead". Die eigene Dokumentation spricht von einer Fünf-Sekunden-Lücke zwischen Agent und Tool, bezeichnet als „Deliberation Time". Jeder CrewAI-Agent denkt buchstäblich nach, bevor er handelt, und dieses Nachdenken kostet sowohl Tokens als auch Wall-Clock-Sekunden. Bei einfachen Aufgaben ist das reiner Overhead. Bei komplexen Aufgaben kann es helfen, weil die Deliberation Fehler abfängt, die ein simpleres Framework übersehen würde. Aber auf Single-Tool-Call-Niveau verliert CrewAI.
Die 5,76x im README und die 2,2x bei AIMultiple messen verschiedene Dinge. Keine ist falsch. Die Verwirrung liegt vollständig in der Art, wie die erste präsentiert wird.
Warum das für die Framework-Auswahl wichtig ist
Wenn du ein Multi-Agent-Framework auswählst, hat diese Unterscheidung praktische Konsequenzen.
Entwicklungs-Geschwindigkeit zählt am meisten beim Prototyping, wenn du klein bist, wenn du noch nicht weißt, ob das Problem sich lohnt. Ausführungs-Geschwindigkeit und Token-Effizienz zählen am meisten im Maßstab, wenn Tokens echtes Geld kosten, wenn Latenz für die Nutzer sichtbar wird.
CrewAI ist in der ersten Phase wirklich gut. Teams bauen in einem Wochenende lauffähige Multi-Agent-Prototypen. Das hat Wert, besonders beim Lernen.
Teuer wird es in der zweiten Phase. Ein Muster, das ich in mehreren Praxis-Berichten bestätigt gesehen habe: Teams starten auf CrewAI wegen der Prototyping-Geschwindigkeit, stoßen nach rund sechs Monaten gegen die dogmatischen Design-Grenzen und schreiben signifikante Teile für die Produktion auf LangGraph um. Schätzungen zu den Umbau-Kosten bewegen sich zwischen 50 und 80 Prozent. Anekdotisch, aber das Muster kommt immer wieder.
Das ist kein Grund, CrewAI zu meiden. Es ist ein Grund, ehrlich zu sein, für welche Phase du optimierst. Wenn dein Projekt erstmal eine Weile im Prototyp-Stadium lebt — oder wenn du Multi-Agent-Konzepte an Engineers unterrichtest, die schnell Ergebnisse sehen müssen — ist CrewAI eine gute Wahl. Wenn du weißt, dass es Richtung Produktion im Maßstab geht, kostet der Start auf LangGraph mehr Anfangsinvestition und spart die Umschrift.
Das Muster hinter dem konkreten Fall
Zoome raus von CrewAI. Das ist eine Schablone, die überall in der Framework-Welt angewendet wird.
„Framework X ist zehnmal schneller als Framework Y" ist ein Satz, der unter Nachfragen fast immer zusammenbricht. Schneller bei was? Wie gemessen? Auf welcher Hardware? Mit welchen Modellen? Unter welcher Last? Für die Entwickler, die den Code schreiben, oder für die Maschine, die ihn ausführt?
Die Benchmarks, denen man vertrauen kann, haben ein paar Eigenschaften gemeinsam. Sie benennen die Dimension, die sie messen. Sie laufen über mehrere Aufgaben, nicht ein handverlesenes Szenario. Sie veröffentlichen ihre Methodik. Sie nennen Trade-offs. Die AIMultiple-Studie tut all das. Das CrewAI-README tut eines — es benennt die Aufgabe — und hört dann auf.
Eine nützliche Gewohnheit beim Lesen jedes Framework-Vergleichs: bei der Zahl kurz stoppen und fragen „Geschwindigkeit von was?". Wenn der Artikel das nicht klar macht, zählt die Zahl nicht. Das gilt für Datenbank-Vergleiche, Web-Framework-Shootouts, Compiler-Speed-Claims, Inferenz-Benchmarks, jede Spielart von Engineering-Marketing.
Für KI-Frameworks speziell gibt es noch eine Dimension, die selten gemessen wird, aber enorm wichtig ist: Verhalten bei Teil-Ausfällen. Multi-Agent-Systeme versagen auf seltsame Weise. Ein Agent liefert eine fehlerhafte Antwort zurück, ein Tool-Call läuft in ein Timeout, ein nachgelagerter Agent wird vom Rauschen verwirrt. Wie geht das Framework damit um? LangGraph hat eingebaute Retry- und State-Checkpointing-Primitive. CrewAI hat sie auch, aber weniger granular. AutoGen handhabt es über Conversation-Patterns, die schwerer zu überblicken sind. Kein Benchmark, den ich gesehen habe, misst das gut, aber es ist wahrscheinlich das, was ein Demo von einem Produktions-System mehr trennt als alle rohen Geschwindigkeits-Zahlen.
Was Anthropics eigene Erfahrung hinzufügt
Anthropic hat im Juni letzten Jahres einen detaillierten Engineering-Post zum Bau ihres Research-Multi-Agent-Systems veröffentlicht. Die frühen Iterationen hatten Fehler, die kein Benchmark fangen würde: Agents, die für eine einzige einfache Anfrage fünfzig Subagents gespawnt haben, endlos nach Quellen suchten, die es nicht gab, sich gegenseitig in Status-Updates ertränkt haben. Der Fix war kein schnelleres Framework. Es waren härtere Constraints — Runden-Limits, explizite Contribution-Regeln, Konvergenz-Kriterien.
Nach diesen Constraints hat ihr Multi-Agent-System (Claude Opus 4 als Orchestrator, Claude Sonnet 4 als Subagents) den Single-Agent-Claude-Opus-4 um 90,2 Prozent in internen Research-Evaluierungen geschlagen. Neunzig Prozent. Das ist ein größerer Gewinn, als fast jeder Framework-Wechsel dir bringen wird.
Die Lehre, die Anthropic daraus gezogen hat, ist verinnerlichenswert: welches Framework du wählst, zählt weniger als ob du die Leitplanken definierst. Ein gut eingerahmtes CrewAI-System schlägt ein unbegrenztes LangGraph-System. Ein gut eingerahmtes LangGraph-System skaliert weiter unter Produktions-Last. Das Framework ist ein Faktor; die Disziplin, die du darum legst, ist ein anderer. Benchmarks messen das erste und schweigen zum zweiten.
Drei Fragen an jeden Framework-Claim
Wenn du vor einem Framework-Vergleich stehst — egal ob du eins auswählst, einen Artikel dazu schreibst oder unterrichtest — sortieren drei Fragen das ehrliche Signal vom Marketing-Rauschen.
Erstens: Welche Dimension? Wenn ein Post sagt „X ist schneller", ohne Entwicklungs-Geschwindigkeit, Ausführungs-Geschwindigkeit, Token-Kosten oder Skalierungsverhalten zu spezifizieren, ist die Aussage nicht nützlich. Frag nach, welche es ist.
Zweitens: Was ist der Gegen-Fall? Jedes Framework, das in einer Dimension gewinnt, verliert in einer anderen. Wenn der Artikel keinen Trade-off erwähnt, verkauft er dir was. Der Trade-off ist nicht versteckt; der Autor hat ihn nur weggelassen.
Drittens: Wie sieht der Failure-Mode des Frameworks aus? Unter welchen Bedingungen bricht es? Wenn die Dokumentation Failure-Modes nicht benennt, ist das Framework entweder noch nicht im Maßstab eingesetzt worden — oder das Team verkauft dir das Demo.
Die 5,76x von CrewAI ist ein nützliches Artefakt, weil sie an allen drei Fragen scheitert. Sie benennt die Dimension nicht. Sie zeigt den Trade-off nicht. Sie beschreibt keinen Failure-Mode. Das ist der Archetyp eines Benchmark-Claims, der dir fast nichts sagt und dabei definitiv klingt.
Sobald du einen davon klar gesehen hast, siehst du sie überall. Das ist die Fertigkeit, die es zu bauen lohnt.
