Habitat, la capa que sostiene a los productos de OpenAI
OpenAI describe Habitat como la plataforma de almacenamiento en línea que permite a sus productos acceder a la información con rapidez y fiabilidad. La empresa la sitúa como una capa compartida por ChatGPT, la API, Codex y otros servicios internos, y afirma que debe responder en milisegundos para más de 1.000 millones de usuarios repartidos en 40 regiones geográficas. También enmarca este texto como la segunda parte de una serie técnica sobre una infraestructura que ya sirve más de 500 petabytes de datos.
El interés de la pieza no está en un lanzamiento visible para el usuario final, sino en el trabajo de base que sostiene esos productos. OpenAI explica que, a medida que crecía, Habitat tuvo que equilibrar fiabilidad, rendimiento y velocidad de desarrollo, tres objetivos que no siempre avanzan al mismo ritmo.
De la separación total a la multi-tenencia por defecto
Una parte central del informe repasa la evolución del modelo de alojamiento de datos. OpenAI explica que pasó por varias etapas: primero confió en primitivas de Azure Cosmos DB, después probó aislamiento de cargas y contenedores de un solo inquilino para algunos casos, y finalmente volvió a un esquema multi-tenant por defecto con capacidad de mover datos cuando hace falta. La compañía atribuye ese recorrido a problemas como límites de partición lógica, efectos de “vecinos ruidosos” y las llamadas “weak partitions”, en las que la capacidad efectiva cae conforme crece el almacenamiento.
Según el documento, el enfoque aislado protegía mejor cada servicio, pero obligaba a cada equipo a planificar capacidad por su cuenta y elevaba el coste operativo. El modelo compartido, en cambio, simplificaba la gestión centralizada, pero exponía a unos servicios a interferencias de otros. La solución que describe OpenAI pasa por contenedores co-gestionados con Azure y por una serie de mejoras en la capa subyacente, entre ellas limitación de claves calientes, priorización de cargas en segundo plano y un modo serverless mejorado.
La empresa añade que ese modo serverless mejorado eleva a 10.000 RU/s el techo por partición física. Conviene leer ese dato como una mejora de ingeniería dentro de su propia arquitectura, no como una referencia independiente verificada por terceros.
La combinación que más ha movido la aguja: caché y Rust
La parte más llamativa del texto está en el rendimiento de lectura. OpenAI dice que ha cambiado su estrategia de lectura con tres medidas principales: colocar datos cerca de los usuarios cuando la capacidad lo permite, replicar ampliamente solo los conjuntos más pequeños y sensibles a la latencia, y apoyarse en una caché integrada para el resto. Esa caché usa la change feed de Azure Cosmos DB para propagar invalidaciones a escala global en segundos y mantener baja la obsolescencia de los datos.
La compañía también afirma que ha reducido el sobrecoste de su propio servicio al reescribir Habitat en Rust, tras haber empezado en Python. Según el informe, la combinación de estas medidas ha rebajado la latencia media global de lectura de aproximadamente 120 ms a aproximadamente 10 ms, lo que OpenAI presenta como una mejora de 12 veces desde que empezó a priorizar el rendimiento a comienzos de año.
Ese dato describe la mediana de lectura global, no todos los casos. OpenAI admite además que las solicitudes más lentas siguen existiendo cuando hay que recuperar datos sin caché desde el almacenamiento subyacente, a menudo desde regiones lejanas. En otras palabras, la mejora es clara, pero no elimina por completo la variabilidad de la plataforma.
Qué significa para ChatGPT y para la plataforma
Para el usuario de ChatGPT, la novedad no se traduce en una función visible, pero sí en una infraestructura más rápida y estable para leer estado, ajustes y otros datos que sostienen la experiencia. OpenAI insiste en que Habitat no es solo una pieza de ChatGPT, sino una capa compartida por varios productos, así que las mejoras afectan también a la API, Codex y servicios internos.
La pieza también deja ver la escala del problema operativo. OpenAI explica que su plataforma de captura de cambios procesa millones de modificaciones por segundo, a través de miles de contenedores y millones de particiones, y que esos cambios alimentan más de cien temas de Kafka para índices secundarios, canalizaciones de movimiento de datos, analítica offline y otras funciones en tiempo real.
Lo que no detalla el informe es cuánto cuesta exactamente esta arquitectura ni cuánto margen de mejora queda por región. Lo confirmado es la dirección técnica: más multi-tenencia, más caché, más automatización en la propagación de cambios y menos carga en la capa de servicio. Lo que siga ocurriendo dependerá de cómo OpenAI y Azure continúen ajustando capacidad, latencia y crecimiento.
