LLM Gateway vs Router vs Inference Provider: Batasan Arsitektur

LLM gateway, router, dan inference provider adalah tiga lapisan berbeda dalam tumpukan (stack) penyajian model, dan mencampuradukkan ketiganya adalah kesalahan paling umum yang dilakukan tim saat merancang produk AI. Gateway berada paling dekat dengan aplikasi Anda dan menangani autentikasi, normalisasi, serta observabilitas; router memutuskan model atau penyedia mana yang menangani permintaan tertentu; inference provider adalah entitas yang sebenarnya menjalankan bobot (weights) dan mengembalikan token.

Kesalahan dalam memahami batasan ini menyebabkan integrasi yang rapuh: tim melakukan hardcode pada SDK penyedia tunggal, kemudian beberapa bulan kemudian menyadari bahwa menambahkan model cadangan atau membandingkan biaya antara Claude Sonnet 5, GPT-5.5, dan DeepSeek V4 Flash berarti harus menulis ulang sebagian besar penanganan permintaan mereka. Artikel ini memisahkan ketiga lapisan tersebut, menunjukkan di mana tanggung jawab sebenarnya berada, dan memberikan kerangka kerja keputusan untuk mengevaluasi vendor di setiap kategori.

Poin Penting

• Inference provider menjalankan bobot model dan mengekspos API (OpenAI, Anthropic, Google, DeepSeek, atau mesin yang di-host sendiri seperti vLLM); router memilih di antara penyedia atau model per permintaan; gateway adalah lapisan yang menghadap aplikasi yang menyatukan autentikasi, pemformatan, logging, dan failover di keduanya.
• Logika perutean (pemilihan berbasis biaya, latensi, atau kapabilitas) dapat ada sebagai layanan mandiri atau sebagai fitur di dalam gateway; ini bukan hal yang sama dengan gateway itu sendiri.
• Menjalankan sendiri (self-hosting) inference provider, menggunakan penyedia berbasis API, dan menggunakan gateway multi-penyedia tidak saling meniadakan; sistem produksi sering kali menggabungkan ketiganya tergantung pada model dan beban kerja.
• Evaluasi vendor dengan menanyakan di lapisan mana mereka sebenarnya beroperasi, karena produk yang dipasarkan sebagai "router" mungkin hanya merutekan antara endpoint yang kompatibel dengan OpenAI yang tidak mereka host sendiri, sementara "gateway" mungkin menggabungkan perutean ditambah fitur tata kelola yang mungkin belum Anda butuhkan.

Apa yang Sebenarnya Dilakukan Inference Provider

Inference provider adalah lapisan yang memiliki bobot model, GPU (atau akselerator yang setara), dan mesin penyajian tingkat rendah. Ini mencakup penyedia API komersial seperti Anthropic (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5), OpenAI (GPT-5.5), Google (Gemini 3.5 Flash), Zhipu (GLM-5.2), dan DeepSeek (DeepSeek V4 Pro, DeepSeek V4 Flash), serta penyebaran model bobot terbuka (open-weight) yang di-host sendiri seperti Qwen3.7 Plus, MiniMax M3, atau Kimi K2.7 Code.

Jika Anda melakukan self-hosting, lapisan inference provider adalah perangkat lunak yang Anda jalankan sendiri. Dokumentasi penyajian vLLM menjelaskan mesin inferensi yang dibangun di sekitar continuous batching dan penanganan perhatian (attention) yang efisien memori untuk melayani beban kerja LLM dalam skala besar, yang merupakan jenis komponen yang berada tepat di bawah penyebaran model yang di-host sendiri. Menjalankan vLLM (atau mesin yang sebanding) menjadikan Anda inference provider untuk model tersebut, yang bertanggung jawab atas perencanaan kapasitas GPU, penskalaan, dan uptime, sebagai ganti kendali atas biaya dan lokalisasi data.

Jika Anda menggunakan API komersial, infrastruktur dan batas kecepatan (rate limit) penyedia menjadi batasan Anda. Setiap penyedia memiliki skema autentikasi, skema permintaan dan respons, kode kesalahan, dan perilaku batas kecepatan sendiri. Ini adalah lapisan di mana kualitas model, jendela konteks (context window), dan latensi mentah sebenarnya ditentukan. Tidak ada router atau gateway yang dapat mengubah kemampuan inference provider; mereka hanya mengubah cara Anda menjangkaunya.

Apa yang Dilakukan Router

Router adalah logika keputusan yang memilih tujuan, model, atau penyedia untuk permintaan yang masuk. Perutean dapat terjadi pada beberapa sumbu: biaya (kirim kueri sederhana ke model murah seperti DeepSeek V4 Flash atau Gemini 3.5 Flash, cadangkan Claude Opus 4.8 untuk kueri kompleks), latensi (pilih penyedia mana pun yang saat ini merespons paling cepat untuk model tertentu), atau ketersediaan (fail over ke penyedia kedua jika yang pertama mengalami penurunan performa).

Penjelasan publik OpenRouter tentang perutean model menjelaskan pola ini di tingkat model: permintaan untuk model bobot terbuka dapat dirutekan ke berbagai penyedia yang menghosting bobot yang sama, sehingga satu panggilan model logis dapat dipenuhi oleh salah satu dari beberapa backend. Dokumentasi pemilihan penyedia OpenRouter lebih lanjut menjelaskan parameter untuk menyatakan preferensi urutan dan untuk mengecualikan penyedia tertentu dari pertimbangan, yang merupakan mekanisme di mana pemanggil menyatakan niat perutean secara eksplisit daripada menyerahkannya sepenuhnya ke platform.

Poin arsitektur yang penting adalah bahwa perutean adalah kebijakan, bukan kategori produk itu sendiri. Anda dapat mengimplementasikan perutean dasar sendiri dalam kode aplikasi (if/else sederhana pada jenis tugas atau loop coba-lagi-saat-error), membelinya sebagai lapisan perutean khusus, atau mendapatkannya yang dibundel di dalam gateway yang lebih luas. Evaluasi kapabilitas perutean dengan menanyakan sinyal apa yang digunakannya (harga, latensi, tingkat kesalahan, kapabilitas model) dan apakah sinyal tersebut dapat dikonfigurasi atau tetap.

Apa yang Dilakukan Gateway

Gateway adalah lapisan yang sebenarnya diajak berkomunikasi oleh kode aplikasi Anda. Tugasnya adalah menyajikan satu antarmuka yang konsisten terlepas dari penyedia inferensi mana yang akhirnya melayani permintaan tersebut. Gateway biasanya mencakup:

• Skema permintaan dan respons yang terpadu di seluruh penyedia, sehingga beralih dari GPT-5.5 ke Claude Sonnet 5 tidak memerlukan penulisan ulang logika parsing Anda.
• Autentikasi dan manajemen kunci, sehingga kredensial penyedia tidak tersebar di seluruh kode aplikasi.
• Logging, pelacakan penggunaan, dan atribusi biaya di setiap model dan penyedia yang digunakan.
• Perilaku failover dan coba-lagi (retry) saat penyedia lambat, terkena batas kecepatan, atau mengembalikan kesalahan.
• Secara opsional, logika perutean sebagai satu fitur di antara beberapa fitur lainnya, bukan keseluruhan produk.

Halaman riset model TokenLab mengkatalogkan model saat ini di seluruh penyedia, termasuk model frontier (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5, GPT-5.5, GLM-5.2, Gemini 3.5 Flash), model yang berorientasi pada pengkodean (Claude Sonnet 5, Kimi K2.7 Code, DeepSeek V4 Pro, DeepSeek V4 Flash), dan kandidat perutean berbiaya rendah (DeepSeek V4 Flash, GLM-5.2, Laguna XS 2.1, Hy3, Qwen3.7 Plus, MiniMax M3), yang merupakan jenis referensi yang dibutuhkan pengguna gateway saat memutuskan ke mana harus merutekan. Lihat tulisan TokenLab tentang mengapa gateway API AI terpadu penting di tahun 2026 untuk pembahasan yang lebih lengkap tentang masalah penyatuan itu sendiri.

Batasan Arsitektur, Secara Konkret

Batasan paling mudah dilihat dengan melacak satu permintaan melalui ketiga lapisan tersebut.

1. Aplikasi Anda mengirimkan permintaan penyelesaian chat (chat completion) ke endpoint gateway, menentukan jenis tugas atau preferensi model.
2. Gateway mengautentikasi permintaan, menormalisasinya ke dalam skema yang diharapkan oleh masing-masing penyedia kandidat, dan menyerahkannya ke logika perutean.
3. Router mengevaluasi kebijakan yang dikonfigurasinya (batas biaya, target latensi, atau urutan penyedia eksplisit) dan memilih tujuan, misalnya Claude Sonnet 5 melalui API Anthropic, atau instance DeepSeek V4 Pro yang di-host sendiri yang disajikan melalui vLLM.
4. Inference provider mengeksekusi model dan mengembalikan token.
5. Gateway menormalisasi respons kembali ke bentuk yang konsisten dan mencatat hasilnya (latensi, biaya, penyedia yang digunakan, keberhasilan atau kegagalan) untuk lapisan observabilitas Anda.

Setiap lapisan dapat gagal secara independen. Pemadaman penyedia adalah masalah lapisan inferensi; keputusan perutean yang buruk (mengirim permintaan konteks panjang ke model dengan jendela konteks kecil) adalah masalah lapisan router; skema respons yang tidak konsisten yang merusak parser Anda adalah masalah lapisan gateway. Memahami lapisan mana yang menghasilkan kegagalan tertentu adalah hal yang membuat debugging menjadi dapat dikelola. Artikel TokenLab tentang infrastruktur keandalan untuk API AI membahas isolasi kegagalan di lapisan-lapisan ini secara lebih mendalam.

Daftar Periksa Keputusan

Gunakan daftar periksa ini saat mengevaluasi apakah Anda memerlukan gateway, router, integrasi penyedia langsung, atau kombinasinya.

Pertanyaan	Jika ya	Jika tidak
Apakah Anda memanggil lebih dari satu model atau penyedia saat ini, atau berharap demikian dalam 12 bulan ke depan?	Anda memerlukan lapisan gateway atau router, bukan panggilan SDK langsung per penyedia.	Integrasi SDK penyedia langsung mungkin cukup untuk jangka pendek.
Apakah Anda memerlukan failover otomatis saat penyedia mengalami penurunan performa atau batas kecepatan?	Anda memerlukan logika tingkat router dengan pemeriksaan kesehatan dan urutan cadangan.	Coba-lagi manual dalam kode aplikasi mungkin dapat diterima pada awalnya.
Apakah Anda memerlukan visibilitas biaya dan penggunaan per model di seluruh penyedia di satu tempat?	Anda memerlukan logging dan atribusi tingkat gateway.	Dasbor bawaan penyedia mungkin dapat memenuhi kebutuhan Anda untuk saat ini.
Apakah Anda melakukan self-hosting model bobot terbuka apa pun (GLM-5.2, DeepSeek V4 Pro, Qwen3.7 Plus, Kimi K2.7 Code)?	Anda juga mengoperasikan lapisan inference provider dan memerlukan infrastruktur penyajian seperti vLLM.	Anda dapat sepenuhnya mengandalkan penyedia API komersial.
Apakah Anda perlu merutekan berdasarkan jenis tugas (model murah untuk klasifikasi, model frontier untuk penalaran)?	Anda memerlukan kebijakan router eksplisit, bukan sekadar failover.	Satu model default mungkin sudah cukup.

Contoh Bentuk Permintaan

Contoh di bawah ini mengilustrasikan bentuk umum permintaan gaya gateway yang menyatakan preferensi model utama dan daftar cadangan, pola yang konsisten dengan bagaimana dokumentasi pemilihan penyedia OpenRouter menjelaskan cara menyatakan preferensi perutean. Anggap nama field sebagai ilustrasi; verifikasi parameter yang tepat terhadap referensi API gateway pilihan Anda saat ini sebelum melakukan deployment.

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "model": "claude-sonnet-5",
  "fallback_models": ["gpt-5.5", "deepseek-v4-flash"],
  "routing_policy": {
    "strategy": "cost_then_latency",
    "max_cost_per_1k_tokens": 0.01
  },
  "messages": [
    {"role": "user", "content": "Summarize the attached incident report."}
  ]
}

Dalam bentuk ini, gateway memiliki normalisasi permintaan dan kontrak respons, router memiliki interpretasi routing_policy dan fallback_models, dan penyedia mana pun yang akhirnya dipilih memiliki tanggung jawab untuk benar-benar menghasilkan penyelesaian. Konfirmasikan skema permintaan dan respons yang tepat terhadap dokumentasi saat ini sebelum mengandalkan nama field tertentu dalam produksi.

Keterbatasan

Dokumentasi publik dari OpenRouter dan vLLM menjelaskan mekanisme perutean dan penyajian umum, bukan jaminan universal. Latensi, harga, dan perilaku failover yang tepat bervariasi menurut penyedia dan berubah seiring waktu, jadi verifikasi angka saat ini secara langsung terhadap dokumentasi penyedia daripada artikel ini. Self-hosting dengan vLLM mengalihkan tanggung jawab operasional (perencanaan kapasitas, penskalaan, patching) ke tim Anda; ini tidak menghilangkan pekerjaan infrastruktur, melainkan memindahkannya. Tidak ada kebijakan perutean yang dapat mengompensasi pilihan model yang secara fundamental tidak cocok, seperti mengirim tugas yang memerlukan penalaran konteks panjang ke model yang tidak cocok untuk itu; konfigurasi router bukanlah pengganti untuk mengevaluasi kapabilitas model terhadap beban kerja Anda, itulah sebabnya menjaga referensi model yang mutakhir seperti riset model TokenLab itu penting.

FAQ

Apakah gateway sama dengan router? Tidak. Router adalah logika keputusan untuk memilih model atau penyedia; gateway adalah lapisan yang lebih luas yang menghadap aplikasi yang mencakup perutean sebagai salah satu fitur yang mungkin ada di samping autentikasi, normalisasi, dan logging.

Bisakah saya menjadi inference provider saya sendiri dan tetap menggunakan gateway? Ya. Model yang di-host sendiri yang disajikan melalui mesin seperti vLLM dapat berada di belakang gateway yang sama dengan penyedia API komersial, selama gateway mendukung endpoint kustom atau yang kompatibel dengan OpenAI.

Apakah saya memerlukan ketiga lapisan tersebut pada hari pertama? Belum tentu. Integrasi langsung penyedia tunggal cukup masuk akal untuk prototipe awal. Segera setelah Anda memerlukan failover, kontrol biaya multi-model, atau perbandingan penyedia, memperkenalkan gateway dengan perutean menjadi sepadan dengan biaya rekayasanya.

Jika Anda sedang mengevaluasi lapisan mana yang harus diadopsi terlebih dahulu, tinjau opsi model saat ini di halaman riset model TokenLab dan Mulailah dengan pengaturan gateway yang memungkinkan Anda menambahkan perutean dan penyedia secara bertahap daripada berkomitmen pada satu integrasi sejak awal.