Execute um Modelo de Linguagem Grande GGUF Quantizado em um Cluster A2 do Ampere
Arquitetura
Essa arquitetura baseada em arquitetura Arm oferece uma implementação de LLM com valor excepcional, executada a uma fração do custo tradicional de infraestrutura de IA. Use essa arquitetura para uma abordagem econômica para começar a usar a IA.
Um balanceador de carga público do OCI fica na frente, distribuindo o tráfego de entrada para um pool de instâncias de computação. Há um pool de instâncias de nós A2 do Ampere. Cada nó é uma instância de computação baseada em Arm de 2 núcleos que executa o Ubuntu. Os nós são gerenciados em um pool de instâncias do OCI, facilitando a escala horizontal à medida que o tráfego cresce. Um gateway de internet permite o acesso público ao balanceador de carga e às instâncias de backend quando necessário.
Cada instância de computação Ampere A2 executa o Ubuntu 22.04 (Arm), um LLM de Formato Unificado Gerado por GPT (GGUF) quantizado (como TinyLlama ou Phi-2) servido localmente usando llama.cpp, uma página de destino HTML/JS simples servida via NGINX e um backend baseado em Python conectado ao llama-cpp-python que trata os prompts da interface do usuário e da saída do modelo de fluxos de volta à página.
Cada nó de computação no pool foi projetado para ser leve, mas totalmente autossuficiente. Após o lançamento, ele se inicializa usando um script cloud-init que instala e executa tudo o que é necessário para atender a um LLM do zero. Os nós são configurados da seguinte forma:
- Instala Dependências: Dependências como build-essential, cmake, git, NGINX e python3-pip são instaladas automaticamente. llama-cpp-python é compilado a partir da origem para garantir a compatibilidade total com ARM64.
- Builds: Os nós extraem a versão mais recente do llama.cpp do GitHub e o criam usando o OpenBLAS para inferência de CPU otimizada, mantendo tudo local - sem dependência de runtime externo em GPUs ou APIs de inferência.
- Faz Download do Modelo: Um modelo GGUF quantizado (TinyLlama ou similar) é extraído diretamente do Hugging Face e colocado no diretório
models. - Atende uma Página de Destino: Uma UI HTML/JavaScript mínima é fornecida via NGINX na porta 80. A interface do usuário permite que os usuários enviem prompts e exibam respostas do LLM diretamente do navegador.
- Manipula a Inferência via Python: Um pequeno backend Python usa llama-cpp-python para interagir com o modelo local. Ele expõe um ponto final
/generatepara o qual a página de destino envia uma solicitação POST quando um usuário envia uma pergunta. - Inicia na Inicialização: Tudo é encapsulado em um serviço
systemd, portanto, a inferência reinicia automaticamente na reinicialização ou falha da instância - sem necessidade de toque manual.
O diagrama a seguir ilustra essa arquitetura de referência.
gen-ai-ampere-gguf-llm-arch.zip
A arquitetura tem os seguintes componentes:
- Região
Uma região do OCI é uma área geográfica localizada que contém um ou mais data centers, hospedando domínios de disponibilidade. Regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou mesmo continentes).
- Domínios de disponibilidade
Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração ou a rede interna do domínio de disponibilidade. Portanto, uma falha em um domínio de disponibilidade não deve afetar os outros domínios de disponibilidade na região.
- Domínios de falha
Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você distribui recursos entre vários domínios de falha, seus aplicativos podem tolerar falhas físicas no servidor, manutenção do sistema e falhas de energia dentro de um domínio de falha.
- VCN (rede virtual na nuvem) e sub-redes
Uma VCN é uma rede personalizável e definida por software que você configura em uma região da OCI. Assim como as redes tradicionais do data center, as VCNs dão a você controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos de CIDR (Classless Inter-domain Routing) não sobrepostos que você pode alterar após criar a VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.
- Balanceador de carga
O Oracle Cloud Infrastructure Load Balancing fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores.
- Gateway de internet
Um gateway de internet permite o tráfego entre as sub-redes públicas em uma VCN e a internet pública.
- Pool de instâncias
Um pool de instâncias é um grupo de instâncias dentro de uma região que são criadas a partir da mesma configuração de instância e gerenciadas como um grupo.
Considerações
Antes de implementar essa arquitetura, considere o seguinte.
- Custos da instância de computação Ampere A2
Cada nó executa o Ampere A2 com 2 OCPUs e 16 GB de RAM. O preço dessa OCPU é atualmente de US$ 0,01 por OCPU por hora. O custo mensal chega a US$ 14,40 com 1 nó sempre ligado.
- Custos do balanceador de carga
Atualmente, um balanceador de carga público (forma pequena) tem um preço de aproximadamente US$ 0,029 por hora. O custo mensal é de aproximadamente US $ 21. Você pode reduzir ainda mais os custos configurando um balanceador de carga personalizado em outra instância do Ampere.
- Custos de armazenamento
Cada nó armazena o SO, llama.cpp e o modelo, que é de aproximadamente 5 a 6 GB. O volume de inicialização padrão é de aproximadamente 50 GB. Os primeiros 200 GB por mês são gratuitos.