Eseguire un modello di lingua grande GGUF quantizzato su un cluster Ampere A2

C'è un divario crescente nell'AI regionale causato dalla mancanza di infrastruttura computazionale. La maggior parte dei moderni modelli linguistici di grandi dimensioni (LLM, large language model) richiedono un numero significativo di GPU specializzate e ad alte prestazioni per addestrarsi in modo efficace. Poiché ogni server ha potenzialmente un prezzo a sei cifre e le supply chain globali sono sotto pressione, queste risorse essenziali rimangono inaccessibili a molti. Durante l'esplorazione di soluzioni per il crescente divario tra AI, è emersa un'alternativa promettente al collo di bottiglia della GPU, il notevole processore Ampere A2. Incuriositi dal potenziale, abbiamo progettato un'implementazione LLM costruita interamente su cluster Ampere A2. I risultati sono stati notevoli. Pur non abbinando la potenza grezza di array GPU all'avanguardia, questi sistemi possono alimentare con successo applicazioni pratiche di retrieval-augmented generation (RAG) per pochi centesimi all'ora di funzionamento.

Architettura

Questa architettura basata su Arm offre un'implementazione LLM a valore eccezionale, eseguita a una frazione del costo dell'infrastruttura AI tradizionale. Utilizza questa architettura per un approccio a misura di budget per iniziare a usare l'intelligenza artificiale.

Un load balancer pubblico OCI si trova in primo piano, distribuendo il traffico in entrata a un pool di istanze di computazione. Esiste un pool di istanze di nodi Ampere A2. Ogni nodo è un'istanza di computazione basata su 2 core e Arm che esegue Ubuntu. I nodi vengono gestiti in un pool di istanze OCI, semplificando la scalabilità orizzontale man mano che il traffico cresce. Un gateway Internet consente l'accesso pubblico sia al load balancer che alle istanze backend, quando necessario.

Ogni istanza di computazione Ampere A2 esegue Ubuntu 22.04 (Arm), un LLM GGUF (Global Generated Unified Format) quantificato (come TinyLlama o Phi-2) servito localmente utilizzando llama.cpp, una semplice pagina di destinazione HTML/JS servita tramite NGINX e un backend basato su Python cablato in llama-cpp-python che gestisce i prompt dall'interfaccia utente e restituisce l'output del modello alla pagina.

Ogni nodo di calcolo nel pool è progettato per essere leggero ma completamente autosufficiente. Al momento del lancio, si avvia da solo utilizzando uno script di inizializzazione cloud che installa ed esegue tutto il necessario per servire un LLM da zero. I nodi sono configurati come indicato di seguito.

  • Dipendenze dell'istanza: dipendenze quali build-essential, cmake, git, NGINX e python3-pip vengono installate automaticamente. llama-cpp-python viene compilato dall'origine per garantire la compatibilità completa con ARM64.
  • Build: i nodi estraggono la versione più recente di llama.cpp da GitHub e la creano utilizzando OpenBLAS per un'inferenza CPU ottimizzata, mantenendo tutto locale, senza dipendenza di runtime esterna dalle GPU o dalle API di inferenza.
  • Scarica il modello: un modello GGUF quantizzato (TinyLlama o simile) viene recuperato direttamente da Hugging Face e posizionato nella directory models.
  • Servire una pagina di arrivo: un'interfaccia utente HTML/JavaScript minima viene fornita tramite NGINX sulla porta 80. L'interfaccia utente consente agli utenti di inviare prompt e visualizzare le risposte LLM direttamente dal proprio browser.
  • Gestisce l'inferenza tramite Python: un piccolo backend Python utilizza llama-cpp-python per interagire con il modello locale. Espone un endpoint /generate a cui la pagina di arrivo invia una richiesta POST quando un utente invia una domanda.
  • Inizia all'avvio: tutto viene sottoposto a wrapping in un servizio systemd, pertanto l'inferenza si riavvia automaticamente al riavvio o all'errore dell'istanza. Non è richiesto alcun tocco manuale.

Il diagramma seguente illustra questa architettura di riferimento.



gen-ai-ampere-gguf-llm-arch.zip

L'architettura ha i seguenti componenti:

  • Area

    Un'area geografica OCI è un'area geografica localizzata che contiene uno o più data center, che ospitano domini di disponibilità. Le regioni sono indipendenti da altre regioni e vaste distanze possono separarle (tra paesi o addirittura continenti).

  • Domini di disponibilità

    I domini di disponibilità sono data center autonomi e indipendenti all'interno di un'area. Le risorse fisiche in ogni dominio di disponibilità sono isolate dalle risorse negli altri domini di disponibilità, il che fornisce tolleranza agli errori. I domini di disponibilità non condividono l'infrastruttura, ad esempio alimentazione o raffreddamento, o la rete interna del dominio di disponibilità. Pertanto, un errore in un dominio di disponibilità non dovrebbe influire sugli altri domini di disponibilità nell'area.

  • Domini di errore

    Un dominio di errori è un raggruppamento di hardware e infrastruttura all'interno di un dominio di disponibilità, Ogni dominio di disponibilità dispone di tre domini di errore con alimentazione e hardware indipendenti. Quando si distribuiscono risorse su più domini di errore, le applicazioni possono tollerare errori fisici del server, manutenzione del sistema e interruzioni di corrente all'interno di un dominio di errore.

  • Rete e subnet cloud virtuale (VCN)

    Una VCN è una rete personalizzabile e definita dal software impostata in un'area OCI. Come le reti di data center tradizionali, le reti VCN ti danno il controllo sul tuo ambiente di rete. Una VCN può avere più blocchi CIDR (Classless Inter-Domain Routing) non sovrapposti che è possibile modificare dopo aver creato la VCN. È possibile segmentare una VCN in subnet, che possono essere definite in un'area o in un dominio di disponibilità. Ogni subnet è costituita da un intervallo contiguo di indirizzi che non si sovrappongono alle altre subnet nella VCN. È possibile modificare le dimensioni di una sottorete dopo la creazione. Una subnet può essere pubblica o privata.

  • Load balancer

    Oracle Cloud Infrastructure Load Balancing fornisce una distribuzione automatica del traffico da un unico punto di accesso a più server.

  • Gateway Internet

    Un gateway Internet consente il traffico tra le subnet pubbliche di una VCN e la rete Internet pubblica.

  • Pool di istanze

    Un pool di istanze è un gruppo di istanze create dalla stessa configurazione e gestite come gruppo.

Considerazioni

Prima di implementare questa architettura, considerare quanto segue.

  • Costi dell'istanza di computazione Ampere A2

    Ogni nodo esegue Ampere A2 con 2 OCPU e 16 GB di RAM. Il prezzo di questa OCPU è attualmente di $0,01 per OCPU all'ora. Il costo mensile funziona a $ 14,40 con 1 nodo sempre attivo.

  • Costi del load balancer

    Un load balancer pubblico (piccola forma) ha un prezzo attualmente di circa $0,029 all'ora. Il costo mensile ammonta a circa $ 21. Puoi ridurre ulteriormente i costi impostando un load balancer personalizzato su un'altra istanza Ampere.

  • Costi di storage

    Ogni nodo memorizza il sistema operativo, llama.cpp e il modello che è di circa 5-6 GB. Il volume di avvio predefinito è di circa 50 GB. Si noti che i primi 200 GB al mese sono gratuiti.

Scopri di più

Ulteriori informazioni sull'esecuzione di un LLM GGUF su un cluster Ampere A2 in Oracle Cloud Infrastructure.

Esaminare le seguenti risorse aggiuntive:

Conferme

  • Autore: Badr Tharwat