any-llm - Antarmuka tunggal untuk berbagai penyedia LLM

 (github.com/mozilla-ai)
7 poin oleh xguru 2025-07-25 | 3 komentar | Bagikan ke WhatsApp
  • Library Python buatan tim Mozilla AI yang memungkinkan penggunaan lebih dari 20 penyedia LLM dengan satu fungsi
    • Saat mengganti model seperti OpenAI, Anthropic, Google, Mistral, atau AWS Bedrock, cukup ubah provider_id/model_id
  • Mengutamakan penggunaan SDK resmi dari penyedia untuk meminimalkan masalah kompatibilitas, dan tidak perlu memasang server proxy/gateway terpisah sehingga bisa langsung digunakan setelah instalasi via pip
  • Ramah pengembang dengan petunjuk tipe IDE yang lengkap, penanganan exception yang intuitif, exception kustom, serta dokumentasi dan panduan cepat
  • Dengan router ringan, bersifat independen dari framework, dan tidak memerlukan server proxy/gateway terpisah (bisa langsung digunakan hanya dengan API Key)
  • Mengatasi masalah pada solusi yang sudah ada, dengan pemeliharaan aktif yang sedang berjalan: sudah digunakan di produk nyata seperti any-agent milik Mozilla
    • LiteLLM: implementasi langsung alih-alih memakai SDK resmi → ada kekhawatiran kompatibilitas/bug
    • AISuite: struktur modular tetapi kurang dalam pengelolaan dan typing
    • Tergantung framework: terfragmentasi lagi untuk setiap proyek
    • Khusus proxy: memerlukan server terpisah, menambah kompleksitas

Dokumentasi terkait

Bacaan terkait

3 komentar

 
kaydash 2025-07-26

Sepertinya harus mengelola key untuk tiap provider LLM.
 
GN⁺ 2025-07-25
Komentar Hacker News
  • Saya tidak merasa itu pasti masalah hanya karena LiteLLM mengimplementasikan antarmuka penyedia secara langsung alih-alih memakai SDK resmi
    Untuk API teks, saya belum mengalami masalah kompatibilitas yang besar, dan saya paham bahwa untuk menstandarkan berbagai API, mereka memang harus mengimplementasikan antarmukanya sendiri
    Proses ini memang diperlukan jika ingin membuat router tertentu
    • Rasanya LiteLLM sebenarnya tidak punya bagian yang benar-benar lite
      Saya sempat mencobanya sebagai library, tetapi akhirnya pindah ke llm milik Simon. Terima kasih untuk Simon
    • Untuk penggunaan standar seperti text completion, kedua pendekatan sama-sama berjalan baik
      Perbedaan lebih terlihat pada kondisi tepi seperti perilaku streaming, penanganan timeout, atau adopsi fitur baru
      Kami juga membuat ulang antarmuka untuk normalisasi API, jadi apakah memakai SDK atau tidak hanyalah perbedaan soal di mana layer dipisahkan
      Mengadopsi SDK lebih merupakan preferensi pemeliharaan, bukan karena ada cacat mendasar pada pendekatan LiteLLM
    • SDK resmi juga kadang menimbulkan masalah dependensi
      SDK milik Together bahkan pernah menyertakan dependensi 60MB bernama Apache Arrow, dan saya harus mem-patch-nya sendiri agar menjadi opsi
      Jika versi dependensi dipatok secara paksa, itu bisa bentrok dengan proyek saya
      Saya rasa lebih baik hanya menggunakan OpenAPI/REST daripada library yang membawa banyak dependensi
    • LiteLLM juga secara keseluruhan punya cukup banyak pengalaman nyata di lapangan
      Hanya karena memakai SDK resmi bukan berarti semua masalah kompatibilitas otomatis selesai, dan any_llm pada akhirnya juga perlu menjaga kompatibilitas secara langsung dengan SDK resmi
      Sulit untuk mengatakan dengan jelas pendekatan mana yang lebih unggul
    • Secara pribadi saya memakai Litellm sebagai AI gateway
      Dari sudut pandang pengguna, apakah proxy memakai SDK resmi atau tidak tidak ada perbedaan nyata dalam penggunaan
      Mungkin ada keuntungan bagi pengembang proxy
      Misalnya, baru-baru ini Litellm sempat punya isu dalam penanganan Deepseek Reasoning, dan bagian reasoning pernah hilang baik pada respons sinkron maupun streaming
  • Dalam posting blog, disebutkan bahwa LiteLLM populer karena mendukung berbagai penyedia LLM, tetapi lalu dikritik karena “tidak memakai SDK resmi dan mengimplementasikan sendiri sehingga bisa menimbulkan masalah kompatibilitas”
    Menurut pengalaman saya, LiteLLM sebenarnya bekerja sangat kokoh
    Para penyedia biasanya memberi pemberitahuan lebih dulu saat ada perubahan API, dan LiteLLM tidak pernah menjadi masalah karena itu
    Kekurangan hipotetis bernada negatif terkait LLM ini hanya muncul di tulisan tersebut
    Tulisan itu juga menyebut OpenRouter dan Portkey sebagai solusi proxy/gateway, tetapi sebenarnya OpenRouter tidak mengharuskan pengguna menjalankan server sendiri, cukup langsung memanggil API ke endpoint-nya
    Tulisan itu salah menganggap OpenRouter sebagai proxy self-hosted
    Lalu AISuite adalah produk buatan Andrew NG, tetapi blog itu menulis bahwa proyek tersebut “tidak terawat sejak Desember 2024”, padahal kenyataannya hanya tidak punya release tag, dan proyek komunitas kecil sering kali memang tidak rajin memberi tag
    Saya merasa bermasalah jika hal-hal seperti ini dipublikasikan ke blog tanpa cek fakta
    Kalau bukan karena merek Mozilla, saya mungkin akan mengira ini penipuan atau malware
    Namanya juga terlalu mirip dengan Anything-LLM sehingga cukup membingungkan
  • Saya menaruh harapan pada proyek any-llm yang baru ini
    Selama ini saya memakai LiteLLM, tetapi kalau melihat implementasi internalnya, sangat kompleks dan penuh masalah
    Sebagai contoh, selama beberapa bulan terakhir Structured Output pada entri Ollama dibiarkan rusak total, dan dokumentasinya juga sama sekali tidak tertata
  • Proyek ini terlihat keren dan menarik
    Alasan memilih Python kemungkinan karena sebagian besar SDK berbasis Python
    Tapi menurut saya akan benar-benar revolusioner kalau bentuknya bisa dipindahkan ke berbagai bahasa tanpa interpreter
    • Ini pertanyaan intinya. Banyak alat mencoba menyelesaikan masalah level sistem (eksekusi model lintas bahasa) di layer aplikasi (library Python)
      Untuk membuat solusi yang benar-benar universal, runtime model dan bahasa harus dipisahkan sepenuhnya, dan itu masalah yang jauh lebih sulit tetapi juga langkah besar ke depan
    • Untuk JS/TS ada Vercel AISDK, untuk C++ ada ClickHouse ai-sdk-cpp, dan untuk Flutter/ReactNative/Kotlin ada Cactus; jadi sudah ada SDK yang bisa dipakai di berbagai bahasa. Tujuannya mirip dengan proyek ini
    • Kami tidak membuat SDK, tetapi langsung membuat gateway berbentuk layanan. Referensi: proyek Portkey-AI Gateway
  • Saya penasaran apa pembeda utamanya dibanding proyek llm milik SimonW
    • Proyek SimonW berfokus pada dukungan OpenAI dan model yang kompatibel, jadi misalnya kalau ingin memakai model seperti Amazon Bedrock, Anda harus men-deploy *gateway/proxy tambahan* sendiri
      Proyek dari Mozilla (termasuk LiteLLM) punya keunggulan karena sudah mendukung berbagai antarmuka, jadi bisa langsung memakai banyak model
      Bisa langsung terhubung ke berbagai LLM Provider tanpa server proxy/gateway terpisah. Untuk perbandingan dengan LiteLLM, saya belum cukup berpengalaman jadi kurang tahu
  • Saya juga sedang membuat proyek open source lapisan abstraksi LLM untuk Python
    Saya mulai mengembangkannya karena dibutuhkan dalam pekerjaan riset saya
    Saya mengambil ide dari proyek yang sudah ada lalu membuatnya untuk penggunaan yang lebih umum
    https://github.com/proxai/proxai
    https://proxai.co/
  • Rasanya timing-nya benar-benar menarik
    Saya juga baru saja merilis lapisan abstraksi LLM yang mirip
    Bisa dipakai dengan mudah lewat pip install, dan dibuat dengan fokus pada kompatibilitas Langchain sehingga mudah menggantikan sistem yang sudah ada
    Selain itu, saat Rate Limit terlampaui, sistem ini juga bisa melakukan failover otomatis lewat penyedia virtual
  • Belakangan ini mulai banyak pilihan untuk layer gateway/proxy LLM seperti LiteLLM, OpenRouter, Arch, any-llm. Sampai di titik ini, mungkin kita semua perlu mencari masalah baru untuk dipecahkan
    • Saya rasa LiteLLM agak rumit. Mungkin masih oke untuk proyek pribadi yang dijalankan sederhana lewat kontainer Docker, tetapi untuk penggunaan produksi nyata saya kurang puas
    • Meskipun 80% penyedia model mendukung endpoint yang kompatibel dengan OpenAI, tetap banyak solusi berbeda yang bermunculan
    • Saya juga ingin memperkenalkan Portkey. Bisa dimanfaatkan dengan JS dan open source
    • Kami menerapkan model routing pada riset akademik dan bidang chatbot PDF. Saya ingin mendengar pendapat orang lain
  • Saya rasa solusi seperti ini harus punya image Docker. Sepertinya Docker tidak disebut, dan saya ingin menghindari benturan versi pip atau Python
  • Saya juga terus memakai Litellm Proxy via Docker bahkan di lingkungan pengembangan
    Fitur Usage/Logs membantu memvisualisasikan penggunaan LLM yang sebenarnya, dan fitur Cache juga sangat membantu menghemat biaya saat pengujian berulang
 
egirlasm 2025-07-26

Terima kasih untuk tulisannya yang bagus. Kebetulan hari ini saya sedang melakukan refactor untuk yang ke-27 kalinya.
Sempat pakai C++, lalu javascript, dan sekarang lagi Rust...