เร่งสปีดการทำงานของระบบเอเจนต์โดยใช้ WebSockets ใน Responses API

เมื่อคุณขอให้ Codex แก้ไขบั๊ก ระบบจะสแกนหาไฟล์ที่เกี่ยวข้องในฐานโค้ด อ่านไฟล์เหล่านั้นเพื่อสร้างบริบท ทำการแก้ไข และรันการทดสอบเพื่อตรวจสอบว่าแก้ไขจุดบกพร่องได้สำเร็จ ในทางปฏิบัติระบบต้องส่ง Request ไปยัง Responses API สลับกันไปมานับสิบครั้ง ทั้งการตัดสินใจว่าโมเดลจะทำอะไรต่อ การสั่งใช้เครื่องมือในเครื่องของคุณ แล้วจึงส่งข้อมูลที่ได้กลับไปที่ API และวนซ้ำแบบนี้ไปเรื่อยๆ

คำขอทั้งหมดนี้รวมกันแล้วอาจทำให้ผู้ใช้ต้องใช้เวลารอหลายนาทีเพื่อให้ Codex ทำงานที่ซับซ้อนให้เสร็จ หากมองในมุมของความหน่วง วงจรการทำงานของ Codex จะใช้เวลาส่วนใหญ่ไปกับ 3 ขั้นตอนหลัก ได้แก่ การประมวลผลในส่วน API (เพื่อตรวจสอบและจัดการคำขอ) การประมวลผลของโมเดล และเวลาในฝั่งไคลเอนต์ (เพื่อรันเครื่องมือและสร้างบริบทให้โมเดล) การอนุมานคือขั้นตอนที่โมเดลทำงานบน GPU เพื่อสร้างโทเค็นใหม่ขึ้นมา เมื่อก่อนขั้นตอนการอนุมาน LLM บน GPU เป็นจุดที่ช้าที่สุดในวงจรของเอเจนต์ ดังนั้นภาระเพิ่มเติมจากการใช้งาน API จึงมองไม่เห็นเท่าไรนัก เมื่อการประมวลผลรวดเร็วขึ้น ภาระงานส่วนเกินสะสมของ API จากการทำงานของเอเจนท์จึงกลายเป็นจุดที่สังเกตเห็นได้ชัดเจนยิ่งขึ้น

เราจะมาอธิบายวิธีเพิ่มความเร็วให้กระบวนการทำงานของเอเจนต์ผ่าน API ขึ้นอีก 40% ซึ่งช่วยให้ผู้ใช้ได้รับประสบการณ์ความเร็วของโมเดลที่ก้าวกระโดดจาก 65 ไปถึงเกือบ 1,000 โทเค็นต่อวินาที แนวทางของเราคือการนำระบบแคชมาใช้ ลดจำนวนการส่งข้อมูลผ่านเครือข่ายที่ไม่จำเป็น ปรับจูนระบบคัดกรองความปลอดภัยให้ทำงานเร็วขึ้น และสร้างการเชื่อมต่อกับ Responses API แบบต่อเนื่อง เพื่อทดแทนการเรียกใช้งาน API ซ้ำๆ ในรูปแบบเดิม

สำหรับ Responses API นั้น โมเดลรุ่นเรือธงในอดีตอย่าง GPT‑5 และ GPT‑5.2 ประมวลผลด้วยความเร็วราว 65 โทเค็นต่อวินาที (TPS) สำหรับการเปิดตัว GPT‑5.3‑Codex‑Spark ซึ่งเป็นโมเดลเขียนโค้ดที่รวดเร็ว เราตั้งเป้าหมายให้มันทำงานไวขึ้นกว่าเดิมถึงสิบเท่า หรือมากกว่า 1,000 TPS โดยใช้ฮาร์ดแวร์เฉพาะทางจาก Cerebras ที่ปรับจูนมาเพื่อการประมวลผล LLM โดยเฉพาะ เพื่อให้มั่นใจว่าผู้ใช้จะได้สัมผัสความเร็วที่แท้จริงของโมเดลรุ่นใหม่นี้ เราจึงจำเป็นต้องลดภาระงานส่วนเกินของ API ลง

ช่วงเดือนพฤศจิกายน พ.ศ. 2568 เราได้เริ่มโครงการเร่งด่วนเพื่อปรับปรุงประสิทธิภาพของ Responses API และประสบความสำเร็จในการเพิ่มความเร็วหลายส่วนให้กับเส้นทางการทำงานที่สำคัญสำหรับการส่งคำขอเพียงครั้งเดียว 

• เราใช้วิธีแคชโทเค็นที่ประมวลผลแล้วและคอนฟิกของโมเดลไว้ในหน่วยความจำ เพื่อตัดขั้นตอนการทำ Tokenization และการเรียกใช้เครือข่ายที่กินเวลาสำหรับการตอบแบบหลายเทิร์น
• การลดความหน่วงจากการส่งข้อมูลในเครือข่าย โดยตัดการเรียกใช้บริการตัวกลาง (เช่น การปรับความละเอียดภาพ) และเปลี่ยนมาเรียกใช้บริการประมวลผลโดยตรง
• ปรับปรุงระบบความปลอดภัย เพื่อให้เราสามารถรันตัวจำแนกประเภทบางตัวเพื่อตรวจจับการสนทนาได้รวดเร็วยิ่งขึ้น

การพัฒนาในส่วนนี้ช่วยลดเวลาการสร้างโทเค็นแรก (TTFT) ลงได้เกือบ 45% ทำให้ผู้ใช้รู้สึกว่า API ตอบสนองได้ไวขึ้นมาก อย่างไรก็ตาม ประสิทธิภาพที่เพิ่มขึ้นนี้ยังไม่เร็วพอสำหรับมาตรฐานของ GPT‑5.3‑Codex‑Spark แม้จะปรับปรุงระบบแล้ว แต่ภาระงานส่วนเกินของ Responses API ก็ยังสูงเกินไปเมื่อเทียบกับความเร็วของโมเดล กล่าวคือผู้ใช้งานต้องเสียเวลารอการประมวลผลของ CPUs ในฝั่ง API ก่อน จึงจะสามารถเข้าถึงการทำงานของ GPUs ที่รันโมเดลได้

ต้นตอของปัญหานี้อยู่ที่โครงสร้างระบบ โดยเราจัดการคำขอของ Codex แต่ละรายการแยกจากกัน ทำให้ต้องประมวลผลสถานะการสนทนาและบริบทอื่นๆ ซ้ำใหม่ทุกครั้งที่มีการถามตอบต่อเนื่อง แม้เนื้อหาการสนทนาส่วนใหญ่จะยังเหมือนเดิม แต่เราก็ยังต้องแบกรับภาระการประมวลผลข้อมูลย้อนหลังทั้งหมดอยู่ดี เมื่อการสนทนายาวขึ้น การประมวลผลซ้ำๆ นั้นก็มีค่าใช้จ่ายสูงขึ้น

เพื่อขัดเกลาการออกแบบให้รัดกุมยิ่งขึ้น เราจึงทบทวนโปรโตคอลการรับส่งข้อมูลใหม่ โดยตั้งคำถามว่าเราจะรักษาการเชื่อมต่อแบบค้างไว้และแคชสถานะข้อมูลได้หรือไม่ แทนที่จะต้องสร้างการเชื่อมต่อผ่าน HTTP ใหม่พร้อมส่งประวัติการสนทนาทั้งหมดไปทุกครั้งที่มีคำขอต่อเนื่อง แนวคิดหลักคือการส่งเฉพาะข้อมูลใหม่ที่ต้องผ่านการตรวจสอบและประมวลผลเท่านั้นโดยจะเก็บสถานะส่วนที่ใช้ซ้ำได้ไว้ในหน่วยความจำตราบเท่าที่ยังมีการเชื่อมต่ออยู่ วิธีนี้จะช่วยลดภาระงานส่วนเกินที่เกิดจากการประมวลผลซ้ำซ้อน

เราพิจารณาแนวทางที่แตกต่างกันหลายวิธี ซึ่งรวมถึงการใช้ WebSockets และการสตรีมมิ่งแบบสองทิศทางของ gRPC รวมอยู่ด้วย เราตัดสินใจเลือกใช้ WebSockets เพราะเป็นโปรโตคอลรับส่งข้อความที่เรียบง่าย ซึ่งช่วยให้ผู้ใช้ไม่ต้องปรับเปลี่ยนรูปแบบข้อมูลขาเข้าและขาออกของ Responses API เดิม วิธีนี้เป็นมิตรกับนักพัฒนาและเข้ากับโครงสร้างระบบเดิมของเราได้อย่างลงตัวโดยไม่สร้างความยุ่งยาก

WebSocket ต้นแบบรุ่นแรกทำให้เราเห็นความเป็นไปได้ใหม่ๆ ในการลดความหน่วงของ Responses API ให้ดียิ่งขึ้นกว่าเดิม วิศวกรในทีม Codex ที่มีความเชี่ยวชาญสูงเกี่ยวกับระบบ API ทั้งหมด ได้สร้างตัวต้นแบบขึ้นมาด้วยการสั่งรัน Codex เอเจนต์ ทิ้งไว้ข้ามคืน

สำหรับตัวต้นแบบนั้น ลูปการทำงานของเอเจนต์ถูกออกแบบเป็น Response เดียวที่รันยาวตลอดทั้งกระบวนการ เมื่อใช้ฟีเจอร์ของ asyncio ตัว Responses API จะหยุดรอการทำงานในลูปการสุ่มตัวอย่างแบบอะซิงโครนัสหลังจากสุ่มเลือกการเรียกใช้เครื่องมือเสร็จสิ้น และ Responses API จะส่งเหตุการณ์ response.done กลับไปยังไคลเอนต์ หลังจากรันการเรียกใช้เครื่องมือเสร็จสิ้น ไคลเอนต์จะส่ง response.append พร้อมผลลัพธ์ของเครื่องมือกลับมา ซึ่งช่วยปลดล็อกลูปการสุ่มตัวอย่างและปล่อยให้โมเดลทำงานต่อไปได้

เราอาจเปรียบเทียบได้ว่าวิธีนี้คือการจัดการกับการเรียกใช้เครื่องมือในเครื่อง ให้เหมือนกับการเรียกใช้เครื่องมือผ่านระบบโฮสต์ เมื่อโมเดลเรียกใช้การค้นหาเว็บ ลูปการอนุมานจะหยุดรอและเรียกใช้บริการค้นหาเว็บ จากนั้นจึงนำผลลัพธ์ที่ได้ไปใส่ไว้ในบริบทของโมเดล ในการออกแบบของเรา เราใช้วิธีการเดียวกันนี้ แต่แทนที่จะเรียกใช้บริการจากระยะไกล เรากลับส่งคำสั่งเรียกใช้เครื่องมือของโมเดลกลับไปให้ไคลเอนต์ผ่านทาง WebSocket แทน เมื่อไคลเอนต์ตอบกลับมา เราก็นำคำตอบจากการเรียกใช้เครื่องมือของไคลเอนต์นั้นใส่ลงในบริบทและดำเนินการสุ่มตัวอย่างต่อไป

ดีไซน์นี้ได้ผลดีนื่องจากช่วยกำจัดการทำงานของ API ที่ต้องทำซ้ำๆ ในระหว่างการประมวลผลของเอเจนต์ เราสามารถทำขั้นตอนก่อนการอนุมานได้แค่ครั้งเดียว หยุดชั่วคราวเพื่อให้เครื่องมือทำงาน แล้วจึงทำขั้นตอนหลังการอนุมานอีกแค่ครั้งเดียวในตอนท้าย

ข้อเสียคือเราต้องแลกประสิทธิภาพดังกล่าวกับโครงสร้าง API ที่มีความยุ่งยากและใช้งานได้ยากกว่าเดิม เราต้องการให้นักพัฒนาสามารถเพิ่มการรองรับ WebSocket เข้าไปได้ทันที โดยไม่ต้องเขียนระบบเชื่อมต่อ API ใหม่ตามรูปแบบการโต้ตอบที่เปลี่ยนไป

สำหรับเวอร์ชันที่เราเปิดตัว เราเปลี่ยนกลับมาใช้รูปแบบที่คุ้นเคย โดยยังคงใช้ response.create พร้อมโครงสร้างเนื้อหาแบบเดิม และใช้ previous_response_id เพื่อสานต่อบริบทการสนทนาจากสถานะของคำตอบก่อนหน้า

ในการเชื่อมต่อ WebSocket เซิร์ฟเวอร์จะเก็บแคชในหน่วยความจำที่มีขอบเขตอยู่ภายในการเชื่อมต่อสำหรับสถานะการตอบกลับก่อนหน้า เมื่อคำขอ response.create ที่ตามมามี previous_response_id รวมอยู่ด้วย เราจะดึงสถานะนั้นจากแคช แทนที่จะสร้างบริบทการสนทนาทั้งหมดขึ้นใหม่ตั้งแต่ต้น

สถานะที่แคชนั้นประกอบด้วย:

• ออบเจ็กต์คำตอบที่เกิดขึ้นก่อนหน้านี้
• รายการอินพุตและเอาต์พุตก่อนหน้า
• คำนิยามของเครื่องมือและขอบเขตการเรียกใช้ชื่อ
• ข้อมูลจากการสุ่มตัวอย่างที่นำมาใช้ซ้ำได้ อย่างเช่นเหล่าโทเค็นที่ระบบเคยสร้างขึ้นแล้ว

การนำสถานะของคำตอบก่อนหน้าที่เก็บไว้ในหน่วยความจำกลับมาใช้ใหม่ ช่วยให้เราสามารถเพิ่มประสิทธิภาพการทำงานหลักได้ในหลายส่วน

• เรากำหนดให้ระบบคัดกรองความปลอดภัยและตัวตรวจสอบคำขอบางส่วนตรวจสอบแค่ข้อมูลใหม่ โดยไม่ต้องย้อนกลับไปประมวลผลประวัติการสนทนาทั้งหมดซ้ำ
• การเก็บแคชของโทเค็นที่ประมวลผลแล้วไว้ในหน่วยความจำเพื่อเขียนข้อมูลต่อเติมเข้าไป ซึ่งช่วยให้เราข้ามขั้นตอน Tokenization ที่ไม่จำเป็นได้
• นำตรรกะการตัดสินใจเลือกและกำหนดเส้นทางโมเดลที่เราเคยทำสำเร็จมาใช้ซ้ำในทุกคำขอ
• ออกแบบให้งานหลังการอนุมานที่ไม่ต้องหยุดรอ เช่น ระบบเรียกเก็บเงินทำงานแบบคู่ขนานไปกับการจัดการคำขอใหม่ที่เข้ามา

เป้าหมายของเราคือการทำให้ระบบมีประสิทธิภาพใกล้เคียงกับตัวต้นแบบที่มีภาระงานส่วนเกินน้อยที่สุด แต่ยังคงรูปแบบ API ที่นักพัฒนาเข้าใจและใช้งานเป็นหลักอยู่แล้ว

หลังจากเราทุ่มเทพัฒนาโหมด WebSocket ตลอดสองเดือน เราจึงเริ่มเปิดให้สตาร์ทอัพเอเจนต์เขียนโค้ดชั้นนำได้ทดลองใช้เวอร์ชันอัลฟา เพื่อให้พวกเขานำไปเชื่อมต่อกับโครงสร้างพื้นฐานและทยอยเพิ่มปริมาณการใช้งานได้อย่างปลอดภัย ผู้ใช้งานเวอร์ชันอัลฟาต่างประทับใจผลลัพธ์นี้ โดยระบุว่าระบบช่วยให้เวิร์กโฟลว์เชิงเอเจนต์มีประสิทธิภาพสูงขึ้นถึง 40%⁠(เปิดในหน้าต่างใหม่) เมื่อพิจารณาจากเสียงตอบรับเชิงบวกจากเวอร์ชันอัลฟา เราจึงพร้อมที่จะเปิดตัวระบบอย่างเป็นทางการ

ผลลัพธ์จากการเปิดตัวเกิดขึ้นทันที Codex ทยอยย้ายปริมาณการใช้งานส่วนใหญ่ของ Responses API ไปยังโหมด WebSocket อย่างรวดเร็ว และพบว่าความหน่วงของระบบลดลงอย่างมาก เราทำระดับความเร็วได้ตามเป้า 1,000 TPS สำหรับ GPT‑5.3‑Codex‑Spark และพุ่งสูงถึง 4,000 TPS ในบางช่วง แสดงให้เห็นว่า Responses API รองรับการอนุมานที่รวดเร็วขึ้นมากในระบบที่ใช้งานจริงได้ ผลลัพธ์ที่เกิดขึ้นยังส่งต่อถึงกลุ่มนักพัฒนาอย่างรวดเร็วเช่นกัน

• Codex ย้ายทราฟฟิกส่วนใหญ่ของตนไปใช้ WebSockets อย่างรวดเร็ว ผู้ใช้ Codex ที่ใช้งานโมเดลล่าสุด เช่น GPT‑5.3‑Codex⁠(เปิดในหน้าต่างใหม่), GPT‑5.4⁠(เปิดในหน้าต่างใหม่), และอื่นๆ อีกมากมายได้รับประโยชน์จากความเร็วที่เพิ่มขึ้นของโหมด WebSocket
• Vercel ผสานรวมโหมด WebSocket เข้ากับ AI SDK และพบว่าความหน่วงลดลง สูงสุด 40%⁠(เปิดในหน้าต่างใหม่)
• เวิร์กโฟลว์แบบหลายไฟล์ของ Cline เร็วขึ้น 39%⁠(เปิดในหน้าต่างใหม่)
• โมเดลของ OpenAI ใน Cursor เร็วขึ้นสูงสุด 30%⁠(เปิดในหน้าต่างใหม่)

โหมด WebSocket ถือเป็นความสามารถใหม่ที่สำคัญที่สุดอย่างหนึ่งของ Responses API นับตั้งแต่การเปิดตัวเมื่อเดือนมีนาคม พ.ศ. 2568 เราใช้เวลาเพียงไม่กี่สัปดาห์ในการเปลี่ยนจากแนวคิดไปสู่การใช้งานจริงในระบบ ด้วยความร่วมมืออย่างใกล้ชิดระหว่างทีม API ของ OpenAI และทีม Codex สิ่งนี้ไม่เพียงแต่ช่วยลดความหน่วงในการเปิดตัวเอเจนต์ได้อย่างมหาศาล แต่ยังตอบสนองความต้องการที่เพิ่มขึ้นของเหล่านักพัฒนา เพราะเมื่อการอนุมานของโมเดลเร็วขึ้น บริการและระบบรอบข้างก็จำเป็นต้องรวดเร็วขึ้นตามไปด้วย เพื่อส่งต่อผลประโยชน์นี้ไให้แก่ผู้ใช้งาน