Es más probable que el modelo de código abierto de China se ralentice en lugar de bloquearse.

Cuando este tipo de discusión cae en el proyecto, eventualmente convergerá en una frase más fría: es difícil borrar por completo el modelo de código abierto. Lo primero que realmente se vuelve frágil es la línea de montaje que gira alrededor del modelo. Mientras uno de los archivos del modelo, imágenes, valores de verificación, entorno de inferencia y scripts de evaluación esté roto, lo que el equipo sentirá no es “si este modelo todavía existe en el mundo”, sino “si esta actualización se puede reproducir”.

Lo que realmente se atasca suelen ser las entradas y las actualizaciones.

La custodia oficial es la más fácil de cerrar primero. Páginas web, API, páginas de descarga, sitios espejo, siempre que la entrada esté centralizada, los pagos, los asuntos legales, la CDN, las restricciones regionales y las políticas de cuentas pueden reducirlo. Lo mismo ocurre con la inferencia de nubes. Una vez que la empresa subcontrata las capacidades del modelo a un determinado punto de alojamiento, el bloqueo no necesita eliminar el modelo del mundo. Mientras se endurezcan las restricciones de accesibilidad, cuotas, pagos y regionales, el sistema empezará a temblar.

Pero una vez que el peso se ha dispersado, la situación cambia. El modelo de código abierto no solo reside en una determinada página de inicio, sino que también reside en discos locales, cachés de compilación, almacenes de imágenes y almacenamiento de artefactos creados por el equipo. Lo que puedes controlar es más la velocidad a la que continúa la distribución que las copias que ya existen. Para aclarar la situación, el mayor impacto a menudo no es “si todavía puedes descargar una determinada versión”, sino “si puedes obtener de manera estable el mismo conjunto de tokenizadores, plantillas de chat, paquetes de cuantificación e instrucciones de dependencia en el futuro”.

También es el más subestimado aquí. La primera vez que ejecuta el modelo, el riesgo parece haber desaparecido; el verdadero problema suele ser la segunda vez. La segunda vez que quise retroceder, la imagen ya no estaba allí; la segunda vez que quise reproducir, el formato de cuantificación había cambiado; la segunda vez que quise actualizar, el código de inferencia y la versión de peso no coincidían; La segunda vez que quise verificar, se habían cambiado el conjunto de evaluación y el script de preprocesamiento. A primera vista, solo falta un enlace de descarga, pero en realidad lo que falta es un conjunto completo de cadenas de suministro repetibles.

Así que este tipo de “sello” se parece más a una desaceleración que a una eliminación. Lo que puede verse significativamente debilitado es la velocidad de comunicación, el acceso a la nube, la sincronización de versiones y la confianza ecológica; lo que es difícil de borrar por completo son las copias ponderadas, las capacidades de implementación local y las capacidades de distribución secundaria que se han extendido. Una vez que el modelo de código abierto ingresa a suficientes máquinas, el riesgo cambia de “puede existir” a “puede evolucionar de manera estable”.

Aquí también es donde los equipos nacionales tienen más probabilidades de fallar. Después de integrar el modelo en el producto, es fácil centrarse únicamente en la primera ronda de efectos y olvidar que el modelo es en realidad una dependencia. Una vez que una dependencia tiene un solo punto de entrada, ese punto único se convertirá en un punto de control; una vez que una dependencia no tiene bloqueo de versión, las actualizaciones se convertirán en un evento aleatorio; una vez que una dependencia no tiene una copia fuera de línea, la llamada “capacidad propia” se revelará después de que falle un determinado espejo.

El enfoque más estable no es imaginar que no habrá bloqueo, sino dividir el bloqueo en varios pequeños problemas asequibles de antemano: el peso y el tiempo de ejecución se almacenan por separado, la dirección de descarga y el valor de verificación se guardan juntos, el entorno de inferencia se reconstruye fuera de línea, los resultados de la evaluación se archivan por versión y la ruta de reversión es tan clara como la ruta de liberación. De esta manera, incluso si el flujo ascendente se cierra repentinamente, el producto solo perderá una entrada y no toda la capacidad estará fuera de línea al mismo tiempo.

El verdadero foso del modelo de código abierto nunca ha sido “nadie se atreve a gestionarlo”, sino “cuando se gestiona, ya es difícil gestionarlo hasta cierto punto”. Hay muchas entradas que se pueden cerrar y es difícil recuperar los ejemplares que se han desparramado.