# الترحيل إلى دلاء التخزين يُبيّن هذا الدليل كيفية نقل مجموعات البيانات الكبيرة إلى [Storage Bucket](./storage-buckets) من أي مكان توجد فيه حاليًا: القرص المحلي، سحابة أخرى، أو Hub. ابحث عن مصدر بياناتك في الجدول أدناه وانتقل إلى القسم المعني. في كل مكان يمكنك فيه، اجعل بياناتك قابلة للقراءة كنظام ملفات وشغّل `hf sync`. فهو يُزيل التكرار على مستوى العميل، مما يعني أنك ستحمّل عددًا أقل من البايتات مقارنةً بنسخة خام. ## لمحة عامة | أين توجد بياناتك الآن | موصى به | بدائل | |---|---|---| | قرص محلي أو نظام ملفات عنقودي | [`hf sync`](#from-local-disk-or-a-cluster-filesystem) | — | | AWS S3 أو متوافق مع S3 (R2، MinIO) | [قم بالتثبيت باستخدام `mount-s3`، ثم `hf sync`](#from-aws-s3-or-s3-compatible-storage) | [rclone عبر بوابة S3](#alternative-rclone-through-the-s3-gateway) | | Google Cloud Storage | [قم بتركيب `gcsfuse`، ثم استخدم `hf sync`](#from-google-cloud-storage-or-azure-blob-storage) | rclone، أو [مهمة](#run-the-migration-in-the-background-with-jobs) | | تخزين أزور بلوب | [قم بالتركيب باستخدام `blobfuse2`، ثم `hf sync`](#from-google-cloud-storage-or-azure-blob-storage) | rclone، أو [مهمة](#run-the-migration-in-the-background-with-jobs) | | مستودع Hub أو حاوية أخرى | [`hf buckets cp` (على جانب الخادم)](#from-a-hub-repository-or-another-bucket) | — | | بادئة S3 كبيرة جداً | [hf-s3ream (alpha)](#very-large-s3-prefixes-with-hf-s3ream) | التركيب + `hf sync`، [التقسيم حسب المسار الفرعي](#split-by-subpath-experimental) | لماذا يُعدّ `hf sync` الخيار الافتراضي: - **ترفع بيانات أقل.** يرفع `hf sync` البيانات عبر عميل [Xet](./xet/index)، الذي يقسّم بياناتك ويزيل التكرار فيها أولاً، بحيث تُرسل فقط المقاطع التي لم يسبق للمركز (Hub) رؤيتها. أما النسخ الخام (على سبيل المثال، rclone عبر بوابة S3) فينقل كل بايت. - **إنه على الأقل بنفس السرعة.** في عمليات الترحيل التي دعمناها حتى الآن، حقق `hf sync` عبر مصدر مُثبّت أداءً مماثلاً لأداء rclone أو تفوّق عليه من حيث معدل نقل البيانات. ## قبل أن تبدأ تستخدم جميع الأوامر في هذا الدليل `hf`، وهو [واجهة سطر الأوامر الخاصة بـ Hugging Face](https://huggingface.co/docs/huggingface_hub/guides/cli). مخرجات المساعدة الخاصة به قابلة للقراءة من قبل الوكلاء، لذا يمكن لوكيل البرمجة تجميع هجرة ومراقبتها نيابةً عنك (انظر [واجهة سطر الأوامر لوكلاء الذكاء الاصطناعي](./agents-cli)). راجع الأوامر قبل تنفيذها على نطاق واسع. 1. **ثبّت واجهة سطر الأوامر.** يأتي عميل Xet مدمجًا معه. ```bash curl -LsSf https://hf.co/cli/install.sh | bash hf version ``` 2. **سجّل الدخول** برمز وصول يتمتع بصلاحيات **الكتابة** ([أنشئ رمزًا](https://huggingface.co/settings/tokens)): ```bash hf auth login hf auth whoami ``` 3. **أنشئ حاوية الوجهة.** `` هو اسم المستخدم أو المنظمة. بدون `--region`، تُنشأ الحاوية في [منطقة التخزين](./storage-regions) الافتراضية للمساحة، وهي دائمًا الولايات المتحدة خارج خطط Team & Enterprise. في تلك الخطط، مرّر `--region us` أو `--region eu` للاختيار. ```bash hf buckets create / --private ``` > [!TIP] > ابدأ بتشغيل تجريبي. بغضّ النظر عن المسار الذي تستخدمه، تدرّب عليه على مجموعة فرعية صغيرة (مجلد واحد، أو نمط `--include`)، وتحقق من النتيجة باستخدام `--dry-run` و`hf buckets ls`، ثم أطلق عملية الترحيل الكاملة. يمكن استئناف كل مسار في هذا الدليل، لذا فإن التشغيل التجريبي لا يكلف شيئًا. ## من القرص المحلي أو نظام ملفات العنقود استخدم هذا عندما تكون بياناتك على قرص محلي، أو وحدة تخزين مرفقة، أو مساحة مؤقتة في العنقود: أي شيء يمكن للآلة قراءته كملفات. وهو أيضًا الخطوة الأخيرة في كل مسار سحابي أدناه، بمجرد تركيب المصدر. ```bash hf sync ./data hf://buckets///data ``` يقارن `hf sync` بين المصدر والوجهة وينقل الفرق فقط، لذا فإن إعادة تشغيل نفس الأمر يستأنف عملية الترحيل المقطوعة: يتم تخطي الملفات التي تم رفعها بالفعل. المتغيرات الشائعة: ```bash # Mirror exactly: also delete destination files that are gone from the source hf sync ./data hf://buckets///data --delete # Preview what would transfer, without uploading hf sync ./data hf://buckets///data --dry-run # Only some files hf sync ./data hf://buckets///data --include "*.parquet" --exclude "tmp/*" ``` لمراجعة هجرة كبيرة قبل تنفيذها، اكتب الخطة إلى ملف، ثم افحصه، ثم طبّقه. يقوم هذا بفحص المصدر والوجهة مرة واحدة، بدلاً من مرة للتشغيل التجريبي ومرة أخرى للتشغيل الفعلي. ```bash hf sync ./data hf://buckets///data --plan plan.jsonl # scan once, write the plan hf sync --apply plan.jsonl # run exactly that plan ``` شغّل `--apply` من المجلد الذي أنشأت فيه الخطة، لأن الخطة تسجّل مسار المصدر كما أدخلته. لا يتحقق `--apply` مما تم رفعه بالفعل، لذا لاستئناف تشغيلٍ مُقاطَع، أعد تشغيل الأمر العادي `hf sync` بدلاً من ذلك. للتحقق، تأكد من أن التشغيل التجريبي لا يحتوي على أي شيء متبقٍ للنقل، وقم بفحص عينات من المحتوى: ```bash hf sync ./data hf://buckets///data --dry-run hf buckets ls hf://buckets///data ``` ### ضبط - **احتفظ بالذاكرة المؤقتة على قرص سريع.** يخزّن عميل Xet المقاطع وفهرس إزالة التكرار (ذاكرة الشرائح المؤقتة) تحت `HF_HOME`. وجّه `HF_HOME` إلى NVMe محلي إذا لم يكن مجلد المستخدم الرئيسي على NVMe. - **تفعيل وضع الأداء العالي** للترحيلات الضخمة على جهاز مموّل جيدًا. يرفع `HF_XET_HIGH_PERFORMANCE=1` مستوى التزامن، وحجم المخازن المؤقتة، وعدد الملفات المُدخلة في آنٍ واحد، مما يتيح للعميل استخدام كل نواة معالج CPU وإشباع الشبكة. وهو مخصص للأجهزة ذات النطاق الترددي العالي والقرص السريع؛ ومع إصدارات `hf_xet` السابقة عن 1.7.0، استخدمه فقط مع ذاكرة عشوائية تبلغ 64 جيجابايت على الأقل (تحقق من ذاكرتك باستخدام `hf env`). راجع [متغيرات البيئة](./xet/using-xet-storage#environment-variables). - **حدّد حجم ذاكرة التخزين المؤقت للشظايا.** حدّ الحجم الأقصى لها مرن: يتمّ تقليص الذاكرة المؤقتة فقط عند بدء التشغيل، لذا قد تتجاوز الحدّ بكثير خلال تشغيل واحد طويل. في عملية ترحيل كبيرة، لا سيما في وضع الأداء العالي، قد تنمو إلى مئات الجيجابايت وتملأ القرص، مما يُسبّب إنهاء التشغيل. اضبط `HF_XET_SHARD_CACHE_SIZE_LIMIT` بمقدار مريح دون مساحة القرص المتاحة، لكن لا تجعله أقلّ ممّا تحتاج: ذاكرة مؤقتة بحجم *X* تُزيل التكرار مقابل ما يقارب 1000 × *X* من البيانات. راجع [ذاكرة التخزين المؤقت للشظايا](./xet/using-xet-storage#shard-cache). اضبط هذه الإعدادات قبل بدء المزامنة. تقبل الأحجام قيمًا مقروءة من قبل الإنسان مثل `64gb`: ```bash export HF_HOME=/mnt/nvme/hf # chunk and shard caches on NVMe export HF_XET_HIGH_PERFORMANCE=1 # use all cores and the full network export HF_XET_SHARD_CACHE_SIZE_LIMIT=64gb # keep the shard cache under free disk space hf sync ./data hf://buckets///data ``` ### التقسيم حسب المسار الفرعي (تجريبي) للمجموعات البيانات الكبيرة جدًا، يمكنك تقسيم المصدر إلى مسارات فرعية وتشغيل عدة عمليات `hf sync` في وقت واحد. تشير الاختبارات المبكرة إلى أن معدل الإنتاجية يتوسع بشكل خطي تقريبًا، لكن هذا يحتاج إلى مزيد من التحقق. قاعدتان: - قسّم على البيانات ذات الصلة، بحيث تُستبعد التكرارات بشكل جيد بين ملفات كل عامل. - امنح كل عامل `HF_HOME` خاصًا به حتى لا يتنافسوا على ذاكرة التخزين المؤقت. نظرًا لأن كل ذاكرة تخزين مؤقت تستهلك مساحة على القرص، فقسّم `HF_XET_SHARD_CACHE_SIZE_LIMIT` بين العمال. ```bash HF_HOME=/mnt/nvme/hf-a hf sync ./data/groupA hf://buckets///groupA & HF_HOME=/mnt/nvme/hf-b hf sync ./data/groupB hf://buckets///groupB & wait ``` تشارك عملية واحدة ذاكرة تخزين مؤقت واحدة وتُزيل التكرارات بشكل أفضل، لذا لا تقسّم إلا عندما تعجز عملية واحدة عن إشباع شبكتك. ### استكشاف الأخطاء وإصلاحها | العرض | إصلاح | |---|---| | `401` أو خطأ في المصادقة | شغّل `hf auth login` باستخدام رمز **Write**، وتحقق منه باستخدام `hf auth whoami`. | | أبطأ مما هو متوقع | ضع `HF_HOME` على NVMe، و اضبط `HF_XET_HIGH_PERFORMANCE=1`، و [شغّل بالقرب من بياناتك](#where-to-run-a-large-migration). | | يتوقف التشغيل مع خطأ امتلاء القرص | امتلىّ كاش الشرائح القرص. اضبط `HF_XET_SHARD_CACHE_SIZE_LIMIT` أقل من المساحة المتاحة لديك، أو انقل `HF_HOME` إلى قرص أكبر. | | تم مقاطعة النقل | أعد تشغيل الأمر `hf sync` نفسه. يتم تجاوز الملفات التي تم رفعها مسبقًا. | ## من AWS S3 أو تخزين متوافق مع S3 لا يقرأ `hf sync` عناوين `s3://`، لذا يجب تركيب حاوية المصدر كنظام ملفات باستخدام [Mountpoint for Amazon S3](https://github.com/awslabs/mountpoint-s3)، ثم المزامنة من نقطة التركيب. لا يزال بياناتك تمر عبر عميل Xet، مما يمنحك إزالة التكرار على جانب العميل. ```bash mount-s3 my-source-bucket /mnt/src hf sync /mnt/src hf://buckets// umount /mnt/src ``` للمخازن المتوافقة مع S3 مثل Cloudflare R2 أو MinIO، أضف `--endpoint-url ` إلى `mount-s3`. بالنسبة إلى دلو عام يسمح بالقراءات المجهولة، مثل تلك الموجودة في [سجل AWS Open Data](https://registry.opendata.aws/)، أضف `--no-sign-request`. التحقق والضبط واستكشاف الأخطاء وإصلاحها هي نفسها [بالنسبة إلى البيانات المحلية](#from-local-disk-or-a-cluster-filesystem). ### بديل: rclone عبر بوابة S3 استخدم هذا الخيار إذا كنت تشغّل rclone بالفعل وتفضّل عدم استخدام المونت. المفاضلة هنا: يرسل rclone كل بايت عبر [بوابة S3](./storage-buckets-s3) دون إزالة التكرار على مستوى العميل، لذا ينقل بيانات أكثر من `hf sync`. تحتاج إلى [بيانات اعتماد S3](./storage-buckets-s3#generating-s3-credentials) للبوابة. > [!WARNING] > استخدم rclone 1.70 أو أحدث (تحقق باستخدام `rclone version`، وقم بالترقية من [تحميلات rclone](https://rclone.org/downloads/)). قد تستنفد الإصدارات الأقدم الذاكرة عند سرد دلاء كبيرة جداً. غالباً ما ينصح في الإرشادات القديمة باستخدام [`--fast-list`](https://rclone.org/docs/#fast-list)؛ مع إصدار حديث من rclone لا تحتاج إليه، وفي حالة سرد ضخم يحتفظ بكل شيء في الذاكرة وقد يسبب نفس الفشل. أضف البوابة كعن بُعد في `~/.config/rclone/rclone.conf`، بجوار العن بُعد الخاص بمصدر البيانات (`aws` أدناه): ```ini [hf] type = s3 provider = Other endpoint = https://s3.hf.co/ access_key_id = HFAK... secret_access_key = ... region = us-east-1 force_path_style = true list_version = 2 upload_cutoff = 256M chunk_size = 256M ``` يدعم البوابة `list_version = 2` فقط، لذا يُشترط استخدام `list_version = 2`. مع 256 مليون جزء، تُقسَّم الملفات الكبيرة إلى عدد أقل بكثير من الأجزاء مقارنةً بالافتراضي في rclone البالغ 5 ملايين جزء. يحتفظ rclone بأربعة أجزاء لكل عملية نقل في الذاكرة، لذا يتطلب `--transfers 16` أدناه حوالي 16 جيجابايت من ذاكرة الوصول العشوائي؛ قم بتقليل هذا الرقم على جهاز أصغر. ثم انسخ الملفات وتحقق: ```bash rclone copy aws:my-source-bucket hf: --transfers 16 --checkers 16 --progress rclone check aws:my-source-bucket hf: ``` `rclone copy` ينقل فقط الكائنات المفقودة أو التي تم تغييرها، لذا فهو آمن لإعادة التشغيل لاستئناف العملية. قبل استيراد كبير، اقرأ [قيود البوابة](./storage-buckets-s3#limitations-and-differences-from-aws-s3)، ولا سيما قواعد تسمية مفاتيح الكائنات. ## من Google Cloud Storage أو Azure Blob Storage نفس النهج المتبع مع S3: قم بتركيب المصدر باستخدام مُشغّل سحابة المصدر الخاصة به، ثم نفّذ `hf sync`. **Google Cloud Storage**: اربطه باستخدام [gcsfuse](https://cloud.google.com/storage/docs/gcsfuse). ```bash gcsfuse my-gcs-bucket /mnt/src hf sync /mnt/src hf://buckets// ``` **Azure Blob Storage**: يُركَّب باستخدام [blobfuse2](https://learn.microsoft.com/azure/storage/blobs/blobfuse2-what-is). يحدد ملف الإعداد اسم حساب التخزين والحاوية. ```bash blobfuse2 mount /mnt/src --config-file=./blobfuse2.yaml hf sync /mnt/src hf://buckets// ``` بدون نقطة تثبيت، يمكنك استخدام rclone (يقرأ GCS وAzure بشكل أصلي؛ أعد استخدام البعيد `hf` [في الأعلى](#alternative-rclone-through-the-s3-gateway)، مع نفس تنازل عدم إزالة التكرار)، أو [نفّذ الترحيل كوظيفة](#run-the-migration-in-the-background-with-jobs). ## شغّل عملية الترحيل في الخلفية باستخدام Jobs [Jobs](./jobs) يشغّل سكربت على حوسبة Hugging Face: تختار العتاد، وتطلقه من سطر الأوامر، و[تدفع بالدقيقة](./jobs-pricing). استخدمه عندما تريد أن تعمل هجرة طويلة متعددة التيرابايت دون إشراف، بدلاً من تشغيلها على حاسوبك المحمول أو في جلسة يجب إبقاؤها مفتوحة. **1. اكتب سكربت الترحيل** (`migrate.py`). ينسخ هذا المثال كل كائن في بادئة S3 إلى دلو عبر عميل Xet، مما يؤدي إلى إزالة التكرار من عمليات الكتابة. يناسب هذا النهج نسخًا لمرة واحدة لبادئة متوسطة الحجم؛ أما للبادئات الكبيرة جدًا، فراجع [hf-s3ream](#very-large-s3-prefixes-with-hf-s3ream). عدّل الإعدادات في الأعلى: ```python # /// script # dependencies = ["huggingface_hub", "boto3", "tqdm"] # /// import boto3 from botocore import UNSIGNED from botocore.config import Config from huggingface_hub import HfFileSystem from tqdm.contrib.concurrent import thread_map # --- adapt these --- SRC_BUCKET = "my-source-bucket" SRC_PREFIX = "some/prefix/" DST = "buckets//" WORKERS = 8 # files copied in parallel # ------------------- s3 = boto3.client("s3") # AWS credentials come from the Job's secrets # For a public bucket (for example from the AWS Open Data registry), read anonymously # instead, and drop the AWS secrets from the launch command: # s3 = boto3.client("s3", config=Config(signature_version=UNSIGNED)) fs = HfFileSystem() # HF token comes from the Job's HF_TOKEN secret # List the destination once: {path: size} of the files already copied done = {path: info["size"] for path, info in fs.find(DST, detail=True).items()} # List the source and keep the objects not copied yet todo = [] pages = s3.get_paginator("list_objects_v2").paginate(Bucket=SRC_BUCKET, Prefix=SRC_PREFIX) for page in pages: for obj in page.get("Contents", []): key = obj["Key"] if key.endswith("/"): continue # folder marker: bucket keys can't end with "/" if done.get(f"{DST}/{key}") != obj["Size"]: todo.append(key) def copy(key): body = s3.get_object(Bucket=SRC_BUCKET, Key=key)["Body"] with fs.open(f"{DST}/{key}", "wb") as out: for chunk in iter(lambda: body.read(64 << 20), b""): out.write(chunk) # Copy WORKERS files at a time, with a progress bar thread_map(copy, todo, max_workers=WORKERS) ``` - يُخزَّن كل كائن مؤقتًا على قرص المهمة ثم يُرفع عند إغلاقه، لذا يجب أن يتسع القرص لعدد `WORKERS` من أكبر الكائنات لديك في آنٍ واحد. ارفع قيمة `WORKERS` لتسريع رفع العديد من الكائنات الصغيرة، وخفّضها في حال كانت الكائنات كبيرة جدًا. - تُتخطى الملفات الموجودة مسبقًا في الدلو والتي لها نفس الحجم، لذا فإن إعادة تشغيل السكربت تستأنف عملية النسخ المقطوعة. لن يعيد السكربت نسخ ملف المصدر الذي تغيّر لكنه احتفظ بحجمه: للحفاظ على مزامنة الدلو مع مصدر متغيّر، [ركّب المصدر وشغّل `hf sync`](#from-aws-s3-or-s3-compatible-storage) بدلاً من ذلك. في حالة استخدام GCS أو Azure، استبدل `boto3` بـ SDK الخاص بذلك السحابة (`google-cloud-storage`، `azure-storage-blob`) وعدّل استدعاءات القائمة والقراءة. يبقى الجزء الخاص بالوجهة كما هو. **2. شغّله كمهمة في الخلفية**، مع تمرير بيانات الاعتماد الخاصة بك كقيم سرية: ```bash hf jobs uv run --detach --flavor cpu-performance --timeout 24h \ --secrets HF_TOKEN \ --secrets AWS_ACCESS_KEY_ID \ --secrets AWS_SECRET_ACCESS_KEY \ migrate.py ``` يمرّر كل `--secrets NAME` قيمة ذلك المتغير من بيئة التشغيل (في حالة `HF_TOKEN`، يُستخدم رمز الدخول الخاص بك إذا لم يكن مُعيَّنًا). تتوقف المهام بعد 30 دقيقة افتراضيًا، لذا عيّن `--timeout` بقيمة كافية لإتمام النقل بالكامل؛ وإذا توقفت مهمة مبكرًا، أعد تشغيلها وستتخطى الملفات التي تم نسخها بالفعل. يعيد `--detach` معرّف المهمة (Job ID) فورًا. يمكنك متابعة التقدم باستخدام `hf jobs logs -f `، وعرض قائمة التشغيلات باستخدام `hf jobs ls`، ومشاهدة خيارات الأجهزة باستخدام `hf jobs hardware`. ## من مستودع Hub أو حاوية أخرى إذا كانت البيانات موجودة مسبقًا على Hub، في مستودع نموذج أو مجموعة بيانات أو حاوية أخرى، انسخها على جانب الخادم. بالنسبة للملفات التي تتبعتها [Xet](./xet/index) فقط، تنتقل تجزئات المحتوى فقط، لذا يكون النسخ شبه فوري ولا يتم إعادة رفع أي شيء. ```bash # From a dataset repository into a bucket hf buckets cp hf://datasets/// hf://buckets/// # From one bucket to another hf buckets cp hf://buckets/// hf://buckets/// ``` - يجب أن يكون المصدر والوجهة في نفس منطقة التخزين. - تحتاج إلى صلاحية القراءة للمصدر وصلاحية الكتابة للوجهة. - تُحمَّل الملفات الصغيرة غير المُتتبَّعة بواسطة Xet (مثل ملفات الإعدادات وملفات README) وتُعاد رفعها تلقائيًا. - لا يتوفر نسخ البيانات من الدلو (bucket) إلى المستودع (repository) بعد؛ وهو مدرج في خارطة الطريق. راجع [نسخ الملفات بين المستودعات والخزانات](./storage-buckets#copying-files-between-repos-and-buckets) للحصول على ما يعادلها بلغة بايثون. ## بادئات S3 كبيرة جداً مع hf-s3ream > [!WARNING] > أداة hf-s3ream هي أداة مجتمعية في مرحلة مبكرة (تجريبية) وليست منتجًا مدعومًا رسميًا من Hugging Face. اختبرها على بادئة صغيرة قبل استخدامها في هجرة كبيرة. يعمل [hf-s3ream](https://huggingface.co/spaces/glutamatt/hf-s3ream) ([المصدر على GitHub](https://github.com/glutamatt/hf-s3ream)، Apache-2.0) على نسخ كبير من S3 إلى bucket من واجهة ويب: 1. سجّل الدخول باستخدام Hugging Face. 2. أدخل بادئة المصدر في S3، ودلو الوجهة، ومعرّفات AWS الخاصة بك. بالنسبة لدلو عام يسمح بالقراءات المجهولة، فعّل **دلو عام**: لا حاجة إلى معرّفات AWS، وتقرأ Jobs من S3 دون توقيع. 3. يُنفّذ **Analyze** تشغيلًا تجريبيًا منخفض التكلفة يتحقق من الوصول، ويكتشف منطقة المصدر، ويوصي بإعداد مناسب. كما ينشئ حاوية الوجهة (خاصة) إذا لم تكن موجودة. 4. يُطلق **Run** مهمة مخطط. يبني المخطط خطة نسخ مبنية على نطاقات، ويبدأ مهام النسخ، ويعرض التقدم على رسم بياني حي. يستمر النسخ في العمل إذا أغلقت التبويب، لكن الصفحة لن تعيد الاتصال به. لإيقاف النسخ، انقر على **Stop copy**، أو ألغِ مهمة المخطط (`hf jobs cancel `): يلغي المخطط مهام النسخ الخاصة به. يعمل hf-s3ream على [Jobs](./jobs) ضمن حسابك، لذا تُحتسب فواتير الـ Jobs عليك. لا يمكن الوصول إلى دلاء S3 التي تسمح بالوصول من شبكة خاصة (VPC) فقط من خلال الـ Jobs. ## أين تُنفَّذ هجرة كبيرة في حالة هجرة بيانات متعددة التيرابايت، ستقوم عادةً بتشغيل عملية النقل على آلة افتراضية سحابية بدلاً من حاسوب محمول. إذا كنت تفضّل عدم إدارة آلة افتراضية، [قم بتشغيلها كعملية](#run-the-migration-in-the-background-with-jobs). - **شغّل العملية في نفس السحابة والمنطقة التي يوجد فيها المصدر.** قراءة المصدر عبر الشبكة المحلية هي الأسرع والأرخص، وغالبًا ما تكون تكلفة الإخراج من سحابة المصدر هي التكلفة الأكبر. ثم تتم عمليات الرفع عبر الإنترنت إلى Hugging Face (تقع منطقة الولايات المتحدة في AWS `us-east-1`). - **استخدم عملية واحدة مع العديد من الخيوط.** عملية `hf sync` واحدة في وضع الأداء العالي تشارك ذاكرة تخزين مؤقت واحدة لإزالة التكرار. [قسّم حسب المسار الفرعي](#split-by-subpath-experimental) فقط عندما لا تستطيع عملية واحدة إشباع شبكتك. - **حافظ على استمرار المهام الطويلة.** عند استخدام SSH، ابدأ عملية الترحيل داخل [`tmux`](https://github.com/tmux/tmux/wiki) (أو `screen`، أو `nohup`) حتى تبقى العملية قائمة في حال انقطاع الجلسة: `tmux new -s migrate`، ثم افصل عن الجلسة بالضغط على Ctrl-b ثم d، وأعد الاتصال بها لاحقًا باستخدام `tmux attach -t migrate`. نقاط البداية لتحديد الحجم، للتحقق منها في تشغيل تجريبي: | الموارد | إرشادات | مثال AWS | مثال GCP | |---|---|---|---| | قرص | NVMe محلي لـ `HF_HOME`، مع مساحة حرة تتجاوز حد كاش الشرائح الخاص بك. تجنّب استخدام الأقراص المتصلة بالشبكة للكاش. | NVMe مخزن الحالة (`c7i`/`m7i` `d` المتغيرات، أو `i4i`) | وحدة SSD محلية على جهاز افتراضي من نوع `n2` أو `c3` | | وحدة المعالجة المركزية | عدد كبير من وحدات المعالجة الافتراضية: يقوم العميل بتقسيم البيانات وتجزئتها على وحدة المعالجة المركزية. | `c7i.8xlarge` أو أكبر | `c3-standard-22` أو أكبر | | الذاكرة | مساحة كافية لذاكرة التخزين المؤقت في وضع الأداء العالي؛ 64 جيجابايت على الأقل مع `hf_xet` قبل الإصدار 1.7.0. | — | — | | الشبكة | نطاق ترددي عالٍ إلى الإنترنت (من فئة 25 جيجابت في الثانية). | — | — | ## الخطوات التالية - **استخدم البيانات في مكانها.** قم بتركيب الدلو كنظام ملفات محلي باستخدام [hf-mount](./storage-buckets-access#mount-as-a-local-filesystem)، أو كـ[حجم في Jobs وSpaces](./storage-buckets-access#volume-mounts-in-jobs-and-spaces). - **اقرأ البيانات من أدواتك.** تقرأ pandas وDask وPyArrow وDaft وDuckDB و🤗 Datasets وSpark مسارات `hf://buckets/...` مباشرة. راجع [تكاملات الدلاء](./storage-buckets-integrations). > [!WARNING] > لا تقم بتنفيذ عملية استيراد كبيرة عبر نقطة تركيب. يقوم `/tmp/hf-mount-cache` بتخزين عمليات الكتابة مؤقتًا في ذاكرة تخزين مؤقت على القرص (افتراضيًا في `/tmp/hf-mount-cache`)، وقد يؤدي تنفيذ هجرة كبيرة عبره إلى امتلاء ذلك القرص. استخدم أحد المسارات المذكورة أعلاه لوضع البيانات في الدلو. إذا كان عليك كتابة كميات كبيرة عبر نقطة تركيب، فوجّه ذاكرة التخزين المؤقت إلى قرص يتوفر فيه مساحة حرة كافية: `hf-mount start --cache-dir /mnt/big bucket / /mnt/data` (يُوضع هذا العلم قبل `bucket`).