全部产品
Search
文档中心

Platform For AI:Tingkatkan efisiensi inferensi dengan router cerdas LLM

更新时间:Jan 30, 2026

Pada aplikasi model bahasa besar (LLM), strategi penyeimbangan beban tradisional kesulitan mengukur secara akurat beban backend secara real-time karena variasi panjang permintaan dan respons, jumlah token yang dihasilkan selama fase Prompt dan Generate bersifat acak, serta konsumsi sumber daya GPU tidak dapat diprediksi. Faktor-faktor tersebut menyebabkan beban instans tidak merata, yang berdampak pada throughput sistem dan efisiensi respons. Untuk mengatasi masalah ini, Elastic Algorithm Service (EAS) memperkenalkan komponen router cerdas LLM. Router ini mendistribusikan permintaan secara dinamis berdasarkan metrik khusus LLM guna menyeimbangkan daya komputasi dan Memori GPU setiap instans inferensi, sehingga meningkatkan pemanfaatan resource kluster dan stabilitas sistem.

Cara kerja

Ikhtisar arsitektur

Router cerdas LLM terdiri dari tiga komponen inti yang menyediakan distribusi dan manajemen traffic cerdas untuk kluster instans inferensi backend LLM: LLM Gateway, LLM Scheduler, dan LLM Agent.

  • LLM Gateway:

    • Bertindak sebagai titik masuk traffic, menerima semua permintaan pengguna dan meneruskannya ke instans inferensi backend tertentu berdasarkan keputusan dari LLM Scheduler.

    • Mendukung protokol HTTP (HTTP_SSE) dan WebSocket serta dapat menyimpan cache permintaan saat instans inferensi backend mengalami beban tinggi.

    • Fitur transformasi protokol API Anthropic diaktifkan secara default. Fitur ini secara otomatis mengubah permintaan yang sesuai dengan spesifikasi Anthropic ke dalam format yang kompatibel dengan OpenAI, sehingga memungkinkan integrasi tanpa hambatan. Anda dapat menggunakan tool ekosistem seperti Claude Code untuk memanggil layanan model yang mengikuti standar antarmuka OpenAI tanpa perlu mengubah kode Anda. Untuk informasi lebih lanjut, lihat Gunakan Claude Code untuk memanggil.

  • LLM Scheduler: Otak dari router cerdas. Komponen ini menjalankan algoritma penjadwalan dengan mengumpulkan metrik real-time dari seluruh LLM Agent. Selanjutnya, komponen ini menghitung instans target optimal untuk setiap permintaan masuk berdasarkan kebijakan penjadwalan yang telah ditentukan, seperti prefix caching.

  • LLM Agent: Diterapkan sebagai kontainer sidecar bersama setiap instans inferensi. Agen ini mengumpulkan metrik performa dari mesin inferensi, mempertahankan heartbeat dengan LLM Scheduler, serta melaporkan status kesehatan dan data beban instans tersebut.

image

Alur implementasi

Router cerdas LLM merupakan jenis layanan EAS khusus yang harus diterapkan dalam kelompok layanan yang sama dengan layanan inferensi agar berfungsi dengan benar. Setelah Anda menerapkan router cerdas LLM dan layanan inferensi, router tersebut akan menjadwalkan permintaan secara cerdas ke layanan inferensi backend. Prosesnya adalah sebagai berikut:

  1. Pendaftaran instans: Setelah layanan inferensi dimulai, LLM Agent menunggu hingga mesin inferensi siap. Kemudian, agen tersebut mendaftarkan instans ke LLM Scheduler dan secara berkala melaporkan status kesehatan serta metrik performanya.

  2. Masuknya traffic: Permintaan pengguna pertama kali tiba di LLM Gateway. Gateway ini mendukung protokol HTTP (SSE) dan WebSocket.

  3. Permintaan penjadwalan: LLM Gateway mengirim permintaan penjadwalan ke LLM Scheduler.

  4. Penjadwalan cerdas: LLM Scheduler memilih instans backend optimal berdasarkan kebijakan penjadwalannya dan metrik real-time dari setiap LLM Agent.

  5. Penerusan permintaan: LLM Scheduler mengembalikan keputusannya kepada LLM Gateway. Selanjutnya, LLM Gateway meneruskan permintaan pengguna asli ke instans target untuk proses inferensi.

  6. Buffering permintaan: Jika semua instans backend sedang mengalami beban tinggi, LLM Gateway sementara waktu menempatkan permintaan baru ke dalam antrian. Permintaan-permintaan tersebut menunggu hingga LLM Scheduler menemukan waktu yang tepat untuk meneruskannya, sehingga mencegah kegagalan permintaan.

Mekanisme failover

Sistem dirancang dengan beberapa lapis toleransi kesalahan untuk memastikan stabilitas layanan:

  • LLM Gateway: Sebagai lapisan ingress traffic tanpa status, `LLM Gateway` harus diterapkan dengan minimal dua instans. Jika salah satu instans gagal, traffic secara otomatis dialihkan ke instans sehat lainnya. Hal ini menjamin kelangsungan layanan dan ketersediaan tinggi (HA).

  • LLM Scheduler: Sebagai komponen penjadwalan permintaan, `LLM Scheduler` berjalan sebagai satu instans untuk mencapai penjadwalan global. Jika LLM Scheduler gagal, LLM Gateway secara otomatis memasuki mode degradasi setelah heartbeat gagal. Gateway kemudian kembali menggunakan kebijakan polling untuk meneruskan permintaan langsung ke instans backend. Hal ini menjamin ketersediaan layanan tetapi mengorbankan performa penjadwalan. Setelah LLM Scheduler pulih, LLM Gateway secara otomatis beralih kembali ke mode perutean pintar.

  • Instans inferensi atau LLM Agent: Jika instans inferensi atau LLM Agent terkaitnya gagal, heartbeat antara LLM Agent dan LLM Scheduler terputus. LLM Scheduler segera menghapus instans yang gagal dari daftar layanan yang tersedia dan berhenti mengalokasikan traffic baru kepadanya. Setelah instans tersebut pulih dan kembali mengirim heartbeat, instans tersebut secara otomatis ditambahkan kembali ke daftar layanan.

Dukungan untuk beberapa mesin inferensi

Mesin inferensi LLM yang berbeda mengekspos metrik berbeda melalui antarmuka /metrics mereka. `LLM Agent` mengumpulkan metrik-metrik tersebut, memformatnya ke dalam struktur terpadu, lalu melaporkannya. Desain ini memungkinkan `LLM Scheduler` fokus pada algoritma penjadwalan berdasarkan metrik terpadu tanpa perlu mengetahui detail implementasi mesin inferensi tertentu. Mesin inferensi LLM yang saat ini didukung beserta metrik yang dikumpulkan adalah sebagai berikut:

Mesin inferensi LLM

Metrik

Catatan

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 cache KV GPU.

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 cache KV.

sglang:prompt_tokens_total

Total jumlah token prompt.

sglang:gen_throughput

Jumlah token yang dihasilkan per detik.

Batasan

  • Tidak didukung untuk pembaruan layanan: Anda hanya dapat mengonfigurasi router cerdas LLM saat membuat layanan baru. Anda tidak dapat menambahkan router cerdas ke layanan inferensi yang sudah ada melalui operasi Update Service.

  • Batasan mesin inferensi: Saat ini, hanya vLLM atau SGLang yang didukung.

  • Direkomendasikan menggunakan beberapa instans inferensi: Router cerdas LLM paling efektif ketika Anda menerapkan beberapa instans inferensi.

Terapkan layanan

Langkah 1: Terapkan layanan router cerdas LLM

Dua metode penerapan berikut didukung:

Metode 1: Terapkan layanan di Konsol

  1. Masuk ke Konsol PAI. Pilih wilayah di bagian atas halaman. Kemudian, pilih ruang kerja yang diinginkan dan klik Elastic Algorithm Service (EAS).

  2. Pada halaman Elastic Algorithm Service (EAS), klik Deploy Service, lalu pilih Scenario-based Model Deployment>Deploy LLM gateway.

  3. Pada halaman Deploy LLM gateway, konfigurasikan parameter utama berikut dan klik Deploy.

    Parameter

    Deskripsi

    Basic Information

    Service Name

    Masukkan nama layanan kustom, misalnya llm_gateway.

    Deployment Resources

    Konfigurasi resource untuk LLM Gateway. Untuk memastikan ketersediaan tinggi, Minimum Number of replicas secara default bernilai 2. Kami merekomendasikan Anda mempertahankan pengaturan ini. Nilai default CPU adalah 4 core, dan nilai default Memory adalah 8 GB.

    Scheduling configuration

    Konfigurasi resource untuk LLM Scheduler. Nilai default CPU adalah 2 core, dan nilai default Memory adalah 4 GB.

    Scheduling Policy

    Sistem memilih instans inferensi backend optimal berdasarkan kebijakan penjadwalan. Kebijakan berikut didukung:

    • Prefix cache: Kebijakan penjadwalan afinitas cache KV komprehensif yang mengambil keputusan berdasarkan berbagai metrik. Kebijakan ini meneruskan permintaan ke instans yang telah menyimpan cache KV terkait untuk diproses guna memaksimalkan efisiensi pemrosesan permintaan. Saat menggunakan kebijakan ini, Anda harus mengaktifkan fitur prefix caching pada mesin inferensi.

    • LLM Metrics: Mengalokasikan traffic layanan secara cerdas berdasarkan berbagai metrik pemantauan layanan LLM untuk memaksimalkan pemanfaatan resource.

    • Minimum Requests: Secara preferensial menetapkan permintaan baru ke instans dengan jumlah permintaan terkecil saat ini.

    • Minimum tokens: Secara preferensial menetapkan permintaan baru ke instans yang sedang memproses jumlah token paling sedikit.

    • Static PD Disaggregation: Pada penerapan LLM yang memisahkan tahap Prefill dan Decode, pilih kebijakan ini untuk memaksimalkan efisiensi penjadwalan. Setelah memilih kebijakan ini, Anda harus menetapkan kebijakan penjadwalan terpisah untuk Prefill dan Decode.

    • Dynamic PD Disaggregation: Secara cerdas dan dinamis beralih antara instans Prefill dan Decode berdasarkan metrik kunci seperti beban layanan aktual, cache KV, dan pemanfaatan GPU. Pada penerapan LLM yang menggunakan disagregasi PD dinamis, pilih kebijakan ini untuk memaksimalkan efisiensi penjadwalan.

Setelah penerapan berhasil, sistem secara otomatis membuat layanan grup dengan nama berformat group_LLM intelligent router service name. Anda dapat melihat layanan ini pada tab Canary Release di halaman Elastic Algorithm Service (EAS).image

Catatan

Router cerdas dan antrian layanan saling bertentangan. Keduanya tidak dapat eksis dalam kelompok layanan yang sama.

Metode 2: Terapkan layanan menggunakan JSON

  1. Masuk ke Konsol PAI. Pilih wilayah di bagian atas halaman. Kemudian, pilih ruang kerja yang diinginkan dan klik Elastic Algorithm Service (EAS).

  2. Pada halaman Elastic Algorithm Service (EAS), klik Deploy Service. Di bagian Custom Model Deployment, klik On-Premises Deployment.

  3. Bagian berikut menyediakan contoh konfigurasi JSON dan deskripsi parameternya. Setelah menyelesaikan konfigurasi, klik Deploy.

    • Contoh konfigurasi:

      Konfigurasi dasar

      Anda dapat menggunakan konfigurasi dasar untuk menerapkan layanan router cerdas LLM secara cepat. Parameter yang tidak dikonfigurasi akan menggunakan nilai default-nya.

      LLM Scheduler dikonfigurasi dengan 4 core CPU dan 4 GB memori secara default. Kebijakan penjadwalan default adalah Prefix Cache.
      {
          "metadata": {
              "type": "LLMGatewayService",
              "cpu": 4,
              "group": "group_llm_gateway",
              "instance": 2,
              "memory": 8000,
              "name": "llm_gateway"
          }
      }

      Konfigurasi lanjutan

      {
          "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

      Tetapkan parameter ini ke LLMGatewayService untuk menerapkan layanan router cerdas LLM. Setelah layanan diterapkan, EAS secara otomatis membuat layanan komposit yang berisi LLM Gateway dan LLM Scheduler.

      instance

      Jumlah instans LLM Gateway. Kami merekomendasikan menetapkan parameter ini ke 2 atau lebih untuk mencegah single point of failure.

      cpu

      CPU untuk LLM Gateway.

      memory

      Memori untuk LLM Gateway.

      group

      Kelompok layanan tempat layanan router cerdas LLM berada.

      cloud.computing.instance_type

      Menentukan spesifikasi resource yang digunakan oleh LLM Gateway. Dalam kasus ini, Anda tidak perlu mengonfigurasi metadata.cpu dan metadata.memory.

      llm_gateway

      max_queue_size

      Panjang maksimum antrian cache LLM Gateway. Nilai default: 512.

      Jika jumlah permintaan melebihi kapasitas pemrosesan framework inferensi backend, permintaan berlebih akan disimpan dalam antrian ini untuk menunggu penjadwalan.

      retry_count

      Jumlah percobaan ulang. Nilai default: 2. Jika instans inferensi backend mengalami anomali, permintaan akan dicoba ulang dan diteruskan ke instans baru.

      wait_schedule_timeout

      Periode timeout untuk penjadwalan permintaan. Nilai default: 10 detik. Jika mesin backend sepenuhnya terbebani, permintaan akan dicoba ulang secara berkala untuk penjadwalan.

      wait_schedule_try_period

      Interval antar percobaan ulang penjadwalan. Nilai default: 1 detik.

      llm_scheduler

      cpu

      CPU untuk LLM Scheduler. Nilai default: 4 core.

      memory

      Memori untuk LLM Scheduler. Nilai default: 4 GB.

      policy

      Kebijakan penjadwalan. Untuk informasi lebih lanjut, lihat deskripsi penerapan berbasis konsol. Nilai default: prefix-cache. Nilai yang valid:

      • prefix-cache: Prefix Cache.

      • llm-metric-based: LLM Metrics.

      • least-request: Minimum Requests.

      • least-token: Minimum Tokens.

      • pd-split: Static PD Disaggregation.

      • dynamic-pd-split: Dynamic PD Disaggregation.

      prefill_policy

      Jika Anda menetapkan policy ke pd-split, Anda harus menetapkan kebijakan penjadwalan untuk Prefill dan Decode. Nilai yang valid: prefix-cache, llm-metric-based, least-request, dan least-token.

      decode_policy

Langkah 2: Terapkan layanan model bahasa besar (LLM)

Saat menerapkan layanan LLM, Anda harus mengaitkannya dengan layanan router cerdas yang telah Anda buat. Topik ini menggunakan contoh penerapan LLM berbasis skenario di EAS. Prosedurnya adalah sebagai berikut:

  1. Masuk ke Konsol PAI. Pilih wilayah di bagian atas halaman. Kemudian, pilih ruang kerja yang diinginkan dan klik Elastic Algorithm Service (EAS).

  2. Pada halaman Inference Service, klik Deploy Service, lalu pilih LLM Deployment. Di bagian Features, temukan dan aktifkan sakelar LLM Intelligent Router. Dari daftar drop-down, pilih layanan router cerdas LLM yang telah Anda terapkan pada Langkah 1. Untuk informasi lebih lanjut mengenai parameter lainnya, lihat LLM Deployment.

    Catatan

    Saat menggunakan vLLM untuk penerapan dipercepat dan Kebijakan Penjadwalan layanan router cerdas LLM diatur ke Prefix cache, Anda harus mengaktifkan fitur prefix caching pada mesin inferensi.

  3. Setelah mengonfigurasi parameter, klik Deploy.

Panggil dan uji layanan

Kirim semua permintaan ke titik akhir layanan router cerdas LLM, bukan ke layanan inferensi backend tertentu.

Dapatkan kredensial akses

  1. Pada halaman Elastic Algorithm Service (EAS), temukan layanan router cerdas LLM yang telah diterapkan.

  2. Klik nama layanan untuk membuka halaman Overview. Di bagian Basic Information, klik View Endpoint Information.

  3. Pada halaman Invocation Method, salin Internet Endpoint dan Token dari bagian Service-specific Traffic Entry.image

Buat dan kirim permintaan

URL permintaan akhir merupakan kombinasi dari titik akhir router cerdas LLM dan path API layanan model.

  • Struktur URL<titik akhir router cerdas LLM>/<path API layanan LLM>

  • Contohhttp://********.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.
# Ganti <model_name> dengan nama model aktual.
curl -X POST "<YOUR_GATEWAY_URL>/v1/chat/completions" \
     -H "Authorization: Bearer <YOUR_TOKEN>" \
     -H "Content-Type: application/json" \
     -N \
     -d '{
           "model": "<model_name>",
           "messages": [{"role": "user", "content": "Hello"}],
           "stream": true
         }'

Berikut adalah contoh hasil yang dikembalikan:

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]

Gunakan Claude Code untuk memanggil

  1. Tetapkan BASE URL dan TOKEN untuk Claude Code, yang disediakan oleh 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>
  2. Jalankan tool Claude Code secara langsung.

    claude "Write a Python Hello World"

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, Anda dapat melihat metrik inti berikut:

Token Throughput

Throughput token input dan output LLM.image

  • IN: Throughput token input LLM.

  • OUT: Throughput token output LLM.

GPU Cache Usage

Penggunaan cache KV GPU dari Mesin LLM.

image

Engine Current Requests

Jumlah permintaan konkuren real-time untuk Mesin LLM.

image

  • Running: Jumlah permintaan yang sedang diproses oleh Mesin LLM.

  • Waiting: Jumlah permintaan dalam antrian tunggu Mesin LLM.

Gateway Current Requests

Jumlah permintaan real-time untuk router cerdas LLM.

image

  • Total: Total jumlah permintaan yang diterima oleh router cerdas LLM. Nilai ini menunjukkan total jumlah permintaan konkuren real-time.

  • Pending: Jumlah permintaan yang disimpan dalam cache oleh router cerdas LLM dan belum diproses oleh Mesin LLM.

Time To First Token

Latensi token pertama dari suatu permintaan.

image

  • Max: Latensi maksimum token pertama dari suatu permintaan.

  • Avg: Latensi rata-rata token pertama dari suatu permintaan.

  • Min: Latensi minimum token pertama dari suatu permintaan.

  • TPxx: Nilai persentil untuk latensi token pertama dari suatu permintaan.

Time Per Output Token

Latensi setiap token dari suatu permintaan.

image

  • Max: Latensi maksimum setiap token dari suatu permintaan.

  • Avg: Latensi rata-rata setiap token dari suatu permintaan.

  • Min: Latensi minimum setiap token dari suatu permintaan.

  • TPxx: Nilai persentil untuk latensi setiap token dari suatu permintaan.

Lampiran: Perbandingan hasil pengujian performa

Pengujian pada model Distill-Qwen-7B, QwQ-32B, dan Qwen2.5-72B menunjukkan bahwa router cerdas LLM memberikan peningkatan performa signifikan dalam kecepatan dan throughput layanan inferensi. Lingkungan pengujian dan hasilnya adalah sebagai berikut:

Penting

Hasil pengujian berikut hanya sebagai referensi. Performa aktual Anda mungkin berbeda.

Lingkungan pengujian

Item konfigurasi

Distill-Qwen-7B

QwQ-32B

Qwen2.5-72B

Kebijakan penjadwalan

prefix-cache

prefix-cache

prefix-cache

Data uji (Percakapan multi-putaran)

ShareGPT_V3_unfiltered_cleaned_split.json

ShareGPT_V3_unfiltered_cleaned_split.json

ShareGPT_V3_unfiltered_cleaned_split.json

Mesin inferensi untuk pengujian

vLLM (0.7.3)

vLLM (0.7.3)

vLLM (0.7.3)

Jumlah instans backend

5

5

5

Tipe kartu

ml.gu8tf.8.40xlarge

ml.gu8tf.8.40xlarge

ml.gu7xf.8xlarge-gu108

Jumlah permintaan konkuren

500

100

100

Hasil pengujian

Metrik

Distill-Qwen-7B

QwQ-32B

Qwen2.5-72B

Tanpa router cerdas LLM

Dengan router cerdas LLM

Peningkatan

Tanpa router cerdas LLM

Dengan router cerdas LLM

Peningkatan

Tanpa router cerdas LLM

Dengan router cerdas LLM

Peningkatan

Permintaan berhasil

3698

3612

-

1194

1194

-

1194

1194

-

Durasi benchmark

460,79s

435,70s

-

1418,54s

1339,04s

-

479,53s

456,69s

-

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

-