اتصال SkyPilot به Hub: حذف ۱۰۰ درصدی هزینه‌های Egress در کلاود

اگر امروز برای دسترسی به GPUهای قدرتمند، داده‌های خود را بین چند ارائه‌دهنده مختلف ابر جابه‌جا می‌کنید، احتمالاً مبلغ هنگفتی را بابت «مالیات انتقال» یا همان Egress Fees می‌پردازید. حالا با یک تغییر فنی، این هزینه برای تیم‌های هوش مصنوعی به صفر رسیده است. طبق اعلام رسمی در ۷ ژوئیه ۲۰۲۶، SkyPilot و Hugging Face سیستمی را پیاده‌سازی کرده‌اند که اجازه می‌دهد کارهای پردازشی، مخازن Hub را مستقیماً و بدون هزینه‌ی خروج داده بخوانند.

برای اکثر تیم‌های AI، ظرفیت ایده‌آل GPU به‌ندرت در یک مکان واحد یافت می‌شود. توسعه‌دهندگان برای securing تعداد کافی H100 یا H200، اغلب مجبورند زیرساخت خود را بین غول‌های ابری (Hyperscalers)، ابرهای نوظهور (Neoclouds) و رک‌های محلی (On-premise) تقسیم کنند. اما چون ذخیره‌سازی اشیاء (Object Storage) به‌طور سنتی منطقه‌ای و وابسته به هر ابر است، جابه‌جایی داده به جایی که پردازش در دسترس است، به یک گلوگاه مالی اصلی تبدیل شده بود. این چالش مالی در حالی است که برخی راهکارهای جایگزین، مانند استقرار محلی مدل‌های کدنویسی با Ollama، تلاش می‌کنند با حذف وابستگی به کلاود، هزینه‌های عملیاتی را به طور کلی کاهش دهند.

همان‌طور که در تحلیل قبلی ما درباره‌ی استانداردسازی توزیع کدهای سفارشی در Hugging Face Kernels اشاره کردیم، این ادغام جدید روی لایه‌ی داده تمرکز دارد. در این رویکرد، Hub دیگر فقط یک مخزن مدل نیست، بلکه به عنوان یک بک‌اند ذخیره‌سازی درجه‌یک برای هر پردازشی عمل می‌کند.

سازوکار: hf:// و نقاط اتصال FUSE

SkyPilot اکنون از یک بک‌اند اختصاصی به نام store: hf پشتیبانی می‌کند. کاربران می‌توانند با استفاده از یک URL ساده با پیشوند hf:// و یک توکن معتبر (HF_TOKEN)، دسترسی خواندن و نوشتن به Hugging Face Buckets یا دسترسی خواندنی به هر مدل، مجموعه‌داده یا Space repo داشته باشند.

این سیستم، ذخیره‌سازی Hugging Face را در کنار پشتیبانی‌های موجود از S3، GCS، Azure و R2 در بک‌اند ذخیره‌سازی SkyPilot قرار می‌دهد. طرح hf:// تمام چرخه عمر مدل را پوشش می‌دهد؛ از خواندن مدل‌های پایه و مجموعه‌داده‌ها از مخازن، نوشتن نقاط بازرسی (Checkpoints) در یک باکت در حین آموزش، تا انتشار مدل نهایی و فراخوانی آن روی سرورهای استنتاج (Inference).

این ادغام از بک‌اند hf-mount FUSE استفاده می‌کند. در اینجا مدل از «خواندن تنبل» (Lazy Reads) بهره می‌برد؛ یعنی به‌جای دانلود کامل یک مجموعه‌داده پیش از شروع آموزش، سیستم فقط بایت‌های مورد نیاز را در لحظه استخراج می‌کند. وقتی کد دستور خواندن می‌دهد، درایور فقط بایت‌های خاص مورد نیاز را از بک‌اند Xet می‌کشد. این یعنی GPUها تقریباً بلافاصله پردازش را شروع می‌کنند و زمان بیکاری (Idle time) که منجر به صورت‌حساب‌های اضافی می‌شود، در شروع اولین دور آموزش (Epoch) به‌شدت کاهش می‌یابد، زیرا داده‌ها به‌جای مسدود شدن مسیر برای یک کپی کامل، به صورت استریم منتقل می‌شوند.

جزئیات فنی و پیاده‌سازی

SkyPilot سه حالت مختلف برای مدیریت این اتصالات ارائه می‌دهد تا تعادلی بین سرعت و ماندگاری ایجاد کند:

• MOUNT: استفاده از بک‌اند FUSE که در آن باکت یا مخزن مانند یک مسیر محلی در کنار سایر اتصالات FUSE مانند gcsfuse، blobfuse2، rclone و goofys ظاهر می‌شود. برای ذخیره‌ساز HF، این حالت به‌طور خودکار یک حافظه پنهان (Cache) روی دیسک ایجاد می‌کند، به این معنی که خواندن‌های تکراری در حالت محلی باقی می‌مانند.
• MOUNT_CACHED: در حالی که SkyPilot از این حالت برای بکاندهای دیگر جهت فعال‌سازی کش استفاده می‌کند، برای ذخیره‌ساز hf دقیقاً مشابه حالت MOUNT عمل کرده و هر دو حافظه پنهان را نگه می‌دارند.
• COPY: این روش داده‌ها را از طریق کلاینت huggingface_hub به‌طور کامل و پیش‌دستانه دانلود می‌کند. این روش نیازی به الزامات خاص FUSE ندارد و مسیر سنتی برای دانلودهای کامل است.

به نقل از مستندات فنی، برای فعال‌سازی این قابلیت‌ها، محیط سیستم به یک ایمیج پایه با glibc 2.34+ و دسترسی به /dev/fuse نیاز دارد. به‌دلیل اینکه تیم Hugging Face اصلاحات خاص hf-mount FUSE را به جریان اصلی (Upstream) بازگرداندند، این اتصال‌ها اکنون حتی در کانتینرهای بدون دسترسی مدیریتی (Unprivileged Containers) که پیش‌فرض بسیاری از خوشه‌های Kubernetes هستند، به‌طور بهینه کار می‌کنند.

مثال پیاده‌سازی

در پیکربندی YAML در SkyPilot، کاربر می‌تواند انواع مختلف نقاط اتصال را با استفاده از طرح hf:// تعریف کند. برای مثال:

• باکت‌های خواندن-نوشتن: برای ذخیره نقاط بازرسی، لاگ‌ها و داده‌های پردازش شده (مثلاً /checkpoints: source: hf://buckets/my-org/qwen-sft).
• مخازن مدل خواندنی: برای بارگذاری مدل‌های پایه (مثلاً /base-model: source: hf://Qwen/Qwen3.5-4B).
• مخازن داده پین‌شده: مخازن داده را می‌توان به یک نسخه خاص مانند @main متصل کرد (مثلاً /data: source: hf://datasets/my-org/my-dataset@main).

عملکرد و بنچمارک‌ها

برای تست این ادغام، تیم‌ها یک عملیات تنظیم دقیق (Fine-tuning) روی مدل Qwen/Qwen3.5-4B با مجموعه‌داده HuggingFaceH4/Multilingual-Thinking با استفاده از SFTTrainer متعلق به TRL اجرا کردند. یک پیکربندی YAML یکسان روی AWS، GCP و Lambda مستقر شد و تنها پرچم --infra تغییر کرد.

یافته‌های کلیدی عبارتند از:

• بارگذاری مدل: آماده‌سازی برای آموزش در حدود ۳۰ ثانیه با سرعت‌هایی تا ۵۰۰ مگابایت بر ثانیه. در این حالت، فقط بایت‌هایی که توسط from_pretrained لمس شدند، فراخوانی شدند.
• نوشتن نقاط بازرسی: وزن‌ها (هر کدام ۸.۴۳ گیگابایت) با سرعت‌های زیر به باکت‌ها استریم شدند:
  • AWS (us-east-2) با استفاده از L40S: حدود ۱۶۸ مگابایت/ثانیه
  • GCP (us-central1) با استفاده از L4: حدود ۱۲۳ مگابایت/ثانیه
  • Lambda (us-west-3) با استفاده از H100: حدود ۱۱۲ مگابایت/ثانیه
• هزینه: هزینه خروج داده (Egress) یا هزینه‌های CDN برای خواندن داده‌ها، بدون توجه به ارائه‌دهنده ابری، صفر بود.

حذف تکرار با Xet

در لایه‌های زیرین، باکت‌های Hugging Face بر پایه Xet ساخته شده‌اند که از تکه‌بندی محتوا-محور (Content-defined Chunking) استفاده می‌کند. این مکانیسم فایل‌ها را به تکه‌های حدود ۶۴ کیلوبایتی تقسیم کرده و هر تکه منحصر‌به‌فرد را فقط یک‌بار ذخیره می‌کند. این بدان معناست که یک ویرایش در فایل، تنها تکه‌های خاصی را که تغییر کرده‌اند، عوض می‌کند.

این ویژگی سه مزیت متمایز برای متخصصان ML دارد:
۱. نقاط بازرسی افزایشی: هنگام آموزش آداپتورها یا منجمد کردن لایه‌ها (Freezing layers)، فقط تکه‌های تغییر یافته آپلود می‌شوند. این کار نیاز به آپلود کل فایل وزن‌ها برای هر بار ذخیره‌سازی را از بین می‌برد.
۲. نسخه‌های مدل: نسخه‌های کوانتیده یا مدل‌های تنظیم‌شده که پایه مشترکی دارند، هم‌پوشانی شدیدی دارند. Xet تکه‌های مشترک را در تمام نسخه‌ها فقط یک‌بار ذخیره می‌کند.
۳. افزودن بهینه: افزودن ردیف به فایل‌های Parquet بزرگ (مانند ردپاهای گفتگو) بسیار بهینه است. در تست‌ها، افزودن ۱۰,۰۰۰ ردیف به یک جدول ۱۰۰,۰۰۰ ردیفی تنها ۱۰ مگابایت داده جابه‌جا کرد، در حالی که حجم کل حدود ۱۰۶ مگابایت بود. کاربران می‌توانند با فعال کردن use_content_defined_chunking=True هنگام ویرایش یا حذف ردیف‌ها در محل، این رفتار را تضمین کنند.

علاوه بر این، آپلود دوباره یک فایل ۸.۴۳ گیگابایتی که قبلاً در باکت موجود بود، به‌جای ۲۴ ثانیه تنها ۸ ثانیه زمان برد، چرا که فقط هش‌های تکه‌ها نیاز به انتقال داشتند. همین مکانیسم اجازه می‌دهد باکت‌های hf عملیات cp (کپی) بین مخازن را از طریق ارجاع انجام دهند، به‌جای اینکه بایت‌ها را مجدداً آپلود کنند.

احراز هویت ساده‌شده

احراز هویت تنها با یک HF_TOKEN مدیریت می‌شود. کاربران توکن را در محیط خود تنظیم کرده و با --secret HF_TOKEN به اجرای برنامه ارسال می‌کنند. این کار نیاز به مدیریت کلیدهای پیچیده و مجزا برای باکت‌های AWS، GCP، Azure، Nebius یا Lambda را از بین می‌برد.

یک توکن واحد، دسترسی به داده‌ها را بدون توجه به اینکه SkyPilot شغل را کجا زمان‌بندی می‌کند، تضمین می‌کند. SkyPilot می‌تواند منابع پردازشی را در بیش از ۲۰ ابر، Kubernetes و خوشه‌های محلی بیابد تا تضمین کند شغل روی هر GPU رزرو شده یا On-demand که در دسترس است، قرار می‌گیرد.

تحلیل: شکستن زنجیر وابستگی به ابر

این ادغام، دینامیک قدرت بین آزمایشگاه‌های AI و ارائه‌دهندگان ابر را تغییر می‌دهد. به‌طور سنتی، «مالیات خروج» (Egress Tax) — که اغلب حدود ۰.۰۹ دلار برای هر گیگابایت هنگام خروج از AWS است — به عنوان یک ابزار نرم برای حبس کاربر (Lock-in) عمل می‌کرد. وقتی داده‌های شما در S3 بود، جابه‌جایی پردازش به یک ارائه‌دهنده GPU ارزان‌تر یا در دسترس‌تر از نظر مالی غیرممکن بود.

با جداسازی ذخیره‌سازی از پردازش، SkyPilot و Hugging Face در واقع ظرفیت GPU را به یک کالای عمومی (Commodity) تبدیل می‌کنند. تیم‌ها اکنون می‌توانند بدون نگرانی از هزینه جابه‌جایی مدل‌ها، به دنبال پایین‌ترین قیمت لحظه‌ای (Spot Price) یا بالاترین دسترسی در کل بازار بگردند. این موضوع به‌ویژه وقتی مقایسه شود که هزینه ذخیره‌سازی در Hugging Face ماهانه ۱۲ تا ۱۸ دلار برای هر ترابایت است، در حالی که S3 حدود ۲۳ دلار به‌علاوه هزینه‌های خروج می‌گیرد، اثرگذارتر است.

هرچند نوشتن داده در یک باکت همچنان هزینه‌های خروج معمول ابر پردازش‌کننده را تحمیل می‌کند، اما اکثر کارهای AI در حالت «خواندن-محور» هستند. مجموعه‌داده‌ای که در چندین دوره (Epoch) استریم می‌شود یا وزن‌های مدلی که روی هر گره استنتاج جدید بارگذاری می‌گردد، حجم اصلی هزینه‌ها را ایجاد می‌کنند. با رایگان کردن بخش خواندن، Hub به یک لایه داده جهانی تبدیل می‌شود که هر GPU را در هر کجای دنیا تغذیه می‌کند.

این پروژه یک تلاش مشترک بود. پشتیبانی اولیه از store: hf به عنوان مشارکت Nikhil Jha آغاز شد. سپس تیم Hugging Face ادغام را پیش برد و اصلاحات حیاتی hf-mount FUSE را برای تضمین سازگاری با کانتینرهای بدون دسترسی (Unprivileged) ارائه داد. کل این خط لوله، شامل SkyPilot، hf-mount شرکت Hugging Face و کلاینت huggingface_hub متن‌باز است.

برای توسعه‌دهنده، حساب ذخیره‌سازی دیگر تصمیمی نیست که تعیین‌کننده ارائه‌دهنده پردازش باشد. برای شروع، کاربران می‌توانند ادغام را از طریق pip install "skypilot[huggingface]" نصب کنند، از طریق hf auth login (یا اکسپورت HF_TOKEN) احراز هویت نمایند و file_mounts خود را با استفاده از طرح hf:// پیکربندی کنند.

گام بعدی شما

• اگر مدل‌های حجیم دارید، آن‌ها را به Hugging Face Hub منتقل کنید تا از محدودیت‌های جغرافیایی S3 و GCS رهایی یابید.
• برای شروع، دستور pip install "skypilot[huggingface]" را اجرا کرده و از طرح hf:// در فایل‌های پیکربندی خود استفاده کنید.
• استراتژی استقرار خود را تغییر دهید تا از Spot Instanceهای ارزان‌تر در ابرهای مختلف بدون ترس از هزینه Egress استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.