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, prioritas, skala), selalu filter ke tingkat yang sedang Anda selidiki.
Alasannya:
Tingkat memiliki karakteristik kinerja yang berbeda
Tingkat prioritas dan skala memiliki SLA yang ditetapkan
Mencampur tingkat mengaburkan kinerja tingkat berbayar
Ini sangat penting untuk analisis latensi.
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.
Memecahkan Masalah Latensi
Analisis latensi paling bermakna pada tingkat prioritas dan skala, yang memiliki SLA yang ditetapkan. Tingkat standar dapat menunjukkan variasi latensi yang lebih luas, dan tidak memiliki latensi yang dijamin.
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. Yang Perlu Dibagikan dengan Dukungan (Jika Diperlukan)
Jika Anda menghubungi dukungan, sertakan:
ID Org yang terdampak (penting)
Endpoint yang terdampak, seperti Chat Completions atau Responses (penting)
Model yang terdampak (penting)
Apakah ini terjadi pada tingkat Skala atau Prioritas (penting)
Rentang waktu dengan zona waktu untuk latensi atau kesalahan (penting)
x-request-id atau X-Client-Request-Id yang relevan, jika tersedia
Timestamp dengan zona waktu, atau setidaknya tanggal, untuk permintaan yang Anda berikan
Jika tersedia, sertakan juga:
ID Proyek yang terkait dengan permintaan
Apakah permintaan residensi data terdampak, dan permintaan mana saja
Deskripsi tren yang Anda lihat
Untuk jenis masalah, sertakan:
Kesalahan: Perkiraan persentase permintaan yang gagal atau mengalami kesalahan, kode respons, pesan kesalahan, dan berapa lama waktu yang dibutuhkan untuk menerima respons kesalahan.
Latensi: Persentil mana yang terdampak (P50 / P90 / P95 / P99), seberapa tinggi nilainya dibandingkan baseline pelanggan, dan contoh permintaan lambat dengan timestamp kirim dan terima.
Keduanya: Screenshot atau tabel data kesalahan atau latensi, plus cara Anda menentukan bahwa tingkat kesalahan atau latensi lebih tinggi dari yang diharapkan.
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.
Tingkat Prioritas atau Tingkat Skala Terlihat Lambat
Kemungkinan penyebab: metrik tercampur di berbagai tingkat, sehingga lalu lintas tingkat standar menutupi kinerja tingkat berbayar.
Periksa:
Filter dibatasi pada 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.