Apa itu API Gateway: Prinsip Kerja, Risiko Umum, dan Checklist Pemilihan

Jalur yang dilalui satu permintaan melalui gateway

Mari kita perjelas istilahnya. "API Proxy" merujuk pada penambahan gerbang yang mengekspos antarmuka standar di antara aplikasi Anda dan backend model yang sebenarnya. Kode Anda tetap mengirim permintaan dalam format OpenAI, hanya saja base_url diarahkan ke alamat gerbang, dan kunci diganti dengan kunci yang diberikan oleh gerbang tersebut.

Gateway biasanya melakukan tiga hal dalam hop ini.

• Penerusan Permintaan: Memvalidasi format body permintaan, melengkapi parameter default jika diperlukan, lalu meneruskan permintaan ke backend; konten yang dikembalikan backend (termasuk potongan SSE streaming) diteruskan kembali kepada Anda apa adanya atau dengan sedikit pemrosesan.
• Pemetaan Kunci API: Anda memegang kunci yang diterbitkan oleh gerbang, yang hanya bermakna di dalam gerbang tersebut. Gerbang menggunakan ini untuk mengidentifikasi siapa Anda, berapa saldo Anda, dan model apa yang dapat Anda panggil; kredensial yang sebenarnya berinteraksi dengan backend tetap berada di dalam gerbang dan tidak muncul di kode Anda.
• Penagihan dan Batas Laju: Setelah setiap permintaan selesai, gerbang mengurangi saldo berdasarkan jumlah token input dan output dalam usage dikalikan harga satuan, serta menghitung jumlah permintaan per menit per kunci; jika melebihi batas, respons 429 akan dikembalikan.

Jika Anda menggabungkan ketiga hal ini, Anda akan memahami mengapa pengalaman gateway sangat bervariasi: implementasi lapisan forwarding menentukan fluktuasi latensi dan stabilitas stream, lapisan kunci menentukan jangkauan kerugian jika terjadi kebocoran, dan lapisan penagihan menentukan apakah tagihan transparan dan dapat diaudit.

Apa perbedaannya dengan layanan koneksi langsung satu model?

Layanan langsung berarti Anda mengirim permintaan langsung ke domain resmi penyedia model, biasanya dengan satu akun yang sesuai dengan satu set model, aturan penagihan, dan dokumentasi. Layanan gateway memiliki dua bentuk umum yang berbeda tergantung pada “berapa banyak yang terhubung di belakang”.

Dimensi	Layanan Koneksi Langsung Satu Model	Gateway Agregat	Proxy Satu Model
Jumlah Model	Beberapa milik penyedia	Puluhan hingga ratusan	Satu
Format Endpoint	Format unik masing-masing	Diseragamkan menjadi kompatibel OpenAI	Kompatibel OpenAI
Kesulitan Troubleshooting	Terendah, rantai terpendek	Tertinggi, banyak pemetaan nama model	Lebih rendah, hanya satu model
Skenario yang Cocok	Produksi stabil yang hanya menggunakan satu penyedia	Perlu sering mengganti model untuk perbandingan	Model tetap, mengutamakan prediktabilitas

Jika bisnis Anda hanya bergantung pada satu model, manfaat agregat tidak akan terpakai, dan Anda justru harus menanggung ketidakpastian “siapa yang sebenarnya dipetakan oleh nama model”. Sebaliknya, jika Anda mengganti model setiap minggu untuk pengujian perbandingan, gateway agregat akan menghemat banyak pekerjaan adaptasi. Tidak ada keunggulan mutlak; kuncinya adalah memahami kategori Anda sendiri.

Situs ini termasuk dalam kategori terakhir: hanya menyediakan satu model dengan id model uncensored, dan antarmukanya adalah komplitasi percakapan yang kompatibel dengan OpenAI. Diskusi mengenai pengorbanan dan biaya ini dapat Anda lanjutkan dengan membaca Biaya dan Pertimbangan API AI Tanpa Sensor.

Tiga risiko paling umum

Keamanan Kunci API

Kunci API gateway setara dengan kartu prabayar; siapa pun yang memilikinya dapat menghabiskan saldo Anda. Jalur kebocoran umum meliputi: menulis kunci API di kode frontend, mengunggahnya ke repositori publik, atau menempelkannya ke tiket dukungan atau tangkapan layar grup chat. Disarankan untuk menyimpannya hanya di variabel lingkungan server; frontend harus selalu meneruskannya melalui backend Anda sendiri. Jika curiga terjadi kebocoran, segera reset. Kunci lama harus langsung tidak berlaku. Perhatikan juga apakah layanan memungkinkan reset mandiri dan apakah kunci lama langsung tidak berlaku setelah reset, bukan “berlaku efektif beberapa jam kemudian”.

Penggantian Model

Ini adalah pertanyaan paling sering dibahas dalam layanan agregat: Anda meminta A, tetapi yang dikembalikan adalah B yang lebih murah. Hal ini sulit dinilai hanya dari dokumentasi, melainkan harus diverifikasi melalui perilaku. Anda dapat menetapkan serangkaian pertanyaan kecil dengan jawaban standar, menetapkan temperature, dan melakukan pengujian berulang untuk mengamati apakah gaya output stabil; atau meminta /v1/models untuk melihat apakah daftarnya konsisten dengan halaman penagihan. Nama model yang ambigu atau perbedaan performa yang signifikan untuk nama yang sama pada waktu berbeda patut diwaspadai.

Batas Laju Tidak Transparan

Beberapa layanan hanya menulis “penggunaan wajar” di dokumentasi, tetapi secara diam-diam menurunkan kecepatan atau membuang permintaan saat puncak, menyebabkan program Anda mengalami timeout acak. Praktik yang matang adalah menuliskan jumlah permintaan per menit per kunci API, mengembalikan 429 yang standar saat batas terlampaui, bukan membiarkan koneksi menggantung. Saat memilih, pastikan untuk menanyakan: apakah batas laju dihitung per kunci API atau per akun, apa yang dikembalikan saat batas terlampaui, dan apakah kode error terpisah dikembalikan saat saldo habis.

Daftar periksa untuk memilih layanan proxy

Daftar ini dapat langsung Anda salin ke dokumen evaluasi Anda dan dicentang satu per satu.

1. Apakah tersedia GET /v1/models publik yang mengembalikan daftar model dan harga yang konsisten dengan halaman harga?
2. Apakah respons error berupa JSON terstruktur yang berisi kode dan pesan, dengan pemisahan yang jelas untuk 401, 402, 429, dan 503?
3. Apakah batas permintaan per menit per kunci ditulis dalam dokumentasi, bukan hanya diucapkan oleh layanan pelanggan?
4. Apakah panjang jendela konteks, token output maksimum per permintaan, dan ukuran tubuh permintaan memiliki angka yang jelas?
5. Apakah penagihan dipotong secara presisi berdasarkan jumlah token di usage, dan apakah saldo dapat Anda periksa kapan saja?
6. Apakah saldo prabayar tidak pernah kedaluwarsa? Apakah masa berlaku kredit uji coba gratis dijelaskan dengan jelas?
7. Apakah kunci dapat direset secara mandiri, dan apakah kunci lama langsung tidak berlaku?
8. Apakah mendukung streaming, dan apakah statistik usage disertakan di akhir untuk memudahkan Anda melakukan rekonsiliasi?
9. Apakah ada penjelasan singkat yang jelas tentang apakah prompt digunakan untuk pelatihan?
10. Apakah kemampuan yang tidak didukung (misalnya vektor, gambar, suara) ditandai secara jujur, bukan dengan penjelasan yang ambigu?

Skor penuh tidak realistis, tetapi jika Anda tidak dapat menjawab dua dari lima pertanyaan pertama, disarankan untuk mencoba dengan saldo kecil terlebih dahulu, bukan langsung mengisi saldo besar.

Verifikasi sepuluh menit setelah mendapatkan kunci

Terlepas dari pilihan Anda, luangkan waktu sepuluh menit untuk verifikasi dasar sebelum peluncuran. Langkah pertama, buat daftar model dan pastikan id yang dikembalikan sesuai dengan harapan Anda:

复制curl -s https://api.llmzhongzhuan.com/v1/models \
  -H "Authorization: Bearer $API_KEY"

Langkah kedua, kirim permintaan kecil dan amati apakah bidang usage dalam respons ada dan apakah jumlahnya masuk akal. Contoh di bawah ini sengaja meminta model untuk mengulang tanggal untuk mengamati apakah ia akan membuat informasi yang tidak diketahuinya. Ini adalah pemeriksaan perilaku kasar, bukan evaluasi ketat:

复制curl -s https://api.llmzhongzhuan.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [{"role": "user", "content": "用一句话介绍你自己，然后复述今天的日期是几号。"}],
    "max_tokens": 200
  }' 

Tulis kedua langkah ini ke dalam skrip deployment Anda dan jalankan setiap kali Anda mengganti kunci atau layanan. Jika respons tidak memiliki usage, atau angka usage tidak sesuai dengan panjang input, itu menunjukkan masalah transparansi penagihan yang perlu Anda klarifikasi sebelum mengisi saldo besar. Untuk mengetahui cara mengintegrasikan di berbagai framework, lihat Panduan Konfigurasi Framework.

Parameter situs ini untuk memudahkan Anda mencocokkan dengan daftar

Di sini kami mencantumkan parameter aktual situs ini agar Anda dapat mencocokkannya dengan daftar di atas tanpa perlu bolak-balik membuka dokumentasi.

• Alamat endpoint: https://api.llmzhongzhuan.com/v1, mendukung POST /v1/chat/completions dan GET /v1/models, otentikasi menggunakan kunci Bearer.
• Hanya ada satu model dengan id uncensored; hanya teks, tanpa vektor, gambar, suara, video, atau fine-tuning.
• Jendela konteks mencakup 100,000 token (input dan output), max_tokens default adalah 2048 dengan batas maksimum per permintaan 32,000; body permintaan tidak boleh melebihi 8 MB.
• 300 permintaan per menit per kunci, melebihi batas mengembalikan 429; upstream_busy 503 berarti Anda dapat mencoba lagi nanti; saldo habis atau uji coba kedaluwarsa mengembalikan 402 no_credit.
• Harga adalah $0.25 per juta token input dan $1.00 per juta token output, dengan sistem saldo prabayar tanpa langganan, dan saldo tidak akan pernah kedaluwarsa.
• Prompt tidak akan digunakan untuk pelatihan.

Angka spesifik mengacu pada halaman harga dan dokumentasi. Akun baru mendapatkan kredit uji coba sebesar $0.50 yang berlaku selama 7 hari. Pendaftaran tidak memerlukan informasi pembayaran, sehingga Anda dapat menggunakannya untuk menyelesaikan proses verifikasi di atas terlebih dahulu.