Un LLM local es un modelo cuyos pesos y su runtime de inferencia están bajo tu control. Tú decides qué modelo se ejecuta, cómo se ejecuta, qué datos procesa y qué sucede con las salidas. Esa libertad viene con responsabilidad operativa: descargas, actualizaciones, compatibilidad, límites de memoria y seguridad.
Esta guía cubre la capa de operación local: qué significa ejecutar un modelo localmente, cómo funciona la cuantización, qué formatos de archivo existen, cómo elegir un runtime, qué nivel de hardware necesitas y cómo medir el rendimiento real de tu configuración.
Este artículo forma parte de una serie técnica sobre IA local.
¿Qué significa realmente «local»?
«Local» puede significar diferentes escalas:
- Un modelo de 2B parámetros ejecutándose en un teléfono.
- Un modelo de 7B a 14B ejecutándose en una GPU de consumo.
- Un modelo de 30B a 70B ejecutándose en una estación de trabajo de gama alta.
- Un modelo MoE (Mixture of Experts) disperso ejecutándose en múltiples GPUs en un centro de datos.
- Un despliegue privado usando vLLM, SGLang, TensorRT-LLM, llama.cpp o un stack personalizado de PyTorch.
Local no significa automáticamente offline, privado, seguro o de código abierto. Solo significa que tú estás ejecutando el modelo. Una aplicación local aún puede enviar telemetría. Un modelo puede ser de pesos abiertos (open-weight) pero no ser de código abierto. Un modelo puede ser local pero inseguro de cargar. Un modelo cuantizado puede caber en memoria pero responder mal.
El intercambio vale la pena cuando necesitas privacidad, baja latencia, comportamiento personalizado, operación offline o control de costes a escala. No vale la pena cuando necesitas la calidad absoluta de un modelo frontera y no tienes el hardware para igualarlo. En ese caso, una API alojada es la herramienta correcta.
La ecuación práctica es:
Éxito de un LLM local = ajuste del modelo + formato de prompt correcto + buen runtime + evaluaciones realistas
Cuantización: Precisión vs. memoria
La cuantización almacena los pesos del modelo en una precisión numérica menor para reducir la memoria requerida y, en algunos casos, mejorar el rendimiento (throughput).
Regla de oro de cuantización en 2026
| Nivel | Calidad | Uso recomendado |
|---|---|---|
| FP16/BF16 | Mejor calidad | Línea base para evaluación, cuando la memoria es abundante |
| Q8 / INT8 | Casi sin pérdida | VRAM disponible, pérdida de calidad mínima |
| Q6 / Q5 | Excelente calidad | Punto medio sólido entre calidad y memoria |
| Q4 | Buena calidad | «Sweet spot» para chat y documentos |
| Q3 / Q2 | Degradación notable | Solo cuando es imprescindible hacer caber un modelo grande |
La cuantización de pesos no es lo mismo que la cuantización del caché KV. La cuantización de pesos reduce el tamaño del modelo almacenado. La cuantización del caché KV reduce la memoria del contexto activo en tiempo de ejecución.
El impacto de la cuantización aparece primero en: matemáticas, razonamiento multietapa, corrección de código, fiabilidad de uso de herramientas, adherencia a JSON/esquemas y recuperación de contextos largos.
Un modelo más pequeño con mayor precisión puede superar a un modelo más grande cuantizado agresivamente. Un modelo de 7B en Q6 puede vencer a un modelo de 13B en Q2 en tareas de razonamiento mientras usa menos memoria y corre más rápido. No adores el conteo de parámetros.
Formatos de archivo y seguridad
La elección del formato de archivo determina qué runtimes pueden cargar el modelo, qué cuantización puedes usar y qué tan rápido se ejecuta.
Formatos principales
| Formato | Uso principal | Seguridad |
|---|---|---|
| safetensors | PyTorch/Transformers | Seguro (sin pickle) |
| GGUF | llama.cpp, LM Studio | Seguro |
| ONNX | Despliegue estandarizado | Seguro |
| TensorRT-LLM | NVIDIA, producción | Seguro |
| EXL2 / GPTQ / AWQ | Inferencia local en GPU | Seguro |
| .bin (PyTorch) | Legacy PyTorch | Peligro: puede ejecutar código |
Seguridad en la carga de modelos
Regla número uno de seguridad en IA local: no dejes que el archivo del modelo de un tercero se convierta en la ejecución de código de un tercero.
La carga basada en pickle de PyTorch puede ejecutar código arbitrario durante la deserialización. Usa safetensors siempre que sea posible, especialmente para modelos PyTorch/Transformers. Evita archivos .bin aleatorios de fuentes no confiables.
Runtimes y motores de inferencia
Un runtime es el software que carga el modelo y realiza la inferencia. En 2026, el ecosistema de runtimes de LLM local está maduro, útil y fragmentado.
Selección por caso de uso
| Runtime | Mejor para | Formato preferido |
|---|---|---|
| llama.cpp | Portabilidad, CPU, Apple Silicon | GGUF |
| LM Studio | Escritorio, principiantes | GGUF |
| Harbor | Stack local completo | GGUF/safetensors |
| vLLM | Servicio privado, producción | safetensors/HF |
| SGLang | Servicio privado, alto throughput | safetensors/HF |
| TensorRT-LLM | Máximo rendimiento NVIDIA | ONNX/motores TRT |
| MLC / WebLLM | Navegador, móvil | MLC format |
La elección del runtime a menudo te vincula a un ecosistema de formatos. llama.cpp significa GGUF. vLLM y SGLang suelen significar safetensors o checkpoints de Hugging Face. TensorRT-LLM significa ONNX o motores optimizados. Elige el runtime primero, luego encuentra los modelos en el formato adecuado.
Modos de servicio
Existen tres modos de servicio prácticos:
Local para un solo usuario
Una aplicación de escritorio, un stack de CLI o un servidor de línea de comandos para una persona. Harbor, LM Studio, llama.cpp server, ExLlama/TabbyAPI y pequeños scripts de Transformers encajan aquí. El objetivo es la iteración rápida: comparar comportamiento, velocidad, uso de memoria y formatos de prompt sin construir una plataforma de operaciones.
API para equipo o privada
Un endpoint compatible con OpenAI en una estación de trabajo o servidor. vLLM, SGLang, TensorRT-LLM y llama.cpp server aparecen aquí dependiendo de las necesidades de tamaño de modelo y rendimiento. Una vez que múltiples personas o trabajos comparten un modelo, necesitas monitoreo, gestión de prompts/versiones, enrutamiento y mediciones realistas de latencia.
Servicio de producción
Ahora la conversación incluye: batching continuo, caché de prefijos, decodificación especulativa, atención paginada (paged attention), paralelismo de tensores, paralelismo de pipeline, servicio cuantizado, salidas estructuradas, balanceo de carga, utilización de GPU, percentiles de latencia, caché de prompts, control de admisión, registro (logging), tolerancia a fallos, privacidad y controles de costes.
A escala de producción, la pregunta fácil es ¿puedo cargar el modelo? La pregunta difícil es ¿puedo servirlo de forma fiable bajo tráfico real?
Matemáticas de VRAM
Existen tres consumidores principales de memoria:
- Pesos del modelo
- Caché KV
- Sobrecarga del runtime
La fórmula aproximada de la memoria de los pesos es:
memoria_pesos ≈ parámetros × bytes_por_parámetro
Aproximaciones útiles
- FP16/BF16: Aproximadamente 2 bytes por parámetro
- INT8/Q8: Aproximadamente 1 byte por parámetro
- Q4: Aproximadamente 0.5 bytes por parámetro, más la sobrecarga del formato
Luego añade:
- Sobrecarga del runtime: buffers del framework, overhead de CUDA, fragmentación de memoria y tensores temporales
- Caché KV: crece con cada token en el contexto activo
- Memoria de batch/concurrencia: cada solicitud concurrente necesita su propio caché
- Memoria del codificador de visión: las imágenes también se convierten en tokens
- Memoria de decodificación especulativa: modelos de borrador, cabezas de borrador o estructuras de verificación extra
- Memoria de adaptadores: los adaptadores LoRA son pequeños, pero siguen siendo reales
Una estimación realista se ve así:
memoria_total = memoria_pesos + caché_KV_para_contexto + sobrecarga_runtime + sobrecarga_batch_o_concurrencia + margen_de_seguridad
La trampa: Un modelo de 13B en Q4 puede caber fácilmente con un contexto de 8K, y luego fallar a los 32K porque el caché KV se cuadruplicó. Los pesos no cambiaron. El contexto sí.
Deja un margen de seguridad del 10 al 20 por ciento. Ejecutar al 99 por ciento de utilización de VRAM es pedir errores de falta de memoria (OOM) y fallos de fragmentación.
Niveles de hardware prácticos
Estas son reglas de oro prácticas para 2026, asumiendo inferencia cuantizada y longitudes de contexto sensatas:
| VRAM | Modelos viables | Contexto práctico |
|---|---|---|
| 8-12 GB | 3B-7B en Q4 | 4K-8K tokens |
| 16 GB | 7B-14B en Q4/Q5 | 8K-16K tokens |
| 24 GB | 14B-32B en Q4/Q5 | 8K-32K tokens |
| 48 GB+ | 32B-70B en Q4/Q5 | 16K-64K tokens |
El rendimiento depende del ancho de banda de memoria, los FLOPs de la GPU, la capacidad de VRAM, el tamaño del caché KV, la implementación de atención, la cuantización, el tamaño del batch, la longitud del prompt, la longitud generada y la madurez del runtime.
La decodificación suele estar limitada por el ancho de banda de memoria: la GPU transmite los pesos del modelo repetidamente mientras realiza relativamente poca computación por byte. El prefill es más limitado por la computación porque puede procesar el prompt en paralelo.
La configuración local más dolorosa es aquella donde el modelo casi cabe y vuelca capas a la CPU. Puede funcionar técnicamente, pero la velocidad de los tokens puede colapsar. El offload a CPU es aceptable para experimentación. No es una estrategia de rendimiento.
Selección de modelo
La pregunta práctica no es ¿Cuál es el mejor modelo? Es ¿Cuál es el modelo más pequeño que gana en tu carga de trabajo real sobre tu hardware?
Empieza con un modelo instruct/chat reciente que quepa cómodamente con la longitud de contexto que realmente necesitas. Usa esta puerta de memoria antes de enamorarte de un checkpoint:
pesos + caché_KV + sobrecarga_runtime ≤ 80-90% de la memoria disponible
Luego ejecuta los mismos 20 a 50 prompts en varios candidatos. Incluye tus tareas reales: ediciones de código, Q&A de documentos, salida JSON, llamadas a herramientas, contexto largo. Mide calidad de respuesta, latencia, uso de memoria, fiabilidad de la plantilla y modos de fallo.
Una elección de modelo práctica suele reducirse a cinco comprobaciones:
- Ajuste de tarea: Chat, código, documentos, agentes, multimodal, edge o fine-tuning
- Ajuste de memoria: Pesos, caché KV, sobrecarga del runtime y margen de seguridad
- Ajuste de interfaz: Tokenizer, plantilla de chat, tokens de parada, esquema de herramientas y modo de razonamiento
- Ajuste de runtime: ¿Tu runtime soporta esta arquitectura, cuantización, longitud de contexto y modo de servicio bien?
- Ajuste de licencia: ¿Puedes usarlo realmente donde planeas usarlo?
Los leaderboards son útiles para el descubrimiento. No son un sustituto de tus propias evaluaciones. Tu carga de trabajo es el benchmark que importa.
Privacidad y seguridad
Los LLM locales mejoran la privacidad porque los prompts y las salidas pueden permanecer en tu hardware. Pero local no significa automáticamente seguro.
Las amenazas incluyen: archivos de modelos maliciosos, carga de pesos basada en pickle, inyección de prompts en documentos recuperados, abuso de llamadas a herramientas, fuga de secretos a través de logs, telemetría de aplicaciones de escritorio, extensiones o plugins de navegador, alucinaciones del modelo en entornos de alto riesgo, violaciones de licencias y contaminación de datos durante el fine-tuning.
Línea base de seguridad
- Carga con cuidado: Prefiere safetensors o GGUF de fuentes reputadas, evita archivos .bin no confiables y no habilites
trust_remote_codecasualmente - Ejecuta con límites: Usa un usuario sin privilegios, contenedores o sandboxes para agentes, y acceso de red desactivado cuando la privacidad offline sea importante
- Protege los secretos: Mantén las credenciales fuera de los prompts e índices RAG, revisa la telemetría de las aplicaciones de escritorio y valida las llamadas a herramientas antes de su ejecución
- Versiona lo que importa: Rastrea el modelo, el prompt, el adaptador, el runtime, la cuantización y el conjunto de evaluaciones, y registra lo suficiente para depurar sin crear un desastre de privacidad
Benchmarks que importan
Haz benchmarks del stack que realmente vas a ejecutar. La puntuación de un modelo en un leaderboard en BF16 no es tu realidad local en Q4.
Mide calidad, latencia, memoria, fiabilidad y ajuste operativo:
- Calidad: Corrección en tus tareas reales, no solo en benchmarks genéricos
- Latencia: Tiempo hasta el primer token, tokens por segundo de decodificación y tiempo de extremo a extremo
- Memoria: Memoria de pesos, crecimiento del caché KV, pico de VRAM y margen de maniobra bajo carga
- Formato: Corrección de la plantilla de chat, éxito en JSON/esquemas, fiabilidad de llamadas a herramientas y comportamiento de tokens de parada
- Recuperación: Fidelidad de las citas, fundamentación de la respuesta, comportamiento ante evidencia faltante e impacto del reranker
- Operaciones: Tiempo de arranque, comportamiento de calentamiento, recuperación de fallos, registro, privacidad y seguimiento de versiones
Crea un pequeño conjunto de evaluaciones con 30 a 100 prompts representativos. Incluye respuestas esperadas o criterios de puntuación, mediciones de latencia y memoria, categorías de fallo, comprobaciones de fundamentación específicas para RAG, comprobaciones de cumplimiento de JSON y revisión humana para tareas ambiguas.
Preguntas frecuentes
¿Qué es la cuantización en LLM?
La cuantización reduce la precisión numérica de los pesos del modelo para ahorrar memoria. Un modelo de 7B en FP16 ocupa ~14 GB, pero en Q4 ocupa ~3.5 GB. La cuantización agresiva (Q2-Q3) puede degradar la calidad en matemáticas, código y tareas estructuradas.
¿GGUF o safetensors?
GGUF es el formato de llama.cpp y LM Studio, optimizado para inferencia local. Safetensors es el formato seguro de PyTorch/Transformers, usado por vLLM y SGLang. Elige según tu runtime.
¿Cuánta VRAM necesito para un modelo de 7B?
En Q4, un modelo de 7B ocupa ~3.5 GB en pesos. Con contexto de 8K y sobrecarga del runtime, necesitas ~6-8 GB de VRAM. Para 32K de contexto, considera 12-16 GB.
¿Es seguro descargar modelos de internet?
Solo si usan formatos seguros como safetensors o GGUF de fuentes reputadas. Evita archivos .bin de PyTorch que pueden ejecutar código arbitrario durante la carga.