- Gemma 4 26B-A4B corre a una velocidad cercana a la de lectura en un servidor de 2016 con un solo Intel Xeon E5-2620 v4, 128GB de DDR3 y sin GPU, gracias a la optimización de
ik_llama.cpp
- En el decoder pass de un LLM, el cuello de botella es el ancho de banda de memoria más que el cómputo, y la CPU pasa mucho tiempo esperando traer los siguientes pesos desde la RAM hacia la caché
--spec-type mtp, --cpu-moe, --merge-up-gate-experts, --run-time-repack y otros reducen los cuellos de botella en entornos DDR3 mediante decodificación especulativa MTP, enrutamiento MoE y disposición de memoria amigable con la caché- Según los logs, el requerimiento total de memoria es de 82,355MiB y, con el contexto completo de 262K, la caché KV ocupa unos 56GB, más que los ~25GB de pesos
- Herramientas de caja negra como
ollama carecen del soporte de modelos y de los controles finos necesarios; en hardware antiguo hace falta entender a fondo el motor de inferencia y la estructura de memoria para exprimir el rendimiento
Entorno de ejecución y cuello de botella principal
- El servidor de prueba es equipo reutilizado, con estas especificaciones: Intel Xeon E5-2620 v4 @ 2.10GHz, 8 núcleos, 16 hilos, AVX2, 20MiB de caché L3, 2MiB de L2, 128GB de DDR3 y sin GPU
- Esta CPU no soporta AVX-512, AVX-VNNI ni BF16, y tampoco tiene GPU integrada
- En la inferencia de LLM, el decoder pass que genera tokens uno por uno está limitado principalmente por el ancho de banda de memoria, no por la cantidad de cómputo
- Para calcular el siguiente token, hay que mover continuamente desde la RAM hacia la caché y los núcleos de la CPU los pesos que contienen el conocimiento aprendido del modelo; el procesador pasa más tiempo esperando ese traslado que haciendo la multiplicación de matrices
- Este tipo de “muro de memoria” (
memory wall) funciona como una barrera de rendimiento importante no solo en Xeon, sino también en equipos de alto desempeño como H100
Los controles de ejecución necesarios en lugar de herramientas de caja negra
- Si simplemente se ejecuta
llama-cli en un entorno con DDR3 y sin GPU, será muy lento, y todavía queda mucho espacio de mejora debido a optimizaciones pensadas para casos generales con GPU
ollama puede no tener el soporte de modelo necesario y no expone suficientes ajustes detallados como para sacar el rendimiento real en ejecución- En la práctica, la ejecución solo fue posible combinando múltiples flags expuestas por
ik_llama.cpp
- El conjunto principal de flags es el siguiente
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune
-sm graph -smgs -sas -mea 256 --split-mode-f32
-t 8 --parallel 8
--cpu-moe --merge-up-gate-experts
--flash-attn on --mla-use 3
--mlock --run-time-repack --no-kv-offload
Decodificación especulativa y optimización de MoE
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune usa el verificador 26B junto con un pequeño drafter MTP generado previamente--draft-max 3 fija un máximo de 3 tokens por draft, --draft-p-min 0.0 acepta cualquier probabilidad y --spec-autotune ajusta la longitud de la cadena según la carga de trabajo- Al generar cadenas largas de razonamiento, aunque el usuario solo vea una respuesta final corta, cada token de pensamiento oculto requiere un decoder pass completo
- En CPU, el costo de hacer streaming de los pesos del verificador hacia la caché es alto, y como las capas activas del drafter pequeño caben bien en la caché L3, la ventaja de la decodificación especulativa se vuelve mayor
- Gemma 4 26B-A4B tiene una estructura MoE donde se activan 8 expertos por token de un total de 128; de unos 25.2B parámetros en total, los parámetros activos son alrededor de 3.8B
--cpu-moe ajusta el enrutamiento a la jerarquía de caché de la CPU y reduce el cache thrashing que se produce al saltar constantemente entre 128 expertos, vaciar la caché y volver a traer datos desde la DDR3--merge-up-gate-experts fusiona la up projection y la gate projection dentro de cada experto en una sola multiplicación de matrices, y en los logs se confirma con fused_up_gate = 1-t 8 está ajustado a los 8 núcleos físicos; en una carga limitada por memoria, usar los 16 hilos SMT puede aumentar el costo de planificación más que el throughput
Fijación de memoria, reempaquetado y partición del grafo
--run-time-repack reorganiza las matrices de pesos justo antes de la inferencia para adaptarlas al layout de caché de la CPU, y en los logs aparece como Repacked 265 tensors- Esta opción paga unos segundos al inicio para reacomodar dentro de la RAM las tablas numéricas a un formato que la CPU pueda leer mejor, y así aprovechar al máximo el ancho de banda de memoria durante la generación real de texto
--mlock fija el modelo en RAM para impedir que el sistema operativo lo intercambie a disco- Si el límite de memlock del kernel no es suficiente, aparecen advertencias como
failed to mlock 27628376064-byte buffer y Try increasing RLIMIT_MEMLOCK; no es un problema del LLM en sí, sino de la configuración base de ulimit
--no-kv-offload omite la búsqueda de mover la caché KV a la GPU en entornos sin GPU y la mantiene en la RAM del sistema-sm graph intenta una partición del grafo de cómputo para dividirlo verticalmente y permitir que varios dispositivos de procesamiento o regiones de memoria calculen al mismo tiempo distintas partes de una misma capa- En esta ejecución, el log
Split mode 'graph' is not supported for Gemma4 external MTP hizo que se degradara de forma segura a una división por capas
-sas indica dividir la carga de trabajo entre sockets físicos de CPU o nodos NUMA, y --split-mode-f32 hace que los puntos intermedios que se vuelven a combinar tras la división usen precisión de coma flotante de 32 bits
Attention, uso de memoria y conclusión
- ikawrakow escribió kernels personalizados para procesar Flash Attention en CPU, permitiendo que funcione sin GPU en contextos pesados
--flash-attn on fusiona el softmax de attention y la multiplicación de matrices, evitando escribir físicamente en RAM la matriz completa de attention N×N y calculándola/consumiéndola en la caché en pequeños bloques--mla-use 3 activa Multi-Head Latent Attention para comprimir Key y Value de la caché KV en una representación latente más pequeña- En los logs aparecen
flash_attn = 1, fused_moe = 1 y fused_up_gate = 1, lo que muestra que esas optimizaciones sí se aplicaron
- Según el log de memoria, la suma total de todas las capas es de 81,607.46MiB, y la memoria necesaria para tensores del modelo y cachés es de 82,355MiB
- Con el contexto completo de 262K, los pesos ocupan unos 25GB y la caché KV unos 56GB, así que la caché KV es más grande que el modelo
- Esta configuración carga un MoE de 25B parámetros y realiza decodificación especulativa con un drafter MTP, generando texto a velocidad de lectura en un Xeon de 2016 con DDR3 y sin GPU
- La conclusión es que el cuello de botella para ejecutar localmente la IA moderna de pesos abiertos no está solo en el silicio, sino en entender cómo funciona el motor de inferencia y la estructura de memoria; con el fork correcto, una cuantización bien ajustada y comprensión de la arquitectura de memoria, también se puede correr en servidores antiguos
2 comentarios
Opiniones de Hacker News
Escribí esto por la frustración de no tener una buena forma de ejecutar el nuevo modelo Gemma 4 Drafter y de que las herramientas convencionales escondan los puntos de ajuste de rendimiento.
Al final logré ejecutar a velocidad de lectura un modelo MoE 26B reciente en un viejo servidor reciclado, sin GPU, con solo un Xeon E5-2620 v4 y 128GB de RAM DDR3.
También dejé enlazado al final un modelo cuantizado, pero no funcionará a menos que uses el fork mencionado de ik_llama-cpp, y para los detalles hay que ver otra publicación.
No soy ingeniero de machine learning y el servidor además está ocupado haciendo de caché de Nix, pero si hay preguntas puedo responder dentro de lo posible.
Mientras un hilo espera a la DDR3, otro hilo podría ejecutarse.
Tampoco termino de entender la explicación de
--cpu-moe. Si un experto tiene unos 4.0GiB de parámetros y el caché L3 es de solo 20MiB, parecería que ni optimizando el orden de los expertos se pueden cachear los parámetros de forma significativa.Además, como ya dijeron otros, solo algunos Intel Xeon E5-2xxx v4 soportaban DDR3, y según la documentación de Intel E5-2620 v4 no es uno de ellos.
Tiene doble Xeon y 128GB DDR3, con 2 × Xeon E5-2697 v2 para un total de 24 núcleos/48 hilos, así que en cantidad de núcleos sale mejor, aunque quizá la diferencia real no sea tan grande.
Es un equipo que está juntando polvo, así que Gemma a velocidad de lectura suena bastante prometedor.
Busca “chia farming” en Amazon, solo que ignorando las chia seeds.
Ahora el mismo equipo cuesta como 2.5 veces más, pero sigue siendo mucho más barato que una máquina DDR5 de generación actual.
https://www.amazon.com/dp/B095TRGCSX
Tengo
Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz, CPU en línea 0-31 y 128GB de RAM.Me pregunto si tener 8 ranuras DIMM realmente mejora el ancho de banda de memoria. Ahora mismo este pobre equipo solo se usa para ver YouTube.
Todavía no hemos llegado a ese punto, pero el destino final obvio cuando termine la burbuja actual es que los modelos abiertos ejecutándose en hardware y dispositivos locales serán “lo suficientemente buenos” para la mayoría de los usos.
Si eso pasa, podría desmoronarse por completo lo que hoy está ocurriendo en la industria tecnológica.
Cuando de verdad me atasque llamaré a la API de Claude, pero parece que un modelo local más tonto puede cubrir el 80% de lo que necesito.
Los lenguajes y las técnicas de programación no cambian tanto, así que espero poder usarlo al menos 5 años; y cuando optimicen modelos más inteligentes para la misma VRAM, entonces actualizo.
Me gusta esa dirección.
Si no lo hacen, mi suposición es que los laboratorios de IA actualmente venden sus modelos con pérdidas enormes, así que para Amazon usar computación de bajo margen quizá resulta menos atractivo que otros productos de alto margen.
Tal vez ni siquiera haga falta llegar a la ejecución local para que el estado actual colapse. Si a los laboratorios de IA se les acaba el dinero fácil y tienen que vender a precios por encima del costo real de ejecución, cualquiera que tenga capacidad de cómputo tendrá incentivo para ofrecer servicios de modelos abiertos más baratos a precios de mercado generales.
Todo el mundo va a tener modelos y capacidad de ejecutarlos, y por eso la escasez de GPU juega a su favor.
Su esperanza depende de que empresas grandes y pymes muevan todos sus procesos de trabajo a la nube, y de que los empleados compitan por consumir la mayor cantidad posible de tokens.
Un modelo “lo suficientemente bueno” sumado a privacidad y ahorro de costos a largo plazo resulta muy atractivo.
Irónicamente, cuanto mejor sea el entorno de ejecución general para agentes de programación, menor será el foso defensivo de servicios como Claude. Cuesta creer lo rápido que algunos modelos abiertos alcanzaron a modelos de punta en apenas unos meses.
El texto está bueno y además es técnicamente impresionante. Coincido en que hay que entender el pipeline de compilación y poder ejecutar esto en local.
Aun así, según la tarifa eléctrica, puede no ser económico. Los servidores viejos son poco eficientes energéticamente, y yo pensaba que un servidor Xeon antiguo consumiría unos 200W bajo carga; mientras tanto, ese mismo modelo está disponible en OpenRouter por 0.1/0.3 dólares por millón de tokens, a 76 tokens/segundo y con 262k de contexto.
Además, estos servidores hacen ruido. Aunque mi estimación de 200W probablemente era demasiado alta; tuve servidores Xeon viejos que sí consumían bastante, pero no recuerdo los modelos exactos.
Los servidores suelen ser ruidosos, aunque eso también depende de la configuración. Hay mucho hosting barato basado en estos chips y, sorprendentemente, son bastante eficientes en consumo.
Si corres una configuración parecida en un gabinete 4U con ventiladores lentos de 120mm, queda bastante bien.
Me alegra ver que otros también se están dando cuenta de esto. Estoy ejecutando Gemma 26B-A4B Q4 en un contenedor con un Xeon de 2012 y 16~24GB de RAM, y obtengo más o menos 8~12 tokens/seg
No se puede comparar con contextos grandes ni con ejecución en GPU, y el decodificador de imágenes de llama.cpp también es mucho más lento que en GPU, pero para tareas pequeñas de automatización o preguntas de conocimiento general está bien. Es lo bastante rápido como para poder seguir leyendo mientras responde, así que la espera se siente menor
La configuración es un build de
llama.cppcon OpenBLAS y OpenMP activados,OPENBLAS_NUM_THREADS=4,OMP_NUM_THREADS=4,unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL, cachéq8_0y un contexto de 8192Hay que buscar optimizaciones por CPU, como AVX2, y probé MTP un momento, pero no hubo mejora de rendimiento. También se puede ajustar el tamaño del lote de caché/contexto o bajar hasta Q2, y conviene evitar asignar demasiados hilos. Recomiendo empezar por los valores por defecto o con
llama-benchDurante las pruebas ejecuté
gemma4:e4b-it-q4_K_M, que cabe por completo en 11GB de VRAM, y superó los 50 tokens/seg. Un modelo así de pequeño no sirve mucho para programar, pero puede tener otros usosQuiero hacer algo tipo Wake-on-Use para usarlo como un ChatGPT personal. Tal vez se pueda poner una Pi como proxy y hacer que invoque un script de Wake-on-LAN, y algún día podría convertirse en un proyecto divertido de fin de semana
El LLM que dejo siempre encendido es
Gemma4:31b, una versión dense que ni siquiera entra a la mitad en una 2060 de 12GB; va muy lento, pero la calidad es buena, y como lo uso para procesamiento automático en cola, no me quedo mirando la salida. Tengo otra 2060, pero si conecto las dos la PC no logra hacer POSTEstuve considerando por un tiempo una Mac Studio Pro, pero al final terminé por este camino. Tengo una HP Z620 sin monitor con 192GB de RAM ECC, doble Xeon E5-2680 v2, Optane AIC, dos P102-100 con 10GB de VRAM, un SSD mínimo de arranque con Debian 12.6 y una versión vieja de CUDA fijada para soportar tarjetas Pascal
La uso de forma remota desde el sótano con AMT/meshcommander, levanto
llama.cppy el frontend, y luego accedo por la red local. He estado probando Talkie, Qwen 3.6 27b y medgemma, y escogiendo una cuantización adecuada, el rendimiento de GGUF en general fue bastante buenoEl costo total fue de menos de 500 dólares, aunque era un servidor que compré en eBay el año pasado, así que ahora podría ser distinto
Más adelante, si los LLM ternarios florecen, espero que este hardware viejo pueda en realidad alojar modelos densos de alta compacidad llenos de conocimiento. No importa si se desbordan hacia Optane por ser más grandes que la RAM de GPU, porque me importa más el conocimiento factual general que la velocidad
El plan final es dejarlo configurado y guardarlo en un bote de basura Faraday en el sótano, como un oráculo para “reconstruir la civilización” cuando el mundo se derrumbe. Claro que en una situación así la energía sería el problema, pero si este hardware es tan barato y la IA moderna ya resulta práctica tantas veces, vale la pena intentarlo
Lo más interesante del avance de la IA no es AGI ni el último modelo de cierto unicornio de IA, sino qué se puede ejecutar en local
Hace 6 años podías correr en una PC gamer potente modelos curiosos pero poco útiles; ahora puedes correr en una laptop M5 algo 100 veces mejor que eso
Si el mercado responde a la falta de memoria y el avance de Apple silicon sigue a este ritmo, lo que podremos ejecutar en local dentro de 6 años será muy interesante o muy aterrador
Tampoco sé qué significa eso para la valuación de las empresas de IA. Una vez hice una pregunta parecida a un empleado de una de esas empresas en un evento, y en vez de responder se fue por un cóctel
El negocio de la IA es intensivo en capital, como una fábrica antigua. Los centros de datos son caros, los modelos consumen mucha electricidad y el hardware interno tiene que reemplazarse cada 3~4 años
Modelos más pequeños y especializados van comiéndose los márgenes desde abajo. Para transcripción, voz o detección de imágenes no hacen falta modelos gigantes
No hay motivo para esperar márgenes altos como en el software tradicional, y la mayor parte de las ganancias de la IA termina yéndose al consumidor. Aun así, unas pocas empresas gigantes como Microsoft, Google, Amazon y Meta sí podrían buscar ventaja de costos mediante economías de escala
No hace falta una gama altísima como una 5080; con una GPU gamer decente ya puedes ejecutar modelos locales mejores que el estado del arte de inicios de 2025
Dependiendo de la tarea que quieras, puede que tengas que cambiar de modelo, y los modelos gigantes que sirven para todo siguen siendo terreno de los centros de datos
Pero la mayoría de la gente con trabajo de tiempo completo y dos hijos no tiene ni el tiempo ni la energía para parchear y dar mantenimiento. Los sistemas siguen volviéndose más complejos y también más propensos a errores. Es el viejo intercambio entre libertad y comodidad
La mayoría de los usuarios no sabe qué es un LLM ni cómo se ejecuta. Muchos usuarios de LLM simplemente usan lo que les dan en el trabajo, y hasta los usuarios un poco más avanzados parecen estar bien pagando una suscripción a OpenAI o Anthropic
Habrá una base pequeña pero comprometida de usuarios de modelos abiertos que prefieran LLM locales, pero el resto probablemente seguirá consumiéndolos de grandes proveedores. Podría parecerse a la elección de sistemas operativos hoy: una minoría usa Linux y la gran mayoría usa Windows, macOS o Chrome
Los juegos de hace 5~6 años se pueden comprar mucho más baratos y corren en hardware común. Pero la industria no se queda quieta durante 5 años, así que siguen saliendo programas nuevos que requieren hardware mejor
El resultado que el autor original reveló en los comentarios es de aproximadamente 12 tokens/seg
Es un esfuerzo mucho más impresionante de lo que pensaba que sería posible con este hardware, pero todavía está bastante por debajo del nivel necesario para una sesión interactiva satisfactoria.
Muchas veces cuestan entre 100 y 500 veces menos que los modelos de punta, y en algunos casos también son entre 2 y 5 veces más rápidos en tokens/seg.
Para uso en segundo plano, sería más que suficiente.
Funciona, pero no tiene el rendimiento necesario para trabajo serio.
El E5-2620 v4 es excelente. Lo he usado durante 10 años, e intenté actualizarlo, pero me detuve al ver los precios actuales.
Le puse 64GB DDR4 y una RX 9060 XT 16GB, y los juegos todavía corren rápido. En DOOM The Dark Ages, el CPU quizá sea un poco cuello de botella, pero a 60fps no hay problema.
Correr un LLM ligero en la GPU es la opción obvia, y está genial que en CPU también pueda ir bastante bien con algo de ajuste.
Hace un mes compré un 2667 v4 por 30 dólares y parece que sí habrá una mejora de rendimiento considerable, pero todavía no lo necesitaba. Como en el artículo, si lo fuera a empujar más hacia LLM, probablemente actualizaría, porque el 2667 puede manejar RAM un poco más rápida.
Todavía me sorprenden bastante las cosas que se pueden encontrar en el mercado de segunda mano.
No esperaba que los precios de la RAM y la GPU se dispararan tanto, así que tuve buena suerte con el timing. Incluso he pensado en cazar una 3080 por unos 300 dólares en eBay y vender la 1080 Ti, pero fuera de eso, ha sido una gran actualización.
Consume electricidad como Coca Cola, pero como workstation funciona de maravilla, así que pienso seguir exprimiéndola hasta que se descomponga.
Antes pensaba que el daño por calor terminaba matando a los CPU después de unos 5 a 7 años, y me pregunto si esa suposición era incorrecta. Quizá los CPU de hoy simplemente sean mucho más resistentes y duraderos que antes.
Hace poco hubo otra publicación parecida relacionada con optimización de Xeon antiguos.
“High-Performance AI on a Budget: Optimizing llama.cpp for Qwen3.5 Inference on a Dual-GPU HP Z440”
https://news.ycombinator.com/item?id=47320244
Sorprendentemente, Itanium también parece encajar bastante bien con los LLM: https://medium.com/@tglozar/running-llama-inference-on-intel...
Pensándolo bien, tiene sentido
Qué interesante el contenido. Tengo un sistema Xeon antiguo, así que voy a intentar probarlo.