Le modèle open source chinois risque davantage d’être ralenti que bloqué.

Lorsque ce genre de discussion s’inscrit dans le projet, elle finira par converger vers une phrase plus froide : il est difficile d’effacer complètement le modèle open source. Ce qui devient vraiment fragile en premier, c’est la chaîne de montage qui tourne autour du modèle. Tant que l’un des fichiers de modèle, des images, des valeurs de contrôle, de l’environnement d’inférence et des scripts d’évaluation est défectueux, l’équipe ne se demandera pas si ce modèle existe toujours dans le monde, mais si cette mise à niveau peut être reproduite.

Ce qui reste vraiment bloqué, ce sont généralement les entrées et les mises à jour.

La garde officielle est la plus simple à mettre fin en premier. Les pages Web, les API, les pages de téléchargement, les sites miroirs, tant que l’entrée est centralisée, le paiement, les affaires juridiques, le CDN, les restrictions régionales et les politiques de compte peuvent tous la réduire. Il en va de même pour l’inférence cloud. Une fois que l’entreprise sous-traite les capacités du modèle à un certain point d’hébergement, le blocus n’a pas besoin de supprimer le modèle du monde. Tant que les restrictions en matière d’accessibilité, de quotas, de paiement et régionales seront renforcées, le système commencera à trembler.

Mais une fois le poids dispersé, la situation change. Le modèle open source ne réside pas seulement sur une certaine page d’accueil, il réside également sur des disques locaux, des caches de construction, des entrepôts d’images et un stockage d’artefacts créés par l’équipe. Ce que vous pouvez contrôler, c’est davantage la vitesse à laquelle la distribution se poursuit que les copies qui existent déjà. Pour clarifier la situation, l’impact le plus important n’est souvent pas « de savoir si vous pouvez toujours télécharger une certaine version », mais « si vous pouvez obtenir de manière stable le même ensemble de tokenizers, de modèles de discussion, de packages de quantification et d’instructions de dépendance à l’avenir ».

C’est aussi le plus sous-estimé ici. La première fois que vous exécutez le modèle, le risque semble écarté ; le vrai problème, c’est souvent la deuxième fois. La deuxième fois que j’ai voulu revenir en arrière, l’image n’était plus là ; la deuxième fois que j’ai voulu reproduire, le format de quantification avait changé ; la deuxième fois que j’ai voulu mettre à niveau, le code d’inférence et la version de poids ne correspondaient pas ; la deuxième fois que j’ai voulu vérifier, l’ensemble d’évaluation et le script de prétraitement avaient été modifiés. En apparence, il ne manque qu’un seul lien de téléchargement, mais en réalité, ce qui manque, c’est un ensemble complet de chaînes d’approvisionnement reproductibles.

Ce type de « sceau » s’apparente donc plus à une décélération qu’à une suppression. Ce qui peut être considérablement affaibli, c’est la vitesse de communication, l’accès au cloud, la synchronisation des versions et la confiance écologique ; ce qui est difficile à effacer complètement, ce sont les copies pondérées, les capacités de déploiement local et les capacités de distribution secondaire qui se sont répandues. Une fois que le modèle open source entre dans suffisamment de machines, le risque passe de « peut-il exister » à « peut-il évoluer de manière stable ».

C’est également là que les équipes nationales risquent le plus de rater leur cible. Après avoir intégré le modèle dans le produit, il est facile de se concentrer uniquement sur la première série d’effets et d’oublier que le modèle est en réalité une dépendance. Dès qu’une dépendance n’a plus qu’un seul point d’entrée, ce point unique devient un point de contrôle ; une fois qu’une dépendance n’a pas de verrouillage de version, les mises à niveau deviennent un événement aléatoire ; une fois qu’une dépendance n’a pas de copie hors ligne, la soi-disant « propre capacité » sera révélée après la défaillance d’un certain miroir.

L’approche la plus stable n’est pas d’imaginer qu’il n’y aura pas de blocage, mais de diviser le blocage en plusieurs petits problèmes abordables à l’avance : le poids et la durée d’exécution sont stockés séparément, l’adresse de téléchargement et la valeur de vérification sont enregistrées ensemble, l’environnement d’inférence est conçu pour être reconstruit hors ligne, les résultats de l’évaluation sont archivés par version et le chemin de restauration est aussi clair que le chemin de publication. De cette façon, même si l’amont s’arrête soudainement, le produit ne perdra qu’une seule entrée et l’ensemble de la capacité ne sera pas hors ligne en même temps.

Le véritable fossé du modèle open source n’a jamais été “personne n’ose le gérer”, mais “quand il est géré, il est déjà difficile de le gérer jusqu’à un certain point”. Il existe de nombreuses entrées qui peuvent être resserrées, et il est difficile de récupérer les copies étalées.