Tại sao WebRTC lại là vấn đề lớn của OpenAI và giải pháp thay thế là gì?

Mới đây, OpenAI đã đăng một bài viết kỹ thuật chi tiết về hạ tầng của họ, và nó đã kích hoạt một cuộc tranh luận sôi nổi trong cộng đồng công nghệ. Là một kỹ sư đã từng xây dựng WebRTC SFU (Selective Forwarding Unit) cho Twitch và Discord, tôi tin rằng việc sử dụng WebRTC cho Voice AI là một sai lầm. WebRTC không phù hợp với Voice AI và thực chất chính nó là nguồn gốc của vấn đề.

WebRTC quá hung hăng với dữ liệu âm thanh

Hãy tưởng tượng bạn mở ứng dụng OpenAI trên điện thoại và hỏi một câu phức tạp. WebRTC được thiết kế để ưu tiên độ trễ thấp bằng cách chủ động loại bỏ các gói tin audio khi mạng kém. Điều này có ý nghĩa trong các cuộc gọi hội nghị, nơi sự tương tác tức thời là quan trọng nhất.

Ví dụ về độ trễ

Tuy nhiên, với Voice AI, người dùng sẽ chấp nhận chờ thêm 200ms để đảm bảo câu lệnh (prompt) được truyền tải chính xác đầy đủ. Một câu lệnh bị rớt gói tin sẽ dẫn đến kết quả rác rưởi từ AI, và người dùng sẽ phải hỏi lại. WebRTC không cho phép tái truyền gói tin audio trong trình duyệt một cách dễ dàng, và bộ đệm rung (jitter buffer) của nó quá nhỏ, gây ra hiện tượng âm thanh bị méo tiếng. Thay vì tối ưu hóa cho chất lượng câu lệnh, WebRTC lại hy sinh nó để lấy tốc độ.

Vấn đề về bộ đệm và độ trễ giả tạo

Trong Voice AI, quá trình Text-to-Speech (TTS) thường nhanh hơn thời gian thực. Ví dụ, GPU mất 2 giây để tạo ra 8 giây âm thanh. Trong thế giới lý tưởng, chúng ta sẽ truyền tải âm thanh này ngay khi nó được tạo ra để client phát lại, giúp có sẵn bộ đệm đệm khi mạng có sự cố.

Tuy nhiên, WebRTC không có cơ chế bộ đệm này; nó phát âm thanh dựa trên thời gian đến. Để khắc phục, OpenAI phải thêm độ trễ nhân tạo vào mỗi gói tin trước khi gửi, nhưng sau đó WebRTC lại tích cực loại bỏ các gói tin đó để "giữ độ trễ thấp". Đây là một vòng luẩn quẩn vô nghĩa, giống như việc chia sẻ màn hình một video YouTube thay vì để nó tự bộ đệm (buffer).

WebRTC là một tập hợp các tiêu chuẩn trong một chiếc áo choàng

WebRTC cực kỳ phức tạp. Nó bao gồm khoảng 45 RFCs và nhiều tiêu chuẩn thực tế khác. Việc triển khai nó là một cơn ác mộng với các giao thức như STUN, DTLS, SRTP, v.v.

WebRTC phức tạp

Hầu hết các dịch vụ lớn đều phải bỏ qua các đặc tả WebRTC chuẩn để có thể hoạt động được. Ví dụ, tại Twitch, tôi phải lưu trữ server WebRTC trên cổng UDP:443 (cổng dành cho HTTPS/QUIC) để lách qua các tường lửa. Discord sử dụng hàng loạt cổng riêng biệt. OpenAI cũng phải sử dụng một giải pháp cân bằng tải (load balancing) tùy chỉnh cực kỳ phức tạp, dựa vào Redis để lưu trữ trạng thái mapping giữa địa chỉ IP người dùng và backend server. Đây là một bản vá (hack) cần thiết do lỗi thiết kế cốt lõi của giao thức.

QUIC: Giải pháp cho vấn đề cân bằng tải

Nếu không dùng WebRTC, thì nên dùng gì cho Voice AI? Câu trả lời là QUIC (nền tảng của HTTP/3) và WebTransport.

Độ trễ Round Trip

WebRTC yêu cầu tối thiểu 8 vòng khứ hồi (Round Trip Time - RTT) để thiết lập kết nối, bao gồm các bước ICE, DTLS, SCTP... Trong khi đó, QUIC chỉ cần 1 RTT để thiết lập kết nối và bảo mật.

Điểm quan trọng nhất của QUIC là Connection ID. Thay vì định tuyến dựa trên địa chỉ IP nguồn (có thể thay đổi khi người dùng chuyển từ WiFi sang 4G), QUIC sử dụng Connection ID do máy chủ chọn. Điều này cho phép cân bằng tải không trạng thái (stateless load balancing). Máy chủ backend có thể mã hóa ID của mình vào Connection ID, và load balancer chỉ cần đọc ID này để chuyển tiếp gói tin đúng nơi mà không cần cơ sở dữ liệu hay trạng thái chia sẻ.

Anycast và Unicast với QUIC

QUIC còn hỗ trợ tính năng Preferred Address, cho phép sử dụng Anycast cho bắt tay và Unicast cho kết nối trạng thái. Điều này giúp việc mở rộng quy mô (scaling) trở nên dễ dàng hơn bao giờ hết. Khi máy chủ quá tải, nó chỉ cần ngừng quảng cáo địa chỉ Anycast mà không làm mất các kết nối hiện tại đang chạy trên địa chỉ Unicast.

Tóm lại

WebRTC làm tổn thương sản phẩm của bạn (do mất gói tin), làm tổn thương khả năng cân bằng tải (do phức tạp và cần trạng thái), và quá khó để triển khai. Ngược lại, QUIC yêu thích sản phẩm của bạn, yêu thích cân bằng tải và dễ dàng mở rộng.

Các kỹ sư tại OpenAI rất xuất sắc và đang chịu áp lực khổng lồ phải mở rộng quy mô ngay lập tức. Tuy nhiên, việc chọn WebRTC cho Voice AI có vẻ như là một giải pháp hiển nhiên nhưng không phù hợp. Thay vì cố gắng sửa chữa (fork) WebRTC, hãy chuyển sang QUIC và WebTransport để xây dựng một giải pháp bền vững hơn cho tương lai.