¿Qué es un modelo de lenguaje pequeño?
Fundamentos, modelos y capacidades de IA
Un modelo de lenguaje pequeño es un modelo de lenguaje diseñado para ofrecer capacidad útil con mucha menos memoria, cómputo y coste que los modelos muy grandes. No existe un umbral único en la industria para definir "pequeño". El término es relativo. En la práctica, suele referirse a un modelo construido para tareas específicas, menor latencia, despliegue local o un control más estricto de los costes, en lugar de la máxima amplitud en todos los benchmarks.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Un modelo de lenguaje pequeño, a menudo abreviado como SLM, se entiende mejor por comparación. Un modelo de lenguaje grande está diseñado para manejar una gama muy amplia de tareas y conocimientos, con frecuencia con requisitos de cómputo extremadamente elevados. Un modelo de lenguaje pequeño aspira a realizar suficiente parte de ese trabajo, para las tareas adecuadas, a una fracción del coste de servicio y la demanda de hardware.
Eso no significa "de juguete". Significa más acotado, más ligero y, por lo general, más deliberado en cuanto a dónde se utiliza. Si se necesita un modelo que clasifique tickets de soporte, extraiga campos de formularios, enrute solicitudes, redacte a partir de una plantilla definida o funcione en un dispositivo o servidor local, los modelos pequeños pueden ser una opción muy razonable.
El término en sí sigue siendo impreciso. Algunos artículos de investigación definen "pequeño" como entre 100 millones y 5.000 millones de parámetros. Otros usan umbrales como menos de 7.000 millones, o hablan de forma más general sobre modelos mucho más pequeños que los sistemas frontera actuales. En la práctica empresarial, lo importante no es el número exacto, sino la intención de diseño: menor huella de memoria, respuesta más rápida, menor coste operativo y adecuación a entornos con recursos limitados.
Así pues, un SLM es una categoría de modelo, no una técnica única. Puede entrenarse desde cero, ajustarse a partir de una base existente, destilarse de un modelo maestro más grande, o hacerse más desplegable mediante cuantización y otros métodos de eficiencia. La destilación es una vía para obtener un SLM, pero no es la definición de un SLM.
Por qué importa
Los responsables deben prestar atención porque muchas tareas empresariales no necesitan el modelo más grande disponible. Necesitan el modelo más económico que pueda realizar el trabajo con suficiente fiabilidad. Esa es una decisión muy diferente.
Los SLM importan más cuando el volumen, la latencia, la privacidad o la flexibilidad de despliegue determinan la economía del proyecto. Si se procesan miles de solicitudes cortas al día, un modelo eficiente puede cambiar materialmente la base de costes. Si se necesitan respuestas en un portátil, una pasarela, un teléfono o un dispositivo de borde en una fábrica, un modelo pequeño puede ser la única opción realista. Si se quiere una capa de IA integrada en el interior del software en lugar de un producto de chat visible, los modelos más pequeños suelen encajar mejor en la arquitectura.
También pueden mejorar la fiabilidad en flujos de trabajo acotados. Un modelo más pequeño orientado a un problema concreto puede ser más fácil de evaluar, enrutar y supervisar. En muchos sistemas en producción, el mejor diseño no es un modelo grande para todo, sino una cascada: modelo pequeño por defecto, modelo más grande solo cuando la confianza es baja o la tarea es inusualmente compleja.
Esto importa porque el tamaño del modelo no equivale a la adecuación al negocio. Mayor tamaño implica mayor amplitud. Menor tamaño puede significar mayor precisión, menor coste y mayor facilidad de operación.
Cómo funciona
Un SLM funciona según el mismo principio básico que cualquier otro modelo de lenguaje: predice los tokens más probables a partir del contexto. Lo que cambia es la escala, la arquitectura, la estrategia de entrenamiento y el objetivo de despliegue.
La escala es la diferencia más evidente. Los modelos más pequeños tienen muchos menos parámetros que los mayores sistemas frontera. Menos parámetros suelen implicar menor uso de memoria y menor coste de inferencia, lo que generalmente se traduce en respuestas más rápidas y la posibilidad de ejecutarse en hardware menos especializado.
Pero el tamaño por sí solo no es suficiente. Muchos SLM modernos son eficaces gracias a cómo se entrenan. Pueden utilizar datos muy filtrados, datos sintéticos, ajuste por instrucciones, ajuste por preferencias o arquitecturas especializadas que extraen más comportamiento útil de menos parámetros. En otras palabras, un buen SLM no es simplemente un modelo grande recortado, sino a menudo un modelo diseñado deliberadamente en torno a la eficiencia.
El despliegue es donde la distinción práctica se hace evidente. Un modelo muy grande alojado en la nube puede ser brillante en un laboratorio, pero resultar caro de invocar a escala. Un SLM puede ejecutarse localmente o en un entorno dedicado pequeño, lo que cambia la postura de privacidad, la latencia y la resiliencia. También puede permitir un rendimiento más predecible, ya que no se depende por completo de capacidad externa compartida.
Desde el punto de vista arquitectónico, algunos modelos pequeños son transformers estándar. Otros utilizan diseños híbridos o elementos recurrentes para reducir el uso de memoria. Algunos están construidos para uso en el borde y en local. Otros están diseñados para cargas de trabajo empresariales en servidor, pero aun así buscan ser mucho más ligeros que los grandes modelos frontera.
La adecuación a la tarea es igualmente importante. Los SLM tienden a rendir mejor cuando el trabajo está estructurado o acotado. Algunos ejemplos son: resumir según una plantilla, clasificación de intenciones, extracción de campos, enrutamiento, formateo de respuestas de recuperación, asistencia de código dentro de un repositorio controlado o selección de herramientas en flujos de trabajo agénticos acotados. En esos contextos, la amplitud importa menos que la eficiencia y la consistencia.
Por eso muchos equipos piensan ahora en términos de enrutamiento de modelos. Un modelo pequeño gestiona la ruta por defecto. Si la solicitud es rutinaria, la completa de forma económica y rápida. Si la solicitud parece ambigua, abierta, sensible en materia de seguridad o inusualmente compleja, el sistema escala a un modelo más grande. Esto crea un equilibrio práctico entre calidad y coste.
También es importante distinguir los SLM de conceptos vecinos. Un modelo cuantizado no es automáticamente un SLM. La cuantización reduce la precisión numérica para que un modelo sea más económico de ejecutar, pero puede seguir siendo un modelo grande en origen y perfil de capacidad. Un modelo destilado tampoco es automáticamente un SLM, aunque la destilación se usa habitualmente para crear uno. La poda, los cambios de arquitectura y el entrenamiento desde cero son otras vías posibles.
Del mismo modo, un SLM no siempre se ejecuta en el dispositivo. Algunos sí funcionan en teléfonos, portátiles o hardware de borde. Otros se despliegan en infraestructura central porque su principal ventaja es el menor coste y la menor latencia, no el uso sin conexión.
La contrapartida, por supuesto, es el techo de capacidad. A medida que las tareas se vuelven más abiertas, más intensivas en conocimiento o más exigentes en razonamiento, los modelos más pequeños suelen encontrar sus límites antes que los más grandes. La planificación en cadenas largas, los casos extremos inusuales, la síntesis jurídica o científica sutil y los juicios entre dominios son donde la brecha tiende a ampliarse.
Eso no convierte a los SLM en una segunda opción en sentido general. Significa que son herramientas con un perfil operativo diferente. En muchos entornos empresariales, la pregunta correcta no es "¿Qué modelo es el más inteligente?", sino "¿Qué modelo es suficientemente inteligente para esta tarea acotada con un riesgo y un coste aceptables?". Los SLM existen porque esa pregunta importa.
Un último apunte: el sector todavía carece de una definición única y consolidada. Vale la pena decirlo con claridad. "Pequeño" es a menudo un término empresarial relativo tanto como uno técnico. Un modelo de 7.000 millones de parámetros puede ser pequeño en comparación con uno de 400.000 millones y grande en comparación con uno de 1.000 millones para dispositivo. Por eso los responsables no deben anclarse en un umbral universal, sino en la adecuación al propósito.
Ejemplos
Un SLM puede integrarse en un sistema de clasificación de correos electrónicos que categoriza los mensajes entrantes en facturación, entrega, cancelación, reclamación o spam, y extrae los números de referencia evidentes antes de que un humano vea la cola. Se trata de un trabajo de alto volumen y repetitivo donde la baja latencia importa más que la elocuencia.
En un entorno de servicio de campo, un modelo local compacto puede ayudar a los técnicos a buscar en manuales, resumir historiales de averías y redactar notas incluso con conectividad intermitente. El objetivo no es una inteligencia general amplia, sino una asistencia útil cerca del trabajo.
Un equipo de finanzas puede usar un modelo más pequeño para normalizar solicitudes de correo electrónico de proveedores, extraer fechas de pago, identificar adjuntos faltantes y enrutar elementos para su revisión. Aquí el valor proviene de la repetibilidad y el control de costes.
Un equipo de software puede usar un SLM como asistente de código por defecto para autocompletado, sugerencias específicas del repositorio o selección estructurada de herramientas, reservando un modelo remoto más grande para depuración más compleja o preguntas de arquitectura.
Un equipo de operaciones con clientes puede usar primero un SLM para detectar la intención y preparar un siguiente paso recomendado, y luego transferir solo los casos más difíciles a un modelo más grande o a un agente humano.
Malentendidos frecuentes
Un malentendido habitual es que pequeño significa débil. En realidad, muchos modelos más pequeños son muy sólidos en tareas acotadas, especialmente cuando se combinan con recuperación, herramientas o prompts bien definidos.
Otro es que los SLM se definen por un rango fijo de parámetros. No es así. El mercado usa el término de forma comparativa, y los artículos académicos emplean umbrales distintos.
Los equipos también asumen que si un modelo es pequeño siempre se ejecutará en el dispositivo. A veces sí, a veces no. Algunos modelos pequeños siguen siendo mejor desplegados en un servidor por razones operativas.
Un error relacionado es confundir los SLM con la destilación. La destilación es una técnica. Un SLM es una categoría de modelo. Algunos SLM son destilados; otros no.
Por último, algunos responsables asumen que un SLM es automáticamente más económico en términos totales. El modelo puede ser más barato de servir, pero si falla con frecuencia y genera retrabajo, reintentos o corrección humana, el coste total puede no ser menor.
Riesgos y límites
El riesgo más claro es subestimar el alcance de la tarea. Los equipos a veces eligen un modelo pequeño para un trabajo que es demasiado amplio, demasiado dependiente del juicio o demasiado lleno de excepciones. El resultado es un comportamiento frágil y una decepción que tiene poco que ver con el concepto en sí.
La evaluación es otro límite. Los modelos pequeños pueden parecer muy buenos en benchmarks acotados y aun así fallar en casos reales importantes. Si la tarea implica casos extremos, reglas de varios pasos o contenido de alta sensibilidad, se necesitan pruebas basadas en los propios datos y modos de fallo.
También existen problemas de infraestructura ocultos. Un modelo puede ser pequeño en número de parámetros y aun así resultar caro en la práctica si se le exigen contextos largos, muchas sesiones concurrentes o cadenas pesadas de recuperación y herramientas.
La gobernanza sigue siendo relevante. Ejecutar un modelo más pequeño en local no elimina los riesgos de privacidad, seguridad o uso indebido. Cambia la forma de esos riesgos.
Este artículo no constituye asesoramiento en materia de adquisición, seguridad ni sectores regulados. Si la ubicación del despliegue, la clasificación de seguridad o los umbrales de calidad son relevantes, conviene evaluar el modelo y la arquitectura exactos que se planea utilizar.
Próximos pasos
Comience por identificar una tarea acotada y frecuente donde la velocidad de respuesta y el coste sean importantes. Los mejores primeros casos de uso de un SLM suelen ser repetitivos y delimitados, no razonamientos estratégicos abiertos.
A continuación, realice benchmarks en contexto. Compare un modelo pequeño candidato con un modelo de referencia más grande usando los prompts, documentos y casos extremos a los que realmente se enfrentan sus equipos. No tome decisiones basándose únicamente en eslóganes de clasificaciones.
Después, diseñe una regla de enrutamiento. Deje que el SLM gestione los casos sencillos, pero defina cuándo una solicitud debe escalar a un modelo más grande o a un humano. Aquí es donde los SLM suelen volverse más eficaces.
A continuación, examine los supuestos de despliegue. Si el atractivo es el uso en el dispositivo o en local, verifique la memoria, la latencia y la concurrencia en el hardware real disponible, no en el hardware de una demostración.
Por último, mida el rendimiento total del sistema, no solo el coste del modelo. Incluya el esfuerzo de corrección, la frecuencia de fallback y la tasa de errores de negocio. Una buena estrategia de SLM trata del diseño global de la carga de trabajo, no simplemente de reducir el tamaño de un modelo.
¿Tiene alguna pregunta o sugerencia, o desea saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Existe una definición universal de modelo de lenguaje pequeño?
No. Distintos artículos y proveedores utilizan umbrales diferentes. En la práctica, "pequeño" es en parte un término relativo vinculado al despliegue y al coste.
¿Puede un SLM reemplazar completamente a un modelo grande?
A veces para un flujo de trabajo específico, pero no habitualmente para todas las tareas de una organización. Muchos equipos adoptan un enfoque de SLM primero con fallback a un modelo más grande.
¿Los SLM solo son útiles en teléfonos y dispositivos de borde?
No. También son útiles en servidores y sistemas empresariales donde importan la menor latencia y el menor coste por solicitud.
¿Un SLM es lo mismo que un modelo destilado?
No. La destilación es una forma de crear o mejorar un modelo más pequeño, pero no la única.
¿Los SLM necesitan recuperación o herramientas con más frecuencia que los modelos grandes?
A menudo sí. Muchos diseños sólidos de SLM combinan un modelo más pequeño con recuperación, function calling, salvaguardas y enrutamiento inteligente.
¿Cómo debo elegir entre un modelo pequeño y uno grande?
Comience por la tarea, la tolerancia al fallo y el coste operativo que puede asumir. Luego pruebe ambos con trabajo real en lugar de asumir que mayor siempre es mejor.
Fuentes
Small Language Models: Survey, Measurements, and Insights (arXiv). Secondary academic source for one rigorous SLM definition range, focused on 100M to 5B parameter decoder-only models, and for runtime measurement context.
A Comprehensive Survey of Small Language Models in the Era of Large Language Models (ACM). Secondary academic source for the point that there is no single agreed threshold for SLMs and that some usage treats the term comparatively.
A Comprehensive Survey of Small Language Models in the Era of Large Language Models (arXiv). Secondary academic source for the relationship between SLMs and methods such as distillation, pruning, and quantisation, and for the business motives of lower latency, lower cost, and easier adaptation.
A Survey of Small Language Models (arXiv). Secondary academic source for the broader view of SLM development, optimisation, and deployment on mobile and edge devices.