Những đường vòng AI mà bạn không nên phải trả tiền

Không phải các công ty AI tiên phong nhất định sẽ không tìm cách thao túng giá token khi bán cho chúng ta, nếu họ có thể làm vậy mà không bị phản đối – dù sao thì Anthropic đã áp dụng mức tăng giá thực tế 30% vào tháng 6; DeepSeek tăng giá API vào tháng 8; còn OpenAI miễn cưỡng rút lại việc giảm hạn mức token ở gói tầm trung vào cuối tháng 9. Vì vậy, xu hướng thắt chặt chi tiêu giờ đã khá rõ ràng.

Quả thực, ý nghĩ ấy thường trở lại khi tác nhân AI của bạn đốt sạch hạn mức token hằng ngày trong 45 phút tạo ra một loạt mã không hẳn là xuất sắc, rồi bảo bạn quay lại sau 3-4 giờ. Vào khoảnh khắc đầy bực bội ấy, người ta khó tránh khỏi tự hỏi liệu một số quy trình vận hành có được thiết kế theo hướng có lợi cho nhà cung cấp hay không. Dù sao thì đó cũng là cách hay để khiến chúng ta móc hầu bao mua thêm một gói token đặc biệt – hoặc thậm chí bật tính năng “tự động nạp”.

Nếu trong giai đoạn này điều đó thực sự xảy ra, các công ty tiên phong hoàn toàn có thể núp sau giả định rằng chúng ta không hiểu hết cách token được sử dụng trong các khối lượng công việc có tác nhân, trên nhiều mô hình và bộ khung khác nhau. Và họ cũng vậy. Ngoại trừ các quy trình thúc đẩy thanh toán của họ (thực sự rất trơn tru), mọi thứ vẫn chỉ ở giai đoạn tiền alpha và tiếp tục là đề tài cho các nghiên cứu tiên phong, bất chấp sản phẩm đã được phổ cập rộng rãi.

Quản lý lãng phí

Việc các tác nhân AI lãng phí token (và do đó làm lãng phí tiền của bạn) khi suy luận trong các quy trình có tác nhân thì đã từ lâu được xác lập rõ: đúng một năm trước, tôi đã viết về nghiên cứu mới cho thấy các mô hình AI suy luận dễ đốt token đến mức nào thông qua việc “dài dòng”; đầu năm nay, tôi viết về một nghiên cứu khác cho rằng suy luận theo chuỗi suy nghĩ chỉ mang tính “trang trí”; và tuần trước, Nils Bunge, Giám đốc Sản phẩm của Tsuga, đã tuyên bố trong một bài viết thể hiện quan điểm chuyên môn tại đây:

“Một nhóm tiêu thụ số token gấp đôi không nhất thiết tạo ra giá trị gấp đôi. Có thể nhóm đó đang xử lý công việc khó hơn, sử dụng một mô hình mạnh hơn mức cần thiết hoặc dựa vào một tác nhân liên tục thử lại những tác vụ thất bại.”

Điều ít được biết đến hơn là cách thức token bị tiêu tốn vào những tác vụ hoặc quy trình không cần thiết; và đây là trọng tâm của một bài nghiên cứu mới khiến tôi chú ý trở lại đến chủ đề này hôm nay.

Có tiêu đề “Các tác nhân AI lãng phí tiền của bạn như thế nào?”, công trình hợp tác học thuật mới của Mỹ này* đưa ra một khuôn khổ thống nhất có thể định lượng mức độ lãng phí token trong các quy trình có tác nhân. Với những mô hình nguồn đóng, phương pháp “bóng” kết hợp số liệu và chỉ số chính thức của nhà cung cấp để tái hiện chi tiết tương đương những gì đã xảy ra với token trong lúc AI suy luận và hành động:

Phương pháp mới để đo lượng token AI bị lãng phí. Quá trình suy luận, hành động và chi phí của từng tác nhân được ghi lại, sau đó được phân tích để tìm những trường hợp lặp lại, yêu cầu không cần thiết và đường vòng có thể tránh được. Phần lãng phí được xác định sẽ bị loại bỏ, rồi khả năng hoàn thành tác vụ ban đầu của tác nhân được kiểm tra lại. Nguồn

Như minh họa ở trên, tác nhân được phép hoạt động bình thường, đồng thời các trao đổi với nhà cung cấp AI được chặn lại và ghi lại, bao gồm những lần suy luận, sử dụng công cụ, mức tiêu thụ token và chi phí. Sau đó, các bản ghi được những mô hình ngôn ngữ lớn (LLM) đóng vai trò giám khảo phân tích để phân biệt công việc hữu ích với việc lặp lại, tìm kiếm không cần thiết và đi đường vòng. Sau bước này, phần lãng phí bị nghi ngờ sẽ được loại bỏ, lượng token tiết kiệm được sẽ được tính toán, rồi tác nhân tiếp tục công việc để xem liệu nó có còn hoàn thành nhiệm vụ thành công hay không.

Trong các thử nghiệm, các nhà nghiên cứu nhận thấy khoảng 18% số token đầu ra của các tác nhân bị lãng phí. Trong hơn 45% số tác vụ, một tác nhân lãng phí nhiều token hơn số token mà một tác nhân khác cần để hoàn thành thành công cùng công việc. Họ cũng phát hiện rằng việc loại bỏ 41–46% phần suy luận không cần thiết hầu như không ảnh hưởng đến hiệu suất, cho thấy có thể tiết kiệm đáng kể mà không làm giảm đáng kể kết quả.

Bài nghiên cứu nêu:

“Trong các chuỗi tương tác được thu thập, khoảng 18% số token đầu ra được xác định là lãng phí.

“Đáng chú ý, trong hơn 45% số tác vụ, lượng token đầu ra bị lãng phí của riêng một tác nhân đã vượt tổng lượng token đầu ra của một tác nhân khác vốn giải quyết thành công cùng tác vụ.”

Ngoài ra, nghiên cứu phát hiện rằng các tác nhân lãng phí nhiều tài nguyên nhất khi thao tác với những công cụ không quen thuộc và theo đuổi các cách tiếp cận rốt cuộc chẳng đi đến đâu; đồng thời, tăng mức độ suy luận không mang lại cải thiện nhất quán: ở mức nỗ lực tối đa, Kimi-K3 được phát hiện tạo ra số token suy luận nhiều gấp 6.6 lần so với mức nỗ lực thấp, nhưng điều đó không đảm bảo kết quả tốt hơn.

Kết quả thử nghiệm cho thấy Kimi-K3 hoạt động như thế nào ở bốn mức độ nỗ lực suy luận trên năm bộ chuẩn đánh giá. Nỗ lực suy luận cao hơn không giúp tỷ lệ thành công tăng lên một cách nhất quán, và đôi khi mức nỗ lực tối đa còn cho kết quả kém hơn các mức thấp hơn.

Tương tự như việc lái một chiếc xe mạnh mẽ nhưng không bao giờ thực sự khai thác hết khả năng của nó, các phiên làm việc của tác tử AI này giống như lái một chiếc xe luôn tăng tốc đến mức tối đa mà nó có thể đạt được trong mọi chuyến đi, ngay cả khi việc đó chẳng đem lại lợi ích gì và có thể kéo theo những hệ quả tiêu cực.

Bài báo cũng khảo sát vai trò của các bộ khung khác nhau trong việc gây lãng phí token, và phát hiện rằng cùng một mô hình AI, Kimi-K3, có thể tạo ra lượng nội dung suy luận nhiều hơn gấp bốn lần cho cùng một tác vụ, tùy thuộc vào bộ khung được sử dụng, mà chưa chắc đạt được kết quả tốt hơn.

Một phần lãng phí bắt nguồn từ những lỗi phần mềm cơ bản: OpenCode, Kimi Code CLI và OpenClaw liên tục khởi chạy tác vụ trong sai môi trường Python, gây ra lỗi và khiến các lần thử lại tiêu tốn token. Kimi Code CLI còn cho phép AI yêu cầu thời gian chờ mà chính phần mềm của nó sẽ từ chối, buộc hệ thống phải thực hiện thêm những lần thử tốn kém.

Trái với dự đoán, các bộ khung cung cấp nhiều công cụ hơn không nhất thiết gây lãng phí nhiều hơn; một số điểm kém hiệu quả lặp đi lặp lại dường như bắt nguồn từ chính các mô hình, bất kể chúng được điều khiển bằng bộ khung nào.

‘[Several]Những đặc điểm của bộ khung tưởng như hiển nhiên không phải lúc nào cũng giải thích được những khác biệt quan sát thấy về mức độ lãng phí. Chẳng hạn, như minh họa [below], các bộ khung cung cấp nhiều công cụ hơn không nhất thiết gây lãng phí nhiều hơn. OpenClaw cung cấp nhiều công cụ hơn hẳn các bộ khung khác, nhưng mức lãng phí vẫn chỉ ở mức vừa phải. Hơn nữa, không phải mọi dạng lãng phí đều thay đổi theo bộ khung.

‘[Below right]cho thấy trên SWE-bench Verified, có một đường vòng lặp đi lặp lại: Kimi-K3 viết ra điều mà nó cho là bản sửa lỗi ban đầu của dự án, rồi sau đó lại từ bỏ nó. ‘

Kết quả thử nghiệm so sánh lượng token bị lãng phí giữa các bộ khung tác tử AI. Bên trái: cung cấp nhiều công cụ hơn không nhất thiết làm tăng mức lãng phí. Bên phải: Kimi-K3 nhiều lần thử rồi từ bỏ một bản sửa lỗi phần mềm được cho là bản gốc, bất kể sử dụng bộ khung nào, nhưng hiếm khi làm vậy với một loại tác vụ khác.

Để khắc phục vấn đề, các tác giả đề xuất rằng bộ khung tác tử cần nhận biết khi những hạn chế của môi trường khiến việc tiếp tục tiến triển trở nên bất khả thi, thông báo rõ những hạn chế đó cho mô hình AI và dừng thực thi, thay vì để các lần thử thất bại lặp đi lặp lại tiêu tốn thêm token. Họ cũng đề xuất sử dụng các phép đo lượng token bị lãng phí để cải thiện quá trình huấn luyện mô hình, chiến lược suy luận và thiết kế bộ khung.

Phương pháp

Để tái dựng hoạt động của một tác tử AI, các nhà nghiên cứu theo dõi từng lượt trao đổi giữa mô hình và phần mềm điều khiển nó, ghi lại quá trình suy luận, phản hồi, yêu cầu sử dụng công cụ và chi phí token; mức độ chi tiết tùy theo từng nhà cung cấp: Kimi-K3 công khai toàn bộ quá trình suy luận; Gemini 3.1 Pro chỉ cung cấp bản tóm tắt; còn Claude thì không công khai nội dung nào.

Kết quả từ mỗi công cụ được gửi trở lại cho tác tử, giúp các nhà nghiên cứu theo dõi quá trình cho đến khi hoàn tất hoặc chạm đến giới hạn vận hành.

Bốn ví dụ về cách tác tử AI sử dụng token. Lặp lại thông tin đã biết, thực hiện những lượt tìm kiếm giống hệt nhau và thêm lời xin lỗi vô ích đều được tính là lãng phí; trong khi đó, một lượt tìm kiếm không thành công chưa chắc đã gây lãng phí, vì tác tử có thể có lý do chính đáng để thử.

Các yêu cầu của tác tử được chuyển qua một máy chủ proxy để theo dõi hoạt động, chỉ cần chỉnh sửa đôi chút mã nguồn; mỗi yêu cầu được gắn nhãn bộ chuẩn đánh giá, lượt chạy, tác vụ và lần thử (ngoại trừ OpenClaw, vốn không hỗ trợ các thẻ này — trong trường hợp đó, mỗi bài kiểm tra sử dụng một máy chủ proxy riêng, được xây dựng trên LiteLLM).

Bốn dạng

Nghiên cứu xác định bốn kiểu lãng phí token thường gặp: Nhắc lại (lặp lại thông tin đã biết); Truy xuất trùng lặp (lặp lại những yêu cầu sử dụng công cụ không cần thiết); Nội dung thừa (thêm văn bản không liên quan); và Đi đường vòng (theo đuổi những cách tiếp cận có vẻ hợp lý nhưng cuối cùng không đem lại kết quả).

Mỗi phiên được ghi lại đều được một mô hình ngôn ngữ lớn đóng vai trò giám khảo (LLMaJ**) xem xét. Mô hình này được cung cấp nhiệm vụ ban đầu, toàn bộ bản ghi và các tiêu chí để nhận diện cả bốn kiểu lãng phí. Những phần bị nghi là lãng phí được đánh dấu và loại bỏ, sau đó số token còn lại được đếm lại để tính tỷ lệ và chi phí lãng phí. Tiếp đó, số liệu được đối chiếu với bộ tách token hoặc công cụ đếm riêng của từng nhà cung cấp, cũng như mức sử dụng đầu ra được báo cáo (chỉ ghi nhận một số khác biệt nhỏ về định dạng).

Các thử nghiệm

Các mô hình được thử nghiệm trong nghiên cứu gồm Kimi-K3; Gemini 3.1 Pro; GPT-5.6 Terra; GPT-6 Astra; Claude Sonnet 5; và Claude Fable 5.1, trên các bộ chuẩn τ²-bench (dịch vụ khách hàng trong lĩnh vực hàng không và bán lẻ); SWE-bench Verified (kỹ thuật phần mềm); Claw-Eval; và MCP-Atlas (sử dụng công cụ đa mục đích).

Ngoài ra, Kimi-K3 được thử nghiệm ở các mức độ suy luận khác nhau, đồng thời năm bộ khung tác tử được đưa ra so sánh: OpenCode; OpenClaw; OpenHands; Hermes; và Kimi Code CLI. Các phép so sánh này được dùng để đánh giá ảnh hưởng của mô hình, nhiệm vụ, mức độ suy luận và thiết kế bộ khung đến tình trạng lãng phí token (đồng thời, trong các thử nghiệm tiếp theo, phần bị nghi là lãng phí được loại bỏ để kiểm tra tác động của việc này đến hiệu suất).

Để xác định mỗi mô hình gây lãng phí bao nhiêu tiền, chi phí cho văn bản và lệnh gọi công cụ không cần thiết được so sánh với tổng chi phí đầu ra, rồi lấy mức trung bình của kết quả trên bốn bộ chuẩn. Quá trình suy luận nội bộ được đánh giá riêng đối với Kimi-K3 — mô hình duy nhất công khai toàn bộ quá trình suy luận:

Kết quả thử nghiệm so sánh chi phí đầu ra bị lãng phí ở sáu mô hình AI, lấy trung bình trên bốn bộ chuẩn. Bên trái: tỷ lệ lãng phí tổng thể, trong đó phần suy luận nội bộ của Kimi-K3 được trình bày riêng. Bên phải: tỷ lệ lãng phí ở các nhiệm vụ thành công và thất bại; nhìn chung, nhiệm vụ thất bại gây lãng phí nhiều hơn.

Như thể hiện ở trên, từ 11% đến 24,9% số tiền chi cho việc tạo câu trả lời và sử dụng công cụ được đánh giá là lãng phí; GPT-6 Astra có kết quả tốt nhất, còn Claude Sonnet 5 kém nhất. Với Kimi-K3, khoảng một trong sáu token bị lãng phí cho câu trả lời và việc sử dụng công cụ; tỷ lệ này tăng lên hơn một trong bốn token trong quá trình suy luận nội bộ.

Nhìn chung, các nhiệm vụ thất bại gây lãng phí nhiều hơn, dù chiều hướng ngược lại xuất hiện trong quá trình suy luận của Kimi-K3; đồng thời, không có bằng chứng rõ ràng cho thấy việc tiêu tốn thêm token vào những phần việc không cần thiết giúp tăng khả năng thành công.

Trong một thử nghiệm khác, các nhà nghiên cứu tìm cách cắt giảm token lãng phí ngay khi AI đang thực hiện nhiệm vụ: ở mỗi bước, một AI giám khảo** được dùng để loại bỏ thông tin lặp lại và nội dung vô ích khỏi quá trình suy luận của mô hình, trước khi cho phép mô hình tiếp tục nhiệm vụ:

Kết quả thử nghiệm cho thấy việc loại bỏ phần suy luận AI không cần thiết ảnh hưởng thế nào đến tỷ lệ thành công trên hai bộ chuẩn. Loại bỏ 41–46% phần suy luận hầu như không ảnh hưởng đến hiệu suất, trong khi loại bỏ toàn bộ phần suy luận khiến số trường hợp thất bại tăng đáng kể.

Trên SWE-bench Verified, 41% phần suy luận bị cắt bỏ mà hiệu suất không suy giảm; thực tế, tỷ lệ thành công còn tăng nhẹ, từ 89% lên 89,5%. Trên MCP-Atlas, 46% phần suy luận bị loại bỏ, khiến tỷ lệ thành công chỉ giảm nhẹ, từ 65% xuống 62,3%.

Nói cách khác, gần như một nửa phần suy luận có thể bị loại bỏ khi AI đang làm việc mà không ảnh hưởng nghiêm trọng đến khả năng hoàn thành nhiệm vụ.

Cuối cùng^†, Kimi-K3 được thử nghiệm trên cùng một bộ nhiệm vụ với các bộ khung tác tử khác nhau. Như minh họa dưới đây, lượng nội dung suy luận đầu ra chênh lệch hơn bốn lần mà không đem lại cải thiện hiệu suất nhất quán:

Kết quả thử nghiệm so sánh mức tiêu thụ token của Kimi-K3 khi dùng các bộ khung tác tử khác nhau trên hai bộ chuẩn. Phần suy luận nội bộ được thể hiện bằng màu xanh lam, còn câu trả lời và lệnh gọi công cụ được thể hiện bằng màu cam. Trong các nhiệm vụ lập trình, lượng nội dung suy luận tạo ra khi dùng Mini-SWE cao hơn Hermes hơn bốn lần.

Một phần lãng phí bắt nguồn từ những lỗi phần mềm cơ bản. OpenCode, Kimi Code CLI và OpenClaw khởi chạy các bài kiểm tra lập trình trong môi trường Python không phù hợp, gây ra lỗi và khiến các bài kiểm tra phải chạy lại.

Kết luận

Đây chỉ là cái nhìn sơ lược về một bài nghiên cứu có độ dài và phương pháp thực hiện tỉ mỉ, có thể sẽ đáng để đọc kỹ hơn.

Chủ đề này khiến tôi nghĩ đến một điều mà tôi thường ý thức rõ: khoảng cách mênh mông giữa những gì chúng ta và các nhà cung cấp tiên phong thực sự hiểu về những quy trình này, và sự sẵn lòng của các công ty trong việc đóng gói sản phẩm như thể nó vừa trải qua ba tháng được công cụ phân tích mã tĩnh kiểm tra và đạt kết quả xuất sắc.

Ở thời điểm này, nếu xảy ra kết quả tồi tệ, chúng ta chỉ có thể đổ lỗi cho chính mình, bởi chúng ta đang mua một sản phẩm mà gần như tất cả chúng ta đều biết là còn mang tính thử nghiệm sâu sắc và khó đoán.

* Với đóng góp được công khai xác nhận là ngang nhau từ University of Illinois Urbana-Champaign, Northeastern University, University of California (Los Angeles) và một nhà nghiên cứu độc lập.

* Theo những gì tôi có thể xác định, bài báo không nêu rõ mô hình nào đã được sử dụng.

^† Dành cho bài viết này, không phải bài báo nghiên cứu—bài báo dài hơn mức tôi thường tự cho phép mình đề cập, đồng thời có nhiều thử nghiệm và chiều sâu hơn những gì chúng tôi có thể trình bày ở đây. Để biết thêm chi tiết, vui lòng tham khảo tệp PDF nguồn được liên kết ở trên.

Được đăng lần đầu vào thứ Sáu, ngày 6 tháng 11 năm 2026