Una carrera de relevos con GPUs alquiladas entrenó el MoE de 2.7B de NanoColibri por $200

Preentrenar un modelo de lenguaje desde cero normalmente implica un clúster, una factura de cómputo de seis cifras y personas pagadas para mantener la ejecución en marcha. La respuesta de un nuevo proyecto de código abierto es más corta. NanoColibri-Instruct, un modelo de Mezcla de Expertos (MoE) de 2.7B de parámetros con 0.34B de parámetros activos por token, pasó de pesos aleatorios a un modelo utilizable por entre $180 y $260, sin clúster, con contribuyentes turnándose en GPUs alquiladas una a la vez. El código, los checkpoints y un registro público de quién entrenó qué viven en el repositorio de entrenamiento.

El modelo nunca fue el objetivo final. El artículo presenta a Nano como la prueba del bucle para una idea más grande: modelos cuyos contenedores int4 son deliberadamente más grandes que la memoria de una máquina de consumo, transmitiendo expertos desde NVMe bajo un presupuesto fijo de RAM. Una laptop de 16 GB no puede contener un modelo de 24 a 28B en RAM. En un MoE de grano fino, cada token toca solo el backbone denso, un experto compartido siempre residente y un par de expertos enrutados de 3 a 4 MB. Almacena en caché a los expertos con un LRU y deja que el disco atienda los fallos. Nano ejercita todo el pipeline, incluida la exportación int4, a un precio donde los errores no duelen.

La arquitectura coincide con la forma nativa del motor de inferencia, HYV3: 24 capas (una densa, 23 MoE), ancho oculto 1024, 64 expertos de ancho 512 con enrutamiento top-2, un gran experto compartido de ancho 2048 que nunca abandona la memoria, atención de consulta agrupada 4x (grouped-query attention) con normalización QK por cabeza, y un enrutador de sigmoide más sesgo. El balanceo de carga sigue la receta de DeepSeek-V3: empuja el sesgo de experto de cada capa por gamma veces el signo de objetivo menos carga.

Entrenamiento por relevos: un compare-and-swap en el Hub

No puedes dividir el preentrenamiento secuencial entre voluntarios como divides un código base. Cada paso depende del anterior, así que la ejecución vive en un único repositorio de modelos de Hugging Face, pesos más estado del optimizador, training_state.json, RELAY.json, LEDGER.md, y los contribuyentes se turnan: reclamar, hacer pull, entrenar una etapa, hacer push, liberar.

La colisión es la parte que debe ser a prueba de fallos. Si dos personas entrenan la misma etapa, quien haga push en segundo lugar destruye silenciosamente un día de GPU. Así que el reclamo del testigo es un arrendamiento, un compare-and-swap real contra el Hub en lugar de una convención cortés, renovado por heartbeat mientras se entrena, lo que significa que una instancia spot interrumpida libera el testigo por sí sola. Un dashboard de solo lectura en la máquina de entrenamiento muestra loss, throughput, equilibrio de expertos y quién tiene el testigo.

Funcionó: 20,000 actualizaciones, aproximadamente 5.2B de tokens de FineWeb-Edu, luego 1,500 actualizaciones de SFT de chat en smol-smoltalk, unas 90 horas-H100 en total.

Hay un resultado que vale la pena robar: entrena con enrutamiento top-2 incluso si vas a servir con top-1. Con top_k=1 el peso enrutado colapsa a una constante y el enrutador recibe esencialmente gradiente cero del loss del LM, así que el enrutamiento permanece congelado en su inicialización aleatoria. top_k=2 restaura el flujo de gradiente mediante la competencia entre dos ganadores. Al momento de servir, el motor sigue ejecutando un experto por token. El balanceo libre de loss auxiliar se mantuvo a esta escala: la fracción de expertos muertos se mantuvo baja, la carga se mantuvo saludable, y la leve asimetría de enrutamiento que queda es lo que le gusta a un caché de streaming.

El desequilibrio de expertos es el mismo modo de fallo en el otro extremo del espectro MoE. Las notas de campo de Nous Research sobre el preentrenamiento de un modelo de un billón de parámetros describen el desafío central como enrutadores que envían tráfico desproporcionado a ciertos expertos, dejando algunas GPUs inactivas mientras otras hacen cola. Afrontar la versión de ese problema en NanoColibri costó unos pocos cientos de dólares.

Lo que compran 5.4B de tokens

Los números vienen con la metodología adjunta. Los benchmarks se ejecutaron con un harness dentro del repositorio, compatible con lm-evaluation-harness, las mismas prompts, la misma puntuación, y las referencias densas se ejecutaron con el mismo código en lugar de confiar en filas publicadas.

modelo	parámetros activos	tokens	lambada	piqa	wino	arc-e	arc-c	obqa	hswag
NanoColibri (chat)	341M	5.4B	26.3	62.7	49.2	43.4	22.8	22.0	31.1
Pythia-410M @ step3000	405M	6.3B	26.3	59.8	50.9	41.3	18.8	15.6	27.0
Cerebras-GPT-256M (final)	256M	5.1B	29.3	61.3	51.1	41.0	17.0	15.8	27.4

NanoColibri gana 5 de 7 contra ambos baselines, empata en LAMBADA contra Pythia y se mantiene dentro del ruido en WinoGrande (±1.4 con n=1267). Las salvedades son públicas. El checkpoint de Pythia está solo aproximadamente al 2% de su esquema de LR, lo cual lo pone en desventaja; la fila de Cerebras-GPT-256M completamente annealed es la comparación conservadora, y Nano también gana esa. El retraso en LAMBADA parece al menos en parte un artefacto de los datos: FineWeb-Edu no contiene esencialmente ficción, y LAMBADA está construido a partir de novelas.

La lectura del proyecto es mesurada: con este presupuesto, un MoE de 2.7B totales se comporta como un buen modelo denso de la clase de 300 a 600M, y el total de parámetros compra una ventaja real sobre dos baselines densos con la misma cantidad de tokens. La brecha con los números de la clase SmolLM2 es de tres órdenes de magnitud de datos, no de arquitectura.

Dos lecciones vergonzosas

La primera es la trampa de la caché de páginas. Para 'medir' el streaming, el equipo le dio al motor de inferencia presupuestos de RAM más pequeños que el contenedor en un servidor alquilado y obtuvo velocidades sospechosamente planas incluso con un presupuesto cinco veces menor que el contenedor. La RAM del servidor empequeñecía al contenedor de 1.2 GB, así que la caché de páginas del SO respaldaba silenciosamente cada fallo. Esas ejecuciones nunca tocaron el disco; caracterizaron la contabilidad de caché del motor. Los números reales de presión de disco necesitan cgroups con límite de memoria en hardware donde el límite se aplique y, admite el equipo, un contenedor más grande. Un bug de benchmark encontrado desde entonces en el harness de velocidad es la razón por la que el post no incluye afirmaciones de tokens/s. La disciplina de medición es más barata de aprender a $200.

La segunda es el coseno agotado. Un esquema de LR coseno fijado a un objetivo de pasos está agotado para cuando lo alcanzas, sin margen para seguir entrenando por inercia. Las ejecuciones sucesoras usan WSD, warmup-stable-decay: una fase estable larga que se adapta a las etapas del relevo y decae una sola vez, cuando el equipo lo decide.

Lo que sigue: un ensayo de 7B y luego un contenedor de 24 a 28B

La hoja de ruta en NEXT_MODEL.md tiene dos etapas. Colibri-Micro: 7B en total, 1B activos, 100B de tokens, una mezcla con mucho código, SFT y luego RLVR para código, y un contenedor realmente lo suficientemente grande, 3.8 GB en int4, para medir el streaming real desde disco en las laptops objetivo. Luego Colibri-Grande, 24 a 28B en total con unos 2.4B activos, cuyo contenedor sobresuscribe deliberadamente la memoria de una laptop de 16 GB. El conteo de expertos de Grande solo se congela una vez que existen las curvas medidas de fallos y velocidad de Micro. Todo se publica abierto: pesos, receta de datos, código de entrenamiento, protocolo de relevo, JSONs de benchmark, el registro.

Nano se pagó de bolsillo. La siguiente etapa necesita unos pocos miles de horas-H100, aproximadamente $9,000 a $12,000 a precios de mercado, y el autor está solicitando subvenciones de cómputo. La prueba del bucle de $200 está hecha. Las lecciones que dimensionó, la caché de páginas y el coseno agotado, son exactamente las que una ejecución de $9,000 no puede permitirse aprender de cero.