Kỹ sư OpenAI tiết lộ cách tối ưu hóa vòng lặp Agent trong ChatGPT

Việc thanh toán theo giờ GPU tính phí cho toàn bộ thời gian máy được đặt trước — bao gồm thiết lập, thời gian nhàn rỗi, chờ đợi trong hàng đợi và lỗi — vì vậy chi phí của bạn phụ thuộc vào hiệu suất cơ sở hạ tầng mà bạn không thể kiểm soát. Crusoe Serverless Fine-Tuning tính phí trên mỗi token được xử lý trong quá trình huấn luyện, giúp chi phí có thể dự đoán được dựa trên kích thước tập dữ liệu và số lượng epoch, mà không cần phải cấp phát hay điều chỉnh quy mô GPU. Tính năng dừng sớm (early stopping) sẽ kết thúc công việc và việc tính phí ngay khi mô hình của bạn ngừng cải thiện — bạn sẽ không bao giờ bị tính phí cho các epoch không mang lại độ chính xác. Các công việc chạy trên cơ sở hạ tầng được tối ưu hóa cho AI với khả năng tự động khôi phục và khởi động lại, đồng thời các checkpoint được lưu lại ở mỗi bước.

Bắt đầu

Các phòng thí nghiệm AI đang tiến triển nhanh hơn bao giờ hết và tung ra những mô hình mạnh mẽ nhất mà chúng ta từng thấy. Gần đây, Anthropic đã phát hành Fable 5, sau đó OpenAI ra mắt dòng GPT-5.6, bao gồm GPT-5.6 Sol — mô hình mạnh mẽ nhất của họ cho đến nay, Kimi phát hành Kimi K3, và Opus 5 cũng vừa ra mắt cách đây vài ngày.

Nhưng năng lực chỉ là một nửa của vấn đề. Nửa còn lại là chi phí để các mô hình này hoàn thành tác vụ, tức là chi phí cho mỗi tác vụ thành công. Chi phí thấp hơn giúp mô hình dễ tiếp cận hơn với người dùng và tiết kiệm hơn cho nhà cung cấp. Một lượng lớn nỗ lực bên trong các phòng thí nghiệm được dành cho việc tối ưu hóa và tăng hiệu suất cho mọi thành phần và lớp trong ứng dụng AI của họ nhằm giảm tổng chi phí. Ví dụ, GPT 5.6 Sol với khả năng suy luận tối đa đạt điểm cao hơn Fable 5 trên chỉ số Artificial Analysis Coding Agent Index trong khi chi phí chỉ bằng chưa đầy một nửa.

Để hiểu những kỹ thuật nào được áp dụng tại các phòng thí nghiệm tiên phong nhằm làm cho các ứng dụng AI hiệu quả hơn, chúng tôi đã gặp gỡ các kỹ sư của OpenAI, những người đã phát triển và triển khai nhiều kỹ thuật hiệu quả vào các hệ thống đằng sau Codex và ChatGPT Work. Cảm ơn Joe, Ahmed, Steve, Matthew và Philippe đã chia sẻ những thông tin chi tiết quý giá với chúng tôi.

Trong bài viết này, bạn sẽ tìm hiểu:

Điều gì thực sự xảy ra khi bạn gửi một yêu cầu đến một AI agent

Cách lớp harness cắt giảm công việc lặp lại với WebSockets bền vững, tiền tố prompt ổn định, khám phá công cụ trì hoãn và Code Mode

Cách lớp API chỉ tokenize phần thay đổi (delta) và chạy các kiểm tra an toàn song song với quá trình suy luận (inference)

Cách lớp suy luận tận dụng tối đa GPU với định tuyến nhận biết bộ nhớ đệm (cache-aware routing), quản lý KV cache, giải mã suy đoán (speculative decoding) và tách biệt quá trình prefill khỏi decode

Những gì OpenAI đã học được từ tất cả những điều này và những bài học bạn có thể áp dụng cho hệ thống của riêng mình

Khi bạn giao cho Codex hoặc ChatGPT Work một tác vụ, chẳng hạn như sửa lỗi, truy vấn đó không đi trực tiếp đến LLM. Mọi thứ phức tạp hơn thế. Một ứng dụng AI như Codex không chỉ là một LLM. Đó là một hệ thống với nhiều thành phần. Các truy vấn của người dùng đi qua nhiều lớp trước khi LLM nhìn thấy dù chỉ một token.

Nhưng tại sao chúng ta không thể gửi truy vấn của người dùng trực tiếp đến LLM? Để hiểu lý do, hãy xem LLM thực sự là gì.

LLM là một mạng thần kinh được huấn luyện để dự đoán token tiếp theo. Nó nhận một chuỗi token làm đầu vào và tạo ra một chuỗi token làm đầu ra. Nó không thể chạy lệnh shell, chỉnh sửa tệp hay ghi nhớ bất cứ điều gì giữa các lần gọi. Nhưng một tác vụ agent như “sửa lỗi này và chạy các bài kiểm tra” chủ yếu là các hành động. Cần có thứ gì đó chuyển đổi các token mà mô hình dự đoán thành các lệnh thực tế, phản hồi kết quả và tiếp tục cho đến khi tác vụ hoàn thành.

Đó là công việc của lớp harness, một hệ thống được xây dựng trên nền tảng LLM để xử lý các trách nhiệm đó. Nó nhận tác vụ của người dùng làm đầu vào, quyết định những hướng dẫn, định nghĩa công cụ và lượng lịch sử nào cần đưa vào ngữ cảnh, đồng thời duy trì lịch sử trò chuyện. Khi mô hình phản hồi bằng một lệnh gọi công cụ (tool call), harness sẽ thực thi nó theo các chính sách phê duyệt trong môi trường sandbox, đính kèm kết quả và gửi cuộc trò chuyện trở lại LLM.

Nhưng ngay cả yêu cầu của harness cũng không đi trực tiếp đến LLM. Trong các ứng dụng sẵn sàng cho sản xuất, có một lớp API (lớp ứng dụng) nằm giữa harness và điểm cuối suy luận (inference endpoint). Lớp này tồn tại vì một sản phẩm thực tế cần xử lý những thứ không được bao phủ bởi lớp harness hoặc LLM. Ví dụ: xác thực người gọi, thực thi giới hạn tốc độ (rate limits) và quan trọng là chuyển đổi văn bản thành các ID token mà LLM mong đợi, cũng như chuyển đổi các token được tạo ra trở lại thành văn bản.

Sau khi lớp API chuẩn bị ngữ cảnh và tokenize nó thành một chuỗi ID token, đã đến lúc LLM xử lý đầu vào. Đó là lớp suy luận. Đây là một điểm cuối từ xa được hỗ trợ bởi các dàn GPU, nơi lưu trữ mô hình. Công việc của nó là chạy tính toán của mô hình trên các token đã chuẩn bị và tạo ra phản hồi, cho dù đó là một lệnh gọi công cụ mới hay câu trả lời cuối cùng, một cách hiệu quả nhất có thể. Sau đó, nó chuyển các token đã tạo trở lại lớp API.

Bây giờ chúng ta đã hiểu ba lớp chính của các ứng dụng AI đại diện (agentic AI), hãy cùng xem qua một ví dụ cụ thể để thấy cách một yêu cầu di chuyển giữa các lớp này. Giả sử bạn yêu cầu Codex “truy vết lỗi hồi quy thanh toán, vá lỗi đó và chạy các bài kiểm tra.” Đây là những gì xảy ra:

Harness tập hợp các hướng dẫn, định nghĩa công cụ và tác vụ của bạn thành một yêu cầu rồi gửi đến API.

API đệm yêu cầu vào bộ nhớ, phân tích cú pháp JSON và xác thực nó: yêu cầu được định dạng đúng và mô hình đã chọn hỗ trợ mọi tính năng mà nó yêu cầu. Nó kiểm tra ai đang gọi, áp dụng giới hạn tốc độ và chạy các kiểm tra sơ bộ (preflight checks).

API hiển thị cuộc trò chuyện theo định dạng đầu vào của mô hình và tokenize nó.

API gửi các token đến lớp suy luận và bắt đầu các kiểm tra an toàn cùng lúc: các bộ phân loại tìm kiếm những thứ như tấn công mạng và nội dung vũ khí sinh học. Các kiểm tra an toàn chạy đua để hoàn thành trước khi token được tạo đầu tiên quay trở lại.

Lớp suy luận xử lý prompt và bắt đầu tạo. Đầu ra của nó ở đây không phải là câu trả lời cuối cùng; đó là một lệnh gọi công cụ: tìm kiếm trong mã nguồn từ khóa “checkout timeout.”

Các token được tạo ra chảy ngược lại API.

API chuyển đổi token thành văn bản, gói chúng vào các sự kiện API.

API truyền (stream) chúng đến harness.

Harness nhận ra lệnh gọi công cụ, chạy tìm kiếm trong sandbox của nó, đính kèm đầu ra vào cuộc trò chuyện và gửi cuộc trò chuyện đã cập nhật trở lại API.

Đây chỉ là một lần lặp. Trong thực tế, một tác vụ lặp lại vòng lặp này nhiều lần cho đến khi mô hình tạo ra bản tóm tắt cuối cùng và harness trao quyền kiểm soát lại cho người dùng. Mỗi lần lặp lại đều thực hiện lại rất nhiều công việc giống nhau đã mô tả ở trên. Ví dụ, lịch sử bị gửi lại, văn bản bị tokenize lại hoặc prompt bị xử lý lại. Loại bỏ công việc lặp lại này là cơ hội chính để tối ưu hóa. Ba phần tiếp theo bao gồm các kỹ thuật tối ưu hóa mà OpenAI đã áp dụng để làm cho mỗi lớp hiệu quả hơn.

Harness là lớp điều phối gần người dùng nhất, chuyển đổi yêu cầu thô của người dùng thành ngữ cảnh và tương tác với LLM trong một vòng lặp cho đến khi tác vụ hoàn thành. Nó có hai trách nhiệm chính.

Thứ nhất, nó là nguồn sự thật cho cuộc trò chuyện. Nó lưu giữ hồ sơ xác thực của mọi hướng dẫn, tin nhắn, lệnh gọi công cụ và kết quả công cụ. Thứ hai, nó chạy vòng lặp agentic. Nó quyết định những gì đi vào ngữ cảnh được gửi đến LLM (hướng dẫn nào, định nghĩa công cụ nào và bao nhiêu lịch sử). Nó gửi yêu cầu, nhận phản hồi dưới dạng luồng, phân tích cú pháp và theo dõi các lệnh gọi công cụ. Khi một lệnh gọi công cụ xuất hiện, nó thực thi lệnh đó theo các chính sách phê duyệt trong môi trường sandbox, đính kèm kết quả vào cuộc trò chuyện và gửi lại cho LLM. Nó lặp lại vòng lặp này cho đến khi tác vụ hoàn thành. Các tác vụ nặng về lý thuyết có thể lặp lại hơn 100 lần. Mỗi lần lặp lại đều mang theo chi phí vận hành (overhead). Ví dụ, thêm một giây cho mỗi lần gọi mô hình sẽ làm tăng khoảng nửa phút cho một tác vụ dài.

Từ góc độ của lớp harness, độ trễ đến từ bốn nguồn: mạng, xử lý prompt, nội dung ngữ cảnh và các vòng lặp khứ hồi (round trips). OpenAI đã áp dụng bốn kỹ thuật sau tại lớp harness để làm cho nó hiệu quả hơn.

Harness chạy trên máy của người dùng, nhưng mô hình chạy trong các trung tâm dữ liệu của OpenAI, vì vậy mỗi lần gọi mô hình là một lần trao đổi qua mạng. Cách tiêu chuẩn để thực hiện trao đổi đó là HTTPS. Harness mở một kết nối, gửi yêu cầu chứa mọi thứ mà máy chủ (lớp API) cần và nhận phản hồi. Vì phản hồi từ mô hình ngôn ngữ đến dần dần, từng token một, các ứng dụng trò chuyện thường sử dụng Server-Sent Events (SSE) trên nền HTTPS, vì vậy máy khách gửi một yêu cầu và máy chủ truyền câu trả lời trở lại theo từng phần nhỏ qua phản hồi đang mở. SSE là con đường một chiều. Nó rất phù hợp cho kỷ nguyên trò chuyện, nơi một tin nhắn người dùng tạo ra một lần gọi mô hình và một câu trả lời được truyền đi. Nhưng các agent không phải là quy trình một lần. Một lượt Codex có thể chứa nhiều lần gọi mô hình. Với HTTPS, mỗi lần gọi đó là một yêu cầu mới với hai chi phí riêng biệt.

Chi phí đầu tiên là thiết lập kết nối. Mở một kết nối HTTPS mới có nghĩa là một lần bắt tay TCP theo sau là một lần bắt tay TLS, mất vài vòng lặp mạng trước khi một byte dữ liệu hữu ích được truyền đi. Trả chi phí đó một lần cho mỗi tin nhắn người dùng thì có thể quản lý được, nhưng trả nhiều lần trong một lượt trò chuyện thì rất đắt đỏ.

Chi phí thứ hai là sự lặp lại của chính tải trọng (payload). HTTP là không trạng thái (stateless), vì vậy mỗi yêu cầu phải mang theo mọi thứ mà máy chủ cần. Ví dụ, các hướng dẫn, định nghĩa công cụ và toàn bộ cuộc trò chuyện cho đến nay đều cần được đưa vào yêu cầu. Đến lệnh gọi công cụ thứ hai mươi, harness đang gửi lại prompt gốc, mười chín lệnh gọi công cụ và mười chín kết quả công cụ, chỉ để thêm một kết quả mới ở cuối. Điều này khiến tải trọng tăng lên sau mỗi lần lặp, vì vậy harness dành ngày càng nhiều thời gian để tải lên dữ liệu mà máy chủ đã thấy.