Mi IA local en un contenedor de Proxmox iba 15 veces más lenta: Ollama contaba los núcleos del nodo, no los del CT

Quería probar si un modelo de lenguaje pequeño, corriendo en casa, podía hacer un trabajo sencillo: leer correos y sacar de ellos unos pocos datos (de qué va el correo, una fecha, un sitio, qué adjuntos importan). Nada de mandar los correos a ningún servicio de fuera.

Para probar sin comprar nada, monté un contenedor (CT) en uno de mis nodos Proxmox, sin tarjeta gráfica:

• Debian 13, 4 núcleos y 10 GB de RAM.
• Ollama, escuchando solo dentro del contenedor.
• El modelo Qwen 3.5 de 9B, en la versión comprimida q4_K_M (unos 7 GB).

Lo arranqué, le hice la primera pregunta y me fui a por un café. Al volver seguía escribiendo.

Lo que vi: 0,3 palabras por segundo

Una respuesta corta tardaba cuatro minutos y medio. Iba a unas 0,3 palabras por segundo. Sin gráfica no esperaba velocidad, pero aquello era demasiado lento incluso para un procesador normal.

Lo primero que miré fue la carga del contenedor, y ahí estaba la pista: los 4 núcleos al máximo, pero con una carga bastante mayor que 4. Había más trabajo pidiendo procesador del que el contenedor tenía.

El porqué: el contenedor no engaña a Ollama

Un contenedor LXC no es una máquina virtual. Comparte el núcleo de Linux con el servidor, y cuando le pones «4 núcleos» Proxmox no le está dando un procesador de 4 núcleos: le pone un límite de uso.

Pero muchos programas, al preguntar cuántos núcleos hay, siguen viendo los del servidor entero. Mi nodo tiene un procesador de 6 núcleos, y Ollama hizo lo lógico con lo que veía: abrió 6 hilos de cálculo.

Seis hilos repartiéndose cuatro núcleos no van un 50 % más lentos, van muchísimo peor. Al generar texto, los hilos tienen que ir sincronizados en cada paso: si uno se queda esperando su turno de procesador, todos los demás le esperan. El límite del contenedor los iba parando por turnos y el cálculo se arrastraba.

El arreglo: una línea en el Modelfile

Ollama deja fijar el número de hilos con el parámetro num_thread. Lo más limpio es crear una variante del modelo con ese ajuste, para no tener que pasarlo en cada llamada:

# Modelfile
FROM qwen3.5:9b-q4_K_M
PARAMETER num_thread 4

ollama create qwen-local -f Modelfile
ollama run qwen-local

Con eso pasó de 0,3 a unas 5 palabras por segundo: unas 15 veces más rápido. Las respuestas cortas pasaron de cuatro minutos y medio a 25 o 30 segundos.

Lo que vino después, con correos de verdad

Esos 25-30 segundos eran con preguntas cortas. Al probarlo con correos reales, con unas instrucciones largas y el texto entero del correo, cada uno tardó entre uno y dos minutos. Sin gráfica, el modelo tiene que «leer» todo lo que le mandas antes de empezar a contestar, y eso también se nota.

Y acertar, acertó mucho pero no todo: en una prueba de 20 correos se equivocó en 4, sobre todo al decidir si un correo era de los que había que tratar o no. Para un trabajo en segundo plano y sin prisa puede valer. Para algo que alguien espera en el momento, se queda corto con este equipo.

Lo que me llevé de esto

• Dentro de un contenedor, no te fíes de cuántos núcleos «ve» un programa. Si hace cálculo pesado, fija tú los hilos al número de núcleos que le has dado al CT.
• Si cambias los núcleos del contenedor, cambia también el num_thread y vuelve a crear la variante. Si no, vuelves al problema sin darte cuenta.
• Una carga mayor que el número de núcleos del contenedor, con todo al máximo, es la señal de que hay más hilos que procesador.
• Para medir, prueba con el trabajo real: con preguntas cortas parece mucho más rápido de lo que luego es.