El catálogo paralelo: las seis etapas LLMOps en open source y en los hyperscalers (AWS, GCP, Azure)

TL;DR

El post forense anterior usó una única request para recorrer las seis etapas del pipeline LLMOps y los dos componentes transversales. Este post recorre las mismas etapas pero las cruza con tres columnas extra: cómo se monta cada etapa en open source on-premise, y cuáles son los servicios equivalentes en AWS, GCP y Azure. No es una guía de migración ni un benchmark de coste: es un catálogo de equivalencias con sus gaps. El patrón general que verás: el OSS te da control, soberanía y composición libre a cambio de operativa cara; los hyperscalers te dan integración y time-to-market a cambio de lock-in en márgenes, contratos de datos y dependencia política. Para escenarios sometidos a ENS / NIS2 con datos críticos del cliente, el OSS gana por defecto; para proyectos de descubrimiento donde el time-to-market es la métrica que decide, el hyperscaler gana por defecto. La parte interesante está en el medio. Como hilo concreto, al final tomamos el chatbot multi-tenant del post anterior y lo portamos a AWS pieza a pieza para mostrar qué desaparece, qué aparece, y dónde se materializa el lock-in.

Estás aquí: las mismas seis etapas, pero por columna

Este post comparte mapa con el post anterior — las seis etapas y los dos transversales están todas activas — pero cambia el corte: en lugar de seguir una request horizontalmente, hace el corte vertical y muestra qué herramientas viven en cada etapa según el modelo de despliegue.

La analogía: la panadería propia y la franquicia

Un panadero abre negocio. Tiene dos modelos posibles.

Puede abrir panadería propia: alquila el local, compra el horno, elige los proveedores de harina, contrata a su maestro panadero, escribe sus recetas, decide los precios, decora el escaparate. El día que quiere lanzar un pan ecológico de masa madre de centeno, no pide permiso a nadie. El día que el precio de la harina sube, busca otro proveedor. Pero todo lo paga él: la inversión inicial, el riesgo, la operativa diaria, los meses en los que no acierta con el barrio. La panadería es suya.

O puede entrar en franquicia: el franquiciador le entrega el local llave en mano, el horno con contrato de mantenimiento, los proveedores ya negociados, los manuales operativos, las recetas escritas, el marketing centralizado, la app de fidelización, el sistema TPV. La curva de aprendizaje es de semanas, no de años. Pero las recetas son del franquiciador, los proveedores también, el precio del pan está en el catálogo y el día que cambia la fórmula del croissant le llega un correo informativo, no una decisión de negocio.

Ambas panaderías sacan pan. Ambas cumplen sanidad y producen ingresos. La diferencia operativa es enorme y no es de tecnología: es de propiedad, control y plazo.

El paralelismo con LLMOps es directo. El stack OSS on-premise es la panadería propia. El stack gestionado en hyperscalers es la franquicia. Las piezas que aparecen en cada etapa son equivalentes funcionalmente — al final del día las dos resuelven el mismo problema técnico —, pero el modelo de gobierno, el coste operativo, el lock-in y las garantías de cumplimiento son distintos. Este post hace el catálogo paralelo para que la elección no se haga por defecto.

Recap rápido del post anterior

En el post forense seguimos una request específica: un usuario premium-es de una aseguradora preguntando "¿Cómo cancelo mi suscripción premium?" al chatbot de soporte multi-tenant del proveedor SaaS que la hospeda. El recorrido atravesó las seis etapas del pipeline LLMOps —Data, Tune, Eval, Deploy, Observe, Retrain— más los dos componentes transversales —prompt versioning y data versioning— sobre una infraestructura on-premise: RKE2 con Cilium BGP, cluster 4×H100 SXM, RTX 4090 de desarrollo, vLLM en Kubernetes, Langfuse + OTel + Prometheus + Tempo, Postgres + Qdrant, DVC + lakeFS + MinIO, Kafka y MLflow. El sistema cumple ENS / NIS2 y mantiene trace_id propagado extremo a extremo.

Lo que viene ahora es ese mismo sistema, pieza a pieza, mostrando para cada caja qué herramienta hace el trabajo si estás en cloud público — porque la pregunta del integrador rara vez es “¿OSS sí o no?”: es “¿qué pierdo y qué gano si esta caja la cojo gestionada?”. Y la respuesta es distinta por caja.

Etapa 1 — Data

El problema. Hay tres sub-problemas que la etapa Data resuelve, frecuentemente confundidos. Primero, versionado e identidad del corpus y de los datasets de entrenamiento (que un dataset_id, dataset_version exista y propague). Segundo, almacenamiento y servido del corpus operativo (object store + vector index + texto estructurado). Tercero, streams e ingestión desde sistemas fuente con CDC, transformación y esquemas estables (Schema Registry).

Stack OSS de referencia. El versionado vive en DVC (apuntadores en git, contenido en object store) combinado con lakeFS para semántica branch/merge sobre datos. El post sobre data versioning profundiza en la diferencia funcional. El object store es MinIO o Ceph. El vector index es Qdrant o Milvus para corpus grandes (millones de chunks) y pgvector sobre Postgres 18 para casos pequeños donde la operativa de un componente menos compensa. La capa stream es Kafka (Apache puro o Redpanda) con Schema Registry (Confluent o Karapace OSS), CDC con Debezium o Flink CDC, transformación con Flink o Spark Structured Streaming. El catálogo / lineage es DataHub, Apache Atlas o OpenMetadata con eventos OpenLineage entre sistemas. El post sobre ingestión PostgreSQL + Qdrant y el post sobre RAG sobre Kafka cubren la operativa detallada.

Equivalentes hyperscaler. En AWS, el corpus vive en S3 (con versioning habilitado, que es el sustituto barato del data versioning serio), las consultas tabulares en Athena o Redshift, el vector index en Amazon OpenSearch con plug-in vectorial o en Amazon Aurora pgvector. La capa stream es MSK (Kafka gestionado) o Kinesis Data Streams, CDC con AWS DMS, transformación con Glue Streaming o MSK Connect. El catálogo es AWS Glue Data Catalog + AWS Lake Formation para gobierno de datos. Y para el caso RAG hay además Amazon Bedrock Knowledge Bases, que es el atajo gestionado: le das S3, te indexa en OpenSearch o Aurora pgvector, te expone un retrieval API y se acaba la operativa — a cambio de pagar por chunk indexado y consulta.

En GCP, el corpus vive en Cloud Storage (con object versioning), el almacén analítico es BigQuery (con BigQuery Vector Search ya integrado), el vector dedicado es Vertex AI Vector Search (antes Matching Engine). La capa stream es Pub/Sub + Dataflow, CDC con Datastream. El catálogo y lineage es Dataplex (que en 2024-2025 absorbió Data Catalog y añadió lineage automático). El equivalente gestionado de Knowledge Bases es Vertex AI Search (antes Discovery Engine).

En Azure, el corpus vive en ADLS Gen2, las consultas tabulares en Microsoft Fabric / Azure Synapse, el vector index en Azure AI Search (vector mode) o Azure Cosmos DB for PostgreSQL con pgvector. La capa stream es Event Hubs + Stream Analytics o Microsoft Fabric Real-Time Intelligence, CDC con Azure Data Factory. El catálogo es Microsoft Purview, que cubre catalog, lineage y data governance integrados con Entra ID.

Tabla resumen — Etapa Data.

Dónde los nombres engañan. S3 Versioning no es DVC. Conserva versiones de objetos pero no tiene noción de dataset (¿qué objetos forman juntos la versión 3 del enriquecido?), no propaga dataset_hash al trainer, no integra con experiment tracking, y no falla un CI si un dataset rompe schema. Cubrirlo de verdad en AWS exige combinarlo con Lake Formation, Glue Data Catalog y registros propios en SageMaker Experiments. Lo mismo en GCP con Dataplex y en Azure con Purview. El gap es real y se paga en operativa o en lineage roto.

Etapa 2 — Tune

El problema. Producir un nuevo model_id, model_version —típicamente un adapter LoRA sobre un base estable, como cuenta el post de fine-tuning continuo— con lineage hasta el dataset que lo entrenó y experiment tracking que permita reproducirlo seis meses después.

Stack OSS. Núcleo técnico: HuggingFace Transformers + PEFT (LoRA, QLoRA), bitsandbytes para quantization, DeepSpeed o FSDP para paralelismo. Experiment tracking: MLflow (autoritativo) o Weights & Biases self-hosted. Frameworks de conveniencia: Axolotl y Llama Factory envuelven la maquinaria anterior con configuración declarativa. Orquestación distribuida: Kubeflow Training Operator o Ray Train. En infraestructuras pequeñas, scripts directos con Slurm o K8s Jobs sobre GPU pools. La cadena de lineage dataset → run → model se cierra registrando el dataset como input artifact MLflow.

Equivalentes hyperscaler. En AWS, SageMaker Training Jobs sirve para la mayoría de cargas, SageMaker HyperPod para entrenamientos grandes con resiliencia a fallos de nodo, SageMaker JumpStart ofrece fine-tuning click-to-train sobre catálogo de modelos pre-curados. Para fine-tuning de modelos Bedrock (Claude, Llama, Mistral hospedados) está Bedrock Custom Models: tú subes el dataset al S3, Bedrock entrena, te devuelve un endpoint privado con throughput provisionado. El experiment tracking equivalente es SageMaker Experiments o MLflow gestionado en SageMaker (sí, AWS hospeda MLflow oficialmente desde 2024).

En GCP, Vertex AI Custom Training corre cualquier contenedor con GPUs o TPUs; Vertex AI Tuning es la API gestionada para fine-tunear Gemini y modelos del Model Garden. Experiment tracking en Vertex AI Experiments (con compatibilidad MLflow).

En Azure, Azure ML Training Jobs sobre clusters propios o managed compute; Azure OpenAI fine-tuning para fine-tunear GPT y o-series; Azure ML Experiments con MLflow integrado nativamente desde 2022.

Tabla resumen — Etapa Tune.

Dónde los nombres engañan. Los fine-tunings managed (Bedrock Custom, Vertex Tuning, AOAI fine-tuning) son caja negra: no eliges hiperparámetros más allá de un puñado, no ves los logs detallados del trainer, no puedes inspeccionar el dataset una vez en su pipeline. El experiment tracking que ofrecen no es comparable al MLflow puesto al lado del trainer, donde puedes capturar cualquier métrica y artefacto. Para escenarios donde operativamente no necesitas inspección esto es liberador; para escenarios de ENS / NIS2 donde tienes que demostrar qué entrenó qué, el caja negra incumple por construcción.

Etapa 3 — Eval

El problema. Validar candidatos antes y después de promotion contra un golden set, con métricas operativas (faithfulness al RAG, tono, format compliance, toxicidad, jailbreak resistance, PII leakage) ejecutadas como gates en CI y como sampling online. Cubierto en el post sobre evals y en el de guardrails.

Stack OSS. Suites de evals: DeepEval, RAGAS (especializada en RAG), Promptfoo (declarativa, ideal para CI), lm-eval-harness (académica), HELM. Evals integrados con tracing: Langfuse Evals, Phoenix Arize OSS. Judges LLM-as-judge: cualquier modelo OSS local; en sistemas serios, dos judges distintos para reducir sesgo. Safety y guardrails: NeMo Guardrails (NVIDIA), Guardrails AI, LlamaGuard + PromptGuard (Meta), ShieldGemma (Google, pesos abiertos), PII detectors tipo Presidio (Microsoft) on-prem.

Equivalentes hyperscaler. En AWS, Bedrock Model Evaluation ofrece evals automáticos (toxicity, accuracy, robustness) y human-in-the-loop, Bedrock Guardrails cubre la capa de safety (denied topics, PII, prompt injection, contextual grounding check), SageMaker Clarify añade bias y explainability sobre modelos generales.

En GCP, Vertex AI Evaluation Service ejecuta evals con métricas automáticas y judge LLM, Vertex AI Model Armor y los safety filters integrados en Gemini API cubren la capa de guardrails. Vertex AI Studio expone Eval interactivo para iteración con prompts.

En Azure, Azure AI Evaluation SDK corre evals offline contra datasets, Azure AI Content Safety cubre safety (Prompt Shields contra jailbreak, Groundedness detection, content categories, PII detection). Todo accesible desde Azure AI Foundry.

Tabla resumen — Etapa Eval.

Dónde los nombres engañan. Los guardrails gestionados son convenientes pero opacos: las reglas de Bedrock Guardrails son configurables pero la implementación de detección no se inspecciona; lo mismo en Azure AI Content Safety. En OSS, NeMo Guardrails te enseña el grafo de Colang y Presidio te enseña los recognizers — auditables, modificables. Para sistemas regulados donde un auditor pregunta "¿cómo detecta exactamente PII?", el OSS responde con código; el cloud responde con documentación.

Etapa 4 — Deploy

El problema. Servir tokens al usuario final con latencia y throughput predecibles, ratio coste / token decente, soporte de adapters hot-swap, y multi-tenancy si el negocio lo exige. Cubierto en los posts de KV cache, PagedAttention, disaggregated serving, vLLM en K8s, operators LLM y cluster multi-tenant.

Stack OSS. Motor de inferencia: vLLM (PagedAttention, prefix caching, LoRA hot-swap, OpenAI-compatible API) como referencia, TensorRT-LLM para máxima optimización sobre Hopper / Ada, SGLang para cargas con muchas restructuraciones de prompt, TGI (Hugging Face) como alternativa madura, llama.cpp para edge y CPUs, NVIDIA Dynamo para disaggregated serving multinodo en clusters grandes. Orquestación en Kubernetes: KServe, KubeRay, operators dedicados como llm-d, vLLM Production Stack y KAITO. Gateway / control plane: Envoy AI Gateway, LiteLLM Proxy, Portkey AI Gateway, Kong AI Gateway. Triton Inference Server cubre cargas mixtas (LLM + tradicionales) donde un solo backend importa.

Equivalentes hyperscaler. En AWS, dos rutas distintas. La ruta gestionada por modelo es Amazon Bedrock: catálogo de modelos hospedados (Claude, Llama, Mistral, Cohere, Titan), pago por token o Provisioned Throughput con SLA, Bedrock Prompt Caching equivalente conceptual al prefix caching de vLLM, Bedrock Agents y Bedrock Knowledge Bases integrados. La ruta gestionada por infraestructura es SageMaker Endpoints (real-time, async, serverless, batch) con Inference Components para densificar múltiples modelos en una instancia. Hardware propio: AWS Inferentia y Trainium vía el chip Neuron, alternativa a NVIDIA con coste / token mejor en cargas estables si compila tu modelo.

En GCP, Vertex AI Prediction Endpoints corre tus contenedores o modelos del Model Garden, Gemini API vía Vertex AI ofrece los Gemini gestionados, Cloud TPU v5e / v5p / Trillium (v6) como hardware propio competidor de H100 para entrenamiento e inferencia. Para soberanía está Google Distributed Cloud air-gapped, que lleva Vertex AI a un rack on-premise certificable.

En Azure, Azure OpenAI Service sirve modelos OpenAI (GPT-4.1, o-series, GPT-image), Azure ML Managed Online Endpoints corre cualquier modelo (incluido OSS vía contenedor), Azure AI Foundry models absorbió en 2025 el catálogo de modelos abiertos servidos as-a-service. Hardware: Azure ND H100 v5, ND H200 v5, ND GB200 v6 y la apuesta propia Microsoft Maia 100 para inferencia interna.

Tabla resumen — Etapa Deploy.

Dónde los nombres engañan. Bedrock Prompt Caching y Vertex context caching suenan equivalentes al prefix caching de vLLM, pero operativamente son distintos: el cache vive en el plano del hyperscaler, su política de eviction es opaca, su coste se cobra aparte, y no podés ver hit ratio por tenant fácilmente. En vLLM ves el hit ratio en métricas Prometheus y decides la política. Igual con disaggregated serving: los hyperscalers lo implementan internamente para reducir su propio coste de servir, pero no exponen el control de prefill/decode al usuario — si necesitas que tu workload tenga TTFT controlado por separado del TPS, no es palanca disponible.

Etapa 5 — Observe

El problema. Trazas LLM end-to-end con trace_id propagado por todos los componentes, métricas de runtime por tenant, scoring online (judge LLM sobre sampling), drift estadístico, y safety / guardrails monitoring. Cubierto en los posts de tracing AgentSight, MCP observability con OTel y eBPF + drift.

Stack OSS. Estándar base: OpenTelemetry (especificación + collector + SDKs) con las gen_ai semantic conventions que se estabilizaron en 2025. Backends: Tempo o Jaeger para traces, Prometheus para metrics, Loki para logs, Grafana como UI común. Capa LLM-específica: Langfuse (self-hosted con licencia EE opcional) y Phoenix Arize OSS. Capa eBPF para observabilidad de bajo nivel: Pixie, Hubble, y Cilium Tetragon para runtime security. Drift: Evidently AI, NannyML, Alibi Detect.

Equivalentes hyperscaler. En AWS, CloudWatch (metrics + logs) + AWS X-Ray (traces) son la base, CloudWatch Application Signals añade APM con OTel compatible, Amazon Managed Prometheus y Amazon Managed Grafana sirven el plano si quieres mantener Prom + Grafana sin operar. Bedrock logging integrado con CloudWatch y S3. ADOT (AWS Distro for OpenTelemetry) es el collector oficial.

En GCP, Cloud Monitoring + Cloud Logging + Cloud Trace + Cloud Profiler forman el quinteto, todos compatibles con OTel. Vertex AI Model Monitoring ofrece drift detection (feature skew, prediction drift) integrado con runs.

En Azure, Azure Monitor + Application Insights + Log Analytics cubren la pila APM con OTel nativo, Azure ML Model Monitor añade drift y data quality, Azure OpenAI diagnostic logs enriquecen los traces con metadata de tokens y modelo.

Tabla resumen — Etapa Observe.

Dónde los nombres engañan. Las herramientas APM clásicas del cloud (X-Ray, Cloud Trace, App Insights) no entienden prompt versioning ni adapter id como conceptos nativos. Aceptan los atributos gen_ai.* como dimensions, pero las UIs no priorizan esas vistas. Langfuse y Phoenix sí, porque están diseñadas para LLM. En cloud, el patrón habitual es enviar dual: APM al servicio gestionado para infra + Langfuse / Phoenix self-hosted para el plano LLM. Eso compensa.

Etapa 6 — Retrain + transversales

El problema (Retrain). Cerrar el bucle feedback → triage → dataset enriquecido → adapter nuevo, con cadencia mixta (trimestral + incident-driven). Cubierto en el post de Retrain.

Stack OSS Retrain. Orquestación: Apache Airflow, Prefect, Dagster o Argo Workflows y Kubeflow Pipelines para K8s-native. Feature store cuando aplica: Feast. Annotation y human-in-the-loop: Argilla, Label Studio, Trubrics. Captura de feedback estructurado: tabla Postgres propia + Langfuse scores + Phoenix annotations. Lineage del ciclo cerrado: OpenLineage atando dataset → run → model → deployment → feedback → dataset siguiente.

Equivalentes hyperscaler Retrain. En AWS, SageMaker Pipelines orquesta el ciclo, SageMaker Ground Truth y A2I (Augmented AI) gestionan annotation y HiL, SageMaker Model Monitor dispara alertas que pueden invocar pipelines de retrain. AWS Step Functions sirve como orquestador alternativo más general.

En GCP, Vertex AI Pipelines (basado en Kubeflow Pipelines, compatible) orquesta, Vertex AI Data Labeling Service anota, Vertex AI Feature Store gestiona features, Workflows o Cloud Composer (Airflow gestionado) como alternativas de orquestación.

En Azure, Azure ML Pipelines orquesta, Azure ML Data Labeling anota, Azure ML Feature Store gestiona features.

El problema (transversales: prompt + data versioning). Que prompt_id, prompt_version y dataset_id, dataset_version propaguen por todo el sistema y aparezcan en spans, runs y métricas. Cubiertos en los posts de prompt versioning y data versioning.

Equivalentes prompt versioning. OSS: Langfuse Prompts, MLflow Prompt Registry. AWS: Bedrock Prompt Management (catalog, versiones, labels, A/B testing integrado) y SageMaker Prompt Hub. GCP: Vertex AI Prompt Management dentro de Vertex AI Studio. Azure: Azure AI Foundry Prompt flow y prompt versioning en Azure OpenAI deployments.

Equivalentes data versioning. OSS: DVC + lakeFS (ya cubierto en Data). AWS: S3 Versioning + Lake Formation + Glue Catalog (no son DVC pero juntos cubren parte). GCP: Cloud Storage versioning + Dataplex (idem). Azure: ADLS Gen2 versioning + Purview (idem). El gap real aquí es que ningún hyperscaler ofrece DVC nativamente — la operativa de dataset-as-first-class-citizen sigue requiriendo capa propia.

Tabla resumen — Etapa Retrain + transversales.

El chatbot del post anterior portado a AWS

Para que el catálogo deje de ser abstracto, tomamos el escenario completo del post anterior — el chatbot multi-tenant de soporte para aseguradoras sobre stack OSS on-premise — y lo describimos componente a componente con stack AWS. No es una migración ejecutable; es el mapa de qué desaparece, qué aparece y dónde aparece el lock-in.

El plano de red. Edge LB y WAF: AWS WAF + CloudFront. Ingress al cluster: AWS Load Balancer Controller sobre EKS. Lo que era Cilium BGP + RKE2 se sustituye por EKS con VPC CNI (o Cilium en EKS, posible). El equivalente conceptual de Tetragon es Amazon GuardDuty for EKS + Falco opcional. Lock-in moderado: el control de red se acopla a VPC.

El gateway de chat y la auth. Lo que era una API gateway propia con JWT verificación se materializa como Amazon API Gateway + Amazon Cognito (o IAM Identity Center si es B2B). El AI-aware routing del gateway se cubre con Bedrock + tags por cliente o con AWS API Gateway custom authorizers invocando una Lambda para tenant resolution. Lock-in alto en la capa de identidad si se elige Cognito.

El motor de inferencia. Tres opciones distintas, con trade-off claro.

• Bedrock con modelo gestionado (Claude / Llama / Mistral): se elimina toda la operativa de vLLM, K8s Operators, KV cache y disaggregated serving. Se pasa a Provisioned Throughput para garantía de latencia. Se gana time-to-market; se pierde control sobre prefill/decode, sobre adapter LoRA custom (Bedrock acepta fine-tunes Bedrock-managed pero no LoRAs arbitrarios), y se entra en lock-in de modelo (cambiar de Claude a Llama es cambiar de API).
• SageMaker Endpoints con tu contenedor vLLM: se mantiene vLLM y sus optimizaciones, pero K8s desaparece y SageMaker lo reemplaza como plano de orquestación. Inference Components permite densificar múltiples adapters. El KV cache, prefix caching y LoRA hot-swap funcionan igual. Lock-in moderado en el SDK SageMaker y en el formato de Inference Components.
• EKS con vLLM (la opción minimalista): básicamente el stack OSS pero con EKS en lugar de RKE2 y EBS/EFS en lugar de Ceph. Lock-in bajo, beneficio limitado del cloud.

Data layer. El corpus pasa a S3 con versioning, los embeddings a Amazon OpenSearch Service o a Aurora pgvector. La opción gestionada radical es Bedrock Knowledge Bases: subes documentos a S3, te indexa, te expone un retrieval API. Eliminamos Qdrant, eliminamos pipelines de embedding manuales, eliminamos parte de Kafka + Flink. Pero el control sobre reranking custom, ACL fino por chunk y la posibilidad de re-embeber con un encoder propio nuevo desaparece — Bedrock KB usa los embedders de Titan o Cohere disponibles en Bedrock, y cambiarlos es cambiar todo el índice. Compliance ENS: hay que validar que los buckets y el índice viven en regiones EU y que el modelo de embedding también.

Stream + CDC. Kafka + Debezium se reemplaza por MSK + MSK Connect o por Kinesis + DMS. Schema Registry: Glue Schema Registry. Los eventos siguen siendo equivalentes funcionalmente. Lock-in moderado si vas a Kinesis (Kinesis no es Kafka), bajo si vas a MSK (compatibilidad Kafka).

Data versioning. Aquí el gap es claro. S3 Versioning + Lake Formation + Glue Catalog no es DVC. Para conservar la disciplina del post anterior — (dataset_id, dataset_version, sha256_hash) propagado como input artifact al trainer — se puede mantener DVC sobre S3 (DVC funciona perfectamente con S3 como remote) o aceptar la limitación y registrar manualmente el lineage en SageMaker Lineage Tracking. La primera opción mantiene la operativa; la segunda acepta degradación.

Etapa Tune. El adapter LoRA customer_support_v7 se entrena con SageMaker Training Jobs sobre instancias ml.p5.48xlarge (8× H100), usando un contenedor HuggingFace + PEFT estándar. MLflow gestionado por SageMaker o MLflow propio en EC2 cubren el tracking. Alternativa: si se acepta el caja negra, Bedrock Custom Models con un dataset en S3 produce un modelo Bedrock fine-tuneado sin instanciar GPU manualmente, a cambio de no poder inspeccionar el run.

Etapa Eval. Promptfoo + RAGAS en CI corre igual sobre CodeBuild. Bedrock Model Evaluation sustituye buena parte de la suite de evals automáticos. Bedrock Guardrails sustituye NeMo Guardrails + Presidio + LlamaGuard, con la pérdida de transparencia comentada antes.

Etapa Deploy. Si se eligió Bedrock como motor, esta etapa se desvanece — Bedrock sirve. Si se eligió SageMaker Endpoints + vLLM, KServe se sustituye por SageMaker Operators (o se conserva KServe sobre EKS). El AI Gateway que en OSS era Envoy AI Gateway o LiteLLM pasa a ser API Gateway + Bedrock o API Gateway + Lambda + SageMaker.

Etapa Observe. OTel Collector sigue siendo el estándar. Trazas a AWS X-Ray + CloudWatch Application Signals. Métricas a Amazon Managed Prometheus. Logs a CloudWatch Logs + opcional OpenSearch para búsqueda. Langfuse se hospeda en ECS Fargate o EKS porque el cloud no tiene equivalente nativo del prompt + traces + scores integrado. Drift: SageMaker Model Monitor sustituye Evidently / NannyML. eBPF (Pixie / Hubble / Tetragon) no tiene equivalente directo en AWS gestionado — Falco o instalación de Tetragon en EKS sigue siendo la ruta.

Etapa Retrain. SageMaker Pipelines orquesta el ciclo trimestral. SageMaker Ground Truth + A2I sustituyen Argilla. El feedback_signals en Postgres se mantiene tal cual (RDS Postgres) o se traslada a DynamoDB para escalas grandes.

Cuánto pesa el lock-in. El componente con lock-in más alto es Bedrock + Bedrock Knowledge Bases + Bedrock Guardrails: salir de ahí requiere reescribir el plano de inferencia y reindexar todo el RAG. Le sigue SageMaker SDK (Pipelines, Endpoints, Training) — salir cuesta pero es reescribir scripts, no datos. Datos en S3 son portables (S3 → MinIO con rclone funciona). El observabilidad OTel es portable casi sin coste si se mantiene el collector como abstracción. El gateway de auth es el otro punto de lock-in alto si va Cognito.

Qué se gana. Reducción dramática de operativa de infraestructura GPU, parches K8s, gestión de drivers CUDA, dimensionamiento de prefill/decode, gestión de Ceph / MinIO. Curva de arranque muy corta: una request servida en menos de un sprint vs varias semanas de bring-up del stack OSS. SLAs explícitos del proveedor.

Qué se pierde. Soberanía contractual de datos (los datos siguen en regiones EU si así se configura, pero el operador es un tercero estadounidense bajo Cloud Act). Visibilidad de la pila completa (Bedrock es caja negra desde el modelo hacia abajo). Independencia de roadmap (la decisión de discontinuar un modelo, subir precios o cambiar guardrails no la controla el cliente). Optimización fina del coste por token (las palancas son las que el proveedor expone). Para clientes ENS bajo declaración ALTA o NIS2 categoría esencial, varios de estos puntos son incumplimiento, no preferencia.

Tabla maestra: el catálogo paralelo entero

Cuándo elegir cada lado — la decisión real

La pregunta correcta no es "¿OSS o cloud?". Es por etapa.

El lado OSS gana por defecto cuando hay:

• Datos sometidos a ENS categoría ALTA, NIS2 sectores esenciales o equivalentes (datos sanitarios identificables, banca regulada, infra crítica). Aquí la trazabilidad del proveedor y el contrato de procesamiento no son negociables; usar un servicio cuyo operador esté sometido a Cloud Act, FISA 702 o equivalente compromete la base legal.
• Requisitos de inspección auditable del modelo, los guardrails y el pipeline completo. Si un regulador pregunta "¿cómo detecta exactamente PII?" y la respuesta acabable en código abierto es obligatoria.
• Volúmenes grandes con cargas estables. Por encima de cierto umbral de tokens/mes, el coste de Bedrock / AOAI / Vertex se aleja del coste amortizado de un cluster GPU propio. El umbral depende de carga, pero típicamente está entre 5-50 mil millones de tokens/mes para modelos del rango Llama 70B.
• Independencia de roadmap es prioritaria. El día que el proveedor discontinúa un modelo o sube el precio un 40%, la organización tiene que poder ignorarlo.

El lado hyperscaler gana por defecto cuando hay:

• Time-to-market crítico, MVP en semanas. La operativa del stack OSS pesa demasiado para un proyecto que aún no ha probado producto-mercado.
• Equipo pequeño sin SREs / MLEs especializados en inferencia GPU. La operativa de KServe + vLLM + KV cache + multi-tenant no es trivial; si el equipo no puede sostenerla, hospedar es el camino.
• Cargas variables / spikes impredecibles. Bedrock on-demand y SageMaker serverless cobran lo que usas; un cluster propio paga la GPU esté ocupada o no.
• Necesidad de modelos propietarios específicos (Claude, GPT-4.1, Gemini Pro) que no tienen equivalente OSS aceptable para el caso.

Las etapas mixtas son frecuentes y razonables. En la práctica, un patrón común en 2026 es: data, observe y retrain en OSS self-hosted (lineage y soberanía), tune en OSS sobre cluster propio, eval en OSS + guardrails gestionados según safety profile, deploy gestionado para modelos propietarios y self-hosted para modelos abiertos. La pregunta a hacerse para cada etapa es: “si el proveedor sube precios un 50% o discontinúa un componente mañana, ¿cuánto cuesta moverlo?”. El catálogo paralelo de este post da la respuesta para cada caja.

Lo que no hemos cubierto (todavía)

Quedan piezas merecedoras de su propio post:

• OpenAI / Anthropic API directamente (no a través de Bedrock o AOAI): otro nivel de gestionado, otro contrato.
• Híbridos serios: Outposts AWS, Distributed Cloud GCP, Azure Stack HCI / Azure Local — el hyperscaler en tu sala.
• Cost accounting por tenant comparado OSS vs cloud: cómo se hace la factura y dónde se rompe la atribución.
• Migración real OSS → cloud o cloud → OSS: pasos, scripts, gotchas.
• Soberanía europea concreta: GAIA-X, EuroHPC, oferta de cloud europeo (OVHcloud, Scaleway, IONOS, Aruba), comparativa con los tres grandes para casos ENS / NIS2.
• AWS Inferentia / Trainium, GCP TPU v6 Trillium, Azure Maia: chips propios y cómo cambian el cálculo de coste / token.

Ver también

• Anatomía de una petición LLM en producción — el recorrido forense de una request por las seis etapas, hilo del que este post hace el corte vertical.
• El catálogo OSS para LLMOps en seis etapas: ficha por ficha — el zoom in al lado open source de la tabla maestra de este post: ficha de ~150 palabras por herramienta OSS core (vLLM, Langfuse, DVC, Qdrant, Airflow, NeMo Guardrails, Presidio…), licencia y gobierno, matriz de decisión por etapa y diagrama del stack OSS conectado.
• El pipeline LLMOps de seis etapas — el mapa maestro al que este catálogo es complemento.
• MLOps específico para LLMs en 2026 — contexto general sobre por qué LLMOps no es MLOps clásico.
• Data versioning con DVC y lakeFS — el deep-dive del transversal Data.
• Prompt versioning con Langfuse y MLflow — el deep-dive del transversal Prompt.
• Fine-tuning continuo en producción — Tune detallado.
• Evals: la capa después del tracing — Eval detallado.
• Guardrails y safety en LLMs — la capa de safety en detalle.
• KV cache · PagedAttention · Disaggregated serving — Deploy desde dentro.
• vLLM en Kubernetes · Operators LLM en K8s · Cluster GPU multi-tenant — Deploy operativo.
• AgentSight tracing LLM · MCP observability con OTel · eBPF + drift — Observe en sus capas.
• Retrain: cerrar el bucle feedback → dataset → adapter — Retrain detallado.

Referencias

• vLLM documentation y vLLM Production Stack — motor de inferencia OSS de referencia.
• Amazon Bedrock documentation — catálogo de modelos gestionados AWS, Knowledge Bases, Guardrails y Prompt Management.
• Amazon SageMaker AI — training, endpoints, pipelines, model monitoring.
• Google Vertex AI documentation — training, prediction, evaluation, model monitoring.
• Azure AI Foundry documentation — plano unificado de Microsoft para AI applications.
• Azure OpenAI Service documentation — modelos OpenAI hospedados en Azure.
• OpenTelemetry GenAI semantic conventions — el estándar que cose la observabilidad a través de las fronteras OSS / cloud.
• Langfuse documentation y Arize Phoenix — LLM observability OSS de referencia.
• DVC y lakeFS — data versioning OSS.
• NeMo Guardrails — safety + dialog policy OSS.
• ENS (Esquema Nacional de Seguridad) y NIS2 (Network and Information Security Directive 2) — los marcos de cumplimiento que tienen la última palabra en la elección OSS vs cloud para clientes regulados de la UE.