La Arquitectura de 500 Petabytes: Cómo OpenAI escaló el almacenamiento para 1 mil millones de usuarios de ChatGPT

OpenAI ha superado la marca de 1 mil millones de usuarios atendidos por ChatGPT y su infraestructura de API, lo que exigió una reformulación extrema en la forma en que la empresa gestiona los datos. El 23 de octubre de 2026, los ingenieros Jon Lee, Hrachya Hakobyan y Chaomin Yu detallaron la "Parte II" de la evolución técnica de Habitat, la plataforma de almacenamiento propietaria de OpenAI. El sistema evolucionó de una biblioteca cliente de Python a un coloso distribuido en casi 40 regiones geográficas, procesando más de 70 millones de solicitudes por segundo y gestionando un volumen de datos superior a 500 petabytes. El núcleo de este salto técnico dependió de llevar el Azure Cosmos DB de Microsoft a su límite absoluto, gestionando cuellos de botella de partición y migrando de entornos de arrendamiento único (single-tenancy) a arrendamiento múltiple (multi-tenancy) gestionado.

El Contexto y la Cronología de la Evolución de Habitat

El viaje del almacenamiento de datos de OpenAI refleja los desafíos de una hiper-escala sin precedentes. Antes de 2023, la empresa basaba gran parte de su infraestructura en sistemas relacionales tradicionales, como PostgreSQL. Sin embargo, el rápido crecimiento de la adopción de ChatGPT evidenció limitaciones severas de escalabilidad, especialmente en relación con la gestión de "claves calientes" (hot keys). Cuando una sola organización o cliente generaba una carga desproporcionada de consultas, la base de datos completa sufría cuellos de botella, exigiendo soluciones complejas de caché y control de tráfico.

Para resolver estos problemas estructurales, OpenAI presentó inicialmente Habitat durante el DevDay 2023. En aquel momento, la plataforma comenzó de forma relativamente modesta, operando como una biblioteca del lado del cliente basada en Python que se conectaba a una base de datos única. El éxito del producto, sin embargo, exigió una rápida transición de una biblioteca local a un servicio autónomo y distribuido globalmente, caracterizando la Fase I de esta transformación técnica, en la que OpenAI adoptó contenedores estándar de Azure Cosmos DB.

En la Fase I, la estrategia involucraba dirigir el tráfico a un único contenedor estándar de Cosmos DB y confiar en el límite teórico de 10,000 Request Units por segundo (RU/s) por clave de partición lógica para generar contrapresión (back pressure). Sin embargo, las decisiones iniciales de API expusieron la selección de estas claves (como user_id y workspace_id) directamente a los clientes. Esto generó colisiones y cuellos de botella, ya que múltiples funcionalidades del producto compartían los mismos límites de partición lógica, estrangulando el throughput general.

La Fase II marcó el intento de aislamiento de cargas de trabajo. El equipo implementó contenedores dedicados (single-tenancy) para casos de uso nuevos y críticos, mitigando conflictos directos de particiones. Aunque este enfoque resolvía el problema del aislamiento, la planificación individual de capacidad (capacity planning) para cada nuevo contenedor generaba desperdicio y sobrecarga operativa considerables, lo que llevó al estado actual de refinamiento del multi-tenancy gestionado nativamente a través de las primitivas de Azure.

Los Números que Definen la Escala de OpenAI

La magnitud del desafío resuelto por la plataforma Habitat se cuantifica mediante métricas operacionales que definen la ingeniería de frontera en el sector de IA. Los datos operacionales publicados en la Parte II del informe técnico (23 de octubre de 2026) revelan:

• Usuarios Activos: Más de 1 mil millones de usuarios en todo el mundo.
• Volumen de Datos: Más de 500 petabytes gestionados por Habitat.
• Caudal de Solicitudes: Más de 70 millones de solicitudes procesadas cada segundo.
• Presencia Global: Operación distribuida en casi 40 regiones geográficas distintas.
• Límites de Infraestructura: 10,000 RU/s (Request Units per second) estipulados por clave de partición lógica en Azure Cosmos DB.
• Autoría de la Arquitectura: El informe técnico "Parte II" está firmado por los ingenieros Jon Lee, Hrachya Hakobyan y Chaomin Yu.

La "Física" de las Bases de Datos en la Nube y los Desafíos de Cosmos DB

El documento de OpenAI expone los efectos secundarios inevitables cuando el volumen de datos entra en fricción con la arquitectura física de la base de datos en la nube. El equipo enfrentó tres obstáculos fundamentales que afectan a cualquier sistema distribuido de este tamaño:

1. Límites de Clave de Partición Lógica: OpenAI expuso las claves lógicas (ej: user_id) para diferentes casos de uso de productos competidores. Como estas cargas de trabajo compartían los límites de las solicitudes de Azure en la misma clave, el diseño estrangulaba las velocidades de lectura y escritura del usuario final, incluso cuando el resto de la infraestructura tenía capacidad de sobra.

2. El Fenómeno de los "Vecinos Ruidosos" (Noisy Neighbors): Aunque los límites oficiales (como los 10,000 RU/s) se aplican a las particiones lógicas, la ejecución real ocurre en los nodos de servidores físicos. Varias particiones lógicas habitan la misma partición física. Así, cargas de trabajo de recursos de nicho consumían la capacidad física, degradando operaciones esenciales, como los flujos de inicio de sesión y registro.

3. Particiones Débiles y el Crecimiento Pasivo: El aprovisionamiento de contenedores de Cosmos DB se distribuye de forma relativamente igualitaria entre las particiones físicas. Cuando el almacenamiento alcanza su tope, una partición física se divide en dos, y cada una recibe la mitad de la capacidad de throughput original. En casos de uso de alto almacenamiento de OpenAI, el simple crecimiento del volumen de datos inactivos reducía el límite efectivo de solicitudes de las particiones físicas, rompiendo cargas de trabajo activas incluso con una tasa de solicitudes del usuario estable.

Para sortear estos escenarios, el cambio técnico final no fue solo construir aislamiento (Fase II), sino implementar un script avanzado de sincronización entre el throughput provisionado y el número de particiones, además de regresar a un modelo multi-tenant optimizado.

El Impacto para el Sector y la Redefinición del Multi-Tenancy

El salto arquitectónico de Habitat afecta directamente a cuatro grupos de manera clara:

La propia OpenAI: La ganancia técnica garantiza que la escalabilidad de ChatGPT y de las APIs de modelos fundacionales (Foundation Models) no colapse bajo su propio peso. Ahora obtienen lecturas de datos hasta 12 veces más rápidas, traduciéndose directamente en un menor tiempo para el primer token generado (Time to First Token - TTFT) y reduciendo drásticamente los costos de sobre-aprovisionamiento en servidores.

Ingenieros de Infraestructura en todo el mundo: El enfoque de OpenAI expone un paradigma en el cual herramientas "listas para usar" de terceros, como los límites documentados de proveedores cloud, requieren ingeniería propietaria profunda para funcionar a hiper-escala. El equilibrio entre el costo operativo del single-tenancy (desperdicio por exceso de aprovisionamiento) versus las pérdidas de rendimiento en el multi-tenancy (vecinos ruidosos) es un estudio de caso directo para equipos que operan Kubernetes y bases de datos no relacionales.

Usuarios del Producto y Mercado Latinoamericano: El mercado de tecnología latinoamericano, compuesto por cientos de miles de desarrolladores que dependen de la API de GPT y usuarios finales en la región, se beneficia de la resiliencia. La latencia global en "casi 40 regiones" estabiliza integraciones críticas en fintechs y startups regionales, evitando que las oscilaciones de pico en Estados Unidos derriben las instancias alojadas regionalmente.

Microsoft y Ecosistema Azure: OpenAI está literalmente estresando la infraestructura de la nube Azure a niveles raramente documentados comercialmente. Los aprendizajes de OpenAI inevitablemente presionan a Microsoft para evolucionar la arquitectura estándar de Cosmos DB y comercializar estas mejoras para otros clientes Fortune 500 en el futuro.

Lo que aún no se sabe

La transparencia del informe técnico deja fuera aspectos vitales de la operación que afectan las finanzas y las migraciones corporativas. Los puntos que aún necesitan aclaración son:

• Mecanismo exacto de Caché Global: Aunque publicaciones periféricas mencionan que el "caching global" fue un factor clave para la aceleración de 12 veces en la velocidad de lectura, el informe original se enfoca mayoritariamente en la optimización de particiones lógicas y físicas de Azure Cosmos DB. Los algoritmos de expiración, coherencia global y tecnologías específicas de Redis o Memcached (si se utilizaron) siguen siendo una caja negra.
• Impacto Financiero de la Migración: La documentación señala que el modelo single-tenant era "caro de operar", pero no detalla si el ahorro operativo absorbió los costos de la compleja ingeniería de enrutamiento de multi-tenancy.
• Migración de Datos Heredados: El texto cita que "muchos casos críticos heredados quedaron atrapados" en el contenedor estándar de la Fase I, exigiendo maniobras para su protección. No está claro cómo OpenAI orquestará la migración en tiempo real de petabytes de datos heredados a nuevos contenedores sin tiempo de inactividad (downtime).

Qué esperar a continuación

El siguiente paso concreto para el equipo de infraestructura de OpenAI implica el desarrollo de un ecosistema de multi-tenancy definitivo, que absorba la carga bruta dejada por los sistemas heredados en contenedores compartidos (default).

La compañía debe automatizar completamente el enrutamiento inteligente de consultas y mejorar el monitoreo del split físico (división) de las particiones en Cosmos DB. La estrategia apunta a profundizar el uso de las primitivas incorporadas en el Cosmos DB de Azure para retrasar la creación de herramientas propietarias superpuestas tanto como sea posible, manteniendo Habitat ligero, incluso sirviendo respuestas en milisegundos para un tercio de la población digital conectada a internet.

Preguntas frecuentes

¿Qué es la plataforma Habitat de OpenAI? Habitat es la plataforma propietaria de almacenamiento en línea de datos de OpenAI, responsable de garantizar acceso casi inmediato a los datos necesarios para el funcionamiento de productos como ChatGPT y las APIs corporativas. Actualmente gestiona más de 500 petabytes de datos en casi 40 regiones.

¿Cuál fue el principal cuello de botella superado por el uso de Cosmos DB? El sistema lidiaba con límites de 10,000 Request Units por segundo (RU/s) en particiones lógicas, generando inestabilidad. Como múltiples claves lógicas compartían un mismo recurso físico, los clientes sobrecargados (vecinos ruidosos) disminuían el rendimiento de la base de datos para los demás servicios regulares.

¿Cuál es la diferencia entre single-tenancy y multi-tenancy implementada por la empresa? En el single-tenancy (arrendamiento único), cada producto tiene su propia base de datos, lo que es seguro, pero extremadamente caro, resultando en una subutilización de la capacidad. En el multi-tenancy gestionado (arrendamiento múltiple), los recursos de la nube se agrupan, y OpenAI utilizó primitivas incorporadas de Azure para controlar la carga y evitar que los servicios impactaran negativamente el almacenamiento y la lectura de otros, optimizando la infraestructura y los costos.