Serverless Computing

A computação sem servidor é um modelo de execução em nuvem no qual o provedor executa código apenas quando um evento exige isso, inicia e dimensiona automaticamente os servidores subjacentes, encerra-os quando o tráfego para e cobra pelas solicitações e pelo tempo de execução, em vez de cobrar por máquinas reservadas. Os servidores continuam existindo, mas os desenvolvedores nunca precisam provisioná-los, aplicar patches ou dimensioná-los. O modelo se popularizou com o AWS Lambda, anunciado em novembro de 2014, e hoje abrange plataformas de funções como Lambda, Azure Functions e Cloud Run functions, além de contêineres sem servidor como Google Cloud Run e Azure Container Apps. Pesquisadores da UC Berkeley descreveram seus pontos fortes e limitações no artigo de 2019 "Cloud Programming Simplified: A Berkeley View on Serverless Computing". Para aprendizado de máquina, a computação sem servidor é adequada à implantação de modelos com tráfego variável ou imprevisível, quando pagar por um servidor GPU ocioso entre os picos custaria mais do que o próprio trabalho.

Como funciona a execução sem servidor#

O código é empacotado como uma função ou imagem de contêiner e associado a gatilhos: uma solicitação HTTP, um arquivo enviado ao armazenamento de objetos, uma mensagem em uma fila ou um agendamento. Quando chega um evento e há uma instância aquecida disponível, a plataforma executa o manipulador nela imediatamente. Caso contrário, ocorre uma inicialização a frio: a plataforma cria um ambiente isolado, como uma das microVMs Firecracker que a AWS desenvolveu para o Lambda, carrega o código, inicia o runtime da linguagem e executa o código de inicialização fora do manipulador antes de processar o evento. As instâncias não têm estado e são descartáveis, portanto tudo o que precisa sobreviver a uma solicitação vai para um armazenamento externo ou banco de dados.

Inicializações a frio e modelos de aprendizado de máquina#

O aprendizado de máquina torna as inicializações a frio dispendiosas, pois a inicialização importa uma estrutura como PyTorch e carrega pesos do modelo que podem ocupar centenas de megabytes. O padrão usual carrega o modelo uma vez por instância, fora do manipulador ou no primeiro uso, para que cada invocação aquecida o reutilize. Este manipulador segue esse padrão com um classificador ResNet-50 do 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")

Em uma CPU Apple M5 Pro, a primeira chamada cria a rede e leva cerca de 0,2 segundo, enquanto as duas chamadas aquecidas que a reutilizam levam cerca de 15 ms cada. As equipes reduzem ainda mais o tempo de inicialização a frio com imagens de contêiner menores, modelos compactos ou quantizados e runtimes mais leves, como o Runtime ONNX, ou eliminam esse tempo mantendo um número mínimo de instâncias aquecidas, como a simultaneidade provisionada do Lambda ou as instâncias mínimas do Cloud Run, o que volta a gerar cobranças pelo tempo ocioso.

Computação sem servidor para cargas de trabalho de IA#

A computação sem servidor é adequada a pipelines de visão computacional acionados por eventos. O envio de uma imagem para o armazenamento de objetos pode acionar uma função que a valida e redimensiona durante o pré-processamento de dados, antes que ela seja adicionada a um conjunto de dados de treinamento. Em um sistema de alarme de segurança, um sensor de movimento pode enviar um único quadro para uma função de detecção de objetos, que só alerta quando encontra uma pessoa. O restante depende dos limites da plataforma: o AWS Lambda executa cada invocação por no máximo 15 minutos, com até 10.240 MB de memória e sem GPU. Isso permite inferência em CPU com modelos compactos, mas impede longas execuções de treinamento, muito menos o treinamento distribuído em várias GPUs. A computação sem servidor com GPU preencheu essa lacuna: o Cloud Run conecta GPUs NVIDIA L4 a contêineres que ainda podem reduzir a zero, e plataformas como a Modal cobram o uso de GPU por segundo.

A Ultralytics Platform oferece a mesma compensação para implantações de YOLO: um endpoint no tamanho padrão de 1 vCPU e 2 GiB é gratuito e reduz a zero quando fica ocioso; a inicialização a partir do estado ocioso pode levar cerca de um minuto, enquanto os tamanhos personalizados mantêm uma instância aquecida e cobram pelo tempo em que ela fica ativa.

Computação sem servidor vs. modelos relacionados#

• Infraestrutura como serviço: Máquinas virtuais que ficam em execução e geram cobranças continuamente, independentemente de chegarem solicitações, com o cliente responsável pelo sistema operacional e pelo dimensionamento. Geralmente é aqui que são executados os trabalhos de treinamento longos.
• Kubernetes: orquestra contêineres em clusters operados pela equipe. O Knative adiciona a ele o dimensionamento orientado a solicitações até zero, recurso que o KServe usa para disponibilizar modelos.
• Computação de borda: executa código nos dispositivos que produzem os dados ou perto deles. A computação sem servidor executa o código em uma região de nuvem, e algumas plataformas de borda combinam as duas abordagens, executando funções em muitos locais pequenos próximos aos usuários.