OpenAI
આ પેજનો અનુવાદ મશીન દ્વારા કરવામાં આવ્યો હતો. મૂળ અંગ્રેજી લેખ જુઓ.

API ભૂલો અને લેટન્સીનું ટ્રબલશૂટિંગ

આ લેખ OpenAI API નો ઉપયોગ કરતી વખતે સામાન્ય ભૂલો અને લેટન્સી સમસ્યાઓનું ટ્રબલશૂટિંગ કરવા માટે Service Health અને Usage ડેશબોર્ડ્સનો ઉપયોગ કેવી રીતે કરવો તે સમજાવે છે.

અપડેટ કર્યા તારીખ: 3 days ago

મહત્વપૂર્ણ લિંક્સ

યોગ્ય ડિફોલ્ટ્સથી શરૂઆત કરો

જ્યારે તમે સેવા આરોગ્ય ડેશબોર્ડ ખોલો છો, ત્યારે તે ડિફોલ્ટ રૂપે આ બતાવે છે:

  • બધા પ્રોજેક્ટ્સ

  • છેલ્લા 30 દિવસ

  • કલાકદીઠ રિઝોલ્યુશન

આ દૃશ્ય માત્ર દિશા સમજવા માટે ઉપયોગી છે. અર્થપૂર્ણ મુશ્કેલીનિવારણ માટે હંમેશાં ફિલ્ટરિંગ જરૂરી છે.

તપાસ પહેલાં ફિલ્ટર કરો

યોગ્ય ફિલ્ટરિંગ સૌથી મહત્વપૂર્ણ પગલું છે. મોટાભાગની ખોટી સમજ મોડલ, સ્તરો અથવા પ્રોજેક્ટ્સને મિક્સ કરવાથી થાય છે.

મોડલ મુજબ ફિલ્ટર કરો (એક સમયે એક)

હંમેશાં એક જ મોડલ સુધી ફિલ્ટર કરો.

શા માટે:

  • ઓછા ટ્રાફિકવાળા મોડલ પરની સમસ્યાઓ વધુ વોલ્યુમવાળા ટ્રાફિકથી છુપાઈ શકે છે

  • વધુ વોલ્યુમવાળા મોડલ સ્થાનિક સમસ્યાઓને વૈશ્વિક જેવી દેખાડી શકે છે

  • અલગ-અલગ મોડલના કામગીરી લક્ષ્યો અલગ હોય છે

નોંધ: અનેક મોડલ પસંદ કરવાથી તે એકત્રિત થાય છે—તે તેમની વચ્ચે સ્વિચ કરતું નથી.

સેવાના સ્તર મુજબ ફિલ્ટર કરો

જો તમે એકથી વધુ સ્તર વાપરો છો—માનક, ઝડપી મોડ (અગાઉ પ્રાથમિકતા પ્રક્રિયા) અથવા વ્યાપકતાનું સ્તર—તો હંમેશાં તમે જે સ્તરની તપાસ કરી રહ્યા હો તેના પર ફિલ્ટર કરો.

શા માટે:

  • દરેક સ્તરની કામગીરીની લાક્ષણિકતાઓ અલગ હોય છે

  • ઝડપી મોડ અને વ્યાપકતાનું સ્તર નિર્ધારિત SLA ધરાવે છે

  • સ્તરોને ભેળવવાથી સશુલ્ક સ્તરની કામગીરી સ્પષ્ટ દેખાતી નથી

વિલંબના વિશ્લેષણ માટે આ ખાસ મહત્વનું છે.

હાલના મોડલ માટે, ઝડપી મોડનો ટ્રાફિક હજી પણ વપરાશ ડૅશબોર્ડમાં priority તરીકે દેખાય છે.

પ્રોજેક્ટ મુજબ ફિલ્ટર કરો

ડિફોલ્ટ રૂપે, સેવા આરોગ્ય બધા પ્રોજેક્ટ્સ બતાવે છે.

મુશ્કેલીનિવારણ માટે, જ્યાં સમસ્યા જોવામાં આવી હતી તે પ્રોજેક્ટ(ઓ) સુધી ફિલ્ટર કરો.

શા માટે:

  • એક વધુ વોલ્યુમવાળો પ્રોજેક્ટ મેટ્રિક્સ પર પ્રભુત્વ મેળવી શકે છે.

  • અસરગ્રસ્ત નાના પ્રોજેક્ટ્સ અસંબંધિત ટ્રાફિકથી ઢંકાઈ શકે છે.

જો તમને લાગે કે સમસ્યા ખરેખર સમગ્ર સંસ્થામાં છે તો જ "બધા પ્રોજેક્ટ્સ" પસંદ રાખો.

ભૂલોનું મુશ્કેલીનિવારણ

HTTP વિનંતીઓનું દૃશ્ય વાપરો

ભૂલોની તપાસ કરવા માટે:

  1. મોડલ અને સેવાના સ્તર મુજબ ફિલ્ટર કરો.

  2. અપટાઇમ ટેબને બદલે HTTP વિનંતીઓ ટેબ ખોલો.

આ દૃશ્ય HTTP સ્થિતિ કોડ મુજબ કુલ વિનંતીઓ અને ભૂલની સંખ્યા બતાવે છે. સૂક્ષ્મ અચાનક વધારા અથવા ફેરફારો ઓળખવા માટે મિનિટ-સ્તરના રિઝોલ્યુશન સુધી ઝૂમ કરો.

ભૂલની સંખ્યા નહીં, દરોનું અર્થઘટન કરો

કોઈપણ પ્રોડક્શન સિસ્ટમમાં કેટલીક ભૂલો અપેક્ષિત હોય છે. કાચા કુલ આંકડા નહીં, ભૂલની ટકાવારી પર ધ્યાન આપો.

તમારું કુલ વોલ્યુમ જેટલું મોટું, અત્યંત ઓછા ભૂલ દર સાથે પણ સંભવિત ભૂલોની સંખ્યા એટલી મોટી.

જ્યારે સેવા આરોગ્યમાં ભૂલો ગુમ હોય

જો તમને ક્લાયંટ-સાઇડ ભૂલો દેખાય પરંતુ સેવા આરોગ્યમાં અનુરૂપ ડેટા ન હોય:

  • વિનંતીઓ કદાચ OpenAI સુધી પહોંચી નથી.

  • સમસ્યા સામાન્ય રીતે અપસ્ટ્રીમ હોય છે (ટાઇમઆઉટ્સ, પ્રોક્સીઓ, નેટવર્કિંગ).

આ આક્રમક ક્લાયંટ-સાઇડ ટાઇમઆઉટ્સ સાથે સામાન્ય છે.

વિલંબનું સમસ્યાનિવારણ

નિર્ધારિત SLA ધરાવતા ઝડપી મોડ અને વ્યાપકતાનું સ્તર પર વિલંબનું વિશ્લેષણ સૌથી વધુ અર્થપૂર્ણ છે. માનક સ્તરમાં વિલંબમાં વધુ ફેરફાર જોવા મળી શકે છે અને તેમાં વિલંબની કોઈ ખાતરી નથી.

મુખ્ય મેટ્રિક્સ

દરેક મેટ્રિક જોવા માટે સંબંધિત ટેબ પર ક્લિક કરો:

  • ટોકન વેગ: પ્રતિ સેકન્ડ જનરેટ થયેલા ટોકન; પ્રોમ્પ્ટ કદથી સ્વતંત્ર.

  • વિનંતી સમય: કુલ વિનંતી અવધિ; આઉટપુટ કદ અને રિઝનિંગથી ખૂબ પ્રભાવિત.

  • પ્રથમ ટોકન સુધીનો સમય (TTFT): પ્રથમ ટોકન જનરેટ થાય ત્યાં સુધીનો સમય; કૅશ ન થયેલા ઇનપુટ પ્રોમ્પ્ટ કદ અને રિઝનિંગથી ખૂબ પ્રભાવિત.

હંમેશાં P50 / P75 / P95 પર્સેન્ટાઇલ્સની સમીક્ષા કરો. સરેરાશો વાસ્તવિક વપરાશકર્તા પરની અસરને છુપાવી શકે છે.

વિલંબ અને ટોકન વપરાશ વચ્ચેનો સંબંધ સમજવો

સેવાની સ્થિતિ દર્શાવે છે કે કામગીરીમાં ફેરફાર ક્યારે થયો. વપરાશનો ડેટા આ ફેરફાર શા માટે થયો તે સમજવામાં મદદ કરે છે.

તમે સેવાની સ્થિતિના ડૅશબોર્ડમાં જોઈ રહ્યા છો તેને સંબંધિત ડેટા જ જોવા માટે, વપરાશના ડૅશબોર્ડમાં નીચે મુજબ કરો:

  • એ જ પ્રોજેક્ટ અને મોડલ માટે ફિલ્ટર કરો.

  • લાગુ પડતું હોય તો, સેવાના સ્તર મુજબ જૂથ બનાવો.

  • આઉટપુટ ટોકન પર ધ્યાન આપો, કારણ કે વિલંબ પર તેમની સૌથી વધુ અસર પડે છે.

વધુ ઊંડાણપૂર્વક વિશ્લેષણ કરવા માટે, પ્રવૃત્તિનો ડેટા નિકાસ કરો અને સમય જતાં દરેક વિનંતી દીઠ ટોકનની સંખ્યા તપાસો.

સહાય ટીમને શું જણાવવું (જરૂર પડે તો)

જો તમે સહાય ટીમનો સંપર્ક કરો, તો આ વિગતો આપો:

  • અસરગ્રસ્ત સંસ્થાઓના આઈડી (મહત્ત્વપૂર્ણ)

  • અસરગ્રસ્ત એન્ડપૉઇન્ટ, જેમ કે Chat Completions અથવા Responses (મહત્ત્વપૂર્ણ)

  • અસરગ્રસ્ત મોડલ (મહત્ત્વપૂર્ણ)

  • સમસ્યા ઝડપી મોડમાં છે કે વ્યાપકતાના સ્તરમાં (મહત્ત્વપૂર્ણ)

  • વિલંબ કે ભૂલો જોવા મળી હોય તે સમયગાળા, સમયક્ષેત્ર સહિત (મહત્ત્વપૂર્ણ)

  • સંબંધિત x-request-id અથવા X-Client-Request-Id, જો ઉપલબ્ધ હોય

  • તમે જે વિનંતીઓની વિગતો આપો છો તેમની તારીખ અને સમય, સમયક્ષેત્ર સહિત, અથવા ઓછામાં ઓછી તારીખ

ઉપલબ્ધ હોય તો, આ વિગતો પણ આપો:

  • વિનંતીઓ સાથે સંબંધિત પ્રોજેક્ટનો આઈડી

  • ડેટા રેસિડન્સી વિનંતીઓ અસરગ્રસ્ત છે કે નહીં, અને હોય તો કઈ

  • તમને જોવા મળતાં વલણોનું વર્ણન

સમસ્યાના પ્રકાર મુજબ, આ વિગતો આપો:

  • ભૂલો: નિષ્ફળ જતી અથવા ભૂલ આપતી વિનંતીઓની અંદાજિત ટકાવારી, પ્રતિસાદ કોડ, ભૂલના સંદેશા અને ભૂલનો પ્રતિસાદ મળવામાં કેટલો સમય લાગ્યો.

  • વિલંબ: કયા પર્સેન્ટાઇલ અસરગ્રસ્ત છે (P50 / P90 / P95 / P99), ગ્રાહકના સામાન્ય સ્તરની સરખામણીમાં તે કેટલા ઊંચા છે અને ધીમી વિનંતીઓનાં ઉદાહરણો સાથે વિનંતી મોકલ્યાની તથા પ્રતિસાદ મળ્યાની તારીખ અને સમય.

  • બંને: ભૂલો કે વિલંબના ડેટાના સ્ક્રીનશૉટ અથવા કોષ્ટક, તેમજ ભૂલોનો દર કે વિલંબ અપેક્ષા કરતાં વધારે હોવાનું તમે કેવી રીતે નક્કી કર્યું તે.

સામાન્ય મુશ્કેલીનિવારણ પરિસ્થિતિઓ

ટાઇમઆઉટ્સ થાય છે પરંતુ સેવા આરોગ્ય સામાન્ય લાગે છે

સંભવિત કારણ: વિનંતીઓ OpenAI સુધી પહોંચે તે પહેલાં જ ટાઇમઆઉટ થઈ રહી છે.

તપાસો:

  • ક્લાયંટ અથવા પ્રોક્સી ટાઇમઆઉટ સેટિંગ્સ

  • સ્થાનિક નેટવર્ક અથવા લોડ બેલેન્સરમાં ફેરફારો

  • સેવા આરોગ્ય ડેશબોર્ડમાં 499 ભૂલોની હાજરી (આ તમારી પોતાની સિસ્ટમ્સમાં 5xx ભૂલો તરીકે દેખાઈ શકે છે).

ડિપ્લોયમેન્ટ વિના લેટન્સી વધી

સંભવિત કારણ: આઉટપુટ ટોકન કદ અથવા રિઝનિંગ વપરાશ વધ્યો છે અને/અથવા ટ્રાફિક સેવાના સ્તરો વચ્ચે ખસ્યો છે.

તપાસો:

  • વપરાશ ડેશબોર્ડમાં પ્રતિ વિનંતી સરેરાશ આઉટપુટ ટોકન (ડેટા ડાઉનલોડ કરીને આઉટપુટ ટોકનને કુલ વિનંતીઓથી ભાગવાની જરૂર છે).

  • સેવા આરોગ્ય ડેશબોર્ડમાં વિનંતી સમય અને TTFT પર્સેન્ટાઇલ્સ.

ઝડપી મોડ અથવા વ્યાપકતાનું સ્તર ધીમું જણાય છે

સંભવિત કારણ: વિવિધ સ્તરોના માપદંડો ભળી ગયા હોવાથી માનક સ્તરનો ટ્રાફિક સશુલ્ક સ્તરની કામગીરીને ઢાંકી રહ્યો છે.

આ તપાસો:

  • ફિલ્ટર માત્ર એક સ્તર અને મોડલ સુધી મર્યાદિત છે.

  • સ્તરો વચ્ચે ટોકનની ગતિની સરખામણી.

5XX ભૂલોમાં અચાનક વધારો

સંભવિત કારણ: ટ્રાફિકના નાના ટકાવારીને અસર કરતી અસ્થાયી નિષ્ફળતાઓ.

તપાસો:

  • ભૂલ દરની ટકાવારી

  • ટ્રાફિક વોલ્યુમ એ જ સમયે બદલાયું હતું કે નહીં

સમસ્યા માત્ર એક પ્રોજેક્ટને અસર કરે છે

સંભવિત કારણ: પ્રોજેક્ટ-વિશિષ્ટ કન્ફિગરેશન અથવા વપરાશ પેટર્ન.

તપાસો:

  • પ્રોજેક્ટ-સ્તરનું ફિલ્ટરિંગ

  • અસર ન થયેલા પ્રોજેક્ટ્સ સાથે તુલના

અંતિમ નિષ્કર્ષો

  • મેટ્રિક્સનું અર્થઘટન કરતાં પહેલાં, જ્યાં સંબંધિત હોય ત્યાં મોડલ, સ્તર અને પ્રોજેક્ટ મુજબ ફિલ્ટર કરો.

  • લેટન્સી વિશ્લેષણ માટે સરેરાશો નહીં, પર્સેન્ટાઇલ્સ વાપરો.

  • નાના ભૂલ દરો અપેક્ષિત છે.

  • ગુમ થયેલો ડેટા સામાન્ય રીતે અપસ્ટ્રીમ સમસ્યાઓ સૂચવે છે.

  • વપરાશ ડેટા લેટન્સી શા માટે બદલાઈ તે સમજાવવામાં મદદ કરી શકે છે; સેવા આરોગ્ય વર્તન ક્યારે બદલાયું તે બતાવે છે.

શું આ લેખ મદદરૂપ હતો?