Selbst gehostete KI-Entwicklungsplattform: eine Bereitstellungs-Checkliste

Kurze Antwort: Self-Hosting erhöht die Kontrolle über die Infrastruktur, ist aber nur dann privat und zuverlässig, wenn Modellwege, Repository-Zugriff, Workload-Isolation, Secrets, Logs, Backups, Upgrades und die Betriebsverantwortung ausdrücklich gestaltet werden.

Das Self-Hosting einer KI-Entwicklungsplattform gibt einer Organisation mehr Kontrolle über Code, Projektdaten, Modellzugriff und Ausführungsinfrastruktur. Es verlagert außerdem wichtige Betriebsverantwortlichkeiten auf die Organisation.

Die richtige Frage ist nicht nur „Können wir es bereitstellen?“ Die richtige Frage ist „Können wir es für ein Engineering-Team zuverlässig, sicher und nützlich betreiben?“

Nutzen Sie diese Checkliste, um ein Pilotprojekt vor dem breiteren Rollout vorzubereiten.

1. Definieren Sie den Grund für Self-Hosting

Beginnen Sie mit der Rahmenbedingung, die Sie lösen. Häufige Gründe sind:

• Quellcode muss in einem privaten Netzwerk bleiben;
• Entwicklungsaufgaben benötigen Zugriff auf interne Dienste;
• die Organisation möchte Modellanbieter zentral verwalten;
• Datenresidenz oder interne Richtlinien schränken gehostete Dienste ein;
• Teams benötigen eigene Images, Rechenleistung oder Netzwerktopologie;
• die Organisation wünscht betriebliche Unabhängigkeit von einer einzelnen gehosteten Oberfläche.

Schreiben Sie den Grund auf. Er treibt Architekturentscheidungen und verhindert, dass ein Self-Hosting-Projekt zu einer endlosen Infrastrukturübung wird.

2. Trennen Sie Steuerungsebene und Aufgabenumgebungen

Eine KI-Entwicklungsplattform hat typischerweise zwei verschiedene Infrastrukturrollen.

Die Steuerungsebene verwaltet Nutzer, Projekte, Anforderungen, Aufgaben, Modellkonfiguration und Verwaltungszustand. Die Entwicklungsumgebungs-Hosts führen Code aus, installieren Abhängigkeiten, bauen Projekte, führen Tests aus und stellen Vorschauen bereit.

Diese Rollen zu trennen hilft bei Isolation und Kapazitätsplanung. Ein Build-Ansturm sollte die Verwaltungskonsole nicht unerreichbar machen.

Die aktuelle öffentliche Bereitstellungsanleitung von MonkeyCode empfiehlt:

Komponente	Minimale Startkonfiguration
MonkeyCode-Konsole	2 CPU-Kerne, 4 GB Speicher, 40 GB Speicherplatz
Entwicklungsumgebungs-Host	8 CPU-Kerne, 16 GB Speicher, 100 GB Speicherplatz

Dies sind Ausgangspunkte, keine Kapazitätsgarantien. Die tatsächliche Kapazität hängt von Aufgaben-Nebenläufigkeit, Repository-Größe, Build-Last, Basis-Images und Aufbewahrungsrichtlinie ab.

3. Planen Sie Isolation vor Nebenläufigkeit

Jede Aufgabe kann nicht vertrauenswürdigen Projektcode und modellgenerierte Befehle ausführen. Behandeln Sie Entwicklungsumgebungen als Grenzen der Workload-Isolation.

Bestätigen Sie:

• wie Aufgaben-Dateisysteme getrennt sind;
• welche Netzwerkziele erreichbar sind;
• wie CPU, Speicher, Speicherplatz und Ausführungszeit begrenzt werden;
• wie Zugangsdaten eine Umgebung betreten und verlassen;
• ob privilegierte Container oder Host-Mounts nötig sind;
• wann Umgebungen und Artefakte gelöscht werden;
• wie eine Entwicklerin eine laufende Aufgabe prüfen kann, ohne Kontrollen zu umgehen.

Beginnen Sie mit niedriger Nebenläufigkeit. Erhöhen Sie sie erst, nachdem Sie das reale Verhalten von CPU, Speicher, Festplatte und Netzwerk beobachtet haben.

4. Inventarisieren Sie Versionskontrolle und Zugangsdaten

Listen Sie die im Pilotprojekt enthaltenen Repositories auf und verwenden Sie eng gefasste Zugangsdaten. Beginnen Sie nicht mit organisationsweiten Tokens.

Dokumentieren Sie für jede Versionskontroll-Integration:

• Lese- und Schreibrechte für Repositories;
• Rechte zum Erstellen von Branches;
• Rechte für Pull- oder Merge-Requests;
• Webhook-Endpunkte und Secrets;
• Token-Besitzer und Rotationsprozess;
• Verfügbarkeit von Audit-Logs;
• Verhalten beim Ablauf von Zugangsdaten.

Ein KI-Agent sollte nur den Zugriff erhalten, den die gewählte Aufgabe erfordert. Der administrative Komfort der Plattform sollte den Umfang eines Tokens nicht erweitern.

5. Entscheiden Sie, wie Modelle erreicht werden

Das Self-Hosting der Plattform bedeutet nicht automatisch, dass jedes Modell lokal läuft. Eine Bereitstellung kann externe Modell-APIs, private Modell-Gateways oder im selben Netzwerk betriebene Modelle aufrufen.

Bewerten Sie jeden Weg anhand von:

• an den Anbieter gesendeten Code- und Prompt-Daten;
• Aufbewahrungs- und Trainingsrichtlinien des Anbieters;
• regionaler Verfügbarkeit und Latenz;
• Authentifizierung und Kontingentverwaltung;
• Modellqualität für Ihre repräsentativen Aufgaben;
• Fallback-Verhalten bei Anbieterausfällen;
• Kostentransparenz nach Team oder Projekt.

MonkeyCode unterstützt mehrere Modellfamilien, darunter GLM, Kimi, MiniMax, Qwen und DeepSeek. Ein Pilotprojekt sollte mindestens zwei Aufgabentypen testen, statt ein Modell allein anhand eines allgemeinen Benchmarks auszuwählen.

6. Bauen Sie ein freigegebenes Umgebungs-Image

Die Aufgabenumgebung sollte die für ein Projekt nötigen Werkzeuge enthalten, ohne zu einer unkontrollierten Sammlung von Zugangsdaten und Paketen zu werden.

Dokumentieren Sie:

• Basis-Betriebssystem und Update-Zeitplan;
• Sprachlaufzeiten und Paketmanager;
• Build-Werkzeuge, Browser und Systembibliotheken;
• interne Zertifizierungsstellen und Paket-Mirror;
• Schwachstellen-Scan und Image-Signierung;
• wer ein Image veröffentlichen oder auswählen darf;
• wie alte Umgebungen Sicherheitsupdates erhalten.

Verwenden Sie im Pilotprojekt wenige freigegebene Images. Zu viel Flexibilität erschwert die Reproduktion von Fehlern.

7. Behandeln Sie Beobachtbarkeit als Produktanforderung

Betreiber brauchen Infrastrukturmetriken, Entwickler brauchen Belege auf Aufgabenebene.

Erfassen Sie mindestens:

• Zustand und Fehlerrate der Steuerungsebene;
• Zeit und Fehlerrate bei der Umgebungserstellung;
• CPU-, Speicher-, Festplatten- und Netzwerknutzung pro Host;
• Dauer und Status von Aufgaben;
• Fehler und Drosselung bei Modellanfragen;
• Build- und Testergebnisse;
• Aufbewahrungs- und Bereinigungsereignisse.

Entscheiden Sie, welche Logs Quellcode, Prompts, Modellantworten oder Zugangsdaten enthalten können, und wenden Sie Zugriffs- und Aufbewahrungskontrollen entsprechend an.

8. Bereiten Sie Backup- und Upgrade-Verfahren vor

Ermitteln Sie, welcher Zustand dauerhaft ist und welche Umgebungen neu erstellt werden können. Sichern Sie den dauerhaften Zustand, testen Sie eine Wiederherstellung und dokumentieren Sie die Verantwortung.

Vor einem Upgrade:

1. die aktuellen Release Notes des Projekts lesen;
2. persistente Daten sichern;
3. die neue Version in einer Staging-Umgebung testen;
4. repräsentative Aufgaben und Integrationen ausführen;
5. Auslöser und Verfahren für ein Rollback definieren;
6. für Nutzer sichtbare Änderungen kommunizieren.

Open Source gibt Teams die Möglichkeit, das System zu prüfen und anzupassen, nimmt ihnen aber den routinemäßigen Plattformbetrieb nicht ab.

9. Entwerfen Sie ein kleines, messbares Pilotprojekt

Wählen Sie eine Handvoll Entwickler, eine begrenzte Menge Repositories und drei bis fünf repräsentative Aufgabentypen. Definieren Sie Erfolg, bevor die erste Aufgabe läuft.

Nützliche Kennzahlen sind:

• Erfolgsquote und Zeit beim Umgebungsstart;
• Anteil der Aufgaben, die zu einer überprüfbaren Änderung führen;
• Bestehensquote von Build und Tests;
• menschliche Review-Zeit;
• Modell- und Infrastrukturkosten pro abgeschlossener Aufgabe;
• Anzahl und Schwere von Zugriffs- oder Zuverlässigkeitsvorfällen;
• Zuversicht der Entwickler, Agent-Arbeit zu verstehen und zu korrigieren.

Das Pilotprojekt sollte zeigen, ob der Workflow passt – nicht nur, ob die Software installierbar ist.

10. Prüfen Sie Lizenz und Organisationsrichtlinien

MonkeyCode wird unter der GNU Affero General Public License v3.0 veröffentlicht. Prüfen Sie die Lizenz, geplante Änderungen und die Netzwerknutzung mit Ihrem Rechtsteam. Richten Sie die Bereitstellung außerdem an bestehenden Richtlinien für Quellcode, Secrets, Drittanbietermodelle, Software-Lieferkette, Logging und Incident Response aus.

Prüfen Sie den Bereitstellungsweg in den offiziellen Quellen

Installationsbefehle, Konfiguration und Integrationen sind zeitkritisch. Lesen Sie vor der Installation die aktuelle MonkeyCode-Bereitstellungsdokumentation und prüfen Sie das Open-Source-Repository.

Wenn die Dokumentation einen Remote-Installer bereitstellt, prüfen Sie dessen Inhalt und testen Sie ihn in einer Nicht-Produktionsumgebung, bevor Sie ihn mit erhöhten Rechten ausführen. Erfassen Sie die genaue Version, Konfiguration, den Modellweg und das Rollback-Verfahren des Pilotprojekts.

#Self-Hosting-KI#KI-Entwicklungsplattform