Cómo correr un LLM potente en una PC lenta

Si quieres correr un LLM local en una PC lenta, el problema no suele ser solo la CPU. Normalmente chocás con tres límites al mismo tiempo: memoria RAM, ancho de banda de memoria y tamaño del contexto. Por eso tanta gente prueba un modelo “liviano” y termina con un sistema que responde a tirones, se queda sin memoria o tarda demasiado en generar incluso una frase corta.

El caso de Colibri, el proyecto publicado en GitHub por JustVugg, muestra justo lo que más interesa hoy: no hace falta tener una workstation para experimentar con modelos modernos. Con ajustes concretos, un modelo grande puede adaptarse a hardware modesto y seguir siendo útil para tareas reales como autocompletado, resumen, clasificación o asistencia técnica. Eso cambia la conversación para equipos pequeños, freelancers y devs en LatAm que no quieren depender siempre de una API externa.

Qué hace posible correr un LLM en hardware modesto

La idea central es simple: no intentas mover el modelo tal como salió del entrenamiento. Lo adaptas para inferencia. Eso significa reducir precisión, recortar memoria usada en pesos y KV cache, y elegir un runtime que aproveche mejor tu CPU o una GPU vieja. En la práctica, el salto entre “no abre” y “sí corre” casi siempre viene de combinar varias técnicas, no de una sola.

La más conocida es la cuantización. En vez de guardar los pesos en FP16 o FP32, los pasas a formatos de menor precisión, como 8 bits, 6 bits o 4 bits. Menos precisión suele significar menos RAM y menos ancho de banda requerido. Según la documentación de llama.cpp, los formatos GGUF y sus variantes de cuantización están pensados justamente para facilitar ejecución local en distintos tipos de hardware: https://github.com/ggerganov/llama.cpp

Otra pieza clave es el offload parcial. Si tu CPU no alcanza, puedes mandar ciertas capas a GPU y dejar el resto en memoria del sistema. No siempre acelera de forma dramática, pero sí puede hacer que el modelo sea usable en una máquina que antes quedaba fuera. Esto es especialmente útil en equipos con GPUs antiguas de 4 a 8 GB, donde no entra un modelo completo pero sí una parte razonable.

También importa el contexto. Un modelo con ventana de contexto enorme consume más memoria para su KV cache, y eso pega directo en máquinas con 8 o 16 GB de RAM. Si tu caso de uso no necesita 128k tokens, bajar el contexto a algo más realista puede ser la diferencia entre una sesión estable y un crash.

Cuantización: el primer filtro real

La cuantización no es un truco cosmético. Es la razón por la que un modelo de varios gigabytes puede caber en una laptop o en una PC de escritorio vieja. En términos simples, comprime los pesos para que ocupen menos, aceptando una pequeña pérdida de calidad. En muchos casos de uso práctico, esa pérdida es menor que el beneficio de poder correr el modelo localmente.

Un ejemplo típico: un modelo de 7B en FP16 puede requerir alrededor de 14 GB solo para pesos, sin contar overhead. En 4 bits, ese mismo modelo puede bajar a una huella mucho más manejable. El número exacto depende del formato y del runtime, pero el patrón es ese: menos precisión, menos memoria, más chance de que arranque.

Offload, CPU y GPU vieja

Si tienes una GPU antigua, no la descartes de entrada. Muchas veces el cuello de botella no es la potencia bruta sino la VRAM disponible. Un modelo bien ajustado puede usar la GPU para acelerar capas concretas y dejar el resto en CPU. Eso no convierte una PC lenta en una bestia, pero sí puede reducir latencia y hacer viable el uso diario.

En CPU pura, el límite suele ser el ancho de banda de memoria. Por eso dos PCs con el mismo procesador pueden comportarse distinto según tengan RAM más rápida o mejor configuración. Para inferencia local, la memoria manda más de lo que muchos esperan.

Qué propone Colibri y por qué importa

Colibri parte de una idea práctica: si el modelo es demasiado grande para tu equipo, no solo necesitas una versión más pequeña. Necesitas una forma de empaquetar, cargar y servir el modelo con menos fricción. El valor del proyecto está en mostrar que la adopción de IA local no depende únicamente de tener el hardware ideal, sino de elegir bien el formato, el runtime y los parámetros.

Eso importa porque el mercado real no está lleno de máquinas nuevas. En LatAm, muchas veces trabajas con equipos reciclados, laptops de tres o cuatro años, o desktops que todavía sirven para desarrollo pero no para ejecutar modelos pesados sin ayuda. Si el stack local se vuelve más accesible, más gente puede probar IA sin pagar costos por token desde el primer día.

También cambia el flujo de trabajo de un equipo pequeño. Cuando el modelo corre localmente, puedes hacer pruebas offline, iterar más rápido y evitar exponer datos sensibles a un proveedor externo. Para un equipo de soporte, una consultora o una startup en fase temprana, eso puede ser más útil que tener la última arquitectura de moda.

La otra ganancia es operativa. Si el modelo vive en tu máquina, no dependes tanto de rate limits, caídas de servicio o cambios de precio. Eso no elimina los problemas de mantenimiento, pero sí te da control sobre el entorno. Y para muchos devs eso pesa más que una demo espectacular.

Qué cambia para devs y equipos pequeños

Para un dev individual, la ventaja es obvia: puedes experimentar sin montar infraestructura. Para un equipo pequeño, el efecto es más profundo porque permite probar casos de uso internos con menos costo inicial. Si tienes un equipo de 3 a 10 personas, no siempre puedes justificar una arquitectura con múltiples servicios, colas y gastos recurrentes desde el primer prototipo.

Hay otro punto menos visible: la privacidad. Si trabajas con documentos internos, tickets de clientes o código propietario, mover todo a un proveedor externo no siempre es la mejor opción. Un modelo local bien configurado puede resolver tareas concretas sin sacar datos de tu red.

Técnicas concretas que sí ayudan

No necesitas aplicar todo al mismo tiempo. De hecho, conviene pensar en una lista de prioridades y probar una por una. El orden correcto depende de tu hardware, pero en la mayoría de casos el camino más efectivo empieza por cuantización, sigue por contexto y termina con tuning del runtime.

1. Elige un modelo más chico antes de tocar parámetros. Un 7B bien afinado suele ser más útil que un 20B mal cargado en una PC limitada.
2. Usa un formato pensado para inferencia local, como GGUF, si tu stack lo soporta.
3. Prueba cuantización 4-bit o 5-bit antes de subir a 8-bit, porque el ahorro de memoria suele ser mucho mayor.
4. Reduce el contexto al mínimo que tu caso necesita. Si haces clasificación o resumen corto, no necesitas una ventana enorme.
5. Ajusta el número de threads al hardware real. Más threads no siempre significa más velocidad.
6. Si tienes GPU vieja, prueba offload parcial y mide. No asumas que CPU pura será mejor.

Aquí conviene medir con números y no con sensaciones. Un modelo que tarda 12 segundos por respuesta puede ser perfectamente usable para tareas internas. Uno que tarda 45 segundos ya empieza a molestar. La diferencia no siempre está en el modelo, sino en cómo lo sirves.

Cuantización sin romper el uso real

El error común es pensar que cualquier cuantización sirve para cualquier tarea. No siempre. Si vas a generar texto largo con precisión técnica, una cuantización demasiado agresiva puede degradar la calidad. Si vas a hacer extracción de datos, clasificación o respuestas cortas, normalmente puedes tolerar más compresión.

La forma correcta de decidir no es por intuición, sino con una mini batería de pruebas. Toma 20 prompts reales de tu trabajo, corre el modelo en dos o tres configuraciones y compara velocidad, calidad y estabilidad. En equipos pequeños, ese benchmark casero vale más que una tabla genérica de internet.

Cómo probarlo sin comprar otra PC

Si tu objetivo es validar si la IA local te sirve, no empieces por optimizar todo. Empieza por una prueba controlada en tu hardware actual. Eso te ahorra tiempo y te dice rápido si el cuello de botella es RAM, CPU, disco o simplemente mala elección de modelo.

Un flujo razonable para probar un LLM en una PC lenta sería este:

1. Identifica tu RAM total y tu GPU, si existe.
2. Elige un modelo que ya tenga variantes cuantizadas.
3. Descarga una sola versión, no tres a la vez.
4. Prueba con contexto corto y una tarea concreta.
5. Mide tiempo de primera respuesta y tokens por segundo.
6. Ajusta una sola variable por vez.

Si quieres referencias de formatos y compatibilidad, la documentación oficial de Ollama es útil para entender cómo se empaquetan y sirven modelos locales: https://docs.ollama.com/

También conviene revisar la especificación de GGUF en el ecosistema de llama.cpp, porque ahí se explica por qué este formato se volvió tan común para correr modelos en equipos modestos: https://github.com/ggerganov/llama.cpp/blob/master/gguf.md

Señales de que tu PC sí da para esto

Hay tres señales buenas. La primera es que el modelo carga sin swap excesivo. La segunda es que puedes sostener varias respuestas seguidas sin que el sistema se arrastre. La tercera es que el tiempo de respuesta, aunque no sea espectacular, se mantiene estable.

Si tu máquina empieza a usar disco como memoria de forma constante, ya perdiste rendimiento. Ahí no estás corriendo un LLM de forma eficiente, solo estás forzando al sistema a sobrevivir. En ese caso, bajar contexto o usar un modelo más pequeño suele rendir más que tocar cualquier otro parámetro.

Qué cambia en la adopción de IA local en LatAm

En Latinoamérica, el costo de hardware sigue siendo una barrera real. No todo el mundo puede comprar una GPU nueva, y muchas empresas pequeñas no tienen presupuesto para una infraestructura dedicada. Por eso, cualquier técnica que baje el umbral de entrada tiene impacto directo en adopción.

La IA local deja de ser un tema para laboratorios o empresas grandes y pasa a ser una herramienta de trabajo. Puedes usarla para documentación interna, asistentes de código, resúmenes de reuniones, análisis de tickets o generación de borradores. No reemplaza todos los flujos en la nube, pero sí te da una capa de autonomía.

También hay un matiz regional. En países donde la conectividad no siempre es estable o barata, tener un modelo local reduce la dependencia de internet. Y si trabajas con clientes que piden privacidad o cumplimiento, poder decir “esto corre dentro de nuestro entorno” pesa bastante.

Para Ecuador y otros mercados de la región, esto abre una puerta práctica: no necesitas esperar a renovar toda la flota para empezar a usar IA. Puedes rescatar hardware que ya tienes, ajustar expectativas y construir casos de uso concretos. Eso es mucho más útil que perseguir benchmarks que solo se ven bien en servidores caros.

Tabla resumen

Si te quedas con una sola idea, que sea esta: correr un LLM potente en una PC lenta no depende de magia, sino de recortar lo que no necesitas y medir lo que sí importa. La combinación correcta de modelo, cuantización, contexto y runtime puede convertir una máquina común en una herramienta útil para trabajo real.