Meta a lancé Muse Spark en avril 2026, son premier modèle sous la bannière Meta Superintelligence Labs, et l'a rendu strictement propriétaire : accès uniquement via l'application Meta AI et un aperçu d'API privé sur invitation, selon l'annonce officielle du laboratoire. Llama, à l'inverse, reste la famille de modèles que Meta laisse encore télécharger, modifier et auto-héberger sans connexion sortante vers ses serveurs. Ce grand écart change la question posée par cet article, qui n'est plus seulement de savoir si Llama vaut le coup, mais combien de temps ce choix restera disponible dans ces conditions, et à quel prix réel aujourd'hui.
Sur les projets d'infrastructure IA que nous menons chez Noxcod, l'auto-hébergement d'un modèle comme Llama revient dès qu'un client veut garder ses données de bout en bout sur un serveur français ou européen, sans dépendre d'une API facturée au token. Ce que peu de guides détaillent, c'est que « open source » ne veut pas dire ce que la licence Llama impose réellement, ni combien de GPU il faut vraiment pour faire tourner un modèle de cette taille en production.
Ce que la licence Llama impose vraiment avant de l'installer
Le Llama 4 Community License Agreement, publié par Meta sur son dépôt GitHub officiel, autorise l'usage, la reproduction, la distribution et la modification des poids sans redevance. Jusque-là, ça ressemble à une licence libre classique. La clause qui change tout se trouve à la section 2 : si les produits ou services de votre entreprise dépassent 700 000 000 d'utilisateurs actifs mensuels (700 millions) au moment de la sortie de la version, une autorisation spécifique de Meta devient obligatoire, accordée ou refusée à sa seule discrétion. Pour la quasi-totalité des entreprises françaises, ce seuil restera théorique, mais il suffit à exclure Llama de la définition stricte retenue par l'Open Source Initiative, qui interdit justement toute restriction fondée sur l'échelle d'usage.
La même licence impose aussi une obligation d'attribution que beaucoup d'équipes découvrent trop tard : la section 1.b.i exige d'afficher « Built with Llama » de façon visible sur tout site, interface, article de blog ou documentation produit qui distribue ou expose le modèle, et d'accoler « Llama » au nom de tout modèle entraîné ou affiné à partir de ses poids ou de ses sorties. Oublier cette mention sur une intégration client n'est pas un détail cosmétique, c'est une clause contractuelle de la licence sous laquelle le modèle est utilisé.
Scout, Maverick, Behemoth : la famille et ses tailles réelles
La famille Llama 4 repose sur une architecture à mélange d'experts qui n'active qu'une fraction des paramètres à chaque requête. Selon le billet de lancement publié par Meta AI en avril 2025, Llama 4 Scout compte 17 milliards de paramètres actifs pour 109 milliards de paramètres au total, répartis sur 16 experts, avec une fenêtre de contexte de 10 000 000 de tokens présentée par Meta comme la plus large du marché à sa sortie, et tient sur un seul GPU H100 une fois quantifié en Int4. Le même billet décrit Llama 4 Maverick avec 400 milliards de paramètres au total pour les mêmes 17 milliards actifs, répartis cette fois sur 128 experts routés plus un expert partagé, nécessitant un hôte H100 DGX complet plutôt qu'une carte isolée.
Le troisième modèle de la génération, Llama 4 Behemoth, est décrit par Meta comme un modèle à 288 milliards de paramètres actifs pour près de 2 000 milliards au total, toujours en entraînement au moment de l'annonce et jamais publié depuis : l'entreprise précise elle-même qu'elle ne le distribue pas tant qu'il n'a pas terminé son cycle d'entraînement, sans donner de date de sortie. Pour une entreprise qui évalue Llama aujourd'hui, ça ramène le choix à deux options concrètes : Scout pour l'essentiel des cas d'usage de raisonnement et de traitement documentaire volumineux, Maverick quand la qualité de réponse prime sur le coût d'infrastructure.
Le calcul GPU qu'il faut faire avant d'installer quoi que ce soit
Le chiffre de 17 milliards de paramètres actifs de Scout est trompeur si on l'utilise seul pour dimensionner un serveur : c'est la taille totale du modèle, 109 milliards de paramètres, qui détermine la mémoire GPU nécessaire pour le charger, même si le calcul par requête reste plus léger. En quantization 4 bits, Scout demande une bonne partie des 80 Go de VRAM d'un GPU H100, la configuration sur laquelle Meta annonce le faire tenir, sans grande marge pour un contexte très long ou plusieurs requêtes simultanées.
Pour un premier test à moindre coût, la variante dense Llama 3.1 8B reste disponible et change complètement l'équation : bien plus légère une fois quantifiée en 4 bits, elle tient sur une instance d'entrée de gamme comme le L4-1-24G de Scaleway (24 Go de VRAM), facturée 0,79 € de l'heure hors taxe, soit environ 574,87 € par mois en continu selon la grille tarifaire officielle du fournisseur. Pour Scout ou Maverick, il faut basculer sur du H100 complet : chez OVHcloud, une instance h100-1-gpu (80 Go de VRAM, 28 vCPU, 350 Gio de RAM) est affichée à 3,39 $ de l'heure sur la page de tarification publique cloud du fournisseur.
Déployer un Llama 8B avec Ollama pour un premier test
Pour évaluer si Llama répond au besoin avant d'investir dans un GPU de production, Ollama reste la voie la plus rapide, comme on l'a détaillé dans notre guide pour faire tourner un LLM en local avec Ollama. Une commande du type ollama run llama3.1:8b télécharge le modèle quantifié et ouvre une session de chat en quelques minutes, sans configuration GPU manuelle ni serveur d'inférence à monter.
Cette étape sert à valider la qualité de réponse sur des prompts représentatifs du projet, pas à mesurer une charge de production. Le piège classique rencontré sur les projets clients : juger Llama sur deux ou trois questions génériques, puis découvrir en production que le modèle échoue sur le vocabulaire métier spécifique de l'entreprise. Tester avec un vrai échantillon de requêtes internes, avant de choisir entre Scout et un modèle plus petit, évite un redimensionnement coûteux six mois plus tard.
Passer à vLLM pour la production, et ce que ça coûte vraiment par mois
Ollama convient à un usage interne ponctuel, pas à une API servant plusieurs utilisateurs en parallèle avec une latence garantie. Passer à vLLM, qui gère le traitement par lots et le chargement continu du modèle en mémoire GPU, devient nécessaire dès qu'un cas d'usage doit tenir une charge régulière. Cette bascule change aussi le calcul de coût : un GPU loué à l'heure pour un test ponctuel devient une ligne de budget mensuelle fixe dès qu'il tourne en continu pour garder le modèle chargé.
Sur un déploiement Scout en continu, en reprenant le tarif horaire de 3,39 $ affiché par OVHcloud pour un H100 dédié, la facture mensuelle dépasse 2 400 $ avant même de compter le stockage, la bande passante ou la supervision. C'est un budget d'infrastructure à comparer honnêtement au coût d'une API managée avant de trancher, et une des raisons pour lesquelles nous orientons certains clients vers un hébergeur souverain français plutôt qu'un cloud généraliste, un arbitrage détaillé dans notre benchmark IA souveraine FR/EU sur les offres Scaleway, OVHcloud, Infomaniak et LightOn.
Ce que l'AI Act change pour un modèle à poids ouverts comme Llama
L'AI Act européen n'exempte pas automatiquement un modèle sous prétexte qu'il est proposé en téléchargement libre. L'article 53 impose aux fournisseurs de modèles d'IA à usage général une documentation technique à jour, une politique de conformité au droit d'auteur et un résumé du contenu d'entraînement, des obligations applicables depuis le 2 août 2025 selon le texte officiel publié par la Commission européenne. L'article 53(2) exempte les modèles publiés sous licence libre et dont les poids sont accessibles publiquement d'une partie de ces obligations, mais cette exemption tombe entièrement si le modèle est classé à risque systémique, ce qui dépend du volume de calcul utilisé pour l'entraînement plutôt que du prix affiché.
Pour une entreprise qui télécharge Llama et l'installe sur son propre serveur sans le redistribuer, c'est la casquette de déployeur qui s'applique, pas celle de fournisseur : les obligations portent sur la gestion des risques liés à l'usage, pas sur la documentation du modèle lui-même. Documenter le choix du modèle, la version exacte téléchargée et le périmètre d'usage interne fait partie du dossier de conformité à constituer, indépendamment du fait que Llama soit américain, Mistral français ou Qwen chinois.
Llama face à Mistral et Qwen : quand le choisir vraiment
Auto-hébergés en France, Llama, Mistral et Qwen répondent tous les trois de la même façon à la question RGPD : une fois les poids téléchargés, aucune connexion sortante n'est nécessaire pour générer une réponse. Ce qui les différencie, ce n'est donc pas la conformité, mais la licence, l'écosystème d'outillage et la gamme de tailles disponibles. Sur la licence, Mistral AI en entreprise distribue ses modèles ouverts sous licence Apache 2.0 et Qwen, le LLM open source d'Alibaba fait le même choix de licence, sans seuil d'utilisateurs, contrairement au plafond de 700 millions de Llama évoqué plus haut.
Sur l'écosystème, Llama garde un avantage concret : c'est le modèle le mieux documenté et le plus testé dans les tutoriels Ollama et vLLM, ce qui réduit le temps d'intégration pour une équipe qui découvre l'auto-hébergement. Notre avis après plusieurs déploiements clients : partir sur Llama 3.1 8B ou Scout pour un premier projet a du sens grâce à cette maturité d'outillage, basculer vers Mistral quand la nationalité de l'éditeur pèse dans la discussion avec un DPO ou un comité de sécurité, et regarder du côté de Mixtral, le modèle open source de Mistral quand le compromis taille et coût de Llama ne convient pas.
Chez Noxcod, on accompagne ce type d'arbitrage sur des projets de développement sur mesure, du choix du modèle jusqu'au dimensionnement GPU et à la mise en production supervisée. Si votre projet touche à des données sensibles ou à un volume de requêtes qui rend une API cloud trop chère, contacter Noxcod permet de chiffrer les scénarios d'auto-hébergement avant de s'engager.
Questions fréquentes
Llama est-il vraiment open source ?
Non, pas au sens strict retenu par l'Open Source Initiative. Les poids sont téléchargeables et modifiables gratuitement, mais la licence Llama 4 impose un plafond de 700 millions d'utilisateurs actifs mensuels au-delà duquel une autorisation de Meta devient obligatoire, ainsi qu'une attribution « Built with Llama » sur toute distribution. Le terme exact est modèle à poids ouverts, pas open source.
Faut-il un GPU coûteux pour tester Llama ?
Non pour un premier test. Un modèle Llama 3.1 8B quantifié tient sur une instance GPU d'entrée de gamme comme le L4-1-24G de Scaleway, facturée 0,79 € de l'heure. Les modèles Scout et Maverick, plus lourds, demandent en revanche un GPU H100 complet, loué autour de 3,39 $ de l'heure chez OVHcloud, pour un usage en production continue.
L'auto-hébergement de Llama envoie-t-il des données vers les États-Unis ?
Non, si le modèle tourne sur votre propre infrastructure ou chez un hébergeur européen. Une fois les poids téléchargés, Llama fonctionne comme un logiciel local, sans connexion sortante vers Meta pour générer une réponse. Le sujet du transfert de données ne se pose que si vous appelez une API hébergée par un tiers américain plutôt que d'auto-héberger le modèle vous-même.
Que devient Llama maintenant que Meta a lancé Muse Spark ?
Meta Superintelligence Labs a lancé Muse Spark en avril 2026 comme modèle propriétaire, accessible seulement via l'application Meta AI et un aperçu d'API privé. Llama reste listé comme la famille de modèles fondamentaux de Meta sur son site développeur, mais rien ne garantit que les prochaines générations resteront téléchargeables dans les mêmes conditions, un argument de plus pour ne pas retarder un projet d'auto-hébergement qui a du sens aujourd'hui.
Quelle taille de Llama choisir pour commencer un projet en entreprise ?
Pour un premier test, Llama 3.1 8B quantifié donne une bonne idée de la qualité de réponse sur un budget GPU limité. Passer à Llama 4 Scout, avec sa fenêtre de contexte de 10 000 000 de tokens, ne se justifie que si le cas d'usage réel demande de traiter de très gros volumes documentaires en une seule requête, après avoir testé le besoin sur des données représentatives.
