Workload Large Language Model (LLM) menghadirkan tantangan seperti panjang permintaan yang bervariasi, generasi token acak, dan pemanfaatan GPU yang fluktuatif. Load balancer tradisional tidak dapat mendeteksi tekanan backend secara real-time, sehingga menyebabkan beban instans tidak merata dan menurunkan kinerja sistem. Untuk mengatasi masalah ini, EAS menyediakan router cerdas LLM—layanan yang mengintegrasikan penjadwalan cerdas dan O&M tervisualisasi. Layanan ini menyeimbangkan daya komputasi dan memori GPU secara dinamis berdasarkan metrik LLM real-time untuk memastikan throughput tinggi dan stabilitas. Workbench WebUI bawaannya menyediakan pemantauan langsung, pembaruan konfigurasi dinamis, serta manajemen kunci API multi-pengguna dengan isolasi identitas guna mengurangi kompleksitas operasional secara signifikan.
Cara kerja
Komponen inti
Layanan router cerdas LLM terdiri dari dua komponen inti berikut:
-
LLM Gateway: Titik masuk trafik dan pusat pemrosesan permintaan. Komponen ini menerima permintaan pengguna dan meneruskannya ke instans inferensi target berdasarkan keputusan dari
LLM Scheduler.-
Mendukung protokol HTTP (HTTP_SSE) dan WebSocket.
-
Secara default, fitur konversi protokol Anthropic API diaktifkan. Fitur ini secara otomatis mengonversi permintaan yang sesuai dengan Anthropic ke format yang kompatibel dengan OpenAI, sehingga Anda dapat menggunakan alat ekosistem seperti Claude Code untuk memanggil layanan model yang mengikuti standar API OpenAI tanpa perlu modifikasi kode. Untuk informasi lebih lanjut, lihat Gunakan Claude Code untuk melakukan panggilan.
-
-
LLM Scheduler: Mesin penjadwalan cerdas. Komponen ini memilih instans target optimal untuk setiap permintaan berdasarkan kebijakan penjadwalan, seperti routing berbasis prefix-cache.
Alur kerja
Berikut adalah alur kerja utama:
-
Menerima permintaan: Permintaan pengguna tiba di
LLM Gateway. Jika instans inferensi backend mengalami beban tinggi, gateway akan mengantrikan permintaan tersebut. -
Penjadwalan cerdas:
LLM Gatewaymengirim permintaan penjadwalan keLLM Scheduler.LLM Schedulerkemudian memilih instans optimal berdasarkan kebijakan penjadwalan dan metrik real-time dari setiap instans. -
Meneruskan permintaan: Setelah menerima keputusan penjadwalan,
LLM Gatewaymeneruskan permintaan pengguna langsung ke instans yang dipilih.
Mekanisme failover
Mekanisme toleransi kesalahan berlapis memastikan stabilitas layanan:
-
LLM Gateway: Kami merekomendasikan untuk menerapkan minimal dua instans. Jika suatu instans gagal, trafik secara otomatis dialihkan ke instans yang sehat.
-
LLM Scheduler: Jika penjadwal gagal,
LLM Gatewaysecara otomatis kembali ke routing round-robin. Hal ini memastikan ketersediaan dengan mengorbankan penjadwalan cerdas. Ketika penjadwal pulih, penjadwalan cerdas akan dilanjutkan secara otomatis. -
Instans inferensi: Jika instans inferensi gagal,
LLM Schedulersegera menghapusnya dari pool yang tersedia dan menghentikan pengiriman trafik baru ke instans tersebut. Setelah instans pulih, penjadwal secara otomatis menambahkannya kembali ke dalam pool.
Batasan
-
Persyaratan grup layanan:
-
Router cerdas LLM harus diterapkan dalam grup layanan yang sama dengan layanan inferensi agar berfungsi dengan benar.
-
Layanan router cerdas dan layanan antrian tidak dapat berada dalam satu grup layanan yang sama.
-
-
Layanan router cerdas hanya dapat dikonfigurasi saat membuat layanan inferensi baru: Keanggotaan grup layanan ditetapkan saat pembuatan dan tidak dapat diubah nanti. Oleh karena itu, fitur routing cerdas hanya dapat dikonfigurasi saat Anda membuat layanan inferensi baru. Anda tidak dapat menggunakan aksi Update service untuk menambahkan atau mengubah routing cerdas pada layanan inferensi yang sudah ada.
-
Batasan mesin inferensi: Hanya vLLM atau SGLang yang didukung.
-
Tidak kompatibel dengan NLB dan Nacos: Anda tidak dapat menggunakan router cerdas LLM dengan layanan inferensi yang diekspos melalui NLB atau Nacos.
-
Direkomendasikan menggunakan beberapa instans: Router cerdas LLM memberikan manfaat penjadwalan hanya jika Anda menerapkan beberapa instans inferensi.
Memulai cepat: router cerdas LLM
Langkah 1: Terapkan router cerdas LLM
-
Login ke Konsol PAI dan pilih wilayah target di bagian atas halaman.
-
Di panel navigasi sebelah kiri, klik Elastic Algorithm Service (EAS). Di halaman EAS, pilih ruang kerja target.
-
Klik Deploy Service, lalu pilih Scenario-based Model Deployment > Deploy LLM gateway.
-
Konfigurasikan parameter:
Parameter
Deskripsi
Basic Information
Service Name
Masukkan nama kustom untuk layanan, misalnya,
llm_gateway.Resource Information
Deployment Resources
Menentukan konfigurasi resource untuk
LLM Gateway. Untuk ketersediaan tinggi, Number of Replicas diatur ke 2 secara default; kami merekomendasikan untuk mempertahankan pengaturan ini. Konfigurasi default adalah 4 vCPUs dan 8 GB memory.Scheduling configuration
Menentukan konfigurasi resource untuk
LLM Scheduler. Default-nya adalah 2 vCPUs dan 4 GB memory.Scheduling Policy
Kebijakan penyeimbangan beban untuk instans inferensi backend. Default-nya adalah Prefix cache. Untuk perbandingan detail guna membantu Anda memilih, lihat Referensi kebijakan penjadwalan.
Advanced Features
Redis config
Opsional. Mempertahankan informasi pengguna dan statistik penggunaan. Jika tidak dikonfigurasi, layanan menggunakan memori lokal, dan data akan hilang ketika layanan dihentikan. Untuk detailnya, lihat Konfigurasi penyimpanan persisten Redis.
-
Klik Deploy. Saat status layanan berubah menjadi Running, penerapan berhasil.
Setelah penerapan, sistem secara otomatis membuat grup layanan bernama group_<nama layanan router cerdas LLM>. Untuk melihat grup tersebut, buka halaman Elastic Algorithm Service (EAS) dan klik tab Group Service.
Langkah 2: Terapkan layanan LLM
Anda harus mengonfigurasi fitur router cerdas saat menerapkan layanan LLM baru. Anda tidak dapat menambahkan fitur ini ke layanan yang sudah ada melalui aksi Update.
Langkah-langkah berikut menggunakan penerapan Qwen3-8B sebagai contoh:
-
Klik Deploy Service, lalu pilih Scenario-based Model Deployment > LLM Deployment.
-
Konfigurasikan parameter kunci berikut:
Parameter
Nilai
Basic Information
Model Settings
Pilih Public Model, lalu cari dan pilih Qwen3-8B.
Inference Engine
Pilih vLLM (direkomendasikan; kompatibel dengan API OpenAI).
CatatanJika layanan router cerdas LLM menggunakan scheduling policy Prefix cache dan Anda memilih vLLM sebagai mesin inferensi, pastikan fitur prefix caching diaktifkan untuk mesin tersebut.
Deployment Template
Pilih Single node. Sistem kemudian secara otomatis mengisi spesifikasi instans, image, dan parameter lain yang direkomendasikan dari templat.
Features
LLM Intelligent Router
Aktifkan toggle dan pilih layanan router cerdas LLM yang diterapkan pada Langkah 1 dari daftar drop-down.
-
Klik Deploy. Penerapan membutuhkan waktu sekitar 5 menit. Saat status layanan berubah menjadi Running, penerapan berhasil.
Langkah 3: Uji layanan
Semua permintaan harus dikirim ke titik akhir akses layanan router cerdas LLM, bukan ke layanan inferensi backend.
-
Jika ada layanan inferensi dalam grup layanan yang memiliki distribusi trafik diaktifkan, permintaan yang dikirim melalui titik masuk trafik agregat grup layanan tersebut dapat melewati router cerdas, menyebabkan kegagalan penjadwalan.
-
Pastikan hanya layanan router cerdas yang memiliki distribusi trafik diaktifkan dalam grup layanan. Kirim permintaan melalui URL dedicated traffic entry layanan router cerdas.
-
Dapatkan kredensial akses.
-
Buka halaman Overview layanan router cerdas LLM. Di bagian Basic Information, klik View Endpoint Information.
-
Di halaman Endpoint Information, di bawah Service-specific Traffic Entry, salin Internet Endpoint dan token.
PentingToken layanan di sini adalah kunci API administrator. Jika administrator telah menetapkan kunci API terpisah untuk Anda melalui workbench WebUI, gunakan kunci API Anda sendiri untuk menggantikan
<YOUR_TOKEN>pada contoh di bawah. -
-
Buat URL permintaan dan panggil layanan.
-
Format URL:
<titik akhir akses router cerdas LLM>/<jalur API layanan LLM> -
Contoh:
http://********.pai-eas.aliyuncs.com/api/predict/group_llm_gateway.llm_gateway/v1/chat/completions
Contoh permintaan:
# Ganti <YOUR_GATEWAY_URL> dan <YOUR_TOKEN> dengan nilai aktual Anda curl -X POST "<YOUR_GATEWAY_URL>/v1/chat/completions" \ -H "Authorization: Bearer <YOUR_TOKEN>" \ -H "Content-Type: application/json" \ -N \ -d '{ "messages": [{"role": "user", "content": "Hello"}], "stream": true }'Contoh tanggapan:
data: {"id":"chatcmpl-9a9f8299*****","object":"chat.completion.chunk","created":1762245102,"model":"Qwen3-8B","choices":[{"index":0,"delta":{"role":"assistant","content":""},"logprobs":null,"finish_reason":null}]} data: {"id":"chatcmpl-9a9f8299*****","object":"chat.completion.chunk","created":1762245102,"model":"Qwen3-8B","choices":[{"index":0,"delta":{"content":"<think>","tool_calls":[]}}]} ... data: [DONE] -
Setelah menerapkan layanan, Anda dapat menggunakan workbench WebUI untuk tugas seperti pemantauan langsung dan manajemen konfigurasi. Untuk detailnya, lihat Gunakan workbench router cerdas LLM.
Konfigurasi Redis untuk penyimpanan persisten
Router cerdas LLM mencakup fitur manajemen pengguna bawaan yang mendukung manajemen multi-pengguna, kontrol akses berbasis peran, pencatatan log audit, dan ikhtisar data. Anda dapat menggunakan instans Redis eksternal untuk mempertahankan informasi pengguna dan statistik penggunaan. Jika Redis tidak dikonfigurasi, layanan menggunakan memori lokal dan semua data akan hilang ketika layanan dihentikan. Untuk penerapan produksi, konfigurasikan Redis untuk penyimpanan persisten.
Langkah 1: Siapkan instans Tair (Redis)
-
Beli instans dari halaman pembelian Tair.
PentingSaat membuat instans, pilih VPC dan vSwitch yang sama dengan layanan router cerdas LLM Anda. Untuk opsi lainnya, Anda dapat memulai dengan spesifikasi minimum.
-
Tambahkan Blok CIDR vSwitch layanan router cerdas LLM ke daftar izin instans. Untuk informasi lebih lanjut, lihat Konfigurasi daftar izin.
-
Klik ID instans target untuk membuka halaman detail. Anda akan memerlukan informasi koneksi saat menerapkan layanan router cerdas LLM.
-
Alamat koneksi dan port: Di bagian Instance information, temukan alamat koneksi VPC dan nomor port di bawah Connection information.
-
Username dan password: Di halaman Account management, temukan akun default. Jika Anda tidak menetapkan kata sandi saat membuat instans, Anda dapat menetapkan atau mengatur ulang di sini. Anda juga dapat membuat akun baru alih-alih menggunakan akun default.
-
Langkah 2: Konfigurasi Redis
Selain konfigurasi dasar, Anda harus mengonfigurasi VPC dan menambahkan parameter koneksi Redis untuk mengaktifkan penyimpanan persisten.
-
Konfigurasi VPC: VPC dan vSwitch harus sama dengan instans Tair yang disiapkan pada Langkah 1. Hal ini memastikan bahwa layanan router cerdas LLM dapat terhubung ke instans Tair.
-
Konfigurasi Redis:
Konsol
Di bagian Advanced Features, aktifkan Redis config dan masukkan parameter berikut:
Parameter
Deskripsi
Redis Address
Alamat koneksi instans Tair, dalam format
<alamat VPC>:<port>. Contohnya,r-uxxx.redis.rds.aliyuncs.com:6379.Redis Username
Username untuk instans Tair.
Redis Password
Password untuk instans Tair.
JSON
Di node
llm_gatewaypada body JSON, tambahkan parameter berikut:Parameter
Deskripsi
enable_user_managementMengaktifkan manajemen pengguna. Default-nya adalah
true.redis_addrsAlamat koneksi instans Tair, dalam format
<alamat VPC>:<port>. Contohnya,r-uxxx.redis.rds.aliyuncs.com:6379.redis_usernameUsername untuk instans Tair.
redis_passwordPassword untuk instans Tair.
Contoh JSON:
{ "llm_gateway": { "enable_user_management": true, "redis_addrs": "r-uxxx.redis.rds.aliyuncs.com:6379", "redis_username": "xxx", "redis_password": "xxx" } }
Konfigurasi lanjutan (JSON)
Gunakan JSON Deployment untuk mengonfigurasi spesifikasi resource untuk LLM Gateway dan menyesuaikan pemrosesan permintaannya.
Di halaman Inference Service, klik Deploy Service. Di bagian Custom Model Deployment, klik JSON Deployment.
Contoh konfigurasi
{
"cloud": {
"computing": {
"instance_type": "ecs.c7.large"
}
},
"llm_gateway": {
"max_queue_size": 128,
"retry_count": 2,
"wait_schedule_timeout": 5000,
"wait_schedule_try_period": 500
},
"llm_scheduler": {
"cpu": 2,
"memory": 4000,
"policy": "prefix-cache"
},
"metadata": {
"group": "group_llm_gateway",
"instance": 2,
"name": "llm_gateway",
"type": "LLMGatewayService",
"rpc": {
"disable_auth": true
}
}
}
Parameter
|
Parameter |
Deskripsi |
|
|
metadata |
type |
Wajib. Harus diatur ke |
|
instance |
Wajib. Jumlah replika |
|
|
cpu |
Jumlah vCPU untuk setiap replika |
|
|
memory |
Memori (dalam GB) untuk |
|
|
group |
Grup layanan tempat layanan router cerdas LLM berada. |
|
|
rpc.disable_auth |
Wajib. Harus diatur ke |
|
|
cloud.computing.instance_type |
Menentukan tipe instans untuk |
|
|
llm_gateway |
max_queue_size |
Kedalaman antrian maksimum untuk Saat permintaan melebihi kapasitas framework inferensi backend, permintaan berlebih ditahan dalam antrian ini untuk menunggu penjadwalan. |
|
retry_count |
Jumlah percobaan ulang. Default: 2. Jika instans inferensi backend gagal, sistem akan mencoba ulang permintaan dan meneruskannya ke instans yang sehat. |
|
|
wait_schedule_timeout |
Saat mesin backend berada pada kapasitas penuh, parameter ini menentukan total timeout dalam milidetik untuk menjadwalkan permintaan. Default-nya adalah 5000 (5 detik). |
|
|
wait_schedule_try_period |
Interval, dalam milidetik, antara upaya penjadwalan. Default-nya adalah 500 (0,5 detik). |
|
|
request_stream_prefill_timeout |
Timeout prefill dalam detik untuk permintaan streaming. Ini adalah waktu maksimum untuk menunggu token pertama. Default: 300. |
|
|
request_stream_decode_timeout |
Timeout decode dalam detik untuk permintaan streaming. Ini adalah interval idle maksimum antara chunk berturut-turut. Default: 300. |
|
|
request_stream_total_timeout |
Total timeout dalam detik untuk seluruh permintaan streaming. Default: 0, yang berarti tanpa timeout. |
|
|
request_non_stream_timeout |
Timeout dalam detik untuk permintaan non-streaming. Ini adalah waktu maksimum untuk respons lengkap. Default: 900. |
|
|
llm_scheduler |
cpu |
Jumlah vCPU untuk |
|
memory |
Memori (dalam GB) untuk |
|
|
policy |
Kebijakan penjadwalan. Default: |
|
|
prefill_policy |
Saat policy diatur ke pd-split, Anda harus menentukan kebijakan penjadwalan terpisah untuk tahap Prefill dan Decode. Nilai yang valid adalah: prefix-cache, llm-metric-based, least-request, dan least-token. |
|
|
decode_policy |
||
Lampiran
Gunakan Claude Code
-
Konfigurasikan Claude Code untuk menggunakan BASE URL dan TOKEN dari layanan router cerdas EAS.
# Ganti <YOUR_GATEWAY_URL> dan <YOUR_TOKEN> dengan nilai aktual Anda export ANTHROPIC_BASE_URL=<YOUR_GATEWAY_URL> export ANTHROPIC_AUTH_TOKEN=<YOUR_TOKEN> -
Jalankan Claude Code.
claude "Write a Python Hello World program"
Kebijakan penjadwalan
Tabel ini membandingkan logika, kasus penggunaan, keunggulan, dan pertimbangan untuk setiap kebijakan penjadwalan.
|
Kebijakan |
Nilai JSON |
Deskripsi |
Kasus penggunaan |
Keunggulan |
Pertimbangan |
|
Prefix cache |
prefix-cache |
(Direkomendasikan) Kebijakan komposit yang memprioritaskan pengarahan permintaan dengan riwayat percakapan (prompt) yang sama ke instans dengan cache KV yang sesuai. |
Chatbot multi-putaran dan sistem RAG dengan prompt sistem tetap. |
Mengurangi Time to First Token (TTFT) secara signifikan, serta meningkatkan kinerja dan throughput untuk percakapan multi-putaran. |
Memerlukan mesin inferensi untuk mengaktifkan prefix caching. |
|
Minimum Requests |
least-request |
Mengarahkan permintaan baru ke instans yang sedang memproses jumlah permintaan paling sedikit. |
Workload dengan kompleksitas permintaan yang relatif seragam (panjang token dan panjang generasi serupa). |
Sederhana dan efisien. Dengan cepat menyeimbangkan jumlah permintaan di seluruh instans. |
Tidak memperhitungkan biaya komputasi aktual dari permintaan. Instans yang menangani permintaan pendek bisa menganggur sementara yang memproses permintaan panjang kelebihan beban. |
|
Minimum tokens |
least-token |
Mengarahkan permintaan baru ke instans yang sedang memproses jumlah total token paling sedikit (input + output). |
Workload di mana jumlah token secara andal mencerminkan biaya pemrosesan. |
Mencerminkan beban instans sebenarnya lebih akurat daripada kebijakan Least Request. |
Mengandalkan estimasi jumlah token, dan tidak semua mesin inferensi melaporkan metrik ini. |
|
Static PD Disaggregation |
pd-split |
Instans dipartisi sebelumnya menjadi grup Prefill dan Decode, dan kebijakan penjadwalan terpisah ditetapkan untuk setiap grup. |
Workload di mana tahap Prefill dan Decode memiliki pola akses komputasi dan memori yang sangat berbeda, serta disagregasi memberikan keunggulan tersendiri. |
Memaksimalkan pemanfaatan hardware melalui tuning spesifik tahap. |
Kompleks untuk dikonfigurasi. Anda harus memahami model dan workload, serta menerapkan layanan Prefill dan Decode terpisah. |
Tolok ukur kinerja
Tolok ukur pada model Distill-Qwen-7B, QwQ-32B, dan Qwen2.5-72B menunjukkan bahwa router cerdas LLM secara signifikan meningkatkan kecepatan dan throughput inferensi.
Hasil ini hanya untuk referensi. Jalankan tolok ukur Anda sendiri untuk memvalidasi kinerja sesuai workload Anda.
Lingkungan pengujian
-
Kebijakan penjadwalan: prefix-cache
-
Set data pengujian: ShareGPT_V3_unfiltered_cleaned_split.json (set data percakapan multi-putaran)
-
Mesin inferensi: vLLM (0.7.3)
-
Instans backend: 5
Hasil pengujian
|
Model uji |
Distill-Qwen-7B |
QwQ-32B |
Qwen2.5-72b |
||||||
|
Jenis instance |
ml.gu8tf.8.40xlarge |
ml.gu8tf.8.40xlarge |
ml.gu7xf.8xlarge-gu108 |
||||||
|
Konkurensi |
500 |
100 |
100 |
||||||
|
Metriks |
Tanpa smart router |
Dengan smart router |
Peningkatan |
Tanpa smart router |
Dengan smart router |
Peningkatan |
Tanpa smart router |
Dengan smart router |
Peningkatan |
|
Permintaan berhasil |
3698 |
3612 |
- |
1194 |
1194 |
- |
1194 |
1194 |
- |
|
Durasi benchmark |
460,79 s |
435,70 s |
- |
1418,54 s |
1339,04 s |
- |
479,53 s |
456,69 s |
- |
|
Total token input |
6605953 |
6426637 |
- |
2646701 |
2645010 |
- |
1336301 |
1337015 |
- |
|
Total token yang dihasilkan |
4898730 |
4750113 |
- |
1908956 |
1902894 |
- |
924856 |
925208 |
- |
|
Throughput permintaan |
8,03 req/s |
8,29 req/s |
+3,2% |
0,84 req/s |
0,89 req/s |
+5,95% |
2,49 req/s |
2,61 req/s |
+4,8% |
|
Throughput token output |
10631,17 tok/s |
10902,30 tok/s |
+2,5% |
1345,72 tok/s |
1421,08 tok/s |
+5,6% |
1928,66 tok/s |
2025,92 tok/s |
+5,0% |
|
Total throughput token |
24967,33 tok/s |
25652,51 tok/s |
+2,7% |
3211,52 tok/s |
3396,38 tok/s |
+5,8% |
4715,34 tok/s |
4953,56 tok/s |
+5,0% |
|
Rata-rata TTFT |
532,79 ms |
508,90 ms |
+4,5% |
1144,62 ms |
859,42 ms |
+25,0% |
508,55 ms |
389,66 ms |
+23,4% |
|
Median TTFT |
274,23 ms |
246,30 ms |
- |
749,39 ms |
565,61 ms |
- |
325,33 ms |
190,04 ms |
- |
|
P99 TTFT |
3841,49 ms |
3526,62 ms |
- |
5339,61 ms |
5027,39 ms |
- |
2802,26 ms |
2678,70 ms |
- |
|
Rata-rata TPOT |
40,65 ms |
39,20 ms |
+3,5% |
68,78 ms |
65,73 ms |
+4,4% |
46,83 ms |
43,97 ms |
+6,1% |
|
Median TPOT |
41,14 ms |
39,61 ms |
- |
69,19 ms |
66,33 ms |
- |
45,37 ms |
43,30 ms |
- |
|
P99 TPOT |
62,57 ms |
58,71 ms |
- |
100,35 ms |
95,55 ms |
- |
62,29 ms |
54,79 ms |
- |