Depois que o modelo de código aberto da China for restrito, a primeira coisa a ser desfiada é a versão e o calibre de avaliação.

Depois que essas restrições são suspensas, a primeira coisa que falha geralmente não é “ainda pode ser baixado?” mas “ainda pode ser baseado no mesmo conjunto de pontuações?”

O modelo em si ainda está lá e o espelhamento pode ser sincronizado, mas o problema começa a passar da entrada para a comparação. Uma versão que funciona bem hoje terá pequenas diferenças em outra máquina devido ao fatiamento de peso, versão do tokenizador, parâmetros de inferência ou atrasos de espelhamento. Só de olhar para cada saída, parece que ainda funciona; uma vez colocada de volta no conjunto de regressão, a curva começa a se espalhar. Antigamente, você só precisava analisar uma pontuação total para decidir se deseja atualizar, mas agora você precisa primeiro desempacotar “se essa mudança vem do modelo ou da pilha de serviços”.

O verdadeiro problema causado pelas restrições não está na ação de download em si, mas na destruição das relações de comparação. No passado, você só precisava se concentrar em uma versão upstream, mas agora muitas vezes existem fontes oficiais, fontes espelhadas, caches internos, versões quantizadas e versões de reversão temporária ao mesmo tempo. Cada linha pode ser executada, mas os resultados não compartilham mais a mesma linha de base. Depois que o conjunto de avaliação for bifurcado, a equipe perderá rapidamente uma linguagem comum: a área de P&D diz que esta versão foi melhorada e o produto diz que a experiência online não mudou. Os solucionadores de problemas devem primeiro confirmar se o modelo mudou ou se o ambiente de inferência mudou.

A coisa mais problemática sobre esse tipo de garfo é que ele não se manifesta imediatamente como um defeito. No primeiro dia, houve apenas uma diferença de 0,3 ponto entre os dois ambientes. No segundo dia, uma certa amostra de texto longo começou a flutuar. Depois de reverter no terceiro dia, descobri que os resultados antigos não podiam ser reproduzidos. Nesta fase, a discussão já não é sobre “podemos obter o modelo?” mas “se o que obtemos é a mesma coisa”.

O que realmente deveria ser encerrado primeiro não é a entrada de download, mas a linha de base. Pelo menos as seguintes coisas precisam ser definidas:

• O hash, a versão do tokenizer, o método de quantização e os parâmetros de inferência do arquivo do modelo.
• Conjunto de avaliação, palavras de alerta, parâmetros de amostragem e lógica de pós-processamento.
• Encapsulamento de inferência compartilhado por serviços online e regressão offline para evitar desvios entre os dois conjuntos de implementações.
• Retenha a imagem antiga e a linha de base ao reverter, sem depender da reconstrução da memória.

Essas coisas podem parecer triviais, mas quando o acesso ao modelo começa a ser restrito, é essa camada de trivialidade que se torna realmente valiosa. Sem eles, a equipe só pode apostar na próxima atualização com “parece bom desta vez”; com eles, eles podem pelo menos confirmar se o problema está no modelo, na pilha de inferência ou no próprio conjunto de dados.

Portanto, quando esta questão finalmente recair sobre o projeto, o julgamento se tornará muito simples: se o modelo pode ser obtido é apenas o começo; se o mesmo conjunto de entradas, o mesmo conjunto de parâmetros e o mesmo conjunto de amostras podem ser executados continuamente na mesma linha determina se ainda pode ser usado de forma estável. Enquanto o calibre comparativo se mantiver, ainda haverá espaço de manobra no modelo; uma vez que o calibre diverge primeiro, a substituição, reversão e solução de problemas subsequentes se tornarão mais caras.