Hören Sie auf, KI-Infrastruktur um die GPU herum zu entwerfen

Warum MSPs mit der Arbeitslast beginnen sollten, nicht mit der Hardware

Verbringen Sie fünf Minuten auf einer KI-Konferenz, und Sie könnten leicht glauben, dass jede erfolgreiche KI‑Einführung mit dem Kauf weiterer GPUs beginnt. Das ist leicht nachvollziehbar. Hardware dominiert die Diskussion. Kunden hören von Blackwell‑Systemen, InfiniBand‑Netzwerken, hyperskaligen Clouds und immer größer werdenden KI‑Clustern. Anbieter neigen natürlich zu den neuesten Beschleunigern und schnellsten Systemen, weil sie spannend, relevant und relativ einfach am Markt zu positionieren sind.

Das Problem ist nicht, dass Rechenleistung keine Rolle spielt. Sie ist enorm wichtig.

Das Problem ist, dass ein Einstieg dort Organisationen dazu verleiten kann, die falsche Frage zu stellen. Der KI‑Markt befindet sich nicht mehr in der Experimentierphase. KI wird in die Produktion überführt, Unternehmen investieren echtes Geld und erwarten messbare Geschäftsergebnisse. Infrastrukturentscheidungen sind weitaus folgenreicher geworden als noch vor zwei Jahren. Dennoch werden zu wenig Entscheidungen von geschäftlichen Anforderungen getrieben – technikgetriebene Entscheidungen bleiben dominierend.

Die erste Frage sollte nicht lauten: „Welche GPU sollen wir kaufen?“

„Welche Arbeitslast wollen wir unterstützen?“ sollte im Fokus stehen.

Diese scheinbar kleine Änderung beeinflusst fast jede nachfolgende Infrastrukturentscheidung.

Es gibt keine standardisierte KI‑Infrastruktur

Eine der größten Fehlannahmen im Markt ist, dass es einen standardisierten Bauplan für KI‑Infrastruktur gibt. Gibt es nicht.

Wir sprechen über KI, als wäre sie eine einzige Arbeitslast. In Wirklichkeit umfasst KI ein enormes Spektrum an Geschäfts‑Anwendungen mit sehr unterschiedlichen Anforderungen. Eine Sprach‑KI‑Plattform hat nicht dieselben Infrastruktur‑Anforderungen wie die medizinische Bildgebung. Wissensabfrage unterscheidet sich von Bildgenerierung. Betrugserkennung sieht nicht wie prädiktive Analytik aus, und keine von beiden ähnelt der Videobearbeitung. Sie alle nutzen KI. Sie verwenden lediglich die Infrastruktur auf unterschiedliche Weise.

Sie entwerfen nicht wirklich Infrastruktur für „KI“. Sie entwerfen Infrastruktur für eine Geschäfts‑Anwendung, die KI verwendet. Diese Unterscheidung ist wichtig. Jede einzelne Arbeitslast stellt einzigartige Anforderungen an die unterstützende Infrastruktur. Einige benötigen erhebliche Rechenressourcen. Andere hängen stark von der Speicher‑Performance ab, weil sie kontinuierlich große Datensätze abrufen. Manche sind durch Netzwerk‑Durchsatz begrenzt, während andere über die Latenz leben oder sterben, weil jede Millisekunde das Kundenerlebnis beeinflusst.

Es gibt zudem eine praktische Realität. Die Infrastruktur, für die ein Modell konzipiert wurde, ist nicht immer die Infrastruktur, die zum Zeitpunkt der Bereitstellung verfügbar ist. Hardware‑Verfügbarkeit, lange Vorlaufzeiten oder Deploy‑Deadlines können Organisationen zwingen, andere GPUs, Beschleuniger oder Infrastruktur‑Konfigurationen zu nutzen als ursprünglich geplant. Das kann bedeuten, das Modell neu zu optimieren oder es sogar um die tatsächlich einsetzbare Hardware herum neu zu entwerfen.

Sicherheits‑ und Governance‑Anforderungen sind ebenso arbeitslast‑spezifisch. Eine Anwendung, die öffentliche Informationen verarbeitet, hat völlig andere Anforderungen als eine, die Finanztransaktionen, Gesundheitsdaten oder proprietäres geistiges Eigentum verarbeitet. Datenschutz, Identitäts‑ und Zugriffs‑Management, Compliance, Souveränität, Backup, Wiederherstellung und Verfügbarkeit können nicht einfach nach der Bereitstellung hinzugefügt werden. Sie sind architektonische Entscheidungen.

Geschäftliche Anforderungen fügen eine weitere Ebene hinzu. Wie schnell muss die Anwendung skalieren? Welche Betriebskosten sind tragbar? Welches Verfügbarkeitsniveau verlangt das Unternehmen? Wie viel Komplexität kann die Organisation realistisch managen? Diese Fragen werden von jedem Kunden unterschiedlich beantwortet. Deshalb gibt es keine Einheits‑KI‑Infrastruktur.

Organisationen, die mit einer bevorzugten Cloud, einer bevorzugten Hardware‑Plattform oder einem bevorzugten Anbieter beginnen, kommen nicht zur richtigen KI‑Infrastruktur. Die Vorreiter beginnen mit der Arbeitslast und entwerfen eine Architektur rund um das Geschäfts‑Ziel.

Training sorgt für Schlagzeilen. Inferenz liefert den geschäftlichen Mehrwert.

Die Faszination der Branche für das Training ist ein weiterer Grund, warum KI‑Infrastruktur‑Diskussionen in die falsche Richtung gehen können.

Das Training eines großen Sprachmodells ist eine außergewöhnliche ingenieurtechnische Herausforderung. Enorme Datensätze, massive GPU‑Cluster, erheblicher Stromverbrauch und eine Infrastruktur, die über Tage, Wochen oder sogar Monate hinweg mit voller Kapazität laufen kann, sind erforderlich. Es ist kostenintensiv, technisch beeindruckend und zieht naturgemäß Aufmerksamkeit auf sich.

Die meisten Organisationen bauen jedoch nicht das nächste Spitzenmodell. Sie entwickeln Kundenservice‑Anwendungen, Sprach‑KI‑Systeme, Mitarbeitenden‑Co‑Piloten, Wissens‑Assistenten, Such‑Tools, Dokument‑Zusammenfassungs‑Plattformen, Betrugserkennungs‑Systeme und Dutzende anderer praktischer Anwendungen, die bereits trainierte Modelle nutzen.

Das sind Inferenz‑Arbeitslasten, und Inferenz verändert die Infrastruktur‑Gleichung. Statt ausschließlich für maximale Rechenleistung zu optimieren, müssen Organisationen möglicherweise für schnelle Reaktionszeiten, niedrige Latenz, vorhersehbare Betriebskosten und konsistente Leistung optimieren.

Ein Kunde kümmert es nicht, wie leistungsstark die zugrunde liegende GPU ist, wenn ein Chatbot fünf Sekunden zum Antworten braucht. Ein Anrufer interessiert die Spezifikation des KI‑Clusters nicht, wenn ein Sprachassistent Anfragen wiederholt missversteht oder während eines Gesprächs zögert. Sie wissen einfach, dass die Anwendung nicht gut funktioniert.

Jede KI‑Umgebung so zu entwerfen, als würde man ein Grundmodell trainieren, ist daher meist der falsche Ansatz und häufig unnötig teuer.

Das Ziel der meisten MSP‑Kunden ist nicht, das weltweit größte GPU‑Cluster zu bauen. Ziel ist es, KI‑Anwendungen schnell, zuverlässig, sicher und wirtschaftlich in die Produktion zu bringen.

Die Herausforderung besteht darin, das richtige Gleichgewicht zwischen Leistung, Sicherheit, Skalierbarkeit, Belastbarkeit und Kosten für die tatsächlich betriebenen Arbeitslasten zu finden.

Vielleicht ist die GPU nicht Ihre Engstelle

GPUs sind zum Star der KI‑Infrastruktur geworden. Sie sind teuer, schwer zu beschaffen und leicht zu vergleichen, was sie zum Mittelpunkt unzähliger Infrastruktur‑Diskussionen macht. Sobald jedoch eine KI‑Anwendung die Produktion erreicht, ist die GPU möglicherweise nicht das, was sie zurückhält.

„Wie viele GPUs benötigen wir?“ ist nicht die Frage, die wir stellen sollten, sondern vielmehr: „Was wird diese Anwendung in sechs Monaten ausbremsen?“

Die Antwort kann auch an anderer Stelle in der Architektur liegen.

Speicher ist ein gutes Beispiel. Enorme Datenmengen werden von KI‑Arbeitslasten verbraucht – und diese Datensätze wachsen im Laufe der Zeit. Selbst eine extrem leistungsstarke GPU kann wertvolle Zeit mit Warten verbringen, wenn der Speicher die Informationen nicht schnell genug liefert. Diese Daten müssen zudem geschützt, gesichert, aufbewahrt, gesichert und über ihren gesamten Lebenszyklus verwaltet werden.

Ebenso wichtig ist das Netzwerk. Durchsatz, Latenz, Ost‑West‑Verkehr und die Kommunikation zwischen KI‑Clustern beeinflussen die Anwendungsleistung. Eine gut gestaltete Compute‑Umgebung kann ein schlecht gestaltetes Netzwerk nicht unbegrenzt ausgleichen.

Auch die Sicherheit muss von Anfang an Teil der Architektur sein. Fragen, die vor der Produktion geklärt werden müssen, umfassen: wo sensible Daten gespeichert sind, wie Netzwerke segmentiert werden, ob Arbeitslasten über private oder öffentliche Verbindungen kommunizieren und wie Compliance‑ und Souveränitätsanforderungen adressiert werden.

Ein leicht übersehener Faktor ist die Konnektivität. Auch wenn sie keine auffälligen Schlagzeilen erzeugen, können Diversität von Glasfasern, Routenvielfalt, Peering‑Beziehungen und geografische Nähe die Benutzererfahrung entscheidend beeinflussen – ganz zu schweigen von der Plattform‑Resilienz.

Endkunden wissen nicht und kümmern sich nicht darum, welche GPU im Rack sitzt. Sie wollen wissen, ob die Anwendung sofort reagiert oder sie warten lässt.

Physische Infrastruktur verdient ebenfalls Aufmerksamkeit. Stromverfügbarkeit, Kühlkapazität, Rack‑Dichte und Erweiterungskapazität bestimmen, ob die heutige erfolgreiche Bereitstellung das Wachstum von morgen bewältigen kann.

Dann gibt es die Daten‑Gravitation. Während sich Datensätze ausdehnen, wird das Verschieben von Petabytes von Informationen zwischen Standorten, nur weil die Rechenleistung woanders sitzt, immer ineffizienter. In vielen Situationen kann es sowohl praktischer als auch kostengünstiger sein, die Rechenleistung näher an die Daten zu bringen.

Deshalb ist die Architektur entscheidend.

Denken Sie an ein Rennwagen – nur weil er den besten Motor hat, bedeutet das nicht, dass er gewinnt. Getriebe, Reifen, Aufhängung, Strecke und vor allem der Fahrer sind ebenfalls wichtig. KI‑Infrastruktur funktioniert nach dem gleichen Prinzip.

Die Organisationen, die den größten Mehrwert aus KI ziehen, werden nicht unbedingt die mit den größten GPU‑Clustern sein. Sie werden diejenigen sein, die verstehen, wie jede Schicht der Infrastruktur zusammenwirkt.

Das ist der Unterschied zwischen dem Kauf von Infrastruktur und deren Gestaltung.

Ein arbeitslast‑first Planungs‑Framework

MSPs haben die Chance, die Infrastruktur‑Diskussion zu verändern.

Statt mit:

• Welche GPU?
• Welche Cloud?
• Welcher Anbieter?

Beginnen Sie mit der Arbeitslast:

• Welches Geschäftsproblem lösen wir?
• Handelt es sich um eine Trainings‑ oder Inferenz‑Arbeitslast?
• Wie viel Latenz kann die Anwendung tolerieren?
• Wo befinden sich die Daten und wie schnell werden sie wachsen?
• Welche Sicherheits‑, Compliance‑ und Souveränitäts‑Anforderungen gelten?
• Wie wird die Arbeitslast skalieren?
• Welches Verfügbarkeitsniveau verlangt das Unternehmen?
• Welches Niveau an betrieblichem Risiko ist akzeptabel?
• Wie hoch werden die Betriebskosten dieser Umgebung sein, wenn die Nutzung steigt?

Die Antworten sollten die Architektur bestimmen. Nicht umgekehrt.

Die Chance für MSPs

Diese Verschiebung ändert die Rolle des MSP.

Kunden benötigen keinen weiteren Partner, der ihnen Infrastruktur verkaufen kann. Ein Partner, der ihnen hilft, bessere Infrastruktur‑Entscheidungen zu treffen, ist das, was gebraucht wird.

Ein arbeitslast‑first Ansatz ist zwingend erforderlich, da er MSPs die Möglichkeit gibt, Compute, Storage, Networking, Konnektivität, Sicherheit, Datenstandort, Verfügbarkeit und Kosten als Bestandteile einer einzigen Architektur zu bewerten – statt separater Beschaffungsentscheidungen.

Auf diese Weise können Sie Kosten kontrollieren, die Leistung verbessern und betriebliche sowie sicherheitsrelevante Risiken erkennen, bevor Anwendungen in die Produktion gehen.

Ein besseres Geschäftsmodell für den MSP entsteht ebenfalls.

MSPs können höherwertige wiederkehrende Services rund um Architektur, Bereitstellung, Optimierung, Sicherheit, Lebenszyklus‑Management, Kapazitätsplanung und kontinuierliche Verbesserung aufbauen – anstatt hauptsächlich über schrumpfende Hardware‑Margen zu konkurrieren.

Der Mehrwert liegt nicht darin, die neueste GPU oder die neueste Cloud‑Plattform zu empfehlen. Er liegt darin zu wissen, wann ein Kunde sie benötigt, wann nicht und was sonst noch um sie herum gestaltet werden muss.

KI‑Infrastruktur ist letztlich keine Hardware‑Entscheidung. Sie ist eine architektonische Entscheidung, die von der Arbeitslast, den Daten und dem geschäftlichen Ergebnis, das der Kunde erreichen möchte, getrieben wird.

Die MSPs, die diese Unterscheidung verstehen, werden sich in eine Position bringen, die weitaus wertvoller ist als die von Infrastruktur‑Anbietern.

Sie werden die Personen werden, denen Kunden vertrauen, um zu entscheiden, welche Infrastruktur sie tatsächlich benötigen.