Metrik API LLM yang Benar-Benar Penting

LLM API mudah diukur dengan buruk. Jumlah permintaan naik, penggunaan token naik, dasbor menjadi semakin berwarna, dan tim tetap tidak bisa menjawab pertanyaan yang penting: apakah pengguna mendapatkan jawaban yang bisa digunakan, apakah latensi tetap berada dalam janji produk, apakah retry menyembunyikan masalah pada penyedia, dan apakah hasil yang diterima biayanya sesuai dengan yang kami harapkan?

Metrik LLM API yang tepat menghubungkan panggilan model dengan hasil produk. Metrik ini membantu engineering, product, dan finance sepakat apakah fitur AI cukup andal untuk diskalakan, cukup murah untuk dipertahankan, dan cukup mudah diamati untuk di-debug.

Panduan ini memberi Anda scorecard praktis untuk pekerjaan produksi LLM API. Gunakan setelah Anda memahami apa itu LLM API, saat membandingkan akses langsung ke penyedia dengan gateway, atau ketika tim Anda sedang berpindah dari panggilan prototipe ke traffic nyata.

Jawaban singkat: ukur hasil yang diterima, bukan hanya aktivitas API

Kesalahan yang umum adalah mengukur wrapper alih-alih workflow. Respons 200, jumlah token, nama model, dan total pengeluaran memang berguna, tetapi itu tidak membuktikan bahwa produk mendapatkan nilai dari panggilan LLM API.

Metrik yang benar-benar penting adalah:

Kelompok metrik	Apa yang dijawab	Mengapa penting
Accepted response rate	Apakah aplikasi menerima jawaban yang bisa digunakan?	Keberhasilan HTTP mentah tidak menangkap kegagalan skema, panggilan tool yang buruk, penolakan, dan regenerasi oleh pengguna.
Latensi berdasarkan jalur pengguna	Apakah jawaban tiba cukup cepat untuk workflow ini?	Chat, coding agent, batch job, dan workflow tool membutuhkan target latensi yang berbeda.
Biaya per output yang diterima	Berapa sebenarnya biaya output yang berguna?	Harga token saja mengabaikan retry, fallback, jawaban yang ditolak, dan pemborosan konteks panjang.
Kesehatan retry dan rate-limit	Apakah sistem stabil di bawah permintaan nyata?	Retry tersembunyi dapat meningkatkan latensi, biaya, dan risiko insiden sebelum tingkat keberhasilan keseluruhan berubah.
Kualitas fallback	Apakah jalur cadangan memulihkan masalah tanpa melanggar kontrak?	Fallback hanya berguna jika jawaban akhir tetap sesuai dengan kebutuhan kualitas, skema, dan kebijakan workload.
Kelengkapan audit	Bisakah tim menjelaskan satu permintaan buruk dengan cepat?	Debugging memerlukan konteks request, key, workload, model, route, token, biaya, latensi, dan error.

Itulah lensa operasionalnya. Tujuannya bukan membuktikan bahwa LLM API menerima traffic. Tujuannya adalah membuktikan bahwa lapisan API membantu jalur produk menjadi lebih andal, lebih cepat, lebih murah, atau lebih mudah dioperasikan.

Metrik 1: tingkat respons yang diterima

Mulailah dengan accepted response rate karena metrik ini paling dekat dengan nilai bagi pengguna.

accepted_response_rate =
  accepted_outputs / user_or_job_requests

Tetapkan accepted_output di tingkat aplikasi. Untuk peringkas dukungan, ini bisa berarti ringkasan lolos pemeriksaan panjang, nada, dan sitasi. Untuk agen pemrograman, ini bisa berarti patch diterapkan dan tes lulus. Untuk alur ekstraksi, ini bisa berarti JSON cocok dengan skema dan aturan kepercayaan. Untuk fitur chat, ini bisa berarti pengguna tidak segera mencoba lagi, meningkatkannya ke dukungan, atau meninggalkannya.

Lacak setidaknya field berikut per permintaan LLM API:

Field	Mengapa penting
request_id	Memungkinkan dukungan, engineering, dan keuangan membahas kejadian yang sama.
workload	Membedakan jalur chat, agen, ekstraksi, enrichment, dan batch.
requested_model	Mencatat apa yang diminta aplikasi.
final_model	Mencatat apa yang benar-benar menghasilkan jawaban.
status	Membedakan sukses, timeout, rate limit, error provider, kegagalan validasi, dan blokir kebijakan.
accepted_output	Menunjukkan apakah hasil menghasilkan nilai produk yang dapat digunakan.
retry_count	Menunjukkan kerja tersembunyi di balik satu permintaan yang terlihat.
fallback_count	Menunjukkan apakah pemulihan mengubah model atau jalur provider.

Jangan perlakukan HTTP 200 / total requests sebagai metrik keandalan utama. Itu adalah sinyal infrastruktur. LLM API dapat mengembalikan respons yang secara teknis berhasil tetapi gagal untuk produk: JSON tidak valid, function call salah, sitasi hilang, penolakan yang tidak aman, field halusinasi, jawaban tidak lengkap, atau respons yang tiba terlalu terlambat.

Metrik 2: latensi per jalur, bukan latensi rata-rata

Latensi rata-rata biasanya adalah angka yang salah. Itu menyembunyikan latensi ekor yang dirasakan pengguna dan masalah routing yang perlu didiagnosis oleh operator.

Untuk jalur LLM API interaktif, lacak:

Metrik	Penggunaan terbaik
Waktu ke token pertama atau potongan pertama	Chat streaming, copilot, agen pemrograman, dan UI apa pun yang memerlukan progres terlihat.
Durasi end-to-end	Jawaban non-streaming, output terstruktur, rantai panggilan tool, dan job batch.
Latensi p90	Tinjauan pengalaman produk untuk sebagian besar pengguna.
Latensi p99	Tinjauan insiden, ketidakstabilan provider, dan deteksi regresi ekor panjang.

Untuk workload latar belakang, lacak throughput juga:

Metrik	Penggunaan terbaik
Token per detik	Generasi panjang, ringkasan, dan workload pemrograman.
Job selesai per menit	Penentuan ukuran antrean dan kesehatan worker.
Throughput yang disesuaikan dengan retry	Kapasitas nyata setelah kegagalan dan retry dihitung.

Konvensi semantik GenAI OpenTelemetry menamai primitif yang berguna seperti penggunaan token, durasi operasi, waktu hingga chunk pertama, waktu per chunk output, durasi permintaan server, waktu hingga token pertama, durasi alur kerja, durasi agen, panggilan inferensi, panggilan alat, dan durasi alat. Anda tidak perlu mengimplementasikan setiap metrik sekaligus, tetapi gunakan nama yang stabil sejak awal agar telemetri API LLM Anda tidak berubah menjadi spreadsheet sekali pakai nantinya.

Segmentasikan latensi berdasarkan:

• beban kerja;
• streaming versus non-streaming;
• model yang diminta;
• model akhir;
• provider atau rute;
• jumlah retry;
• jumlah fallback;
• ukuran prompt atau bucket jendela konteks.

Segmentasi itu memberi tahu Anda apakah latensi berubah karena model menjadi lebih lambat, prompt menjadi lebih besar, rute berubah, provider mencapai batas, atau kebijakan retry mulai melakukan terlalu banyak pekerjaan.

Metrik 3: biaya per output yang diterima

Harga token tidak sama dengan biaya produksi. Model berbiaya rendah bisa menjadi mahal jika membutuhkan retry berulang, menghasilkan jawaban yang ditolak, atau memaksa manusia memeriksa output dengan tingkat keyakinan rendah. Model premium bisa lebih murah untuk satu beban kerja jika menghasilkan jawaban yang diterima dengan lebih sedikit panggilan.

Gunakan metrik biaya API LLM ini:

cost_per_accepted_output =
  total_workload_cost / accepted_outputs

Lalu pisahkan biayanya:

Komponen biaya	Apa yang diungkapkannya
Biaya percobaan utama	Biaya dasar ketika panggilan pertama berhasil.
Biaya retry	Biaya yang tersembunyi di balik satu permintaan yang terlihat oleh pengguna.
Biaya fallback	Biaya jalur pemulihan.
Biaya output yang ditolak	Pengeluaran yang tidak menghasilkan nilai produk yang dapat digunakan.
Pemborosan konteks panjang	Biaya dari pengiriman konteks berulang atau yang tidak perlu.
Biaya alat atau media	Biaya alat berbayar, panggilan gambar, panggilan video, tindakan browser, atau langkah pengayaan yang terhubung ke alur kerja.

Untuk tinjauan keuangan, laporkan biaya berdasarkan beban kerja, kunci, lingkungan, kebijakan rute, dan model akhir. Untuk tinjauan teknik, tambahkan tingkat respons yang diterima di samping biaya. Grafik biaya tanpa kualitas dapat mendorong tim ke model yang terlihat murah dan menimbulkan lebih banyak kegagalan produk.

Di sinilah permukaan produk Flatkey relevan. Dokumen publik Flatkey menjelaskan REST API yang kompatibel dengan OpenAI di https://router.flatkey.ai/v1, dan quickstart-nya memberi tahu pengguna untuk memeriksa Usage Logs untuk model, jumlah token, latensi, dan biaya setelah permintaan. Itu memberi tim buku besar dasar yang berguna. Tim produksi tetap harus menambahkan label beban kerja, aturan output yang diterima, dan catatan kebijakan rute di sekitar buku besar itu.

Metrik 4: retry, 429, dan tekanan rate limit

Rate limit bukan sekadar administrasi provider. Itu mengubah latensi, biaya, dan pengalaman pengguna.

Dokumentasi REST API Flatkey menyatakan bahwa permintaan API menggunakan autentikasi Bearer, batas rate diterapkan per API key, dan jika melebihi batas akan mengembalikan 429 Too Many Requests. Itu berarti dasbor API LLM yang nyata harus membedakan kegagalan dari penyedia, tekanan di sisi klien, dan masalah kapasitas di tingkat key.

Lacak:

Metrik	Rumus atau definisi	Yang perlu diperhatikan
Tingkat 429	429 responses / total requests	Lonjakan berarti kapasitas di tingkat key, pola burst, atau desain antrean perlu ditinjau.
Tingkat retry	requests with retry_count > 0 / total requests	Tingkat retry yang tinggi dapat menyembunyikan ketidakstabilan di balik keberhasilan pada akhirnya.
Tingkat keberhasilan retry	accepted outputs after retry / retried requests	Menunjukkan apakah retry memulihkan nilai atau hanya menambah biaya.
Penalti latensi retry	latency after retry - primary-success latency	Menunjukkan biaya pengalaman pengguna dari pemulihan.
Penalti biaya retry	cost after retry - primary-success cost	Menunjukkan biaya penagihan dari pemulihan.

Retry harus memiliki anggaran. Jika satu permintaan dapat diam-diam retry tiga kali, produk mungkin terlihat andal sementara p99 latensi dan biaya melenceng di luar kendali. Untuk jalur interaktif, anggaran retry harus lebih ketat daripada untuk pekerjaan latar belakang. Untuk jalur batch, antrean mungkin lebih baik daripada retry segera.

Metrik 5: pemulihan fallback dan ketidaksesuaian fallback

Fallback berguna ketika menyelamatkan permintaan yang seharusnya gagal. Ini berbahaya ketika menyembunyikan masalah penyedia dengan mengembalikan jawaban yang melanggar kontrak aplikasi.

Dokumentasi fallback OpenRouter menjelaskan upaya mencoba model lain ketika provider model utama sedang down, terkena rate limit, atau menolak membalas karena moderasi; dokumentasi itu juga mencatat bahwa harga mengikuti model yang pada akhirnya digunakan. Dokumentasi routing provider OpenRouter menunjukkan kontrol routing seperti urutan provider, izin fallback, pengurutan berdasarkan harga, throughput, atau latensi, dan ambang kinerja yang dipilih. Implementasi yang tepat berbeda di tiap platform, tetapi pertanyaan operasionalnya secara luas berguna untuk setiap API LLM dengan beberapa rute yang mungkin.

Lacak:

Metrik	Rumus atau definisi	Menjawab apa
Tingkat pemicu fallback	requests with fallback_count > 0 / total requests	Seberapa sering routing utama gagal atau memilih cadangan.
Tingkat pemulihan fallback	accepted outputs after fallback / fallback-triggered requests	Apakah fallback benar-benar memulihkan output yang berguna.
Tingkat ketidaksesuaian fallback	fallback outputs rejected for schema, tool, context, modality, or policy mismatch / fallback-triggered requests	Apakah rute cadangan kompatibel.
Denda biaya fallback	fallback-success cost - primary-success cost	Apakah pemulihan dapat diterima secara finansial.
Denda latensi fallback	fallback-success latency - primary-success latency	Apakah pemulihan dapat diterima untuk jalur pengguna.
Visibilitas rute akhir	requests with logged final model and provider / total requests	Apakah tim dapat melakukan debugging dan audit terhadap rute.

Untuk LLM API, fallback harus diuji berdasarkan kontrak, bukan hanya ketersediaan. Jika jalur utama memerlukan pemanggilan tool, skema JSON, jendela konteks yang panjang, atau kebijakan data tertentu, jalur fallback harus memenuhi persyaratan yang sama atau dikecualikan dari beban kerja tersebut.

Metrik 6: efisiensi konteks

Biaya API LLM sering meningkat karena konteks bertambah. Tim merilis system prompt yang lebih panjang, menambahkan instruksi berulang, menambahkan hasil retrieval, menyertakan riwayat percakapan, dan menaikkan token output maksimum tanpa mengaitkan perubahan itu dengan output yang diterima.

Lacak:

Metrik	Mengapa penting
Token input per output yang diterima	Menunjukkan pembengkakan prompt dan retrieval.
Token output per output yang diterima	Menunjukkan apakah respons lebih panjang daripada yang dibutuhkan produk.
Pemanfaatan konteks	Menunjukkan apakah beban kerja mendekati batas konteks praktis model.
Porsi token yang dapat di-cache	Menunjukkan apakah bagian prompt yang berulang dapat digunakan kembali saat provider atau gateway mendukung caching.
Tingkat truncation atau error konteks	Menunjukkan apakah ukuran input menyebabkan kegagalan sebelum kualitas generasi dievaluasi.

Pertanyaan tinjauan yang berguna bukan "model mana yang punya jendela konteks terbesar?" Melainkan "seberapa banyak konteks yang dibutuhkan beban kerja ini untuk menghasilkan jawaban yang diterima?" Itu menjaga pemilihan model tetap terkait dengan hasil, bukan spesifikasi maksimum.

Metrik 7: kelengkapan audit

Insiden LLM API di produksi biasanya dimulai dengan keluhan spesifik: satu pengguna mendapat jawaban buruk, satu job menjadi mahal, satu provider melambat, satu key mencapai batas, atau satu model mengembalikan output yang tidak valid. Kelengkapan audit mengukur apakah tim dapat merekonstruksi kejadian itu dengan cepat.

Setidaknya, setiap request produksi harus terhubung ke:

Bidang audit	Jawaban yang diperlukan
request_id	Permintaan yang mana tepatnya yang sedang kita bahas?
timestamp	Kapan itu terjadi?
api_key_id atau environment	Aplikasi, tim, atau environment mana yang mengirimkannya?
workload	Jalur produk atau pekerjaan mana yang mengirimkannya?
route_policy	Aturan apa yang seharusnya diterapkan?
requested_model	Apa yang diminta oleh aplikasi?
final_model	Apa yang menjawab?
final_provider_or_route	Ke mana permintaan itu sebenarnya pergi?
status dan error_type	Apa yang terjadi?
input_tokens dan output_tokens	Seberapa banyak pekerjaan yang dilakukan?
latency_ms dan time_to_first_chunk_ms	Seberapa lambat itu?
cost	Berapa biayanya?
retry_count dan fallback_count	Seberapa banyak pemulihan yang terjadi?
accepted_output	Apakah aplikasi menerima hasilnya?

Jika bidang-bidang ini berada di alat yang terpisah, API LLM mungkin tetap berfungsi, tetapi operasional akan lebih lambat. Tim harus bisa menjawab "apa yang berubah?" tanpa harus menyatukan faktur penyedia, log aplikasi, log antrean, dan tangkapan layar dari lima dasbor.

Kartu skor API LLM

Gunakan kartu skor ini selama pemilihan penyedia, migrasi gateway, dan tinjauan operasional bulanan.

Pertanyaan	Metrik	Kondisi lolos
Apakah pengguna mendapatkan jawaban yang bisa digunakan?	Tingkat respons yang diterima	Stabil atau lebih tinggi berdasarkan workload setelah perubahan model atau route.
Apakah API cukup cepat?	Latensi p90/p99 dan waktu ke chunk pertama	Memenuhi target untuk setiap jalur pengguna.
Apakah sistem lebih murah dalam praktiknya?	Biaya per output yang diterima	Lebih rendah setelah retry, fallback, output yang ditolak, dan biaya alat disertakan.
Apakah batas-batas terkendali?	Tingkat 429, tingkat retry, tingkat keberhasilan retry	Tekanan limit terlihat dan tidak secara diam-diam menaikkan biaya atau latensi.
Apakah jalur cadangan berfungsi?	Pemulihan fallback dan tingkat ketidakcocokan	Fallback memulihkan kegagalan tanpa merusak skema, alat, kebijakan, atau kualitas.
Apakah konteks terkendali?	Token input per output yang diterima dan tingkat error konteks	Pertumbuhan prompt dan retrieval menghasilkan nilai yang terukur.
Apakah engineer bisa men-debug insiden?	Kelengkapan audit	Request, workload, route, final model, status, latensi, token, biaya, dan tipe error terlihat.
Apakah finance bisa mengatribusikan pengeluaran?	Biaya berdasarkan key, workload, environment, route, dan model	Pengeluaran dipetakan ke pemilik dan jalur produk.

Jika sebuah alat tidak dapat mengekspos field yang diperlukan untuk scorecard ini, gunakan dengan hati-hati. Anda mungkin tetap memilihnya untuk eksperimen, tetapi alat tersebut tidak boleh menjadi control plane operasional untuk traffic LLM API produksi tanpa instrumentation kompensasi.

Rencana pengukuran sederhana 30 hari

Anda tidak memerlukan stack observabilitas yang sempurna pada hari pertama. Mulailah dengan struktur yang cukup agar keputusan routing atau model berikutnya dapat diukur.

Minggu 1: definisikan workload dan request ID

Pilih tiga hingga lima workload yang representatif:

• satu jalur asisten interaktif atau chat;
• satu jalur coding agent atau tool-calling;
• satu jalur ekstraksi atau enrichment batch;
• satu jalur model berbiaya tinggi;
• satu jalur yang sensitif terhadap fallback.

Tambahkan request_id, workload, environment, requested_model, dan status. Tanpa field ini, analisis berikutnya berubah menjadi tebak-tebakan.

Minggu 2: tambahkan hasil dan error

Tentukan accepted_output untuk setiap workload. Lalu klasifikasikan error dengan daftar singkat: timeout, rate limit, provider error, validation failure, policy block, context error, dan unknown. Hindari label error yang terlalu detail karena membuat grafik sulit dibaca.

Minggu 3: tambahkan latency, token, dan biaya

Catat durasi operasi, time to first chunk untuk panggilan streaming, input token, output token, dan biaya. Buat satu tampilan berdasarkan workload dan satu tampilan berdasarkan model akhir. Biasanya ini sudah cukup untuk menemukan optimasi bermakna pertama.

Minggu 4: bandingkan rute dan kebijakan

Bandingkan:

• jalur provider langsung versus jalur gateway;
• model lama versus model baru;
• keberhasilan primary-only versus keberhasilan fallback;
• biaya per request versus biaya per accepted output;
• latency rata-rata versus latency p90 dan p99;
• jalur retry-disabled versus jalur retry-enabled untuk workload yang sama.

Tinjauan tersebut seharusnya menghasilkan keputusan rute atau model, bukan sekadar dashboard yang lebih cantik.

Di mana Flatkey cocok

Flatkey relevan ketika LLM API harus menjadi lapisan operasional bersama, bukan sekadar panggilan ke satu provider. Sumber Flatkey saat ini mendukung fakta produk berikut:

• Flatkey mengekspos REST API yang kompatibel dengan OpenAI di https://router.flatkey.ai/v1.
• Request API menggunakan autentikasi Bearer.
• Base URL yang sama bekerja lintas endpoint, provider, dan model.
• Dokumentasi API Flatkey mencantumkan endpoint untuk chat completions, responses, embeddings, image generation, video generation, dan model listing.
• Quickstart Flatkey menyatakan bahwa REST API, OpenAI SDK, Flatkey CLI, dan jalur coding-agent berbagi satu key, satu saldo akun, dan satu katalog model.
• Quickstart tersebut menyebut bahwa Usage Logs menampilkan model, jumlah token, latency, dan biaya setelah request.
• Situs publik Flatkey memposisikan produk di sekitar satu key, satu balance, model resmi, alat pay-per-call, dan satu invoice.

Itu adalah primitif yang berguna untuk mengukur operasi LLM API. Namun, itu bukan pengganti metrik spesifik beban kerja. Tim tetap perlu menentukan output yang diterima, target latensi, anggaran retry, kebijakan fallback, dan persyaratan audit.

Jika Anda sudah membandingkan lapisan API, pasangkan artikel ini dengan scorecard metrik API routing AI. Jika Anda masih berada di tahap awal, mulailah dengan cara menggunakan unified AI API lalu kembali ke scorecard ini sebelum memindahkan traffic produksi.

Kesalahan umum

Kesalahan 1: berhenti pada total token.
Total token memberi tahu Anda konsumsi. Itu tidak memberi tahu apakah output diterima, apakah retry menggelembungkan tagihan, atau apakah pengguna mendapatkan pengalaman yang lebih baik.

Kesalahan 2: mencampur semua workload menjadi satu.
Agen coding, asisten dukungan pelanggan, job enrichment malam hari, dan alur kerja gambar tidak boleh berbagi satu target keberhasilan.

Kesalahan 3: memperlakukan fallback sebagai keandalan otomatis.
Fallback hanya meningkatkan keandalan ketika jalur cadangan memenuhi kontrak output yang sama dan menghasilkan hasil yang diterima.

Kesalahan 4: membandingkan harga daftar tanpa output yang ditolak.
Model yang lebih murah tidak lebih murah jika menghasilkan lebih banyak respons yang dibuang, prompt yang lebih panjang, atau lebih banyak peninjauan manusia.

Kesalahan 5: membuat log hanya berguna bagi engineer.
Keuangan membutuhkan pengeluaran per pemilik dan workload. Produk membutuhkan hasil yang diterima. Dukungan membutuhkan pencarian tingkat permintaan. Buku besar LLM API harus mendukung ketiganya.

Pertanyaan yang sering diajukan

Apa metrik API LLM yang paling penting?

Metrik LLM API yang paling penting adalah tingkat respons yang diterima per workload. Metrik ini menghubungkan panggilan API dengan apakah produk benar-benar menerima jawaban yang bisa digunakan.

Apakah penggunaan token merupakan metrik kualitas API LLM?

Tidak. Penggunaan token adalah sinyal biaya dan kapasitas. Metrik ini menjadi berguna ketika dipasangkan dengan output yang diterima, latensi, dan konteks workload.

Haruskah dasbor API LLM berfokus pada latensi rata-rata?

Tidak. Latensi rata-rata saja tidak cukup untuk tinjauan produksi. Lacak latensi p90 dan p99, plus waktu ke token pertama atau potongan pertama untuk jalur streaming.

Bagaimana tim harus membandingkan biaya API LLM lintas penyedia?

Bandingkan biaya per output yang diterima, bukan hanya harga token. Sertakan retry, fallback, respons yang ditolak, pemborosan konteks panjang, dan setiap panggilan tool atau media yang terkait dengan alur kerja.

Kapan gateway API LLM membantu dengan metrik?

Gateway dapat membantu ketika tim membutuhkan satu base URL, akses model bersama, log penggunaan, visibilitas penagihan, kebijakan rute, perilaku fallback, dan konteks audit di berbagai penyedia. Gateway tetap membutuhkan label workload dan aturan output yang diterima dari aplikasi.

Kesimpulan akhir

LLM API harus diukur seperti infrastruktur produksi, bukan seperti endpoint demo. Jumlah permintaan, nama model, total token, dan keberhasilan HTTP hanyalah lapisan awal.

Metrik yang benar-benar penting adalah tingkat respons yang diterima, latensi per jalur, biaya per output yang diterima, kesehatan retry dan rate limit, pemulihan fallback, efisiensi konteks, dan kelengkapan audit. Lacak semuanya berdasarkan workload dan kebijakan rute, maka LLM API akan lebih mudah dioptimalkan, lebih mudah dipercaya, dan lebih mudah dipertahankan ketika engineering, produk, keuangan, dan dukungan bertanya apa yang berubah.

Mulailah dengan satu uji praktis: pilih beban kerja nyata, kirimkan melalui jalur penyedia Anda saat ini dan melalui base URL kompatibel OpenAI dari Flatkey, lalu bandingkan output yang diterima, model akhir, latensi, penggunaan token, biaya, percobaan ulang, dan perilaku fallback dengan scorecard yang sama.