สำหรับ AI เสียง การรู้ว่าควรพูดเมื่อไรยากกว่าที่คิด มนุษย์ผลัดกันพูดได้อย่างเป็นธรรมชาติในเสี้ยววินาที แต่ระบบ AI เสียงก่อนหน้านี้ตามจังหวะดังกล่าวไม่ทัน สถาปัตยกรรมแบบผลัดกันพูดของระบบเหล่านั้นอาศัยโมเดลขนาดเล็กที่เรียกว่าตัวตรวจจับการผลัดพูด ซึ่งต้องทำงานที่น่าหนักใจ กล่าวคือ หากคาดเดาเร็วไป ผู้ใช้จะถูกตัดบท แต่หากช้าไป การตอบกลับก็จะดูเชื่องช้า LLM ที่ใหญ่กว่ามากจะเริ่มทำงานได้ก็ต่อเมื่อตัวตรวจจับตัดสินใจแล้ว
GPT‑Live ระบบเสียงรุ่นที่สามของเรา นำตัวตรวจจับการผลัดพูดออกจากเส้นทางเสียง โมเดลเสียงของระบบเป็นแบบฟูลดูเพล็กซ์ จึงฟังและพูดได้พร้อมกัน วิธีนี้ไม่ต้องใช้ตัวตรวจจับแยกต่างหาก และทำให้การสนทนาฉับไวเป็นธรรมชาติยิ่งขึ้น เมื่อต้องใช้การให้เหตุผลเชิงลึกหรือเครื่องมือ GPT‑Live ยังปรึกษาโมเดลระดับแนวหน้าของเรา เช่น GPT‑5.5 ได้โดยไม่ขัดจังหวะการสนทนา ความสามารถเหล่านี้ทำให้ GPT‑Live ผสานการตอบสนองในการสนทนาเข้ากับระดับการคิดได้อย่างที่ไม่เคยมีมาก่อน
การมอบประสบการณ์นี้ในวงกว้างต้องใช้สถาปัตยกรรมระบบใหม่ที่ปรับมาเพื่อความหน่วงต่ำ ต่างจากการอนุมานแบบรับคำขอแล้วตอบกลับทั่วไป ระบบของเราสตรีมเสียงขาเข้าไปยังโมเดลเสียงและส่งเสียงพูดขาออกกลับไปยังผู้ใช้ พร้อมจัดการการมอบหมายงานบนเส้นทางอะซิงโครนัสแยกต่างหาก ตลอดหกเดือนที่ผ่านมา เราปรับปรุงการอนุมานของโมเดล การจัดการบริบท และการรับส่งสื่อใหม่ เพื่อให้เสียงพูดไหลลื่นตั้งแต่ต้นจนจบ
สถาปัตยกรรมนี้ยังแบ่งเส้นทางหลักของระบบเสียงออกจากลอจิกของแอปพลิเคชันอย่างชัดเจน จึงปรับแต่งการทำงานของแอปได้ง่ายโดยไม่กระทบต่อความรวดเร็วในการตอบสนอง โครงสร้างพื้นฐานนี้รองรับความสามารถต่างๆ ของ ChatGPT Voice ที่เพิ่มขึ้นอย่างต่อเนื่อง รวมถึงฟีเจอร์ใหม่ที่ช่วยให้คุณควบคุมคอมพิวเตอร์และประสานงานระหว่างเอเจนต์ในแอป ChatGPT บนเดสก์ท็อป
ในบทความนี้ เราจะอธิบายว่าเหตุใดระบบแบบผลัดกันพูดรุ่นก่อนจึงไม่ตอบโจทย์ และเราออกแบบระบบใหม่ให้ตอบสนองฉับไวในทุกชั้นได้อย่างไร เราจะกล่าวถึงการอนุมานแบบมีสถานะ การจัดการบริบทแบบไดนามิก การมอบหมายงานแบบอะซิงโครนัส และการปรับให้เหมาะสมในระดับโปรโตคอล ซึ่งทำงานร่วมกันเพื่อให้ GPT‑Live รู้สึกว่าเกิดขึ้นแบบสดจริงๆ
สถาปัตยกรรมระบบเสียงในยุคแรกยังคงใช้รูปแบบการผลัดกันโต้ตอบของ LLM ที่ประมวลผลข้อความ แต่เปลี่ยนจากข้อความมาเป็นไฟล์เสียงแยกในแต่ละรอบ สำหรับระบบแบบหลายขั้นตอน ระบบแปลงเสียงเป็นข้อความ LLM และระบบแปลงข้อความเป็นเสียงจะทำงานต่อกันเป็นลำดับ กระบวนการดังกล่าวทำให้การตอบสนองล่าช้าและสูญเสียรายละเอียดสำคัญอย่างน้ำเสียงและจังหวะการพูด
โมเดลการแปลงเสียงเป็นเสียงปรับปรุงแนวทางนี้ด้วยการประมวลผลเสียงโดยตรง การฝึกให้โมเดลเข้าใจและสร้างเสียงพูดได้โดยตรงช่วยรักษารายละเอียดที่สูญหายในการถอดเสียง และทำให้ตอบสนองได้เร็วขึ้น แต่ระบบยังต้องพึ่งตัวตรวจจับการผลัดพูดเพื่อตัดสินใจว่าเมื่อใดจึงจะเริ่มการอนุมานได้ โมเดลรับหน้าที่ในการโต้ตอบมากขึ้น แต่การโต้ตอบยังคงเป็นแบบผลัดกันพูด
GPT‑GPT‑Live ออกแบบให้โมเดลเสียงควบคุมการสนทนา โดยรับและส่งเสียงผ่านโมเดลโดยตรง ส่วนการใช้เหตุผลที่ซับซ้อนและการเรียกใช้เครื่องมือจะทำงานเบื้องหลังแบบอะซิงโครนัส ระบบมีหน้าที่หลักในการรักษาวงจรการรับส่งสื่อให้ต่อเนื่องโดยไม่สะดุด ส่วนงานอื่นๆ เช่น การเรียกใช้โมเดลระดับแนวหน้าและการบันทึกบทสนทนา จะประมวลผลแยกจากเส้นทางแบบเรียลไทม์
การทำให้การรับส่งสื่อดำเนินไปอย่างต่อเนื่องโดยไม่สะดุดนั้นไม่ใช่เรื่องง่ายเสมอไป ความล่าช้าในการรับส่ง การประมวลผล หรือการอนุมานอาจทำให้เสียงหยุดชะงักหรือเกิดเสียงผิดเพี้ยนได้ ระบบแบบผลัดกันโต้ตอบที่ใช้ก่อนหน้านี้ยังรองรับความคลาดเคลื่อนของเวลาที่ข้อมูลเสียงแต่ละชุดมาถึงได้บ้าง แต่ระบบสื่อแบบสดต้องส่งเสียงทุกเฟรมให้ตรงเวลา
งานก่อนหน้านี้เกี่ยวกับ ChatGPT Voice และ Realtime API วางรากฐานสำคัญให้เรา เราได้สร้างโครงสร้างพื้นฐานด้านเสียงขึ้นใหม่แล้ว เพื่อสตรีมเสียงและวิดีโอเข้าและออกจากระบบโดยตรงด้วยความหน่วงที่ต่ำลงและคาดการณ์ได้มากขึ้น GPT‑Live ต่อยอดการออกแบบนี้ไปอีกขั้น โดยสตรีมสื่อไปจนถึงตัวโมเดลผ่านระบบอนุมานแบบมีสถานะรูปแบบใหม่ที่สร้างขึ้นเพื่อการสนทนาอย่างต่อเนื่อง
อย่างไรก็ตาม การอนุมานแบบสตรีมมิงเป็นเพียงส่วนหนึ่งของโซลูชันเท่านั้น เพื่อให้ระบบทำงานได้ดีในสภาพแวดล้อมจริง เรายังต้องทำให้มั่นใจว่าระบบจะส่งข้อมูลเสียงจากไคลเอ็นต์ไปยังชุดระบบอนุมานได้อย่างเสถียร พร้อมทั้งรับมือกับความท้าทายของการจัดการสถานะ
เราตัดสินใจตั้งแต่ช่วงแรกว่าจะแยกการรับส่งสื่อออกจากการทำงานของแอปพลิเคชันและตรรกะทางธุรกิจโดยเฉพาะ เสียงจะรับส่งระหว่างไคลเอ็นต์กับโมเดลเสียงผ่านเส้นทางความเร็วสูงโดยเฉพาะ ส่วนการมอบหมายงาน การใช้เครื่องมือ และงานอื่นๆ ของแอปพลิเคชันจะทำงานอยู่อีกฝั่งของขอบเขต RPC แบบอะซิงโครนัส การเรียกใช้เครื่องมือหรือบริการแบ็กเอนด์ที่ล่าช้าอาจทำให้ผลลัพธ์ของส่วนนั้นมาถึงช้าลง แต่จะไม่ทำให้การรับส่งสื่อหยุดชะงัก
การแยกส่วนนี้ยังช่วยกำหนดขอบเขตที่ชัดเจนสำหรับการปรับแต่งระบบ แอปพลิเคชันสามารถเปลี่ยนเครื่องมือ นโยบาย และการทำงานของแบ็กเอนด์ได้โดยไม่กระทบฟรอนต์เอนด์ด้านสื่อที่ทำหน้าที่รับส่งเสียงอย่างต่อเนื่อง เส้นทางการรับส่งแบบสดจึงยังคงมีขนาดเล็ก ทำงานได้อย่างคาดการณ์ได้ และมุ่งเน้นเฉพาะงานที่ต้องเกิดขึ้นแบบเรียลไทม์
เราพัฒนาฟรอนต์เอนด์ด้านสื่อและตรรกะการอนุมานขึ้นใหม่ด้วยภาษา Go แทนระบบเดิมที่ใช้ asyncio ของ Python การเปลี่ยนแปลงนี้ช่วยให้ส่งเฟรมได้ลื่นไหลขึ้นอย่างมาก โดยค่า p95 ของระบบใหม่อยู่ในระดับเดียวกับค่า p50 ของระบบเดิม
WebRTC ทำหน้าที่เป็นโครงสร้างพื้นฐานสำหรับการรับส่งข้อมูล โดยออกแบบมาเพื่อรับส่งสื่อด้วยเวลาแฝงต่ำ และยังทำงานต่อไปได้แม้เกิดการสูญหายของแพ็กเก็ต เวลาในระบบคลาดเคลื่อน หรือการเชื่อมต่อของไคลเอ็นต์เปลี่ยนแปลง หากแพ็กเก็ตมาถึงล่าช้า WebRTC จะปรับยืดเสียงอย่างแนบเนียนเพื่อไม่ให้เกิดช่วงเงียบ ก่อนเร่งการเล่นเสียงชั่วคราวเพื่อให้กลับมาตรงกับเวลาจริง
ด้วยการลดการบัฟเฟอร์และการบล็อกทั่วทั้งระบบ เราจึงตอบสนองได้ภายในไม่ถึงหนึ่งวินาทีตามที่มนุษย์คาดหวังจากการสนทนา
ระบบอนุมานแบบมีสถานะมาพร้อมกับข้อแลกเปลี่ยนด้านการปฏิบัติงาน เซสชันเสียงอาจทำงานอยู่นาน แต่บริบทจะเพิ่มขึ้นต่อเนื่อง ขณะที่อินสแตนซ์ของโมเดลเริ่มและหยุดทำงานตามความต้องการ
เพื่อรับมือกับความท้าทายเหล่านี้ เราได้สร้างกลไกส่งต่อการทำงานระหว่างอินสแตนซ์ของโมเดลอย่างราบรื่น เมื่อจำเป็นต้องเปลี่ยนอินสแตนซ์ ระบบจะเตรียมอินสแตนซ์ใหม่ให้พร้อมควบคู่ไปกับอินสแตนซ์เดิม เติมบริบทปัจจุบันของเซสชันให้ล่วงหน้า ประมวลผลการอนุมานบนทั้งสองอินสแตนซ์พร้อมกัน แล้วจึงสลับไปใช้อินสแตนซ์ใหม่เมื่อพร้อมทำงานอย่างสมบูรณ์
กลไกพื้นฐานแบบเดียวกันนี้ยังรองรับการบีบอัดบริบทแบบไดนามิกอีกด้วย เมื่อการสนทนาดำเนินไป บริบทที่สะสมไว้อาจเกินขีดจำกัดบริบทของโมเดลในที่สุด การบีบอัดจะช่วยลดขนาดบริบทให้อยู่ภายในขีดจำกัด แต่กระบวนการนี้ต้องใช้เวลา และเนื่องจากการบีบอัดเปลี่ยนแปลงบริบทก่อนหน้า จึงทำให้แคชคีย์-แวลู (KV) ของโมเดลใช้ไม่ได้ด้วย แคชนี้เก็บคีย์และค่าของกลไกความสนใจจากโทเค็นที่ประมวลผลไปแล้ว การสร้างสถานะนั้นใหม่ต้องเติมข้อมูลล่วงหน้าอีกครั้ง จึงทำให้เกิดความล่าช้าเพิ่มเติม
ด้วยเหตุนี้เราจึงจัดการการบีบอัดบริบทในลักษณะเดียวกับการเปลี่ยนผ่านอื่นๆ ขณะที่อินสแตนซ์ของโมเดลเดิมยังสนทนาต่อ ระบบจะบีบอัดบริบทและเตรียมอินสแตนซ์ทดแทนด้วยบริบทใหม่ เมื่ออินสแตนซ์นั้นพร้อม ระบบก็สามารถสลับไปใช้งานได้โดยไม่ทำให้การรับส่งสื่อสะดุด วิธีนี้ช่วยให้ระบบรองรับสายที่ใช้งานเป็นเวลานาน โดยย่อบริบทได้ทุกเมื่อที่จำเป็น
งานประมวลผลหนักจะอยู่นอกเส้นทางการทำงานแบบสด ดังนั้นแม้ในช่วงส่งต่อการทำงาน บทสนทนาก็ยังดำเนินต่อได้อย่างลื่นไหลไม่มีสะดุด
ความสามารถของ GPT‑Live ในการเรียกใช้โมเดลระดับแนวหน้าที่มีอยู่ทำให้ระบบทรงพลังมาก โดยแยก “การพูด” ออกจาก “การคิด” เชิงลึกได้อย่างแท้จริง แต่การทำให้สถาปัตยกรรมสองโมเดลนี้รู้สึกเป็นระบบเดียวต้องแก้โจทย์วิศวกรรมสองข้อที่เกี่ยวข้องกัน
การมอบหมายงานที่ลึกซึ้งยิ่งขึ้น
GPT-Live ตอบกลับได้อย่างรวดเร็วและเป็นธรรมชาติ ในขณะที่ GPT-5.5 ทำหน้าที่ค้นหาข้อมูลอยู่เบื้องหลัง
ข้อแรก ผลลัพธ์ต้องกลับมาเร็วพอที่จะเป็นประโยชน์ต่อบทสนทนาที่กำลังดำเนินอยู่ เราจึงต้องลดความหน่วงตลอดเส้นทางการมอบหมายงาน ตั้งแต่การกำหนดเส้นทางและประมวลผลพรอมต์ ไปจนถึงการอนุมานและการเรียกเครื่องมือ ขณะเดียวกัน ระบบส่วนอื่นๆ ของผลิตภัณฑ์ยังต้องใช้ข้อความแยกเป็นรายการ เราจึงต้องนำเสนอการสนทนาที่ต่อเนื่องให้อยู่ในรูปแบบที่ระบบเหล่านั้นเข้าใจได้
เมื่อส่งงานออกไป เราปรับระบบเพื่อลดเวลาจนกว่าโมเดลระดับแนวหน้าจะสร้างสิ่งที่เป็นประโยชน์ต่อการสนทนา โมเดลเสียงช่วยประคองบทสนทนาได้ชั่วครู่ระหว่างที่โมเดลระดับแนวหน้ากำลังให้เหตุผลหรือใช้เครื่องมือ แต่ไม่อาจกลบเกลื่อนการตอบสนองที่ช้าเกินไปได้ เราจึงนับวงจรการมอบหมายงานทั้งหมด ทั้งการกำหนดเส้นทาง การประมวลผลพรอมต์ การอนุมาน และการเรียกเครื่องมือ เป็นส่วนหนึ่งของงบเวลาการตอบสนอง
การปรับประสิทธิภาพอย่างแรกคือการเตรียมโมเดลระดับแนวหน้าและเครื่องมือที่จำเป็นให้พร้อมก่อนมีคำขอมอบหมายงาน เมื่อเซสชันเสียงเริ่มต้นขึ้น เซิร์ฟเวอร์แอปพลิเคชันจะสร้างเซสชันการอนุมานสำหรับโมเดลดังกล่าวและป้อนบริบทเริ่มต้นของการสนทนาล่วงหน้า เพื่อให้โมเดลประมวลผลพรอมต์ทั้งหมดเสร็จสิ้นก่อนรับคำขอมอบหมายงานครั้งแรก
จากนั้นเราเก็บเซสชันอนุมานนั้นไว้ตลอดการสนทนาด้วยเสียง และกำหนดให้คำขอต่อเนื่องส่งไปยังเซสชันเดิมอย่างสม่ำเสมอ เมื่อใช้ร่วมกับการแคชพรอมต์ เทคนิคเหล่านี้ช่วยลดความหน่วง พร้อมทั้งทำให้ระบบกู้คืนได้ง่ายหากเวิร์กเกอร์ขัดข้อง
ปัจจัยอย่างระดับการใช้เหตุผล ขีดจำกัดของผลลัพธ์ รูปแบบคำสั่งของเครื่องมือ และจำนวนรอบที่โมเดลต้องโต้ตอบกับเครื่องมือ ล้วนส่งผลต่อระยะเวลาที่ผู้ใช้จะได้รับผลลัพธ์ที่เป็นประโยชน์ เราจึงปรับปัจจัยเหล่านี้เพื่อให้ระบบตอบสนองเร็วขึ้น และเมื่อลดภาระงานในเส้นทางการมอบหมายงานให้เหลือน้อยที่สุด โมเดลเสียงก็สามารถนำผลลัพธ์จากโมเดลระดับแนวหน้ามาใช้ได้อย่างรวดเร็ว
ถึงแม้โมเดลเสียงจะรับและประมวลผลเสียงพูดอย่างต่อเนื่อง แต่ระบบแวดล้อมจำนวนมากยังทำงานโดยแบ่งเป็นรอบของผู้ใช้และผู้ช่วย เช่น UI การสนทนาของ ChatGPT รวมถึงโครงสร้างพื้นฐานบางส่วนด้านการวิเคราะห์และความปลอดภัย เซิร์ฟเวอร์แอปพลิเคชันจึงแยกบทสนทนาที่พูดทับกันและบางครั้งก็กำกวมออกเป็นข้อความแต่ละรายการ
เมื่อมีเสียงเข้ามา เซิร์ฟเวอร์จะอาศัยข้อความถอดเสียงบางส่วนและข้อมูลด้านเวลาเพื่อประเมินว่าใครกำลังเป็นฝ่ายพูด และจัดเรียงข้อความไว้เป็นคิว ข้อความล่าสุดจะยังไม่ถือเป็นฉบับสมบูรณ์ โดยเนื้อหา เวลา และการระบุผู้พูดอาจเปลี่ยนแปลงได้เมื่อมีเสียงเข้ามาเพิ่มเติม เมื่อผู้พูดคนหนึ่งพูดต่อเนื่องนานพอจนระบบระบุผู้พูดได้อย่างน่าเชื่อถือ เซิร์ฟเวอร์จึงจะยืนยันข้อความนั้นเป็นฉบับสมบูรณ์
การพูดทับกันทำให้กระบวนการนี้ซับซ้อนยิ่งขึ้น คำตอบรับสั้นๆ จากผู้ช่วยในขณะที่ผู้ใช้กำลังพูด เช่น “อือฮึ” หรือ “โอเค” อาจไม่จำเป็นต้องแยกเป็นข้อความใหม่ แต่หากผู้ช่วยพูดแทรกด้วยเนื้อหาที่มีสาระ ก็มักควรแยกเป็นอีกข้อความหนึ่ง ในทำนองเดียวกัน แม้ผู้ใช้จะพูดแทรกกลางประโยค เราก็ให้ความสำคัญกับความต่อเนื่องและความเข้าใจง่ายของคำตอบจากผู้ช่วยที่แสดงบนหน้าจอ
นโยบายแต่ละแบบในการแบ่งบทสนทนาเป็นช่วงๆ ต้องหาจุดสมดุลระหว่างการแสดงข้อมูลล่าสุดกับความมั่นใจในความถูกต้อง หากยืนยันข้อความเร็วเกินไป ประวัติการสนทนาจะแตกเป็นส่วนย่อยและลำดับอาจเปลี่ยนไปมา แต่หากรอนานเกินไป ข้อความถอดเสียงและฟีเจอร์ที่ต้องใช้ข้อความเหล่านั้นก็จะแสดงผลล่าช้า ระบบจึงดูแลบทสนทนาสองมุมมองควบคู่กัน คือมุมมองชั่วคราวที่สะท้อนสถานะล่าสุด และบันทึกที่ยืนยันแล้วว่ามีการพูดอะไรบ้าง เนื่องจากหน้าจอการสนทนาในแอปรองรับการอัปเดตได้ จึงใช้มุมมองชั่วคราว ส่วนการบันทึกข้อมูลลงในกระบวนการวิเคราะห์จำเป็นต้องใช้ข้อความถอดเสียงฉบับสมบูรณ์
วิธีนี้ช่วยให้ส่วนอื่นๆ ของ ChatGPT เห็นภาพการสนทนาที่คงที่ ขณะที่เส้นทางเสียงแบบเรียลไทม์ยังดำเนินต่อไปได้โดยไม่ต้องรอให้แต่ละฝ่ายผลัดกันพูด
ระบบต้องเริ่มตอบสนองทันทีที่ผู้ใช้คลิกปุ่ม เมื่อใช้ GPT‑Live ระบบต้องสร้างเส้นทางการรับส่งสื่อและเริ่มส่งเสียงเข้าโมเดลก่อนจึงจะเริ่มการสนทนาได้ ดังนั้น ทุกขั้นตอนในกระบวนการเริ่มต้นจึงมีผลโดยตรงต่อระยะเวลาในการตอบสนอง
ตามที่อธิบายไว้ข้างต้น WebRTC เป็นพื้นฐานที่มีประสิทธิภาพสำหรับระบบเรียลไทม์ แต่การเริ่มต้นเซสชัน WebRTC แบบทั่วไปกลับต้องใช้ขั้นตอนการเชื่อมต่อระหว่างโปรโตคอลและการรับส่งข้อมูลไปกลับผ่านเครือข่ายมากกว่าที่หลายคนคาด WebRTC ถือกำเนิดขึ้นก่อนที่แนวคิดการลดจำนวนรอบการรับส่งข้อมูลจะกลายเป็นหัวใจสำคัญในการออกแบบโปรโตคอลรุ่นหลังอย่าง QUIC ด้วยเหตุนี้ เมื่อนำโปรโตคอลพื้นฐานของ WebRTC มาใช้ร่วมกัน บางครั้งจึงเกิดการทำงานซ้ำซ้อน เช่น แต่ละโปรโตคอลมีกลไกป้องกันการโจมตีแบบ DoS ของตนเอง แม้บางกลไกจะไม่จำเป็นเมื่อทำงานอยู่ภายในสแต็ก WebRTC ทั้งระบบ
เราวิเคราะห์สแต็กและพัฒนา WebRTC Abridged Roundtrip Protocol (WARP(เปิดในหน้าต่างใหม่)) ซึ่งลดขั้นตอนการเริ่มต้นรับส่งสื่อและข้อมูลจากการรับส่งข้อมูลไปกลับผ่านเครือข่าย 6 รอบเหลือเพียงรอบเดียว WARP ทำได้ด้วยการปรับปรุงโปรโตคอลหลายส่วนที่ยังรองรับการทำงานแบบย้อนหลัง ได้แก่ การส่งกระบวนการแฮนด์เชก DTLS พ่วงไปกับ ICE (SPED(เปิดในหน้าต่างใหม่)) การใช้ DTLS 1.3(เปิดในหน้าต่างใหม่) ซึ่งสามารถทำการแฮนด์เชกได้เร็วกว่า การเจรจากระบวนการแฮนด์เชก SCTP ล่วงหน้า (SNAP(เปิดในหน้าต่างใหม่)) และการเจรจาช่องทางข้อมูลล่วงหน้าแทน DCEP(เปิดในหน้าต่างใหม่)
เราออกแบบ WARP ให้เป็นชุดข้อกำหนดแบบเปิด โดยทำงานร่วมกับผู้เชี่ยวชาญจากชุมชน WebRTC เพื่อให้ระบบนิเวศในวงกว้างสามารถนำผลงานนี้ไปใช้ประโยชน์ได้ ขณะนี้เรากำลังผลักดันข้อเสนอต่างๆ ผ่านคณะทำงาน TSVWG ของ IETF ทั้ง libwebrtc และ Pion ได้เพิ่มการรองรับ WARP แล้ว และทีมที่พัฒนา WebRTC รูปแบบอื่นๆ ก็กำลังดำเนินการในส่วนนี้เช่นกัน
หลังปรับกระบวนการแฮนด์เชกของสื่อให้เหมาะสม ยังมีความล่าช้าอีกจุดที่เด่นชัด นั่นคือการแลกเปลี่ยนสัญญาณเพื่อแชร์พารามิเตอร์ SDP ก่อนที่ WebRTC จะเชื่อมต่อได้ เพื่อส่งพารามิเตอร์ SDP ก่อนที่ WebRTC จะเชื่อมต่อได้ เราจึงพัฒนาสิ่งที่เรียกว่า Instant Connect เพื่อไม่ให้ขั้นตอนนี้อยู่ในเส้นทางสำคัญ โดยระบบจะเจรจาพารามิเตอร์เหล่านี้ไว้ล่วงหน้าโดยไม่ต้องสำรองความจุของเซิร์ฟเวอร์หรือปรับเปลี่ยนการใช้งาน WebRTC ที่มีอยู่
Instant Connect ทำงานควบคู่กับกระบวนการส่งสัญญาณมาตรฐาน หากพารามิเตอร์ที่เจรจาไว้ล่วงหน้าถูกต้อง เซิร์ฟเวอร์จะสร้างเซสชันจริงได้ทันทีที่แพ็กเก็ตสื่อแรกมาถึง หากพารามิเตอร์ล้าสมัยหรือไม่ถูกต้อง กระบวนการส่งสัญญาณก็เริ่มทำงานอยู่แล้ว ไคลเอ็นต์จึงเปลี่ยนไปใช้เส้นทางสำรองได้โดยไม่เพิ่มความหน่วง
Instant Connect และ WARP ช่วยลดเวลาตั้งแต่ผู้ใช้เริ่มสั่งงานจนระบบเริ่มรับส่งสื่อสดได้อย่างมาก เนื่องจากไม่ต้องรอการแลกเปลี่ยน SDP ในเส้นทางสำคัญ และ WARP ช่วยลดขั้นตอนการแฮนด์เชกสำหรับการรับส่งข้อมูล ไคลเอ็นต์จึงเริ่มต้นเซสชันด้วยแพ็กเก็ต UDP เพียงแพ็กเก็ตเดียวได้ เซิร์ฟเวอร์ตอบกลับได้ทันที ทำให้ส่วนอื่นๆ ของระบบเริ่มทำสิ่งที่ผู้ใช้ต้องการจริงๆ ได้ นั่นคือการฟังและตอบกลับ
ระบบอาจดูเหมือนทำงานได้รวดเร็วในทางทฤษฎี แต่กลับติดขัดเมื่อต้องรองรับการใช้งานเสียงจริง ก่อนเปิดให้ GPT‑Live แชตกับผู้ใช้ เราได้ทำการทดสอบแบบเบื้องหลัง โดยค่อยๆ ส่งเซสชัน ChatGPT Voice ในระบบจริงจำนวนเล็กน้อยไปยังทั้ง Advanced Voice Mode ที่ใช้อยู่เดิมและระบบใหม่ของเรา Advanced Voice Mode ยังคงให้บริการผู้ใช้ตามปกติ ส่วนระบบที่ทดสอบเบื้องหลังจะประมวลผลในโหมดอ่านอย่างเดียว การทดสอบนี้ช่วยให้ระบบรับมือกับไคลเอ็นต์ เครือข่าย ระยะเวลาเซสชัน และการใช้งานจากหลากหลายภูมิภาคในสถานการณ์จริง โดยไม่ส่งผลต่อเสียงที่ผู้ใช้ได้ยิน
หนึ่งในบทเรียนแรก ๆ ที่เราได้รับคือ เราไม่สามารถประเมินขีดความสามารถของระบบจากปริมาณงานที่ GPU ประมวลผลได้เพียงอย่างเดียว เนื่องจากเซสชันเสียงจะเชื่อมต่อค้างไว้และส่งเฟรมอย่างต่อเนื่อง ระบบจัดการสตรีม คิว และเส้นทางเครือข่ายที่ทำงานบน CPU จึงต้องรองรับการขยายตัวควบคู่ไปกับระบบอนุมานด้วย เมื่อใช้งานจริงในปริมาณมาก องค์ประกอบสนับสนุนส่วนหนึ่งทำงานเต็มขีดจำกัดเร็วกว่าที่เราประเมินไว้ในการทดสอบโหลด ส่งผลให้คำขออนุมานสะสมและความล่าช้าเพิ่มขึ้นอย่างต่อเนื่อง เราจึงเปลี่ยนคำถามในการวางแผนขีดความสามารถจาก “GPU หนึ่งตัวรองรับคำขอได้กี่รายการ” เป็น “ระบบรองรับเซสชันพร้อมกันได้กี่เซสชัน โดยยังประมวลผลทุกเฟรมได้ตามกำหนดเวลา”
การทดสอบนี้ยังทำให้เราตระหนักว่าที่ตั้งทางภูมิศาสตร์เป็นปัจจัยสำคัญอันดับต้นๆ การส่งเซสชันไปยังทรัพยากรที่อยู่ห่างไกลอาจเพิ่มความล่าช้าในหลายช่วง ทั้งระหว่างการเริ่มต้นระบบและการสตรีม เราจึงเริ่มตรวจสอบการเปิดตัวโมเดลควบคู่กับขีดความสามารถของแต่ละภูมิภาคและการกำหนดค่าการกำหนดเส้นทางทราฟฟิก จากนั้นจึงวิเคราะห์ความล่าช้าโดยแยกตามภูมิภาคต้นทาง การนำระบบอนุมานมาไว้ใกล้ผู้ใช้มากขึ้นช่วยลดความล่าช้าได้ แต่ก็ตอกย้ำบทเรียนสำคัญว่า การตอบสนองที่รวดเร็วตลอดทั้งระบบขึ้นอยู่กับทุกบริการที่อยู่ในเส้นทาง ไม่ใช่เพียงเซิร์ฟเวอร์โมเดลเท่านั้น
ข้อผิดพลาดบางอย่างจะปรากฏขึ้นเฉพาะเมื่อทดสอบวงจรการทำงานของเซสชันในสถานการณ์จริงเท่านั้น เซสชันที่ทำงานเป็นเวลานานทำให้เห็นแรงกดดันด้านหน่วยความจำและการคงสถานะไว้ ส่วนการเชื่อมต่อใหม่เป็นการทดสอบการบีบอัดบริบทและการกู้คืนสถานะ ขณะที่การตัดการเชื่อมต่อของไคลเอ็นต์ทั่วไปทำให้เห็นความขัดแย้งในการปิดระบบ ปัญหาเหล่านี้แทบไม่ปรากฏในการทดสอบโหลดระยะสั้น เนื่องจากขึ้นอยู่กับระยะเวลา สถานะที่สะสม และการทำงานระหว่างบริการต่างๆ
สุดท้าย การทดสอบในระบบจริงทำให้เราต้องปรับปรุงการติดตามสถานะระบบและการควบคุมการทยอยเปิดใช้งาน เราพบเมตริกที่นำความล่าช้าจากหลายสาเหตุมารวมกัน แดชบอร์ดที่แสดงเพียงข้อมูลภาพรวมจนบดบังเอนจินบางตัวที่ทำงานผิดปกติ และการกำหนดค่าของระบบที่ผ่านการทดสอบกับระบบที่นำไปใช้งานจริงไม่ตรงกัน เราจึงเพิ่มข้อมูลเทเลเมทรีที่ละเอียดขึ้น ตรวจสอบความถูกต้องโดยเทียบกับการกำหนดค่ามาตรฐานที่เชื่อถือได้ ทยอยเพิ่มทราฟฟิกเป็นระยะ และเพิ่มความสามารถในการแยกหรือปิดใช้งานเส้นทางแต่ละเส้นทางได้อย่างรวดเร็ว การทดสอบแบบเงียบจึงกลายเป็นการซ้อมเปิดตัวระบบล่วงหน้า ไม่ใช่แค่เพื่อดูว่าระบบรองรับทราฟฟิกได้มากเพียงใด แต่ยังรวมถึงการประเมินว่าเราจะตรวจพบ ควบคุม และกู้คืนระบบจากความขัดข้องได้รวดเร็วเพียงใด
การทำให้ GPT‑Live รองรับผู้ใช้ในระดับเดียวกับ ChatGPT จำเป็นต้องสร้างระบบใหม่ทั้งหมด โดยยึดหลักสำคัญเพียงข้อเดียว นั่นคือเสียงต้องไหลลื่นอย่างต่อเนื่อง การอนุมานแบบสตรีมมิงช่วยส่งข้อมูลเสียงให้โมเดลแบบฟูลดูเพล็กซ์ได้อย่างต่อเนื่อง เส้นทางสื่อเฉพาะช่วยให้ส่งเฟรมได้อย่างเสถียร การมอบหมายงานแบบอะซิงโครนัสช่วยให้การคิดที่ซับซ้อนยิ่งขึ้นทำงานคู่ขนานกันได้ ส่วนการรับส่งข้อมูลที่ปรับแต่งมาอย่างมีประสิทธิภาพช่วยให้ระบบตอบสนองได้รวดเร็วตลอดเส้นทางไปจนถึงผู้ใช้
สถาปัตยกรรมเบื้องหลัง GPT‑Live กำลังพัฒนาเป็นแพลตฟอร์มที่กว้างขึ้นสำหรับการโต้ตอบแบบเรียลไทม์แล้ว สถาปัตยกรรมนี้ขับเคลื่อน ChatGPT Voice ซึ่งกำลังขยายขีดความสามารถจากการสนทนาไปสู่การประสานงานระหว่างเอเจนต์ และจะเป็นรากฐานของ GPT‑Live API ที่กำลังจะเปิดตัว ในอนาคตประสบการณ์เสียงจะครอบคลุมอุปกรณ์ แอป และรูปแบบที่หลากหลายยิ่งขึ้น โดยไม่สูญเสียความฉับไวที่ทำให้การสนทนาด้วยเสียงรู้สึกเหมือนเกิดขึ้นสดๆ
หากคุณอยากแก้โจทย์ด้านวิศวกรรมแบบนี้ มาร่วมงานกับเรา
