
Orchestration Tax
Die Orchestration Tax ist der zusätzliche Aufwand, der entsteht, wenn viele Programmteile oder KI-Modelle koordiniert zusammenarbeiten müssen. Sie zeigt sich als längere Wartezeit, höhere Kosten und mehr Fehlerquellen — und frisst einen Teil des Vorteils wieder auf, den die Aufteilung bringen sollte.
Große Software wird heute selten als ein einzelner Block gebaut. Stattdessen zerlegt man sie in viele kleine Bausteine, die sich gegenseitig Aufträge schicken. Jemand muss diese Bausteine dann anleiten: wer arbeitet wann, wer bekommt welches Ergebnis, was passiert bei einem Fehler. Genau dieses Anleiten heißt Orchestrierung, und es kostet Zeit, Geld und Nerven. Diesen Preis nennt man Orchestration Tax, also übersetzt etwa „Koordinationssteuer“. Der Begriff ist keine echte Steuer, sondern ein Bild: man zahlt eine Abgabe dafür, dass die Arbeit verteilt ist.
Warum verteilte Systeme oft langsamer sind als versprochen
Die Aufteilung in Bausteine hat gute Gründe. Kleine Teile lassen sich unabhängig entwickeln, austauschen und bei Lastspitzen vervielfachen. Auf dem Papier wird alles schneller und flexibler. In der Praxis bleibt oft ein Teil dieses Gewinns liegen.
Der Grund ist einfach: jeder Übergang zwischen zwei Bausteinen kostet etwas. Daten müssen verpackt, verschickt, entpackt und geprüft werden. Bei zehn Zwischenschritten summieren sich lauter kleine Verzögerungen zu einer merkbaren Wartezeit. Ein Aufruf innerhalb eines einzigen Programms braucht Bruchteile einer millionsten Sekunde, ein Aufruf über das Netzwerk gut und gerne einige Millisekunden. Das ist ein Unterschied um mehrere Größenordnungen.
Dazu kommt der menschliche Anteil. Verteilte Systeme sind schwerer zu verstehen und schwerer zu reparieren. Wenn eine Antwort falsch ist, muss man erst herausfinden, welcher der zwanzig beteiligten Teile den Fehler gemacht hat. Diese Suchzeit ist Teil der Rechnung, auch wenn sie in keinem Rechenzentrum auftaucht.
Woraus sich der Aufschlag zusammensetzt
Der erste Posten ist die Kommunikation. Jede Nachricht zwischen zwei Teilen läuft über ein Netzwerk und braucht dort eine gewisse Laufzeit. Der zweite Posten ist die Wiederholung. Weil Nachrichten verloren gehen können, fragt man im Zweifel noch einmal nach, und dieselbe Arbeit wird zweimal gemacht.
Der dritte Posten ist die Aufsicht selbst. Es braucht eine Stelle, die den Ablaufplan kennt, Zwischenergebnisse zwischenspeichert und über Reihenfolgen entscheidet. Diese Stelle ist zusätzliche Software, die entwickelt, betrieben und überwacht werden muss. Sie kann auch selbst ausfallen und wird damit zur neuen Schwachstelle.
Bei KI-Systemen ist der Effekt besonders deutlich. Sogenannte Agenten sind Programme, die ein Sprachmodell mehrfach hintereinander befragen, um eine Aufgabe in Schritten zu lösen. Ein Agent, der fünf Schritte macht und in jedem Schritt eine Anfrage an das Modell stellt, zahlt fünfmal Wartezeit und fünfmal die Kosten pro Anfrage. Ein häufiger Irrtum ist, mehr Schritte automatisch für besser zu halten. Oft löst ein einziger, gut formulierter Auftrag die Aufgabe schneller und zuverlässiger.
Der Begriff in Cloud-Rechnungen und Agenten-Debatten
In Firmen tauchen die Kosten meist auf der Cloud-Rechnung auf. Cloud bedeutet, dass die Server nicht im eigenen Haus stehen, sondern bei einem Anbieter gemietet werden. Dort wird pro Anfrage und pro Rechenzeit abgerechnet, und viele kleine Anfragen sind teurer als wenige große. Wenn ein Projekt sein Budget überzieht, ist ein überkomplizierter Ablauf eine der häufigsten Ursachen.
In der Berichterstattung über KI fällt der Begriff vor allem beim Thema Agenten. Anbieter zeigen Demos, in denen mehrere Modelle sich gegenseitig kontrollieren und korrigieren. Kritiker rechnen dann vor, wie viele Sekunden und wie viele Cent so eine Kette pro Aufgabe kostet. Das ist keine Nebensächlichkeit: bei Millionen Nutzern entscheidet sie darüber, ob ein Produkt Geld verdient.
Als Nutzer merkt man die Orchestration Tax an der Ladeanzeige. Ein Chatbot, der zehn Sekunden „nachdenkt“, arbeitet oft nicht besonders schwer, sondern wartet auf eigene Zwischenschritte. Wichtig ist die Abgrenzung zum reinen Rechenaufwand: Rechenaufwand entsteht durch die Arbeit selbst, die Orchestration Tax durch deren Verteilung. Gute Entwicklerteams versuchen deshalb, Schritte zusammenzulegen, statt immer neue hinzuzufügen.