Cómo elegir SLM e implementarlo en tu proyecto paso a paso

Elegir un SLM —un modelo de lenguaje pequeño (Small Language Model)— es una de las decisiones técnicas más relevantes que puedes tomar cuando quieres integrar IA en un proyecto sin depender de APIs externas ni incurrir en costes desorbitados. Saber cómo elegir SLM correctamente implica evaluar criterios técnicos concretos, conocer las herramientas disponibles y seguir un proceso de implementación ordenado. Esta guía te lleva desde la decisión hasta el despliegue, incluyendo patrones avanzados como RAG y fine-tuning.

¿Qué es un SLM y por qué importa elegirlo bien?

Un SLM es un modelo de inteligencia artificial capaz de procesar y generar lenguaje natural con muchos menos recursos que un LLM convencional. Los pequeños modelos de lenguaje realizan tareas específicas con menos recursos, lo que los convierte en la opción natural para proyectos con restricciones de hardware, privacidad o presupuesto. Elegir SLM adecuadamente marca directamente la viabilidad del proyecto.

A diferencia de los LLM generalistas, los SLM suelen diseñarse pensando en casos de uso concretos, lo que permite priorizar eficiencia, rapidez y control. En tareas bien delimitadas —clasificación de texto, extracción de datos, asistentes internos, moderación de contenido—, un modelo bien elegido puede superar en rendimiento práctico a uno grande mal ajustado. Por eso, saber elegir SLM con criterio es tan valioso como saber desplegarlo.

El ecosistema de modelos de lenguaje pequeños ha crecido enormemente. Hugging Face ha superado los 2 millones de modelos públicos. Elegir SLM mal supone tiempo perdido, infraestructura sobredimensionada o resultados mediocres. Elegir SLM bien puede marcar la diferencia entre un proyecto viable y uno que nunca llega a producción.

¿Cuándo tiene sentido usar un SLM frente a un LLM?

Antes de entrar en criterios de selección, conviene tener claro cuándo un modelo pequeño es la respuesta correcta. Elegir SLM es la decisión correcta cuando se cumplen una o varias de estas condiciones:

• Privacidad de los datos: necesitas que los datos no salgan de tu infraestructura.
• Latencia crítica: tu aplicación requiere respuestas en tiempo real o casi real.
• Presupuesto limitado: las llamadas a APIs de modelos grandes son demasiado costosas a escala.
• Tarea acotada: el modelo solo necesita hacer una cosa bien, no todo.
• Despliegue en edge: el modelo correrá en un dispositivo con recursos limitados.

Por el contrario, si tu caso requiere razonamiento complejo, generación creativa abierta o manejo de múltiples dominios simultáneamente, un LLM sigue siendo la opción más robusta. En ese caso, elegir SLM podría no ser suficiente.

¿Qué criterios técnicos usar para elegir SLM?

Tomar esta decisión con rigor requiere evaluar al menos cinco dimensiones técnicas antes de descargar ningún modelo. Cada criterio influye directamente en si la elección del SLM será acertada o no.

Número de parámetros y requisitos de hardware

El tamaño del modelo —medido en miles de millones de parámetros (B)— determina directamente cuánta memoria necesitas. Para hardware de 8 GB de VRAM, Phi-4-mini (3,8 B) es el mejor razonador compacto con aproximadamente 3 GB de VRAM en cuantización Q4, y Gemma 3 4B es la mejor opción si necesitas capacidades multimodales o soporte de más de 140 idiomas. Estos datos son esenciales para elegir SLM que encaje con tu infraestructura real.

Como regla general: modelos de 1-4 B parámetros funcionan en portátiles con 8 GB de RAM; modelos de 7-14 B requieren una GPU dedicada o al menos 16 GB de RAM unificada. No elijas el modelo más grande que pueda correr en tu hardware; elige el más pequeño que resuelva tu tarea con calidad suficiente. Este principio es fundamental al elegir SLM para cualquier entorno de producción.

Latencia e inferencia

La latencia —el tiempo que tarda el modelo en generar una respuesta— depende del tamaño del modelo, del hardware y del nivel de cuantización aplicado. La cuantización convierte datos de alta precisión a menor precisión, lo que aligera la carga computacional y acelera la inferencia. Evaluar la latencia real en tu hardware es un paso imprescindible antes de comprometerte con un modelo en producción. Ignorar este punto es uno de los errores más comunes al elegir SLM.

Para aplicaciones interactivas, apunta a modelos que generen al menos 20-30 tokens por segundo en tu hardware. Herramientas como Ollama te muestran esta métrica directamente durante la inferencia, lo que facilita comparar candidatos cuando necesitas elegir SLM con requisitos de velocidad estrictos.

Precisión en la tarea específica

Los benchmarks generales son orientativos, pero la precisión real es la que obtienes en tu tarea concreta. Un modelo con un MMLU alto puede comportarse peor que uno más pequeño en, por ejemplo, extracción de entidades en documentos legales en español. Este matiz es crítico para elegir SLM de forma objetiva.

La recomendación práctica: define un conjunto de 20-50 ejemplos representativos de tu caso de uso y evalúa cada modelo candidato sobre ellos antes de tomar la decisión final. Esto es más valioso que cualquier tabla de benchmarks y es el método más fiable para elegir SLM con garantías.

Licencia y uso comercial

No todos los modelos de lenguaje pequeños son libres para uso comercial. Antes de integrar un SLM en un producto, verifica su licencia. Este paso es imprescindible al elegir SLM para un entorno empresarial. Los modelos Qwen 3 SLM están disponibles bajo la licencia Apache 2.0, y son de descarga gratuita, ajuste fino y uso comercial. Otros modelos, como los de la familia Gemma, tienen licencias propias que permiten el uso comercial con ciertas condiciones.

Revisa siempre la licencia antes de construir sobre un modelo. Un cambio de licencia a posteriori puede obligarte a migrar toda tu implementación. Tenerlo en cuenta desde el principio simplifica mucho elegir SLM con garantías legales.

Soporte multilingüe y calidad real en español

Si tu proyecto opera en español u otros idiomas distintos del inglés, el soporte multilingüe es un criterio crítico al elegir SLM. Algunos modelos como Qwen 3 soportan más de 100 idiomas y dialectos. Modelos entrenados principalmente en inglés pueden degradar notablemente su calidad en castellano.

Para ilustrar la diferencia, considera este prompt de extracción de información en castellano: “Extrae el nombre del cliente, el importe y la fecha de vencimiento de esta factura: ‘Cliente: Distribuciones López S.L. Importe: 3.450,00 € Vencimiento: 15/02/2026.'”

Con Qwen 3 4B, la salida es estructurada y precisa. Con un modelo sin soporte multilingüe real, la respuesta típica mezcla idiomas, omite el símbolo de moneda o reformatea la fecha al estándar anglosajón. Prueba siempre con ejemplos en el idioma de producción: los benchmarks públicos suelen medirse en inglés y no reflejan la calidad real en castellano. Este paso es especialmente relevante para elegir SLM en proyectos hispanohablantes.

¿Qué modelos de lenguaje pequeños están disponibles hoy?

El ecosistema de modelos de lenguaje pequeños ha madurado rápidamente. Conocer el catálogo disponible es indispensable para elegir SLM de forma informada. Estos son los más relevantes en 2025-2026:

Phi-4 (14 B) es el SLM de referencia en benchmarks generales —84,8 % en MMLU, superando a GPT-4o en matemáticas— y cabe en una GPU de 12 GB. Sin embargo, para proyectos con hardware más limitado, los modelos de 3-4 B son el punto de partida más pragmático para elegir SLM sin sobredimensionar la infraestructura.

¿Qué herramientas SLM existen para el despliegue local?

Las herramientas para despliegue local de SLM han madurado hasta el punto de que cualquier desarrollador puede tener un modelo corriendo en minutos. Elegir SLM correctamente también implica elegir la herramienta de despliegue adecuada.

Ollama: el estándar para despliegue local

Ollama se ha convertido en el estándar de facto para la gestión local de modelos de lenguaje por su simplicidad: gestiona los pesos del modelo, la configuración del entorno y el servidor de API en un único paquete. Es una de las primeras herramientas que debes valorar al elegir SLM para entornos de desarrollo.

Su ventaja más práctica es la integración automática: Ollama crea automáticamente un servidor local en localhost:11434, lo que permite integrar el modelo en aplicaciones Python o JavaScript con facilidad. Además, Ollama permite ejecutar modelos sin conexión a internet, lo que ayuda a proteger datos sensibles. Puedes consultar la documentación oficial de Ollama para ver los modelos soportados.

LM Studio: interfaz visual para comparar modelos

LM Studio proporciona una interfaz gráfica para usuarios que quieren comparar distintos modelos de Hugging Face; permite ver el uso de recursos (CPU/RAM) en tiempo real y seleccionar niveles específicos de cuantización. Es especialmente útil en la fase de evaluación, cuando todavía estás intentando elegir SLM entre varios candidatos.

LM Studio pasó a ser gratuito para uso comercial en julio de 2025. Si eres nuevo en el ecosistema de modelos pequeños, LM Studio es el punto de entrada más amigable para elegir SLM sin experiencia previa.

llama.cpp y Hugging Face Transformers

Para desarrolladores que necesitan mayor control, llama.cpp es especialmente eficiente para ejecutar modelos cuantizados de forma nativa. Ollama ejecuta llama.cpp internamente, por lo que usarlo directamente te da acceso a más opciones de configuración a cambio de mayor complejidad. Esta opción es adecuada cuando necesitas elegir SLM y ajustar al máximo los parámetros de inferencia.

Hugging Face Transformers ofrece una gama más amplia de modelos y tareas. Es la opción natural si ya trabajas con el ecosistema Python de machine learning y quieres integrar un SLM en un pipeline de datos existente. Elegir SLM a través de Transformers da acceso al mayor repositorio de modelos disponible.

RAG con SLM: conecta el modelo a tus documentos sin reentrenarlo

RAG (Retrieval-Augmented Generation) es el patrón arquitectónico más habitual para extender las capacidades de un SLM sin modificar sus pesos. La idea central es sencilla: en lugar de reentrenar el modelo con tus datos, le proporcionas contexto relevante en cada consulta, recuperado en tiempo real desde una base de conocimiento propia. Elegir SLM compatible con este patrón amplía enormemente su utilidad.

El flujo básico de una arquitectura RAG con un SLM local tiene tres pasos:

1. Indexación: tus documentos se dividen en fragmentos y se convierten en vectores numéricos mediante un modelo de embeddings. Estos vectores se almacenan en una base de datos vectorial como ChromaDB o Qdrant.
2. Recuperación: cuando el usuario hace una pregunta, el sistema convierte la pregunta en un vector y busca los fragmentos más similares en la base de datos.
3. Generación: el SLM recibe la pregunta original junto con los fragmentos recuperados y genera una respuesta fundamentada en esa información concreta.

Para implementar este patrón con un modelo local, los dos frameworks más utilizados son LlamaIndex y LangChain. LangChain excela en la orquestación de flujos de trabajo de IA en varios pasos, mientras que LlamaIndex se centra en optimizar la indexación y recuperación de documentos. Ambos facilitan elegir SLM y conectarlo a tus fuentes de datos internas.

¿Cuándo usar RAG en lugar de fine-tuning? RAG es la opción correcta cuando tus datos cambian con frecuencia o cuando necesitas que el modelo cite fuentes concretas. El fine-tuning es más adecuado cuando quieres modificar el estilo de respuesta del modelo o especializar su comportamiento en un dominio estático. Esta distinción también influye en cómo elegir SLM base para cada caso.

¿Cuándo usar RAG, fine-tuning o modelo base? Tabla de decisión

Esta tabla es una guía rápida para elegir SLM con la estrategia de adaptación correcta según tu situación concreta.

Fine-tuning de SLM: cuándo y cómo ajustar el modelo a tu dominio

El fine-tuning consiste en continuar el entrenamiento de un SLM preentrenado con datos propios de tu dominio, de modo que el modelo interioriza el vocabulario, el estilo y los patrones específicos de tu caso de uso. Es la opción correcta cuando RAG no es suficiente: por ejemplo, cuando necesitas que el modelo adopte un tono de marca muy específico o clasifique según categorías propietarias. Antes de aplicarlo, es importante elegir SLM base que sea compatible con las técnicas de ajuste que planeas usar.

LoRA y QLoRA: fine-tuning eficiente en hardware modesto

El reentrenamiento completo de un SLM requiere recursos de cómputo prohibitivos. Las técnicas de adaptación de bajo rango (LoRA y QLoRA) resuelven este problema: en lugar de actualizar todos los parámetros del modelo, solo se entrenan matrices adicionales de rango reducido que se añaden a los pesos originales, congelados. El paper original de LoRA (Hu et al., 2021) demostró que esta técnica puede igualar el rendimiento del fine-tuning completo con hasta un 10.000× menos de parámetros entrenables. Esto hace que elegir SLM para fine-tuning con LoRA sea accesible incluso con hardware modesto.

QLoRA lleva esto un paso más lejos combinando la cuantización de 4 bits con LoRA. Con QLoRA es posible hacer fine-tuning de modelos de 3B parámetros usando solo 8 GB de VRAM. Elegir SLM compatible con QLoRA amplía significativamente las opciones de ajuste fino en equipos de consumo.

Herramientas para el fine-tuning: Unsloth y Axolotl

Dos herramientas destacan hoy como las más accesibles para hacer fine-tuning de SLMs en hardware de consumo:

• Unsloth: utiliza kernels CUDA/Triton personalizados que aceleran el fine-tuning con LoRA y QLoRA hasta 5× mientras reducen el uso de memoria. Es la opción más rápida para un único GPU. Sin embargo, no soporta entrenamiento multi-GPU.
• Axolotl: orientado a la comunidad para el fine-tuning de LLMs, con configuraciones basadas en YAML e integración extensa con las librerías de Hugging Face. Es la opción natural para entornos multi-GPU.

El proceso mínimo para hacer fine-tuning con Unsloth es: preparar un dataset en formato JSONL con pares instrucción-respuesta, configurar los parámetros LoRA, lanzar el entrenamiento y exportar el adaptador resultante. Con 500-2000 ejemplos de calidad, un SLM de 3-4 B puede especializarse notablemente en una tarea concreta. Elegir SLM de tamaño adecuado es el primer paso antes de iniciar cualquier proceso de fine-tuning.

¿Cómo implementar SLM en tu proyecto paso a paso?

Implementar un SLM en un proyecto real sigue siempre el mismo proceso, independientemente del modelo o la herramienta que elijas. Estos pasos también sirven como guía para elegir SLM con rigor metodológico.

1. Define la tarea con precisión. Escribe en una frase qué debe hacer el SLM: «clasificar tickets de soporte en 5 categorías», «resumir contratos en menos de 100 palabras». Cuanto más acotada sea la tarea, más fácil será elegir SLM correcto e implementarlo.
2. Evalúa tu hardware disponible. Comprueba la RAM disponible, si tienes GPU dedicada y cuánta VRAM tiene. Esto determinará el rango de tamaños de modelo que puedes ejecutar y acotará significativamente cómo elegir SLM viable.
3. Selecciona 2-3 modelos candidatos. Usando los criterios descritos anteriormente, elige un conjunto pequeño de candidatos. Para proyectos en español, Qwen 3 4B, Gemma 3 4B y Llama 3.2 3B son un buen punto de partida para elegir SLM con soporte multilingüe.
4. Instala Ollama y descarga los modelos candidatos. Una vez instalado, descarga los modelos con comandos como ollama pull qwen3:4b. Es el método más rápido para elegir SLM y probarlo en local.
5. Evalúa con datos reales. Prepara un conjunto de 20-50 ejemplos de tu caso de uso y ejecuta cada modelo candidato. Mide precisión, latencia y calidad subjetiva. Esta evaluación es la base objetiva para elegir SLM definitivo.
6. Aplica cuantización si es necesario. Si el modelo elegido es demasiado lento, prueba una versión cuantizada (Q4 o Q8). La cuantización permite elegir SLM más grandes sin exceder los límites de tu hardware.
7. Integra vía API local. Una vez confirmada la elección, intégralo en tu aplicación a través del endpoint local que Ollama expone:

Opción A — librería oficial de Ollama para Python:

# pip install ollama
import ollama

response = ollama.chat(
model=”qwen3:4b”,
messages=[
{
“role”: “user”,
“content”: “Clasifica este ticket en una de estas categorías: Facturación, Soporte técnico, Envíos, Otros. Ticket: ‘No me ha llegado el pedido 12345.'”
}
]
)

print(response[“message”][“content”])

Opción B — llamada HTTP directa con requests:

import requests, json

payload = {
“model”: “qwen3:4b”,
“messages”: [
{
“role”: “user”,
“content”: “Clasifica este ticket en una de estas categorías: Facturación, Soporte técnico, Envíos, Otros. Ticket: ‘No me ha llegado el pedido 12345.'”
}
],
“stream”: False
}

resp = requests.post(“http://localhost:11434/api/chat”, json=payload)
data = resp.json()
print(data[“message”][“content”])

1. Considera RAG o fine-tuning si el rendimiento base no es suficiente. Si el modelo responde bien en general pero no conoce tus datos propios, implementa un pipeline RAG. Si necesitas cambiar el comportamiento o el estilo del modelo, valora el fine-tuning con LoRA/QLoRA. En ambos casos, elegir SLM base compatible con estas técnicas facilita mucho la integración.
2. Monitoriza y ajusta. En producción, el seguimiento sistemático es lo que separa un prototipo de un sistema fiable. Elegir SLM con buena documentación y comunidad activa facilita la resolución de problemas en esta fase.

Monitorización de SLM en producción: herramientas y métricas

El paso de monitorización es el más infravalorado de toda la implementación. Sin observabilidad, no puedes saber cuándo el modelo falla, por qué falla ni cómo mejorarlo. Elegir SLM adecuado para producción incluye considerar desde el principio cómo vas a monitorizarlo.

Herramientas de trazabilidad para LLM

Dos herramientas destacan como estándar para la observabilidad de sistemas basados en modelos de lenguaje:

• Langfuse: plataforma open-source de trazabilidad para LLM que registra cada llamada al modelo con su prompt, respuesta, latencia y coste estimado. Se integra con LangChain, LlamaIndex y llamadas directas a la API. Es la opción más recomendada para equipos pequeños que necesitan visibilidad rápida sin infraestructura compleja. Es especialmente útil cuando has tenido que elegir SLM sin experiencia previa en observabilidad.
• Phoenix (Arize): herramienta open-source orientada a la evaluación y depuración de pipelines RAG y LLM. Especialmente útil cuando tienes un pipeline RAG y quieres entender qué fragmentos se recuperan y cómo afectan a la calidad de la respuesta. Elegir SLM con soporte activo de la comunidad facilita su integración con Phoenix.

Métricas mínimas a registrar

Independientemente de la herramienta que uses, estas son las métricas que debes registrar desde el primer día en producción:

• Latencia p50 y p95: la mediana te dice el rendimiento típico; el percentil 95 te dice cuánto tardan las llamadas lentas. Un p95 por encima de 5 segundos suele ser inaceptable en aplicaciones interactivas. Si detectas este problema, puede ser señal de que debes elegir SLM más ligero o aplicar más cuantización.
• Tasa de error: porcentaje de llamadas que devuelven un error o una respuesta vacía. Una tasa superior al 1% en producción requiere investigación inmediata.
• Longitud de respuesta: respuestas sistemáticamente más cortas o más largas de lo esperado indican problemas con el prompt o con la temperatura configurada.
• Tasa de rechazo o alucinación: en tareas de extracción o clasificación, mide cuántas respuestas no siguen el formato esperado. Un incremento sostenido puede indicar que conviene elegir SLM con mejor ajuste a tu tarea.

Log mínimo viable sin herramientas externas

Si no puedes integrar Langfuse o Phoenix de inmediato, este es el log mínimo que debes implementar en Python para tener visibilidad básica:

import time, json, logging

logging.basicConfig(filename=”slm_production.log”, level=logging.INFO)

def call_model_with_log(prompt: str, model: str = “qwen3:4b”) -> str:
import requests
start = time.time()
try:
resp = requests.post(
“http://localhost:11434/api/chat”,
json={“model”: model, “messages”: [{“role”: “user”, “content”: prompt}], “stream”: False},
timeout=30
)
latency_ms = (time.time() – start) * 1000
output = resp.json()[“message”][“content”]
logging.info(json.dumps({
“model”: model,
“latency_ms”: round(latency_ms, 1),
“prompt_len”: len(prompt),
“response_len”: len(output),
“status”: “ok”
}))
return output
except Exception as e:
latency_ms = (time.time() – start) * 1000
logging.error(json.dumps({“model”: model, “latency_ms”: round(latency_ms, 1), “status”: “error”, “error”: str(e)}))
raise

Este log en formato JSONL es directamente importable en cualquier herramienta de análisis y te permite detectar degradaciones de rendimiento sin depender de plataformas externas. Es válido independientemente del SLM que hayas elegido.

¿Cuáles son los errores más comunes al elegir e implementar un SLM?

Conocer los errores habituales te ahorra semanas de trabajo. Estos son los más frecuentes cuando se trabaja con modelos de lenguaje pequeños por primera vez y se intenta elegir SLM sin una metodología clara.

Elegir por popularidad en lugar de por ajuste a la tarea

El modelo más descargado no es necesariamente el mejor para tu caso. Evalúa siempre sobre tus propios datos antes de comprometerte. Seleccionar por popularidad sin validación empírica es uno de los errores más frecuentes y más evitables al elegir SLM. La popularidad es un indicador de comunidad, no de idoneidad para tu tarea específica.

Ignorar las limitaciones de los SLM

La capacidad de procesamiento limitada puede dar lugar a una precisión reducida en tareas que implican razonamientos multifactor o altos niveles de abstracción; por lo tanto, es posible que no sean la mejor opción para aplicaciones que requieren una precisión alta, como la investigación científica o el diagnóstico médico. Conocer estas limitaciones es parte esencial de saber elegir SLM correctamente.

Saltarse la fase de evaluación

Muchos equipos instalan el primer modelo que encuentran y lo integran directamente en producción. La fase de evaluación con datos reales es la inversión más rentable del proceso: detecta problemas antes de que lleguen a los usuarios y permite elegir SLM de forma objetiva entre las opciones disponibles.

No considerar el soporte multilingüe desde el inicio

Si tu proyecto opera en español, verificar el soporte multilingüe desde el principio es crítico. Algunos modelos degradan notablemente su calidad en castellano. Prueba siempre con ejemplos en el idioma de producción, no en inglés. Pasar por alto este punto al elegir SLM puede arruinar la experiencia de usuario final incluso con un modelo técnicamente sólido en inglés.

¿Cómo encaja el despliegue local de IA en una estrategia de negocio?

El despliegue local de IA con modelos pequeños no es solo una decisión técnica: es también una decisión estratégica. Elegir SLM propio permite a pymes y emprendedores tener capacidades de IA sin depender de proveedores externos, sin costes variables por llamada y sin ceder datos de clientes a terceros.

Para ilustrar el argumento económico, esta estimación orientativa compara el coste de API externa frente a infraestructura propia para un volumen de 1 millón de inferencias al mes:

El punto clave no es el número exacto, sino la estructura del coste: con APIs externas pagas por cada inferencia; con un SLM propio, el coste es fijo y escala sin coste marginal. A partir de cierto volumen, el modelo local es más económico y más seguro. Elegir SLM local frente a API externa es, a esa escala, una decisión de negocio tan importante como técnica.

Los casos de uso más inmediatos para equipos de marketing y negocio incluyen: clasificación automática de leads, análisis de sentimiento en reseñas, generación de borradores de contenido interno, o asistentes de atención al cliente que corren completamente en la infraestructura propia. La clave es empezar con una tarea acotada, medirla y escalar solo cuando el valor está demostrado. Elegir SLM adecuado para ese primer caso de uso es el punto de partida de cualquier estrategia de IA local sostenible.