Nutanix Enterprise AI no NKPParte 1: arquitetura, licenças e dimensionamento

Resumo: o Nutanix Enterprise AI (NAI) transforma um cluster Kubernetes numa plataforma de inferência com API compatível com a OpenAI, chaves por aplicação, catálogo de modelos e auditoria. Antes de instalar, li o User Guide 2.8.1 e os dois Nutanix Validated Designs que tratam dele. Cinco pontos definiram o meu plano: a licença é separada do NKP, com trial de 2 dias (a chave entra no dia da instalação); o guia cita a NKP 2.18, e o catálogo da 2.19 já traz o NAI 2.8.1; o plano de controle pede 30 vCPU e 60 GB além da inferência; os NVDs põem o NAI num cluster dedicado; e sem GPU, o lab roda a inferência em CPU sem AMX. Esta é a parte 1 de 4.

A série

Parte	Tema
1	NAI: arquitetura, licenças e dimensionamento (este post)
2	Nutanix Files para o Kubernetes: o RWX que o NAI exige
3	Do catálogo ao primeiro token: cluster dedicado, NAI 2.8.1 e licença
4	CPU, GPU e MCP: o NAI numa arquitetura híbrida

O lab: um cluster HCI Nutanix de 3 hosts, Prism Central e AOS 7.6, NKP 2.19 com um cluster de management e um de serviços. Nenhuma GPU nos hosts. Esta parte é a leitura e o planejamento; não tem nada instalado ainda. É a parte que eu gostaria de ter lido antes de abrir um projeto de NAI num cliente.

---

O que é o Nutanix Enterprise AI

O NAI é uma plataforma da Nutanix para servir modelos de IA dentro do Kubernetes, com governança. Na prática, ele entrega:

Recurso	O que é
Endpoints locais	Um modelo do Hugging Face ou um NIM da NVIDIA publicado como API compatível com a OpenAI, rodando em GPU ou CPU
Catálogo de modelos validados	Modelos testados pela Nutanix, com CPU, memória e parâmetros do vLLM preenchidos automaticamente
Chaves de API	Uma chave por aplicação, com ativação, desativação e auditoria
Unified Endpoints	Um endpoint único que distribui entre modelos locais e provedores externos (OpenAI, Anthropic, Bedrock, Azure OpenAI, Vertex, Gemini, Mistral, Cohere ou outro NAI), com limite de taxa
MCP Servers	Servidores MCP locais ou remotos para agentes, com credenciais e chaves de cliente
NAI Labs	Aplicações de exemplo: Chat, Talk to My Data e um agente
Governança	IAM com LDAP, SAML e políticas, eventos de auditoria, security scan de modelos, métricas de uso

A versão atual é a 2.8.1, e ela já aparece no catálogo do NKP 2.19, na aba AI Applications:

Como as peças se encaixam

Camada	Componentes	O que faz
Entrada	Envoy Gateway (com Gateway API)	Recebe as chamadas HTTPS, valida a chave, aplica limites
Plano de controle	nai-api, UI, IAM, PostgreSQL, ClickHouse, Valkey, OpenTelemetry	Catálogo, chaves, usuários, métricas e auditoria
Inferência	KServe, LeaderWorkerSet, vLLM ou NIM	Sobe cada modelo como um serviço, em uma ou várias réplicas
Dados	Volume RWX (Files) e volumes RWO	Pesos dos modelos e dados da plataforma

---

Licenciamento: separado do NKP, com trial de 2 dias

As edições

Edição	O que inclui
NAI Standalone (Pro)	Só o NAI, em qualquer Kubernetes CNCF: NKP, EKS, AKS, GKE
NAI-NKP (Pro ou Ultimate)	NAI + NKP no mesmo pacote
NAI Full-Stack / GPT-in-a-Box (Pro ou Ultimate)	NAI + NCI + NKP + Unified Storage (+ NDK e NDB)

A métrica

O NAI tem três licenças, e você aplica a que corresponde ao seu uso:

Licença	Métrica	Quando usar
CPU	vCPUs usados pelos endpoints de inferência	Cluster sem GPU (o caso do lab)
GPU	GB de memória de GPU, somando todas as GPUs	Cluster com GPU
Agent Gateway	Chaves de acesso ativas em Unified Endpoints e MCP	Só o gateway, sem inferência local

Um detalhe que facilita a vida: a licença CPU conta o que os endpoints usam, não o tamanho dos nós. O plano de controle do NAI não entra na conta.

O relógio

Regra	O que diz o User Guide 2.8.1
Trial	2 dias depois da instalação
Licença POC	30 dias (pedido à Nutanix)
Depois de vencer	30 dias de carência; depois, os endpoints hibernam
Quando aplicar CPU ou GPU	Só na primeira instalação, não num upgrade
Troca	CPU → GPU sem pré-requisito; para Agent Gateway, hibernar os endpoints antes

No lab, o licenciamento está assim:

Licença	Situação no lab
NKP Ultimate	400 vCPU aplicados
NAI Pro	600 disponíveis, ainda não aplicada (entra na Parte 3)
NUS Pro	50 TiB + 1 TiB incluído no NCI Ultimate (usada na Parte 2)
NDK	Incluído no NKP Ultimate, sem limite
Flow Network Security	Incluído no NCI Ultimate (aparece como NCI Security)

---

O que o User Guide 2.8.1 exige

Plataforma

Requisito	O que diz o guia	No lab
Kubernetes	Versão 1.35	1.36.2
NKP	“Você pode instalar o NAI 2.8.1 só na NKP 2.18”	NKP 2.19
Imagem dos nós	Ubuntu	Rocky Linux 9.8
Outras plataformas	EKS, AKS e GKE; air-gapped só no NKP	—
Arquitetura	Só x86	x86 (os hosts Nutanix)
GPU	NVIDIA, com GPU Operator e taint nvidia.com/gpu:NoSchedule	Nenhuma

A arquitetura x86 tem uma consequência no lab: o servidor com GPU NVIDIA GB10 que temos é ARM, e não pode ser nó do NAI. Ele entra na Parte 4 por outro caminho.

Rede, DNS e certificado

Requisito	Detalhe
LoadBalancer	IP externo para o Envoy (no NKP, MetalLB)
FQDN	Um nome DNS que resolva para esse IP
Certificado	Assinado por CA; o NAI só aceita HTTPS. Para teste, existe a opção de certificado autoassinado via cert-manager

Storage

Item	Mínimo	Para quê
Block (RWO)	150 GiB	PostgreSQL (40), ClickHouse (50 + 10), NAI Labs (20), nai-api (20), Valkey (8), auditoria (1)
NFS (RWX)	2 TiB, storage class com Immediate	Modelos
Export NFSv4	Um share	Importar modelos custom
S3	1 TiB (opcional)	Outra forma de importar modelos

O NKP vem só com storage RWO. O RWX é o assunto inteiro da Parte 2.

Dependências

O guia instala por Helm; o catálogo do NKP 2.19 já traz quase tudo:

Componente	Versão no guia	No catálogo do NKP 2.19
Envoy Gateway + Gateway API	1.8.1	NAI Envoy Gateway 1.8.2
KServe	0.19.0 (modo RawDeployment)	0.19.0
LeaderWorkerSet	0.8.0	0.8.0
OpenTelemetry Operator	0.114.1	0.114.1 (categoria Observability)
CloudNativePG	app do NKP	app do NKP
Prometheus Monitoring	app do NKP, instalação mínima	já existe
cert-manager	vem com o NKP	já existe
NVIDIA GPU Operator	só com GPU	não se aplica

Também é preciso um token de acesso do Docker Hub gerado no portal da Nutanix, para baixar as imagens do NAI.

---

Dimensionamento: o plano de controle vem primeiro

O mínimo do guia

O guia assume um cluster dedicado ao NAI e conta só o plano de controle; a inferência é somada à parte.

Nós	Qtde	vCPU	Memória	Disco
Control plane do Kubernetes	3	4	16 GB	150 GB
Workers do NAI	3	10	20 GB	150 GB
Total	6	42	108 GB	—

Os componentes que mais pesam:

Componente	vCPU	Memória
nai-api	5,1	7,1 GiB
Envoy (gateway de entrada)	5,1	10,3 GiB
ClickHouse (observabilidade)	4	8 GiB
OpenTelemetry Collector	4	2 GiB
UI	2	2 GiB
PostgreSQL	2	2 GiB

Perfis

Perfil	Capacidade	Workers
Default	300 requisições simultâneas, 100 chaves	3 × 10 vCPU / 20 GB
c1k_k200	1.000 requisições, 200 chaves	3 × 60 vCPU / 90 GB
c5k_k1k	5.000 requisições, 1.000 chaves	3 × 90 vCPU / 150 GB

A inferência, por cima

Referência do guia para um endpoint de 1 GPU:

Motor	CPU	Memória
NVIDIA NIM	12 cores	32 GiB
vLLM	8 cores	16 GiB (1 GPU) a 128 GiB (8 GPUs)

---

E sem GPU?

O NAI aceita endpoints em CPU: na criação do endpoint, Acceleration Type → CPU, que aparece para os modelos que suportam execução em CPU. Com Xeon de 4ª geração ou mais novo, existe a opção Optimise endpoint to run on Intel AMX, que usa a aceleração de matrizes do processador.

O host do lab:

Item	Valor	Impacto
CPU	2 × Xeon Silver 4210 (Cascade Lake, 2ª geração), 2,2 GHz, 20 cores por host	Sem AMX; tem AVX-512 e VNNI. Inferência em CPU funciona, com desempenho de lab
Memória	376 GiB por host, 3 hosts	O limite real do lab
Storage	Híbrido: 2 HDD + 1 SSD por host	Carga de modelos mais lenta quando o dado cai no HDD

Candidatos do catálogo validado para CPU, pelo tamanho:

Modelo	Tipo	Tamanho
ibm-granite/granite-embedding-107m-multilingual	Embeddings, 12 idiomas	~2 GiB
cross-encoder/ms-marco-MiniLM-L6-v2	Reranker	~4 GiB
google/gemma-3-270m-it	Texto	~10 GiB
meta-llama/Llama-3.2-1B-Instruct	Texto (gated no Hugging Face)	~10 GiB

Quais deles aparecem com a opção CPU, só a interface vai dizer.

---

O que dizem os Nutanix Validated Designs

Li dois: o NVD-2057 (Nutanix Enterprise AI Design, agosto de 2026) e o NVD-2115 (GPT-in-a-Box com NKP, janeiro de 2026).

Versões validadas × lab

Componente	NVD-2057	NVD-2115	Lab
Prism Central / AOS	7.5.1.6	2024.3.0.1 / 7.0	7.6 / 7.6
NKP	2.18.0	2.14	2.19
NAI	2.7	2.0	2.8.1
Files	5.2.2.1	5.1	5.4.0.1

O lab está à frente de tudo o que foi validado. O próprio NVD-2057 diz que é um exemplo de configuração suportada, não a única.

Os padrões que valem para qualquer cliente

Tema	O que o NVD faz
Cluster do NAI	Dedicado, num workspace próprio. No NVD-2057, um nai-prod e um nai-stage
Plano de controle	Nós só de CPU, em VM, no cluster de gestão; GPUs em bare metal Ubuntu 24.04
Pool de workers do NAI	NVD-2115: 12 vCPU / 40 GB / 100 GB
Banco de dados	PostgreSQL externo, via NDB, um por instância de NAI
Certificados	CA privada emitindo pelo cert-manager, validade de 1 ano
Workspaces	gateway, prod, stage, qa e dev; NAI Labs só em qa e dev
Alta disponibilidade	2 réplicas de nai-api e do Envoy em gateway, prod e stage
Observabilidade	Stack central, ServiceMonitor do vLLM e dashboards do Envoy
Backup	Velero para o Nutanix Objects, com replicação

Token as a Service

O NVD-2057 descreve o NAI como uma plataforma de tokens: uma API única compatível com a OpenAI, com cotas de tokens por camada (Free, Standard, Enterprise, Premium), que os times consomem sem ver GPU nenhuma. Na frente de tudo, o Agent Gateway distribui o tráfego entre produção e homologação:

Modelo	Papel	Produção : homologação
openai/gpt-oss-120b (MoE)	Arquiteto: planeja	75 : 25
google/gemma-4-26B-A4B-it (MoE)	Desenvolvedor: escreve o código	75 : 25
google/gemma-4-31B-it (denso)	Revisor: confere	90 : 10
Embeddings, reranker, Llama Guard	Apoio ao RAG e segurança	50 : 50

O desenho validado: 16 nós com 128 GPUs RTX PRO 6000 Blackwell, para cerca de 1.750 usuários simultâneos. Os modelos pequenos rodam em fatias MIG 1g.24gb (4 por GPU); os grandes, em GPUs inteiras.

KV cache: o que limita os usuários

Cada sessão ativa reserva memória de GPU para o KV cache. O NVD usa estes números:

Perfil de uso	Contexto	KV cache por sessão
Chat e assistente de código	8K tokens	~0,6 GB
RAG e extração estruturada	17K tokens	~1,5 GB
Sumarização, pesquisa, agentes	106K tokens	~8 GB

É a conta que define quantos usuários cabem numa réplica, e é a primeira pergunta para dimensionar GPU num cliente.

---

A decisão do lab: cluster dedicado

Com o guia e os NVDs na mão, comparei duas opções. O limite é a memória: com 3 hosts de 376 GiB, quero que tudo continue rodando se um host cair (N+1), o que dá cerca de 752 GiB utilizáveis. O lab já usa ~591 GiB, contando o Files da Parte 2.

	A: node pool no cluster de serviços	B: cluster dedicado
Formato	+3 workers de 12 vCPU / 40 GiB	1 control plane 4/16 + 3 workers 12/40, workspace próprio
Memória adicionada	120 GiB	136 GiB
Total previsto	~711 GiB (94,5% do N+1)	~727 GiB (96,7% do N+1)
Segue os NVDs	Não	Sim
Nós Ubuntu	Não (cluster existente em Rocky)	Possível, se a 2.19 oferecer a imagem
Isolamento	Divide o cluster com outros serviços	Pode ser apagado sem afetar nada

Escolhi a B. Custa 16 GiB a mais, segue o desenho da Nutanix, isola o experimento e permite usar a imagem Ubuntu que o guia pede. A contrapartida: um control plane só (aceitável em lab) e quase nenhuma margem de memória enquanto o NAI estiver no ar.

---

O que aprendi

1. O NAI é uma licença à parte, separada do NKP Ultimate; a métrica é vCPU de inferência (CPU) ou GB de memória de GPU.
2. O trial é de 2 dias, e a licença CPU ou GPU só entra na primeira instalação. A chave sai do portal no mesmo dia.
3. O guia 2.8.1 cita a NKP 2.18. Na 2.19, o caminho é o app do catálogo, compatível com >=2.18 <2.20 pela anotação do próprio app.
4. O plano de controle pede 30 vCPU e 60 GB em 3 workers, antes de qualquer modelo.
5. O NAI precisa de RWX. A storage class padrão do NKP é RWO; o RWX vem do Nutanix Files (Parte 2).
6. FQDN e certificado de CA são obrigatórios. Sem DNS interno, isso vira pré-requisito de projeto.
7. Os NVDs põem o NAI em cluster dedicado, com o plano de controle em VMs e as GPUs em bare metal.
8. Sem GPU, o NAI serve para governança, embeddings e modelos pequenos. Com AMX, o desempenho em CPU melhora; o hardware do meu lab não tem.

Checklist de pré-venda

• Edição definida: Standalone, NAI-NKP ou Full-Stack
• Métrica estimada: vCPU de inferência ou GB de GPU
• Versão do NKP conferida na anotação nkp-version-support do app do NAI e na matriz de compatibilidade
• Cluster dedicado dimensionado: plano de controle (30 vCPU / 60 GB) + inferência
• GPU: modelo, quantidade, MIG ou GPU inteira; ou CPU com AMX
• KV cache estimado pelo perfil de uso (chat, RAG ou agentes)
• Storage: RWO 150 GiB, RWX 2 TiB (Files), export para modelos custom, S3 opcional
• Rede: IP de LoadBalancer, FQDN e certificado de CA
• Token do Docker Hub e conta no Hugging Face (modelos gated)
• Chave da licença gerada no mesmo dia da instalação

O que ainda não testei

• Endpoints em GPU no NAI. Os hosts do lab não têm GPU, e o servidor com GPU GB10 é ARM, enquanto o NAI pede x86; ele entra na Parte 4 por outro caminho. A GPU dentro do próprio NKP é o próximo passo do lab.
• A opção de endpoint otimizado para Intel AMX. Ela pede Xeon de 4ª geração ou mais novo, e os hosts do lab são Cascade Lake (2ª geração).
• O cluster do NAI com 3 control planes, como na tabela do guia. No lab, o cluster dedicado tem um control plane só, o que basta para um lab.

Referências

Nutanix

• Nutanix Validated Design: Nutanix Enterprise AI (NVD-2057)
• Nutanix Cloud Platform: opções de software e licenciamento
• Nutanix Enterprise AI: FAQ
• Nutanix Enterprise AI Guide 2.8 (portal Nutanix), seções de requisitos, licenciamento e deploy no NKP
• NVD-2115: Nutanix GPT-in-a-Box com Nutanix Kubernetes Platform Design (portal Nutanix)

Independentes

• Nutanix Enterprise AI 2.8 e NKP 2.19 (StorageReview)