LLM Routing 2026: Panduan RouteLLM, Portkey, dan OpenRouter untuk Optimasi Biaya dan Latensi

Diperbarui: 4 September 2026

LLM routing adalah pola arsitektur yang otomatis memilih model bahasa terbaik untuk setiap permintaan berdasarkan biaya, latensi, atau kualitas jawaban, biasanya melalui gateway seperti Portkey, OpenRouter, atau LiteLLM, atau melalui router pembelajaran mesin seperti RouteLLM. Dalam praktik saya membangun workflow produksi sepanjang 2025–2026, memindahkan 60–80% traffic dari model frontier ke model yang lebih murah tanpa menurunkan kualitas jawaban adalah efek paling nyata dari routing yang benar. Panduan ini membandingkan empat tool utama, memberikan contoh kode siap-jalan, dan menjelaskan kapan setiap pola cocok.

• LLM routing memindahkan keputusan "model mana yang menjawab" dari kode aplikasi ke lapisan gateway atau router terpisah, mirip API gateway di dunia microservice.
• Ada empat kelas tool: gateway agregator (OpenRouter), gateway self-hosted (Portkey, LiteLLM), dan router berbasis ML (RouteLLM) yang belajar kapan model kecil sudah cukup.
• Portkey dan LiteLLM memberi kontrol penuh (fallback, retry, load balancing, guardrails), sementara OpenRouter menyederhanakan billing lintas 300+ model.
• RouteLLM dari LMSYS mencapai penghematan biaya hingga 85% pada MT-Bench dengan menurunkan kualitas kurang dari 5% jika dikalibrasi dengan benar.
• Pola paling andal untuk 2026 adalah gateway (Portkey/LiteLLM) plus router semantik atau prompt-based di atasnya, bukan memilih salah satu.
• Selalu ukur biaya per successful task, bukan biaya per token. Routing yang salah bisa membuat retry lebih mahal daripada memakai model besar sejak awal.

Apa itu LLM routing dan mengapa penting di 2026

Sebagai recovering ops engineer, saya suka menyebut LLM routing sebagai "reverse proxy untuk kecerdasan". Alih-alih meng-hardcode gpt-4o di kode aplikasi, permintaan pergi ke satu endpoint (router) yang memutuskan model mana yang benar-benar dieksekusi berdasarkan konten prompt, prioritas, atau anggaran. Pemisahan ini memberi tim dua kekuatan yang mahal untuk didapat dengan cara lain: kemampuan mengganti model tanpa deploy, dan kemampuan mencampur beberapa model dalam satu pipeline.

Kenapa 2026 jadi tahun routing benar-benar dibutuhkan? Pertama, ekonomi model. Selisih harga antara frontier (Claude Opus 4.5, GPT-5, Gemini 2.5 Pro) dan model small (Haiku 4.5, GPT-5-mini, Gemini 2.5 Flash) kini mencapai 20–40×. Kedua, konsistensi kontrak. Standar Structured Outputs dan tool use sudah cukup mirip antar provider sehingga routing tidak lagi memaksa penulisan ulang prompt untuk setiap model. Ketiga, insiden. Waktu Anthropic sempat throttle region APAC pada Juli 2026, tim yang punya fallback OpenAI di gateway Portkey tetap online. Sisanya menulis postmortem.

Sudut pandang praktis: kalau tim Anda pakai lebih dari dua model provider atau menghabiskan lebih dari $500/bulan untuk API LLM, kemungkinan besar Anda sudah lewat titik di mana routing memberi ROI dalam minggu pertama.

Empat kategori tool LLM routing

Landscape LLM routing sering membingungkan karena istilah "gateway", "proxy", dan "router" dipakai bertukar-tukar. Saya membedakannya jadi empat kategori berdasarkan pertanyaan operasional: siapa yang hosting, siapa yang mengambil keputusan, dan siapa yang menagih.

1. Managed gateway agregator

OpenRouter, Together, dan Replicate masuk kategori ini. Satu API key, satu invoice, akses ke ratusan model. Anda hanya menyebut anthropic/claude-opus-4.5 atau openai/gpt-5-mini di parameter model. Routing hanya sebatas menerjemahkan nama model ke endpoint provider yang sesuai. Tidak ada kecerdasan lanjutan kecuali Anda menulisnya sendiri.

2. Managed gateway dengan control plane

Portkey dan Helicone masuk sini. Selain agregasi, mereka menambahkan fallback deklaratif, retry, load balancing, semantic caching, dan observability. Konfigurasi berbentuk YAML/JSON yang bisa diubah tanpa deploy aplikasi. Cocok untuk tim yang ingin routing rules didefinisikan oleh SRE atau platform team.

3. Self-hosted proxy

LiteLLM adalah pemain dominan. Anda menjalankan container di infrastruktur sendiri, dan ia menerima permintaan OpenAI-compatible lalu meneruskannya ke provider mana pun. Manfaat utama: kredensial provider tidak pernah keluar dari VPC Anda, dan biaya tambahan hanya sebatas resource server. Untuk regulasi seperti PDP di Indonesia atau GDPR, ini sering jadi persyaratan wajib.

4. Model router berbasis ML

RouteLLM dari LMSYS, NotDiamond, dan Martian masuk kategori ini. Bukan cuma meneruskan permintaan, mereka memprediksi apakah model kecil sudah cukup atau permintaan perlu dieskalasi ke model besar. Prediksi dibuat dengan classifier ringan (BERT-based) yang dilatih pada preferensi human atau LLM judge. Ini kelas paling menarik untuk optimasi biaya agresif.

Perbandingan RouteLLM, Portkey, OpenRouter, dan LiteLLM

Tabel di bawah ini merangkum empat opsi yang paling sering saya rekomendasikan pada Q3 2026. Saya sengaja menghindari klaim seperti "yang terbaik", karena pilihan bergantung pada apakah Anda ingin kontrol infrastruktur, kecepatan integrasi, atau optimasi biaya berbasis prediksi.

Aspek	RouteLLM	Portkey	OpenRouter	LiteLLM
Kategori utama	ML router (weak/strong)	Managed gateway + control plane	Managed agregator	Self-hosted proxy
Deployment	Library Python / server	SaaS + opsi self-hosted enterprise	SaaS	Self-hosted (docker/k8s) atau SaaS
Provider didukung	Bebas (via LiteLLM di bawah)	250+ model	300+ model	100+ provider
Fallback deklaratif	Tidak (harus kode sendiri)	Ya, YAML/JSON	Terbatas (order model)	Ya, config router
Semantic caching	Tidak	Ya	Tidak	Ya (via Redis)
Cost-based routing	Ya (dilatih)	Manual via aturan	Manual	Manual via config
Guardrail terintegrasi	Tidak	Ya (Guardrails AI, Aporia)	Tidak	Ya (plugin)
Model harga	Open source (Apache 2.0)	Freemium, $49+/bulan	Markup ~5% di atas provider	Open source (MIT) + enterprise
Kurva belajar	Menengah–tinggi	Rendah	Sangat rendah	Menengah

Aturan singkat saya: kalau Anda baru mulai dan ingin bereksperimen dengan banyak model, pakai OpenRouter. Kalau Anda sudah di produksi dan butuh SLA, fallback, dan observability, pakai Portkey atau LiteLLM. Kalau Anda ingin memotong biaya inference agresif dan punya dataset preferensi, tumpuk RouteLLM di atas gateway pilihan.

Implementasi RouteLLM: router weak-vs-strong

RouteLLM adalah proyek riset LMSYS yang dirilis pertengahan 2024 dan diperbarui akhir 2025 dengan classifier yang lebih akurat. Idenya sederhana: latih classifier untuk memprediksi apakah model "lemah" (misalnya gpt-5-mini) akan menghasilkan jawaban yang cukup baik dibandingkan model "kuat" (misalnya gpt-5). Kalau ya, route ke lemah. Kalau tidak, escalate.

Repository GitHub RouteLLM menyediakan empat jenis router: bert, causal_llm, mf (matrix factorization), dan sw_ranking. Untuk workflow produksi, saya biasanya mulai dengan mf. Cepat, ringan, dan hasilnya kompetitif dengan classifier BERT pada benchmark MT-Bench.

from routellm.controller import Controller

client = Controller(
    routers=["mf"],
    strong_model="gpt-5",
    weak_model="gpt-5-mini",
)

# Threshold 0.11593 dipilih berdasarkan kalibrasi:
# 50% traffic akan diarahkan ke weak model pada dataset MT-Bench.
response = client.chat.completions.create(
    model="router-mf-0.11593",
    messages=[
        {"role": "user", "content": "Jelaskan cara kerja OAuth 2.0 dalam 3 kalimat."}
    ],
)

print(response.choices[0].message.content)
print(f"Model dipakai: {response.model}")

Threshold di nama model (router-mf-0.11593) adalah tombol utama. Nilai lebih tinggi berarti lebih banyak permintaan diescalate ke strong, dan nilai lebih rendah berarti lebih banyak ditangani weak. Skrip calibrate_router.py di repo membantu memilih threshold yang mempertahankan target kualitas Anda.

Portkey untuk fallback dan load balancing produksi

Portkey menonjol karena konfigurasinya deklaratif dan bisa diubah tanpa deploy. Bagi saya ini kunci: SRE bisa menambahkan fallback pada 03:00 saat insiden tanpa memaksa developer merge PR. Konfig routing dinamakan Configs dan berbentuk JSON.

{
  "strategy": {
    "mode": "fallback",
    "on_status_codes": [429, 500, 502, 503, 504]
  },
  "targets": [
    {
      "virtual_key": "anthropic-primary",
      "override_params": {"model": "claude-opus-4-5"}
    },
    {
      "virtual_key": "openai-secondary",
      "override_params": {"model": "gpt-5"}
    },
    {
      "virtual_key": "google-tertiary",
      "override_params": {"model": "gemini-2.5-pro"}
    }
  ]
}

Alur dalam prosa: request masuk ke Portkey, Portkey memanggil Claude Opus 4.5, dan jika balik 429/5xx, langsung fallback ke GPT-5 tanpa penundaan tambahan. Jika masih gagal, ke Gemini 2.5 Pro. Kalau semua gagal, Portkey melempar 502 ke aplikasi Anda. Semua transisi dicatat sebagai satu trace, jadi observability tetap koheren. Pola ini menyelamatkan salah satu klien e-commerce saya waktu insiden multi-region Anthropic Juli lalu (jujur, tim saya sudah siap begadang, tapi ternyata gateway menangani semuanya sendiri).

Untuk load balancing (bukan fallback), ubah mode ke loadbalance dan tambahkan weight. Cocok untuk membagi traffic antara akun Azure OpenAI dan OpenAI langsung, atau untuk canary release model baru dengan 10% traffic.

OpenRouter untuk agregasi cepat lintas provider

OpenRouter mengambil pendekatan berbeda: satu API key untuk 300+ model, dengan billing pay-as-you-go tanpa langganan. Trade-off yang jujur: Anda membayar markup ~5% di atas harga provider, tetapi menghemat waktu procurement (satu vendor, satu invoice, satu compliance review).

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="sk-or-v1-...",
)

response = client.chat.completions.create(
    model="anthropic/claude-opus-4.5",
    messages=[{"role": "user", "content": "Tulis SQL migrasi untuk soft delete."}],
    extra_body={
        "route": "fallback",
        "models": [
            "anthropic/claude-opus-4.5",
            "openai/gpt-5",
            "google/gemini-2.5-pro"
        ]
    }
)

Parameter route: fallback yang dirilis awal 2026 memberi kemampuan fallback dasar tanpa perlu Portkey. Kelemahannya: tidak ada retry cerdas, tidak ada semantic caching, dan aturan hanya berbasis error, bukan konten prompt. Untuk MVP dan prototipe, cukup. Untuk beban produksi tinggi, saya biasanya "lulus" ke Portkey atau LiteLLM.

LiteLLM sebagai proxy self-hosted

LiteLLM adalah tool yang paling sering saya deploy untuk klien yang bekerja di sektor perbankan atau kesehatan. Alasannya: proxy jalan di infrastruktur Anda, kredensial provider tidak pernah keluar VPC, dan konfigurasi bisa disimpan di git. Instalasi minimal via Docker:

# config.yaml
model_list:
  - model_name: claude-opus
    litellm_params:
      model: anthropic/claude-opus-4-5
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: gpt5-fallback
    litellm_params:
      model: openai/gpt-5
      api_key: os.environ/OPENAI_API_KEY

router_settings:
  routing_strategy: usage-based-routing-v2
  fallbacks:
    - claude-opus: ["gpt5-fallback"]
  redis_host: os.environ/REDIS_HOST
  redis_port: 6379

docker run -d -p 4000:4000 \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  -e REDIS_HOST=redis.internal \
  -v $(pwd)/config.yaml:/app/config.yaml \
  ghcr.io/berriai/litellm:main-stable \
  --config /app/config.yaml

Aplikasi Anda tinggal menunjuk base_url="http://localhost:4000" dan menggunakan SDK OpenAI standar. Semua model (Anthropic, OpenAI, Google, Cohere, Mistral, open-weights via vLLM) tersedia di endpoint yang sama. Untuk detail lebih lanjut, dokumentasi proxy LiteLLM sudah sangat lengkap.

Pola arsitektur: menggabungkan gateway dan router

Kesalahan mental yang sering saya lihat: memperlakukan RouteLLM dan Portkey sebagai alternatif. Sebenarnya mereka bekerja pada layer berbeda. Router memutuskan model mana yang cocok untuk task ini. Gateway memutuskan bagaimana memanggil model yang dipilih dengan andal. Digabung, keduanya membentuk pipeline dua tahap yang tangguh.

Arsitektur referensi yang saya pakai untuk beberapa klien fintech Indonesia:

1. Aplikasi mengirim permintaan ke internal endpoint /v1/chat.
2. Middleware Python memanggil RouteLLM controller untuk memutuskan apakah task perlu strong atau weak.
3. Berdasarkan keputusan, middleware memanggil LiteLLM proxy dengan model name yang sesuai (misalnya strong-cluster atau weak-cluster).
4. LiteLLM proxy menangani fallback antar provider, retry dengan exponential backoff, dan semantic caching via Redis.
5. Response dikembalikan ke aplikasi, sementara trace lengkap dikirim ke Langfuse untuk analisis biaya per task.

Untuk pemahaman lebih dalam tentang lapisan observability yang saya sebut di atas, lihat panduan LLM observability dengan OpenTelemetry, Langfuse, dan Helicone. Kalau workflow Anda banyak memakai tool use atau structured outputs, cek dulu panduan function calling LLM dan structured outputs supaya router tidak memindahkan traffic ke model yang tidak mendukung skema Anda.

Semantic routing dan classifier ringan

Tidak semua team siap memakai RouteLLM, karena melatih dan mengkalibrasi classifier butuh dataset preferensi. Alternatif yang lebih mudah adalah semantic routing: pakai embedding untuk mengukur kemiripan prompt dengan kategori tugas yang sudah pra-labeled, lalu route berdasarkan kategori.

Contoh sederhana dengan library semantic-router:

from semantic_router import Route, RouteLayer
from semantic_router.encoders import OpenAIEncoder

routes = [
    Route(
        name="code_generation",
        utterances=[
            "tulis fungsi Python untuk parse CSV",
            "buat SQL query gabung tiga tabel",
            "refactor komponen React ini",
        ],
    ),
    Route(
        name="short_answer",
        utterances=[
            "apa ibukota Norwegia",
            "berapa 15% dari 240",
            "definisi throughput",
        ],
    ),
    Route(
        name="long_reasoning",
        utterances=[
            "analisis pro-kontra migrasi ke Kubernetes",
            "buat rencana peluncuran produk 90 hari",
            "evaluasi arsitektur event-driven vs request-response",
        ],
    ),
]

encoder = OpenAIEncoder(name="text-embedding-3-small")
rl = RouteLayer(encoder=encoder, routes=routes)

def choose_model(prompt: str) -> str:
    match = rl(prompt).name
    if match == "code_generation":
        return "anthropic/claude-opus-4-5"
    if match == "short_answer":
        return "openai/gpt-5-nano"
    return "openai/gpt-5"  # default untuk long reasoning

Semantic router jauh lebih murah dijalankan (satu embedding call, biasanya <5ms) dan tidak butuh dataset preferensi. Kelemahannya: keputusan didasarkan pada domain, bukan kualitas yang bisa dicapai model kecil. Cocok untuk task yang jelas dipisahkan seperti chatbot customer service dengan intent yang stabil.

Menghitung penghematan biaya dan dampak latensi

Semua vendor akan menjanjikan "hemat 70%". Sebagai arsitek workflow, tugas Anda adalah memverifikasi angka itu di dataset produksi sendiri. Rumus yang saya pakai:

penghematan_bulanan = (
    total_requests
    * fraksi_ke_weak
    * (harga_strong_per_call - harga_weak_per_call)
) - overhead_gateway

Contoh nyata dari satu klien SaaS Q2 2026: 1,2 juta permintaan/bulan, biaya rata-rata GPT-5 sekitar $0.02/call. Setelah routing dengan RouteLLM (mf, threshold 0.115), 62% permintaan turun ke GPT-5-mini yang berharga $0.0012/call. Penghematan bulanan: 1.200.000 × 0.62 × ($0.02 - $0.0012) - $49 (Portkey) = $13.987. Kualitas jawaban diukur dengan LLM judge menurun 3.1% pada benchmark internal, dianggap dapat diterima.

Dampak latensi patut diperhatikan. Setiap hop menambah 5–20ms. Portkey SaaS biasanya menambah 15–25ms. LiteLLM self-hosted di region yang sama dengan aplikasi biasanya <5ms. RouteLLM menambah 20–50ms untuk inferensi classifier. Untuk aplikasi realtime seperti voice agent, tumpukan classifier + gateway + provider mungkin terlalu banyak. Lebih baik pakai router prompt-based yang deterministic dan cepat.

Optimasi biaya lain yang bersinergi baik dengan routing adalah prompt caching pada Anthropic, OpenAI, dan Gemini. Kombinasi keduanya sering memberi total penghematan 75–90%.

Kesalahan umum yang harus dihindari

Mengukur biaya per token, bukan per task berhasil

Model kecil sering butuh retry atau clarification tambahan. Biaya per token turun 20×, tetapi biaya per task berhasil hanya turun 5× karena volume retry naik. Selalu ukur end-to-end. Saya pernah kena bug persis ini di project pertama saya dengan routing, dan itu pelajaran mahal.

Melupakan perbedaan schema tool use

Format function calling OpenAI, Anthropic, dan Google tidak identik. Kalau workflow Anda mengandalkan tool use kompleks, pastikan router tidak memindahkan traffic ke model yang tidak mendukung skema Anda.

Tidak menyiapkan circuit breaker

Kalau Anthropic down dan Anda fallback ke OpenAI, pastikan bukan cuma request tunggal yang beralih. Semua request untuk 5–10 menit ke depan harus beralih untuk menghindari beban thundering herd. Portkey dan LiteLLM mendukung ini natively.

Menggabungkan routing dan A/B testing

Router menentukan model terbaik untuk task, sementara A/B test menentukan hipotesis produk. Menggabungkan keduanya membuat sinyal saling mengaburkan. Pisahkan lapisan eksperimen dari lapisan routing.

Integrasi dengan n8n, Zapier, dan Temporal

Untuk workflow yang tidak berbentuk aplikasi web tradisional, integrasi gateway tetap sederhana karena semua opsi di atas exposing OpenAI-compatible endpoint. Di n8n, node "OpenAI Chat Model" cukup diarahkan ke base URL Portkey atau LiteLLM Anda. Semua fitur (fallback, caching, routing) bekerja transparan.

Di Zapier, saya memakai action "Webhook" yang memanggil endpoint gateway internal dan menyimpan response ke storage. Overhead ini worth it karena Anda bisa mengubah model tanpa menyentuh puluhan Zap. Untuk workflow durable dengan Temporal atau Inngest, saya biasanya membungkus panggilan gateway dalam activity terpisah dengan retry policy yang lebih longgar dari default Temporal, karena gateway sudah menangani retry di layernya, dan retry ganda cuma bikin request timeout jadi masalah pelik.

Untuk pipeline data yang lebih kompleks dengan retrieval, lihat pola arsitektur di panduan membangun pipeline RAG produksi 2026. Routing gateway biasanya masuk di lapisan generator akhir pipeline.

Frequently Asked Questions (Tanya Jawab)

Apa perbedaan LLM router dan LLM gateway?

Router membuat keputusan model mana yang cocok untuk task ini berdasarkan konten prompt, biaya, atau kualitas. Gateway meneruskan permintaan ke provider yang dipilih dengan andal, menangani autentikasi, retry, fallback, caching, dan observability. Portkey dan LiteLLM adalah gateway, sementara RouteLLM dan NotDiamond adalah router. Keduanya sering digunakan bersama.

Apakah OpenRouter aman untuk aplikasi produksi?

Untuk beban ringan hingga menengah, ya. OpenRouter menjaga SLA yang wajar dan menyediakan fallback dasar sejak awal 2026. Untuk beban regulasi tinggi (perbankan, kesehatan) atau volume besar (>$10.000/bulan), pertimbangkan LiteLLM self-hosted karena kredensial provider tidak pernah keluar dari VPC Anda dan margin markup 5% menjadi signifikan pada volume tersebut.

Berapa banyak penghematan biaya realistis dari LLM routing?

Pada dataset umum, RouteLLM dan router serupa mencapai penghematan 50–70% dengan penurunan kualitas <5%. Kombinasi dengan prompt caching dan semantic caching sering memberi total penghematan 75–90%. Yang penting: ukur pada dataset produksi Anda sendiri, bukan benchmark publik, karena distribusi prompt sangat mempengaruhi hasil.

Apakah LiteLLM proxy menambah latensi signifikan?

Kalau di-deploy di region dan VPC yang sama dengan aplikasi Anda, overhead biasanya <5ms. Kalau via SaaS atau di region berbeda, bisa 20–50ms. Untuk aplikasi realtime seperti voice agent, self-host di region aplikasi adalah wajib. Untuk API asinkron atau batch, latensi tambahan tidak relevan.

Kapan sebaiknya menggunakan router ML seperti RouteLLM dibandingkan aturan manual?

Router ML unggul ketika Anda tidak bisa mendefinisikan aturan sederhana untuk memisahkan "task mudah" dari "task sulit", misalnya asisten umum atau chatbot open-domain. Aturan manual (semantic router atau if/else berbasis intent) unggul ketika domain sempit dan intent bisa diklasifikasikan dengan jelas, misalnya customer service dengan 20 kategori tetap.

Bagaimana cara memilih threshold RouteLLM yang tepat?

Mulai dengan threshold default 0.11593 yang mencapai 50% traffic ke weak model pada MT-Bench. Kumpulkan 100–500 sampel prompt produksi, evaluasi kualitas jawaban dari kedua model dengan LLM judge, lalu gunakan skrip calibrate_router.py di repo untuk menemukan threshold yang menahan target kualitas (misalnya penurunan <3% dari strong-only baseline).