Depois que o modelo de código aberto se torna público, o que é realmente frágil é a rota padrão

Coloque a questão como “Os Estados Unidos podem ser selados?” e a resposta geralmente é menos dramática. Os arquivos de peso não desaparecerão necessariamente do mundo, mas as rotas padrão podem ser facilmente substituídas. Contanto que um endereço de hub, um valor padrão do SDK e uma entrada de inferência on-line sejam usados ​​normalmente, a automação subsequente será frágil.

Comece a partir de um endereço

O modelo de código aberto começou apenas como um endereço. Puxar, avaliar, implantar, devolver, todas as ações apontam para a mesma entrada. Quando o upstream não mudou, esse caminho parecia “suave” e até natural; quando o upstream mudou, percebi que não confiava na capacidade do modelo, mas no caminho padrão.

O ponto de interrupção mais comum no projeto não é “não é possível obter o modelo”, mas “ainda é possível obtê-lo, mas não o original”. A sincronização do espelho é lenta, os aliases são trocados, o acesso regional é restrito, a versão padrão é movida, mas o script ainda está em execução no endereço antigo. A ontologia do modelo ainda existe, mas o processo começou a se desviar.

A falha ocorre primeiro na automação

Não é difícil trocar imagens manualmente, mas a dificuldade é que a automação não entende isso sozinha. CI, avaliação programada, construção de contêineres, registros de experimentos, exemplos de documentos e scripts locais de colegas podem copiar o mesmo valor padrão. Enquanto nada for alterado, a entrada antiga continuará a aparecer.

É também aqui que o termo “selo” é mais enganoso. A verdadeira mudança muitas vezes não é que os pesos sejam apagados, mas que os valores padrão sejam reescritos. Ainda parece o mesmo nome por fora, mas a entrada, a versão e as dependências foram alteradas por dentro. Para os humanos, isso é apenas uma mudança; para a automação, é uma ampla tendência comportamental.

O peso pode ser movido, mas o valor padrão não pode ser movido.

Uma vantagem importante do modelo de código aberto é que os pesos podem ser copiados, espelhados, bifurcados e salvos offline. O problema é que o arquivo é copiado, não o caminho padrão. Enquanto o consumidor ainda considerar uma determinada entrada externa como a única verdade, por mais aberto que seja o peso, o método de operação ainda será influenciado por regras externas.

O que é ainda mais problemático é que essa alteração pode não causar necessariamente um erro imediato. Muitas vezes parece que ainda pode ser executado, mas os resultados são diferentes: um conjunto de avaliações foi aprovado no espelho A e outro conjunto foi sacudido no espelho B; uma versão está disponível localmente, mas se torna outro conjunto de patches quando chega ao pipeline; sob o mesmo nome de modelo, o comportamento real começou a divergir.

Duas coisas precisam ser distinguidas aqui. O problema da cadeia de suprimentos é mais parecido com gerenciamento de arquivos e gerenciamento de versões, e o problema de roteamento padrão é mais parecido com tomada de decisão em tempo de execução. O primeiro se preocupa se há um backup e o último se preocupa com qual caminho a solicitação deve seguir primeiro. Contanto que o valor padrão seja gravado externamente, as ações externas poderão substituir diretamente o fluxo de trabalho.

O que precisa ser complementado é a rota pin, mirror e fallback.

As soluções não são complicadas, mas poucas pessoas as consideram a primeira prioridade.

A versão deve ser fixada em um commit, hash ou release específico específico e não depender de nomes como Latest, que podem variar por um longo tempo. É melhor colocar pesos, tokenizadores, configurações e imagens de inferência juntos no armazém interno, pelo menos para garantir que eles possam ser reconstruídos quando a rede for desconectada. A entrada padrão deve ter uma rota alternativa e não pode ter apenas um endereço online. Amostras de avaliação e resultados antigos também devem ser mantidos em arquivo, caso contrário não ficará claro nem mesmo “quanto mudou”.

Todas essas coisas parecem detalhes de operação e manutenção, mas na verdade estão retomando o controle dos padrões externos. Sem esta camada de fechamento, o código aberto só trará “aparência de liberdade”, mas não “controlabilidade real”.

Depois que o modelo de código aberto se torna público, o que é realmente frágil não é o peso em si, mas a rota padrão. Enquanto a entrada ainda for controlada pelos valores padrão de outras pessoas, o fluxo de trabalho ainda será abalado quando o modelo for aberto novamente.