Miniguía sobre IA en local

Este post es una mezcla de experiencia personal y mini guía. Después de llevar un tiempo haciendo pruebas con modelos de IA en local, llega el momento de intentar poner orden, y para mí no hay mejor forma de hacer eso que tratando de ponerlo por escrito.

Usar un modelo en local tiene sentido por cosas bastante prácticas. Cuando trabajas contra una API, el código sale de tu máquina, pagas por token y mañana pueden cambiarte el precio, el modelo o los términos. En local nadie ve lo que le pegas, no hay factura que crezca con cada petición y, si la red se cae, sigues. No nos engañemos, al menos por ahora, esto no va a sustituir a las soluciones de pago, sus modelos frontera y a todo el andamiaje que ya tienen montado alrededor de ellos. Pero para scripts, limpiezas, comparar JSON o preguntarle cosas sobre un fichero sin mandarlo a un tercero, puede valer.

Al principio me perdí en los nombres. Que si 7B, que si Q4_K_M, que si Instruct, que si 26B-A4B. Y luego está lo de siempre, ves un tutorial que te pone los dientes largos, bajas un modelo que en teoría te cabe, lo arrancas, y el equipo se queda frito o va a dos tokens por segundo. ¿A quién no le ha pasado?

En local casi todo lo que puedes bajar son modelos de pesos abiertos. Ya conté qué significa eso y por qué no es open source del todo. Te bajas los pesos, los corres en tu máquina y nadie ve tus datos. Llama, Qwen, Mistral, Gemma, Phi, DeepSeek y compañía. Si lo vas a usar para trabajar conviene mirar la licencia, que no todas son iguales.

Con qué correrlos

Un modelo, en la práctica, es un fichero grande en el disco. Para usarlo hace falta un programa que lo cargue en memoria y te deje hablar con él. Ese programa puede ser una ventana de chat, o puede dejar que otra herramienta, como opencode, le envíe preguntas y reciba respuestas, en un formato determinado, y en forma de instrucciones para realizar acciones, ejecutar comandos, escribir código, etc. Todo esto sin salir de tu máquina.

Ese formato suele ser el de la API de OpenAI. No es que estés usando nada de OpenAI ni mandando datos a sus servidores. Ellos definieron la primera API que se popularizó para hablar con un modelo, y el resto del ecosistema la copió. LM Studio y Ollama levantan un servidor en tu propio ordenador que responde igual: mismas peticiones, mismas respuestas. Por eso opencode, y casi cualquier cliente, se conecta sin inventar un protocolo nuevo.

Las tres opciones que más se ven son LM Studio, Ollama y llama.cpp. Hacen lo mismo en el fondo: ejecutar el modelo en tu ordenador. Se diferencian en cómo te lo ponen, en si puedes ver y cambiar su código, y sobre todo en el catálogo de modelos que te ofrecen.

LM Studio es una aplicación de escritorio, con ventanas, buscador de modelos y un chat. Eliges el modelo, lo descargas, lo arrancas y hablas con él. También puede dejarlo escuchando en local para que opencode lo use. Es lo que estoy usando ahora, porque para probar y comparar modelos me resulta más cómodo verlo en pantalla. El catálogo es Hugging Face entero, sin filtro: Hugging Face es el sitio donde la gente publica estos modelos, el GitHub de los LLM digamos, y LM Studio te deja bajar casi cualquiera. Eso está bien para trastear, y también implica que te puedes descargar cosas mal convertidas o que luego no van. Es gratis, pero no es software libre: no publican el código, no puedes estudiarlo ni modificarlo.

Ollama hace lo mismo, pero desde la terminal. Escribes un comando para bajar el modelo y otro para arrancarlo. No hay tanto que configurar a mano, y para usarlo con opencode va muy bien. El código sí es abierto (licencia MIT), así que puedes ver cómo funciona y tocarlo si quieres. La diferencia gorda respecto a LM Studio es el catálogo: Ollama no te enseña Hugging Face al completo, sólo modelos que ellos han empaquetado y dan por buenos. Menos donde elegir, menos sorpresas. Si te manejas en la terminal, suele ser el camino más simple. Ya lo usé con opencode. El inconveniente, al menos para mí, es que controlas menos detalles: qué parte del modelo va a la GPU, cuánta memoria reserva, etc.

llama.cpp no es una aplicación para usuario final. Es el programa que realmente sabe ejecutar el modelo: le pasas el fichero, le dices cuánta memoria usar y si debe aprovechar la gráfica. Más preciso, más pesado de manejar. LM Studio y Ollama existen, entre otras cosas, para no tener que pelearte con eso. También es software libre, licencia MIT.

Hay otras interfaces, pero no las he usado en serio. Como tengo un Mac, suelo usar más LM Studio, porque en teoría está más optimizado para la arquitectura Silicon de Apple (los chips M). Tiene soporte integrado para MLX, el framework que Apple diseñó para exprimir sus chips. Necesitas que los modelos tengan versiones MLX, frente al estándar GGUF que es el habitual. Para los que están disponibles, sólo con eso, puedes duplicar la velocidad del modelo frente a ejecutarlo en Ollama con GGUF. Pero ten en cuenta que es un caso particular para la arquitectura Apple.

Qué significan los nombres de los modelos

Un modelo ocupa lo que ocupan sus parámetros por la precisión con la que los guardas. Las B de 7B, 8B o 32B son billions, miles de millones de parámetros. A más parámetros, en general más capacidad de razonar, aunque eso también depende mucho del entrenamiento.

La precisión es la cuantización: apretar esos pesos para que quepan en un equipo normal. El original suele venir en 16 bits, unos 2 bytes por parámetro, así que un 8B se te pone en unos 16 GB sin contar nada más. Demasiado para un portátil normal. Cuantizar es bajar a 8, a 4 o hasta a 2 bits, a costa de perder un poco de finura. Eso de cuantizar lo escucharás mucho hablando de modelos en local. A mí la palabra que más me gusta es lobotizar, porque en el fondo lo que haces con la cuantización es hacer un poco más torpe el modelo. Su entrenamiento es el mismo pero al quitarle precisión a los pesos es como cuando a ti te falta el café del lunes por la mañana. El Q4_K_M que verás habitualmente es el que casi todos usamos: unos 4 bits, medio byte por parámetro. Un 7B-8B se queda en 4 o 5 GB, un 32B en 18 o 20 GB. Si subes a Q8 ocupa casi el doble y apenas ganas inteligencia. Si bajas a 2 bits cabe en cualquier sitio, pero se vuelve torpe y para código no vale. Un 14B en Q4 suele darte más que un 7B en Q8 ocupando parecido.

Los nombres, una vez los desmontas, lo cuentan todo. Por ejemplo, qwen2.5-coder-7b-instruct-q4_K_M: Qwen es la familia, 2.5 la versión, coder que está afinado para código, 7b los parámetros, instruct que está entrenado para obedecer órdenes y no solo completar texto, y Q4_K_M la cuantización. Si ves un 26B-A4B es un Mixture of Experts: 26 mil millones en total pero solo activa 4 por cada token. Más rápido que un denso del mismo tamaño, aunque en disco y en memoria te ocupe como grande. En Mac además verás MLX frente a GGUF. GGUF es el formato más habitual. MLX está pensado para Apple Silicon y la memoria unificada. En el M1, MLX va mejor.

El equipo

Lo que decide qué modelo máximo puedes cargar es la memoria disponible. Y no todos los equipos funcionan igual.

En un PC con Nvidia dedicada tienes la VRAM de la gráfica, separada y muy rápida, y aparte la RAM del sistema. Si el modelo cabe en la VRAM, vuela. Si no cabe, LM Studio y llama.cpp hacen offload y tiran de CPU para el resto, que funciona pero va mucho más lento. Una 4060 de 8 GB es un mundo distinto a una 4090 de 24 GB.

En un Mac con Apple Silicon no hay VRAM separada, hay memoria unificada que comparten CPU y GPU. Puedes cargar modelos más grandes de lo que sugiere la etiqueta de gráfica: en un Mac de 32 GB metes un 30B cuantizado que en una Nvidia de 12 GB ni arranca. A cambio, esa memoria también se la come macOS, el navegador y todo lo demás, y el ancho de banda es menor que en una dedicada potente.

Luego están los portátiles con integrada Intel o AMD, sin gráfica dedicada. También comparten la RAM con el sistema, como el Mac, pero con peor ancho de banda, peores drivers y más trabajo en CPU. Para un 3B o un 7B pequeño en Q4, con paciencia, valen. Para lo demás, no.

Para hacerme una idea uso dos cuentas. La primera: coge lo que ocupa el modelo en disco, lo que Hugging Face dice que pesa, y multiplícalo por 1,2 si vas a usar contexto corto, de 4K, y por 1,5 o 1,6 si quieres ir a 32K con margen. La segunda: unos 0,6 GB por cada mil millones de parámetros en Q4, cerca de 1 GB por B en Q8, más el contexto.

El peso del fichero no es lo que te va a pedir en memoria. Es el punto de partida. Cuando arrancas el modelo, a esos pesos hay que sumarle la caché de clave-valor, donde guarda la conversación para no recalcularlo todo a cada token. Esa caché crece con la ventana de contexto que configures, con las capas del modelo y con lo largo que sea lo que le pegues. El mismo 8B con 4K te pide medio giga extra y ni lo notas. Con 32K, 2 o 4 GB más. Con 128K se te puede comer 8 GB él solo. Por eso dos personas con el mismo modelo pueden tener experiencias distintas: uno lo usa para chatear corto y le va fino, otro le pasa un repositorio entero con opencode y se le hunde.

Tomando Q4_K_M como referencia, y dejando aparte lo que se come el sistema, me salen más o menos estos números:

Modelo en Q4	Pesa en disco	RAM para 4K	RAM para 32K
3B-4B	2-2,5 GB	3-4 GB	5-6 GB
7B-8B	4-5 GB	6-8 GB	8-10 GB
14B	8-9 GB	11-12 GB	14-16 GB
32B	18-20 GB	22-24 GB	26-30 GB

En un M1 de 16 GB, restando lo que se come macOS, quedan 10 o 12 GB de aire. Un 9B en Q4 te cabe, un 14B ya es ir justo y un 32B ni lo intentes. Si apuras, en cuanto le pegas un fichero un poco grande empieza el swap y todo va a pedales. Mejor un modelo un punto más pequeño con contexto de sobra que uno grande justo de memoria.

Lo otro que decide si trabajar es usable es la velocidad de la memoria. No es tanto la potencia de la CPU como cuántos gigas por segundo puede mover. Una RTX de gama alta de Nvidia anda por los 1000 GB/s, un Mac M1 por los 200. Los nuevos M5 Pro y Max pueden llegar hasta los 600 o 700 GB/s. Una arquitectura Intel o AMD integrada raramente podrá dar más de 100. Por eso el mismo modelo va mucho más rápido en una Nvidia buena. En mi equipo, un M1 Pro con 16 GB, Gemma 4B en Q4 se mueve a unos 50 tokens por segundo, que para chat sobra, y Qwen 3.5 9B en Q4 se queda en 20, un poco justo para picar código, pero factible para tareas pequeñas. Si tu prompt empieza por «hazme una aplicación que…» ni sueñes que te va a funcionar.

Chat no es lo mismo que herramientas

En LM Studio, en modo chat, casi todos los modelos parecen buenos. Les preguntas algo, te contestan con soltura y listo.

Con opencode es otra cosa. Ahí el modelo tiene que llamar a herramientas: leer un fichero, listar un directorio, aplicar un diff. Eso exige que sepa hacer function-calling, que genere el JSON que opencode espera y que no se ponga a explicarte cómo haría la tarea en vez de hacerla.

Me pasó con Gemma 4B en Q4_K_M: en chat perfecto, a 50 tokens por segundo, y en opencode no sabía gestionar las herramientas. Me devolvía un “para listar los ficheros deberías usar ls” en lugar de llamar a la herramienta. Tuve que tocar el system prompt para obligarle a ejecutar y no explicar, y aun así no era muy adecuado. Está afinado para ser asistente de chat, no para usar herramientas.

Qwen 3.5 9B en Q4_K_M sí me funciona con opencode. Llama a las herramientas, aplica el diff y no se pone a dar la charla. El pero es la velocidad: 20 tokens por segundo en el M1, un poco justo. Usable, pero se nota que el equipo va al límite.

Si lo quieres para agente, mira que diga que soporta tools o function-calling, y mejor una variante instruct o coder. Un Qwen de ese tipo está bastante más pensado para esto que un Gemma pequeño de chat. Y aun así puede hacer falta ajustar el system prompt en LM Studio.

En resumen

¿Qué puedes esperar de esto, al menos con la experiencia que tengo yo? Si quieres un chat, trabajar con documentos que no quieres mandar a un servidor que no controlas, o un asistente pequeño para el tren o para cuando no hay red, bien. A nivel de código la cosa se complica. Para tareas pequeñas, ordenar ficheros, scripts atómicos o cambios muy acotados en un repositorio, vale. Si quieres trabajar igual que con la herramienta de pago, sobre un repositorio grande, pedir análisis complejos, refactorings y demás, necesitas un equipo muy potente, yo diría que mínimo 64 GB de RAM, y afinar bastante la configuración, sea con LM Studio o con Ollama.

Los modelos de pesos abiertos que hay hoy ya son lo suficientemente listos para hacer casi cualquier cosa. Con un equipo potente y un buen harness se pueden hacer muchas cosas en local. El límite, la mayoría de las veces, no es el modelo. Es el ordenador y una buena configuración de herramientas.