OpenAI 4 月 5 日公布 chi tiết về cơ sở hạ tầng AI giọng nói—nhằm phục vụ dịch vụ AI giọng nói cho 900 triệu người dùng hoạt động hằng tuần (Weekly Active Users), đội ngũ thiết kế lại stack WebRTC, chuyển cấu trúc tầng kết nối media từ mô hình truyền thống “một cổng cho một session” sang mô hình relay mỏng viết bằng Go, và gom toàn bộ trạng thái của các session WebRTC vào một dịch vụ có tên “transceiver”. Blog chính thức của OpenAI giải thích rằng kiến trúc này đồng thời hỗ trợ chế độ giọng nói của ChatGPT, Realtime API, cùng nhiều dự án nghiên cứu khác. Với bất kỳ đội nhóm nào đang làm kỹ thuật cho AI giọng nói, đây là tài liệu kỹ thuật hiếm hoi về câu hỏi “làm thế nào để vận hành được AI giọng nói quy mô toàn cầu”.
Ba ràng buộc kỹ thuật: WebRTC truyền thống đều “đâm tường” ở quy mô OpenAI
Nhóm kỹ sư OpenAI trong bài viết nêu rõ ba ràng buộc “khi phóng to quy mô thì các thứ lại va chạm lẫn nhau”:
Cách kết thúc media theo kiểu truyền thống “một session một cổng” (per-session port termination) không phù hợp với hạ tầng của OpenAI—khi 900 triệu người dùng mỗi tuần có thể đồng thời mở các session giọng nói, thiết kế mỗi session chiếm một cổng sẽ làm cạn kiệt tài nguyên mạng
Các phiên hội thoại có trạng thái của ICE (Interactive Connectivity Establishment) và DTLS (Datagram Transport Layer Security) cần một “chủ sở hữu” ổn định—trong hệ thống phân tán, nếu trạng thái session bị chia sẻ bởi nhiều dịch vụ, thì việc chịu lỗi và di chuyển sẽ cực kỳ phức tạp
Tuyến đường toàn cầu phải duy trì độ trễ chặng đầu thấp (first-hop latency)—cảm giác “tự nhiên” của AI giọng nói phụ thuộc vào turn-taking (chuyển lượt hội thoại) mượt mà; nếu chặng đầu vượt quá 100ms thì sẽ thấy rõ bị ngắt quãng
Danh sách nhu cầu của OpenAI cũng nêu rõ: phủ sóng toàn cầu (bao trùm hơn 900 triệu người dùng), thiết lập session nhanh (người dùng vừa mở lời là có thể nói), và thời gian round-trip media thấp và ổn định (bao gồm độ jitter thấp và mất gói thấp).
Giải pháp: relay mỏng viết bằng Go + dịch vụ transceiver tập trung
Kiến trúc của OpenAI chia làm hai lớp:
Lớp Relay—viết bằng Go, thực hiện cố tình giữ ở mức đơn giản. Một process Go thông thường, đọc gói tin từ socket lấy phần tiêu đề, cập nhật trạng thái lưu lượng rất ít, chuyển tiếp gói tin, không kết thúc WebRTC. Đây là chìa khóa để relay có thể mở rộng theo chiều ngang—không cần duy trì trạng thái đầy đủ của WebRTC, việc thay đổi qua lại giữa các relay không gây đau đầu, và lỗi ở một điểm cũng không làm gián đoạn toàn bộ session.
Lớp Transceiver—dịch vụ duy nhất sở hữu trạng thái của WebRTC session, bao gồm kiểm tra kết nối ICE, bắt tay DTLS, khóa mã hóa SRTP, và quản lý vòng đời session. Gom các trạng thái này vào một dịch vụ để suy luận về “ai sở hữu session” dễ hơn, còn các dịch vụ backend có thể mở rộng như dịch vụ thông thường, không cần tự đóng vai peer WebRTC.
Điểm tinh tế của thiết kế này nằm ở chỗ: tách nghiêm ngặt phần “cần trạng thái” và phần “không trạng thái”. Relay là mặt dữ liệu không trạng thái (có thể nhân bản nhiều), còn transceiver là mặt điều khiển có trạng thái (ít nhưng đầy đủ trạng thái). Việc phân lớp này cũng giúp OpenAI có thể mở rộng theo chiều ngang tùy theo nhu cầu sử dụng, mà không cần lo “bùng nổ” số lượng kết nối WebRTC.
Vì sao dùng Go: logic lựa chọn cho kỹ thuật AI giọng nói
Bài viết của OpenAI nêu rõ relay dùng Go và cố tình giữ giao diện hẹp. Logic kỹ sư đằng sau lựa chọn này:
goroutine của Go hỗ trợ tự nhiên các tác vụ IO-bound như “xử lý hàng chục nghìn kết nối trên một cổng”, không cần vòng lặp sự kiện phức tạp
Gói net của thư viện chuẩn có thể trực tiếp đọc các gói UDP, không cần ràng buộc thư viện C
Sau khi biên dịch tạo ra một binary tĩnh duy nhất; triển khai, đóng gói container và hỗ trợ đa kiến trúc (x86/ARM) đều dễ
Quản lý bộ nhớ của Go phù hợp với “rất nhiều đối tượng ngắn tuổi” (mỗi gói cần được parse), và thời gian tạm dừng do GC có thể kiểm soát
Cũng vì thế mà Go có tỷ lệ thâm nhập tăng liên tục trong lớp hạ tầng hiện đại (Cloudflare, Tailscale, HashiCorp…): không phải vì “Go giỏi hơn ngôn ngữ khác”, mà vì “Go phù hợp nhất với các tình huống hạ tầng cần IO-bound và cần mở rộng theo chiều ngang—viết lên trực tiếp nhất”.
Đối vị của Cloudflare: chiến trường Realtime Voice AI
Đồng thời vào đầu tháng 5, Cloudflare cũng công bố blog kỹ thuật〈Cloudflare là nơi tốt nhất để xây dựng đại lý giọng nói thời gian thực〉, đưa ra giải pháp của riêng mình đối vị với OpenAI. Hai hướng đi khác nhau:
OpenAI: tự xây stack WebRTC relay/transceiver, không phụ thuộc bên thứ ba, và đưa cả tầng media vào nền tảng công nghệ của mình
Cloudflare: biến dịch vụ media WebRTC thành phần mở rộng của nền tảng Workers của họ, cung cấp cho nhà phát triển cơ sở hạ tầng “một điểm chạm”
Với các đội nhóm AI quy mô nhỏ và vừa, hướng của Cloudflare thực dụng hơn—chỉ cần gọi API, không phải tự xây dựng hạ tầng WebRTC. Với các đội nhóm quy mô như OpenAI, tự xây dựng là con đường bắt buộc—SLA của dịch vụ bên ngoài, cấu trúc tính phí và phân bổ địa lý không thể nào khớp hoàn toàn.
Theo dõi tiếp theo: transceiver mã nguồn mở, mức độ mở rộng Realtime API, phản ứng của đối thủ
Những trọng điểm quan sát giai đoạn tới:
OpenAI có đưa transceiver/relay ra mã nguồn mở không—Anthropic, Google, xAI… đều đang tự xây stack giọng nói; nếu OpenAI mã nguồn mở, nó có thể trở thành tiêu chuẩn của ngành
Việc tính phí và quy mô của Realtime API—hiện tại chủ yếu dựa vào việc trích từ gói đăng ký ChatGPT; nếu doanh thu từ API tăng lên, liệu nó có trở thành một mảng sản phẩm độc lập hay không
Đối ứng của Anthropic và Google—Claude và Gemini đều đã hỗ trợ giọng nói, nhưng về độ trễ và quy mô so với OpenAI vẫn còn khoảng cách; lần tiết lộ kỹ thuật này liệu có thúc đẩy họ theo kịp ở mặt kỹ thuật hay không
Với nhà phát triển AI ứng dụng tại Đài Loan, AI giọng nói là mặt trận quan trọng của nửa cuối năm 2026—các kịch bản như chăm sóc khách hàng, giáo dục, xe hơi, IoT đều cần hội thoại độ trễ thấp. Lần lộ kỹ thuật lần này của OpenAI là một trong những tham chiếu quan trọng nhất để đánh giá “nên tự xây stack giọng nói hay dùng API bên thứ ba”.
Bài viết này về việc OpenAI tái cấu trúc stack giọng nói WebRTC: lõi là relay viết bằng Go cho 900M người dùng hoạt động hằng tuần; lần đầu xuất hiện tại 鏈新聞 ABMedia.
