Ringkasan
- Respons aliran memerlukan penapisan SSE yang kukuh untuk menangani bahagian tidak lengkap dan data penggunaan token akhir.
- Kegagalan mod JSON biasanya berpunca daripada model menjana teks akhir di luar skema JSON yang ketat.
- Tetingkap konteks 100k dikongsi antara prompt dan penyelesaian, jadi output panjang mengurangkan ruang input yang tersedia.
- Penaksiran kos mesti mengambil kira harga token output yang lebih tinggi berbanding token input.
Kenapa Respon Streaming Anda Tersekat
Respons aliran tergantung apabila klien gagal membaca bahagian Acara yang Dihantar Pelayan (SSE) terakhir yang mengandungi data penggunaan token. API kami mengalirkan token seperti yang dijana, tetapi sambungan hanya ditutup sepenuhnya selepas bahagian terakhir tiba. Jika kod klien anda memutuskan sambungan awal atau mengabaikan bahagian terakhir, anda kehilangan kiraan token tepat yang diperlukan untuk pengesahan pengebilan.
Baca setiap bahagian sehingga aliran berakhir. Jangan andaikan bahagian terakhir hanya mengandungi token akhir. Bahagian akhir dalam aliran SSE kami termasuk usage bidang dengan jumlah token input dan output. Jika anda membuang data ini, anda tidak dapat melacak penggunaan kredit prabayar anda dengan tepat.
Jebakan Lazim
- Mengabaikan acara SSE akhir.
- Masa tamat ditetapkan terlalu rendah untuk penyelesaian teks panjang.
- Tidak mengendalikan JSON separa dalam mod penstriman.
Sentiasa konsumsi seluruh aliran untuk memastikan pelayan mengetahui klien telah menerima respons penuh. Ini mencegah kebocoran sumber di pihak kami dan memastikan anda mempunyai data yang diperlukan untuk log anda sendiri.
Menangani Ralat Mod JSON dalam Pengeluaran
Kesilapan mod JSON berlaku kerana model mungkin menjana teks selepas kurungan penutup, melanggar peraturan penguraian JSON yang ketat. Apabila anda menetapkan response_format ke {"type": "json_object", model cuba output JSON yang sah, tetapi ia sering menambah pengisian perbualan seperti 'Ini adalah data:' selepas kurungan penutup. Parser anda kemudian rosak pada teks tambahan.
Buang teks akhir selepas kurungan penutup yang sah terakhir. Jangan bergantung pada model untuk berhenti tepat di hujung struktur JSON. Anda mesti melaksanakan langkah pasca-pemprosesan untuk mencari '{' atau ']' terakhir dan membuang segala-galanya selepasnya. Ini sangat penting apabila menguraikan array atau objek bersarang.
Amalan Terbaik
- Gunakan regex untuk mengekstrak blok JSON sah terakhir.
- Sahkan rentetan yang diekstrak dengan pengekod JSON.
- Cuba semula dengan suhu yang lebih rendah jika outputnya kacau.
Pendekatan ini memastikan saluran pengeluaran anda kekal stabil walaupun model memutuskan untuk menjadi banyak bicara. Model uncensored kurang terikat, jadi mereka mungkin terasa lebih 'kreatif' dengan format mereka.
Memahami Had Tetingkap Konteks
Had jendela konteks ialah 100,000 token untuk prompt dan penyelesaian gabungan. Ini bermakna jika input anda ialah 50,000 token, anda hanya boleh menjana sehingga 50,000 token sebelum mencapai had. Had ini bukan hanya untuk input; ia adalah bajet bersama untuk keseluruhan permintaan.
Kira ruang output tersedia anda dengan menolak jumlah token input daripada 100,000. Jika anda menghantar prompt sistem besar atau sejarah mesej yang panjang, ruang output tersedia anda akan mengecil dengan sewajarnya. Ini sangat penting untuk aplikasi yang mengekalkan sejarah perbualan yang panjang.
Contoh Pengiraan
- Jendela Jumlah: 100,000 token.
- Token Input: 20,000 token.
- Output Maks: 80,000 token.
Jika anda melebihi had ini, API mengembalikan ralat. Pantau penggunaan token anda dengan teliti untuk mengelakkan pemendekan tidak dijangka pada respons model anda. Model tidak memendekkan secara automatik; ia hanya menolak permintaan jika jumlah melebihi tetingkap.
Pengiraan Token dan Anggaran Kos
Penaksiran kos mesti mengambil kira perbezaan harga antara token input dan output. Token input berharga $0.15 per 1M token, manakala token output berharga $0.50 per 1M token. Token output jauh lebih mahal, jadi menjana respons panjang akan meningkatkan kos anda dengan lebih cepat berbanding menghantar prompt panjang.
Anggaran kos anda dengan mendarabkan jumlah token yang dijangka dengan harga masing-masing. Sebagai contoh, 10,000 token input dan 5,000 token output akan menelan: (10,000/1,000,000 * $0.15) + (5,000/1,000,000 * $0.50). Ini bersamaan dengan $0.0015 + $0.0025 = $0.004 per permintaan.
Jadual Harga
| Jenis Token | Harga per 1M Token |
|---|---|
| Input | $0.15 |
| Output | $0.50 |
Jejak penggunaan anda melalui potongan SSE akhir atau respons API. Ini memastikan anda boleh membuat bajet dengan tepat untuk aplikasi bervolume tinggi. Kredit pra-dibayar tidak luput, jadi anda boleh merancang perbelanjaan anda dari masa ke masa tanpa yuran bulanan.
Had Kadar: Penjelasan 300 RPM
Had kadar mengekang permintaan anda pada 300 setiap minit bagi setiap kunci API. Had ini terpakai untuk semua permintaan, tidak kira saiz payload atau kiraan token. Jika anda melebihi had ini, API akan memulangkan ralat 429. Anda mesti melaksanakan penangguhan eksponen untuk mengendalikan ralat ini dengan baik.
Pantau kadar permintaan anda dan laraskan kekonkurenan anda dengan sewajarnya. Jika anda menggunakan beberapa benang atau proses, pastikan mereka berkongsi kunci API yang sama dan secara kolektif kekal di bawah had 300 RPM. Melebihi had ini akan mengakibatkan ralat sementara sehingga kadar ditetapkan semula.
Menangani Ralat 429
- Laksanakan penangguhan eksponen.
- Log permintaan yang gagal untuk analisis.
- Kurangkan kekonkurensian jika had sering berlaku.
API kami direka bentuk untuk penggunaan bervolume tinggi, tetapi had kadar memastikan penggunaan yang adil untuk semua klien. Jika anda memerlukan had yang lebih tinggi, anda boleh menjana kunci API baharu, tetapi ambil perhatian bahawa setiap akaun dihadkan kepada satu kunci aktif pada satu masa.
Penyelesaian Masalah Kegagalan Pemanggilan Fungsi
Kegagalan panggilan fungsi berlaku apabila definisi alat model tidak sepadan dengan skema yang dijangka atau apabila model gagal mengeluarkan JSON yang sah untuk hujah alat. Pastikan definisi alat anda tepat dan termasuk semua parameter yang diperlukan. Skema yang kabur membawa kepada panggilan alat yang rosak.
Sahkan hujah alat sebelum melaksanakan fungsi. Model mungkin menjana hujah yang kekurangan medan diperlukan atau mengandungi jenis yang salah. Kod klien anda harus menangani ralat ini dengan cuba semula dengan arahan yang lebih jelas atau melaraskan definisi alat.
Langkah Nyahpepijat
- Semak sintaks definisi alat.
- Sahkan jenis dan nilai hujah.
- Semak output model untuk medan yang hilang.
Panggilan fungsi adalah ciri berkuasa, tetapi memerlukan reka bentuk skema yang teliti. Model tanpa sensor mungkin kurang konsisten dengan definisi alat berbanding rakan mereka yang ditapis, jadi pengesahan yang ketat adalah penting.
Mengapa 'tanpa sensor' bukan bermaksud tanpa had sepenuhnya
Label 'tidak disaring' bermaksud model tidak menolak topik dewasa, fiksyen, atau kontroversi yang sah, tetapi ia masih mempunyai had keras terhadap kandungan seksual yang melibatkan kanak-kanak. Ini adalah satu-satunya had kandungan keras yang sentiasa terpakai. Permintaan yang mengandungi kandungan sedemikian akan ditolak, walaupun sebahagian besar arahan lain adalah sah sepenuhnya.
Penolakan lain mungkin masih berlaku akibat ralat teknikal atau had kadar. Model bukan sihir; ia masih boleh gagal menjana respons jika input terlalu kompleks atau tetingkap konteks telah melebihi. Fahami bahawa 'uncensored' merujuk kepada dasar kandungan, bukan kebolehpercayaan teknikal.
Had Kandungan
- Tiada kandungan seksual melibatkan kanak-kanak bawah umur.
- Kandungan Dewasa Sah dibenarkan.
- Ralat teknikal masih boleh menyebabkan penolakan.
Perbezaan ini penting untuk aplikasi yang perlu menangani pelbagai topik. Mengetahui had khusus membantu anda mereka bentuk logik penapisan anda dengan betul.
Nyahpepijat Ralat 400 vs 429
Ralat 400 menunjukkan masalah dengan permintaan itu sendiri, seperti JSON tidak sah, medan yang diperlukan hilang, atau melebihi had badan permintaan 8 MB. Ralat 429 menunjukkan bahawa anda telah melebihi had laju 300 permintaan per minit. Membezakan antara ralat-ralat ini membantu anda membetulkan isu yang betul dengan cepat.
Untuk ralat 400, semak payload permintaan dan skema anda. Untuk ralat 429, laksanakan backoff dan kurangkan konkurensi. Jika anda menerima ralat 400 dengan mesej tentang saiz badan permintaan, pastikan anda tidak menghantar terlalu banyak data dalam satu permintaan. Had 8 MB adalah ketat.
Kod Ralat
| Kod Ralat | Makna |
|---|---|
| 400 | Permintaan Buruk |
| 429 | Had Kadar Dilebihkan |
Melogkan ralat-ralat ini dengan konteks mereka (payload, cap masa) menjadikan nyahpepijat jauh lebih mudah. Gunakan data ini untuk mengoptimumkan integrasi anda dan mengelakkan kegagalan berulang.
Langkah seterusnya untuk Pengoptimuman Heretic LLM
Pengoptimuman bermula dengan memantau penggunaan token anda dan kadar ralat. Gunakan data token dari segmen SSE akhir untuk melacak penggunaan sebenar anda. Bandingkan ini dengan anggaran kos anda untuk memastikan ketepatan. Laraskan strategi kekonkurenan dan had kadar anda berdasarkan corak penggunaan yang diperhatikan.
Pertimbangkan menggunakan suhu yang lebih rendah untuk output JSON atau panggilan fungsi yang lebih konsisten. Jika anda memerlukan respons yang lebih kreatif, tingkatkan suhu tetapi bersiaplah untuk lebih banyak ralat pengekodan. Eksperimen dengan parameter berbeza untuk mencari keseimbangan yang tepat untuk kes penggunaan anda.
Petua Pengoptimuman
- Pantau penggunaan token dengan teliti.
- Laraskan suhu untuk konsistensi berbanding kreativiti.
- Laksanakan pengendalian ralat yang kukuh.
Mulakan dengan percubaan percuma untuk menguji integrasi anda. Ini adalah cara berisiko rendah untuk mengesahkan bahawa kod klien anda mengendalikan penstriman, mod JSON, dan had kadar dengan betul sebelum berkomitmen kepada kredit pra-bayar.
