Platform For AI:Akselerasi cache lokal Lingjun

Konsep utama

Cache lokal mencakup kemampuan berikut:

• High-speed caching: Menggunakan disk lokal pada node komputasi untuk membangun cache baca, mempercepat akses dataset dan checkpoint, serta mengurangi latensi akses data.

• Horizontal scaling: Throughput cache meningkat secara linear seiring bertambahnya jumlah node komputasi, mendukung kluster mulai dari ratusan hingga ribuan node.

• RDMA high-bandwidth acceleration: Menggunakan protokol RDMA (Remote Direct Memory Access) untuk memaksimalkan bandwidth jaringan berkecepatan tinggi dalam kondisi pembacaan data berkonkurensi tinggi, sehingga meningkatkan throughput.

• Data warm-up: Memuat data tertentu ke dalam cache lokal sebelum pekerjaan pelatihan dimulai, mencegah penundaan cold-start pada epoch pertama.

• Client-side bandwidth throttling: Membatasi bandwidth baca per klien pekerjaan DLC untuk mencegah satu pekerjaan menghabiskan bandwidth penyimpanan secara berlebihan dan memengaruhi pekerjaan lain.

• Serverless operation: Aktifkan atau nonaktifkan hanya dengan satu klik. Tidak diperlukan perubahan kode. Fitur ini non-intrusif dan tidak memerlukan pemeliharaan operasional.

Kasus penggunaan

Cache lokal cocok untuk pekerjaan pelatihan multi-epoch di mana ukuran dataset jauh lebih besar daripada data yang dibaca dalam satu kali traversal dan data tersebut diakses berulang kali. Akselerasi RDMA, data warm-up, dan client-side bandwidth throttling masing-masing menangani karakteristik pelatihan yang berbeda dan dapat dikombinasikan sesuai kebutuhan:

Batasan

• Dukungan penyimpanan: Object Storage Service (OSS) dan CPFS (Cloud Parallel File System) didukung.

• Sumber daya yang berlaku: Hanya sumber daya komputasi Lingjun. Saat diaktifkan, sumber daya node komputasi akan dikonsumsi: pemasangan satu sistem file atau bucket OSS menggunakan 4 vCPU dan 14 GB memori per node; setiap pemasangan tambahan menggunakan 1 vCPU dan 2 GB memori. Cadangkan sumber daya sebelum mengaktifkan.

• Konsumsi sumber daya RDMA: Dalam mode RDMA, pemasangan satu sistem file atau bucket OSS menggunakan 8 vCPU dan 16 GB RAM per node; setiap pemasangan tambahan menggunakan 1 vCPU dan 2 GB memori. Node harus memiliki kartu jaringan RDMA; node Lingjun spesifikasi tinggi mendukung ini secara default.

• Kapasitas dan kebijakan penggantian: Kapasitas cache maksimum bergantung pada tipe instans Lingjun. Kebijakan penggantian adalah LRU (Least Recently Used).

• Cakupan akselerasi: Hanya akselerasi baca. Operasi tulis tidak dipercepat.

• Ketersediaan data: Ketersediaan tinggi tidak dijamin. Data cache dapat hilang. Segera backup data pelatihan penting.

• Kinerja epoch pertama: Epoch pertama membaca dari instance penyimpanan (misalnya OSS atau CPFS) dan menulis ke cache, yang sedikit lebih lambat daripada membaca langsung dari penyimpanan. Epoch berikutnya membaca langsung dari cache lokal dengan kecepatan lebih tinggi. Untuk menghindari perlambatan pada epoch pertama, gunakan data warm-up.

Mengaktifkan akselerasi cache lokal

Untuk mengaktifkan akselerasi cache lokal, lengkapi langkah-langkah berikut:

1. Aktifkan cache lokal untuk kuota sumber daya.

2. Konfigurasikan aturan inbound grup keamanan.

3. Buat pekerjaan DLC dengan cache diaktifkan.

4. Opsional: konfigurasikan akselerasi RDMA, client-side bandwidth throttling, dan data warm-up.

   Langkah 1: Aktifkan cache lokal untuk kuota sumber daya

   1. Di panel navigasi kiri, klik Resource Quota > Intelligent Computing LINGJUN Resources, temukan nama kuota target, lalu klik untuk membuka halaman manajemen.

      Catatan

      Untuk kuota bersarang multi-level, hanya kuota level atas yang mendukung pengaktifan cache lokal.

   2. Beralih ke tab Local cache, aktifkan Local cache acceleration, dan tetapkan jalur penyimpanan yang akan di-cache. Jalur cache harus mengarah ke direktori penyimpanan tempat data pelatihan Anda berada.

      

   3. Untuk menggunakan akselerasi RDMA, aktifkan sakelar Supports RDMA di halaman konfigurasi cache.

   Langkah 2: Konfigurasikan aturan inbound grup keamanan

   Untuk grup keamanan enterprise, konfigurasikan aturan inbound untuk mengizinkan layanan cache berkomunikasi melalui jaringan VPC.

   1. Di halaman kuota sumber daya, temukan nama atau ID grup keamanan di bagian informasi jaringan.

   2. Buka grup keamanan tersebut. Jika tipe grup keamanan adalah Enterprise, tambahkan aturan inbound dengan pengaturan berikut:

      • Tetapkan kebijakan otorisasi ke Allow.

      • Tetapkan prioritas ke 1.

      • Tetapkan protokol ke Custom TCP.

      • Tetapkan sumber ke IPv4 dan masukkan Blok CIDR VPC, misalnya 10.0.0.0/8.

      • Tetapkan rentang port tujuan ke 10080/(10080+n-1) dan 10070/(10070+n-1), di mana n adalah jumlah entri layanan penyimpanan (n ≤ 10). Misalnya, dengan 4 layanan penyimpanan dikonfigurasi, buka port 10080/10083 dan 10070/10073.

   Catatan

   Tetapkan sumber ke Blok CIDR vSwitch yang digunakan oleh kuota sumber daya. Jumlah port tujuan harus sesuai dengan jumlah layanan penyimpanan dalam konfigurasi cache.

   Langkah 3: Buat pekerjaan DLC dengan cache diaktifkan

   1. Buat pekerjaan DLC (Distributed Learning Container) menggunakan sumber daya Lingjun dari kuota sumber daya target.

   2. Saat mengonfigurasi parameter Storage Mount untuk pekerjaan DLC, pilih URI mount OSS dan jalur mount (misalnya, /mnt/data/).

   3. Jika alamat penyimpanan yang dimount sesuai dengan jalur cache yang dikonfigurasi, sakelar Use Cache akan otomatis diaktifkan (Anda dapat menonaktifkannya jika diperlukan).

      

   Langkah 4: Konfigurasikan client-side bandwidth throttling (opsional)

   Saat membuat pekerjaan DLC, tambahkan parameter mountOptions dalam konfigurasi dataset lanjutan untuk membatasi bandwidth baca per klien:

   {
     "mountOptions": "-o g_tier_DadiSdkGetTrafficLimit=3221225472"
   }

   Deskripsi parameter:

   • g_tier_DadiSdkGetTrafficLimit: Ambang batas pembatas laju baca klien, dalam B/s (byte per detik). Nilai default adalah 3221225472 (3 GB/s).

   Nilai pembatas laju umum:

   Batas target	Nilai (B/s)
   1 GB/s	1073741824
   3 GB/s (default)	3221225472
   4 GB/s	4294967296
   5 GB/s	5368709120

   Langkah 5: Siapkan data warm-up (opsional)

   Sebelum pekerjaan pelatihan dimulai, gunakan data warm-up untuk memuat data tertentu ke dalam cache lokal dan menghindari penundaan cold-start pada epoch pertama.

   Konsol

   Buat tugas warm-up

   1. Di tab Local cache, gulir ke bagian Data warm-up dan klik + Create warm-up task di pojok kanan atas.

      

   2. Di kotak dialog, isi bidang berikut sesuai kebutuhan:

      Bidang	Wajib	Deskripsi	Rekomendasi
      Cache data source	Ya	Pilih dari dropdown. Hanya instance penyimpanan yang dikonfigurasi di Langkah 1 yang tersedia.	Pilih bucket tempat pekerjaan pelatihan Anda membaca data.
      Warm-up subdirectory	Tidak	Tentukan subdirektori dalam sumber data yang dipilih. Masukkan jalur secara manual atau klik ikon folder untuk menjelajahi. Biarkan kosong untuk melakukan warm-up seluruh sumber data.	Tentukan subdirektori dataset atau checkpoint untuk mengurangi trafik yang tidak perlu.
      Match pattern	Tidak	Ekspresi reguler relatif terhadap subdirektori. Default-nya adalah .* (cocokkan semua).	Misalnya, untuk melakukan warm-up hanya file JPEG: .*\.jpg$.

   3. Untuk melakukan warm-up beberapa lokasi, klik + Add path di bagian bawah untuk menambahkan entri lain. Klik ikon hapus di awal baris untuk menghapusnya.

   4. Klik OK untuk mengirimkan. Tugas langsung muncul di daftar data warm-up.

   Hanya satu tugas warm-up yang berjalan dalam satu waktu per instance cache. Tugas tambahan akan masuk antrian dalam urutan FIFO dan tetap dalam status Creating. Volume warm-up total tidak boleh melebihi kapasitas cache, atau data akan diganti oleh kebijakan LRU.

   Lihat progres warm-up

   Daftar tugas warm-up menampilkan informasi berikut: ID tugas, jalur (sumber data + subdirektori + pola pencocokan), status, waktu pembuatan, waktu penyelesaian, jumlah file/byte yang cocok, dan alasan kegagalan.

   Deskripsi status:

   • Creating: Telah dikirim dan dalam antrian untuk dieksekusi.

   • Running: Menarik data ke dalam cache lokal.

   • Completed: Warm-up selesai dan cache telah dimuat.

   • Cancelled: Dibatalkan secara manual.

   • Failed: Warm-up gagal. Periksa alasan kegagalannya. Penyebab umum: jalur tidak ada, atau tidak ada file yang cocok dengan pola.

   Batalkan atau hapus tugas warm-up

   • Untuk tugas dengan status Creating atau Running, klik Cancel di akhir baris untuk menghentikan tugas.

   • Catatan Completed atau Failed hanya disimpan untuk keperluan audit dan dapat dihapus langsung.

   Penting

   Pastikan tidak ada pekerjaan pelatihan yang sedang berjalan bergantung pada cache saat ini sebelum mematikan sakelar utama akselerasi cache lokal. Mematikan sakelar ini akan menghapus semua catatan warm-up dan data cache.

   API

   Tentukan port warm-up

   Setiap entri konfigurasi cache memiliki port warm-up khusus dalam rentang 10070–10079:

   Indeks cache	Warm-up Port
   Cache ke-1	10070
   Cache ke-2	10071
   Cache ke-3	10072

   Jalankan data warm-up

   Jalankan perintah berikut di instance DSW (Data Science Workshop) atau DLC dalam kuota yang sama untuk memulai warm-up:

   Note: API warm-up hanya dapat dipanggil dari instance DSW atau DLC dalam kuota yang sama dengan layanan cache. Instance DSW memiliki izin role yang diperlukan secara default dan tidak memerlukan konfigurasi tambahan.

   # Jika isShareded = true dalam respons getDataCacheService, gunakan perintah ini:
   curl -s "http://<CacheServiceId>-svc-0.t<AccountId>.svc.cluster.local.<clusterId>.t<AccountId>:<Port>/v1/warmup/load?target_path=<path1>,<path2>&pattern=<glob_pattern>"
   
   # Jika tidak, gunakan perintah ini:
   curl -s "http://<CacheServiceId>.t<AccountId>.svc.cluster.local.<clusterId>.t<AccountId>:<Port>/v1/warmup/load?target_path=<path1>,<path2>&pattern=<glob_pattern>"

   Deskripsi parameter:

   • isShareded: Di halaman detail kuota di konsol, buka tab Local cache, buka developer tools browser (F12), dan periksa bidang isShareded dalam respons API getDataCacheService.

   • CacheServiceId: Panggil API GetQuota untuk menanyakan kuota sumber daya target. Ambil CacheServiceId dari respons kuota level atas (kuota sumber daya level pertama).

   • <primary account ID>: Di konsol, klik avatar pengguna di pojok kanan atas untuk melihat ID akun utama Anda.

   • clusterId: Sama seperti isShareded — periksa respons API getDataCacheService.

   • Port: Port warm-up yang ditentukan pada langkah sebelumnya.

   • target_path: Jalur yang akan di-warm-up, dengan beberapa jalur dipisahkan koma. Harus berupa jalur relatif di bawah direktori mount. Misalnya, untuk melakukan warm-up /path1/path2 pada BMCPFS, tetapkan target_path=path1/path2.

   • pattern (opsional): Pola pencocokan file yang mendukung ekspresi reguler. Misalnya, pattern=.*.txt hanya melakukan warm-up file .txt.

   Contoh:

   # Lakukan warm-up semua file .txt di bawah dataset/train dalam direktori mount
   curl -s "http://cacheservice-xxxx:t10953*******.svc.cluster.local.ca076dea628***********.t10953*******:10070/v1/warmup/load?target_path=dataset/train&pattern=.*.txt"

   Periksa status warm-up

   Jalankan perintah berikut untuk memeriksa progres warm-up:

   # Jika isShareded = true dalam respons getDataCacheService, gunakan perintah ini:
   curl -s "http://<CacheServiceId>-svc-0.t<AccountId>.svc.cluster.local.<clusterId>.t<AccountId>:<Port>/v1/warmup/stat?target_path=<path1>,<path2>&preceding_time=<minutes>"
   
   # Jika tidak, gunakan perintah ini:
   curl -s "http://<CacheServiceId>.t<AccountId>.svc.cluster.local.<clusterId>.t<AccountId>:<Port>/v1/warmup/stat?target_path=<path1>,<path2>&preceding_time=<minutes>"

   Deskripsi parameter:

   • target_path: Jalur yang sama seperti yang digunakan dalam permintaan warm-up.

   • preceding_time: Tanyakan status warm-up untuk N menit terakhir.

   Contoh:

   # Periksa status warm-up untuk dataset/train dalam 10 menit terakhir
   curl -s "http://cacheservice-xxxx:t10953*******.svc.cluster.local.ca076dea628***********.t10953*******:10070/v1/warmup/stat?target_path=dataset/train&preceding_time=10"

   Catatan penggunaan

   • API warm-up hanya dapat dipanggil dari instance DSW atau DLC dalam kuota yang sama dengan layanan cache.

   • target_path harus menggunakan jalur relatif terhadap direktori mount. Jangan gunakan jalur mutlak.

   • Untuk kuota sumber daya bersarang multi-level, pastikan CacheServiceId berasal dari kuota sumber daya level atas (level pertama).

   • Warm-up berjalan secara asinkron. Lacak progres dengan API /v1/warmup/stat.

FAQ