¿Y si pudieras adaptar ALIA a tu dominio — no solo desplegarla — en una caja de 4.000 €?

En enero de 2025 escribimos sobre ALIA, el modelo de lenguaje multilingüe del Gobierno de España desarrollado por el Barcelona Supercomputing Center (BSC). Es un proyecto serio: 40.000 millones de parámetros, soporte nativo para castellano, catalán, euskera y gallego (que se traduce en un tokenizador casi 2× más eficiente que los modelos anglosajones — puedes comprobarlo en directo en nuestra demo), y entrenamiento en datos representativos de los idiomas y la cultura ibérica.

Pero entre "tener un modelo open source" y "poder personalizarlo de verdad para mi caso de uso" hay un abismo. Adaptar un modelo de 40B parámetros — su vocabulario interno, su tono, su conocimiento sobre tu dominio específico — históricamente ha requerido un cluster de servidores que la mayoría de organizaciones no tienen.

Hoy publicamos los resultados de un mes de trabajo: ALIA-40b-instruct-2601 cuantizado a NVFP4 (el formato nativo de las nuevas GPUs NVIDIA Blackwell). El modelo cabe ahora cómodamente en una NVIDIA DGX Spark — la nueva estación de desarrollo de IA del tamaño de un Mac mini, con 128 GB de memoria unificada — con espacio de sobra para hacer fine-tuning local con LoRA / QLoRA. Y como bonus, también sirve inferencia a ~10 tokens por segundo desde la misma caja.

El modelo y todo el código están disponibles ahora mismo en Hugging Face.

🎥 Demo en vídeo (5 min): — mostramos el modelo cuantizado cargándose, respondiendo en español a unos 10 tokens por segundo, y el espacio de memoria que queda libre para hacer fine-tuning.

¿Por qué importa esto?

ALIA es la pieza tecnológica más ambiciosa de la estrategia de IA pública española. El BSC y el Gobierno han invertido recursos significativos para que España tenga un LLM soberano: entrenado en datos europeos, con licencia abierta, y con calidad comparable a los modelos comerciales para los idiomas peninsulares.

Pero un modelo genérico — por bueno que sea — rara vez es lo que necesitas en producción. Lo que tu administración o tu empresa necesita es ALIA hablando tu idioma específico: la terminología jurídica del BOJA, el vocabulario sanitario de tu hospital, el corpus de incidencias de tu departamento de soporte, la jerga técnica de tu sector.

Eso requiere fine-tuning: tomar el modelo base y entrenarlo unas pocas épocas más sobre datos representativos de tu dominio. Y aquí es donde la mayoría de proyectos se atascan:

• Fine-tuning completo de un 40B en BF16: necesita ~400 GB de memoria GPU entre pesos, gradientes, estados del optimizador y activaciones. Hardware: ~80.000 € de servidor con 8× H100.
• Fine-tuning en la nube: te ahorra el hardware pero te obliga a enviar tus datos privados a un proveedor estadounidense, lo cual contradice la motivación de soberanía y de RGPD.
• Cuantizaciones agresivas a 3-4 bits genéricas (Q3/Q4): degradan especialmente la calidad para idiomas minoritarios — precisamente donde ALIA es más valiosa.

La consecuencia: muchas administraciones públicas, cooperativas y PYMEs españolas saben que ALIA existe, pero no encuentran un camino realista para personalizarla sobre su propia infraestructura.

NVIDIA DGX Spark + NVFP4: la oportunidad

NVIDIA lanzó la DGX Spark a principios de 2026 como su estación de desarrollo de IA compacta: un GPU GB10 (arquitectura Blackwell), 128 GB de memoria unificada, y un precio en torno a los 4.000 €. No está pensada para servir miles de usuarios concurrentes — para eso existen los servidores B100/H100. Está pensada para que un equipo de desarrollo de IA tenga, encima del escritorio, una caja donde:

• Hacer fine-tuning de modelos de hasta ~70B con técnicas eficientes (LoRA, QLoRA, SFT, DPO)
• Prototipar agentes y pipelines sin depender de APIs de pago
• Iterar sobre tus propios datos sin sacarlos de la organización
• Servir inferencia local para validar resultados o para despliegues piloto

La clave técnica que hace todo esto posible es NVFP4, el formato de coma flotante de 4 bits que NVIDIA introdujo con Blackwell. A diferencia de cuantizaciones anteriores, NVFP4 está diseñado a nivel de hardware: las GPUs Blackwell tienen tensor cores específicos que multiplican matrices NVFP4 a velocidades comparables a FP8, con un tercio del tamaño en memoria. Y crucialmente, mantiene una calidad mucho más cercana al BF16 original que las cuantizaciones genéricas Q3/Q4.

ALIA en NVFP4 ocupa ~27 GB, frente a los 76 GB del original. Eso significa que en una DGX Spark te quedan más de 90 GB libres — suficientes para hacer QLoRA fine-tuning con holgura: adaptadores LoRA + estados del optimizador Adam + activaciones + un contexto razonable, todo en la misma caja, sin tocar la nube.

En papel todo cuadraba. En la práctica, llegar hasta aquí requirió encontrar y arreglar un bug en llama.cpp que llevaba meses produciendo archivos corruptos en silencio para cualquier modelo de la familia Llama cuantizado a NVFP4. Los detalles técnicos están al final del artículo para quien le interese la cocina; primero, lo que esto significa para ti.

Lo que hemos publicado hoy

Tres artefactos abiertos, con licencia Apache 2.0 (la misma que ALIA original):

1. GGUF para llama.cpp y Ollama: montevive/ALIA-40b-instruct-2601-NVFP4-GGUF — 27 GB, listo para llama-cli o despliegue con Ollama. Útil principalmente para inferencia y validación rápida.

2. Safetensors para vLLM, TensorRT-LLM y fine-tuning: montevive/ALIA-40b-instruct-2601-NVFP4 — el mismo modelo en formato compressed-tensors, compatible con el ecosistema HuggingFace. Es la base sobre la que aplicar QLoRA o LoRA para personalizar ALIA a tu dominio (vía peft, axolotl, unsloth o trl).

3. El parche para llama.cpp: Pull Request #22611 — abierto y a la espera de revisión del equipo de mantenimiento. Una vez mergeado, cualquier futuro NVFP4 GGUF de un modelo Llama saldrá correcto sin necesidad de aplicar el parche manualmente.

4. Demo interactiva del tokenizador de ALIA: labs.montevive.ai/alia-tokenizer-comparison/ — comparador en directo entre el tokenizador de ALIA, Llama 3 y Mistral, ejecutándose 100 % en tu navegador. Pega cualquier texto y mira al instante por qué ALIA es ~1,7× más eficiente con las lenguas peninsulares. Lo contamos en detalle en este artículo dedicado.

Quién puede aprovechar esto hoy

Administración pública española

Una DGX Spark + ALIA permite a un ayuntamiento, diputación, consejería o agencia estatal:

• Adaptar ALIA a su corpus interno: jerga jurídica, expedientes históricos, normativa específica
• Entrenar versiones especializadas: una para atención ciudadana en lenguas cooficiales, otra para clasificación de subvenciones, otra para resumen de actas
• Validar resultados localmente antes de desplegar a producción
• Mantener todos los datos dentro de la organización durante todo el ciclo de desarrollo

Empresas con requisitos de soberanía o RGPD estricto

Sectores regulados (sanidad, banca, legal, defensa) que necesitan adaptar IA generativa a su dominio sin enviar datos a la nube. Coste de hardware: 4.000 € para el equipo, vs. 30.000-80.000 € para un servidor de fine-tuning con H100s, vs. 0 € fijo pero datos saliendo continuamente hacia OpenAI/Anthropic.

Cooperativas, PYMEs y startups

Equipos pequeños que quieren un asistente especializado en su producto, su soporte técnico, sus contratos. La DGX Spark se amortiza en pocos meses si tu carga de trabajo es continua y los datos son sensibles.

Investigadores y desarrolladores

Si trabajas con LLMs ibéricos, ALIA-40B en NVFP4 es probablemente el mejor punto de partida disponible en mayo de 2026 para experimentar con fine-tuning multilingüe sobre hardware razonable.

Por qué Montevive

Llevamos años trabajando en IA aplicada con foco en privacidad, soberanía y eficiencia. No vendemos hype ni modelos masivos en la nube: construimos las herramientas que faltan para que la IA realmente útil funcione en infraestructura propia.

Algunas piezas recientes:

• Privacy Filter local — detección de PII en el navegador, sin servidores
• Go Name Detector — librería Go open source para detección de nombres
• AutoCache — proxy inteligente que reduce hasta 90% el coste de APIs LLM

Esta cuantización de ALIA encaja en la misma línea: hacer accesible localmente lo que el mercado da por sentado que tiene que vivir en la nube.

¿Quieres adaptar ALIA a tu organización?

Si trabajas en una administración, empresa o cooperativa que quiere usar ALIA en serio — adaptada a tu dominio, integrada en tus sistemas, ejecutándose en tu infraestructura — te ayudamos a hacerlo:

• Fine-tuning de dominio: adaptamos ALIA a tu terminología (legal, sanitaria, técnica, sectorial) usando LoRA / QLoRA sobre DGX Spark o servidores Blackwell
• Consultoría de despliegue: evaluamos tu caso de uso, dimensionamos hardware, diseñamos la arquitectura de fine-tuning + inferencia
• Instalación y configuración: NVIDIA DGX Spark, servidores Blackwell, o infraestructura cloud privada
• Integración con tus sistemas: APIs, RAG sobre documentos internos, agentes especializados, evaluación continua

📧 Contáctanos: info@montevive.ai

🌐 Más información: montevive.ai

ALIA es de todos. Que esté a tu alcance — adaptable, ejecutable, soberana — es lo que estamos construyendo.

🔧 Para los técnicos: cómo lo hicimos

Si te interesa la parte de ingeniería de la historia — qué bug encontramos, cómo lo diagnosticamos, qué números prueban que el parche funciona, y qué rendimiento de inferencia mide nuestra DGX Spark — sigue leyendo. Si no, gracias por llegar hasta aquí.

El bug: cuando la cuantización produce palabras al azar

Aplicamos el flujo estándar para producir el GGUF (el formato de archivo de llama.cpp):

1. Cuantizar el modelo BF16 a NVFP4 con NVIDIA ModelOpt
2. Convertir el resultado a GGUF con convert_hf_to_gguf.py
3. Ejecutar con llama-cli sobre la DGX Spark

Resultado: Certainlyrics|assistant|assistant|... Para la frase "The capital of France is", el modelo respondía con tokens al azar entremezclados con marcadores de chat.

Lo curioso es que el mismo modelo cuantizado al formato anterior (Q5_K_M) funcionaba perfectamente. El problema era específico de NVFP4. Y los logs no mostraban ningún error: la conversión "tenía éxito", el modelo "cargaba", la inferencia "corría". Solo que la salida era basura.

La investigación

Después de varias iteraciones (incluyendo escribir un kernel CUDA de NVFP4 a mano para descartar problemas en el runtime), encontramos el origen leyendo línea a línea el código del conversor.

Los modelos de la familia Llama (a la que pertenece ALIA) requieren una permutación específica de filas en las matrices q_proj y k_proj (las proyecciones de "query" y "key" del mecanismo de atención) para que la convención de RoPE de GGML coincida con la de Hugging Face. Esa permutación se aplica correctamente en el camino BF16 estándar, dentro de la función LlamaModel.modify_tensors.

Pero el camino NVFP4 nuevo bypasea esa función. Escribe los pesos cuantizados directamente en el GGUF a través de _repack_nvfp4, sin pasar por la permutación. Resultado: las cabezas de atención salen barajadas, el modelo "funciona" técnicamente pero genera puro ruido.

Este bug afecta a cualquier modelo de arquitectura Llama cuantizado a NVFP4 con el conversor estándar de llama.cpp: Llama 1/2/3, Mistral, Qwen2, ALIA, y todos sus derivados. Es probable que más de uno haya producido GGUFs corruptos sin darse cuenta porque los modelos parecen cargar.

La solución: 16 líneas y una contribución upstream

El parche aplica la misma permutación a las matrices NVFP4 dentro de _repack_nvfp4. Son 16 líneas que duplican intencionalmente la lógica de LlamaModel.permute para mantener la separación entre ModelBase (clase padre) y LlamaModel (clase hija).

Para validarlo, reprodujimos el bug en un modelo pequeño (TinyLlama-1.1B) y medimos perplexidad — la métrica estándar para detectar degradación en LLMs:

| Build | Perplexidad (wikitext-2) | |---|---| | Referencia BF16 | 44.0 | | NVFP4 GGUF (master sin parche) | 4419 (basura total) | | NVFP4 GGUF con nuestro parche | 43.9 |

La perplexidad pasa de 4419 a 43.9 — esencialmente coincide con la referencia BF16. Lo mismo se confirma cualitativamente con ALIA-40B: respuestas coherentes en español, catalán, euskera y gallego con el parche; basura sin él.

Hemos enviado el parche upstream a llama.cpp para que el resto del mundo lo herede automáticamente: ggml-org/llama.cpp#22611.

Rendimiento de inferencia en la DGX Spark

Aunque el caso de uso principal de la DGX Spark es desarrollo y fine-tuning, sí medimos inferencia para validar la calidad del modelo. Sobre la DGX Spark (GB10 Blackwell, 128 GB memoria unificada, aarch64), generación greedy con prompts en español:

| Backend | Formato | Generación | |---|---|---| | llama.cpp (GPU) | NVFP4 | 10.2 tok/s | | llama.cpp (GPU) | Q8_0 (referencia) | 5.4 tok/s | | vLLM (GPU) | NVFP4 | 8.7 tok/s | | llama.cpp (CPU, ARM NEON) | Q8_0 | 2.7 tok/s |

NVFP4 sobre Blackwell es ~1,9× más rápido en inferencia que Q8_0, y ocupa un 33% menos en disco y memoria. El número que más nos importa, sin embargo, es el de los 90+ GB libres que NVFP4 deja en una DGX Spark — espacio para gradientes, activaciones, estados del optimizador y contexto durante un fine-tuning con QLoRA.

Si quieres bajar al detalle absoluto — el commit, la justificación del diseño, el reproductor en TinyLlama — todo está en el PR upstream #22611 y en el README del repo de Hugging Face.