Podsumowanie
- Odpowiedzi strumieniowe wymagają niezawodnego parsowania SSE, aby obsłużyć niekompletne fragmenty i dane o użyciu końcowych tokenów.
- Awarie trybu JSON zwykle wynikają z generowania przez model tekstu końcowego poza ścisłym schematem JSON.
- Okno kontekstowe 100k jest dzielone między podpowiedź a uzupełnienie, więc długie wyjścia zmniejszają dostępną przestrzeń wejściową.
- Szacowanie kosztów musi uwzględniać wyższą cenę tokenów wyjściowych w porównaniu do tokenów wejściowych.
Dlaczego Twoja odpowiedź streamingowa się zawiesza
Strumieniowanie odpowiedzi zawiesza się, gdy klient nie odczyta ostatniego fragmentu zdarzeń wysłanych przez serwer (SSE) zawierającego dane o zużyciu tokenów. Nasze API strumieniuje tokeny w miarę ich generowania, ale połączenie jest w pełni zamykane dopiero po przybyciu ostatniego fragmentu. Jeśli Twój kod klienta rozłączy się wcześniej lub zignoruje ostatni fragment, tracisz dokładne liczby tokenów potrzebne do weryfikacji rozliczeń.
Czytaj każdy chunk do końca strumienia. Nie zakładaj, że ostatni chunk zawiera tylko ostatni token. Ostatni chunk w naszym strumieniu SSE zawiera usage pole z łączną liczbą tokenów wejściowych i wyjściowych. Jeśli odrzucisz te dane, nie będziesz mógł dokładnie śledzić zużycia kredytów.
Typowe pułapki
- Ignorowanie ostatniego zdarzenia SSE.
- Zbyt niskie limity czasu dla długich uzupełnień.
- Nie obsługuje częściowego JSON-a w trybie strumieniowym.
Zawsze pobieraj cały strumień, aby serwer wiedział, że klient otrzymał pełną odpowiedź. Zapobiega to wyciekom zasobów po naszej stronie i zapewnia, że masz dane potrzebne do własnych logów.
Rozwiązywanie błędów trybu JSON w środowisku produkcyjnym
Błędy trybu JSON występują, ponieważ model może generować tekst po zamykającym nawiasie klamrowym, naruszając ścisłe zasady parsowania JSON. Gdy ustawisz response_format do {"type": "json_object", model próbuje wygenerować poprawny JSON, ale często dodaje tekst konwersacyjny, np. 'Oto dane:', po zamykającym nawiasie klamrowym. Twój parser następnie ulega awarii na skutek dodatkowego tekstu.
Usuń tekst końcowy po ostatnim poprawnym nawiasie klamrowym. Nie polegaj na modelu, aby zatrzymał się dokładnie na końcu struktury JSON. Musisz zaimplementować krok postprzetwarzania, aby znaleźć ostatni '}' lub ']' i odrzucić wszystko po nim. Jest to krytyczne podczas parsowania tablic lub obiektów zagnieżdżonych.
Najlepsze praktyki
- Użyj wyrażenia regularnego do wyodrębnienia ostatniego poprawnego bloku JSON.
- Zweryfikuj wyodrębniony ciąg znaków za pomocą parsera JSON.
- Ponów próbę z niższą temperaturą, jeśli wynik jest chaotyczny.
To podejście zapewnia stabilność Twojego potoku produkcyjnego nawet wtedy, gdy model zdecyduje się być gadatliwy. Modele uncensored są mniej ograniczone, więc mogą wydawać się bardziej 'kreatywne' w swoim formatowaniu.
Zrozumienie limitów okna kontekstowego
Limit okna kontekstowego wynosi 100,000 tokenów łącznie dla promptu i uzupełnienia. Oznacza to, że jeśli Twój input ma 50,000 tokenów, możesz wygenerować maksymalnie 50,000 tokenów przed osiągnięciem limitu. Limit nie dotyczy tylko danych wejściowych; jest to wspólny budżet na całe żądanie.
Oblicz dostępną przestrzeń wyjściową, odejmując liczbę tokenów wejściowych od 100 000. Jeśli wyślesz duży prompt systemowy lub długą historię wiadomości, Twoja dostępna przestrzeń wyjściowa zmniejszy się odpowiednio. Jest to kluczowe dla aplikacji utrzymujących długie historie rozmów.
Przykład obliczeń
- Całkowite okno: 100 000 tokenów.
- Tokeny wejściowe: 20 000 tokenów.
- Maks. Wyjście: 80,000 tokenów.
Jeśli przekroczysz ten limit, API zwraca błąd. Monitoruj zużycie tokenów ściśle, aby uniknąć nieoczekiwanego ucinania odpowiedzi modelu. Model nie odcina automatycznie; po prostu odrzuca żądanie, jeśli całkowita liczba przekracza okno.
Liczenie tokenów i szacowanie kosztów
Szacowanie kosztów musi uwzględniać różnicę cen między tokenami wejściowymi a wyjściowymi. Tokeny wejściowe kosztują $0.15 za 1M tokenów, podczas gdy tokeny wyjściowe kosztują $0.50 za 1M tokenów. Tokeny wyjściowe są znacznie droższe, więc generowanie długich odpowiedzi zwiększy Twoje koszty szybciej niż wysłanie długich promptów.
Oszacuj swoje koszty, mnożąc oczekiwaną liczbę tokenów przez odpowiednią cenę. Na przykład, 10.000 tokenów wejściowych i 5.000 tokenów wyjściowych będzie kosztować: (10.000/1.000.000 * $0,15) + (5.000/1.000.000 * $0,50). To daje $0,0015 + $0,0025 = $0,004 za żądanie.
Tabela cenowa
| Typ tokena | Cena za 1M tokenów |
|---|---|
| Wejście | $0.15 |
| Wyjście | $0.50 |
Śledź swoje zużycie za pomocą ostatniego fragmentu SSE lub odpowiedzi API. Zapewnia to możliwość dokładnego planowania budżetu dla aplikacji o dużym ruchu. Kredyt z góry opłacony nie wygasa, więc możesz planować wydatki w czasie bez opłat miesięcznych.
Limit prędkości: wyjaśnienie 300 RPM
Limitowanie zapytań ogranicza liczbę zapytań do 300 na minutę na klucz API. Limit ten dotyczy wszystkich zapytań, niezależnie od rozmiaru ładunku lub liczby tokenów. Jeśli przekroczysz ten limit, API zwróci błąd 429. Musisz zaimplementować wykładnicze ponawianie prób, aby obsłużyć te błędy w sposób elegancki.
Monitoruj szybkość zapytań i dostosuj do niej współbieżność. Jeśli używasz wielu wątków lub procesów, upewnij się, że dzielą ten sam klucz API i łącznie mieszczą się w limicie 300 zapytań na minutę. Przekroczenie tego limitu spowoduje tymczasowe błędy do momentu zresetowania limitu.
Obsługa błędów 429
- Zaimplementuj wykładnicze zwalnianie.
- Loguj nieudane żądania do analizy.
- Zmniejsz współbieżność, jeśli limity są częste.
Nasz API jest zaprojektowane do intensywnego użytku, ale limit szybkości zapewnia uczciwe wykorzystanie przez wszystkich klientów. Jeśli potrzebujesz wyższych limitów, możesz wygenerować nowy klucz API, ale pamiętaj, że każde konto jest ograniczone do jednego aktywnego klucza w danym czasie.
Rozwiązywanie niepowodzeń wywoływania funkcji
Niepowodzenia wywoływania funkcji występują, gdy definicja narzędzia modelu nie pasuje do oczekiwanego schematu lub gdy model nie zwróci poprawnego JSON dla argumentów narzędzia. Upewnij się, że definicje narzędzi są precyzyjne i zawierają wszystkie wymagane parametry. Niejednoznaczne schematy prowadzą do niepoprawnych wywołań narzędzi.
Zweryfikuj argumenty narzędzia przed wykonaniem funkcji. Model może wygenerować argumenty, które nie zawierają wymaganych pól lub zawierają nieprawidłowe typy. Twój kod klienta powinien obsługiwać te błędy, ponawiając żądanie z jaśniejszym promptem lub dostosowując definicję narzędzia.
Kroki debugowania
- Sprawdź składnię definicji narzędzia.
- Zweryfikuj typy i wartości argumentów.
- Przejrzyj wyjście modelu pod kątem brakujących pól.
Wywoływanie funkcji to potężna funkcja, ale wymaga starannego projektowania schematu. Modele uncensored mogą być mniej spójne z definicjami narzędzi niż ich filtrowane odpowiedniki, więc rygorystyczna walidacja jest niezbędna.
Dlaczego 'bez cenzury' nie oznacza całkowitej nieograniczoności
Etykieta 'bez cenzury' oznacza, że model nie odmawia legalnych treści dla dorosłych, fikcyjnych lub kontrowersyjnych, ale nadal ma ścisłą granicę co do treści seksualnych z udziałem małoletnich. Jest to jedyna ścisła ograniczenie treści, które zawsze obowiązuje. Żądania zawierające takie treści zostaną odrzucone, nawet jeśli reszta promptu jest całkowicie poprawna.
Pozostałe odmowy mogą nadal wystąpić z powodu błędów technicznych lub limitów szybkości. Model nie jest magią; nadal może nie wygenerować odpowiedzi, jeśli wejście jest zbyt złożone lub okno kontekstowe zostanie przekroczone. Zrozum, że 'uncensored' odnosi się do polityki treści, a nie niezawodności technicznej.
Limity treści
- Brak treści seksualnych z udziałem małoletnich.
- Prawne treści dla dorosłych są dozwolone.
- Błędy techniczne mogą nadal powodować odmowy.
Ta różnica jest ważna dla aplikacji, które muszą obsługiwać szeroki zakres tematów. Znanie konkretnego limitu pomaga poprawnie zaprojektować logikę filtrowania.
Debugowanie błędów 400 vs 429
Błędy 400 wskazują na problem z samym żądaniem, taki jak nieprawidłowy JSON, brakujące pola wymagane lub przekroczenie limitu 8 MB dla ciała żądania. Błędy 429 wskazują, że przekroczyłeś limit szybkości wynoszący 300 żądań na minutę. Rozróżnianie tych błędów pomaga szybko naprawić właściwy problem.
Dla błędów 400 sprawdź ładunek żądania i schemat. Dla błędów 429 zaimplementuj backoff i zmniejsz współbieżność. Jeśli otrzymasz błąd 400 z komunikatem dotyczącym rozmiaru ciała żądania, upewnij się, że nie wysyłasz zbyt wielu danych w jednym żądaniu. Limit 8 MB jest ścisły.
Kody błędów
| Kod błędu | Znaczenie |
|---|---|
| 400 | Nieprawidłowe żądanie |
| 429 | Przekroczono limit częstości |
Logowanie tych błędów wraz z ich kontekstem (ładunek, znacznik czasu) znacznie ułatwia debugowanie. Wykorzystaj te dane do optymalizacji integracji i unikania powtarzających się awarii.
Kolejne kroki dla optymalizacji Heretic LLM
Optymalizacja zaczyna się od monitorowania zużycia tokenów i wskaźników błędów. Użyj danych tokenów z ostatniego fragmentu SSE, aby śledzić rzeczywiste zużycie. Porównaj to ze szacowanymi kosztami, aby zapewnić dokładność. Dostosuj strategie współbieżności i limitów szybkości na podstawie obserwowanych wzorców użytkowania.
Rozważ użycie niższej temperatury dla bardziej spójnego wyjścia JSON lub wywoływania funkcji. Jeśli potrzebujesz bardziej kreatywnych odpowiedzi, zwiększ temperaturę, ale bądź przygotowany na większą liczbę błędów parsowania. Eksperymentuj z różnymi parametrami, aby znaleźć odpowiednie równowagę dla Twojego przypadku użycia.
Wskazówki optymalizacyjne
- Monitoruj zużycie tokenów uważnie.
- Dostosuj temperaturę dla spójności vs. kreatywności.
- Wdroż solidną obsługę błędów.
Zacznij od darmowej próby, aby przetestować swoją integrację. Jest to sposób o niskim ryzyku, aby zweryfikować, czy Twój kod klienta poprawnie obsługuje strumieniowanie, tryb JSON i limity szybkości przed zobowiązaniem się do przedpłaconego kredytu.
