Menjalankan Gateway AI Sendiri Daripada Membagikan Kunci Provider ke Semua Orang

Masalah dengan kunci provider per orang

Memberikan setiap developer, layanan, dan alat internal kunci provider secara langsung memang praktis pada awalnya. Namun, pola ini juga sulit dibongkar kemudian.

Setiap kunci menjadi kredensial yang harus kami terbitkan, simpan, rotasi, cabut, dan selidiki. Penggunaan tersebar di berbagai akun atau proyek, sehingga menjawab pertanyaan dasar seperti tim mana yang menimbulkan biaya ini? dapat mengharuskan kami mengekspor data dari beberapa dasbor provider. Kami juga kehilangan titik kendali yang praktis ketika sebuah eksperimen mulai mengirim trafik tak terduga.

Kami lebih memilih memberi aplikasi akses ke gateway AI internal daripada langsung ke provider model. Gateway menyimpan kredensial provider. Aplikasi menerima kredensial dengan cakupan terbatas yang dapat kami nonaktifkan atau ubah tanpa mengubah akun provider hulu kami.

Apa yang kami tempatkan di belakang gateway

Gateway kami berada di antara klien dan provider model. Klien mengirim permintaan ke satu endpoint internal, lalu gateway memutuskan cara mengautentikasi, mengotorisasi, merutekan, mencatat, dan menghitung biayanya.

Kami dapat menjalankan desain ini dengan LiteLLM karena LiteLLM menyediakan antarmuka yang kompatibel dengan OpenAI sekaligus mendukung beberapa provider model. Kompatibilitas ini penting dalam praktik: banyak SDK dan alat yang sudah ada dapat diarahkan ke gateway kami dengan mengubah base URL dan kunci API, bukan dengan memerlukan integrasi provider khusus di setiap aplikasi.

Gateway AI yang di-host sendiri tidak menghilangkan hubungan kami dengan provider. Kami tetap memerlukan akun provider, kunci hulu, kontrak bila diperlukan, serta pemahaman atas kebijakan retensi dan data masing-masing provider. Yang berubah adalah lokasi penyimpanan kunci tersebut dan tempat penerapan kontrol penggunaan.

Virtual key bukan kunci provider

Keputusan implementasi utama kami adalah menerbitkan virtual key untuk pengguna dan workload.

Virtual key adalah kredensial internal yang dibuat oleh gateway. Kunci ini dapat dikaitkan dengan seseorang, layanan, lingkungan, proyek, atau otomasi. Gateway memetakan kunci tersebut ke model yang diizinkan dan satu atau beberapa kredensial provider hulu.

Hal ini memberi kami kontrol yang sulit diterapkan ketika setiap orang memiliki kunci provider:

• Kami dapat mencabut akses satu aplikasi tanpa memengaruhi aplikasi lain.
• Kami dapat membatasi sebuah kunci pada model atau provider tertentu.
• Kami dapat menetapkan batas laju yang sesuai untuk pengguna interaktif, pekerjaan latar belakang, atau layanan bersama.
• Kami dapat melampirkan metadata seperti tim, proyek, lingkungan, dan pusat biaya.
• Kami dapat merotasi virtual key secara terpisah dari kunci provider hulu.

Kami tidak menganggap virtual key tidak berbahaya hanya karena sifatnya internal. Kunci ini tetap rahasia, dan kami menjaganya agar tidak masuk ke source control, kode browser, serta berkas konfigurasi yang tidak terlindungi. Gateway paling berguna ketika klien memanggilnya dari workload sisi server yang terkontrol. Untuk fitur berbasis browser, kami biasanya menjaga panggilan model tetap berada di belakang backend aplikasi kami, bukan mengekspos kredensial AI berumur panjang ke browser.

Kontrol anggaran memerlukan kebijakan yang jelas

Anggaran hanya berguna jika kami memutuskan apa yang harus terjadi ketika anggaran mendekati atau melampaui batas. Gateway dapat melacak pengeluaran berdasarkan virtual key, tim, proyek, atau model, tetapi gateway tidak dapat membuat keputusan kebijakan tersebut untuk kami.

Kami biasanya menetapkan beberapa tingkat kontrol anggaran:

• Batas per kunci melindungi kami dari satu kredensial yang bocor atau deployment yang bermasalah.
• Anggaran proyek membuat pekerjaan eksperimental terlihat sebelum menjadi pengeluaran infrastruktur bersama.
• Anggaran tim atau pusat biaya mendukung perencanaan dan peninjauan internal.
• Batas provider global menjadi perlindungan terakhir, walaupun seharusnya bukan satu-satunya perlindungan.

Ada trade-off antara pemblokiran keras dan peringatan. Batas keras langsung menahan biaya, tetapi dapat mengganggu alur kerja produksi. Peringatan menjaga ketersediaan, tetapi memerlukan seseorang untuk merespons. Untuk workload kritis, kami lebih memilih model fallback yang terdokumentasi atau jalur fitur yang terdegradasi daripada berasumsi penegakan anggaran tidak akan pernah aktif.

Kami juga membedakan perilaku input dan output saat meninjau biaya. Sistem dengan prompt besar, riwayat percakapan panjang, hasil tool, atau output yang panjang dapat menghabiskan anggaran dengan cepat meskipun jumlah permintaannya terlihat biasa saja. Jumlah permintaan saja bukan ukuran pengeluaran AI yang andal.

Atribusi biaya harus dimulai dari metadata permintaan

Atribusi biaya jauh lebih mudah ketika kami mewajibkan metadata pada batas gateway. Kami ingin setiap permintaan membawa konteks yang cukup untuk menjawab siapa yang memulainya, produk atau layanan mana yang menggunakannya, dan mengapa permintaan itu diizinkan memakai model tertentu.

Field yang sering berguna meliputi:

• team
• project
• environment
• service
• feature
• cost_center
• request_id

Penamaan yang tepat kurang penting dibandingkan konsistensinya. Kami menetapkan sejumlah kecil field wajib dan menolak atau menandai permintaan yang tidak menyertakannya. Jika setiap klien menciptakan label sendiri, pelaporan berubah menjadi pekerjaan pembersihan data.

Kami juga memisahkan atribusi dari data pribadi jika memungkinkan. Identifier proyek biasanya lebih berguna untuk analisis biaya rutin daripada alamat email pengguna. Jika kami perlu menyelidiki insiden, kami dapat mengorelasikan identifier permintaan dengan log aplikasi menggunakan kontrol akses yang sesuai.

Perutean adalah tempat fleksibilitas menjadi kompleksitas

Salah satu manfaat LiteLLM dan pola gateway serupa adalah perutean model. Kami dapat mengekspos nama model logis secara internal lalu memetakannya ke model provider. Ini memungkinkan kami mengubah model hulu, memindahkan workload ke provider lain, atau menetapkan fallback tanpa memperbarui setiap klien.

Fleksibilitas tersebut menimbulkan risiko. Provider yang berbeda dapat berbeda dalam pemanggilan tool, perilaku output terstruktur, batas konteks, pengaturan keamanan, latensi, dan harga. Kami tidak boleh menganggap dua model dengan nama serupa dapat saling menggantikan.

Kami membuat keputusan perutean secara eksplisit:

1. Kami menentukan workload mana yang boleh menggunakan model tertentu.
2. Kami menguji alur prompt dan tool yang penting terhadap model fallback yang diusulkan.
3. Kami mendokumentasikan perilaku yang diharapkan saat provider utama tidak tersedia.
4. Kami menjaga agar perubahan model dapat ditinjau, bukan diam-diam mengubah rute untuk setiap workload.

Untuk beberapa use case, merutekan ke model dengan biaya lebih rendah adalah masuk akal. Untuk kasus lain, kualitas atau kompatibilitas lebih penting daripada biaya per unit. Gateway memberi kami tempat untuk menerapkan keputusan itu, tetapi tidak menghilangkan kebutuhan akan evaluasi.

Mengoperasikan gateway AI yang di-host sendiri

Self-hosted AI berarti kami menerima tanggung jawab operasional. Kami perlu memasang patch pada gateway, melindungi antarmuka administratifnya, mengelola secret, mencadangkan konfigurasi bila diperlukan, memantau ketersediaan, dan memutuskan berapa lama log disimpan.

Kami juga memutuskan data permintaan apa yang harus dicatat. Prompt dan respons lengkap dapat bernilai untuk debugging, tetapi dapat berisi informasi sensitif. Kami lebih memilih mencatat metadata operasional secara default dan mengaktifkan pencatatan konten terperinci hanya ketika ada kebutuhan yang dapat dibenarkan, kontrol akses yang sesuai, dan kebijakan retensi.

Setidaknya, kami memantau:

• Kesalahan gateway dan kesalahan provider hulu.
• Volume permintaan, latensi, dan pola timeout.
• Pengeluaran serta penggunaan token per proyek, model, dan provider.
• Peristiwa rate limit dan penegakan anggaran.
• Kegagalan autentikasi dan aktivitas kunci yang tidak biasa.

Gateway itu sendiri dapat menjadi dependensi. Kami merencanakannya dengan menjalankannya menggunakan disiplin yang sama seperti layanan produksi internal lain: health check, perubahan konfigurasi terkontrol, prosedur rotasi secret, dan jalur penanganan insiden yang terdokumentasi.

Jalur migrasi yang praktis

Kami tidak perlu memindahkan setiap aplikasi sekaligus. Migrasi bertahap mengurangi risiko dan memberi kami waktu untuk memvalidasi pelaporan serta kebijakan.

1. Kami menerapkan gateway dengan kumpulan terbatas kredensial provider dan akses administratif.
2. Kami menentukan format virtual key dan field metadata wajib.
3. Kami memigrasikan satu workload internal yang tidak kritis terlebih dahulu.
4. Kami memverifikasi bahwa atribusi biaya, log, anggaran, dan perilaku modelnya dapat dipahami.
5. Kami memigrasikan layanan secara bertahap dan mencabut akses provider langsung setelah setiap migrasi selesai.
6. Kami meninjau virtual key dan kunci provider langsung yang tidak digunakan secara teratur.

Selama migrasi, kami menghindari bypass permanen. Kunci provider langsung sementara mungkin diperlukan untuk diagnosis, tetapi harus memiliki pemilik, tanggal kedaluwarsa, dan alasan yang terdokumentasi. Jika tidak, pola akses lama akan kembali secara diam-diam.

Keputusan yang kami ambil

Menjalankan gateway AI sendiri bukan tentang menyembunyikan provider di balik lapisan tambahan demi lapisan itu sendiri. Kami memilih control plane untuk akses AI.

Dengan LiteLLM, virtual key, aturan anggaran, atribusi biaya yang konsisten, dan operasi self-hosted yang cermat, kami dapat memberi tim akses model yang berguna tanpa menjadikan setiap orang bertanggung jawab atas akun dan kredensial provider. Trade-off-nya adalah kami harus mengoperasikan dan mengelola gateway dengan baik. Bagi kami, itu lebih baik daripada membagikan kunci hulu yang kuat dan mencoba membangun kembali kontrol setelah penggunaan sudah menyebar.