Schritt 4: Bestellen, aufbauen, live gehen¶

Ab hier wird nicht mehr nur gebaut, sondern kontrolliert. Ziel ist nicht, den Server irgendwie online zu bringen, sondern frueh zu erkennen, ob Phase A auf go, pause/remediate, de-risk oder exit laeuft. Siehe auch 05-risiken-red-team-exit.md.

Ziel von G3 und G4¶

G3: Hardware, Colo und Host-Setup sind technisch und operativ rack-ready und verifizierbar
G4: Der echte Betrieb bestaetigt die These ueber Tag 30 / 60 / 90 oder liefert frueh ein klares Gegenargument

4a) Vertraege unterschreiben¶

[ ] G2 ist dokumentiert und auf go
[ ] Hardware bestellen / Mietkauf unterschreiben
[ ] Colo-Vertrag unterschreiben
[ ] Elektronikversicherung + Betriebshaftpflicht binden — vor Inbetriebnahme
[ ] Exit-Basis dokumentieren: Kuendigungsfrist Colo, Restschuld-Logik, Wiederverkaufspfad, Ansprechpartner

Vor Unterschrift nicht vergessen:

[ ] Gewaehlte SKU ist final (A100 80GB oder A100 40GB)
[ ] Finale Monatsrate, Anzahlung und Haftungsprofil stimmen mit G2 ueberein
[ ] Keine wesentliche offene Validierung bleibt unadressiert

4b) Lieferung bis rack-ready¶

[ ] Server empfangen / zusammenbauen (oder Komplettserver von Anbieter)
[ ] Burn-in: Stresstest, nvidia-smi -q, ECC/Xid pruefen, mind. 48h
[ ] An Colo liefern, einbauen, Netzwerk + IPMI/iDRAC einrichten
[ ] Vast-relevante Randbedingungen im Rack bestaetigen: Port-Range, statische IP, Bandbreite, Remote-Reboot

G3 — Rack-ready nur wenn¶

[ ] Keine wiederkehrenden ECC-, Xid-, Thermal- oder Power-Probleme
[ ] Remote-Zugriff, Reboot und Out-of-Band-Management funktionieren
[ ] Port-Range, statische IPv4 und symmetrische Bandbreite sind real, nicht nur vertraglich versprochen
[ ] Der Host ist fuer Verifikation vorbereitet und kein Infrastrukturblocker mehr offen

4c) Vast.ai Host Setup¶

[ ] Ubuntu 22.04 LTS, NVIDIA Driver, Docker, NVIDIA Container Toolkit
[ ] Vast Host Software installieren, Verification starten
[ ] Listing erstellen, Startpreis setzen
[ ] Soft Launch: Preis etwas unter Markt fuer initiale Bewertungen, aber nicht unter die in Schritt 3 definierte Unterkante
[ ] Monitoring aktiv: Auslastung, effektive Host-Rate, Incident-Backlog, Auszahlungen, Reliability

Pricing-Regel fuer den Start¶

Nicht nur "Preis setzen", sondern nach einer einfachen Regel steuern:

[ ] Peer-Band fuer die exakte SKU beobachten
[ ] Startpreis bewusst wettbewerbsfaehig setzen, um erste Buchungen und Signale zu bekommen
[ ] Preis nie unter eine Untergrenze senken, die Break-even, Stressfall oder Stop-Loss aus 03-go-no-go.md verletzt
[ ] Preis nicht isoliert betrachten: Verification, Reliability, Template-Qualitaet und Reaktionsgeschwindigkeit laufen mit

KPI-Dashboard ab Tag 1¶

Diese Kennzahlen sollten fortlaufend sichtbar sein:

[ ] Rolling 60d Auslastung
[ ] Realisierte Netto-EUR/GPU-h nach Payout und FX
[ ] 2-Monats-Rolling-Netto
[ ] Reliability / Uptime / Incident-Backlog
[ ] Remote-Hands- und Zusatzkosten
[ ] Auszahlungen und Zahlungsdelay
[ ] Offene technische Root Causes

4d) Zwischengates bis Verified-Status¶

Schritt	Go	Pause / Remediate	Exit / Stopp
Hardware / Burn-in	Keine kritischen Fehler, stabile GPUs	Einzelne Probleme behebbar	Wiederkehrende ECC/Xid-/Thermal-Probleme ohne klare Loesung
Colo-Setup	Netzwerk, Ports, IP, Remote-Zugang wie vereinbart	Teilweise Nacharbeit noetig	Vertrag liefert Kernanforderungen faktisch nicht
Verification / Listing	Verified oder klarer Pfad dorthin	Template/Pricing/Config nachbessern	Kein belastbarer Platform-Fit

4e) Messen und steuern (30 / 60 / 90 Tage)¶

Tag	Pruefe	Go	Pause / Remediate	Exit / De-Risk
30	Listing aktiv, erste Buchungen, Burn-in-Folgen	Verified-Status oder klar isolierter letzter Blocker mit Owner und Termin	Buchungen da, aber Pricing / Template / Reliability noch instabil	Kein Listing-Fit oder fundamentale Setup-Probleme
60	Rolling Auslastung, Net EUR/GPU-h, Auszahlungen	Richtung 70-80% Erfolgskorridor; 2-Monats-Netto > -400 EUR/Mo	Nachfrage vorhanden, aber Root Cause klar und operativ behebbar	Nachfragebild schwach, Payout/FX/Incident-Mix macht Oekonomie fragil
90	Wirtschaftlichkeit gegenueber Schritt 3	Rolling 60d-Auslastung im oder klar am Rand des 70-80%-Korridors; Reserve stabil; kein chronischer Incident-Backlog	45-70% Auslastung oder Oekonomie zu duenn, aber Root Cause isoliert und remediierbar	<45% Auslastung ueber den Ramp-up-Zeitraum oder 2-Monats-Netto unter Stop-Loss ohne glaubhafte Remediation

4f) Eskalationslogik nach Go-live¶

Go: 90-Tage-Gate bestanden, Reserve stabil, kein chronischer Incident-Backlog.
Pause / Remediate: Kein Wachstum; Preis, Listing, Templates, Verifikation oder Betrieb nachziehen.
De-Risk: Kein weiterer Server, Kosten senken, Vertragsseite verbessern, ggf. Multi-Platform pruefen.
Exit: Listing stoppen, colo-seitigen Footprint geordnet abbauen, Hardware verwerten, Restschuld gegen Erlos rechnen.

Stop-Loss: 2-Monats-Netto unter -400 EUR/mo → keine Expansion. Erst Remediation; wenn danach keine belastbare Verbesserung sichtbar ist, De-Risk oder Exit.

Offene Validierungen nach Launch¶

Auch nach Go-live gibt es offene Punkte, die aktiv gefuehrt werden muessen:

[ ] Bleibt die reale Host-Rate nahe genug an der in Schritt 3 unterstellten Groessenordnung?
[ ] Ist die Nachfrage schwach wegen Preis, Listing-Qualitaet, Verifikation oder echter Marktknappheit?
[ ] Sind Remote-Hands, RMA und Incident-Prozess im echten Betrieb noch tragfaehig?
[ ] Gibt es einen Plattform- oder Multi-Platform-Bedarf, bevor ueber de-risk oder exit entschieden wird?

4g) Exit-Ablauf¶

Listing deaktivieren oder auf minimale Restnutzung zurueckfahren.
Offene Kundenjobs sauber auslaufen lassen.
Colo-Kuendigung und Ausbau-Termin planen.
Restschuld, Rueckkaufoptionen und Sekundaermarktpreis gegenrechnen.
Hardware verkaufen oder in kleinerem Footprint weiterbetreiben.

Phase B (naechster Server): Erst wenn das 90-Tage-Gate bestanden ist und die Kriterien aus 03-go-no-go.md auf Flottenebene ebenfalls positiv bleiben. Siehe BUSINESS-PLAN.md §10.