Tautan Penting
Dasbor Kondisi Layanan (saat ini hanya tersedia untuk pelanggan API Enterprise)
Mulai dengan Default yang Tepat
Saat Anda membuka dasbor Kondisi Layanan, default-nya adalah:
Semua proyek
30 hari terakhir
Resolusi per jam
Tampilan ini hanya berguna untuk orientasi. Pemecahan masalah yang bermakna selalu memerlukan pemfilteran.
Filter Sebelum Menyelidiki
Pemfilteran yang benar adalah langkah paling penting. Sebagian besar salah tafsir berasal dari pencampuran model, tingkat, atau proyek.
Filter berdasarkan Model (Satu per Satu)
Selalu filter ke satu model.
Alasannya:
Masalah pada model dengan lalu lintas rendah dapat tersembunyi oleh lalu lintas yang lebih besar
Model bervolume tinggi dapat membuat masalah lokal terlihat global
Model yang berbeda memiliki sasaran kinerja yang berbeda
Catatan: memilih beberapa model akan mengagregasikannya—bukan beralih di antara model tersebut.
Filter berdasarkan Tingkat Layanan
Jika Anda menggunakan lebih dari satu tingkat (standar, Mode Cepat (sebelumnya Pemrosesan Prioritas), Tingkat Skala), selalu pilih tingkat yang sedang Anda selidiki melalui filter.
Alasannya:
Setiap tingkat memiliki karakteristik performa yang berbeda
Mode Cepat dan Tingkat Skala memiliki SLA yang ditetapkan
Mencampur berbagai tingkat menyamarkan performa tingkat berbayar
Hal ini sangat penting untuk analisis latensi.
Untuk model yang sudah ada, traffic Mode Cepat masih ditampilkan sebagai priority di dasbor Penggunaan.
Filter berdasarkan Proyek
Secara default, Kondisi Layanan menampilkan semua proyek.
Untuk pemecahan masalah, filter ke proyek tempat masalah diamati.
Alasannya:
Satu proyek bervolume tinggi dapat mendominasi metrik.
Proyek terdampak yang lebih kecil dapat tertutupi oleh lalu lintas yang tidak terkait.
Biarkan hanya "Semua proyek" yang dipilih jika Anda yakin masalahnya benar-benar terjadi di seluruh organisasi.
Memecahkan Masalah Kesalahan
Gunakan Tampilan Permintaan HTTP
Untuk menyelidiki kesalahan:
Filter berdasarkan model dan tingkat layanan.
Buka tab Permintaan HTTP, bukan tab Waktu Aktif.
Tampilan ini menunjukkan total permintaan dan jumlah kesalahan berdasarkan kode status HTTP. Perbesar ke resolusi tingkat menit untuk mengidentifikasi lonjakan atau perubahan granular.
Tafsirkan Tingkat Kesalahan, Bukan Jumlah
Sebagian kesalahan memang diperkirakan terjadi di sistem produksi mana pun. Fokus pada persentase kesalahan, bukan total mentah.
Semakin besar volume total Anda, semakin besar potensi jumlah kesalahan meskipun tingkat kesalahannya sangat rendah.
Saat Kesalahan Tidak Muncul di Kondisi Layanan
Jika Anda melihat kesalahan sisi klien tetapi tidak ada data yang sesuai di Kondisi Layanan:
Permintaan kemungkinan tidak mencapai OpenAI.
Masalahnya biasanya berada di upstream (timeout, proxy, jaringan).
Ini umum terjadi dengan timeout sisi klien yang agresif.
Pemecahan Masalah Latensi
Analisis latensi paling bermakna untuk Mode Cepat dan Tingkat Skala, yang memiliki SLA yang ditetapkan. Tingkat standar dapat menunjukkan variasi latensi yang lebih besar dan tidak memiliki jaminan latensi.
Metrik Utama
Untuk melihat setiap metrik, klik tab yang relevan:
Kecepatan Token: Token yang dihasilkan per detik; tidak bergantung pada ukuran prompt.
Waktu Permintaan: Total durasi permintaan; sangat dipengaruhi oleh ukuran output dan penalaran.
Waktu hingga Token Pertama (TTFT): Waktu hingga token pertama dihasilkan; sangat dipengaruhi oleh ukuran prompt input yang tidak di-cache dan penalaran.
Selalu tinjau persentil P50 / P75 / P95. Rata-rata dapat menyembunyikan dampak pada pengguna nyata.
6. Mengorelasikan Latensi dengan Penggunaan Token
Kondisi Layanan menunjukkan kapan perilaku berubah. Data penggunaan membantu menjelaskan mengapa.
Di dasbor Penggunaan, lakukan hal berikut untuk memastikan Anda melihat data yang relevan dengan tampilan Anda di Dasbor Kondisi Layanan:
Filter ke proyek dan model yang sama.
Kelompokkan berdasarkan tingkat layanan, jika berlaku.
Fokus pada token output, yang paling kuat memengaruhi latensi.
Untuk analisis yang lebih mendalam, ekspor Data Aktivitas dan periksa token per permintaan dari waktu ke waktu.
7. Informasi yang Perlu Disampaikan kepada Dukungan (Jika Diperlukan)
Jika Anda menghubungi dukungan, sertakan:
ID organisasi yang terdampak (penting)
Endpoint yang terdampak, seperti Chat Completions atau Responses (penting)
Model yang terdampak (penting)
Apakah masalah terjadi pada Mode Cepat atau Tingkat Skala (penting)
Rentang waktu beserta zona waktunya untuk latensi atau error (penting)
x-request-id atau X-Client-Request-Id yang relevan, jika tersedia
Stempel waktu beserta zona waktunya, atau setidaknya tanggal, untuk permintaan yang Anda berikan
Jika tersedia, sertakan juga:
ID proyek yang terkait dengan permintaan
Apakah permintaan dengan residensi data terdampak, dan permintaan mana saja
Deskripsi tren yang Anda amati
Untuk jenis masalah, sertakan:
Error: Perkiraan persentase permintaan yang gagal atau mengalami error, kode respons, pesan error, dan waktu yang diperlukan untuk menerima respons error.
Latensi: Persentil yang terdampak (P50 / P90 / P95 / P99), seberapa tinggi nilainya dibandingkan tolok ukur pelanggan, serta contoh permintaan lambat beserta stempel waktu pengiriman dan penerimaannya.
Keduanya: Tangkapan layar atau tabel data error maupun latensi, serta cara Anda menentukan bahwa tingkat error atau latensi lebih tinggi daripada yang diperkirakan.
Skenario Pemecahan Masalah Umum
Timeout Terjadi tetapi Kondisi Layanan Terlihat Normal
Kemungkinan penyebab: permintaan mengalami timeout sebelum mencapai OpenAI.
Periksa:
Pengaturan timeout klien atau proxy
Perubahan jaringan lokal atau load balancer
Adanya kesalahan 499 di dasbor Kondisi Layanan (ini dapat muncul sebagai kesalahan 5xx di sistem Anda sendiri).
Latensi Meningkat Tanpa Deployment
Kemungkinan penyebab: ukuran token output atau penggunaan penalaran meningkat dan/atau lalu lintas berpindah antar tingkat layanan.
Periksa:
Rata-rata token output per permintaan di dasbor Penggunaan (memerlukan pengunduhan data dan pembagian token output dengan total permintaan).
Persentil Waktu Permintaan dan TTFT di dasbor Kondisi Layanan.
Mode Cepat atau Tingkat Skala Terasa Lambat
Kemungkinan penyebab: metrik dari berbagai tingkat tercampur, sehingga traffic tingkat standar menyamarkan performa tingkat berbayar.
Periksa:
Filter dibatasi hanya untuk satu tingkat dan model.
Perbandingan kecepatan token antar tingkat.
Lonjakan Kesalahan 5XX
Kemungkinan penyebab: kegagalan sementara yang memengaruhi sebagian kecil lalu lintas.
Periksa:
Persentase tingkat kesalahan
Apakah volume lalu lintas berubah pada saat yang sama
Masalah Hanya Memengaruhi Satu Proyek
Kemungkinan penyebab: konfigurasi atau pola penggunaan khusus proyek.
Periksa:
Pemfilteran tingkat proyek
Perbandingan dengan proyek yang tidak terdampak
Poin Akhir
Filter berdasarkan model, tingkat, dan proyek jika relevan sebelum menafsirkan metrik.
Gunakan persentil, bukan rata-rata, untuk analisis latensi.
Tingkat kesalahan kecil memang diperkirakan terjadi.
Data yang hilang biasanya menunjukkan masalah di sisi upstream.
Data penggunaan dapat membantu menjelaskan mengapa latensi berubah; Kondisi Layanan menunjukkan kapan perilaku berubah.