Key Takeaways
- Deshabilitar logging/debugging (fácil): ~10% de mejora de velocidad.
- Usar cuantización Q4 (fácil): Misma velocidad, menos VRAM.
- Optimizar batch size (medio): 2-3× de velocidad para procesamiento por lotes.
- Usar vLLM en lugar de Ollama (difícil): 2-5× de velocidad para solicitudes concurrentes.
- Uso de memoria GPU 90%+ (medio): 15-20% de mejora de velocidad.
- Combinando todas las técnicas: ~2-3× de aceleración total.
¿Cómo afecta el uso de memoria GPU a la velocidad?
Por defecto, la mayoría de las herramientas usan el 70–80% del VRAM de la GPU, dejando memoria libre sin usar. Aumentar al 90–95% mejora la velocidad un 15–20% al permitir que el motor pre-asigne más caché KV:
# vLLM: increase GPU memory utilization
vllm serve meta-llama/Llama-2-7b-hf \
--gpu-memory-utilization 0.95
# Ollama: environment variable
export OLLAMA_GPU_THRESHOLD=0.95 # Use 95% of GPU
ollama run llama3.2:3b
# LM Studio: Settings → GPU acceleration slider (move to 100%)¿Qué batch size maximiza el throughput?
Para el procesamiento por lotes (múltiples prompts), aumentar el batch size de 1 a 32 produce una mejora de throughput de 2–4×.
Una solicitud individual = utilización limitada del pipeline. Batch de 32 solicitudes = 2–4× de throughput.
Compromiso: Mayor latencia por solicitud individual (esperan a que se complete el lote).
| Batch Size | Throughput | Latencia/Solicitud | Caso de uso |
|---|---|---|---|
| 1 (individual) | 50 tokens/seg | Mínima | Chat en tiempo real |
| 8 | 120 tokens/seg | Aceptable | Concurrencia ligera |
| 32 | 200 tokens/seg | Alta | API por lotes |
| 64+ | 250+ tokens/seg | Muy alta | Lotes offline |
¿Qué motor de inferencia es el más rápido: vLLM vs Ollama vs llama.cpp?
vLLM: 5–10× más rápido que Ollama para solicitudes concurrentes — úsalo para APIs de producción que sirven a múltiples usuarios.
llama.cpp: El más rápido para solicitudes individuales en hardware de consumo — úsalo para configuraciones locales personales.
Ollama: Mejor experiencia de desarrollo para configuraciones de un solo usuario; comparable a llama.cpp para solicitudes individuales.
Text-Generation-WebUI: El más lento, pero con más características — solo para experimentación, no para producción.
¿La cuantización realmente acelera la inferencia?
En GPUs modernas (RTX serie 40), Q4 y Q5 corren a la misma velocidad que FP16 — cuantiza para reducir VRAM, no para ganar velocidad.
Beneficios indirectos de velocidad de la cuantización:
- Archivo de modelo más pequeño = carga de arranque en frío más rápida desde disco
- Menor ancho de banda de memoria = ligeramente más rápido (10–15%) en hardware antiguo o con memoria limitada
La cuantización es principalmente para reducir VRAM, no para aumentar el throughput de tokens bruto.
¿Cuánta velocidad puedes ganar de forma realista?
Ejemplo: Optimizando un modelo 7B en RTX 4090 — paso a paso:
| Cambio | Velocidad | Ganancia acumulada |
|---|---|---|
| Ollama por defecto (línea base) | 120 tok/seg | — |
| Deshabilitar logging de debug | 132 tok/seg | +10% |
| Memoria GPU → 95% | 150 tok/seg | +25% total |
| Cambiar a vLLM (lotes) | 300 tok/seg (lotes) | +2.5× (lotes) |
| Todas las optimizaciones combinadas | 300 tok/seg | +2.5× throughput |
Errores comunes en la optimización de velocidad
- Llevar la memoria GPU al 100%. Riesgo de crashes por falta de memoria. El máximo seguro es 90-95%.
- Bajar el batch size para ganar velocidad. El batch size no afecta la latencia de solicitudes individuales. Solo ayuda al throughput.
- Cuantizar en exceso para ganar velocidad. Q4 tiene aproximadamente la misma velocidad que FP16. Cuantiza para reducir VRAM, no para ganar velocidad.
- Cambiar el motor de inferencia a mitad del despliegue. Cambiar Ollama → vLLM → llama.cpp introduce errores. Elige uno y optimízalo.
Preguntas frecuentes
¿Cuál es la forma más efectiva de acelerar la inferencia de LLMs locales?
Cambiar de Ollama a vLLM para solicitudes concurrentes proporciona la mayor aceleración individual — una mejora de throughput de 5–10× para el procesamiento por lotes. Para solicitudes individuales, aumentar el uso de memoria GPU del 70% al 90–95% da un 15–20% de mejora de velocidad. Deshabilitar el logging de debug aporta un 10% adicional.
¿El procesamiento por lotes mejora la latencia de solicitudes individuales?
No — el batch size afecta el throughput (tokens totales por segundo en todas las solicitudes), no la latencia de solicitudes individuales. Para reducir la latencia de una solicitud, optimiza el uso de memoria GPU y usa un motor más rápido (vLLM o llama.cpp). Los lotes más grandes aumentan el tiempo de espera por solicitud.
¿Cuánto más rápido es vLLM que Ollama?
Para solicitudes individuales, vLLM y Ollama tienen un rendimiento similar (ambos alcanzan ~120–150 tok/seg en una RTX 4090 con un modelo 7B). Para solicitudes concurrentes, vLLM es 5–10× más rápido gracias al batching continuo y PagedAttention. Usa Ollama para configuraciones personales/de un solo usuario; cambia a vLLM para APIs que sirven a múltiples usuarios.
¿La cuantización acelera la inferencia?
El beneficio principal de la cuantización es la reducción de VRAM, no la velocidad. En GPUs NVIDIA modernas (RTX serie 40), Q4 y Q5 corren a la misma velocidad que FP16. El beneficio indirecto de velocidad: un modelo Q4 más pequeño carga más rápido desde el disco y puede permitir batch sizes ligeramente más grandes dentro del mismo presupuesto de VRAM.
¿Qué uso de memoria GPU debo configurar para máxima velocidad?
Configura el uso de memoria GPU al 90–95% en vLLM (`--gpu-memory-utilization 0.92`). Esto permite al motor pre-asignar más memoria para el caché KV, mejorando el throughput. Evita el 100% — provoca crashes OOM cuando la generación supera las predicciones. El margen de seguridad del 5–10% es innegociable.
¿Por qué mi LLM local es más lento después del primer prompt?
El primer prompt carga el modelo en VRAM (arranque en frío), lo que puede tomar 10–30 segundos. Los prompts posteriores corren a velocidad completa. Mantén el servidor en ejecución (no lo reinicies entre sesiones). Con Ollama, configura OLLAMA_KEEP_ALIVE=24h para evitar que el modelo se descargue tras inactividad.
¿Puede acelerarse de forma significativa la inferencia solo con CPU?
Se pueden obtener ganancias limitadas: usa llama.cpp con el flag -t para ajustar el número de hilos al de núcleos físicos (no lógicos), habilita los conjuntos de instrucciones AVX2/AVX-512 y usa la cuantización Q4_K_M. Techo realista: 8–12 tok/seg en un i9 moderno. Para chat interactivo, el hardware GPU es el único camino hacia una latencia aceptable.
¿Cómo afecta la longitud del contexto a la velocidad de inferencia?
Las ventanas de contexto más largas ralentizan la inferencia porque el mecanismo de atención escala cuadráticamente con la longitud del contexto. Un prompt con contexto de 4K es ~4× más lento de procesar que uno de 1K. Mantén los prompts del sistema por debajo de 500 tokens y usa resumen de contexto para conversaciones largas y mantener la velocidad.
¿Qué es PagedAttention y por qué acelera vLLM?
PagedAttention es el sistema de gestión del caché KV de vLLM. En lugar de pre-asignar un bloque de memoria fijo por solicitud, gestiona la memoria de forma dinámica mediante paginación — como la memoria virtual en un sistema operativo. Esto elimina la fragmentación de VRAM, permite más solicitudes concurrentes y mejora la utilización de la GPU del ~55% (naive) al 90%+.
¿Hay diferencia de velocidad entre los formatos de modelo GGUF y safetensors?
Sí. GGUF (usado por llama.cpp y Ollama) está optimizado para inferencia en CPU/GPU de consumo con cuantización integrada. Safetensors (usado por vLLM y HuggingFace) es más rápido para inferencia GPU de precisión completa. Para GPUs RTX serie 40 que ejecutan FP16, safetensors + vLLM supera típicamente a GGUF + Ollama en un 10–20%.
Fuentes
- Guía de optimización vLLM -- docs.vllm.ai/en/dev_guide/performance_tuning.html
- Consejos de rendimiento de Ollama -- github.com/ollama/ollama/blob/main/docs/troubleshooting.md