全部产品
Search
文档中心

Platform For AI:Tingkatkan efisiensi inferensi dengan router cerdas LLM

更新时间:Feb 25, 2026

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.

Penting

Router cerdas LLM merupakan layanan EAS khusus. Layanan ini harus diterapkan dalam kelompok layanan yang sama dengan layanan inferensi agar berfungsi dengan benar.

image

Proses intinya adalah sebagai berikut:

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

  2. Masuknya trafik: Permintaan pengguna pertama kali tiba di LLM Gateway.

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

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

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

  6. Buffering permintaan: Jika semua instans backend sedang mengalami beban tinggi, permintaan baru sementara dibuffer di antrian LLM Gateway. Permintaan tersebut menunggu hingga LLM Scheduler menentukan 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.

  • Mendukung protokol HTTP (HTTP_SSE) dan WebSocket. Komponen ini juga dapat menyimpan permintaan dalam cache saat instans inferensi backend sedang mengalami beban tinggi.

  • Fitur konversi protokol API Anthropic diaktifkan secara default. Fitur ini secara otomatis mengonversi permintaan yang sesuai dengan spesifikasi Anthropic ke format yang kompatibel dengan OpenAI. Anda dapat menggunakan tool dari ekosistem Claude Code untuk memanggil layanan model yang mengikuti standar antarmuka OpenAI tanpa mengubah kode Anda. Hal ini memungkinkan integrasi tanpa hambatan. Untuk informasi lebih lanjut, lihat Lampiran: Gunakan Claude Code untuk melakukan panggilan.

LLM Scheduler

Otak dari penjadwalan cerdas. Komponen ini mengumpulkan metrik real-time yang dilaporkan oleh seluruh LLM Agent. Selanjutnya, komponen ini menghitung instans target optimal untuk setiap permintaan berdasarkan kebijakan penjadwalan yang dipilih, seperti kebijakan berbasis prefix cache.

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 LLM Scheduler, serta melaporkan status kesehatan dan data beban instans tersebut.

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 Scheduler gagal, LLM Gateway secara 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. Setelah LLM Scheduler pulih, LLM Gateway secara otomatis melanjutkan penjadwalan cerdas.

  • Instans inferensi atau LLM Agent (penghapusan otomatis): Saat instans inferensi atau LLM Agent terkaitnya gagal, heartbeat antara LLM Agent dan LLM Scheduler terputus. LLM Scheduler segera 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

  1. Masuk ke Konsol PAI dan pilih wilayah tujuan di bagian atas halaman.

  2. Pada panel navigasi kiri, klik Elastic Algorithm Service (EAS). Pilih ruang kerja target untuk membuka halaman EAS.

  3. Klik Deploy Service dan pilih Scenario-based Model Deployment > Deploy LLM gateway.

  4. 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.

  5. 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.image

Catatan

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:

  1. Klik Deploy Service dan pilih Scenario-based Model Deployment > LLM Deployment.

  2. 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).

    Catatan

    Jika 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.

  3. 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.

  1. Dapatkan kredensial akses.

    1. Klik layanan router cerdas LLM untuk membuka halaman Overview. Di bagian Basic Information, klik View Endpoint Information.

    2. Pada halaman Endpoint Information, salin Internet Endpoint dan Token di bawah Service-specific Traffic Entry.image

  2. 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 Gateway dalam 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 mengonfigurasi metadata.cpu dan metadata.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 Scheduler dalam 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 LLMimage

  • IN: Throughput token input LLM.

  • OUT: Throughput token output LLM.

GPU Cache Usage

Penggunaan GPU KV Cache Mesin LLM

image

Engine Current Requests

Permintaan konkuren real-time Mesin LLM

image

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

  • Waiting: Jumlah permintaan dalam antrian tunggu Mesin LLM.

Gateway Current Requests

Permintaan real-time router cerdas LLM

image

  • Total: Total jumlah permintaan yang saat ini diterima oleh router cerdas LLM (total konkurensi real-time).

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

Time To First Token

Waktu hingga token pertama untuk permintaan

image

  • Max: Waktu maksimum hingga token pertama.

  • Avg: Waktu rata-rata hingga token pertama.

  • Min: Waktu minimum hingga token pertama.

  • TPxx: Nilai persentil untuk waktu hingga token pertama.

Time Per Output Token

Latensi Permintaan per Paket

image

  • Max: Latensi permintaan maksimum per paket.

  • Avg: Latensi permintaan rata-rata per paket.

  • Min: Latensi permintaan minimum per paket.

  • TPxx: Latensi permintaan per paket pada berbagai tingkat persentil.

Lampiran: Gunakan Claude Code untuk melakukan panggilan

  1. 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>
  2. 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.

Penting

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

-