Si llevas un tiempo usando herramientas de IA, seguro que en algun momento te ha pasado esto: ves un modelo open source que pinta brutal, lo quieres probar en tu maquina, y a los diez minutos ya estas en el lio de siempre. Que si no sabes si tu GPU aguanta, que si no entiendes cuanta VRAM necesitas, que si bajas algo demasiado gordo y el ordenador se arrastra como si estuviera pidiendo auxilio.
La idea de correr modelos en local suena muy bien, y a veces de verdad merece mucho la pena. Tienes mas privacidad, controlas el coste, no dependes de una API externa y puedes montar flujos bastante potentes en tu propio equipo. Pero tambien hay bastante fantasmeo alrededor de esto. No todo el mundo necesita IA local, y no todas las maquinas estan hechas para mover ciertos modelos sin sufrir.
En este post vamos a hacerlo bien. Primero ver si tu equipo puede con ello usando CanIRun.ai, luego instalar Ollama, bajar un modelo, probarlo en local y, a partir de ahi, conectarlo a herramientas como Open Code o Cloud Code si quieres trabajar con ese modelo dentro de tu flujo diario.
Por que querrias ejecutar IA en local
La primera razon suele ser la mas obvia: privacidad. Si estas trabajando con codigo, notas, documentos internos o simplemente no te hace gracia mandar todo a un tercero, ejecutar el modelo en tu propio equipo te da una tranquilidad bastante distinta.
La segunda es el coste. Cuando empiezas a usar APIs en serio, sobre todo para programar o iterar mucho, la broma sube. En local pagas en hardware y electricidad, claro, pero a cambio puedes trastear sin ir mirando el contador todo el rato.
Y la tercera, que para mi es de las mas interesantes, es el control. Puedes elegir el modelo que te da la gana, cambiar de quantizacion, probar uno fine-tuned para codigo, otro para razonamiento, otro para RAG, y montarte un flujo mucho mas tuyo. No dependes de que una empresa cambie el modelo, te meta limites raros o te corte una feature de un dia para otro.
Ahora bien, una cosa importante: local no siempre significa mejor. Si tienes un portatil justito, o si pretendes correr un modelo de 30B como si fuera magia negra, te vas a llevar una hostia de realidad. Y por eso hay que empezar por lo que casi nadie mira al principio.
Antes de bajar nada, mira si tu maquina puede con ello
La forma mas rapida de dejar de perder el tiempo es entrar en CanIRun.ai. Esa web te detecta la maquina y te enseña, con estimaciones bastante utiles, que modelos pueden irte bien, cuales van justos y cuales son directamente mala idea.
Lo bueno es que no se queda en el nombre del modelo y ya. Te da una referencia de VRAM, contexto y distintas quantizaciones, que es justo lo que necesitas mirar si no quieres ir a ciegas.
Si en CanIRun.ai ves que un modelo te sale como Runs great o Runs well, guay. Si te sale en Tight fit o Barely runs, no significa que sea imposible, pero ya te esta avisando de que seguramente vas a sacrificar velocidad, contexto o estabilidad. Y si te sale como demasiado pesado, no te pongas creativo. No pasa nada por bajar un modelo mas pequeno. Lo que pasa es que mucha gente quiere empezar por uno enorme porque en Twitter queda mas bonito decirlo.
La VRAM es lo que manda de verdad
Aqui esta una de las claves importantes. Cuando hablamos de correr modelos en local, lo que manda no es solo que tengas una GPU, sino cuanta VRAM tiene esa GPU.
La VRAM es la memoria de la grafica. Y es donde idealmente quieres meter los pesos del modelo y buena parte del trabajo de inferencia. Si el modelo cabe comodo ahi, la experiencia cambia una barbaridad. Si no cabe, empiezan los apaños: parte se va a RAM, parte se descarga a CPU, sube la latencia y de repente eso que en teoria ibas a usar a diario se convierte en una tortura.
Por eso no basta con pensar en “este modelo es de 7B” o “este otro es de 14B”. Tambien importa la quantizacion. Un mismo modelo puede ocupar mucho menos en Q4_K_M que en Q8_0 o F16, pero claro, no sale gratis: estas ajustando memoria, calidad y rendimiento.
La forma sencilla de pensarlo es esta:
- Si vas justo de VRAM, te interesan modelos pequenos o quantizaciones agresivas.
- Si tienes VRAM de sobra, puedes permitirte subir de tamano o ir a quantizaciones mas comodas.
- Si el modelo “casi cabe”, muchas veces la experiencia empeora mas de lo que la gente espera.
Y ojo con otra cosa: la VRAM no solo afecta a “si arranca o no”. Tambien afecta a cuanto contexto puedes usar y a la velocidad real cuando empiezas a meter prompts largos, herramientas o flujos de codigo. Un modelo que responde medio bien a una pregunta corta puede venirse abajo en cuanto le exiges trabajo serio.
Nota: CanIRun.ai te da una estimacion muy util, pero sigue siendo eso, una estimacion. Tomalo como filtro inicial, no como verdad divina escrita en piedra.
Instalar Ollama sin complicarte la vida
Si lo que quieres es levantar modelos en local sin volverte loco, Ollama es de las opciones mas comodas ahora mismo. Instalas, bajas modelo y a correr. Sin hacer malabares raros con runtimes ni historias innecesarias.
En Linux o macOS puedes instalarlo asi:
curl -fsSL https://ollama.com/install.sh | shSi estas en Windows, lo mas razonable es bajar el instalador desde la web oficial o usar WSL si tu flujo ya vive ahi.
Cuando lo tengas, comprueba que esta bien instalado:
ollama --versionY si quieres verificar que el servicio local esta levantado y expone su endpoint compatible con OpenAI, puedes hacer esta prueba:
curl http://localhost:11434/v1/modelsEse detalle es importante porque luego es justo lo que te permite conectarlo con otras herramientas.
Descargar un modelo con ollama pull
Aqui ya entra el criterio. No empieces por el modelo mas bestia que hayas visto en una comparativa. Empieza por algo que tu maquina pueda mover de verdad.
Para programacion o pruebas generales, una opcion bastante sensata para arrancar es esta:
ollama pull qwen2.5-coder:7bSi quieres algo mas generalista, tambien puedes mirar familias tipo qwen3:8b, llama3.1:8b o algun modelo pequeno de Gemma, pero la idea es la misma: elige en funcion de tu hardware, no del hype.
Cuando termine la descarga, puedes listar lo que tienes en local:
ollama listY ahi ya ves el nombre exacto del modelo para usarlo luego en CLI o en clientes externos.
Probar el modelo en local antes de meterlo en herramientas
Esto es importante. Antes de enchufarlo a Open Code, Cloud Code o cualquier agente, pruebalo directamente. Asi ves si responde bien, si tarda demasiado o si la maquina empieza a sufrir.
La prueba mas simple es esta:
ollama run qwen2.5-coder:7bY una vez dentro, le puedes pedir algo tonto pero util, por ejemplo:
Escribeme una funcion en TypeScript para hacer debounce y explicame por que funciona.Si ya notas que tarda demasiado aqui, no esperes milagros cuando luego lo metas dentro de un flujo con herramientas, contexto largo y codigo real. Local queda muy bonito en una demo, pero lo que importa es si te sirve en el dia a dia.
Como usarlo luego con Open Code y Cloud Code
Aqui viene la parte que mola. Ollama expone compatibilidad con el API de OpenAI en http://localhost:11434/v1, y eso te abre la puerta a conectarlo con clientes que soporten endpoints OpenAI-compatible.
En Open Code esto encaja bastante bien porque permite configurar proveedores personalizados y modelos locales. Un ejemplo de configuracion seria algo asi:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama (local)",
"options": {
"baseURL": "http://localhost:11434/v1"
},
"models": {
"qwen2.5-coder:7b": {
"name": "Qwen 2.5 Coder 7B (local)"
}
}
}
}
}Con eso, Open Code puede hablar con tu modelo local como si fuese otro proveedor mas, pero sin salir de tu maquina.
En Cloud Code, o en cualquier cliente parecido, la idea es la misma si te deja configurar un proveedor compatible con OpenAI o una baseURL personalizada. Si te deja hacerlo, apuntas a:
http://localhost:11434/v1Y usas como nombre de modelo el que tengas cargado en Ollama.
Si esa herramienta no permite cambiar endpoint o solo funciona con APIs cerradas del proveedor, entonces no vas a poder enchufarle Ollama directamente y ya esta. Y esto mejor decirlo claro. A veces el problema no es tu maquina. Es que el cliente no esta pensado para ese flujo.
Expectativas realistas: local esta muy bien, pero no hace magia
Esta es la parte que mas se maquilla en internet. Si tienes una GPU decente y eliges bien el modelo, puedes montarte una experiencia muy util. Pero no esperes que un modelo local pequeno vaya a rendir como el mejor modelo cloud del momento en tareas duras de razonamiento, arquitectura o agente complejo.
Donde local suele tener mucho sentido es cuando estas iterando rapido, valoras la privacidad, quieres automatizar cosas muy concretas, repites tareas una y otra vez, haces prototipos o simplemente prefieres tener el coste bajo control.
Donde hay que bajar un poco a tierra es cuando alguien pretende usar un modelo local justito para sustituirlo absolutamente todo. Si tu equipo va corto, lo normal es que puedas hacer cosas utiles, pero con limites. Menos velocidad, menos contexto comodo y mas necesidad de elegir bien el caso de uso.
Y no pasa nada. De hecho, usar IA local con cabeza suele ir de eso: saber que tarea merece local y cual no.
Y si quiero usar modelos fine-tuned
Tambien puedes. Y de hecho tiene bastante sentido.
Si encuentras un modelo fine-tuned para codigo, SQL, soporte, RAG o lo que sea que haces todo el rato, puedes rascar un comportamiento mas afinado que con un modelo generalista. Pero no confundas “fine-tuned” con “milagroso”. Si la base es floja o el hardware va asfixiado, el tuning no te salva de la realidad.
La gracia de Ollama y del ecosistema open es justo esa: puedes probar varias opciones y quedarte con la que mejor equilibra calidad, memoria y velocidad para tu caso.
La idea con la que me quedaria
Si te apetece probar IA local, no empieces descargando cosas al tuntun. Empieza por mirar CanIRun.ai, entiende cuanta VRAM tienes de verdad, elige un modelo que encaje con tu maquina y levanta primero algo sencillo con Ollama.
Cuando eso funcione bien, entonces si, lo conectas a Open Code, a Cloud Code o al cliente que toque y te montas tu flujo. Pero en ese orden. Primero compatibilidad real, luego modelo, luego integracion. No al reves.
Porque si haces el camino al reves, lo mas probable es que acabes diciendo que la IA local va fatal, cuando en realidad lo que iba fatal era el planteamiento.
Si quieres, en otro post puedo bajar esto aun mas a tierra y montar una configuracion concreta segun el tipo de maquina que tengas: portatil normal, sobremesa con GPU dedicada o mini servidor en casa.
¿Qué te ha parecido?
Déjame tu opinión, pregunta o sugerencia. Los comentarios se sincronizan con GitHub Discussions .