Logo GH

Implementación de modelos ML

(Sección: Tecnologías e Infraestructura)

Resumen breve

El despliegue confiable de ML es un conjunto de: artefactos repetibles (modelo/tokenizer/config), serving estandarizado (Triton/KServe/vLLM), proceso de liberación seguro (canary/blue green/shadow), observabilidad (latencia, calidad, deriva) y runbook-a-incidentes. Para iGaming, la baja latencia (antifraude/personalización), los estrictos SLO, PII/cumplimiento y el control de costos son críticos.

1) Modos de despliegue

Batch (offline): tareas nocturnas/horarias (retrospectiva, actualización de segmentos). Barato, predecible.
Online (API sincronizada): antifraude, personalización, recomendaciones, pistas LLM. Requiere p95 SLA (por ejemplo, ≤ 100-300 ms).
Stream (near-real-time): ventanas de 1-60 segundos (Flink/Spark/Kafka Streams) para señales y disparadores CRM.
Híbrido: Scorer rápido y áspero en línea + revalorización/calibración fuera de línea.

2) Artefactos y embalaje

Artefactos de modelo: pesos, tokenisor, confecciones de preprocesamiento/postprocesamiento, versión dataset/código.
Formatos: PyTorch/TF SavedModel, ONNX para la compatibilidad, TensorRT-engine para la aceleración, GGUF/awq/gptq para la cuantización LLM.
Contenedores: Imágenes OCI Docker con dependencias pinned; etiquetas de plataforma múltiple (CPU/GPU).
Versiones immutables: teging 'model: fraud-v3. 2. 1`, `image: fraud:3. 2. 1`.

3) Plataforma de serving

Triton Inference Server: multimodal, batch dinámico, ensemble-pipelines.
KServe (K8s-nativo): auto-skale (HPA/KPA), canario/shadow, runtime propio.
vLLM/TGI (LLM): batching continuo, caché KV, decodificación especulativa.
Fichastor: online (ms-SLA) + offline para la coherencia fich (feature parity).

Ejemplo de KServe-canario (idea):
yaml apiVersion: serving. kserve. io/v1beta1 kind: InferenceService metadata: { name: fraud }
spec:
predictor:
canaryTrafficPercent: 15 model:
modelFormat: { name: triton }
storageUri: s3://models/fraud/v3. 2. 1/
resources: { limits: { nvidia. com/gpu: "1" } }

4) Estrategias de lanzamiento

Blue-Green: dos pilas idénticas, cambio de tráfico instantáneo, retroceso simple.
Canary: aumento gradual del tráfico (1% → 5% → 25% → 100%) en las gatitas SLO/calidad.
Shadow: el nuevo modelo recibe una copia del tráfico, las respuestas no afectan a nada - evaluación segura.
Pruebas A/B: medimos métricas de negocio (conversión, retención), significación estadística.

Ejemplo de reglas de routing (pseudo-NGINX):

map $request_id $route {
default old;
"~ canary" new; # 5-15% by flag/cook/feature-toggle
}

5) SLO y presupuestos de trabajo

Antifraude/personalización en línea: p95 ≤ 100-150 ms, p99 ≤ 250-400 ms.
Pistas LLM (128-512 tokens): p95 ≤ 300-800 ms de generación de los primeros tokens, tokens/s ≥ objetivo.
Disponibilidad: ≥ 99. 9% para rutas críticas.
Calidad: AUC/PR-AUC/Top-K @ N ≥ del umbral;% de respuestas tóxicas/incorrectas ≤ X.
Costo: $/1k solicitudes o $/1k tokens - dentro del presupuesto.

6) CI/CD para modelos

Transportador:

1. Train/finetune → el modelo en el registro (metadatos: datos/código/métricas/licencias).

2. Pack & Validate: pruebas unitarias de preprotz ./postproc., compatibilidad con API, pruebas de carga (latency/tokens/s).

3. Canary Deploy: 1-5% de tráfico; observabilidad (SLO/calidad/costo).

4. Promote/Rollback según los criterios de las gaitas.

Ejemplo de un fragmento de GitHub Actions (idea):
yaml jobs:
build-serve:
steps:
- run: make export_onnx && make docker_build
- run: pytest tests/serve --maxfail=1
- run: python perf_check. py --p95 120 --fail-on-regress
- run: kubectl apply -f kserve-canary. yaml

7) Optimización de latencia y ancho de banda

Batching/microbatching (Triton/vLLM), paralelismo de consultas, pre-/post-processing en CPU.
Cuantización (INT8/FP8/INT4) con calibración; Compilación TensorRT/ONNX Runtime.
Almacenamiento en caché: fich (online-fichastor/Redis), resultados y caché KV para LLM.
Warmup: calentamiento de la báscula/caché en la deba; podas «cálidas» para auto-scale.
Tiempo-presupuesto: parada temprana, restricción de tokens/beam, adaptación de temperatura.

8) Observabilidad: telemetría, deriva, calidad

Métricas SRE: RPS, p50/p95/p99, errores (5xx/4xx), GPU/CPU util, memoria, cola, batch-fill.
Métricas ML: AUC/PR-AUC, calibración error, coverage, tokens/s, longitud de respuesta, caché-hit.
Deriva: divergencia PSI/JS por entradas/fichas, monitoreo del cambio de distribución; alertas.
Calidad en línea: ejemplos de oro de control, sampling de respuestas, RAG-score automático/toxicidad para LLM.
Registro: prompt/respuesta (con anonimización), trace_id, versión del modelo.

Ejemplo Prometheus (idea):

inference_latency_ms_bucket{model="fraud-v3. 2. 1",le="100"} 12345 inference_qps{model="fraud-v3. 2. 1"} 450 tokens_per_second{model="llm-help-v1"} 210

9) Gestión y coherencia de las fichas

Feature-parity: las mismas transformaciones en offline/online; versionar los fichas como código.
Fichastor en línea: ms-SLA, TTL, upsert, idempotency; caché más cerca del serving.
Backfill/refresh: un plan para que la puntuación en línea no esté reñida con las métricas offline.

10) Seguridad, PII y licencias

PII: tokenización/enmascaramiento, segmentación por región (EU/TR/LATAM), cifrado en reposo/en tránsito.
Secretos/claves: KMS/Secrets Manager, sin secretos en las imágenes.
Políticas LLM: filtros de contenido, parador seguro, equipo rojo.
Licencias: compruebe las condiciones de datasets/pesos, prohibiciones de redistribución/comercio.
Aislamiento: namespace-RBAC, cuotas, taints/tolerations para grupos de GPU.

11) Auto Scale y QoS

Autoscaling: por RPS/cola/latency/GPU-util; min-ready-pods para líneas directas.
Clases de QoS: crítica en línea (anti-fraud)> Chat de LLM> experimentos. Preemption en favor de los críticos.
Multirregión: enrutamiento latency-based, cachés de peso calentado, replicación fich.

12) Runbooks e incidentes

Crecimiento p99: comprobar batch-fill, cola, GPU-util, caché-miss; activar batching agresivo/bajar beam/tokens.
La calidad ha caído: retroceder a la versión anterior, habilitar shadow, fijar fuentes de deriva.
El coste crece: habilita la cuantización/TensorRT, mejora el batch, optimiza los fiches/caché, reduce la frecuencia de generación LLM a través de RAG/caché de resultados.
Incidente PII: stop-the-line inmediato, retirada de artefactos, auditoría de acceso, informe al regulador del procedimiento.

13) Ejemplos de plantillas

Triton - batching dinámico (fragmento):
text dynamic_batching { preferred_batch_size: [4, 8, 16, 32]
max_queue_delay_microseconds: 2000 }
instance_group { kind: KIND_GPU count: 2 }
vLLM lanzamiento (ideas):

--tensor-parallel-size 2
--max-num-seqs 512
--gpu-memory-utilization 0. 9
Comprobación de compatibilidad de API (pseudocódigo):
python resp = client. score({"features": f}) # v3. 2. 1 assert set(resp. keys()) >= {"score","version","latency_ms"}

14) Lista de verificación de implementación

1. Defina SLO/SLA (latency/availability/quality/cost).
2. Estandarice los artefactos y el registro de modelos (versiones, metadatos).
3. Seleccione la pila de serving (Triton/KServe/vLLM) y el fichastor.
4. Configurar canario/azul verde/sombreado y gates automáticos.
5. Construya CI/CD: pruebas de compatibilidad, regresión de perfume, promoción segura.
6. Habilite la observabilidad (SRE + métricas ML), el monitoreo a la deriva y las alertas.
7. Proporcionar PII/seguridad/licencias y auditoría.
8. Configure la etiqueta automática/QoS y las políticas multirregionales.
9. Prepara el runbook-i y pasa el game-day.
10. Introduzca la gestión de costos: batcheo, cuantización, caché, RAG.

15) Antipattern

Deploy «tal cual» sin canario/observabilidad → incidentes inesperados.
Los fichas offline/online inconsistentes → la divergencia de métricas.
La ausencia de pruebas de perfume y límites de → p99 «flota».
La lógica de las respuestas/prompts sin anonimato → el riesgo PII.
Un grupo de GPU común para todo sin QoS → crítico en línea sufre.
No hay retroceso y los snapshots de artefactos → largos tiempos de inactividad.

Resultados

El despliegue exitoso de los modelos ML son artefactos contenedorizados, serving estandarizado, proceso de liberación seguro (canary/blue-green/shadow), SLO rígidos y observabilidad de calidad/deriva/costo. Agregue fichastor, CI/CD con puertas perfumadas, higiene PII, scale automático y QoS, y sus servicios antifraude/personalización/LLM mantendrán las cargas máximas de iGaming de forma constante, manteniéndose predecibles en p99 y presupuesto.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.