IT-Infrastruktur bis 2030: Was Unternehmen vorbereiten sollten
KI, Speicherarchitekturen, Energie und portable Systeme einordnen. Belegte Entwicklungen, unsichere Szenarien und konkrete Investitionsentscheidungen klar getrennt.
Bis 2030 können sich Rechenlast, Energiebedarf und Betriebsmodelle deutlich verändern. Sinnvolle Vorbereitung bedeutet heute messbare Kapazität, portable Daten und kleine überprüfbare Experimente statt Hardwarekäufe auf Verdacht.
Für Unternehmen, die Infrastruktur erneuern und dabei KI-Anwendungen, wachsende Datenmengen und spätere Anbieterwechsel berücksichtigen möchten.
Was belegt ist und was ein Szenario bleibt
Eine Investition mit fünf Jahren Laufzeit braucht einen Blick nach vorn. Sie braucht aber keine Behauptung, dass jede neue Technik bis dahin überall eingesetzt wird. In diesem Artikel unterscheiden wir dokumentierte technische Möglichkeiten, Prognosen aus benannten Quellen und eigene Entscheidungsszenarien. Daraus entstehen konkrete Prüfpunkte für die heutige Planung.
| Entwicklung | Status | Praktische Folge |
|---|---|---|
| Wachsender Strombedarf von Rechenzentren | IEA-Schätzung für 2024 und modellierte Entwicklung bis 2030 | Energie und Anschlussleistung in die Planung aufnehmen |
| CXL-Speichererweiterung und Pooling | Dokumentierte technische Möglichkeiten | Bei großen Speicherengpässen beobachten, konkrete Plattform prüfen |
| Container auf mehreren CPU-Architekturen | Vorhandene Werkzeuge, anwendungsabhängige Kompatibilität | Build und Tests für mögliche Zielplattformen vorbereiten |
| Mehr lokale KI in kleinen Unternehmen | Eigenes mögliches Szenario, keine sichere Vorhersage | Bedarf durch einen begrenzten Pilot belegen |
| Sinkende eigene Betriebskosten durch Automatisierung | Mögliches Ergebnis, kein Automatismus | Aufwand und Fehler vor und nach dem Pilot messen |
Eine belastbare Planung benennt auch, was sie nicht vorhersagen kann: künftige RAM-Preise, die wirtschaftlich beste Prozessorfamilie oder den Funktionsumfang eines bestimmten Cloudtarifs. Dafür werden Reserven, Vergleichspunkte und Zeitfenster für eine Neubewertung vorgesehen. So bleibt die Entscheidung handlungsfähig, wenn sich eine Annahme verändert.
Energie wird ein Architekturthema
Die IEA schätzt den weltweiten Stromverbrauch von Rechenzentren für 2024 auf rund 415 TWh. Im Basisszenario ihres Berichts Energy and AI von 2025 steigt er bis 2030 auf ungefähr 945 TWh. Das ist eine modellierte Entwicklung mit Unsicherheiten, keine bereits eingetretene Messung für 2030. Der Bericht beschreibt unter anderem unterschiedliche Annahmen zu KI-Nutzung und Effizienz. IEA: Energy and AI, Executive Summary (2025) ↗
Für ein kleines Unternehmen folgt daraus keine bestimmte Strompreisprognose. Praktisch lohnt sich aber eine saubere Ausgangsmessung: Welche Systeme laufen durchgehend, welche erledigen nur wenige Stunden produktive Arbeit und welche Reserven sind für Ausfälle nötig? Konsolidierung kann Energie sparen, erhöht jedoch die Zahl der Anwendungen, die vom selben Gerät abhängen. Der Ausfallplan muss mitwachsen.
AWS empfiehlt in seinem Sustainability Pillar, Hardwareumfang und Dienste am tatsächlichen Workload auszurichten und passende effiziente Ressourcen auszuwählen. Als eigene betriebliche Kennzahl eignet sich zum Beispiel Energie oder Kosten je erfolgreich verarbeitetem Auftrag. Ein niedriger Leerlaufverbrauch hilft wenig, wenn die Anwendung für dieselbe Aufgabe deutlich länger rechnet. AWS: Hardware and Services im Sustainability Pillar ↗
KI verändert die Speicherfrage, aber nicht jede Anwendung braucht eine GPU
Ein Dokumentenassistent kann externe Modelldienste verwenden, ein kleineres Modell lokal ausführen oder beide Ansätze verbinden. Die passende Architektur hängt von Daten, Antwortzeit, Nutzungshäufigkeit und betreibbarer Software ab. Ein eigener Beschleuniger ist erst dann gut begründet, wenn ein Test einen tragfähigen Bedarf zeigt. Die Größe einer Modellbezeichnung allein ist keine vollständige Hardwareanforderung.
Eine reine Modellrechnung verdeutlicht die Grenze: Acht Milliarden Parameter mit jeweils zwei Byte benötigen ungefähr 16 GB allein für die Gewichte. Das ist eine rechnerische Untergrenze unter dieser Speicherannahme. Laufzeit, Zwischenergebnisse, Kontextspeicher und parallele Anfragen benötigen zusätzlichen Platz. Eine andere Darstellung der Gewichte kann den Bedarf verändern; daraus folgt ohne Qualitätstest keine Empfehlung für eine bestimmte Komprimierung oder Grafikkarte.
Messen Sie im Pilot mit typischen Dokumenten, echter Kontextlänge und erwarteter Gleichzeitigkeit. Bewerten Sie Antwortqualität, Dauer, Speicherbedarf und Kosten gemeinsam. Ein Modell, das schnell antwortet, aber regelmäßig fachlich unbrauchbare Ergebnisse liefert, ist keine effiziente Lösung. Berücksichtigen Sie zudem Datenaufbereitung und menschliche Prüfung; diese Arbeit verschwindet nicht, wenn das Modell auf dem eigenen Server läuft.
Neue Speicherarchitekturen beobachten, ohne darauf angewiesen zu sein
Das CXL-Konsortium beschreibt für CXL 2.0 Speichererweiterung und die verwaltete Zuweisung gemeinsam bereitgestellter Speicherressourcen. Dafür arbeiten Plattform, Speichergeräte, Software und gegebenenfalls Switches zusammen. Es handelt sich um eine dokumentierte technische Architektur, nicht um die Zusage, dass jedes vorhandene Mainboard nachgerüstet werden kann. CXL-Konsortium: CXL 2.0 Memory Pooling ↗
Unsere Einordnung: Solche Ansätze können für Umgebungen interessant sein, in denen teurer Speicher ungleich über viele Systeme verteilt ist. Für einen einzelnen kleinen Dateiserver steht der Zusatznutzen nicht fest. Prüfen Sie konkrete Latenzen, Kompatibilität, Support und den Verwaltungsaufwand. Mehr Kapazität über einen anderen Datenweg ist nicht automatisch gleichwertig mit direkt angebundenem RAM für jede Anwendung.
Heute lässt sich bereits vorbereiten, was unabhängig vom künftigen Standard nützt: RAM-Verbrauch nach Anwendung messen, sinnvolle Speicherbudgets festlegen und Engpässe von fehlerhafter Konfiguration unterscheiden. Wer seine Last nicht kennt, kann auch ein neues Speicherverfahren nicht wirtschaftlich bewerten. Ein sauberer Ausbaupfad für die aktuelle Plattform bleibt deshalb wertvoll.
Portabilität entsteht durch getestete Abhängigkeiten
Mehr Auswahl zwischen CPU-Plattformen oder Hostingmodellen hilft nur, wenn die Anwendung tatsächlich darauf funktioniert. Docker dokumentiert Mehrplattform-Builds für verschiedene Zielarchitekturen. Ein Containerimage ist damit aber nicht automatisch auf jeder Architektur lauffähig: Abhängigkeiten und Binärdateien müssen zur Zielplattform passen. Docker: Multi-platform Builds ↗
Lassen Sie bei einer Modernisierung daher nicht nur das Image erzeugen, sondern die wichtigsten Abläufe auf der vorgesehenen Zielplattform testen. Dazu gehören Datenbanktreiber, Dokumentenerzeugung und externe Bibliotheken. Eine offene Schnittstelle erleichtert den Wechsel, ersetzt aber weder ein exportierbares Datenmodell noch die Migration der Benutzerzuordnung und Berechtigungen.
Für kleine Teams kann eine überschaubare Architektur mit dokumentierter Bereitstellung die bessere Zukunftsvorsorge sein als eine zusätzliche Orchestrierungsplattform. Wenn Skalierung nötig wird, muss sie vom Team beherrscht werden. Kubernetes nutzt Ressourcenanforderungen für die Planung von Containern und Grenzen zur Steuerung ihres Verbrauchs; auch dort bleiben Kapazitätsplanung und passende Einstellungen erforderlich. Kubernetes: Ressourcen für Pods und Container verwalten ↗
Drei Szenarien für die nächste Investitionsrunde
| Szenario | Frühes Signal | Sinnvolle Reaktion |
|---|---|---|
| Der heutige Bedarf bleibt weitgehend stabil | Daten und Last wachsen innerhalb der geplanten Reserve | Support und Wiederherstellung pflegen; funktionierende Hardware weiter bewerten |
| Ein neues digitales Angebot wächst stark | Nutzerzahlen und gleichzeitige Verarbeitung steigen dauerhaft | Anwendungsteile gezielt skalieren und Kosten pro Geschäftsvorgang prüfen |
| Lokale Datenverarbeitung wird wichtiger | Messbare Latenz-, Datenweg- oder Betriebsanforderungen | Begrenzten lokalen Pilot mit vollständiger Betriebskostenrechnung starten |
Legen Sie zu jedem Szenario einen Auslöser fest. Beispielsweise wird ein Ausbau geprüft, wenn die Reserve über mehrere repräsentative Lastzyklen unter die vereinbarte Grenze sinkt. Ein einzelner Spitzenwert muss dagegen zuerst erklärt werden. Für den KI-Pilot könnte der Auslöser ein nachgewiesener Nutzen bei wiederkehrenden Aufgaben sein. Eine hohe öffentliche Aufmerksamkeit ist dafür kein Ersatz.
Was sich in den nächsten 90 Tagen konkret vorbereiten lässt
- Tage 1–30: Anwendungen, Verantwortlichkeiten und Supportlaufzeiten inventarisieren. CPU-, RAM-, Speicher- und Kostenverlauf über einen sinnvollen Geschäftszyklus erfassen.
- Tage 31–60: Eine reale Wiederherstellung und einen Datenexport testen. Die größten manuellen Abhängigkeiten dokumentieren und einen begrenzten Verbesserungsversuch auswählen.
- Tage 61–90: Den Versuch mit vorher festgelegten Kriterien auswerten. Kosten, Qualität und Betrieb gemeinsam betrachten und nur bei nachgewiesenem Nutzen ausbauen.
Diese eigene Zeitplanung dient der Strukturierung und muss zur verfügbaren Kapazität passen. Der wichtigste Output ist ein aktuelles Entscheidungsblatt: Was funktioniert, wo sind Grenzen, was kostet der Betrieb und welche Annahme wird als Nächstes geprüft? Neue Technologien lassen sich daran messen, statt die Planung bei jeder Ankündigung neu zu beginnen.
Eine zukunftsfähige Infrastruktur braucht nicht heute sämtliche Fähigkeiten von morgen. Sie braucht ausreichend Reserven für begründete Entwicklungen, einen überprüften Wiederanlauf und die Möglichkeit, Daten und Anwendungen geordnet zu verändern. Diese Eigenschaften bleiben nützlich, auch wenn sich einzelne Marktprognosen bis 2030 nicht erfüllen.