Infraestructura de IA y grupos de GPU

(Sección: Tecnologías e Infraestructura)

Resumen breve

La producción AI no es «un solo modelo en un solo servidor», sino un clúster de nodos GPU, grupos de aceleradores compartidos, serving unificado, datos/fichas, observabilidad y administración de costos. Para iGaming, esto es crítico en tiempo real: antifraude, personalización, chatbots, asistentes LLM, recomendaciones de juegos/promociones. Ladrillos básicos: Kubernetes/Slurm para planificación, aislamiento de cargas de trabajo, red de alta velocidad (100/200/400G con RDMA), almacenamiento rápido, MLOps maduros, y SLO «de hormigón armado».

1) Mapa arquitectónico

1. Clúster de computación: nodos GPU (clases A/H, AMD/ROCm, Intel Gaudi, etc.), nodos CPU para preprocesamiento/fichas.

2. Red: 100G + Ethernet/IB, RDMA (RoCEv2), topología NCCL, QoS.

3. Almacenamiento: objeto (S3-joint.) distribuido por POSIX (Ceph/grid), NVMe-scratch local.

4. Datos/fichas: ficha (online/offline), DAB vectorial (ANN), caché (Redis), colas.

5. Plataforma ML: registro de artefactos y modelos, pipelines (CI/CD), control de versiones, fichas como código.

6. Capa de servicio: Triton/KServe/vLLM/text-generation-inference (TGI), A/B/Canary deploy, autocresycle.

7. Gobierno y seguridad: PII, secretos, auditoría, políticas de exportación, licencias de pesos/datasets.

• Puntuación en línea (p95 ≤ 50-150 ms) - antifraude, recomendaciones, clasificación.
• Serving LLM (p95 ≤ 200-800 ms en 128-512 tokens) - chat/agentes/pistas.
• Análisis/preparación por lotes - ventanas nocturnas, métricas fuera de línea.
• Faintuning/Adaptation - periódicamente, con prioridad debajo en línea.

2) Grupos de GPU y planificación

Modelo de grupos

Pool «Serving»: consultas cortas, batching alto, SLO rigurosos.
Pool «Entrenamiento/Feintuning»: jobs largos, entrenamiento distribuido (DDP).
Grupo «I + D/Experimentos»: cuotas/límites, preemption permitido.
Grupo «CPU/Pre-/Post-Processing»: normalización, tokenización, rerank en CPU.

Plan

Kubernetes (+ device-plugin, NodeFeatureDiscovery, taints/tolerations, PriorityClass, PodPriority/Preemption).
Slurm (a menudo para entrenamiento HPC) - Se puede mezclar con K8s a través de workers individuales.
Fair Share y cuotas: cuotas de namespace por GPU, CPU, memoria; «bancos» GPU-reloj; Límites de neymspace/proyecto.

Partición de GPU

AMB (Multi-Instance GPU): corte del acelerador en diapositivas aisladas (para serving/multi-tenencia).
MPS: sharing SM para tareas menores (monitorear interferencia).
NVLink/PCIe: tener en cuenta la topología a la hora de pintar podas (Topology Aware Scheduling).

yaml apiVersion: v1 kind: Pod metadata:
annotations:
scheduling. k8s. io/group-name: "ai-serving"
spec:
nodeSelector: { gpu-pool: serving }
tolerations: [{ key: "gpu", operator: "Exists", effect: "NoSchedule" }]
priorityClassName: ai-serving-critical

3) Rendimiento de red y entre nodos

RDMA (RoCEv2) para reducciones NCCL-all; Configuración ECN/PFC, aislamiento de clases de tráfico.
Localización: formación dentro de una «fábrica» (pod/host/óptica), serving - más cercano al usuario (edge/región).
Control de congestión: perfiles tuned, marcos jumbo, interfaces pin-ning.

4) Almacenamiento y datos

Almacenamiento de pesas/artefactos: objeto (versioning, immutability).
Datacets/fiches: Lakehouse (Delta/Iceberg/Hudi) + offline-fichastor; online-fichastor (milisegundos SLA).
BD vectorial (ANN): Faiss/ScaNN/aceleradores, o motores vectoriales vendores; charding, HNSW/IVF, replicación.
Caché NVMe local: calentamiento de escalas/embebidos para inicio en frío.

5) Serving modelos

Freymvorki

Triton Inference Server (multimodel, multitineam, batching dinámico).
KServe (K8s-nativo, autoscaling HPA/KPA, canario).
vLLM/TGI para tokenización LLM y decodificación de alto rendimiento (paged-attention, caché KV offloud).
ONNX Runtime/TensorRT-LLM - para compilar y acelerar.

Optimizaciones

Cuantificación: INT8/FP8/INT4 (percentili/calibración, AWQ/GPTQ) - en línea con cuidado, medir la calidad.
Compilación de grafos: TensorRT, TorchInductor/XLA, fused-kernels.
Batching/microbatching: dinámico y estático; для LLM — continuous batching.
Caché KV: sharing entre consultas, offload en CPU/NVMe en contextos largos.
Decodificación especulativa: modelo de draft + verificador para acelerar la pronunciación de token.
Límites de tokens/contexto, detención temprana, palabras de parada, tiempo-budget para solicitar.

los Políticos deploya

A/B, canario, shadow - comparación de latencia/calidad/métricas de negocio.
Blue Green - sin downtime.
Rollback por SLO/errores.

6) Entrenamiento/feintuning

DDP/FSDP/ZeRO: memoria/degradados distribuidos, contabilidad NVLink/topología.
Comprobaciones: incrementales/completas, frecuencia vs I/O.
Mixed Precision: bf16/fp16 + loss scaling; perfilar la estabilidad.
Dataset-sharding: iterador uniforme, replicación por nodos.
Prioridades: frijoles interrumpibles (preemptible) a favor del serving.
Pipelines autónomos: data → train → eval → registro → promoción PROD según criterios gate.

7) MLOps y plataforma

Registro de modelos: versiones, firmas, dependencias, licencias/derechos de uso de básculas.
Modelos de CI/CD: pruebas de compatibilidad, regresión de rendimiento, gates de calidad, deba seguro.
Fichero: consistencia offline/online (feature parity), TTL y backfill.
Línea de datos/modelo: seguimiento desde el dataset hasta el informe/experimento.
Catálogo de plantillas/prompts para LLM (versioning).

8) Observabilidad y SLO

• Latencia p50/p95/p99, tokens/s, latch occupancy, queue wait, GPU-util/SM occupancy, memoria, errores.
• Características del LLM: tokens de E/S, longitud media de respuesta, porcentaje de fallos por límites, caché de hit KV.
• Calidad: pruebas automáticas de regresión (fuera de línea), telemetría en línea (banderas de contenido, toxicidad, precisión de emisión en muestras de oro).
• SLO de negocios: conversión de personalización, precisión antifraude, retención.

Alertas: crecimiento de p99/cola, caída de tokens/s, degradación de batch-fill, agotamiento de VRAM/PCIe-throttle, crecimiento de fallas de rate-limit.

9) Seguridad, cumplimiento y privacidad

PII/findados: segmentación de cálculos y datos por región, cifrado en reposo/en tránsito, tokenización.
Secretos/claves: KMS/Secrets Manager; eliminar el almacenamiento en imágenes/código.
Directivas de salida LLM: filtros de seguridad, red-teaming, registro de huellas/respuestas (con anonimato).
Licencias: cumplimiento de las licencias de datasets/pesos; «no-redistribute «/restricciones comerciales.
Aislamiento de tenantes: namespace-RBAC, redes, diapositivas AMB, límites y cuotas.

10) Costo y phinops

Planificación de Kapashity: perfiles de carga (RPS, tokens/sec), «colas» de torneos y campañas.
Reserva/Spot: grupos mixtos (reservado + spot/preemptible) con reestablecimiento de tareas y comprobaciones.
Auto scale: HPA/KPA por RPS/queue depth/GPU-util; «comienzo cálido» con escalas calientes.
Zoológico modelo: reducir el número de opciones; utilice la adaptación (LoRA/PEFT) en lugar de la duplicación completa.
Caché: embeddings/resultados de consultas costosas, sharing KV caché para LLM.
Optimización de tokens: compresión de prompts, generación retrieval-augmented (RAG), rerank antes de la generación.

11) Multirregión, HA y DR

Active/Active serving más cercano al usuario, routing global (latency-based).
Replicación de escalas y fichas con comprobación de integridad; calentamiento de cachés durante las liberaciones.
Plan DR: pérdida de AZ/región, evacuación al grupo de reserva, control de dependencia del directorio centralizado.
Chaos-days: pruebas de fallo de dominio/almacenamiento de red/GPU-nod.

12) Plantillas de configuración (conceptos)

text dynamic_batching {
preferred_batch_size: [4, 8, 16, 32]
max_queue_delay_microseconds: 2000
}
instance_group { count: 2 kind: KIND_GPU }

yaml spec:
predictor:
canaryTrafficPercent: 20 model:
modelFormat: { name: triton }
resources:
limits: { nvidia. com/gpu: "1" }

--tensor-parallel-size 2
--max-num-seqs 512
--gpu-memory-utilization 0. 9
--enforce-eager

13) LLM-especificidad: RAG y circuito de búsqueda

Indexación: chanking, embeddings, charding ANN por 'tenant/locale'.
Rerank: modelo ligero en la diapositiva CPU/GPU para mejorar la precisión.
Caché de prompts/contextos: dedoup, canonicalización.
Políticas de cotización/responsabilidad para dominios sensibles (CUS/reglas).

14) Lista de verificación de implementación

1. Fije el SLO (p95 latency/tokens/s, disponibilidad) y los perfiles de carga.
2. Dividir el clúster en grupos (serving/train/R & D), introducir cuotas/prioridades.
3. Incluya RDMA/NCCL y la planificación informada topológicamente.
4. Configure los almacenes: básculas, datasets, fichastor (online/offline), vectores DB.
5. Seleccione la pila de serving (Triton/KServe/vLLM), agregue la memoria caché/KV/cuantificación.
6. Inicie el registro de modelos, CI/CD, canario/shadow deploy.
7. Proporcione la observabilidad: sistema + métricas de negocio, calidad, rastreo.
8. Introduzca las directivas de seguridad/PII, licencias, auditoría.
9. Optimice TCO: reserved + spot, auto scale, caché, PEFT en lugar de clones completos.
10. Prepare el HA/DR y pase el día del juego.

15) Antipattern

«Una gran GPU para todo» sin grupos y prioridades.
La ausencia de batcheo dinámico y caché KV para LLM → una explosión de p99 y costo.
Entrenamiento y serving en una sola piscina sin preemption → incidentes SLO.
Cero telemetría calidad/seguridad → degradación imperceptible y riesgos.
Monolito centralizado sin fichero/registro de modelos → no hay reproducibilidad.
Ignorar licencias de pesos/datos.

Resultados

La infraestructura de AI exitosa son grupos de GPU con planificación inteligente, alta red y almacenamiento correcto, serving eficiente (batching, caché, cuantización, compilación), MLOps maduros y SLO estrictos. En combinación con seguridad/PII, HA/DR multirregional y finops elaborados, la plataforma ofrece una p99 estable, una consulta controlada por $/y una rápida introducción de nuevos modelos, desde antifraude hasta personalización y asistentes LLM.