Back

Guía completa para ejecutar LLMs locales en 2025

La era de depender únicamente de la API de OpenAI está llegando a su fin. Si bien GPT-4 y Claude 3.5 Sonnet siguen siendo los reyes del razonamiento complejo, una revolución silenciosa está ocurriendo en nuestras máquinas locales.

En 2025, ejecutar un Gran Modelo de Lenguaje (LLM) localmente ya no es solo un proyecto divertido de fin de semana: es una estrategia viable para aplicaciones en producción, requisitos estrictos de privacidad y reducción de costos. Con el lanzamiento de modelos eficientes como Llama 3, Mistral y Phi-3, la "inteligencia local" ya no es un oxímoron.

Esta guía es una inmersión profunda en el Stack de LLM Local. No vamos a limitarnos a ejecutar ollama run llama3. Vamos a entender los cuellos de botella del hardware, la mecánica de la cuantización (quantization) y cómo construir un servidor de inferencia de grado de producción.

¿Por qué hacerlo local?

Antes de ver el cómo, establezcamos el por qué.

  1. Privacidad y Soberanía de Datos: Este es el punto clave. Para datos de salud, legales o financieros propietarios, enviar tokens a una API externa no es una opción. Los LLMs locales aseguran que tus datos nunca salgan de tu VPC (o de tu portátil).
  2. Previsibilidad de Costos: Los precios basados en uso matan a las startups. Un servidor GPU local tiene un costo mensual fijo. Si lo bombardeas con peticiones 24/7, tu factura no cambia.
  3. Latencia: Los saltos de red suman. Para aplicaciones en tiempo real (como asistentes de voz), ejecutar el modelo donde está el usuario (edge computing) supera a un viaje de ida y vuelta a un centro de datos.
  4. Sin Límites de Tasa (Rate Limits): Tú eres el administrador. Olvídate del error "429 Too Many Requests".

Parte 1: El Panorama del Hardware

El mayor cuello de botella para los LLMs locales es la VRAM (Memoria de Video).

Los LLMs están limitados por la memoria, no por el cómputo, para la inferencia. La fórmula para estimar el uso de memoria de un modelo es aproximadamente:

Memoria(GB)Paraˊmetros(Milesdemillones)×Bytes Por ParaˊmetroMemoria (GB) \approx Parámetros (Miles de millones) \times Bytes \ Por \ Parámetro

  • FP16 (Precisión Completa): 2 bytes por parámetro. Un modelo de 7B necesita ~14GB.
  • Cuantización de 4 bits (El Estándar): 0.5-0.7 bytes por parámetro. Un modelo de 7B necesita ~5GB.

La Ventaja de Apple Silicon

Los MacBooks con chips de la serie M (Pro/Max) son el estándar de oro actual para el desarrollo local debido a la Memoria Unificada. La GPU comparte RAM con la CPU. Un MacBook Pro con 128GB de RAM puede cargar un modelo masivo de 120B parámetros. Una NVIDIA 4090 está limitada a 24GB de VRAM.

La Ruta de NVIDIA

Si estás construyendo un servidor, NVIDIA sigue siendo el rey debido a la optimización CUDA.

  • Consumidor: RTX 3090/4090 (24GB VRAM) - Bueno para modelos 7B-30B (cuantizados).
  • Prosumidor: Dual 3090s o 4090s vía NVLink - 48GB VRAM.
  • Enterprise: A100/H100 - Demasiado caro para la mayoría de configuraciones "locales".

Parte 2: El Stack de Software

Hemos ido más allá de los scripts de Python sin procesar. Las herramientas en 2025 están maduras.

1. Ollama: El "Docker" de los LLMs

Si quieres empezar en 5 minutos, usa Ollama. Envuelve llama.cpp en un backend de Go y proporciona una CLI limpia y una API REST.

Instalación (macOS):

brew install ollama

Ejecutando Llama 3:

ollama run llama3

Ollama gestiona los pesos del modelo, el parsing de GGUF y la descarga al hardware automáticamente. Expone una API compatible con OpenAI en el puerto 11434, lo que lo convierte en un reemplazo directo para tus aplicaciones existentes.

2. Llama.cpp: El Motor

llama.cpp de Georgi Gerganov es el proyecto que inició la revolución. Permite ejecutar LLMs en hardware de consumo con Apple Metal, CUDA e incluso soporte puro de CPU. La mayoría de herramientas de alto nivel (Ollama, LM Studio) son wrappers alrededor de esto.

3. vLLM: El Servidor de Producción

Ollama es genial para desarrollo, pero para servir en producción con alto throughput, vLLM es el estándar. Utiliza PagedAttention, un algoritmo de gestión de memoria inspirado en la memoria virtual del SO, para aumentar el throughput entre 2x y 4x.


Parte 3: Desmitificando la Cuantización (GGUF)

Verás nombres de archivo como llama-3-8b-instruct.Q4_K_M.gguf. ¿Qué significa eso?

La Cuantización ayuda a reducir el tamaño del modelo reduciendo la precisión de los pesos.

  • FP16: Punto flotante de 16 bits (Pesos originales).
  • Q5_K_M: Cuantización de 5 bits. Virtualmente indistinguible de FP16.
  • Q4_K_M: 4 bits. El "punto dulce" entre velocidad y calidad.
  • Q2_K: 2 bits. Daño cerebral significativo al modelo. Evitar a menos que sea desesperado.

El Trade-off de "Perplexity":
Menos bits = Mayor Perplejidad (modelo más confundido). GGUF es un formato de archivo diseñado para carga rápida y mapeo a memoria.

[!TIP]
Siempre apunta a Q4_K_M o Q5_K_M. Ir a Q8 (8 bits) rara vez produce mejores resultados que Q6, pero consume el doble de VRAM.


Parte 4: Construyendo un Agente RAG Local (Python)

Vamos a construir un script que use Ollama con LangChain para chatear con un documento local.

Prerrequisitos:

pip install langchain langchain-community chromadb bs4 ollama pull mistral

El Código:

from langchain_community.llms import Ollama from langchain_community.document_loaders import WebBaseLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma from langchain.chains import RetrievalQA # 1. Configurar LLM Local llm = Ollama(model="mistral") # 2. Cargar Datos (ej. un post de blog) loader = WebBaseLoader("https://example.com/some-article") data = loader.load() # 3. Dividir Texto text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=0) splits = text_splitter.split_documents(data) # 4. Embeddings y Almacenamiento (¡Localmente!) # Usamos Nomic-embed-text, un gran modelo de embedding local embeddings = OllamaEmbeddings(model="nomic-embed-text") vectorstore = Chroma.from_documents(documents=splits, embedding=embeddings) # 5. Query qa_chain = RetrievalQA.from_chain_type(llm, retriever=vectorstore.as_retriever()) question = "¿Cuáles son los puntos clave?" result = qa_chain.invoke({"query": question}) print(result['result'])

Fíjate bien: Sin claves API. No se requiere conexión a internet después de la descarga inicial del modelo. Todo este pipeline se ejecuta en tu portátil.


Conclusión: El Futuro es Híbrido

El futuro no es "Nube vs. Local". Es Híbrido.
Ejecutarás modelos pequeños de 8B localmente para autocompletado, resumen y RAG sobre datos sensibles. Enrutarás tareas de razonamiento complejo (como análisis de contratos legales o generación de arquitectura compleja) a GPT-4o o Claude Opus en la nube.

Pero la capacidad de ejecutar una IA de nivel "Ingeniero Senior" en tu máquina local, con cero latencia y cero fuga de datos, es un superpoder disponible para ti ahora mismo. Abre tu terminal y escribe ollama run llama3.

Bienvenido a la resistencia local.

AI EngineeringLocal LLMOllamaLlama 3Privacy