Skip to content

English · Español

Lab 04 — Survey: vLLM, TGI, y qué añade la producción

🇪🇸 Has implementado un mini continuous batcher. Los sistemas de producción (vLLM, TGI, Triton, Ray Serve) hacen lo mismo a otra escala. Esta lab es lectura, no código: identifica qué añaden, por qué, y qué dejas sobre la mesa al usarlos.

Objetivo

Una lab sin código. Lee la documentación y los papers clave de tres servidores de inferencia de producción, identifica qué añaden más allá del scheduler del lab 03, y escribe una comparación de 2 páginas. Esto construye el vocabulario que necesitarás en las Fases 34 (observabilidad), 35 (distribuido) y 39 (capstone).

Lectura requerida

  1. vLLM — paper de PagedAttention. Kwon et al. 2023, "Efficient Memory Management for Large Language Model Serving with PagedAttention." Lee el abstract, §1 (motivación), §3 (PagedAttention), §4 (scheduling). Salta los internos del kernel en la primera pasada.

  2. TGI (Hugging Face Text Generation Inference) — README y doc de arquitectura. Lee el README de GitHub y la página de docs sobre "How TGI works internally" (o equivalente en el momento de la lectura).

  3. NVIDIA Triton Inference Server — Concepts. Lee las páginas "Inference Request Lifecycle" y "Dynamic Batching". Triton soporta muchos tipos de modelo; foco en serving de LLM.

  4. (Opcional) Documentación de Ray Serve / Anyscale Endpoints para la capa de orquestación.

Tareas

  1. Construye una matriz de features. Haz una tabla markdown con columnas para cada sistema (Tu lab-03 / vLLM / TGI / Triton). Filas:
Feature Tu lab-03 vLLM TGI Triton
Continuous batching ✅ ✅ ✅ ✅ (dynamic batching)
PagedAttention KV cache ❌ ✅ parcial varía
Speculative decoding ❌ ✅ ✅ varía
Tensor parallel ❌ ✅ ✅ ✅
Prefix caching ❌ ✅ parcial ❌
Streaming output ❌ ✅ ✅ ✅
Multi-model hosting ❌ ❌ ❌ ✅
API HTTP nativa ✅ (FastAPI) ✅ (compatible OpenAI) ✅ gRPC/HTTP
Hot-swap de adapter (LoRA) ❌ ✅ ✅ parcial
Log probs por petición ✅ (trivial) ✅ ✅ varía
Open source n/a Apache 2.0 Apache 2.0 BSD-3

Añade 3-5 filas más propias basadas en tu lectura.

  1. Identifica la única cosa que cada sistema añade de forma única.

  2. vLLM: PagedAttention — resuelve el problema de fragmentación de memoria del KV-cache a escala.

  3. TGI: integración estrecha con HuggingFace + rendimiento Rust para el scheduler.
  4. Triton: agnóstico al backend — el mismo servidor puede hospedar ONNX, TensorRT, PyTorch, Python custom.

Para cada uno, escribe 3-5 frases en inglés llano.

  1. Identifica qué perderías al cambiar. Si reemplazaras tu scheduler del lab-03 con vLLM mañana, ¿qué dejarías de poder hacer? Ejemplos:
  2. Loop del agente custom (vLLM está construido para APIs estilo completion, no agente-con-tools).
  3. Estrategias de muestreo custom (vLLM tiene las suyas; integrar las tuyas no es trivial).

  4. Visibilidad en el scheduler (los internos de vLLM están abstraídos — para producción, está bien; para aprender, es un muro).

  5. Identifica qué ganarías. Mismo ejercicio desde la otra dirección:

  6. PagedAttention → 2-4× más peticiones concurrentes con la misma memoria.
  7. Prefix caching → ~1.5-3× de speedup para workloads de chat con prefijos compartidos.

  8. Hardening de producción (rate limiting, métricas, multi-replica) sin escribirlo tú mismo.

  9. Criterio de decisión. Escribe 3-5 frases: "El tutor de gramática de Lynx Cortex usaría [X] en producción porque [razones]." No hay una única respuesta correcta. El punto es articular el trade-off.

  10. Referencias forward. Lista las fases que construyen sobre esto:

  11. Fase 34 — observabilidad: vLLM emite métricas Prometheus; las consumirás.
  12. Fase 35 — distribuido: tensor parallel llega en vLLM/TGI.
  13. Fase 39 — capstone: el tutor de gramática de producción; probablemente correrás vLLM o TGI bajo el capó.

Entregables

Guarda en experiments/<date>-phase-33-lab-04/:

  • survey.md — el write-up de 2 páginas con la matriz de features y tu discusión.
  • decision.md — tu criterio de decisión con razonamiento.

Aceptación

  • El survey es factualmente correcto (sin features alucinadas). Cita fuentes por URL o título del paper.
  • La matriz de features tiene al menos 12 filas (las 11 de arriba + al menos una propia).
  • El criterio de decisión es específico a la workload del tutor de verbos del §A13, no genérico.

Trampas

  • Confundir dynamic batching (término de Triton) con continuous batching. Dynamic batching es lo que construiste en el lab 02 (static batching con un deadline flexible). Continuous batching es lo que construiste en el lab 03 (scheduling a nivel de iteración). El "dynamic batching" de Triton se acerca más al lab 02; vLLM y TGI implementan continuous batching de verdad.
  • Leer demasiado profundo. Esta es una lab de lectura de 2-3 horas. No te dejes succionar por los internos del kernel de PagedAttention — eso es la Fase 27.
  • Confundir frameworks. vLLM, TGI, Triton, Ray Serve, KServe, BentoML, Modal — no son todos la misma capa. vLLM/TGI son engines; Triton/Ray Serve son orquestadores; KServe es pegamento de Kubernetes. Sé preciso.

Stretch

  • Ejecuta vLLM localmente (CPU-only, sobre un modelo pequeño de HF Hub si es compatible) y sirve una petición única. Compara su interfaz curl con tu servicio del lab-03.
  • Compara la latencia de tu lab-03 sobre la workload de verbos contra vLLM (si es compatible). No esperes ganar; vLLM es una inversión de ingeniería de varios años. El ejercicio es ver la magnitud del gap.

Fin de los labs de la Fase 33. Es hora de escribir PHASE_33_REPORT.md y reflexionar.