# 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: ```text 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](https://arxiv.org/abs/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](https://arxiv.org/abs/2501.12948) - [DeepSeek V4 technical report](https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf) ### 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](https://arxiv.org/abs/2305.18290) Tambien influyeron metodos posteriores mas simples o eficientes para preferencia, como: - [SimPO](https://arxiv.org/abs/2405.14734) - [ORPO](https://arxiv.org/abs/2403.07691) 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: ```text 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](https://arxiv.org/abs/2402.03300) - [DAPO](https://arxiv.org/abs/2503.14476) - [TRL GRPO Trainer](https://huggingface.co/docs/trl/en/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: ```text 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](https://www.kimi.com/blog/kimi-k2-6) - [Kimi K2.5 report](https://arxiv.org/pdf/2602.02276) - [Hugging Face Cookbook](https://huggingface.co/learn/cookbook/index) - [Smol Training Playbook](https://huggingface.co/spaces/HuggingFaceTB/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: ```text 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: ```bash 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: ```text 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: ```text 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.