Entre AWS et Hugging Face, les arbitrages LLM d’eTF1

Plutôt TGI ou vLLM ? Chez eTF1, on a opté pour le premier de ces serveurs d’inférence, qui « répond [aux] besoins actuels ». On garde toutefois un œil sur le second, dans l’optique de montées en charge.

Les déploiements de LLM se font sur AWS. Plus précisément sur EKS, à l’aide de Karpenter, avec des configurations spécifiques pour provisionner deux types d’instances, équipées respectivement en puces NVIDIA T4 et Inferentia.

Pour minimiser la consommation de ressources, eTF1 recourt à la quantisation (réduction de précision)… mais pas avec les puces Inferentia, qui ne la prennent pas en charge. Sur ses Mac de prototypage, il est en 4 bits avec Ollama. Dans le cloud, il a le choix entre plusieurs implémentations. Parmi elles, EETQ (8 bits, qui fonctionne avec tous les modèles), AWQ (4 bits, qui nécessite un modèle spécifique) et bitsandbytes (qui « fonctionne avec tous les modèles  mais peut être plus lent »).

Le fonctionnement des Inferentia diffère de celui des GPU NVIDIA pour une autre technique sur laquelle eTF1 s’appuie : le traitement par lots (travail sur plusieurs prompts en simultané). Sur les puces d’AWS, le batching a la particularité d’être statique (déterminé à la compilation).

Entre autres techniques, eTF1 met aussi en œuvre le sharding, qui lui permet d’exploiter les deux cores des instances Inferentia. Il inclure en outre un schéma dans ses batchs afin d’obtenir du JSON en retour. Le RAG est exploré avec un outil origine Hugging Face : TEI (Text Embeddings Inference).

À consulter en complément :

IA générative et internet ouvert : les craintes de l’Arcep
Les arbitrages de Salesforce pour l’évaluation des LLM
La problématique VMware plus concrète que les LLM chez Red Hat France
Mozilla face au dilemme de la GenAI dans Firefox
Comment marier IA générative et données d’entreprise

Illustration © Quardia Inc. – Adobe Stock