Estatísticas de download de modelos

Como os downloads são contabilizados para os modelos?

Contar o número de downloads de modelos não é uma tarefa trivial, pois um único repositório de modelo pode conter múltiplos arquivos, incluindo vários arquivos de pesos de modelo (por exemplo, em modelos fragmentados) e diferentes formatos dependendo da biblioteca (GGUF, PyTorch, TensorFlow, etc.). Para evitar a contagem duplicada de downloads (por exemplo, contar um único download de um modelo como múltiplos downloads), o Hub utiliza um conjunto de arquivos de consulta empregados para a contagem de downloads. Nenhuma informação é enviada pelo usuário e nenhuma chamada adicional é feita para isso. A contagem é feita no lado do servidor à medida que o Hub fornece arquivos para download.

Cada solicitação HTTP a esses arquivos, incluindo GET e HEAD, será contada como um download. Por padrão, quando nenhuma biblioteca é especificada, o Hub usa config.json como arquivo de consulta padrão. Caso contrário, o arquivo de consulta depende de cada biblioteca, e o Hub pode examinar arquivos como pytorch_model.bin ou adapter_config.json.

Quais são os arquivos de consulta para diferentes bibliotecas?

Por padrão, o Hub verifica config.json, config.yaml, hyperparams.yaml, params.json e meta.yaml. Algumas bibliotecas substituem esses padrões especificando seu próprio filtro (especificando countDownloads). O código que define essas substituições é open-source. Por exemplo, para a biblioteca nemo, todos os arquivos com a extensão .nemo são usados para contar os downloads.

Posso adicionar meus arquivos de consulta para minha biblioteca?

Sim, você pode abrir um Pull Request aqui. Aqui está um exemplo mínimo adicionando métricas de download para VFIMamba. Consulte o guia de integração para mais detalhes.

Como os arquivos GGUF são tratados?

Arquivos GGUF são autocontidos e não estão vinculados a uma única biblioteca, portanto, todos eles são contabilizados para downloads. Isso resultará em contagem duplicada de downloads no caso de um usuário realizar o clonagem de um repositório inteiro, mas a maioria dos usuários e interfaces baixa um único arquivo GGUF para um repositório específico.

Como o diffusers é tratado?

A biblioteca diffusers é um caso especial e tem seu filtro configurado no código interno. O filtro garante que os repositórios marcados como diffusers contabilizem tanto os arquivos carregados por meio da biblioteca quanto aqueles baixados manualmente pelos usuários, por meio de interfaces que exigem o download do arquivo safetensors de nível superior.

filter: [
		{
			bool: {
				/// Include documents that match at least one of the following rules
				should: [
					/// Downloaded from diffusers lib
					{
						term: { path: "model_index.json" },
					},
					/// Downloaded from diffusers lib through modular pipelines
					{
						term: { path: "modular_model_index.json" },
					},
					/// Direct downloads (LoRa, Auto1111 and others)
					/// Filter out nested safetensors and pickle weights to avoid double counting downloads from the diffusers lib
					{
						regexp: { path: "[^/]*\\.safetensors" },
					},
					{
						regexp: { path: "[^/]*\\.ckpt" },
					},
					{
						regexp: { path: "[^/]*\\.bin" },
					},
				],
				minimum_should_match: 1,
			},
		},
	]
}

E se eu precisar de dados de download mais detalhados para meus modelos?

Se você precisar de dados de download mais granulares, por exemplo, para:

• distinguir config.json dos pesos do modelo,
• exclua downloads de pipelines de CI/CD,
• ou desduplicar usuários (ou seja, contar os baixadores únicos),

em seguida, Publisher Analytics, e em particular o recurso de logs granulares, pode fornecer logs de acesso anônimos, no nível de requisição, para todos os modelos e conjuntos de dados publicados pela sua organização.

Eles são fornecidos como logs brutos, pois a maioria das organizações desejará aplicar suas próprias regras personalizadas.