SmolLM3 - LLM pequeño, multilingüe y con razonamiento de contexto largo

• El modelo SmolLM3 es un LLM de código abierto que busca eficiencia y rendimiento al mismo tiempo en un tamaño de 3B parámetros
• Soporta 6 idiomas: inglés, francés, español, alemán, italiano y portugués, con soporte ampliado hasta una longitud de contexto máxima de 128k
• Con modo dual (reasoning/non-reasoning), permite cambiar el modo de razonamiento usando las banderas /think y /no_think
• Proporciona por completo las distintas etapas de entrenamiento de pretraining, mid-training y post-training, junto con los datasets publicados y los blueprints de ingeniería
• En rendimiento, supera a Llama-3.2-3B y Qwen2.5-3B, y mantiene competitividad a nivel de modelos de 4B

---

Resumen

SmolLM3 es un modelo de lenguaje grande de código abierto que busca eficiencia y rendimiento al mismo tiempo en la escala de 3B parámetros. Su mayor diferenciador es que, siendo pequeño y rápido, también soporta contexto largo, multilingüismo y razonamiento.

• Entrenado con 11 billones (11T) de tokens con 3B parámetros
• Logra rendimiento de última generación (SoTA), capaz de competir con modelos de 4B
• Modelo instruct de modo dual: soporta cambiar entre reasoning y non-reasoning mediante /think y /no_think
• Soporta inglés, francés, español, alemán, italiano y portugués
• Hasta 128k de contexto con NoPE y YaRN

Se publica completamente la arquitectura de todo el proceso de entrenamiento, la mezcla de datos y las recetas de cada etapa.

Pretraining

Arquitectura y configuración de entrenamiento

SmolLM3 está basado en un transformer decoder, y modifica la estructura de Llama para mejorar la eficiencia y el rendimiento en contextos largos.

• Grouped Query Attention (GQA): más eficiente en memoria que multi-head attention, manteniendo un rendimiento equivalente
• NoPE: elimina rotary position embedding cada 4 capas para mejorar el rendimiento en contextos largos
• Enmascaramiento dentro del documento: aplica máscaras para que documentos distintos no hagan attending entre sí, permitiendo un entrenamiento de long-context más estable
• Eliminación de weight decay en embedding: asegura un comportamiento de entrenamiento más estable

La configuración de entrenamiento es:

• Batch global de 2.36M tokens, longitud de secuencia de 4096, learning rate 2e-4, AdamW(β1:0.9, β2:0.95), weight decay 0.1, gradient clipping 1
• Scheduler WSD: 2000 warmup, con reducción lineal en el último 10%
• Entrenamiento distribuido con el framework nanotron, uso de datos de datatrove y la herramienta de evaluación lighteval
• 384 GPUs H100, 24 días de entrenamiento

Mezcla de datos y entrenamiento por etapas

Pretraining en 3 etapas:

• Etapa 1 (0T→8T): web (85%, 12% multilingüe), código (12%), matemáticas (3%)
• Etapa 2 (8T→10T): web (75%, 12% multilingüe), código (15%), matemáticas (10%) - se agregan datos de código y matemáticas de mayor calidad
• Etapa 3 (10T→11.1T): web (63%, 12% multilingüe), código (24%), matemáticas (13%) - upsampling de código y matemáticas de alta calidad, e introducción de datos de instruction/razonamiento

La proporción de mezcla de datos en cada etapa fue optimizada mediante numerosos experimentos de ablation.

Después del pretraining, se aplica además un proceso de mid-training para reforzar el rendimiento en long-context y reasoning.

Mid-training

Entrenamiento de long-context

Después del pretraining, se agregan 100B tokens adicionales para aumentar la longitud de contexto en 2 etapas (4k→32k→64k).

• Extensión de longitud mediante ajuste de RoPE theta
• Upsampling de datos de matemáticas, código y razonamiento
• Optimización del rendimiento en secuencias largas con NoPE y decay mixture
• Durante el entrenamiento llega hasta 64k, y con YaRN en inferencia puede procesar hasta 128k

Mid-training de reasoning

Para mejorar la capacidad de razonamiento, el modelo se reentrena con 35B tokens (OpenThoughts3-1.2M, Llama-Nemotron-Post-Training-Dataset, etc.).

• Aprende capacidad general de reasoning, sin estar orientado a dominios específicos
• Uso de plantilla ChatML y wrapped packing
• Se ejecutan 4 épocas (~140B tokens) y luego se guarda el checkpoint

Post-training

Mientras que la mayoría de los modelos de reasoning requerían procesos cerrados o complejos de RL, SmolLM3 implementa una estructura dual instruction (razonamiento/no razonamiento) con datos abiertos y recetas claras.

Plantilla de chat

• Inserta las banderas /think y /no_think en el prompt del sistema para cambiar el modo de reasoning
• Proporciona secciones separadas para XML Tools y Python Tools, con soporte para código y llamadas a herramientas
• Usa mensajes de sistema y metadata (date, knowledge cut-off, reasoning mode), con posibilidad de override flexible

Supervised Finetuning (SFT)

Tras el mid-training con 140B de datos de reasoning, se realiza supervised finetuning con 1.8B tokens (datos SFT: razonamiento lógico / no razonamiento).

• Para complementar dominios poco frecuentes de reasoning, se generan datos sintéticos de reasoning usando Qwen3-32B
• Máxima eficiencia de memoria y rendimiento con técnicas como best-fit decreasing packing
• Está previsto publicar todos los datos y scripts de entrenamiento

Anchored Preference Optimization (APO)

• Después de SFT, se alinea el modelo con APO, una variante de DPO, usando preferencias Tulu3 (non-reasoning) y pares sintéticos de preferencia de Qwen3-32B/0.6B (reasoning)
• La pérdida se construye con triplet prompt + response, logrando optimización estable y buen rendimiento
• Como se observó una caída del rendimiento long-context por el efecto del mid-training de reasoning, se superó mediante model merging

Model merging

• Uso de la librería MergeKit, con un merge lineal entre el checkpoint de APO modelsoup (0.9) y el checkpoint de mid-training (0.1)
• Recupera el rendimiento de long-context de 128k y mantiene el rendimiento general
• Se libera el modelo final usando el checkpoint óptimo

Evaluación

Modelo base

En 12 benchmarks principales, supera ampliamente a otros modelos de 3B y logra un rendimiento cercano al de modelos de 4B

• Fortalezas equilibradas en comprensión de documentos, razonamiento, matemáticas y coding
• Clara capacidad de extensión de longitud en pruebas como RULER 64k
• Capacidad multilingüe demostrada en Global MMLU, MLMM HellaSwag, Flores-200, Belebele, entre otros
• Rendimiento consistente también en 5 lenguas europeas además del inglés

Modelo Dual Instruct / Reasoning

Evaluación non-reasoning

SmolLM3 supera a Llama3.2-3B Instruct y Qwen2.5 3B Instruct, manteniendo un buen balance entre eficiencia y rendimiento al nivel de modelos de reasoning de 4B

Evaluación reasoning

Con /think activado, el rendimiento sube fuertemente en la mayoría de los benchmarks

• Incluso resuelve problemas difíciles como AIME 2025(36.7% vs 9.3%), LiveCodeBench(30.0% vs 15.2%) y GPQA Diamond(41.7% vs 35.7%)
• Razonamiento de 3B comparable con Qwen3 4B, razonamiento matemático y resolución de problemas complejos

Con el modo dual, se puede elegir entre velocidad y análisis profundo

Guía de uso real

SmolLM3 tiene soporte oficial en transformers v4.53.0 o superior

• Carga del modelo, escritura de prompts e inferencia con código sencillo
• El modo reasoning/non-reasoning se cambia con las banderas /think y /no_think en el prompt del sistema

Soporta los parámetros xml_tools, python_tools para llamadas a herramientas (Agentic)

Conclusión

SmolLM3 es un modelo fully open que soporta long-context, multilingüismo y reasoning en la escala de 3B.

• Publica completamente el blueprint de ingeniería, incluyendo recetas de entrenamiento por etapa, datasets y logs de entrenamiento
• Puede maximizar la participación de la comunidad en mejoras y validación

Materiales

• Modelo, scripts, datasets, etc.: HuggingFaceTB/SmolLM3-3B
• Para el paper, evaluaciones, herramientas de cuantización y merge, consultar los enlaces correspondientes en GitHub, Hugging Face y el paper

[GN⁺]

Opiniones en Hacker News

• Parece de esos raros modelos que logran la mayor parte del rendimiento SOTA con un tamaño de 3B, y además se suman con toda legitimidad al pequeño club de modelos realmente abiertos, con código y hasta receta de reproducción completa. Si alguien quisiera entrenarlo por su cuenta, probablemente necesitaría tiempo de GPU equivalente a alrededor de un millón de dólares (tomando como referencia 4000 GPU durante 24 días). También impresionó lo bien documentado que está; se percibe como una contribución sólida y positiva para la industria
  • En realidad serían 384 H100 corriendo durante 24 días, así que el costo ni siquiera llega a la mitad de un millón de dólares
  • Esta mañana hice una validación cruzada rápida, unos 10 minutos, con benchmarks de Phi-4-mini, y me pareció raro que este modelo no apareciera ahí; en general salía consistentemente por detrás. Para contexto, estoy desarrollando un cliente para LLM y mi objetivo principal es reducir al mínimo la brecha entre local y nube usando llama.cpp. Hoy por hoy, fuera de Microsoft casi no hay empresas que sigan tomándose en serio la IA local de forma sostenida. Normalmente no digo estas cosas, pero aunque HF sea realmente un gran ciudadano del ecosistema, destacar la superioridad de otros modelos sin mencionar a la superestrella termina ignorando el viejo SoTA local de este campo. Por eso esta vez quise decirlo abiertamente
• Este modelo es pequeño (3B) y muestra un rendimiento excelente en benchmarks. Encaja muy bien para despliegues en edge/móvil, así que ofrece ventajas claras frente a gemma3-4b. Soporta modo dual de razonamiento/no razonamiento, y además publica por completo toda la metodología de entrenamiento > Publicamos SmolLM3 junto con su plano de ingeniería. Incluye la arquitectura detallada, una estrategia de preentrenamiento en 3 etapas para elevar gradualmente el rendimiento por dominio y la metodología para construir un modelo híbrido de razonamiento. Conseguir este tipo de resultados normalmente requiere meses de ingeniería inversa, pero nosotros publicamos toda la metodología
• Yo mismo corregí el problema de la plantilla de chat para llama.cpp y otros motores de inferencia; para ejecutarlo, ingresen este comando ./llama.cpp/llama-cli -hf unsloth/SmolLM3-3B-GGUF:Q4_K_XL --jinja -ngl 99
• Su rendimiento casi alcanza al distill de Qwen3, pero el modelo solo tiene el 75% de ese tamaño; eso es tremendo. El modelo base de smollm ya era de muy buena calidad, así que lo he seguido usando también para fine-tuning, y planeo usarlo pronto para agentes locales o completado de código. El algoritmo de RL también se ve interesante. Hasta ahora había trabajado más con algoritmos de OpenAI, pero ya toca revisar el SOTA más reciente (de verdad, la velocidad a la que avanza esto es absurda y cuesta seguirle el ritmo)
• Me gustaría saber qué modelos pequeños recomiendan para hacer fine-tuning sobre distintos datasets empresariales. En nuestra unidad de negocio estamos buscando algo que pueda correr en navegador y móvil, y queremos resolverlo sin el dolor de cabeza de RAG y recursos en la nube
  • Los modelos pequeños son débiles para acumular conocimiento. No recomendaría mucho el enfoque de hacer fine-tuning para “inyectar” conocimiento. En su lugar, parece mejor implementar un sistema RAG embebido con despliegue offline en wasm; ya existen casos exitosos con ese enfoque
  • Lo importante es probar varios modelos uno mismo y tener benchmarks de verdad. ML no es mi especialidad, pero incluso haciendo fine-tuning con la guía y herramientas oficiales de Mistral 7B, los resultados no estuvieron a la altura de lo esperado. Metí preguntas muy específicas del dataset y, sin importar cómo variara el fine-tuning, no lograba responderlas bien. Más que esperar que “aprenda” la información, una mezcla de búsqueda vectorial + búsqueda por palabras clave funciona mucho mejor para extraer contexto. Usamos un enfoque de dataset de preentrenamiento, y quizá habría sido mejor sintetizar Q&A a partir de los datos para entrenar, pero no tuvimos tiempo de experimentar también con eso
  • Hice fine-tuning con Gemma 3N 2B y funciona bien, aunque en un S23U carga lento. Una vez levantado, corre bien. También probé SmolVLM 256M y 500M, que arrancan mucho más rápido y se pueden incluir como assets dentro de la app; con algo de experiencia sí son utilizables. Eso sí, los modelos pequeños tienen rendimiento limitado por la propia cantidad de parámetros. Además, en Android no se pueden distribuir archivos de más de 2GB por temas de compresión, así que el modelo se tiene que descargar aparte; y como no se puede cargar directamente desde la carpeta de descargas, hay que copiarlo a una carpeta propia de la app. Gemma 3N 2B pesa 3.14GB y requiere al menos 7GB de espacio libre
  • Me da curiosidad cuál sería exactamente el objetivo de hacer fine-tuning de esa manera
• Tiene algo de sketch de comedia británica: "¿Esto? ¿Dices que es pequeño pero también que es un modelo de lenguaje grande?" "Sí, de verdad es pequeño." "¿Pero cómo puede ser grande y pequeño a la vez?" "Bueno... es pequeño comparado con los modelos de lenguaje grandes." "Entonces sí es grande." "Sí, bastante grande." "¿Y grande comparado con qué?" "Con los modelos de lenguaje pequeños." "Entonces, ¿algo como ChatGPT qué sería? ¿Grande entre los grandes?" "Exacto. Un LLLM."
  • Me da vibra de comedia australiana, tipo Clarke and Dawe/Utopia
  • La vara cambia todo el tiempo. GPT-2 en su momento fue “grande”, pero ahora tiene la mitad del tamaño de este modelo. Y además Sam Altman decía entonces que ni GPT-2 se podía publicar por ser demasiado peligroso. Para mí, si no puede correr en un dispositivo de consumo, entonces es “grande”, y discutir la definición no aporta mucho
  • No pienso meterme con el hámster espacial gigante miniatura (chiste de los juegos de BG)
  • Ya no sé si es big little planet o small big planet
• Según entiendo, los modelos llama3 son relativamente fáciles de afinar (corríjanme si estoy equivocado o si aquí hay un modelo mejor). Me da curiosidad qué tan difícil es hacer fine-tuning de smollm3; los LLM MoE me parecen especialmente temperamentales en ese aspecto
• Lo interesante es que no aplicaron RL directamente, sino que hicieron fine-tuning solo con trazas de razonamiento sobre un dataset grande
  • En realidad usaron métodos offline como Anchored Preference Optimization; como ya se vio en el proyecto Open R1, aplicar RL multitarea a modelos pequeños no es nada sencillo. Los métodos offline hacen que la iteración sea mucho más rápida porque la clave está en curar/generar el dataset. Es un enfoque adecuado para la escala de modelos con la que estamos trabajando
• Gran trabajo; mis respetos para anton y todos los involucrados. Ojalá sigan saliendo modelos de 50~100M parámetros también. Creo que modelos que terminan rápido en CPU, como en los casos de prueba de Solve by LLM, siguen teniendo muchísimo valor