Arquitectura de sistemas de IA
Ejecutaste una demostración de un modelo grande en tu portátil y funciona bien, pero cuando quieres convertirlo en un producto real, surgen los problemas:
¿Qué haces si el modelo tiene demasiados parámetros y no cabe en una sola GPU?
-
¿Cómo se reanuda el entrenamiento después de un fallo si el entrenamiento tarda semanas?
-
¿Cómo garantizas una latencia inferior a 1 segundo cuando hay millones de solicitudes de usuarios al día?
-
¿Cómo recopilar comentarios de los usuarios para que el modelo evolucione continuamente?
Estos problemas son los que la arquitectura de sistemas de IA debe resolver.
Una demostración se centra en si funciona; un sistema de producción se centra en si puede funcionar de manera estable, eficiente y a bajo costo.
Características de un sistema de IA de nivel de producción: disponibilidad 7x24, soporte para concurrencia de millones, observable, escalable, con recuperación ante desastres confiable y costo controlable.
Desafíos específicos de los sistemas de IA
En comparación con los servicios web tradicionales, los sistemas de IA tienen tres desafíos únicos.
Desafío 1: Salida incierta
La salida de los sistemas tradicionales es determinista: si introduces 1+1, siempre devuelve 2.
La salida de los sistemas de IA es probabilística: con el mismo mensaje, dos generaciones pueden dar resultados diferentes.
Esto plantea varios problemas: ¿cómo garantizar la calidad de la salida? ¿Cómo evaluar el efecto? ¿Cómo manejar las alucinaciones?
Las soluciones suelen ser: añadir estrategias de muestreo en la capa de salida, filtrado posterior de resultados, circuito cerrado de retroalimentación humana y votación de múltiples modelos.
Desafío 2: Compensación entre latencia y costo
La inferencia de IA requiere una gran cantidad de cómputo, lo que significa una contradicción natural entre latencia y costo.
¿Quieres rapidez? Usa más GPU y el costo se dispara.
¿Quieres ahorrar? Procesa en cola, y la experiencia del usuario se deteriora.
El núcleo de un sistema de producción es encontrar un equilibrio entre el SLA (acuerdo de nivel de servicio) y el costo.
| Dirección de optimización | Técnicas comunes | Efecto |
|---|---|---|
| Compresión de modelos | Cuantización, poda y destilación | Velocidad 2-4 veces mayor, con una ligera disminución de precisión |
| Optimización de inferencia | vLLM、TensorRT、FlashAttention | Rendimiento 3-10 veces mayor |
| Diseño de arquitectura | Procesamiento por lotes, caché multinivel | Costo por solicitud reducido en 50%-80% |
Desafío 3: Construcción del volante de datos
Un sistema de IA no termina cuando se pone en producción; necesita iteración continua.
Cuanto más usan los usuarios, más datos de retroalimentación hay, mejor se puede entrenar el modelo, y los usuarios están más dispuestos a usarlo: esto es el volante de datos.
Pero hacer girar el volante no es fácil: ¿cómo recopilar retroalimentación efectiva? ¿Cómo etiquetar datos? ¿Cómo entrenar continuamente? ¿Cómo evaluar nuevas versiones?
No hay respuestas estándar para estas preguntas, pero cada producto de IA exitoso tiene su propio diseño de volante.
Infraestructura de entrenamiento a gran escala
Entrenar modelos grandes con cientos de miles de millones o incluso billones de parámetros requiere infraestructura de supercomputación.
Arquitectura de clústeres de GPU
Los clústeres de entrenamiento de IA modernos suelen estar compuestos por cientos o miles de GPUs.
Tomemos la GPU H100 como ejemplo: una H100 tiene 80GB de memoria y una capacidad de cómputo de 1979 TFLOPS en precisión FP8.
Pero una sola GPU es insuficiente: el entrenamiento de GPT-3 utilizó unas 355 V100 durante 3 meses.
La topología típica del clúster es:
| Nivel | Dispositivo | Método de conexión | Ancho de banda |
|---|---|---|---|
| Dentro de un solo servidor | GPU-GPU | NVLink | 900GB/s |
| Mismo rack | Servidor a servidor | InfiniBand | 400Gb/s |
| Entre racks | Switch a switch | InfiniBand Fabric | 400Gb/s |
La red es el cuello de botella del entrenamiento distribuido. Si el ancho de banda de comunicación es insuficiente, la utilización de la GPU puede caer del 90% al 30%, pasando la mayor parte del tiempo esperando datos.
Interconexión de alta velocidad InfiniBand
El Ethernet normal es demasiado lento; el entrenamiento distribuido utiliza InfiniBand.
InfiniBand se caracteriza por: latencia extremadamente baja (nivel de microsegundos), ancho de banda muy alto y soporte para RDMA (acceso directo a memoria remota).
RDMA permite que una GPU lea y escriba directamente la memoria de una GPU en otro servidor sin pasar por el kernel del sistema operativo, mucho más rápido.
Diseño del sistema de almacenamiento
Los datos de entrenamiento suelen ser del orden de TB o incluso PB, por lo que el sistema de almacenamiento también es muy importante.
Diseño típico de almacenamiento en capas:
- Datos calientes: SSD o NVMe, para almacenar los lotes que se están entrenando actualmente
- Datos tibios: almacenamiento distribuido (como Ceph, Lustre), para almacenar el conjunto de entrenamiento completo
- Datos fríos: almacenamiento de objetos (como S3), para almacenar datos históricos y copias de seguridad
Tolerancia a fallos y puntos de control
Entrenar tarda semanas; ¿qué pasa si una GPU falla durante el proceso? Empezar desde cero es un desperdicio.
La solución esPuntos de control (Checkpointing): guardar periódicamente el estado del modelo en disco y, si ocurre un error, recuperar desde el punto de control más reciente.
Pero los puntos de control también tienen un costo: guardar una vez puede tomar varios minutos y ocupar decenas de GB de espacio.
La estrategia habitual es: guardar cada varios cientos de pasos, conservar los pocos puntos de control más recientes y limpiar automáticamente los antiguos.
Estrategias de entrenamiento distribuido
Una sola GPU no puede contener un modelo grande; es necesario dividir la tarea de entrenamiento entre múltiples GPUs.
Hay principalmente tres estrategias de paralelismo: paralelismo de datos, paralelismo de tensores y paralelismo de canalización; la combinación de las tres es el paralelismo 3D.
Paralelismo de datos (Data Parallelism)
La estrategia más simple y más común: cada GPU tiene el modelo completo, pero procesa datos diferentes.
Por ejemplo, con 8 GPUs y un tamaño de lote de 1024, cada GPU procesa 128 muestras.
La propagación hacia adelante se calcula por separado; después de la propagación hacia atrás, los gradientes se agregan y se promedian, y luego se actualiza el modelo.
El problema del paralelismo de datos es que la memoria sigue siendo el cuello de botella: si el modelo es demasiado grande para caber en una sola GPU, el paralelismo de datos no sirve.
Optimización de memoria ZeRO
ZeRO (Zero Redundancy Optimizer) es una versión mejorada del paralelismo de datos que ahorra aún más memoria.
En el paralelismo de datos normal, cada GPU almacena los parámetros completos del modelo, los gradientes y el estado del optimizador: esto es redundante.
La idea de ZeRO es dividir estos estados entre diferentes GPUs y comunicarlos solo cuando sea necesario.
| Etapa de ZeRO | Contenido dividido | Ahorro de memoria |
|---|---|---|
| ZeRO-1 | Estado del optimizador | Aproximadamente 4 veces |
| ZeRO-2 | Estado del optimizador + gradientes | Aproximadamente 8 veces |
| ZeRO-3 | Estado del optimizador + gradientes + parámetros | Lineal en el número de GPUs |
Configurar ZeRO con DeepSpeed es muy sencillo:
"train_batch_size": 1024,
"train_micro_batch_size_per_gpu": 16,
"optimizer": {
"type": "Adam",
"params": {
"lr": 0.0001,
"betas": [0.9, 0.95],
"eps": 1e-8,
"weight_decay": 0.01
}
},
"zero_optimization": {
"stage": 3,
"allgather_partitions": true,
"allgather_bucket_size": 2e8,
"overlap_comm": true,
"reduce_scatter": true,
"reduce_bucket_size": 2e8,
"contiguous_gradients": true,
"stage3_prefetch_bucket_size": 1e8,
"stage3_param_persistence_threshold": 1e5,
"stage3_max_live_parameters": 1e9,
"stage3_max_reuse_distance": 1e9
},
"gradient_clipping": 1.0,
"fp16": {
"enabled": true,
"loss_scale": 0,
"loss_scale_window": 1000,
"initial_scale_power": 16,
"hysteresis": 2,
"min_loss_scale": 1
},
"checkpoint": {
"tag": "ejemplo-checkpoint",
"load_universal": true
}
}
Esta configuración usa ZeRO-3, que puede distribuir el estado del modelo entre todas las GPUs, reduciendo linealmente el uso de memoria con el número de GPUs.
Paralelismo de tensores (Tensor Parallelism)
Python es un lenguaje conciso y elegante, adecuado para principiantes.
El aprendizaje automático permite que las computadoras aprendan patrones a partir de los datos.
- Este es un artículo completamente diferente.
- Finalmente, concatena los resultados.
Así, cada cálculo de capa requiere comunicación, pero el uso de memoria también se reduce a la mitad.
Megatron-LM es la biblioteca de paralelismo tensorial de NVIDIA y tiene muy buena compatibilidad con PyTorch.
Paralelismo de canalización (Pipeline Parallelism)
El paralelismo tensorial es "división dentro de la capa"; el paralelismo de pipeline es "división entre capas".
Por ejemplo, en un modelo de 32 capas, GPU 0 contiene las primeras 8 capas, GPU 1 las siguientes 8, GPU 2 las siguientes 8 y GPU 3 las últimas 8.
Los datos fluyen de GPU 0 a GPU 3, como una línea de producción en una fábrica.
Pero el pipeline tiene un problema: la burbuja (Bubble) — cuando GPU 0 empieza a calcular, GPU 1-3 no tienen nada que hacer; cuando los datos llegan a GPU 1, GPU 0 se queda sin trabajo.
La solución es dividir los datos en "micro-lotes" (Micro-batch), llenándolos como una línea de producción para reducir el tiempo de burbuja.
Paralelismo 3D (DP+TP+PP)
Las tres estrategias se pueden combinar:
- Paralelismo de pipeline: divide las capas del modelo entre nodos
- Paralelismo tensorial: divide el cálculo dentro de las capas en un nodo
- Paralelismo de datos: replica todo el pipeline a mayor escala
Por ejemplo, con 64 GPUs se puede planificar así:
- 8 etapas de pipeline (PP=8)
- Dentro de cada etapa se usan 2 GPUs para paralelismo tensorial (TP=2)
- Luego se replican 4 copias para paralelismo de datos (DP=4)
- Total: 8 × 2 × 4 = 64 GPUs
Esto es el paralelismo 3D: la configuración estándar para entrenar modelos grandes modernos.
Ingeniería de datos
La premisa de un buen modelo son los buenos datos: la ingeniería de datos representa más del 60% del trabajo en los sistemas de IA.
Canalización de recopilación y limpieza de datos
Los datos de entrenamiento suelen provenir de múltiples fuentes: páginas web, libros, código, conversaciones, etc.
Proceso típico:
- Deduplicación: eliminar documentos duplicados o altamente similares
- Filtrado de calidad: eliminar contenido de baja calidad, tóxico o sesgado
- Unificación de formato: convertir diferentes fuentes a un formato uniforme
- Tokenización: convertir texto en secuencias de entrada para el modelo
Deduplicación de datos: MinHash LSH
Calcular directamente la similitud entre pares de documentos es demasiado lento; el método común es MinHash + LSH (hashing sensible a la localidad).
La idea es: convertir cada documento en una "huella" corta; documentos similares probablemente tengan huellas iguales o parecidas, y luego agrupar por huella.
Ejemplo
import re
from typing import List, Set, Dict, Tuple
def generate_shingles(text: str, k: int = 5) -> Set[str]:
"""Generar k-shingles: secuencias de k palabras consecutivas
Por ejemplo "我爱你 ejemplo 教程", k=2 → {"我爱", "爱 ejemplo", "ejemplo 教程"}
"""
# Segmentación simple (en escenarios reales se puede usar una herramienta de segmentación profesional)
words = re.findall(r'\w+', text.lower())
shingles = set()
for i in range(len(words) - k + 1):
shingle = ' '.join(words[i:i+k])
shingles.add(shingle)
return shingles
def minhash_signature(shingles: Set[str], num_hashes: int = 100) -> List[int]:
"""Generar firma MinHash
Usar múltiples funciones hash, cada una tomando el valor mínimo
"""
signature = []
for i in range(num_hashes):
# Usar i como semilla para generar diferentes funciones hash
min_hash = None
for shingle in shingles:
# Combinar shingle e i para generar el valor hash
h = hashlib.sha256(f"{shingle}-{i}".encode()).hexdigest()
h_int = int(h, 16)
if min_hash is None or h_int < min_hash:
min_hash = h_int
signature.append(min_hash)
return signature
def lsh_banding(signature: List[int], bands: int = 20) -> List[str]:
"""Generar claves LSH con el método de bandas (Banding)
Dividir la firma en múltiples bandas, y hashear cada banda por separado
"""
keys = []
rows_per_band = len(signature) // bands
for i in range(bands):
start = i * rows_per_band
end = start + rows_per_band
band = tuple(signature[start:end])
# Hashear esta banda para generar una clave
band_hash = hashlib.sha256(str(band).encode()).hexdigest()[:16]
keys.append(f"band-{i}-{band_hash}")
return keys
def deduplicate_documents(documents: List[str],
threshold: float = 0.7) -> List[str]:
"""Usar MinHash + LSH para deduplicar documentos
Devolver la lista de documentos deduplicados
"""
# Almacenamiento: clave LSH → lista de índices de documentos
buckets: Dict[str, List[int]] = {}
# Almacenamiento: índice de documento → firma
signatures: Dict[int, List[int]] = {}
# Marcar: qué documentos son duplicados
duplicates: Set[int] = set()
for idx, doc in enumerate(documents):
shingles = generate_shingles(doc)
sig = minhash_signature(shingles)
signatures[idx] = sig
keys = lsh_banding(sig)
# Verificar si ya existe un documento similar
is_duplicate = False
for key in keys:
if key in buckets:
# Ya hay documentos en este bucket, comparar similitud de firmas uno por uno
for other_idx in buckets[key]:
other_sig = signatures[other_idx]
# Calcular similitud de firmas (aproximación de Jaccard)
matches = sum(1 for a, b in zip(sig, other_sig) if a == b)
similarity = matches / len(sig)
if similarity >= threshold:
# Si supera el umbral, se considera duplicado
is_duplicate = True
duplicates.add(idx)
break
if is_duplicate:
break
if not is_duplicate:
# No es duplicado, agregarse a cada bucket
for key in keys:
if key not in buckets:
buckets[key] = []
buckets[key].append(idx)
# Devolver documentos no duplicados
return [doc for idx, doc in enumerate(documents) if idx not in duplicates]
# ============================================
# Probar deduplicación de datos ejemplo
# ============================================
if __name__ == "__main__":
documents = [
"Bienvenido al tutorial de ejemplo, este es un buen lugar para aprender programación.",
"Bienvenido al tutorial de ejemplo, este es un buen lugar para aprender programación.", # Altamente similares
"Python es un lenguaje conciso y elegante, adecuado para principiantes.",
"Python es un lenguaje de programación conciso y elegante, muy adecuado para principiantes.", # Altamente similares
"El aprendizaje automático permite que las computadoras aprendan patrones a partir de los datos.",
"Este es un artículo completamente diferente.",
]
print(f"Antes de la deduplicación: {len(documents)} documentos")
deduplicated = deduplicate_documents(documents, threshold=0.6)
print(f"Después de la deduplicación: {len(deduplicated)} documentos"\n")
print("Documentos conservados:")
for i, doc in enumerate(deduplicated):
print(f" [{i}] {doc}")
# Salida:
# Antes de la deduplicación: 6 documentos
# Después de la deduplicación: 4 documentos
#
# Documentos conservados:
#
#
#
#
En la producción real, también se usan implementaciones más eficientes (como la biblioteca datasketch), pero la idea central es la misma.
Formato de datos: WebDataset
Los conjuntos de datos pequeños se pueden almacenar de cualquier manera, pero los conjuntos de datos de nivel TB requieren un formato especializado.
WebDataset es uno de los más comunes: empaqueta archivos en paquetes tar, cada tar contiene miles de muestras, y admite lectura aleatoria y lectura secuencial.
Las ventajas son:
- Reduce la presión sobre el sistema de archivos (millones de archivos pequeños son muy lentos)
- Admite lectura en streaming, sin necesidad de cargar todo el conjunto de datos en memoria
- Se puede cargar de forma distribuida, cada worker lee un tar diferente
Diseño del volante de datos
El volante de datos es el foso de los productos de IA: cuantos más usuarios, más datos; más datos, mejor modelo; mejor modelo, más usuarios.
Recopilación de datos de comentarios de los usuarios
La retroalimentación tiene dos tipos: explícita e implícita:
- Retroalimentación explícita: me gusta, no me gusta, edición, regeneración
- Retroalimentación implícita: tiempo de permanencia, copiar, compartir, duración de la sesión
La retroalimentación explícita es de alta calidad pero escasa; la implícita es abundante pero ruidosa.
Un buen sistema de retroalimentación combina ambas: usar la retroalimentación explícita para entrenar el modelo de recompensa y la implícita para pruebas A/B.
Anotación automática de datos
La anotación manual es demasiado costosa y lenta; la tendencia actual es "usar modelos para anotar modelos".
Estrategias comunes:
- El modelo fuerte anota al modelo débil: usar datos anotados por GPT-4 para entrenar modelos pequeños
- Bootstrapping (auto-reforzamiento): usar el modelo existente para generar candidatos y filtrarlos manualmente
- Datos sintéticos: usar modelos para generar datos de entrenamiento diversos
Estrategias de entrenamiento continuo
El modelo no es "entrenar una vez y listo": el mundo cambia, y el modelo también debe cambiar.
Flujo típico de entrenamiento continuo:
- Recopilar nuevos datos de interacción de usuarios diariamente
- Hacer una actualización menor cada semana (SFT, ajuste fino supervisado)
- Hacer una actualización mayor cada mes (preentrenamiento continuo + SFT + RLHF)
- En cada actualización se realizan pruebas A/B; solo después de confirmar el efecto se implementa a gran escala.
En el entrenamiento continuo hay que prestar atención al "olvido catastrófico": si se entrena demasiado con datos nuevos, el modelo puede olvidar capacidades anteriores. La solución es mantener un "buffer de repetición" y mezclar datos nuevos y antiguos en cada entrenamiento.
Arquitectura de plataforma de IA empresarial
Una plataforma de IA empresarial completa generalmente incluye los siguientes componentes.
Registro de modelos y gestión de versiones
Cuantos más modelos, más complicada es la gestión: se necesita un registro de modelos centralizado.
El registro debe registrar:
- Archivos del modelo (pesos, configuración, tokenizer)
- Número de versión y registro de cambios
- Fuente de los datos de entrenamiento e hiperparámetros
- Métricas de evaluación
- Estado del despliegue
MLflow, Weights & Biases y Hugging Face Hub son herramientas comunes.
Feature Store
Muchas aplicaciones de IA necesitan ingeniería de características: perfiles de usuario, comportamiento histórico, información contextual, etc.
Feature Store es un sistema de gestión de características que resuelve varios problemas:
- Skew de entrenamiento/inferencia: las características utilizadas en entrenamiento e inferencia son inconsistentes
- Reutilización de características: diferentes modelos pueden compartir características
- Consistencia en línea/fuera de línea: características calculadas fuera de línea, leídas en línea con baja latencia
La arquitectura típica es: cómputo por lotes con Spark o Flink fuera de línea, y lectura de baja latencia con Redis o Cassandra en línea.
Servicios de inferencia en línea/fuera de línea
La inferencia se divide en dos escenarios, con arquitecturas diferentes:
| Escenario | Requisito de latencia | Arquitectura | Ejemplo |
|---|---|---|---|
| Inferencia en línea | Nivel de milisegundos | API en tiempo real + procesamiento por lotes | Chatbots, búsqueda |
| Inferencia fuera de línea | Nivel de horas/días | Cola de tareas por lotes | Moderación de contenido, generación de informes |
Los servicios de inferencia en línea deben considerar:
- Procesamiento por lotes (Batching): agrupar múltiples solicitudes para calcularlas juntas y aumentar el rendimiento
- Batching dinámico: usar vLLM o Text Generation Inference para batching dinámico
- Caché: K/V Cache acelera la generación autoregresiva; los prompts populares devuelven el resultado directamente desde la caché
- Balanceo de carga: múltiples instancias del modelo, enrutamiento inteligente
Monitoreo de extremo a extremo
Los problemas en los sistemas de IA son difíciles de rastrear: se necesita observabilidad.
Varias dimensiones del monitoreo:
- Métricas del sistema: utilización de GPU, VRAM, latencia, rendimiento, tasa de error
- Métricas del modelo: longitud de salida, tasa de repetición, distribución de stop words
- Métricas de negocio: satisfacción del usuario, tasa de retención, tasa de finalización de tareas
Combinación clásica: Prometheus + Grafana para métricas, ELK para registros, Jaeger para el trazado de enlaces.
Sistema de referencia de evaluación
¿Cómo saber si el modelo ha mejorado o empeorado? Se necesita un sistema de evaluación.
Referencia de capacidades generales
Benchmarks comúnmente usados en el ámbito académico:
| Benchmark | Contenido de la prueba | Tareas típicas |
|---|---|---|
| MMLU | Comprensión de lenguaje multitarea | Preguntas de opción múltiple de 57 materias |
| HumanEval | Generación de código | 164 problemas de programación |
| MBPP | Generación de código | 974 problemas de Python |
| TruthfulQA | Factualidad | 817 preguntas, para probar alucinaciones |
| GSM8K | Razonamiento matemático | 8000 problemas de matemáticas de primaria |
Referencia en chino
Que un benchmark sea bueno en inglés no significa que lo sea en chino; se necesitan benchmarks específicos para chino:
- C-Eval: comprensión de lenguaje multitarea en chino, 13948 preguntas de opción múltiple
- CMMLU: comprensión multimodal en chino (actualmente principalmente texto)
- AGIEval: preguntas del examen de ingreso a la universidad de China (Gaokao) y exámenes para funcionarios públicos
Conjunto de evaluación de negocio personalizado
Los benchmarks públicos son la base, pero lo más importante es tu propio conjunto de evaluación de negocio.
Cómo construirlo:
- Recopilar solicitudes reales de usuarios (de cientos a miles)
- Etiquetar manualmente "bueno/medio/malo" o puntuar
- Dividir en conjunto de prueba y conjunto de validación (el conjunto de prueba es fijo, no se debe modificar)
- Ejecutarlo en cada actualización del modelo y observar los cambios en las métricas
El conjunto de evaluación de negocio es tu "estándar de oro": es más importante que cualquier benchmark público.
Servicios de IA multiinquilino
Si lo que se desarrolla es un producto ToB, el multiinquilinato es un tema inevitable.
Aislamiento de inquilinos
El aislamiento tiene varios niveles:
| Nivel de aislamiento | Recursos | Ventajas | Desventajas |
|---|---|---|---|
| Aislamiento físico | Máquinas GPU independientes | Aislamiento total, seguro | Costo alto |
| Aislamiento con K8s | Pod/Namespace independientes | Equilibra costo y seguridad | Requiere orquestación |
| Aislamiento lógico | Recursos compartidos, control de permisos | Costo mínimo | Riesgo de fuga |
La estrategia habitual es: aislamiento físico para clientes grandes, aislamiento lógico para clientes medianos y pequeños.
Compartición de modelos y gestión de ajuste fino
Una necesidad común en entornos multiinquilino: entrenar un modelo propietario con mis datos.
La arquitectura debe soportar:
- Almacenamiento compartido del modelo base
- Los adaptadores LoRA de cada inquilino se guardan por separado
- Cargar dinámicamente el LoRA del inquilino correspondiente durante la inferencia
Esto permite ahorrar mucha VRAM: no es necesario cargar el modelo completo para cada inquilino.
Facturación y cuotas
El costo de los servicios de IA es muy alto; la facturación debe ser detallada:
- Facturación por token (entrada y salida se calculan por separado)
- Facturación por cantidad de solicitudes
- Facturación por tiempo de GPU (escenarios de fine-tuning)
- Límites de cuota (cuántas solicitudes por minuto, cuántos tokens por día)
Recuperación ante desastres y alta disponibilidad
Los sistemas de nivel empresarial no pueden caerse: se necesita un diseño de alta disponibilidad.
Despliegue en múltiples zonas de disponibilidad
El requisito más básico: implementación entre zonas de disponibilidad (AZ).
Por ejemplo:
- Clúster principal en AZ A
- Clúster en espera activa (hot standby) en AZ B
- Replicación asíncrona de datos
- El balanceador de carga conmuta el tráfico automáticamente
El objetivo es: si una AZ se cae, el servicio no se interrumpe y no se pierden datos.
Instantáneas de modelos y reversión
Las nuevas versiones del modelo pueden tener problemas: se necesita poder hacer rollback rápidamente.
Estrategia:
- Guardar una instantánea del modelo antes de cada lanzamiento
- Conservar las últimas N versiones
- Monitorear métricas anómalas y activar rollback automático
- Lanzamiento canario: primero desviar el 1% del tráfico; si no hay problemas, lanzamiento completo
Degradación y limitación de tasa
¿Qué hacer si el tráfico aumenta repentinamente? No se puede caer directamente; hay que tener un plan:
- Limitación de tráfico: devolver 429 si se supera la cuota
- Degradación: usar un modelo más pequeño o devolver resultados cacheados
- Cola: devolver un job ID y consultar el resultado más tarde
Principio fundamental:Degradación elegante, no indisponibilidad total.
Otras extensiones