Runpod montre comment déployer Llama 3.1 8B sur vLLM sans serveurs propres

Runpod a publié un guide pas à pas pour déployer Llama 3.1 8B Instruct sur le moteur vLLM, au sein de sa plateforme Serverless. Ce modèle de 8 milliards de paramètres, avec un contexte allant jusqu'à 128K tokens, devient un endpoint d'API qui se réveille à la demande et ne nécessite pas de louer une carte graphique en permanence. Il s'agit d'un tutoriel, pas du lancement d'un nouveau produit. Le sujet est néanmoins très concret : c'est ainsi que les petites équipes mettent aujourd'hui des modèles ouverts en production, sans bâtir leur propre infrastructure.

Llama 3.1 est sortie en juillet 2024 en trois tailles : 8B, 70B et 405B. La version à 8 milliards de paramètres est la plus accessible. En FP16, ses poids occupent environ 16 Go, ce qui lui permet de tenir sur une seule carte de 24 Go de mémoire. Il faut toutefois prévoir à part une marge pour le KV-cache sur les contextes longs.

Comment fonctionne l'ensemble

vLLM est aujourd'hui l'un des moteurs d'inférence les plus répandus pour les modèles ouverts. Il repose sur PagedAttention : la mémoire du KV-cache est allouée par blocs, comme les pages d'un système d'exploitation, ce qui réduit la fragmentation. Associé au continuous batching, qui insère les nouvelles requêtes dans un batch déjà en cours d'exécution, il augmente le débit sur une même carte. Autre avantage pour les développeurs : le serveur vLLM est compatible avec le format de l'API OpenAI, de sorte que le code client change très peu.

Runpod Serverless ajoute une couche d'orchestration. Le modèle est empaqueté dans un conteneur-worker, les requêtes arrivent dans une file d'attente, la plateforme démarre et éteint elle-même les workers, et la facturation suit leur temps de fonctionnement à la seconde près. Pour vLLM, Runpod propose un template prêt à l'emploi, configuré par des variables d'environnement : nom du modèle, token Hugging Face, longueur maximale du contexte.

Paramètres clés de l'architecture :

• Modèle : Meta Llama 3.1 8B Instruct, environ 8 milliards de paramètres.
• Contexte : jusqu'à 128K tokens.
• Poids en FP16 : de l'ordre de 16 Go.
• Moteur : vLLM avec PagedAttention et continuous batching.
• Interface : API compatible OpenAI.
• Plateforme : Runpod Serverless, avec autoscaling des workers, y compris jusqu'à zéro.

Les pièges à connaître

Le principal est le démarrage à froid. Quand le worker est éteint, il doit charger environ 16 Go de poids dans la mémoire du GPU dès la première requête, et l'utilisateur le ressent. Trois approches atténuent le problème : intégrer le modèle directement dans l'image du conteneur, s'appuyer sur le cache de la plateforme, ou maintenir au moins un worker actif. Cette dernière option grignote une partie des économies pour lesquelles on choisit justement le serverless.

Le deuxième point concerne l'accès. Llama 3.1 est distribuée sous licence Meta, et le modèle est verrouillé sur Hugging Face : il faut accepter les conditions et transmettre un token au worker. Le troisième touche à la mémoire. Par défaut, vLLM peut réserver de l'espace pour la totalité du contexte de 128K ; il est donc préférable de limiter max model len aux besoins réels de l'application. Il restera alors plus de place pour les requêtes parallèles.

L'intérêt du serverless dépend du profil de charge. Le guide ne cite aucun tarif précis : il faudra faire le calcul soi-même d'après les tarifs actuels de Runpod. Le repère est simple : pour des requêtes rares et concentrées en pics, la facturation à la seconde l'emporte sur une carte dédiée ; avec une charge élevée et stable, un serveur dédié revient en général moins cher.

Par où commencer

Pour un premier essai, une courte séquence suffit :

1. Accepter la licence Llama 3.1 sur Hugging Face et créer un token d'accès. 2. Créer un endpoint Serverless à partir du template vLLM, en indiquant le modèle et le token. 3. Choisir un GPU avec au moins 24 Go de mémoire, en gardant une marge, et limiter la longueur maximale du contexte. 4. Régler le nombre minimal et maximal de workers, ainsi que le délai d'inactivité avant l'arrêt. 5. Rediriger un client OpenAI existant vers le nouvel endpoint et mesurer la latence du premier token sur un worker à froid et sur un worker chaud.

Si le démarrage à froid est critique pour votre produit, mesurez-le avant la migration, pas après. Pour les outils internes et les tâches de fond, il reste généralement tolérable. Pour les interfaces de chat avec des utilisateurs en direct, il faudra très probablement garder un worker chaud.