Ringkasan
- Respons streaming memerlukan parsing SSE yang robust untuk menangani bagian yang tidak lengkap dan data penggunaan token terakhir.
- Kesalahan mode JSON biasanya berasal dari model menghasilkan teks tambahan di luar skema JSON yang ketat.
- Jendela konteks 100k dibagi antara prompt dan completion, sehingga output panjang mengurangi ruang input yang tersedia.
- Estimasi biaya harus memperhitungkan harga token output yang lebih tinggi dibandingkan token input.
Mengapa Respons Streaming Anda Menggantung
Responsi streaming macet ketika klien gagal membaca bagian Server-Sent Event (SSE) terakhir yang berisi data penggunaan token. API kami mengalirkan token saat token tersebut dihasilkan, tetapi koneksi hanya ditutup sepenuhnya setelah bagian terakhir tiba. Jika kode klien Anda memutuskan koneksi lebih awal atau mengabaikan bagian terakhir, Anda kehilangan jumlah token tepat yang diperlukan untuk verifikasi penagihan.
Baca setiap bagian hingga aliran berakhir. Jangan mengasumsikan bagian terakhir hanya berisi token terakhir. Bagian terakhir dalam aliran SSE kami menyertakan usage bidang dengan total token input dan output. Jika Anda membuang data ini, Anda tidak dapat melacak konsumsi kredit prabayar secara akurat.
Jebakan Umum
- Mengabaikan peristiwa SSE terakhir.
- Timeout diatur terlalu rendah untuk penyelesaian panjang.
- Tidak menangani JSON parsial dalam mode streaming.
Selalu konsumsi seluruh stream untuk memastikan server mengetahui klien telah menerima respons penuh. Ini mencegah kebocoran sumber daya di sisi kami dan memastikan Anda memiliki data yang diperlukan untuk log Anda sendiri.
Menangani Error Mode JSON dalam Produksi
Kesalahan mode JSON terjadi karena model mungkin menghasilkan teks setelah kurung kurawal penutup, melanggar aturan parsing JSON yang ketat. Ketika Anda mengatur response_format ke {"type": "json_object", model berusaha menghasilkan JSON yang valid, tetapi sering kali menambahkan pengisi percakapan seperti 'Ini adalah data:' setelah kurung tutup. Parser Anda kemudian rusak karena teks tambahan tersebut.
Hapus teks trailing setelah kurung kurawal penutup valid terakhir. Jangan mengandalkan model untuk berhenti tepat di akhir struktur JSON. Anda harus menerapkan langkah pasca-pemrosesan untuk menemukan '}' atau ']' terakhir dan membuang segalanya setelahnya. Ini sangat kritis saat mengurai array atau objek bersarang.
Praktik Terbaik
- Gunakan regex untuk mengekstrak blok JSON terakhir yang valid.
- Validkan string yang diekstrak dengan parser JSON.
- Coba lagi dengan suhu lebih rendah jika outputnya kacau.
Pendekatan ini memastikan pipa produksi Anda tetap stabil bahkan ketika model memutuskan untuk banyak bicara. Model uncensored kurang terkendali, sehingga mereka mungkin terasa lebih 'kreatif' dengan format mereka.
Memahami Batas Jendela Konteks
Batas jendela konteks adalah 100.000 token untuk prompt dan completion gabungan. Ini berarti jika input Anda adalah 50.000 token, Anda hanya dapat menghasilkan hingga 50.000 token sebelum mencapai batas. Batas ini bukan hanya untuk input; ini adalah anggaran bersama untuk seluruh permintaan.
Hitung ruang output yang tersedia dengan mengurangi jumlah token input dari 100.000. Jika Anda mengirim prompt sistem besar atau riwayat pesan panjang, ruang output yang tersedia akan menyusut sesuai. Ini sangat penting untuk aplikasi yang mempertahankan riwayat percakapan panjang.
Contoh Perhitungan
- Jendela Total: 100.000 token.
- Token Input: 20.000 token.
- Output Maks: 80.000 token.
Jika Anda melebihi batas ini, API mengembalikan error. Pantau penggunaan token Anda secara ketat untuk menghindari pemotongan respons model yang tidak terduga. Model tidak secara otomatis memotong; model hanya menolak permintaan jika total melebihi jendela.
Penghitungan Token dan Estimasi Biaya
Estimasi biaya harus memperhitungkan perbedaan harga antara token input dan output. Token input berharga $0,15 per 1M token, sedangkan token output berharga $0,50 per 1M token. Token output jauh lebih mahal, sehingga menghasilkan respons panjang akan meningkatkan biaya Anda lebih cepat dibandingkan mengirim prompt panjang.
Perkirakan biaya Anda dengan mengalikan jumlah token yang diharapkan dengan harga masing-masing. Misalnya, 10.000 token input dan 5.000 token output akan biayanya: (10.000/1.000.000 * $0,15) + (5.000/1.000.000 * $0,50). Ini sama dengan $0,0015 + $0,0025 = $0,004 per permintaan.
Tabel Harga
| Jenis Token | Harga per 1M Token |
|---|---|
| Input | $0.15 |
| Output | $0.50 |
Lacak penggunaan Anda melalui chunk SSE akhir atau respons API. Ini memastikan Anda dapat membuat anggaran secara akurat untuk aplikasi dengan volume tinggi. Kredit prabayar tidak pernah kedaluwarsa, sehingga Anda dapat merencanakan pengeluaran Anda seiring waktu tanpa biaya bulanan.
Batas Laju: Penjelasan 300 RPM
Pembatasan laju membatasi permintaan Anda menjadi 300 per menit per kunci API. Batas ini berlaku untuk semua permintaan, terlepas dari ukuran payload atau jumlah token. Jika Anda melebihi batas ini, API mengembalikan kesalahan 429. Anda harus menerapkan backoff eksponensial untuk menangani kesalahan ini dengan baik.
Pantau laju permintaan Anda dan sesuaikan konkurensi Anda. Jika Anda menggunakan beberapa utas atau proses, pastikan mereka berbagi kunci API yang sama dan secara kolektif tetap di bawah batas 300 RPM. Melebihi batas ini akan menghasilkan error sementara hingga laju direset.
Menangani Error 429
- Terapkan backoff eksponensial.
- Log permintaan yang gagal untuk analisis.
- Kurangi konkurensi jika batas sering terjadi.
API kami dirancang untuk penggunaan volume tinggi, tetapi batas laju penggunaan memastikan penggunaan yang adil di semua klien. Jika Anda membutuhkan batas yang lebih tinggi, Anda dapat membuat kunci API baru, tetapi perhatikan bahwa setiap akun dibatasi hanya untuk satu kunci aktif pada satu waktu.
Pemecahan Masalah Kegagalan Function Calling
Kegagalan function calling terjadi ketika definisi alat model tidak sesuai dengan skema yang diharapkan atau ketika model gagal menghasilkan JSON yang valid untuk argumen alat. Pastikan definisi alat Anda presisi dan menyertakan semua parameter yang diperlukan. Skema yang ambigu menyebabkan panggilan alat yang tidak valid.
Validkan argumen alat sebelum mengeksekusi fungsi. Model mungkin menghasilkan argumen yang kehilangan bidang yang diperlukan atau berisi tipe yang salah. Kode klien Anda harus menangani kesalahan ini dengan mencoba ulang dengan prompt yang lebih jelas atau menyesuaikan definisi alat.
Langkah Debugging
- Periksa sintaks definisi alat.
- Validasi tipe dan nilai argumen.
- Tinjau output model untuk bidang yang hilang.
Function calling adalah fitur yang kuat, tetapi memerlukan desain skema yang hati-hati. Model uncensored mungkin kurang konsisten dengan definisi alat dibandingkan rekan mereka yang terfilter, sehingga validasi yang ketat sangat penting.
Mengapa 'tanpa sensor' Bukan Sepenuhnya Tanpa Batas
Label 'tanpa sensor' berarti model tidak menolak topik dewasa, fiksi, atau kontroversial yang sah, tetapi masih memiliki batas keras pada konten seksual yang melibatkan anak di bawah umur. Ini adalah satu-satunya pembatasan konten keras yang selalu berlaku. Permintaan yang berisi konten tersebut akan ditolak, bahkan jika sisa prompt valid sepenuhnya.
Penolakan lain mungkin masih terjadi karena kesalahan teknis atau batas laju. Model ini bukan sihir; model ini masih dapat gagal menghasilkan respons jika input terlalu kompleks atau jendela konteks terlampaui. Pahami bahwa 'uncensored' mengacu pada kebijakan konten, bukan keandalan teknis.
Batas Konten
- Tidak ada konten seksual yang melibatkan anak di bawah umur.
- Konten Dewasa Hukum diizinkan.
- Kesalahan teknis masih dapat menyebabkan penolakan.
Pembedaan ini penting untuk aplikasi yang perlu menangani berbagai topik. Mengetahui batas spesifik membantu Anda merancang logika filter Anda dengan benar.
Debugging Error 400 vs 429
Error 400 menunjukkan adanya masalah dengan permintaan itu sendiri, seperti JSON tidak valid, bidang yang diperlukan hilang, atau melebihi batas body permintaan 8 MB. Error 429 menunjukkan bahwa Anda telah melebihi batas kecepatan 300 permintaan per menit. Membedakan antara error-error ini membantu Anda memperbaiki masalah yang tepat dengan cepat.
Untuk kesalahan 400, periksa payload permintaan dan skema Anda. Untuk kesalahan 429, terapkan backoff dan kurangi konkurensi. Jika Anda menerima kesalahan 400 dengan pesan tentang ukuran badan permintaan, pastikan Anda tidak mengirim terlalu banyak data dalam satu permintaan. Batas 8 MB bersifat ketat.
Kode Kesalahan
| Kode Kesalahan | Makna |
|---|---|
| 400 | Permintaan Buruk |
| 429 | Batas Laju Dilewati |
Mencatat error ini beserta konteksnya (payload, timestamp) membuat debugging jauh lebih mudah. Gunakan data ini untuk mengoptimalkan integrasi Anda dan menghindari kegagalan berulang.
Langkah Selanjutnya untuk Optimasi Heretic LLM
Optimasi dimulai dengan memantau penggunaan token dan tingkat error Anda. Gunakan data token dari potongan SSE terakhir untuk melacak konsumsi aktual Anda. Bandingkan ini dengan perkiraan biaya Anda untuk memastikan akurasi. Sesuaikan strategi konkurensi dan pembatasan laju berdasarkan pola penggunaan yang Anda amati.
Perhatikan penggunaan suhu yang lebih rendah untuk output JSON atau pemanggilan fungsi yang lebih konsisten. Jika Anda memerlukan respons yang lebih kreatif, tingkatkan suhu tetapi bersiaplah untuk lebih banyak kesalahan parsing. Bereksperimen dengan parameter berbeda untuk menemukan keseimbangan yang tepat untuk kasus penggunaan Anda.
Tips Optimasi
- Pantau penggunaan token secara ketat.
- Sesuaikan suhu untuk konsistensi vs. kreativitas.
- Implementasikan penanganan kesalahan yang kuat.
Mulai dengan percobaan gratis untuk menguji integrasi Anda. Ini adalah cara berisiko rendah untuk memverifikasi bahwa kode klien Anda menangani streaming, mode JSON, dan batas laju dengan benar sebelum berkomitmen pada kredit pra-dibayar.
