O verdadeiro avanço do modelo de código aberto da China é a rede de colaboração

Ao falar sobre “se será lacrado” no modelo de código aberto, a coisa mais fácil de se observar é considerar o arquivo de peso como tudo.

Depois que os pesos são baixados, o modelo em si muitas vezes não desaparece tão facilmente. O que é mais fácil de quebrar primeiro é a rede que gira em torno dela: sites espelho, conjuntos de avaliação, modelos de inferência, scripts de ajuste fino, soluções de problemas, parâmetros de implantação padrão e o consenso na comunidade de que “esta versão pode ser executada e essa versão não deve ser tocada”.

A parte que pode atingir o solo é a que tem menos medo de quebrar.

Enquanto um modelo de código aberto entrar em um armazém local, armazenamento de objetos ou imagem de intranet, não importa quão restrito seja o mundo externo, o arquivo geralmente ainda estará lá. Cópias offline, caches internos e produtos de construção histórica atrasarão por muito tempo a questão de “se ainda pode ser usado”.

Esta é também a maior diferença entre o modelo de código aberto e os serviços de nuvem puros. Depois que um serviço em nuvem é bloqueado, o acesso geralmente desaparece; mesmo que o serviço upstream do modelo de código aberto seja interrompido, os pesos, o tokenizer e a imagem de inferência em mãos podem continuar a ser executados. A questão não é “você tem isso?” mas “você pode continuar a usá-lo da mesma forma que os outros?”

O que é realmente nítido é o relacionamento de sincronização

Só porque o modelo pode continuar funcionando não significa que a equipe possa continuar a acompanhá-lo.

As primeiras coisas a serem relaxadas geralmente são os relacionamentos de sincronização:

• O upstream lançou uma nova versão, mas o espelho interno não acompanhou o ritmo.
• O conjunto de avaliação foi revisado e os resultados da regressão não podem mais ser alinhados com os registros antigos.
• O modelo de chat ou tokenizer foi movido um pouco, mas o estilo de saída mudou muito.
• Uma certa correção entrou apenas nas relações públicas da comunidade, não na imagem da intranet corporativa
• A quantização padrão, o comprimento do contexto padrão e os parâmetros de amostragem padrão são separados.

Essas coisas não parecem grandes por si só, mas empilhá-las irá quebrar o “mesmo modelo” em várias partes.

Nesta fase, o verdadeiro dano causado pelas restrições externas não é apagar um documento pesado do mundo, mas quebrar o facto de “todos olharem para a mesma coisa”. A equipe ainda está falando sobre o mesmo nome de modelo, mas o que eles realmente conseguem é um pacote combinado com versões diferentes, modelos diferentes e parâmetros diferentes.

Avaliações, correções e experiência serão divididas juntas

Depois que um modelo de código aberto entra no fluxo de trabalho real, o valor real geralmente não é o peso em si, mas o julgamento acumulado em torno do peso.

Qual versão é mais estável, qual tokenizador quebrará o texto longo, qual conjunto de parâmetros de amostragem é mais adequado para cenários de atendimento ao cliente, qual script de ajuste fino aumentará a ilusão, todas essas experiências dependem de troca contínua. Enquanto a rede de colaboração permanecer, todos ainda poderão mexer na mesma linha de base; uma vez quebrada a rede de colaboração, cada equipe desenvolverá lentamente sua própria versão privada.

Versões privadas não são ruins, mas o preço sobe:

• O retorno à linha de base torna-se cada vez mais difícil de reutilizar
• A revisão de acidentes torna-se cada vez mais difícil de alinhar
• Correção do patch que está se tornando cada vez mais difícil de sincronizar
• O mesmo problema aparecerá repetidamente em equipes diferentes

Neste momento, parece que “o modelo ainda está lá”, mas na verdade tornou-se “muitas cópias locais que são pouco utilizáveis”, e não há um caminho de atualização comum entre elas.

O que realmente vale a pena se preocupar não é bloquear, mas bifurcar

O modelo de código aberto é difícil de ser completamente selado como uma API online porque a replicabilidade existe. O que realmente devemos ter cuidado é que, depois de a pressão externa interromper a distribuição, a reparação e a colaboração, o modelo começa a divergir ao longo dos ritmos das diferentes organizações.

Quando houver mais garfos, não será mais uma questão de “pode ​​ser baixado?” mas “quem pode garantir que isso ainda é o mesmo tipo de coisa?” Este assunto aumentará diretamente o custo de acesso: novas revisões precisam ser refeitas, falhas antigas precisam ser reexplicadas, diferenças de versão precisam ser reorganizadas e a equipe precisa criar suas próprias estratégias de reversão e congelamento para cada linha bifurcada.

A resiliência do modelo de código aberto é de facto mais forte do que a dos serviços puros em nuvem; mas a sua vulnerabilidade também é muito clara, não se o peso foi retirado, mas se a rede de colaboração pode continuar a manter o mesmo nome da mesma coisa.