Kategorie: Erklärer

Du baust ein Haus. Du verlegst Rohre, damit Wasser fließt, und du ziehst Kabel, damit Strom ankommt. Das ist Data Integration: Systeme werden verbunden, Daten bewegen sich von A nach B und kommen in der richtigen Form an. Aber wer entscheidet, wann der Wasserhahn aufgedreht wird, welche Pumpe läuft und was passiert, wenn ein Rohr bricht? Das ist Workflow Orchestration: die Koordination der Arbeit, die auf den verbundenen Systemen ausgeführt wird. Der Artikel zieht eine klare Linie: Systeme verbinden ist nicht dasselbe wie die Arbeit darüber zu koordinieren. Dennoch behandeln Unternehmen diese beiden Disziplinen oft als eine Einheit, kaufen Tools, stellen Teams ein und entwerfen Architekturen, als ob Data Integration und Workflow Orchestration austauschbar wären. Sie sind es nicht.

Die Verwirrung beginnt bei den Connectors. Ein Data-Integration-Tool bringt vorgefertigte Anschlüsse mit – für Datenbanken, SaaS-Apps, APIs. Ein moderner Orchestrator wie Airflow, Dagster, Kestra, Prefect oder Temporal bietet ebenso Dutzende von Plugins für dieselben Systeme. Oberflächlich betrachtet können beide an alles anknüpfen. Aber die Connectors erfüllen unterschiedliche Aufgaben. Integration nutzt sie, um Daten zu verschieben und umzuformen. Orchestrierung nutzt sie, um Tasks auszulösen, Abhängigkeiten zu steuern und nach Fehlern wieder hochzufahren. Derselbe Plugin zu einem System, aber zwei völlig verschiedene Gründe, ihn aufzurufen. Der Artikel unterscheidet zwischen Data Integration und Workflow Orchestration, zeigt die Überlappungen und erklärt, warum ein einheitliches Control Plane in Unternehmen immer wichtiger wird.

Was ist Data Integration?

Data Integration ist die Praxis, Systeme zu verbinden und Daten in der richtigen Form zwischen ihnen zu bewegen. Es ist nicht eine einzige Technik, sondern umfasst drei Kommunikationsparadigmen, die sich grundlegend unterscheiden. Da ist das Request-Response-Muster: Ein System fragt, ein anderes antwortet – APIs, REST, gRPC. Synchron und sofortig. Dann das ereignisgesteuerte Muster: Systeme veröffentlichen Ereignisse, andere reagieren darauf – Streaming, Apache Kafka, Change Data Capture. Kontinuierlich und entkoppelt. Und schließlich der Batch-Betrieb: Daten werden in geplanten, massenhaften Läufen verschoben – ETL, ELT, Dateitransfer. Periodisch und mit hohem Volumen. ETL, ELT, ESB, iPaaS, CDC, Reverse ETL und Event Streaming fallen alle in diese Paradigmen. Gleiches Ziel, andere Physik. Ein nächtlicher Warehouse-Load und ein Echtzeit-Fraud-Stream sind beides Integration, aber ihr Design hat kaum etwas gemeinsam.

Der schwierige Teil ist selten der Connector. Es ist die Konsistenz. Derselbe Kundendatensatz lebt in einem Dutzend Systemen, und die Integration muss sie in Übereinstimmung halten. Echtzeit-Integration macht das nicht einfacher, sondern schwieriger. Das Dual-Write-Problem, außerhalb der Reihenfolge eintreffende Ereignisse und doppelte Zustellung bedrohen die Korrektheit. Die meisten Streaming-Systeme bieten At-Least-Once-Delivery plus idempotente Verarbeitung – effektiv genau einmal, aber keine echte Exactly-Once-Garantie. Change Data Capture, Transactional Outbox Patterns und Reconciliation existieren, um die Konsistenz zusammenzuhalten. Die Integrationsfrage lautet also nicht nur: Sind die Daten angekommen? Sondern: Sind sie korrekt, vollständig, pünktlich und konsistent in allen Systemen angekommen? Die Arbeitseinheit der Integration ist der Datensatz, der Stream oder der Record.

Was ist Workflow Orchestration?

Workflow Orchestration ist die Koordinationsschicht, die entscheidet, was läuft, in welcher Reihenfolge, unter welchen Bedingungen und wie das System sich erholt, wenn etwas kaputtgeht. Sie bewegt nicht primär Daten, sondern steuert die Ausführung. Wo die Integration fragt: „Sind die Daten angekommen?“, fragt die Orchestrierung: „Sind die richtigen Schritte in der richtigen Reihenfolge mit den richtigen Abhängigkeiten gelaufen, und was tun wir mit dem einen, das fehlgeschlagen ist?“ Die Arbeitseinheit ist der Task, der Workflow oder der Prozess. Retry-Logik, Abhängigkeiten, bedingte Verzweigungen, Zeitplanung, Backfills und Ende-zu-Ende-Sichtbarkeit leben hier.

Orchestrierung reicht über die reine Datenwelt hinaus. Dieselben Koordinationsprobleme treten im IT- und Batch-Job-Scheduling, in der Geschäftsprozessautomatisierung und in der Infrastrukturbereitstellung auf. Und zunehmend auch in agentischer KI, wo die Aktionen eines Agenten sequenziert, mit Gates versehen und wiederhergestellt werden müssen wie jeder andere Workflow. Orchestrierung steht nicht allein. Sie ist der Ausführungskern einer breiteren Disziplin: Process Intelligence, die zeigt, wie diese Abläufe tatsächlich laufen, wo sie stocken und was sie kosten. „Du kannst einen Prozess nicht verbessern, den du nicht sehen kannst.“ Der Artikel über Process Intelligence ergänzt diesen Text und trennt die Orchestrierung von der Datenintegration.

Data Orchestration und Workflow Automation – Begriffe, die die Linie verschwimmen lassen

Zwei benachbarte Begriffe sorgen für die meiste Verwirrung. Data Orchestration ist ein gängiger Begriff im modernen Data Stack. Er beschreibt Workflow Orchestration, die auf die Datenwelt beschränkt ist: Koordination von Ingestion, Transformation und Lieferung innerhalb der Data Pipeline. Viele argumentieren, es sei schlicht Workflow Orchestration angewendet auf Daten, und der einfachere Name verursache weniger Verwirrung. Wenn ein Anbieter „Orchestrierung“ sagt und nur Pipelines meint, beschreibt er die datenbezogene Version.

Workflow Automation dagegen ist kein niedrigeres Level derselben Leiter, sondern etwas Engeres. Automation feuert eine einzelne Aufgabe ab, wenn ein Trigger eintritt. Orchestrierung koordiniert viele Aufgaben über Systeme hinweg, respektiert ihre Abhängigkeiten und weiß, was zu tun ist, wenn eine fehlschlägt. Automation führt eine Aufgabe aus. Orchestrierung führt den Prozess darum herum. Keiner der Begriffe ist ein Synonym für Orchestrierung, die sich über mehrere Kategorien erstreckt.

Was Cross-Domain wirklich bedeutet

Mit Domain ist hier eine Kategorie von Arbeit gemeint: Data Pipelines, Infrastrukturautomatisierung, Geschäftsprozesse, IT- und Infrastruktur-Scheduling. Data Integration lebt in der Datenkategorie. Workflow Orchestration kann Tasks über mehrere Kategorien hinweg in einem Flow koordinieren. Diese Fähigkeit ist mit Cross-Domain gemeint. Es ist eine Fähigkeit, keine Garantie. Viele Orchestratoren laufen nur Data Pipelines, was sie in der Praxis zu Data Orchestratoren macht. Die Kategorie wird dadurch definiert, was Orchestrierung abdecken kann, nicht dadurch, was jede einzelne Bereitstellung zufällig nutzt.

Warum Data Integration und Workflow Orchestration verwechselt werden

Die beiden treffen sich innerhalb der Data Pipeline, und dort kreuzen sich die Drähte. Integrationstools haben eingebaute Scheduler. Ein modernes ETL- oder iPaaS-Produkt kann Jobs auslösen, ein paar Schritte verketten und einen Fehler wiederholen. Das ähnelt Orchestrierung. Orchestratoren bewegen Daten. Eine Workflow-Engine kann eine API aufrufen, eine Transformation ausführen und eine Datei ablegen – unter Verwendung derselben Connectors, die ein Integrationstool verwenden würde. Das ähnelt Integration. Die Data Pipeline ist die Überschneidung. Beide können eine betreiben, aber ihre Reichweite unterscheidet sich. So dringen beide in das jeweils andere Terrain vor, und einige Plattformen sitzen in beiden. Moderne iPaaS-Suiten wie Boomi, MuleSoft und Workato haben echte Orchestrierungsfähigkeiten entwickelt, und viele Teams führen ihre Prozesse dort aus. Die nützliche Frage ist nicht, welches Etikett ein Tool trägt, sondern seine Reichweite. Ein Tool, das seine eigenen Connectors und Jobs koordiniert, deckt eine Kategorie gut ab. Cross-Domain-Orchestrierung reicht weiter: den Daten-Load, die Infrastruktur, auf der er läuft, die Freigabe, die ihn freischaltet, und den Agenten, der auf das Ergebnis reagiert.

Data Integration vs Workflow Orchestration: Vier Dimensionen

Der Artikel unterscheidet zwischen den beiden Konzepten entlang von vier Dimensionen. Das Kernanliegen: Verschieben und Umformen von Daten versus Koordination von Arbeitsabläufen. Die Arbeitseinheit: Datensatz, Stream oder Record versus Task, Workflow oder Prozess. Der Umfang: Daten über Systeme hinweg versus Arbeit über Kategorien hinweg. Das Fehlerbild: falsche, verspätete oder inkonsistente Daten versus eine unterbrochene Sequenz ohne Wiederherstellung. Integration kümmert sich um die Daten, Orchestrierung um die Arbeit.

Operativ oder analytisch? Der Unterschied zieht sich durch beide

Eine weitere Unterscheidung liegt unter all dem. Systeme bedienen zwei Ebenen. Die operative Ebene (Operational Plane) betreibt das Geschäft in Echtzeit: Bestellungen, Zahlungen, Inventar. Die analytische Ebene (Analytical Plane) unterstützt Entscheidungen: Data Warehouses, Lakes, BI, Modelltraining. Integration umfasst beide. Ein latenzunempfindlicher nächtlicher Load in ein Warehouse ist analytische Integration. Ein missionskritischer, niedrig-latenter Event-Stream, der ein Bestellsystem speist, ist operative Integration. Sie verlangen unterschiedliche Garantien. Orchestrierung umfasst ebenfalls beide. Das Planen von Analyse-Pipelines ist nicht dasselbe wie die Koordination eines Zahlungs-Workflows, bei dem ein fehlender Schritt Geld kostet. Ein häufiger Fehler ist, jede Pipeline als missionskritisch zu behandeln oder jeden missionskritischen Flow als einfache Pipeline. Gleiche die Zuverlässigkeit des Tools an die Ebene an, die es bedient.

Wann brauchst du Workflow Orchestration zusätzlich zur Data Integration?

Der eingebaute Scheduler deines Integrationstools reicht aus, solange die Arbeit innerhalb dieses Tools bleibt. Ein paar Pipelines, lineare Abhängigkeiten, Fehler, die du per Hand im Auge behältst. Du bist darüber hinausgewachsen, wenn Abhängigkeiten Systeme kreuzen – zum Beispiel ein Daten-Load, der auf einen Infrastrukturschritt wartet, der wiederum auf eine menschliche Freigabe wartet. Wenn Fehler Logik brauchen: wiederhole dies, überspringe jenes, kompensiere das andere, alarmiere eine Person beim vierten Versuch. Wenn ein einziger Blick (One Pane of Glass) wichtig ist und du jeden Lauf über den gesamten Stack sehen willst, nicht nur ein Tool nach dem anderen. Und wenn die Arbeit Kategorien überspannt – Daten, Infrastruktur, Anwendungen und Agenten im selben Flow.

Das Gegenteil gilt ebenso. Ein Orchestrator kann eine API aufrufen und eine Datei verschieben, aber das ist keine Data-Integrationsplattform. Wenn du zuverlässigen, volumenstarken, konsistenten Datentransport benötigst – mit ausgereiften Connectors, Change Data Capture, Schema-Handling und Transformation – dann willst du eine dedizierte Integrationsschicht. Baue das nicht in deinem Orchestrator nach, nur um Daten zu bewegen. Und wenn deine Integrationsplattform bereits die Prozesse koordiniert, die du ausführst, brauchst du vielleicht gar keinen separaten Orchestrator. Passe das Tool an die Reichweite der Koordination an, nicht an das Etikett auf der Verpackung.

Unified Orchestration: Ein Control Plane für alle Kategorien

Jahrelang bekam jede Kategorie ihren eigenen Koordinator. Ein Data-Team betrieb einen Pipeline-Scheduler. Ein Platform-Team betrieb Infrastrukturautomatisierung. Eine Geschäftseinheit betrieb eine Process Engine. Ein IT-Team betrieb einen Batch-Scheduler, geerbt aus der Mainframe-Ära. Vier Koordinatoren, vier Silo, keine gemeinsame Sicht. Unified Orchestration ist die Idee, dass ein einziges Control Plane die Arbeit über alle diese Kategorien hinweg koordinieren kann. Nicht ein Tool, das alles macht, sondern eine Orchestrierungsschicht, die Data Pipelines, Infrastrukturautomatisierung, Geschäftsprozesse und IT-Scheduling sequenziert – mit gemeinsamer Sichtbarkeit und gemeinsamer Governance. Agentische KI macht diese Entwicklung unvermeidlich. Ein Agent, der Live-Daten liest, einen internen Service aufruft, einen Datensatz aktualisiert und auf eine menschliche Freigabe wartet, berührt jede Kategorie auf einmal. Etwas muss das koordinieren. Ein pro-Kategorie-Scheduler kann das nicht. Unified Orchestration ist eine Kategorierichtung, nicht unbedingt ein einzelnes Produkt. Die Plattformen konvergieren dorthin.

Für den Praktiker bedeutet das: Überlege nicht, ob du ein Integrationstool oder einen Orchestrator brauchst, sondern welche Reichweite deine Koordination haben muss. Der Trend geht zur Vereinheitlichung, aber die Grundlage bleibt das Verständnis der beiden Disziplinen. Data Integration verbindet Systeme – Workflow Orchestration koordiniert die Arbeit darauf. Wer den Unterschied versteht, kann Architekturen bauen, die sowohl korrekte Daten als auch zuverlässige Abläufe liefern. Das Ziel: die richtigen Daten zur richtigen Zeit am richtigen Ort – und die richtigen Arbeitsschritte in der richtigen Reihenfolge, egal ob ein System ausfällt oder ein Mensch erst zustimmen muss.

Quelle: kai-waehner.de

Stell dir vor, du leitest ein Team von Softwareentwicklern. Ihr habt einen Haufen automatisierter Tests, die nach jedem Commit laufen. Bisher hast du Skripte geschrieben, die Tests starten, Ergebnisse sammeln und Fehler melden. Jetzt kommt eine neue Technologie: agentic AI. Damit könnten diese Abläufe vollständig autonom von KI-Agenten gesteuert werden – von der Planung bis zur Fehlerbehebung. Klingt verlockend, oder? Aber sobald man tiefer gräbt, wird klar: Der Erfolg hängt nicht an einem besseren Sprachmodell. Er hängt an der gesamten Infrastruktur, die diese Agenten umgibt.

Intel hat das genau untersucht. In tausenden Experimenten mit agentischen KI-Workloads haben sie fünf praktische Lektionen extrahiert. Relevant für jeden, der agentic AI im Unternehmen produktiv einsetzen will. Intel hat nicht nur die reine Inferenzleistung gemessen, sondern das gesamte System – Orchestrierung, Datenzugriff, Tool-Ausführung und Skalierung. Die Ergebnisse sind eine Art Bauplan für die Enterprise-Umgebung von morgen.

Was ist agentic AI wirklich?

Agentic AI ist mehr als nur ein Chatbot mit Zugriff auf eine Datenbank. Es sind Software-Agenten, die eigenständig komplexe Geschäftsprozesse Ende-zu-Ende ausführen. Ein typischer Agent plant einen mehrstufigen Auftrag, ruft verschiedene Tools und APIs auf, liest Zwischenergebnisse und wiederholt Schritte, wenn etwas schiefgeht. Erinnert an einen virtuellen Kollegen, der nicht nur denkt, sondern handelt. Im Kern ist agentic AI eine Workflow-Automation auf KI-Basis – aber die meiste Zeit verbringt ein Agent nicht mit Denken, sondern mit Warten auf Antworten von Datenbanken, APIs und anderen Systemen. Genau das macht die Infrastruktur so entscheidend.

Die fünf Lektionen aus Intels Experimenten

1. Agentic AI ist ein Systemproblem, kein reines Inference-Problem

Die erste Erkenntnis: Die Performance eines Agenten hängt nicht allein von der Geschwindigkeit des Sprachmodells ab. Intels Experimente zeigten, dass die meiste Zeit für Orchestrierung, Datenzugriff und Tool-Ausführung draufgeht – das LLM ist nur ein Teil des Puzzles. Wer die Infrastruktur nur nach der Inferenzleistung optimiert, übersieht die Engpässe bei der Workflow-Ausführung. Stell dir einen Flughafen vor: Die beste Startbahn nützt nichts, wenn die Gepäckabfertigung oder die Sicherheitskontrollen stocken. Bei agentic AI muss die gesamte Kette stimmen.

2. Die meisten Benchmarks messen das Falsche

Gängige Metriken für agentic AI konzentrieren sich auf die Qualität des LLMs – etwa Genauigkeit oder BLEU-Scores. Für den Enterprise-Einsatz reicht das nicht. Intel schlägt sechs praxisrelevante Metriken vor: Task-Erfolgsrate, Kosten pro Aufgabe, Zeit pro Aufgabe, Durchsatz (Anzahl abgeschlossener Aufgaben pro Zeit), Agentendichte (Anzahl Agenten pro virtuellem CPU-Kern) und Latenz (insbesondere die 95. Perzentil-Latenz). Diese Kennzahlen beantworten Fragen, die ein IT-Leiter wirklich stellt: Läuft das System wie erwartet? Wie viele Agenten kann ich gleichzeitig betreiben? Wie muss ich skalieren, wenn die Last steigt?

3. Plane mit Agentendichte, nicht mit Agentenzahl

Eine praktische Lektion: Statt zu fragen „Wie viele Agenten passen auf einen Server?“, betrachte die Agentendichte – die Anzahl der Agenten pro virtuellem CPU-Kern (vCPU). Das ist wie bei einem Büro: Die reine Mitarbeiterzahl sagt wenig, wenn man nicht weiß, wie viel Platz und Equipment jeder benötigt. Ein System mit 8 vCPUs und 10 Agenten verhält sich ähnlich wie ein System mit 16 vCPUs und 20 Agenten, wenn die Dichte gleich ist. Die richtige Dichte hängt vom Einsatzzweck ab: Interaktive Assistenten (z.B. Chatbots) brauchen niedrige Dichte, weil schnelle Antworten wichtig sind. Batch-Workloads (z.B. automatisierte IT-Aufgaben) vertragen höhere Dichte. Das gibt Teams ein praktisches Werkzeug, um Kosten und Performance auszutarieren.

4. Überwache die Task-Latenz, nicht nur die CPU-Auslastung

Agenten arbeiten oft in Stößen: Sie warten auf eine Modellantwort, führen dann kurz intensive Berechnungen durch, warten wieder, und so weiter. Durchschnittliche CPU-Auslastung kann dabei völlig normal aussehen, selbst wenn die Wartezeiten die Nutzererfahrung ruinieren. Intel empfiehlt, die Task-Latenz im 95. Perzentil (P95) als Frühwarnsignal zu nutzen. Wenn die Latenz steigt, wissen Betreiber sofort, dass die Workflows in die Warteschleife geraten – noch bevor sich die durchschnittliche Bearbeitungszeit verschlechtert. Das ist wie bei einer Ampel: Die durchschnittliche Wartezeit aller Autos sagt wenig aus, wenn einzelne Fahrer ewig stehen. Die P95-Latenz zeigt dir die echten Staus.

5. Default zu Scale-out, nicht Scale-up

Die letzte Lektion betrifft die Skalierung. Scale-out bedeutet, mehr Server hinzuzufügen. Scale-up bedeutet, einen einzelnen Server mit mehr Kernen oder Arbeitsspeicher aufzurüsten. Intels Daten zeigen: Scale-out ist meist die bessere Wahl. Agenten sind halbunabhängig und verursachen nur moderate Lastspitzen – das passt perfekt zu vielen kleineren Systemen. Scale-out verbessert die Gesamtperformance, erhöht die Ausfallsicherheit und senkt oft die Kosten. Zudem lässt sich die gewünschte Agentendichte leichter einhalten. Scale-up sollte man nur dann einsetzen, wenn Agenten rechenintensive Bursts haben, wenn sie gemeinsamen Speicher benötigen oder Lizenzmodelle es vorgeben. Faustregel: Skaliere horizontal, es sei denn, du hast einen guten Grund dagegen.

Die drei Phasen des Aufbaus

Intel fasst die Erkenntnisse in drei Phasen zusammen, die Unternehmen bei der Einführung von agentic AI durchlaufen sollten. Zuerst planen: nicht die Anzahl der Agenten, sondern die Dichte pro vCPU bestimmen. Dann beobachten: mit P95-Latenz als Leitmetrik und nicht mit Durchschnittswerten. Und schließlich skalieren: standardmäßig horizontal wachsen, nur bei speziellen Anforderungen vertikal. Dieser Dreiklang gibt einen klaren Fahrplan für den Weg vom Pilotprojekt zur Produktion.

Wo entsteht der größte Business-Value?

Organisationen, die mit agentic AI bereits echte Ergebnisse erzielen, setzen es dort ein, wo es bereits codierte Regeln und messbare Service-Level gibt. Typische Beispiele: Code-Erstellung, Regression-Test-Farmen, Ticket-Triaging, Marktanalysen und Security-Reviews. Die ideale Persona für agentic AI ist nicht der experimentierfreudige Enthusiast, sondern der verantwortungsbewusste Manager, der Zykluszeiten verbessern, Produktivität steigern, Servicequalität schützen und Kosten kontrollieren muss. Agentic AI liefert dann Wert, wenn es echte Arbeit quer durch Teams, Systeme und Prozesse erledigt – zuverlässig und skalierbar.

Was bedeutet das konkret?

Wer heute in agentic AI investiert, sollte nicht nur auf ein besseres Sprachmodell hoffen. Der Erfolg steht und fällt mit der Infrastruktur: mit der Fähigkeit, Agenten zu orchestrieren, ihre Latenz zu überwachen, die Dichte zu planen und horizontal zu skalieren. Intels Experimente sind kein Marketing, sondern eine solide technische Richtschnur. Sie zeigen, dass die „magische“ KI vor allem harte Systemarbeit braucht – und dass die Prinzipien, die wir aus dem Betrieb verteilter Systeme kennen, auch für die Agenten-Welt gelten. Wer diese Lektionen ernst nimmt, wird agentic AI nicht als Hype, sondern als nächsten logischen Schritt der Automatisierung in sein Unternehmen integrieren.

Quelle: technologyreview.com

Warum Roboter nicht einfach aus dem Internet lernen können

Einem Menschen beibringen, zu kochen: Man gibt ihm Kochbücher, zeigt Videos, lässt ihn nachmachen und korrigiert Fehler. Jede Methode liefert andere Informationen – Theorie, Bewegung, haptische Rückmeldung. Beim Training von Robotern mit Künstlicher Intelligenz ist es ähnlich. Sprachmodelle schöpfen aus Milliarden Texten im Internet – einem kostenlosen, von der Menschheit gesammelten Übungskorpus. Für Roboter gibt es keinen vergleichbaren Datenberg. Es existiert kein „YouTube für Roboteraktionen“, aus dem ein System die optimale Greifbewegung extrahieren könnte. Dieses Datenproblem ist der zentrale Flaschenhals für eine physische Allgemeine Künstliche Intelligenz (AGI) – Roboter, die flexibel in unserer unordentlichen Welt agieren. Die Robotik-Forschung setzt auf eine kluge Kombination verschiedener Datenquellen, eine Art Datenpyramide, die das Beste aus jedem Bereich zusammenbringt.

Die Pyramide als roter Faden

Stell dir eine Pyramide vor: Die Basis besteht aus massenhaft vorhandenen, aber wenig spezifischen Daten – etwa Webvideos. Je höher man klettert, desto teurer und aufwendiger wird die Datensammlung, aber desto präziser und näher an der echten Roboter-Hardware. An der Spitze stehen die begehrtesten Daten: echte Robotereinsätze in Fabriken oder Haushalten. Das NVIDIA-Team GR00T hat dieses Modell vorgeschlagen, die Community griff es auf. In diesem Beitrag tauchen wir tiefer in den Datenengpass ein und betrachten eine erweiterte Version dieser Pyramide mit sieben konkreten Datentypen, gegliedert in drei Kategorien: Webdaten, synthetische Daten und echte Roboter-Daten. Der Autor Tanay Jaipuria, Partner bei Wing und Verfasser eines Newsletters über die Technologieindustrie, beschreibt, wie die Robotik-Forschung diesen Engpass zu überwinden versucht.

Ebene 1: Webdaten – Die Millionen-Stunden-Quelle, die kaum genutzt wird

Die unterste Ebene der Pyramide ist die breiteste: das gesamte öffentlich zugängliche Videomaterial im Internet. Auf YouTube kommen jährlich rund 300 Millionen Stunden Videomaterial hinzu – Menschen, die kochen, putzen, montieren, reparieren. Dieses Rohmaterial ist nicht angereichert, es fehlen Tiefeninformationen, Kraftrückmeldungen oder präzise Handpositionen. Trotzdem kann es einem Modell grundlegende Konzepte beibringen: Was ist ein Teller? Wie sieht eine Greifbewegung aus? In welcher Umgebung findet eine bestimmte Tätigkeit statt? Bislang fließen diese Daten meist nur indirekt ein – über vortrainierte Sprach-Bild-Modelle, die als Grundlage für Robotersysteme dienen. Doch es gibt konkrete Versuche, den Schatz direkt zu heben. NVIDIA arbeitet an DreamZero, einer Methode, die eine auf Internet-Videos vortrainierte Videogenerierung direkt in eine Roboter-Policy einbaut. Das Startup Rhoda AI geht noch einen Schritt weiter: Es trainiert zunächst auf Hunderten Millionen Internet-Videos und passt das Modell dann mit nur 10 bis 20 Stunden echter Roboter-Daten auf eine spezifische Maschine an. Ein Kochlehrling sieht erst tausend Kochshows und braucht dann nur eine kurze praktische Anleitung, um ein bestimmtes Gericht zu perfektionieren.

Ebene 2: Egocentrische Humanvideos – Die Perspektive des Handelnden

Einen Schritt weiter oben in der Pyramide liegen Videos aus der Ich-Perspektive, aufgenommen mit am Kopf befestigten Kameras. Seit etwa einem Jahr kaufen viele Robotik-Labore gezielt solche Aufnahmen ein. Offene Datensätze wie Egoverse und Ego4D enthalten tausende Stunden Material, in denen Menschen alltägliche Aufgaben in Haushalten oder Fabriken verrichten. Die Kamera blickt aus der Perspektive der Hände, die die Arbeit machen, und liefert damit eine ähnliche visuelle Information, wie sie auch ein Roboter mit seiner Kamera sehen würde. Forschungsarbeiten haben gezeigt: Modelle, die auf sorgfältig gefilterten egozentrischen Humanvideos vortrainiert wurden, schneiden besser ab als solche, die auf der gleichen Menge an teleoperierten Roboterdaten trainiert wurden – vorausgesetzt, beide werden anschließend auf den Zielroboter adaptiert. Ein Mensch, der etwas tut, liefert scheinbar nützlichere Trainingssignale als ein Roboter, der dieselbe Aktion ausführt. Der Grund liegt in der Vielfalt und Natürlichkeit der menschlichen Bewegung, die der Roboter später nachahmen soll.

Ebene 3: Angereicherte ego-/exocentrische Daten – Vom rohen Video zum strukturierten Datensatz

Manchmal reicht ein einfaches Video nicht aus. Dann wird das egozentrische Material mit zusätzlichen Informationen angereichert: Hand-Pose-Tracking, Tiefenkameras, Blickrichtung (Gaze-Tracking) oder sogar vollständige Motion-Capture-Anzüge, die jede Gelenkbewegung aufzeichnen. Der Datensatz Ego-Exo4D enthält rund 1.400 Stunden sowohl aus der Ich- als auch aus der Dritten-Person-Perspektive von anspruchsvollen Tätigkeiten. Auch Tesla hat Arbeiter in Motion-Capture-Anzüge gesteckt, um präzise Bewegungsdaten zu sammeln. Je nach Detailgrad der Anreicherung – manche Labore erfassen sogar taktile Kräfte – können diese Daten die Lücke zwischen menschlicher Demonstration und Roboterausführung deutlich verkleinern. Die Datensammlung wird aufwendiger und teurer, skaliert aber immer noch besser als echte Roboterdaten.

Ebene 4: UMI-Daten (Universal Manipulation Interface) – Der Mensch als Roboter-Stellvertreter

Eine besonders clevere Methode ist der Universal Manipulation Interface (UMI). Ein Mensch trägt am Ende seines Arms oder in der Hand ein End-Effector-Werkzeug – den Greifer oder die Hand, die später der Roboter verwenden soll. Der Mensch führt die Aufgaben aus, während das System Bewegungen und Kräfte aufzeichnet. Der Vorteil: Du sammelst Daten, die fast so aussehen, als kämen sie vom echten Roboter, ohne den Roboter selbst zu benötigen. Das Startup Sunday Robotics, gegründet von den UMI-Erfindern, verschickt eigens entwickelte Greifhandschuhe an Freiwillige nach Hause. Diese Handschuhe sind kodesigniert mit den Roboterhänden des Unternehmens. So hat Sunday Robotics sein Modell ACT-1 auf rund zehn Millionen Haushalts-Episoden trainiert – ohne eine einzige Sekunde echte Roboter-Teleoperation. Auch das Toyota Research Institute setzt auf UMI, kombiniert mit Teleoperation und Simulation, um seine Large Behavior Models zu trainieren.

Ebene 5: Simulierte und synthetische Daten – Die grenzenlose, aber unperfekte Welt

Ein weiterer Zweig der Pyramide sind simulierte Daten aus Physik-Engines wie Isaac Sim oder MuJoCo. Theoretisch sind nur die Rechenkapazität Grenzen gesetzt: Du kannst Millionen von virtuellen Umgebungen generieren, in denen der Roboter trainieren kann, ohne dass ein physischer Roboter abgenutzt wird oder riskante Manöver ausführt. In der Praxis klafft jedoch die sogenannte Sim-to-Real-Lücke: Was in der Simulation perfekt funktioniert, überträgt sich oft nicht eins zu eins in die reale Welt. Besonders bei Manipulationen von weichen Objekten oder bei komplexen physikalischen Interaktionen stoßen Simulatoren an ihre Grenzen. Neue Entwicklungen wie Weltmodelle – etwa NVIDIAs Cosmos oder Googles Genie 3 – versuchen, diese Lücke zu schließen, indem sie als gelernte Simulatoren agieren, die aus echten Daten gelernt haben, wie die Welt funktioniert. Die Autonome-Fahrzeug-Industrie, etwa Waymo, hat gezeigt, dass Simulation ein mächtiges Werkzeug sein kann, um Fahrsituationen milliardenfach zu trainieren. Für Roboter in Haushalten oder Fabriken ist diese Technik noch nicht reif für den breiten Einsatz – der Fortschritt ist rasant.

Ebene 6: Teleoperierte Roboterdaten – Präzise, aber teuer

Ein Schritt weiter oben steht die Teleoperation. Ein menschlicher Operator steuert den Roboter in Echtzeit, entweder über ein VR-Set oder über einen mechanischen Nachführarm (Rig). Der Roboter kopiert jede Bewegung des Menschen millimetergenau. Das Ergebnis sind extrem hochwertige, embodiment-spezifische Daten – sie stammen exakt von der Hardware, die später auch autonom fahren soll. Der Haken: Teleoperation ist teuer. Die Kosten liegen bei über 100 Dollar pro Stunde, benötigen geschulte Operateure und sind durch die Anzahl der Roboter und Umgebungen begrenzt. Sergey Levine, führender Kopf bei Physical Intelligence, hat in einem Podcast die Spannung beschrieben: Einerseits ist Teleoperation die sicherste Methode, um Daten ohne Übersetzungsverlust zu sammeln, andererseits kaum skalierbar. Die allgemeine Meinung in Laboren: Teleoperation wird nie ganz verschwinden, aber ihr Anteil am Trainingsmix könnte sinken, wenn andere Quellen besser werden. Vielleicht wird Teleoperation künftig vor allem in der Feinabstimmung (Post-Training) eingesetzt, während die groben Fähigkeiten aus billigeren Daten stammen.

Ebene 7: Echte Robotereinsätze – Der heilige Gral, aber das Henne-Ei-Problem

An der Spitze der Pyramide stehen die begehrtesten Daten: echte Roboter, die reale Arbeit in realen Umgebungen verrichten – idealerweise bezahlte Arbeit. Der Roboter läuft entweder vollständig autonom, oder ein menschlicher Teleoperator greift nur dann ein, wenn das System überfordert ist (wie ein Sicherheitsfahrer bei autonomen Autos). Das Problem: Bevor man einen Roboter einsetzen kann, muss er schon gut genug sein, um nicht ständig Hilfe zu brauchen. Ein klassisches Henne-Ei-Problem. Über die Zeit könnten diese Einsätze zu einem sich selbst verstärkenden Kreislauf führen: Mehr Deployments erzeugen mehr Daten, die die Leistung verbessern und weitere Deployments ermöglichen. In der Praxis ist die Anzahl heutiger Robotereinsätze außerhalb stark strukturierter Umgebungen – Fabriken oder autonome Fahrzeuge – noch sehr gering. Zwei wichtige Einschränkungen: Erstens helfen Daten von extrem engen Aufgaben in gleichbleibender Umgebung kaum für die Generalisierung auf andere Tätigkeiten. Zweitens werden viele frühe Deployments als Hybridsystem laufen: Der Roboter arbeitet autonom, und ein Teleoperator übernimmt bei Fehlern. Diese Form des Interventions-Lernens ist praktisch und liefert wertvolles Datenmaterial über Fehlschläge und deren Korrektur. Eine bekannte Methode ist DAgger (Dataset Aggregation), bei der die Policy aus den Korrekturen des Menschen lernt. Ansätze wie Sirius oder HIL-SERL bauen darauf auf und zeigen, dass dieses Feedback die Datenqualität enorm steigern kann.

Was bedeutet das konkret? – Eine geerdete Einordnung

Niemand weiß heute, wie viel Roboterdaten ausreichen, um eine robuste allgemeine Roboterintelligenz zu erreichen. Sergey Levine hat in dem erwähnten Podcast ehrlich gesagt: „Das ist es ja – wir wissen es nicht.“ Ob Roboter das Hundertfache oder Tausendfache der heutigen Datenmenge brauchen, bleibt offen. Für ein Robotik-Team, das ein konkretes Produkt bauen will, stellt sich die Frage pragmatischer: Welche Zuverlässigkeit ist nötig, um einen bestimmten Satz von Aufgaben in einer hybriden Umgebung zu bewältigen? Welche Mischung aus den sieben Datenquellen ist die kostengünstigste, um diese Schwelle zu überschreiten? Die Antwort wird je nach Anwendungsfall variieren. In der Medizinrobotik mag Teleoperation und hochangereichertes Egocentric-Daten dominieren, in der Logistik könnten synthetische Daten und Webvideos ausreichen. Einen Königsweg gibt es nicht. Die Zukunft gehört Teams, die klug die verschiedenen Ebenen der Datenpyramide kombinieren – vom billigen Webvideo bis zum teuren Roboter-Deployment – und dabei nie aus den Augen verlieren, dass jedes Datum seinen Preis und seinen Wert hat. Wie beim Handwerk: Wer nur aus Büchern lernt, kann nicht kochen. Wer nur von einem Meister beobachtet wird, entwickelt nie ein Eigenverständnis. Wer nur aus Fehlern lernt, verbrennt sich am Herd. Die Robotik braucht alle drei – in der richtigen Dosis.

Fazit für den Alltag: Was bedeutet das für dich?

Wenn du das nächste Mal ein Video von einem Roboter siehst, der einen Teller aufhebt oder ein Paket stapelt, denk daran: Hinter dieser scheinbar simplen Bewegung steckt ein komplexer Daten-Cocktail aus Millionen von Stunden Videomaterial, Simulationen, menschlichen Demonstrationen und vielleicht sogar echtes Geld für Teleoperation. Die KI-Technologie hinter modernen Robotern ist nicht nur eine Frage von Algorithmen und Rechenleistung, sondern vor allem eine Frage des Zugangs zu den richtigen Daten. Und weil diese Daten nicht einfach im Internet liegen wie Texte, sind clevere Ingenieure und Unternehmer gefragt, die neue Wege finden, sie zu sammeln. Es bleibt spannend, welche dieser Methoden sich durchsetzen wird. Eines ist sicher: Der Wettlauf um die Datenpyramide hat gerade erst begonnen.

Quelle: tanayj.com

Du kaufst ein Auto mit 600 PS, aber die Karosserie ist aus Pappe, die Lenkung schwammig und die Bremsen sind Spielzeug. Damit gewinnst du kein Rennen. So ist es auch mit KI-Agenten. Viele konzentrieren sich nur auf das Modell – GPT, Claude oder Llama – und vergessen, dass die Umgebung, in der das Modell agiert, ebenso wichtig ist. Dieses Grundgerüst nennen Fachleute den Harness. Ein Forscherteam von NVIDIA zeigt: Allein die Architektur dieses Harness kann ein Modell doppelt so gut abschneiden lassen – bei halbem Token-Verbrauch. Das klingt übertrieben. Aber schauen wir uns die Details an.

Das Team um NVIDIA Labs hat NOOA veröffentlicht – NVIDIA Object-Oriented Agents. Die Idee ist einfach, aber mächtig: Ein Agent ist kein komplexes Geflecht aus Prompt-Vorlagen, Tool-Schemas, Callback-Code und Workflow-Graphen mehr. Stattdessen wird er zu einem einzigen Python-Objekt. Seine Methoden sind seine Fähigkeiten, seine Felder sein Zustand, seine Docstrings seine Prompts, und seine Typannotationen durchgesetzte Verträge. Du schreibst eine Klasse mit einer Methode, die nur aus ... (Ellipsis) besteht. Diese Methode wird zur Laufzeit von einem LLM-gesteuerten Loop ausgefüllt. Methoden mit einem normalen Rumpf laufen deterministisch. Das bedeutet: Agentenentwicklung wird zu normaler Softwareentwicklung. Du kannst einen Agenten differenzieren, code-reviewen, unit-testen, versionieren und umgestalten – von Menschen und von KI-Coding-Agenten, mit denselben Werkzeugen wie für jeden anderen Code.

Sechs konkrete Schnittstellen-Ideen treiben das NOOA-Harness an. Sie sind wie die Zylinder eines Motors – jeder trägt zur Gesamtleistung bei. Gehen wir sie durch.

1. Typisierte Ein- und Ausgabe. Statt Freitext zu produzieren und auf einen korrekten Parser zu hoffen, werden alle Aufrufe mit getypten Argumenten und validierten Rückgabewerten ausgeführt. Fehler werden früh abgefangen.

2. Referenzübergabe (Pass by Reference). Bisher wurde jedes Tool-Ergebnis als Text in den Kontext geschrieben – bei großen Dateien explodiert der Token-Verbrauch. NOOA übergibt dem Modell einen Live-Verweis auf das Python-Objekt. Das Modell sieht eine typisierte, begrenzte Vorschau, der volle Wert bleibt im Ausführungskontext lebendig. Das spart Tokens und beschleunigt die Verarbeitung.

3. Code als Aktion. Das Modell handelt, indem es Python schreibt: Methodenaufrufe, Kontrollstrukturen, Variablen – wie ein Entwickler. Keine brüchigen JSON-Schemas, sondern ausführbarer Code in derselben Umgebung wie der Agent.

4. Programmierbare Schleifensteuerung. Die Orchestrierungsschleifen sind normales Python. Der Entwickler kann sie schreiben, aber auch das Modell selbst kann sie anpassen. Das gibt Flexibilität wie bei menschlichen Programmierern.

5. Expliziter Objektzustand. Der Zustand eines Agenten lebt nicht nur im Gesprächsverlauf, sondern in dauerhaften, getypten Feldern auf dem Objekt. Der Agent kann sich Dinge merken, auch wenn der Kontext abgeschnitten ist. Dieser Zustand ist versionierbar und testbar.

6. Vom Modell aufrufbare Harness-APIs. Kontextblöcke und Ereignishistorien sind nicht verborgen. Das Modell kann sie über API-Aufrufe inspizieren und verwalten. Es kann seine eigene Erinnerung kuratieren – gezielt schreiben, abfragen und korrigieren. Statt einer undurchsichtigen Blackbox gibt es einen transparenten, steuerbaren Speicher.

Dieser Speicher ist ein weiteres Kernstück von NOOA. Statt automatischer Hintergrund-Zusammenfassung gibt es einen Langzeitspeicher, den der Agent selbst verwaltet. Aufzeichnungen tragen Typen, Wichtigkeit und Tags. Sie sind über Beziehungen wie „unterstützt“, „widerspricht“ und „abgeleitet von“ in einem Wissensgraphen vernetzt. Eine Hintergrund-Reflexion konsolidiert den Speicher: Duplikate werden zusammengeführt, verwandte Aufzeichnungen verknüpft, Episoden zu Erkenntnissen destilliert und irrelevante Informationen entfernt. Das alles passiert in einer menschenlesbaren SQLite-Datei, die Teams inspizieren, sichern und mit Standardpraktiken überprüfen können. Mehrere Agenten können sich einen Speicher teilen, während sie getrennte Besitzverhältnisse behalten. In der ARC-AGI-3-Auswertung verbesserte das System die RHAE um +11,8 Punkte gegenüber dem gleichen Agenten mit dateibasierten Notizen.

Die Ergebnisse: Auf SWE-bench Verified erreicht NOOA mit GPT-5.5 82,2% – über dem bisherigen Spitzenwert von 79,2%. Mit Opus 4.6 sind es 79,8%. Und das mit einem allgemeinen, 253-zeiligen Agenten ohne benchmarkspezifische Prompts. Im Cybersicherheitsbereich CyberGym L1 löst NOOA 86,8% der Aufgaben mit GPT-5.5 – der Spitzenwert unter offenen Agenten, noch vor den meisten führenden geschlossenen Systemen. Der Agent hatte keinen Netzwerkzugriff, und eine regelbasierte „Cheat-Prüfung“ lief über jede Trajektorie. Die Ergebnisse stammen aus logischem Denken über den Code, nicht aus dem Nachschlagen bekannter Schwachstellen. Keine cybersicherheitsspezifische Steuerung wurde verwendet. Bei allgemeinem logischem Denken auf ARC-AGI-3 erreicht ein einzelner NOOA-Agent 50,2% mittlere RHAE mit GPT-5.5 und 85,1% mit GPT-5.6-sol – zu Kosten unter 20 Dollar pro Spiel.

Die Effizienz ist bemerkenswert. NOOA benötigt auf SWE-bench Verified nur 29 LLM-Aufrufe und etwa 1,1 Millionen Tokens pro Aufgabe. Vergleichbare Harnesses kommen auf 66 Aufrufe und 2,2 Millionen Tokens bei niedrigerer Genauigkeit. Das halbiert die Kosten bei gleicher oder besserer Leistung. Zwei Mechanismen treiben das: die Referenzübergabe (Tool-Ergebnisse werden nicht in den Kontext serialisiert) und die daraus resultierende Vermeidung von Context Compaction. Weil die Ergebnisse live bleiben, sind Transkripte append-only und Cache-tauglich über die gesamte Sitzung.

Stell dir vor, du musst ein kniffliges Problem lösen. Statt jedes Mal das gesamte Handbuch neu zu lesen, hast du einen Assistenten, der dir nur die relevanten Seiten zeigt und dir erlaubt, direkt mit den Werkzeugen zu arbeiten. Genau das macht NOOA. Der Entwickler kann deterministische Prüfungen und Modelllogik auf einem einzigen getypten Objekt vereinen – jeder Verifikationsschritt läuft als erzwungener Code, nicht als lose Anweisung.

Das Team hat NOOA als offene Forschungsvorschau veröffentlicht. Framework, Tests, Benchmark-Agent und Evaluierungsmethodik sind öffentlich. Teams können den Ansatz überprüfen und darauf aufbauen. Die Botschaft: Der Harness eines Agenten ist kein nachrangiges Detail. Er ist der entscheidende Hebel, um aus einem guten Modell einen herausragenden Agenten zu machen. Alles, was du dafür brauchst, ist Python, etwas Objektorientierung und die Bereitschaft, über das reine Modell-Tuning hinauszuschauen.

Quelle: developer.nvidia.com

Man kauft keinen teuren Kühlschrank nur für Milch. Der Kühlschrank funktioniert, aber nach ein paar Monaten merkt man: Die Milch bleibt auch in einer Kühlbox frisch. Genau das ist dem TanStack-Team mit React Server Components (RSC) passiert. Sie kehrten zu klassischem Server-Side Rendering (SSR) zurück.

Tanner Linsley, Kopf hinter TanStack, beschrieb den Wechsel auf dem offiziellen Blog. Eine pragmatische Entscheidung, basierend auf harten Daten, nicht auf Hype. Sie wirft eine Frage auf: Wann ist ein neues Werkzeug die richtige Wahl – und wann wird es zum Hindernis?

Der Anfang: RSC als Retter

Vor Monaten war tanstack.com ein RSC-Paradebeispiel. Die Seite war content-lastig – Blogposts, Docs, Codebeispiele. Problem: Jeder Seitenaufruf lud ein schweres Markdown- und Syntax-Highlighting-Paket in den Browser. Rund 1,1 MiB JavaScript pro Docs-Seite, davon 358 KiB für Shiki und Begleiter. Eine unnötige Last für den Browser.

RSC schien die Lösung. Statt den schweren Renderer zum Client zu schicken, rendert man Markdown und Highlighting auf dem Server, schickt fertiges HTML (Flight-Payload). Der Browser hat weniger Arbeit. Die Performance-Sprünge waren beeindruckend: Total Blocking Time fiel von 1.200 ms auf 260 ms, Transfergröße von 1.101 KiB auf 785 KiB. Lighthouse-Scores gingen hoch. RSC hielt sein Versprechen.

Die unerwartete Einsicht

Im Alltag zeigte sich die Komplexität. Linsley beschreibt, wie die Content-Pipeline immer mehr Schichten bekam: Markdown wurde zu JSX in server-only Dateien, JSX zu Flight-Payload, Route-Komponenten empfingen contentRsc – ein fast unkenntlicher Wert. Jede Änderung erforderte Wissen über Runtime-Grenzen, Bundler-Konfiguration, spezielle Dateien. Nicht unmöglich, aber unnötig aufwendig.

Der entscheidende Moment: Das Team entfernte Drittanbieter-Anzeigen von der Seite. Plötzlich war der größte Übeltäter nicht das Ad-Tracking, sondern der Content selbst. Die Frage: Brauchen wir wirklich 358 KiB für Syntax-Highlighting? Oder geht es einfacher?

Der Bau eines schlankeren Werkzeugs

Das Team entwickelte zwei eigene Pakete: @tanstack/markdown und @tanstack/highlight. Klein, spezifisch, auf die Anforderungen von tanstack.com zugeschnitten. Kein Generalistenwerkzeug, sondern Spezialwerkzeuge. Ergebnis: Statt 358 KiB wanderten nur noch etwa 27 KiB zum Client – kein Grund mehr für eine ganze RSC-Architektur.

Der Trade-Off wurde klar: RSC löste ein Abhängigkeitsproblem durch Architektur. Nachdem die Abhängigkeit schrumpfte, blieb die Architektur mit ihren Kosten: spezielle Routen, Flight-Serialisierung, Server-only-Komponenten, verzwickter Context.

Zurück zu SSR – und die Ergebnisse

Das Team entfernte die RSC-Content-Pipeline. Der Migrations-Commit 92b1c481 löschte oder benannte neun Dateien für RSC-spezifische Content-Rohre um, plus acht alte Rendering-Plugins. Insgesamt 555 Zeilen RSC-Code und 994 Zeilen alte Renderer flogen raus. Der Content-Pfad wurde einfach: Serverfunktionen geben Content-Daten zurück, eine Markdown-Komponente rendert lokal.

Die Performance auf den wichtigsten Routen:

• /blog/react-server-components: RSC: 76 Lighthouse, 139 ms TBT, 1.086 KiB / SSR: 67 Lighthouse, 66 ms TBT, 889 KiB
• /router/latest/docs/overview: RSC: 71 Lighthouse, 209 ms TBT, 1.017 KiB / SSR: 71 Lighthouse, 115 ms TBT, 836 KiB

Der Lighthouse-Score beim Blog ist etwas niedriger, aber Bytes und TBT sind besser. Der Renderer wiegt jetzt etwa 27 KiB – ein Bruchteil des alten Shiki-Stacks. Der Vorteil zeigt sich bei wiederholten Seitenaufrufen.

Warum sechs Seiten den Unterschied machen

Beim ersten Aufruf lädt SSR den Renderer einmal. Danach nur noch reine Daten (Markdown, Quelldaten) – nicht den gerenderten Komponentenbaum. RSC hingegen schickt bei jeder Navigation erneut ein serialisiertes Flight-Payload mit dem gesamten Server-Teil.

Lokale Tests: Für einen Blogpost sparte SSR 5,6 KiB pro Anfrage gegenüber RSC. Bei sechs Seiten pro Session (Durchschnitt auf tanstack.com) multipliziert sich das. Einmal 27 KiB für den Renderer zahlen, dann jedes Mal sparen – eine lohnende Wette. RSC verwandelte eine einmalige Client-Abhängigkeit in wiederkehrende serialisierte Ausgabe. Sinnvoll bei großer Abhängigkeit, nicht nach Verkleinerung.

Die Lektion: Wann ist RSC wirklich die richtige Wahl?

Linsley selbst sagt: RSC löst ein Problem, wenn die Server-Abhängigkeit riesig ist. Ein schwerer Markdown-Renderer, eine große Grafikbibliothek, ein komplexer Parser. Sobald die Abhängigkeit verkleinert ist, entfällt die Rechtfertigung für die Komplexität.

Erkenntnis: Tool-Entscheidungen basieren auf Messungen, nicht auf Trends. RSC ist kein Selbstzweck. Die TanStack-Geschichte zeigt: Nach dem ersten Erfolg lohnt es sich zu fragen: War das nötig? Wie sieht der Preis im Alltag aus?

Für viele Projekte ist RSC perfekt. Für content-lastige Seiten mit kontrollierten Abhängigkeiten ist klassisches SSR mit eigenen Paketen oft einfacher und schneller. Devise: Verstehe dein Problem, miss deine Lösung, und tausche den Kühlschrank gegen eine Kühlbox.

Quelle: tanstack.com