Saat meluncurkan layanan inferensi AI pada beberapa node, fitur penyiaran model OSS Connector hanya memuat data model dari OSS pada satu node. Node lain kemudian menerima data tersebut melalui topologi berantai. Metode ini secara signifikan mengurangi trafik kembali ke sumber (back-to-source traffic) dan meningkatkan efisiensi distribusi model.
Cara kerja
Ketika beberapa node yang menjalankan layanan inferensi AI menarik file model dari OSS secara bersamaan, aktivitas unduh tersebut dapat memenuhi bandwidth egress sumber, menciptakan bottleneck performa yang berpotensi menyebabkan penundaan atau kegagalan saat startup. Masalah ini terutama terasa di wilayah dengan bandwidth egress OSS yang lebih rendah, di mana trafik back-to-source konkuren dapat sangat memengaruhi efisiensi penerapan.
Penyiaran model OSS Connector mengoptimalkan penerapan inferensi AI skala besar. Saat beberapa instans inferensi untuk model yang sama diluncurkan, hanya satu atau beberapa node saja yang memuat data model langsung dari OSS. Data tersebut kemudian didistribusikan ke node lain melalui topologi berantai. Dengan memanfaatkan sumber daya penyimpanan dan jaringan node, penyiaran model mengurangi trafik kembali ke sumber, meringankan beban sumber, serta meningkatkan efisiensi distribusi.
Penyiaran model OSS Connector menggunakan metode transport berantai, di mana file model diteruskan secara serial dari satu node ke node berikutnya. Setiap node hanya menerima dan meneruskan data sekali. Untuk transfer file model, satu aliran data (data stream) umumnya sudah cukup untuk memenuhi bandwidth jaringan sebagian besar tipe instans mainstream. Metode berantai ini menghindari bottleneck bandwidth yang dapat terjadi pada transport berbasis pohon (tree-based), di mana satu node harus mengirim data ke beberapa node downstream secara bersamaan.
OSS Connector melakukan preload file model dari OSS ke dalam buffer memori menggunakan strategi konkurensi tinggi, sehingga mesin inferensi dapat memuat model ke Memori GPU sesuai kebutuhan. Buffer tersebut dilepas setelah jeda waktu tertentu sejak inferensi selesai. Fitur penyiaran model memperluas mekanisme ini dengan memungkinkan buffer dibagikan lintas node. Fitur ini mengintegrasikan fungsionalitas DADI P2P dan hanya memerlukan layanan Redis atau Tair untuk discovery node dan manajemen metadata. Konfigurasi ini memungkinkan data yang telah dibuffer didistribusikan ke node lain. Dibandingkan dengan penerapan node tunggal, solusi ini hanya menambahkan logika pembagian buffer yang ringan sambil memanfaatkan sepenuhnya bandwidth egress node yang menganggur selama proses pemuatan model, sehingga menghasilkan metode pemuatan model terdistribusi yang hemat biaya dan efisien.
Dengan penyiaran model, hanya satu aliran data yang ditarik dari OSS pada satu waktu untuk model tertentu. Hal ini secara signifikan mengurangi beban pada sumber OSS selama startup batch. Namun, jika performa sumber tetap menjadi bottleneck, Anda sebaiknya menggunakan fitur ini bersama OSS Accelerator atau versi cache terdistribusi dari DADI P2P.
Prasyarat
OSS Connector for AI/ML v1.2.0 atau versi yang lebih baru telah terinstal. Untuk instruksi instalasi, lihat Tingkatkan efisiensi penerapan model dengan OSS Connector for AI/ML.
Anda memiliki database Redis atau Tair yang tersedia untuk discovery node dan manajemen metadata.
Konfigurasi database
Fitur penyiaran model memerlukan layanan Redis atau Tair untuk discovery node dan manajemen metadata. Anda harus mengonfigurasi database ini untuk menggunakan fitur tersebut.
Opsi 1: Beli dan konfigurasi Tair (Direkomendasikan)
Tair adalah layanan database cloud managed penuh dari Alibaba Cloud yang kompatibel dengan protokol Redis.
Buat instans Tair. Untuk instruksi, lihat Ikhtisar quick start. Versi instans harus 6.0 atau lebih baru, dan Anda dapat menggunakan spesifikasi minimum.
Konfigurasikan daftar putih untuk memastikan bahwa node inferensi dapat mengakses instans Tair.
Anda akan memerlukan
Connection Address,Port Number,Username, danPassworduntuk mengonfigurasi penyiaran model.
Opsi 2: Deploy layanan Redis standalone
Sebagai alternatif, Anda dapat mendeploy layanan Redis sendiri di kluster Kubernetes.
Konfigurasi YAML berikut mendeploy layanan Redis dengan otentikasi Access Control List (ACL).
Buat file konfigurasi ACL dan buat rahasia (secret) Kubernetes.
# Buat konten ACL cat > users.acl << EOF user default off -@all user Username on >Password ~* &* +@all EOF # Buat secret kubectl create secret generic redis-acl-secret \ --from-file=users.acl \ --dry-run=client -o yaml | kubectl apply -f -CatatanGanti
UsernamedanPassworddengan username dan password aktual Anda.Gunakan konfigurasi berikut untuk mendeploy layanan Redis dan deployment-nya.
# redis-service.yaml apiVersion: v1 kind: Service metadata: name: redis spec: selector: app: model-redis ports: - protocol: TCP port: 6379 targetPort: 6379 --- # redis-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: model-redis-deployment spec: replicas: 1 selector: matchLabels: app: model-redis template: metadata: labels: app: model-redis spec: containers: - name: redis image: mirrors-ssl.aliyuncs.com/redis:8.4.0 ports: - containerPort: 6379 command: ["redis-server"] args: - "--aclfile" - "/etc/redis/users.acl" - "--maxmemory" - "900mb" - "--maxmemory-policy" - "volatile-lru" - "--save" - "" - "--appendonly" - "no" - "--loglevel" - "notice" resources: requests: memory: "1Gi" cpu: "100m" limits: memory: "1Gi" cpu: "200m" volumeMounts: - name: acl-config mountPath: /etc/redis/users.acl subPath: users.acl volumes: - name: acl-config secret: secretName: redis-acl-secretUntuk mendeploy layanan Redis, jalankan perintah berikut.
kubectl apply -f redis-service.yaml
Aktifkan penyiaran model
Tambahkan konfigurasi penyiaran model ke file konfigurasi OSS Connector di /etc/oss-connector/config.json.
{
...
"broadcast": {
"enableBroadcast": true,
"tenant": "${P2P_KEY_PREFIX}",
"db": {
"host": "${P2P_REDIS_HOST}",
"port": 6379,
"username": "${P2P_REDIS_USERNAME}",
"password": "${P2P_REDIS_PASSWD}"
}
},
"bindPort": 19898
...
}Tabel berikut menjelaskan parameter konfigurasi tersebut.
Parameter | Deskripsi |
broadcast.enableBroadcast | Menentukan apakah penyiaran model diaktifkan. Atur nilai ini ke |
broadcast.tenant | Menentukan nama penyewa (tenant). Node dengan nama tenant yang sama dapat menggunakan penyiaran model. Kami merekomendasikan mengonfigurasi tenant unik untuk setiap layanan. |
broadcast.db.host | Menentukan alamat koneksi layanan Redis atau Tair. |
broadcast.db.port | Menentukan nomor port layanan Redis atau Tair. Nilai default-nya adalah 6379. |
broadcast.db.username | Menentukan username untuk layanan Redis atau Tair. |
broadcast.db.password | Menentukan password untuk layanan Redis atau Tair. |
bindPort | Menentukan port yang digunakan untuk menyediakan data ke node lain. Nilai default-nya adalah 19898. |
Untuk contoh lengkap cara mendeploy layanan penyiaran model dengan beberapa instans di kluster Kubernetes, lihat Deploy layanan penyiaran model dengan beberapa instans.
Batasi ukuran cache
Selama penyiaran model, node menyimpan data model dalam memori untuk pengambilan oleh node lain. Anda dapat membatasi memori cache ini dengan cara berikut.
Metode 1: Atur variabel lingkungan
export CONNECTOR_MAX_CACHE_ADVISE_GB=100Metode 2: Atur dalam file konfigurasi
Atur
prefetch.maxCacheAdviseGBdalam/etc/oss-connector/config.json:{ ... "prefetch": { "vcpus": 16, "workers": 24, "maxCacheAdviseGB": 100 }, ... }
Batas memori merupakan batas lunak (soft limit).
Variabel lingkungan memiliki prioritas lebih tinggi daripada file konfigurasi.
Laporan performa
Berikut adalah hasil pengujian performa fitur penyiaran model dengan model Qwen2.5-72B (135,437 GB) di berbagai wilayah.
Pengujian di wilayah Beijing
Lingkungan pengujian
Item | Konfigurasi |
OSS | China (Beijing), bandwidth unduh intranet 250 Gbps |
Konfigurasi node | ecs.g9i.24xlarge, jaringan 32/48 Gbps (peak), 96 vCPU, 384 GiB |
Model | Qwen2.5-72B, 135,437 GB |
Metrik | Waktu dari startup server API vLLM hingga layanan siap digunakan, beserta trafik OSS dan P2P. |
Ukuran cache tanpa batas
Hanya satu aliran data kembali ke sumber yang digunakan, sedangkan semua data lain ditransfer melalui P2P. Hal ini meminimalkan tekanan bandwidth pada OSS.
Waktu rata-rata hingga model siap tetap mendekati O(1) dan tidak meningkat secara linear seiring bertambahnya jumlah node, menunjukkan skalabilitas horizontal yang sangat baik.
Ukuran cache terbatas
Waktu hingga model siap diuji untuk 1, 10, 50, dan 100 node yang dimulai secara bersamaan dengan ukuran cache tanpa batas dan dibatasi menjadi 100, 60, 40, 20, dan 0 GB.
Penyiaran model berfungsi sesuai harapan di bawah berbagai batas ukuran cache.
Dampak batas cache terhadap performa konsisten di semua tingkat konkurensi. Ukuran cache 40 GB atau lebih besar tidak memberikan pengaruh signifikan terhadap waktu hingga model siap. Performa mulai menurun secara nyata ketika ukuran cache 20 GB atau lebih kecil.
Pengujian di wilayah Ulanqab
Lingkungan pengujian
Item | Konfigurasi |
OSS | China (Ulanqab), bandwidth unduh intranet 10 Gbps |
Konfigurasi node | ecs.g9i.24xlarge, jaringan 32/48 Gbps (peak), 96 vCPU, 384 GiB |
Model | Qwen2.5-72B, 135,437 GB |
Waktu hingga model siap diuji untuk 1, 10, 50, dan 100 node yang dimulai secara bersamaan dengan ukuran cache tanpa batas dan dibatasi menjadi 60 dan 0 GB.
Bahkan dengan bandwidth unduh OSS yang terbatas, hasil pengujian menunjukkan bahwa penyiaran model tetap mempertahankan skalabilitas horizontal yang sangat baik dan meminimalkan tekanan bandwidth pada OSS.