Operando LLMs multimodais entre engines e nuvens

Minha contribuição

Construí fluxos de serving em GPU e de deployment, selecionei runtimes conforme a compatibilidade de modelo, corrigi falhas silenciosas de build e de roteamento de tráfego, e provisionei a identidade necessária para a inferência autenticada. Trabalhei com o time da aplicação para promover e validar a integração de fallback entre ambientes.

O trabalho evoluiu em etapas: uma prova de conceito (POC) de router com três provedores, caminhos de serving específicos por modelo usando vLLM e llama.cpp, e uma integração posterior de fallback de detecção de impressão em produção. São peças de engenharia relacionadas, com registros de validação separados.

Escolha o runtime a partir do modelo

Um identificador de modelo não basta para garantir que um engine de serving consiga carregar sua arquitetura, quantização e projetor de visão. Adicionei um resolver que lê os metadados do modelo e seleciona vLLM ou llama.cpp, com imagens, fluxos de deployment e grupos de concorrência separados.

O caminho do vLLM continuou servindo seu modelo existente enquanto o runtime alternativo era desenvolvido isoladamente. Guardas cruzadas rejeitavam um modelo no fluxo errado antes de construir uma imagem ou provisionar um pod. Os testes também verificavam se uma requisição nominalmente bem-sucedida de fato continha uma resposta utilizável: um modelo de reasoning poderia esgotar seu orçamento de tokens antes de produzir o conteúdo da resposta.

Depure a camada que de fato falhou

Em pods de GPU reais, um ciclo de vida de container aparentemente saudável escondia uma falha de carregamento de biblioteca compartilhada. A imagem upstream do llama.cpp esperava suas bibliotecas sob seu próprio diretório de trabalho; mudar esse diretório quebrava a inicialização. Tornar o caminho da biblioteca explícito resolveu o crash. Hipóteses anteriores sobre o tratamento do entrypoint e a compatibilidade de driver não explicavam aquela falha específica.

Os perfis de GPU, o contexto do modelo e as configurações de cache key/value permaneceram explícitos por runtime. Um valor de concorrência configurado maior não foi tratado como uma melhoria de throughput medida. A entrega registrou 164 testes aprovados e validação em pods de GPU reais; os pods experimentais foram removidos depois.

Um deploy verde ainda pode servir a revisão antiga

Um pipeline de deployment no Cloud Run tinha três falhas que se mascaravam mutuamente: pins de dependência incompatíveis, tráfego permanecendo em uma revisão mais antiga e smoke tests exercitando aquela imagem mais antiga. Corrigi a cadeia de dependências, movi as atualizações de tráfego para o comando correto e verifiquei que o digest servido correspondia à imagem construída pelo CI.

A validação pré-merge constrói o estágio de dependências sem baixar pesos de modelo de múltiplos gigabytes. Os smoke tests de runtime rodam a partir do caminho de rede que os chamadores reais usam, e as guardas de deployment rejeitam argumentos inconsistentes ou mudanças inseguras de ingress. A saída bem-sucedida de um comando é um sinal; servir a revisão pretendida é o resultado.

Fallback em produção e identidade

A integração posterior na aplicação usou um provedor hospedado, um modelo multimodal auto-hospedado e um caminho final de CNN. Provisionei uma identidade dedicada de service account do Kubernetes e do Google em desenvolvimento, staging e sandbox, concedendo invocação no serviço-alvo em vez de papéis amplos de projeto. O cluster de produção legado continuou usando sua identidade de nó existente; ele não foi convertido para Workload Identity por esta mudança.

Todos os quatro ambientes passaram em suas verificações de identidade e de provedor no encerramento. Na amostra pós-deploy registrada em produção, 395 requisições HTTP retornaram 200. Três timeouts do provedor primário alcançaram um modelo auto-hospedado frio e então foram concluídos pelo fallback final. Isto descreve o rollout observado, não um SLA de disponibilidade.

O scale-to-zero é um trade-off operacional: um serviço de GPU frio pode levar cerca de cinco minutos para iniciar, enquanto o orçamento da aplicação é de cerca de 30 segundos. Por isso o pré-aquecimento e o próximo fallback importam. Verificações de autenticação e monitoramento de alto tráfego foram adicionados com limiares calibrados conforme o uso real, em vez de alertar a cada requisição de fallback esperada.

Resultados e medição

A entrega de serving orientada ao modelo registrou dois caminhos de runtime isolados e 164 testes aprovados. O rollout posterior de fallback verificou identidade e comportamento da aplicação em quatro ambientes. Esses resultados são separados do POC anterior de router descrito abaixo.

As medições de otimização de boot também precisam de seu próprio escopo: um teste de imagem melhorou de 5m16s para 3m32s; um teste posterior de clean-boot registrou cerca de 4m05s. Configurações e caminhos de teste diferentes não devem ser combinados em uma afirmação universal de cold-start.

O POC anterior de router com três provedores

Construí um router FastAPI para exercitar o fluxo normal, o fallback a frio e a quente, o caminho do provedor final, os health checks e a falha de todos os provedores. Seis cenários passaram. A infraestrutura de testes foi removida depois, à espera de uma decisão de adoção em produção para aquele router; a integração posterior de fallback na aplicação é uma entrega distinta.

As observações registradas de requisições do POC foram 568 ms no RunPod, 1,917 ms no Cloud Run GPU e 7,681 ms no caminho do GCE Managed Instance Group, com uma observação de fallback a frio de cerca de 41 segundos. Foram requisições de teste específicas, não percentis de latência de produção. GCE Managed Instance Group não significa particionamento GPU Multi-Instance GPU.

Opere a frota, não pods individuais

Também conectei o inventário do router à descoberta dinâmica do Prometheus, para que o monitoramento acompanhasse workers de GPU efêmeros em vez de depender de uma lista de endereços atualizada manualmente. Leia o estudo de caso de observabilidade de frota para conhecer seus limites de rollout e monitoramento.

A lição

O serving de modelos é um sistema de decisões de compatibilidade, identidade, deployment e falha. Valide o modelo carregado, a revisão servida e o comportamento de fallback de forma independente; um build verde ou uma resposta de health HTTP não conseguem provar os três.