Tác nhân AI nào rẻ hơn vào năm 2026: chi phí cho một nhiệm vụ được giải quyết

Giá thuê bao và giá mỗi token là đầu vào của phép so sánh chi phí, nhưng riêng chúng chưa đủ. Cùng một khoản tiền có thể hoàn thành năm việc hoặc chỉ một. Để so giá trị với công việc của bạn, hãy đo tiền chi cho mỗi việc đạt trạng thái hoạt động đã định, gồm cả lần thử không thành công.

Tiếp theo, tôi sẽ trình bày công thức tính chi phí này và tính thử bằng giá của các nhà cung cấp vào đầu tháng 9 năm 2026. Tôi dùng số liệu sử dụng mẫu và sẽ nói rõ điều đó: số liệu của bạn sẽ là của riêng bạn. Bạn có thể tự tính lại mọi thứ bên dưới; không có lời hứa tiết kiệm hay tổ hợp thần kỳ nào cả.

Để tìm hiểu cách sử dụng dịch vụ, hãy xem tài liệu Ailoot.

Vì sao giá theo tháng không cho biết tác nhân nào rẻ hơn?#

Hầu hết mọi người nhìn vào giá thuê bao khi chọn dịch vụ. Một tác nhân giá 20 đô la mỗi tháng, tác nhân khác giá 200 đô la, nên tác nhân đầu có vẻ đáng tiền gấp mười lần. Nhưng riêng giá chưa xác lập giá trị: thuê bao đo quyền truy cập, còn công việc hoàn thành trong đó vẫn cần đo.

Hãy tưởng tượng hai chiếc taxi có phí cố định hằng tháng. Một chiếc đưa bạn đến nơi cần đến ngay lần đầu, còn chiếc kia rẽ nhầm đường trong một nửa số chuyến, khiến bạn phải gọi lại. Thuê bao của chúng có thể bằng nhau, nhưng trên thực tế, bạn sẽ đến đích với chi phí chỉ bằng một nửa khi đi chiếc đầu tiên. Tác nhân cũng vậy: bạn trả cùng một khoản thuê bao, nhưng số nhiệm vụ hoàn thành phụ thuộc vào những gì bên trong.

Tốt nhất nên tách thuê bao khỏi cuộc thảo luận về chi phí cho một nhiệm vụ. Ưu điểm của thuê bao là khoản tiền phải trả có thể dự đoán được. Tôi có bài phân tích riêng về việc chọn mô hình định giá — thuê bao, trả theo mức sử dụng hay phát triển tùy chỉnh — trong bài viết giá của một tác nhân AI bao gồm những gì. Bài viết này trả lời một câu hỏi khác: bất kể mô hình thanh toán là gì, tác nhân nào tạo ra kết quả với chi phí thấp hơn?

Vì sao giá mỗi token cũng gây hiểu lầm?#

Cách so sánh phổ biến thứ hai là xem giá mỗi token. Token là một phần văn bản, gần như một phần của từ; nó đo cả nội dung bạn gửi cho mô hình lẫn nội dung mô hình viết để trả lời. Các nhà cung cấp công bố giá cho mỗi triệu token, và mức giá giữa các mô hình khác nhau rất nhiều. Nghe có vẻ hợp lý: chọn mô hình có giá thấp hơn để trả ít hơn.

Cái bẫy nằm ở chỗ giá mỗi token là giá nguyên liệu thô, giống như giá xăng mỗi lít. Điều bạn quan tâm là chi phí của cả chuyến đi; riêng giá một lít chẳng cho bạn biết nhiều. Tác nhân giải quyết một nhiệm vụ qua nhiều bước: duyệt tệp, chạy lệnh, đọc lỗi, viết lại mã và gửi lại ngữ cảnh cho mô hình ở mỗi bước. Một cuộc hội thoại với tác nhân có thể dễ dàng biến thành hàng chục yêu cầu, mỗi yêu cầu đều sử dụng token.

Hai tác động có thể làm thay đổi so sánh chỉ theo giá: mô hình cần nhiều bước và token hơn, hoặc hoàn thành ít việc hơn. Không tác động nào tự suy ra từ giá. Đo từng mô hình trên cùng nhiệm vụ, gồm lần thử thất bại; xem cách tính mức sử dụng token API và vì sao vibe coding tốn kém hơn tưởng tượng.

Chi phí cho một nhiệm vụ được giải quyết là bao nhiêu?#

Chỉ số ở đây là chi phí một kết quả hoàn thành. Giá gói hoặc token đóng góp vào chi phí nhưng riêng nó chưa đủ; cần thêm lượng dùng thực tế và kết quả hoàn thành. Công thức là:

1. Lấy giá của một lần chạy tác nhân trên một nhiệm vụ — chi phí của toàn bộ token được dùng trong một lần thử.
2. Ước tính tỷ lệ nhiệm vụ mà tác nhân thực sự đưa đến trạng thái hoạt động được.
3. Lấy số thứ nhất chia cho số thứ hai để tính chi phí cho một nhiệm vụ được giải quyết.

Đây là lý do cần phép chia. Nếu tác nhân hoàn thành bảy trong mười nhiệm vụ, ba trong số mười lần chạy bị lãng phí, nhưng bạn đã trả tiền cho cả mười. Điều đó có nghĩa là chi phí của mười lần chạy được phân bổ cho bảy kết quả hoạt động được, khiến mỗi kết quả đắt hơn một lần chạy đơn lẻ. Khi giữ chi phí trung bình mỗi lượt chạy không đổi, tỷ lệ thành công thấp hơn làm chi phí mỗi việc hoạt động được cao hơn.

“Tỷ lệ nhiệm vụ hoàn thành” có thể đo được. Chỉ số này được đo bằng các benchmark như SWE-bench: tác nhân nhận các lỗi thực từ những dự án thực và gửi bản sửa lỗi để hệ thống kiểm tra bằng các bài kiểm thử tự động. Tỷ lệ phần trăm trong bảng là tỷ lệ nhiệm vụ được giải quyết. Nhưng tỷ lệ trong phòng thí nghiệm không giống tỷ lệ của bạn: tỷ lệ trên dự án của chính bạn sẽ khác, vì vậy hãy xem benchmark là mốc tham khảo chứ không phải lời hứa. Tôi giải thích riêng cách đọc các bảng này trong bài viết về xếp hạng tác nhân lập trình AI.

Ba yếu tố cấu thành chi phí của một nhiệm vụ là gì?#

Hãy phân tách chi phí thành các thành phần để xem khoản chi thêm ẩn ở đâu.

Thứ nhất: giá mỗi token. Giá cơ bản của mô hình: một triệu token đầu vào và một triệu token đầu ra có giá bao nhiêu. Mô hình lớn và mô hình nhẹ có thể chênh lệch giá hàng chục lần.

Thứ hai: lượng token mỗi nhiệm vụ. Lượng văn bản tác nhân xử lý qua mô hình trong một lần thử phụ thuộc độ lớn công việc, tệp đọc lại và số bước. Mô hình giải quyết bằng ít bước hơn có thể dùng ít token hơn; xác minh mức dùng thật thay vì suy ra từ giá hay nhãn mô hình.

Thứ ba: tỷ lệ nhiệm vụ hoàn thành. Phần trăm lần thử kết thúc bằng kết quả hoạt động được. Yếu tố này chia tổng chi phí: khi giữ nguyên chi phí mỗi lượt chạy, tỷ lệ thành công 40 phần trăm khiến mỗi việc hoàn thành đắt gấp đôi so với 80 phần trăm. So sánh đó không xác lập yếu tố nào quan trọng nhất khi giá và lượng dùng cũng đổi.

Mọi sự nhầm lẫn khi so sánh đều xuất phát từ việc mọi người chỉ nhìn vào con số đầu tiên — giá mỗi token. Nhưng cả ba con số đều quyết định chi phí cuối cùng. Giá thấp cùng với khối lượng cao và tỷ lệ thành công thấp có thể dễ dàng khiến tổng chi phí cao hơn giá cao đi kèm khối lượng thấp và tỷ lệ thành công cao.

Kết hợp ba con số thành cách làm việc cần đo chúng cùng nhau. Ngữ cảnh rõ và phương pháp phù hợp có thể giảm token hoặc tăng thành công, nhưng đổi mô hình cũng có thể thay đổi chúng. Ví dụ này chưa đo phương pháp hay giá mô hình có tác động lớn hơn.

Chi phí một lần chạy của các mô hình khác nhau là bao nhiêu?#

Để minh họa cụ thể công thức, tôi sẽ tính chi phí của một lần chạy bằng giá niêm yết thực tế. Tôi dùng một nhiệm vụ mẫu tương đối phức tạp, trong đó tác nhân sử dụng khoảng 300,000 token đầu vào cho mỗi lần thử (đọc lại dự án và lỗi qua nhiều bước) và khoảng 40,000 token đầu ra. Xin nhắc lại, đây là ví dụ để tính toán chứ không phải số liệu đo được; mức sử dụng của bạn sẽ khác.

Dưới đây là giá mỗi triệu token theo bảng giá chính thức của các nhà cung cấp vào đầu tháng 9 năm 2026:

Bạn có thể kiểm tra công thức bằng ví dụ thực tế từ tài liệu của Anthropic. Với một yêu cầu gửi đến Opus 5 có 50,000 token đầu vào và 15,000 token đầu ra, phép tính như sau:

Nói cách khác, cộng chi phí đầu vào và đầu ra theo giá tương ứng của từng loại — chính xác như trong công thức. Việc còn lại là chia chi phí lần chạy cho tỷ lệ nhiệm vụ hoàn thành, và đây là lúc giá thấp bắt đầu cho kết quả bất ngờ.

Vì sao mô hình rẻ có thể khiến một nhiệm vụ đắt hơn mô hình mạnh?#

So sánh hai mô hình bằng chi phí mỗi kết quả, trong đó chi phí lượt chạy vẫn là đầu vào cùng với tỷ lệ thành công.

Sonnet 5: một lần chạy tốn khoảng một đô la, và với nhiệm vụ mẫu của chúng ta, hãy giả sử mô hình hoàn thành 70 phần trăm số lần thử. Chi phí cho một nhiệm vụ hoạt động được là một đô la chia cho 0.7, tức khoảng 1.40 đô la.

Haiku 4.5: lượt mẫu giá khoảng 50 xu, giá token niêm yết bằng một nửa. Trong minh họa này, giả sử dùng lượng token gấp khoảng 1.6 lần và hoàn thành 40 phần trăm lần thử. Với giả định đó, mỗi việc hoàn thành tốn khoảng 2 đô la. Lượng dùng thêm và tỷ lệ thành công là đầu vào giả định, không phải quan sát do mô hình rẻ hơn gây ra.

Trong ví dụ giả định này, mô hình giá token bằng một nửa có chi phí tính toán mỗi việc hoàn thành cao hơn vì mức dùng và tỷ lệ thất bại giả định lấn át ưu thế giá. Điều này minh họa công thức, không xác định mô hình nào đáng tiền hơn trong dự án của bạn.

Lưu ý: Tôi đã dùng các tỷ lệ thành công mẫu 70 và 40 phần trăm cùng khối lượng token mẫu để minh họa cách cơ chế này hoạt động. Số liệu của bạn sẽ khác, và hoàn toàn có thể một mô hình nhẹ xử lý tốt khối lượng công việc của bạn mà vẫn là lựa chọn rẻ nhất. Mô hình đắt hơn không nhất thiết đáng tiền hơn; hãy so sánh chi phí mỗi kết quả bằng ba con số của chính bạn.

Cách tính chi phí cho mỗi nhiệm vụ của bạn: ba hồ sơ?#

Để áp dụng vào công việc của bạn, hãy ước tính hồ sơ nào phù hợp nhất. Công thức vẫn như cũ; chỉ ba con số thay đổi.

Hồ sơ một: nhiệm vụ đơn giản, lặp lại. Viết lại văn bản, sắp xếp dữ liệu, sửa mã nhỏ. Thử xem mô hình nhẹ như Haiku hoặc DeepSeek V4-Flash có đạt tiêu chí chấp nhận với lượng dùng thấp và ít thử lại không. So chi phí đo được mỗi kết quả dùng được với ứng viên khác trước khi gọi mô hình nào rẻ nhất hoặc cho rằng Opus là trả quá mức.

Hồ sơ hai: công việc phức tạp với mã chưa quen. Tìm hiểu dự án người khác, sửa lỗi khó nhận ra, tạo tính năng. Đo toàn bộ lần thử. Mô hình giá token cao hơn có thể rẻ hơn trên mỗi kết quả dùng được nếu thành công tăng hoặc lượng dùng giảm đủ bù giá; lợi thế phải được kết quả chứng minh thay vì suy từ loại mô hình.

Hồ sơ ba: khối lượng công việc hỗn hợp. So thiết lập một mô hình với định tuyến việc thường ngày và việc khó cho các ứng viên khác nhau. Tính lượng dùng, lỗi và công sửa của toàn bộ công việc. Định tuyến có thể cải thiện chi phí mỗi kết quả, nhưng bài này chưa đo nó là phương án rẻ nhất. Nhiều tác nhân cho phép đổi mô hình khi làm việc.

Hãy tính riêng từng hồ sơ bằng cùng một công thức, bạn sẽ thấy phương án nào có chi phí thấp hơn.

Sai lầm phổ biến nhất khi chọn là gì?#

Chọn theo giá có thể che kết quả khác nhau giữa các công việc. Một mô hình có thể làm việc thường ngày kinh tế nhưng cần thêm lần thử cho tính năng khó. Những lần thử ấy có khiến kết quả đắt hơn mô hình khác không phải được trả lời bằng mức dùng và tỷ lệ hoàn thành đo được, không phải nhãn giá thấp.

Chiều ngược lại cũng có thể xảy ra: nếu mô hình nhẹ hoàn thành cùng nhiệm vụ được chấp nhận với một phần ba chi phí, chọn thiết lập giá cao hơn sẽ tăng chi không cần thiết. Đây là so sánh có điều kiện; thử chất lượng, số lần thử và chi phí trước khi giả định mô hình rẻ hơn làm được vậy.

Một ghi chú về cách làm của riêng tôi. Tôi sử dụng Claude Code và thuê bao; tôi không dùng API thông thường cho công việc hằng ngày vì thích khoản phí dự đoán được hơn một đồng hồ tính tiền liên tục. Nhưng sau một năm rưỡi làm việc hằng ngày với AI, tôi đi đến một kết luận: cách tổ chức công việc có thể thay đổi chi phí mỗi nhiệm vụ hoàn thành, nhưng vẫn phải tính giá mô hình, tổng token qua mọi lần thử và tỷ lệ thành công. Trải nghiệm này chưa đo tách biệt yếu tố nào quan trọng nhất. Nhiệm vụ rõ và ngữ cảnh phù hợp là những điểm có thể cải thiện. Chúng có thể đổi mức token và tỷ lệ thành công, nhưng cần đo cùng mô hình và giá thay vì cho rằng chỉ ngữ cảnh gọn đã khiến mô hình rẻ xử lý được việc.

Vậy tác nhân nào rẻ hơn?#

Không có một tác nhân nào “rẻ nhất” trong mọi trường hợp, và giờ bạn đã thấy lý do: khả năng tiết kiệm được đo bằng chi phí mỗi kết quả, và chi phí này thay đổi theo khối lượng công việc. Chỉ giá gói hoặc giá mỗi token là chưa đủ; cần tính cùng tổng lượng dùng và tỷ lệ thành công. Hãy tính chi phí lần chạy, thay tỷ lệ nhiệm vụ hoàn thành của chính bạn vào, chia và so sánh các con số đó — rồi cập nhật phép tính khi giá hoặc công việc thay đổi.

Chi phí cho mỗi nhiệm vụ được giải quyết phụ thuộc vào giá mô hình, số token dùng trong tất cả các lần thử và tỷ lệ nhiệm vụ thực sự thành công. Ngữ cảnh và cách làm việc có thể thay đổi lượng token và tỷ lệ thành công; đổi mô hình cũng có thể thay đổi chúng. Các tỷ lệ minh họa phía trên không đo lường yếu tố nào quan trọng nhất. Hãy so sánh các mô hình trên cùng nhóm nhiệm vụ đại diện, tính cả lần thử lại và phần con người phải sửa, rồi chọn theo chi phí đo được cho mỗi kết quả dùng được.

Ngữ cảnh gọn gàng và công việc có cấu trúc có thể thay đổi lượng token và tỷ lệ thành công. Cách làm việc, mô hình được chọn và giá mô hình đều phải được tính khi đo chi phí mỗi nhiệm vụ hoàn thành, gồm mọi lần thử và phần con người phải sửa.

Tìm hiểu về Ailoot.