Was erfordern Air-Gap-Modelle wirklich?

Air-Gap-Modelle erfordern weit mehr als einen GPU-Server, dessen Netzwerkkabel abgezogen wurde. Eine brauchbare Definition lautet: Es ist ein System, dessen Inferenzdaten, Modellartefakte, Administrationsweg, Protokolle und Update-Prozess die Sicherheitsgrenze nur über ein ausdrücklich freigegebenes und geprüftes Transferverfahren überschreiten können. Wenn ein Techniker für die Installation eines Pakets den Internetzugang wiederherstellen kann oder ein Management-Controller weiterhin einen Anbieter-Cloud-Dienst aufruft, hat das Konzept eine Lücke im gewöhnlichen Sinn und keinen Air Gap im sicherheitstechnischen Sinn.

Diese Unterscheidung verändert die Beschaffung. Sie übernehmen die Verantwortung für Hardwarekapazität, Verwahrung der Modelle, Softwareabhängigkeiten, Identitäten, Überwachung, Wiederherstellung nach Fehlern und jedes spätere Update. Außerdem akzeptieren Sie, dass manche gehosteten Funktionen um keinen Preis intern betrieben werden können, weil der Anbieter seine Modellgewichte nicht herausgibt. Für Quellcode, Produktionsdaten, exportkontrolliertes Material oder regulierte Arbeitslasten kann das trotzdem die richtige Lösung sein, sofern das Betriebsmodell feststeht, bevor die Server eintreffen.

Ein Air Gap ist eine geregelte Datenflussgrenze

Eine Maschine ist nur dann air-gapped, wenn jeder Weg über ihre Grenze entweder fehlt oder als kontrolliertes Transferereignis behandelt wird. Teams prüfen oft das Anwendungsnetz und vergessen den Baseboard-Management-Controller, die Hypervisor-Verwaltung, Speicherreplikation, DNS, Zeitsynchronisation, Telemetrie-Exporter, Lizenzprüfungen, Absturzberichte und den Laptop, den ein Administrator auf beiden Seiten benutzt. Jeder dieser Wege kann aus einer angeblich geschlossenen Umgebung eine teilweise verbundene machen.

Beginnen Sie mit vier Flüssen: Eingabedaten, Ausgabedaten, Softwarelieferung und Administration. Zeichnen Sie jede Quelle und jedes Ziel ein. Vermerken Sie Protokoll, verwendete Identität, freigabeberechtigte Person und aufbewahrte Nachweise. Ein Diagramm mit der Beschriftung „Offline-Cluster“ sagt einem Prüfer fast nichts. Ein Flussverzeichnis mit dem Eintrag „signiertes Release-Paket gelangt nach Freigabe durch zwei Personen über Transferstation T1 hinein“ beschreibt eine Kontrolle, die Techniker umsetzen und testen können.

Es gibt mehrere vertretbare Isolationsstufen. Sie alle Air Gap zu nennen, führt zu schlechten Entscheidungen. Ein privates Subnetz mit gesperrtem ausgehendem Verkehr hängt weiterhin von verbundenen Routern, Cloud-Steuerungen und Identitätsdiensten ab. Eine getrennte Umgebung kann geplante Importe über ein überwachtes Gateway annehmen. Ein physischer Air Gap hat keinen aktiven Netzwerkpfad und bewegt freigegebene Artefakte auf kontrollierten Datenträgern oder über eine speziell gebaute Einwegverbindung. Wählen Sie die Stufe anhand des Bedrohungsmodells und verwenden Sie anschließend in Verträgen und Architekturprüfungen den korrekten Begriff.

NIST SP 800-53 behandelt Medienschutz, Medientransport, Grenzschutz, Konfigurationsverwaltung und Audit als getrennte Kontrollfamilien. Diese Trennung ist nützlich. Das Entfernen einer Route beantwortet nicht, wer ein Update transportieren darf, wie der Datenträger geprüft wird, ob die empfangende Seite ihn verifiziert oder wie Administratoren Änderungen belegen. Bei einem Air Gap müssen alle diese Kontrollen zusammenspielen.

Testen Sie die Behauptung, statt dem Diagramm zu vertrauen. Erfassen Sie Netzwerkschnittstellen und Funkmodule, verfolgen Sie Switch-Ports, prüfen Sie Management-Controller, versuchen Sie DNS- und ausgehende Verbindungen aus jedem Workload-Namensraum und kontrollieren Sie, wohin Protokolle gesendet werden. Wiederholen Sie die Prüfungen nach Wartungsarbeiten, denn vorübergehender Diagnosezugang wird erstaunlich oft zu dauerhafter Infrastruktur.

Das Bedrohungsmodell bestimmt, was intern bleiben muss

Die Grenze muss jene Werte und Abläufe einschließen, deren Offenlegung oder externe Abhängigkeit Sie nicht akzeptieren können. Dennoch betreiben viele Teams nur die Inferenz intern, während Prompts in einem verbundenen Dienst vorbereitet, Ergebnisse in ein gehostetes Ticketsystem kopiert oder Traces mit Quellcode an die Beobachtungsplattform übertragen werden. Die GPU hat lokal gearbeitet, die Arbeitslast jedoch nicht.

Trennen Sie drei Ebenen. Die Datenebene transportiert Prompts, abgerufene Dokumente, Modellantworten, Einbettungen und Werkzeugergebnisse. Die Steuerungsebene übernimmt Benutzeridentität, Planung, Richtlinien, Geheimnisse, Protokollierung und Administration. Die Lieferkette bringt Gewichte, Container, Betriebssystempakete, Treiber, Firmware und Informationen zu Schwachstellen hinein. Wenn Sie nur die Datenebene schließen, bleiben zwei breite Wege für Angriffe oder Datenabfluss offen.

Erstellen Sie ein Bedrohungsmodell mit benannten Gegnern und Fehlerfällen. Ein Team für regulierte Datensätze sorgt sich vielleicht vor allem um versehentliche Offenlegung und nachweisbare Verwahrung. Ein Verteidigungsprojekt kann zusätzlich einen fähigen Lieferkettenangreifer annehmen. Eine Fabrik kann den Weiterbetrieb bei Ausfall externer Verbindungen priorisieren. Diese Anforderungen führen zu verschiedenen Transferregeln, Redundanzen und Prüftiefen. „Die Sicherheit verlangt es“ ist zu ungenau, um Hardware auszuwählen oder eine Ausnahme zu genehmigen.

Legen Sie fest, welche Ausgaben die Grenze verlassen dürfen. Ein umgeschriebener Quellbaum kann Kommentare, Zugangsdaten, Kundennamen und Logik enthalten, die schon in der Eingabe standen. Eine Modellantwort ist nicht automatisch bereinigt, nur weil sie neu erzeugt wurde. Wenn Ergebnisse die Grenze überschreiten, behandeln Sie das als Export mit Inhaltsprüfung, Freigabeperson, Ziel und Protokoll. Das Gleiche gilt für Support-Pakete: Stack-Traces und Prompt-Mitschnitte enthalten oft genau das Material, das der Air Gap schützen sollte.

Die unbequeme Frage betrifft die Menschen, die das Konzept umgehen könnten. Wenn Betreiber Fehlermeldungen mit privaten Telefonen fotografieren, Befehle aus einem verbundenen Chat abtippen oder beliebige USB-Geräte zwischen Zonen bewegen, verschiebt die formale Netzwerkgrenze lediglich den Datenweg. Stellen Sie eine interne Dokumentationskopie, durchsuchbare Betriebshandbücher, freigegebene Transfermedien und ein Supportverfahren bereit, das auch unter Druck funktioniert. Kontrollen, die eine Wiederherstellung unmöglich machen, werden beim ersten ernsten Ausfall umgangen.

Hardware wird nach der Arbeitslast dimensioniert, nicht nach der Modellkarte

Dimensionieren Sie einen isolierten Inferenz-Cluster anhand gemessener Anfragen, Parallelität, Kontextlänge, Latenz und Verfügbarkeit. Wählen Sie dann Modell und Genauigkeit passend dazu. Genügend GPU-Speicher zum Laden der Gewichte beweist nur, dass ein Prozess starten kann. Die Produktion braucht zusätzlich Speicher für Key-Value-Cache, Aktivierungen, Laufzeit-Arbeitsbereiche, parallele Ausführungskontexte und den Serving-Stack.

Eine erste Schätzung der Gewichtsgröße ist einfach:

weight_bytes ~= parameter_count * bits_per_weight / 8
required_vram = weights + kv_cache + activations + runtime_workspace + safety_margin

Die erste Zeile ist eine Untergrenze, kein Angebot. Quantisierte Formate enthalten Skalen und Metadaten. Manche Architekturen aktivieren pro Token nur einen Teil ihrer Parameter, müssen aber dennoch alle Experten im Speicher halten. Die TensorRT-Dokumentation von NVIDIA weist praktisch darauf hin, dass ein serialisiertes Engine-Paket den Gewichtsspeicher ungefähr abbildet, während Ausführungskontexte dauerhaften und Enqueue-Speicher hinzufügen. Sie empfiehlt auch, freien Gerätespeicher zu messen und Arbeitsbereiche ausdrücklich zu begrenzen. Das ist sinnvoller, als die Parameterzahl zu multiplizieren und die nächstgrößere GPU zu bestellen.

Messen Sie den echten Serving-Build auf genau der vorgesehenen Hardware. Verwenden Sie repräsentative Ein- und Ausgabelängen, einschließlich langer Anfragen, die den Cache dominieren. Erfassen Sie Zeit bis zum ersten Token, Token pro Sekunde, Wartezeit, maximalen Gerätespeicher, Hauptspeicher, Speicherlesevorgänge beim Start und die Erholung nach Ausfall eines Workers. Führen Sie genügend parallele Anfragen aus, damit das Verhalten des Schedulers sichtbar wird. Ein einzelner interaktiver Prompt verbirgt das Kapazitätsproblem.

Auch CPU-RAM und Speicherplatz zählen. Sie brauchen möglicherweise Platz für aktuelle und vorige Gewichte, eine entpackte Staging-Kopie, Container-Schichten, Engine-Caches, Evaluationsdaten und Auditprotokolle. Wenn ein Rollback nur möglich ist, indem das einzige bekannte gute Modell gelöscht wird, war der Speicher zu klein. Schneller lokaler Speicher verkürzt Neustarts, während ein langsamer gemeinsamer Speicher dazu führen kann, dass alle Knoten gleichzeitig zurückkehren und am selben Engpass warten.

Die Ausführung über mehrere GPUs löst ein Speicher- oder Latenzproblem, fügt aber Kommunikation und eine weitere Fehlerdomäne hinzu. NVIDIA dokumentiert, dass die Aufteilung der Ausführung den Speicherdruck pro Gerät senkt, jedoch Inter-GPU-Kommunikation kostet. Prüfen Sie Topologie, Peer-to-Peer-Pfad und Kollektivbibliotheken mit denselben Treiber- und Firmwareversionen, die in Produktion vorgesehen sind. Zwei GPUs in einer Stückliste garantieren keine brauchbare Tensorparallelität.

Verfügbarkeit vervielfacht den Bedarf. Wenn Wartung oder ein Hardwarefehler die Inferenz nicht stoppen dürfen, planen Sie genügend Kapazität ein, um beim größten erlaubten Ausfall die Latenzziele weiter zu erreichen. Dafür können ein Ersatzknoten, freie GPU-Kapazität über mehrere Knoten, redundante interne Registries und vor Ort gelagerte Ersatzteile nötig sein. Ein Hosting-Anbieter versteckt einen großen Teil dieser Reserve im Dienstpreis. Innerhalb der Grenze tragen Sie sie selbst.

Kapazitätstests müssen Strom- und Temperaturgrenzen abdecken, nicht nur Softwaredurchsatz. Ein dicht bestückter Beschleunigerknoten kann einen kurzen Benchmark bestehen und bei längerer Last drosseln, weil das Rack die Wärme nicht abführt oder eine Stromzufuhr nicht alle Geräte unter Volllast trägt. Zeichnen Sie Taktraten, Temperaturen, korrigierte Hardwarefehler und Leistungsaufnahme während eines Dauertests auf. Fragen Sie das Gebäudeteam, was beim Ausfall einer Stromzufuhr oder Kühlung passiert, und wiederholen Sie die Leistungsrechnung unter diesen Bedingungen.

Qualifizieren Sie eine vollständige Hardware- und Softwarebasis: Server-Firmware, Management-Controller-Firmware, GPU-Firmware, Treiber, Laufzeit, Kernel, Container-Image und Inferenz-Engine. Eine optimierte Engine kann für eine bestimmte GPU-Generation oder Softwarekombination gebaut sein. Der Import einer vorgebauten Engine ohne passendes Ziel kann daher innerhalb der Zone beim Start scheitern. Halten Sie den Build-Prozess intern verfügbar oder geben Sie eine Engine erst frei, nachdem sie auf der Produktionshardwareklasse gelaufen ist.

Gehen Sie nicht davon aus, dass CPU-Inferenz einen brauchbaren Notbetrieb ermöglicht. Sie kann ein kleines Modell am Leben halten, doch Latenz und Speicherbandbreite können dazu führen, dass die Hauptarbeitslast jedes Serviceziel verfehlt. Messen und benennen Sie den Modus korrekt: eingeschränkter Dienst, reine Stapelverarbeitung oder kein Fallback. Dasselbe gilt für gemischte Beschleunigerflotten. Verschiedene Geräte können verschiedene Engines erfordern und Planung sowie Reserve schwieriger machen, als der Einkaufspreis vermuten lässt.

Reservieren Sie schließlich eine Qualifizierungsstrecke. Wenn alle GPUs Produktionsverkehr bedienen, muss jedes Treiber-, Laufzeit- und Gewichtsupdate entweder auf abweichender Hardware oder direkt im Live-Pool getestet werden. Ein kleiner repräsentativer Knoten kann Importe prüfen, Engines neu bauen, Evaluationen ausführen und Kompatibilitätsfehler vor der Freigabe zeigen. Das kostet Kapazität, doch noch teurer ist die Feststellung nach einem Notfall-Patch, dass dem einzigen internen Compiler-Image eine Abhängigkeit fehlt.

Gewichte brauchen Verwahrung, Lizenzen und reproduzierbare Identität

Modellgewichte sind ausführbare Eingaben mit Rechtsbedingungen, Sicherheitsfolgen und einer genauen Identität. Wer sie wie eine große Datei von einer Workstation kopiert, verliert die Informationen, die für Reproduktion oder Untersuchung einer Bereitstellung nötig sind. Der Release-Datensatz sollte Gewichtsdateien mit Modellkonfiguration, Tokenizer, Inferenzlaufzeit, Adaptern, Container-Images, Lizenzen und Evaluationsergebnis verbinden.

Verwenden Sie unveränderliche Digests statt veränderlicher Namen wie latest oder einer bloßen Modellbezeichnung. Die Open Container Initiative Image Specification verlangt, dass Deskriptoren einen Inhalts-Digest und eine Größe enthalten, und empfiehlt, empfangene Bytes vor der Nutzung zu prüfen. Dieses Prinzip gilt auch, wenn Gewichte als gewöhnliche Dateien transportiert werden. Ein signiertes Manifest sollte jedes Artefakt mit SHA-256, Bytezahl, Quelle, geprüfter Lizenz und Freigabevorgang aufführen.

Ein minimales Paket lässt sich mit Werkzeugen prüfen, die in fast jeder kontrollierten Build-Umgebung vorhanden sind:

$ sha256sum -c SHA256SUMS
weights/model-00001-of-00004.safetensors: OK
weights/model-00002-of-00004.safetensors: OK
weights/model-00003-of-00004.safetensors: OK
weights/model-00004-of-00004.safetensors: OK
config/tokenizer.json: OK
images/inference-server.oci.tar: OK

$ sha256sum SHA256SUMS
4b7f...a921  SHA256SUMS

Der verkürzte Digest zeigt nur die Ausgabeform und ist kein zu kopierender Wert. Erfassen Sie in Produktion die vollständige Prüfsumme, prüfen Sie die Manifest-Signatur mit einem innerhalb der Grenze bereits vertrauenswürdigen öffentlichen Schlüssel und berechnen Sie nach dem Transfer jeden Datei-Digest neu. Eine Prüfsumme schützt die Integrität nur, wenn die erwartete Prüfsumme über einen vertrauenswürdigen, authentisierten Weg eintrifft. Eine schädliche Datei samt passender Prüfsumme auf demselben ungeprüften Laufwerk beweist nichts.

Bewahren Sie das ursprüngliche Paket nach der Freigabe auf. Wenn sich eine Ausgabe ändert, müssen Sie erkennen können, ob eine Gewichtsrevision, ein Tokenizer-Wechsel, ein neuer Laufzeit-Build, ein Treiberupdate, eine Sampling-Konfiguration oder Anwendungscode die Ursache war. Versionieren Sie die gesamte Inferenzeinheit und machen Sie Rollbacks zu einer gewöhnlichen Bereitstellungsfunktion. Bauen Sie während eines Vorfalls niemals ein altes Release aus beweglichen Abhängigkeiten neu.

Lizenzen können eine Bereitstellung blockieren, selbst wenn die Dateien technisch herunterladbar sind. Prüfen Sie Rechte zum Betrieb, Ändern, internen Verteilen, Erstellen abgeleiteter Werke und Verwenden der Ausgaben für den beabsichtigten Zweck. Erfassen Sie Nutzungsbedingungen, die die Arbeitslast betreffen. Ein Modell, das umgangssprachlich als Open Source beschrieben wird, kann eine Lizenz besitzen, die nicht der Open-Source-Definition Ihrer Organisation entspricht. Eine Sicherheitsfreigabe ersetzt daher keine Rechtsprüfung.

Der Update-Pfad gehört zum Produktionssystem

Eine Air-Gap-Umgebung braucht eine geplante Importstrecke, weil Modelle von einem veränderlichen Software-Stack abhängen. Treiber, Firmware, Laufzeiten, Basis-Images, Python- oder Systempakete, Modellgewichte, Tokenizer-Dateien, Schwachstellenhinweise und Sperrdaten altern. Sie dauerhaft einzufrieren spart Transferarbeit, sammelt aber Fehler an und erschwert den späteren Versionssprung.

Verwenden Sie zwei Staging-Zonen. Eine verbundene Beschaffungszone lädt festgelegte Artefakte herunter und erfasst ihre Herkunft. Eine Transferstation prüft, verifiziert, inventarisiert und paketiert das Release, ohne Produktionsgeheimnisse zu halten. Die Empfängerzone prüft das signierte Manifest erneut, importiert Artefakte in interne Repositories, führt Abnahmetests aus und gibt sie per unveränderlichem Digest frei. Produktion sollte nie direkt vom Transfergerät lesen.

Die Red-Hat-Dokumentation für getrennte OpenShift-Umgebungen behandelt Spiegelung und Offline-Updates als laufenden Betrieb, nicht als Installationskniff. Das ist auch außerhalb von OpenShift das richtige Modell. Spiegeln Sie die von der Bereitstellung verwendeten Repositories, bewahren Sie Release-Metadaten auf und üben Sie Upgrades sowie Rollbacks ohne öffentliche Infrastruktur. Wenn ein Paketmanager während eines Neubaus unbemerkt einen externen Index aufruft, ist das Paket unvollständig.

Legen Sie unterschiedliche Takte für normale und dringende Änderungen fest. Regelmäßige Releases können Modell-, Laufzeit- und Betriebssystemupdates nach der Evaluation bündeln. Eine aktiv ausgenutzte Schwachstelle in Treiber oder Bibliothek kann ein eng begrenztes Notfallpaket verlangen. Bestimmen Sie, wer diesen Weg ausrufen darf, welche Tests verkürzt werden dürfen, wie das Risiko akzeptiert wird und wann die vollständige Testsuite nachgeholt wird. Sonst wird jeder dringende Patch zur improvisierten Grundsatzdebatte.

Bei regulierten Legacy-Umschreibungen liefert CodeHero die Modelle und kann sie air-gapped innerhalb der Kundengrenze auf Kundenhardware oder von CodeHero an den Kunden vermieteter Hardware betreiben. Kunde und Umsetzungsteam müssen trotzdem Transferbefugnis, physischen Zugang, Protokolle, Exportprüfung und den abschließenden Umgang mit Gewichten und Hardware vereinbaren.

Planen Sie das Entfernen ebenso sorgfältig wie den Import. Abgelaufene Gewichte, defekte Laufwerke, Transfermedien, Protokollarchive und gemietete Hardware können geschützte Daten oder Modellartefakte enthalten. Legen Sie Nachweise für Löschung und Vernichtung vor der Außerbetriebnahme fest. Eine geschlossene Grenze mit undokumentiertem Ausgang verschiebt das Verwahrungsproblem nur.

Offline-Betrieb braucht eigene Abhängigkeiten

Der Cluster muss funktionieren, wenn jede öffentliche Hilfe fehlt. Dazu gehören Identität, Zeit, Namensauflösung, Zertifikate, Paket-Repositories, Überwachung, Alarmierung, Dokumentation, Backups und Supportwerkzeuge. Ein Modellserver, der läuft, während sich Benutzer nicht anmelden können, ist kein verfügbarer Dienst.

Identität ist oft die erste versteckte Abhängigkeit. Wenn die Organisation einen Cloud-Identitätsanbieter nutzt, entscheiden Sie, ob die geschlossene Zone ein eigenes Verzeichnis, eine kontrolliert replizierte Teilmenge oder lokal verwaltete Konten erhält. Planen Sie Erstellung, Sperrung und Prüfung von Konten. Eine Cache-Dauer ersetzt keine Identitätsarchitektur, besonders wenn ein ausgeschiedener Administrator bis zum Ablauf eines Offline-Tokens Zugriff behält.

Zeit und Zertifikate fallen stiller aus. Betreiben Sie eine interne verbindliche Zeitquelle und dokumentieren Sie deren Synchronisation und Driftprüfungen. Betreiben Sie eine interne Zertifizierungsstelle oder importieren Sie Zertifikate mit einem Erneuerungsprozess, der lange vor Ablauf beginnt. Testen Sie, wie Inferenz-Gateway, Registry, Überwachung und Automatisierung auf ein abgelaufenes Zertifikat reagieren. Notfallmäßige Uhränderungen können Protokolle und Signaturen ungültig machen und eignen sich nicht als normale Reparatur.

Beobachtungsdaten bleiben intern, sofern kein freigegebener Export etwas anderes bestimmt. Erfassen Sie Anfragekennungen, Latenz, Warteschlangentiefe, Tokenzahlen, Speicherdruck, Hardwarefehler, Modellversion, Richtlinienentscheidungen und Bedieneraktionen. Protokollieren Sie vollständige Prompts und Ausgaben nicht standardmäßig. Wenn Inhaltsmitschnitte für Fehlersuche oder Paritätstests nötig sind, beschränken Sie sie nach Rolle, Aufbewahrung und Fall, denn der Protokollspeicher kann zu einer konzentrierten Kopie der geschützten Arbeitslast werden.

Bauen Sie eine interne maßgebliche Quelle für Runbooks und bekannte Fehler auf. Der Herstellersupport kann Diagnosedaten verlangen, die nicht hinausdürfen. Vereinbaren Sie vorher, ob Supportpersonal die Grenze betreten darf, ob ein bereinigtes Paket sie verlassen kann und welche Befehle der Kunde ausführt. Üben Sie GPU-Ausfall, beschädigtes Modellpaket, Registry-Ausfall, Zertifikatsablauf und Rollback. Ein Isolationskonzept gewinnt im Wiederherstellungsfall Vertrauen, nicht in der Architekturpräsentation.

Backups brauchen unabhängige Wiederherstellungstests. Sichern Sie Konfiguration, Manifeste, Metadaten interner Repositories, Richtlinien und zustandsbehaftete Anwendungsdaten. Nehmen Sie nicht automatisch an, dass Gewichte im selben System gesichert werden müssen, wenn signierte Release-Pakete bereits eine wiederherstellbare Quelle bilden. Stellen Sie in einem sauberen Segment wieder her und beweisen Sie, dass kein externer Download nötig ist.

Geschlossene Modelle setzen eine harte Fähigkeitsgrenze

Sie können kein Modell selbst betreiben, dessen Anbieter weder Gewichte noch eine brauchbare Lizenz veröffentlicht. Das ist der deutlichste Nachteil gegenüber gehosteter Inferenz, und der Einkauf kann fehlende Artefakte nicht wegverhandeln. Ein kleineres verteilbares Modell kann für Klassifikation, Extraktion, Code-Transformation oder abrufgestützte Aufgaben genügen, entspricht aber nicht automatisch dem stärksten gehosteten Modell bei breitem Schlussfolgern oder seltenen Sprachen.

Gehostete Dienste bündeln außerdem Entwicklungsarbeit, die eine geschlossene Bereitstellung selbst leisten muss: optimierte Kernel, Anfrage-Batching, automatische Skalierung, Modell-Routing, Missbrauchskontrollen, Werkzeugausführung, multimodale Vorverarbeitung, strukturierte Ausgaben und häufige Modellupdates. Einige Funktionen lassen sich intern nachbauen. Andere hängen von proprietären Modellen oder Systemen des Anbieters ab und entfallen. Listen Sie jede benötigte Fähigkeit auf und testen Sie sie. Akzeptieren Sie nicht die pauschale Behauptung, ein lokales Modell sei „gleich“.

Die Kontextlänge auf einer Modellkarte beweist keine brauchbare Leistung über diese Länge. Lange Kontexte verbrauchen Cache-Speicher, senken die Parallelität und können schlechtere Ergebnisse liefern, obwohl die Anfrage hineinpasst. Testen Sie echte Dokumente und die tatsächliche Form des Codebestands. Bei einem Repository mit einer Million Zeilen lautet die praktische Frage nicht, ob ein Prompt alles aufnehmen kann. Das System braucht ein Verfahren, das den gesamten Baum analysiert, Beziehungen erhält und Änderungen gegen beobachtetes Verhalten prüft.

Updates treffen absichtlich langsamer ein. Ein gehosteter Endpunkt kann sich hinter einer stabilen API ändern, zum Guten oder Schlechten. Innerhalb der Grenze durchläuft jedes neue Gewicht oder jede Laufzeit Beschaffung, Prüfung, Transfer, Evaluation und Freigabe. Diese Verzögerung kauft Kontrolle und Reproduzierbarkeit, bedeutet aber, dass neue Funktionen und Sicherheitskorrekturen nicht sofort ankommen. Legen Sie fest, welche Verzögerung für normale Verbesserungen akzeptabel ist und welche Fehler den Notfallweg auslösen.

Externe Werkzeuge bilden eine weitere Trennlinie. Websuche, gehostete Code-Repositories, SaaS-Ticketsysteme, öffentliche Paketmetadaten und vom Anbieter verwaltete Suche sind nicht verfügbar, sofern sie nicht gespiegelt oder über ein genehmigtes Gateway angeboten werden. Ein Workflow mit Live-Werkzeugaufrufen verliert beim Umzug nach innen Fähigkeiten. Ersetzen Sie jede Abhängigkeit durch interne Daten und APIs oder erklären Sie offen, dass die Funktion entfällt.

Die Qualitätsprüfung muss auf die Aufgabe zugeschnitten sein. Halten Sie innerhalb der Grenze einen versionierten Satz repräsentativer Eingaben, erwarteter Invarianten, verbotener Offenlegungen, Latenzgrenzen und menschlicher Bewertungsregeln. Vergleichen Sie Kandidaten vor der Freigabe mit dem bisherigen Modell. Allgemeine öffentliche Benchmarks helfen bei der Vorauswahl, sagen aber nicht, ob eine Umschreibung das Verhalten des Monatsabschlusses erhält oder eine Extraktion die schwierigsten Formulare bewältigt.

Gehostete und isolierte Kosten verhalten sich verschieden

Gehostete Inferenz macht einen großen Teil der Plattform zu variablen Ausgaben, während eine isolierte Bereitstellung Kosten in reservierter Kapazität und Betrieb bündelt. Der Vergleich eines Tokenpreises mit einem GPU-Kaufpreis lässt bei beiden Systemen den Großteil aus. Modellieren Sie den Dienst, der dieselben Anforderungen an Verfügbarkeit, Latenz, Kontext, Sicherheit und Support erfüllt.

Für die geschlossene Seite zählen GPU-Knoten, CPU und RAM, schneller Speicher, internes Netzwerk, Rackfläche, Strom, Kühlung, Reservekapazität, Ersatzteile, sichere Transfergeräte, interne Registries, Überwachung, Backup und Arbeitszeit. Addieren Sie Beschaffungsvorlauf und die Kosten von Kapazität, die für Spitzen oder Ausfälle ungenutzt bereitsteht. Wenn getrennte Entwicklungs-, Test- und Produktionszonen nötig sind, zählen Sie jede. Für das Projekt gemietete Hardware bleibt dedizierte Kapazität und ist keine gehostete Tokenabrechnung.

Für die gehostete Seite zählen Ein- und Ausgabenutzung, Regeln für zwischengespeicherte Eingaben, reservierter Durchsatz, Datenaufbewahrung, private Verbindungen, Gateway- und Protokolldienste, Evaluationsverkehr, Wiederholungen und die Arbeit zur Verwaltung von Modelländerungen. Addieren Sie Bereinigung oder Datenminimierung, falls Rohmaterial nicht übertragen werden darf. Ein günstiger Endpunkt, den Recht oder Sicherheit nicht freigeben, hat keine brauchbare Wirtschaftlichkeit.

Ein einfacher Vergleich legt Annahmen offen:

closed_annual_cost = annualized_hardware + facilities + licenses + operations + transfer_and_assurance
hosted_annual_cost = request_volume * blended_request_cost + connectivity + operations + assurance
cost_per_success = total_cost / accepted_task_outputs

Die letzte Zeile ist am wichtigsten. Token pro Sekunde und Kosten pro Token können ein schnelles System belohnen, dessen Arbeit Menschen ablehnen. Definieren Sie ein akzeptiertes Ergebnis für die Aufgabe, etwa eine Transformation, die Paritätstests besteht, oder eine Extraktion über der Prüfschwelle. Messen Sie dann Wiederholungen und menschliche Korrektur. Verwenden Sie Bandbreiten für Auslastung, Anfragenwachstum, Hardwarelebensdauer und Personal statt einer scheinbar exakten Prognose.

Isolation ist oft wirtschaftlich, wenn die Arbeitslast gleichmäßig ist, die Hardware gut ausgelastet bleibt, das gewählte verteilbare Modell die Aufgabe erfüllt und die Datenvorgabe ohnehin lokalen Betrieb erfordert. Hosting ist oft besser bei schwankender Nachfrage, wenn die neueste proprietäre Fähigkeit das Ergebnis verändert, globale Kapazität zählt oder die Organisation keine Beschleuniger betreiben will. Hybride Konzepte können freigegebene, wenig sensible Arbeit nach außen leiten, brauchen aber zuverlässige Klassifikation und müssen bei unklarer Empfindlichkeit geschlossen bleiben.

Die Freigabe sollte auf Nachweisen beruhen, nicht auf dem Etikett

Geben Sie eine Air-Gap-Modellbereitstellung frei, wenn das Team die Grenze belegen, die Inferenzeinheit reproduzieren, jede Abhängigkeit offline betreiben, über einen getesteten Weg aktualisieren und zurückrollen sowie die Eignung des Modells für die echte Aufgabe zeigen kann. Lehnen Sie Vorschläge ab, die nur eine getrennte GPU und das Versprechen bieten, Updates später zu lösen. Das ist ein Experiment und kein Produktionskonzept.

Fordern Sie prüfbare Nachweise: Datenflussverzeichnis, Bedrohungsmodell, Hardwarebenchmark, Kapazitätsrechnung, signiertes Artefaktmanifest, Lizenznachweis, Evaluationsbericht, Wiederherstellungs-Runbook, Transferprotokoll, Schwachstellenprozess und Stilllegungsplan. Beobachten Sie danach einen Release-Import und ein Rollback. Kontrollen auf Papier scheitern häufig genau bei der Übergabe zwischen dem verbundenen Beschaffungsteam und den internen Betreibern.

Führen Sie vor dem Kauf eine Fehlerprüfung durch. Was passiert, wenn eine GPU ausfällt, ein Administrator den Zugriff verliert, die interne Registry beschädigt ist, ein Zertifikat abläuft, ein Modell stark zurückfällt oder eine schwere Laufzeitschwachstelle bekannt wird? Benennen Sie die vom Geschäft tolerierte Wiederherstellungszeit und die handlungsberechtigten Personen. Wenn die Antwort ein erneutes Verbinden des Clusters verlangt, planen und genehmigen Sie diese Ausnahme jetzt oder ändern Sie die Abhängigkeit.

Verlangen Sie Isolation nicht als Statussymbol. Wenn private gehostete Inferenz mit vertraglichen Kontrollen das Bedrohungsmodell erfüllt, kann sie bessere Modelle mit weniger Betriebsrisiko liefern. Wenn Quellcode, Datensätze oder Richtlinien die Grenze nicht überschreiten dürfen, akzeptieren Sie die Kosten für Funktionen und Personal, statt sie zu verschweigen. CodeHero schließt jede Legacy-Umschreibung in unter 30 Tagen ab, daher müssen Grenze, Hardware und Transfer früh genug für diesen Lieferzeitraum feststehen.

Der entscheidende Test ist praktisch: Trennen Sie jeden externen Pfad, importieren Sie ein signiertes Update, führen Sie die repräsentative Arbeitslast aus, exportieren Sie ein genehmigtes Ergebnis, rollen Sie zurück und erholen Sie sich von einem Knotenausfall. Wenn das Team diese Folge aus eigenen Repositories ausführen und eine vollständige Prüfspur hinterlassen kann, ist der Air Gap für Produktionsarbeit belastbar.