Biblioteca do Ollama tem 7 modelos "mortos" entre 305: eles não conseguem escrever código

Quando um desenvolvedor roda um modelo de linguagem no próprio computador, quase sempre baixa um arquivo comprimido de um catálogo público. Essa compressão se chama quantização: os pesos do modelo são armazenados em 2–8 bits, e não em 16, para que o arquivo caiba na memória. Esses arquivos são publicados pelos operadores dos catálogos ou por voluntários, e nem nas páginas dos catálogos nem nos metadados há qualquer registro de que o arquivo tenha sido testado na prática.

Os pesquisadores decidiram verificar isso na escala de um catálogo inteiro: pegaram todas as 305 builds elegíveis (tags) da biblioteca oficial do Ollama e rodaram tarefas de programação em cada uma. Sete builds, ou 2,3%, se mostraram inutilizáveis: resolveram no máximo 6 de 164 tarefas.

Como os arquivos mortos foram encontrados

A amostra incluiu 15 linhas de modelos: oito voltadas a código e sete de uso geral. No total, são 35 variantes de modelos; 291 builds são quantizadas e 14 estão na precisão padrão de 16 bits. Também entraram 22 arquivos populares da comunidade, do Hugging Face, vindos de 12 repositórios.

A verificação teve duas etapas:

• Filtro rápido. 15 tarefas do HumanEval+, escolhidas entre as 39 que todas as 23 configurações comprovadamente saudáveis do Qwen2.5-Coder resolveram. Uma build que resolvia menos de 9 das 15 caía sob suspeita. A geração leva cerca de 30 segundos por arquivo. • Execução completa. As suspeitas receberam todas as 164 tarefas do HumanEval+. Foi considerada inutilizável a build que resolveu menos de 10% e, ao mesmo tempo, ficou muito atrás da própria versão em alta precisão.

Todas as execuções rodaram em uma placa de vídeo RTX 4090, com decodificação gulosa e semente fixa (seed 42), de modo que uma nova execução em uma segunda máquina produziu as mesmas 225 respostas, byte a byte. No caminho, os autores encontraram um erro na própria contagem: por causa de timeouts, a tarefa HumanEval/15 era contada como falha quase em toda parte. Depois de rever as builds suspeitas, sobraram 39 em vez de 50, e os sete principais suspeitos não mudaram.

As sete são versões fortemente comprimidas de modelos com até 4 bilhões de parâmetros. Cinco delas pertencem ao Qwen e ao phi3.5. As outras duas são tags do llama3.2 de 1 bilhão de parâmetros. Elas não foram recriadas por causa da licença dos pesos originais, então a causa continua sem explicação. Dois arquivos da comunidade também não funcionaram e foram verificados separadamente, com diferentes templates de chat.

Os arquivos estão íntegros; o culpado é a receita

Os pesquisadores recriaram cinco dos suspeitos a partir dos pesos originais, seguindo a receita indicada nos metadados, ou seja, sem calibração. Em seguida, compararam os tensores: tipo, formato e bytes. O resultado foi inesperado: os cinco arquivos do catálogo coincidiram integralmente com a recriação. Não houve nenhuma corrupção na conversão. São quantizações exatas dos pesos originais, que simplesmente não funcionam.

Depois, os autores testaram a calibração. Trata-se da matriz de importância (imatrix): estatísticas de ativação coletadas em uma amostra de texto. Ela indica ao quantizador onde o erro de arredondamento é mais perigoso, e ele ajusta com mais precisão as escalas dos blocos. A matriz foi construída ou com 100 trechos do WikiText-2 de 512 tokens, ou com 1,5 MB de código Python do repositório llama.cpp.

O resultado foi este:

• No Qwen2.5-Coder-3B, em três dos quatro níveis de compressão quebrados, o desempenho subiu de zero para 76–113 tarefas de 164, ou seja, 46–69%. A versão de quatro bits do mesmo modelo resolve cerca de 80%. • A mesma receita, sem calibração, no Qwen2.5-Coder-1.5B gerou um modelo funcional. Ou seja, não dá para prever a falha apenas pela receita. • Entre 66 builds aprovadas no filtro e verificadas por amostragem, não há nenhuma inutilizável.

A primeira versão do estudo escolhia a referência pelo autor da conversão, e não pela receita, e chamava os arquivos de defeituosos. A recriação pela mesma receita corrigiu essa conclusão.

O que fazer: operadores de catálogos e usuários

Problemas com arquivos em catálogos já aconteceram antes. Em 2024, os mantenedores do llama.cpp descobriram que parte das conversões usava um pré-processamento de texto incorreto antes da tokenização, e usuários relataram falhas. Dois anos depois, 26 das 305 tags oficiais ainda não informam o tipo de tokenizador.

Os autores recomendam o seguinte:

• Antes de publicar, passar as builds de poucos bits por um teste curto de execução de código. Para isso, eles disponibilizaram a ferramenta quantcheck e os dados da auditoria. • Se a build falhar no teste, é preciso calibrá-la ou não publicá-la. • Usuários não devem presumir que uma tag do catálogo foi verificada, sobretudo com 2–3 bits por peso e em modelos de até 4 bilhões de parâmetros.

Há também limitações. A verificação abrange apenas modelos para código, uma biblioteca oficial e uma pequena amostra do Hugging Face. As duas tags inutilizáveis do llama3.2-1B continuam sem explicação. O filtro se apoia em tarefas selecionadas a partir de builds saudáveis do Qwen e, entre os modelos deepseek-coder-1.3B, seis tags marcam apenas 1–6 de 15 mesmo em alta precisão, embora essa seja outra história. Mas a conclusão principal é clara: a coincidência exata com a receita ainda não significa que o arquivo funcione, e um teste barato de 30 segundos encontrou o que ficou meses parado no catálogo.