Ihr KI-Problem ist vermutlich nicht die Rechenleistung. Sondern das Netzwerk, das Sie nicht mehr hinterfragen.  

24/02/2026
Sonja Berghman
Sonja Berghman, Group Proposition Manager Enterprise Networks

Es gibt eine stille Annahme, die viele von uns in KI-Projekte mitnehmen. Wenn die Performance schwach ist, wenn Jobs länger dauern als erwartet, wenn die Kosten schneller steigen als geplant, dann muss die Antwort mehr Rechenleistung sein. Mehr GPUs. Größere Cluster. Schnellere Beschleuniger. 

Manchmal stimmt das. Oft jedoch nicht.

Oft steht etwas anderes im Weg. Das Netzwerk. Nicht, weil es defekt wäre, sondern weil es als gelöstes Problem betrachtet wurde. Und KI ist sehr gut darin, Probleme offenzulegen, von denen wir dachten, wir hätten sie längst gelöst.

KI-Workloads verhalten sich anders. Sie bewegen Daten seitlich und nicht nur Nord–Süd. Training und Inferenz erzeugen intensiven East–West-Traffic zwischen GPUs. Latenzspitzen, die früher tolerierbar waren, werden plötzlich relevant. Engpässe, die früher selten auftraten, werden zum konstanten Hintergrundrauschen. Das Netzwerk hört auf, unsichtbar zu sein, und beginnt, Ergebnisse zu beeinflussen.

Dieser Wandel ist unangenehm. Besonders, wenn stark in Rechenleistung investiert wurde und man erwartet hat, dass der Rest schon mithalten wird. 

Was sich jedoch zunehmend zeigt, ist ein recht konsistentes Muster. In Unternehmensumgebungen wird KI-Performance heute weniger durch reine Rechenleistung begrenzt als durch die Effizienz, mit der Daten zwischen Systemen bewegt werden. Die Forschung hinter AI Strategy 2025–2028: The Ethernet Advantage macht diesen Punkt deutlich, auch wenn sie es nicht ganz so direkt formuliert.

Und es wirft eine noch unangenehmere Frage auf: Haben wir möglicherweise das Falsche optimiert?

 

Warum das gerade jetzt passiert

KI ist aus dem Pilotmodus herausgewachsen. Das ist offensichtlich. Weniger offensichtlich ist, was das für das Infrastrukturdesign bedeutet.

Sobald KI Teil der Kernprozesse wird, hat man es nicht mehr mit isolierten Workloads zu tun. Es entstehen überlappende Modelle, gemischte Beschleuniger, verschiedene Teams, die zu unterschiedlichen Zeiten aus unterschiedlichen Gründen Jobs ausführen. Die Umgebung wird komplex. Realistisch. Menschlich.

In einem solchen Umfeld geraten Netzwerke, die für Vorhersehbarkeit konzipiert wurden, unter Druck. Feste Annahmen über Traffic-Muster gelten nicht mehr. Und wenn mehrere Fabrics betrieben werden – eine für klassische Workloads, eine für KI –, wird die operative Belastung sichtbar. Skill-Lücken werden relevant. Komplexität potenziert sich. Kleine Probleme werden systemisch.

Hier rückt Ethernet leise wieder in den Mittelpunkt der Diskussion.

Nicht als Kompromiss, wie es früher teilweise dargestellt wurde, sondern als stabilisierender Faktor. Offene Standards. Ein breiter Talentpool. Vertraute Betriebsmodelle. Und zunehmend Performance-Eigenschaften, die nah genug an Alternativen liegen, sodass die Abwägungen nicht mehr eindeutig erscheinen.

Hinzu kommt ein zeitlicher Aspekt. KI-Infrastruktur ist nicht statisch. Kaum eine Organisation wird einmal bauen und dann stehen bleiben. In den kommenden Jahren werden die meisten neue Fähigkeiten schrittweise auf bestehende Umgebungen aufsetzen. Brownfield und Greenfield nebeneinander. Netzwerke, die diese Realität nicht tolerieren, werden schnell zum Hindernis.

 

Was viele Teams noch missverstehen

Das größte Missverständnis besteht meiner Ansicht nach darin, KI-Netzwerke als spezialisierte Ecke des Rechenzentrums zu betrachten. Als etwas Separates. Als etwas, das man „später“ angeht.

Diese Denkweise war sinnvoll, als KI experimentell war. Sie ist weniger sinnvoll, wenn KI-Traffic mit hoher Wahrscheinlichkeit auf Netzwerken auftaucht, die heute gebaut werden – unabhängig davon, ob man dafür plant oder nicht.

Ein weiteres Missverständnis ist, Performance allein als Entscheidungsgrundlage zu nehmen. Latenzwerte, Durchsatz-Benchmarks, nominelle Geschwindigkeiten. All das ist wichtig. Aber es sagt wenig darüber aus, wie sich ein Netzwerk im Zeitverlauf verhält, unter Last, bei Teil-Ausfällen oder wenn Teams es Tag für Tag betreiben müssen.

Die operative Realität zählt. Resilienz zählt. Ebenso die Fähigkeit, sich weiterzuentwickeln, ohne alles zu stoppen und neu zu beginnen.

Die Forschung deutet darauf hin, wenn sie über Unified Fabrics, Live-Patching, Telemetrie und Echtzeitschutz spricht. Liest man zwischen den Zeilen, ist die Botschaft klar: KI-Infrastruktur wird auf neue Arten ausfallen, und man wird nicht immer den Luxus geplanter Downtime haben, um sie zu reparieren.

Das verändert die Definition von „ausreichend gut“.

 

Ein leiser Wandel, der Aufmerksamkeit verdient Eine ruhigere Veränderung, die es wert ist, beachtet zu werden

Ein Detail, das mir besonders aufgefallen ist, ist die wachsende Betonung von Interoperabilität und Langlebigkeit. Nicht als abstrakte Ideale, sondern als praktische Notwendigkeiten.

Die meisten Unternehmen werden nicht dauerhaft auf einen einzigen Beschleuniger oder Anbieter standardisieren. Sie werden Generationen mischen. Alternativen testen. Entscheidungen erben, die vor Jahren getroffen wurden. Das Netzwerk liegt unter all dem – im Guten wie im Schlechten.

Der Vorteil von Ethernet liegt hier nicht darin, perfekt zu sein. Sondern darin, flexibel zu bleiben, ohne zu brechen. Es ermöglicht inkrementelle Veränderungen. Es toleriert Heterogenität. Und es entspricht eher dem tatsächlichen Verhalten von Organisationen als idealisierten Whiteboard-Architekturen.

Es gibt auch eine menschliche Dimension, die oft zu wenig Beachtung findet. Ethernet-Know-how ist weit verbreitet. Debugging-Tools sind vertraut. Wenn um zwei Uhr morgens etwas schiefgeht, zählt das mehr als Benchmark-Diagramme.

 

Was das jetzt für IT-Verantwortliche bedeutet

Wenn Sie für KI-Infrastruktur verantwortlich sind, lautet die Schlussfolgerung nicht „alles ersetzen“ oder „auf X standardisieren“. Sie ist nachdenklicher.

Vielleicht lohnt es sich zu fragen:

Gehen wir einfach davon aus, dass das Netzwerk zurechtkommt, oder haben wir es unter realistischen KI-Lasten getestet?

Wissen wir, wo Engpässe entstehen, und wie schnell wir sie erkennen und darauf reagieren können?

Bauen wir etwas, das nur für die heutigen Modelle funktioniert, oder etwas, das die nächsten drei Hardwarezyklen übersteht?

Und vielleicht die schwierigste Frage: Wenn die KI-Performance enttäuscht, werden wir wissen, ob das Problem die Rechenleistung ist – oder kaufen wir einfach mehr und hoffen?

Das sind weniger technische als Governance-Fragen. Sie liegen an der Schnittstelle von Architektur, Betrieb und Risiko.

 

Am Ende beginnt es genau hier

KI wird jedes Unternehmen berühren, bewusst oder indirekt. Das ist nicht mehr strittig. Offen bleibt, wie viel Reibung Organisationen bereit sind zu akzeptieren, wenn KI skaliert.

Die Teams, die erfolgreich sein werden, sind nicht unbedingt diejenigen, die als Erste die größten Modelle einsetzen. Es sind diejenigen, die Infrastruktur mit genügend Spielraum, Transparenz und Anpassungsfähigkeit bauen, um Veränderungen aufzunehmen, ohne ständig neu beginnen zu müssen.

Die aktuelle Studie der 650 Group untersucht diese Dynamik genauer, insbesondere warum Ethernet zur Standardwahl für KI-Netzwerke in Unternehmen wird und was dies für die nächsten Jahre bedeutet.

Doch selbst ohne Studien wird die Richtung zunehmend klar.

KI testet nicht nur Ihre Compute-Strategie. Sie testet Ihre Bereitschaft, die Teile des Stacks neu zu denken, die Sie bereits als abgeschlossen betrachtet haben.

 

Warum Partnerschaft wichtiger ist als Plattformentscheidungen

Es gibt zudem eine praktische Realität, die leicht übersehen wird. Nur wenige Organisationen möchten all das allein herausfinden. Das Design, der Betrieb und die Weiterentwicklung KI-fähiger Netzwerke betreffen Architektur, Operations und Security gleichermaßen – und passen selten sauber in die Verantwortung eines einzelnen Teams. Hier kann die Zusammenarbeit mit einem Serviceprovider wie Damovo einen echten Unterschied machen. Nicht, indem eine starre Lösung verkauft wird, sondern indem Trade-offs transparenter gemacht, Annahmen kritisch geprüft und Architekturen entwickelt werden, die zur realen Umgebung passen – nicht zu einer idealisierten. Manchmal liegt der Mehrwert nicht in einer neuen Technologieentscheidung, sondern in einem erfahrenen Partner, der Entscheidungen frühzeitig hinterfragt, bestehende Komplexität reduziert und auch nach dem Go-Live an Bord bleibt, während sich das Netzwerk weiterentwickelt.