Back home

É mais provável que o modelo de código aberto da China seja desacelerado do que bloqueado.

O que realmente se torna frágil é a distribuição, atualizações e cadeias de dependências

Quando esse tipo de discussão cai no projeto, eventualmente convergirá para uma frase mais fria: É difícil apagar completamente o modelo de código aberto. O que realmente se torna frágil primeiro é a linha de montagem que gira em torno do modelo. Enquanto um dos arquivos de modelo, imagens, valores de verificação, ambiente de inferência e scripts de avaliação estiver quebrado, o que a equipe sentirá não é “se este modelo ainda existe no mundo”, mas “se esta atualização pode ser reproduzida”.

O que realmente trava geralmente são as entradas e atualizações.

A custódia oficial é a mais fácil de encerrar primeiro. Páginas da Web, APIs, páginas de download, sites espelho, desde que a entrada seja centralizada, pagamento, assuntos jurídicos, CDN, restrições regionais e políticas de conta podem restringir tudo. O mesmo se aplica à inferência na nuvem. Uma vez que a empresa terceiriza os recursos do modelo para um determinado ponto de hospedagem, o bloqueio não precisa excluir o modelo do mundo. Enquanto a acessibilidade, as quotas, o pagamento e as restrições regionais forem reforçadas, o sistema começará a tremer.

Mas uma vez que o peso se dispersou, a situação muda. O modelo de código aberto não reside apenas em uma determinada página inicial, mas também em discos locais, caches de construção, armazéns de imagens e armazenamento de artefatos construídos pela equipe. O que você pode controlar é mais a velocidade com que a distribuição continua do que as cópias que já existem. Para deixar a situação clara, o maior impacto muitas vezes não é “se você ainda pode baixar uma determinada versão”, mas “se você pode obter de forma estável o mesmo conjunto de tokenizadores, modelos de chat, pacotes de quantização e instruções de dependência no futuro”.

Também é o mais subestimado aqui. Na primeira vez que você executa o modelo, o risco parece ter acabado; o verdadeiro problema geralmente é a segunda vez. Na segunda vez que quis reverter, a imagem não estava mais lá; na segunda vez que quis reproduzir, o formato de quantificação havia mudado; na segunda vez que quis atualizar, o código de inferência e a versão de peso não correspondiam; na segunda vez que quis verificar, o conjunto de avaliação e o script de pré-processamento foram alterados. Superficialmente, falta apenas um link de download, mas, na verdade, o que falta é um conjunto completo de cadeias de suprimentos repetíveis.

Então esse tipo de “selo” é mais uma desaceleração do que uma exclusão. O que pode ser significativamente enfraquecido é a velocidade da comunicação, o acesso à nuvem, a sincronização de versões e a confiança ecológica; o que é difícil de ser completamente apagado são as cópias ponderadas, as capacidades de implantação local e as capacidades de distribuição secundária que se espalharam. Uma vez que o modelo de código aberto entra em máquinas suficientes, o risco muda de “pode existir” para “pode evoluir de forma estável”.

É também aqui que as equipas nacionais têm maior probabilidade de errar o alvo. Depois de integrar o modelo ao produto, é fácil focar apenas na primeira rodada de efeitos e esquecer que o modelo é na verdade uma dependência. Uma vez que uma dependência tenha apenas um ponto de entrada, o ponto único se tornará um ponto de controle; uma vez que uma dependência não possui bloqueio de versão, as atualizações se tornarão um evento aleatório; uma vez que uma dependência não possui uma cópia offline, a chamada “capacidade própria” será revelada após a falha de um determinado espelho.

A abordagem mais estável não é imaginar que não haverá bloqueio, mas quebrar o bloqueio antecipadamente em vários pequenos problemas acessíveis: o peso e o tempo de execução são armazenados separadamente, o endereço de download e o valor de verificação são salvos juntos, o ambiente de inferência é feito para ser reconstruído offline, os resultados da avaliação são arquivados por versão e o caminho de reversão é tão claro quanto o caminho de liberação. Dessa forma, mesmo que o upstream seja desligado repentinamente, o produto perderá apenas uma entrada e toda a capacidade não ficará offline ao mesmo tempo.

O verdadeiro fosso do modelo de código aberto nunca foi “ninguém se atreve a gerenciá-lo”, mas “quando é gerenciado, já é difícil gerenciá-lo até certo ponto”. Existem muitas entradas que podem ser fechadas e é difícil recuperar as cópias que se espalharam.