SLM vs LLM: ¿Qué tamaño de modelo necesita tu empresa?

Por Ben Van Every, CEO de ALGO

Pregunta a la mayoría de los equipos cómo eligieron su modelo y, si son sinceros, la respuesta suele ser: el que empezaron utilizando.

Normalmente se trata de un modelo grande. Consiguió que la demo funcionara, así que permanece en producción mucho después de que alguien se haya planteado si sigue siendo la herramienta adecuada para ese trabajo.

La pregunta suele formularse así: ¿deberíamos utilizar un modelo pequeño o uno grande?

Pero esa no es la pregunta correcta. La pregunta adecuada es:

¿Cuál es la arquitectura de modelos menos compleja capaz de alcanzar en producción el nivel necesario de rendimiento, fiabilidad, velocidad, control y sostenibilidad económica?

En la mayoría de los sistemas en producción, la respuesta no será un único modelo. Será una arquitectura híbrida: código determinista para lo predecible, un modelo pequeño para tareas acotadas y de gran volumen, un modelo grande para aquello que exige gestionar ambigüedad y una persona responsable allí donde las consecuencias sean más relevantes.

Llegar a esa arquitectura exige tomar la decisión de forma deliberada, no por inercia.

La especialización hay que justificarla

Un modelo de lenguaje pequeño, o SLM, no es simplemente un modelo de lenguaje grande más barato. Es una apuesta diferente: una capacidad más acotada a cambio de menor coste, menor latencia y mayor control. Y esa apuesta solo compensa cuando se cumplen determinadas condiciones.

Un modelo pequeño tiene sentido cuando la tarea está suficientemente acotada como para especializarla, se repite con suficiente frecuencia como para justificar la optimización y puede medirse con suficiente claridad como para gestionarla adecuadamente.

En la práctica, esto significa que el alcance está bien delimitado, la operación se repite, la corrección puede evaluarse frente a criterios acordados, el volumen hace que la eficiencia sea relevante y la organización tiene capacidad real para desplegar, monitorizar y mantener el modelo una vez que está en producción.

Un modelo grande suele seguir siendo más adecuado cuando el trabajo es abierto, ambiguo, poco frecuente, cambia rápidamente o depende de razonamiento entre distintos dominios. Por ejemplo, una tarea de asesoramiento en la que la conversación salta de forma impredecible entre cuestiones comerciales, técnicas y operativas, o una tarea de planificación en la que el razonamiento adecuado depende de circunstancias que nadie pudo anticipar durante el diseño.

Trasladar ese tipo de trabajo a un modelo pequeño no supone automáticamente una mejora, aunque el modelo obtenga resultados adecuados en las pruebas. Dividir una carga de trabajo entre varios modelos especializados puede limitarse a trasladar la complejidad a otro lugar: más endpoints, más pipelines de despliegue, más versiones, más evaluaciones y más componentes que alguien debe gestionar.

Un modelo que cuesta menos por petición puede hacer que el sistema completo sea más caro de operar.

Por eso la comparación debe hacerse a nivel del modelo operativo, no de la ficha del modelo.

El objetivo no es utilizar el modelo más pequeño posible. Es utilizar el modelo más pequeño que supere el umbral necesario para producción.

Ya hemos aplicado este mismo principio a la autonomía: utilizar la arquitectura menos autónoma capaz de conseguir el resultado requerido. El tamaño del modelo responde a la misma disciplina, aplicada un nivel más abajo.

Seis preguntas antes de mirar una ficha de modelo

Antes de comparar benchmarks, conviene responder a seis preguntas, y hacerlo en este orden. Saltarse alguna es una buena forma de acabar con una decisión que parece razonable sobre el papel, pero falla al llegar a producción.

1. Valor de negocio

¿Qué proceso, servicio o decisión va a mejorar y con qué frecuencia se ejecuta?

Una tarea muy acotada que se realiza de forma esporádica difícilmente justificará el coste de especializar un modelo, por muy atractiva que resulte técnicamente de forma aislada.

2. Características de la tarea

¿Está claramente definido el alcance? ¿Son consistentes los inputs? ¿Están estructurados los outputs?

Hay una prueba sencilla que resulta útil: ¿podría una persona competente describir en una sola página la tarea, sus inputs, sus outputs y sus principales modos de fallo?

Si la respuesta es no, probablemente la tarea todavía no esté suficientemente acotada para un modelo pequeño.

3. Rendimiento necesario

La pregunta no es:

«¿Qué tal funciona este modelo pequeño en general?»

La pregunta es:

«¿Supera el umbral requerido para esta tarea concreta y con los datos de esta organización?»

4. Despliegue y control

¿Existe una necesidad real de ejecución local, baja latencia o menor dependencia de la nube?

¿O se trata simplemente de una opción técnicamente atractiva que nadie ha sometido todavía a una prueba seria?

5. Economía completa

¿Sigue siendo más barato el modelo pequeño cuando se incluyen la evaluación, la infraestructura, la monitorización, la seguridad, el reentrenamiento y las llamadas de respaldo al modelo grande que seguirá necesitando en algunos casos?

6. Preparación de la organización

¿Quién será responsable del modelo una vez desplegado?

¿Qué ocurre cuando su rendimiento empieza a deteriorarse?

Si no existe una respuesta clara, probablemente todavía no sea el momento de pasar a un modelo pequeño.

Cuando se responden estas preguntas con rigor, el patrón suele aparecer rápidamente. Una tarea acotada, de gran volumen y bien instrumentada es una candidata sólida. Una tarea amplia, de bajo volumen y mal medida todavía no lo es, por muy bien que haya funcionado la demo.

Evalúa el umbral, no la media

La comparación que importa no es cómo rinde el modelo pequeño frente al grande en benchmarks generales. Lo que importa es si el modelo pequeño alcanza el nivel que exige esa tarea concreta.

Construye un conjunto de evaluación específico a partir de ejemplos reales de producción: casos normales, casos difíciles y modos de fallo conocidos. Como mínimo, evalúa la precisión, la consistencia entre distintos inputs, el cumplimiento de instrucciones, el cumplimiento del formato esperado, la latencia y la capacidad para detectar outputs inválidos o de baja confianza.

Compara al menos tres opciones: el modelo grande actual o propuesto, un modelo pequeño estándar y, cuando esté justificado, una versión adaptada.

Un modelo que cuesta menos por llamada, pero genera habitualmente outputs que alguien tiene que corregir, no es realmente más barato.

Simplemente ha trasladado el coste de la factura de inferencia a la tarde de trabajo de una persona.

Calcula el coste del modelo operativo, no solo el de la inferencia

Un menor coste por token no implica automáticamente un menor coste total.

Un modelo grande alojado por un proveedor implica consumo de API, volumen de tokens, límites de uso, integración, monitorización y dependencia del proveedor. Un modelo pequeño puede implicar selección del modelo, infraestructura o capacidad en dispositivo, ingeniería de despliegue, evaluación, monitorización, seguridad y reentrenamiento. Además, seguirá necesitando llamadas de respaldo a un modelo grande para aquellos casos que realmente no pueda resolver.

Hay también un argumento en sentido contrario que merece tomarse en serio. Un gran modelo alojado de forma centralizada puede aprovechar mejor la infraestructura que una colección dispersa de endpoints especializados.

Un modelo pequeño puede resultar más barato por inferencia y, aun así, ser más caro en conjunto si la demanda nunca alcanza el volumen necesario para justificar su operación.

Por eso conviene realizar la comparación en varios escenarios: volumen actual, volumen esperado, diez veces el volumen actual y una adopción inferior a la prevista.

La pregunta útil no es:

«¿Es más barato hoy el modelo pequeño?»

Es:

«¿A partir de qué volumen pasa a ser más barato y es realista pensar que llegaremos a ese volumen?»

Puntúalo antes de comprometerte

Las seis preguntas anteriores permiten determinar si merece la pena investigar un modelo pequeño. Convertir ese análisis en una puntuación sencilla permite comparar distintas tareas candidatas sin tener que replantear desde cero las mismas seis cuestiones para cada carga de trabajo.

Puntúa cada dimensión de 1, caso débil, a 5, caso sólido:

Por encima de aproximadamente 24 sobre 30, existe un caso sólido para realizar una evaluación específica de un modelo pequeño.

En la zona intermedia puede tener sentido una arquitectura híbrida, con el modelo pequeño gestionando los casos estándar y un mecanismo de respaldo para el resto.

Por debajo de aproximadamente 15, conviene mantener el modelo grande o rediseñar primero el flujo de trabajo antes de modificar la arquitectura de modelos.

La puntuación debe servir para estructurar la discusión, no para sustituir las evidencias. Nada debería pasar a producción únicamente porque haya obtenido una determinada puntuación.

Construye una arquitectura de routing, no un único modelo

Una carga de trabajo rara vez necesita un solo modelo de principio a fin. Necesita una jerarquía.

Código determinista para todo aquello que responda a reglas explícitas y estables: validaciones, cálculos, permisos o estado del flujo de trabajo.

Un modelo pequeño para tareas de lenguaje acotadas: clasificación, extracción, reranking, resúmenes estructurados o selección de herramientas.

Un modelo grande para aquello que realmente requiere una comprensión amplia, resolver ambigüedad o desarrollar razonamiento en varios pasos.

Revisión humana cuando las consecuencias, la incertidumbre o la novedad lo justifiquen.

Código primero cuando sea posible.

Un modelo pequeño cuando sea suficiente.

Un modelo grande cuando sea necesario.

Una persona cuando esté justificado.

La ruta de migración si ya tienes un LLM en producción

La mayoría de las organizaciones no eligen entre modelos pequeños y grandes desde el primer día. Empiezan con un modelo grande para entender cómo se comporta realmente el flujo de trabajo y después utilizan los datos obtenidos en producción para identificar qué merece la pena especializar.

El patrón se repite en la mayoría de las cargas de trabajo que vemos:

1. Instrumenta lo que ya tienes. Registra el tipo de tarea, input, output, latencia, coste, llamadas a herramientas, correcciones humanas y causa de los fallos.
2. Agrupa la carga de trabajo. Clasifica las peticiones en categorías recurrentes en lugar de tratar cada llamada como algo único: clasificación, extracción, resumen, routing o gestión de excepciones.
3. Prioriza candidatos. Busca patrones de alto volumen y estables, con outputs medibles, un coste relevante asociado al modelo grande y una complejidad de razonamiento reducida.
4. Establece la referencia. Mide la calidad, latencia, coste y tasa de fallos del modelo actual específicamente para esa tarea antes de cambiar nada.
5. Prueba un modelo pequeño estándar antes de construir o adaptar uno. El ajuste fino, o fine-tuning, es un paso posterior, no el primero.
6. Adapta solo cuando la diferencia lo justifique, y únicamente si existe suficiente información representativa para hacerlo correctamente.
7. Introduce routing con un mecanismo de respaldo. Envía cualquier caso de baja confianza, fuera de dominio o identificado como de alto riesgo de vuelta al modelo grande o a una persona.
8. Monitoriza y amplía de forma deliberada. Tasa de éxito, tasa de fallback, latencia, deriva y coste por resultado satisfactorio. Amplía la cobertura únicamente cuando las evidencias lo justifiquen.

Distintas organizaciones, distintos puntos de partida

No existe un punto de partida adecuado para todos.

Las grandes empresas con cargas de trabajo recurrentes de gran volumen, capacidades de datos maduras y un gasto relevante en inferencia presentan el caso más sólido para la especialización. También son las que corren un mayor riesgo de acabar con una proliferación descontrolada de modelos pequeños sin estándares comunes ni responsabilidades claramente asignadas.

Las administraciones públicas suelen tener motivos reales para requerir despliegue local o soberano y una elevada capacidad de auditoría. Ejecutar un modelo localmente no elimina la necesidad de gobernanza, control de acceso y supervisión humana. Simplemente cambia el lugar donde deben situarse esos controles.

Las pymes deberían ser prudentes antes de asumir que alojar un modelo en infraestructura propia será automáticamente más barato. Sin suficiente volumen o capacidad especializada de mantenimiento, un modelo grande alojado por un proveedor y correctamente instrumentado suele ser un punto de partida más sensato.

La especialización selectiva puede incorporarse después, cuando los datos demuestren que existe realmente un patrón estable y de gran volumen.

El filtro antes de llevar un modelo pequeño a producción

Antes de aprobar un modelo pequeño para producción, la respuesta debería ser afirmativa a todas estas preguntas:

• ¿Existe una razón medible para alejarse del modelo grande y un punto de equilibrio realista que lo justifique?
• ¿La tarea es acotada y estable, con excepciones identificables?
• ¿Se ha probado el modelo con datos representativos frente a un umbral acordado y pueden detectarse los outputs de baja confianza?
• ¿Se ha descompuesto el flujo de trabajo y definido un mecanismo de respaldo, en lugar de entregar todo el proceso a un único modelo?
• ¿Existen registros, monitorización, una responsabilidad clara y un proceso de gestión de incidentes?
• ¿El acceso a los datos, los límites del despliegue y la supervisión humana son proporcionales a las posibles consecuencias?

Varias respuestas negativas no significan que haya que descartar la especialización. Significan que conviene mantener el modelo grande, rediseñar el flujo de trabajo o ejecutar primero un piloto controlado.

En resumen

En la mayoría de los sistemas maduros en producción, la respuesta no es «modelo pequeño» o «modelo grande».

Es una arquitectura híbrida gobernada que asigna cada tarea al modelo menos complejo capaz de realizarla de forma fiable, utilizando código determinista y revisión humana allí donde sean, sencillamente, herramientas más adecuadas.

Es la misma disciplina que aplicamos a la economía de la IA y a la arquitectura de producción de forma más amplia: empezar por el resultado de negocio, diseñar el sistema completo alrededor de él, incorporar la gobernanza que exijan las posibles consecuencias y dejar que sean las evidencias obtenidas en producción las que determinen qué debe ejecutarse dónde, no una clasificación de benchmarks.

En ALGO, la selección del modelo es solo una parte de una disciplina más amplia que incluye ingeniería de software, datos, cloud, DevOps, ciberseguridad, monitorización y soporte operativo. Son estas capacidades, en conjunto, las que permiten mantener fiable un sistema de IA en producción después de su lanzamiento, no solo conseguir que resulte impresionante el día de la demo.

Porque el objetivo nunca fue elegir el modelo más grande.

Ni tampoco el más pequeño.

El objetivo era construir un sistema que hiciera bien su trabajo.

¿Quieres hablar sobre tu arquitectura de modelos?

Si estás utilizando un único modelo grande para una carga de trabajo que ya ha superado lo que esa arquitectura puede gestionar adecuadamente, o estás intentando determinar si un modelo más pequeño y especializado funcionaría de forma fiable en tu entorno de producción, ponte en contacto con nosotros.

Email: info@algocodingexperts.com
Teléfono: +34-91-633-1884
Formulario de contacto.

Sobre ALGO

ALGO es un socio de ingeniería especializado en tecnologías avanzadas.

Ayudamos a startups, pymes, grandes empresas y administraciones públicas a diseñar, desarrollar e integrar sistemas tecnológicamente exigentes preparados para funcionar en el mundo real.

Nuestro trabajo combina conocimiento tecnológico especializado con las capacidades de software, datos, cloud, DevOps, ciberseguridad, UX, QA, integración, monitorización y operación necesarias para convertir tecnologías avanzadas en sistemas completos, fiables y sostenibles.