OpenAI 5 月 4 日公布รายละเอียดโครงสร้างพื้นฐานสำหรับ AI ด้านเสียง—เพื่อรองรับบริการ AI เสียงที่มีผู้ใช้งานรายสัปดาห์ถึง 900 ล้านราย (Weekly Active Users) ทีมงานได้ออกแบบสแต็ก WebRTC ใหม่ โดยเปลี่ยนชั้นการเชื่อมต่อสื่อจากสถาปัตยกรรมแบบเดิมที่ “หนึ่งพอร์ตต่อหนึ่ง session” มาเป็นรีเลย์แบบบาง (thin relay) ที่เขียนด้วย Go และรวมสถานะของ WebRTC session ทั้งหมดไว้ที่บริการหนึ่งชื่อ “transceiver” บล็อกทางการของ OpenAI อธิบายว่า สถาปัตยกรรมชุดนี้รองรับทั้งโหมดเสียงของ ChatGPT, Realtime API และโครงการวิจัยอีกหลายรายการ สำหรับทีมที่กำลังทำวิศวกรรม AI ด้านเสียง นี่ถือเป็นเอกสารด้านเทคนิคที่หายากมากสำหรับคำถามว่า “ระบบเสียง AI ระดับโลกสร้างและรองรับกันอย่างไร”
ข้อจำกัดทางเทคนิค 3 ประการ: WebRTC แบบเดิมทั้งหมดชนเพดานในระดับ OpenAI
ทีมวิศวกรรมของ OpenAI ระบุชัดเจน 3 ข้อจำกัดที่ “ชนกันเองเมื่อขยายสเกล” ดังนี้
วิธี “สิ้นสุดสื่อต่อหนึ่ง session หนึ่งพอร์ต” (per-session port termination) ไม่เหมาะกับโครงสร้างพื้นฐานของ OpenAI—เมื่อมีผู้ใช้งานรายสัปดาห์ 900 ล้านรายที่อาจเปิด session เสียงพร้อมกัน แต่ละ session ก็ใช้หนึ่งพอร์ต การออกแบบเช่นนี้จะทำให้ทรัพยากรเครือข่ายหมดไป
ICE (Interactive Connectivity Establishment) และ DTLS (Datagram Transport Layer Security) ที่มีสถานะ ต้องมีเจ้าของที่เสถียร—ในระบบแบบกระจาย หากสถานะของ session ถูกแบ่งไปหลายบริการ การทำ fault tolerance และการย้าย (migration) จะซับซ้อนมาก
การกำหนดเส้นทางทั่วโลกต้องรักษา first-hop latency ต่ำ—ความ “เป็นธรรมชาติ” ของ AI ด้านเสียงขึ้นอยู่กับ turn-taking ความลื่นไหลของการสลับบทสนทนา หาก first hop เกิน 100ms จะเห็นอาการสะดุดชัดเจน
เช็กลิสต์ความต้องการของ OpenAI ก็ระบุชัดเจนเช่นกัน: การครอบคลุมผู้ใช้ทั่วโลก (ครอบคลุมมากกว่า 900 ล้านราย), การสร้าง session อย่างรวดเร็ว (ผู้ใช้พูดแล้วเริ่มใช้งานได้ทันที), และ low/stable media round-trip time (รวมถึง jitter ต่ำและแพ็กเก็ตสูญหายต่ำ)
วิธีแก้: รีเลย์แบบบางที่เขียนด้วย Go + บริการ transceiver แบบรวมศูนย์
สถาปัตยกรรมของ OpenAI แบ่งเป็น 2 ชั้น:
ชั้น Relay—เขียนด้วย Go และจงใจทำให้เรียบง่าย หนึ่งโพรเซส Go ทั่วไป อ่านแพ็กเก็ตจาก socket เพื่อดูหัวแพ็กเก็ต อัปเดตสถานะทราฟฟิกเพียงเล็กน้อย ส่งต่อแพ็กเก็ต และไม่จบ WebRTC นี่คือกุญแจที่ทำให้ relay ขยายแบบแนวนอนได้—ไม่จำเป็นต้องรักษาสถานะ WebRTC แบบครบถ้วน ระหว่าง relay เปลี่ยนตัวกันได้แบบไม่เจ็บปวด และ single point of failure ก็ไม่ทำให้ session ทั้งหมดสะดุด
ชั้น Transceiver—เป็นบริการเดียวที่เป็นเจ้าของ WebRTC session state ประกอบด้วยการตรวจสอบการเชื่อมต่อ ICE, การจับมือ DTLS, กุญแจการเข้ารหัส SRTP และการจัดการ lifecycle ของ session การรวมสถานะเหล่านี้ไว้ที่บริการเดียว ทำให้การเป็นเจ้าของ session ตีความได้ง่ายขึ้น และบริการฝั่งหลังสามารถขยายเหมือนบริการทั่วไป โดยไม่ต้องเป็น WebRTC peer เอง
จุดที่น่าสนใจของดีไซน์นี้อยู่ที่การแยก “ส่วนที่ต้องมีสถานะ” กับ “ส่วนที่ไร้สถานะ” ออกจากกันอย่างเคร่งครัด Relay คือ data plane แบบไร้สถานะ (ทำสำเนาได้จำนวนมาก) ส่วน transceiver คือ control plane แบบมีสถานะ (มีจำนวนน้อยแต่ถือสถานะครบถ้วน) การแบ่งชั้นนี้ยังทำให้ OpenAI สามารถขยายตามการใช้งานแนวนอนได้ตามต้องการ โดยไม่ต้องกังวลจำนวน WebRTC connection ที่อาจพุ่งจนระเบิด
ทำไมใช้ Go: ตรรกะการเลือกในงานวิศวกรรมเสียง AI
เอกสารของ OpenAI ระบุชัดว่าใช้ Go สำหรับ relay และจงใจทำให้ขอบเขตแคบ เหตุผลเชิงวิศวกรรมเบื้องหลังได้แก่:
goroutine ของ Go รองรับงานประเภท IO-bound อย่าง “การประมวลผลหลายหมื่นการเชื่อมต่อต่อพอร์ต” ได้โดยธรรมชาติ ไม่จำเป็นต้องทำ event loop ที่ซับซ้อน
แพ็กเกจ net ของไลบรารีมาตรฐานสามารถอ่าน UDP packet ได้โดยตรง ไม่ต้องผูกกับ C library
หลังคอมไพล์จะได้ binary แบบ static ตัวเดียว การดีพลอย การทำคอนเทนเนอร์ และความเข้ากันได้ข้ามสถาปัตยกรรม (x86/ARM) ทำได้ง่าย
การจัดการหน่วยความจำของ Go เหมาะกับ “ออบเจ็กต์จำนวนมากที่มีอายุสั้น” (ต้อง parse ทุกแพ็กเก็ต) และควบคุมเวลาหยุดชั่วคราวของ GC ได้
นี่ก็อธิบายว่าทำไม Go ถึงมีอัตราการแทรกเข้าไปในโครงสร้างพื้นฐานยุคใหม่ (เช่น Cloudflare, Tailscale, HashiCorp ฯลฯ) เพิ่มขึ้นอย่างต่อเนื่อง—ไม่ใช่เพราะ “Go เก่งกว่าภาษาอื่น” แต่เป็นเพราะ “Go ใช้งานได้ตรงที่สุดในสถานการณ์โครงสร้างพื้นฐานที่เป็น IO-bound และต้องขยายแนวนอน”
แง่มุมฝั่ง Cloudflare: สนามรบ Realtime Voice AI
ในช่วงเวลาเดียวกัน (ต้นเดือนพฤษภาคม) Cloudflare ก็เผยแพร่บล็อกเทคนิค <Cloudflare คือสถานที่ที่ดีที่สุดในการสร้างตัวแทนเสียงแบบเรียลไทม์> และเสนอแนวทางของตัวเองเมื่อเทียบกับ OpenAI เส้นทางของทั้งสองฝ่ายแตกต่างกัน:
OpenAI: สร้างสแต็ก WebRTC relay/transceiver เอง ไม่พึ่งพบุคคลที่สาม และรวมชั้นสื่อเข้าไปในเทคโนโลยีของตัวเอง
Cloudflare: ใช้ WebRTC media service เป็นส่วนต่อขยายของแพลตฟอร์ม Workers ของตัวเอง มอบโครงสร้างพื้นฐานแบบ “จบในที่เดียว” ให้กับนักพัฒนา
สำหรับทีมพัฒนา AI ขนาดเล็กถึงกลาง แนวทางของ Cloudflare จะใช้งานได้จริงกว่า—เรียกใช้ API ได้เลย ไม่ต้องสร้าง WebRTC infrastructure เอง สำหรับทีมระดับสเกลของ OpenAI การสร้างเองคือเส้นทางที่หลีกเลี่ยงไม่ได้—SLA ของบริการภายนอก โครงสร้างการคิดค่าบริการ และการกระจายตามภูมิศาสตร์จะไม่สามารถเข้ากันได้อย่างสมบูรณ์
การจับตาต่อไป: transceiver แบบโอเพนซอร์ส, ขนาดของ Realtime API, และการตอบสนองของคู่แข่ง
จุดจับตาสำหรับขั้นถัดไป:
OpenAI จะเปิดซอร์สส่วน transceiver/relay หรือไม่—คู่แข่งอย่าง Anthropic, Google, xAI ต่างก็สร้างสแต็กเสียงของตัวเอง หาก OpenAI เปิดซอร์ส ก็อาจกลายเป็นมาตรฐานอุตสาหกรรม
การกำหนดราคาและขนาดของ Realtime API—ตอนนี้รายได้หลักมาจากการเฉลี่ยผ่านการสมัคร ChatGPT หากรายได้จาก API เติบโต จะกลายเป็นสายผลิตภัณฑ์ที่แยกออกมาไหม
การเทียบกับ Anthropic และ Google—Claude และ Gemini รองรับเสียงอยู่แล้ว แต่เมื่อเทียบด้านความหน่วงและขนาด OpenAI ยังตามหลังหรือมีช่องว่าง การเปิดเผยทางเทคนิคครั้งนี้จะเร่งให้พวกเขาติดตามด้านวิศวกรรมหรือไม่
สำหรับนักพัฒนา AI ในไต้หวัน AI ด้านเสียงคือสนามรบสำคัญในช่วงครึ่งหลังของ 2026—ทั้งงานบริการลูกค้า การศึกษา รถยนต์ และ IoT ต้องการการสนทนาแบบหน่วงต่ำ การเปิดเผยเชิงวิศวกรรมครั้งนี้ของ OpenAI เป็นหนึ่งในข้อมูลอ้างอิงที่สำคัญที่สุดในการตัดสินใจว่า “ควรสร้างสแต็กเสียงเองหรือใช้ API จากบุคคลที่สาม”
บทความนี้ OpenAI รีแฟกเตอร์สแต็ก WebRTC ด้านเสียง: รีเลย์แกนหลักที่เขียนด้วย Go สำหรับผู้ใช้งานรายสัปดาห์ 900M เผยแพร่ครั้งแรกที่ 鏈新聞 ABMedia
