Topik ini menggunakan model Qwen3-32B sebagai contoh untuk menunjukkan cara menyebarkan layanan inferensi model dalam Kluster Container Service for Kubernetes (ACK) menggunakan kerangka kerja Dynamo dengan arsitektur penguraian prefill-decode (PD).
Latar Belakang
Qwen3-32B
Qwen3-32B merupakan evolusi terbaru dari seri Qwen, dengan arsitektur padat 32,8B-parameter yang dioptimalkan untuk efisiensi penalaran dan kelancaran percakapan.
Fitur Utama:
Kinerja Dual-Mode: Unggul dalam tugas kompleks seperti penalaran logis, matematika, dan pembuatan kode, sambil tetap sangat efisien untuk pembuatan teks umum.
Kemampuan Canggih: Menunjukkan kinerja luar biasa dalam mengikuti instruksi, dialog multi-giliran, penulisan kreatif, dan penggunaan alat terbaik di kelasnya untuk tugas agen AI.
Jendela Konteks Besar: Secara asli menangani hingga 32.000 token konteks, yang dapat diperluas hingga 131.000 token menggunakan teknologi YaRN.
Dukungan Multibahasa: Memahami dan menerjemahkan lebih dari 100 bahasa, menjadikannya ideal untuk aplikasi global.
Untuk informasi lebih lanjut, lihat blog, GitHub, dan dokumentasi.
Dynamo
Dynamo adalah kerangka kerja inferensi berkapasitas tinggi, latensi rendah dari NVIDIA, dirancang khusus untuk melayani model bahasa besar (LLM) dalam lingkungan terdistribusi multi-node.

Fitur Utama:
Tidak Bergantung pada Mesin: Dynamo tidak terikat pada mesin inferensi tertentu dan mendukung berbagai backend seperti TensorRT-LLM, vLLM, dan SGLang.
Kemampuan Optimasi Spesifik LLM:
Penguraian PD: Memisahkan tahap prefill yang intensif komputasi dari tahap decode yang terikat memori, mengurangi latensi dan meningkatkan throughput.
Penjadwalan GPU Dinamis: Mengoptimalkan kinerja berdasarkan perubahan beban waktu nyata.
Perutean LLM Pintar: Merutekan permintaan berdasarkan cache key-value (KV) node untuk menghindari perhitungan ulang KV cache yang tidak perlu.
Transmisi Data Dipercepat: Menggunakan teknologi NVIDIA Inference Xfer Library (NIXL) untuk mempercepat transfer hasil komputasi antara dan KV cache.
Offloading KV Cache: Dapat memindahkan KV cache ke memori, disk, atau bahkan disk cloud untuk meningkatkan throughput sistem total.
Kinerja Tinggi dan Ekstensibilitas: Inti dibangun dalam Rust untuk kinerja maksimum, sementara menyediakan antarmuka Python untuk ekstensibilitas pengguna.
Sepenuhnya Open Source: Dynamo sepenuhnya open source dan mengikuti filosofi pengembangan transparan, open source-first.
Untuk informasi lebih lanjut tentang kerangka kerja Dynamo, lihat Dynamo GitHub dan Dokumentasi Dynamo.
PD penguraian
Arsitektur penguraian PD adalah teknik optimasi terdepan untuk inferensi LLM. Ini menyelesaikan permintaan sumber daya yang bertentangan dari dua tahap inti inferensi:
Tahap Prefill (Pemrosesan Prompt): Ini adalah proses yang terikat komputasi yang menangani seluruh prompt input secara paralel untuk menghasilkan cache key-value (KV) awal. Ini intensif komputasi tetapi hanya berjalan sekali di awal permintaan.
Tahap Decode (Generasi Token): Ini adalah proses auto-regresif yang terikat memori di mana token baru dihasilkan satu per satu. Setiap langkah secara komputasi kecil tetapi memerlukan akses berulang, kecepatan tinggi ke bobot model besar dan KV cache dalam memori GPU.

Masalah inti: Penjadwalan beban kerja campuran tidak efisien
Tantangannya adalah menjadwalkan dua beban kerja yang berbeda pada GPU yang sama sangat tidak efisien. Mesin inferensi biasanya menggunakan continuous batching untuk memproses beberapa permintaan pengguna secara bersamaan, mencampur tahap prefill dan decode dari permintaan yang berbeda dalam batch yang sama. Ini menciptakan konflik sumber daya: tahap prefill yang intensif komputasi (memproses seluruh prompt) mendominasi sumber daya GPU, menyebabkan tahap decode yang jauh lebih ringan (menghasilkan satu token) harus menunggu. Konflik sumber daya ini meningkatkan latensi untuk tahap decode, yang pada gilirannya meningkatkan latensi sistem keseluruhan dan secara serius menurunkan throughput.

Arsitektur penguraian PD menyelesaikan konflik ini dengan memisahkan kedua tahap dan menyebarkannya pada GPU yang berbeda, terspesialisasi.
Pemisahan ini memungkinkan sistem mengoptimalkan penjadwalan untuk setiap beban kerja secara independen. Dengan mendedikasikan GPU tertentu untuk tugas prefill dan lainnya untuk tugas decode, konflik sumber daya dihilangkan. Ini mengarah pada pengurangan signifikan dalam Rata-rata Waktu Per Token Output (TPOT) dan peningkatan substansial dalam throughput sistem keseluruhan.
RoleBasedGroup
RoleBasedGroup (RBG) adalah beban kerja Kubernetes baru yang dirancang oleh tim ACK untuk menyederhanakan penyebaran skala besar dan O&M arsitektur kompleks, seperti penguraian PD. Untuk informasi lebih lanjut, lihat Proyek GitHub RBG.
RBG didefinisikan oleh sekelompok peran, di mana setiap peran dapat dibangun berdasarkan StatefulSet, Deployment, atau jenis beban kerja lainnya. Fitur Utama:
Definisi Multi-Peran Fleksibel: RBG memungkinkan Anda mendefinisikan sejumlah peran dengan nama apa pun. Anda dapat menentukan dependensi startup di antara mereka, dan menskalakan setiap peran secara independen.
Manajemen Runtime Tingkat Grup: Menyediakan penemuan layanan otomatis dalam grup, mendukung berbagai kebijakan restart, pembaruan bergulir, dan penjadwalan gang.

Prasyarat
Kluster ACK yang dikelola menjalankan Kubernetes 1.22 atau lebih baru dengan setidaknya 6 GPU, di mana setiap GPU memiliki setidaknya 32 GB memori. Untuk informasi lebih lanjut, lihat Buat Kluster ACK yang Dikelola dan Tambahkan Node GPU ke Kluster.
Tipe instans
ecs.ebmgn8is.32xlargedirekomendasikan. Untuk informasi lebih lanjut tentang tipe instans, lihat Famili Instans ECS Bare Metal.Komponen ack-rbgs diinstal di kluster Anda. Anda dapat melakukan langkah-langkah berikut untuk menginstal komponen tersebut.
Masuk ke Konsol Manajemen Layanan Kontainer. Di panel navigasi di sebelah kiri, pilih Clusters. Klik nama kluster target. Di halaman detail kluster, instal komponen ack-rbgs menggunakan Helm. Anda tidak perlu mengonfigurasi Application Name atau Namespace untuk komponen tersebut. Setelah Anda klik Next, kotak dialog Please Confirm muncul. Klik Ya untuk menerima nama aplikasi default (ack-rbgs) dan namespace (rbgs-system). Kemudian, pilih versi Chart terbaru dan klik OK untuk menyelesaikan instalasi.

Penyebaran Model
Diagram urutan berikut menunjukkan siklus hidup permintaan dalam arsitektur penguraian PD Dynamo:
Ingesti Permintaan: Permintaan pengguna pertama kali dikirim ke komponen processor. router di dalam processor memilih decode worker yang tersedia dan meneruskan permintaan kepadanya.
Keputusan Prefill: Decode worker menentukan apakah komputasi prefill harus dilakukan secara lokal atau didelegasikan ke prefill worker jarak jauh. Jika komputasi jarak jauh diperlukan, ia mengirim permintaan prefill ke prefill queue.
Ekseskusi Prefill: Sebuah prefill worker mengambil permintaan dari antrian dan mengeksekusi komputasi prefill.
Transfer KV Cache: Setelah komputasi selesai, prefill worker mentransfer KV cache yang dihasilkan ke decode worker yang ditentukan, yang kemudian melanjutkan dengan tahap decode.

Langkah 1: Siapkan file model Qwen3-32B
Jalankan perintah berikut untuk mengunduh model Qwen3-32B dari ModelScope.
Jika plugin
git-lfsbelum diinstal, jalankanyum install git-lfsatauapt-get install git-lfsuntuk menginstalnya. Untuk metode instalasi lainnya, lihat Menginstal Git Large File Storage.git lfs install GIT_LFS_SKIP_SMUDGE=1 git clone https://www.modelscope.cn/Qwen/Qwen3-32B.git cd Qwen3-32B/ git lfs pullMasuk ke Konsol OSS dan catat nama bucket Anda. Jika Anda belum membuatnya, lihat Buat Bucket. Buat direktori di Object Storage Service (OSS) dan unggah model ke dalamnya.
Untuk informasi lebih lanjut tentang cara menginstal dan menggunakan ossutil, lihat Instal ossutil.
ossutil mkdir oss://<your-bucket-name>/Qwen3-32B ossutil cp -r ./Qwen3-32B oss://<your-bucket-name>/Qwen3-32BBuat volume persisten (PV) bernama
llm-modeldan klaim volume persisten (PVC) untuk kluster Anda. Untuk instruksi rinci, lihat Buat PV dan PVC.Contoh menggunakan konsol
Buat PV
Masuk ke Konsol ACK. Di panel navigasi di sebelah kiri, klik Clusters.
Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel navigasi di sebelah kiri, pilih .
Di halaman Volumes, klik Create di pojok kanan atas.
Di kotak dialog Create Volume, konfigurasikan parameter.
Tabel berikut menjelaskan konfigurasi dasar PV contoh:
Parameter
Deskripsi
PV Type
Dalam contoh ini, pilih OSS.
Volume Name
Dalam contoh ini, masukkan llm-model.
Access Certificate
Konfigurasikan ID AccessKey dan Rahasia AccessKey yang digunakan untuk mengakses bucket OSS.
Bucket ID
Pilih bucket OSS yang Anda buat di langkah sebelumnya.
OSS Path
Masukkan path tempat model berada, seperti
/Qwen3-32B.
Buat PVC
Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel navigasi di sebelah kiri, pilih .
Di halaman PersistentVolumeClaims, klik Create di pojok kanan atas.
Di halaman Create PersistentVolumeClaim, konfigurasikan parameter.
Tabel berikut menjelaskan konfigurasi dasar PVC contoh.
Item Konfigurasi
Deskripsi
PVC Type
Dalam contoh ini, pilih OSS.
Name
Dalam contoh ini, masukkan llm-model.
Allocation Mode
Dalam contoh ini, pilih Existing Volumes.
Existing Volumes
Klik hyperlink Select PV dan pilih PV yang Anda buat.
Contoh menggunakan kubectl
Gunakan template YAML berikut untuk membuat file bernama
llm-model.yaml, berisi konfigurasi untuk Secret, PV statis, dan PVC statis.apiVersion: v1 kind: Secret metadata: name: oss-secret stringData: akId: <your-oss-ak> # ID AccessKey yang digunakan untuk mengakses bucket OSS. akSecret: <your-oss-sk> # Rahasia AccessKey yang digunakan untuk mengakses bucket OSS. --- apiVersion: v1 kind: PersistentVolume metadata: name: llm-model labels: alicloud-pvname: llm-model spec: capacity: storage: 30Gi accessModes: - ReadOnlyMany persistentVolumeReclaimPolicy: Retain csi: driver: ossplugin.csi.alibabacloud.com volumeHandle: llm-model nodePublishSecretRef: name: oss-secret namespace: default volumeAttributes: bucket: <your-bucket-name> # Nama bucket. url: <your-bucket-endpoint> # Endpoint, seperti oss-cn-hangzhou-internal.aliyuncs.com. otherOpts: "-o umask=022 -o max_stat_cache_size=0 -o allow_other" path: <your-model-path> # Dalam contoh ini, path adalah /Qwen3-32B/. --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: llm-model spec: accessModes: - ReadOnlyMany resources: requests: storage: 30Gi selector: matchLabels: alicloud-pvname: llm-modelBuat Secret, PV statis, dan PVC statis.
kubectl create -f llm-model.yaml
Langkah 2: Instal layanan etcd dan NATS
Kerangka kerja Dynamo bergantung pada dua layanan eksternal utama: etcd untuk penemuan layanan dan NATS untuk perpesanan. Secara khusus, Dynamo menggunakan NIXL untuk komunikasi lintas node, yang mendaftarkan ke etcd untuk menemukan node lain. NATS digunakan sebagai bus pesan antara pekerja prefill dan decode. Oleh karena itu, baik etcd maupun NATS harus diterapkan sebelum memulai layanan inferensi.
Buat file bernama
etcd.yaml.Sebarkan layanan etcd.
kubectl apply -f etcd.yamlBuat file bernama
nats.yaml.Sebarkan layanan NATS.
kubectl apply -f nats.yaml
Langkah 3: Sebarkan layanan inferensi Dynamo PD-disagregasi
Topik ini menggunakan RBG untuk menyebarkan layanan Dynamo 2 prefill, 1 decode (2P1D). Baik peran prefill maupun decode akan menggunakan ukuran Tensor Parallelism (TP) sebesar 2. Arsitektur penyebaran:

Buat ConfigMap bernama
dynamo-configs.yamluntuk menyimpan konfigurasi Dynamo dan model qwen3.kubectl apply -f dynamo-configs.yamlSiapkan runtime image Dynamo.
Ikuti instruksi di Komunitas Dynamo untuk membangun atau menarik image dengan vLLM sebagai kerangka kerja inferensi.
Buat file bernama
dynamo.yamluntuk mendefinisikan RBG. Pastikan Anda mengganti placeholder dengan alamat runtime image Dynamo Anda.Sebarkan layanan tersebut.
kubectl apply -f ./dynamo.yaml
Langkah 4: Validasi layanan inferensi
Buat penerusan port antara layanan inferensi dan lingkungan lokal Anda untuk pengujian.
PentingPenerusan port yang dibuat oleh
kubectl port-forwardtidak memiliki reliabilitas, keamanan, dan skalabilitas tingkat produksi. Ini cocok untuk tujuan pengembangan dan debugging saja dan tidak boleh digunakan di lingkungan produksi. Untuk solusi jaringan siap produksi dalam kluster Kubernetes, lihat Manajemen Ingress.kubectl port-forward svc/dynamo-service 8000:8000Keluaran yang Diharapkan:
Forwarding from 127.0.0.1:8000 -> 8000 Forwarding from [::1]:8000 -> 8000Kirim permintaan sampel ke layanan inferensi model.
curl http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{"model": "qwen","messages": [{"role": "user","content": "Mari kita uji"}],"stream":false,"max_tokens": 30}'Keluaran yang Diharapkan:
{"id":"31ac3203-c5f9-4b06-a4cd-4435a78d3b35","choices":[{"index":0,"message":{"content":"<think>\nBaiklah, pengguna mengirim 'Mari kita uji'. Saya perlu mengonfirmasi maksud mereka terlebih dahulu. Mereka mungkin sedang menguji kecepatan respons saya atau fungsionalitasnya, atau mungkin mereka ingin","refusal":null,"tool_calls":null,"role":"assistant","function_call":null,"audio":null},"finish_reason":"length","logprobs":null}],"created":1753702438,"model":"qwen","service_tier":null,"system_fingerprint":null,"object":"chat.completion","usage":null}Respon JSON yang berhasil menunjukkan bahwa layanan inferensi Dynamo PD Anda berjalan dengan benar.
Referensi
Konfigurasikan Penskalaan Otomatis untuk Layanan Inferensi LLM
Beban kerja LLM sering kali berfluktuasi, menyebabkan sumber daya berlebih atau kinerja buruk selama lonjakan lalu lintas. Horizontal Pod Autoscaler (HPA) Kubernetes, yang terintegrasi dengan ack-alibaba-cloud-metrics-adapter, menyelesaikan masalah ini dengan:
Secara otomatis menskalakan pod Anda berdasarkan utilisasi GPU, CPU, dan memori waktu nyata.
Mengizinkan Anda mendefinisikan metrik khusus untuk pemicu penskalaan yang lebih canggih.
Memastikan ketersediaan tinggi selama permintaan puncak sambil mengurangi biaya selama periode idle.
Percepat Pemuatan Model dengan Caching Terdistribusi Fluid
File model besar (>10 GB) yang disimpan di layanan seperti OSS atau File Storage NAS dapat menyebabkan startup pod lambat (cold start) karena waktu unduh yang lama. Fluid menyelesaikan masalah ini dengan membuat lapisan caching terdistribusi di seluruh node kluster Anda. Ini secara signifikan mempercepat pemuatan model dalam dua cara utama:
Throughput Data Dipercepat: Fluid mengumpulkan kapasitas penyimpanan dan lebar pita jaringan dari semua node dalam kluster. Ini menciptakan lapisan data kecepatan tinggi, paralel yang mengatasi hambatan menarik file besar dari satu sumber jarak jauh.
Latensi I/O Dikurangi: Dengan menyimpan file model langsung di node komputasi tempat mereka dibutuhkan, Fluid memberikan aplikasi akses lokal, hampir instan ke data. Mekanisme baca yang dioptimalkan ini menghilangkan penundaan panjang yang terkait dengan I/O jaringan.