Un patron conocido: el piloto de IA local corre en el portatil de un desarrollador, Ollama se instala en diez minutos, las respuestas llegan con fluidez. Luego se decide desplegarlo a treinta companeros, todos consultan a la vez, y de repente cada peticion se queda colgada. No es un fallo. Es la diferencia entre una herramienta para un usuario y un servidor para muchos.
Miramos Ollama hace poco desde otro angulo, cuando el ejecutor de modelos se convirtio en un agente local. Hoy no van de nuevas funciones. Va de una pregunta mas antigua que se esta volviendo practica para las pymes ahora mismo: que lleva la IA local de un escritorio a un departamento entero.
Del piloto a toda la plantilla
En un piloto suele probar una sola persona. Escribe una pregunta, espera la respuesta, escribe la siguiente. Esa secuencia de peticion y respuesta es justo el terreno donde Ollama se siente en casa. Instalacion sencilla, valores por defecto razonables, y funciona en un Mac Studio igual que en una estacion de trabajo con una GPU.
La produccion es otra cosa. Diez, veinte, cincuenta personas lo usan a lo largo del dia, muchas veces en oleadas, por la manana al revisar el correo o a ultima hora antes de irse. Lo que decide entonces no es la respuesta individual, sino cuantas peticiones atiende el sistema en paralelo sin que la espera se vuelva incomoda. Aqui es donde las herramientas se separan.
Por que Ollama brilla con un solo usuario
Ollama esta hecho para que una peticion tras otra pase limpia. Para el dia a dia de un solo usuario eso es ideal. No hay razon para montar nada mas complicado para un desarrollador que trabaja en local sobre codigo o textos. Si estas probando la IA local, sigue empezando por Ollama o LM Studio. El error solo aparece cuando el montaje del piloto se declara servidor del departamento sin cambiar nada.
La razon es de arquitectura. En su nucleo, Ollama procesa las peticiones una detras de otra. Si llegan cinco a la vez, cuatro esperan mientras se atiende una. Con un usuario eso no se nota nunca. Con veinte, la espera se convierte en el cuello de botella, y ninguna opcion de ajuste saca lo que el diseno no contempla.
Que muestra el benchmark de Red Hat
Cuanto se ensancha la brecha bajo carga lo midio Red Hat en agosto de 2025 en un benchmark muy citado, y la comunidad ha confirmado la direccion a lo largo de 2026. Sobre la misma tarjeta NVIDIA A100, con concurrencia de uno a 256 usuarios, vLLM alcanzo en su pico unos 793 tokens por segundo y Ollama unos 41. Eso es cerca de diecinueve veces mas.
Ese numero suele viajar sin la parte que importa. Con un solo usuario, el mismo benchmark deja a ambos en una franja de unos 130 a 180 tokens por segundo, practicamente empatados. La brecha se abre solo con la concurrencia: el rendimiento de vLLM siguio subiendo con el numero de usuarios mientras que el de Ollama se aplano casi de inmediato. La latencia conto lo mismo. A plena carga, el percentil 99 quedo alrededor de 80 milisegundos en vLLM y alrededor de 673 en Ollama, segun el informe.
En la practica: si hoy atiendes a una o dos personas, apenas notaras diferencia entre los dos. Si atiendes a un departamento, la diferencia es casi lo unico que notas.
Batching continuo, la diferencia real
Detras del numero hay una tecnica llamada batching continuo, combinada con una gestion eficiente en memoria de la llamada cache KV. Dicho simple: vLLM mete muchas peticiones en curso en un mismo flujo de procesamiento en la GPU y rellena la capacidad que se libera de inmediato con la siguiente peticion en espera. En lugar de una cola donde cada uno avanza solo, se forma una cinta transportadora que nunca se queda vacia.
Eso explica tambien por que vLLM no lleva ventaja con un usuario. Una cinta con un solo paquete no es mas rapida que un par de manos. El diseno solo rinde cuando muchos paquetes circulan a la vez. Asi que la eleccion no es bueno contra malo, es un usuario contra muchos.
Una nota sobre el hardware: vLLM despliega su ventaja en una GPU de servidor de verdad con suficiente memoria, clasicamente NVIDIA. Ollama tambien corre en Apple Silicon, y por eso mismo resulta tan comodo en un piloto. Planificar el paso a produccion suele implicar planificar tambien un paso de hardware.
La proteccion de datos no cambia
Importante para cualquier pyme bajo el RGPD: el cambio no altera nada en cuanto a los datos. Las dos herramientas ejecutan el modelo en local, las peticiones no salen del edificio. Elegir entre Ollama y vLLM es una cuestion de operacion y de rendimiento, no de soberania. Si usas inferencia local por motivos de proteccion de datos, conservas esa ventaja en ambos casos. Lo que lo enmarca en lo legal lo hemos reunido en nuestra pagina de soberania del dato.
Es una buena noticia, porque mantiene dos preguntas separadas. Primero: se quedan los datos en casa. Despues, y solo despues: aguanta la tecnologia el numero de usuarios. La IA local responde a la primera con cualquier herramienta. La segunda decide la arquitectura.
Que herramienta para cada fase
Un camino practicable para una empresa que se toma en serio la IA local suele verse asi:
- Piloto y puesto individual: Ollama o LM Studio. Rapido de montar, bueno para probar modelos y flujos, ideal en un Mac Studio que ya tengas.
- Equipo pequeno, pocos simultaneos: Ollama puede bastar cuando el uso rara vez llega en oleadas. Comprueba con honestidad donde caen los picos.
- Departamento o empresa entera: vLLM sobre una GPU dedicada, o una pila de servido comparable con batching. Aqui el montaje mas costoso se paga con tiempos de respuesta estables.
El error que mas vemos no es la herramienta equivocada en el piloto. Es el cambio que nunca llega despues. Un montaje pensado para una persona se declara solucion del departamento, y luego se busca el fallo en los modelos cuando esta en la construccion del servidor.
Para financiar el paso de hardware, en Espana conviene mirar el Kit Digital y sus categorias subvencionables segun el segmento de la empresa. Las cifras y la elegibilidad concreta pertenecen a un analisis individual, no a una entrada de blog.
La diferencia entre un piloto que funciona y una operacion que funciona rara vez es el modelo. Casi siempre es la capa de debajo la que decide si veinte personas pueden trabajar a la vez.
Tienes la IA local en piloto y te preguntas como es el paso a toda la plantilla? Nuestro proyecto piloto resuelve arquitectura, hardware y rendimiento sobre tu caso real, con criterios de aceptacion claros. Mas sobre el alcance en la pagina de IA local.