TUEO Handbuch für die private Bereitstellung (Xinchuang / inländische IT)

Bereitstellungshandbuch für Delivery-Ingenieure und Betriebsteams. Die private Bereitstellung von TUEO ist die Hauptlinie: pro Kunde eine unabhängige, einzelne Standortinstallation, isoliert; Xinchuang-first, Offline- / Air-Gap-Standard, Installation in einem Klick; Daten verlassen das Unternehmen nicht, durchgängig prüfbar und zurücksetzbar.

1. Xinchuang- und Lokalisierungsanpassung

TUEO ist vollständig an inländische Software- und Hardware-Umgebungen angepasst und unterstützt die Bereitstellung auf Xinchuang-Rechnern, inländischen CPU-Architekturen, inländischen GPU-Beschleunigungskarten und Xinchuang-Betriebssystemen. Damit erfüllt es die Compliance-Anforderungen an Sicherheit und Kontrollierbarkeit in Schlüsselbranchen wie Partei und Staat, Polizei, öffentliche Verwaltung, Energie und Finanzen:

• Inländische CPU-Architektur: unterstützt gängige inländische CPUs (x86- und ARM-Ökosystem) als Control-Plane- und Compute-Knoten;
• Inländische GPU-Beschleunigungskarten: unterstützt inländische GPUs für Modellinferenz und Vektorsuche-Beschleunigung, betreibbar in vollständig internen Netzen;
• Xinchuang-Betriebssysteme: angepasst an gängige inländische Linux-Distributionen, kompatibel mit deren Softwarequellen und Kernel-Basislinien;
• Xinchuang-Validierung: Bereitstellung bereits in Schlüsselbranchen wie Polizei und öffentliche Verwaltung validiert, erfüllt die Anforderungen von MLPS und Klassifizierungsschutz.

Die Plattform ist zudem kompatibel mit allgemeinen x86-Servern und Standard-Linux-Distributionen; die Lieferform ist zuschneidbar: vollständig inländischer Stack (Xinchuang-Rechner + inländische GPUs + Xinchuang-Betriebssystem) oder allgemeiner Stack — beide in einem Klick bereitstellbar.

2. Bereitstellungsformen und Architektur

2.1 Drei Lieferformen

2.2 Schichtenarchitektur

L3 Produkte und Middleware     identity · cohort · studio · capabilities · executor
                               + PG / Redis / MinIO / Wissensbasis / IM / Modell-Gateway
L2 Betriebsplattform           TUEO Console (Konfigurationszentrale · Protokolle · Statuswand · Deploy-Orchestrierung · Backup · Audit)
L1 Basis                       Harbor-Intranet-Image-Registry · Datenbank-Hochverfügbarkeit · Zertifikate · Gateway
L0 Cluster-Basis               k3s HA · Intranet-Cache-Ebene · Image-Proxy
Rechenebene                    Mehrfach-Modell-Rechner-Server — unabhängige Rechenknoten, einheitliche Bereitstellung und Verwaltung der Modelle
L-1 OS-Basislinie              Inländisches / allgemeines Betriebssystem · Kernel-Basislinie · Softwarequellen-Beschleunigung

Mehrfach-Modell-Rechner-Server ist ein unabhängiger Rechenknoten in der Bereitstellungsarchitektur, der speziell für die Bereitstellung von Modellen dient:

• Einheitlich trägt er mehrere Modelle: Inferenz großer Sprachmodelle, Vektor-Embeddings, visuelle / Sprachmodelle — bedarfsgerecht auf demselben Rechenknoten bereitstellbar und planbar;
• Inländische / allgemeine Beschleunigungskarten: unterstützt inländische GPUs und allgemeine Beschleunigungskarten; Modellinferenz und Vektorsuche finden vollständig im Intranet statt;
• Einheitlich von der Plattform verwaltet: Modell-Dienste werden über die Betriebsplattform registriert und bereitgestellt; Modellschlüssel verlassen den Server nicht; Aufrufe werden einheitlich über das Intranet-Modell-Gateway geroutet;
• Unabhängig erweiterbar: Rechenknoten lassen sich je nach Geschäftsgröße separat erweitern, ohne Control-Plane und Geschäftsknoten zu beeinträchtigen.

Wichtiger Punkt: Die Basis (Datenbank / Cache / Container-Basis / Objektspeicher / Modell-Rechenleistung) ist ebenfalls ein von der Betriebsplattform einheitlich verwaltetes Managed-Objekt — keine Drittanbieter-Infrastruktur, die der Kunde anderweitig warten lässt. Die Plattform ist sogar selbst ein Managed-Objekt (Selbst-Upgrade nur durch Image-Tausch, das Genesis-Manifest bleibt dauerhaft die einzige Wahrheit).

3. Bereitstellungsphasen (die Verzeichnisstruktur ist die Reihenfolge)

Die Bereitstellung erfolgt mit wiederholbaren Skripten + Standort-Manifest, von der Bare-Metal-Maschine zur Produktionsumgebung, ohne manuelles Tippen von SSH:

Nach der Bereitstellung dient das Skript von 00 Pre-Check zugleich als Abnahme-Health-Check und kann jederzeit erneut ausgeführt werden.

4. Standort-Manifest (deklarative Konfiguration)

Jeder Kundenstandort erhält ein site/<name>.yaml; Skripte lesen die Parameter, null Hardcoding:

• Standort: Name, Domain-Suffix, Zeitzone;
• Netzwerk: Pod-/Service-Netzsegmente, Knoten-Subnetz, Gateway, DNS, öffentlicher Einstieg, Out-of-Band-Management-Netz;
• Quellen: Offline-Bundle-Pfad oder Image-URL (Air-Gap-Standorte über Offline-Bundle);
• Zugang: Spring-Box (Jump Host), SSH-Credential-Referenzen (Klartext kommt nicht in die Datenbank);
• Knoten: Hostname, Intranet-IP, Rolle (Control-Plane / Compute / Mehrfach-Modell-Rechenleistung), Hardwarespezifikationen und harte Beschränkungen;
• Rechenleistung: Typ und Anzahl der Beschleunigungskarten (inländisch / allgemein), Modell-Liste und Ressourcenreservierung.

5. Offline- und Air-Gap-Bereitstellung

Air-Gap (vollständig ohne Netzwerk) ist Standardfähigkeit, kein Ausstattungsmerkmal:

• Offline-Image-Lieferung: Images in einer netzwerkfähigen Umgebung bauen und packen → intranetseitig in die Intranet-Image-Registry laden → Cluster pullt, Knoten ohne docker;
• Offline-Bundle: Container-Basis, Images und Systempakete zu einem Offline-Bundle packen, in einem Durchgang in den Air-Gap-Standort bringen;
• Intranet-Cache: Image-Proxy + Softwarequellen-Cache, jede Abhängigkeit bei langsamem öffentlichem Netz (z. B. nur 0,5 MB/s) nur einmal über die langsame Leitung;
• Offline-Updates: signierte .tueoupdate-Update-Pakete werden nach Signaturprüfung importiert; der Verzeichnis-Abschnitt geht an die Fähigkeitsplattform, der Image-Abschnitt in die Intranet-Registry; unsignierte Pakete werden abgelehnt;
• Offline-Autorisierung: signierte Lizenzen aktivieren ohne Netzwerk; die Software-Knotensperre verhindert das Kopieren auf mehrere Installationen.

6. Betriebshandbuch

Nach der Bereitstellung erfolgt der gesamte Betrieb über eine Oberfläche: TUEO Console:

Plattform-Selbst-Upgrade: Push von Code löst automatischen Build aus → Image-Promotion → Image-Tausch → Health-Check-Konvergenz; das Upgrade ändert nur Image-Tags und rendert das Genesis-Manifest nicht neu (Datenvolumes / Master-Schlüssel / Gateway bleiben vollständig erhalten).

7. Sicherheit und Compliance

• Daten verlassen das Unternehmen nicht: alle Komponenten im Intranet bereitgestellt; Modelle können über das eigene Gateway des Kunden oder lokale Modelle laufen, Schlüssel verlassen das Kundennetz nicht;
• Physische Multi-Mandanten-Isolation: Datenbank-Row-Level-Security + explizite Mandantenfilterung auf Dienstebene als Doppelverteidigung;
• Audit-Protokollierung: kryptografische Audit-Hashkette, Manipulation erkennbar; sensible Aktionen mit doppelter Bestätigung + Genehmigungsfluss;
• Tiefenverteidigung: OIDC-Single-Sign-on, Rollen-Konvergenz, verschlüsselte Zugangsdaten-Tresore, netzwerkgetrennte Sandbox, Content-Safety-Gate;
• Xinchuang-Compliance: vollständig private Bereitstellung, erfüllt MLPS, Klassifizierungsschutz und die Compliance-Anforderungen von Schlüsselbranchen.

8. Lieferumfang

Bei Fragen zur Bereitstellung oder bei Bedarf an gemeinsamer Abstimmung für die Xinchuang-Umgebung wenden Sie sich an das TUEO-Delivery-Team.