Gemma 4 26B en un Xeon viejo

Un modelo de 26 mil millones de parámetros corriendo en un servidor con 13 años encima, sin GPU, y aun así entregando alrededor de 5 tokens por segundo. Esa es la clase de prueba que te obliga a bajar a tierra varias ideas sobre IA local. Porque una cosa es hablar de costo por millón de tokens y otra muy distinta es ver qué pasa cuando el hardware ya no es nuevo, la memoria no sobra y el presupuesto para aceleradores simplemente no existe.

Este experimento, basado en el caso publicado por NeoMind Labs, no sirve para decirte que todo modelo grande debe correr en CPU. Sirve para algo más útil: te ayuda a medir el piso real de la IA local cuando el entorno es austero. Si tú trabajas con infraestructura heredada, con servidores de segunda mano o con despliegues en empresas donde comprar una GPU no entra en el plan, este tipo de prueba te da referencias concretas para decidir qué sí vale la pena intentar y qué no.

Qué se probó y por qué importa

La idea central fue simple: ejecutar Gemma 4 26B en un Xeon de hace 13 años, sin GPU dedicada, y ver si el sistema podía sostener una velocidad usable. El resultado reportado fue cercano a 5 tokens por segundo. No es una cifra para competir con una GPU moderna, pero tampoco es un número simbólico. Para ciertas cargas, especialmente asistentes internos, resúmenes cortos o tareas por lotes, esa velocidad puede ser suficiente.

Lo interesante no es solo el rendimiento bruto. También importa el contexto: hardware viejo, probablemente con limitaciones de memoria y ancho de banda, y un modelo que ya de por sí exige bastante. En escenarios reales de LatAm, eso se parece más a una empresa mediana reciclando servidores que a un laboratorio con presupuesto de hyperscaler. Por eso este caso conecta con una pregunta muy práctica: ¿cuánto puedes estirar una máquina vieja antes de que la IA local deje de tener sentido?

Por qué 5 tokens por segundo no es una cifra menor

Cinco tokens por segundo no suena espectacular si vienes de benchmarks con GPU. Pero en CPU pura, y más en una plataforma antigua, esa cifra cambia el cálculo. Si tu salida promedio es de 100 tokens, estás hablando de unos 20 segundos solo de generación, sin contar prompt, carga del modelo ni postprocesado. Para un chat interactivo puede sentirse lento, pero para una tarea de back office puede ser perfectamente aceptable.

El punto clave es que la latencia no siempre mata el caso de uso. Si el modelo responde a una solicitud interna de clasificación, extracción o borrador, esperar 15 o 25 segundos puede seguir siendo mejor que pagar infraestructura nueva. En cambio, si quieres una experiencia tipo copiloto en tiempo real, 5 tokens por segundo ya te deja fuera de juego. La misma cifra puede ser útil o inútil según el producto.

Qué te dice esto sobre el hardware viejo

Un Xeon de 13 años no está pensado para correr LLMs modernos. Su arquitectura, su caché, el subsistema de memoria y la ausencia de aceleración moderna ponen un techo claro. Aun así, el hecho de que el sistema arranque y produzca texto útil demuestra que la barrera de entrada para IA local es más baja de lo que mucha gente asume.

Eso tiene implicaciones directas para empresas en Ecuador, Perú, Colombia, México o cualquier mercado donde el CAPEX se mira con lupa. Si ya tienes servidores apagados o subutilizados, tal vez no sea necesario comprar hardware nuevo para ciertos pilotos. Primero puedes probar con lo que existe, medir latencia, consumo y estabilidad, y recién después decidir si vale la pena invertir.

Qué necesitas para intentar algo parecido

No cualquier máquina vieja sirve, pero tampoco necesitas una granja de servidores. El experimento demuestra que el primer filtro no es la edad del CPU, sino la combinación entre memoria, tipo de modelo y expectativas de uso. Si el modelo cabe, si la inferencia no se ahoga y si aceptas una latencia moderada, la prueba tiene sentido.

Para ordenar la idea, piensa en tres variables: tamaño del modelo, ancho de banda de memoria y calidad del runtime. En CPU, esos tres factores pesan más de lo que suele admitir la conversación comercial sobre IA. La GPU acelera mucho, sí, pero la ausencia de GPU no siempre significa imposibilidad.

Cuantización y memoria: el primer filtro real

Si tú intentas correr un modelo grande en CPU, la cuantización no es un detalle técnico menor. Es la diferencia entre cargar el modelo o quedarte mirando un error de memoria. En la práctica, formatos más compactos permiten probar en hardware que sería descartado con un modelo en precisión alta.

La otra pieza es la RAM. No basta con que el modelo entre por poco. También necesitas espacio para el contexto, el runtime y el sistema operativo. Cuando ese margen es estrecho, la máquina empieza a pagarlo con swapping o con una caída brutal en velocidad. Ahí es donde una prueba como esta deja de ser teórica y se convierte en una medición de viabilidad real.

Runtime y formato de inferencia

No todos los entornos de ejecución se comportan igual en CPU. Algunos priorizan compatibilidad, otros velocidad, otros facilidad de despliegue. Si quieres replicar un caso parecido, conviene revisar la documentación oficial del runtime que uses y del modelo que vayas a cargar. Por ejemplo, la documentación de llama.cpp es útil para entender opciones de cuantización y ejecución en CPU, mientras que la de Gemma te ayuda a ver el ecosistema oficial del modelo.

También vale la pena revisar cómo el sistema maneja el contexto y el batch size. En CPU, pequeños cambios de configuración pueden mover bastante la aguja. No siempre vas a ganar más velocidad por subir núcleos; a veces el cuello de botella está en memoria o en cómo el backend reparte la carga.

Qué significa para costos, latencia y despliegue

Aquí está la parte que más le importa a quien toma decisiones. Si puedes correr un modelo grande en hardware viejo, aunque sea a 5 tokens por segundo, entonces el costo inicial baja mucho. No estás comprando una GPU de miles de dólares para validar una idea. Estás reutilizando activos existentes o comprando un servidor usado a una fracción del precio.

Pero el ahorro no es gratis. Lo pagas con latencia, menor concurrencia y más cuidado operativo. Una sola consulta puede ser tolerable; varias a la vez pueden saturar el sistema. Por eso este tipo de despliegue funciona mejor cuando el patrón de uso es predecible y no necesitas cientos de usuarios simultáneos.

Cuándo sí tiene sentido

Hay escenarios donde 5 tokens por segundo en CPU es suficiente:

1. Resumen de documentos internos que no requieren respuesta instantánea.
2. Extracción de campos de facturas, contratos o tickets.
3. Clasificación de texto en lotes fuera de horario pico.
4. Asistentes internos con pocas consultas por minuto.
5. Prototipos para validar producto antes de comprar GPU.

En estos casos, el valor no está en la velocidad absoluta sino en el costo total de la prueba. Si el sistema funciona con el hardware que ya tienes, puedes validar flujo, precisión y aceptación del usuario antes de escalar.

Cuándo no vale la pena

Si tu producto promete respuestas casi inmediatas, una CPU vieja no te va a salvar. Tampoco si necesitas alta concurrencia o ventanas de contexto muy largas con múltiples usuarios. En ese escenario, la latencia se acumula y la experiencia se vuelve difícil de sostener.

También hay que mirar el costo oculto de la operación. Un servidor viejo puede ser barato de comprar, pero más caro de mantener si consume más energía por token generado, si falla más seguido o si necesita intervención manual. El precio del hardware no es el único número que importa.

Lecciones prácticas para equipos en LatAm

Este experimento es útil porque se parece a la realidad de muchas empresas de la región. No todo equipo tiene acceso a GPUs nuevas. No todo proyecto tiene presupuesto para cloud constante. Y no siempre conviene pagar por capacidad ociosa si el uso será intermitente.

La lección principal es que la IA local no empieza en el hardware ideal, sino en el hardware disponible. Si tu objetivo es aprender, medir o automatizar tareas acotadas, un servidor viejo puede servir como banco de pruebas. Eso te permite responder preguntas concretas antes de invertir más.

Cómo evaluar tu propio caso en 5 pasos

1. Define la tarea exacta: chat, resumen, clasificación o extracción.
2. Mide la RAM libre real, no solo la instalada.
3. Prueba primero con un modelo cuantizado y un contexto corto.
4. Registra tokens por segundo, tiempo total y consumo de CPU.
5. Compara el costo de seguir en CPU frente a comprar o rentar GPU.

Si haces esto con números, la conversación cambia. Ya no discutes si la IA local “es viable” en abstracto. Discutes si tu caso concreto aguanta 12 segundos de espera, si el usuario final lo acepta y si el ahorro compensa la menor velocidad.

Un ejemplo realista de decisión

Imagina una empresa en Quito que quiere automatizar resúmenes de tickets internos. Tiene un Xeon antiguo en desuso, 64 GB de RAM y un flujo de 200 tickets al día. Si cada ticket tarda 15 o 20 segundos, el proceso sigue siendo viable si se corre por lotes. En cambio, si esos mismos tickets llegan a un agente humano en tiempo real, el cuello de botella ya no es técnico sino operativo.

Ese tipo de cálculo es el que este experimento ayuda a hacer. No te dice “sí” o “no” de forma universal. Te da una referencia para decidir con menos intuición y más datos.

Qué deberías medir si repites la prueba

Si tú quieres reproducir algo parecido, no te quedes solo con la velocidad promedio. Hay varias métricas que te conviene guardar desde el primer intento. La idea es que puedas comparar hardware, modelos y configuraciones sin depender de impresiones subjetivas.

Un registro mínimo debería incluir tiempo de carga, tokens por segundo, uso de RAM, temperatura del sistema y estabilidad en sesiones largas. Si el equipo aguanta bien una consulta corta pero se degrada después de 10 minutos, eso también es un dato útil. En producción, los problemas suelen aparecer por acumulación, no por una sola corrida.

Métricas que sí te conviene anotar

• Tiempo de arranque del modelo.
• Tokens por segundo en salida.
• Latencia del primer token.
• RAM usada durante inferencia.
• Uso promedio de CPU por núcleo.
• Temperatura y throttling si el equipo es viejo.
• Tasa de errores o cuelgues en sesiones largas.

Si además quieres comparar diferentes configuraciones, usa el mismo prompt, el mismo contexto y el mismo número de repeticiones. Sin eso, los números se vuelven difíciles de interpretar.

Tabla resumen

La conclusión práctica es sencilla: la IA local sin GPU no es una fantasía, pero tampoco es una solución universal. En hardware viejo puede funcionar, y ese “puede” ya es valioso porque abre una vía de prueba barata. Si tú estás evaluando despliegues con presupuesto ajustado, este tipo de benchmark te ayuda a decidir con menos riesgo.

Lo útil aquí no es celebrar que un Xeon antiguo todavía respira. Lo útil es entender cuánto puedes pedirle antes de que el sistema se vuelva incómodo, y si ese margen alcanza para tu caso de negocio. En LatAm, donde cada dólar cuenta y el hardware usado sigue teniendo vida, esa respuesta puede ahorrarte una compra innecesaria o, al revés, evitarte una falsa economía.