Key Takeaways
- La cuantización convierte los pesos del modelo de 16 bits a 4 u 8 bits, reduciendo la RAM entre un 50–75%.
- Q4_K_M es el nivel estándar recomendado — mejor equilibrio entre calidad y RAM para hardware de consumo.
- Un modelo 7B en FP16 = ~14 GB de RAM. En Q4_K_M = ~4,5 GB. En Q8_0 = ~7 GB.
- La pérdida de calidad en Q4_K_M es del 1–3% en benchmarks MMLU frente a FP16 — imperceptible en la mayoría de tareas prácticas.
- GGUF es el formato de archivo que almacena modelos cuantizados para llama.cpp, Ollama y LM Studio.
¿Qué es la cuantización de LLM y por qué importa?
La cuantización convierte los pesos del modelo de 16 bits (FP16) a enteros de 4 u 8 bits, reduciendo la RAM entre un 50–75% con solo un 1–3% de pérdida de calidad en Q4_K_M. Un modelo de lenguaje grande almacena su conocimiento aprendido como miles de millones de pesos numéricos. Por defecto, estos se almacenan como números de punto flotante de 16 bits (FP16) — dos bytes por peso. Un modelo 7B tiene 7 mil millones de pesos, por lo que el tamaño del archivo FP16 es de aproximadamente 14 GB.
La cuantización reemplaza estos floats de 16 bits con enteros de menor precisión. Con cuantización de 4 bits, cada peso usa 0,5 bytes en lugar de 2 — reduciendo la memoria a ~3,5 GB solo para los pesos. Con el overhead de metadatos, un modelo 7B cuantizado a Q4_K_M tiene aproximadamente 4,5 GB.
Esto importa para la inferencia local porque el hardware de consumo tiene RAM limitada. Sin cuantización, un modelo 7B requiere 16 GB de RAM para ejecutarse. Con cuantización Q4_K_M, el mismo modelo funciona con 6 GB de RAM, haciéndolo accesible en la mayoría de laptops modernos.
¿Qué es la cuantización Q4_K_M?
Q4_K_M es un formato de cuantización GGUF de 4 bits utilizado en llama.cpp y Ollama. La "K" significa que usa K-quants (precisión mixta), y "M" = medium — un equilibrio entre tamaño del modelo, velocidad y pérdida de calidad. Q4_K_M almacena la mayoría de los pesos a 4 bits pero usa 6 bits para las capas más sensibles, lo que le da una mejor relación calidad/tamaño que el Q4_0 puro de 4 bits.
- Q4_K_M usa ~4,5 GB de RAM para un modelo 7B — un 70% menos que FP16 — con solo un 1–3% de pérdida de calidad
- Los K-quants aplican diferente precisión a distintos grupos de pesos según su sensibilidad (los pesos importantes obtienen más bits)
- La variante "M" es la versión estándar recomendada (también existen las variantes más ligera "S" y más pesada "L")
- Q4_K_M es la elección predeterminada para hardware de consumo con 6–16 GB de VRAM
- Funciona con Ollama (`ollama run model:q4_k_m`), LM Studio y llama.cpp
¿En qué se diferencian Q4_K_M, Q5_K_M, Q8_0 y otros niveles?
Q4_K_M a 4 bits es la recomendación estándar — aproximadamente 4,5 GB de RAM para un modelo 7B con solo un 1–3% de pérdida de calidad frente a FP16. Los nombres de cuantización siguen un patrón: Q{bits}_{variante}. El número de bits es la precisión de los pesos; la variante afecta cómo se aplica la cuantización:
| Nivel | Bits | RAM (7B) | Pérdida de calidad | Cuándo usar |
|---|---|---|---|---|
| Q2_K | 2 | ~2,7 GB | Alta | RAM < 4 GB, acepta degradación de calidad |
| Q3_K_S | 3 | ~3,3 GB | Moderada | RAM 4-5 GB |
| Q4_K_M | 4 | ~4,5 GB | Baja (1-3%) | Predeterminado para la mayoría de usuarios |
| Q5_K_M | 5 | ~5,7 GB | Mínima (<1%) | 16 GB de RAM, mejor calidad |
| Q6_K | 6 | ~6,6 GB | Casi sin pérdida | 16 GB de RAM, tareas de código/matemáticas |
| Q8_0 | 8 | ~7,7 GB | Insignificante | 16+ GB de RAM, máxima calidad |
¿Qué es el formato GGUF y cómo se relaciona con la cuantización?
GGUF (GPT-Generated Unified Format) es el estándar de archivo único para pesos de LLM cuantizados, que contiene pesos del modelo, metadatos y tokenizador — utilizado por Ollama, LM Studio y llama.cpp. Fue creado por el proyecto llama.cpp y reemplaza al formato GGML anterior.
Un archivo GGUF contiene: los pesos del modelo cuantizados, todos los metadatos del modelo (arquitectura, tokenizador, longitud de contexto) y un número de versión del formato. Este diseño autosuficiente significa que un único archivo `.gguf` es todo lo necesario para ejecutar el modelo — sin archivos de tokenizador separados, sin JSON de configuración.
A partir de abril de 2026, GGUF es el formato estándar para Ollama, LM Studio, Jan AI y GPT4All. Cuando ejecutas `ollama pull llama3.1:8b`, Ollama descarga internamente un archivo GGUF. Cuando LM Studio muestra tamaños de archivos de modelos, esos son tamaños de archivos GGUF.
El nivel de cuantización es parte del nombre de archivo: `Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf` es un GGUF cuantizado a Q4_K_M de Llama 3.1 8B.
¿Cuánta RAM ahorra la cuantización para diferentes tamaños de modelos?
| Tamaño del modelo | FP16 | Q8_0 | Q4_K_M | Q3_K_S |
|---|---|---|---|---|
| 3B | ~6 GB | ~3,8 GB | ~2 GB | ~1,6 GB |
| 7B | ~14 GB | ~7,7 GB | ~4,5 GB | ~3,3 GB |
| 13B | ~26 GB | ~14 GB | ~8,5 GB | ~6 GB |
| 34B | ~68 GB | ~36 GB | ~22 GB | ~16 GB |
| 70B | ~140 GB | ~70 GB | ~40 GB | ~30 GB |
¿Cuánta calidad se pierde realmente con la cuantización?
Q4_K_M pierde un 1–3% en benchmarks MMLU frente a FP16 — imperceptible en la mayoría de tareas prácticas. Q3_K_S pierde un 5–10% y es notorio en matemáticas y razonamiento. La pérdida de calidad por cuantización se mide comparando puntuaciones de benchmarks entre versiones de precisión completa y cuantizadas. A abril de 2026, los hallazgos establecidos son:
La cuantización reduce el uso de memoria pero puede degradar la calidad de las respuestas. Los prompts bien diseñados compensan esto: técnicas como ejemplos few-shot y restricciones de salida explícitas ayudan a los modelos cuantizados a mantener la precisión. Consulta las técnicas de prompt engineering para métodos que funcionan a cualquier nivel de cuantización.
- Q4_K_M vs FP16: degradación del 1–3% en MMLU. En un modelo 7B que puntúa 73% en FP16, Q4_K_M puntúa 71–72%. En tareas prácticas, esta diferencia es imperceptible.
- Q3_K_S vs FP16: degradación del 5–10%. Notoria en razonamiento complejo y tareas matemáticas. Un modelo que resuelve correctamente un problema matemático en FP16 puede fallar en Q3_K_S.
- Q2_K vs FP16: degradación del 15–25%. Pérdida de calidad significativa en todos los tipos de tareas. Usar solo cuando la restricción de RAM es absoluta.
- Q8_0 vs FP16: menos del 0,5% de degradación — esencialmente idéntico para todos los propósitos prácticos.
- Las variantes K_M (K-Quant Medium) usan un enfoque de precisión mixta que preserva mejor la calidad que la cuantización Q4_0 antigua con el mismo número de bits. Siempre prefiere Q4_K_M sobre Q4_0 cuando ambos estén disponibles.
¿Qué cuantización debes usar? (Árbol de decisión rápido)
Elige según tu VRAM disponible, no solo según el tamaño del modelo. La tabla siguiente muestra qué cuantización seleccionar para diferentes restricciones de hardware.
- Para 6 GB de RAM (laptop/desktop más común): Usa Q4_K_M. Un modelo 7B cuantizado a Q4_K_M es ~4,5 GB, dejando 1,5 GB para el SO y el navegador.
- Para tareas de código o matemáticas: Usa Q5_K_M o superior incluso si tienes presupuesto para Q4_K_M. Los efectos de cuantización (pérdida del 1–3%) son más visibles en el razonamiento numérico preciso. Para una configuración de código air-gapped de extremo a extremo que combina Q5_K_M Qwen3-Coder con operación sin internet, consulta LLM de código local sin internet.
- Compensación cuantización + temperatura: Un modelo Q4_K_M a temperatura 0.3 produce una salida más determinista que un modelo de precisión completa (FP16) a temperatura 1.0. Para ajuste independiente, consulta temperatura y top-p: controla la creatividad de la IA.
| Tu VRAM | Mejor cuantización | Tamaño de modelo | Calidad |
|---|---|---|---|
| 4–6 GB | Q3_K_S o Q4_K_M | 3B, 7B (Q4) | 7B (Q3) | Pérdida del 5–10% (Q3) | 1–3% (Q4) |
| 6–8 GB | Q4_K_M (recomendado) | 7B nativo | Pérdida del 1–3% (imperceptible) |
| 12–16 GB | Q5_K_M | 7B, 13B nativo | Pérdida <1% (mínima) |
| 24 GB (RTX 4090) | Q5_K_M o Q6_K | 13B, 32B nativo | Q4 + offload para 70B | Insignificante <0,5% |
| 32 GB (RTX 5090) | Q5_K_M, Q6_K o Q8_0 | 70B en Q4 (35 GB), Q5 (43 GB) | Pérdida del 0–2% |
| 48+ GB (2× RTX 4090) | Q5_K_M o Q8_0 | 70B nativo con layer splitting | Insignificante <0,5% |
LM Studio: cómo seleccionar la cuantización en la interfaz
LM Studio (aplicación de escritorio) muestra las variantes de cuantización disponibles para cada descarga de modelo. Al buscar un modelo, verás múltiples opciones GGUF: Q2_K, Q3_K_S, Q4_K_M, Q5_K_M, Q6_K, Q8_0.
Paso 1: Abre LM Studio → Navega a la pestaña "Modelos locales". Busca un modelo (p. ej., "Llama 3.1 8B"). Paso 2: Cada modelo muestra las cuantizaciones disponibles. Fíjate en el tamaño del archivo para estimar el uso de VRAM. Q4_K_M para un modelo 7B suele aparecer como ~4,5 GB. Paso 3: Haz clic en el ícono de descarga junto a la cuantización elegida.
Valores predeterminados recomendados para LM Studio:
- Si tu GPU tiene 6-8 GB de VRAM (RTX 4060, RTX 3060 Ti, RTX 4060 Ti): Descarga la variante Q4_K_M (archivo más pequeño con calidad aceptable).
- Si tu GPU tiene 12-16 GB de VRAM (RTX 4070, RTX 4080): Descarga Q5_K_M o Q6_K (mejor calidad, aún dentro del VRAM).
- Si tu GPU tiene 24+ GB de VRAM (RTX 4090, RTX 5090): Descarga Q8_0 o FP16 (máxima calidad, penalización mínima de velocidad).
La función "GPU offload" de LM Studio: Activa el interruptor "Usar GPU" en la interfaz de chat. LM Studio moverá automáticamente la mayor cantidad posible de capas del modelo a la GPU, dejando el resto en RAM de CPU. Si la RAM del sistema es suficiente, esto permite ejecutar modelos ligeramente más grandes que tu VRAM de GPU (p. ej., Llama 3.3 70B Q4_K_M en RTX 4090 con 64+ GB de RAM del sistema).
Offloading: RAM de CPU como desbordamiento
Cuando la VRAM está llena, los modelos pueden descargar (mover) capas a la RAM del sistema. El offloading cambia velocidad por capacidad.
Escenario: ejecutar el modelo 70B Q4 en RTX 4090 (24 GB). El modelo necesita 35 GB. Con offloading, ejecuta a ~5-10 tokens/seg (80% hacia la RAM).
El offloading es un último recurso — hace que la inferencia sea poco práctica. Úsalo solo para procesamiento por lotes offline o experimentación.
# Ollama: enable offloading
export OLLAMA_NUM_GPU=0 # Disable GPU (force CPU)
ollama run llama3.3:70b
# vLLM: enable CPU offload (partial)
vllm serve meta-llama/Llama-3.3-70B-Instruct \
--gpu-memory-utilization 0.7 \
--cpu-offload-gb 10 # Offload 10GB to RAMLayer splitting: distribuir entre múltiples GPUs
Los motores de inferencia modernos (vLLM, llama.cpp) pueden dividir un modelo entre múltiples GPUs automáticamente. Más información sobre LLMs locales multi-GPU para configuraciones avanzadas.
Ejemplo: modelo 70B con 2× RTX 4090:
- Sin splitting: Imposible (necesita 40+ GB de VRAM en una sola GPU).
- Con splitting: La mitad de los pesos del modelo en cada GPU. Velocidad de inferencia: ~100 tokens/seg (la latencia de comunicación es mínima).
El layer splitting es práctico para despliegues en producción y es transparente para el usuario.
# vLLM: automatic tensor parallelism
vllm serve meta-llama/Llama-3.3-70B-Instruct \
--tensor-parallel-size 2 # Split across 2 GPUs
# llama.cpp: multi-GPU support
ollama run llama3.3:70b # Auto-detects and splits across GPUsCuantización de KV Cache: reducir el overhead de memoria de contexto
La cuantización de KV Cache reduce la memoria necesaria para almacenar los pares clave-valor de atención durante la inferencia, especialmente importante al procesar contextos largos (32K+ tokens). Mientras que la cuantización de pesos del modelo (Q4_K_M) es la más común, la cuantización de KV Cache apunta a un cuello de botella de memoria diferente.
Durante la inferencia, el modelo mantiene pares clave-valor (KV) en ejecución para cada token del contexto. Para un modelo 7B procesando un contexto de 32K tokens, el KV cache por sí solo puede consumir 8–16 GB de VRAM según la precisión. El KV cache estándar usa FP16 (2 bytes por valor); cuantizar el KV cache a FP8 o Q8 lo reduce en un 50%.
Cómo activar la cuantización de KV Cache:
- Ollama: Automático en modelos compatibles; no se necesita configuración del usuario.
- LM Studio: Activa el interruptor "KV cache quantization" en Configuración (si está disponible en tu versión).
- llama.cpp: Usa las flags `--cache-type-q8_0` o `--cache-type-f8` al iniciar el servidor.
Compromisos: La cuantización de KV Cache tiene un impacto mínimo en la calidad (<1% de degradación incluso con cuantización agresiva) porque los patrones de atención son más robustos a menor precisión que los pesos del modelo. Recomendado para modelos que procesan contextos de 16K+ en hardware limitado.
Enfoque híbrido: combinando técnicas
Los mejores resultados vienen de combinar las tres técnicas. Consulta la guía de requisitos de VRAM para planificación específica de hardware.
Escenario 1: 70B en una sola RTX 4090 (24 GB)
- Cuantizar a Q4 (35 GB → 18 GB)
- Usar offloading para los 6 GB restantes (a la RAM del sistema)
- Resultado: ~8-10 tokens/seg (lento pero funciona)
Escenario 2: 70B en 2× RTX 4090
- Cuantizar a Q5 (43,75 GB)
- Usar layer splitting entre 2 GPUs (22 GB cada una)
- Resultado: ~100 tokens/seg (práctico)
¿Cuáles son los compromisos de rendimiento?
Cada técnica cambia reducción de VRAM por penalizaciones de velocidad. La cuantización tiene un impacto mínimo; el offloading causa una ralentización de 5–10×; el layer splitting añade ~5% de overhead.
| Técnica | VRAM ahorrada | Impacto en velocidad | Impacto en calidad |
|---|---|---|---|
| Cuantización (Q4) | 50% | Ninguno (±5%) | Menor |
| Offloading (RAM de CPU) | 60-80% | 5-10× más lento | Ninguno |
| Layer splitting (2 GPUs) | N/A (habilita modelos más grandes) | 5-10% más lento | Ninguno |
| Cuantización + Offloading | 75-90% | 3-5× más lento | Menor |
Mac Studio M2 Ultra: 70B nativo sin offloading
Mac Studio M2 Ultra con 192 GB de memoria unificada ejecuta Llama 3.3 70B en Q4 de forma nativa — sin offloading, sin layer splitting.
Ancho de banda de memoria unificada: Mac Studio M2 Ultra accede tanto a la memoria de CPU como de GPU a ~800 GB/s. El offloading de RAM DDR5 del sistema está limitado a ~90 GB/s. Esta ventaja de 9× elimina la penalización de velocidad que hace impracticable el offloading.
| Configuración | Modelo | Velocidad | Complejidad |
|---|---|---|---|
| 1× RTX 4090 + offloading | Llama 3.3 70B Q4 | 5–10 tok/seg | Media |
| 2× RTX 4090 layer split | Llama 3.3 70B Q5 | ~100 tok/seg | Alta |
| 1× RTX 5090 (32 GB) | Llama 3.3 70B Q4 | 10–12 tok/seg | Baja |
| Mac Studio M2 Ultra | Llama 3.3 70B Q4 | 35 tok/seg | Baja (plug & play) |
Cuantización de LLM: contexto regional
- UE (RGPD, Artículo 44) — Las transferencias transfronterizas de datos de IA requieren decisiones de adecuación o Cláusulas Contractuales Estándar. La cuantización Q4_K_M permite que modelos 7B se ejecuten en dispositivos edge de 8 GB, eliminando por completo las llamadas a APIs de nube de terceros. La AEPD española y la CNIL francesa recomiendan la inferencia local para el procesamiento de IA de alto riesgo bajo el Artículo 22 del RGPD. Los modelos Mistral y Llama cuantizados son las opciones dominantes en despliegues empresariales de la UE por esta razón.
- Japón (Directrices de Gobernanza de IA de METI 2024) — El Ministerio de Economía, Comercio e Industria de Japón requiere documentación de gobernanza de IA para despliegues empresariales. Los modelos cuantizados en infraestructura doméstica satisfacen los requisitos de "controlabilidad" de METI — los pesos del modelo permanecen en las instalaciones. La cuantización Q4_K_M hace viables modelos de 13B-32B en servidores corporativos de 16-32 GB sin clústeres de GPU. Qwen2.5 y Llama 3 son las familias más desplegadas en entornos empresariales japoneses.
- China (Regulaciones de IA Generativa del CAC 2023) — La Administración del Ciberespacio de China requiere evaluaciones de seguridad para la IA desplegada públicamente y localización de datos para datos de usuarios. Los modelos chinos nativos cuantizados (Qwen2.5, Baichuan2, Yi) se ejecutan completamente en hardware doméstico, satisfaciendo los requisitos de localización del CAC. La cuantización Q4_K_M y Q5_K_M reduce los costos de hardware en un 60-70% frente a FP16, haciendo económicamente viable el cumplimiento del CAC en instalaciones propias para empresas medianas.
¿Cuáles son los errores comunes con la cuantización de LLM?
- Descargar Q4_0 en vez de Q4_K_M — Q4_0 es un método de cuantización más antiguo sin las mejoras de K-Quant. Q4_K_M es un 5-8% mejor en calidad con el mismo uso de RAM. Cuando ambos estén disponibles, elige siempre Q4_K_M.
- Asumir que mayor cuantización siempre significa peor calidad — Mayor número Q = más bits = mejor calidad. Q8_0 es mejor que Q4_K_M. Q5_K_M es mejor que Q4_K_M. Un modelo Q4_K_M de 70B superará a un modelo Q8_0 de 7B en la mayoría de tareas.
- No verificar el espacio libre de RAM antes de cargar un modelo — El tamaño del modelo no es el único consumidor de RAM. El SO, el navegador y otras aplicaciones también usan RAM. En una máquina de 8 GB, un modelo 7B Q4_K_M de 4,5 GB deja solo 3,5 GB para todo lo demás. Regla: tamaño del archivo del modelo + 2 GB de overhead del SO + 1 GB de margen = RAM mínima requerida.
Preguntas frecuentes sobre cuantización de LLM
¿Ollama usa automáticamente la mejor cuantización?
Sí — cuando ejecutas `ollama pull llama3.1:8b`, Ollama descarga la variante Q4_K_M por defecto. Para obtener una cuantización específica, añade el tag: `ollama pull llama3.1:8b-instruct-q5_K_M`. Los tags de cuantización disponibles para cada modelo están listados en la página del modelo en ollama.com/library.
¿Puedo cuantizar un modelo yo mismo en lugar de descargar una versión pre-cuantizada?
Sí — llama.cpp incluye un binario `quantize` que convierte archivos GGUF a cualquier nivel de cuantización soportado. El proceso tarda 5-30 minutos dependiendo del tamaño del modelo. La mayoría de usuarios debería descargar archivos GGUF pre-cuantizados de Hugging Face en lugar de cuantizar ellos mismos, ya que los resultados son equivalentes.
¿La cuantización afecta la ventana de contexto del modelo?
No — la cuantización solo afecta la precisión de los pesos del modelo, no la longitud del contexto. Un modelo Llama 3.1 8B soporta 128K tokens tanto si está cuantizado a Q4_K_M como si se ejecuta en FP16. Sin embargo, procesar contextos más largos requiere más RAM independientemente de la cuantización — procesar un contexto de 64K tokens con un modelo 7B Q4_K_M puede requerir 10+ GB de RAM.
¿Cuál es la diferencia entre cuantización GGUF y GPTQ?
GGUF (formato llama.cpp) y GPTQ son dos enfoques de cuantización diferentes. GGUF usa K-Quants y funciona en CPU y GPU. GPTQ es solo para GPU y requiere PyTorch. Para inferencia local con Ollama, LM Studio o Jan AI, GGUF es el formato correcto. GPTQ se usa con frameworks de inferencia orientados a GPU como AutoGPTQ y vLLM.
¿Hay diferencia de calidad entre modelos Q4_K_M de diferentes proveedores en Hugging Face?
El algoritmo de cuantización está estandarizado en llama.cpp, por lo que las cuantizaciones Q4_K_M del mismo modelo base deberían ser casi idénticas independientemente de quién haya creado el archivo GGUF. Sin embargo, algunos proveedores aplican ajustes adicionales (cuantización imatrix) que mejoran la calidad. Los archivos descritos como cuantizados con "imat" o "importance matrix" son generalmente de mayor calidad con el mismo número de bits.
¿Qué es la cuantización imatrix?
La cuantización imatrix (importance matrix) usa datos de calibración para asignar diferentes niveles de precisión a diferentes pesos según su importancia para la salida del modelo. Los pesos que más afectan las predicciones se cuantizan con más bits; los pesos menos importantes usan menos bits. Resultado: mejor calidad con el mismo número de bits en comparación con la cuantización uniforme. Las cuantizaciones imatrix de Qwen2.5 son un 2-4% mejores que el Q4_K_M estándar.
¿Cuál es la diferencia entre Q4_K_M y Q4_K_S?
Ambas son cuantización de 4 bits, pero K_M (Medium) y K_S (Small) difieren en la asignación de memoria por bloque de cuantización. Q4_K_M usa más metadatos para una mejor reconstrucción de calidad — típicamente 4,5-5 GB para un modelo 7B. Q4_K_S es más agresivo — ahorra 300-400 MB comparado con K_M pero con una pérdida de calidad del 3-5%. Usa Q4_K_M a menos que estés en hardware extremadamente limitado (< 4 GB de RAM).
¿Puedo cambiar entre niveles de cuantización sin redownloadear el modelo?
No — cambiar entre niveles de cuantización requiere descargar un archivo GGUF diferente o re-cuantizar el modelo base tú mismo. Una vez que un modelo está cuantizado a Q4_K_M, no puedes convertirlo de vuelta a Q5_K_M sin el modelo FP16 original. La mayoría de usuarios descarga archivos GGUF pre-cuantizados de Hugging Face para su nivel de cuantización deseado.
¿Cómo afecta la cuantización a la velocidad de inferencia?
La cuantización típicamente aumenta la velocidad de inferencia entre un 10-40% porque cargar y procesar pesos de 4 bits es más rápido que los floats de 16 bits. Un modelo 7B Q4_K_M funciona a ~8-12 tok/s en una CPU de consumo; el mismo modelo en FP16 funciona a ~1-2 tok/s. La ganancia de rendimiento GPU por cuantización es menor (5-15% más rápido) porque las GPUs ya están optimizadas para aritmética de punto flotante.
¿Qué nivel de cuantización usa Ollama por defecto?
Ollama usa Q4_K_M por defecto para todos los modelos de su biblioteca. Cuando ejecutas `ollama pull llama3.1:8b`, estás descargando la variante Q4_K_M. Este valor predeterminado equilibra bien la calidad y los requisitos de RAM para la mayoría de usuarios. Para obtener una cuantización diferente, añade el tag: `ollama pull llama3.1:8b:q5_k_m` o `ollama pull llama3.1:8b:q8_0`.
¿Puedo ejecutar Llama 3.3 70B en una sola RTX 4090?
Sí, pero lento. Cuantiza a Q4 (35 GB), hace offload de 11 GB a la RAM del sistema. Espera 5-10 tok/seg — demasiado lento para chat en tiempo real, bien para procesamiento por lotes. Para inferencia práctica de 70B: 2× RTX 4090 con layer splitting (~100 tok/seg) o Mac Studio M2 Ultra (35 tok/seg nativo).
¿Cuál es la diferencia entre cuantización y offloading?
La cuantización reduce la precisión de los pesos del modelo de forma permanente (FP16 → Q4), reduciendo el archivo del modelo. El offloading mueve capas del modelo de la VRAM a la RAM del sistema en tiempo de ejecución. La cuantización tiene un impacto mínimo en la calidad (±5%); el offloading causa una degradación de velocidad de 5–10×. Usa primero la cuantización, el offloading como último recurso.
¿Mac Studio M2 Ultra necesita cuantización para modelos de 70B?
Solo cuantización leve. 192 GB de memoria unificada contiene Llama 3.3 70B en Q4 (35 GB) de forma nativa — sin offloading ni layer splitting. En Q5, 70B todavía cabe (44 GB). FP16 70B (140 GB) también cabe pero funciona más lento. Q4 es el punto óptimo para flujos de trabajo de 70B en Mac Studio.
¿Qué combinación de técnicas es mejor para mi hardware?
RTX 4090 única (24 GB): Q4 + offloading para 70B (lento). Q5 nativo para 32B (rápido). 2× RTX 4090 (48 GB): Q5 + layer splitting para 70B (100 tok/seg). RTX 5090 (32 GB): Q4 nativo para 70B (10-12 tok/seg). Mac Studio M2 Ultra (192 GB): Q4 nativo para 70B (35 tok/seg).
Fuentes
- Documentación de cuantización de llama.cpp
- Discusión técnica sobre K-Quants — PR original de K-Quant
- Especificación del formato GGUF
- Open LLM Leaderboard — benchmarks de cuantización
Registro de actualizaciones
- 2026-05-17: Título actualizado para reflejar intención orientada a la decisión; contenido sin cambios.