Operación y gobierno de sistemas de IA on-premise

Descripción

Un sistema de gestión de IA tiene dos caras que este curso recorre de abajo arriba: la plataforma técnica que sirve un modelo de lenguaje en producción —del silicio al token— y el sistema de gestión en sentido normativo (un AIMS según ISO/IEC 42001) que la gobierna y la hace demostrable ante ENS, NIS2 y el EU AI Act.

Está pensado para que un ingeniero que ya domina Linux, redes y Kubernetes aproveche ese terreno como rampa de entrada: empezamos donde tiene ventaja (NUMA, PCIe, topología de red, RKE2) y subimos capa a capa hasta el motor de inferencia, la optimización, los datos y RAG, la operación en Kubernetes, la observabilidad y, como cierre, el gobierno del sistema.

Es eminentemente práctico: cerca de dos tercios del tiempo son laboratorios sobre un entorno real con GPU.

Objetivos

Al terminar el curso, el participante será capaz de:

• Leer la topología de un nodo de inferencia (NUMA, PCIe, NVLink, NUMA de red) y aplicar pinning y aislamiento.
• Levantar y configurar un motor de inferencia OSS (vLLM) y explicar KV cache, PagedAttention y continuous batching.
• Optimizar throughput y latencia con quantization y FP8, prefix cache y batch sizing.
• Dimensionar GPUs a partir de un SLO (capacity planning).
• Montar y evaluar un pipeline RAG con embeddings, vector store, CDC y RAGAS.
• Operar la plataforma en Kubernetes: gateway, autoscaling, canary/blue-green/shadow y runbooks.
• Instrumentar observabilidad end-to-end con OpenTelemetry GenAI, DCGM y Langfuse.
• Conectar la operación con un AIMS (ISO 42001) y el marco ENS × EU AI Act, mapeando controles a evidencias.

Requisitos

Imprescindibles

• Linux a nivel administrador: línea de comandos, systemd, diagnóstico.
• Redes: TCP/IP, enrutamiento, latencia y ancho de banda.
• Contenedores y Kubernetes a nivel intermedio (pods, deployments, services, kubectl).

Recomendables (no obligatorios)

• Python básico para leer y adaptar los scripts de los laboratorios.
• Familiaridad con Prometheus / Grafana.
• Nociones de GPU y cómputo paralelo.

No se requiere experiencia previa en machine learning.

Dirigido a

Ingenieros con buenos conocimientos de sistemas y redes que quieren introducirse en los sistemas de gestión de IA:

• Administradores de sistemas, SRE y DevOps que operan infraestructura y quieren sostener cargas de inferencia LLM.
• Ingenieros de redes e infraestructura que dimensionan y diagnostican plataformas GPU on-premise.
• Arquitectos de plataforma que evalúan llevar IA generativa on-premise bajo soberanía y compliance.
• Responsables técnicos en sectores regulados que deben conectar la operación con ENS / NIS2 / EU AI Act.

Metodología y formato

Cada sesión combina una exposición breve del concepto con un laboratorio guiado sobre entorno real. Los laboratorios son acumulativos: lo que se construye en una sesión se amplía en la siguiente.

Son 5 sesiones de 2 horas en días alternos sin fines de semana, repartidas en dos semanas. Los días alternos dejan libre el fin de semana y dan margen para repasar el concepto y el material de apoyo entre sesiones.

Requisitos técnicos del entorno

lo0.es proporciona el entorno de laboratorio; el alumno solo necesita un portátil con navegador y cliente SSH. El entorno de referencia (genérico, no específico de ningún cliente) es:

• Un nodo Linux con una GPU NVIDIA de 24 GB de VRAM (clase RTX 4090 / L4 o superior).
• Acceso puntual a un nodo multi-GPU con NVLink para los labs de topología.
• Un clúster Kubernetes ligero (RKE2 o k3s) con NVIDIA device plugin.
• Stack OSS: vLLM, Qdrant, PostgreSQL, Prometheus + DCGM exporter, OpenTelemetry Collector, Tempo, Langfuse y un gateway L7 (Envoy AI Gateway / LiteLLM).

Contenido del curso

Sesión 1 — Marco, mapa mental y la planta de abajo (2 h)

Fijamos el mapa completo y bajamos a la capa física, donde un ingeniero de sistemas y redes ya tiene ventaja.

1.1 · El mapa mental (0:30 h). Las dos acepciones de «sistema de gestión de IA» y el pipeline del curso: el panorama 2026 frente a MLOps clásico, el pipeline LLMOps de seis etapas y sus transversales, la anatomía de una petición real como hilo conductor y las siete capas del stack de inferencia on-premise.

1.2 · La planta de abajo: hardware, NUMA y red (1:30 h). Leer la topología de un nodo y aplicar pinning para que la GPU no espere al kernel: cinco niveles de madurez de la plataforma; NUMA, hugepages y aislamiento de CPU; topología PCIe, GPUDirect P2P y ACS; NVLink/NVSwitch/NCCL; NUMA de red (Cilium eBPF) y resource managers en RKE2. Lab: inspección con lstopo y nvidia-smi topo -m; vLLM con y sin pinning NUMA y hugepages, midiendo la diferencia.

Sesión 2 — El motor de inferencia y el camino del token (2 h)

Abrimos la caja negra de vLLM y seguimos un token desde el disco hasta la red.

2.1 · Memoria de trabajo y batching (1:00 h). Cómo vLLM gestiona memoria y agrupa peticiones: KV cache como memoria de trabajo, PagedAttention y el block manager, continuous batching, chunked prefill y goodput. Lab: levantar vLLM con un modelo cuantizado de 7–8B; observar KV cache y batching continuo bajo carga.

2.2 · El camino del token en la GPU (1:00 h). Recorrer el trayecto interno y ver dónde se pierde tiempo: del disco a la HBM (cold start), el scheduler step, SMs, CUDA streams y CUDA graphs, el backend de atención (FlashAttention/FlashInfer). Lab: medir cold start vs caché caliente; activar CUDA graphs y observar el efecto en el decode.

Sesión 3 — Rendimiento: optimización y dimensionado (2 h)

De «funciona» a «funciona con un coste y una latencia que puedo justificar».

3.1 · Optimizar la inferencia (1:00 h). Aplicar las palancas y medir su efecto en calidad y velocidad: quantization (FP8, INT4 — GPTQ, AWQ, GGUF), FP8 end-to-end (pesos y KV), prefill y decode como los knobs del TTFT y del throughput, prefix cache e ingeniería del hit rate. Lab: activar FP8 y medir TTFT/TPS y calidad; subir el prefix cache hit rate con prompts de sistema repetidos.

3.2 · Dimensionar la plataforma (1:00 h). Convertir un SLO en una cifra de GPUs defendible: batch sizing por grid search, una réplica grande vs N pequeñas (tensor parallel vs réplicas), capacity planning desde el SLO. Lab: grid search de batch size y curva throughput/latencia; rellenar una plantilla de capacity planning.

Sesión 4 — Datos y RAG + operación en Kubernetes (2 h)

De dónde sale el conocimiento (RAG) y cómo se mantiene el servicio en pie.

4.1 · Datos y RAG (1:00 h). Montar y evaluar un pipeline RAG operable: embeddings 2026 (denso, esparso, multi-vector), PostgreSQL + Qdrant y CDC con Debezium, reranker, hybrid retrieval y semantic cache, evaluación con RAGAS y golden dataset. Lab: RAG mínimo (Qdrant + embeddings + CDC); añadir reranker y cache; evaluar con RAGAS sobre 20 preguntas.

4.2 · Operación en Kubernetes (1:00 h). Poner la plataforma delante de usuarios con escalado y despliegues sin downtime: el router/gateway L7 y la elección del gateway OSS, autoscaling con HPA y KEDA, canary/blue-green/shadow, runbooks de incident response. Lab: desplegar vLLM en K8s con gateway; HPA/KEDA; canary 90/10 verificando el SLO.

Sesión 5 — Observabilidad, ciclo de vida y gobierno (AIMS) (2 h)

Hacemos el sistema observable y mejorable; luego demostramos que cumple.

5.1 · Observabilidad y trazabilidad (0:30 h). Instrumentar para que cada petición sea auditable: tracing end-to-end con OpenTelemetry GenAI, instrumentar vLLM con OTel, métricas DCGM y vLLM y anomalías reales, Langfuse self-hosted. Lab: instrumentar el request path con OTel; dashboard DCGM + vLLM; identificar tres anomalías inyectadas.

5.2 · Ciclo de vida del modelo (0:30 h). Cerrar el bucle de mejora continua sin reentrenar a ciegas: fine-tuning continuo en producción, retrain del incidente al adapter, evals como capa después del tracing, prompt versioning como contrato. Lab: entrenar un adapter LoRA y hot-swap; eval gate en CI que bloquea una regresión.

5.3 · Gobierno: el AIMS sobre la plataforma (capstone, 1:00 h). Conectar la operación con un AIMS y demostrar cumplimiento con las evidencias ya generadas: ISO/IEC 42001 como manual de operaciones, EU AI Act como expediente técnico, el mapeo cruzado ENS × 42001 × AI Act, guardrails y LLM Guard como controles técnicos. Lab (capstone): mapear los artefactos de las sesiones 1–5 a controles ISO 42001 / ENS / EU AI Act; matriz control → evidencia; clasificar un sistema bajo el EU AI Act.

Qué te llevas

• Repositorio de laboratorios (manifests, configs vLLM, scripts de medición).
• Plantilla de capacity planning.
• Matriz de controles ISO 42001 × ENS × EU AI Act → evidencias.
• Checklist de despliegue greenfield.
• Acceso continuado al blog Tendencias IA.
• Certificado de aprovechamiento.

Evaluación y certificado

La evaluación es práctica y continua: se valora la resolución de los laboratorios de cada sesión y el taller capstone de la sesión 5. Quien completa los laboratorios y el capstone recibe el certificado de aprovechamiento de lo0.es.

Próxima edición

• Inicio: miércoles 8 de julio de 2026 (sesiones los días 8, 10, 13, 15 y 17 de julio).
• Duración: 10 horas · 5 sesiones de 2 h, en días alternos sin fines de semana.
• Modalidad: presencial o remoto en directo.
• Grupo: reducido, recomendado ≤ 12 participantes.
• Precio: 999 € por participante (IVA no incluido).
• Incluye: formación en directo, entorno de laboratorio con GPU, repositorio, materiales, plantillas y certificado.

Realizamos también formaciones privadas a empresas y asociaciones, con precios por grupos, y ayudamos a gestionar los fondos de FUNDAE. Solicita información para conocer las próximas convocatorias y disponibilidad.