LLM Local: Qué Motor de Inferencia Elegir

2026.05.22
Technology
717 Words
Tabla de contenidos
LLM Local: Qué Motor de Inferencia Elegir

Parte 3 de 4. Parte 1: Metodología · Parte 2: Resultados · Parte 4: FAQ y Próximos Pasos

Los números solos no te dicen qué desplegar. Aquí está mi marco práctico para elegir entre estos tres motores según patrones de carga de trabajo reales.

Marco de Decisión: Cuándo Usar Cada Motor

Después de ejecutar estos benchmarks en mis clusters, aquí está mi marco de decisión práctico:

Usa Ollama Cuando:

  • Necesitas configuración zero-config. He desplegado Ollama en Kubernetes con un solo manifiesto de Deployment. Simplemente funciona.
  • Desarrollo interactivo. El bajo TTFT lo hace sentir ágil para aplicaciones de chat.
  • Escenarios de un solo usuario. Si estás construyendo un asistente de IA personal o una herramienta de desarrollo, la simplicidad de Ollama gana.
  • Entornos con recursos limitados. A 5.8 GB de VRAM, es la opción más ligera.

Usa vLLM Cuando:

  • Sirves a múltiples usuarios. El batching continuo escala muy bien para endpoints de API.
  • El throughput máximo importa. Nada se acerca para escenarios de alta concurrencia.
  • APIs de producción. He ejecutado vLLM en producción con 99.9% de uptime. La integración de métricas Prometheus es sólida.
  • Necesitas compatibilidad con la API de OpenAI. El endpoint de vLLM es compatible drop-in con cambios mínimos.

Usa llama.cpp Cuando:

  • Necesitas inferencia solo-CPU. Si no tienes GPU, llama.cpp es tu mejor opción.
  • Se requiere integración personalizada. El núcleo en C++ te permite embeber la inferencia directamente en tu aplicación.
  • Máxima flexibilidad. Puedes ajustar cada aspecto del pipeline de inferencia.
  • Soporte multiplataforma. Corre en todas partes: Linux, macOS, Windows, incluso iOS/Android.

Instrucciones de Reproducción

¿Quieres verificar estos resultados en tu propio hardware? Así es cómo:

Prerrequisitos

  • Sistema Linux con GPU NVIDIA (24GB+ VRAM recomendado)
  • CUDA 12.x instalado
  • Docker y Docker Compose
  • Python 3.10+ con paquetes openai, psutil

Paso a Paso

Terminal window
# 1. Clone the benchmark repository
git clone https://github.com/eduard3v/llm-benchmark-harness.git
cd llm-benchmark-harness


# 2. Install dependencies
pip install -r requirements.txt


# 3. Start Ollama
docker run -d --gpus all -p 11434:11434 -v ollama:/root/.ollama ollama/ollama:0.3.12
docker exec <container_id> ollama pull llama3:8b


# 4. Start vLLM
docker run -d --gpus all -p 8000:8000 \
  --ipc=host vllm/vllm-openai:v0.5.4 \
  --model meta-llama/Meta-Llama-3-8B-Instruct


# 5. Start llama.cpp server
git clone https://github.com/ggerganov/llama.cpp.git
cd llama.cpp && make GGML_CUDA=1
./server -m models/llama3-8b-q4_k_m.gguf -c 2048 --port 8080


# 6. Run the benchmark
python benchmark_harness.py --engine ollama --concurrency 8 --requests 100 --output ollama_results.json
python benchmark_harness.py --engine vllm --concurrency 8 --requests 100 --output vllm_results.json
python benchmark_harness.py --engine llama-cpp --concurrency 8 --requests 100 --output llamacpp_results.json


# 7. Generate comparison report
python generate_report.py --results ollama_results.json vllm_results.json llamacpp_results.json

Tiempo de Ejecución Esperado

Una ejecución completa del benchmark (todos los niveles de concurrencia, 3 iteraciones cada uno) toma aproximadamente 45 minutos en el hardware especificado arriba.

FAQ

¿Cómo elijo entre Ollama y vLLM para un proyecto nuevo?

Empieza con Ollama. Toma 1 hora configurarlo y sabrás en un día si su throughput de petición única cubre tus necesidades. Si llegas al límite de concurrencia (alrededor de 16 peticiones concurrentes), migra a vLLM. He hecho esta migración dos veces y la API compatible con OpenAI significa que cambias una variable de entorno, no tu código de aplicación.

¿Puedo ejecutar Ollama y vLLM lado a lado en la misma GPU?

No de forma eficiente. Cada motor quiere control total de la memoria GPU. Los 5.8 GB de Ollama y los 9.2 GB de vLLM no caben en 24 GB simultáneamente con margen útil. El enfoque práctico los ejecuta en GPUs separadas o los programa en diferentes horarios. Yo uso time-slicing de GPU en Kubernetes con node selectors.

¿Soporta llama.cpp alguna forma de batching continuo?

No, en su modo servidor actual (b3324 al momento de las pruebas). Cada petición bloquea la GPU hasta completarse. El equipo de llama.cpp ha discutido decodificación paralela en su roadmap, pero las cargas de trabajo multitenant en producción deberían usar vLLM. La fortaleza de llama.cpp es el throughput de un solo flujo y su capacidad de embeber.

¿Cuál es la forma más rápida de hacer benchmark de mi propio modelo con este harness?

Descarga el harness, edita los nombres de modelo en las configuraciones de motor y ejecuta con --concurrency 1 --requests 20. Obtendrás métricas base en menos de 5 minutos. Para ajuste en producción, recomiendo el suite completo pero empieza con concurrencia 1, 4 y 8 para identificar la curva de throughput.

¿Cada cuánto debería re-ejecutar estos benchmarks para sistemas en producción?

Ejecuto benchmarks trimestralmente o después de cualquier cambio de infraestructura (actualización de driver CUDA, cambio de versión del motor, mejora de GPU). vLLM publica mejoras de rendimiento cada pocos meses; vi una ganancia de 15% en throughput al pasar de v0.4.0 a v0.5.4. Sin números base, no notarás mejoras ni regresiones.

¿Es la API compatible con OpenAI realmente idéntica en los tres motores?

Casi pero no exacta. Ollama y llama.cpp implementan el endpoint core de chat completions con streaming. vLLM añade function calling, salida estructurada (JSON mode) y tool use. Si tu aplicación usa estas funciones avanzadas, estás limitado a vLLM o necesitas escribir capas de abstracción.

Partes en esta serie: ← Parte 2 | Parte 4 →

# local-llm # benchmark # performance # Ollama # Vllm # llama-cpp # inference-speed