BLOG.md

ALIA-40B Distill Vapol: post-entrenamiento practico de un asistente multilingue en hardware local

Este documento resume el trabajo tecnico realizado para convertir BSC-LT/ALIA-40b-instruct-2601 en apol/alia-40b-distill-vapol: un modelo post-entrenado, empaquetado como Transformers BF16, adaptador PEFT y GGUF Q4_K_M, con mejoras medidas en tareas locales de asistente multilingue, formato estricto, JSON, uso de herramientas y RAG.

El objetivo no fue crear un nuevo modelo base ni competir con modelos frontier en conocimiento general. El objetivo fue mas practico: tomar ALIA-40B Instruct, mejorar su comportamiento de asistente en tareas concretas, hacerlo reproducible en la maquina local disponible, medir cada salto con evaluaciones retenidas y publicar un artefacto usable en Hugging Face.

Resumen ejecutivo

El punto de partida fue BSC-LT/ALIA-40b-instruct-2601, no el modelo base. La decision fue deliberada: para conseguir un asistente general util en menos iteraciones, es mejor empezar desde un checkpoint ya instruido y alineado que desde un modelo de completado sin chat tuning.

El resultado publicado incluye:

Artefacto	Uso principal
Modelo Transformers BF16 fusionado	Inferencia y evaluacion con transformers, accelerate, vLLM o runtimes compatibles.
Adaptador PEFT LoRA	Reproducir el delta de post-entrenamiento sobre BSC-LT/ALIA-40b-instruct-2601.
GGUF Q4_K_M en chunks de transporte	Uso local en llama.cpp y LM Studio tras reensamblar el GGUF unico.
Manifest de chunks	Tamanos, SHA256 por parte y SHA256 del GGUF reensamblado.
README/model card	Instrucciones de carga, resultados y limitaciones.

La mejora local mas importante se vio en el artefacto BF16/adaptador:

Comparacion local	Original ALIA Instruct	Distill Vapol	Cambio relativo
Filas pasadas en eval visible	21 / 80	33 / 80	+57.1%
Checks pasados en eval visible	386 / 519	446 / 519	+15.5%
Filas con validacion/reparacion de runtime	21 / 80	41 / 80	+95.2%
Checks con validacion/reparacion de runtime	386 / 519	458 / 519	+18.7%

Estas cifras no son MMLU, GPQA, GSM8K ni HumanEval. Son evaluaciones locales deterministas, disenadas para medir comportamiento de asistente: obediencia exacta a instrucciones, salida JSON, llamadas de herramienta, citas, restricciones de idioma, tareas administrativas, pequenas tareas de codigo y razonamiento acotado.

Hardware y entorno

El trabajo se hizo en una maquina local con:

Recurso	Estado usado
GPU	2 x NVIDIA RTX 5000 Ada, 32 GB VRAM cada una.
RAM / disco	Suficiente para staging de BF16, GGUF y datasets; el disco fue un factor operativo importante.
WSL	Ubuntu con CUDA visible y tooling de entrenamiento/evaluacion.
LM Studio	Usado para servir y evaluar el GGUF Q4_K_M.
vLLM	Disponible en WSL para servir/evaluar modelos cuando el formato y memoria lo permiten.
Hugging Face CLI	Usado para staging, subida de modelo, adaptador, README y GGUF.

La pila de entrenamiento/evaluacion disponible incluyo torch, transformers, peft, trl, bitsandbytes, accelerate, axolotl, datasets y vLLM.

Una restriccion importante: 40B parametros en dos GPUs de 32 GB no es un entorno comodo para full fine-tuning. La ruta realista fue QLoRA/LoRA, evaluaciones pequenas pero frecuentes, merge BF16 posterior y cuantizacion GGUF.

Por que ALIA Instruct y no ALIA Base

El modelo base BSC-LT/ALIA-40b es atractivo si se quiere control total sobre identidad, estilo y politica de alineamiento. Pero para conseguir rapidamente un asistente util, tiene costes altos:

• requiere mas SFT;
• requiere una capa de seguridad y preferencia desde cero;
• es mas facil terminar con un primer modelo poco usable;
• hace mas dificil comparar mejoras en comportamiento conversacional.

BSC-LT/ALIA-40b-instruct-2601 ya trae:

• chat template;
• obediencia basica a instrucciones;
• comportamiento conversacional;
• capacidades multilingues;
• una alineacion inicial.

Por eso el trabajo se centro en mejorar el checkpoint instruct. El modelo base sigue siendo una opcion para un experimento posterior si se demuestra una meseta clara de steerability.

Profesores y generacion de datos

La estrategia inicial contemplaba tres fuentes:

Fuente	Rol previsto
GPT-5.5/Codex	Orquestacion, generacion de datos, reparacion, diseno de evals, escritura de scripts y analisis.
DeepSeek V4 Flash local	Recurso local probado para diversidad, borradores y candidatos negativos cuando el servidor sea estable.
MiniMax M2.7 local	Recurso local probado como segundo modelo de contraste cuando el servidor sea estable.

En la ejecucion real, GPT-5.5/Codex fue la fuente fiable para generar artefactos, ejemplos, evals y reparaciones. Los modelos locales DeepSeek V4 Flash y MiniMax M2.7 estaban disponibles, pero las pruebas de carga/inferencia local no fueron suficientemente estables para convertirlos en generadores masivos reproducibles en esta ronda. Por eso se conservaron como recursos secundarios y como parte del plan de la siguiente ronda, no como fuente principal de datos gold ya publicados.

Esta decision importa: para post-entrenamiento no basta con "tener un modelo local". El teacher debe producir datos trazables, repetibles, validables y con coste operativo asumible. Si el servidor se queda en procesamiento indefinido o falla al cargar, el riesgo de contaminar el dataset o bloquear el pipeline es mayor que el beneficio.

Metodo de mejora

El trabajo uso una variante pragmatica de staged post-training:

1. Evaluacion base antes de generar datos grandes.
2. Construccion de ejemplos sinteticos y hard examples.
3. SFT QLoRA sobre tareas objetivo.
4. DPO sobre pares elegido/rechazado de alto impacto.
5. Evaluacion visible y hidden antes de promocionar.
6. Merge BF16.
7. Export GGUF Q4_K_M.
8. Subida a Hugging Face.
9. Rechazo explicito de ramas que mejoraban loss pero no mejoraban comportamiento retenido.

La parte mas importante no fue el volumen de datos. Fue el bucle:

modelo actual -> eval -> fallo concreto -> ejemplo corregido -> SFT/DPO pequeno -> eval hidden -> promocion o rechazo

Este bucle evito hacer bulk SFT a ciegas. Cuando una ronda posterior redujo loss pero empeoro los gates retenidos, se rechazo y se mantuvo el artefacto anterior como release.

Intervenciones principales

1. SFT QLoRA dirigido

La primera palanca fue QLoRA: entrenar adaptadores LoRA sobre el modelo instruct sin actualizar todo el modelo de 40B parametros. Esto permitio trabajar dentro de las restricciones de 2 x RTX 5000 Ada.

La idea se apoya en QLoRA: finetuning eficiente sobre pesos cuantizados con LoRA, descrito en arXiv:2305.14314, y en practicas de Hugging Face para bitsandbytes, FSDP/QLoRA y entrenamiento reproducible.

El SFT se enfoco en:

• salida estructurada;
• tareas administrativas en espanol;
• catalan, euskera y gallego;
• pequenas tareas de codigo;
• RAG y citas;
• instrucciones con restricciones exactas.

2. Distilacion activa de hard examples

En vez de generar ejemplos aleatorios, se generaron ejemplos donde el modelo fallaba:

• JSON sin campos obligatorios;
• null omitidos;
• llamadas a herramientas con argumentos incompletos;
• respuestas en idioma equivocado;
• citas no soportadas por el contexto;
• codigo que parecia correcto pero fallaba pequenos tests;
• respuestas demasiado genericas en tareas administrativas.

Esto sigue una leccion comun en sistemas recientes: gastar computo y teacher tokens donde el estudiante es debil. Las ideas se inspiraron en rejection sampling, distillation y staged post-training descritos en DeepSeek-R1 y la documentacion tecnica de DeepSeek V4:

• DeepSeek-R1
• DeepSeek V4 technical report

3. DPO con pares de alto margen

La segunda fase fue preference optimization. Se construyeron pares elegido/rechazado donde el rechazado representaba fallos reales del modelo o candidatos mas debiles, y el elegido era una respuesta corregida, validada o mejor alineada con la instruccion.

La base teorica principal fue DPO:

• Direct Preference Optimization, arXiv:2305.18290

Tambien influyeron metodos posteriores mas simples o eficientes para preferencia, como:

• SimPO
• ORPO

La decision practica fue no usar DPO masivo indiscriminado. El DPO se concentro en pares de alto impacto y con validadores claros.

Tambien hubo una restriccion de sistema: los caminos DPO estandar pueden ser caros en memoria para ALIA-40B por el modelo de referencia, el vocabulario grande y las secuencias largas. Cuando una ruta de entrenamiento no cabia de forma fiable, se prefirio reducir escala, trocear trabajo y mantener gates de evaluacion antes que forzar una ejecucion grande y opaca.

4. Validadores antes que jueces de modelo

Para tareas estructuradas, el criterio fue:

validador determinista primero, judge LLM despues si hace falta

Ejemplos:

• JSON parsea o no parsea;
• campos requeridos presentes o ausentes;
• tool call compatible con schema o no;
• cita existe en el documento fuente o no;
• respuesta esta en el idioma requerido o no;
• test de codigo pasa o falla.

Esta direccion esta alineada con RLVR/GRPO: usar recompensas verificables donde sea posible, en vez de pedir a un modelo juez que opine sobre todo.

Referencias utiles:

• DeepSeekMath
• DAPO
• TRL GRPO Trainer

En esta ronda no se hizo un entrenamiento RLVR/GRPO completo sobre ALIA-40B, ni se reprodujo una receta frontier de DeepSeek, Kimi o DAPO. Se aplico la filosofia de verificacion para construir datos, filtrar ejemplos y decidir promocion. El siguiente salto deberia usar RLVR/GRPO pequeno solo donde la recompensa sea fiable: JSON, tool calls, math verificable, SQL, extraccion y codigo con tests.

5. Tareas agenticas, herramientas y long-context

El entrenamiento no trato "tool use" como una frase bonita, sino como formato concreto:

usuario -> llamada de herramienta o respuesta sin herramienta -> resultado -> respuesta final

Se entrenaron y evaluaron patrones como:

• no llamar herramienta si faltan argumentos requeridos;
• pedir aclaracion si el usuario no da datos suficientes;
• devolver JSON estricto cuando se pide JSON;
• mantener idioma de salida;
• citar solo informacion soportada por contexto;
• producir respuestas finales cortas despues de un resultado de herramienta.

Las ideas estan alineadas con la direccion de modelos agenticos recientes, incluyendo Kimi K2/K2.5/K2.6, y con guias practicas de Hugging Face:

• Kimi K2.6 blog
• Kimi K2.5 report
• Hugging Face Cookbook
• Smol Training Playbook

Dataset y mezcla de tareas

El dataset no se diseno para mejorar todo por igual. La mezcla priorizo competencia practica:

Familia	Objetivo
Instrucciones exactas	Seguir restricciones explicitas y formato pedido.
Espanol administrativo/legal	Resumir, extraer obligaciones, contestar con estructura clara.
Catalan/euskera/gallego	Evitar deriva hacia ingles o espanol cuando se pide otra lengua.
JSON estructurado	Cumplir schemas, campos requeridos, null explicito.
Tool calls	Emitir llamadas validas o pedir aclaracion cuando falten datos.
RAG/citas	Usar solo contexto dado y citar soporte.
Codigo/debugging	Reparar bugs pequenos, explicar cambios y respetar tests.
Math/razonamiento acotado	Resolver tareas verificables, sin intentar aparentar mejoras generales no medidas.

La seguridad se mantuvo como guardrail de regresion, no como objetivo principal de optimizacion. El foco de esta ronda fue competencia y performance en tareas utiles.

Resultados locales

Evaluacion principal

Modelo / artefacto	Eval visible	Eval hidden	Comentario
BSC-LT/ALIA-40b base	no comparable	no ejecutada	Modelo raw completion, no chat-tuned.
BSC-LT/ALIA-40b-instruct-2601 original	21/80 filas, 386/519 checks	no ejecutada	Baseline local con validadores deterministicos.
Distill Vapol adaptador / BF16 fusionado	33/80 filas, 446/519 checks	14/20 filas, 108/116 checks	Mejor artefacto estatico medido.
Distill Vapol con validacion/reparacion de runtime	41/80 filas, 458/519 checks	no ejecutada	Mejor pipeline practico cuando se puede validar en runtime.
Distill Vapol GGUF Q4_K_M	16/80 filas, 388/519 checks	12/20 filas, 104/116 checks	Usable y portable; menor precision exacta por cuantizacion/runtime.

La lectura correcta:

• el modelo BF16/adaptador mejora de forma clara frente al instruct original en el benchmark local;
• el pipeline con validadores y reparacion mejora aun mas;
• el GGUF Q4_K_M es util para uso local, pero no debe tratarse como equivalente exacto al BF16 en tareas con validadores estrictos.

Smoke de benchmarks oficiales

Tambien se hizo un smoke generativo de multiple-choice a traves de LM Studio con muestras de familias presentes en evaluaciones oficiales de ALIA. Es una prueba de cableado y sanity check, no una reproduccion completa de leaderboard.

Tarea	Correctas	Accuracy
ARC Easy	4 / 5	0.80
ARC Challenge	4 / 5	0.80
OpenBookQA	5 / 5	1.00
HellaSwag	3 / 5	0.60
Total	16 / 20	0.80

No se ejecuto una campana completa de MMLU, GPQA, GSM8K, HumanEval, BBH, MT-Bench, XQuAD, FLORES o Belebele. Por eso cualquier estimacion de MMLU debe ser conservadora. Dado el tipo de datos usados, el movimiento esperado en MMLU general es pequeno: aproximadamente plano a +0-2 puntos, con ganancias mas visibles en comportamiento, formato y tareas objetivo.

Que mejoro de verdad

La mejora no debe describirse como "el modelo sabe mucho mas". El resultado correcto es:

1. Sigue mejor instrucciones estrictas.
2. Produce mejor JSON y formatos validables.
3. Maneja mejor patrones de tool-use.
4. Se comporta mejor en la mezcla multilingue objetivo.
5. Responde mejor en tareas donde se entrenaron hard examples.
6. Puede publicarse y usarse como BF16, adaptador o GGUF.

Esto es exactamente el tipo de mejora que suele producir post-entrenamiento bien dirigido: behavior shaping, formato, obediencia, robustez local y especializacion.

Que no mejoro lo suficiente

Los limites tambien son claros:

• El GGUF Q4_K_M baja en validadores exactos frente a BF16/adaptador.
• Codigo y math mejoran menos que JSON/tooling porque no se hizo RL verificable completo.
• RAG multilingue sigue teniendo fallos de idioma y soporte de cita.
• Algunas ramas posteriores redujeron loss pero empeoraron hidden eval; fueron rechazadas.
• Los modelos locales teacher no se integraron como generadores masivos reproducibles en esta ronda.
• No hay claim de benchmark academico completo.

Estos limites no invalidan el trabajo. Definen el siguiente salto.

Empaquetado y publicacion

El repo de Hugging Face contiene:

apol/alia-40b-distill-vapol
  config.json
  tokenizer files
  model.safetensors.index.json
  model-*.safetensors
  adapter/
  ALIA-40b-distill-vapol-Q4_K_M.gguf.part-000
  ...
  ALIA-40b-distill-vapol-Q4_K_M.gguf.part-045
  manifests/gguf_q4_k_m_raw512m_transport_manifest.json
  manifests/gguf_q4_k_m_raw512m_transport.sha256
  README.md
  BLOG.md

El GGUF unico existe como artefacto local/source, pero fue problematico de subir como fichero grande. El workaround robusto fue publicarlo como 46 chunks binarios de transporte de 512M y subirlos uno por uno por LFS clasico. Esto no cambia el modelo; cambia la forma de transporte. Los chunks se concatenan para recuperar el GGUF Q4_K_M exacto.

Para llama.cpp-compatible runtimes, primero hay que reensamblar:

cat ALIA-40b-distill-vapol-Q4_K_M.gguf.part-* > ALIA-40b-distill-vapol-Q4_K_M.gguf
sha256sum ALIA-40b-distill-vapol-Q4_K_M.gguf

El SHA256 esperado del GGUF reensamblado es 45f75478c721cf26617dc10f89bbfc663f5946a3779ddd19982bb7787790d285.

Lecciones tecnicas

1. Eval primero, data despues

Sin evaluacion base, la generacion sintetica escala ruido. La regla usada fue:

no bulk generation hasta tener eval y validadores

Esto evito gastar computo en datos que solo mejoran estilo.

2. Hidden eval manda

Una rama que mejora loss o incluso algun score visible no debe promocionarse si cae en hidden eval. Esto paso, y se rechazo la rama.

La decision correcta fue mantener el mejor artefacto medido, no el ultimo artefacto entrenado.

3. DPO puede ayudar o empeorar

DPO no es magia. Si los pares no son buenos o el objetivo es demasiado mixto, puede empeorar comportamiento retenido. La siguiente ronda debe usar DPO mas estrecho:

• no-tool vs tool-call invalido;
• JSON exacto vs JSON incompleto;
• cita soportada vs cita inventada;
• patch que pasa tests vs patch que falla tests.

4. Los teachers locales necesitan smoke tests duros

DeepSeek V4 Flash y MiniMax M2.7 son recursos interesantes, pero para usarlos como teachers hay que demostrar antes:

• carga estable;
• latencia estable;
• salida reproducible;
• compatibilidad de chat template;
• capacidad de batch;
• trazabilidad de prompt/model/date/hash.

Hasta que eso este estable, GPT-5.5/Codex es mejor como generador principal.

5. Cuantizacion requiere eval separada

El GGUF Q4_K_M es el artefacto mas comodo para uso local, pero no hay que asumir que conserva todos los comportamientos exactos del BF16. Se evaluo aparte y se reporto aparte.

Plan del siguiente salto

El siguiente salto no deberia ser "mas datos". Deberia ser una ronda estrecha de competencia verificable:

Area	Accion
JSON estricto	Generar ejemplos con campos requeridos, null, listas vacias, schemas anidados y validacion automatica.
Tool-use	Pares DPO donde el elegido pide aclaracion y el rechazado llama herramienta con argumentos incompletos.
RAG multilingue	Validadores de idioma + citas exactas + penalizacion de informacion no soportada.
Codigo	Tareas pequenas con tests ejecutables; entrenar solo sobre soluciones que pasan.
Math	Problemas con respuesta verificable y formato estricto.
RLVR/GRPO	Aplicar solo a JSON/tool/math/code, donde la recompensa sea objetiva.
GGUF	Ajustar prompts/chat template y repetir eval para reducir perdida de runtime.

La arquitectura de la proxima ronda:

fallos del modelo actual
  -> generacion/correccion GPT-5.5-Codex
  -> candidatos DeepSeek/MiniMax si el servidor local es estable
  -> validadores deterministicos
  -> SFT repair set pequeno
  -> DPO/SimPO-style contrastivo
  -> RLVR/GRPO en tareas verificables
  -> hidden eval
  -> merge y GGUF solo si supera al release actual

Conclusion

apol/alia-40b-distill-vapol es una mejora practica de ALIA-40B Instruct, no un nuevo frontier model. Su valor esta en el post-entrenamiento dirigido:

• mejor obediencia a instrucciones;
• mejor formato validable;
• mejor comportamiento multilingue objetivo;
• mejor packaging local;
• decision disciplinada de promocionar solo lo que supera gates retenidos.

El resultado mas fuerte es el BF16/adaptador. El GGUF Q4_K_M es el artefacto portable. El siguiente gran salto requiere menos entrenamiento generico y mas entrenamiento verificable: hard examples, DPO de alto margen y RLVR/GRPO limitado a tareas con recompensas objetivas.