- CommaAI realiza todo el entrenamiento de modelos y el procesamiento de datos en su propio centro de datos, operando directamente una infraestructura de unos 5 millones de dólares
- Depender de la nube puede llevar a costos crecientes y pérdida de control, mientras que operar cómputo propio permite mejorar la calidad de ingeniería y reducir costos
- El centro de datos está compuesto por aproximadamente 450 kW de energía, 600 GPU, 4 PB de almacenamiento SSD y una estructura simple de enfriamiento y red
- La pila de software está diseñada con Ubuntu + Salt, almacenamiento minikeyvalue (mkv), planificador Slurm, entrenamiento distribuido con PyTorch y cómputo distribuido con miniray
- Con esta arquitectura, comma.ai automatiza por completo el entrenamiento de modelos de conducción autónoma y logra un ahorro de costos de alrededor de 5 veces frente a la nube
Por qué operar un centro de datos propio
- Depender de la nube genera aumento de costos y dependencia del proveedor
- Las empresas de nube facilitan el onboarding, pero dificultan el offboarding
- Con el uso continuo, es fácil quedar atrapado en una estructura de costos alta
- Operar cómputo propio impulsa la autonomía tecnológica y una cultura de ingeniería más eficiente
- La nube requiere gestión centrada en APIs y sistemas de pago, pero un centro de datos exige resolver problemas técnicos reales centrados en energía, cómputo y ancho de banda
- Incluso desde la perspectiva de ingeniería de ML, las restricciones de recursos impulsan la optimización del código y mejoras de fondo
- En la nube basta con aumentar el presupuesto, pero en infraestructura propia la mejora de rendimiento es obligatoria
- En costos, comma.ai invirtió unos 5 millones de dólares; calcula que hacer el mismo trabajo en la nube habría requerido más de 25 millones de dólares
Componentes del centro de datos
-
Energía
- Uso máximo de 450 kW, con un costo eléctrico de 540,112 dólares en 2025
- La tarifa eléctrica en San Diego es de 40 centavos/kWh, unas 3 veces el promedio mundial
- Se menciona un futuro plan de generación eléctrica propia
-
Enfriamiento
- Usa enfriamiento con aire exterior, más eficiente en consumo eléctrico que un sistema CRAC
- Circulación de aire con 2 ventiladores de entrada y 2 de salida de 48 pulgadas
- Bucle de control PID para ajustar automáticamente temperatura y humedad (manteniéndola por debajo de 45%)
- El consumo eléctrico se mantiene en el rango de decenas de kW
-
Servidores y almacenamiento
- Está compuesto por 75 TinyBox Pro (600 GPU en total), fabricados internamente
- Cada equipo tiene 2 CPU + 8 GPU y se usa tanto para entrenamiento como para cómputo general
- La fabricación propia facilita el mantenimiento
- El almacenamiento se basa en Dell R630/R730, con un total de 4 PB SSD
- Estructura sin redundancia (non-redundant), con 20 Gbps de velocidad de lectura por nodo
- La red está compuesta por 3 switches Z9264F de 100 Gbps y 2 switches Infiniband
Infraestructura de software
-
Configuración base
- Todos los servidores usan Ubuntu + arranque PXE y se administran con Salt
- Una estructura de maestro único mantiene un 99% de disponibilidad
-
Almacenamiento distribuido — minikeyvalue (mkv)
- Los datos de conducción para entrenamiento se guardan en 3 PB de almacenamiento sin redundancia
- 1 TB/s de velocidad de lectura, lo que permite entrenar directamente sin caché
- Un arreglo de 300 TB para caché y un arreglo con almacenamiento redundante guardan modelos y métricas
- Cada arreglo se administra con un servidor maestro único
-
Gestión de trabajos — Slurm
- Programa tanto trabajos de entrenamiento con PyTorch como trabajos distribuidos con miniray
-
Entrenamiento distribuido — PyTorch + FSDP
- Opera dos particiones de entrenamiento conectadas por una red Infiniband
- Un framework propio de entrenamiento automatiza el loop de entrenamiento
- Ofrece un servicio de seguimiento de experimentos de modelos
-
Cómputo distribuido — miniray
- Planificador de tareas open source ligero que ejecuta código Python en máquinas inactivas
- Más simple que Dask, administra tareas con un servidor central Redis
- Los workers con GPU realizan inferencia de modelos con Triton Inference Server
- Puede escalar en paralelo a cientos de máquinas
- Ejemplo: el récord de Controls Challenge se logró usando 1 hora del centro de datos
-
Gestión de código — monorepo basado en NFS
- Todo el codebase ocupa menos de 3 GB y se replica en todas las estaciones de trabajo
- Al iniciar un trabajo, se sincronizan el código local y los paquetes, y termina en menos de 2 segundos
- Garantiza que todos los trabajos distribuidos se ejecuten con el mismo código y entorno
Pipeline de entrenamiento integrado
- La tarea más compleja en comma es entrenar modelos de conducción con enfoque on-policy
- Para este entrenamiento, es necesario ejecutar conducción simulada aplicando los pesos más recientes del modelo para generar datos de entrenamiento
- Todo el pipeline puede ejecutarse con un único comando como el siguiente
./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
- Para ejecutar este entrenamiento se utiliza toda la infraestructura descrita arriba
- Aunque es un solo comando simple, coordina múltiples componentes
Conclusión
- comma.ai logró reducir costos y ganar autonomía tecnológica operando su propio centro de datos
- Con el mismo enfoque, empresas o personas también podrían construir su propia infraestructura
3 comentarios
¡La memoria es cara!
jajajajajajajajajajaja
Opiniones de Hacker News
En nuestra industria, poseer vs. nube están en los extremos de un espectro
① La nube requiere menos inversión inicial (capex) y menos personal, pero tiene costos operativos (opex) altos y variables
② Managed Private Cloud es a lo que nos dedicamos: lo administramos sobre software open source y cuesta alrededor de 50% menos que AWS
③ Rented Bare Metal es un modelo donde te resuelven el financiamiento del hardware, y sale 90% más barato que AWS
④ Comprar directamente y usar colocation es lo más barato si tienes la capacidad técnica y la escala
Empresas como Hetzner operan con un ROI a 3 años, y las opciones 3 y 4 encajan para empresas grandes o donde la infraestructura es clave
Para startups, la 1 es lo realista; para pymes, la 2 (lithus.eu)
El problema es que la estructura de costos de la nube no se debe simplemente al precio del hardware, sino a que te empuja hacia arquitecturas complejas, lo que aumenta la ineficiencia
Los ‘servicios administrados’ de AWS están diseñados de modo que, cuanto más mejora el usuario la eficiencia de sus servidores, menos gana AWS
Si simplemente pones 4 servidores Java sobre EC2 y una base de datos replicada, es mucho más eficiente
Al final, las facturas absurdas de AWS aparecen cuando abusas de demasiados servicios
(derek@ de Carolina Cloud) Nosotros también preferimos el modelo (4), pero los usuarios con menos capacidad técnica se quedan en los modelos 1–3 y terminan atrapados en la estructura de alto costo de la nube pública
Dicen que es ‘pago por uso’, pero en la práctica trae cargos base y consumos mínimos, así que termina siendo mucho más caro (carolinacloud.io)
Hetzner es una opción atractiva
Tener que administrar tú mismo servicios como Postgres o VPN puede pesar, pero a partir de 10–15 mil dólares al mes conviene más que AWS
Hay riesgo, pero vale la pena asumirlo
Yo alquilo un servidor bare metal de 500 dólares al mes, y el tiempo de administración es apenas unas horas al año
Tal vez sea porque mis requisitos son simples, pero me parece mucho mejor que una nube excesivamente compleja
Hace 2 años nos pasamos a colocation, y ahora tenemos más capacidad por 30% del costo
También existe el beneficio de las bajadas tardías de precio en RAM/almacenamiento
Eso sí, hay que prestar un poco más de atención al cumplimiento normativo
Antes a esto simplemente se le llamaba centro de datos
Es un concepto que ya existía antes de la nube, y al final es otra vez el ciclo de propiedad vs. alquiler y centralización vs. descentralización
Cuando una empresa elige de forma extrema solo un lado, vuelve a toparse con los mismos problemas
Lo interesante es que la nube resultaba atractiva para finanzas por el efecto de ahorro fiscal
Pero con leyes recientes (OBB) que permiten tratar el CapEx como gasto, se está viendo un regreso hacia on-prem
Entonces, ¿por qué no aparece una alternativa de nube competitiva en precio?
AWS y Azure dominan el mercado y no tienen incentivos para bajar precios, y Google tiene un riesgo alto de cerrar servicios
Antes de la nube, el equipo interno de infraestructura era el cuello de botella
La nube estandarizó eso y lo simplificó con un sistema de facturación único
Además, fuera de EE. UU. la compra de servidores era lenta, así que la ventaja de velocidad de la nube era grande
Los centros de datos on-prem tienen una carga operativa alta y consumen muchos recursos de ingeniería
Por eso esta discusión vuelve una y otra vez
La verdadera innovación de la nube fue “hacer explícito el costo por servicio”
En lugar de “¿a quién tengo que pedírselo?”, ahora se puede acceder por API
Ese contexto está bien resumido en este texto
Incluso en una zona como San Diego, donde controlar la temperatura es fácil, el enfriamiento con aire exterior es riesgoso
La humedad y los contaminantes dañan los servidores rápidamente
En cambio, métodos como los enfriadores de rueda entálpica (kyotocooling) son eficientes y consumen poca energía en relación con la capacidad de enfriamiento
Hay que tener cuidado con el enfriamiento por aire exterior porque puede acortar mucho la vida útil del equipo
También hay casos de buenos resultados con filtración y manteniendo la humedad por debajo de 45%
No sabía que había que preocuparse por ese tipo de cosas
Por eso yo solo uso la nube — así evito este tipo de ‘riesgos desconocidos’
Lo realista es combinar on-prem y nube
La infraestructura crítica se deja en una nube confiable, y cosas como trabajos de Slurm se corren en servidores propios
El colocation sigue siendo una opción válida, y también vale la pena considerar HPC para investigación
En Noruega, incluso empresas privadas pueden usar HPC de investigación pagando
Yo operé granjas de servidores en dos ubicaciones en Italia; 5 empleados las administraban y manteníamos casi 100% de disponibilidad
Con 800 mil euros al año ahorrábamos entre 7 y 8 millones de euros en costos de nube
Muchos desarrolladores creen por error que no pueden encargarse del hosting
En realidad es más fácil de lo que parece, y también tiene la gracia de resolver problemas técnicos
Si alquilas espacio en lugares como Equinix o Global Switch, ellos se encargan de la energía, el enfriamiento, el cableado, etc.
También es totalmente posible tener tus propias salas de servidores en dos ubicaciones
Nosotros seguimos usando Azure para servicios dirigidos a usuarios
Para servicios web que no necesitan GPU, la nube es más eficiente
GitHub también sigue siendo un servicio confiable para nosotros
(En tono de broma) Una vez un daemon de Postgres se enredó en el pool de Slurm y Rust se descontroló
Al final lo estabilizamos, pero desde la perspectiva de un ingeniero de hardware, el mundo del software es caótico
Al inicio de un proyecto, se puede arrancar en AWS con 250 dólares al mes, y cuando llegas a 30 mil dólares mensuales, pasarte a colocation
La clave es saber calcular costos — un buen ingeniero debería poder proponerlo a la dirección con números
Más allá de la simple cuenta, también hay que pensar qué tipo de talento quieres atraer y qué negocio quieres construir
Si es una empresa que entrena modelos de ML, quizá le convenga más tener infraestructura propia
Pero en la mayoría de las empresas, los ingenieros no participan en la elección de la plataforma
En 99.999999% de los casos, la dirección ya decidió y solo lo comunica
Al principio de mi carrera, la nube era la opción obvia, pero ahora on-prem vuelve a estar de moda
En 10 años quizá vuelva la tendencia contraria
Por mi experiencia, los equipos que impulsaban on-prem siempre subestimaban el cansancio del mantenimiento
En lugares como startups, donde hay que desarrollar rápido, eso más bien te frena
En cambio, en empresas que ya entraron en modo mantenimiento, on-prem sí era eficiente
Con la edad, se vuelve más importante “terminar rápido y dentro del presupuesto”, y operar tu propia infraestructura pierde atractivo
Yo veo esta tendencia no solo como un ciclo tecnológico, sino como una reacción contra una sociedad donde nada se posee
Cuando todo —música, casa, auto— se vuelve suscripción, también aparece un impulso empresarial por recuperar la soberanía computacional
Estos ciclos siempre han existido
Mainframe → PC → cuarto de servidores → nube → edge computing: es la repetición de centralización ↔ descentralización
Al final, cuando cambian la tecnología y las prioridades, todo vuelve
Cuando reaparezca la frase “la red es la computadora”, será otra vuelta más al ciclo
(Broma) Lo siguiente probablemente sea la etapa espacial (Skynet)
La razón por la que la mayoría de las empresas evita on-prem es la gestión del riesgo
Las buenas empresas concentran el riesgo en su ventaja competitiva principal
No hay que juzgarlo solo por costo, sino por costo ajustado por riesgo
Pero hoy también queda la duda de si las empresas tienen la capacidad de evaluar ese riesgo con precisión
Porque la competitividad en precio también es un factor de diferenciación
La clave es enfocarse en el negocio principal
Si no te ayuda a vender mejor un producto que hoy no logras vender, no deberías perder tiempo con un centro de datos
La excepción es un caso como Google, donde la propia infraestructura forma parte de la ventaja competitiva del producto
Al final, en la mayoría de los casos, es una pelea donde Opex le gana a Capex
La verdadera ventaja de on-prem es la libertad, el control y la privacidad
No es solo una cuestión de dinero; se parece más a poseer una casa vs. rentarla
La doctrina tipo MBA de los años 2010 era “mueve todo a la nube”
Se veía como la respuesta correcta transferir el riesgo y el costo a un tercero
Pero en la práctica, nuestro centro de datos era mucho más barato, y las alzas en las suscripciones de software fueron mucho mayores que en hardware
Pero si consideras también el costo laboral y de gestión, una comparación de costo simple no tiene sentido
Un solo tornado podría llevarse por delante a una empresa, así que al final hay que decidir según el valor frente al riesgo