- CommaAI führt das gesamte Modelltraining und die gesamte Datenverarbeitung im eigenen Datacenter durch und betreibt dafür direkt eine Infrastruktur im Wert von rund 5 Millionen US-Dollar
- Die Abhängigkeit von der Cloud kann zu steigenden Kosten und Kontrollverlust führen, während der Betrieb eigener Compute-Ressourcen bessere Engineering-Qualität und Kostensenkungen ermöglicht
- Das Datacenter besteht aus rund 450 kW Stromleistung, 600 GPUs, 4 PB SSD-Storage sowie einer einfachen Kühl- und Netzwerkstruktur
- Der Software-Stack ist mit Ubuntu + Salt, minikeyvalue (mkv)-Storage, dem Slurm-Scheduler, verteiltem PyTorch-Training und miniray für verteiltes Computing aufgebaut
- comma.ai automatisiert mit dieser Struktur das Training von Modellen für autonomes Fahren vollständig und erzielt gegenüber der Cloud etwa eine 5-fache Kostenersparnis
Warum ein eigenes Datacenter betreiben
- Die Abhängigkeit von der Cloud führt zu steigenden Kosten und Vendor Lock-in
- Cloud-Unternehmen machen das Onboarding einfach, das Offboarding jedoch schwierig
- Bei dauerhafter Nutzung gerät man leicht in eine dauerhaft teure Kostenstruktur
- Der Betrieb eigener Compute-Ressourcen fördert technologische Unabhängigkeit und eine effiziente Engineering-Kultur
- In der Cloud liegt der Schwerpunkt auf der Verwaltung von APIs und Abrechnungssystemen, während ein Datacenter die Lösung realer technischer Probleme rund um Strom, Rechenleistung und Bandbreite verlangt
- Auch aus Sicht des ML-Engineerings führen Ressourcenbeschränkungen zu Code-Optimierung und grundlegenden Verbesserungen
- In der Cloud löst man Probleme oft einfach durch ein höheres Budget, in einer eigenen Infrastruktur sind Performance-Verbesserungen zwingend erforderlich
- comma.ai hat kostenmäßig rund 5 Millionen US-Dollar investiert; für dieselbe Arbeit in der Cloud wären nach eigener Berechnung mehr als 25 Millionen US-Dollar nötig gewesen
Komponenten des Datacenters
-
Stromversorgung
- Maximalverbrauch 450 kW, Stromkosten 2025 von 540.112 US-Dollar
- Der Strompreis in San Diego liegt bei 40 Cent/kWh und damit etwa beim Dreifachen des Weltdurchschnitts
- Ein künftiger eigener Stromerzeugungsplan wird erwähnt
-
Kühlung
- Es wird Außenluftkühlung verwendet, die energieeffizienter ist als ein CRAC-System
- Luftzirkulation über jeweils zwei 48-Zoll-Zuluft- und Abluftventilatoren
- PID-Regelkreis zur automatischen Steuerung von Temperatur und Luftfeuchtigkeit (unter 45 %)
- Der Stromverbrauch liegt im Bereich von mehreren zehn kW
-
Server und Storage
- Besteht aus 75 TinyBox Pro-Systemen (insgesamt 600 GPUs), in Eigenbau gefertigt
- Jedes System hat 2 CPUs + 8 GPUs und wird für Training sowie allgemeine Rechenaufgaben genutzt
- Der Eigenbau erleichtert die Wartung
- Das Storage basiert auf Dell R630/R730 und umfasst insgesamt 4 PB SSD
- Nicht-redundante Architektur mit 20 Gbit/s Lesegeschwindigkeit pro Node
- Das Netzwerk besteht aus drei 100-Gbit/s-Z9264F-Switches und zwei Infiniband-Switches
Software-Infrastruktur
-
Basiskonfiguration
- Alle Server verwenden Ubuntu + PXE-Boot und werden mit Salt verwaltet
- Eine Single-Master-Architektur hält 99 % Verfügbarkeit
-
Verteiltes Storage — minikeyvalue (mkv)
- Fahrdaten für das Training werden auf 3 PB nicht-redundantem Storage gespeichert
- 1 TB/s Lesedurchsatz, direktes Training ohne Caching möglich
- Ein 300-TB-Cache-Array sowie ein redundantes Storage-Array speichern Modelle und Metriken
- Jedes Array wird von einem einzelnen Master-Server verwaltet
-
Job-Management — Slurm
- Plant PyTorch-Trainingsjobs und verteilte miniray-Jobs
-
Verteiltes Training — PyTorch + FSDP
- Betrieb von zwei Trainingspartitionen, die über ein Infiniband-Netzwerk verbunden sind
- Ein eigenes Trainings-Framework automatisiert die Trainingsschleife
- Bereitstellung eines Services zur Nachverfolgung von Modellexperimenten
-
Verteiltes Computing — miniray
- Leichtgewichtiger Open-Source-Task-Scheduler, der Python-Code auf ungenutzten Maschinen ausführt
- Einfacher als Dask, Verwaltung der Tasks über einen zentralen Redis-Server
- GPU-Worker führen Modellinferenz mit dem Triton Inference Server aus
- Skalierung auf Hunderte von Maschinen parallel möglich
- Beispiel: Ein Controls-Challenge-Rekord wurde mit einer Stunde Datacenter-Nutzung erreicht
-
Code-Management — NFS-basiertes Monorepo
- Die gesamte Codebasis ist unter 3 GB groß und wird auf alle Workstations repliziert
- Beim Start eines Jobs werden lokaler Code und Pakete synchronisiert, in unter 2 Sekunden abgeschlossen
- Gewährleistet, dass alle verteilten Jobs in derselben Codebasis und Umgebung laufen
Integrierte Trainingspipeline
- Die komplexeste Aufgabe bei comma ist das Training eines Fahrmodells im On-Policy-Verfahren
- Dafür müssen Simulationsfahrten mit den neuesten Modellgewichten ausgeführt werden, um Trainingsdaten zu erzeugen
- Die gesamte Pipeline lässt sich mit einem einzelnen Befehl ausführen
./training/train.sh N=4 partition=tbox2 trainer=mlsimdriving dataset=/home/batman/xx/datasets/lists/train_500k_20250717.txt vision_model=8d4e28c7-7078-4caf-ac7d-d0e41255c3d4/500 data.shuffle_size=125k optim.scheduler=COSINE bs=4
- Für die Ausführung dieses Trainings wird die gesamte oben beschriebene Infrastruktur genutzt
- Es ist nur ein einfacher Befehl, koordiniert aber viele verschiedene Komponenten
Fazit
- comma.ai erreicht durch den Betrieb eines eigenen Datacenters Kostensenkung und technologische Unabhängigkeit
- Derselbe Ansatz könnte auch für Unternehmen oder Einzelpersonen beim Aufbau eigener Infrastruktur realistisch sein
3 Kommentare
Speicher ist teuer!
هههههههههههههههههههه
Hacker-News-Kommentare
In unserer Branche liegen Eigentum vs. Cloud an den beiden Enden eines Spektrums
① Die Cloud erfordert wenig Anfangsinvestition (CapEx) und wenig Personal, aber die Betriebskosten (OpEx) sind hoch und volatil
② Managed Private Cloud ist das, was wir machen: auf Open Source basierend verwaltet und etwa 50 % günstiger als AWS
③ Gemietetes Bare Metal ist ein Modell, das die Hardware-Finanzierung ersetzt, und 90 % günstiger als AWS
④ Selbst kaufen und dann Colocation nutzen ist am günstigsten, wenn man die technische Kompetenz und die nötige Größenordnung hat
Anbieter wie Hetzner kalkulieren mit einem ROI über 3 Jahre, und Option 3–4 eignet sich für Unternehmen mit großem Maßstab oder für die Infrastruktur ein Kerngeschäft ist
Für Startups ist Option 1, für KMU Option 2 realistisch (lithus.eu)
Das Problem ist, dass die Kostenstruktur der Cloud nicht einfach nur vom Hardwarepreis kommt, sondern dadurch, dass man zu komplexen Architekturen verleitet wird und die Ineffizienz steigt
Die „managed Services“ von AWS sind so aufgebaut, dass der Gewinn von AWS sinkt, je effizienter Nutzer ihre Server auslasten
Wenn man einfach vier Java-Server auf EC2 plus eine replizierte DB betreibt, ist das deutlich effizienter
Die absurd hohen AWS-Rechnungen entstehen letztlich dann, wenn man unzählige Services missbraucht
(derek@ von Carolina Cloud) Auch wir bevorzugen Modell (4), aber Nutzer mit zu wenig technischer Kompetenz bleiben bei 1–3 und sitzen damit in der hochpreisigen Struktur der Public Cloud fest
Es heißt zwar „nutzungsbasiert“, tatsächlich kommen aber Grundgebühren und Mindestabnahmen dazu, wodurch es viel teurer wird (carolinacloud.io)
Hetzner ist eine attraktive Option
Es ist zwar lästig, Services wie Postgres oder VPN selbst zu verwalten, aber ab 10.000–15.000 Dollar im Monat ist es vorteilhafter als AWS
Es gibt Risiken, aber es ist es wert
Ich miete einen Bare-Metal-Server für 500 Dollar im Monat, und der Verwaltungsaufwand beträgt nur ein paar Stunden pro Jahr
Vielleicht liegt es an meinen einfachen Anforderungen, aber es fühlt sich deutlich besser an als eine übermäßig komplexe Cloud
Ich bin vor zwei Jahren auf Colocation umgestiegen und habe jetzt mehr Kapazität zu 30 % der Kosten
Dazu kommt, dass man von den nachgelagerten Preisrückgängen bei RAM und Storage profitiert
Allerdings muss man sich um Compliance-Management etwas mehr kümmern
Früher nannte man so etwas einfach Rechenzentrum
Das Konzept gab es schon vor der Cloud, und letztlich ist es nur eine Wiederholung von Besitz vs. Miete und Zentralisierung vs. Dezentralisierung
Wenn Unternehmen sich extrem nur für eine Seite entscheiden, stoßen sie am Ende wieder auf dieselben Probleme
Interessant ist, dass die Cloud für Finanzabteilungen vor allem wegen der Steuervorteile attraktiv war
Aber da mit dem jüngsten Gesetz (OBB) CapEx als Aufwand verbucht werden kann, kommt On-Prem wieder in Fahrt
Warum gibt es dann keine preislich konkurrenzfähige Cloud-Alternative?
AWS und Azure beherrschen den Markt und haben keinen Anreiz, die Preise zu senken, und bei Google ist das Risiko einer Einstellung von Services hoch
Vor der Cloud war das interne Infrastrukturteam der Engpass
Die Cloud hat das standardisiert und mit einem einheitlichen Abrechnungssystem vereinfacht
Außerdem war die Serverbeschaffung außerhalb der USA langsam, sodass der Geschwindigkeitsvorteil der Cloud groß war
On-Prem-Rechenzentren bedeuten eine hohe operative Last und binden viele Engineering-Ressourcen
Deshalb kommt diese Debatte immer wieder auf
Die eigentliche Innovation der Cloud war, „Kosten pro Service klar auszuweisen“
Statt wie früher zu fragen „Wen muss ich dafür bitten?“ war der Zugriff plötzlich per API möglich
Der Kontext dazu ist in diesem Beitrag gut zusammengefasst
Selbst in Regionen wie San Diego, wo Temperaturregelung einfach ist, ist Kühlung mit Außenluft riskant
Feuchtigkeit und Schadstoffe beschädigen Server schnell
Stattdessen sind Verfahren wie Enthalpierad-Kühler (kyotocooling) effizient und verbrauchen im Verhältnis zur Kühlleistung wenig Strom
Bei Außenluftkühlung ist das Risiko einer verkürzten Gerätelebensdauer hoch, daher ist Vorsicht geboten
Es gibt auch Beispiele, bei denen mit Filtern und einer Luftfeuchtigkeit unter 45 % recht gute Ergebnisse erzielt wurden
Mir war nicht klar, dass man auf so etwas achten muss
Deshalb nutze ich einfach die Cloud — damit vermeide ich solche „unbekannten Risiken“
On-Prem und Cloud parallel zu nutzen ist realistisch
Die Kerninfrastruktur wird einer vertrauenswürdigen Cloud überlassen, während Slurm-Jobs auf eigenen Servern laufen
Colocation ist weiterhin eine valide Option, und auch Forschungs-HPC ist einen Blick wert
In Norwegen können auch private Unternehmen Forschungs-HPC gegen Bezahlung nutzen
Ich habe in Italien Serverfarmen an zwei Standorten betrieben; fünf Mitarbeiter haben sie verwaltet und dabei eine nahezu 100%ige Verfügbarkeit gehalten
Für 800.000 Euro pro Jahr wurden so 7–8 Millionen Euro Cloud-Kosten eingespart
Viele Entwickler glauben fälschlicherweise, sie könnten Hosting nicht selbst machen
In Wirklichkeit ist es einfacher als gedacht, und es macht sogar Spaß, technische Probleme zu lösen
Wenn man bei Anbietern wie Equinix oder Global Switch Fläche mietet, werden Strom, Kühlung, Verkabelung usw. vollständig mitverwaltet
Auch eigene Serverräume an zwei Standorten zu betreiben ist durchaus machbar
Wir nutzen Azure weiterhin für nutzernahe Services
Web-Services ohne GPU-Bedarf sind in der Cloud effizienter
Auch GitHub nutzen wir weiterhin als vertrauenswürdigen Service
(im Scherz) In einem Slurm-Pool hat sich mal ein Postgres-Daemon verhakt und Rust ist völlig durchgedreht
Am Ende haben wir es stabilisiert, aber aus Sicht eines Hardware-Ingenieurs ist die Softwarewelt chaotisch
In der Frühphase eines Projekts startet man auf AWS mit 250 Dollar im Monat und wechselt bei etwa 30.000 Dollar Monatskosten auf Colocation
Entscheidend ist die Fähigkeit zur Kostenkalkulation — gute Ingenieure sollten auf dieser Basis dem Management Vorschläge machen können
Dabei geht es nicht nur um einfache Rechnungen, sondern auch darum, welche Talente man anziehen und welches Geschäft man aufbauen will
Für ein Unternehmen, das ML-Modelle trainiert, kann eigene Infrastruktur besser geeignet sein
In den meisten Unternehmen sind Ingenieure an der Wahl der Plattform aber nicht beteiligt
In 99,999999 % der Fälle entscheidet das Management bereits und teilt es dann mit
Zu Beginn meiner Karriere war die Cloud die selbstverständliche Wahl, jetzt ist On-Prem wieder im Trend
In zehn Jahren könnte der Trend schon wieder in die andere Richtung gehen
Meiner Erfahrung nach haben Teams, die On-Prem vorangetrieben haben, die Ermüdung durch Wartung immer unterschätzt
In Umgebungen wie Startups, wo schnelle Entwicklung wichtig ist, bremst das eher
Bei Unternehmen im Wartungsmodus dagegen war On-Prem effizient
Mit zunehmendem Alter wird wichtiger, Dinge „schnell und im Budget“ fertigzubekommen, und der Reiz des selbst betriebenen Infrastruktur-Stacks nimmt ab
Ich sehe diesen Trend nicht nur als technischen Zyklus, sondern als Gegenreaktion auf eine Gesellschaft, in der man nichts mehr besitzt
Von Musik über Wohnungen bis Autos wird alles zum Abo-Modell, und Unternehmen versuchen ebenfalls, ihre Computing-Souveränität zurückzugewinnen
Solche Zyklen gab es schon immer
Mainframe → PC → Serverraum → Cloud → Edge Computing ist nur die wiederholte Bewegung zwischen Zentralisierung und Dezentralisierung
Wenn sich Technik und Prioritäten ändern, schwingt das Pendel wieder zurück
Wenn wieder jemand sagt: „Das Netzwerk ist der Computer“, dann haben wir die nächste Runde gedreht
(Scherz) Als Nächstes kommt vielleicht die Weltraum-Phase (Skynet)
Die meisten Unternehmen meiden On-Prem wegen des Risikomanagements
Gute Unternehmen konzentrieren Risiken auf ihre Kernkompetenzen
Man sollte also nicht nur nach Kosten urteilen, sondern nach risikobereinigten Kosten
Allerdings frage ich mich, ob Unternehmen heute überhaupt noch in der Lage sind, dieses Risiko präzise zu bewerten
Denn Wettbewerbsfähigkeit beim Preis ist am Ende ebenfalls ein Differenzierungsmerkmal
Entscheidend ist, sich auf das Kerngeschäft zu konzentrieren
Wenn es nicht dabei hilft, ein sich schlecht verkaufendes Produkt besser zu verkaufen, sollte man keine Zeit im Rechenzentrum verschwenden
Eine Ausnahme sind Fälle wie Google, wo die Infrastruktur selbst Teil der Produktstärke ist
Am Ende ist es meist ein Kampf, in dem OpEx CapEx schlägt
Der eigentliche Vorteil von On-Prem ist Freiheit, Kontrolle und Privatsphäre
Es geht nicht nur ums Geld, sondern ist wie der Unterschied zwischen einem eigenen Haus und einer Mietwohnung
Das MBA-Dogma der 2010er lautete: „Verlagert alles in die Cloud“
Risiken und Kosten an Dritte auszulagern galt als die richtige Antwort
In der Praxis war unser eigenes Rechenzentrum aber viel günstiger, und die Steigerungsraten bei Software-Abogebühren lagen weit über denen der Hardware
Aber wenn man Personalkosten und Verwaltung mit einrechnet, ist ein reiner Kostenvergleich sinnlos
Ein einziger Tornado kann ein Unternehmen auslöschen — letztlich muss man also nach Wert im Verhältnis zum Risiko entscheiden