Viktiga punkter
- Context windows combine prompt and completion, so long histories drain limits faster than expected.
- Streaming kräver att man hanterar SSE-händelser noggrant för att undvika korrupt JSON eller förlorade tokens.
- JSON mode demands strict schema adherence; malformed responses cause silent parsing failures.
- Förbetalt kryptobetalning innebär att fel är gratis, men räkningen av tokens måste vara exakt för att undvika överraskningar.
Varför din API-nyckel kan nekas
API-nycklar avslås när klienten skickar felaktiga rubriker eller överskrider gränsen för begärans brödtext. Servern validerar autentiseringsrubriken innan någon logik bearbetas. Om rubriken saknas eller innehåller extra mellanslag, misslyckas begäran omedelbart.
En annan vanlig orsak är att skicka en payload som överskrider gränsen för kroppens storlek på 8 MB. Stora kontextfönster med många meddelanden kan lätt överskrida denna tröskel. Kontrollera längden på din meddelandearray och tokenantal innan du skickar.
- Se till att Authorization-huvudet använder prefixet 'Bearer' korrekt.
- Verify the request body size stays under 8 MB.
- Kontrollera att API-nyckeln är aktiv och inte har gått ut.
Förståelse för kontextfönstrets begränsningar
Kontextfönstret inkluderar både inmatningsprompten och den genererade slutförandet. Vårt API stöder ett fönster på 100,000 tokens, men du måste ta hänsyn till båda sidorna. Om du skickar 80,000 tokens av kontext har du bara 20,000 kvar för svaret.
De flesta modeller har en liten utmatningsgräns som standard om du inte anger max_tokens. Detta kan oväntat klippa av långa svar. Ange max_tokens till den längd du vill ha endast om du vill ha en gräns. Kom ihåg att gränsen gäller för hela begäran, inte bara för prompten.
Hantering av strömningsavbrott korrekt
Streaming via Server-Sent Events (SSE) kräver robust felhantering. Om anslutningen bryts kan du förlora den sista token eller användningsmetadata. Buffra alltid inkommande bitar och återställ hela svaret på klienten.
Tokenanvändningsdata skickas vanligtvis i den sista delen av strömmen. Om du avslutar anslutningen i förtid kan du missa det exakta tokenantalet. Detta påverkar faktureringsnoggrannheten i förbetalsystem. Implementera en återförsöksmekanism med exponentiell backoff för att hantera tillfälliga nätverksproblem.
Använd en dedikerad strömningsklient som hanterar SSE-parsing automatiskt. Detta minskar risken för parseringsfel och säkerställer att du fångar all data.
JSON-lägets tolkningsfel
När du använder response_format: {"type": "json_object"} måste modellen returnera giltig JSON. Avvikelser leder till parserfel i din applikation. Se till att din prompt uttryckligen instruerar modellen att endast returnera JSON.
Ibland inkluderar modellen markdown-kodblock runt JSON:et, vilket bryter strikt parser. Ta bort -omslutningar innan parsing. Validera också JSON-strukturen på klienten innan du använder data.
Använd ett bibliotek för schemavalidering för att fånga fel tidigt. Detta förhindrar krascher när modellen returnerar oväntade nycklar eller typer.
Överraskningar vid tokenräkning och fakturering
Förbetald fakturering tar bara betalt för faktisk tokenanvändning. Fel och avslag är gratis, vilket är en betydande fördel jämfört med prenumerationer. Tokenräkning kan dock vara knepigt om du inte tar hänsyn till hela kontexten.
Varje meddelande i konversationshistoriken räknas mot gränsen för inmatningstokens. Långa konversationer tömmer ditt förbetala konto snabbare än du kanske tror. Övervaka din användning regelbundet för att undvika att ta slut på krediter mitt i en session.
Ställ in aviseringar för låga kreditbalanser. Detta säkerställer att du kan ladda upp innan dina förfrågningar misslyckas. Kom ihåg att krediter aldrig går ut, så du kan ladda upp när det passar dig.
Undvika mjuka avslag i NSFW-frågor
Mjuka avslag uppstår när modellen tvekar eller ger ett ofullständigt svar istället för ett direkt svar. Detta händer ofta vid kontroversiella eller vuxenämnen. Även i en ocensurerad modell kan vissa utlösare orsaka tvekan.
Justera temperature-parametern för att minska slumpmässigheten. En lägre temperatur gör modellen mer deterministisk och mindre benägen att tveka. Se också till att din prompt är tydlig och direkt. Undvik tvetydigt språk som kan förvirra modellen.
Om du stöter på frekventa mjuka avvisningar, försök att formulera om frågan lite. Små ändringar i formuleringen kan ofta kringgå tvekan och ge ett direkt svar.
Toppning av rate limits och backoff-strategier
API:et tillåter 300 anrop per minut och 8 samtidiga anrop per nyckel. Trafiktoppar kan snabbt nå dessa gränser. Implementera exponentiell backoff för att hantera rate limit-fel på ett smidigt sätt.
När du får en 429-statuskod, vänta innan du försöker igen. Börja med en kort fördröjning och öka den vid varje försök. Detta förhindrar att servern överbelastas under toppbelastningstider.
Övervaka din begäranderate och justera dina koncurrentsnivåer därefter. Om du gör många samtidiga begäranden, överväg att sprida ut dem över tid. Detta säkerställer stadig genomströmning utan att nå gränserna.
Strukturer för funktionssamplingspayloads
Funktionssamling kräver en specifik laststruktur. Definiera dina funktioner i tools-parametern och ange tool_choice. Modellen returnerar ett funktionsanrop om den bedömer att det är ett lämpligt svar.
Säkerställ att dina funktionsdefinitioner är korrekta och kompletta. Saknade parametrar eller felaktiga typer kan få modellen att generera ogiltiga anrop. Kontrollera alltid funktionsanropsargumenten innan du utför dem.
Använd parametern tool_choice för att styra när modellen anropar funktioner. Du kan tvinga fram ett funktionsanrop, låta modellen bestämma eller inaktivera funktionsanrop helt och hållet. Detta ger dig finjusterad kontroll över modellens beteende.
Felsökning av 400- och 500-fel
400-fel indikerar problem på klient-sidan, såsom ogiltig JSON eller saknade parametrar. 500-fel tyder på problem på server-sidan, som interna fel eller tidsgränser. Att skilja på de två hjälper dig att felsöka snabbare.
För 400-fel, kontrollera felmeddelandet som anges i svaret. Det pekar vanligtvis direkt på problemet. För 500-fel, försök igen efter en kort fördröjning. Om felet kvarstår, kontakta support med begärande-ID:t.
Logga både begärans- och svarsdetaljer för varje fel. Detta hjälper till att identifiera mönster och återkommande problem. Använd en loggningstjänst för att spåra fel över tid och förbättra din API-integration.
