Статистика загрузок моделей

Как учитываются загрузки моделей?

Подсчёт количества загрузок моделей — задача не тривиальная, поскольку в одном репозитории модели может содержаться несколько файлов, включая несколько файлов весов модели (например, в случае с шардированными моделями) и различные форматы в зависимости от библиотеки (GGUF, PyTorch, TensorFlow и т. д.). Чтобы избежать двойного подсчёта загрузок (например, когда одна загрузка модели учитывается как несколько), Hub использует набор файлов для запросов, применяемых для подсчёта загрузок. От пользователя не отправляется никакой информации, и для этого не выполняются дополнительные вызовы. Подсчёт выполняется на стороне сервера, когда Hub предоставляет файлы для загрузки.

Каждый HTTP-запрос к этим файлам, включая GET и HEAD, будет засчитан как загрузка. По умолчанию, если библиотека не указана, Hub использует config.json в качестве файла для запроса. В противном случае файл для запроса зависит от конкретной библиотеки, и Hub может проверять такие файлы, как pytorch_model.bin или adapter_config.json.

Какие файлы запросов используются для разных библиотек?

По умолчанию Hub обращается к config.json, config.yaml, hyperparams.yaml, params.json и meta.yaml. Некоторые библиотеки переопределяют эти значения по умолчанию, указывая собственный фильтр (указывая countDownloads). Код, определяющий эти переопределения, является открытым. Например, для библиотеки nemo для подсчета загрузок используются все файлы с расширением .nemo.

Могу ли я добавить файлы запросов для моей библиотеки?

Да, вы можете открыть Pull Request здесь. Вот минимальный пример добавления метрик загрузки для VFIMamba. Подробнее смотрите в руководстве по интеграции.

Как обрабатываются файлы GGUF?

Файлы GGUF являются самодостаточными и не привязаны к конкретной библиотеке, поэтому все они учитываются при подсчёте загрузок. В случае, если пользователь клонирует весь репозиторий, это приведёт к двойному учёту загрузок, однако большинство пользователей и интерфейсов скачивают один файл GGUF для данного репозитория.

Как обрабатывается diffusers?

Библиотека diffusers является частным случаем, и её фильтр настроен во внутреннем кодовом репозитории. Фильтр обеспечивает учёт как файлов, загруженных через библиотеку, так и через интерфейсы, в которых пользователям необходимо вручную скачивать верхнеуровневые safetensors, для репозиториев с меткой diffusers.

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,
			},
		},
	]
}

Что делать, если мне нужны более детальные данные о загрузке моих моделей?

Если вам нужны более детальные данные о загрузке, например, чтобы:

• различать config.json и веса модели,
• исключить загрузки из конвейеров CI/CD,
• или дедуплицировать пользователей (т.е. подсчитать уникальных скачивающих),

затем Publisher Analytics, а в особенности функция granular logs, может предоставлять анонимизированные журналы доступа на уровне запросов для всех моделей и наборов данных, опубликованных вашей организацией.

Они предоставляются в виде сырых журналов, поскольку большинство организаций захочет применить собственные пользовательские правила.