Mejores hosting locales para correr Llama 3: hardware, VRAM y herramientas (guía 2025)

Qué significa “hosting en local” para Llama 3 (y por qué elegirlo)

Cuando hablo de hosting local me refiero a ejecutar y servir el modelo en tu propio hardware: tu portátil, una torre con GPU, un mini-PC o un Mac con memoria unificada. Nada de nube: privacidad total, latencias bajas y coste controlado.
Yo lo uso para prototipos rápidos de chat, RAG básico y pruebas de prompts sin pagar GPU por minuto. En mi caso, la primera vez que monté un entorno local me sorprendió lo que mejora la latencia del primer token en comparación con servicios remotos [nota para medir: ms de primer token vs nube].

Cuándo tiene sentido local:

• Quieres iterar rápido sin costes variables.
• Te importa la privacidad (documentos internos, PII).
• Tu caso de uso cabe en 8B–13B con buena calidad (o aceptas “descansar” a 70B con compromisos).

Cuándo no:

• Necesitas contextos enormes persistentes o concurrencia alta.
• Tu app exige modelos de >70B con latencias de producción estrictas.
• Prefieres administración cero (ahí la nube gana).

---

Requisitos clave: VRAM, RAM, CPU, almacenamiento y SO (Windows/Linux/macOS)

La VRAM manda. Llama 3 se siente “cómodo” cuando el modelo y su KV-cache caben en la GPU. Si no, offload a RAM/SSD y baja la velocidad.

Reglas prácticas (aprox.):

• Llama 3 8B (GGUF cuant. Q4–Q5) → 5–8 GB VRAM.
• Llama 3 8B (Q8) → 9–11 GB VRAM.
• Llama 3 70B (Q4) → requiere 48 GB+ VRAM o multi-GPU; en 24 GB solo con offload pesado (lento).
• RAM: 16–32 GB para 8B cómodos; 64–128 GB si vas a cargar 70B con offload.
• CPU: importa menos que la VRAM, pero más núcleos ayudan al preprocesado/carga.
• Almacenamiento: SSD NVMe (PCIe 3.0/4.0). Los modelos pesan varios GB; un NVMe rápido reduce tiempos de carga. En mi equipo, pasar de SATA a NVMe bajó la carga inicial en [nota para medir: −X s].
• SO:
  • Windows + NVIDIA (CUDA): plug-and-play para la mayoría.
  • Linux + NVIDIA: máximo rendimiento y control.
  • Linux + AMD (ROCm): viable, mejora cada mes, requiere atención a versiones.
  • macOS (Apple Silicon + Metal): muy cómodo para 8B–13B; 70B cabe en MU alta, pero va más lento.

Tabla rápida VRAM ↔ modelo/quantización (orientativa)

Tamaño	Cuantización (GGUF)	VRAM recomendada	Comentario
8B	Q4_K_M	5–6 GB	Arranque rápido, calidad decente para chat general
8B	Q5_K_M	6–8 GB	Algo más de calidad, coste VRAM moderado
8B	Q8_0	9–11 GB	Calidad alta, útil para tareas sensibles
70B	Q4_K_M	48 GB+	Ideal 48–80 GB o multi-GPU; si 24 GB → offload a RAM/SSD

Nota: las cifras concretas dependen del backend (Ollama/llama.cpp), del context window y de extensiones (Flash-Attention, etc.). Te dejo hueco para tus mediciones [nota para medir: consumo VRAM y T/s por combo].

---

Perfiles y presupuestos: del portátil al rig con GPU dedicada

Portátil “entry” (8–12 GB VRAM)

• Para quién: chat, asistente de escritura, RAG ligero.
• Ejemplos: RTX 4060 (8 GB), 3060 (12 GB) o M-series con 24–48–64 GB MU.
• Qué esperar: 8B en Q4/Q5 con buena experiencia. 70B no es su territorio.
• En mi caso, con 8B Q5 obtuve respuestas fluidas en tareas de resumen [nota para medir: T/s medio].

Torre “sweet spot” (12–16 GB VRAM)

• Para quién: usuarios que quieren margen con 8B Q8 y modelos alternativos (Mixtral pequeños, Gemma 9B).
• Ejemplos: RTX 4070/4070 Ti, 4080 (16 GB).
• Qué esperar: tokens/seg altos, ventanas de contexto mayores, menos offload.

Workstation 24 GB+ (una GPU)

• Para quién: power users que quieren 8B al máximo y experimentar con 70B con offload.
• Ejemplos: RTX 3090/4090 (24 GB).
• Qué esperar: 8B Q8 como mantequilla; 70B solo para pruebas, latencia alta.

Workstation multi-GPU o GPU 48–80 GB

• Para quién: investigación y escenarios 70B serios.
• Ejemplos: 2× 24 GB (con particionado) o 48 GB/80 GB profesionales.
• Qué esperar: 70B Q4 utilizable, siempre que el software soporte tensor parallel / GPU split.

---

Stacks recomendados por sistema: CUDA (NVIDIA), ROCm (AMD), Metal (Mac)

Windows (NVIDIA/CUDA)

• Drivers al día (Studio o Game Ready), CUDA/cuDNN ya vienen integrados en muchas builds.
• Excelente compatibilidad con Ollama, LM Studio y llama.cpp precompilados.

Linux (NVIDIA)

• Máximo rendimiento y control fino (persistencia del driver, nvidia-smi, limitación de potencia).
• Ideal para servidores caseros y multi-usuario (tmux/systemd).

Linux (AMD/ROCm)

• Madura bien para inference con llama.cpp/Ollama en algunas distros.
• Comprueba versiones exactas de ROCm y kernel. Si fallan binarios, compila desde fuente.

macOS (Apple Silicon/Metal)

• Instalación muy simple con Ollama y LM Studio.
• Memoria unificada ayuda a cargar modelos grandes, pero el throughput es menor que una 4090.

Micro-experiencia: en mi Mac con 32 GB MU, Llama 3 8B Q5 funciona estable; el salto a 70B cargó pero con latencia de varios segundos [nota para medir: s/token].

---

Herramientas para servir Llama 3 en local: Ollama, LM Studio, GPT4All, llama.cpp y Jan

Ollama (CLI + servidor local)

• Descarga, cuantizaciones GGUF listas, API HTTP en http://localhost:11434.
• Comandos clave: # Instala/actualiza Ollama (según SO) # Arranca el servidor (si no arranca solo) ollama serve # Baja y ejecuta Llama 3 ollama pull llama3:8b ollama run llama3:8b # Ajusta contexto (ejemplo 8k) y temperatura desde un Modelfile si lo necesitas
• Ideal para integrar con tu app en minutos.

LM Studio (GUI)

• Interfaz amigable, descarga modelos GGUF, ajusta parámetros (contexto, top-p, temp) sin tocar consola.
• Perfecto para empezar en Windows/macOS, o para probar prompts visualmente.

llama.cpp (núcleo C/C++)

• Proyecto base que usan muchas GUIs. Compilando con flags correctos (CUDA/Metal) sacas máximo rendimiento.
• Recomendado si te gusta afinar fino (batching, flash-attn, etc.).

GPT4All

• GUI multi-plataforma con catálogo propio; sencillo para tests rápidos.

Jan

• Alternativa simple con enfoque “todo local” y chats aislados.

---

Qué modelo de Llama 3 elegir (8B–70B) y qué cuantización usar

Tamaño

• 8B: polivalente, rápido y “barato” en VRAM. Para la mayoría de asistentes y RAG ligeros, es el dulce.
• 70B: más calidad en razonamiento y factualidad, pero exige VRAM o acepta latencias mayores con offload.

Cuantizaciones (GGUF más comunes)

• Q4_K_M: mejor equilibrio tamaño/calidad.
• Q5_K_M: un poco mejor en calidad; coste extra de VRAM.
• Q8_0: calidad alta, peso notable; pide 9–11 GB para 8B.
• Consejo: empieza por Q4_K_M. Si tu GPU puede, sube a Q5_K_M. Para tareas delicadas, Q8.

Tabla orientativa de elección

Objetivo	Recomendación
Chat general, resúmenes	Llama 3 8B Q4_K_M
Asistente técnico ligero	8B Q5_K_M o Q8 si VRAM lo permite
Evaluación de calidad extra	Prueba 70B Q4 (acepta latencia/offload)
Máxima velocidad	8B Q4/Q5 + buen NVMe + contexto moderado

---

Plantillas de “hosting local tipo” (mini-PC, torre 1 GPU, torre 2 GPU, Mac 128 GB)

Mini-PC silencioso (entrada práctica)

• CPU de 6–8 núcleos, 32 GB RAM, NVMe 1–2 TB.
• GPU externa (si cabe) o iGPU/Mac para 8B Q4/Q5.
• Ideal para escritorio, bajo consumo.

Torre 1× GPU (12–16 GB VRAM)

• CPU 8–12 núcleos, 32–64 GB RAM, NVMe 2 TB.
• RTX 4070/4080.
• Producción ligera con 8B Q8 y RAG básico; muy polivalente.

Torre 1× GPU (24 GB VRAM)

• CPU 12–16 núcleos, 64 GB RAM, NVMe 2–4 TB.
• RTX 3090/4090.
• 8B “sobrado” y pruebas serias con 70B (offload).

Torre 2× GPU (2×24 GB) o 48–80 GB profesionales

• CPU 16–24 núcleos, 128 GB RAM, NVMe 4 TB+.
• 70B Q4 usable con particionado (si tu stack lo soporta).

Mac 128 GB MU

• Comodidad máxima, instalación sencilla.
• 8B impecable; 70B posible con paciencia. Perfecto para desarrollo + demos.

---

Rendimiento esperado: cómo medir y optimizar tokens/segundo

Benchmark casero reproducible (Ollama):

# 1) Arranca el servidor
ollama serve

# 2) Warm-up y medición básica
time ollama run llama3:8b -p "Resume en 3 viñetas qué es el aprendizaje por refuerzo"

# 3) Stress: contexto largo
OLLAMA_NUM_PARALLEL=1 ollama run llama3:8b -p "$(cat prompt_largo.txt)"

• Mide T/s, CPU/GPU util y RAM/VRAM con herramientas del SO.
• Repite con Q4/Q5/Q8 y contexto 4k/8k/16k para ver el impacto.
• En mi caso, solo activando un NVMe más rápido mejoré la latencia del primer token [nota para medir: −X %].

Optimización rápida

• Reduce el contexto si no lo necesitas (el KV-cache pesa).
• Sube a Q5 solo si notas mejora de calidad real.
• Evita usar el disco como “muleta” (offload excesivo).
• Mantén drivers y binarios actualizados.

---

Errores comunes y cómo evitarlos

• Bajar el modelo equivocado: para Ollama/LM Studio, usa GGUF (no pesos originales).
• Subestimar la VRAM: 8B Q8 no cabrá en 8 GB; pasa a Q4/Q5.
• Ignorar el NVMe: la carga lenta mata la experiencia.
• ROCm a la primera: valida compatibilidades exactas (kernel/driver).
• Contextos gigantes por defecto: más contexto ≠ más calidad.
• No medir nada: sin métricas, optimizas a ciegas. Deja anotadas tus cifras [nota para medir: tabla con T/s y consumo].

---

Checklist de compra y configuración rápida

Compra

• GPU con VRAM suficiente para tu objetivo (8–16 GB para 8B feliz; 24 GB si quieres experimentar con 70B).
• RAM 32–64 GB si haces RAG o piensas en 70B con offload.
• SSD NVMe 2 TB (modelos + datasets crecen rápido).
• Fuente/ventilación acorde (las GPUs potentes lo agradecen).

Configuración

• Sistema y drivers actualizados.
• Instala Ollama o LM Studio primero; prueba 8B Q4.
• Ajusta contexto y temperatura a tu caso.
• Mide T/s, latencia del primer token y consumo.
• Documenta tus resultados (te dejo campos):
  • 8B Q4: [nota para medir: T/s, VRAM]
  • 8B Q5: [nota para medir: T/s, VRAM]
  • 8B Q8: [nota para medir: T/s, VRAM]
  • 70B Q4 (si aplicase): [nota para medir: T/s, RAM/VRAM/offload]

---

FAQs