Shrnutí
- Streamované odpovědi vyžadují robustní parsování SSE pro zpracování neúplných bloků a dat o využití posledního tokenu.
- Selhání režimu JSON obvykle pramení z generování koncového textu mimo přísné schéma JSON.
- Kontextové okno 100k je sdíleno mezi promptem a dokončením, takže dlouhé výstupy snižují dostupný prostor pro vstup.
- Odhad nákladů musí zohlednit vyšší cenu výstupních tokenů ve srovnání s vstupními.
Proč je vaše streamovaná odpověď visící
Odpovědi v proudu visí, když klient selže při čtení posledního kusu Server-Sent Event (SSE) obsahujícího data o využití tokenů. Naše API streamuje tokeny, jak jsou generovány, ale spojení se plně uzavře až po příjezdu posledního kusu. Pokud se váš kód klienta odpojí dříve nebo ignoruje poslední kus, přijdete o přesné počty tokenů potřebné pro ověření fakturace.
Přečtěte každý chunk, dokud stream neskončí. Nepředpokládejte, že poslední chunk obsahuje pouze poslední token. Poslední chunk v našem SSE streamu obsahuje usage pole s celkovým součtem vstupních a výstupních tokenů. Pokud tato data zahodíte, nebudete moci přesně sledovat spotřebu předplacených kreditů.
Běžné pasti
- Ignorování poslední události SSE.
- Časové limity nastavené příliš nízko pro dlouhá dokončení.
- Nepodporuje částečný JSON v režimu streamování.
Vždy spotřebujte celý stream, aby server věděl, že klient přijal celou odpověď. To zabraňuje únikům zdrojů na naší straně a zajišťuje, že máte data potřebná pro vaše vlastní protokoly.
Zvládání chyb režimu JSON ve výrobě
Chyby režimu JSON nastávají, protože model může generovat text po uzavírací závorce, čímž poruší pravidla striktního parsování JSON. Když nastavíte response_format na {"type": "json_object", model se snaží vrátit platné JSON, ale často přidá konverzační plýtvání, jako je 'Zde jsou data:' za uzavírací závorku. Váš parser pak spadne na dodatečném textu.
Odstraňte koncový text za posledním platným uzavíracím složenou závorkou. Nepočítejte s tím, že model přesně zastaví na konci struktury JSON. Musíte implementovat krok post-zpracování, který najde poslední '}' nebo ']' a zahodí vše za ním. Toto je kritické při parsování polí nebo vnořených objektů.
Nejlepší postupy
- Použijte regulární výraz k extrakci posledního platného bloku JSON.
- Ověřte extrahovaný řetězec pomocí parseru JSON.
- Opakujte s nižší teplotou, pokud je výstup chaotický.
Tento přístup zajišťuje stabilitu vašeho produkčního pipeline, i když se model rozhodne být „mluvnivý“. Uncensored modely jsou méně omezené, takže mohou působit více „kreativně“ při formátování.
Pochopení limitů kontextového okna
Limit kontextového okna je 100 000 tokenů pro kombinovaný prompt a odpověď. To znamená, že pokud je váš vstup 50 000 tokenů, můžete vygenerovat maximálně 50 000 tokenů, než narazíte na limit. Limit neplatí jen pro vstup; je to sdílený rozpočet pro celý požadavek.
Vypočítejte dostupný prostor pro výstup odečtením počtu vstupních tokenů od 100 000. Pokud odešlete velký systémový prompt nebo dlouhou historii zpráv, váš dostupný prostor pro výstup se příslušně zmenší. To je zásadní pro aplikace, které udržují dlouhé historie konverzací.
Příklad výpočtu
- Celkové okno: 100 000 tokenů.
- Vstupní tokeny: 20 000 tokenů.
- Max Výstup: 80,000 tokenů.
Pokud překročíte tento limit, API vrátí chybu. Sledujte své využití tokenů úzce, abyste předešli neočekávanému zkrácení odpovědi modelu. Model automaticky nezkracuje; pouze zamítne požadavek, pokud celkový součet překročí okno.
Počítání tokenů a odhad nákladů
Odhad nákladů musí zohlednit cenový rozdíl mezi vstupními a výstupními tokeny. Vstupní tokeny stojí $0,15 za 1M tokenů, zatímco výstupní tokeny stojí $0,50 za 1M tokenů. Výstupní tokeny jsou výrazně dražší, takže generování dlouhých odpovědí zvýší vaše náklady rychleji než odeslání dlouhých promptů.
Odhadněte své náklady vynásobením očekávaného počtu tokenů příslušnou cenou. Například 10 000 vstupních tokenů a 5 000 výstupních tokenů by stálo: (10 000/1 000 000 * 0,15 $) + (5 000/1 000 000 * 0,50 $). To je 0,0015 $ + 0,0025 $ = 0,004 $ za požadavek.
Cenová tabulka
| Typ tokenu | Cena za 1M tokenů |
|---|---|
| Vstup | $0.15 |
| Výstup | $0.50 |
Sledujte své využití prostřednictvím posledního SSE chunku nebo odpovědi API. To zajišťuje, že můžete přesně plánovat rozpočet pro aplikace s vysokým objemem. Předplacený kredit nevyprší, takže můžete plánovat své výdaje v čase bez měsíčních poplatků.
Limitování rychlosti: Vysvětlení 300 RPM
Omezení rychlosti omezuje vaše požadavky na 300 za minutu na klíč API. Tento limit se vztahuje na všechny požadavky bez ohledu na velikost payloadu nebo počet tokenů. Pokud tento limit překročíte, API vrátí chybu 429. Musíte implementovat exponenciální backoff pro graceful zpracování těchto chyb.
Sledujte rychlost požadavků a přizpůsobte jí souběžnost. Pokud používáte více vláken nebo procesů, ujistěte se, že sdílejí stejný klíč API a společně zůstanou pod limitem 300 požadavků za minutu. Překročení tohoto limitu povede k dočasným chybám, dokud se limit neobnoví.
Zvládání chyb 429
- Implementujte exponenciální zpomalování.
- Logujte selhané požadavky pro analýzu.
- Snížení konkurence, pokud jsou limity časté.
Naše API je navrženo pro vysoký objem provozu, ale limit rychlosti zajišťuje férové využití pro všechny klienty. Pokud potřebujete vyšší limity, můžete vygenerovat nový klíč API, ale mějte na paměti, že každý účet může mít v daném čase aktivní pouze jeden klíč.
Řešení selhání volání funkcí
Selhání volání funkcí nastává, když definice nástroje modelu neodpovídá očekávanému schématu nebo když model selže při výstupu platného JSON pro argumenty nástroje. Ujistěte se, že jsou vaše definice nástrojů přesné a obsahují všechny požadované parametry. Nejasná schémata vedou k nesprávným voláním nástrojů.
Ověřte argumenty nástroje před vykonáním funkce. Model může generovat argumenty, které postrádají vyžadovaná pole nebo obsahují nesprávné typy. Váš klientský kód by měl tyto chyby zpracovat opakováním s jasnějším promptem nebo úpravou definice nástroje.
Kroky ladění
- Zkontrolujte syntaxi definice nástroje.
- Ověřte typy a hodnoty argumentů.
- Zkontrolovat výstup modelu na chybějící pole.
Volání funkcí je výkonná funkce, ale vyžaduje pečlivý návrh schématu. Modely bez omezení mohou být méně konzistentní s definicemi nástrojů než jejich filtrované protějšky, takže je nezbytná přísná validace.
Proč 'bez omezení' není zcela neomezené
Označení 'uncensored' znamená, že model neodmítá legální témata pro dospělé, fiktivní nebo kontroverzní, ale stále má pevný limit na sexuální obsah zahrnující nezletilé. Toto je jediné pevné omezení obsahu, které platí vždy. Požadavky obsahující takový obsah budou odmítnuty, i když zbytek promptu je zcela platný.
Další odmítnutí mohou stále nastat kvůli technickým chybám nebo limitům rychlosti. Model není kouzlo; stále může selhat při generování odpovědi, pokud je vstup příliš složitý nebo je překročeno kontextové okno. Pochopte, že 'uncensored' se vztahuje k politice obsahu, nikoli k technické spolehlivosti.
Omezení obsahu
- Žádný obsah s sexualitou za účasti nezletilých.
- Právní obsah pro dospělé je povolen.
- Technické chyby mohou stále způsobit odmítnutí.
Tento rozdíl je důležitý pro aplikace, které musí zvládat širokou škálu témat. Znalost konkrétního limitu vám pomůže správně navrhnout logiku filtrování.
Ladění chyb 400 vs 429
Chyby 400 signalizují problém s samotným požadavkem, jako je neplatný JSON, chybějící povinná pole nebo překročení limitu velikosti těla požadavku na 8 MB. Chyby 429 signalizují, že jste překročili limit rychlosti 300 požadavků za minutu. Rozlišení těchto chyb vám pomůže rychle opravit správný problém.
Pro chyby 400 zkontrolujte payload požadavku a schéma. Pro chyby 429 implementujte backoff a snižte souběžnost. Pokud obdržíte chybu 400 se zprávou o velikosti těla požadavku, ujistěte se, že neposíláte příliš mnoho dat v jednom požadavku. Limit 8 MB je přísný.
Kódy chyb
| Kód chyby | Význam |
|---|---|
| 400 | Nesprávný požadavek |
| 429 | Překročen limit rychlosti |
Zaznamenávání těchto chyb s jejich kontextem (payload, časové razítko) usnadňuje ladění. Použijte tato data k optimalizaci integrace a vyhněte se opakovaným selháním.
Další kroky pro optimalizaci Heretic LLM
Optimalizace začíná sledováním spotřeby tokenů a míry chyb. Použijte data o tokenech z posledního bloku SSE pro sledování skutečné spotřeby. Porovnejte to s odhadovanými náklady a zajistěte přesnost. Upravte strategie konkurence a omezení rychlosti na základě pozorovaných vzorců používání.
Zvažte použití nižší teploty pro konzistentnější výstup JSON nebo volání funkcí. Pokud potřebujete kreativnější odpovědi, zvýšte teplotu, ale počítejte s vyšším výskytem chyb při parsování. Experimentujte s různými parametry a najděte správnou rovnováhu pro váš případ použití.
Tipy pro optimalizaci
- Sledujte využití tokenů úzce.
- Upravte teplotu pro konzistenci versus kreativitu.
- Implementujte robustní zpracování chyb.
Začněte s bezplatným testem pro otestování vaší integrace. Toto je způsob s nízkým rizikem pro ověření, zda váš klientský kód správně zvládá streamování, režim JSON a limity rychlosti před zavázáním se k předplacenému kreditu.
