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

አስፈላጊ አገናኞች

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

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

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

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

• ሁሉም ፕሮጀክቶች

• ያለፉት 30 ቀናት

• የሰዓት ጥራት

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

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

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

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

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

ለምን፦

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

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

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

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

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

ከአንድ በላይ ደረጃ ከተጠቀሙ (standard፣ priority፣ scale)፣ ሁልጊዜ ወደሚመረምሩት ደረጃ ያጣሩ።

ለምን፦

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

• Priority እና scale ደረጃዎች የተገለጹ SLA-ዎች አሏቸው

• ደረጃዎችን መቀላቀል የተከፈለበት ደረጃ አፈጻጸምን ያደበዝዛል

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

በፕሮጀክት ያጣሩ

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

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

ለምን፦

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

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

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

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

የHTTP Requests እይታን ይጠቀሙ

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

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

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

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

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

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

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

ስህተቶች ከService Health ሲጠፉ

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

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

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

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

መዘግየትን መላ መፈለግ

የመዘግየት ትንተና በተገለጹ SLA-ዎች ባሏቸው priority እና scale ደረጃዎች ላይ በጣም ትርጉም ያለው ነው። መደበኛ ደረጃ የበለጠ ሰፊ የመዘግየት ልዩነት ሊያሳይ ይችላል፣ እና የተረጋገጠ መዘግየት የለውም።

ቁልፍ መለኪያዎች

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

• 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-ዎች (አስፈላጊ)

• የተጎዱ መጨረሻ ነጥቦች፣ ለምሳሌ Chat Completions ወይም Responses (አስፈላጊ)

• የተጎዱ ሞዴሎች (አስፈላጊ)

• ይህ በScale ወይም Priority ደረጃ ላይ መሆኑን (አስፈላጊ)

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

• ተዛማጅ 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 ፐርሰንታይሎች።

Priority ወይም የመመዘኛ ደረጃ ዘገምተኛ ይመስላል

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

ያረጋግጡ፦

• ማጣሪያዎች በአንድ ደረጃ እና ሞዴል ብቻ የተገደቡ ናቸው።

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

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

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

ያረጋግጡ፦

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

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

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

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

ያረጋግጡ፦

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

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

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

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

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

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

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

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