Blog

LLMs locales con Ollama y llama.cpp: cuándo valen la pena y cómo empezar

Anderson Sinaluisa4 min de lectura
Guía práctica para correr modelos de lenguaje en tu propia máquina con Ollama y llama.cpp, integrarlos en tu app y decidir cuándo conviene más que una API en la nube.

Cada vez que agrego IA a un producto me hago la misma pregunta: ¿esto tiene que salir de la máquina del usuario? Muchas veces la respuesta es no. Para clasificar un gasto, resumir una nota o sugerir una categoría, mandar datos personales a un servidor externo es más riesgo que beneficio. Ahí es donde los modelos locales se vuelven interesantes.

En este artículo te cuento cómo correr un LLM en tu propia computadora con Ollama y llama.cpp, cómo llamarlo desde tu código y, sobre todo, cuándo vale la pena hacerlo.

Tu app llama a Ollama o llama.cpp en localhost, que ejecuta el modelo en tu equipo; una API en la nube queda como plan B

¿Por qué correr un modelo local?

  • Privacidad. Los datos nunca salen de tu equipo. Para finanzas, salud o código interno, esto cambia la conversación con usuarios y clientes.
  • Costo predecible. No pagas por token. Si tu caso de uso hace miles de llamadas pequeñas, la diferencia se nota.
  • Funciona sin internet. Útil para herramientas de escritorio o entornos restringidos.
  • Experimentación libre. Puedes probar prompts mil veces sin mirar la factura.

Con un modelo local los datos se quedan en tu laptop; con una API en la nube viajan a un servidor externo

Y las desventajas, que también existen:

  • Los modelos que caben en una laptop son más pequeños y razonan peor que los modelos grandes en la nube.
  • Necesitas RAM o VRAM suficiente. Como referencia, un modelo de ~8B parámetros cuantizado a 4 bits ocupa alrededor de 5 GB.

Memoria aproximada para modelos cuantizados a 4 bits: 3B unos 2 GB, 8B unos 5 GB, 14B unos 9 GB y 70B unos 40 GB

  • La latencia depende del hardware de cada usuario, así que la experiencia no es uniforme.

Mi regla: tareas acotadas y repetitivas → modelo local; razonamiento complejo → modelo grande en la nube.

Árbol de decisión para elegir entre modelo local y modelo en la nube

Opción 1: Ollama, la forma más rápida

Ollama empaqueta modelos listos para usar y expone una API HTTP local. Después de instalarlo desde ollama.com:

# Descarga un modelo
ollama pull llama3.2

# Chatea con él desde la terminal
ollama run llama3.2

Lo interesante es que Ollama levanta un servidor en http://localhost:11434. Puedes llamarlo desde cualquier lenguaje:

const response = await fetch('http://localhost:11434/api/chat', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    model: 'llama3.2',
    stream: false,
    messages: [
      { role: 'system', content: 'Clasifica el gasto en una sola categoría: comida, transporte, servicios u otros.' },
      { role: 'user', content: 'Uber al aeropuerto $12.50' },
    ],
  }),
});

const data = await response.json();
console.log(data.message.content); // "transporte"

Ollama también ofrece un endpoint compatible con la API de OpenAI en http://localhost:11434/v1. Eso significa que puedes usar el mismo cliente que ya tienes y solo cambiar la URL base. Es una forma muy cómoda de tener un modo “local” y un modo “nube” con el mismo código.

Opción 2: llama.cpp, más control

llama.cpp es el motor que está detrás de muchas de estas herramientas. Usarlo directamente te da más control sobre cuantización, hilos y uso de GPU. Trabaja con modelos en formato GGUF:

# Levanta un servidor compatible con la API de OpenAI
llama-server -m ./models/modelo-q4_k_m.gguf --port 8080

A partir de ahí apuntas tu cliente a http://localhost:8080/v1 y listo. Lo uso cuando necesito ajustar detalles finos o embeber el motor en una app de escritorio.

Patrones que me funcionan

1. Pide respuestas estructuradas. Los modelos pequeños se equivocan menos si les das un formato cerrado. Ollama permite forzar JSON con format: 'json', y siempre conviene validar la respuesta con un esquema (por ejemplo con Zod) antes de usarla.

2. Prompts cortos y específicos. Un modelo de 3B–8B no necesita (ni aguanta bien) un prompt de dos páginas. Una instrucción clara más dos o tres ejemplos rinden mucho más.

3. Ten un plan B. Si el modelo local no responde, tarda demasiado o devuelve algo inválido, cae a una regla simple o a un modelo en la nube (con consentimiento del usuario).

4. Mide antes de decidir. Arma un set pequeño de casos reales, por ejemplo 50 gastos ya categorizados, y compara la precisión del modelo local contra la del modelo grande. A veces la diferencia es mínima, y otras veces no.

¿Cuándo NO usaría un modelo local?

  • Cuando la tarea necesita razonamiento largo o mucho contexto (analizar un contrato completo, planificar una arquitectura).
  • Cuando tus usuarios tienen equipos modestos y la latencia arruinaría la experiencia.
  • Cuando la calidad de la respuesta es más crítica que la privacidad o el costo.

Conclusión

Los LLMs locales no reemplazan a los modelos grandes, pero sí abren una puerta muy valiosa: IA útil sin sacrificar la privacidad. Si estás construyendo algo que toca datos sensibles, te recomiendo empezar con Ollama, medir con casos reales y decidir con datos.

Si te interesa este tipo de contenido, comparto más sobre desarrollo e IA en TikTok: @andydev22.

Volver al blog