Exécution d'un grand modèle de langage GGUF quantifié sur un cluster Ampere A2
Architecture
Cette architecture basée sur Arm offre une implémentation de LLM à une valeur exceptionnelle, exécutée à une fraction du coût de l'infrastructure d'IA traditionnelle. Utilisez cette architecture pour une approche économique de la prise en main de l'IA.
Un équilibreur de charge public OCI se trouve à l'avant, distribuant le trafic entrant à un pool d'instances de calcul. Il existe un pool d'instances de noeuds Ampere A2. Chaque noeud est une instance de calcul Arm à 2 coeurs exécutant Ubuntu. Les noeuds sont gérés dans un pool d'instances OCI, ce qui facilite le redimensionnement horizontal à mesure que le trafic augmente. Une passerelle Internet permet un accès public à l'équilibreur de charge et aux instances back-end si nécessaire.
Chaque instance de calcul Ampere A2 exécute Ubuntu 22.04 (Arm), un LLM au format unifié généré par GPT (GGUF) quantifié (comme TinyLlama ou Phi-2) servi localement à l'aide de llama.cpp, une page de destination HTML/JS simple servie via NGINX et un back-end basé sur Python câblé en llama-cpp-python qui gère les invites de l'interface utilisateur et transmet la sortie du modèle à la page.
Chaque noeud de calcul du pool est conçu pour être léger mais entièrement autonome. Lors de son lancement, il s'initialise à l'aide d'un script cloud-init qui installe et exécute tout ce qui est nécessaire pour servir un LLM à partir de zéro. Les noeuds sont configurés comme suit :
- Dépendances d'instance : les dépendances telles que build-essential, cmake, git, NGINX et python3-pip sont installées automatiquement. llama-cpp-python est compilé à partir de la source pour assurer la compatibilité complète de ARM64.
- Builds : les noeuds extraient la dernière version de llama.cpp à partir de GitHub et la créent à l'aide de OpenBLAS pour optimiser l'inférence de l'UC, tout en conservant tout ce qui est local : aucune dépendance d'exécution externe sur les GPU ou les API d'inférence.
- Télécharge le modèle : un modèle GGUF quantifié (TinyLlama ou similaire) est extrait directement à partir de Hugging Face et placé dans le répertoire
models. - Serve une page de destination : une interface utilisateur HTML/JavaScript minimale est fournie via NGINX sur le port 80. L'interface utilisateur permet aux utilisateurs de soumettre des invites et d'afficher les réponses LLM directement à partir de leur navigateur.
- Gestion de l'inférence via Python : un petit back-end Python utilise llama-cpp-python pour interagir avec le modèle local. Elle expose une adresse
/generateà laquelle la page de destination envoie une demande POST lorsqu'un utilisateur soumet une question. - Commence à l'initialisation : tout est encapsulé dans un service
systemd. L'inférence redémarre donc automatiquement au redémarrage ou à l'échec de l'instance. Aucune intervention manuelle n'est requise.
Le schéma suivant illustre cette architecture de référence.
gen-ai-ampere-gguf-llm-arch.zip
L'architecture comporte les composants suivants :
- Région
Une région OCI est une zone géographique précise qui contient des centres de données, hébergeant des domaines de disponibilité. Les régions sont indépendantes les une des autres et peuvent les séparer d'un pays ou d'un continent à l'autre par de grandes distances.
- Domaines de disponibilité
Les domaines de disponibilité sont des centres de données autonomes indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées de celles des autres, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent ni infrastructure (par exemple, alimentation, système de refroidissement), ni réseau de domaine de disponibilité interne. Par conséquent, une panne sur un domaine de disponibilité ne doit pas affecter les autres domaines de disponibilité de la région.
- Domaines de pannes
Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec une alimentation et un matériel indépendants. Lorsque vous répartissez des ressources entre plusieurs domaines de pannes, vos applications peuvent tolérer les pannes du serveur physique, la maintenance du système et les pannes d'alimentation au sein d'un domaine de pannes.
- Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région OCI. Comme les Réseaux de centre de données traditionnels, les Réseaux cloud virtuels vous donnent un contrôle sur l'environnement réseau. Un VCN peut comporter plusieurs blocs de routage interdomaine sans classe (CIDR) qui ne se chevauchent pas et que vous pouvez modifier une fois le VCN créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
- Equilibreur de charge
Oracle Cloud Infrastructure Load Balancing fournit une distribution automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs.
- Passerelle Internet
Une passerelle Internet permet le trafic entre les sous-réseaux publics d'un VCN et le réseau Internet public.
- Pool d'instances
Un pool d'instances est un groupe d'instances d'une région qui sont créées à partir de la même configuration d'instance et gérées en tant que groupe.
Points à prendre en compte
Avant d'implémenter cette architecture, tenez compte des points suivants.
- Coûts d'instance de calcul Ampere A2
Chaque noeud exécute Ampere A2 avec 2 OCPU et 16 Go de RAM. La tarification de cette OCPU est actuellement de 0,01 $ par OCPU par heure. Le coût mensuel s'élève à 14,40 $ avec 1 noeud toujours activé.
- Coûts d'équilibreur de charge
Le prix d'un équilibreur de charge public (petite forme) est actuellement d'environ 0,029 $ l'heure. Le coût mensuel s'élève à environ 21 $. Vous pouvez encore réduire les coûts en configurant un équilibreur de charge personnalisé sur une autre instance Ampere.
- Coûts de stockage
Chaque noeud stocke le système d'exploitation, llama.cpp et le modèle, qui est d'environ 5 à 6 Go. Le volume d'initialisation par défaut est d'environ 50 Go. Notez que les 200 premiers Go par mois sont gratuits.