La véritable avancée du modèle open source chinois réside dans le réseau de collaboration.

Lorsqu’on parle de « s’il sera scellé » dans le modèle open source, la chose la plus simple à considérer est de considérer le fichier de poids comme tout.

Une fois les poids téléchargés, le modèle lui-même ne disparaît souvent pas aussi facilement. Ce qui est plus facile à briser en premier, c’est le réseau qui tourne autour de lui : sites miroirs, ensembles d’évaluation, modèles d’inférence, scripts de réglage fin, résolutions de problèmes, paramètres de déploiement par défaut et consensus au sein de la communauté selon lequel “cette version peut s’exécuter et cette version ne doit pas être modifiée”.

La partie qui peut toucher le sol a le moins peur de se casser.

Tant qu’un modèle open source est entré dans un entrepôt local, un stockage d’objets ou une image intranet, aussi étroit que soit le monde extérieur, le fichier sera généralement toujours là. Les copies hors ligne, les caches internes et les produits de construction historiques retarderont tous pendant longtemps la question de savoir « s’il peut encore être utilisé ».

C’est également la plus grande différence entre le modèle open source et les services cloud purs. Une fois qu’un service cloud est bloqué, l’entrée disparaît souvent ; même si le service en amont du modèle open source est arrêté, les poids, le tokenizer et l’image d’inférence disponibles peuvent continuer à s’exécuter. La question n’est pas « l’avez-vous ? mais “pouvez-vous continuer à l’utiliser de la même manière que les autres ?”

Ce qui est vraiment net, c’est la relation de synchronisation

Ce n’est pas parce que le modèle peut continuer à fonctionner que l’équipe peut continuer à le suivre.

Les premières choses à assouplir sont généralement les relations de synchronisation :

• L’amont a sorti une nouvelle version, mais le miroir interne n’a pas suivi dans le temps.
• L’ensemble d’évaluation a été révisé et les résultats de régression ne peuvent plus être alignés sur les anciens enregistrements.
• Le modèle de chat ou tokenizer a été légèrement déplacé, mais le style de sortie a beaucoup changé.
• Un certain correctif n’est entré que dans les relations publiques de la communauté, pas dans l’image intranet de l’entreprise.
• La quantification par défaut, la longueur de contexte par défaut et les paramètres d’échantillonnage par défaut sont chacun séparés.

Ces choses ne semblent pas grandes en elles-mêmes, mais les empiler ensemble divisera le « même modèle » en plusieurs parties.

À ce stade, le véritable préjudice causé par les restrictions extérieures n’est pas d’effacer du monde un document pesant, mais de briser le fait que « tout le monde regarde la même chose ». L’équipe parle toujours du même nom de modèle, mais ce qu’elle obtient en réalité est un package combiné avec différentes versions, différents modèles et différents paramètres.

Les avis, les correctifs et l’expérience seront regroupés

Une fois qu’un modèle open source entre dans le flux de travail réel, la valeur réelle n’est généralement pas le poids lui-même, mais le jugement accumulé autour du poids.

Quelle version est la plus stable, quel tokenizer brisera le texte long, quel ensemble de paramètres d’échantillonnage est le plus adapté aux scénarios de service client, quel script de réglage fin augmentera l’illusion, ces expériences reposent toutes sur un échange continu. Tant que le réseau de collaboration demeure, tout le monde peut toujours bricoler autour de la même base de référence ; une fois le réseau de collaboration rompu, chaque équipe développera lentement sa propre version privée.

Les versions privées ne sont pas une mauvaise chose, mais le prix grimpe :

• Le retour à la ligne de base devient de plus en plus difficile à réutiliser
• L’examen des accidents devient de plus en plus difficile à aligner
• Correction d’un patch devenant de plus en plus difficile à synchroniser
• Le même problème apparaîtra à plusieurs reprises dans différentes équipes

À l’heure actuelle, il semble que “le modèle est toujours là”, mais en fait, il s’agit de “de nombreuses copies locales à peine utilisables”, et il n’y a pas de chemin de mise à jour commun entre elles.

Ce qui vaut vraiment la peine de s’inquiéter, ce n’est pas de bloquer, mais de bifurquer

Le modèle open source est difficile à être complètement scellé comme une API en ligne car la réplicabilité est là. Ce dont nous devons vraiment nous méfier, c’est qu’une fois que la pression externe a interrompu la distribution, la réparation et la collaboration, le modèle commence à diverger selon les rythmes des différentes organisations.

Une fois qu’il y a plus de forks, il n’est plus question de « est-ce que ça peut être téléchargé ? mais “qui peut garantir que c’est toujours le même genre de chose ?” Ce problème augmentera directement le coût d’accès : les nouvelles révisions doivent être refaites, les anciens défauts doivent être réexpliqués, les différences de version doivent être réorganisées et l’équipe doit élaborer ses propres stratégies de restauration et de gel pour chaque ligne fourchue.

La résilience du modèle open source est en effet plus forte que celle des services cloud purs ; mais sa vulnérabilité est également très claire, non pas si le poids a été supprimé, mais si le réseau de collaboration peut continuer à conserver le même nom pour la même chose.