Llama 3.1 405B : ce que télécharger des poids ne fournit pas
LlamaModèles ouvertsInfrastructureCoût2024-07-2310 min
Le modèle ouvert atteint le niveau des meilleurs fermés. Ce qui reste à fournir soi-même représente l'essentiel du coût, et se découvre après la décision.
Le seuil symbolique est franchi
Un modèle à poids ouverts atteint le niveau des meilleurs modèles propriétaires, ce qui clôt le débat sur la capacité et ouvre celui sur l'exploitation. Le second débat est plus difficile que le premier.
Pendant deux ans, l'argument contre les modèles ouverts était la qualité. Cet argument tombe. Celui qui le remplace est moins commode à traiter parce qu'il ne porte pas sur une caractéristique du modèle mais sur une capacité de l'organisation.
La question devient : qui fait tourner ce modèle, tous les jours, pendant trois ans. Elle n'a pas de réponse technique.
Les quatre charges qui ne sont pas fournies
La mémoire vidéo, la supervision, la redondance et la montée de version constituent l'essentiel du coût réel d'un modèle hébergé. Aucune n'apparaît dans la comparaison de tarifs qui motive en général la décision.
La mémoire vient en premier et c'est la seule qu'on chiffre correctement : un modèle de cette taille demande une infrastructure de centre de données, plusieurs centaines de giga-octets de mémoire vidéo.
La supervision est permanente. Quelqu'un doit surveiller la disponibilité, diagnostiquer les ralentissements, gérer la saturation aux heures de pointe. Ce n'est pas un projet, c'est une astreinte.
La redondance conditionne la criticité. Un service dont l'organisation dépend ne peut pas reposer sur une machine unique, ce qui double le matériel.
La montée de version, enfin, revient tous les six mois et n'est jamais provisionnée. Le raisonnement complet figure dans modèles ouverts et souveraineté.
Quand l'hébergement interne reste le bon choix
- Quand les données ne peuvent pas sortir, pour une raison réglementaire ou contractuelle. C'est l'argument décisif, et le seul qui ne se remplace pas.
- Quand le volume est très élevé et stable, ce qui amortit le matériel et la supervision sur un grand nombre d'appels.
- Quand la stabilité prime, un modèle figé ne changeant pas de comportement. Voir le jour où le modèle a changé sans prévenir.
- Quand l'équipe d'exploitation existe déjà et sait tenir un service critique. Sans elle, la décision est un vœu.
La configuration qui fonctionne le mieux en pratique
Héberger un modèle de taille moyenne pour les données protégées, et recourir à une API pour l'analyse complexe sur le reste. Cette architecture mixte donne plus de souveraineté réelle qu'un projet d'hébergement ambitieux.
Le raisonnement est simple. La quasi-totalité des traitements portant sur des données sensibles sont structurés : extraction, classification, anonymisation, recherche documentaire. Un modèle de taille moyenne les traite très bien, et il tient sur du matériel accessible.
L'analyse complexe, elle, porte le plus souvent sur des contenus qui peuvent sortir, ou qui ont été préalablement anonymisés par le premier étage.
Cette configuration a un mérite supplémentaire : elle est réversible. Si le modèle interne s'avère insuffisant, on bascule ; si l'API devient trop chère, on internalise davantage. Elle suppose la couche d'abstraction décrite dans la couche qui rend le modèle remplaçable.
La question qui tranche en une réunion
« Qui sera d'astreinte sur ce modèle un dimanche de novembre ? » Si personne n'a de réponse, l'hébergement interne n'est pas décidé, il est seulement souhaité, et le projet s'arrêtera au troisième mois.
Ce que ça annonce pour les dix-huit mois suivants
Les versions réduites de ce modèle, publiées par la communauté, auront plus d'effet pratique que le modèle lui-même. C'est le schéma observé à chaque publication majeure.
Un très grand modèle ouvert sert de matière première : il est compressé, distillé, spécialisé, et donne naissance à des modèles bien plus petits qui héritent d'une partie de ses capacités. Ce sont ceux-là que les organisations déploieront réellement.
La recommandation pratique en découle. Construire aujourd'hui une architecture réversible, avec un jeu de tests, permet d'adopter ces dérivés sans projet quand ils arriveront. Une architecture liée à un fournisseur devra être réécrite pour en profiter, ce qui revient en général à ne pas en profiter.
Le calcul qu'il faut refaire chaque semestre
Le seuil de rentabilité entre hébergement interne et API se déplace deux fois par an, dans les deux sens. Un calcul fait une fois est faux six mois plus tard.
Deux forces s'opposent. Les modèles ouverts deviennent plus capables à matériel constant, ce qui favorise l'internalisation. Les tarifs d'API baissent et les caches de contexte réduisent la facture, ce qui la défavorise.
La seule façon de tenir cette décision est de la rendre bon marché à reprendre : une couche d'abstraction, un jeu de tests, et un seuil de volume écrit à l'avance qui déclenche le réexamen. Voir construire un jeu de tests en une journée.
Questions fréquentes
- Un modèle ouvert de pointe est-il utilisable par une PME ?
Pas dans sa version complète : la mémoire vidéo requise relève du centre de données. Les versions réduites publiées ensuite par la communauté, elles, sont exploitables sur du matériel accessible.
- Que coûte réellement un modèle hébergé ?
Le matériel, la supervision permanente, la redondance si le service est critique, et la montée de version tous les six mois. Ces trois derniers postes dépassent souvent le premier et n'apparaissent dans aucune comparaison de tarifs.
- Quelle configuration recommander en pratique ?
Un modèle de taille moyenne hébergé pour les données protégées, une API pour l'analyse complexe sur le reste. Cette architecture mixte est réversible et donne plus de souveraineté réelle qu'un projet ambitieux inachevé.
- Quand l'hébergement interne s'impose-t-il vraiment ?
Quand les données ne peuvent pas sortir pour une raison réglementaire ou contractuelle. C'est le seul argument qui ne se remplace pas par une clause de contrat ou une baisse de tarif.