Alternatif LiteLLM (2026) — gateway ter-host, control plane dengan kunci sendiri, dan kapan tetap menggunakannya

LiteLLM adalah proxy sumber terbuka yang kompatibel dengan OpenAI dan Anda jalankan sendiri: proxy ini berada di depan akun penyedia Anda dan memberi kode Anda satu endpoint serta satu bentuk kunci di seluruh penyedia (dokumentasinya). Tim mencari alternatif karena dua alasan yang tidak berkaitan. Operasional: proxy yang di-host sendiri adalah satu layanan tambahan yang harus di-patch, diskalakan, dan dipantau. Rantai pasokan: pada 24 Maret 2026, seorang penyerang menerbitkan dua rilis LiteLLM yang disisipi backdoor ke PyPI, dan insiden tersebut memperlihatkan kepada banyak tim risiko dari «sebuah paket dalam build Anda» yang sebelumnya belum mereka perhitungkan. Rangkuman ini memetakan setiap motivasi ke alat yang benar-benar menjawabnya — termasuk alasan untuk tetap menggunakan LiteLLM, yang lebih kuat daripada yang disiratkan oleh tujuh daftar vendor pada pencarian ini.

Bias dinyatakan sejak awal: Kunavo adalah produk kami, dan tercantum pertama. Setiap alat lain di bawah ini mendapat rekomendasi yang sungguh-sungguh; detail yang telah kami verifikasi tersedia langsung di halaman perbandingan; dan dua alat yang belum kami evaluasi hanya dijelaskan sebatas pernyataan situs mereka sendiri.

Daftar singkat

Pembedaan yang paling menentukan

LiteLLM melakukan dua pekerjaan sekaligus, dan sebagian besar penggantinya hanya melakukan salah satunya. LiteLLM adalah proxy (satu endpoint untuk banyak penyedia) dan juga alat BYO-key (akun penyedia tetap milik Anda). Gateway inferensi terkelola — Kunavo, OpenRouter — menggantikan keduanya: tidak ada proxy yang perlu dijalankan dan tidak ada akun penyedia yang perlu dikelola, karena gateway menyimpan kredensial upstream dan menagih Anda berdasarkan penggunaan. Control plane terkelola — Portkey, TrueFoundry — hanya menggantikan yang pertama: Anda berhenti mengoperasikan proxy, tetapi tetap memiliki akun. Mengetahui bagian mana yang ingin Anda ganti menyelesaikan sebagian besar daftar ini. Polanya diuraikan dalam panduan gateway LLM.

Apa yang sebenarnya mendorong orang mencari

Hasil teratas dalam pencarian ini bukan artikel berbentuk daftar — melainkan utas Reddit tentang serangan rantai pasokan. Inilah yang terjadi, menurut pembaruan keamanan LiteLLM sendiri: pada 24 Maret 2026, seorang penyerang menerbitkan litellm==1.82.7 dan litellm==1.82.8 ke PyPI dengan kode berbahaya yang disisipkan ke dalam wheel yang didistribusikan. Keduanya aktif sejak 10:39 UTC selama sekitar 40 menit sebelum dikarantina oleh PyPI. Kompromi tersebut dilacak ke dependensi Trivy dalam alur kerja pemindaian keamanan CI/CD LiteLLM; penyerang melewati alur rilis resmi dan mengunggah langsung ke PyPI. Menurut SecurityWeek, lebih dari 2.500 organisasi terdampak.

Remediasi LiteLLM tercatat dan cukup besar: paket yang dikompromikan ditarik, kredensial pengelola dirotasi, Mandiant dilibatkan untuk forensik, dan v1.83.0 dirilis melalui pipeline CI/CD yang dibangun ulang dengan lingkungan build terisolasi, gerbang rilis yang lebih kuat, dan image Docker yang ditandatangani cosign. Jika Anda menggunakan 1.83.0 atau yang lebih baru dan tidak menjalankan versi berbahaya selama jendela 40 menit tersebut, insiden ini telah selesai bagi Anda.

Alasan insiden ini tetap mendorong orang mencari alternatif bersifat struktural, bukan khusus tentang LiteLLM. Proxy yang di-host sendiri adalah paket dalam build Anda, sehingga CI/CD dan cluster Anda menjadi bagian dari radius dampaknya. Itulah kalimat yang layak direnungkan — hal ini sama-sama berlaku untuk setiap alternatif yang di-host sendiri di halaman ini, termasuk MLflow AI Gateway, dan merupakan satu hal yang dihapus oleh endpoint terkelola: Anda memanggil URL HTTPS, sehingga tidak ada paket yang dapat diracuni dan tidak ada bagian gateway yang berjalan di dalam jaringan Anda.

Setengah lainnya yang jujur: gateway terkelola tidak lebih aman; paparannya berbeda. Kunci API dan teks prompt Anda melewati infrastruktur orang lain, dan Anda mewarisi risiko kebocoran mereka sebagai pengganti risiko patching Anda sendiri. Jika teks prompt tidak dapat keluar dari infrastruktur Anda, self-hosting adalah jawaban yang tepat dan bagian lain dari halaman ini membahas pertukaran yang sebaiknya tidak Anda lakukan.

1. Kunavo — tanpa proxy, tanpa akun penyedia

Kunavo adalah gateway inferensi terkelola: satu base URL yang kompatibel dengan OpenAI, satu kunci sk-kn-, satu saldo bayar sesuai penggunaan, dan kami menyimpan kredensial penyedia upstream, bukan Anda. Dibandingkan LiteLLM, ini merupakan pembagian tugas yang berbeda — Anda tidak menjalankan proxy dan tidak memelihara akun di Anthropic, Google, dan OpenAI secara terpisah.

Harga: sebagian besar katalog tercantum di bawah tarif resmi penyedia — Claude Sonnet 4.6 seharga $2,10 / $10,50 per 1 juta token dibandingkan dengan tarif Anthropic sebesar $3,00 / $15,00. LiteLLM tidak memiliki markup karena tidak menjual kembali apa pun; yang Anda bayar adalah harga sesuai kesepakatan Anda sendiri dengan penyedia, jadi perbandingannya adalah tarif kami dengan tarif langsung Anda, bukan dengan nol. Cakupan: model chat, gambar, video, dan musik dengan kunci serta saldo yang sama. Yang tidak dilakukan: merutekan kunci penyedia Anda sendiri — itulah bagian BYO-key yang dipertahankan LiteLLM dan tidak kami gantikan. Detail: Kunavo vs LiteLLM.

2. OpenRouter — cakupan model terpanjang

Gateway inferensi terkelola lainnya, dan pilihan ketika keluasan katalog lebih penting daripada harga satuan: ratusan model dari banyak penyedia dalam satu dompet, ditambah tingkat gratis dan routing dengan kunci Anda sendiri yang tidak ditawarkan Kunavo. Jika Anda meninggalkan LiteLLM karena ingin berhenti mengelola akun, OpenRouter dan Kunavo adalah dua bentuk yang realistis. Kunavo vs OpenRouter membandingkan keduanya berdampingan, dan rangkuman OpenRouter membahas bidang lainnya.

3. Portkey — pertahankan kunci, lepaskan operasional

Control plane terkelola di atas akun penyedia yang sudah Anda miliki: routing, fallback, guardrail, dan observabilitas, tanpa proxy sendiri yang perlu dijalankan. Ini adalah pengganti terdekat jika Anda memilih LiteLLM karena fitur routing dan anggarannya, dan satu-satunya hal yang ingin Anda lepaskan adalah pengoperasiannya. Detail: Kunavo vs Portkey.

4. Helicone — jika observabilitas adalah seluruh alasannya

Banyak penerapan LiteLLM ada karena seseorang membutuhkan log permintaan dan atribusi biaya per tim, dan proxy menjadi cara untuk mendapatkannya. Jika itu menggambarkan penggunaan Anda, lapisan observabilitas di atas panggilan penyedia yang sudah ada jauh lebih kecil untuk dioperasikan daripada gateway. Detail: Kunavo vs Helicone.

5. TrueFoundry — ketika pengadaan memerlukan vendor

Menempati posisi 2 dalam pencarian ini dengan perbandingan LiteLLM-nya sendiri. Produk ini merupakan gateway AI perusahaan yang dijual berdasarkan overhead latensi, fleksibilitas penerapan, SLA, tata kelola, dan kontrol yang siap diaudit (halaman produknya). Kami belum mengevaluasinya, jadi entri ini hanya merupakan rujukan, bukan rekomendasi: jika hambatan Anda adalah proxy sumber terbuka tidak memiliki kontrak dukungan, inilah kategori yang menyelesaikannya, dan perbandingan tersebut layak dibaca dengan menyadari bahwa merekalah yang menulisnya.

6. MLflow AI Gateway — pengganti sumber terbuka yang paling mirip

Posisi 3, dan yang paling mirip dengan LiteLLM di halaman ini: gateway sumber terbuka yang di-host sendiri dan berada di depan kunci penyedia Anda sendiri, dikelola sebagai bagian dari proyek MLflow. Perlu dinyatakan dengan jelas: menukar satu proxy yang di-host sendiri dengan proxy lain mempertahankan model penerapan dan karena itu juga mempertahankan permukaan serangan yang dijelaskan di atas. Itu pilihan yang sah — inilah yang Anda inginkan jika yang tidak Anda sukai adalah proyeknya, bukan modelnya.

7. Cloudflare AI Gateway — caching dan batas di edge

Proxy tipis di depan akun penyedia yang sudah Anda miliki: caching respons, pembatasan laju, percobaan ulang, dan analitik, tanpa menjual kembali inferensi. Proxy ini dapat dipadukan dengan sumber inferensi apa pun alih-alih menggantikannya, termasuk Kunavo atau OpenRouter. Detail: Kunavo vs Cloudflare AI Gateway.

Kapan LiteLLM masih menjadi pilihan yang tepat

• Teks prompt tidak boleh meninggalkan infrastruktur Anda. Data yang diatur regulasi, lingkungan air-gapped, atau kebijakan yang tidak dapat dipenuhi oleh gateway ter-host. Self-hosting adalah jawabannya, dan satu-satunya pertanyaan adalah proxy self-hosted mana yang dipilih.
• Anda telah menegosiasikan kontrak dengan penyedia. Komitmen pengeluaran atau tarif enterprise di Anthropic, OpenAI, atau Google lebih bernilai daripada apa pun yang dicantumkan reseller, dan alat BYO-key adalah cara Anda terus menggunakannya.
• Anda menggunakan anggaran per-key dan perutean timnya. Fitur-fitur tersebut adalah alasan banyak deployment LiteLLM dibuat; pastikan pengganti Anda mencakupnya sebelum menganggap penggantian base URL sebagai keseluruhan migrasi.
• Anda menginginkan source code yang dapat dibaca dan di-patch. Proxy open source yang Anda kendalikan adalah aset nyata, dan insiden Maret 2026 tidak menghilangkannya — itu adalah kompromi pada pipeline rilis, yang sejak itu telah ditangani, bukan cacat pada proxy itu sendiri.

Beralih hanya memerlukan dua baris

Setiap alternatif di sini yang menjual kembali inference berbicara dalam protokol wire OpenAI, jadi berpindah dari proxy LiteLLM adalah base_url dan penggantian key — bentuk request dan response tidak berubah:

# Before: your own LiteLLM proxy, your own provider keys,
# your own container to patch.
client = OpenAI(
    api_key=os.environ["LITELLM_MASTER_KEY"],
    base_url="http://litellm.internal:4000",
)

# After: a hosted endpoint. No package in your build, no proxy to run.
client = OpenAI(
    api_key=os.environ["KUNAVO_API_KEY"],
    base_url="https://api.kunavo.com/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

Bagian yang tidak cukup diselesaikan dalam dua baris adalah apa pun yang dilakukan LiteLLM di luar routing: anggaran per-key, fan-out tim, callback kustom. Inventarisasikan semuanya terlebih dahulu. Detail tingkat wire ada di panduan API yang kompatibel dengan OpenAI, dan hal-hal yang seharusnya ditangani gateway untuk Anda mencakup set fitur yang perlu diperiksa pada pengganti.

Pertanyaan umum