Puedes ejecutar un modelo de lenguaje capaz en tu portátil ahora mismo. No un modelo de juguete, sino uno real. Llama 3.1 8B funciona con 16GB de RAM. Mistral 7B funciona con menos. La configuración lleva una hora. La brecha de rendimiento entre las llamadas locales y las API en la nube es menor de lo que piensas.
La mayoría de los desarrolladores asumen que los LLM locales son lentos, limitados o requieren una GPU que no tienen. Esa suposición te cuesta dinero cada mes. También te cuesta latencia, preocupaciones de privacidad y la capacidad de personalizar el comportamiento sin esperar la aprobación de un proveedor de API.
Aquí te mostramos lo que realmente funciona y lo que no.
Elegir el Modelo Adecuado para tu Hardware
El tamaño del modelo y tu RAM disponible no son variables independientes. Tampoco lo es la memoria de la GPU, si tienes una.
Una regla general que se mantiene en la práctica: un modelo necesita aproximadamente 2 bytes de VRAM por parámetro cuando se carga en precisión completa, y aproximadamente 0.5 bytes por parámetro en cuantización de 4 bits. Eso significa que Llama 3.1 8B (8 mil millones de parámetros) necesita aproximadamente 4GB de VRAM en formato de 4 bits, o 16GB en precisión completa.
Para 16GB de RAM total (sin GPU dedicada): Mistral 7B o Llama 3.1 8B funcionan de manera fiable. Ambos funcionan a velocidades utilizables con cuantización. Phi-3 5B es excesivo en términos de capacidad; es bueno si necesitas una huella de memoria inferior a 4GB.
Para 32GB+ de RAM o cualquier GPU con 8GB+ de VRAM: Llama 3.1 70B se vuelve viable. Aquí es donde empiezas a ver mejoras significativas de calidad sobre los modelos más pequeños.
Para máquinas solo con CPU: Espera una inferencia más lenta, no una inferencia inutilizable. Una CPU moderna de 8 núcleos ejecutando Mistral 7B en cuantización de 4 bits genera texto a aproximadamente 5-10 tokens por segundo. Es lo suficientemente lento como para notarlo, pero no lo suficientemente lento como para abandonar el enfoque por completo.
Instalar y Ejecutar con Ollama
Ollama es el camino más rápido para pasar de cero a un modelo en ejecución. Descárgalo, ejecuta tres comandos y listo.
# Instala Ollama desde ollama.ai, luego:
ollama pull mistral:7b
ollama run mistral:7bEso es todo. Ahora tienes un modelo ejecutándose en localhost:11434. El primer pull descarga aproximadamente 4-5GB (para Mistral en forma cuantizada). Las ejecuciones posteriores se cargan desde el disco instantáneamente.
Si quieres llamarlo programáticamente desde Python o Node:
import requests
import json
prompt = "Explica cómo funciona la atención del transformador en un párrafo."
response = requests.post(
"http://localhost:11434/api/generate",
json={
"model": "mistral:7b",
"prompt": prompt,
"stream": False
}
)
result = json.loads(response.text)
print(result["response"])
Esto es funcionalmente idéntico a una llamada a la API de OpenAI en estructura: envías texto, recibes texto. La diferencia es que el modelo se ejecuta en tu máquina y no cuesta nada por token.
Ollama maneja la cuantización del modelo automáticamente. Por defecto, utiliza cuantización de 4 bits, que reduce el uso de memoria aproximadamente en un 75% con una pérdida mínima de calidad. Puedes forzar la precisión completa con ollama pull mistral:fp16 si tienes la VRAM, pero normalmente no es necesario.
Cuándo los Modelos Locales Tienen un Rendimiento Inferior (y Cómo Saberlo)
Los modelos locales son buenos. No son reemplazos directos para Claude o GPT-4o en todas las tareas.
Mistral 7B funciona bien para: generación de código, resumen, clasificación, extracción estructurada. Falla visiblemente en: razonamiento de contexto largo (cualquier cosa que requiera pensamiento coherente a lo largo de más de 20 párrafos), lógica de múltiples pasos donde los pasos anteriores se acumulan y tareas que requieren conocimiento del mundo explícito publicado después de la fecha de entrenamiento del modelo.
La solución práctica: evalúa tu caso de uso específico. No asumas el fracaso. Probé Mistral 7B en una tarea de clasificación de clientes y coincidió con la precisión de GPT-3.5 al 1/100 del costo. En otra tarea —extracción de sentimiento matizado de documentos financieros— obtuvo un 15% menos. El contexto importa.
Sabrás cuándo un modelo está luchando: salida incoherente, frases repetidas, cambios bruscos de tema o razonamiento correcto que contradice su propia declaración anterior. Estos no siempre son sutiles. Cuando los veas, cambia a la variante 70B o añade más contexto a través de RAG.
Compensaciones de la Cuantización: Velocidad vs. Precisión
La cuantización comprime un modelo representando números con menos bits. La cuantización de 4 bits usa 4 bits por parámetro en lugar de 32, reduciendo el modelo aproximadamente 8 veces.
La pérdida de calidad es real pero no catastrófica para la mayoría de las tareas. Llama 3.1 8B en cuantización de 4 bits obtiene aproximadamente el 95-98% del rendimiento de precisión completa en benchmarks estándar (MMLU, HumanEval). Esa brecha se amplía ligeramente en tareas de lenguaje matizado.
La ganancia de velocidad es sustancial: la cuantización de 4 bits a menudo añade un 20-30% más de inferencia rápida en CPU porque el ancho de banda de la memoria se convierte en un cuello de botella menor. En GPU, la diferencia es menor pero aún medible.
Empieza con 4 bits (predeterminado de Ollama). Si la calidad de la salida es decepcionante, siempre puedes descargar una variante de mayor precisión y volver a intentarlo; los modelos se cargan en segundos una vez descargados.
Construyendo un Flujo de Trabajo de LLM Local: Ejemplo Práctico
Digamos que estás procesando tickets de soporte y extrayendo datos estructurados (prioridad, categoría, urgencia).
import requests
import json
def classify_ticket(ticket_text):
prompt = f"""Clasifica este ticket de soporte y responde ÚNICAMENTE con JSON.
Ticket: {ticket_text}
Responde con este formato:
{{
"priority": "high" | "medium" | "low",
"category": "billing" | "technical" | "account",
"urgency_minutes": number,
"summary": "resumen-de-una-sentencia"
}}"""
response = requests.post(
"http://localhost:11434/api/generate",
json={"model": "mistral:7b", "prompt": prompt, "stream": False}
)
result = json.loads(response.text)["response"]
return json.loads(result) # Analiza el JSON de la salida del modelo
ticket = "El cliente dice que el inicio de sesión dejó de funcionar después de restablecer la contraseña. Necesita acceso antes del final del día."
print(classify_ticket(ticket))
Esto funciona. Mistral 7B genera de manera fiable JSON válido para tareas de extracción estructurada, mejor de lo que cabría esperar de un modelo de 7B. La latencia en una CPU moderna es de 2 a 4 segundos de extremo a extremo. Es más lento que una llamada a una API en la nube (que podría ser de 0.5 a 1 segundo), pero lo estás ejecutando sin conexión y pagando cero por inferencia.
Una Cosa para Hacer Hoy: Prueba el Límite de tu Hardware
Descarga Ollama. Ejecuta ollama pull mistral:7b. Ejecuta el modelo. Comprueba el uso de la RAM del sistema y la CPU mientras se ejecuta: top en Mac/Linux o el Administrador de Tareas en Windows.
Verás exactamente cuánto margen tienes antes de llegar al límite. Ese número te dice si puedes ejecutar cómodamente modelos de 7B, si necesitas reducir a modelos más pequeños o si un modelo de 70B está a tu alcance. No se requiere suposición. Solo datos.
