Đẩy nhanh quy trình làm việc của các tác nhân với WebSockets trong API phản hồi

Khi bạn yêu cầu Codex sửa lỗi, công cụ này sẽ quét qua cơ sở mã của bạn để tìm các tệp có liên quan, đọc chúng để nắm ngữ cảnh, thực hiện chỉnh sửa và chạy thử nghiệm để xác minh rằng bản sửa lỗi đã hoạt động. Về bản chất, điều đó có nghĩa là có hàng chục yêu cầu qua lại đến Responses API: xác định hành động tiếp theo của mô hình, chạy một công cụ trên máy tính của bạn, gửi dữ liệu đầu ra của công cụ trở lại API, rồi lặp lại.

Tất cả những yêu cầu này có thể cộng lại thành vài phút mà người dùng phải chờ Codex hoàn thành các tác vụ phức tạp. Xét về độ trễ, vòng lặp tác nhân Codex dành phần lớn thời gian cho ba giai đoạn chính: làm việc trong các dịch vụ API (để xác thực và xử lý yêu cầu), suy luận mô hình và thời gian phía máy khách (chạy các công cụ và xây dựng ngữ cảnh mô hình). Giai đoạn suy luận là giai đoạn mà mô hình chạy trên GPU để tạo ra các token mới. Trước đây, việc chạy suy luận LLM trên GPU là phần chậm nhất trong vòng lặp tác nhân, do đó chi phí dịch vụ API rất dễ che giấu. Khi quá trình suy luận trở nên nhanh hơn, phần chi phí phụ trội tích lũy của API từ quá trình triển khai tác nhân trở nên đáng kể hơn nhiều.

Trong bài viết này, chúng tôi sẽ giải thích cách chúng tôi đã làm cho các vòng lặp tác nhân sử dụng API nhanh hơn 40% từ đầu đến cuối, giúp người dùng trải nghiệm tốc độ suy luận tăng từ 65 lên gần 1.000 token mỗi giây. Chúng tôi đã giải quyết vấn đề này thông qua cơ chế lưu đệm, loại bỏ các bước trung chuyển mạng không cần thiết, cải thiện hệ thống an toàn để nhanh chóng phát hiện và gắn cờ các vấn đề, và—quan trọng nhất—xây dựng một phương pháp để thiết lập một kết nối liên tục tới API Phản hồi, thay vì phải thực hiện một loạt lệnh gọi API đồng bộ.

Trong API phản hồi, các mô hình chủ lực trước đây như GPT‑5 và GPT‑5.2 hoạt động với tốc độ khoảng 65 token mỗi giây (TPS). Đối với việc ra mắt GPT‑5.3‑Codex‑Spark, một mô hình lập trình tốc độ cao, mục tiêu của chúng tôi là nhanh hơn gấp một bậc độ lớn: hơn 1.000 TPS, nhờ phần cứng Cerebras chuyên dụng được tối ưu hóa cho suy luận LLM. Để đảm bảo người dùng có thể trải nghiệm tốc độ thực sự của mô hình mới này, chúng tôi đã phải giảm chi phí phụ của API. 

Vào khoảng tháng 11 năm 2025, chúng tôi đã triển khai một đợt nước rút về hiệu suất cho API Phản hồi, đưa vào nhiều biện pháp tối ưu hóa đối với độ trễ trên đường dẫn quan trọng cho một yêu cầu đơn lẻ: 

• Lưu vào bộ nhớ tạm các token đã được kết xuất và cấu hình mô hình trong bộ nhớ để bỏ qua các lệnh gọi mạng và bước phân tách token tốn kém cho các phản hồi nhiều lượt
• Giảm độ trễ qua các chặng mạng bằng cách loại bỏ các lệnh gọi đến các dịch vụ trung gian (ví dụ: xử lý độ phân giải hình ảnh) và gọi trực tiếp dịch vụ suy luận.
• Cải thiện hệ thống an toàn của chúng tôi để có thể chạy một số bộ phân loại nhằm đánh dấu các cuộc trò chuyện nhanh hơn

Với những cải tiến này, chúng tôi đã ghi nhận mức cải thiện gần 45% về thời gian đến token đầu tiên (TTFT)—chỉ số phản ánh mức độ phản hồi nhanh của API—nhưng những cải tiến này vẫn chưa đủ nhanh đối với GPT‑5.3‑Codex‑Spark. Ngay cả với những cải tiến này, chi phí xử lý phát sinh của API Phản hồi vẫn quá lớn so với tốc độ của mô hình—tức là người dùng phải chờ các CPU chạy API của chúng tôi trước khi họ có thể sử dụng các GPU phục vụ mô hình.

Vấn đề cốt lõi nằm ở cấu trúc: chúng tôi coi mỗi yêu cầu Codex là độc lập, xử lý trạng thái hội thoại và các ngữ cảnh có thể tái sử dụng khác trong mỗi yêu cầu tiếp theo. Ngay cả khi phần lớn cuộc trò chuyện không thay đổi, chúng tôi vẫn trả tiền cho công việc liên quan đến toàn bộ lịch sử. Khi cuộc trò chuyện kéo dài hơn, quá trình xử lý lặp đi lặp lại đó trở nên tốn kém hơn.

Để tinh gọn thiết kế, chúng tôi đã suy nghĩ lại về giao thức truyền tải: liệu chúng tôi có thể duy trì một kết nối liên tục và lưu trạng thái vào bộ nhớ đệm, thay vì thiết lập một kết nối mới qua HTTP và gửi toàn bộ lịch sử cuộc trò chuyện cho mỗi yêu cầu tiếp theo hay không? Ý tưởng là chỉ gửi bất kỳ thông tin mới nào cần được xác thực và xử lý, đồng thời lưu trạng thái có thể tái sử dụng trong bộ nhớ đệm trong suốt thời gian tồn tại của kết nối. Điều này sẽ giảm chi phí phát sinh do công việc trùng lặp.

Chúng tôi đã xem xét một vài phương pháp khác nhau, bao gồm WebSockets và truyền dữ liệu hai chiều gRPC. Chúng tôi đã chọn WebSockets vì với vai trò là một giao thức truyền tải thông điệp đơn giản, người dùng sẽ không phải thay đổi cấu trúc đầu vào và đầu ra của Responses API. Nó thân thiện với nhà phát triển và phù hợp với kiến trúc hiện có của chúng tôi mà không gây ra nhiều xáo trộn.

Nguyên mẫu WebSocket đầu tiên đã thay đổi những gì chúng tôi nghĩ là có thể đối với độ trễ của Responses API. Một kỹ sư trong nhóm Codex với chuyên môn sâu rộng trên toàn bộ ngăn xếp API đã tạo ra một nguyên mẫu bằng cách chạy một tác nhân Codex qua đêm.

Trong nguyên mẫu đó, việc triển khai đại lý được mô hình hóa như một Phản hồi duy nhất chạy lâu dài. Khi sử dụng các tính năng của asyncio, Responses API sẽ chặn bất đồng bộ trong vòng lặp lấy mẫu sau khi một lệnh gọi công cụ được lấy mẫu, và Responses API sẽ gửi một sự kiện response.done trở lại máy khách. Sau khi thực thi lệnh gọi công cụ, các máy khách sẽ gửi lại sự kiện response.append với kết quả của công cụ, điều này sẽ giải phóng vòng lặp lấy mẫu và cho phép mô hình tiếp tục hoạt động.

Một phép so sánh ở đây là coi lệnh gọi công cụ cục bộ như một lệnh gọi công cụ được lưu trữ. Khi mô hình gọi tìm kiếm trên web, vòng lặp suy luận sẽ bị chặn, gọi dịch vụ tìm kiếm trên web và đưa phản hồi của dịch vụ vào ngữ cảnh của mô hình. Trong thiết kế của chúng tôi, chúng tôi cũng làm tương tự; nhưng thay vì gọi một dịch vụ từ xa, chúng tôi đã gửi lệnh gọi công cụ của mô hình trở lại máy khách thông qua WebSocket. Khi khách hàng phản hồi, chúng tôi đã đặt phản hồi từ công cụ của khách hàng vào ngữ cảnh và tiếp tục lấy mẫu.

Thiết kế này cực kỳ hiệu quả vì nó đã loại bỏ công việc API lặp đi lặp lại trong suốt quá trình triển khai tác nhân. Chúng ta có thể thực hiện công việc tiền suy luận một lần, tạm dừng để thực thi công cụ, và thực hiện công việc hậu suy luận một lần vào cuối cùng.

Thật không may, điều này đi kèm với cái giá là một cấu trúc API kém quen thuộc hơn và phức tạp hơn. Chúng tôi muốn các nhà phát triển có thể bỏ qua hỗ trợ WebSocket mà không cần phải viết lại tích hợp API của họ xung quanh một chế độ tương tác mới.

Đối với phiên bản chúng tôi đã ra mắt, chúng tôi đã quay lại một cách thức quen thuộc: tiếp tục sử dụng response.create với cùng phần nội dung yêu cầu, và sử dụng previous_response_id để tiếp tục ngữ cảnh cuộc trò chuyện từ trạng thái của phản hồi trước đó.

Trên kết nối WebSocket, máy chủ duy trì một bộ nhớ đệm trong bộ nhớ theo phạm vi kết nối cho trạng thái phản hồi trước đó. Khi một response.create tiếp theo bao gồm previous_response_id, chúng tôi sẽ lấy trạng thái đó từ bộ nhớ đệm thay vì xây dựng lại toàn bộ cuộc trò chuyện từ đầu.

Trạng thái được lưu vào bộ nhớ đệm đó bao gồm:

• Đối tượng phản hồi trước đó
• Các mục đầu vào và đầu ra trước đó
• Định nghĩa công cụ và không gian định danh
• Các tạo tác lấy mẫu có thể tái sử dụng, chẳng hạn như các token đã hiển thị trước đó

Bằng cách tái sử dụng trạng thái phản hồi trước đó trong bộ nhớ, chúng tôi đã thực hiện được một số tối ưu hóa lớn:

• Cho phép một số trình phân loại an toàn và trình xác thực yêu cầu của chúng tôi chỉ xử lý dữ liệu đầu vào mới thay vì toàn bộ lịch sử mỗi lần
• Duy trì một bộ nhớ đệm trong bộ nhớ cho các token đã được kết xuất mà chúng tôi nối thêm vào để có thể bỏ qua việc phân tách token không cần thiết
• Tái sử dụng logic phân giải/định tuyến mô hình thành công của chúng tôi trên các yêu cầu 
• Chồng lấp các tác vụ sau suy luận không chặn như lập hóa đơn với các yêu cầu tiếp theo

Mục tiêu là tiến gần nhất có thể đến nguyên mẫu với chi phí phụ trội tối thiểu, nhưng vẫn giữ cấu trúc API mà các nhà phát triển đã quen thuộc và xây dựng dựa trên đó.

Sau hai tháng tập trung xây dựng chế độ WebSocket, chúng tôi đã ra mắt phiên bản alpha với các công ty khởi nghiệp tác nhân lập trình để họ có thể tích hợp nó vào cơ sở hạ tầng của mình và tăng lưu lượng truy cập một cách an toàn. Người dùng phiên bản Alpha rất hài lòng, báo cáo rằng quy trình làm việc với tác nhân của họ đã được cải thiện tới 40%⁠(mở trong cửa sổ mới) . Nhận được phản hồi tích cực từ phiên bản alpha, chúng tôi đã sẵn sàng ra mắt sản phẩm.

Kết quả của việc ra mắt đến ngay lập tức. Codex nhanh chóng chuyển phần lớn lưu lượng truy cập API Phản hồi của họ sang chế độ WebSocket, và nhận thấy sự cải thiện đáng kể về độ trễ. Với GPT‑5.3‑Codex‑Spark, chúng tôi đã đạt được mục tiêu 1.000 giao dịch mỗi giây (TPS) và ghi nhận những đợt tăng đột biến lên đến 4.000 TPS, cho thấy API Phản hồi có thể theo kịp tốc độ suy luận nhanh hơn nhiều trong lưu lượng truy cập thực tế. Tác động này cũng nhanh chóng lan rộng trong cộng đồng lập trình viên:

• Codex đã nhanh chóng chuyển phần lớn lưu lượng truy cập của họ sang WebSockets. Người dùng Codex đang sử dụng các mô hình mới nhất như GPT‑5.3‑Codex⁠(mở trong cửa sổ mới), GPT‑5.4⁠(mở trong cửa sổ mới), và hơn thế nữa, tất cả đều được hưởng lợi từ tốc độ được tăng cường của chế độ WebSocket.
• Vercel đã tích hợp chế độ WebSocket vào AI SDK và ghi nhận độ trễ giảm lên đến 40%⁠(mở trong cửa sổ mới).
• Quy trình làm việc nhiều tệp của Cline nhanh hơn 39%⁠(mở trong cửa sổ mới).
• Các mô hình OpenAI trong Cursor trở nên nhanh hơn tới 30%⁠(mở trong cửa sổ mới).

Chế độ WebSocket là một trong những khả năng mới quan trọng nhất của API Phản hồi kể từ khi ra mắt vào tháng 3 năm 2025. Chúng tôi đã đi từ ý tưởng đến triển khai và vận hành trong môi trường production chỉ trong vài tuần nhờ sự hợp tác chặt chẽ giữa đội ngũ API của OpenAI và đội ngũ Codex. Điều này không chỉ cải thiện đáng kể độ trễ triển khai tác nhân mà còn hỗ trợ nhu cầu ngày càng tăng của các nhà phát triển: khi quá trình suy luận mô hình trở nên nhanh hơn, các dịch vụ và hệ thống xung quanh quá trình suy luận cũng cần phải tăng tốc để chuyển những lợi ích này đến người dùng.