Nutanix Enterprise AI no NKPParte 4: CPU, GPU e MCP numa arquitetura híbrida

Resumo: na Parte 3 o NAI respondeu o primeiro token em CPU. Agora ele deixa de ser uma ilha. Coloco o mesmo cliente OpenAI chamando o endpoint em CPU do NAI e um modelo de 30B numa GPU GB10, só trocando o model. Ganho +40% de tokens/s em CPU com uma variável de ambiente. Levo as métricas do vLLM para o Grafana do NKP. Ligo o Agentic Gateway do NAI: unified endpoint, rate limit por tokens e MCP, validados de ponta a ponta com dois ajustes de configuração que mostro passo a passo. E protejo o NAI com Velero (cópia no Backblaze B2) e NDK (snapshot local), com restauração testada nos dois. Esta é a parte 4 de 4.

Onde estamos

O ponto de partida: o NAI 2.8.1 num cluster NKP dedicado, um endpoint qwen3-06b-cpu (Qwen3 0,6B no vLLM, 8 vCPU) e, no mesmo lab, um ASUS Ascent GX10 (chip NVIDIA GB10, a plataforma do DGX Spark) servindo o Nemotron 30B por NIM atrás de um LiteLLM, que as aplicações do NKP já usavam.

O roteiro em uma tabela

1. A mesma API para CPU e GPU

O desenho é simples: o LiteLLM que já atendia as aplicações vira o ponto único. Cada aplicação tem uma chave do LiteLLM; o LiteLLM tem uma API key do NAI só para ele.

O que mudou no GX10

Três coisas, com backup e rollback:

1. Uma API key nova no NAI (litellm-gx10), só para o endpoint em CPU. A chave de teste continua separada.
2. O LiteLLM aprendeu a confiar na CA interna. O container usa o certifi do Python, que não conhece a CA do lab. Montei um bundle (as CAs do certifi + a CA interna) e apontei SSL_CERT_FILE e REQUESTS_CA_BUNDLE para ele. Enquanto o nome do NAI não está no DNS, um extra_hosts resolve.
3. Um modelo novo no config.yaml:

  - model_name: qwen3-cpu-nai
    litellm_params:
      model: openai/qwen3-06b-cpu
      api_base: https://nai.lab.exemplo.local/enterpriseai/v1
      api_key: os.environ/NAI_API_KEY
      extra_body:
        chat_template_kwargs:
          enable_thinking: false

O provider openai/ funciona porque a API do NAI é compatível com a da OpenAI. Só o container do LiteLLM foi recriado, e voltou em 11 segundos; o NIM nem percebeu.

O teste: o mesmo código, dois mundos

Um script Python com o SDK oficial da OpenAI, rodando num pod do cluster de aplicações do NKP. A única diferença entre as chamadas é o model:

client = OpenAI(base_url="https://gx10-llm.ai-gateway.svc/v1", api_key=os.environ["API_KEY"])
for model in ["nemotron-lightning", "qwen3-cpu-nai"]:
    stream = client.chat.completions.create(model=model, stream=True, ...)

A GPU é 13× mais rápida com um modelo 50× maior. Ninguém vai usar o 0,6B em CPU para conversa; o ponto é outro: o código da aplicação não muda, e o log de uso do LiteLLM registra as chamadas dos dois backends no mesmo lugar.

2. +40% em CPU com uma variável

Na Parte 3 o endpoint em CPU entregava 4,5 tokens/s e a explicação era o estrangulamento de CPU: o container enxerga os 12 núcleos do nó, o vLLM abre 11 threads OpenMP, mas o limite do pod é de 8 vCPU. O painel do Grafana (seção 3) mostrou o tamanho do efeito: 60% a 77% dos períodos estrangulados durante a geração.

O ajuste é a variável VLLM_CPU_OMP_THREADS_BIND=0-7, que prende as threads do vLLM em 8 núcleos. No NAI 2.8.1, a configuração avançada do endpoint oferece Engine Arguments e KV Cache Aware Routing; uma variável de ambiente como essa vai no InferenceService:

Apliquei a variável direto no InferenceService do KServe. Esse caminho fica fora da interface do NAI (em ambiente de produção, aja com cautela); no lab, o NAI manteve a mudança. O rollout pediu um ajuste: o predictor usa RollingUpdate, que sobe o pod novo antes de derrubar o antigo, e o nó de inferência do meu lab (12 vCPU) não comporta dois pods de 8 vCPU.

+40% de tokens/s e 30% menos tempo total, sem mudar vCPU, memória nem modelo.

3. As métricas do vLLM no Grafana do NKP

O NAI mostra requisições e tokens por endpoint. Para ver também latência e uso de CPU do pod, o vLLM expõe tudo isso em /metrics na porta 8000 do predictor; basta apontar o Prometheus do NKP para lá. Ele só coleta monitores com o rótulo do Kommander:

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: nai-vllm
  namespace: nai-admin
  labels:
    prometheus.kommander.d2iq.io/select: "true"
spec:
  selector:
    matchLabels:
      endpoint.iep.nai.nutanix.com/engine: vllm
  podMetricsEndpoints:
    - portNumber: 8000
      path: /metrics
      interval: 15s

Em 10 segundos o alvo estava up e o Prometheus tinha 349 séries vllm:*. O painel vai por um ConfigMap com grafana_dashboard: "1", que o sidecar do Grafana do NKP carrega sozinho:

O painel que justificou a seção 2 é o de CPU do predictor e estrangulamento (CFS): durante a geração, o pod usava 5,5–6,3 vCPU e passava 60–77% dos períodos estrangulado.

4. O Agentic Gateway

O NAI 2.8 trouxe o Agentic Gateway: unified endpoints (um nome só na frente de vários modelos, com balanceamento ou fallback), providers externos, rate limit por tokens e MCP. Por baixo está o Envoy AI Gateway. A licença do meu lab não inclui o Agentic Gateway (Parte 3), mas o menu já está na console, e usei o lab para conhecer o recurso a fundo.

O desenho acima resume o que testei: chat e MCP entram pela mesma porta, e o gateway faz três coisas em sequência antes de chegar ao modelo ou ao MCP server. Ele é adaptado do fluxo do Agent Gateway que a Nutanix apresentou no lançamento do NAI 2.7.

Unified endpoint

Criei o unified-endpoint-pr, tipo Chat, com o endpoint local em CPU como modelo e a API key de teste:

A interface gerou um AIGatewayRoute do Envoy AI Gateway que casa o cabeçalho x-ai-eg-model: unified-endpoint-pr, troca o nome do modelo pelo do endpoint real e contabiliza tokens de entrada, saída e total. O caminho é /enterpriseai/gateway/v1/chat/completions; o /enterpriseai/v1, dos endpoints locais, devolve 404 para o nome do unified endpoint.

No lab, reduzi os requests (não os limites) no GatewayConfig e no EnvoyProxy do NAI. O pod novo subiu em 67 segundos, o antigo saiu sozinho, e o unified endpoint respondeu 200 em 5,4 s. Em produção, o caminho recomendado é dimensionar os nós do gateway para os valores padrão. São cerca de 5 vCPU e 10 GiB por réplica que entram na conta antes de qualquer modelo.

Rate limit por tokens

O rate limit é por tokens, não por requisições: global para o endpoint e, opcionalmente, por API key (ou por valor de um cabeçalho, quando várias aplicações dividem a chave).

Por baixo vira uma BackendTrafficPolicy do Envoy com duas regras. A de cliente identifica a chave pelo cabeçalho X-Nutanix-Api-Key-Id, que o próprio NAI injeta depois de autenticar, e o custo de cada requisição é o total de tokens da resposta. A rajada de teste, com 300 tokens/min para a chave:

O contador desconta os tokens reais de cada resposta, e a 11ª chamada é barrada no gateway, em 13 ms, sem chegar ao modelo.

MCP: servers, connectors e controle de tools

A parte de MCP tem três peças:

• MCP Servers: locais (o NAI sobe a partir de uma imagem Docker) ou remotos (uma URL).
• MCP Connectors: juntam um ou mais servers e escolhem quais tools cada um expõe.
• MCP Client Keys: um tipo de chave próprio, separado das API keys de chat.

Usei um MCP server remoto público, o Context7 (documentação de bibliotecas). O connector descobriu as duas tools; liberar as duas exige digitar “confirm”:

O connector vira uma MCPRoute em /enterpriseai/gateway/mcp/<connector>, com um toolSelector listando as tools liberadas. É assim que o “Tool Control” da interface vira configuração.

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: Backend
metadata:
  name: mcp-context7
  namespace: nai-admin-extensions
spec:
  type: Endpoints
  endpoints:
    - fqdn: { hostname: mcp.context7.com, port: 443 }
  tls:
    sni: mcp.context7.com
    wellKnownCACertificates: System
    ecdhCurves: [X25519, P-256, P-384, P-521]

Com isso, o MCP pelo Agentic Gateway funcionou de ponta a ponta:

O prefixo é o que permite juntar vários servers num connector sem conflito de nomes.

5. Protegendo o NAI: Velero e NDK

O NAI guarda estado em quatro volumes RWO no nai-system (o banco PostgreSQL, o ClickHouse, o keeper e o Valkey) e os modelos em volumes RWX do Files. O banco roda em uma instância, então inclua esses volumes na sua rotina de backup. Usei as duas ferramentas do catálogo do NKP, com papéis diferentes.

Velero com cópia fora do lab (Backblaze B2)

O Velero do NKP 2.19 é o 1.18, com plugin AWS, data mover (Kopia) e node-agent. O destino foi um bucket no Backblaze B2, compatível com S3 e fora do lab. Duas notas para o B2: checksumAlgorithm: "" no backup storage location (o plugin novo manda um checksum que o B2 pode recusar) e o ciclo de vida do bucket em “manter só a última versão”, senão os backups apagados viram versões ocultas e o espaço só cresce.

Ao habilitar o Velero, a console avisa que falta o Rook Ceph Cluster:

Outros dois detalhes do Velero no NKP:

• O pre-install espera o Ceph por 5 minutos. Com destino externo, o Velero sobe sozinho depois disso; não é erro.
• Depois de editar um override na console, confira a revisão do Helm. No meu teste, mudei o agendamento e o release continuou na revisão 1; conferir se o release subiu de revisão garante que a mudança chegou ao cluster.

No primeiro backup completo, o limite foi o link de saída do lab para o B2 (0,2–0,3 MB/s): o modelo de 1,5 GB levaria horas. Decisão: modelos fora do backup (voltam do Hugging Face em um minuto), com uma resourcePolicy que pula a storage class do Files:

version: v1
volumePolicies:
  - conditions:
      storageClass: [nai-nfs]
    action:
      type: skip

Resultado: 510 objetos e 4 volumes em 776 s, 0 erros. Os ~710 MB dos volumes viraram ~313 MB no bucket (o Kopia comprime e deduplica):

NDK: snapshot local em segundos

O Nutanix Data Services for Kubernetes 2.3 protege a aplicação com snapshots do próprio storage Nutanix. A instalação pede uma credencial de Docker Hub própria do NDK (o portal Nutanix gera um token), passada no override:

O NDK é leve: 35m de CPU e 256 MiB de requests. Depois do Enable, três passos:

1. StorageCluster: liga o NDK ao Prism Central e ao cluster AOS, pelos UUIDs dos dois. Peguei-os pela API v3 do Prism com a credencial que o CSI já tinha.
2. Application: o namespace nai-system inteiro. O NDK pede um seletor explícito, e o seletor por namespace faz parte de um recurso que vem desligado por padrão (a mensagem é “multi namespace feature not enabled”). A forma simples de pegar o namespace inteiro é selecionar tudo que não tem um rótulo inexistente:

apiVersion: dataservices.nutanix.com/v1alpha1
kind: Application
metadata:
  name: nai-system
  namespace: nai-system
spec:
  applicationSelector:
    resourceLabelSelectors:
      - labelSelector:
          matchExpressions:
            - { key: lab.exemplo.local/excluir, operator: DoesNotExist }

3. ApplicationSnapshot: pronto em 41 segundos, crash-consistent, com os deployments, statefulsets, secrets, configmaps e PVCs do NAI.

Não restaurei o NAI inteiro em outro namespace: subiria uma segunda cópia de 18 workloads num cluster de lab sem folga. Testei o mesmo mecanismo com uma aplicação pequena (1 volume com 50 MB aleatórios): snapshot em 37 s, restore em 21 s, hash idêntico. Para restaurar em outro namespace, o NDK exige um ReferenceGrant no namespace de origem.

Velero ou NDK? Os dois

Os números

O que aprendi

1. Um gateway na frente libera a aplicação da escolha do hardware. CPU para o barato, GPU para o pesado, o mesmo código.
2. Em CPU, prenda as threads do vLLM ao limite do pod. Foram 40% de graça. E use Recreate em endpoints maiores que meio nó.
3. Meça do lado do servidor. O PodMonitor do vLLM e o painel de estrangulamento mostraram o que nenhum número do cliente explicava.
4. Reserve ~5 vCPU e ~10 GiB por réplica do Agentic Gateway antes de qualquer modelo. E confira se o pod novo do proxy está Running antes do primeiro teste do unified endpoint.
5. Rate limit por tokens funciona como esperado, cobrando os tokens reais da resposta.
6. Valide o MCP server remoto antes de criar o connector: a curva do certificado e a sessão MCP são os dois pontos a conferir.
7. Velero e NDK não competem. Um tira a cópia do site; o outro volta em segundos.
8. Restaurar volume com data mover exige um pod consumidor quando a storage class é WaitForFirstConsumer.

Checklist: NAI híbrido e protegido

• API key dedicada no NAI para o gateway de LLM, separada da de teste
• CA interna no bundle de CAs do gateway (SSL_CERT_FILE)
• Chaves do gateway liberadas por modelo, por aplicação
• VLLM_CPU_OMP_THREADS_BIND no endpoint em CPU e deploymentStrategy: Recreate
• Chamada de aquecimento depois de qualquer restart do endpoint
• PodMonitor do vLLM com prometheus.kommander.d2iq.io/select: "true" e painel no Grafana
• Folga de ~5 vCPU e ~10 GiB por réplica do gateway antes de criar o primeiro unified endpoint
• API keys associadas a cada unified endpoint; MCP client keys separadas
• MCP server remoto testado (curva do certificado, sessão) antes de virar connector
• Velero com destino externo (sem Rook Ceph); resourcePolicy para os modelos
• Ciclo de vida do bucket em “última versão”
• Revisão do Helm conferida depois de cada Edit de override
• NDK com StorageCluster, Application do nai-system e ProtectionPlan
• Restore testado nos dois

O que ainda não testei

• GPU dentro do próprio NKP. Nesta parte, a GPU entra pelo GX10, atrás do LiteLLM; um endpoint em GPU servido pelo NAI no NKP é o próximo passo do lab.
• Providers externos no Agentic Gateway. No lab, o unified endpoint roteou para o endpoint local em CPU e o MCP para o Context7; providers externos ficaram fora deste teste.
• O restore do NAI inteiro com o NDK em outro namespace. Subiria uma segunda cópia de 18 workloads num cluster de lab sem folga; testei o mesmo mecanismo com uma aplicação pequena.

Referências

Nutanix

• Nutanix Enterprise AI Guide 2.8.1 (portal Nutanix): endpoints, API keys, Agentic Gateway (unified endpoints, MCP servers e connectors, rate limit)
• Nutanix Data Services for Kubernetes 2.3 (portal Nutanix)

Projetos e comunidade

• Envoy AI Gateway: documentação
• Envoy Gateway: Backend e configurações de TLS
• LiteLLM: providers compatíveis com OpenAI
• vLLM: instalação e variáveis para CPU
• KServe: InferenceService
• Velero: data movement e resource policies
• Model Context Protocol: especificação