የAPI ስህተቶችን እና ሌተንሲን መፍታት

አስፈላጊ አገናኞች

• የአገልግሎት ጤና ዳሽቦርድ (በአሁኑ ጊዜ ለEnterprise API ደንበኞች ብቻ ይገኛል)

• የአጠቃቀም ዳሽቦርድ

በትክክለኛ ነባሪዎች ይጀምሩ

የአገልግሎት ጤና ዳሽቦርድን ሲከፍቱ፣ ነባሪው ይህ ነው፦

• ሁሉም ፕሮጀክቶች

• ያለፉት 30 ቀናት

• የሰዓት ጥራት

ይህ እይታ ለአቅጣጫ ማወቂያ ብቻ ጠቃሚ ነው። ትርጉም ያለው መላ መፈለግ ሁልጊዜ ማጣራትን ይፈልጋል።

ከመመርመርዎ በፊት ያጣሩ

ትክክለኛ ማጣራት ከሁሉም በላይ አስፈላጊው ደረጃ ነው። አብዛኞቹ የተሳሳቱ ትርጓሜዎች ሞዴሎችን፣ ደረጃዎችን ወይም ፕሮጀክቶችን ከመቀላቀል ይመጣሉ።

በሞዴል ያጣሩ (አንድ በአንድ)

ሁልጊዜ ወደ አንድ ሞዴል ያጣሩ።

ለምን፦

• በዝቅተኛ ትራፊክ ሞዴሎች ላይ ያሉ ችግሮች በከፍተኛ መጠን ትራፊክ ሊደበቁ ይችላሉ

• ከፍተኛ መጠን ያላቸው ሞዴሎች አካባቢያዊ ችግሮችን ዓለም አቀፍ እንዲመስሉ ሊያደርጉ ይችላሉ

• የተለያዩ ሞዴሎች የተለያዩ የአፈጻጸም ግቦች አሏቸው

ማስታወሻ፦ ብዙ ሞዴሎችን መምረጥ ያዋህዳቸዋል—በመካከላቸው አይቀያይርም።

በአገልግሎት ደረጃ ያጣሩ

ከአንድ በላይ ደረጃዎችን (መደበኛ፣ ፈጣን ሁነታ (ቀደም ሲል Priority processing)፣ የመመዘኛ ደረጃ) የሚጠቀሙ ከሆነ፣ ሁልጊዜ ለሚመረምሩት ደረጃ ብቻ ያጣሩ።

ምክንያቱ፦

• ደረጃዎቹ የተለያዩ የአፈጻጸም ባህሪያት አሏቸው

• ፈጣን ሁነታ እና የመመዘኛ ደረጃ የተወሰኑ SLAዎች አሏቸው

• ደረጃዎችን መቀላቀል የሚከፈልበትን ደረጃ አፈጻጸም ይሸፍናል

ይህ በተለይ ለመዘግየት ትንታኔ አስፈላጊ ነው።

ለነባር ሞዴሎች፣ የፈጣን ሁነታ ትራፊክ አሁንም በUsage ዳሽቦርድ ላይ priority ተብሎ ይታያል።

በፕሮጀክት ያጣሩ

በነባሪነት፣ Service Health ሁሉንም ፕሮጀክቶች ያሳያል።

ለመላ መፈለግ፣ ችግሩ ወደተስተዋለበት ፕሮጀክት(ፕሮጀክቶች) ያጣሩ።

ለምን፦

• አንድ ከፍተኛ መጠን ያለው ፕሮጀክት መለኪያዎችን ሊቆጣጠር ይችላል።

• ትናንሽ የተጎዱ ፕሮጀክቶች ባልተዛመደ ትራፊክ ሊሸፈኑ ይችላሉ።

ችግሩ በእውነት በድርጅቱ ሁሉ የተስፋፋ ነው ብለው ካመኑ ብቻ "ሁሉም ፕሮጀክቶች" ተመርጦ ይቆይ።

ስህተቶችን መላ መፈለግ

የHTTP Requests እይታን ይጠቀሙ

ስህተቶችን ለመመርመር፦

1. በሞዴል እና በአገልግሎት ደረጃ ያጣሩ።

2. ከUptime ትር ይልቅ የHTTP Requests ትርን ይክፈቱ።

ይህ እይታ ጠቅላላ ጥያቄዎችን እና የስህተት ቆጠራዎችን በHTTP ሁኔታ ኮድ ያሳያል። ዝርዝር ድንገተኛ ጭማሪዎችን ወይም ለውጦችን ለመለየት ወደ የደቂቃ ደረጃ ጥራት ያጉሉ።

ቆጠራዎችን ሳይሆን የስህተት መጠኖችን ይተርጉሙ

በማንኛውም የምርት ስርዓት ውስጥ አንዳንድ ስህተቶች ይጠበቃሉ። በጥሬ ጠቅላላዎች ሳይሆን በስህተት መቶኛ ላይ ያተኩሩ።

ጠቅላላ መጠንዎ በበዛ መጠን፣ የስህተት መጠኑ እጅግ ዝቅተኛ ቢሆንም የስህተቶች ብዛት የመሆን እድሉ ይበዛል።

ስህተቶች ከService Health ሲጠፉ

በደንበኛ በኩል ስህተቶችን ቢያዩ ነገር ግን በService Health ውስጥ ተዛማጅ ውሂብ ከሌለ፦

• ጥያቄዎቹ ምናልባት OpenAI አልደረሱም።

• ችግሩ ብዙውን ጊዜ upstream ነው (ጊዜ ማብቂያዎች፣ ፕሮክሲዎች፣ ኔትወርኪንግ)።

ይህ ጠንካራ የደንበኛ-ጎን ጊዜ ማብቂያዎች ሲኖሩ የተለመደ ነው።

የመዘግየት ችግር መላ መፈለግ

የመዘግየት ትንታኔ የተወሰኑ SLAዎች ባሏቸው ፈጣን ሁነታ እና የመመዘኛ ደረጃ ላይ የበለጠ ትርጉም አለው። መደበኛው ደረጃ ሰፋ ያለ የመዘግየት ልዩነት ሊያሳይ ይችላል፤ የተረጋገጠ የመዘግየት ጊዜም የለውም።

ቁልፍ መለኪያዎች

እያንዳንዱን መለኪያ ለማየት ተዛማጅ ትሩን ጠቅ ያድርጉ፦

• Token Velocity፦ በሰከንድ የሚመነጩ token-ዎች፤ ከእርምጃ መጠን ገለልተኛ ነው።

• Request Time፦ ጠቅላላ የጥያቄ ቆይታ፤ በውጤት መጠን እና በማመዛዘን በእጅጉ ይጎዳል።

• Time to First Token (TTFT)፦ የመጀመሪያው token እስኪመነጭ ያለው ጊዜ፤ በcache ያልተቀመጠ የግብዓት እርምጃ መጠን እና በማመዛዘን በእጅጉ ይጎዳል።

ሁልጊዜ P50 / P75 / P95 ፐርሰንታይሎችን ይገምግሙ። አማካዮች በእውነተኛ ተጠቃሚ ላይ ያለውን ተጽዕኖ ሊደብቁ ይችላሉ።

የምላሽ መዘግየትን ከtoken አጠቃቀም ጋር ማዛመድ

የአገልግሎት ሁኔታ ክፍል የአሠራር ለውጥ መቼ እንደተከሰተ ያሳያል። የአጠቃቀም ውሂብ ደግሞ ለምን እንደተከሰተ ለማብራራት ይረዳል።

በአጠቃቀም ዳሽቦርድ ውስጥ የሚያዩት ውሂብ በአገልግሎት ሁኔታ ዳሽቦርድ ላይ ከሚያዩት ጋር የሚዛመድ መሆኑን ለማረጋገጥ፣ የሚከተሉትን ያድርጉ፦

• ተመሳሳይ ፕሮጀክትና ሞዴል እንዲታዩ ያጣሩ።

• አግባብነት ካለው፣ በአገልግሎት ደረጃ ይመድቡ።

• በምላሽ መዘግየት ላይ ከፍተኛውን ተጽዕኖ በሚያሳድሩት የውጤት tokenዎች ላይ ያተኩሩ።

ለጥልቅ ትንተና፣ የእንቅስቃሴ ውሂብን ወደ ውጭ ይላኩና በእያንዳንዱ ጥያቄ ያለውን የtoken ብዛት በጊዜ ሂደት ይመርምሩ።

ለድጋፍ ቡድኑ ማጋራት ያለብዎት መረጃ (ካስፈለገ)

የድጋፍ ቡድኑን ሲያነጋግሩ፣ የሚከተሉትን ያካትቱ፦

• ችግሩ የተከሰተባቸው ድርጅቶች መለያዎች (አስፈላጊ)

• ችግሩ የተከሰተባቸው የመጨረሻ ነጥቦች፣ ለምሳሌ Chat Completions ወይም Responses (አስፈላጊ)

• ችግሩ የተከሰተባቸው ሞዴሎች (አስፈላጊ)

• ችግሩ በፈጣን ሁነታ ወይም በየመመዘኛ ደረጃ ላይ መከሰቱን (አስፈላጊ)

• የምላሽ መዘግየት ወይም ስህተቶች የተከሰቱባቸው የጊዜ ክልሎች፣ ከሰዓት ሰቅ ጋር (አስፈላጊ)

• ካለ፣ ከችግሩ ጋር የተያያዘ x-request-id ወይም X-Client-Request-Id

• ለሚያቀርቧቸው ጥያቄዎች የተመዘገቡ ጊዜያት ከሰዓት ሰቅ ጋር፣ ወይም ቢያንስ ቀኑ

ካሉ፣ የሚከተሉትንም ያካትቱ፦

• ከጥያቄዎቹ ጋር የተያያዘ የፕሮጀክት መለያ

• ችግሩ የውሂብ ነዋሪነት በሚመለከታቸው ጥያቄዎች ላይ መከሰቱን፣ እና በየትኞቹ ላይ እንደተከሰተ

• እያዩ ስላሉት አዝማሚያዎች ማብራሪያ

እንደ ችግሩ አይነት፣ የሚከተሉትን ያካትቱ፦

• ስህተቶች፦ ያልተሳኩ ወይም ስህተት የሚመልሱ ጥያቄዎች ግምታዊ መቶኛ፣ የምላሽ ኮዶች፣ የስህተት መልዕክቶች፣ እና የስህተት ምላሹን ለመቀበል የፈጀው ጊዜ።

• የምላሽ መዘግየት፦ ችግሩ የታየባቸው ፐርሰንታይሎች (P50 / P90 / P95 / P99)፣ ከደንበኛው መደበኛ የምላሽ ጊዜ አንጻር ምን ያህል እንደጨመሩ፣ እንዲሁም የላኩባቸውና ምላሽ የተቀበሉባቸው ጊዜያት የተመዘገቡላቸው የዘገዩ ጥያቄዎች ምሳሌዎች።

• ሁለቱም፦ የስህተት ወይም የምላሽ መዘግየት ውሂብ የሚያሳዩ የማያ ገጽ ቅጂዎች ወይም ሰንጠረዥ፣ እንዲሁም የስህተት መጠን ወይም የምላሽ መዘግየት ከሚጠበቀው በላይ እንደሆነ እንዴት እንዳረጋገጡ።

የተለመዱ የመላ መፈለግ ሁኔታዎች

ጊዜ ማብቂያዎች ይከሰታሉ ግን Service Health መደበኛ ይመስላል

ሊሆን የሚችል ምክንያት፦ ጥያቄዎች OpenAI ከመድረሳቸው በፊት ጊዜያቸው ያልቃል።

ያረጋግጡ፦

• የደንበኛ ወይም የፕሮክሲ ጊዜ ማብቂያ ቅንብሮች

• የአካባቢ ኔትወርክ ወይም የload balancer ለውጦች

• በService Health ዳሽቦርድ ውስጥ የ499 ስህተቶች መኖር (እነዚህ በራስዎ ስርዓቶች ውስጥ እንደ 5xx ስህተቶች ሊታዩ ይችላሉ)።

ምንም ስምሪት ሳይኖር መዘግየት ጨመረ

ሊሆን የሚችል ምክንያት፦ የውጤት token መጠን ወይም የማመዛዘን አጠቃቀም ጨምሯል እና/ወይም ትራፊክ በአገልግሎት ደረጃዎች መካከል ተቀይሯል።

ያረጋግጡ፦

• በየጥያቄው አማካይ የውጤት token-ዎች በአጠቃቀም ዳሽቦርድ ውስጥ (ውሂብን ማውረድ እና የውጤት token-ዎችን በጠቅላላ ጥያቄዎች መካፈል ያስፈልጋል)።

• በአገልግሎት ጤና ዳሽቦርድ ውስጥ የRequest Time እና TTFT ፐርሰንታይሎች።

ፈጣን ሁነታ ወይም የመመዘኛ ደረጃ የዘገየ ይመስላል

ሊሆን የሚችል ምክንያት፦ የተለያዩ ደረጃዎች መለኪያዎች ተቀላቅለዋል፤ ይህም የመደበኛው ደረጃ ትራፊክ የሚከፈልበትን ደረጃ አፈጻጸም እንዲሸፍን ያደርጋል።

ያረጋግጡ፦

• ማጣሪያዎቹ በአንድ ደረጃና ሞዴል ብቻ መገደባቸውን።

• በደረጃዎች መካከል የtoken ፍጥነት ንጽጽር።

በ5XX ስህተቶች ውስጥ ድንገተኛ ጭማሪ

ሊሆን የሚችል ምክንያት፦ በትራፊክ ትንሽ መቶኛ ላይ ተጽዕኖ የሚያሳድሩ ጊዜያዊ ውድቀቶች።

ያረጋግጡ፦

• የስህተት መጠን መቶኛ

• የትራፊክ መጠን በተመሳሳይ ጊዜ ተቀይሯል ወይስ አልተቀየረም

ችግሩ አንድ ፕሮጀክት ብቻ ይጎዳል

ሊሆን የሚችል ምክንያት፦ ለፕሮጀክት የተለየ ውቅር ወይም የአጠቃቀም ንድፍ።

ያረጋግጡ፦

• በፕሮጀክት ደረጃ ማጣራት

• ካልተጎዱ ፕሮጀክቶች ጋር ንጽጽር

የመጨረሻ ቁልፍ ነጥቦች

• መለኪያዎችን ከመተርጎምዎ በፊት አስፈላጊ በሆነበት ቦታ በሞዴል፣ በደረጃ እና በፕሮጀክት ያጣሩ።

• ለመዘግየት ትንተና አማካዮችን ሳይሆን ፐርሰንታይሎችን ይጠቀሙ።

• ትናንሽ የስህተት መጠኖች የሚጠበቁ ናቸው።

• ውሂብ መጥፋት ብዙውን ጊዜ የupstream ችግሮችን ያመለክታል።

• የአጠቃቀም ውሂብ መዘግየት ለምን እንደተቀየረ ለማብራራት ሊረዳ ይችላል፤ Service Health ደግሞ ባህሪው መቼ እንደተቀየረ ያሳያል።