De $0 a $5M - Cómo comma.ai montó su datacenter (análisis de costes)

comma.ai opera un datacenter de $5M mientras su competencia paga facturas millonarias a AWS cada trimestre. ¿Locura o genialidad?

La mayoría de startups nunca cuestionan el dogma “cloud-first”. Pero para cargas de trabajo de machine learning, la economía está cambiando radicalmente en 2026. George Hotz y su equipo en comma.ai hicieron una apuesta contraria que les ha ahorrado más de $20 millones frente al equivalente en cloud.

Los números no mienten: 5x de ahorro en costes comparado con AWS. Y no es casualidad.

La decisión que nadie se atreve a tomar

El “cloud-first” ha sido dogma tecnológico durante 15 años. AWS, Google Cloud y Azure han construido imperios sobre la premisa de que alquilar siempre es mejor que comprar. Para la mayoría de empresas, esto es cierto. Pero para compañías con cargas intensivas de machine learning, las matemáticas cuentan otra historia.

comma.ai, la empresa de conducción autónoma fundada por George Hotz, tomó una decisión que muchos consideraron temeraria: invertir $5M en construir su propio datacenter. Mientras otras empresas de ML pagan facturas de cientos de miles de dólares mensuales a proveedores cloud, comma.ai controla cada dólar de infraestructura.

El problema que enfrentan las empresas ML-heavy:

• Facturas de AWS que crecen exponencialmente con el volumen de datos
• Vendor lock-in que limita flexibilidad técnica y estratégica
• Infraestructura como margen de beneficio de otra empresa
• Costes de egress de datos que se disparan con procesamiento intensivo

En este artículo, analizamos los números reales del datacenter de comma.ai, calculamos el punto de equilibrio frente a cloud, y desarrollamos un framework de decisión para saber cuándo tiene sentido la infraestructura propia. Con datos, no opiniones.

El setup de comma.ai: hardware, software y filosofía

Hardware: 600 GPUs y 4PB de almacenamiento

La configuración de comma.ai es impresionante pero no extravagante:

Computación:

• 75 máquinas TinyBox Pro (diseño propio)
• 600 GPUs totales (8 GPUs por máquina, 2 CPUs cada una)
• Uso mixto: entrenamiento de modelos y computación general
• Construcción in-house para optimizar costes

Almacenamiento:

• ~4 petabytes distribuidos en servidores Dell R630/R730
• Almacenamiento no redundante para datos de entrenamiento (3PB gestionados por minikeyvalue)
• Infraestructura diseñada para acceso de alta velocidad

Inversión total: $5M en hardware y setup inicial.

Lo interesante no es solo el hardware. Es que lo construyeron ellos mismos. Las TinyBox Pro son máquinas optimizadas para el workload específico de comma.ai: entrenar modelos de conducción autónoma con millones de millas de datos de vídeo.

Software: simplicidad radical con herramientas custom

Aquí es donde la filosofía de comma.ai brilla. En lugar de adoptar soluciones enterprise complejas, construyeron herramientas minimalistas pero production-grade:

minikeyvalue (mkv): Key-value store distribuido en ~1,000 líneas de código

• Gestiona 3PB de almacenamiento no redundante
• Stack tecnológico: nginx + filesystem + LevelDB
• Principio de diseño: simplicidad sobre features
• Open source en GitHub

miniray: Scheduler ligero para tareas distribuidas

• Ejecuta código Python distribuido en el cluster
• Alternativa más simple que Dask o Apache Ray
• Usa API estándar de concurrent.futures
• Enfocado en hacer una cosa bien: distribuir trabajo

Otras herramientas:

• Slurm para scheduling de jobs
• PyTorch con FSDP (Fully Sharded Data Parallel) para entrenamiento distribuido
• Monitorización y métricas custom

La lección clave: herramientas simples, bien hechas, específicas para tu problema. No necesitas adoptar toda la complejidad de Kubernetes si 1,000 líneas de Python bien escritas resuelven tu caso de uso.

Filosofía: el coste real del vendor lock-in

George Hotz es conocido por opiniones técnicas controvertidas pero fundamentadas. Su filosofía sobre infraestructura:

“El mayor error que cometimos con las computadoras fue ponerlas en datacenters en lugar de en las manos de las personas.” — George Hotz

Para comma.ai, esto se traduce en principios concretos:

1. Evitar vendor lock-in a toda costa: Dependencia de AWS/GCP significa ceder control estratégico
2. Control = mejores prácticas de ingeniería: Gestionar tu propia infraestructura te obliga a entender profundamente tus sistemas
3. Commoditizar el petaflop: Hacer accesible la computación masiva, no mantenerla como dominio exclusivo de hyperscalers
4. Ingeniería honesta: Construir lo necesario, no lo que vende el vendor

Esta filosofía es debatible para muchas empresas. Pero para comma.ai, con cargas de ML predecibles y altísimo uso (entrenamiento 24/7), las matemáticas respaldan la ideología.

Análisis de costes: los números reales

Ahora entramos en lo importante: los dólares. ¿Funciona realmente la apuesta de comma.ai o es vanidad tecnológica cara?

La inversión inicial: $5M desglosados

Desglose estimado del CAPEX:

• Hardware de computación (GPUs, CPUs, RAM): ~$3.5M
• Infraestructura de almacenamiento: ~$800K
• Networking y switches de alta velocidad: ~$400K
• Setup inicial y colocation/facility: ~$300K

Total: $5M upfront antes de operaciones.

Para contexto, eso es aproximadamente:

• El presupuesto de infraestructura de una Serie B bien financiada
• 2-3 años de salarios de un equipo de ingeniería de 10 personas
• Una inversión que muchos CEOs y CFOs rechazarían instintivamente

Equivalente en cloud: $25M+ de diferencia

comma.ai estima que ejecutar la misma capacidad en AWS costaría más de $25M solo en el equivalente de hardware, antes incluso de considerar costes operacionales recurrentes.

Contexto de precios cloud 2026:

Según datos de múltiples proveedores (RunPod, Jarvislabs), los precios de GPUs en cloud han estabilizado después de caídas del 64-75% desde picos de 2024:

• NVIDIA H100: $2.85 - $3.50/hora (precio estabilizado Q1 2026)
• 200 GPU-hours en AWS: ~$1,514
• 200 GPU-hours en Azure: ~$1,396
• 200 GPU-hours en GCP: ~$2,212

Para una operación como comma.ai con 600 GPUs corriendo casi 24/7, los costes mensuales en cloud serían astronómicos:

Cálculo conservador:

• 600 GPUs × $3/hora × 720 horas/mes = $1.3M/mes
• Anual: $15.6M solo en compute
• 3 años: $46.8M vs $5M initial + operational costs

Costes ocultos del cloud que muchos olvidan:

• Egress de datos: Puede superar los costes de GPU para workloads data-intensive
• Almacenamiento: 4PB en S3/GCS cuesta $80-100K/mes adicionales
• Soporte Enterprise: $10-50K/mes según tier
• Networking premium: Para baja latencia entre GPUs

Según análisis de Cudo Compute y Swfte AI, estos costes ocultos pueden añadir 30-50% adicional a la factura base de GPU.

Costes operacionales continuos (OPEX)

La infraestructura propia no es gratis. Tiene costes recurrentes significativos:

Estimación anual de OPEX:

• Mantenimiento de hardware: ~50% del coste de hardware/año = $1.75M
• Energía y refrigeración: $300-500K (depende de ubicación y PUE del datacenter)
• Colocation/facility fees: $100-200K
• Personal (DevOps/Infra): 2-3 ingenieros senior = $400-600K/año
• Networking y bandwidth: $50-100K

Total OPEX anual: ~$2.6M - $3.2M

Comparación cloud vs on-premise:

• Cloud: $15.6M/año (solo compute) + $1M almacenamiento = $16.6M/año
• On-premise: $3M/año operational (después del CAPEX inicial)

Ahorro anual después del primer año: $13.6M

Incluso con estimaciones conservadoras de mantenimiento al 50% del coste de hardware anualmente, la infraestructura on-premise a utilización del 100% sigue siendo significativamente más barata que el equivalente en cloud.

Break-even analysis: cuándo se recupera la inversión

El análisis crítico: ¿cuánto tiempo tarda en amortizarse la inversión inicial?

Según estudios de TCO de Lenovo Press y análisis de RunPod:

Break-even general para infraestructura GPU:

• Configuración 8x NVIDIA H100: break-even a ~8,556 horas = 11.9 meses
• Con reserved instances (3-5 años): break-even a ~10.4 meses

El umbral crítico: la regla de las 6 horas

Esta es la métrica más importante para tu decisión:

• Menos de 5 horas/día de uso: Cloud es más económico
• 6-9 horas/día: On-premise empieza a ser cost-effective
• Más de 6 horas/día continuos: Definitivamente on-premise

¿Por qué 6 horas? Es el punto donde los costes de compute cloud superan el coste amortizado de hardware propio + operational expenses.

El caso de comma.ai:

• Utilización: ~20-24 horas/día (entrenamiento continuo)
• Break-even: alcanzado a los ~12 meses
• Ahorro acumulado a 3 años: $35M+ (vs cloud)

La alta utilización predecible es lo que hace que los números funcionen. Si tus GPUs están idle el 50% del tiempo, la ecuación cambia radicalmente.

Ahorro total a 3 años: el ROI real

Año 1:

• Inversión: $5M (CAPEX)
• OPEX: $3M
• Total: $8M
• vs Cloud: $16.6M
• Ahorro primer año: $8.6M

Año 2:

• Solo OPEX: $3M
• vs Cloud: $16.6M
• Ahorro segundo año: $13.6M

Año 3:

• Solo OPEX: $3M
• vs Cloud: $16.6M
• Ahorro tercer año: $13.6M

Ahorro acumulado 3 años: $35.8M

ROI de la inversión inicial: 716% en 3 años.

Estos números explican por qué comma.ai tomó la decisión. Y por qué más empresas ML-heavy están corriendo los mismos cálculos en 2026.

¿Cuándo tiene sentido montar tu datacenter?

No todas las empresas son comma.ai. La infraestructura propia no es una solución universal. Aquí está el framework de decisión basado en datos reales.

Señales verdes: cuando self-hosting tiene sentido

1. Cargas de trabajo altas y predecibles

Si cumples estos criterios, self-hosting probablemente te ahorrará dinero:

• Entrenamiento de ML diario o continuo
• Patrones de computación predecibles (no esporádicos)
• Más de 6 horas/día de utilización de GPUs
• Workloads que escalan horizontalmente (puedes usar toda la capacidad)

Ejemplo: Empresa de computer vision procesando 100TB de vídeo diario para entrenamiento de modelos.

2. Equipo de DevOps sólido

Necesitas capacidad técnica in-house:

• Expertise en infraestructura y sistemas distribuidos
• Capacidad de construir y mantener tooling custom
• Cultura de ingeniería que valora control sobre conveniencia
• Al menos 2-3 ingenieros senior dedicados a infraestructura

Ejemplo: Team de 50+ ingenieros con 3-5 dedicados a platform/infra.

3. Capital disponible

Requerimientos financieros:

• $5M+ de inversión upfront posible
• Pensamiento a largo plazo (horizonte 12+ meses)
• Cash flow que soporta modelo CAPEX en lugar de OPEX
• CFO que entiende amortización vs gasto operativo

Ejemplo: Serie B+ bien financiada o empresa profitable con reserves.

4. Preocupación por vendor lock-in

Consideraciones estratégicas:

• Control sobre roadmap de infraestructura
• Evitar dependencia de decisiones de AWS/GCP
• Oportunidades de optimización custom
• Datos sensibles o proprietary que prefieres controlar

Ejemplo: Empresa con IP crítica en algoritmos de ML que quiere control total.

5. Operaciones ML/AI-heavy

Perfil de uso:

• El entrenamiento de modelos es core business (no auxiliar)
• Procesamiento de datos a escala petabyte
• Optimización de performance es ventaja competitiva crítica
• Iteración rápida requiere acceso instantáneo a compute

Ejemplo: Empresa cuyo producto ES el modelo (LLMs, modelos generativos, etc).

Señales rojas: cuando cloud gana

1. Cargas de trabajo variables

Si tu perfil es este, quédate en cloud:

• Necesidades de compute impredecibles
• Uso estacional o con picos (black friday, campañas marketing)
• Baja utilización promedio (menos de 5 horas/día)
• Workloads que no escalan linealmente

Ejemplo: SaaS B2B con procesamiento batch nocturno ocasional.

2. Recursos limitados de DevOps

Constraints de equipo:

• Team de ingeniería pequeño (menos de 10 personas)
• Sin expertise en infraestructura
• Necesitas focus en producto, no en ops
• No puedes dedicar 2-3 ingenieros a mantener infra

Ejemplo: Startup pre-Serie A con 5 ingenieros fullstack.

3. Distribución geográfica

Requerimientos multi-región:

• Necesidad de presencia en múltiples continentes
• Concerns de latencia para usuarios globales
• Compliance en múltiples jurisdicciones
• Redundancia geográfica para disaster recovery

Ejemplo: App consumer global con usuarios en 50+ países.

4. Startup early-stage

Características de fase temprana:

• Capital limitado (pre-Serie A)
• Trayectoria de crecimiento incierta
• Necesitas flexibilidad sobre optimización de costes
• Experimentación rápida es más crítica que eficiencia

Ejemplo: MVP en fase de product-market fit con métricas volátiles.

5. Complejidad de compliance

Overhead regulatorio:

• Múltiples certificaciones requeridas (SOC2, HIPAA, PCI-DSS, etc)
• Proveedores cloud ofrecen compliance as a service
• Auditorías propias serían prohibitivamente caras
• Equipos legales/compliance limitados

Ejemplo: HealthTech manejando PHI que necesita HIPAA compliance.

Framework de decisión: la tabla definitiva

Scoring simple:

• 7-9 factores alineados con “Self-Host”: Considera seriamente infraestructura propia
• 4-6 factores mixtos: Enfoque híbrido (próxima sección)
• 7-9 factores alineados con “Cloud”: Mantente en cloud

La mayoría de empresas caen en la zona intermedia. Por eso el enfoque híbrido es el pragmático.

El enfoque híbrido: lo mejor de ambos mundos

En 2026, las empresas más sofisticadas no eligen “cloud vs on-premise”. Eligen “cloud AND on-premise” con arquitectura de tres capas.

Arquitectura de tres capas para ML

Capa 1: On-premise core (70-80% del compute)

Para cargas predecibles y de alto uso:

• Inferencia de producción con tráfico consistente
• Jobs de entrenamiento scheduled (nightly, weekly)
• Capacidad baseline predecible
• Optimizado para coste por token/inference

Ejemplo concreto: 200 GPUs on-premise para entrenar modelo principal cada noche + serving de producción.

Capa 2: Cloud burst capacity (15-25% del compute)

Para flexibilidad y experimentación:

• Experimentación e investigación (modelos nuevos)
• Manejo de picos (lanzamientos de producto, demos)
• Testing de expansión geográfica
• Fallback para disaster recovery

Ejemplo concreto: 0-100 GPUs en AWS/GCP on-demand para experimentos y picos de tráfico.

Capa 3: Edge para latencia (5-10% del compute)

Para casos críticos de tiempo:

• Inferencia time-critical (<100ms latency)
• Procesamiento local de datos sensibles
• Mínima dependencia de network
• Dispositivos IoT o edge computing

Ejemplo concreto: Modelos pequeños en edge devices para pre-procesamiento antes de enviar a cloud/on-prem.

Esta arquitectura de tres capas es la que emerge como best practice en 2026 para empresas ML-heavy.

Caso de estudio: empresa ML hipotética

Perfil:

• 50 ingenieros, 10 en ML/Data
• $100M ARR, Serie C
• Entrenamiento diario de modelos de NLP
• Serving de 50M predictions/día

Configuración híbrida:

On-premise:

• 200 GPUs (25 máquinas × 8 GPUs)
• Inversión: $2M initial
• OPEX: $1.2M/año
• Cubre: 80% del entrenamiento + todo el serving de producción

Cloud (AWS):

• 0-100 GPUs on-demand (variable)
• Coste promedio: $150K/mes = $1.8M/año
• Cubre: Experimentos, picos, geo-expansion testing

Edge:

• Modelos optimizados en customer devices
• Coste: incluido en product engineering

Total cost año 1: $2M (CAPEX) + $1.2M (on-prem OPEX) + $1.8M (cloud) = $5M vs Pure cloud: $12M/año estimado para el mismo workload Ahorro: $7M en año 1, $10M/año en años 2+

Beneficios adicionales:

• Flexibilidad mantenida para experimentación
• Disaster recovery built-in (failover a cloud)
• Optimización de coste sin sacrificar velocidad de innovación

Estrategia de migración gradual

Si estás considerando moverte de pure cloud a híbrido, no lo hagas de golpe. Estrategia recomendada:

Phase 1: Baseline y auditoría (Mes 1-2)

• Audita gasto actual en cloud (desglosado por workload)
• Mide utilización real de recursos (cuántas horas/día realmente usas)
• Identifica cargas predecibles vs variables
• Calcula break-even teórico para tu scale

Phase 2: Infraestructura on-premise piloto (Mes 3-5)

• Adquiere cluster pequeño (10-20 GPUs para empezar)
• Migra UNA carga de trabajo de alta utilización
• Mantén todo lo demás en cloud (safety net)
• Aprende operational challenges reales

Phase 3: Migración de workloads predecibles (Mes 6-12)

• Mueve gradualmente jobs de entrenamiento scheduled a on-prem
• Optimiza tooling y automation
• Mantén cloud para burst y experiments
• Monitoriza savings vs targets

Phase 4: Optimización y scaling (Mes 12-18)

• Escala on-premise basado en learnings
• Refina división cloud/on-prem
• Implementa automation avanzada
• Alcanza target de 70-80% on-premise, 20-30% cloud

Timeline total: 12-18 meses para migración completa y madura.

Keys de éxito:

• No apagar cloud prematuramente (keep safety net)
• Empezar pequeño y escalar basado en data
• Invertir en automation desde día 1
• Medir religiosamente: costs, utilization, reliability

Optimización de costes en configuración híbrida

Tácticas específicas para maximizar ROI:

En cloud:

• Spot instances para training jobs no-críticos (60-80% descuento)
• Reserved instances (1-3 años) para baseline predecible en cloud (40-60% descuento)
• Savings Plans en AWS para flexibilidad con descuento
• Committed use en GCP para cargas parcialmente predecibles

En on-premise:

• Maximizar utilization con scheduler inteligente (Slurm, Kubernetes)
• Shared resources entre teams (no silos)
• Right-sizing: no sobre-provisionar “por si acaso”
• Monitorización de idle time (target: <10% idle)

Resultado esperado: 50-60% de reducción de coste total vs pure cloud, manteniendo flexibilidad.

Lecciones prácticas para tu empresa

Después de analizar los números de comma.ai y el landscape de 2026, aquí están las lecciones accionables para tu organización.

5 conclusiones clave

1. “Cloud-first” no es verdad universal

La narrativa dominante de la última década ha sido: “siempre usa cloud, nunca gestiones infraestructura”. Esta regla tiene excepciones importantes:

• Para workloads de ML con alta utilización (>6 horas/día), on-premise puede ahorrar 60-80% de costes
• El dogma “cloud is always cheaper” asume utilización baja y variable, no cargas 24/7
• Cuestiona el dogma con datos de TU empresa, no con assumptions generales

Acción: Calcula tu utilización real de GPUs en cloud. Si es >50% consistent, tienes un case para considerar alternativas.

2. Las prácticas de ingeniería importan más que el provider

comma.ai construyó herramientas custom de 1,000 líneas de código que reemplazan sistemas enterprise complejos. La lección:

• Infrastructure ownership fuerza mejores prácticas (conoces profundamente tus sistemas)
• Herramientas simples y específicas > frameworks genéricos complejos
• Control permite optimización imposible con abstracciones de terceros
• “Build vs buy” tiene respuesta diferente cuando buy = lock-in costoso

Acción: Pregúntate: ¿estamos usando el 20% de features de nuestro tooling actual? ¿Podríamos construir el 80% que necesitamos de forma más simple?

3. Híbrido es la opción pragmática para la mayoría

Solo un porcentaje pequeño de empresas debe ir 100% on-premise como comma.ai. Para la mayoría:

• Start with cloud (everyone does, it’s fine)
• Add on-premise estratégicamente para cargas predecibles
• Keep flexibility donde la necesites (experiments, spikes)
• Optimize for 70/30 split (on-prem/cloud) en estado maduro

Acción: No migres todo o nada. Identifica UNA carga de trabajo candidata para on-premise y pilotéala.

4. La regla de las 6 horas

Este es el heuristic más simple y accionable:

• <5 horas/día uso: Pure cloud es óptimo
• 6-9 horas/día: Híbrido empieza a tener sentido económico
• >9 horas/día: Mayormente on-premise con burst cloud

Este cálculo simplifica un análisis TCO complejo en una métrica tracking fácil.

Acción: Mide cuántas horas/día realmente están activas tus GPUs (no provisioned, sino ACTIVAS). Si es >6hrs, tienes un case.

5. Independencia de vendor tiene valor no-financiero

Más allá del coste:

• Control estratégico sobre tu infraestructura crítica
• No estás a merced de price increases unilaterales de AWS/GCP
• Autonomía de ingeniería (no esperas features del vendor)
• Diferenciación técnica (tu infra puede ser ventaja competitiva)

George Hotz’s point: “putting computers in data centers instead of people’s hands” es sobre democratización de acceso y control.

Acción: Calcula no solo el ROI financiero, sino el valor estratégico de independence para tu producto.

Action steps: qué hacer esta semana, mes y trimestre

Esta semana:

• Audita gasto actual en cloud

  • Desglose por servicio (compute, storage, network)
  • Identifica qué % es GPU/ML workloads
  • Separa cargas predecibles vs variables

• Calcula utilización real de GPUs

  • Horas activas/día (no solo provisioned)
  • Workloads que corren >6 horas/día
  • Idle time promedio

• Identifica cargas predecibles

  • Training jobs scheduled
  • Production inference con tráfico estable
  • Batch processing regular

Este mes:

• Run break-even analysis para tu escala

  • Usa calculadoras de TCO (Lenovo, AWS)
  • Compara 1 año, 3 años, 5 años
  • Incluye OPEX real (personal, energía, mantenimiento)

• Evalúa capacidad de tu equipo

  • ¿Tienes 2-3 ingenieros que podrían gestionar infra?
  • ¿Tu cultura valora ownership sobre conveniencia?
  • ¿Experiencia actual en systems/infra?

• Explora opciones de arquitectura híbrida

  • Investiga colocation providers en tu región
  • Benchmarks de hardware actual (H100, H200 pricing)
  • Diseña three-tier architecture sketch

Este trimestre:

• Piloto pequeño on-premise (si los números dan sentido)

  • Cluster de 10-20 GPUs
  • Migra UNA carga predecible
  • Mide savings, reliability, operational overhead reales

• Optimiza spend en cloud (independientemente de on-prem decision)

  • Implement spot instances para non-critical jobs
  • Compra reserved capacity para baseline predecible
  • Auditoria de recursos idle (shutdown automático)

• Build expertise interna en infraestructura

  • Training de team en systems/distributed computing
  • Contrata 1-2 infra engineers si planning on-prem
  • Document current architecture y optimizations

Recursos útiles

Herramientas de comma.ai (open source):

• minikeyvalue: Distributed key-value store
• Blog posts de George Hotz sobre filosofía de infraestructura

Calculadoras y análisis TCO:

• Lenovo TCO Calculator: Generative AI cloud vs on-premise
• Swfte AI TCO Analysis: 2026 cloud vs on-prem comparison

GPU pricing comparisons:

• Jarvislabs H100 Price Guide: NVIDIA H100 GPU costs 2026
• RunPod GPU Providers: Top 12 cloud GPU providers

Consultoría especializada:

• Auditoría Gratuita de Infraestructura: 30 minutos con nuestro equipo para evaluar tu caso

Conclusión: calcula primero, decide después

La apuesta de $5M de comma.ai no fue impulsiva. Fue calculada, basada en utilización real, horizonte temporal claro y capacidad de equipo comprobada. Los resultados: más de $20M ahorrados vs cloud en capacidad equivalente, con break-even alcanzado a los 12 meses.

Pero comma.ai es un caso extremo. Tienen:

• Utilización de GPUs del 90%+ (entrenamiento 24/7)
• Equipo de ingeniería de élite cómodo construyendo infra
• Cargas de trabajo perfectamente predecibles
• Capital disponible para inversión upfront

La mayoría de empresas no cumplen todos estos criterios. Y eso está bien.

El panorama de 2026:

La era de “cloud-first para todas las cargas de AI” está terminando. Los datos económicos favorecen on-premise para workloads de ML predecibles con alta utilización. Pero la flexibilidad sigue teniendo valor real.

Las empresas más sofisticadas no dogmatizan. Optimizan.

• Usan cloud donde tiene sentido (experiments, burst, geo-distribution)
• Usan on-premise donde ahorra dinero (baseline predecible, high-utilization)
• Miden religiosamente y ajustan basado en datos reales

La pregunta no es si cloud u on-premise es “mejor”.

La pregunta es: ¿Cuál es tu utilización? ¿Cuál es tu timeline? ¿Cuál es tu break-even?

Corre los números. Luego decide.

La apuesta contraria de George Hotz no fue locura. Fue matemáticas. En 2026, más empresas de ML están corriendo los mismos cálculos y llegando a las mismas conclusiones: own your infrastructure or let it own you.

¿No estás seguro si self-hosting tiene sentido para tu infraestructura de ML?

Hemos ayudado a empresas a analizar su gasto en cloud y diseñar arquitecturas híbridas que ahorran 40-60% en costes de compute sin sacrificar flexibilidad.

Solicita una Auditoría Gratuita de Infraestructura — 30 minutos con nuestro equipo, análisis personalizado de tu caso, recomendaciones específicas basadas en tus números reales.