Quantisiertes GGUF Large Language Model auf einem Ampere A2-Cluster ausführen

Es gibt eine wachsende regionale KI-Division, die durch den Mangel an Recheninfrastruktur verursacht wird. Die meisten modernen großen Sprachmodelle (LLMs) erfordern eine erhebliche Anzahl spezialisierter, leistungsstarker GPUs, um effektiv zu trainieren. Da jeder Server potenziell einen sechsstelligen Preis hat und globale Lieferketten unter Druck stehen, sind diese wichtigen Ressourcen für viele weiterhin unzugänglich. Bei der Erforschung von Lösungen für die wachsende KI-Division stellte sich eine vielversprechende Alternative zum GPU-Engpass heraus - der bemerkenswerte Ampere A2-Prozessor. Vom Potenzial fasziniert, haben wir eine LLM-Implementierung entwickelt, die vollständig auf Ampere A2-Clustern basiert. Die Ergebnisse waren bemerkenswert. Obwohl diese Systeme nicht mit der Rohmacht hochmoderner GPU-Arrays übereinstimmen, können sie praktische RAG-Anwendungen (Retrieval-Augmented Generation) für nur wenige Cent pro Betriebsstunde erfolgreich betreiben.

Architektur

Diese Arm-basierte Architektur bietet eine LLM-Implementierung mit außergewöhnlichem Wert, die zu einem Bruchteil der traditionellen KI-Infrastrukturkosten ausgeführt wird. Verwenden Sie diese Architektur für einen budgetfreundlichen Ansatz für den Einstieg in die KI.

Ein öffentlicher OCI-Load Balancer sitzt vorne und verteilt eingehenden Traffic an einen Pool von Compute-Instanzen. Es ist ein Instanzpool mit Ampere A2-Knoten vorhanden. Jeder Knoten ist eine 2-Core-, Arm-basierte Compute-Instanz, auf der Ubuntu ausgeführt wird. Die Knoten werden in einem OCI-Instanzpool verwaltet, sodass sie horizontal skaliert werden können, wenn der Datenverkehr wächst. Ein Internetgateway ermöglicht bei Bedarf öffentlichen Zugriff auf den Load Balancer und die Backend-Instanzen.

Jede Ampere A2-Compute-Instanz führt Ubuntu 22.04 (Arm) aus, ein quantisiertes GPT-generiertes Unified Format-(GGUF-)LLM (wie TinyLlama oder Phi-2), das lokal mit llama.cpp bereitgestellt wird, eine einfache HTML/JS-Landingpage, die über NGINX bereitgestellt wird, und ein Python-basiertes Backend, das in llama-cpp-python integriert ist, das Prompts von der UI verarbeitet und die Modellausgabe zurück zur Seite streamt.

Jeder Compute Node im Pool ist so konzipiert, dass er leicht und dennoch vollständig autark ist. Nach dem Start bootet es sich mit einem Cloud-Init-Skript, das alles installiert und ausführt, was erforderlich ist, um ein LLM von Grund auf zu bedienen. Die Knoten sind wie folgt konfiguriert:

  • Installs Dependencies: Abhängigkeiten wie build-essential, cmake, git, NGINX und python3-pip werden automatisch installiert. llama-cpp-python wird von der Quelle kompiliert, um die vollständige ARM64-Kompatibilität sicherzustellen.
  • Builds: Knoten rufen die neueste Version von llama.cpp aus GitHub ab, und erstellen sie mit OpenBLAS für optimierte CPU-Inferenz, während alles lokal bleibt - keine externe Laufzeitabhängigkeit von GPUs oder Inferenz-APIs.
  • Lädt das Modell herunter: Ein quantisiertes GGUF-Modell (TinyLlama oder ähnlich) wird direkt aus Hugging Face abgerufen und im Verzeichnis models abgelegt.
  • Dient einer Landingpage: Eine minimale HTML/JavaScript-UI wird über NGINX auf Port 80 bereitgestellt. Auf der Benutzeroberfläche können Benutzer Prompts weiterleiten und LLM-Antworten direkt über ihren Browser anzeigen.
  • Inferenz über Python verarbeiten: Ein kleines Python-Backend verwendet llama-cpp-python, um mit dem lokalen Modell zu interagieren. Es wird ein /generate-Endpunkt bereitgestellt, an den die Landingpage eine POST-Anforderung sendet, wenn ein Benutzer eine Frage weiterleitet.
  • Beginnt beim Booten: Alle Elemente werden in einen systemd-Service gewrappt, sodass die Inferenz beim Neustart oder Ausfall der Instanz automatisch neu gestartet wird - es ist keine manuelle Berührung erforderlich.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.



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

Die Architektur umfasst folgende Komponenten:

  • Region

    Eine OCI-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Centre enthält, das Availability-Domains hostet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können über Länder oder Kontinente voneinander getrennt werden.

  • Availability-Domains

    Availability-Domains sind eigenständige, unabhängige Data Center innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain sind von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz sicherstellt. Availability-Domains haben keine gemeinsame Infrastruktur wie Stromversorgung oder Kühlung oder das interne Availability-Domainnetzwerk. Ein Fehler in einer Availability-Domain sollte sich also nicht auf die anderen Availability-Domains in der Region auswirken.

  • Faultdomains

    Eine Faultdomain ist eine Gruppierung aus Hardware und Infrastruktur innerhalb einer Availability-Domain. Jede Availability-Domain verfügt über drei Faultdomains mit unabhängiger Stromversorgung und Hardware. Wenn Sie Ressourcen über mehrere Faultdomains verteilen, können Ihre Anwendungen physische Serverausfälle, Systemwartungen und Stromausfälle innerhalb einer Faultdomain tolerieren.

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetze

    Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer OCI-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten Sie über VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

  • Load Balancer

    Oracle Cloud Infrastructure Load Balancing bietet eine automatisierte Trafficverteilung von einem einzigen Einstiegspunkt auf mehrere Server.

  • Internetgateway

    Ein Internetgateway ermöglicht Traffic zwischen den öffentlichen Subnetzen in einem VCN und dem öffentlichen Internet.

  • Instanzpool

    Ein Instanzpool ist eine Gruppe von Instanzen innerhalb einer Region, die aus derselben Instanzkonfiguration erstellt und als Gruppe verwaltet werden.

Hinweise

Beachten Sie vor der Implementierung dieser Architektur Folgendes:

  • Kosten für Ampere A2-Compute-Instanz

    Jeder Knoten führt Ampere A2 mit 2 OCPUs und 16 GB RAM aus. Die Preise für diese OCPU betragen derzeit 0,01 US-Dollar pro OCPU pro Stunde. Die monatlichen Kosten werden auf 14,40 US-Dollar berechnet, wobei 1 Knoten immer aktiviert ist.

  • Load-Balancer-Kosten

    Ein öffentlicher Load Balancer (kleine Ausprägung) kostet derzeit etwa 0,029 US-Dollar pro Stunde. Die monatlichen Kosten betragen etwa 21 US-Dollar. Sie können die Kosten weiter senken, indem Sie einen benutzerdefinierten Load Balancer auf einer anderen Ampere-Instanz einrichten.

  • Speicherkosten

    Jeder Knoten speichert das BS, llama.cpp und das Modell, das etwa 5-6 GB beträgt. Das Standard-Boot-Volume beträgt ca. 50 GB. Beachten Sie, dass die ersten 200 GB pro Monat kostenlos sind.

Mehr erfahren

Weitere Informationen zum Ausführen eines GGUF-LLM auf einem Ampere A2-Cluster in Oracle Cloud Infrastructure.

Prüfen Sie die folgenden zusätzlichen Ressourcen:

Bestätigungen

  • Autor: Badr Tharwat