Análisis en profundidad · Unos 7 min de lectura
Cómo OpenAI rediseñó Habitat: capacidad compartida, cachés regionales y una mejora de lectura de 12× con límites
OpenAI detalla la tenencia de Cosmos DB, la invalidación por CDC y Rust; la mejora de la mediana combina varios cambios.
- Publicado aquí
- Fecha de la fuente
- Fuente revisada
En un artículo de ingeniería del 23 de octubre, OpenAI explica cambios en el almacenamiento Azure Cosmos DB y la ruta de lectura de Habitat. Son decisiones operativas y mediciones comunicadas por la empresa, no el lanzamiento de un modelo o de un servicio público de almacenamiento.
Escucha las noticias
Escucha este artículo o continúa con las noticias.
Preparando la lectura…
Voz del dispositivo
El navegador o dispositivo procesa la voz. AISubHub no envía el texto a una API de audio. Las voces y la reproducción con pantalla bloqueada dependen del dispositivo.
Al continuar puede repetirse una frase breve.
Resumen
- OpenAI atribuye la reducción del p50 global de lectura de unos 120 ms a 10 ms a ubicación de datos, cachés regionales y una reescritura en Rust; las lecturas lentas sin acierto de caché todavía alcanzan almacenamiento distante.
- Habitat pasó de contenedores compartidos a aislados y volvió a compartir por defecto tras colaborar con Azure. Otro sistema de escala exabyte sigue en desarrollo.
Por qué compartir podía limitar funciones no relacionadas
OpenAI describe Habitat como una capa con más de 500 petabytes para productos que atienden a más de 1.000 millones de usuarios en 40 regiones geográficas. Son cifras del autor, no un recuento independiente ni usuarios incorporados en este anuncio. El problema es agrupar capacidad sin que una función perjudique a otra. Inicialmente cada cuenta Cosmos DB tenía un contenedor predeterminado y los clientes elegían claves de partición lógica; identificadores comunes podían hacer que usos diferentes compartieran el mismo límite.
RU/s expresa unidades de solicitud por segundo, no un número fijo de consultas. El diseño inicial confiaba en un límite anunciado de 10.000 RU/s por clave lógica, pero los límites se aplican en particiones físicas compartidas. Claves no relacionadas compiten allí. Además, si aumenta el almacenamiento y se divide una partición sin aumentar el rendimiento total del contenedor, cada hija recibe menos capacidad. Un uso con objetos grandes puede sufrir límites aunque no suba su tasa de solicitudes. Los diagramas explican mecanismos; sus proporciones no son mediciones de producción.
El aislamiento redujo daños y multiplicó la planificación
Los contenedores dedicados dieron a servicios críticos particiones físicas separadas y redujeron el alcance de los vecinos ruidosos. El equipo también ajustó el rendimiento aprovisionado al número de particiones para corregir las débiles. A cambio, cada servicio debía planificar capacidad. Un salto de pruebas internas a tráfico público podía saturar un contenedor pequeño, mientras el mismo incremento apenas alteraba un gran fondo compartido. Separar cargas cambió las fronteras del fallo, pero no eliminó la previsión necesaria antes de un lanzamiento.
Habitat volvió a compartir por defecto con limitación de claves calientes, menor prioridad para trabajo masivo y una variante serverless desarrollada con Azure. El artículo contrapone el límite anterior de 5.000 RU/s por partición física a una modalidad adaptada de hasta 10.000 RU/s, con divisiones por uso de RU además de almacenamiento. Describe una colaboración concreta, no una configuración que todos los clientes puedan activar. Nuestro análisis: compartir vuelve a ser sostenible cuando la ejecución protege tráfico interactivo y el control de capacidad responde a la demanda.
Por qué el servicio gestionado necesitó pruebas conjuntas
OpenAI afirma que su mayor cuenta Cosmos DB almacena decenas de petabytes y sirve más de 20 millones de consultas por segundo. Un corte eléctrico a finales de 2024 y un incidente de retorno aproximadamente un mes después revelaron supuestos no comprobados: tras un corte eléctrico, las cuentas mayores tardarían varias horas en conmutar a otra región; aproximadamente un mes después, el retorno provocó una avalancha de conexiones que saturó la pasarela original. Los clientes volvieron a conectarse antes de que retornaran todas las particiones correspondientes. Fueron dos fases e incidentes, no una única caída continua.
La respuesta no se limitó a comprar capacidad. Habitat y Azure supervisan conjuntamente las capas, prueban una cuenta no productiva de tamaño comparable a producción, revisan SDK y mantienen escalamiento directo entre ingenieros. También describen caché de metadatos de pasarela, protección de carga, reutilización de conexiones y separación de trabajo crítico y fuera de línea. Inferimos que otros equipos deberían probar tanto la conmutación como el retorno a escala representativa. Que el proveedor gestione la base no valida automáticamente conexiones, tiempo de recuperación o alcance aceptable del fallo.
Qué incluye realmente la mejora de lectura de 12×
Según OpenAI, las lecturas superan el 90% de las solicitudes de Habitat. La estrategia acerca datos cuando hay capacidad, replica ampliamente pocos conjuntos pequeños sensibles a latencia y usa Valkey cercano para otros objetos y relaciones frecuentes. Algunas cuentas críticas se replican en las 40 regiones Azure atendidas; eso no implica replicación global de todos los datos. Almacenamiento y cómputo compiten por electricidad, refrigeración y espacio. La ubicación sigue siendo una decisión de producto y capacidad, sin garantía ilimitada de proximidad.
La invalidación se alimenta del flujo de cambios de Cosmos DB: consumidores CDC invalidan copias locales tras actualizaciones y la siguiente lectura las repuebla. OpenAI informa de propagación global en segundos, evitando depender solo de expiración TTL; no equivale a consistencia instantánea. La reescritura en Rust redujo también sobrecarga. En conjunto, el p50 global pasó de unos 120 ms a 10 ms. La gráfica distingue replicación cercana, caché regional y Rust. El factor 12× no corresponde solo a Rust, no describe escrituras ni el tiempo total de respuesta de ChatGPT para cada usuario.
CDC a escala y la diferencia entre despliegue y proyecto
CDC también alimenta índices secundarios, traslado de datos y análisis. OpenAI comunica millones de cambios por segundo desde miles de contenedores y millones de particiones, a través de más de cien temas Kafka. Un plano de control distribuye regiones y trabajadores; lecturas en réplicas y baja prioridad protegen tráfico interactivo. Aislamiento de flujos, gestión de arrendamientos, colas de mensajes fallidos y cambio de lectores ante averías regionales cubren fallos distintos. Apartar entregas permanentemente fallidas evita bloquear el flujo, pero no demuestra que todos los consumidores estén al día.
Persisten límites importantes: los fallos lentos de caché acceden al almacenamiento remoto y el artículo no ofrece un experimento controlado que separe cada optimización ni una garantía universal de latencia de cola. OpenAI desarrolla un sistema exabyte con el núcleo RocksDB Cloud de Rockset, replicación Raft y modelo documental compatible con Cosmos. Almacenamiento desagregado y replicación física buscan ahorrar flash a cambio de menor QPS máximo. Sigue en desarrollo; no ha sustituido Cosmos. Leímos esta segunda parte y su gráfica, sin verificar independientemente la primera, el código SDK o garantías de servicio enlazadas.
Por qué importa
Los equipos pueden comparar aislamiento, margen agregado de capacidad y responsabilidades operativas. Frescura de caché, recuperación y latencia de cola requieren criterios de aceptación distintos.
Límites y disponibilidad
Son afirmaciones de OpenAI, sin reproducción de AISubHub ni garantía de Azure. El texto no establece acceso universal al modo serverless personalizado, ventajas de suscripción ni mejoras de latencia de toda la aplicación.
Fuentes y pruebas
Fecha de la fuente: · Fuente revisada:
Contenido editorial asistido por IA y contrastado con fuentes primarias. Las afirmaciones del proveedor se atribuyen; la inclusión no implica recomendación.