Entrenar LLMs desde cero como startup
Entrenar modelos de lenguaje grandes desde cero a escala de startup plantea preguntas difíciles sobre infraestructura, fiabilidad del hardware y elección de frameworks, especialmente en contraste con los sistemas TPU y herramientas internas de Google, estrechamente integrados. Los comentaristas debaten si usar GPUs, JAX o PyTorch cambia de forma significativa la fiabilidad y la velocidad de iteración, y cuánto del progreso actual depende de experiencia de élite, enorme capital y canalizaciones de datos opacas. Muchos ven un panorama en el que numerosos equipos bien financiados duplican modelos cercanos al estado del arte con diferenciación modesta —mediante alineación, calidad de datos o productos de nicho— mientras los inversores luchan por distinguir el valor duradero del hype.
Contexto y panorama general
- El hilo analiza una entrada de blog sobre entrenar LLMs de vanguardia desde cero en una startup tras dejar una gran empresa tecnológica.
- A los comentaristas les interesa el contraste de “estar en la intemperie”: hacer trabajo de grandes LLMs sin la infraestructura interna de un hyperscaler ni TPUs.
Frameworks, hardware y fiabilidad
- Debate sobre JAX vs PyTorch:
- Algunos ven JAX como bueno para investigación y optimización en TPU; otros dicen que PyTorch es mejor para prototipado rápido y ecosistema.
- TensorFlow es ampliamente considerado rezagado o “heredado”.
- Experiencias mixtas con la fiabilidad de GPU vs TPU:
- Algunos informan fallos frecuentes de TPU y depuración dolorosa; otros reportan experiencias sólidas con JAX+TPU.
- Las anécdotas sobre la fiabilidad de GPU divergen: configuraciones pequeñas con T4 se ven como a prueba de balas, mientras que clústeres grandes de A100/H100 se describen como propensos a fallos.
- Una visión: las diferencias de fiabilidad pueden deberse más a la madurez del centro de datos y a la gestión del hardware que a los chips en sí.
Google frente a código e infraestructura no Google
- Varios describen el código interno de Google como de alta calidad, muy estandarizado y respaldado por tooling y CI sólidos.
- Compromiso: mejor mantenibilidad pero menor velocidad y una infraestructura de ML/LLM compleja y frágil, difícil de aprender y depurar.
- Algunos exinsiders recientes afirman que la infraestructura de LLM de Google, en particular, es confusa y lenta para iterar en comparación con otros laboratorios.
Economía y redundancia de las startups de LLM
- Muchos ven las startups que entrenan modelos base como trabajo muy similar con hardware y datos similares, creando una redundancia masiva y muy intensiva en energía.
- Visión escéptica: muchas no tienen gran “salsa secreta” y principalmente buscan demostrar que pueden entrenar modelos cercanos al estado del arte, con la esperanza de ser adquiridas.
- Otros argumentan que esta redundancia es cómo los mercados impulsan la innovación, a pesar del enorme desperdicio.
- Hay consenso en que recaudar dinero para este tipo de startups es más fácil para personas con trayectorias y redes de élite, creando un foso basado en el pedigrí.
Alineación, censura y comportamiento del modelo
- Discusión sobre qué diferencia a los modelos: datos, fine-tuning, alineación/censura.
- Una definición de alineación: hacer que los modelos sigan patrones de interacción deseados (por ejemplo, comportamiento de preguntas y respuestas), no solo la continuación cruda de tokens.
- El uso más nuevo se centra en restricciones morales/políticas y en evitar salidas “vergonzosas”.
- Algunos ven esto como control de producto necesario y práctica para seguridad de mayor riesgo; otros lo ven como un “campo de distorsión de la realidad” y potencialmente orwelliano.
Calidad del producto y diferenciación
- El producto de chat público de la startup se parece a una interfaz típica estilo ChatGPT, con precios comparables a los de modelos cerrados de gama media.
- La comparación informal de un comentarista entre varios modelos importantes sitúa al modelo de la startup aproximadamente al mismo nivel de calidad, sin ser claramente mejor ni peor.
- Se cuestiona el presupuesto exacto de cómputo necesario para alcanzar un rendimiento similar al de GPT‑3.5; se especula con magnitudes de millones de dólares, pero no se responde.
Datos de entrenamiento y preocupaciones GIGO
- Varias personas quieren más detalle sobre las canalizaciones de datos de entrenamiento, etiquetado y curación; la entrada del blog se considera escasa en eso.
- Una perspectiva enfatiza “garbage in, garbage out”: la calidad y la estructura de los datos son cruciales, especialmente en dominios como la detección de malware o la medicina.
- Se sugiere que algunas startups pueden estar invirtiendo en silencio de forma intensa en datos curados y bien etiquetados como una verdadera diferenciación, aunque las historias sobre cómputo dominen los discursos a inversores.
Puntos operativos y misceláneos
- Los trabajos a gran escala deben tolerar fallos frecuentes de hardware; se entiende que el checkpointing y el software robusto son necesidades.
- Se observa que algunas configuraciones de carga de datos (por ejemplo, 20GB de JSON que tardan 6 horas) son muy subóptimas; se sugieren parsers más rápidos y enfoques de streaming.
- Debates menores cubren CLIs de nube basadas en Python, runtimes empaquetados, tamaño binario y si “ground zero” es el modismo correcto en el título.