Serverless Computing

La computación sin servidor es un modelo de ejecución en la nube en el que el proveedor ejecuta el código solo cuando un evento lo requiere, inicia y escala automáticamente los servidores subyacentes, los apaga por completo cuando cesa el tráfico y cobra por las solicitudes y el tiempo de ejecución, en lugar de por máquinas reservadas. Los servidores siguen existiendo, pero los desarrolladores nunca tienen que aprovisionarlos, aplicarles parches ni dimensionarlos. El modelo se generalizó con AWS Lambda, anunciado en noviembre de 2014, y ahora abarca plataformas de funciones como Lambda, Azure Functions y Cloud Run functions, además de contenedores sin servidor como Google Cloud Run y Azure Container Apps. Investigadores de UC Berkeley describieron sus ventajas y limitaciones en el artículo de 2019 «Cloud Programming Simplified: A Berkeley View on Serverless Computing». Para el aprendizaje automático, la computación sin servidor es adecuada para la prestación de modelos con tráfico irregular o imprevisible, en los que pagar por un servidor GPU inactivo entre picos costaría más que el propio trabajo.

Cómo funciona la ejecución sin servidor#

El código se empaqueta como una función o una imagen de contenedor y se asocia a activadores: una solicitud HTTP, la llegada de un archivo al almacenamiento de objetos, un mensaje en una cola o una programación. Cuando llega un evento y hay disponible una instancia activa, la plataforma ejecuta el controlador en ella inmediatamente. De lo contrario, realiza un arranque en frío: crea un entorno aislado, como una de las microVM Firecracker que AWS desarrolló para Lambda, carga el código, inicia el entorno de ejecución del lenguaje y ejecuta el código de inicialización fuera del controlador antes de gestionar el evento. Las instancias no tienen estado y son desechables, por lo que cualquier dato que deba persistir tras una solicitud se guarda en un almacenamiento externo o en una base de datos.

Arranques en frío y modelos de aprendizaje automático#

El aprendizaje automático hace que los arranques en frío sean costosos, porque la inicialización importa un framework como PyTorch y carga pesos del modelo que pueden ocupar cientos de megabytes. El patrón estándar carga el modelo una vez por instancia, fuera del controlador o en el primer uso, para que cada invocación en caliente lo reutilice. Este controlador sigue ese patrón con un clasificador ResNet-50 de torchvision:

import time

import torch
import torchvision

model = None  # module state survives between invocations while the instance stays warm


def handler(event, context):
    """Classify one image tensor, building the model only on a cold start."""
    global model
    cold_start = model is None
    if cold_start:
        model = torchvision.models.resnet50().eval()  # built once per instance
    with torch.inference_mode():
        logits = model(event["image"])
    return {"cold_start": cold_start, "class_id": int(logits.argmax())}


for _ in range(3):
    start = time.perf_counter()
    response = handler({"image": torch.rand(1, 3, 224, 224)}, context=None)
    print(response["cold_start"], f"{(time.perf_counter() - start) * 1000:.0f} ms")

En una CPU Apple M5 Pro, la primera llamada crea la red y tarda aproximadamente 0,2 segundos, mientras que las dos llamadas en caliente que la reutilizan tardan unos 15 ms cada una. Los equipos reducen el tiempo restante de arranque en frío con imágenes de contenedor más pequeñas, modelos compactos o cuantizados y entornos de ejecución más ligeros, como ONNX Runtime; también pueden eliminarlo manteniendo un número mínimo de instancias en caliente, como la concurrencia aprovisionada de Lambda o las instancias mínimas de Cloud Run, aunque así se vuelve a pagar por el tiempo de inactividad.

Computación sin servidor para cargas de trabajo de IA#

La informática sin servidor encaja en las canalizaciones de visión artificial basadas en eventos. La carga de una imagen al almacenamiento de objetos puede activar una función que la valida y cambia de tamaño durante el preprocesamiento de datos antes de incorporarla a un conjunto de datos de entrenamiento. En un sistema de alarma de seguridad, un sensor de movimiento puede enviar un único fotograma a una función de detección de objetos que avisa solo si encuentra a una persona. El resto depende de los límites de la plataforma: AWS Lambda ejecuta cada invocación durante un máximo de 15 minutos, con hasta 10.240 MB de memoria y sin GPU. Esto sirve para ejecutar inferencias en CPU con modelos compactos, pero descarta los entrenamientos largos y, con mayor motivo, el entrenamiento distribuido en muchas GPU. La informática sin servidor con GPU ha cubierto esa carencia: Cloud Run conecta GPU NVIDIA L4 a contenedores que siguen pudiendo escalar a cero, y plataformas como Modal facturan el tiempo de GPU por segundos.

Ultralytics Platform ofrece la misma disyuntiva para las implementaciones de YOLO: un endpoint con el tamaño predeterminado de 1 vCPU y 2 GiB es gratuito y escala a cero cuando está inactivo; al iniciarlo desde cero, puede tardar alrededor de un minuto. Los tamaños personalizados mantienen una instancia activa y cobran por el tiempo que está en funcionamiento.

Computación sin servidor frente a modelos relacionados#

• Infraestructura como servicio: Máquinas virtuales que están en funcionamiento y generan costes las 24 horas, tanto si reciben solicitudes como si no, y cuyo sistema operativo y escalado gestiona el cliente. Los trabajos de entrenamiento largos suelen ejecutarse aquí.
• Kubernetes: Orquesta contenedores en clústeres que gestiona el equipo. Knative añade sobre esta base el escalado a cero en función de las solicitudes, y KServe lo utiliza para servir modelos.
• Computación perimetral: Ejecuta el código en los dispositivos que producen los datos o cerca de ellos. La computación sin servidor lo ejecuta en una región de la nube, y algunas plataformas perimetrales combinan ambos enfoques al ejecutar funciones en muchas ubicaciones pequeñas cerca de los usuarios.