Construyen un clúster de almacenamiento para preentrenamiento con discos duros de 30 petabytes

• Para el preentrenamiento de modelos para resolver problemas de uso de computadoras, avanzaron con la construcción directa de un clúster de almacenamiento en el centro de San Francisco con el objetivo de guardar datos de video por 90 millones de horas
• Eligieron un enfoque on-premises, con el que pueden operar una infraestructura de 30 PB por $354k al año (500 millones de wones). En AWS costaría $12m (17 mil millones de wones), por lo que reducen el costo en unas 34 veces
• A diferencia de la mayoría de las nubes públicas, no priorizan la alta disponibilidad ni la integridad, y aplican una estrategia de tolerancia a la pérdida de datos acorde con la naturaleza de los datos de entrenamiento
• Lo operan con software simple basado en Rust y Nginx y, en lugar de sistemas complejos como Ceph o MinIO, lo administran con un programa propio de 200 líneas
• Durante el proyecto pasaron por varios aprendizajes prácticos y prueba y error, incluyendo distribución física, configuración de red y gestión de cableado

---

Introducción y contexto

• El preentrenamiento de modelos para uso de computadoras requiere grandes volúmenes de datos de video
• Mientras que un LLM de texto típico (por ejemplo, LLaMa-405B) puede bastarse con unos 60 TB de datos, el entrenamiento basado en video requiere 500 veces más almacenamiento
• Usar una nube pública como AWS costaría 12 millones de dólares al año, pero al alquilar un centro de colocation y construir la infraestructura por cuenta propia pudieron reducirlo drásticamente a unos 354 mil dólares
• Al conservar internamente datos de gran volumen, resolvieron un problema en el que el costo de los datos era la principal limitación

Por qué lo construyeron por su cuenta

• La nube se enfoca en alta confiabilidad, redundancia e integridad de datos, pero los datos para preentrenamiento no son tan críticos como para no poder tolerar una pérdida del 5%
• Gracias a esta característica, pudieron elegir requisitos de confiabilidad mucho más flexibles que los de una empresa típica (aplicando 2 nueves en lugar de 13 nueves)
• El precio del almacenamiento está fijado muy por encima de su costo real
• Como los datos eran el mayor componente de costo, concluyeron que montar un datacenter local era más conveniente dentro de un rango suficientemente predecible

Comparación de costos: nube vs. construcción propia

• Costo recurrente mensual: internet $7,500 + electricidad $10,000 = total $17,500
• Costos únicos: discos duros $300,000, chasis $35,000, nodos de CPU $6,000, instalación $38,500, mano de obra $27,000, red y otros costos de instalación $20,000 → total $426,500
• Calculado con un costo fijo mensual de $29,500 incluyendo depreciación (3 años)
• AWS $1,130,000 al mes, Cloudflare R2 $270,000 al mes, construcción propia $29,500 al mes
  • AWS: unos 38 dólares por TB/mes
  • Cloudflare: unos 10 dólares por TB/mes
  • Construcción propia: 1 dólar por TB/mes
• En entrenamiento de modelos a gran escala, incluso Cloudflare tuvo problemas de rate limit por alta carga interna, pero en su propio entorno resolvieron esto con una línea dedicada de 100Gbps

Construcción y proceso

• Para acelerar la implementación, planearon Storage Stacking Saturday(S3), con ayuda de conocidos y contratistas profesionales
• En 36 horas montaron 2,400 discos duros en racks y completaron el hardware de 30 PB
• El software es Rust (para escritura, 200 líneas) + nginx (para lectura) + SQLite (seguimiento de metadatos)
  • No usaron Ceph, MinIO, Weka, Vast, etc. por problemas de complejidad/costo (complejidad, falta de necesidad, carga de mantenimiento, etc.)
  • Todos los discos fueron formateados con XFS

Retroalimentación y lecciones del proyecto

Qué salió bien

• Aplicaron adecuadamente el trade-off entre redundancia y rendimiento, aprovechando casi al máximo la red de 100G
• Al construirlo en un lugar físicamente cercano, aseguraron facilidad para depuración y mantenimiento
• Encontraron proveedores en eBay, pero las compras reales las hicieron directamente con proveedores individuales, enfatizando la importancia de la garantía
• La línea de internet de 100G tuvo muchas ventajas y también facilitó depurar por cuenta propia los problemas de red
• Una gestión de cableado de alta calidad ayudó mucho a resolver problemas después
• Aplicaron el principio de simplicidad en lugar de usar sistemas de almacenamiento open source complejos, minimizando la carga de mantenimiento
• También estimaron con precisión el costo de tiempo y mano de obra, y confirmaron claramente el ahorro

Dificultades y prueba y error

• El uso de front loaders volvió engorroso instalar manualmente uno por uno los 2,400 HDD
• Faltó densidad de almacenamiento; con una densidad mayor en el diseño inicial habría sido posible reducir trabajo
• El daisy chain genera cuellos de botella de velocidad; lo ideal es conectar un HBA dedicado a cada chasis
• En componentes de red importa la compatibilidad entre marcas, especialmente en transceptores ópticos
• La experimentación y configuración de red tomó tiempo; en vez de DHCP/NAT, armaron la infraestructura con foco en rendimiento y conveniencia (aplicando solo requisitos mínimos de firewall/secure link)
• Tomaron conciencia de la importancia del acceso físico y del cableado para monitor/teclado durante la instalación

Ideas que vale la pena probar

• Mejorar la eficiencia de administración remota con KVM e IPMI
• Se recomienda una red Ethernet separada para administración
• Vale la pena considerar sobreaprovisionamiento de red (por ejemplo, una red interna de 400G)
• Con servidores de mayor densidad (Supermicro de 90 discos / HDD de 20TB, etc.)
  sería ventajoso reducir cantidad de racks, consumo eléctrico y consolidar CPU

Cómo se puede construir por cuenta propia

Configuración de almacenamiento

• 10 nodos principales de CPU (Intel RR2000, etc.; se recomienda dual Intel Gold 6148/128GB ECC DDR4 RAM por servidor)
  • Las funciones con alta carga de CPU (como ZFS) podrían requerir equipos más potentes
• 100 chasis DS4246 (cada uno con 24 HDD)
• 2,400 HDD de 3.5" (si es posible, se recomiendan discos SAS por ventaja de velocidad)
  • Combinación de distintas capacidades (12TB, 14TB, etc.); mientras mayor la capacidad, mejor para distribución y valor de reventa
• Rieles/brackets para montaje físico, cableado de equipos y cables
• Varios crash carts (monitor + teclado) para depurar problemas de red

Infraestructura de red

• Switches 100GbE (Arista de segunda mano, etc., con puertos QSFP28)
• HBA por servidor (recomendado: Broadcom 9305-16E, etc.), y método de conexión entre puertos HBA/chasis
• Tarjetas de red (Mellanox ConnectX-4, etc., obligatoriamente en modo Ethernet)
• Cables DAC/AOC — si se considera la distancia entre racks, DAC tiene ventajas de compatibilidad
• Se recomienda usar proveedores que entreguen los nodos principales de CPU con HBA/NIC preinstalados
• Cables seriales, y una red separada de Ethernet de administración (como alternativa, adaptador inalámbrico de respaldo + mini switch)

Requisitos del datacenter

• 3.5kW de consumo por gabinete, asumiendo una configuración de 4U×10 + 2U×1 sobre una base de 42U
• 3PB por gabinete, más 1 gabinete 42U adicional para switches o reemplazo por un chasis de 1U
• Cross-connect dedicado de 100G (normalmente un par óptico QSFP28 LR4), con verificación previa obligatoria de compatibilidad de form factor y marca
• Se recomienda una ubicación cercana a la oficina (colocation) porque permite una respuesta física rápida cuando hay problemas y optimiza la productividad de depuración y operación

Consejos de configuración inicial

• Tras la configuración inicial del switch por consola local, conviene validar primero la configuración del puerto uplink 100GbE y la compatibilidad del transceptor óptico
  • Si hace falta, se puede conectar directamente la fibra del ISP al NIC para comprobar el link-up y luego moverlo al switch
• Durante la instalación de Ubuntu, es más práctico terminar la configuración de red de los nodos con Netplan
• Una vez que los nodos tengan conexión a internet, conviene seguir el flujo conectar 1 cable a cada DS4246 → formatear/montar → revisar estado para detectar temprano fallas de cableado o de discos

Consideraciones de rendimiento, estabilidad y seguridad

• Bajo la premisa de seguridad de que es solo para datos de entrenamiento, operan de forma simplificada con IP pública directa + firewall por puertos + nginx secure_link
  • Si se manejan datos de clientes, la misma configuración es inadecuada, y se vuelven imprescindibles DHCP/NAT/firewalls segmentados
• El daisy chain simplifica la administración y el cableado, pero provoca cuellos de botella de ancho de banda; si es posible, se recomienda un HBA dedicado por chasis
• Los transceptores ópticos tienen un fuerte lock-in por marca; conviene abastecerse tanto en FS.com como en Amazon, verificando cuidadosamente la coincidencia de especificaciones y marca

Conclusión y significado

• Con un almacenamiento propio ultrabarato a nivel de $1/TB-mes, hicieron viable el preentrenamiento en video de 30PB y lograron una reducción de costos de 10 a 38 veces frente a la nube
• La arquitectura simple y la accesibilidad física redujeron tiempo y riesgo, y la línea dedicada de 100G eliminó los cuellos de botella de I/O
• En la era de los grandes modelos multimodales y de video, la infraestructura de datos de gran volumen y bajo costo es una ventaja competitiva clave, y este enfoque ofrece una referencia práctica que puede implementarse incluso con equipos pequeños

Cierre y colaboración

• Si alguien construyó un clúster de almacenamiento similar tomando este artículo como referencia, esperan que comparta mejoras y experiencias
• Están contratando personal de investigación para preentrenamiento de modelos de uso de computadoras a gran escala y para investigación en IA relacionada con generalización y valores humanos (contacto: [e-mail])

[GN⁺]

Comentarios de Hacker News

• Cuando empecé mi carrera, lo normal era trabajar on-premise; el hardware duradero termina recibiendo mucho cuidado y cada servidor va acumulando estado. Con el tiempo, cuando el rendimiento del hardware se queda corto, hay que elegir nuevo hardware de una lista existente a través del equipo interno y además conseguir aprobación de costos adicionales, así que es engorroso. A veces los proyectos también se retrasan durante el proceso de reemplazar hardware o de separar por completo equipos que uno ha cuidado como si fueran mascotas para migrar a equipos nuevos. Cuando apareció la nube, pasé a pensar “ahora sí, todo debe irse a la nube”. Pero con el tiempo, uno y la organización olvidan cómo gestionar hardware directamente, y al final, si no se recupera esa capacidad, la nube, que había sido una buena opción, se vuelve cada vez menos atractiva. Así que gracias por ayudar a volver a desarrollar esas habilidades.

  • Nosotros estamos en una situación algo particular. Desde el inicio no podíamos costear el gasto operativo de una nube hiperescalar, así que no nos quedó de otra más que desarrollar capacidad propia. No ha resultado tan difícil como pensábamos y por un tiempo seguiremos así. Eso sí, ya se empieza a notar el problema de la acumulación de estado que mencionabas.

  • En mi recuerdo, on-premise siempre fue más barato. Se eliminaban varios obstáculos logísticos y además todo se simplificaba con una sola factura. Cuando la nube estaba en auge, el consejo siempre era usar on-premise y recurrir a la nube solo cuando el tráfico subiera o bajara bruscamente. Pero ese uso temporal para escalar se fue convirtiendo poco a poco en uso permanente, y los desarrolladores terminaron dependiendo de poder levantar máquinas nuevas al instante. Ahora todos consideran la nube como el estado por defecto. En ese proceso perdimos la base para percibir bien el costo real, y la brecha de costos entre nube y on-premise se ha ido ampliando cada vez más.

  • Docker es una herramienta excelente para hacer que los servidores dejen de ser mascotas. Un servidor en el rack pasa a tratarse simplemente como otro nodo de K3 o K8, así que deja de manejarse como algo especial. Eso me encanta. Se podría decir algo parecido de las VM, pero al final la propia VM se convierte en la mascota. Claro, puedes crear imágenes o snapshots, pero no se siente igual al cambio que trae Docker.

  • Una pregunta en tono de broma: ¿te animarías a intentarlo otra vez?

• Una startup que tiene tanto dinero como para comprar sin problema un dominio de dos letras en .inc tiene demasiado financiamiento. Es el mismo fenómeno que antes se veía contando cuántas sillas Aeron había en la oficina de una startup. No es una buena señal.

  • Los dominios .inc de dos letras que no están en uso se venden por $2300 al año. Eso no llega ni al 5% del costo de un desarrollador.

  • Tengo mis dudas de que un nombre de dominio .inc tenga valor real.

• Qué artículo tan entretenido. Me dio cierta satisfacción vicaria mientras lo leía. Para disfrutar más este tipo de experiencia, me gustaría que hubiera más fotos.

  • Si los autores llegan a comentar, me gustaría preguntar directamente qué hace Standard Intelligence PBC: si significa Public Benefit Corporation o qué clase de proyectos están haciendo.

• Me gustó que explicaran el contenido técnico con tanto detalle. Pero tengo curiosidad por saber cómo fue el proceso para conseguir espacio de colocación, si usaron un broker y cuánto difirió el precio final del primer presupuesto tras negociar.

  • Pedimos cotizaciones a la mayoría de los proveedores de colocación en San Francisco y Fremont. No hubo diferencia entre la cotización y el precio que terminamos pagando, aunque sí negociamos las condiciones y algunos cargos únicos.

• El post del blog de Discord que enlazaron también está interesante. En general es serio, pero tenía partes divertidas como esta: cuando caía un gol en el Mundial, ese dato se reflejaba de inmediato en las gráficas de monitoreo, así que los miembros del equipo podían justificar que estaban viendo fútbol durante una reunión como si fuera monitoreo de trabajo. También se citó como base para el uso real del sistema, o para afirmar que Discord guarda mensajes en un almacenamiento “por debajo del petabyte”. Supongo que, calculando con el tamaño y la cantidad de nodos de este artículo, el clúster anterior daba unos 708 TB y la nueva configuración unos 648 TB, incluyendo margen de crecimiento.

• El almacenamiento en sí es muy barato. Pero no entiendo la parte del entrenamiento y la configuración de red. En otros comentarios leí que los GPU no están en un solo lugar; si es así, entonces tendrían que intercambiar datos de entrenamiento entre varios sitios usando solo 100Gbps. Me preocupa que eso termine siendo un cuello de botella durante el preentrenamiento.

  • Por ahora solo tenemos un enlace de 100 gigas, y de todos modos los clústeres de GPU también solo pueden manejar más o menos ese nivel de transferencia de datos. Planeamos aumentar tanto el ancho de banda como el almacenamiento a medida que escalemos. Como referencia, también tenemos varias 4090 dentro del colo, y fueron increíblemente útiles para tareas como particionado de datos o generación de embeddings.

• Para una carga de trabajo de este tamaño, en AWS u otras nubes también podrías conseguir cotizaciones privadas sin problema. En el caso de S3, con apenas 0.5 PB ya puedes obtener una cotización aparte. Eso no significa necesariamente que el costo total sea menor que gestionarlo por cuenta propia, pero comparar los precios retail de un CSP contra equipo comprado en eBay más mano de obra gratis —salvo el costo de la pizza— no es una comparación del todo justa.

  • En AWS o en la nube, el costo de egress es realmente la clave. Incluso cuando intentas negociarlo, no ceden nada en absoluto. Para entrenamiento de IA está prácticamente fuera de consideración. La cotización de Cloudflare es de las más baratas entre los almacenamientos de buckets de objetos administrados. Al construir nuestro propio clúster, la diferencia frente a un servicio administrado se redujo bastante; además, tener infraestructura propia también te da poder de negociación. Aun así, un bucket administrado es excesivamente sobredimensionado para algo tan simple como almacenamiento para preentrenamiento. Glacier tiene buena relación costo-beneficio como archivo, pero todavía no existe un producto que encaje perfectamente para uso de ML.

  • Me interesa saber qué tipo de acuerdo concreto se puede conseguir. ¿Es posible obtener descuentos de más de la mitad?

• Me divertí ayudando a montar las unidades. Trabajar con volúmenes reales de datos tan grandes es de las experiencias más emocionantes que hay :P

• No se menciona la tasa de fallas de los discos. Me pregunto cómo estará la situación después de algunos meses.

  • Esto viene de una experiencia anterior: cuando montamos varios arreglos de discos, tuvimos una ola de fallas masivas. Instalamos el rack un viernes por la tarde, lo dejamos sin tocar durante el fin de semana y ejecutamos pruebas simples de lectura/escritura con un shell script. Cuando volvimos el lunes, casi la mitad de los discos había muerto sin dejar ningún log. No había forma de saber si fue un problema en el proceso de striping o si reventaron durante la prueba de estrés. Resultó ser un lote defectuoso de fábrica, y varios clientes de la misma empresa también se quejaron. El fabricante reemplazó todo y lo único que se retrasó fue la entrada a producción. Después de eso no hubo ninguna falla en un año.

  • En comparación con hace 10 años, la tasa de fallas de discos ha bajado muchísimo. Antes llegábamos a reemplazar más de 10 por semana, pero ahora es algo raro. Creo que basta con revisar las estadísticas de discos duros de Backblaze.

  • Decían que ese clúster usa unidades enterprise, pero por ahorrar costos uno puede terminar perdiendo mucho más después. En lo personal, probé discos usados para un servidor casero y la variación de rendimiento era tan grande que no me convenció.

  • Buen punto.