Bagaimana cara kerja gateway LLM? Panduan praktis untuk tim engineering

Gateway LLM berada di antara aplikasi Anda dan penyedia model yang Anda hubungkan melaluinya, sehingga Anda memiliki satu tempat untuk mengelola kredensial dan melacak penggunaan.

“Saat ini, semuanya kacau balau,” kata seorang engineer yang menulis di Reddit dalam r/LLMDevs pada September 2026.

“Setiap orang punya set kunci masing-masing untuk Claude, OpenAI, AWS Bedrock, dan semua penyedia inferensi lain yang kami gunakan.”

Liputan BigGo tentang llm-proxy-tk, sebuah gateway FastAPI yang ringan, mengibaratkan penyiapan ini sebagai upaya mengubah LLM menjadi “air keran korporat,” dengan gateway sebagai katup utama gedung.

Namun, sebelum Anda menaruh kepercayaan sebesar itu pada sistem pipanya, mari kita lihat apa yang sebenarnya Anda pasang.

Apa itu gateway LLM?

Gateway LLM adalah reverse proxy untuk panggilan model. Aplikasi Anda mengirim permintaan ke gateway, bukan langsung ke OpenAI, Anthropic, Google, atau penyedia LLM mana pun yang Anda gunakan. Gateway meneruskan permintaan tersebut sambil menerapkan aturan Anda di sepanjang jalurnya.

Setiap penyedia LLM memiliki API sendiri, lengkap dengan format permintaan, autentikasi, dan cara mengembalikan error masing-masing. Masing-masing juga memiliki batas laju dan mode kegagalan yang berbeda. Jika tidak ada lapisan bersama di depannya, setiap aplikasi yang memanggil penyedia harus menangani semuanya sendiri, dan masing-masing melakukannya dengan cara yang sedikit berbeda.

Analogi air keran memang ada batasnya, tetapi cukup untuk menjelaskan hal ini—penyedia cukup disambungkan sekali, di gateway. Setelah itu, setiap aplikasi mendapatkan sambungan bermeteran sendiri, sehingga Anda dapat melihat siapa menggunakan apa dan mematikan satu jalur mana pun tanpa mengganggu jalur lainnya.

Gateway LLM, AI, MCP, dan API: Apa bedanya?

Bagaimana cara kerja gateway LLM?

Ikuti perjalanan satu permintaan dari aplikasi Anda ke model dan kembali lagi.

1. Permintaan tiba di gateway: Aplikasi Anda mengirim permintaan chat yang tampak biasa, sering kali dalam format yang kompatibel dengan OpenAI, ke endpoint gateway. Dari sudut pandang aplikasi, inilah alamat yang dipanggilnya untuk menjangkau model.
2. Gateway memeriksa siapa yang meminta dan apa yang boleh mereka lakukan: Sebelum meneruskan permintaan, gateway memvalidasi kredensial. Sering kali, kredensial itu berupa kunci virtual yang diterbitkan untuk sebuah tim atau produk. Jika Anda memasang guardrail input, prompt juga dapat dipindai untuk mendeteksi data sensitif atau upaya mengesampingkan instruksi model.
3. Gateway memeriksa apakah jawabannya sudah tersedia: Jika caching diaktifkan, permintaan yang cocok dan memenuhi syarat dapat dijawab dari respons yang tersimpan tanpa perlu memanggil penyedia lagi. Beberapa gateway juga menawarkan semantic caching, yang mencari permintaan yang dinilai cukup mirip, bukan yang identik. Cara ini bisa cocok untuk lalu lintas bergaya FAQ.
4. Gateway memilih tujuan permintaan: Permintaan bisa menyebutkan model tertentu atau sebuah alias. Gateway mencari rute yang cocok dalam konfigurasi Anda. Anda juga dapat mengonfigurasi rute cadangan. Jika penyedia A mengalami timeout, gateway dapat mencoba penyedia B.
5. Gateway menyiapkan panggilan dan mengembalikan respons: Gateway mengonversi permintaan Anda ke format penyedia yang dipilih dan mengautentikasi panggilan keluar. Begitu respons diterima, respons tersebut dikonversi ke format yang dibutuhkan aplikasi Anda.
6. Gateway mencatat apa yang terjadi: Saat logging diaktifkan, gateway mencatat detail seperti siapa yang melakukan panggilan, model mana yang melayaninya, jumlah token, latensi, dan biaya. Inilah log yang tidak dimiliki engineer Reddit di bagian pengantar tadi.

4 hal yang perlu Anda ketahui sebelum menerapkan gateway di lingkungan produksi

Semua yang dijelaskan di bagian sebelumnya dimungkinkan karena gateway melihat setiap permintaan yang dirutekan melaluinya. Itulah nilai jualnya. Namun, hal itu juga menggambarkan permukaan serangan dan ketergantungan pada vendor yang harus Anda antisipasi.

Gateway kini menjadi komponen paling berharga dalam stack AI Anda

Gateway memusatkan akses. Karena itu, gateway juga menempatkan banyak kredensial dalam jangkauan satu layanan. Tim keamanan Microsoft mencantumkan apa saja yang mungkin disimpan atau diambil oleh deployment LiteLLM: kunci API penyedia, kunci master miliknya sendiri, catatan kunci virtual, string koneksi database, pengaturan perutean, dan kebijakan tenant.

Pada Oktober 2026, Check Point Research mengungkap dua kerentanan berisiko tinggi di LiteLLM:

• CVE-2026-35029 memungkinkan pengguna terautentikasi, termasuk pengguna dengan akses baca saja, menjangkau fungsi administratif dan mengambil alih instans.
• CVE-2026-59823 memungkinkan pengguna mengalihkan permintaan ke server yang mereka kendalikan dan menangkap kunci penyedia.

Keduanya telah diperbaiki di versi 1.83.9. Aplikasi yang menggunakan gateway seharusnya tidak dapat mengubah pengaturannya.

Guardrail Anda memerlukan kebijakan kegagalan

Tinjauan Pillar Security pada 4 Oktober 2026 mendokumentasikan integrasi guardrail pihak ketiga di berbagai gateway utama, termasuk LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management, dan Apigee. (Pillar menjual guardrail, jadi ingatlah hal itu saat membaca rekomendasinya.)

Hook adalah titik dalam jalur permintaan, biasanya sebelum prompt dikirim ke model atau setelah respons kembali, tempat gateway dapat menyerahkan konten ke pemindai eksternal untuk mendapatkan putusan. Pemeriksaan yang memblokir akan menunggu putusan tersebut sebelum membiarkan lalu lintas berlanjut. Dokumentasi Portkey menyebutnya before_request_hooks dan after_request_hooks; TrueFoundry menjalankan empat hook, dengan menambahkan pemeriksaan sebelum dan sesudah panggilan alat MCP.

Nah, ada dua hal yang perlu diperiksa:

• Apa yang terjadi jika pemindainya sendiri gagal? Jika Anda memblokir permintaan, Anda menghentikan lalu lintas yang belum diperiksa, tetapi mungkin mengganggu aplikasi Anda. Jika Anda membiarkannya lewat, aplikasi Anda dapat terus berjalan tanpa pemeriksaan tersebut. Log kegagalan akan menunjukkan setelahnya bahwa pemeriksaan itu terlewat, yang memang berguna, tetapi tidak sama dengan benar-benar menjalankannya.
• Bisakah Anda mengganti pemindainya? Jika penyedia lain tidak didukung, Anda mungkin harus memperbarui aplikasi atau menggunakan proxy lain untuk terhubung.

Hook MCP TrueFoundry memperluas jangkauan gateway dari permintaan model ke panggilan alat. Namun, gateway hanya dapat memeriksa lalu lintas yang melewatinya. Agen coding yang menjalankan perintah di mesin developer mungkin berada di luar jangkauan pandangan tersebut.

Numbat, alat open-source dari Perplexity, bekerja di sisi tersebut. Numbat terhubung ke agen yang didukung melalui hook lokal dan dapat memeriksa tindakan yang direncanakan, seperti perintah shell atau penulisan file, sebelum dijalankan. Fitur pemblokiran bersifat opsional dan dinonaktifkan secara default. Gateway melihat lalu lintas model yang dirutekan melaluinya. Numbat menambahkan visibilitas atas apa yang dilakukan agen dengan jawaban tersebut.

Anda perlu mengetahui di mana kendali gateway berakhir

Forkast News mengidentifikasi tiga garis evolusi yang mendekati gateway dari arah berbeda:

• Gateway yang berfokus pada LLM: LiteLLM dan Portkey berawal dari panggilan model: menerjemahkan antarpenyedia, merutekan permintaan, dan melacak token. Kini keduanya menambahkan kontrol untuk panggilan alat.
• Platform manajemen API: Kong, Apigee milik Google, dan Azure API Management berawal dari autentikasi, izin, dan manajemen lalu lintas, lalu menambahkan dukungan untuk model dan aturan khusus AI.
• Infrastruktur native agen: agentgateway, misalnya, dibangun dengan fokus pada agen yang berkomunikasi dengan model, alat, dan agen lain, termasuk melalui MCP dan A2A.

Pertanyaan penentunya adalah apa yang Anda rutekan:

• Hanya panggilan model? Gateway yang mengutamakan LLM adalah titik awal yang baik.
• Panggilan model di dalam perusahaan yang sudah penuh dengan aturan API? Mulailah dengan platform yang sudah Anda miliki.
• Agen memanggil alat yang memanggil model? Pastikan koneksi tersebut juga tercakup.

Anda menciptakan titik kegagalan bersama

Misalnya, chatbot dukungan Anda menggunakan OpenAI dan alat riset Anda menggunakan Anthropic—keduanya terhubung melalui gateway yang sama. Namun, jika gateway itu berhenti berfungsi, kedua alat tersebut kehilangan akses ke modelnya, meskipun OpenAI dan Anthropic berjalan normal.

Ini benar-benar pernah terjadi. Tingkat error AI Gateway milik Cloudflare memuncak di angka 97% selama gangguan pada 12 Juni 2025. Gateway tersebut mengandalkan layanan penyimpanan Workers KV milik Cloudflare untuk pengaturannya, dan layanan itu sedang mengalami kegagalan.

Jika Anda menjalankan gateway sendiri, siapkan salinan lain yang tetap berjalan dan dapat mengambil alih jika salah satunya gagal. Jika gateway Anda di-host oleh pihak lain, tanyakan bagaimana mereka menjaganya tetap berjalan saat terjadi kegagalan dan apa yang terjadi pada permintaan Anda selama pemulihan.

Fitur utama yang perlu dicari pada gateway LLM

Anda akan memberi gateway akses ke kredensial semua orang, jadi wajar jika Anda menuntut banyak darinya sebagai imbalan.

• Satu API di depan banyak penyedia: Kode Anda menggunakan satu format, sering kali format yang kompatibel dengan OpenAI, dan gateway yang menerjemahkannya. Penyedia LLM pun ikut menyesuaikan diri. Misalnya, Agent API Perplexity mendukung antarmuka Responses API OpenAI, sehingga tim dapat menggunakan kembali library klien OpenAI yang sudah ada.
• Kunci virtual dengan aturan terlampir: Setiap tim atau produk mendapatkan kuncinya sendiri, dengan aturan yang mengatur model yang diizinkan, batas permintaan, dan pengeluaran.
• Perutean dan fallback: Gateway mengirim permintaan ke model berdasarkan pengaturan Anda, yang mungkin mengutamakan biaya, kecepatan, atau penyedia tertentu. Jika sebuah panggilan gagal, gateway dapat mencoba model lain. Agent API Perplexity memungkinkan Anda mencantumkan hingga lima model, termasuk model dari penyedia berbeda, sesuai urutan pilihan Anda.
• Caching: Respons yang tersimpan dapat menghemat satu panggilan ke penyedia. Beberapa gateway mencocokkan permintaan yang identik; yang lain juga dapat mencocokkan permintaan dengan makna serupa. Periksa apakah respons dalam cache dapat dipisahkan per pengguna atau tim, dan apakah Anda dapat menonaktifkan caching untuk jawaban yang dipersonalisasi atau sensitif terhadap waktu.
• Streaming dan error yang konsisten: Respons tiba secara bertahap saat dihasilkan, dan error dari penyedia diterjemahkan ke dalam format yang dapat ditangani aplikasi Anda. Periksa apa yang terjadi saat Anda menambahkan guardrail AI.
• Logging dan atribusi biaya: Gateway mencatat siapa yang melakukan panggilan, model mana yang melayaninya, berapa banyak token yang digunakan, berapa lama waktunya, dan perkiraan biayanya. Periksa apakah log mencakup prompt dan respons, serta berapa lama log tersebut disimpan.
• Hook guardrail: Ini adalah titik dalam jalur permintaan tempat gateway dapat mengirim konten ke pemindai eksternal untuk mendapatkan putusan. Biasanya, hook ini berada sebelum permintaan model atau setelah responsnya. Periksa apakah permintaan berhenti atau berlanjut saat pemindai gagal, dan apakah Anda dapat menghubungkan pemindai lain.
• Antarmuka admin yang dapat Anda kunci: Gateway mengelola akses ke kredensial penyedia dan aturan yang digunakan semua orang. Pastikan Anda dapat membatasi akses admin secara terpisah dari lalu lintas aplikasi, serta pengguna dengan akses baca saja tidak dapat mengubah pengaturan. Katup utama perlu dikunci.

Alat apa yang dapat Anda gunakan untuk membangun gateway LLM?

Daftar fitur di pasar saling tumpang tindih. Dalam satu utas Reddit tentang akses model internal, pembuat utasnya bertanya: gateway mana yang tidak memerlukan engineer khusus?

Menurut kami, itulah pertanyaan yang tepat, dan ada empat jawabannya, tergantung seberapa banyak pekerjaan yang bersedia Anda tangani sendiri.

Buat sendiri

Gateway minimal menangani daftar tugas yang singkat—menerima permintaan, memeriksa kunci pemanggil, menambahkan kredensial penyedia, meneruskan panggilan, dan mencatat hasilnya. Namun, mendukung berbagai format penyedia menambah pekerjaan. Begitu pula menjaga seluruh sistem tetap berjalan.

Jika Anda sudah menjalankan Envoy, filter external-processing-nya memungkinkan Anda menghubungkan layanan yang memeriksa dan mengubah permintaan serta respons. Anda tetap harus membangun dan menjalankan layanan tersebut.

Dalam utas r/LLMDevs tentang apakah gateway dapat memangkas biaya, u/QuanTradin mengatakan bahwa mencatat token dan penanda cache-hit pada setiap panggilan membantu mereka menemukan dua job yang membayar harga penuh untuk prompt yang identik.

“...memperbaiki hal itu lebih berharga daripada lapisan perutean mana pun.”

Itu adalah pengalaman yang dilaporkan pengguna, dan bisa menjadi titik awal yang baik. Cari tahu apa yang Anda bayar sebelum membangun cara-cara rumit untuk merutekannya.

Host sendiri gateway open-source

LiteLLM adalah pilihan umum di sini: kompatibel dengan OpenAI, mendukung beragam penyedia, dan memiliki komunitas yang besar. Bifrost adalah alternatif yang dibuat untuk overhead per permintaan yang rendah. Helicone layak dilirik jika observabilitas berada di urutan teratas daftar fitur Anda.

Seperti produk apa pun, LiteLLM memiliki keterbatasan bagi sebagian tim. Dalam utas r/aiagents tentang alternatif selain membangun sendiri, u/Own_Bar_920 mengatakan bahwa LiteLLM menangani perutean dengan baik, tetapi kurang memadai bagi mereka dalam hal pembuatan versi prompt lintas tim dan evaluasi berkelanjutan saat mengganti model, sehingga mereka beralih ke alat terpisah.

Kebutuhan tersebut melampaui perutean gateway dasar, dan justru itulah intinya—jika perutean adalah kebutuhan utama, LiteLLM terbukti andal bagi mereka.

Anda mendapatkan daftar fitur siap pakai, dengan sebagian fitur bergantung pada edisinya, dan gateway tetap berada di dalam jaringan Anda. Anda juga bertanggung jawab atas patching, seperti yang diperjelas oleh pengungkapan Check Point sebelumnya, serta ketersediaan gateway, seperti yang diperjelas oleh bagian tentang titik kegagalan tunggal.

Namun, siapkan anggaran untuk orang yang bertanggung jawab atasnya. Salah satu kekhawatiran dalam utas r/LLMDevs tentang gateway untuk akses internal adalah pemeliharaan. u/Informal-Writer9685 menginginkan sesuatu yang “tidak memerlukan engineer khusus untuk memeliharanya” dan bertanya apakah ketidakstabilan upgrade LiteLLM yang dilaporkan merupakan masalah nyata pada skala mereka atau hanya menjadi kekhawatiran di lingkungan produksi.

Gunakan gateway terkelola

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter, dan gateway yang di-host Portkey menjalankan layanan ini untuk Anda. Untuk aplikasi yang kompatibel, meloloskan permintaan pertama mungkin hanya memerlukan perubahan URL dan sebuah kunci API.

Konsekuensinya, setiap prompt kini melewati pihak ketiga sebelum mencapai penyedia. Artinya, ada satu pemroses data lagi dalam dokumen kepatuhan Anda, dan gangguan pada gateway itu sendiri merupakan insiden milik vendor—bukan tugas Anda untuk memperbaikinya.

Misalnya, pada 17 dan 19 Februari 2026, OpenRouter mengalami gangguan yang masing-masing berlangsung 38 dan 35 menit setelah sebuah dependensi caching gagal. Beberapa pelanggan menerima error “User not found” dan menghabiskan waktu men-debug kunci API yang sebenarnya valid. Kesalahannya ada pada infrastruktur gateway.

Namun, patut diapresiasi, OpenRouter menerbitkan postmortem yang mendetail dan menambahkan perlindungan agar kegagalan cache tidak membebani database-nya. Gateway terkelola seperti OpenRouter dapat menyederhanakan akses, tetapi seperti yang ditunjukkan u/QuanTradin di r/LLMDevs, menggabungkan tagihan tidak otomatis mengurangi pengeluaran.

Perluas gateway API yang sudah Anda miliki

Jika Kong, Apigee, atau Azure API Management sudah berada di depan layanan Anda, masing-masing memiliki kemampuan khusus AI: Kong AI Gateway, kebijakan gateway AI Apigee, dan gateway AI Azure API Management. Anda dapat memanfaatkan autentikasi, aturan jaringan, dan prosedur operasional yang sudah ada, lalu menambahkan kontrol model melalui plugin atau kebijakan.

Di perusahaan besar, ini bisa menjadi jalur dengan resistensi organisasi paling rendah. Fitur AI-nya lebih baru dibandingkan gateway mandiri. Pastikan untuk menguji rate limiting berbasis token dan streaming melalui seluruh rangkaian plugin atau kebijakan yang akan Anda gunakan.

Jadi, silakan saja pasang katup utamanya—gateway yang mahakuasa itu. Meski begitu, insinyur di bagian pendahuluan tadi ada benarnya. Akses model sebuah perusahaan seharusnya tidak bergantung pada siapa pun yang kebetulan menyimpan kunci yang tepat di lacinya.

Gateway mengatasi hal itu dengan menempatkan kunci-kunci tersebut di bawah kendali terpusat, yang justru memperbesar risiko jika laci itu dibiarkan terbuka. Anda harus tahu laci siapa itu.

FAQ gateway LLM

Apakah gateway LLM gratis?

Jika yang Anda maksud adalah kategorinya, beberapa gateway LLM memiliki versi gratis.

Gateway LLM tersedia dalam berbagai pilihan, dari perangkat lunak sumber terbuka gratis hingga paket berbayar mulai sekitar $50 per bulan, dengan harga khusus untuk penerapan skala enterprise. Ada juga yang mengenakan biaya berupa persentase; misalnya, paket Standard OpenRouter menambahkan 5,5% pada pembelian kredit.

Gateway LLM mana yang terbaik?

Pekerjaan apa yang bersedia Anda tangani sendiri?

• Coba lihat Bifrost atau Helicone jika Anda ingin meng-host sendiri dan mengontrol konfigurasinya.
• Opsi terkelola seperti OpenRouter atau Vercel AI Gateway cocok untuk tim yang ingin layanannya dijalankan oleh pihak lain.
• Jika Anda sudah menggunakan Kong atau Azure API Management, periksa terlebih dahulu kemampuan AI yang ditawarkan keduanya.

Uji daftar pilihan Anda dengan permintaan Anda sendiri, termasuk apa yang terjadi saat salah satu penyedia gagal.

Apakah AWS memiliki gateway LLM?

Ya. Amazon Bedrock AgentCore Gateway mendukung panggilan model melalui apa yang disebut AWS sebagai “inference targets”. Fitur ini memungkinkan aplikasi menggunakan satu endpoint untuk menjangkau berbagai penyedia, termasuk Amazon Bedrock, OpenAI, dan Anthropic, sementara gateway menangani kredensial penyedia dan perutean.