Dalam aplikasi model bahasa besar (LLM), kebijakan penyeimbangan beban tradisional sering kali tidak memadai. Variasi panjang permintaan dan respons, generasi token acak, serta penggunaan sumber daya GPU yang tidak dapat diprediksi menyulitkan penilaian beban backend secara real-time. Hal ini menyebabkan ketidakseimbangan beban di antara instans, sehingga mengurangi throughput sistem dan efisiensi respons. Elastic Algorithm Service (EAS) memperkenalkan komponen router cerdas LLM yang menggunakan metrik khusus LLM untuk mendistribusikan permintaan secara dinamis. Pendekatan ini menyeimbangkan alokasi daya komputasi dan VRAM di seluruh instans inferensi, meningkatkan pemanfaatan sumber daya kluster dan stabilitas sistem.
Cara kerja
Ikhtisar arsitektur
Router cerdas LLM terdiri dari tiga komponen inti: LLM Gateway, LLM Scheduler, dan LLM Agent. Ketiganya bersama-sama menyediakan distribusi dan manajemen trafik cerdas untuk kluster instans inferensi backend LLM.
Router cerdas LLM merupakan layanan EAS khusus. Layanan ini harus diterapkan dalam kelompok layanan yang sama dengan layanan inferensi agar berfungsi dengan benar.
Proses intinya adalah sebagai berikut:
Pendaftaran instans: Setelah layanan inferensi dimulai,
LLM Agentmenunggu hingga mesin inferensi siap. Selanjutnya, agen tersebut mendaftarkan instans keLLM Schedulerdan mulai melaporkan status kesehatan serta metrik performanya secara berkala.Masuknya trafik: Permintaan pengguna pertama kali tiba di
LLM Gateway.Keputusan penjadwalan:
LLM Gatewaymengirim permintaan penjadwalan keLLM Scheduler.Penjadwalan cerdas:
LLM Schedulermemilih instans backend optimal berdasarkan kebijakan penjadwalan dan metrik real-time yang dikumpulkan dari setiapLLM Agent.Penerusan permintaan:
LLM Schedulermengembalikan keputusannya kepadaLLM Gateway. Selanjutnya,LLM Gatewaymeneruskan permintaan pengguna asli ke instans target.Buffering permintaan: Jika semua instans backend sedang mengalami beban tinggi, permintaan baru sementara dibuffer di antrian
LLM Gateway. Permintaan tersebut menunggu hinggaLLM Schedulermenentukan waktu yang tepat untuk meneruskannya, sehingga mencegah kegagalan permintaan.
Komponen inti
Komponen | Tanggung Jawab Inti |
LLM Gateway | Titik masuk trafik dan pusat pemrosesan permintaan. Komponen ini menerima semua permintaan pengguna dan meneruskannya ke instans inferensi backend yang ditentukan berdasarkan keputusan
|
LLM Scheduler | Otak dari penjadwalan cerdas. Komponen ini mengumpulkan metrik real-time yang dilaporkan oleh seluruh |
LLM Agent | Probe yang diterapkan bersama instans inferensi. Komponen ini diterapkan sebagai kontainer sidecar pada setiap instans inferensi. Komponen ini mengumpulkan metrik performa dari mesin inferensi, mempertahankan heartbeat dengan |
Mekanisme failover
Sistem ini mencakup mekanisme toleransi kesalahan berlapis untuk memastikan stabilitas layanan:
LLM Gateway (ketersediaan tinggi): Sebagai lapisan masuk trafik tanpa status, terapkan minimal dua instans. Saat suatu instans gagal, trafik secara otomatis dialihkan ke instans sehat lainnya guna menjaga ketersediaan layanan yang berkelanjutan.
LLM Scheduler (degradasi elegan): Sebagai komponen penjadwalan permintaan, komponen ini berjalan sebagai satu instans untuk memungkinkan penjadwalan global. Jika
LLM Schedulergagal,LLM Gatewaysecara otomatis mengalami degradasi setelah heartbeat gagal dan menggunakan kebijakan polling untuk meneruskan permintaan langsung ke instans backend. Hal ini memastikan ketersediaan layanan tetapi mengurangi performa penjadwalan. SetelahLLM Schedulerpulih,LLM Gatewaysecara otomatis melanjutkan penjadwalan cerdas.Instans inferensi atau LLM Agent (penghapusan otomatis): Saat instans inferensi atau
LLM Agentterkaitnya gagal, heartbeat antaraLLM AgentdanLLM Schedulerterputus.LLM Schedulersegera menghapus instans tersebut dari daftar layanan yang tersedia dan menghentikan alokasi trafik baru kepadanya. Setelah instans tersebut pulih dan kembali melaporkan heartbeat, instans tersebut secara otomatis bergabung kembali ke daftar layanan.
Dukungan untuk beberapa mesin inferensi
Metrik yang dikembalikan oleh titik akhir /metrics bervariasi di antara mesin inferensi LLM. LLM Agent mengumpulkan metrik tersebut, memformatnya secara seragam, lalu melaporkannya. LLM Scheduler tidak perlu mengetahui detail implementasi mesin inferensi tertentu. Komponen ini hanya perlu menerapkan algoritma penjadwalan berdasarkan metrik terpadu. Mesin inferensi LLM yang didukung beserta metrik terkaitnya adalah sebagai berikut:
Mesin inferensi LLM | Metrik | Deskripsi |
vLLM | vllm:num_requests_running | Jumlah permintaan yang sedang berjalan. |
vllm:num_requests_waiting | Jumlah permintaan yang menunggu dalam antrian. | |
vllm:gpu_cache_usage_perc | Penggunaan GPU KV Cache. | |
vllm:prompt_tokens_total | Total jumlah token prompt. | |
vllm:generation_tokens_total | Total jumlah token yang dihasilkan. | |
SGLang | sglang:num_running_reqs | Jumlah permintaan yang sedang berjalan. |
sglang:num_queue_reqs | Jumlah permintaan yang menunggu dalam antrian. | |
sglang:token_usage | Penggunaan KV Cache. | |
sglang:prompt_tokens_total | Total jumlah token prompt. | |
sglang:gen_throughput | Jumlah token yang dihasilkan per detik. |
Batasan
Tidak dapat ditambahkan selama pembaruan: Anda hanya dapat mengonfigurasi router cerdas LLM saat membuat layanan baru. Anda tidak dapat menambahkannya ke layanan inferensi yang sudah ada melalui pembaruan layanan.
Batasan mesin inferensi: Saat ini, hanya vLLM dan SGLang yang didukung.
Disarankan menerapkan beberapa instans inferensi: Router cerdas LLM memberikan nilai maksimal saat beberapa instans inferensi diterapkan.
Memulai: Gunakan router cerdas LLM
Langkah 1: Terapkan layanan router cerdas LLM
Masuk ke Konsol PAI dan pilih wilayah tujuan di bagian atas halaman.
Pada panel navigasi kiri, klik Elastic Algorithm Service (EAS). Pilih ruang kerja target untuk membuka halaman EAS.
Klik Deploy Service dan pilih Scenario-based Model Deployment > Deploy LLM gateway.
Konfigurasikan parameter:
Parameter
Deskripsi
Basic Information
Service Name
Masukkan nama layanan kustom, misalnya
llm_gateway.Resource Information
Deployment Resources
Konfigurasi sumber daya untuk
LLM Gateway. Untuk memastikan ketersediaan tinggi, Number of Replicas secara default bernilai 2. Kami menyarankan untuk mempertahankan nilai ini. CPU default adalah 4 core dan Memori default adalah 8 GB.Scheduling configuration
Konfigurasi sumber daya untuk
LLM Scheduler. CPU default adalah 2 core dan Memori default adalah 4 GB.Scheduling Policy
Pilih kebijakan penyeimbangan beban untuk instans inferensi backend. Nilai default adalah Prefix cache. Untuk perbandingan mendetail dan rekomendasi pemilihan, lihat Penjelasan kebijakan penjadwalan.
Klik Deploy. Saat status layanan berubah menjadi Running, penerapan berhasil.
Setelah penerapan berhasil, sistem secara otomatis membuat kelompok layanan bernama group_<LLM_intelligent_router_service_name>. Anda dapat membuka halaman Elastic Algorithm Service (EAS) dan mengklik tab Canary Release untuk melihatnya.
Router cerdas dan antrian layanan saling bertentangan. Keduanya tidak dapat berada dalam kelompok layanan yang sama.
Langkah 2: Terapkan layanan LLM
Anda harus mengonfigurasi fitur router cerdas saat menerapkan layanan LLM baru. Anda tidak dapat menambahkannya dengan memperbarui layanan LLM yang sudah ada.
Langkah-langkah berikut menggunakan penerapan Qwen3-8B sebagai contoh:
Klik Deploy Service dan pilih Scenario-based Model Deployment > LLM Deployment.
Konfigurasikan parameter utama berikut:
Parameter
Nilai
Basic Information
Model Settings
Pilih Public Model. Kemudian cari dan pilih Qwen3-8B.
Inference Engine
Pilih vLLM (disarankan, kompatibel dengan API OpenAI).
CatatanJika Anda memilih Prefix cache sebagai scheduling policy untuk layanan router cerdas LLM dan memilih vLLM sebagai mesin inferensi saat menerapkan layanan LLM, pastikan untuk mengaktifkan fitur prefix caching pada mesin tersebut.
Deployment Template
Pilih Standalone. Sistem akan secara otomatis mengisi tipe instans, citra runtime, dan parameter lainnya berdasarkan templat yang direkomendasikan.
Features
LLM Intelligent Router
Aktifkan sakelar dan pilih layanan router cerdas LLM yang diterapkan pada Langkah 1 dari daftar drop-down.
Klik Deploy. Penerapan layanan membutuhkan waktu sekitar 5 menit. Saat status layanan berubah menjadi Running, penerapan berhasil.
Langkah 3: Uji layanan
Kirim semua permintaan ke titik akhir layanan router cerdas LLM, bukan ke layanan inferensi backend.
Dapatkan kredensial akses.
Klik layanan router cerdas LLM untuk membuka halaman Overview. Di bagian Basic Information, klik View Endpoint Information.
Pada halaman Endpoint Information, salin Internet Endpoint dan Token di bawah Service-specific Traffic Entry.

Buat URL permintaan dan lakukan panggilan.
Struktur URL:
<LLM_intelligent_router_endpoint>/<LLM_service_API_path>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 informasi 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 }'Berikut adalah 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]
Konfigurasi lanjutan
Penerapan independen berbasis JSON menyediakan opsi konfigurasi yang lebih fleksibel. Anda dapat menentukan spesifikasi sumber daya untuk LLM Gateway dan menyesuaikan perilaku penanganan permintaannya secara lebih rinci.
Titik masuk konfigurasi: Pada 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" } }Deskripsi parameter:
Parameter
Deskripsi
metadata
type
Wajib diisi. Harus diatur ke
LLMGatewayService. Ini menunjukkan bahwa Anda sedang menerapkan layanan router cerdas LLM.instance
Wajib diisi. Jumlah replika untuk
LLM Gateway. Kami menyarankan mengatur nilai ini minimal 2 untuk mencegah single point of failure.cpu
Jumlah core CPU untuk setiap replika
LLM Gateway.memory
Memori
LLM Gatewaydalam satuan GB.group
Kelompok layanan tempat layanan router cerdas LLM berada.
cloud.computing.instance_type
Menentukan spesifikasi sumber daya untuk
LLM Gateway. Jika Anda mengatur parameter ini, Anda tidak perlu mengonfigurasimetadata.cpudanmetadata.memory.llm_gateway
max_queue_size
Panjang maksimum antrian cache
LLM Gateway. Nilai default adalah 512.Saat jumlah permintaan melebihi kapasitas pemrosesan framework inferensi backend, permintaan berlebih disimpan dalam antrian ini untuk menunggu penjadwalan.
retry_count
Jumlah percobaan ulang. Nilai default adalah 2. Saat instans inferensi backend gagal, permintaan dicoba ulang dan diteruskan ke instans baru.
wait_schedule_timeout
Saat mesin backend berada pada kapasitas penuh, permintaan dijadwalkan secara berkala. Parameter ini menentukan waktu percobaan penjadwalan. Nilai default adalah 10 detik.
wait_schedule_try_period
Interval antara setiap percobaan penjadwalan. Nilai default adalah 1 detik.
llm_scheduler
cpu
Jumlah core CPU untuk
LLM Scheduler. Nilai default adalah 4.memory
Memori
LLM Schedulerdalam satuan GB. Nilai default adalah 4 GB.policy
Kebijakan penjadwalan. Nilai default adalah
prefix-cache. Untuk nilai opsional dan deskripsinya, lihat Penjelasan kebijakan penjadwalan.prefill_policy
Jika Anda mengatur policy ke pd-split, Anda harus menentukan kebijakan penjadwalan secara terpisah untuk tahap Prefill dan Decode. Nilai yang valid: prefix-cache, llm-metric-based, least-request, dan least-token.
decode_policy
Penjelasan kebijakan penjadwalan
Memilih kebijakan penjadwalan yang tepat merupakan kunci untuk memaksimalkan nilai router cerdas LLM. Tabel berikut membandingkan logika, skenario, keunggulan, dan catatan untuk setiap kebijakan guna membantu Anda mengambil keputusan terbaik.
Nama kebijakan | Nilai JSON | Logika inti | Skenario | Keunggulan | Catatan |
Prefix cache | prefix-cache | (Direkomendasikan) Kebijakan komprehensif yang memprioritaskan pengiriman permintaan dengan konteks historis (prompt) yang sama ke instans yang telah menyimpan KV Cache-nya. | Bot percakapan multi-putaran dan sistem Generasi yang Diperkaya dengan Pengambilan Data (RAG) dengan prompt sistem tetap. | Secara signifikan mengurangi waktu hingga token pertama (TTFT) serta meningkatkan performa dan throughput percakapan multi-putaran. | Mesin inferensi harus memiliki Prefix Caching yang diaktifkan. |
LLM Metrics | llm-metric-based | Menjalankan penjadwalan cerdas berdasarkan metrik beban komprehensif instans backend, seperti jumlah permintaan dalam antrian, permintaan yang sedang berjalan, dan penggunaan KV Cache. | Beban kerja LLM umum dengan pola permintaan beragam dan tanpa fitur percakapan yang jelas. | Secara efektif menyeimbangkan beban di berbagai instans dan meningkatkan pemanfaatan sumber daya. | Logika penjadwalan relatif kompleks dan mungkin tidak seefektif kebijakan berbasis prefix cache dalam skenario tertentu. |
Minimum Requests | least-request | Mengirim permintaan baru ke instans yang sedang memproses jumlah permintaan paling sedikit. | Skenario di mana kompleksitas komputasi permintaan (panjang token, panjang generasi) relatif seragam. | Sederhana dan efisien. Dapat dengan cepat menyeimbangkan jumlah permintaan di antara instans. | Tidak dapat merasakan beban aktual permintaan. Hal ini dapat menyebabkan instans dengan permintaan pendek menganggur sementara instans dengan permintaan panjang kelebihan beban. |
Minimum tokens | least-token | Mengirim permintaan baru ke instans yang sedang memproses total token paling sedikit (input + output). | Skenario di mana jumlah token secara akurat mencerminkan biaya pemrosesan permintaan. | Mencerminkan beban aktual instans lebih akurat dibandingkan kebijakan "Least request". | Bergantung pada estimasi jumlah token, dan tidak semua mesin melaporkan metrik ini. |
Static PD Disaggregation | pd-split | Memerlukan pembagian awal instans ke dalam kelompok Prefill dan Decode serta menentukan kebijakan penjadwalan untuk masing-masing kelompok. | Skenario di mana karakteristik komputasi dan akses memori tahap Prefill dan Decode sangat berbeda, serta penerapan terpisah memberikan manfaat signifikan. | Optimalisasi ekstrem untuk pemanfaatan perangkat keras maksimal. | Konfigurasi kompleks. Memerlukan pemahaman mendalam tentang model dan logika bisnis, serta penerapan layanan Prefill dan Decode secara terpisah. |
Dynamic PD Disaggregation | dynamic-pd-split | Instans tidak perlu diberi peran sebelumnya. Penjadwal secara dinamis mengirimkan tahap Prefill atau Decode suatu permintaan ke instans yang paling sesuai berdasarkan beban real-time. | Sama seperti di atas, tetapi cocok untuk skenario dengan beban yang berubah secara dinamis. | Lebih fleksibel dibandingkan pemisahan statis dan dapat beradaptasi dengan perubahan beban. | Konfigurasi lebih kompleks. Memberikan tuntutan lebih tinggi pada penjadwal dan mesin. |
Lihat metrik pemantauan layanan
Setelah menerapkan layanan, Anda dapat melihat metrik performa intinya di Konsol EAS untuk mengevaluasi efektivitas router cerdas.
Pada halaman Elastic Algorithm Service (EAS), klik layanan router cerdas LLM yang telah diterapkan untuk membuka halaman detail layanan. Pada tab Monitoring, fokuslah pada metrik inti berikut:
Token Throughput Throughput token input dan output LLM
| GPU Cache Usage Penggunaan GPU KV Cache Mesin LLM
|
Engine Current Requests Permintaan konkuren real-time Mesin LLM
| Gateway Current Requests Permintaan real-time router cerdas LLM
|
Time To First Token Waktu hingga token pertama untuk permintaan
| Time Per Output Token Latensi Permintaan per Paket
|
Lampiran: Gunakan Claude Code untuk melakukan panggilan
Konfigurasikan Claude Code untuk menggunakan BASE URL dan TOKEN yang disediakan oleh layanan router cerdas EAS.
# Ganti <YOUR_GATEWAY_URL> dan <YOUR_TOKEN> dengan informasi aktual Anda export ANTHROPIC_BASE_URL=<YOUR_GATEWAY_URL> export ANTHROPIC_AUTH_TOKEN=<YOUR_TOKEN>Jalankan tool Claude Code secara langsung.
claude "Write a Hello World program in Python"
Lampiran: Perbandingan hasil uji performa
Pengujian pada model Distill-Qwen-7B, QwQ-32B, dan Qwen2.5-72B menunjukkan bahwa router cerdas LLM secara signifikan meningkatkan kecepatan dan throughput layanan inferensi. Lingkungan pengujian dan hasilnya adalah sebagai berikut.
Hasil pengujian berikut hanya sebagai referensi. Performa aktual dapat berbeda tergantung pada pengujian Anda.
Lingkungan pengujian
Kebijakan penjadwalan: prefix-cache
Data uji: ShareGPT_V3_unfiltered_cleaned_split.json (set data percakapan multi-putaran)
Mesin inferensi: vLLM (0.7.3)
Jumlah instans backend: 5
Hasil pengujian
Model uji | Distill-Qwen-7B | QwQ-32B | Qwen2.5-72b | ||||||
Tipe kartu | ml.gu8tf.8.40xlarge | ml.gu8tf.8.40xlarge | ml.gu7xf.8xlarge-gu108 | ||||||
Konkurensi | 500 | 100 | 100 | ||||||
Metrik | Tanpa router cerdas LLM | Gunakan router cerdas LLM | Peningkatan | Tanpa router cerdas LLM | Menggunakan router cerdas LLM | Peningkatan | Tanpa router cerdas LLM | Menggunakan router cerdas LLM | 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 | +4,4% |
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 | - |





