Qué significa realmente "GPU sin servidor"
La IA no es solo software, es una realidad física con límites estrictos de recursos. He recorrido centros de datos donde las torres de enfriamiento por evaporación consumen más agua que un vecindario pequeño; una realidad que muchos ingenieros de software pueden permitirse ignorar. Mis clientes, sin embargo, no pueden. Vienen a mí con una restricción específica: necesitan la potencia de las GPU para la inferencia o el ajuste fino, pero sin la carga operativa de aprovisionar hardware dedicado. El camino tradicional —adquirir instancias de GPU costosas, gestionar controladores, construir grupos de autoescalado complejos— conduce a recursos infrautilizados o a una actividad frenética durante los picos de demanda.
Esta guía es la capa de decisión. Compara cómo AWS, GCP y Azure abordan el acceso sin servidor a GPU, saca a la luz las ventajas y desventajas que importan en producción, y le brinda un marco claro para elegir la plataforma adecuada para su carga de trabajo. Cada plataforma tiene un artículo de inmersión profunda dedicado en esta serie; los enlaces se proporcionan al final de cada sección.
El término está sobrecargado. Entre los proveedores, cubre al menos tres patrones distintos:
- Puntos finales de inferencia que escalan a cero — usted implementa un modelo; el proveedor escala las instancias (incluidas las instancias de GPU) entre cero y N según el tráfico. Paga por invocación o por segundo de cómputo activo. Los arranques en frío son el costo principal.
- Trabajos por lotes / de ajuste fino sin servidor — usted envía un trabajo; el proveedor asigna recursos de GPU durante la duración, luego los libera. Sin punto final que gestionar, sin recuento de réplicas que ajustar.
- API de modelos gestionados — el proveedor ejecuta el modelo por completo (por ejemplo, Amazon Bedrock, Azure OpenAI). Usted llama a una API; nunca toca la abstracción de la GPU en absoluto.
No todas las plataformas admiten los tres patrones por igual. Esa asimetría es lo primero que hay que entender antes de elegir.
Comparación de plataformas
| AWS | GCP | Azure | |
|---|---|---|---|
| Servicio principal | SageMaker Serverless Inference | Vertex AI Endpoints | Azure AI Projects (AIProjectClient) |
| API de modelo gestionado | Amazon Bedrock | Vertex AI Model Garden | Azure OpenAI |
| Inferencia sin servidor (modelos personalizados) | ✅ SageMaker Serverless | ✅ Vertex AI (min_replica=0) | ⚠️ Managed Online Endpoints (no es un verdadero escalado a cero) |
| Ajuste fino sin servidor | ✅ SageMaker Training | ⚠️ Trabajo personalizado, no totalmente sin servidor | ✅ Azure OpenAI fine-tuning via AIProjectClient |
| Límite de memoria (sin servidor) | 6 GB | ~16 GB (n1-standard-4 + T4) | Depende del modelo (gestionado por Azure OpenAI) |
| Mitigación de arranques en frío | ProvisionedConcurrency | min_replica_count ≥ 1 | N/A (basado en trabajo) |
| Soporte IaC | CloudFormation / CDK / Terraform | Terraform (primera clase) | Bicep / Terraform |
| Mejor ajuste | Inferencia variable, pila de AWS existente | Pipelines de MLOps integradas | Ajuste fino de modelos de Azure OpenAI |
AWS: SageMaker Serverless Inference y Bedrock
AWS le ofrece dos puntos de entrada sin servidor distintos. Para modelos personalizados, SageMaker Serverless Inference le permite implementar su propio contenedor sin gestionar instancias. Para modelos fundacionales, Amazon Bedrock proporciona acceso API totalmente gestionado y de pago por token a Anthropic, Cohere, Amazon Titan y otros, sin ninguna gestión de GPU.
Las palancas de configuración clave son MemorySizeInMB (1024–6144 MB) y MaxConcurrency. El límite de memoria de 6 GB es el límite estricto que más importa en la práctica: los modelos de más de aproximadamente 3-4 mil millones de parámetros en FP16 no cabrán. Para modelos más grandes, el camino son los puntos finales de SageMaker con instancias de GPU dedicadas (ml.g5 o ml.inf2) o Bedrock.
ProvisionedConcurrency es el control de los arranques en frío. Configurarlo en 0 maximiza el ahorro de costos pero introduce arranques en frío de 10-30 segundos. Configurarlo en 1–2 mantiene las instancias activas a un costo fijo modesto. Aconsejo a los clientes que comiencen en cero para establecer una línea de base, luego agreguen concurrencia aprovisionada solo si se incumplen los SLO de latencia.
Cuándo elegir AWS: Su equipo ya opera en el ecosistema de AWS, su modelo cabe dentro de 6 GB de memoria y desea el modelo de IAM y observabilidad más familiar. La visibilidad del gasto por punto final de AWS Cost Explorer es también la más madura de las tres plataformas.
→ Ver la guía completa de implementación: Inferencia GPU sin servidor en AWS SageMaker
GCP: Vertex AI Endpoints
Los puntos finales de Vertex AI ofrecen la integración más estrecha con la plataforma Vertex más amplia — Model Registry, Experiments, Pipelines y Monitoring comparten el mismo modelo de recursos. Usted define un tipo de máquina con un acelerador de GPU adjunto (T4, A100, H100), establece los límites de autoescalado y Vertex se encarga del resto.
La configuración crítica es min_replica_count. Establecerlo en 0 da un verdadero comportamiento de costo de escalado a cero, pero introduce arranques en frío que regularmente superan los 60 segundos para las instancias de GPU. Para cualquier servicio de cara al usuario, min_replica_count=1 es el valor predeterminado correcto: el costo de una réplica inactiva n1-standard-4 + T4 (aproximadamente $0,95/hora) es casi siempre más barato que el esfuerzo de ingeniería para depurar incumplimientos de SLO.
Para el margen de memoria, Vertex AI es el más flexible de los tres: puede adjuntar una A100 (40 GB HBM2) o H100 (80 GB HBM3) a un tipo de máquina personalizado, evitando el límite de 6 GB que restringe a AWS SageMaker Serverless.
Cuándo elegir GCP: Está construyendo dentro de la plataforma Vertex AI y desea herramientas de MLOps (pipelines, versionado de modelos, experimentos) en un solo lugar. También es la elección correcta si su modelo es demasiado grande para SageMaker Serverless pero desea permanecer adyacente a sin servidor con autoescalado.
→ Ver la guía completa de implementación: Inferencia GPU sin servidor en GCP Vertex AI
Azure: Ajuste fino e inferencia sin servidor a través de AIProjectClient
La historia de la GPU sin servidor de Azure se divide claramente por caso de uso.
Para el ajuste fino, Azure tiene el modelo sin servidor más sólido de las tres plataformas. Se conecta a su proyecto de Azure AI a través de AIProjectClient, obtiene un cliente de OpenAI, carga los datos de entrenamiento y envía un trabajo de ajuste fino. Azure asigna computación GPU durante la duración, el trabajo se completa y usted paga solo por lo que se ejecutó. No hay punto final que gestionar, no hay recuento de réplicas que ajustar y no hay preocupación por los arranques en frío. Para el caso de uso específico del ajuste fino, este es el patrón sin servidor más limpio que he encontrado en cualquier nube.
Para la inferencia en tiempo real en modelos personalizados, Azure es el más débil de los tres. Los puntos finales en línea gestionados de Azure Machine Learning admiten tipos de instancias de GPU y autoescalado, pero no escalan a cero; debe permanecer ejecutándose un mínimo de una instancia. Esto los hace operativamente similares a una instancia dedicada gestionada en lugar de un verdadero sin servidor. La excepción son los puntos finales de Azure OpenAI: estos están totalmente gestionados, escalan de forma transparente y son la elección correcta si su carga de trabajo de inferencia es contra un modelo de OpenAI compatible.
Cuándo elegir Azure: Está ajustando modelos de Azure OpenAI, su organización ya opera en Azure o necesita las garantías de cumplimiento y residencia de datos de las regiones europeas de Azure. No elija Azure para la inferencia sin servidor de modelos personalizados si el escalado a cero sin arranques en frío es un requisito estricto.
→ Ver la guía completa de implementación: GPU sin servidor en Azure — Ajuste fino e inferencia con AIProjectClient
NVIDIA: La capa fundamental
NVIDIA no es un competidor en la nube para los tres anteriores, es el sustrato sobre el que corren los tres. El SKU de GPU que utiliza su proveedor determina directamente la memoria disponible, el rendimiento de computación y el precio:
| SKU de NVIDIA | HBM | Mapeo típico en la nube | Ideal para |
|---|---|---|---|
| T4 | 16 GB | GCP n1 + T4, AWS ml.g4dn | Caballos de batalla de inferencia, optimizados en costos |
| A10G | 24 GB | AWS ml.g5 | Inferencia + ajuste fino ligero |
| A100 | 40 / 80 GB | GCP a2, Azure NC A100 v4 | Inferencia de modelos grandes, entrenamiento |
| H100 | 80 GB HBM3 | GCP a3, Azure ND H100 v5 | Entrenamiento e inferencia de modelos de vanguardia |
NVIDIA Inference Microservices (NIMs) merecen una mención: son contenedores optimizados y precompilados para modelos populares (LLaMA, Mistral, Stable Diffusion) que se ejecutan de forma idéntica en local o en cualquier GPU de nube compatible. Si la portabilidad de hardware es un requisito —ejecutar la misma carga de trabajo en GCP hoy y en local el próximo trimestre—, los NIMs son la capa de abstracción adecuada para evaluar.
Elección: Un marco de decisión
Comience con la forma de su carga de trabajo:
- ¿Modelo fundacional gestionado (sin pesos personalizados)? → Use Bedrock (AWS), Vertex AI Model Garden (GCP) o Azure OpenAI. No se necesita gestión de GPU.
- ¿Modelo personalizado, tráfico esporádico, ≤ 6 GB de memoria? → AWS SageMaker Serverless Inference. El modelo operativo más simple en el ecosistema de AWS.
- ¿Modelo personalizado, tráfico variable, necesita gran memoria GPU o una integración MLOps estricta? → GCP Vertex AI con
min_replica_count=1. - ¿Ajuste fino de un modelo OpenAI o ejecución contra Azure OpenAI? → Azure AIProjectClient. La mejor experiencia de ajuste fino sin servidor de los tres.
- ¿Inferencia de modelo personalizado en Azure? → Azure ML Managed Online Endpoints, pero presupuestar para una instancia mínima en ejecución.
Principio fundamental de FinOps: Ejecute sin servidor durante 30 días, luego decida
Instrumente la alerta de costos antes de ir a producción — AWS Cost Explorer, GCP Budget API o Azure Cost Management. Establezca una alarma de presupuesto al 150% de su previsión. Un punto final de GPU sin servidor que escala para satisfacer un pico de tráfico inesperado puede generar el gasto esperado de un mes en una sola tarde. Capture la latencia p99, el recuento de invocaciones y el gasto real durante 30 días. Solo entonces evalúe si una instancia de GPU reservada es más barata. En mi experiencia, menos del 20% de las cargas de trabajo justifican la sobrecarga operativa de la computación GPU dedicada una vez que el tiempo de inactividad y el costo de ingeniería se tienen plenamente en cuenta.
Conclusión
El acceso sin servidor a GPU ha madurado lo suficiente como para ser el punto de partida predeterminado para cualquier nueva carga de trabajo de IA. Pero "sin servidor" significa algo diferente en cada plataforma, y la elección entre ellas no es principalmente técnica, sino operativa y organizativa.
Elija AWS si su equipo ya vive en el ecosistema de AWS y sus modelos caben dentro del límite de memoria de 6 GB. Elija GCP Vertex AI si necesita la plataforma MLOps completa o margen de GPU grande sin instancias dedicadas. Elija Azure si está ajustando modelos de Azure OpenAI o si opera en una organización prioritaria de Azure.
Los tres artículos de inmersión profunda de esta serie lo guían paso a paso a través de la implementación en cada plataforma, desde Terraform hasta llamadas SDK e instrumentación de costos. Comience con la plataforma más cercana a su infraestructura existente, mida durante 30 días y trate la gobernanza de FinOps como un requisito de primera clase desde el primer día.
