Responses API дахь WebSocket-оор агент урсгалыг хурдасгах нь

Codex-оос алдаа засахыг хүсэхэд энэ нь таны кодын санд холбогдох файлуудыг хайж, контекст бүрдүүлэхийн тулд уншиж, засвар хийж, засвар ажилласныг баталгаажуулахын тулд тест ажиллуулдаг. Цаана нь энэ нь Responses API руу олон арван нааш цааш хүсэлт явуулна гэсэн үг: загварын дараагийн үйлдлийг тодорхойлох, таны компьютер дээр хэрэгсэл ажиллуулах, хэрэгслийн гаралтыг API руу буцаан илгээх, тэгээд дахин давтах.

Эдгээр бүх хүсэлт нийлээд Codex-ийг төвөгтэй даалгавар дуусгахыг хүлээхэд хэрэглэгчдийн зарцуулах хугацааг минутуудаар нэмэгдүүлж болно. Хоцролтын өнцгөөс харахад Codex агентын цикл ихэнх цагаа API үйлчилгээний дотор ажиллахад (хүсэлтийг шалгаж боловсруулах), загварын inference, мөн client-side хугацаанд (хэрэгсэл ажиллуулах ба загварын контекст бүрдүүлэх) өнгөрөөдөг. Inference бол загвар GPU дээр ажиллаж шинэ токен үүсгэдэг үе шат юм. Өмнө нь GPU дээр LLM inference ажиллуулах нь агент урсгалын хамгийн удаан хэсэг байсан тул API үйлчилгээний нэмэлт зардлыг нуухад амар байв. Inference хурдсахын хэрээр агент ажиллагааны rollout-оос үүсэх API-ийн хуримтлагдсан нэмэлт зардал илүү мэдэгдэхүйц болдог.

Энэ нийтлэлд бид API ашигладаг агентын циклийг төгсгөлөөс төгсгөл хүртэл 40% хурдан болгож, хэрэглэгчдэд inference-ийн хурд секундэд 65 токеноос бараг 1,000 токен хүртэл өссөнийг мэдрэх боломжийг хэрхэн олгосноо тайлбарлана. Үүнийг бид кэшлэлт, хэрэггүй сүлжээний дамжлагыг арилгах, асуудлыг хурдан тэмдэглэхийн тулд аюулгүй байдлын стэкээ сайжруулах, мөн хамгийн чухал нь дараалсан synchronous API дуудлагууд хийхийн оронд Responses API-тай тогтвортой холболт үүсгэх арга бүтээх замаар хийсэн.

Responses API-д GPT‑5, GPT‑5.2 зэрэг өмнөх тэргүүлэх загварууд секундэд ойролцоогоор 65 токеноор (TPS) ажилладаг байсан. Хурдан кодчлолын загвар болох GPT‑5.3‑Codex‑Spark‑ийг гаргахдаа бидний зорилго үүнээс арав дахин хурдан, өөрөөр хэлбэл секундэд 1,000+ TPS байлаа. Үүнийг LLM inference-д оновчлогдсон тусгай Cerebras төхөөрөмж боломжтой болгосон. Хэрэглэгчид энэ шинэ загварын жинхэнэ хурдыг мэдрүүлэхийн тулд бид API-ийн нэмэлт зардлыг багасгах шаардлагатай болсон.

2025 оны 11-р сарын орчимд бид Responses API дээр гүйцэтгэлийн спринт эхлүүлж, нэг хүсэлтийн чухал замын хоцролтыг багасгах олон оновчлол хийсэн:

• Олон ээлжтэй хариултад үнэтэй токенжуулалт ба сүлжээний дуудлагыг алгасахын тулд рэндэрлэсэн токен болон загварын тохиргоог санах ойд кэшлэх
• Дунд шатны үйлчилгээнүүд рүү (жишээ нь зураг боловсруулах нягтрал) хийх дуудлагыг арилгаж, inference үйлчилгээг шууд дуудах замаар сүлжээний hop-ийн хоцролтыг бууруулах
• Яриануудыг илүү хурдан тэмдэглэхийн тулд зарим ангилагчийг ажиллуулах боломж бүрдүүлж, аюулгүй байдлын стэкээ сайжруулах

Эдгээр сайжруулалтын ачаар бид first token хүртэлх хугацаанд (TTFT) бараг 45%-ийн сайжралт харсан—энэ нь API хэр мэдрэмжтэй санагддагийг илтгэнэ—гэхдээ энэ нь GPT‑5.3‑Codex‑Spark‑д хангалттай хурдан хэвээр байсангүй. Эдгээр сайжруулалттай байсан ч Responses API-ийн нэмэлт зардал загварын хурдтай харьцуулахад хэт өндөр байв—өөрөөр хэлбэл, хэрэглэгчид загварт үйлчилж буй GPU-г ашиглахаасаа өмнө манай API-г ажиллуулж буй CPU-г хүлээх шаардлагатай байсан.

Илүү гүн асуудал нь бүтэцтэй холбоотой байв: бид Codex-ийн хүсэлт бүрийг бие даасан гэж үзэж, дараагийн хүсэлт бүр дээр ярианы төлөв болон дахин ашиглаж болох бусад контекстыг боловсруулж байсан. Ярианы ихэнх хэсэг өөрчлөгдөөгүй байсан ч бид бүтэн түүхтэй холбоотой ажлын өртгийг төлсөөр байв. Яриа уртсах тусам энэ давтагдсан боловсруулалт улам үнэтэй болсон.

Загварыг илүү цэгцтэй болгохын тулд бид тээвэрлэлийн протоколыг дахин бодож үзсэн: HTTP-ээр шинэ холболт бүр үүсгэж, дараагийн хүсэлт бүрт ярианы бүтэн түүхийг илгээхийн оронд тогтвортой холболт хадгалж, төлөвийг кэшлэж болох уу? Гол санаа нь шалгалт, боловсруулалт шаардсан шинэ мэдээллийг л илгээж, дахин ашиглах төлөвийг холболтын насжилтын турш санах ойд кэшлэх явдал байв. Ингэснээр давхардсан ажлаас үүдэх нэмэлт зардал буурна.

Бид WebSocket болон gRPC-ийн хоёр чиглэлт стрийминг зэрэг хэд хэдэн аргыг авч үзсэн. Энгийн мессеж тээвэрлэх протоколын хувьд хэрэглэгчид Responses API-ийн оролт, гаралтын бүтцийг өөрчлөх шаардлагагүй тул бид WebSocket-ийг сонгосон. Энэ нь хөгжүүлэгчдэд ээлтэй байсан бөгөөд манай одоогийн архитектурт бага өөрчлөлтөөр нийцэж байв.

Анхны WebSocket прототип Responses API-ийн хоцролтын талаар бидний боломжтой гэж бодож байсан зүйлийг өөрчилсөн. API стэкийн бүх түвшинд гүн мэдлэгтэй Codex багийн нэг инженер шөнийн турш Codex агент ажиллуулан прототипээ босгосон.

Тэр прототип дээр агент rollout-уудыг нэг урт хугацаанд ажиллах Response хэлбэрээр загварчилсан. asyncio-ийн боломжуудыг ашиглан Responses API нь хэрэгслийн дуудлага sample хийгдсэний дараа sampling loop дотор асинхроноор block хийж, дараа нь response.done event-ийг клиент рүү буцааж илгээдэг байв. Хэрэгслийн дуудлагыг гүйцэтгэсний дараа клиентүүд хэрэгслийн үр дүнтэй response.append event-ийг буцаан илгээж, энэ нь sampling loop-ийг unblock хийж загварыг үргэлжлүүлэх боломж олгодог байв.

Үүнийг орон нутгийн хэрэгслийн дуудлагыг hosted хэрэгслийн дуудлага мэт авч үзэж байна гэж зүйрлэж болно. Загвар web search дуудах үед inference loop block болж, web search үйлчилгээг дуудаж, үйлчилгээний хариуг загварын контекстэд байршуулдаг. Манай загварт ч бид яг үүнийг хийсэн; гэхдээ алсын үйлчилгээ дуудахын оронд загварын хэрэгслийн дуудлагыг WebSocket-оор клиент рүү буцаан илгээсэн. Клиент хариу өгөхөд бид клиентийн хэрэгслийн дуудлагын хариуг контекстэд оруулж, sampling-ийг үргэлжлүүлсэн.

Энэ загвар агент rollout-ийн турш давтагддаг API ажлыг арилгасан тул маш үр дүнтэй байсан. Бид preinference ажлыг нэг удаа хийж, хэрэгсэл ажиллуулах дээр түр зогсоод, эцэст нь postinference ажлыг нэг удаа хийх боломжтой болсон.

Харамсалтай нь энэ нь танил биш, илүү төвөгтэй API хэлбэрийн үнээр ирсэн. Хөгжүүлэгчид шинэ харилцан үйлчлэлийн горимд API интеграцаа бүхэлд нь дахин бичихгүйгээр WebSocket дэмжлэгийг шууд нэмж чаддаг байгаасай гэж бид хүссэн.

Бидний гаргасан хувилбарт танил хэлбэр рүү буцсан: ижил body-тай response.create-ийг үргэлжлүүлэн ашиглаж, өмнөх response-ийн төлвөөс ярианы контекстыг үргэлжлүүлэхдээ previous_response_id-г ашигласан.

WebSocket холболт дээр сервер нь холболтын хүрээнд, санах ойд хадгалагдах өмнөх response төлвийн кэшийг хадгалдаг. Дараагийн response.create хүсэлтэд previous_response_id орсон байвал бид бүтэн яриаг шинээр босгохын оронд тэр төлвийг кэшээс авч ашигладаг.

Тэр кэшлэгдсэн төлөвт дараах зүйлс орно:

• Өмнөх response объект
• Өмнөх оролт, гаралтын элементүүд
• Хэрэгслийн тодорхойлолт ба namespace-ууд
• Өмнө нь рэндэрлэсэн токен зэрэг дахин ашиглах боломжтой sampling артефактууд

Санах ой дахь өмнөх response төлвийг дахин ашигласнаар бид хэд хэдэн томоохон оновчлол хийж чадсан:

• Зарим аюулгүй байдлын ангилагч болон хүсэлт шалгагчийг бүтэн түүхийг биш, зөвхөн шинэ оролтыг боловсруулах боломжтой болгох
• Рэндэрлэсэн токены санах ойн кэшийг хадгалж, түүнд нэмж бичснээр хэрэггүй токенжуулалтыг алгасах
• Загвар шийдэл/маршрутын амжилттай логикоо хүсэлтүүдийн хооронд дахин ашиглах
• Төлбөр тооцоо зэрэг block хийхгүй postinference ажлыг дараагийн хүсэлтүүдтэй давхардуулах

Зорилго нь хөгжүүлэгчдийн аль хэдийн ойлгож, түүн дээрээ системээ байгуулсан API хэлбэрийг хадгалсаар хамгийн бага нэмэлт зардалтай прототипт аль болох ойртох байв.

WebSocket горимыг бүтээх хоёр сарын спринтийн дараа бид гол кодчилолын агент стартапуудтай альфа хувилбарыг гаргаж, тэдэнд дэд бүтцэд нь нэгтгэж, урсгалыг аюулгүйгээр аажмаар нэмэх боломж олгосон. Альфа хэрэглэгчид үүнийг маш их таалж, өөрсдийн агент урсгалд 40% хүртэл сайжралт⁠(шинэ цонхонд нээгдэнэ) гарсан гэж мэдээлсэн. Альфын эерэг санал хүсэлтийг харгалзан бид нээлтээ хийхэд бэлэн болсон.

Гаргалтын үр дүн тэр дороо мэдэгдсэн. Codex өөрсдийн Responses API урсгалын дийлэнхийг WebSocket горим руу хурдан шилжүүлж, хоцролтын мэдэгдэхүйц сайжралт үзсэн. GPT‑5.3‑Codex‑Spark‑ийн хувьд бид 1,000 TPS зорилтдоо хүрч, 4,000 TPS хүртэлх оргил мөчүүдийг харсан нь Responses API бодит үйлдвэрлэлийн урсгал дээр 훨씬 хурдан inference-тэй хөл нийлүүлж чаддагийг харуулсан. Нөлөө нь хөгжүүлэгчдийн нийгэмлэгт ч хурдан мэдрэгдсэн:

• Codex урсгалынхаа дийлэнхийг WebSocket руу хурдан шилжүүлсэн. GPT‑5.3‑Codex⁠(шинэ цонхонд нээгдэнэ), GPT‑5.4⁠(шинэ цонхонд нээгдэнэ) зэрэг хамгийн сүүлийн загваруудыг ашиглаж буй Codex хэрэглэгчид бүгд WebSocket горимын хурдны өсөлтөөс ашиг хүртэж байна.
• Vercel AI SDK-д WebSocket горимыг нэгтгэж, хоцролт 40% хүртэл⁠(шинэ цонхонд нээгдэнэ) буурсныг харсан.
• Cline-ийн олон файлын урсгалууд 39% хурдан⁠(шинэ цонхонд нээгдэнэ) болсон.
• Cursor дахь OpenAI загварууд 30% хүртэл хурдан⁠(шинэ цонхонд нээгдэнэ) болсон.

WebSocket горим нь 2025 оны 3-р сард нээлтээ хийснээс хойшхи Responses API-ийн хамгийн ач холбогдолтой шинэ боломжуудын нэг юм. OpenAI-ийн API болон Codex багуудын нягт хамтын ажиллагааны ачаар бид санаанаас үйлдвэрлэлд ажиллах хүртэл ердөө хэдхэн долоо хоногт хүрсэн. Энэ нь агент rollout-ийн хоцролтыг эрс сайжруулаад зогсохгүй бүтээгчдийн өсөн нэмэгдэж буй хэрэгцээг ч дэмждэг: загварын inference хурдсахын хэрээр inference-ийг хүрээлсэн үйлчилгээ, системүүд ч мөн эдгээр олзыг хэрэглэгчдэд хүргэхийн тулд хурдасах хэрэгтэй.