Los modelos de lenguaje pequeños para agentes de IA son modelos compactos, por debajo de unos 10.000 millones de parámetros según la definición de trabajo de NVIDIA, que asumen los pasos estrechos y repetidos de un agente: elegir una herramienta, extraer campos, clasificar una solicitud, dar formato a una respuesta. NVIDIA Research sostiene en "Small Language Models are the Future of Agentic AI" que estos modelos son lo bastante capaces para la mayoría de esos pasos, más adecuados para ellos y más baratos de ejecutar. Coincidimos con casi todo el artículo, y nuestras propias mediciones respaldan su tesis central en una tarea concreta. Nuestros matices son de ingeniería: qué tamaño necesita cada paso, qué optimizaciones mantienen el listón de calidad y a partir de qué volumen ejecutar tu propio modelo sale más barato que una API frontier.
Este artículo resume el argumento del texto tal como está escrito, dónde coincide nuestra evidencia, qué detalle añadiríamos, qué familias de modelos abiertos encajan con el trabajo de agentes a octubre de 2026 y cómo encajan los modelos de lenguaje pequeños en los agentes empresariales.
¿Qué son los modelos de lenguaje pequeños para agentes de IA?
Un modelo de lenguaje pequeño (SLM, por sus siglas en inglés) para un agente de IA es un modelo lo bastante pequeño para funcionar en un dispositivo corriente o en un único servidor modesto, entrenado o ajustado para las tareas estrechas que un agente encarga a un modelo de lenguaje. El artículo de NVIDIA define un SLM por dónde se ejecuta: un modelo de lenguaje que cabe en un dispositivo electrónico de consumo común y responde con una latencia lo bastante baja para atender las solicitudes de agente de un usuario. En parámetros, los autores dicen que, a 2025, considerarían SLM a la mayoría de los modelos por debajo de 10.000 millones de parámetros.
Un agente envía muchas solicitudes a un modelo de lenguaje por cada tarea que completa. Algunas llamadas a la API necesitan razonamiento abierto o conversación. Muchas son estrechas: elegir una herramienta y rellenar sus argumentos, extraer campos de un documento, clasificar una solicitud, resumir un registro, devolver JSON con un esquema fijo. En esas llamadas a la API estrechas es donde encaja un modelo pequeño.
"Modelo de lenguaje pequeño" es el término del artículo y el que la gente busca. En nuestro trabajo describimos el resultado por lo que hace: un modelo específico de tarea, entrenado para un trabajo y dimensionado al modelo más pequeño que mantiene el listón de calidad de ese trabajo.
¿Qué sostiene el artículo de NVIDIA?
Es un artículo de posición de Peter Belcak y siete colegas de NVIDIA Research y Georgia Tech (arXiv 2506.02153, publicado por primera vez el 2 de junio de 2025, versión 3 del 22 de septiembre de 2026). Su tesis central, en sus propias palabras, es que los SLM son "sufficiently powerful, inherently more suitable, and necessarily more economical for many invocations in agentic systems, and are therefore the future of agentic AI" (lo bastante potentes, intrínsecamente más adecuados y necesariamente más económicos para muchas invocaciones en sistemas agénticos, y por tanto el futuro de la IA agéntica).
Apoya esa tesis en tres posturas:
| Postura | La tesis, en breve | Apoyo principal |
|---|---|---|
| V1, capacidad | Los modelos pequeños bastan para casi todas las solicitudes | Resultados publicados de Phi, Nemotron-H, SmolLM2 y xLAM-2 |
| V2, adecuación | Los modelos pequeños encajan mejor con los agentes | Tareas estrechas, formatos estrictos, modelos combinados |
| V3, economía | Los modelos pequeños cuestan menos en casi todas las solicitudes | Servicio más barato y ajuste rápido |
En detalle, el artículo dice que los SLM tienen en principio potencia suficiente para los encargos de modelado de lenguaje de las aplicaciones agénticas, que son intrínsecamente más adecuados en la operación de sistemas agénticos que los LLM y que son necesariamente más económicos para la gran mayoría de usos de modelos de lenguaje en esos sistemas. Para la capacidad cita resultados publicados de Phi, Nemotron-H, SmolLM2, Hymba, DeepSeek-R1-Distill, RETRO y xLAM-2. Para la economía, sitúa el coste de servir un modelo de 7B entre 10 y 30 veces por debajo del de un modelo de 70B a 175B en latencia, energía y FLOPs, y el ajuste fino de un modelo pequeño en unas pocas horas de GPU.
Cuatro puntos sostienen la mayor parte del argumento propio de los agentes:
- Los agentes usan una porción estrecha del modelo. El artículo describe un agente como una puerta de acceso a un modelo de lenguaje muy instruida y coreografiada desde fuera, y sostiene que bastaría un modelo pequeño bien ajustado para las instrucciones elegidas.
- Los agentes necesitan un único formato de salida, siempre. Las llamadas a herramientas y las salidas que se analizan deben ajustarse a un esquema estricto. Un modelo entrenado con un solo formato sirve mejor para ese trabajo que un generalista que de vez en cuando responde en otro.
- Los agentes pueden combinar modelos. Cada solicitud del código del agente puede ir a un modelo distinto, así que el artículo propone sistemas heterogéneos en los que los SLM se usan por defecto y los LLM se invocan de forma selectiva y escasa.
- El tráfico del agente es material de entrenamiento. Cada solicitud registrada al modelo es una fuente natural de datos para mejoras futuras, lo que convierte el entrenamiento de un modelo pequeño experto en un paso natural del despliegue de agentes.
El artículo termina con un algoritmo de conversión de LLM a SLM en seis pasos: registrar de forma segura las solicitudes del agente al modelo, depurar los datos y eliminar la información personal y sensible, agrupar las solicitudes en tareas recurrentes, seleccionar modelos pequeños candidatos, ajustarlos con cada tarea y reentrenarlos periódicamente con datos nuevos. Su apéndice estima qué parte de las consultas a LLM de tres agentes de código abierto podrían atender de forma fiable SLM especializados: alrededor del 60% en MetaGPT, el 40% en Open Operator y el 70% en Cradle.
El artículo también responde a sus críticos. Acepta la evidencia de que un modelo grande supera a uno pequeño de la misma generación en comprensión general del lenguaje, y responde que un modelo pequeño se puede ajustar con facilidad a una tarea concreta hasta la fiabilidad necesaria. En economía es más prudente. Califica la postura contraria, que el servicio centralizado de LLM sigue siendo más barato por economías de escala, de "a valid view, with the exact economical considerations being highly case-specific" (una postura válida, con consideraciones económicas que dependen mucho de cada caso), y dice que la cuestión sigue abierta.
¿Dónde coincide nuestra evidencia?
En una tarea concreta, nuestras mediciones respaldan las posturas del artículo sobre capacidad y economía: un modelo entrenado para el trabajo mantuvo el listón de calidad con una fracción del tamaño de un modelo general, y el argumento de coste se apoya en dos dimensiones.
Modelos entrenados superaron a modelos propietarios alojados en un benchmark. Nuestro estudio QMSum (arXiv 2609.25028) puntuó el resumen de reuniones orientado a consultas con una sola implementación sobre el conjunto de prueba completo de 281 consultas. Los modelos entrenados de 406M y 1.200M de parámetros obtuvieron 36,33 y 35,41 de ROUGE-1. Cinco modelos propietarios alojados, ejecutados en zero-shot con una única instrucción concisa, obtuvieron entre 27,89 y 32,43. Los límites importan: los modelos alojados escribieron respuestas más largas, lo que contribuye a la diferencia en una métrica de solapamiento con la referencia; no se hizo evaluación humana ni de factualidad; y las conclusiones se limitan a QMSum y a métricas automáticas. Los sistemas QMSum publicados más fuertes declaran puntuaciones más altas en sus propios artículos, hasta 38,82 de ROUGE-1.
El entrenamiento pesó más que el tamaño. Dentro de un mismo modelo base de 1.200M, el ajuste fino con los mismos fragmentos de transcripción recuperados que el modelo lee en inferencia sumó 5,29 de ROUGE-1 (intervalo del 95%: +4,02 a +6,56). Un modelo de 406M entrenado de la misma forma obtuvo 36,33 frente a 35,41 del sistema de 1.200M, una diferencia que QMSum no puede separar estadísticamente, con menos de la mitad de la memoria máxima de inferencia. En una tarea, esa es la respuesta del artículo a sus críticos: un modelo pequeño entrenado para la tarea alcanza la fiabilidad que la tarea necesita.
El gasto está en tareas que los agentes repiten. En los datos públicos de OpenRouter de los 30 días hasta el 12 de octubre de 2026, clasificación, extracción y transformación sumaron el 20,8% del gasto clasificado en modelos, y los modelos frontier cerrados se llevaron entre el 75% y el 87% del gasto de los diez primeros modelos en esas tareas. Son los trabajos estrechos y verificables que, según el artículo, los agentes encargan a un modelo de lenguaje. Los datos describen la actividad del mercado: indican dónde mirar, y cada comprador mide después su propio ahorro.
El coste baja en dos dimensiones. La economía del artículo se basa en el precio por token, ya que un modelo más pequeño cuesta menos de servir. Un modelo entrenado también envía menos tokens por tarea. El artículo describe agentes sostenidos por instrucciones redactadas con esmero y una gestión de contexto cuidadosamente orquestada; cuando las instrucciones, el protocolo y los ejemplos que se repiten en esos prompts se entrenan en el modelo, dejan de enviarse y solo quedan los datos de cada solicitud. Un modelo entrenado también puede responder directamente, sin largas trazas de razonamiento. El tamaño de este segundo ahorro depende de cuánto de cada prompt es texto repetido y de si tu modelo actual cobra tokens de razonamiento. El caché de prompts ya abarata la entrada repetida en las API frontier, así que frente a una configuración bien cacheada el ahorro de entrada es menor. Nuestra comparativa open-weight vs frontier desarrolla las dos dimensiones con precios de lista.
¿Qué matizaríamos del artículo?
El artículo marca una dirección. Un equipo que pone un modelo pequeño en un agente en producción aún tiene que responder tres preguntas de ingeniería y de economía, y cada una se resuelve midiendo sobre su propia tarea.
Qué tamaño debe tener el modelo. La definición del artículo fija un techo: cualquier modelo que quepa en un dispositivo de consumo. Por debajo de ese techo, el tamaño adecuado cambia según el paso. En nuestro estudio QMSum, un modelo de 406M quedó dentro de la resolución del benchmark respecto a uno de 1.200M, mientras que los propios casos de estudio del artículo dejan la planificación, la depuración y la recuperación de errores a modelos más grandes. El tamaño sale de la evaluación: entrena candidatos de dos o tres tamaños con tus ejemplos y quédate con el más pequeño que mantenga tu listón de calidad.
Qué optimizaciones mantienen el listón. El artículo menciona el ajuste fino, el cómputo en inferencia, el uso de herramientas y el enrutamiento. Nuestros resultados añaden que los datos de entrenamiento tienen que coincidir con las entradas reales del agente. Un resumidor de 406M publicado perdió 6,30 de ROUGE-1 cuando su entrada pasó de transcripciones largas a los fragmentos recuperados que le da nuestro pipeline, y ajustarlo con las nuevas entradas recuperó la pérdida. Las entradas de un agente cambian cada vez que cambian su recuperación, sus herramientas o sus prompts, así que el especialista se reentrena con las entradas que ve ahora. La recuperación, la cuantización y el enrutamiento mueven coste y calidad, y cada uno se comprueba con el mismo conjunto de evaluación.
Dónde está el punto de cruce de coste. El artículo deja esto abierto, y es la pregunta correcta. Un modelo pequeño cuesta menos por token de servir, pero un modelo dedicado también conlleva entrenamiento, alojamiento, balanceo de carga y personas que lo operen, algo que el artículo acepta que depende mucho de cada caso. Con poco volumen, una API frontier a menudo gana en coste total. Los laboratorios frontier también venden niveles económicos que pueden cobrar menos por token que un modelo abierto alojado, y frente a ellos el argumento se apoya en menos tokens por tarea y en la calidad. El punto de cruce es un volumen, y puedes estimarlo con tus recuentos de tokens y precios actuales antes de construir nada, con la calculadora de coste por tarea.
Qué medir. El artículo señala que el desarrollo de modelos pequeños se apoya en los mismos benchmarks generalistas que el trabajo con LLM, y lo cita como una barrera para su adopción. Una puntuación en una tabla de clasificación dice poco sobre un paso de un agente. Construye un conjunto de evaluación con las solicitudes reales del agente y sus salidas esperadas, y puntúa con él a cada candidato, pequeño o grande. Nuestra guía de evaluación de LLM de dominio explica cómo, con el protocolo del estudio QMSum como ejemplo práctico.
¿Cuáles son los mejores modelos de lenguaje pequeños para agentes de IA?
El mejor modelo de lenguaje pequeño para un paso de un agente es el más pequeño que mantiene tu listón de calidad tras entrenarlo con tus propios ejemplos, con una licencia que permita tu uso. Como candidatos de partida, estas familias abiertas publican tamaños por debajo de 10B e indican funciones para agentes en sus propias fichas de modelo, consultadas el 30 de octubre de 2026:
| Familia (desarrollador) | Tamaños por debajo de 10B | Licencia | Ventana de contexto | Funciones para agentes en la ficha |
|---|---|---|---|---|
| Qwen3.5 (equipo Qwen, Alibaba) | 0.8B, 2B, 4B, 9B | Apache 2.0 | 262.144 tokens | "Qwen3.5 excels in tool calling capabilities" |
| Gemma 4 (Google DeepMind) | E2B, E4B (2,3B y 4,5B efectivos) | Apache 2.0 | 128K tokens | "native function-calling support" |
| Ministral 3 (Mistral AI) | 3B, 8B | Apache 2.0 | 256k tokens | "native function calling and JSON outputting" |
| Granite 4.2 (IBM) | 3B, 8B | Apache 2.0 | 128K tokens, ampliable a 512K | Menciona llamadas a herramientas y flujos agénticos como su punto fuerte |
| Nemotron 3 Nano 4B (NVIDIA) | 4B | NVIDIA Nemotron Open Model License | Hasta 262K tokens | Razonamiento desactivable; ajustes recomendados para llamadas a herramientas |
| SmolLM3 (Hugging Face) | 3B | Apache 2.0 | Entrenado a 64k, hasta 128k con YaRN | "SmolLM3 supports tool calling!" |
Salen versiones nuevas a menudo (la ficha de Granite 4.2 da como fecha de lanzamiento el 25 de agosto de 2026), así que comprueba la fecha de cualquier lista, también de esta. Las licencias también varían. La mayoría de estas familias usan Apache 2.0, mientras que el modelo de NVIDIA tiene su propia licencia de modelo abierto, así que lee las condiciones antes de un uso comercial. Para licencias y tamaños desde un ángulo empresarial, consulta nuestra comparativa de modelos pequeños para empresas.
Tres comprobaciones pesan más que la ficha del modelo:
- Formato. ¿Produce el modelo tu formato exacto de llamada a herramientas o de JSON tras entrenarlo con tus ejemplos?
- Razonamiento. ¿Mantiene tu listón de calidad con el razonamiento desactivado? Varios de estos modelos piensan antes de responder por defecto, y los tokens de razonamiento suman coste a cada tarea.
- Licencia. ¿Permite la licencia tu uso, incluido servir el modelo dentro de un producto comercial?
¿Están listos los modelos de lenguaje pequeños para los agentes empresariales?
Los modelos de lenguaje pequeños para agentes empresariales están listos para pasos estrechos, repetidos y verificables, una vez que cada uno se entrena y se evalúa con los ejemplos propios de la empresa. Aportan tres ventajas prácticas: menor coste por tarea, una latencia lo bastante baja para agentes que encadenan muchos pasos y libertad para elegir dónde se ejecuta el modelo, ya que un modelo pequeño cabe en la nube propia de la empresa o en sus instalaciones además de en un servicio gestionado. Los pasos de conversión del artículo también conllevan obligaciones empresariales: registros cifrados con acceso basado en roles y eliminación de los datos personales y sensibles antes de que se conviertan en datos de entrenamiento.
Los agentes empresariales siguen teniendo sitio para los modelos grandes. La conversación abierta, la planificación de muchos pasos y las solicitudes inusuales pueden quedarse en un modelo frontier mientras los especialistas entrenados asumen el volumen, que es el diseño heterogéneo que recomienda el artículo. Para ejecutar modelos pequeños en las instalaciones propias, consulta modelos de lenguaje pequeños para empresas. Para el enrutamiento entre modelos pequeños y grandes, consulta arquitectura SLM-first.
¿Cómo se pasa un agente de IA de un LLM a modelos de lenguaje pequeños?
Empieza por un paso repetido, regístralo y cámbialo cuando un modelo entrenado mantenga el listón en tu evaluación:
- Registra las solicitudes del agente al modelo. Guarda entradas, salidas y llamadas a herramientas de los pasos que se ejecutan entre bastidores, con controles de acceso y sin datos personales.
- Encuentra los pasos repetidos. Agrupa las solicitudes en tareas recurrentes, como la selección de herramientas, la extracción, la clasificación o el resumen de un tipo de documento.
- Elige primero la tarea verificable de mayor volumen. El volumen fija el ahorro, y una salida verificable fija un listón de calidad claro.
- Construye el conjunto de evaluación antes de entrenar. Reúne salidas esperadas para solicitudes reales y puntúa del mismo modo al modelo actual y a cada candidato.
- Entrena dos o tres tamaños y quédate con el más pequeño que mantenga el listón.
- Enruta ese paso al especialista. Mantén el modelo grande para el resto y reentrena cuando cambien las entradas del paso.
Esto sigue el algoritmo del artículo, con el conjunto de evaluación al principio. Para saber cuándo una tarea merece su propio modelo, consulta modelos fundacionales vs modelos específicos de tarea.
Ertas, un laboratorio de IA aplicada, ofrece para esto el endpoint de modelo adaptativo: un modelo entrenado con el trabajo de tus agentes, servido a través de una API compatible con OpenAI, con una evaluación previa a cada versión. Las nuevas versiones se entrenan en segundo plano con el tráfico de tus agentes, se puntúan con tus evaluaciones y solo pasan a producción con tu aprobación. Si una versión nueva se queda corta, el modelo actual sigue en servicio. Funciona gestionado por Ertas, en tu propia nube o en tus instalaciones, y tus datos siguen siendo privados. El endpoint es actualmente solo por invitación, y estamos desarrollando una versión más ágil para un acceso más amplio. Para ver cómo funciona el ciclo, consulta aprendizaje continuo para agentes de IA.
Preguntas frecuentes
¿Qué se considera un modelo de lenguaje pequeño?
El artículo de NVIDIA lo define por dónde se ejecuta: un modelo que cabe en un dispositivo de consumo común y responde lo bastante rápido para atender al agente de un usuario. En parámetros, sus autores sitúan el límite en unos 10.000 millones a 2025. Los proveedores usan la etiqueta con holgura, así que comprueba qué significa "pequeño" antes de comparar dos afirmaciones.
¿Pueden los modelos de lenguaje pequeños hacer llamadas a herramientas?
Sí. Qwen3.5, Gemma 4, Ministral 3, Granite 4.2 y SmolLM3 indican compatibilidad con llamadas a herramientas o funciones en sus fichas de modelo a octubre de 2026, y el artículo de NVIDIA cita a xLAM-2-8B de Salesforce como superior a GPT-4o y Claude 3.5 en llamadas a herramientas. Prueba el formato exacto que usa tu agente, y entrena con tus propios esquemas de herramientas si el modelo base se desvía de él.
¿Sustituirán los modelos de lenguaje pequeños a los LLM en los agentes de IA?
En muchos pasos, según el artículo, que estima que entre el 40% y el 70% de las consultas a LLM de tres agentes de código abierto podrían pasar a modelos pequeños especializados. Los modelos grandes conservan el trabajo abierto: la conversación, la planificación y la recuperación ante estados inesperados. El diseño que recomienda el artículo combina ambos.
¿Qué es un ejemplo de modelo de lenguaje pequeño?
Qwen3.5-4B, Gemma 4 E4B, Ministral 3 8B, Granite 4.2 3B y SmolLM3-3B son modelos de lenguaje pequeños con pesos abiertos. Un ejemplo específico de tarea es el resumidor de reuniones de 406M de nuestro estudio QMSum, entrenado para un único trabajo y publicado junto al artículo.
¿Son más baratos los modelos de lenguaje pequeños para agentes de IA?
Por token, normalmente sí: el artículo sitúa el coste de servir un modelo de 7B entre 10 y 30 veces por debajo del de un modelo de 70B a 175B en latencia, energía y cómputo. Por tarea, un modelo entrenado también envía menos tokens, porque las instrucciones que se repiten en cada prompt se entrenan en él. El coste total depende del volumen, ya que un modelo dedicado conlleva costes de entrenamiento y alojamiento. La calculadora de coste por tarea encuentra el punto de cruce con tus cifras.
En resumen
El artículo de NVIDIA sostiene que casi todo lo que un agente pide a un modelo de lenguaje es estrecho y repetido, y que los modelos pequeños entrenados para esos pasos son lo bastante capaces, más adecuados y más baratos. En una tarea concreta nuestros resultados coinciden: un modelo entrenado de 406M quedó dentro de la resolución del benchmark respecto a un modelo tres veces mayor, y ambos modelos entrenados superaron a cinco modelos propietarios alojados en ROUGE-1, con los límites indicados. Las preguntas abiertas son de ingeniería y de economía: el tamaño adecuado para cada paso, las optimizaciones que mantienen el listón y el volumen a partir del cual tu propio modelo sale más barato que una API. Tu propio conjunto de evaluación responde a cada una.
Para la comparación más amplia, consulta modelos open-weight vs frontier.
Fuentes, consultadas el 30 de octubre de 2026: Belcak et al., "Small Language Models are the Future of Agentic AI" (arXiv 2506.02153v3, 22 de septiembre de 2026) y su página en NVIDIA Research; fichas de modelo de Qwen3.5-4B, Gemma 4 E4B, Ministral 3 8B, Granite 4.2 8B, Nemotron 3 Nano 4B y SmolLM3-3B. Nuestra investigación: el estudio QMSum y el informe de OpenRouter sobre tareas estructuradas.

