Một thử nghiệm mới cho thấy trong tác vụ lập trình, mô hình AI có giá token thấp chưa chắc là lựa chọn tiết kiệm hơn. Theo nhóm nghiên cứu, để đánh giá chi phí thực tế, cần xem đồng thời tỷ lệ hoàn thành, độ dài phản hồi và chi phí cho mỗi ca sửa lỗi thành công, thay vì chỉ nhìn vào bảng giá API.

Theo Gigazine ngày 22/9, nhóm nghiên cứu thuộc Fiddler, công ty chuyên quan sát và đánh giá AI, đã so sánh Claude Haiku 4.5 với Claude Sonnet 5 của Anthropic trong một bài kiểm tra lập trình. Kết quả cho thấy Haiku, dù rẻ hơn về đơn giá token, lại tiêu tốn nhiều tiền hơn để hoàn thành một ca sửa lỗi thành công.

Bài thử nghiệm gồm 5 nhiệm vụ sửa lỗi trong một chương trình Python. Mỗi nhiệm vụ được chạy 3 lần, tạo thành một bộ gồm 15 lượt thử, và mỗi mô hình được chạy 3 bộ. Tổng cộng, mỗi mô hình trải qua 45 lượt thử, tương đương 90 lượt cho cả hai mô hình.

Ở mỗi lượt, mô hình AI thực hiện các tác vụ như kiểm tra tệp, chỉnh sửa mã và chạy kiểm thử. Môi trường thử nghiệm được thiết kế để trong mỗi phản hồi của mô hình chỉ có một lệnh thực sự được thực thi. Bài kiểm tra kết thúc khi mô hình xác nhận đã hoàn tất sửa lỗi; nếu không đưa ra xác nhận này, hệ thống sẽ dừng sau tối đa 8 lượt phản hồi.

Điểm mà nhóm nghiên cứu tập trung không phải là giá token, mà là tổng chi phí để đạt được một ca sửa lỗi thành công. Kết quả được xác thực bằng một bài kiểm tra riêng không cung cấp trước cho mô hình, và chỉ những trường hợp vượt qua bài kiểm tra này mới được tính là thành công. Từ đó, nhóm lấy tổng chi phí, bao gồm cả các lượt thất bại, chia cho số lần thành công để tính chi phí cho mỗi ca sửa lỗi thành công.

Kết quả cho thấy chênh lệch rất lớn. Trong 45 lượt thử, Sonnet chỉ tiêu tốn 0,45 USD, trong khi Haiku mất tới 4 USD. Tính theo từng bộ thử nghiệm, chi phí cho mỗi ca sửa lỗi thành công của Haiku cao hơn Sonnet từ 8,4 đến 14,1 lần.

Đáng chú ý, nếu chỉ xét đơn giá token thì kết quả lại hoàn toàn ngược lại. Giá token đầu vào và đầu ra của Haiku chỉ bằng khoảng một nửa Sonnet. Tuy nhiên, trong tác vụ thực tế, Haiku tạo ra lượng token lớn hơn đáng kể, khiến lợi thế về giá gần như bị xóa nhòa.

Nguyên nhân lớn nhất nằm ở độ dài phản hồi. Trung vị token đầu ra của Sonnet là 16, trong khi con số này ở Haiku lên tới 361. Theo nhóm nghiên cứu, Haiku có xu hướng tạo sẵn cả kết quả cho những lệnh chưa hề được thực thi.

Thay vì chờ kết quả chạy thực tế, mô hình viết trước kết quả dự kiến, rồi tiếp tục sinh thêm lệnh và kết quả tiếp theo dựa trên giả định đó. Hệ quả là cả những nội dung chưa từng được thực thi trong môi trường thật vẫn bị tính vào token đầu ra, kéo chi phí tăng mạnh.

Vấn đề này thể hiện rõ nhất ở một lượt thử cụ thể. Haiku tạo ra một phản hồi chứa tới 60 lệnh cùng các kết quả thực thi giả định, sử dụng tổng cộng 21.492 token trước khi thông báo đã sửa xong lỗi.

Tuy nhiên, trong môi trường thử nghiệm, chỉ lệnh đầu tiên trong phản hồi đó được thực thi. 59 lệnh còn lại chỉ tồn tại dưới dạng văn bản nhưng vẫn bị tính vào chi phí đầu ra.

Phản hồi dài cũng làm chi phí tăng ở các lượt sau. Do môi trường thử nghiệm phải nạp lại toàn bộ ngữ cảnh hội thoại trước đó trong mỗi lượt, một phản hồi quá dài sẽ khiến lượng token đầu vào ở các tương tác tiếp theo phình to.

Trong ví dụ do nhóm nghiên cứu đưa ra, đến lượt tương tác thứ 5, số token đầu vào của Haiku là 9.930, trong khi Sonnet chỉ ở mức 1.220. Điều này cho thấy chỉ một phản hồi kéo dài cũng có thể đẩy mạnh chi phí ở những lượt kế tiếp.

Phân tích bổ sung cho thấy chi phí của Haiku chênh lệch rõ rệt theo độ dài phản hồi. Với nhóm phản hồi ngắn, chi phí trung bình mỗi lượt là 0,00235 USD, thấp hơn mức trung bình chung 0,00244 USD của Sonnet. Ngược lại, ở nhóm phản hồi dài, chi phí mỗi lượt lên tới 0,01693 USD, cao gấp 7,2 lần nhóm phản hồi ngắn.

Nói cách khác, vấn đề không nằm ở việc Haiku có đơn giá token thấp, mà ở chỗ mô hình này có thể tạo ra các phản hồi dài không cần thiết cho tác vụ, qua đó làm thay đổi đáng kể cấu trúc chi phí.

Dù vậy, nhóm nghiên cứu cũng lưu ý rằng kết quả này không có nghĩa mọi tác vụ lập trình đều cho ra kết quả tương tự. Chi phí thực tế có thể thay đổi tùy loại nhiệm vụ, môi trường thực thi và cách triển khai mô hình. Tuy nhiên, khi đưa AI vào quy trình lập trình, doanh nghiệp không nên chỉ so sánh giá token đầu vào và đầu ra, mà cần thử mô hình trên các bài toán gần với thực tế, đồng thời đo tỷ lệ thành công, độ dài phản hồi và chi phí cho mỗi ca hoàn thành thành công, bao gồm cả các lượt thất bại.

Thử nghiệm này cũng cho thấy trong môi trường lập trình dựa trên AI agent, tiêu chí lựa chọn mô hình có thể khác đáng kể so với cách đánh giá thông thường. Một phản hồi dài không cần thiết không chỉ làm tăng chi phí đầu ra mà còn đẩy chi phí đầu vào lên ở các lượt hội thoại kế tiếp.

Theo nhóm nghiên cứu, năng lực cạnh tranh về chi phí của AI lập trình không nằm ở mức giá cho mỗi token, mà ở số tiền thực tế phải bỏ ra để hoàn thành công việc. Ngay cả khi chọn mô hình có giá rẻ, nếu phản hồi quá dài và hiệu quả xử lý thấp lặp lại, tổng chi phí vận hành vẫn có thể cao hơn đáng kể. Vì vậy, việc đo chi phí trong môi trường làm việc thực tế là yếu tố đặc biệt quan trọng.