بالنسبة لمعظم الفرق، توجد النماذج ومجموعات البيانات في مجموعة بيانات في منطقة واحدة من سحابة واحدة. إن وحدات معالجة الرسومات التي يمكنك الحصول عليها، سواء للتطوير أو التدريب أو الخدمة، تتواجد بشكل متزايد على سحابة مختلفة عن بياناتك. في اللحظة التي ينفصل فيها هذين الاثنين، فإنك تدفع ضريبة نقل عبر السحابة فقط لقراءة بياناتك الخاصة على وحدات معالجة الرسومات الخاصة بك.
جنبًا إلى جنب مع Hugging Face، انضممنا إلى النصفين: تظل النماذج ومجموعات البيانات الخاصة بك على Hub، ويقوم SkyPilot بتشغيل الحوسبة (التطوير أو التدريب أو الخدمة) على أي مجموعة تحتوي على وحدات معالجة الرسومات. قم بتركيب Hugging Face Bucket أو أي Hub repo في مهمة SkyPilot باستخدام واحدة hf:// عنوان URL و HF_TOKEN لديك بالفعل، ثم قم بتشغيله حيثما تكون السعة. لا تفرض Hugging Face أي رسوم على الخروج، لذا فإن قراءة بياناتك على وحدات معالجة الرسومات هذه لا تكلف شيئًا على أي سحابة.
إليك ما هو الجديد:
- بيانات المحور الخاص بك في أي وظيفة.
store: hfيتصاعد وجه المعانقة دلو (القراءة والكتابة) أو أي النموذج / مجموعة البيانات / الريبو الفضائي (للقراءة فقط) في مهمة SkyPilot بواحدةhf://URL والموجود لديكHF_TOKEN، عبرMOUNTأوCOPY. - قم بتشغيله على أي GPU، على أي سحابة. وجدت SkyPilot أن حوسبة المهام عبر أكثر من 20 سحابة، وKubernetes، وSlurm، والمحلية، لذلك يستخدم نفس التشغيل أيًا من وحدات معالجة الرسومات المحجوزة أو عند الطلب المتاحة، على أي بائع.
- لا يوجد مخرج لقراءة البيانات الخاصة بك. لا تفرض Hugging Face Storage أي رسوم خروج أو رسوم CDN، لذا أينما تولى SkyPilot المهمة، فإنه يقرأ النماذج ومجموعات البيانات الخاصة بك مباشرة من نفس المجموعة، بدون نسخ لكل سحابة ولا فاتورة خروج لسحبها.
- dedup المدعومة من Xet. يتم إنشاء الجرافات على Xet، لذا فإن نقاط التفتيش الإضافية ومتغيرات النماذج تقوم فقط بتخزين ونقل الأجزاء التي تغيرت.
- بنيت معا. قام Hugging Face وSkyPilot بشحن هذا المنتج بشكل مشترك، وقام فريق Hugging Face بنقل البيانات إلى المنبع
hf-mountإصلاحات FUSE التي تجعلها تعمل في حاويات غير مميزة.
أصبحت Hugging Face Storage الآن واجهة خلفية SkyPilot من الدرجة الأولى

تقوم مهام SkyPilot بالفعل بقراءة وكتابة مخازن الكائنات السحابية (S3 وGCS وAzure وR2 وغيرها الكثير) عن طريق تركيبها على مسار محلي. ينضم الآن Hugging Face Storage إلى تلك القائمة باسم store: hf، تم التوصل إليه من خلال hf:// مخطط:
file_mounts:
/checkpoints:
source: hf://buckets/my-org/qwen-sft
store: hf
mode: MOUNT
/base-model:
source: hf://Qwen/Qwen3.5-4B
store: hf
mode: MOUNT
/data:
source: hf://datasets/my-org/my-dataset@main
store: hf
mode: MOUNT
هذا hf:// يغطي المخطط دورة الحياة بأكملها: اقرأ نموذج و dataset من مستودعاتهم، والكتابة نقاط التفتيش إلى دلو أثناء التدريب، وانشر النموذج النهائي مرة أخرى إلى الريبو، واسحبه إلى خوادم الاستدلال عند التقديم. تحتفظ معظم الفرق بالفعل بنماذجها ومجموعات البيانات الخاصة بها على المركز، لذلك لا توجد خطوة ترحيل ولا يوجد حساب تخزين جديد لإنشاءه.
MOUNT يستخدم معانقة الوجه hf-mount الواجهة الخلفية لـ FUSE، لذلك يظهر الدلو أو الريبو كمسار محلي بجوار حوامل FUSE الأخرى الخاصة بـ SkyPilot (gcsfuse, blobfuse2, rclone, goofys). يحدث الجلب في طبقة نظام الملفات: عندما يصدر الكود الخاص بك ملف read()، يقوم برنامج التشغيل بسحب تلك البايتات فقط من الواجهة الخلفية لـ Xet، وبالتالي فإن البيانات التي تلمسها فعليًا فقط هي التي تعبر الشبكة، و hf-mount يحتفظ بذاكرة تخزين مؤقت على القرص، لذا تظل القراءات المتكررة محلية. إن ذاكرة التخزين المؤقت الموجودة على القرص هي السلوك الذي تقدمه SkyPilot لواجهاتها الخلفية الأخرى MOUNT_CACHED، حيث سهل MOUNT بدلاً من ذلك، يقوم ببث كل قراءة من المجموعة دون الاحتفاظ بأي شيء محليًا. ل hf محل، MOUNT و MOUNT_CACHED تتصرف بنفس الطريقة، لذلك يحتفظ أي من الوضعين بذاكرة التخزين المؤقت.
نظرًا لأن عمليات القراءة كسولة، يمكن أن تبدأ العملية في العمل على ملف كبير قبل تنزيل الملف بأكمله، بدلاً من حظر النسخة الكاملة أولاً. يؤدي ذلك إلى إبقاء وحدة معالجة الرسومات مشغولة على الفور تقريبًا، حيث يتم التدريب على البيانات أثناء تدفقها بدلاً من البقاء في وضع الخمول (والفواتير) أثناء نسخ مجموعة البيانات أو نقاط التفتيش. إنه يؤتي ثماره أكثر في العصر الأول، عندما لا يتم تخزين أي شيء مؤقتًا بعد. COPY يأخذ الطريق الآخر والتنزيلات من خلال huggingface_hub مقدما، دون أي متطلبات خاصة.
المصادقة هي الرمز المميز الذي لديك بالفعل. تعيين HF_TOKEN في بيئتك وتسليمها للتشغيل --secret HF_TOKEN; يستخدمه SkyPilot للتركيب على أي سحابة تصل إليها المهمة. يعمل رمز واحد سواء وصلت المهمة إلى AWS، أو GCP، أو Azure، أو Nebius، أو Lambda، أو مجموعة Kubernetes الخاصة بك، لذلك لا توجد مفاتيح مجموعة لكل سحابة للتلاعب بها.
لا يوجد خروج: يتوقف التخزين عن تحديد المكان الذي ستركض فيه
نادرًا ما تأتي سعة وحدة معالجة الرسومات من مكان واحد بعد الآن. للحصول على ما يكفي من H100s وH200s، تحتفظ الفرق بقدرة محجوزة وملتزمة عبر العديد من البائعين في وقت واحد (كتلة على وحدة قياس فائقة السرعة، أو مجموعة على سحابة جديدة، أو ربما رف محلي) وتشغيلها في أي مكان لديهم تخصيص. تم تصميم SkyPilot لهذا الغرض: مواصفات مهمة واحدة، مجدولة عبر أكثر من 20 سحابة، وKubernetes، ومحليًا، والهبوط على أي مجموعة محجوزة مجانية.
لقد كان تخزين الكائنات هو المصيد. تعتبر مخازن الكائنات إقليمية ولكل سحابة، لذا فإن تغذية وحدة معالجة الرسومات أو خادم الاستدلال الموجود في مركز بيانات بائع مختلف يعني إما الاحتفاظ بنسخة من بياناتك في مجموعة كل بائع أو الدفع مقابل سحبها. تتقاضى معظم السحابات رسوم الخروج (حوالي 0.09 دولارًا أمريكيًا/جيجابايت من AWS) في اللحظة التي تغادر فيها البيانات شبكتها، وغالبًا ما يكون ذلك بين المناطق داخل سحابة واحدة. يؤدي سحب نموذج أساسي إلى كل عقدة استدلال، أو تكرار مجموعة بيانات لعدة حقب من مجموعة على سحابة أخرى، إلى إضافة فاتورة باهظة على وحدات معالجة الرسومات التي قمت بحجزها بالفعل. وينتهي الأمر بالفرق بتثبيت كل عملية تشغيل على أي بائع يحتفظ بالبيانات وترك بقية قدراتهم في وضع الخمول.
معانقة تخزين الوجه يزيل هذه التكلفة من الطاولة حيث يعض: جانب القراءة. مع عدم وجود رسوم خروج أو CDN وتخزين بسعر 12-18 دولارًا أمريكيًا لكل تيرابايت شهريًا (مقابل AWS S3 بسعر 23 دولارًا أمريكيًا تقريبًا لكل تيرابايت بالإضافة إلى الخروج)، يمكن الوصول إلى نفس الحاوية من كل مجموعة من هذه المجموعات، والقراءة منها مجانية بغض النظر عن مكان تشغيل وحدات معالجة الرسومات. لا تزال الكتابة مرة أخرى تكلف الخروج المعتاد لسحابتك الحاسوبية، كما هو الحال في أي متجر خارج السحابة، ولكن بالنسبة لمعظم أعمال الذكاء الاصطناعي، تهيمن القراءات: مجموعة بيانات متدفقة على العديد من العصور، أو أوزان نموذجية يتم سحبها على كل عقدة تدريب أو استدلال جديدة. لذلك تتوقف عن تثبيت كل عملية تشغيل لأي بائع يحتفظ بنسخة من البيانات.
معيار سريع
لجمع بعض الأرقام القياسية، قمنا بإجراء تعديل بسيط: Qwen/Qwen3.5-4B على HuggingFaceH4/Multilingual-Thinking مجموعة البيانات مع TRL SFTTrainer، وتركيب النموذج للقراءة فقط من Hub repo الخاص به وكتابة كل نقطة تفتيش في Hugging Face Bucket. تم تشغيل SkyPilot YAML نفسه على AWS وGCP وLambda، مع التغيير فقط --infra. وضعت SkyPilot كل وظيفة في أي مكان تكون فيه وحدات معالجة الرسومات مجانية، وقام الثلاثة جميعًا بقراءة وكتابة نفس المجموعة.
resources:
accelerators: H100:1
file_mounts:
/base-model:
source: hf://Qwen/Qwen3.5-4B
store: hf
mode: MOUNT
/checkpoints:
source: hf://buckets/my-org/qwen-sft
store: hf
mode: MOUNT
run: |
python train.py --model /base-model --output_dir /checkpoints
ما قمنا بقياسه:
- تم تحميل النموذج مجانًا على كل سحابة. يقرأ كسول سحب ما فقط
from_pretrainedاللمسات، لذلك كان جاهزًا للتدريب في حوالي 30 ثانية (ما يصل إلى500 ميجابايت/ثانية). نظرًا لأن Hugging Face لا يتطلب أي خروج، فإن هذا السحب لا يكلف شيئًا؛ لو كان النموذج موجودًا في S3، لكان من الممكن أن يتم تحرير فاتورة لكل قراءة لوحدة معالجة الرسومات على سحابة أخرى (0.09 دولار/جيجابايت على AWS). - تدفقت نقاط التفتيش مباشرة إلى الدلو بسرعة تصل إلى 170 ميجابايت/ثانية تقريبًا (8.43 جيجابايت من أوزان كل منها) واستمرت بعد مثيل وحدة معالجة الرسومات.
لكل سحابة، كتبت نقاط التفتيش إلى الدلو على:
| سحاب | GPU | نقطة تفتيش الكتابة |
|---|---|---|
| AWS (الولايات المتحدة-الشرق-2) | L40S | ~168 ميجابايت/ثانية |
| Google Cloud Platform (us-central1) | L4 | ~123 ميجابايت/ثانية |
| لامدا (الولايات المتحدة-الغرب-3) | H100 | ~112 ميجابايت/ثانية |
التخزين المدعوم بـ Xet: dedup لنقاط التفتيش ومتغيرات الطراز
تم تصميم Hugging Face Buckets على Xet، والذي يستخدم التقطيع المحدد بالمحتوى لتقسيم الملفات إلى أجزاء تبلغ سعتها 64 كيلوبايت تقريبًا وتخزين كل قطعة فريدة مرة واحدة. نظرًا لأن الحدود تتبع المحتوى، فإن التحرير يغير فقط الأجزاء التي يلمسها ويتم التعرف على الباقي على أنه مخزن بالفعل. وهذا يؤتي ثماره في أماكن قليلة:
- نقاط التفتيش المتزايدة والمحول. عندما تقوم بتجميد الطبقات، أو تدريب المحولات، أو ترك معظم الأوزان دون تغيير بين عمليات الحفظ، يتم تحميل الأجزاء التي تم تغييرها فقط بدلاً من نقطة التحقق بأكملها.
- متغيرات النموذج التي تشترك في القاعدة. تتداخل الضبط الدقيق والتكميم لنموذج أساسي واحد بشكل كبير، لذلك يتم تخزين الأجزاء المشتركة مرة واحدة عبر كل النماذج.
- مجموعات البيانات التي تلحق بها. تنمو السجلات مثل آثار المحادثة أو مخرجات الاستدلال عن طريق إلحاق صفوف بملفات Parquet كبيرة الحجم. تظل مجموعات الصفوف الموجودة متطابقة بايت، لذلك يتم نقل الصفوف الجديدة فقط: في اختبار Hugging Face، تم نقل إلحاق 10 آلاف صف إلى جدول مكون من 100 ألف صف بحوالي 10 ميجابايت بدلاً من 106 ميجابايت بالكامل. (إذا قمت بتحرير أو حذف صفوف في مكانها، فاكتب باستخدام
use_content_defined_chunking=Trueللحفاظ على التغييرات المحلية.) - عمليات إعادة التحميل تتخطى ما تم تخزينه بالفعل. في الاختبار الذي أجريناه، استغرقت إعادة تحميل كائن كبير كبير بحجم 8.43 غيغابايت موجود بالفعل في المجموعة حوالي 8 ثوانٍ، مقابل 24 ثانية للتحميل الأول، لأن تجزئات القطعة فقط هي التي تتحرك. نفس الآلية تسمح من جانب الخادم
hf buckets cpيتم النسخ بين عمليات إعادة الشراء والدلاء حسب المرجع بدلاً من إعادة تحميل البايتات.
يعتمد المبلغ الذي ستوفره على مدى تداخل القطع الأثرية، ولكن إلغاء البيانات المكررة يكون تلقائيًا: تكتب نقطة تفتيش كالمعتاد، ولا تخرج إلا القطع الجديدة من الجهاز.
ابدأ
pip install "skypilot[huggingface]"
hf auth login
أضف hf:// قم بالتركيب على أي مهمة SkyPilot وابدأ التشغيل. MOUNT يحتاج إلى صورة أساسية مع glibc 2.34+ و /dev/fuse.
مدمجان معًا: Hugging Face وSkyPilot
الأولي store: hf بدأ الدعم كمساهمة من نيخيل جها. قام فريق Hugging Face بنقله إلى الأمام ونقله إلى المنبع hf-mount يعمل FUSE على إصلاحات تسمح بتثبيته في حاويات غير مميزة، وهو الوضع الافتراضي في العديد من مجموعات Kubernetes. قام فريق SkyPilot بتوصيله إلى الواجهة الخلفية للتخزين. المسار بأكمله مفتوح المصدر: SkyPilot، Hugging Face’s hf-mount، و huggingface_hub عميل.
موارد