Llama 2 : la licence compte autant que le modèle
Modèles ouvertsLicenceSouverainetéArchitecture2023-07-1810 min
Ce qui change avec Llama 2 n'est pas la qualité du modèle mais son contrat. Trois droits décident si vous pouvez réellement construire dessus.
L'événement est juridique avant d'être technique
Llama 2 est publié avec ses poids et une licence autorisant l'usage commercial, ce qui n'était pas le cas de la génération précédente. C'est cette clause, et non le score du modèle, qui change les décisions d'architecture.
Un modèle dont les poids sont téléchargeables mais dont la licence interdit l'usage commercial n'a aucune valeur pour une entreprise : il sert à la recherche et à la démonstration, pas à la production. Le passage à une licence commerciale fait entrer une nouvelle option dans l'arbitrage, celle du modèle hébergé sur son propre matériel.
Cette option n'était pas ouverte jusqu'ici, quel que soit le niveau technique de l'équipe. Elle l'est désormais, et elle change la nature de la conversation avec une direction juridique ou un responsable de la sécurité.
Les trois droits à vérifier, un par un
Une licence de modèle accorde ou refuse séparément trois choses : utiliser, modifier, redistribuer. Confondre les trois est l'erreur la plus fréquente, et elle se paie tard.
Le droit d'utiliser permet de faire tourner le modèle pour son propre compte. C'est le minimum, et c'est souvent tout ce qui est réellement accordé sous l'étiquette « ouvert ».
Le droit de modifier permet le réglage fin sur ses propres données. Il conditionne toute stratégie de spécialisation, et il s'accompagne parfois d'obligations : publier les modifications, mentionner l'origine, ne pas entraîner un modèle concurrent.
Le droit de redistribuer permet de livrer le modèle à un tiers, un client, une filiale, un partenaire. C'est celui qui manque le plus souvent, et c'est un problème pour tout éditeur de logiciel qui voudrait embarquer le modèle dans son produit.
À cela s'ajoutent des restrictions moins visibles : seuils d'utilisateurs actifs au-delà desquels la licence ne s'applique plus, usages interdits, obligations de nommage.
Ce que l'auto-hébergement change réellement
- Les données ne quittent plus l'infrastructure. C'est l'argument décisif dans la santé, la défense et le secteur public, et il ne se remplace pas par une clause contractuelle.
- Le coût devient fixe au lieu d'être variable. Un serveur amorti coûte le même prix à mille ou à cent mille requêtes, ce qui inverse complètement le calcul au-delà d'un certain volume. Voir modèles ouverts et souveraineté.
- Le modèle ne change plus sans prévenir. Une version figée reste identique, ce qui supprime la classe de problèmes décrite dans le jour où le modèle a changé sans prévenir.
- La charge d'exploitation devient interne. Mise à jour, supervision, capacité, incidents : tout ce que le fournisseur assurait devient une responsabilité d'équipe.
Le calcul honnête, avec les coûts qu'on oublie
L'auto-hébergement devient rentable au-delà d'un volume précis, et ce volume est plus élevé que ne l'estiment la plupart des équipes. L'erreur classique consiste à comparer le prix d'un serveur au prix des appels API, en oubliant tout le reste.
Ce qu'il faut ajouter du côté interne : le temps d'ingénierie pour la mise en service, la supervision permanente, la capacité à absorber les pointes, la redondance si le service est critique, et le coût de la montée de version quand un meilleur modèle sort. Ces postes représentent en général davantage que le matériel.
Ce qu'il faut ajouter du côté API : rien de caché, mais un risque de dépendance et une exposition à des changements de tarif ou de disponibilité.
Ma recommandation reste la même : commencer par une API derrière une couche d'abstraction, mesurer trois mois, puis rejouer le calcul avec des chiffres constatés.
La question à poser à votre direction juridique
« Avons-nous le droit de livrer ce modèle à un client, dans notre produit ? » Si la réponse est non, l'architecture ne doit pas dépendre de ce modèle en particulier, et la couche d'abstraction devient obligatoire, pas optionnelle.
Ce que ça annonce pour les deux années suivantes
L'écart entre modèles fermés et modèles ouverts va se réduire, et le choix deviendra un arbitrage ordinaire plutôt qu'un renoncement. C'est déjà perceptible sur les tâches structurées : extraction, classification, reformulation.
Sur ces tâches, un modèle ouvert de taille moyenne fait le travail à une fraction du coût. Sur le raisonnement complexe et les contextes très longs, l'écart reste net et le restera un certain temps.
La conséquence pratique est le routage : petit modèle ouvert pour le volume, grand modèle fermé pour les cas difficiles. Ce réglage suppose une couche d'abstraction et un jeu de tests, faute de quoi personne ne saura quelle tâche relève de quel modèle. C'est le chaînon décrit dans l'évaluation continue.
Questions fréquentes
- Un modèle « ouvert » est-il un modèle libre ?
Rarement. La plupart des licences dites ouvertes accordent l'usage et la modification, mais restreignent la redistribution ou imposent des seuils d'utilisateurs. Il faut lire la licence, pas l'étiquette.
- À partir de quel volume l'auto-hébergement devient-il rentable ?
Le seuil dépend du modèle et du matériel, mais il est toujours plus élevé qu'estimé, parce que le calcul oublie la supervision, la redondance et la montée de version. Il faut mesurer trois mois d'usage réel avant de trancher.
- Peut-on combiner modèle ouvert et modèle propriétaire ?
Oui, et c'est souvent la configuration la plus économique : un modèle ouvert pour les tâches structurées à fort volume, un modèle propriétaire pour le raisonnement complexe. Cela suppose une couche d'abstraction commune.
- Le réglage fin est-il nécessaire sur un modèle ouvert ?
Pas systématiquement. Sur la plupart des usages documentaires, une bonne récupération donne de meilleurs résultats qu'un réglage fin, pour un coût très inférieur et une maintenance beaucoup plus simple.