إحصائيات تنزيل النماذج

كيف يتم احتساب عمليات التنزيل للنماذج؟

إنّ عدّ عدد التحميلات للنماذج ليس مهمةً بسيطة، إذ قد يحتوي مستودع نموذج واحد على ملفات متعددة، بما في ذلك ملفات أوزان نماذج متعددة (مثل النماذج المقسّمة) وصيغ مختلفة اعتمادًا على المكتبة (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 لعدّ عمليات التنزيل.

هل يمكنني إضافة ملفات الاستعلام الخاصة بمكتبت

نعم، يمكنك فتح طلب سحب هنا. إليك مثالًا بسيطًا لإضافة مقاييس التحميل لـ 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، أن توفر سجلات وصول مُجهَّلة على مستوى الطلب لجميع النماذج ومجموعات البيانات التي تنشرها مؤسستك.

تُقدَّم هذه البيانات كسجلات خام، لأن معظم المؤسسات ستُريد تطبيق قواعد مخصصة خاصة بها.