Ejecutar LLM en local: una guía práctica para un solo portátil

Ejecutar un modelo de lenguaje en tu propia máquina solía ser un ejercicio de laboratorio de investigación. Ahora es un proyecto de fin de semana. La razón no es un único avance, sino la madurez de los modelos de pesos abiertos y de las herramientas a su alrededor. Esta guía se salta el bombo y explica lo que de verdad determina si la inferencia local te funciona: memoria, cuantización, herramientas y una idea realista de lo que ganas y lo que cedes.

Por qué ejecutar en local

Tres motivaciones honestas, más o menos en el orden en que se sostienen:

• Privacidad y control. Nada sale de tu máquina. Para notas sensibles, borradores, documentos de clientes o código interno, esa es una ventaja real que ninguna configuración en la nube replica del todo. No hay política de retención de datos que leer porque no hay datos que salgan.
• Coste con volumen sostenido. Si haces muchas llamadas y ya posees el hardware, el coste marginal es aproximadamente tu electricidad. Para volumen irregular o bajo, una API alojada suele ser más barata una vez que cuentas tu tiempo de configuración.
• Aprender y trastear. Ejecutar un modelo en local lo desmitifica. Ves los compromisos directamente —memoria, velocidad, calidad— en lugar de tras una API que los oculta.

Lo que no deberías esperar: el techo de los mayores modelos alojados. Los modelos locales han cerrado buena parte de la brecha para las tareas cotidianas, pero el razonamiento más difícil y el trabajo con el contexto más largo todavía favorecen a los sistemas frontera alojados. Entrar con esa expectativa es la diferencia entre quedar impresionado y quedar decepcionado.

El número que más importa: la memoria

La mayor restricción individual es cuánta memoria ocupan los pesos del modelo. Como regla general, la huella de un modelo escala con su número de parámetros multiplicado por los bytes usados por parámetro. Los pesos a precisión completa son grandes; el truco que hace viables los portátiles es la cuantización: almacenar los pesos a menor precisión (por ejemplo 4 bits en lugar de 16) para reducir la huella varias veces.

Lo que esto significa en la práctica, en términos sencillos:

• Un modelo pequeño (unos pocos miles de millones de parámetros) cuantizado a 4 bits cabe cómodamente en la memoria de un portátil moderno y funciona a velocidad utilizable.
• Un modelo de tamaño medio (aproximadamente el rango de 7 a 14B) cuantizado es el punto óptimo para muchos portátiles con memoria unificada o de GPU adecuada.
• Los modelos más grandes son posibles, pero se vuelven lentos o sencillamente no caben sin hardware serio.

En Apple Silicon, la memoria unificada se comparte entre CPU y GPU, y por eso esas máquinas rinden por encima de su categoría en inferencia local: la GPU puede direccionar un gran fondo de memoria. En una máquina típica de Windows o Linux, la memoria dedicada de la GPU suele ser el factor limitante, y un modelo que la excede o bien se desborda a la memoria del sistema, más lenta, o bien no consigue cargarse.

Cuantización: el compromiso en una sección

Menor precisión significa más pequeño y más rápido, a cierto coste de calidad. La buena noticia es que la pérdida de 16 bits a alrededor de 4 bits es, para la mayoría de las tareas cotidianas, menor de lo que la gente teme, a menudo apenas perceptible en uso normal. Baja mucho más de 4 bits y la degradación se vuelve evidente: el modelo empieza a perder coherencia, a saltarse instrucciones o a repetirse.

El consejo práctico es una regla simple: empieza con una cuantización de 4 bits del mayor modelo que quepa, y solo sube en precisión si puedes medir un problema de calidad en tus propias tareas. La mayoría de la gente nunca lo necesita. Perseguir mayor precisión "por si acaso" suele comprar nada más que un modelo más lento y una factura de memoria mayor.

Las herramientas, en breve

No necesitas compilar nada desde cero. Dos opciones maduras y bien documentadas dominan:

• llama.cpp: un motor de inferencia ligero y rápido que ejecuta modelos cuantizados de forma eficiente en CPU y GPU en todas las plataformas principales. Es la base sobre la que se construyen muchas otras herramientas, y vale la pena conocerlo aunque uses una capa por encima.
• Ollama: una capa más amigable que gestiona la descarga, los formatos de cuantización y un servidor local con unos pocos comandos. Para la mayoría de quienes empiezan, este es el camino de menor resistencia.

Los modelos en sí provienen de repositorios abiertos como Hugging Face, donde las publicaciones de pesos abiertos se distribuyen con sus licencias adjuntas. Lee la licencia antes de cualquier uso no personal: "pesos abiertos" no siempre significa "libre para uso comercial", y los términos varían más de lo que la gente supone.

Una primera ejecución realista

Una secuencia inicial sensata, sin comprometerse con versiones concretas que quedan obsoletas:

1. Instala Ollama (o compila llama.cpp si quieres más control).
2. Descarga un modelo de pesos abiertos pequeño y bien valorado en una cuantización de 4 bits.
3. Hazle el tipo de pregunta que de verdad te importa, no un test de trivialidades. Observa los tokens por segundo y juzga si la velocidad es utilizable para tu flujo de trabajo.
4. Si la calidad se queda corta, sube el tamaño del modelo antes de subir la precisión. Si la velocidad se queda corta, baja el tamaño.
5. Una vez que algo se sienta utilizable, guarda el modelo y los ajustes exactos. La reproducibilidad es la mitad de la batalla.

Dónde se rompe la inferencia local sin avisar

Tres modos de fallo que conviene esperar para que no te sorprendan:

• La longitud del contexto también cuesta memoria. Las entradas largas consumen memoria además de los pesos. Un modelo que carga bien con un prompt corto puede quedarse sin espacio en un documento largo, y el fallo puede parecer un cuelgue en lugar de un claro "memoria insuficiente".
• El rendimiento no es la latencia. Un modelo puede sentirse rápido en una respuesta corta y arrastrarse en una larga. Mide siempre en la longitud de salida que realmente vas a usar, no en un saludo de una línea.
• La primera ejecución es la lenta. La carga inicial, y a veces la primera generación, incluye una preparación que las posteriores se saltan. Juzga la velocidad en la segunda y tercera ejecución.

Cuándo no merece la pena

La inferencia local no siempre es la respuesta correcta, y vale la pena ser honesto al respecto. Si tu volumen es bajo y esporádico, una API alojada es más barata y más rápida de configurar. Si necesitas el tope absoluto de capacidad o un contexto muy largo, los modelos frontera alojados siguen liderando. Y si pasaras más tiempo manteniendo el montaje que usándolo, la nube te está haciendo un favor. Lo local tiene sentido cuando la privacidad, el volumen sostenido o la curiosidad inclinan la balanza, no como opción por defecto.

Una nota rápida sobre seguridad

Ejecutar en local elimina el riesgo de transmisión por red, pero no elimina todo riesgo. Descarga modelos y herramientas de fuentes de confianza, presta atención a las licencias y recuerda que un modelo local todavía puede producir salidas erróneas o inseguras: "local" describe dónde se ejecuta, no cuánto deberías confiar en lo que dice.

En resumen

Los LLM locales ya no son exóticos. La decisión se reduce a tres preguntas honestas: ¿cabe el modelo en memoria, es la calidad cuantizada lo bastante buena para tu tarea, y es la velocidad utilizable para tu flujo de trabajo? Responde a esas en tu propia máquina con tus propios prompts y sabrás en una tarde si la inferencia local pertenece a tu caja de herramientas, mucho más fiablemente de lo que cualquier benchmark o entrada de blog podría decirte, incluida esta.