Key Takeaways
- Escritura/creación de contenido: Ollama + OpenWebUI. Sin configuración, UI de chat excelente, ventana de contexto ajustable.
- Código/revisión de código: vLLM + FastAPI + extensión VS Code. Procesamiento por lotes, inferencia paralela, streaming.
- RAG local: LlamaIndex + Ollama/vLLM + Qdrant vector DB. Chunking de documentos, embedding y recuperación integrados.
- Agentes IA: LangGraph + backend vLLM. Uso de herramientas, memoria, bucle de planificación. Curva de aprendizaje más pronunciada.
- API multiusuario: vLLM detrás de un load balancer (nginx). Gestiona 10+ solicitudes concurrentes. La opción más escalable.
- Fine-tuning: HuggingFace Transformers + LoRA + Ollama para inferencia. Entrenamiento separado del serving.
- Streaming en tiempo real: Ollama (streaming nativo) o vLLM + endpoint de streaming de tokens. Mejor UX para chatbots.
Decisión rápida: stack por nivel de hardware (abril 2026)
Elige el stack según tu GPU/VRAM. Cada combinación está probada con benchmarks reales. Los flujos de código y agentes se benefician más de modelos grandes que la escritura; el RAG depende más de la calidad del embedding que del tamaño del LLM.
| Tu hardware | Escritura | Código | RAG | Agentes |
|---|---|---|---|---|
| 4–8 GB VRAM (GTX 1660, RTX 3050) | Ollama + Phi-4 Mini | Ollama + Qwen2.5-Coder-1.5B | LlamaIndex + Phi-4 Mini | No recomendado |
| 12 GB VRAM (RTX 3060, RTX 4070) | Ollama + Llama 3.2 8B | vLLM + Qwen2.5-Coder-7B | LlamaIndex + Llama 3.2 8B | LangGraph + Ollama (más lento) |
| 16 GB VRAM (RTX 4070 Ti, RTX 4080) | Ollama + Mistral Small 3.1 | vLLM + Qwen2.5-Coder-14B | LlamaIndex + Mistral 3.1 | LangGraph + vLLM |
| 24 GB VRAM (RTX 3090, RTX 4090) | Ollama + Llama 3.3 70B Q4 | vLLM + Qwen2.5-Coder-32B | LlamaIndex + Llama 3.3 70B | LangGraph + vLLM (el más rápido) |
**Mejor stack: Ollama + OpenWebUI + editor Markdown**
Por qué este stack: OpenWebUI tiene la mejor UX de chat. No requiere código. La flexibilidad de la ventana de contexto (4K–32K) supera a LM Studio para escritura de texto largo. Más económico que las API cloud para escritores.
- 1Para 24 GB VRAM: `ollama pull llama3.3:70b` — calidad máxima, equiparable a GPT-4 (2023) en benchmarks de escritura.
- 2Para 16 GB VRAM: `ollama pull mistral-small3.1` — contexto de 128K, mejor calidad por debajo de 24 GB.
- 3Para 8 GB VRAM: `ollama pull llama3.2:8b` — buena calidad de escritura, rápido en hardware de consumo.
- 4Instala OpenWebUI via Docker: `docker run -d -p 3000:8080 ghcr.io/open-webui/open-webui:latest`.
- 5Configura la ventana de contexto (8K–32K tokens) en la configuración de OpenWebUI según la longitud del documento.
**Mejor stack: vLLM + Qwen2.5-Coder + extensión IDE**
Por qué este stack: Qwen2.5-Coder obtiene un 82% en HumanEval (mejor modelo de código open-source, abril 2026). vLLM es 3–5× más rápido que Ollama para inferencia por lotes. La compatibilidad nativa con la API de OpenAI encaja con las herramientas IDE existentes. Streaming habilitado para sugerencias en tiempo real.
Revisión de código con IA para múltiples archivos
Para revisión automatizada de varios archivos, usa el procesamiento por lotes de vLLM:
- 1Instala vLLM: `pip install vllm`.
- 2Inicia el servidor vLLM con Qwen2.5-Coder-7B: `python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-Coder-7B-Instruct --port 8000`.
- 3Para 16+ GB VRAM, usa el modelo 14B: `--model Qwen/Qwen2.5-Coder-14B-Instruct`.
- 4Conecta la extensión IDE (VS Code Continue.dev, Cursor, etc.) a `http://localhost:8000/v1`.
- 5Habilita el procesamiento por lotes para revisión de código: procesa 10 archivos en paralelo con una sola llamada API (`vllm` admite batch=10 por defecto).
# Review 10 files in parallel using vLLM batch processing
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
code_files = [
("utils.py", open("utils.py").read()),
("models.py", open("models.py").read()),
# ... up to 10 files
]
# vLLM processes all 10 in parallel (1 batch request)
reviews = []
for filename, code in code_files:
prompt = f"Review this code for bugs, style, and performance:
{code}"
response = client.chat.completions.create(
model="Qwen2.5-Coder-7B-Instruct",
messages=[{"role": "user", "content": prompt}],
temperature=0.2, # Deterministic for review tasks
)
reviews.append((filename, response.choices[0].message.content))
for filename, review in reviews:
print(f"=== {filename} ===
{review}
")Mejor stack: LlamaIndex + Ollama/vLLM + Qdrant + FastAPI UI
Por qué este stack: LlamaIndex gestiona el chunking y la recuperación. Qdrant es rápido, local y privado. Ollama proporciona embeddings (gratuito) o usa vLLM para la inferencia LLM.
- 1Instala LlamaIndex (`pip install llama-index`).
- 2Carga documentos (PDF, TXT, markdown) en LlamaIndex.
- 3Divide los documentos en chunks (1024 tokens por defecto), genera embeddings con un modelo local u OpenAI (respaldo).
- 4Almacena los embeddings en la vector DB Qdrant (se ejecuta localmente via Docker).
- 5Consulta via LlamaIndex: recupera los top-K documentos similares y envía el contexto al LLM.
- 6Envuelve en un endpoint FastAPI para UI web o integración con IDE.
Mejor stack: LangGraph + vLLM + definiciones de herramientas
Por qué este stack: LangGraph proporciona un flujo de agente estructurado. vLLM es lo suficientemente rápido para 10+ llamadas LLM secuenciales. El uso de herramientas es explícito y fácil de depurar.
- 1Instala LangGraph (`pip install langchain langgraph`).
- 2Define las herramientas (búsqueda web, calculadora, E/S de archivos) como firmas de funciones.
- 3Crea el grafo del agente con el LLM como nodo de decisión y las herramientas como nodos de acción.
- 4Usa el backend vLLM para llamadas LLM de baja latencia en bucles ajustados.
- 5Ejecuta el bucle del agente: LLM → selección de herramienta → ejecución → repetir hasta completar.
Mejor stack: vLLM + load balancer nginx + monitoreo
Por qué este stack: vLLM admite serving distribuido. Nginx multiplexa las solicitudes. Escala a 10+ usuarios concurrentes en un equipo con dual GPU. Monitorea el throughput de tokens por usuario.
- 1Despliega vLLM con `--served-model-name model-name` en un puerto fijo.
- 2Configura nginx para balancear la carga entre 2+ instancias de vLLM (una por GPU si tienes múltiples GPUs).
- 3Usa el endpoint `/v1/chat/completions` compatible con OpenAI para compatibilidad con clientes.
- 4Monitorea mediante el endpoint de scrape de Prometheus (vLLM exporta latencia de solicitudes y métricas de throughput).
- 5Configura el rate limiting por usuario con el algoritmo token bucket.
Mejor stack: HuggingFace Transformers + LoRA + Ollama (inferencia)
Por qué este stack: LoRA reduce el uso de VRAM para fine-tuning 10×. Ollama carga modelos ajustados fácilmente. Modular: entrena en una máquina, sirve en otra.
Nota (abril 2026): Meta deprecó Llama 2 para fine-tuning comercial. Haz fine-tuning en Llama 3.2 (`meta-llama/Llama-3.2-1B` o más grande) o Qwen2.5 (`Qwen/Qwen2.5-7B`) para términos de licencia Apache 2.0 / open-source. Ambos admiten LoRA y se cargan fácilmente en Ollama.
- 1Realiza fine-tuning con la librería `peft` (LoRA) para reducir el uso de VRAM.
- 2Entrenamiento: se necesita 4× la VRAM del modelo (estado del optimizador, gradientes). Ejecuta por separado de la inferencia.
- 3Exporta el adaptador LoRA a HuggingFace Hub o al sistema de archivos local.
- 4Carga el modelo ajustado en Ollama: `ollama create mymodel -f Modelfile`.
- 5O usa HuggingFace TRL (Transformers Reinforcement Learning) para RLHF.
Mejor stack: Ollama (streaming nativo) o vLLM + Server-Sent Events (SSE)
Por qué este stack: El streaming mejora el rendimiento percibido (el usuario ve cómo aparecen los tokens). Ollama es el más sencillo. vLLM tiene el mayor throughput de tokens.
- 1Ollama: llama a `/api/generate` con `stream: true`. Los tokens llegan como JSON delimitado por saltos de línea.
- 2vLLM: usa `/v1/chat/completions` con `stream: true`. Devuelve un stream SSE compatible con OpenAI.
- 3Frontend: usa la API EventSource (JavaScript) para consumir el stream y actualizar la UI por token.
- 4Deshabilita el procesamiento por lotes (batch=1) para la menor latencia posible.
¿Debo usar Ollama o vLLM?
Ollama para UI de chat + simplicidad. vLLM para servidor API + procesamiento por lotes + rendimiento. No son mutuamente excluyentes; puedes ejecutar ambos.
¿Puedo usar Ollama como API de producción?
Sí, pero vLLM es más rápido (3–5× mayor throughput). Ollama es adecuado para <10 req/seg. vLLM para 10+ req/seg.
¿Cuál es el mejor LLM local para revisión de código?
vLLM + Qwen2.5-Coder-7B-Instruct. Qwen2.5-Coder obtiene un 82% en HumanEval (el mejor open-source). vLLM procesa 10 archivos en paralelo. ~30–50 tok/seg en RTX 3060 12GB.
¿Necesito una vector DB para RAG simple?
Para <100 documentos: embeddings en memoria (np.ndarray) son suficientes. Para >100: usa Qdrant o Weaviate para evitar el exceso de memoria.
¿LangGraph es exagerado para chatbots simples?
Sí. Usa Ollama o vLLM directamente. LangGraph es para flujos de trabajo de múltiples pasos (bucles de agentes, planificación).
¿Puedo combinar backends de Ollama y vLLM?
Sí. Por ejemplo, Ollama para la UI de chat, vLLM para la API por lotes. Pueden ejecutarse en la misma máquina en puertos diferentes.
Lectura relacionada
- Mejor asistente de código IA para LLM local — Elección de IDE para tu stack de código (Cursor, Continue.dev, Cody).
- Mejores LLM locales para código 2026 — Rankings HumanEval: Qwen2.5-Coder vs DeepSeek-Coder.
- Configuración RAG local 2026 — Guía completa de implementación con LlamaIndex + Qdrant + Ollama.
- Agentes LLM locales con LangGraph — Framework de workflows de agentes con ejemplos paso a paso.
- Ollama vs LM Studio — Comparativa de backends: CLI vs GUI, velocidad, procesamiento por lotes.
- Open WebUI vs SillyTavern — Comparativa de UI de chat: profesional vs roleplay.
- ¿Cuánta VRAM necesitan los LLM locales? — Requisitos de hardware por tamaño de modelo y caso de uso.
Errores comunes al elegir un stack de LLM
- Usar Ollama para API de producción sin vLLM: Ollama tiene un límite de <10 req/seg. Para producción con 10+ usuarios concurrentes, vLLM es obligatorio. Prueba el throughput bajo carga antes de desplegar.
- Ejecutar LangGraph sin backend vLLM: Los agentes de LangGraph realizan 10+ llamadas LLM secuenciales. Ollama introduce cuellos de botella de latencia. Combina siempre LangGraph con vLLM para tiempos de respuesta por debajo del segundo.
- Mezclar Ollama + vLLM en la misma GPU sin gestión de memoria: Ambas herramientas cargan pesos en la VRAM. Dos instancias de un modelo 70B consumen 32 GB. Usa GPUs separadas o cuantiza fuertemente (Q2) para que ambos quepan.
- Elegir la ventana de contexto incorrecta para escribir: El contexto por defecto de 4K limita las sesiones de brainstorming. Para escritura de texto largo, configura una ventana de 16K–32K tokens en OpenWebUI. Compromiso: inferencia más lenta (2–3× más lento por token).
- Asumir que todos los backends son igual de rápidos: vLLM y Ollama usan kernels diferentes. En el mismo hardware, vLLM es 2–3× más rápido para inferencia. La diferencia de velocidad está en el backend, no en el frontend (OpenWebUI, LM Studio son solo UIs).
Fuentes
- Ollama GitHub — Documentación oficial, especificación de la API de streaming y biblioteca de modelos.
- vLLM GitHub — Compatibilidad con la API de OpenAI, procesamiento por lotes y documentación de continuous batching.
- Informe técnico de Qwen2.5-Coder — Alibaba Qwen. Puntuación HumanEval del 82%, especializado en tareas de código. Licencia Apache 2.0.
- Documentación de LlamaIndex — Framework de indexación de documentos, chunking y recuperación RAG.
- Documentación de LangGraph — Framework de workflows de agentes, máquinas de estado, patrones de uso de herramientas.
- Documentación de Qdrant — Base de datos vectorial para almacenamiento local de embeddings, lista para Docker, Apache 2.0.
- Documentación de Continue.dev — Extensión IDE para VS Code y JetBrains usando backends LLM locales.