ወደ ዋና ይዘት እለፍ
OpenAI

22 ኤፕሪል 2026

ምህንድስና

በምላሾች API ውስጥ WebSockets በመጠቀም የወኪል የሥራ ፍሰቶች ማፋጠን

በBrian Yu እና Ashwin Nathan፣ የቴክኒክ ሠራተኞች አባላት

በመጫን ላይ…

Codex ሳንካ እንዲያስተካክል ሲጠይቁት፣ ተዛማጅ ፋይሎች ለማግኘት የኮድ መሠረትዎን ይቃኛል፣ አውድ ለመገንባት ያነባቸዋል፣ አርትዖቶችን ያደርጋል እና ጥገናው መሥራቱን ለማረጋገጥ ሙከራዎችን ያካሂዳል። ክውስጡ ሲታይ፣ ይህ ማለት በደርዘን የሚቆጠሩ ተመላላሽ የምላሾች API ጥያቄዎች ማለት ነው፦ የሞዴሉን ቀጣይ እርምጃ ይወስኑ፣ በኮምፒውተርዎ ላይ መሣሪያ ያሂዱ፣ የመሣሪያውን ውጤት ወደ API መልሰው ይላኩ እና ይድገሙት።

እነዚህ ሁሉ ጥያቄዎች Codex ውስብስብ ተግባራትን እስኪፈጽም ድረስ ተጠቃሚዎች የሚያባክኑት ደቂቃዎች ላይ ሊታከሉ ይችላሉ። ከመዘግየት አንፃር፣ የCodex ወኪል ድግግሞሽ አብዛኛውን ጊዜ በሦስት ዋና ደረጃዎች ላይ ያሳልፋል፦ በAPI አገልግሎቶች ውስጥ መሥራት (ጥያቄዎችን ለማረጋገጥ እና ለማካሄድ)፣ የሞዴል መደምደሚያ፣ እና የደንበኛ-ጎን ጊዜ (መሣሪያዎች ማሠራት እና የሞዴል አውድ መገንባት)። መደምደሚያ ሞዴሉ በGPUዎች ላይ አዲስ ቶክን ለማመንጨት የሚሠራበት ደረጃ ነው። ቀደም ሲል፣ በGPUዎች ላይ የLLM መደምደሚያን ማስኬድ የወኪል ድግግሞሽ በጣም ቀርፋፋ ክፍሉ ነበር፣ ስለዚህ የAPI አገልግሎትን የላይ ክፍል መደበቅ ቀላል ነበር። የመደምደሚያ ፍጥነት እየጨመረ ሲሄድ፣ ከውክልና ልቀት የሚገኘው ድምር የAPI የላይኛው ክፍል ላይ በጣም ጎልቶ ይታያል።

በዚህ ልጥፍ ላይ፣ ተጠቃሚዎች ከጫፍ እስከ ጫፍ 40% ፈጣን የሆነ APIን በመጠቀም የወኪል ድግግሞሾችን እንዴት እንዳከናወንን እናብራራለን፣ ይህም ተጠቃሚዎች በሰከንድ ከ 65 እስከ 1,000 ገደማ የሚጠጉ የቶክኖች መደምደሚያ ፍጥነት ጭማሬ ተሞክሮ እንዲያገኙ ያስችላቸዋል። ይህን ያደረግነው አላስፈላጊ የአውታረመረብ ዝላዮችን በማስወገድ፣ ችግሮችን በፍጥነት ለማግኘት የደኅንነት ንብርብራችንን በማሻሻል እና—ከሁሉም በላይ—ተከታታይ የተመሳሰሉ የAPI ጥሪዎች ከማድረግ ይልቅ ከምላሾች API ጋር የማያቋርጥ ግንኙነት ለመፍጠር መንገድ በመገንባት ነው።

«ትግበራ ላይ ያለ የCodex ወኪል ድግግሞሽ» የሚል ሥዕላዊ መግለጫ በCodex እና በምላሾች API መካከል ተደጋጋሚ ፍሰትን የሚያሳይ ሲሆን፣ የመሣሪያ ጥሪዎች (rg፣ sed፣ apply_patch፣ pytest) እና ውጤቶቹ እስከ መጨረሻው መልዕክት ድረስ ልውውጥ ያደርጋሉ፦ «ሳንካው ተስተካክሏል።»

APIዩ ማነቆ በሚሆንበት ጊዜ

በምላሾች API ውስጥ፣ እንደ GPT‑5 እና GPT‑5.2 ያሉ ቀድሞ የነበሩ ዋና ሞዴሎች በሰከንድ በ 65 ቶክኖች (TPS) ይሠሩ ነበር። ፈጣን የኮድ መጻፊያ ሞዴል የሆነውን GPT‑5.3‑Codex‑Spark ለማስጀመር፣ ግባችን በፍጥነት ደረጃ የላቀ መጠንን ማስመዝገብ ነበር፦ ለLLM መደምደሚያ በተመቻቸ ልዩ የሴሬብራስ ሃርድዌር የነቁ፣ ከ 1,000 በላይ TPS። ተጠቃሚዎች የዚህን አዲስ ሞዴል እውነተኛ ፍጥነት ተሞክሮ ማግኘታቸውን ለማረጋገጥ፣ የAPI የላይኛው ክፍልን መቀነስ ነበረብን። 

በ2025 ኖቬምበር አካባቢ፣ በምላሾች API ላይ የአፈጻጸም ፍጥነት ጭማሬን ማካሄድ ጀምረናል፣ ይህም ለአንድ ጥያቄ ወሳኝ በሆነው መንገድ መዘግየት ላይ ብዙ ማሻሻያዎችን አስገኝቷል፦ 

  • ውድ የሆኑ የtokenization እና በርካታ-ዙር ምላሾችን ለመዝለል የተቀረጹ ቶክኖች እና የሞዴል ውቅርን በትውስታ ውስጥ መሸጎጥ
  • ወደ መካከለኛ አገልግሎቶች የሚደረጉ ጥሪዎችን በማስወገድ (ለምሳሌ፣ የምስል ማሰናዳት ጥራት) እና በቀጥታ ወደ የማጠቃለያ አገልግሎቱ በመደወል የአውታረ መረብ መዝለል መዘግየት መቀነስ
  • ውይይቶችን በፍጥነት ለማግኘት የተወሰኑ መመደቢያዎች ማሠራት እንድንችል የደኅንነት ንብርብራችንን ማሻሻል

በእነዚህ ማሻሻያዎች፣ ከመጀመሪያ ቶክን (TTFT) ጊዜ ወደ 45% ገደማ መሻሻል አይተናል—ይህም API ምን ያህል ምላሽ እንደሚሰጥ የሚያንፀባርቅ ቢሆንም—እነዚህ ማሻሻያዎች አሁንም ለGPT‑5.3‑Codex‑Spark በቂ ፍጥነት አልነበራቸውም። እነዚህ ማሻሻያዎች ቢኖሩም፣ የምላሾች API የላይኛው ክፍል ከሞዴሉ ፍጥነት ጋር ሲነጻጸር በጣም ትልቅ ነበር—ማለትም፣ ተጠቃሚዎች ሞዴሉን የሚያገለግሉ GPUዎች መጠቀም ከመቻላቸው በፊት የእኛን API የሚሠሩ CPUዎች መጠበቅ ነበረባቸው።

የበለጠ ጥልቅ የሆነው ችግር መዋቅራዊ ነበር፦ እያንዳንዱን የCodex ጥያቄ እንደ ገለልተኛ፣ የውይይት ሁኔታን እና በእያንዳንዱ የክትትል ጥያቄ ላይ እንደገና ጥቅም ላይ ሊውል እንደሚችል አውድ አድርገን ተመልክተን ነበር። ምንም እንኳን አብዛኛው የውይይቱ ክፍል ባይቀየርም፣ ከሙሉ ታሪኩ ጋር ለተያያዘው ሥራ መክፈላችን አልቀረም ነበር። ውይይቶች እየረዘሙ ሲሄዱ፣ ያ ተደጋጋሚ ሂደት የበለጠ ውድ ሆኗል።

የማያቋርጥ ግንኙነት መፍጠር

ንድፉን ለማጠናከር፣ የትራንስፖርት ፕሮቶኮሉን እንደገና አስበንበታል፦ በHTTP በኩል አዲስ ግንኙነት ከመመሥረት እና ለእያንዳንዱ የክትትል ጥያቄ ሙሉውን የውይይት ታሪክ ከመላክ ይልቅ፣ የማያቋርጥ ግንኙነት እና የመሸጎጫ ሁኔታ ማቆየት እንችል ይሆን? ሐሳቡ በግንኙነቱ ቆይታ ሙሉ ማረጋገጫን እና ሂደትን የሚፈልግ ማንኛውንም አዲስ መረጃ ብቻ መላክ እና እንደገና ጥቅም ላይ ሊውል የሚችል የመሸጎጫ ሁኔታ ማህደረ ትውስታ ውስጥ ማከማቸት ነበር። ይህ ከተደጋጋሚ ሥራ የሚመጣውን ተጨማሪ ጫና ይቀንሳል።

WebSockets እና gRPC ባለ ሁለት አቅጣጫ ዥረትን ጨምሮ ጥቂት የተለያዩ አቀራረቦችን ተመልክተናል። በWebSockets ላይ ያረፍንበት ምክንያት፣ እንደ ቀላል የመልእክት ማጓጓዣ ፕሮቶኮል፣ ተጠቃሚዎች የእነርሱን ምላሾች API ግቤት እና ውጤት ቅርጾች መቀየር አይጠበቅባቸውም። ለገንቢዎች ተስማሚ እና ከትንሽ መስተጓጎል ጋር ከነባር አርክቴክቸራችን ጋር የሚጣጣም ነበር።

የመጀመሪያው የWebSocket ፕሮቶታይፕ ለምላሾች API መዘግየት የሚቻል ይሆናል ብለን ያሰብነውን ነገር ቀይሮታል። በCodex ቡድን ውስጥ ጥልቅ እውቀት ያለው መሐንዲስ በአንድ ሌሊት የCodex ወኪል በማሥራት አንድ ፕሮቶታይፕ አዘጋጅቷል።

በዚያ ፕሮቶታይፕ ውስጥ፣ የወኪል ልቀቶች እንደ አንድ ረጅም ጊዜ የሚቆይ ምላሽ ተቀርጸው ነበር። የ asyncio ባህሪያት በመጠቀም፣ የመሣሪያ ጥሪ ናሙና ከተወሰደ በኋላ የምላሾች API ባልተመሳሰለ ሁኔታ በናሙና ድግግሞሽ ውስጥ ያግዳል፣ እና ምላሾች API response.done ክስተትን ወደ ደንበኛው መልሶ ይልካል። የመሣሪያውን ጥሪ ከፈጸሙ በኋላ፣ ደንበኞች ከመሣሪያው ውጤት ጋር response.append መልሰው ይልካሉ፣ ክስተት ያክሉ፣ ይህም የናሙና ድግግሞሹን እገዳ አንስቶ ሞዴሉ እንዲቀጥል ያስችላል።

እዚህ ላይ ያለው ምሳሌ የአካባቢውን የመሣሪያ ጥሪ እንደ የአስተናጋጅ የመሣሪያ ጥሪ አድርጎ መቁጠር ነው። ሞዴሉ የድር ፍለጋ ሲጠራ፣ የመደምደሚያው ድግግሞሽ ያግዳል፣ የድር ፍለጋ አገልግሎት ይጠራል እና የአገልግሎቱን ምላሽ በሞዴል አውድ ውስጥ ያስቀምጣል። በንድፋችን ውስጥ፣ ተመሳሳይ ነገር አድርገናል፤ ነገር ግን የርቀት አገልግሎት ከመጥራት ይልቅ፣ የሞዴሉን የመሣሪያ ጥሪ ወደ ደንበኛው በWebSocket በኩል መልሰን ልከናል። ደንበኛው ምላሽ ሲሰጡ፣ የደንበኛውን የመሣሪያ ጥሪ ምላሽ ወደ አውዱ አስገብተን ናሙና ማድረጋችንን ቀጠልን።

ይህ ንድፍ በወኪል ልቀት ላይ ተደጋጋሚ የAPI ሥራን ስላስወገደ እጅግ በጣም ውጤታማ ነበር። የቅድመ-ግምት ሥራ አንድ ጊዜ ማድረግ፣ የመሣሪያ አፈፃፀም ለአፍታ ማቆም እና በመጨረሻው ላይ አንድ ጊዜ የድህረ መደምደሚያ ሥራ ማከናወን እንችላለን።

እንደ አለመታደል ሆኖ፣ ይህ ብዙ የማይታወቅ እና የበለጠ ውስብስብ የሆነ የAPI ቅርፅ አስከትሏል። ፍላጎታችን ገንቢዎች የAPI ውህደታቸውን በአዲስ የግንኙነት ሁነታ ላይ እንደገና መጻፍ ሳያስፈልጋቸው የWebSocket ድጋፍን ማግኘት እንዲችሉ ነበር።

ንብርብር በመጨመር APIን የበለጠ እንዲታወቅ ማድረግ

ለጀመርነው ሥሪት፣ ወደ የተለመደ ቅርፅ ተመልሰናል፦ በተመሳሳይ አካል response.create መጠቀምዎን ይቀጥሉ፣ እና ከቀድሞው ምላሽ ሁኔታ የውይይት አውዱን ለመቀጠል previous_response_id ይጠቀሙ።

በWebSocket ግንኙነት ላይ፣ አገልጋዩ ቀደም ሲል በነበረውን የምላሽ ሁኔታ መሸጎጫ የተወሰነ ግንኙነት ያቆያል። የክትትል response.create previous_response_id ሲያካትት፣ ሙሉውን ውይይት ከመጀመሪያ ከመገንባት ይልቅ ያንን ሁኔታ ከመሸጎጫው እናመጣለን።

የተሸጎጠው ሁኔታ የሚከተሉትን ያካትታል፦

  • የቀድሞው ምላሽ ጉዳይ
  • ቀዳሚ የግቤት እና የውጤት ንጥሎች
  • የመሣሪያ መግለጫዎች እና የስም ቦታዎች
  • እንደ ቀደም ሲል ሬንደር የተደረጉ ቶክኖች ያሉ እንደገና ጥቅም ላይ ሊውሉ የሚችሉ የናሙና ቅርሶች
«ከተከታታይ ጥያቄዎች ወደ ተደራራቢ አፈፃፀም» የሚል ሥዕላዊ መግለጫ ተከታታይ ዝርጋታ WebSocketን መሠረት ካደረገ አቀራረብ ጋር በማነፃፀር በርካታ ጥያቄዎች በማረጋገጫ፣ በቅድመ መደምደሚያ፣ በናሙና እና በድህረ-ውሳኔ ደረጃዎች ላይ ይደራርባል።

የቀድሞውን የትውስታ ውስጥ ምላሽ ሁኔታ እንደገና በመጠቀም፣ በርካታ ዋና ማመቻቻዎች ማድረግ ችለን ነበር፦

  • አንዳንድ የደኅንነት መመደቢዎቻችንን እና የጥያቄ ማረጋገጫዎቻችንን በየጊዜው ሙሉውን ታሪክ ሳይሆን፣ አዲስ ግቤት ብቻ እንዲያካሄዱ ማድረግ
  • አላስፈላጊ የtokenization ሂደት መዝለል እንድንችል የምናካትታቸው ሬንደር የተደረጉ የቶክኖች መሸጎጫ በትውስታ ውስጥ ማቆየት
  • በጥያቄዎች መካከል ስኬታማ የሆነ የሞዴል ጥራት/አቅጣጫ መፈለጊያ ሎጊካችንን እንደገና መጠቀም 
  • እንደ ክፍያ መጠየቂያ ካሉ ተከታይ ጥያቄዎች ጋር እገዳ የማያስከትል የድህረ መደምደሚያ ሥራ ማደራረብ

ግቡ ገንቢዎች አስቀድመው የተረዱት እና በዙሪያው የገነቡበት የAPI ቅርፅ ጋር በተቻለ መጠን ዝቅተኛ የላይ ክፍል ያለው ፕሮቶታይፕ ማግኘት ነበር።

ለፍጥነት አዲስ ገደብ ማዘጋጀት

የWebSocket ሁነታን ለሁለት ወራት በፍጥነት ከገነባን በኋላ፣ ከመሠረተ ልማታቸው ጋር ለማዋሃድ እና ትራፊክን ደኅንነቱ በተጠበቀ ሁኔታ ለማሳደግ ቁልፍ የኮድ ወኪል ጅምሮች ያሉት አልፋ አስጀመርን። የአልፋ ተጠቃሚዎች የወደዱት ሲሆን፣ በወኪል ፍሰታቸው ላይ እስከ 40% የሚደርሱ ማሻሻያዎችን(በአዲስ መስኮት ውስጥ ይክፈታል) ሪፖርት አድርገዋል። የአልፋውን አዎንታዊ ግብረመልስ ከግምት ውስጥ በማስገባት፣ ለመጀመር ዝግጁ ነበርን።

የልቀቱ ውጤቶች አፋጣኝ ነበሩ። Codex አብዛኛውን የእነርሱን ምላሾች API ትራፊክ ወደ WebSocket ሁነታ በፍጥነት አሳድጎታል፣ ይህም ጉልህ የሆነ የመዘግትየት ማሻሻያዎች አሳይቷል። ለGPT‑5.3‑Codex‑Spark፣ የ 1,000 TPS ግባችንን አሳክተናል እና እስከ 4,000 TPS የሚደርሱ ከፍተኛ ጭማሪዎችን ተመልክተናል፣ ይህም ምላሾች API በእውነተኛ የምርት ትራፊክ ውስጥ ከዚህ የበለጠ ፈጣን መደምደሚያ ጋር እኩል መሄድ እንደሚችል አሳይቷል። ተፅዕኖው እንዲሁ በገንቢው ማኅበረሰብ ውስጥ በፍጥነት ታይቷል፦

የWebSocket ሁነታ ከማርች 2025 ጀምሮ በምላሾች API ውስጥ ካሉት በጣም አስፈላጊ አዲስ ችሎታዎች አንዱ ነው። በጥቂት ሳምንታት ውስጥ በOpenAI API እና በCodex ቡድኖች መካከል በቅርበት በመተባበር ከሐሳብ ወደ ምርት ውስጥ መሥራት ተዛውረናል። የወኪል ልቀት መዘግየትን በከፍተኛ ሁኔታ ከማሻሻል ባለፈ ለገንቢዎች እየጨመረ የመጣውን ፍላጎት ይደግፋል፦ የሞዴል መደምደሚያ ፍጥነት እየጨመረ ሲሄድ፣ መደምደሚያ ዙሪያ ያሉ አገልግሎቶች እና ሥርዓቶች እነዚህን ጥቅሞች ለተጠቃሚዎች ለማስተላለፍ መፋጠን ያስፈልጋቸዋል። 

ደራሲዎች

Brian Yu እና Ashwin Nathan

ምስጋናዎች

የWebSocket ሁነታን ለመፍጠር ለሠሩት የምላሾች API እና የCodex ቡድኖች ልዩ ምስጋና ይገባቸዋል።