Modelos open-weight no Google Cloud: arquitetura com llm-d, vLLM e NVIDIA Dynamo

Servindo modelos open-weight de grande porte no Google Cloud: o que llm-d, vLLM e NVIDIA Dynamo mudam na arquitetura

Um endpoint de inferência pode estar saudável, retornar HTTP 200 e ainda entregar uma experiência ruim: o primeiro token demora, a resposta chega com pausas e algumas requisições monopolizam os aceleradores. Isso acontece porque servir um modelo de linguagem de grande porte não equivale a executar uma API stateless com mais memória. O tamanho dos prompts, a geração incremental e o estado de atenção influenciam diretamente o escalonamento. (cloud.google.com)

No Google Cloud, a discussão deixa de ser apenas qual GPU comprar. Ela passa a envolver qual engine executa o modelo, como escolher a réplica, onde manter o cache e quando separar o processamento do prompt da geração da resposta. Google Kubernetes Engine, ou GKE, oferece uma base para essas arquiteturas, incluindo integrações com vLLM, llm-d e NVIDIA Dynamo. (docs.cloud.google.com)

A recomendação deste artigo é evoluir por evidência: estabelecer uma baseline agregada, medir seus limites e somente então introduzir roteamento especializado ou inferência desagregada. Os exemplos são didáticos, não benchmarks nem uma certificação de compatibilidade entre releases.

1. Três projetos, responsabilidades diferentes

vLLM: a engine de execução

O vLLM carrega os pesos, executa a inferência e oferece uma API compatível com interfaces de completions e chat. Entre seus mecanismos estão continuous batching, que reorganiza o conjunto de requisições ao longo da geração, e gerenciamento paginado do KV cache, associado ao PagedAttention. O objetivo é aproveitar melhor memória e capacidade computacional. (docs.vllm.ai)

Ele também suporta execução distribuída. Portanto, vLLM não significa necessariamente uma GPU ou um único servidor. Entretanto, distribuir o cálculo de uma réplica é diferente de escolher, entre várias réplicas, qual deve atender uma requisição. (docs.vllm.ai)

llm-d: composição Kubernetes-native para inferência distribuída

O llm-d combina servidores de modelos, roteamento e mecanismos de inferência distribuída. Na integração com Gateway API Inference Extension, o InferencePool identifica os backends e o Endpoint Picker, ou EPP, participa da escolha do destino considerando sinais como carga e afinidade de cache. Não se trata do scheduler que posiciona Pods em nodes. (llm-d.ai)

O vLLM pode ser a engine dessa arquitetura. O conjunto exato de backends e funcionalidades depende da versão; não é correto assumir que llm-d é apenas um novo nome para vLLM ou que todos os backends possuem paridade funcional. (llm-d.ai)

NVIDIA Dynamo: coordenação distribuída e movimentação de estado

O Dynamo reúne frontend, roteamento consciente de KV cache, mecanismos de planejamento e transferência de dados. Pode trabalhar com engines como vLLM, SGLang e TensorRT-LLM. Sua arquitetura contempla separar prefill e decode e movimentar estado com componentes como NVIDIA Inference Xfer Library, ou NIXL. (nvidia.com)

Assim, a comparação útil não é simplesmente vLLM versus Dynamo. São possíveis arquiteturas com vLLM sozinho, llm-d com vLLM ou Dynamo com vLLM. Minha recomendação é escolher uma camada principal de coordenação e evitar sobrepor roteadores e autoscalers sem uma responsabilidade explícita para cada um.

2. Prefill, decode e KV cache

Prefill processa os tokens de entrada e produz o estado inicial de atenção. Decode utiliza esse estado para gerar novos tokens progressivamente. Prefill tende a exigir bastante computação; decode frequentemente é limitado por acesso à memória, embora o gargalo real dependa de modelo, batch e hardware. (llm-d.ai)

O KV cache, de key/value cache, armazena tensores intermediários da atenção. Não é um cache de respostas prontas nem o histórico persistente da aplicação. Automatic Prefix Caching permite reaproveitar computação de prefixos compatíveis já processados, reduzindo trabalho de prefill; não elimina o custo de gerar a resposta. (docs.vllm.ai)

Para analisar a experiência, separe:

• TTFT — time to first token: tempo até o primeiro token.
• ITL — inter-token latency: intervalo entre tokens entregues.
• Latência total: duração completa da requisição.
• Throughput: requisições ou tokens processados por unidade de tempo.

TTFT e ITL ajudam a distinguir a pressão de prefill da pressão de decode. Recomendo definir objetivos por classe de tamanho de entrada e saída, não apenas uma média para todo o endpoint. (docs.nvidia.com)

Paralelismo não é sinônimo de alta disponibilidade

Tensor parallelism divide operações entre aceleradores; pipeline parallelism divide estágios do modelo. Réplicas independentes atendem requisições distintas. Uma réplica que depende de vários aceleradores continua sendo uma única unidade lógica de serviço: mais GPUs não significam automaticamente mais redundância. (docs.vllm.ai)

Como estimativa aritmética, 70 bilhões de parâmetros com dois bytes por parâmetro representam aproximadamente 140 GB decimais apenas de pesos. Esse número não é dimensionamento final: é necessário reservar memória para KV cache, buffers, execução e overhead. Quantização deve ser avaliada junto com qualidade e compatibilidade, não tratada como redução gratuita de memória.

3. O que muda no caminho da requisição

Arquitetura agregada

Cliente → gateway autenticado → réplica vLLM → prefill e decode → streaming

Cada réplica executa as duas fases. É uma baseline apropriada para descobrir se o problema está na capacidade da engine, na distribuição de requisições ou no perfil do tráfego. O vLLM pode ser exposto como serviço Kubernetes sem adicionar um framework de desagregação. (docs.vllm.ai)

Roteamento consciente da inferência

Cliente → Gateway → consulta ao EPP → réplica selecionada → streaming

Com llm-d e um gateway compatível, a seleção deixa de depender apenas de um balanceamento genérico. O gateway consulta a camada de decisão e encaminha a requisição ao backend escolhido. No GKE, existe um caminho documentado de integração com GKE Inference Gateway; ele exige compatibilidade entre Gateway, extensões e recursos instalados. (docs.cloud.google.com)

Prefill e decode separados

Requisição → coordenação → pool de prefill → transferência de KV → pool de decode → streaming

Esse é um fluxo lógico: os detalhes de chamadas, sidecars e handshakes variam entre implementações. No llm-d, o caminho de desagregação inclui seleção dos workers e proxy de roteamento. No Dynamo, workers especializados podem formar pools independentes. (llm-d.ai)

A separação permite dimensionar as fases de forma diferente, mas adiciona transporte de KV, coordenação e novos modos de falha. Em baixa concorrência ou com rede inadequada, a arquitetura agregada pode ser mais simples e mais rápida. Desagregar deve ser uma decisão de benchmark, não uma etapa obrigatória de maturidade. (docs.dynamo.nvidia.com)

4. Decisões específicas para Google Cloud

A documentação do Google apresenta uma receita de Dynamo com GKE, vLLM e máquinas A3 Ultra com GPUs H200. Isso demonstra um caminho integrado, não uma garantia de desempenho para qualquer combinação de modelo e infraestrutura. (cloud.google.com)

Para desenhar a plataforma, recomendo:

1. Escolher a topologia antes do YAML: uma réplica cabe em um node ou precisa de múltiplos hosts?
2. Confirmar capacidade regional: quota, disponibilidade zonal e reservas são decisões anteriores ao rollout.
3. Validar a rede do acelerador: famílias diferentes usam caminhos distintos, como GPUDirect-TCPX, TCPXO ou RDMA, de remote direct memory access.
4. Manter uma matriz de versões: GKE, driver, imagem, engine, conectores e controladores devem ser homologados juntos.

Disponibilidade de GPUs varia por zona, e a documentação de rede distingue explicitamente os mecanismos por família de máquina. Não presuma que instalar um conector habilita RDMA em qualquer node. (cloud.google.com)

Como política arquitetural, prefira comunicação intensiva dentro de uma topologia de baixa latência e use réplicas completas em outros domínios de falha. Não distribua shards entre zonas apenas para preencher uma checklist de alta disponibilidade.

5. Exemplo Kubernetes: baseline agregada com modelo de 72B

O manifesto abaixo usa Qwen/Qwen2.5-72B-Instruct, duas réplicas e quatro GPUs A100 de 80 GB por Pod. O modelo possui licença própria: acesso aos pesos não implica ausência de condições de uso. A escolha aqui é ilustrativa, não uma recomendação de modelo para todo produto. (huggingface.co)

Pré-requisitos: GKE Standard com suporte a minDomains, nodes com quatro GPUs disponíveis, drivers funcionando, duas zonas elegíveis, acesso ao repositório do modelo e armazenamento efêmero suficiente. O seletor nvidia-a100-80gb corresponde ao acelerador documentado pelo GKE. (cloud.google.com)

A imagem v0.10.2 é uma referência histórica fixa para a sintaxe documentada, não uma recomendação de release para produção em outubro de 2026. Antes do uso real, selecione uma versão corrigida e homologada, fixe seu digest e a revisão dos pesos. O exemplo combina APIs nativas do Kubernetes com parâmetros documentados do vLLM. (docs.vllm.ai)

apiVersion: v1
kind: Namespace
metadata:
  name: model-serving
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: vllm
  namespace: model-serving
automountServiceAccountToken: false
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-qwen
  namespace: model-serving
spec:
  replicas: 2
  minReadySeconds: 30
  progressDeadlineSeconds: 3600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: vllm-qwen
  template:
    metadata:
      labels:
        app: vllm-qwen
    spec:
      serviceAccountName: vllm
      terminationGracePeriodSeconds: 300
      nodeSelector:
        cloud.google.com/gke-accelerator: nvidia-a100-80gb
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      topologySpreadConstraints:
        - maxSkew: 1
          minDomains: 2
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: vllm-qwen
      containers:
        - name: vllm
          image: vllm/vllm-openai:v0.10.2
          command: ["vllm", "serve"]
          args:
            - Qwen/Qwen2.5-72B-Instruct
            - --host=0.0.0.0
            - --port=8000
            - --served-model-name=qwen-72b
            - --tensor-parallel-size=4
            - --dtype=bfloat16
            - --max-model-len=8192
            - --max-num-seqs=16
            - --gpu-memory-utilization=0.90
            - --enable-prefix-caching
            - --disable-log-requests
          env:
            - name: HF_HOME
              value: /models
          ports:
            - name: http
              containerPort: 8000
          resources:
            requests:
              cpu: "16"
              memory: 128Gi
              ephemeral-storage: 300Gi
              nvidia.com/gpu: "4"
            limits:
              cpu: "32"
              memory: 192Gi
              ephemeral-storage: 350Gi
              nvidia.com/gpu: "4"
          startupProbe:
            httpGet:
              path: /health
              port: http
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 180
          readinessProbe:
            httpGet:
              path: /health
              port: http
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /health
              port: http
            periodSeconds: 20
            timeoutSeconds: 5
            failureThreshold: 6
          volumeMounts:
            - name: model-cache
              mountPath: /models
            - name: shm
              mountPath: /dev/shm
      volumes:
        - name: model-cache
          emptyDir:
            sizeLimit: 275Gi
        - name: shm
          emptyDir:
            medium: Memory
            sizeLimit: 8Gi
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-qwen
  namespace: model-serving
spec:
  type: ClusterIP
  selector:
    app: vllm-qwen
  ports:
    - name: http
      port: 8000
      targetPort: http
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: vllm-qwen
  namespace: model-serving
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: vllm-qwen

Como interpretar a configuração

• tensor-parallel-size=4 divide cada réplica entre quatro GPUs; o total nominal é oito GPUs, não quatro.
• max-model-len limita o contexto total, incluindo entrada e saída. max-num-seqs limita sequências processadas por iteração, não implementa sozinho uma fila HTTP limitada.
• gpu-memory-utilization controla o orçamento utilizado pela engine; não equivale à utilização computacional da GPU. (docs.vllm.ai)

A startup probe permite aproximadamente 30 minutos para inicialização antes de provocar reinicializações. Depois disso, readiness controla a elegibilidade para receber tráfego e liveness detecta falhas persistentes. Ajuste os tempos com medições reais: uma probe agressiva pode transformar lentidão em uma sequência de reinicializações. (kubernetes.io)

O spread exige dois domínios elegíveis para acomodar as duas réplicas. O PodDisruptionBudget limita interrupções voluntárias compatíveis com a API de eviction; não impede falha de zona. O rollout é controlado separadamente por maxUnavailable e maxSurge. (kubernetes.io)

Cuidados para produção: este exemplo ainda não inclui autenticação, TLS, NetworkPolicy, coleta de métricas ou uma imagem endurecida. O ClusterIP não deve ser confundido com uma fronteira de segurança. Homologue execução sem root e o acesso necessário aos dispositivos antes da promoção. (docs.vllm.ai)

O cache emptyDir é descartável; planeje armazenamento de pesos versionados e staging previsível. Os requests elevados exigem capacidade alocável correspondente no node. Além disso, maxSurge: 1 pode exigir quatro GPUs adicionais: sem essa folga, o rollout pode ficar aguardando capacidade. (docs.vllm.ai)

Salve o exemplo como serving.yaml e execute em um ambiente isolado:

kubectl apply -f serving.yaml
kubectl rollout status deployment/vllm-qwen -n model-serving --timeout=3600s
kubectl get pods -n model-serving -o wide
kubectl port-forward -n model-serving service/vllm-qwen 8000:8000

Em outro terminal:

curl --fail-with-body http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen-72b","messages":[{"role":"user","content":"Explain readiness probes."}],"max_tokens":128,"temperature":0}'

Esse teste valida o caminho básico da API. Não valida distribuição entre réplicas, tolerância a falhas ou capacidade sob carga.

6. Quando adicionar llm-d ou Dynamo

Para llm-d, comece pelo caminho documentado de GKE Inference Gateway e pelas receitas compatíveis com a release escolhida. O Inference Quickstart também oferece geração de configurações para a stack llm-d. Revise os manifests gerados antes de incorporá-los ao GitOps. (docs.cloud.google.com)

Para Dynamo, use uma receita que corresponda ao hardware e à versão do backend. Há exemplos com workers vLLM agregados e desagregados; seus requisitos de conectores e inicialização não devem ser inferidos apenas a partir de um Deployment vLLM convencional. (docs.dynamo.nvidia.com)

Minha sequência de avaliação seria:

1. Medir a baseline agregada com cache frio e quente.
2. Testar roteamento consciente de carga e prefixos.
3. Avaliar se o ganho vem de menos recomputação ou apenas de mais capacidade.
4. Introduzir prefill/decode separados quando houver interferência mensurável.
5. Manter a baseline como opção de rollback.

Evite copiar CRDs, ou Custom Resource Definitions, de tutoriais de versões diferentes. Um recurso aceito pelo Kubernetes não comprova que engine, conector e roteador compartilham o mesmo contrato operacional.

7. Cenário corporativo: assistente de documentos

Problema: considere um cenário hipotético de Retrieval-Augmented Generation, ou RAG, em que consultas curtas e análise de documentos extensos compartilham o mesmo endpoint.

Solução proposta: separar classes de serviço e estabelecer limites de tokens, concorrência e tempo de espera. A hipótese a testar é que requisições longas prejudicam a interatividade das curtas.

Implementação: manter uma baseline vLLM, reproduzir tráfego sanitizado e comparar três configurações: agregada, agregada com roteamento especializado e desagregada. Preservar modelo, revisão, perfil de carga e orçamento de aceleradores na comparação.

Resultado esperado, não medido: escolher a configuração que entrega mais requisições dentro dos objetivos de serviço por unidade de custo. Se a arquitetura distribuída não apresentar benefício suficiente, manter a alternativa simples é uma decisão técnica válida.

8. Produção: capacidade, disponibilidade e autoscaling

Recomendo tratar o autoscaling como dois problemas: aumentar workers e obter infraestrutura para executá-los. O Horizontal Pod Autoscaler, ou HPA, pode consumir métricas customizadas quando a infraestrutura de métricas está configurada; aumentar réplicas não garante disponibilidade imediata de GPUs. (kubernetes.io)

Use fila, tokens de entrada, gerações ativas e pressão de cache como candidatos a sinais de escala. Evite depender somente de CPU. Se houver um planner específico da stack, defina quem controla cada recurso para não criar reconciliações concorrentes.

Para serviços críticos, minha checklist inclui:

• Capacidade aquecida para absorver falhas e o tempo de carregamento dos pesos.
• Fila limitada, backpressure e rejeição explícita de sobrecarga.
• Prazo de drenagem alinhado aos maiores streams aceitos.
• Capacidade remanescente suficiente após perder uma réplica ou zona.
• Testes de queda de worker, indisponibilidade de gateway e falha de transporte.

Não presuma retomada transparente de um stream após perder o worker. Defina com a aplicação quando uma nova tentativa é permitida, evitando duplicar ações externas de agentes.

Em desenvolvimento, uma réplica e observabilidade simplificada podem ser suficientes. Em produção, a aprovação deve incluir redundância, limites, isolamento, alertas, capacidade de recuperação e rollback exercitado — não apenas um Pod em estado Running.

9. Observabilidade orientada ao usuário

O vLLM expõe métricas Prometheus em /metrics, incluindo sinais de requisições em execução e aguardando processamento. Os nomes disponíveis variam com a versão: confira o endpoint antes de escrever dashboards. (docs.vllm.ai)

Recomendo organizar a telemetria em quatro grupos:

• Experiência: TTFT, ITL, duração total, erros e cancelamentos.
• Engine: fila, tokens processados, pressão de KV cache e recomputação.
• Infraestrutura: memória de GPU, CPU, memória do container, disco e reinicializações.
• Distribuição: duração da transferência de KV, desequilíbrio entre pools e falhas de comunicação.

Use Prometheus e Grafana, ou serviços equivalentes, para relacionar esses sinais. Instrumente traces da aplicação e do gateway para distinguir tempo de recuperação de documentos, fila e inferência. Evite registrar prompts completos por padrão.

Defina um Service Level Objective, ou SLO, por classe de requisição e alerte sobre sua degradação. GPU ocupada é um sinal de capacidade; não é, isoladamente, prova de experiência adequada.

10. Segurança e governança

No GKE, use Workload Identity Federation for GKE para acesso autorizado a serviços Google Cloud, evitando chaves estáticas de Service Accounts. Diferencie IAM, que governa recursos cloud, de RBAC, que governa permissões na API Kubernetes. (cloud.google.com)

A fronteira de confiança precisa incluir o tráfego interno. A documentação do vLLM alerta que comunicações distribuídas não devem ser consideradas seguras por padrão; portas internas e transferência de KV precisam ficar restritas a redes confiáveis. TLS no gateway não protege automaticamente esse caminho. (docs.vllm.ai)

Como política de plataforma, recomendo:

• TLS e autenticação no ingresso; autorização e quotas por consumidor.
• NetworkPolicy e regras de firewall compatíveis com todas as interfaces utilizadas.
• Secrets com rotação e acesso mínimo, sem credenciais em manifests.
• Imagens verificadas, dependências corrigidas e pesos com integridade validada.
• Política explícita de isolamento de cache entre tenants.
• Criptografia e retenção adequada para pesos, logs e dados persistidos.

Open-weight não significa automaticamente licença permissiva. Registre os termos do modelo e sua revisão no processo de aprovação; no exemplo, a própria model card identifica a licença Qwen. (huggingface.co)

11. FinOps, manutenção e recuperação

Minha recomendação de FinOps é calcular custo por trabalho útil entregue dentro do SLO, incluindo capacidade ociosa, rede, armazenamento, balanceamento e observabilidade. Um teste que maximiza tokens por segundo, mas viola a latência contratada, não comprova eficiência para o produto.

Compare capacidade regular com Spot apenas em cenários cujo tratamento de interrupções tenha sido validado. Para workloads críticos, não baseie toda a disponibilidade em capacidade interrompível. Inclua na projeção o custo da réplica adicional de rollout e o aquecimento de caches após manutenção.

Versione como uma unidade de release: imagem, pesos, tokenizer, template de chat, argumentos e configuração de roteamento. Recomendo canário com carga representativa antes de promover uma atualização.

O rollback de um Deployment restaura seu template anterior, não desfaz automaticamente alterações externas em pesos, CRDs ou outros serviços. Prefira artefatos imutáveis e preserve a configuração anterior completa. (kubernetes.io)

Faça backup dos artefatos e do estado de negócio necessário à recuperação. Não trate KV cache transitório como banco de dados: planeje sua reconstrução e o impacto do cache frio no retorno do serviço.

12. Troubleshooting

Use uma sequência curta de investigação:

kubectl get nodes
kubectl get pods -n model-serving -o wide
kubectl describe deployment vllm-qwen -n model-serving
kubectl describe pod <pod> -n model-serving
kubectl logs <pod> -n model-serving -c vllm
kubectl logs <pod> -n model-serving -c vllm --previous
kubectl get events -n model-serving --sort-by=.metadata.creationTimestamp

Essas são hipóteses de diagnóstico, não associações exclusivas. As referências de Kubernetes, vLLM e Dynamo descrevem requisitos de inicialização, memória e transporte que ajudam a confirmar a causa. (docs.vllm.ai)

13. Quando usar — e quando simplificar

Como critério de decisão, recomendo:

Vertex AI oferece caminhos de deployment para modelos abertos e containers vLLM; a disponibilidade concreta depende do modelo e do modo de implantação. (docs.cloud.google.com)

Não recomendo inferência desagregada apenas porque o modelo é grande. Também evitaria uma plataforma própria complexa quando volume, equipe e requisitos de controle não justificam sua manutenção.

Resumo prático

• Comece com uma baseline reproduzível e uma definição de serviço aceitável.
• Diferencie execução do modelo, seleção de réplicas e placement de infraestrutura.
• Avalie cache e roteamento antes de multiplicar componentes.
• Trate rede e movimentação de KV como parte do caminho crítico.
• Promova somente configurações com segurança, recuperação e custo validados.

Conclusão

A decisão arquitetural mais importante não é adotar o maior número de projetos. É definir qual camada resolve cada gargalo e quais evidências autorizam aumentar a complexidade.

Para DevOps e Platform Engineering, isso significa transformar versões, topologias e políticas em caminhos reproduzíveis. Para SRE, significa operar objetivos de serviço, capacidade e falhas — não apenas containers saudáveis. Uma plataforma madura deve conseguir explicar por que usa llm-d ou Dynamo, demonstrar o benefício e retornar com segurança a uma arquitetura mais simples quando necessário.