Hace solo dos anios la idea de ejecutar un modelo de lenguaje util en un dispositivo industrial era una aspiracion mas que una realidad. Los modelos abiertos grandes pedian servidores con decenas de gigabytes de memoria de GPU, y los pequenios eran curiosos pero demasiado limitados para tareas practicas. En 2025 esta ecuacion ha cambiado. Phi-3.5, Gemma 2, Llama 3.2 y los primeros Qwen 2.5 pequenios han demostrado que un modelo de 2 a 8 miles de millones de parametros, bien entrenado, puede resolver tareas concretas con calidad suficiente para produccion. Eso abre un espacio nuevo en el edge industrial donde la latencia, la soberania de los datos y el coste de conectividad hacen que lo local compense. Repaso donde encajan estos modelos en planta, donde no, y como se integran sin sumar complejidad innecesaria.
Que ha cambiado para los modelos pequenios
Hasta 2023 el termino SLM (Small Language Model) era casi peyorativo. Los modelos de 1 a 3 mil millones de parametros eran juguetes comparados con GPT-3.5 o Llama 1. Dos cosas han cambiado la percepcion. La primera es la calidad del corpus de entrenamiento: los modelos pequenios de 2024 y 2025 estan entrenados con datos cuidadosamente filtrados, con razonamiento sintetico y con refinamientos posteriores de calidad alta. Un modelo de 3.8 mil millones de parametros como Phi-3.5-mini rinde en tareas de razonamiento comparable a GPT-3.5 de hace dos anios.
La segunda es la madurez del entorno de ejecucion. Herramientas como llama.cpp, Ollama y vLLM han pulido la cuantizacion, la carga eficiente de pesos y el batching. Un modelo que antes requeria una GPU de 24 GB ahora corre en una CPU decente con 16 GB de RAM con latencias aceptables. Para tareas no interactivas, esto es suficiente. Para tareas interactivas a ritmo humano, una GPU modesta o un NPU integrado basta.
El punto fundamental es que un modelo pequenio bien usado en una tarea acotada rinde mejor que un modelo grande mal dirigido en la misma tarea. Si lo que quieres es clasificar texto, extraer campos, generar resumenes cortos o responder preguntas sobre documentos concretos, un modelo pequenio ajustado o con buen prompt rinde al nivel del caso de uso. Llevar un modelo grande al edge para hacer lo mismo es, en la mayoria de casos, desperdicio.
Por que el edge industrial les pega
Las plantas, almacenes y puntos de venta son entornos con tres restricciones que el edge atiende mejor que la nube. La primera es la conectividad: no siempre hay enlace estable a internet, y cuando lo hay es caro o lento. Un modelo local elimina la dependencia de conectividad para las tareas que puede resolver, y deja solo los casos raros para la nube.
La segunda es la latencia. Para un proceso industrial que depende de una lectura para actuar, que la respuesta tarde dos segundos porque el paquete tuvo que cruzar el oceano es un problema. Un modelo local responde en milisegundos. Esto vale sobre todo para tareas integradas en bucles de control donde la inferencia es parte del flujo de produccion.
La tercera es la soberania de datos. Muchas plantas tienen informacion sensible: diagramas, recetas, datos de clientes, cifras de produccion. Enviar esta informacion a un proveedor externo aunque sea para una tarea trivial tiene implicaciones de cumplimiento. Un modelo local mantiene los datos dentro del perimetro y simplifica la conformidad con NIS2, GDPR o requisitos sectoriales.
Estas tres restricciones se combinan de forma que el edge industrial es probablemente el mejor encaje natural para SLM. En un entorno de oficina tipica, donde hay conectividad buena y la soberania no aprieta tanto, la balanza se inclina mas facilmente hacia la nube.
Tareas donde ya funcionan bien
Hay un conjunto de tareas donde los SLM en el edge ya funcionan con calidad de produccion. La primera es la extraccion estructurada de datos desde texto libre (facturas, albaranes, partes, OCR de etiquetas): un modelo pequenio con prompt bien disenado extrae campos con tasas de acierto superiores al 95% en la mayoria de documentos industriales. La segunda es la clasificacion y enrutado de texto: un operario escribe un parte, el modelo decide si es incidencia critica, a que equipo pertenece o si es duplicado. Aqui la latencia del edge y la soberania juegan a favor.
La tercera es la generacion de resumenes cortos: un supervisor recibe decenas de lecturas de turno y un modelo pequenio las sintetiza en un resumen diario con los hallazgos importantes. La cuarta es la asistencia conversacional acotada tipo chatbot interno sobre procedimientos o manuales, con RAG sobre un corpus documental limitado. La calidad no es la de GPT-4, pero para consultas operativas estandar es mas que suficiente.
Donde los SLM fallan todavia
Los SLM se quedan cortos en razonamiento de varios pasos sobre problemas complejos: calcular secuencias largas, depurar codigo complicado, analizar texto legal con matices. La diferencia entre un modelo de 4 mil millones y uno de 70 mil millones es enorme y cualitativa. Tambien fallan en conversacion larga con mucho contexto porque las ventanas son mas pequenias y la coherencia se degrada cuando el historial se alarga.
Fallan tambien en cualquier tarea que requiera conocimiento amplio y actualizado (responder sobre actualidad, traducir jerga cultural, interpretar referencias recientes) y en generacion creativa libre: para material de marketing, texto literario o codigo original desde especificaciones abiertas, los modelos grandes siguen produciendo resultados claramente mejores.
Como se suelen desplegar
El patron de despliegue edge que se ve funcionar en 2025 tiene tres capas. En hardware, un equipo con CPU potente o GPU modesta (RTX 4060 o equivalente) con 32 a 64 GB de RAM: entre 1.500 y 3.000 euros por nodo edge. Para tareas con latencia baja o alta concurrencia, una GPU integrada reciente de AMD o Intel basta.
En la capa de ejecucion, Ollama o un servidor basado en vLLM. Ollama es comodo para empezar porque gestiona descargas, cuantizacion y sirve API compatible con OpenAI. vLLM escala mejor para alta concurrencia: bajo 10 peticiones por segundo Ollama basta, por encima conviene algo con batching agresivo. En aplicacion, el modelo se consume como API local con llamadas REST igual que contra la nube; la diferencia es solo la URL, lo que simplifica la migracion entre ambos lados.
En el fichero de configuracion de Ollama es comun ver ollama pull phi3.5:3.8b-mini-instruct-q4_K_M para descargar la version cuantizada, y despues curl http://localhost:11434/api/generate -d '{"model": "phi3.5:3.8b-mini-instruct-q4_K_M", "prompt": "Extrae numero de lote"}' para invocarlo.
Seleccion del modelo en 2025
Phi-3.5-mini rinde bien en razonamiento y tareas estructuradas, y su tamanio reducido lo hace ideal para CPUs sin GPU. Gemma 2 (en sus variantes de 2 y 9 mil millones) tiene buena calidad general con formato de instrucciones estable. Llama 3.2 destaca en tareas multilingues y tiene muy buen soporte en Ollama. Qwen 2.5 brilla en matiz de traduccion y conocimiento amplio.
Para espanol nativo, Llama 3.2 y Gemma 2 suelen ganar a Phi-3.5 (optimizado para ingles). La diferencia entre modelos en la misma banda de tamanio es pequenia; la inversion en ingenieria de prompt y evaluacion es lo que de verdad mueve la calidad. Conviene tener un conjunto de evaluacion propio con cincuenta o cien ejemplos reales y ejecutarlo contra cada candidato: ese conjunto vale mas que cualquier benchmark publico porque captura las peculiaridades del caso.
Cuando compensa
Mi criterio practico en 2025 es claro: si la tarea es acotada, de volumen alto y la latencia importa, el edge con SLM es la opcion correcta. Si la tarea requiere razonamiento complejo, conocimiento del mundo amplio o el volumen es bajo, la nube con modelo grande sigue siendo mejor. La clave es no pensar en modelo grande contra modelo pequenio como dicotomia, sino como herramientas distintas con casos distintos.
La arquitectura que mas veo funcionar es hibrida: un SLM en el edge para el 90% de peticiones rutinarias, y un respaldo a modelo grande en la nube para los casos dificiles que el modelo local marque como inciertos. Este patron combina lo mejor de ambos mundos: coste bajo, latencia baja y soberania para la mayoria, con un as en la manga para los casos raros.
El cambio cultural que falta es dejar de ver el modelo grande como respuesta por defecto. Muchos equipos empiezan con GPT-4 o Claude en la nube para cualquier cosa, simplemente porque es lo que conocen. Para una gran fraccion de casos industriales, un modelo pequenio local es mejor: mas rapido, mas barato, mas privado, y con menos dependencias. Aprender a distinguir que casos caen en cada lado es una competencia que vale la pena desarrollar, y que va a pesar mas en los proximos anios conforme los SLM sigan mejorando.
