Özet
- Akış yanıtları, eksik parçaları ve son belirteç kullanım verilerini işlemek için sağlam SSE ayrıştırma gerektirir.
- JSON modu başarısızlıkları genellikle modelin sıkı JSON şemasının dışında kalan metinler üretmesinden kaynaklanır.
- 100k bağlam penceresi prompt ve tamamlama arasında paylaşıldığından, uzun çıktılar mevcut giriş alanını azaltır.
- Maliyet tahmini, çıktı tokenlarının girdi tokenlarına göre daha yüksek fiyatını hesaba katmalıdır.
Neden Akış Yanıtınız Donuyor
Akış yanıtları, istemci belirteç kullanım verilerini içeren son Sunucu Tarafı Olayı (SSE) parçasını okumadığında takılır. API'miz belirteçleri oluşturulduklarında akışa alır, ancak bağlantı son parça geldiğinde tamamen kapanır. İstemci kodunuz erken bağlantıyı keserse veya son parçayı yok sayarsa, faturalandırma doğrulaması için gereken kesin belirteç sayılarını kaybedersiniz.
Akış sonlanana kadar her parçayı okuyun. Son parçanın yalnızca son tokenı içerdiğini varsaymayın. SSE akışımızdaki son parça şunu içerir usage alanı, giriş ve çıkış token toplamlarını içerir. Bu veriyi atarsanız, ön ödemeli kredi tüketiminizi doğru bir şekilde takip edemezsiniz.
Yaygın Tuzaklar
- Son SSE olayının göz ardı edilmesi.
- Uzun tamamlamalar için çok düşük ayarlanmış zaman aşımları.
- Akış modunda kısmi JSON işlenmiyor.
Sunucunun istemcinin tam yanıtı aldığını bilmesini sağlamak için akışı her zaman tüketin. Bu, tarafımızda kaynak sızıntılarını önler ve kendi günlükleriniz için gereken verilere sahip olduğunuzdan emin olursunuz.
Üretimde JSON Modu Hatalarını İşleme
JSON modu hataları, modelin kapanış parantezinden sonra metin üretmesi ve sıkı JSON ayrıştırma kurallarını ihlal etmesi nedeniyle oluşur. Set response_format için {"type": "json_object", model geçerli JSON çıktısı vermeye çalışır ancak genellikle kapanış parantezinden sonra 'Veriler şunlardır:' gibi konuşmacı dolgu metni ekler. Parserınız fazladan metin nedeniyle çöker.
Son geçerli kapanış parantezinden sonra gelen metni temizleyin. Modelin JSON yapısının tam sonunda durduğuna güvenmeyin. '}' veya ']' karakterini bulup ardından gelen her şeyi atmak için bir post-işleme adımı uygulamanız gerekir. Bu, dizileri veya iç içe nesneleri ayrıştırırken kritiktir.
En İyi Uygulamalar
- Son geçerli JSON bloğunu çıkarmak için bir regex kullanın.
- Çıkarılan dizgiyi bir JSON ayrıştırıcısıyla doğrulayın.
- Çıktı kaotikse, daha düşük bir sıcaklıkla yeniden deneyin.
Bu yaklaşım, modelin konuşkan olmaya karar verse bile üretim hattınızın stabil kalmasını sağlar. Uncensored modeller daha az kısıtlayıcıdır, bu nedenle biçimlendirmelerinde daha 'yaratıcı' olabilirler.
Bağlam Penceresi Limitlerini Anlamak
Bağlam penceresi limiti, birleşik istem ve tamamlama için 100,000 token'dır. Bu, girdiniz 50,000 token ise, limite takılmadan yalnızca 50,000 token oluşturabileceğiniz anlamına gelir. Limit yalnızca girdi için değildir; tüm istek için paylaşılan bir bütçedir.
Giriş token sayısını 100.000'den çıkararak mevcut çıkış alanınızı hesaplayın. Büyük bir sistem istemi veya uzun bir mesaj geçmiş gönderirseniz, mevcut çıkış alanınız buna göre daralır. Bu, uzun konuşma geçmişlerini yöneten uygulamalar için kritiktir.
Hesaplama Örneği
- Toplam Pencere: 100.000 token.
- Girdi Tokenleri: 20.000 token.
- Maksimum Çıktı: 80.000 token.
Bu sınırı aşarsanız API bir hata döndürür. Modelinizin yanıtının beklenmedik şekilde kırpılmasını önlemek için token kullanımunu yakından izleyin. Model otomatik olarak kırpma yapmaz; toplam pencereyi aşarsa isteği basitçe reddeder.
Token Sayma ve Maliyet Tahmini
Maliyet tahmini, girdi ve çıktı tokenları arasındaki fiyat farkını hesaba katmalıdır. Girdi tokenları 1M başına $0.15, çıktı tokenları ise 1M başına $0.50'dir. Çıktı tokenları önemli ölçüde daha pahalı olduğundan, uzun yanıtlar oluşturmak, uzun istemler göndermeye kıyasla maliyetlerinizi daha hızlı artırır.
Maliyetlerinizi tahmin etmek için beklenen token sayısını ilgili fiyatla çarpın. Örneğin, 10.000 giriş tokenı ve 5.000 çıktı tokenı şu maliyete neden olur: (10.000/1.000.000 * $0.15) + (5.000/1.000.000 * $0.50). Bu, istek başına $0.0015 + $0.0025 = $0.004 eder.
Fiyat Tablosu
| Token Türü | 1M Token başına fiyat |
|---|---|
| Girdi | $0.15 |
| Çıktı | $0.50 |
Kullanımınızı son SSE chunk'ı veya API yanıtı üzerinden takip edin. Bu, yüksek hacimli uygulamalar için bütçenizi doğru bir şekilde planlamanızı sağlar. Ön ödemeli kredi süresi dolmaz, böylece aylık ücretler olmadan harcamalarınızı zaman içinde planlayabilirsiniz.
Saniye Başına İstek Limiti: Dakikada 300 RPM Açıklaması
Hız sınırlama, isteklerinizi dakikada 300'e kadar sınırlandırır. Bu sınır, yük boyutu veya token sayısından bağımsız olarak tüm isteklere uygulanır. Bu sınırı aşarsanız API bir 429 hatası döndürür. Bu hataları zarifçe yönetmek için üstel geri çekilme (exponential backoff) uygulamanız gerekir.
İstek hızını izleyin ve eşzamanlılığı buna göre ayarlayın. Birden fazla iş parçacığı veya işlem kullanıyorsanız, bunların aynı API anahtarını paylaştığından ve kolektif olarak dakikada 300 RPM sınırının altında kaldığından emin olun. Bu limiti aşmak, hız sıfırlanana kadar geçici hatalara neden olur.
429 Hatalarını İşleme
- Üstel geri çekilme uygulayın.
- Analiz için başarısız istekleri günlüğe kaydedin.
- Sınırlar sıkça alınıyorsa eşzamanlılığı azaltın.
API'miz yüksek hacimli kullanım için tasarlanmıştır ancak hız sınırı tüm istemciler arasında adil kullanım sağlar. Daha yüksek limitlere ihtiyacınız varsa yeni bir API anahtarı oluşturabilirsiniz, ancak her hesabın aynı anda yalnızca bir aktif anahtarı olabileceğini unutmayın.
Fonksiyon Çağırma Başarısızlıklarını Halletmek
Fonksiyon çağırma hataları, modelin araç tanımı beklenen şema ile eşleşmediğinde veya model araç argümanları için geçerli JSON oluşturamadığında oluşur. Araç tanımlarınızın kesin olduğundan ve tüm gerekli parametreleri içerdiğinden emin olun. Belirsiz şemalar bozuk araç çağrılarına yol açar.
İşlevi yürütmeden önce araç argümanlarını doğrulayın. Model, gerekli alanları eksik içeren veya yanlış türlerde argümanlar üretebilir. İstemci kodunuz, bunları daha net bir istemle tekrarlayarak veya araç tanımını ayarlayarak bu hataları işlemelidir.
Hata Ayıklama Adımları
- Araç tanımı sözdizimini kontrol edin.
- Argüman türlerini ve değerlerini doğrula.
- Model çıktısını eksik alanlar için gözden geçirin.
Fonksiyon çağırma güçlü bir özelliktir ancak dikkatli şema tasarımı gerektirir. Uncensored modeller, filtreli karşılıklarına göre araç tanımları konusunda daha az tutarlı olabilir, bu nedenle titiz doğrulama esastır.
'uncensored' Tamamen Sınırsız Değil
'kısıtlanmamış' etiketi modelin yasal yetişkin, kurgusal veya tartışmalı konuları reddetmediği anlamına gelir ancak küçüklerle ilgili cinsel içerikler için katı bir sınırı vardır. Bu, her zaman geçer olan tek katı içerik kısıtlamasıdır. Bu tür içerik içeren istekler reddedilir, prompt'un geri kalanı mükemmel olsa bile.
Diğer reddetmeler teknik hatalar veya hız sınırları nedeniyle yine de ortaya çıkabilir. Model sihirli değnek değildir; girdi çok karmaşıksa veya bağlam penceresi aşılırsa yanıt oluşturamaması hala mümkündür. 'uncensored' ifadesinin teknik güvenilirlik değil, içerik politikası anlamına geldiğini anlayın.
İçerik Sınırları
- Reşit olmayanlarla cinsel içerik yok.
- Hukuki yetişkin içeriğe izin verilir.
- Teknik hatalar hala reddetmelere neden olabilir.
Bu ayrım, geniş bir konu yelpazesini işlemesi gereken uygulamalar için önemlidir. Belirli limiti bilmek, filtreleme mantığınızı doğru tasarlamanıza yardımcı olur.
400 ve 429 Hatalarını Hata Ayıklama
400 hataları, geçersiz JSON, gerekli alanların eksikliği veya 8 MB istek gövdesi sınırının aşılması gibi istekle ilgili bir sorunu gösterir. 429 hataları, dakikada 300 istek hız sınırını aştığınızı gösterir. Bu hataları ayırt etmek, doğru sorunu hızlıca çözmenize yardımcı olur.
400 hataları için istek yükünüzü ve şemanızı kontrol edin. 429 hataları için geri çekilme uygulayın ve eşzamanlılığı azaltın. İstek gövdesi boyutu hakkında bir mesaj içeren bir 400 hatası alırsanız, tek bir istekte çok fazla veri göndermediğinizden emin olun. 8 MB sınırı katıdır.
Hata Kodları
| Hata Kodu | Anlam |
|---|---|
| 400 | Hatalı İstek |
| 429 | Saniye Başına İstek Limiti Aşıldı |
Bu hataları bağlamıyla birlikte (yük, zaman damgası) günlüğe kaydetmek hata ayıklamayı çok daha kolay hale getirir. Entegrasyonunuzu optimize etmek ve tekrarlayan başarısızlıklardan kaçınmak için bu verileri kullanın.
Heretic LLM Optimizasyonu İçin Sonraki Adımlar
Optimizasyon, token kullanımınızı ve hata oranlarınızı izleyerek başlar. Gerçek tüketiminizi takip etmek için son SSE parçasından gelen token verisini kullanın. Bu veriyi tahmini maliyetlerinizle karşılaştırarak doğruluğu sağlayın. Gözlemlediğiniz kullanım kalıplarına göre eşzamanlılık ve hız sınırlama stratejilerinizi ayarlayın.
Daha tutarlı JSON çıktısı veya işlev çağırma için daha düşük bir sıcaklık kullanmayı göz önünde bulundurun. Daha yaratıcı yanıtlar gerekiyorsa sıcaklığı artırın ancak daha fazla ayrıştırma hatası ile karşılaşmaya hazır olun. Kullanım durumunuz için doğru dengeyi bulmak üzere farklı parametrelerle deney yapın.
Optimizasyon İpuçları
- Token kullanımunu yakından izleyin.
- Tutarlılık ile yaratıcılık arasında sıcaklığı ayarlayın.
- Sağlam hata işleme uygulayın.
Entegrasyonunuzu test etmek için ücretsiz deneme ile başlayın. Bu, istemci kodunuzun akış, JSON modu ve hız sınırlarını doğru şekilde işleyip işlemediğini taahhüt etmeden önce doğrulamak için düşük riskli bir yoldur.
