7 Ihr Unternehmen hat ein großes Sprachmodell trainiert oder von einem Anbieter lizenziert. Nun bereiten Sie das Deployment in der Produktion vor, um Inferenzanfragen von Anwendungen, Benutzern oder internen Systemen zu bedienen. Die Trainingsphase war rechenintensiv, ist aber abgeschlossen. Die Inferenzphase ist anders: Sie ist fortlaufend, kontinuierlich und unumgänglich. Ihre Infrastruktur für die LLM-Inferenz läuft ununterbrochen und bedient Anfragen rund um die Uhr. Jede Ausfallzeit wirkt sich direkt auf Ihr Geschäft und Ihre Benutzer aus. Das Deployment einer Infrastruktur für die LLM-Inferenz erfordert ein neues Verständnis von Resilienz in der Produktion. Große Sprachmodelle sind teuer im Betrieb. Eine einzelne GPU kann Dutzende oder Hunderte Anfragen pro Sekunde bedienen. Der Speicherbedarf eines Modells – Gewichte, Aktivierungs-Caches, unterstützende Indizes – liegt jedoch je nach Modellgröße zwischen einigen Dutzend Gigabyte und mehreren Terabyte. Die Skalierung der Inferenz erfordert sowohl Rechenressourcen als auch eine ausgefeilte Speicherarchitektur. Der Speicher muss leistungsfähig genug sein, um Modellgewichte und Zwischendaten so schnell zu liefern, dass die GPUs ausgelastet bleiben. Er muss zuverlässig genug sein, damit sich ein Leistungsabfall des Speichers berechenbar auf die Inferenz-Performance auswirkt. Und er muss sicher genug sein, damit Ihre Modellgewichte geschützt sind und Ihre Inferenzinfrastruktur gegen Kompromittierung verteidigt werden kann. Erwägen Sie eine Speicherinfrastruktur für agentische KI , die speziell für diese Workloads konzipiert ist. Dieser Beitrag beleuchtet die Architektur für Resilienz, Sicherheit und Disaster Recovery, auf der eine produktive LLM-Inferenz beruht, und zeigt, was CISOs und Infrastrukturarchitekten beim Entwurf von Inferenz-Deployments beachten müssen, die zugleich leistungsfähig und sicher sind. Die Speicherarchitektur der LLM-Inferenz: Modelle als Daten Große Sprachmodelle sind im Kern Daten. Ein Modell besteht aus Milliarden oder Billionen von Parametern – Gewichten, die die erlernte Repräsentation des Modells bilden. Bei der Inferenz müssen diese Gewichte mit hoher Performance verfügbar sein. Ein Inferenzserver lädt die Modellgewichte in den Speicher (meist GPU- oder CPU-Speicher), verarbeitet einen Prompt und erzeugt eine Ausgabe. Die Latenz beim Laden dieser Gewichte wirkt sich direkt auf die Zeit bis zum ersten Token und die gesamte Inferenzlatenz aus. Bei großen Modellen ist die Gewichtsdatei größer als der Speicher einer einzelnen GPU. Daraus ergeben sich architektonische Anforderungen. Sie brauchen Strategien, um Modelle auf mehrere GPUs zu verteilen, Gewichte effizient vorzuladen oder ein dynamisches Laden umzusetzen, bei dem Gewichte nach Bedarf ein- und ausgelagert werden. All diese Strategien hängen vom Speicher ab – von der Fähigkeit, Modellgewichte schnell aus persistentem Speicher zu lesen und den Inferenzservern bereitzustellen. Zudem erzeugt die Inferenz Zwischendaten. Inferenz-Frameworks führen Aktivierungs-Caches, Attention-Vektoren und Zwischenzustände von Berechnungen. Für manche Optimierungen wie Speculative Decoding oder Prefix Caching halten Sie persistente Caches vor, die nachfolgende Anfragen beschleunigen. All diese Daten müssen irgendwo gespeichert werden, und der Speicher muss leistungsfähig sein. Die Folge: Ihre Inferenzinfrastruktur ist nicht nur rechenintensiv, sondern auch datenintensiv. Ihre Speicherarchitektur bestimmt direkt, wie schnell Sie Modelle laden, wie stark Sie die Inferenz parallelisieren und wie effizient Sie die Inferenzkapazität skalieren können. Mit einer schlechten Speicherarchitektur lassen sich die Latenz- und Durchsatzanforderungen einer produktiven Inferenz nicht erfüllen. Sicherheit der Modellgewichte in der Produktion Modellgewichte sind geistiges Eigentum. Für Unternehmen, die erhebliches Kapital in das Training eines Modells investiert haben, ist der Schutz dieser Gewichte vor Diebstahl entscheidend. Für Unternehmen, die Modelle von Anbietern lizenzieren, verbietet der Lizenzvertrag in der Regel das unbefugte Kopieren oder Offenlegen der Gewichte. Dennoch müssen die Modellgewichte in der Produktion verfügbar sein. Ein Inferenzserver muss sie laden. Jemand muss sie verwalten – versionieren, aktualisieren und auf frühere Versionen zurücksetzen, wenn neue Versionen die Performance verschlechtern. Das schafft eine Angriffsfläche. Überall, wo Modellgewichte zugänglich sind, besteht ein potenzielles Einfallstor für Datenabfluss. Ihre Sicherheitsarchitektur muss die Modellgewichte über den gesamten Inferenz-Lebenszyklus schützen. Verschlüsseln Sie die Modellgewichte im Ruhezustand mit Schlüsseln, die von der Inferenzinfrastruktur getrennt sind. Ein Angreifer, der einen Inferenzserver kompromittiert, kann die Gewichte dann ohne Zugriff auf die Schlüssel nicht entschlüsseln. Dafür braucht es einen von der Inferenzinfrastruktur getrennten Key-Management-Service, der den Zugriff auf die Modellgewichte steuert. Verschlüsseln Sie die Modellgewichte auch bei der Übertragung vom Speicher zu den Inferenzservern – meist über TLS beim Netzwerktransport. Bei sensibleren Modellen kann eine kryptografische Authentifizierung der Gewichte zusätzlich sicherstellen, dass sie während der Übertragung nicht verändert wurden. Während der Inferenz liegen die Modellgewichte im GPU- oder CPU-Speicher. Diese Bedrohung ist schwerer abzuwehren. Verschafft sich ein Angreifer Administratorzugriff auf einen Inferenzserver, ist es technisch möglich, die Gewichte aus dem Speicher auszulesen. Die Abwehr erfordert, dass Ihre Inferenzinfrastruktur ebenso streng geschützt wird wie jedes andere sensible Produktionssystem: mit Netzwerkisolation, Zugriffskontrollen, Audit-Logging und Bedrohungserkennung. Hochverfügbarkeit und Fehlertoleranz Eine Infrastruktur für die LLM-Inferenz, die produktive Workloads bedient, verträgt keine Ausfallzeiten. Anders als bei der Stapelverarbeitung, bei der ein Fehler zur Wiederholung eines Jobs führt, wirkt sich ein Ausfall der Inferenz direkt auf die Benutzer aus. Hochverfügbarkeit bedeutet, die Inferenz auf mehreren Ebenen fehlertolerant zu gestalten. Auf Ebene der Inferenzserver brauchen Sie Redundanz: mehrere Inferenzserver mit demselben Modell und einen Lastausgleich, der die Anfragen verteilt. Fällt ein Server aus, werden die Anfragen an die übrigen weitergeleitet. Dafür müssen die Inferenzserver zustandslos sein, damit eine Anfrage ohne Zustandsverlust an jeden verfügbaren Server geleitet werden kann. Auf Modellebene brauchen Sie Versionsmanagement und Rollback-Fähigkeit. Verschlechtert eine neu bereitgestellte Modellversion die Performance oder verursacht sie Fehler, müssen Sie schnell auf die vorherige Version zurückwechseln können. Dafür müssen frühere Modellversionen verfügbar bleiben, und Ihre Inferenzinfrastruktur muss einen schnellen Modellwechsel unterstützen. Auf Speicherebene brauchen Sie Redundanz und eine schnelle Wiederherstellung. Die Modellgewichte müssen repliziert werden, damit ein einzelner Speicherausfall nicht zum vollständigen Verlust führt. Die Replikation sollte nach Möglichkeit geografisch erfolgen. Kopien in verschiedenen Rechenzentren oder Verfügbarkeitszonen schützen vor regionalen Ausfällen. Die Wiederherstellung muss so schnell sein, dass die Inferenz fortgesetzt werden kann, ohne SLAs zu verletzen. Bei Modellen, deren Betrieb besonders rechenintensiv ist, können Sie zusätzlich Caching-Strategien einsetzen. Antworten auf häufige Anfragen lassen sich zwischenspeichern, sodass identische oder ähnliche Anfragen ohne aufwendige Inferenz aus dem Cache bedient werden. Die Invalidierung des Caches wird dabei zur betrieblichen Anforderung: Werden Modelle aktualisiert, müssen die Caches geleert oder so verwaltet werden, dass keine veralteten Antworten ausgeliefert werden. Disaster Recovery für die Inferenzinfrastruktur Beim Disaster Recovery für die Inferenzinfrastruktur geht es um zwei verschiedene Aspekte: die Wiederherstellung der Inferenzinfrastruktur selbst und die Wiederherstellung der Modellartefakte, von denen sie abhängt. Das Verständnis von RTO und RPO wird bei der Planung von Wiederherstellungsstrategien für große Deployments entscheidend. Die Wiederherstellung der Inferenzinfrastruktur ist vergleichsweise einfach: Geht Ihr primäres Inferenz-Deployment verloren, können Sie die Inferenzserver aus Standard-Container-Images oder Infrastructure as Code neu bereitstellen und auf Ihre Modellgewichte verweisen. Sind Ihre Modellgewichte repliziert und zugänglich, lässt sich die Inferenzinfrastruktur in Minuten bis Stunden neu aufbauen. Schwieriger ist die Wiederherstellung der Modellartefakte. Liegt die einzige Kopie Ihres trainierten Modells in Ihrem primären Rechenzentrum und fällt dieses katastrophal aus, ist Ihr Modell verloren. Deshalb müssen trainierte Modelle gesichert werden. Kopien werden an einem separaten Standort vorgehalten, idealerweise in einer anderen geografischen Region. Bei kritischen Modellen sollten die Backup-Kopien regelmäßig getestet werden, um sicherzustellen, dass sie sich tatsächlich bereitstellen und erfolgreich betreiben lassen. Daraus ergibt sich ein erheblicher Speicherbedarf: Kritische Modelle benötigen Backup-Speicher. Umfassen Ihre größten Modelle mehrere Terabyte, brauchen Sie entsprechend Terabytes an Backup-Kapazität. Zudem muss dieser Backup-Speicher mit Ihren produktiven Modellen synchron gehalten werden, während neue Versionen trainiert werden. Für Unternehmen mit mehreren trainierten Modellen und schnellen Modelliterationen kann der Backup-Speicher zu einem erheblichen Betriebs- und Investitionsposten werden. Disaster Recovery durch Unveränderlichkeit und Versionierung Eine wirksame Strategie für das Disaster Recovery einer LLM-Inferenzinfrastruktur ist die unveränderliche Versionierung von Modellen. Jedes Mal, wenn ein Modell trainiert oder aktualisiert wird, wird es mit einer unveränderlichen Versionskennung gespeichert. Frühere Versionen werden unbegrenzt oder für eine festgelegte Aufbewahrungsfrist vorgehalten. So entsteht ein Repository für Modellartefakte, aus dem sich jede frühere Version wiederherstellen oder erneut bereitstellen lässt. Unveränderlichkeit verhindert das versehentliche oder böswillige Löschen von Modellversionen. Ist eine Modellversion einmal im Artefakt-Repository abgelegt, kann sie ohne ausdrückliche Autorisierung weder geändert noch gelöscht werden. Das stellt sicher, dass ein Disaster Recovery möglich ist: Es gibt immer eine bewährte Version eines Modells für die Wiederherstellung. Die Versionierung ermöglicht auch einen schnellen Rollback. Verursacht eine neu bereitgestellte Modellversion Probleme, können Sie die Inferenzserver schnell auf eine frühere Version zurückschalten – schneller, als ein Modell neu zu trainieren oder aufzubauen. Der Nachteil sind die Speicherkosten. Mehrere Versionen großer Modelle vorzuhalten, verbraucht viel Speicher. Unternehmen steuern das über Aufbewahrungsrichtlinien: die letzten 10 Versionen eines Modells behalten oder alle Versionen der letzten 90 Tage. Solche Richtlinien sind in der Praxis sinnvoll und bringen den Bedarf an Disaster Recovery mit den Speicherkosten in Einklang. Monitoring, Observability und Bedrohungserkennung Eine produktive Infrastruktur für die LLM-Inferenz erfordert ein ausgefeiltes Monitoring. Sie brauchen Einblick in Inferenzlatenz, Inferenzdurchsatz, Fehlerraten, GPU-Auslastung und Speicher-Performance. Diese Kennzahlen zeigen direkt, ob Ihre Inferenzinfrastruktur gesund ist und ob die Endbenutzer eine akzeptable Servicequalität erhalten. Über das betriebliche Monitoring hinaus brauchen Sie eine Bedrohungserkennung. Inferenzserver sind vernetzte Systeme, die zum Ziel von Angreifern werden können. Ungewöhnliche Verkehrsmuster, Versuche der Rechteausweitung oder unerwarteter Ressourcenverbrauch können auf einen Angriff hindeuten. Ihr Sicherheitsmonitoring muss eine Erkennung auf Infrastrukturebene umfassen, die verdächtige Aktivitäten identifiziert. Überwachen Sie zudem Anomalien im Modellverhalten. Verschlechtert sich die Qualität der Inferenz – liefert das Modell plötzlich unsinnige Ausgaben oder steigt die Latenz unerwartet –, kann das auf ein Problem in der Serving-Infrastruktur hindeuten oder darauf, dass das Modell verändert wurde. Wer die Modellausgaben überwacht und mit dem normalen Verhalten vergleicht, kann bestimmte Arten von Angriffen oder Infrastrukturproblemen erkennen. Eine sichere, resiliente Inferenzinfrastruktur aufbauen Die Unternehmen, die ihre Infrastruktur für die LLM-Inferenz am sichersten und zuverlässigsten betreiben, behandeln sie als produktionskritisches System. Sie wenden dieselbe Sorgfalt an wie bei jeder anderen sensiblen Produktionsinfrastruktur. Sie investieren in eine Sicherheitsarchitektur, die die Modellgewichte schützt, in Redundanz und Replikation für die Fehlertoleranz sowie in Monitoring und eine Disaster-Recovery-Planung, die die Verfügbarkeit der Inferenz sicherstellen. Je stärker Ihr Unternehmen von der LLM-Inferenz abhängt, desto wichtiger werden die betrieblichen und sicherheitsbezogenen Anforderungen an diese Infrastruktur. Investieren Sie in hochperformanten KI-Speicher , der die Performance liefert, die die Inferenz erfordert. Setzen Sie Sicherheitskontrollen ein, die Modellgewichte und Inferenzinfrastruktur schützen. Planen Sie Disaster-Recovery-Szenarien und testen Sie sie regelmäßig. Die Kosten von Ausfällen der Inferenzinfrastruktur wachsen mit der Abhängigkeit Ihres Unternehmens. Bauen Sie eine Infrastruktur auf, die resilient, sicher und für den Produktionsbetrieb konzipiert ist. Diese Investition schützt sowohl das geistige Eigentum Ihrer Modelle als auch Ihre Fähigkeit, Benutzer zuverlässig zu bedienen. Weiterführende Artikel Was ist Hochverfügbarkeit (HA)? DRaaS: Disaster Recovery as a Service Datenverschlüsselung: Leitfaden für Compliance- und IT-Verantwortliche Business-Continuity-Plan Immutable Storage und Ransomware-Abwehr (auf Englisch) Datenintegrität bei Festplattenausfällen sichern (auf Englisch)
