Kết quả Browser-Agent 76x của GPT-6.1 Sol: Asana thực sự đã đo lường điều gì

Asana đã công bố một nghiên cứu về chi phí của tác nhân trình duyệt vào ngày 8 tháng 10 năm 2026, và nhà phát triển của GPT-6.1 Sol đã viết bài về nó vào ngày hôm sau với tiêu đề "Asana cắt giảm chi phí mô hình 76 lần trong các thử nghiệm trên trình duyệt với GPT-6.1 Sol." Con số 76 lần là thật theo nghĩa ai đó đã đo được nó, nhưng nó không phải là một sự thật về giá của GPT-6.1 Sol. Đó là một sự thật về điều xảy ra khi bạn sửa một prompt cache bị hỏng trên một tác nhân trình duyệt rồi sau đó thay thế mô hình nằm đằng sau nó. Cùng phép tối ưu hóa đó, khi chạy trên mô hình mà Asana vốn đã có trong môi trường sản xuất — mô hình mà họ gọi là Model B — tự nó đã cắt giảm chi phí 29 lần. GPT-6.1 Sol đóng góp 2,6 lần còn lại. Các thí nghiệm được thực hiện bởi GPT-6 Astra làm việc trong Codex, và mô hình đứng sau đường cơ sở là mô hình của một đối thủ cạnh tranh mà Asana gọi là Model B, vì vậy hai phiên bản từ cùng một nhà cung cấp và một đối thủ giấu tên đều xuất hiện trong câu chuyện này. Phần tiếp theo sẽ tách riêng phần kết quả mà bạn có thể sao chép vào thứ Hai khỏi phần thuộc về ngăn xếp cụ thể của Asana.

Sự so sánh, được nêu chính xác

Ngăn xếp của Asana cho việc này là StackAI, nền tảng tự động hóa quy trình làm việc mà hãng đã mua lại, vận hành một tác nhân trình duyệt có thể điều hướng các trang web, điền biểu mẫu và thu thập thông tin mà không cần viết mã. Nhiệm vụ kiểm thử khá hẹp và cụ thể: thu thập sáu trường cho mỗi cuốn trong số 32 cuốn sách từ một danh mục demo công khai. Điều đó mang tính đại diện cho những gì một số khách hàng đang vận hành, và cũng đủ nhỏ để một nghiên cứu 144 lượt chạy nằm gọn trong một tuần.

Thiết kế gồm sáu chính sách lưu đệm và chụp ảnh màn hình ở hai ngân sách lịch sử, ba lần chạy cho mỗi điều kiện, trên bốn mô hình — 144 lần chạy, cộng thêm một đợt theo dõi 12 lần chạy. Chi phí được tính từ bộ đếm token của chính từng nhà cung cấp, và mọi câu trả lời đều được chấm điểm dựa trên một tài liệu tham chiếu được chuẩn bị độc lập. Bốn mô hình là ba mô hình tiên tiến giấu tên (Mô hình A, B và C) và GPT-6.1 Sol. Mô hình A là một mô hình nhỏ hơn, rẻ hơn từ một phòng thí nghiệm khác, phát hành vào Mùa thu 2025, có giá bằng một nửa GPT-6.1 Sol. Mô hình B là mô hình đã từng được đưa vào vận hành, cùng phòng thí nghiệm với A, phát hành vào Mùa hè 2026, có giá ngang bằng GPT-6.1 Sol. Mô hình C là một phiên bản mới hơn của Mô hình B, phát hành vào Mùa thu 2026, cũng có giá ngang bằng GPT-6.1 Sol. Cả ba đều được giấu tên trong cả hai bài viết, nên người đọc không thể tái lập so sánh — điều đáng biết trước khi bạn coi 29x là một con số nói về mô hình của ai đó khác. Đây là các số liệu do Asana và OpenAI công bố, không phải những số liệu được kiểm toán độc lập.

Thang kết quả, tất cả đều là số liệu của chính Asana:

• Sản xuất cơ sở trên Model B — ít nhất $36.21 mỗi lần chạy, ít nhất 22.5 phút mỗi lần chạy. Một số lần chạy cơ sở đã đạt giới hạn bước trước khi hoàn thành, nên giá trị trung bình chỉ là mức sàn chứ không phải giá trị trung bình thực sự.

• Model B, tác nhân được tối ưu hóa — 1,24 đô la mỗi lần chạy, nhanh hơn 4 lần so với mức cơ sở, cắt giảm chi phí 29 lần.

• GPT-6.1 Sol, cùng một agent tối ưu — 0,47 USD mỗi lần chạy, khoảng bốn phút, giảm chi phí 76 lần và nhanh hơn 5 lần.

• GPT-6.1 Sol, trước và sau bản sửa lỗi — từ $1.97 xuống $0.47 mỗi lần chạy, giảm 4 lần chỉ nhờ các thay đổi về bộ nhớ đệm và cắt tỉa.

Bởi vì mốc cơ sở là một giới hạn dưới, bản thân 76x cũng là một mức sàn. Cách hiểu trung thực là “ít nhất 76x”, chứ không phải “76x”.

Điều gì thực sự đã thay đổi, và tại sao đó không phải là một tính năng của mô hình

Cơ chế ở đây là cơ chế đệm prompt, và đáng để hiểu vì nó áp dụng cho bất kỳ agent nào bạn chạy trên bất kỳ mô hình nào. Một agent trình duyệt sẽ gửi lại các công cụ, lời nhắc hệ thống và lịch sử ngày càng dài gồm văn bản trang lẫn ảnh chụp màn hình trong mỗi lần gọi mô hình. Đệm prompt giúp giảm giá cho phần lặp lại, nhưng chỉ với tiền tố dài nhất không đổi — ngay khi bất cứ thứ gì ở giữa yêu cầu thay đổi, việc tái sử dụng sẽ đứt gãy từ điểm đó trở đi.

Agent production của Asana mắc hai lỗi cộng dồn vào nhau. Nó cache các chỉ dẫn cố định và định nghĩa công cụ, nhưng lại không cache lịch sử duyệt web của mình. Và nó chỉnh sửa lịch sử đó ở gần như mọi bước: mỗi lần đều bỏ ảnh chụp màn hình trước đó và cắt bớt văn bản cũ hơn để vừa với hạn mức lịch sử. Mỗi lần chỉnh sửa đều làm mất hiệu lực tiền tố, nên cache sẽ gần như vô dụng kể cả khi đã được bật. Bài viết của Asana lưu ý rằng trên các mô hình được thử nghiệm, chi phí đọc cache chỉ bằng 0,05x đến 0,1x giá đầu vào tiêu chuẩn — vậy nên phần thưởng rất lớn mà agent lại đang hệ thống từ chối nó.

Bản sửa lỗi có hai phần. Thứ nhất, cũng lưu lịch sử vào bộ nhớ đệm, kèm dấu đệm trên kết quả công cụ mới nhất. Thứ hai, ngừng chỉnh sửa nó ở mỗi lần gọi: giữ lại ảnh chụp màn hình và cắt tỉa chúng theo lô với tỷ lệ 20 ăn 1, nhờ đó tác nhân giữ tối đa 20 ảnh rồi cắt giảm về ảnh gần nhất. Khoảng 19 lần gọi liên tiếp sau đó sẽ tái sử dụng một tiền tố không đổi. Hãy nâng ngân sách lịch sử từ 120.000 lên 480.000 ký tự để văn bản cũ không còn bị cắt bớt, và phép tính sẽ khớp: trên GPT-6.1 Sol, chi phí mỗi lần gọi thấp hơn khoảng 3 lần vì 89% đầu vào đến từ bộ nhớ đệm.

Phát hiện quan trọng nhất ở đây là một phát hiện tiêu cực. Việc lưu đệm lịch sử mà không cắt tỉa theo lô, ở ngân sách lớn hơn, tốn nhiều hơn so với không lưu đệm chút nào trên ba trong bốn mô hình — bộ đệm liên tục bị ghi lại và hiếm khi được đọc. Hạ tầng bộ đệm được bật lên mà không có kỷ luật lịch sử chỉ-ghi-thêm là một cách trả thêm chi phí ghi mà chẳng được gì. Chế độ thất bại đó không phụ thuộc vào mô hình, và đó là lý do cùng một bản sửa đã cải thiện Model B gấp 29 lần.

Nơi việc lựa chọn mô hình thực sự đã phát huy tác dụng

Gạt bỏ phần sửa lỗi quy trình và so sánh cùng điều kiện với nhau: ở cùng một agent đã được tối ưu, GPT-6.1 Sol chạy rẻ hơn 2,6 lần so với Model B, ở cùng mức giá niêm yết. Yếu tố tạo ra khác biệt là hành vi trúng cache, không phải bảng giá. Sol đọc 89% đầu vào từ cache; Asana không công bố tỷ lệ tương đương cho Model B, nên mức 2,6 lần là một kết quả đo được mà không có phân tách được công bố. Hãy coi đó là “mô hình này, trên khối lượng công việc này, đã dùng cache tốt hơn”, chứ không phải lợi thế 2,6 lần nói chung so với một mô hình mà chúng ta không thể nêu tên.

Về mặt thời gian chạy thì không có gì mơ hồ: nhanh gấp 5 lần so với mức cơ sở, với quy trình Sol được tối ưu chỉ mất khoảng bốn phút, so với mức cơ sở ít nhất là 22,5 phút. Tốc độ ảnh hưởng đến chi phí ở các tác nhân tính phí theo token, vì một mô hình chậm mà lặp lại sẽ phải trả tiền cho các vòng lặp của nó.

Với bất kỳ ai đang tính toán khoản này: mức giá API tiêu chuẩn của GPT-6.1 Sol là 2,00 USD cho mỗi triệu token đầu vào, 0,10 USD cho mỗi triệu token đầu vào được lưu đệm cùng 10,00 USD cho mỗi triệu token đầu ra, và mức chiết khấu khi đọc bộ đệm bằng 0,05 lần giá đầu vào — mức sâu nhất trên bảng giá hiện hành của OpenAI. GPT-6 Astra, mô hình đã đảm nhận phần việc kỹ thuật trong Codex, có giá 10,00 USD cho đầu vào và 50,00 USD cho đầu ra, tức khoảng cách gấp năm lần mà OpenAI dựa vào trong cách giới thiệu khi ra mắt. Lý do nghiên cứu tạo ra các lượt chạy tốn 0,47 USD thay vì 2 USD không nằm ở bảng giá; mà là vì 89% của một yêu cầu có tính lặp lại rất cao được tính với mức chỉ bằng một phần hai mươi giá đầu vào. Với một agent dùng nhiều bộ đệm, dòng chiết khấu đóng vai trò lớn hơn cả mức giá được nêu bật, và trên danh sách nhà cung cấp trong danh mục của chính chúng tôi, giá niêm yết được chuyển nguyên với mức markup 0%, nên khi một nhà cung cấp thay đổi cách tính token đầu vào lưu đệm thì hóa đơn của bạn cũng thay đổi ngay trong cùng ngày.

Con số còn lại trong nghiên cứu: ngân sách lịch sử quyết định liệu tác nhân có trả lời hay không

Chi phí mỗi lần chạy là con số mà ai cũng nhắc đến, nhưng kết quả hữu ích hơn của nghiên cứu lại nói về độ tin cậy, và đó là kết quả mà người vận hành nên đọc trước tiên.

• Với ngân sách 120.000 ký tự, Model C không trả lời trong bất kỳ lần chạy nào trong số 18 lần chạy của nó và GPT-6.1 Sol trả lời trong 3 trong số 18 lần — hầu hết các lần chạy đều chạm giới hạn bước mà không đưa ra câu trả lời.

• Ở mức 480.000 ký tự, mọi lần chạy trên cả hai mô hình đều trả lời, và mỗi lần đều đưa ra câu trả lời đúng.

• Các mô hình mới hơn đốt ngân sách nhỏ hơn nhanh hơn: Model C lần đầu cắt bớt lịch sử ở lần gọi thứ 10, Model A ở lần gọi thứ 64.

• Trong quy trình làm việc được tối ưu hóa, mỗi lần chạy đều hoàn thành nhiệm vụ và trả về câu trả lời đúng, và mỗi lần chạy trong điều kiện tốt nhất trên mọi mô hình đều gặp đủ tất cả 192 dữ kiện mà nó được cho là phải thu thập.

Đó là một lập luận khác với "rẻ hơn". Một ngân sách lịch sử quá nhỏ trên một mô hình có năng lực sẽ tạo ra một agent thất bại vì hết chỗ chứa, và nó thất bại vì chạm trần số bước — cách thất bại tốn kém nhất: bạn trả tiền cho toàn bộ lượt chạy mà chẳng thu được gì. Tăng ngân sách làm tăng chi phí mỗi lần gọi và giảm chi phí mỗi câu trả lời, và đó là con số duy nhất mà người vận hành production nên theo dõi. Nếu bạn đang đánh giá một mô hình chưa được kiểm chứng cho một agent như thế này, mô thức ít rủi ro là giữ tuyến production của bạn trên mô hình bạn tin tưởng và đặt mô hình mới phía sau một cơ chế failover hoặc một tuyến chia tách, để lỗi chạm giới hạn số bước hiện lên như một sự kiện định tuyến thay vì một sự cố. Mọi mô hình trong so sánh này đều có thể truy cập qua một API cho hơn 200 mô hình với giá niêm yết của nhà cung cấp được chuyển nguyên vẹn, điều này cũng khiến chiết khấu đọc cache trở nên có thể so sánh giữa các nhà cung cấp trên cùng một hóa đơn thay vì năm dashboard.

Cần rút ra những gì từ điều này, theo thứ tự

Nếu bạn vận hành một trình duyệt hoặc tác nhân sử dụng máy tính, có ba đòn bẩy trong nghiên cứu của Asana đáng để kéo trước khi bạn xem bảng giá:

• Biến tiền tố của yêu cầu thành chỉ-thêm-vào-cuối. Mọi chỉnh sửa ở giữa lịch sử trong từng lần gọi đều xóa sạch khả năng tái sử dụng bộ nhớ đệm kể từ điểm đó trở đi.

• Cắt tỉa theo lô. Phân tích tiếp theo của Asana cho thấy việc giữ lại mọi ảnh chụp màn hình tốn ít hơn1,2 lần chi phí cho mỗi lượt gọi so với điều kiện cắt tỉa tốt nhất trên Model B và GPT-6.1 Sol, và ít hơn khoảng 5% trên Model C. Việc cắt tỉa vẫn quan trọng đối với các tác vụ dài, cửa sổ ngữ cảnh nhỏ và các lần đọc bộ nhớ đệm đắt đỏ — nhưng lý do cho tỷ lệ lô 20:1 là sự ổn định của bộ nhớ đệm, chứ không phải bản thân các ảnh chụp màn hình.

• Đặt ngân sách lịch sử theo từng mô hình và đối chiếu nó với giới hạn số bước của bạn. Một ngân sách phù hợp với một mô hình có thể làm mô hình tiếp theo bị thiếu hụt.

Hai rào chắn an toàn từ nghiên cứu rất dễ bị bỏ qua và không nên bị bỏ qua. Không có lượt chạy nào đạt tới ngân sách 480.000 ký tự, nên ngân sách chưa bao giờ giới hạn các lượt chạy này — nhưng một agent đang trôi dạt sẽ phình dần tới giới hạn ngữ cảnh của nó, và nếu cache hỏng, mọi lệnh gọi đều phải trả đủ chi phí. Giới hạn trần về số bước, token và chi phí mỗi lượt chạy chính là thứ khống chế một lượt chạy tồi. Ở một khía cạnh khác, nghiên cứu dùng ba hoặc bốn lượt chạy cho mỗi điều kiện với số lượng lệnh gọi thay đổi, điều mà chính Asana nói là đủ để cho thấy các xu hướng rộng và không đủ để phân tách các điều kiện chỉ cách nhau vài phần trăm. Đừng đọc ra mức chênh lệch 5% từ dữ liệu này rồi xây dựng lại pipeline của bạn dựa trên đó.

Phần thực sự mới, và phần không phải vậy

Những lưu ý về thiết lập này đáng được nói thẳng ra: bốn mô hình, ba trong số đó không được nêu tên, một tác vụ hẹp với 32 cuốn sách, các bộ đếm có gắn thiết bị đo của chính Asana, và một bài viết của chính nhà cung cấp lưu trữ kết quả. Chưa có gì ở đây được tái lập bên ngoài Asana. Nhưng cơ chế đã được đặc tả đầy đủ — lịch sử chỉ ghi thêm, dấu đệm trên kết quả công cụ cuối cùng, cắt tỉa theo lô, ngân sách lớn hơn, đo các lượt đọc bộ đệm bằng bộ đếm của nhà cung cấp — và đây là kiểu phát hiện vẫn đứng vững ngay cả khi bị gán nhầm cho phòng thí nghiệm khác. Con số 76x là con số của Asana trên một khối lượng công việc của Asana. Lý do nó đáng đọc là nó chứng minh một quy tắc bạn có thể kiểm tra trong một buổi chiều: một agent tự sửa lịch sử của chính nó ở mỗi bước đang trả đủ giá cho một cuộc hội thoại mà nó đã có rồi.