የ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 ፐርሰንታይሎችን ይገምግሙ። አማካዮች በእውነተኛ ተጠቃሚ ላይ ያለውን ተጽዕኖ ሊደብቁ ይችላሉ።

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

Service Health ባህሪው መቼ እንደተቀየረ ያሳያል። የአጠቃቀም ውሂብ ለምን እንደሆነ ለማብራራት ይረዳል።

በአጠቃቀም ዳሽቦርድ ውስጥ፣ በService Health Dashboard እይታዎ ጋር ተዛማጅ ውሂብን እያዩ መሆኑን ለማረጋገጥ የሚከተለውን ያድርጉ፦

• ወደ ተመሳሳይ ፕሮጀክት እና ሞዴል ያጣሩ።

• ካስፈለገ በአገልግሎት ደረጃ ይመድቡ።

• በመዘግየት ላይ በጣም ተጽዕኖ በሚያሳድሩ የውጤት token-ዎች ላይ ያተኩሩ።

ለጥልቅ ትንተና፣ Activity Data ወደ ውጭ ያውጡ እና በጊዜ ሂደት ውስጥ በየጥያቄው ያሉ token-ዎችን ይመርምሩ።

7. ለድጋፍ ቡድኑ ምን መላክ እንዳለብዎት (ካስፈለገ)

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

• ችግሩ ያጋጠማቸው Org IDዎች (አስፈላጊ)

• ችግሩ ያጋጠማቸው endpoints፣ ለምሳሌ Chat Completions ወይም Responses (አስፈላጊ)

• ችግሩ ያጋጠማቸው ሞዴሎች (አስፈላጊ)

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

• ለመዘግየት ወይም ለስህተቶች የጊዜ ክልሎችን ከሰዓት ሰቅ ጋር (አስፈላጊ)

• ካሉ፣ ተዛማጅ x-request-id ወይም X-Client-Request-Id

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

የሚገኙ ከሆነ፣ እነዚህንም ያካትቱ፦

• ከጥያቄዎቹ ጋር የተያያዘ Project 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 ደግሞ ባህሪው መቼ እንደተቀየረ ያሳያል።