Lokal. Cloud. Hybrid.
Entscheidend ist der Betrieb.

„Wir brauchen KI-Infrastruktur“ beschreibt noch keinen auslegbaren Bedarf. Ein interaktiver Assistent, die nächtliche Verarbeitung von Dokumenten und ein zeitlich begrenztes Modelltraining beanspruchen Systeme unterschiedlich. Zuerst wird festgehalten, wer welche Funktion nutzt, welche Daten verarbeitet werden und wie sich Nachfrage über den Tag verteilt. Dazu gehören auch die bestehenden Anwendungen: Ein Modellendpunkt allein bildet selten den vollständigen Dienst, den Mitarbeitende oder Kunden tatsächlich benötigen.

Als fiktives Beispiel betrachten wir einen industriellen Zulieferer. Sein Service benötigt tagsüber Unterstützung bei technischen Anfragen. Neue Dokumente werden außerhalb der Hauptarbeitszeit aufbereitet. Ein Entwicklungsteam untersucht gelegentlich zusätzliche Modelle mit einem dafür freigegebenen Datenbestand. Diese Aufgaben teilen Informationen, benötigen aber nicht zwingend dieselbe Rechenumgebung. Ein Engpass bei einem Experiment sollte den laufenden Service nicht beeinträchtigen; ein verschobener Hintergrundlauf ist anders zu bewerten als ein nicht erreichbarer Kundendienst.

Für jede Aufgabe werden Betriebsziele formuliert. Ein Service Level Objective, kurz SLO, beschreibt beispielsweise, welcher Anteil gültiger Anfragen innerhalb einer festgelegten Zeit beantwortet werden soll. Bei generierenden Anwendungen können Wartezeit bis zur ersten Ausgabe, Dauer der vollständigen Antwort und fachlich brauchbares Ergebnis getrennt relevant sein. Der Durchschnitt reicht dafür nicht: Seltene langsame Antworten können den Arbeitsablauf prägen. Messung und Fehlerbudget müssen deshalb zum tatsächlichen Nutzungserlebnis passen.

Inferenz bedeutet die Ausführung eines bereits bereitgestellten Modells. Training und Anpassung verändern dagegen Modellparameter und können andere Speicher-, Rechen- und Datendurchsatzanforderungen haben. Auch vorbereitende Arbeit wie Dateiextraktion, Bildverarbeitung oder Indexaufbau benötigt Ressourcen, ohne ständig denselben Beschleuniger zu belegen. Die Architektur ordnet diese Tätigkeiten getrennten Lastprofilen zu. So wird sichtbar, welche Kapazität dauerhaft gebraucht wird und welche Aufgabe warten, gebündelt oder zeitweise anderswo ausgeführt werden kann.

Der Anforderungskatalog enthält außerdem Schutzbedarf, zulässige Verarbeitungsorte, erwartete Parallelität, Wartungsfenster und verfügbare Betriebskompetenz. Dazu kommt die Frage, ob ein fertiger Dienst ausreicht oder ein eigenes Modell betrieben werden muss. Eigener Betrieb schafft bestimmte Gestaltungsmöglichkeiten, übernimmt aber auch zusätzliche Aufgaben. Eine kleine, klar beschriebene erste Arbeitslast liefert bessere Entscheidungsdaten als ein umfangreicher Einkauf für noch unbestimmte künftige Anwendungen.

Lokal kann ein eigener Serverraum, eine Anlage am Standort oder eine kundenseitig betriebene Umgebung in einem Rechenzentrum bedeuten. Colocation verlagert beispielsweise die physische Unterbringung, ohne automatisch den Softwarebetrieb zu übernehmen. Auch eine private Cloud ist nicht durch den Standort allein definiert: Entscheidend sind unter anderem Bereitstellung, Nutzung und Verantwortungsmodell. Für eine Entscheidung sollten Eigentum, Verwaltung und tatsächliche Abhängigkeiten deshalb ausdrücklich benannt werden.

In der öffentlichen Cloud reicht das Spektrum von gemieteten Recheninstanzen bis zu weitgehend verwalteten KI-Diensten. Bei Infrastructure as a Service bleibt typischerweise mehr Verantwortung für Betriebssystem, Laufzeit und Anwendung beim Kunden als bei einer verwalteten Modell-API. Welche Tätigkeiten ein Anbieter übernimmt, ist am konkreten Dienst und Vertrag zu prüfen. Datenklassifizierung, Zugriffsvergabe und die fachliche Eignung der Anwendung verschwinden durch die Verlagerung nicht.

Eigener Betrieb kann sinnvoll sein, wenn regelmäßig ausreichend Last anfällt, spezielle Integrationen erforderlich sind oder definierte Aufgaben ohne externe Verbindung verfügbar bleiben sollen. Dafür braucht es geeignete Räume beziehungsweise Hosting, Wartung, Ersatzkapazität und ein zuständiges Team. Cloud-Dienste können einen schnellen Einstieg oder zeitweise zusätzliche Kapazität ermöglichen. Sie bringen ihrerseits Quoten, Dienstgrenzen, laufende Entgelte und vertragliche sowie technische Abhängigkeiten mit. Keines dieser Modelle ist allein durch seine Bezeichnung überlegen.

Eine hybride Lösung verteilt unterschiedliche Aufgaben bewusst. Im Beispiel kann der laufende interne Service lokal ausgeführt werden, während ein freigegebener, separater Datenbestand für gelegentliche Modellvergleiche eine externe Rechenumgebung nutzt. Dafür werden Übergaben und Datenwege festgelegt. Eine Architektur, die bei jeder lokalen Anfrage zwingend einen Cloud-Dienst aufruft, ist nicht automatisch offlinefähig. Umgekehrt schafft ein zusätzlicher lokaler Rechner noch keinen funktionierenden Rückfallweg für einen externen Modellendpunkt.

Die interaktive Topologie zeigt vereinfachte Abhängigkeiten bei Normalbetrieb, Verbindungsstörung und Ausfall eines lokalen Inferenzsystems. Die Cloud-Variante verwendet einen bereits übertragenen, freigegebenen Datenstand; lokale Oberfläche und Datenzugriff sind vom ausgefallenen Inferenzrechner getrennt. Hybrid teilt vertrauliche lokale und für die Cloud erlaubte Aufgaben auf, ohne bei einem Fehler automatisch die Datenklasse zu wechseln. Diese Annahmen bestimmen, welcher Teil weiterarbeiten kann. Für reale Systeme werden zusätzliche Abhängigkeiten und Rückfallwege ausdrücklich ergänzt.

Bei einer lokalen KI-Umgebung ist die Modellgröße nur ein Teil der Dimensionierung. Neben Modellgewichten benötigen Laufzeit, Zwischenergebnisse und die Verarbeitung paralleler Anfragen Speicher. Bei vielen generierenden Sprachmodellen hält ein KV-Cache bereits berechnete Informationen aus dem Kontext vor. Sein Bedarf hängt unter anderem von Modellarchitektur, Kontextlängen, Datenformat und Gleichzeitigkeit ab. Eine Konfiguration, die eine einzelne kurze Anfrage verarbeitet, kann bei längeren oder mehreren gleichzeitigen Anfragen an eine andere Grenze stoßen.

RAM und Beschleunigerspeicher erfüllen unterschiedliche Aufgaben. Große Mengen Arbeitsspeicher ersetzen nicht ohne Weiteres den schnellen Speicher am Beschleuniger. Eine Auslagerung kann bestimmte Konfigurationen ermöglichen, verändert aber Datenwege und Laufzeitverhalten. Ebenso ist die Summe mehrerer Speichergrößen kein Beleg, dass ein Modell ohne geeignete Aufteilung und Kommunikation effizient darauf läuft. Die tatsächliche Softwareunterstützung, Verbindung zwischen Recheneinheiten und das konkrete Lastprofil müssen gemeinsam geprüft werden. Auch CPU-Leistung bleibt wichtig, etwa für Dateiextraktion, Vorverarbeitung und Anwendungslogik. Ob eine Aufgabe einen Beschleuniger benötigt, ergibt sich aus gemessenem Durchsatz und Antwortverhalten, nicht allein aus dem Etikett KI.

Quantisierung verändert die numerische Darstellung und kann Speicherbedarf reduzieren. Sie ist jedoch keine pauschal verlustfreie Abkürzung. Fachliche Qualität und Geschwindigkeit werden mit der verwendeten Modellfassung und Laufzeit erneut untersucht. Batching kann den Durchsatz erhöhen, beeinflusst aber das Antwortverhalten einzelner Anfragen. Lange Eingaben, umfangreiche Ausgaben und viele parallele Sitzungen konkurrieren um Ressourcen. Ein Benchmark muss deshalb realistische Kombinationen dieser Größen enthalten, statt nur den schnellsten Einzelwert zu dokumentieren.

Das Kapazitätsmodell betrachtet gleichartige Anfragen mit einer angenommenen, konstanten Bearbeitungsleistung je Instanz. Liegt der Eingang über dieser Leistung, wächst im vereinfachten Modell der Rückstand. In der Praxis schwanken Laufzeiten und Eingangsverläufe; zudem können Speichergrenzen, Scheduler und Warteschlangenregeln eingreifen. Die Grafik ist deshalb keine Vorhersage der Antwortzeit. Sie erklärt, warum ein guter Monatsdurchschnitt eine kurze, aber geschäftlich relevante Lastspitze verdecken kann. Die angenommene Leistung je zusätzlicher Instanz setzt unabhängig verfügbare, vergleichbare Ressourcen voraus. Mehrere Prozesse auf demselben bereits ausgelasteten Beschleuniger vervielfachen dessen Kapazität nicht.

Zur Auslegung gehören schließlich Stromversorgung, Kühlung, Stellfläche, Geräuschentwicklung und Wartungszugang. Die maximale elektrische Anschlussleistung und der tatsächliche Verbrauch im Lastprofil sind verschiedene Größen. Für produktive Systeme werden auch Treiberpflege, Ersatzteile, Wartungsdauer und Kapazität während eines Ausfalls betrachtet. Eine zusätzliche Instanz dient nicht nur dem Wachstum: Sie kann für Wartung oder Redundanz vorgesehen sein und darf dann nicht vollständig als frei verfügbare Dauerleistung verplant werden.

Der Speicherplan unterscheidet Originaldaten, verarbeitete Daten, Indizes, Modellartefakte und Betriebsinformationen. Diese Bestände haben verschiedene Anforderungen an Verfügbarkeit, Zugriffsverhalten und Wiederherstellung. Originale können zentral verwaltet werden, während häufig genutzte Arbeitsdaten nahe an der Verarbeitung liegen. Ein schneller lokaler Index kann die Nutzung unterstützen; sein Neuaufbau benötigt trotzdem Eingaben, Versionen und ausreichend Zeit. Welche Daten ersetzbar sind, wird dokumentiert und nicht nur angenommen.

Ein NAS kann eine geeignete zentrale Ablage sein, ist aber nicht automatisch für jedes Zugriffsprofil der schnellste oder einzige sinnvolle Speicherort. Viele kleine Zugriffe, parallele Leser und große sequenzielle Übertragungen beanspruchen ein System unterschiedlich. Zu prüfen sind auch Metadatenoperationen, Protokollverhalten und die Konkurrenz durch Sicherungen oder andere Anwendungen. Lokale schnelle Laufwerke können Arbeitsbestände aufnehmen, benötigen jedoch eine klare Regel für Synchronisation, Wiederaufbau und Verlust des Rechners.

Netzwerkplanung umfasst Durchsatz, Latenz, Ausfallsicherheit und die tatsächlichen Wege zwischen Diensten. Mehrere gebündelte Anschlüsse bedeuten nicht automatisch, dass eine einzelne Übertragung die Summe ihrer Bandbreiten nutzt. Bei üblichen LACP-Konfigurationen werden Verbindungen auf einzelne Links verteilt. Ein scheinbar ausreichend dimensionierter Gesamtanschluss kann daher für einen bestimmten Datenstrom begrenzt bleiben. Messungen sollten den realen Pfad abbilden, einschließlich Switches, Firewalls, Tunnel und beteiligter Speichersysteme.

Bei einer Verteilung zwischen Standorten und Cloud wird die Bewegung der Daten selbst zur Architekturfrage. Große Bestände wiederholt zu übertragen kann Zeit, Bandbreite und Kosten beanspruchen. Oft ist es sinnvoll, Verarbeitung nahe am vorhandenen Datenbestand zu organisieren und nur definierte Ergebnisse oder freigegebene Teilmengen zu bewegen. Dafür müssen Aktualität, Löschung und Zuständigkeit über alle Kopien hinweg geklärt sein. Ein weiterer Speicherort erhöht sonst vor allem die Zahl möglicher widersprüchlicher Fassungen.

RAID, Replikation und Snapshots erfüllen andere Aufgaben als eine unabhängig geschützte Datensicherung. Eine redundante Speicherung kann bestimmte Geräteausfälle abfangen, übernimmt aber unter Umständen auch versehentliche Löschungen oder schädliche Änderungen. Ein Sicherungskonzept benennt deshalb geschützte Kopien, Aufbewahrung, getrennte Zugriffe und Wiederherstellungswege. Neben Daten gehören Konfigurationen und erforderliche Schlüssel in die Planung. Erst ein Wiederherstellungstest zeigt, ob die vollständige Anwendung daraus in der vorgesehenen Zeit wieder nutzbar wird.

Eine lokale Installation kann schlecht abgesichert sein; ein externer Dienst kann geeignete Schutzmechanismen bereitstellen. Für die Bewertung zählt, wie Identitäten, Daten und administrative Rechte tatsächlich behandelt werden. Die Architektur unterscheidet Nutzerzugänge, technische Dienstkonten und privilegierte Administration. Berechtigungen werden an Aufgaben gebunden, regelmäßig überprüft und beim Wegfall des Bedarfs entzogen. Gemeinsame, dauerhaft weitreichende Zugangsschlüssel erschweren dagegen die Zuordnung und Begrenzung von Zugriffen.

Anwendung, Datenhaltung, Entwicklungsumgebung und Verwaltung erhalten passende Netzwerkgrenzen. Ein Modellserver muss nicht unmittelbar aus allen Netzen erreichbar sein. Kontrollierte Ein- und Ausgänge erlauben, zugelassene Dienste, Datenarten und Authentisierung zu prüfen. Schlüssel gehören in eine dafür geeignete Verwaltung mit Rotation und geregeltem Zugriff. Verschlüsselung schützt bestimmte Datenwege und Speicherzustände; sie ersetzt jedoch keine Prüfung, wer während der Verarbeitung auf Inhalte zugreifen kann.

Bei KI können Eingaben, Ausgaben, Diagnosedaten und Protokolle sensible Informationen enthalten. Logging sollte den Betrieb erklären, ohne automatisch vollständige vertrauliche Inhalte dauerhaft zu sammeln. Für Fehlersuche, Sicherheitsanalyse und fachliche Evaluation können unterschiedliche Daten und Aufbewahrungszeiten erforderlich sein. Das Team definiert, welche Informationen überhaupt protokolliert werden, wer sie sehen darf und wie sie gelöscht werden. Eine komfortable Entwicklungsprotokollierung ist nicht ohne weitere Prüfung die passende Produktionskonfiguration.

Für personenbezogene Daten werden Zweck, Rechtsgrundlage, erforderlicher Umfang und Schutzmaßnahmen auf den konkreten Einsatz abgestimmt. Beim Dienstleister kommen unter anderem vertragliche Rollen, Unterauftragnehmer, Verarbeitungsorte und mögliche internationale Übermittlungen hinzu. Die Auswahl einer europäischen Speicherregion beantwortet nicht automatisch alle Fragen zu Zugriffen und Verarbeitung. Umgekehrt entsteht durch lokale Speicherung allein noch keine DSGVO-konforme Anwendung. Fachliche Datenfreigabe und technische Umsetzung müssen dieselben Grenzen abbilden.

Das gilt auch für Modelle, Laufzeitpakete und Container-Images. Herkunft, Lizenz, Integrität und Updateweg werden geprüft; Tests und Produktion sollten nachvollziehbare Stände verwenden. Ein neues Paket darf nicht allein deshalb in den Betrieb gelangen, weil es im Experiment funktioniert. Für Änderungen braucht es Zuständigkeit und Rückkehrmöglichkeit. Sicherheitsanforderungen werden so zu konkreten Betriebsaufgaben, die sowohl im eigenen Rechenzentrum als auch bei ausgelagerten Komponenten erfüllt und kontrolliert werden müssen.

Eine Anwendung kann an Identität, Datenbank, Modelllaufzeit, Speicher, Netzwerk oder einem externen Dienst scheitern. Verfügbarkeit wird deshalb vom Nutzungsfall aus betrachtet. Welche Abhängigkeiten müssen für eine gültige Antwort funktionieren? Welche Aufgaben dürfen mit älteren Daten weiterlaufen, welche müssen geordnet warten? Ein Betriebsdiagramm sollte diese Unterschiede sichtbar machen. Für kritische Pfade werden Einzelpunkte des Versagens und gemeinsame Ausfallursachen untersucht, etwa eine gemeinsame Stromversorgung oder eine einzige Verwaltungsidentität. Dabei werden Verarbeitung und Verwaltung unterschieden: Ein laufender Dienst kann lokal rechnen und trotzdem für Anmeldung, Lizenzprüfung, Modelldownload oder Überwachung externe Komponenten benötigen. Diese Abhängigkeiten gehören ebenso ins Verzeichnis wie die eigentlichen Nutzdatenwege.

Die Verantwortlichen legen Wiederherstellungsziele fest. Das Recovery Time Objective, RTO, beschreibt die angestrebte Dauer bis zur Wiederaufnahme; das Recovery Point Objective, RPO, den zeitlichen Umfang eines akzeptablen Datenverlusts. Beide Ziele entstehen aus dem Geschäftsprozess. Ein täglich gesicherter Bestand passt nicht zu jeder Anforderung, und ein kurzfristig verfügbarer Ersatzrechner hilft wenig, wenn die Wiederherstellung der benötigten Daten deutlich länger dauert. Ziele und Verfahren werden gemeinsam erprobt.

Ein Backup ist kein automatischer Failover. Für einen Ausweichbetrieb müssen beispielsweise Datenstand, Anwendung, Modell, Identitäten, Netzwerkfreigaben und Kapazität zusammenpassen. Auch ein Wechsel auf einen anderen Modellanbieter kann das fachliche Ergebnis verändern. Er benötigt eine dafür freigegebene Anwendungskonfiguration. Wo ein zweiter vollständiger Betriebsweg unverhältnismäßig wäre, kann ein klar kommunizierter eingeschränkter Betrieb oder ein manueller Ablauf die angemessenere Lösung sein. Die Entscheidung wird vor der Störung getroffen.

Beobachtbarkeit verbindet technische und anwendungsbezogene Signale. Dazu gehören Fehlerraten, Wartezeiten, abgewiesene Anfragen, Queue-Länge und Ressourcenbedarf sowie Aktualität der Daten und Erfolg der Hintergrundläufe. Ein vollständig belegter Beschleunigerspeicher ist nicht automatisch ein Fehler; er kann zum Betriebsverhalten der Laufzeit gehören. Aussagekräftig wird ein Signal im Zusammenhang mit dem Dienstziel. Alarmierungen brauchen einen zuständigen Empfänger, einen nachvollziehbaren Handlungsweg und eine sinnvolle Priorität.

Updates werden in einer kontrollierten Umgebung geprüft und schrittweise übernommen. Betriebssystem, Treiber, Laufzeit, Modell und Anwendung bilden einen zusammenhängenden Stand. Ein Rollback benötigt nicht nur eine alte Datei, sondern einen kompatiblen Zustand von Konfiguration und Daten. Regelmäßige Übungen umfassen deshalb Wiederherstellung, Ablauf von Zugangsdaten, Verbindungsunterbrechung und den Ausfall einer wichtigen Komponente. Gute Übungen zeigen auch, welche Dokumentation und Kontakte im Störfall außerhalb des betroffenen Systems erreichbar sein müssen.

Ein Vergleich benötigt denselben Leistungsumfang. Werden auf der einen Seite nur einzelne Modellaufrufe gerechnet, auf der anderen jedoch Speicher, Redundanz und Betriebspersonal, entsteht kein brauchbarer Kostenvergleich. Zuerst wird festgelegt, welche Aufgabe mit welcher Qualität, Last und Verfügbarkeit erbracht werden soll. Darauf beziehen sich Kosten je nutzbarem Ergebnis und über einen gemeinsamen Zeitraum. Auch ein günstiger technischer Aufruf ist kein wirtschaftlicher Erfolg, wenn die Anwendung ständig manuell nachbearbeitet werden muss.

Beim eigenen Betrieb gehören Anschaffung oder Leasing, Einrichtung, Integration und gegebenenfalls räumliche Anpassungen zur Betrachtung. Laufend entstehen unter anderem Energie, Hosting, Wartung, Sicherung und personeller Aufwand. Nicht jede Position verändert sich unmittelbar mit der Zahl der Anfragen. Ein gering ausgelastetes System verursacht weiterhin fixe Kosten; eine notwendige Reserve ist ebenfalls zu finanzieren. Die angenommene Nutzungsdauer und der Umgang mit Ersatzinvestitionen müssen nachvollziehbar sein.

Bei Cloud-Diensten können neben Rechenzeit oder Modellnutzung auch Speicher, Datentransfer, verwaltete Komponenten, Support und Mindestabnahmen relevant sein. Der konkrete Tarif bestimmt, welche Mengen und Zeiträume abgerechnet werden. Eine ausgeschaltete Recheninstanz beseitigt nicht zwingend alle übrigen Kosten. Ebenso kann eine günstige langfristige Bindung Flexibilität reduzieren. Das Team benötigt eine Zuordnung nach Anwendung oder Kostenstelle, Budgetgrenzen und eine Kontrolle unerwarteter Nutzung, ohne allein auf eine verspätete Monatsrechnung angewiesen zu sein. Auch Einrichtung, Integration und Migration können einmalige Kosten verursachen; ein nutzungsabhängiger Tarif macht den Einstieg nicht automatisch aufwandsfrei.

Das interaktive Kostenmodell trennt fixe und nutzungsabhängige Annahmen für zwei vereinfachte Varianten. Es rechnet mit vergleichbaren Arbeitseinheiten über einen gewählten Zeitraum und zeigt, wie Last und angesetzte Kosten das Verhältnis verändern. Es enthält keine aktuellen Anbieterpreise und wählt keine Architektur automatisch aus. Nicht abgebildete Positionen werden für eine reale Entscheidung ergänzt; gemeinsam anfallende Kosten dürfen weder vergessen noch auf einer Seite doppelt angesetzt werden. Eine Kostenrechnung bestätigt außerdem nicht, dass die betrachtete Kapazität das Lastprofil tatsächlich bewältigt.

Für die Entscheidung sind mehrere Verläufe hilfreicher als ein einzelner Punkt: geringe Nutzung während des Einstiegs, erwarteter Dauerbetrieb und ein Wachstumsszenario mit zusätzlichen Ressourcen. Besonders relevant ist, wann eine Kapazitätsstufe oder ein Vertragswechsel nötig wird. Der Wechsel verläuft selten vollständig linear. Hybrider Betrieb kann bestimmte Lasten wirtschaftlich verteilen, bringt aber eigene Integrations- und Betriebsaufwände mit. Eine Entscheidungsvorlage verbindet daher Kosten, technische Eignung und verfügbare Kompetenzen, statt nur den niedrigsten rechnerischen Betrag zu markieren.

Modelle, Laufzeiten und Angebote ändern sich schneller als viele Beschaffungszyklen. Deshalb sollte die Anwendung wichtige Entscheidungen von austauschbaren Komponenten trennen. Ein klar definierter Modellzugang, versionierte Konfigurationen und dokumentierte Datenformate erleichtern Änderungen. Sie garantieren noch keine beliebige Austauschbarkeit. Zwei Dienste können ähnliche Schnittstellen anbieten und sich trotzdem bei Kontextgrenzen, Werkzeugaufrufen, Ausgabeformaten, Fehlerverhalten und Antwortqualität unterscheiden.

Portabilität wird praktisch überprüft. Lässt sich ein benötigter Datenbestand einschließlich Metadaten und Berechtigungen exportieren? Sind Modellgewichte, Adapter, Lizenzen und Laufzeit für den geplanten Ausweichort verfügbar? Können Images und Konfigurationen reproduzierbar bereitgestellt werden? Ein Wechsel braucht außerdem Zugänge, Kapazität, Netzwerkanbindung und Zeit für Tests. Ein Standardformat ist hilfreich, ersetzt aber keinen durchgespielten Wechsel mit einer realistischen Teilmenge.

Für Anwendungen mit Suchindizes ist zwischen Originalbestand und abgeleitetem Zustand zu unterscheiden. Ein Index kann von einer bestimmten Modellfassung, Konfiguration oder Datenbank abhängen. Nach einem Wechsel kann ein Neuaufbau notwendig werden. Die dafür benötigte Dauer und Rechenleistung gehören in den Migrationsplan. Auch fachliche Vergleichstests werden erneut ausgeführt: Ein technisch erreichbarer Endpunkt belegt nicht, dass die bisherige Anwendung mit den neuen Antworten unverändert zuverlässig arbeitet.

Ein sinnvoller Exit-Plan benennt Auslöser, Verantwortliche, Datenumfang und die Reihenfolge des Übergangs. Gründe können veränderte Kosten, fachliche Anforderungen, Vertragsbedingungen oder ein nicht mehr passendes Betriebsmodell sein. Parallelbetrieb kann einen Wechsel absichern, verursacht aber vorübergehend zusätzliche Arbeit und Kosten. Danach werden alte Zugänge, Kopien und laufende Ressourcen gezielt bereinigt. Ohne diesen Abschluss bleiben sowohl Risiken als auch Ausgaben bestehen.

Offene Komponenten können Gestaltungsspielraum schaffen, benötigen jedoch Pflege und die Prüfung ihrer jeweiligen Nutzungsbedingungen. Verwaltete Dienste können Aufwand abnehmen, erfordern aber Transparenz über Grenzen und Abhängigkeiten. Die Architektur hält diese Abwägung sichtbar. Das Ziel ist keine theoretisch vollständig anbieterfreie Umgebung, sondern eine begründete Bindung mit einem realistischen Weg für die Änderungen, die im eigenen Geschäft wahrscheinlich werden.

Der Einstieg beginnt mit einem kurzen Architekturprofil: Anwendung, Datenarten, Lastprofile, Dienstziele, Schutzbedarf und Verantwortliche. Bestehende Infrastruktur und Betriebskompetenz werden ebenso erfasst wie offene Annahmen. Daraus entstehen wenige vergleichbare Varianten. Für den fiktiven Zulieferer könnten dies ein verwalteter Modellzugang, ein eigener Inferenzdienst und eine getrennte Ausführung von internem Tagesgeschäft und externen Experimenten sein. Jede Variante muss dieselbe erste Aufgabe erfüllen, bevor zusätzliche Möglichkeiten bewertet werden.

Ein Benchmark verwendet repräsentative Eingaben und festgehaltene Modell- und Softwarestände. Er prüft nicht nur den warmen Einzelaufruf, sondern auch parallele Nutzung, längere Eingaben, Hintergrundlast und den Start nach einer Unterbrechung. Fachliche Ergebnisqualität, Antwortverhalten und Kosten werden zusammen erfasst. Ergebnisse gelten für die geprüften Bedingungen. Wenn eine andere Modellfassung oder ein längerer Kontext vorgesehen ist, braucht diese Änderung eine erneute Bewertung statt einer stillschweigenden Übernahme alter Messwerte.

Der begrenzte Pilot integriert Identität, Datenzugriff, Protokollierung, Budgetkontrolle und Support. Er soll zeigen, ob die Anwendung im vorgesehenen Arbeitsumfeld betreibbar ist. Dazu gehören die bewusste Unterbrechung ausgewählter Abhängigkeiten und ein Wiederherstellungstest. Ein Dienst, der nur unter Betreuung des Entwicklungsteams funktioniert, hat seine Betriebsreife noch nicht gezeigt. Die Übergabe macht daher sichtbar, wer bei Störungen entscheidet und welche Tätigkeiten das interne Team oder ein Partner übernimmt.

Vor einem Ausbau werden Kapazitätsgrenzen, Wartungswege und Kosten erneut betrachtet. Eine zusätzliche Fachabteilung kann andere Daten, längere Anfragen oder höhere Verfügbarkeitsanforderungen mitbringen. Skalierung bedeutet deshalb nicht nur mehr Rechenleistung. Sie kann neue Berechtigungsmodelle, Prioritäten und Betriebsprozesse erfordern. Regelmäßige Überprüfung verbindet gemessene Nutzung mit dem nächsten Investitionsschritt und verhindert, dass ein ursprünglich kleiner Pilot unbemerkt zu einer unbetreuten Kernanwendung wird.

Scalevity unterstützt die Verbindung von fachlicher Anwendung, Softwarearchitektur und IT-Betrieb: Anforderungen einordnen, Varianten vergleichen, Schnittstellen und Datenwege gestalten sowie einen prüfbaren Pilot entwickeln. Physische Infrastruktur, Hosting und spezialisierte Sicherheitsaufgaben werden mit den jeweils zuständigen Teams und Partnern abgestimmt. Das Ergebnis ist eine nachvollziehbare Entscheidung darüber, was wo läuft, wer es betreibt und anhand welcher Kriterien die Architektur später verändert wird.