Sammanfattning
- Streaming-responder kräver robust SSE-parsing för att hantera ofullständiga delar och slutlig tokenanvändningsdata.
- JSON-lägesfel beror vanligtvis på att modellen genererar efterföljande text utanför det strikta JSON-schemat.
- 100k kontextfönstret delas mellan prompt och slutförande, så långa utdata minskar tillgängligt inmatningsutrymme.
- Kostnadsberäkningen måste ta hänsyn till att utmatningstokens är dyrare än inmatningstokens.
Varför ditt streaming-svar hänger sig
Strömsvar fastnar när klienten misslyckas med att läsa den sista Server-Sent Event (SSE)-delen som innehåller data om tokenanvändning. Vårt API strömmar tokens när de genereras, men anslutningen stängs helt först när den sista delen anländer. Om din klientkod kopplar ner sig tidigt eller ignorerar den sista delen förlorar du exakta tokenantal som behövs för faktureringsverifiering.
Läs varje chunk tills strömmen avslutas. Anta inte att den sista chunken endast innehåller den sista tokenen. Den sista chunken i vår SSE-ström innehåller usage fält med totala inmatnings- och utmatningstokens. Om du ignorerar denna data kan du inte spåra ditt förbetala kreditförbrukning.
Vanliga fallgropar
- Att ignorera den sista SSE-händelsen.
- Timeouts som satts för lågt för långa slutföranden.
- Hanterar inte delvis JSON i streamingläge.
Konsumera alltid hela strömmen för att säkerställa att servern vet att klienten har mottagit hela svaret. Detta förhindrar resursläckor på vår sida och säkerställer att du har datan som behövs för dina egna loggar.
Hantera JSON-lägesfel i produktion
JSON-lägesfel uppstår eftersom modellen kan generera text efter den slutliga klamern, vilket bryter mot strikta JSON-parningsregler. När du ställer in response_format för {"type": "json_object", försöker modellen att returnera giltig JSON, men den lägger ofta till konversationell fyllnadsmaterial som 'Här är datan:' efter den slutgiltiga parentesen. Din parser kraschar sedan på den extra texten.
Ta bort efterföljande text efter den sista giltiga slutgiltiga klamren. Lita inte på att modellen slutar exakt i slutet av JSON-strukturen. Du måste implementera ett efterbehandlingssteg för att hitta den sista '}' eller ']' och kasta allt efter det. Detta är kritiskt vid parsning av arrayer eller nästlade objekt.
Bästa praxis
- Använd ett regex för att extrahera den sista giltiga JSON-blocket.
- Validera den extraherade strängen med en JSON-parser.
- Försök igen med lägre temperatur om utdata är kaotisk.
Denna metod säkerställer att din produktionspipeline förblir stabil även när modellen bestämmer sig för att vara pratvill. Uncensored-modeller är mindre begränsade, så de kan upplevas som mer 'kreativa' med sin formatering.
Att förstå begränsningar för kontextfönster
Kontextrutans gräns är 100 000 token för den kombinerade prompten och completionen. Det betyder att om din input är 50 000 token kan du bara generera upp till 50 000 token innan du träffar gränsen. Gränsen gäller inte bara för input; det är en delad budget för hela begäran.
Beräkna ditt tillgängliga utmatningsutrymme genom att subtrahera antalet inmatningstokens från 100 000. Om du skickar en stor systemprompt eller en lång historik av meddelanden minskar ditt tillgängliga utmatningsutrymme därefter. Detta är avgörande för applikationer som upprätthåller långa konversationshistoriker.
Beräkningsexempel
- Total fönsterstorlek: 100 000 token.
- Ingångstokens: 20 000 tokens.
- Max utdata: 80,000 tokens.
Om du överskrider denna gräns returnerar API:t ett fel. Övervaka din tokenanvändning noga för att undvika oväntad beskärning av modellens svar. Modellen beskär inte automatiskt; den avvisar helt enkelt förfrågan om totalen överstiger fönstret.
Tokenräkning och kostnadsuppskattning
Kostnadsberäkningen måste ta hänsun till pris skillnaden mellan in- och utmatningstokens. Inmatningstokens kostar 0,15 $ per 1M tokens, medan utmatningstokens kostar 0,50 $ per 1M tokens. Utmatningstokens är betydligt dyrare, så att generera långa svar ökar dina kostnader snabbare än att skicka långa prompts.
Uppskatta dina kostnader genom att multiplicera det förväntade antalet tokens med respektive pris. Till exempel skulle 10 000 inmatningstokens och 5 000 utmatningstokens kosta: (10 000/1 000 000 * $0,15) + (5 000/1 000 000 * $0,50). Detta är lika med $0,0015 + $0,0025 = $0,004 per anrop.
Pristabell
| Tocken typ | Pris per 1M Tokens |
|---|---|
| Input | $0.15 |
| Utdata | $0.50 |
Spåra din användning via den sista SSE-chunken eller API:s svar. Detta säkerställer att du kan budgetera noggrant för applikationer med hög volym. Förbetalt kredit utlöper aldrig, så du kan planera dina utgifter över tid utan månadskostnader.
Begäransgräns: 300 RPM förklarat
Begäransgränsen begränsar dina begäranden till 300 per minut per API-nyckel. Denna gräns gäller för alla begäranden, oavsett payload-storlek eller antal tokens. Om du överskrider denna gräns returnerar API:t ett 429-fel. Du måste implementera exponentiell backoff för att hantera dessa fel på ett skonsamt sätt.
Övervaka din begärantakt och justera din konkurrenskapacitet därefter. Om du använder flera trådar eller processer, se till att de delar samma API-nyckel och tillsammans håller sig under gränsen på 300 begäranden per minut. Att överskrida denna gräns leder till tillfälliga fel tills hastigheten återställs.
Hantera 429-fel
- Implementera exponentiell backoff.
- Logga misslyckade begäranden för analys.
- Minska koncurrentsen om gränserna är frekventa.
Vårt API är utformat för högvolymeanvändning, men hastighetsbegränsningen säkerställer rättvis användning för alla klienter. Om du behöver högre gränser kan du generera en ny API-nyckel, men observera att varje konto är begränsat till en aktiv nyckel i taget.
Felsökning av funktionsanropssvikt
Funktionsanropsfel uppstår när modellens verktygsdefinition inte matchar det förväntade schemat eller när modellen misslyckas med att returnera giltig JSON för verktygsargumenten. Se till att dina verktygsdefinitioner är exakta och innehåller alla obligatoriska parametrar. Tvetydiga scheman leder till felaktiga verktygsanrop.
Validera verktygsargumenten innan du exekverar funktionen. Modellen kan generera argument som saknar obligatoriska fält eller innehåller felaktiga typer. Din klientkod bör hantera dessa fel genom att försöka igen med en tydligare prompt eller justera verktygsdefinitionen.
Felsökningssteg
- Kontrollera verktygsdefinitionssyntax.
- Validera argumenttyper och värden.
- Granska modellens output för saknade fält.
Funktionsanrop är en kraftfull funktion, men det kräver noggrann schemadesign. Ofiltrerade modeller kan vara mindre konsekventa med verktygsdefinitioner än sina filtrerade motsvarigheter, så rigorös validering är avgörande.
Varför 'uncensored' inte är helt obegränsat
Etiketten 'uncensored' betyder att modellen inte vägrar lagligt vuxet, fiktivt eller kontroversiellt innehåll, men den har fortfarande en hård gräns för sexuellt innehåll som involverar minderåriga. Detta är den enda hårda innehållsbegränsningen som alltid gäller. Begäranden som innehåller sådant innehåll kommer att avvisas, även om resten av prompten är helt giltig.
Andra avslag kan fortfarande förekomma på grund av tekniska fel eller hastighetsbegränsningar. Modellen är inte magisk; den kan fortfarande misslyckas med att generera ett svar om inmatningen är för komplex eller kontextfönstret överskrids. Förstå att 'obegränsad' syftar på innehållspolitik, inte teknisk tillförlitlighet.
Innehållsbegränsningar
- Inget sexuellt innehåll som involverar minderåriga.
- Lagligt vuxet innehåll är tillåtet.
- Tekniska fel kan fortfarande orsaka avslag.
Denna distinktion är viktig för applikationer som behöver hantera ett brett spektrum av ämnen. Att känna till den specifika gränsen hjälper dig att designa din filterlogik korrekt.
Felsökning av 400- vs 429-fel
400-fel indikerar ett problem med begäran i sig, såsom ogiltig JSON, saknade obligatoriska fält eller att gränsen för begärans kropp på 8 MB överskrids. 429-fel indikerar att du har överskridit hastighetsbegränsningen på 300 begäranden per minut. Att skilja på dessa fel hjälper dig att åtgärda rätt problem snabbt.
För 400-fel, kontrollera din förfrågan och schema. För 429-fel, implementera backoff och minska koncurrenten. Om du får ett 400-fel med ett meddelande om storleken på förfrågan, se till att du inte skickar för mycket data i en enda förfrågan. 8 MB-gränsen är strikt.
Felskoder
| Felskod | Mening |
|---|---|
| 400 | Bad Request |
| 429 | Rate Limit överskridet |
Att logga dessa fel med deras kontext (payload, tidsstämpel) gör felsökning mycket enklare. Använd denna data för att optimera din integration och undvika upprepade fel.
Nästa steg för Heretic LLM-optimering
Optimeringen börjar med att övervaka din tokenanvändning och felrate. Använd tokendatan från den sista SSE-chunken för att spåra din faktiska förbrukning. Jämför detta med dina uppskattade kostnader för att säkerställa noggrannhet. Justera dina strategier för koncurrent och hastighetsbegränsning baserat på dina observerade användningsmönster.
Överväg att använda en lägre temperatur för mer konsekvent JSON-utdata eller funktionsanrop. Om du behöver mer kreativa svar, öka temperaturen men var beredd på fler parseringsfel. Experimentera med olika parametrar för att hitta rätt balans för ditt användningsområde.
Optimeringstips
- Övervaka tokenanvändningen noggrant.
- Justera temperatur för konsekvens jämfört med kreativitet.
- Implementera robust felhantering.
Börja med gratis provperiod för att testa din integration. Detta är ett lågrisk sätt att verifiera att din klientkod hanterar strömning, JSON-läge och hastighetsbegränsningar korrekt innan du förbinder dig till förbetald kredit.
