RTK báo tiết kiệm token khổng lồ, nhưng đo chi phí thực tế lại cho kết quả ngược lại

Công nghệ11 tháng 9, 2026·8 phút đọc

RTK (Rust Token Killer) với hơn 79k sao GitHub được quảng cáo có thể cắt giảm tới 60% token khi dùng AI viết code. Tuy nhiên, thử nghiệm tốn hơn 1.500 USD trên Terminal-Bench 2.1 cho thấy chi phí thực tế không giảm, thậm chí tăng tới 17% với một số mô hình. Nguyên nhân nằm ở việc nén đầu ra terminal không đồng nghĩa với giảm hóa đơn.

RTK báo tiết kiệm token khổng lồ, nhưng đo chi phí thực tế lại cho kết quả ngược lại

RTK báo tiết kiệm token khổng lồ, nhưng đo chi phí thực tế lại cho kết quả ngược lại

RTK (Rust Token Killer) đang là một trong những công cụ phổ biến nhất giúp việc lập trình với AI rẻ hơn, với hơn 79.000 sao GitHub. Công cụ này lọc và nén đầu ra terminal trước khi tác nhân AI đọc. Một bài đăng trên X khẳng định RTK có thể cắt tới 60% token của Claude Code đã đạt 313.000 lượt xem. Nhưng khi đo chi phí thực tế trên benchmark, bức tranh hoàn toàn khác.

RTK hoạt động như thế nào?

RTK có thể viết lại các lệnh Git, kiểm thử, đóng gói và thao tác tệp mà tác nhân AI chạy qua công cụ shell (Bash trong Claude Code, bash trong OpenCode). Mỗi lần viết lại, nó trả về một phiên bản đầu ra ngắn gọn hơn.

Ví dụ, RTK giữ lại tên tệp, kích thước và quyền (644 nghĩa là rw-r—r—) nhưng bỏ chủ sở hữu và ngày tháng:

$ ls -la /app/warriors
-rw-r--r-- 1 root root  824 Sep 13  2025 g2-clear.red
-rw-r--r-- 1 root root  487 Sep 13  2025 paper.red

$ rtk ls -la warriors/
644  g2-clear.red  824B
644  paper.red  487B

Nghe có vẻ hợp lý: ít đầu ra hơn nghĩa là ít token hơn. Nhưng đó là nơi sai lầm bắt đầu.

Minh họa quy trình nén đầu ra terminal của RTKMinh họa quy trình nén đầu ra terminal của RTK

Thử nghiệm trên Terminal-Bench 2.1

Vì RTK nén đầu ra terminal, nhóm nghiên cứu đã thử nghiệm trên Terminal-Bench 2.1 — một benchmark có tương tác terminal dày đặc. Họ chạy Claude Code với Fable 5.0 và OpenCode với DeepSeek V4 Pro 0813 qua OpenRouter. Mỗi tác vụ được lên lịch năm lần không có RTK và năm lần có RTK, trên cùng tuyến mô hình, nền tảng và thời gian chờ.

Sau khi loại bỏ bốn tác vụ bảo mật của Fable bị từ chối, so sánh cuối cùng bao gồm 85 tác vụ Fable và 89 tác vụ DeepSeek, tương đương 1.740 lần thử.

Kết quả ban đầu trông khá hứa hẹn:

  • Với Fable, chi phí giảm 5% khi dùng RTK (từ 596 USD xuống 546 USD).
  • Với DeepSeek, chi phí lại tăng 5% (từ 26 USD lên 31 USD).

Tỷ lệ vượt qua cũng thấp hơn khi dùng RTK: giảm 1% với Fable và 2% với DeepSeek.

Khi chia toàn bộ chi tiêu — bao gồm cả các lần thất bại — cho số lần vượt qua, Fable rẻ hơn 3% với RTK, còn DeepSeek đắt hơn 7%.

Một tác vụ thay đổi toàn bộ kết quả

Gần như toàn bộ khoản tiết kiệm của Fable đến từ một tác vụ duy nhất: winning-avg-corewars. Cả hai cấu hình đều vượt qua mọi lần thử, nhưng với RTK, tác vụ hoàn thành chỉ trong khoảng một nửa số lượt. Với các tác vụ còn lại, mức tiết kiệm chưa đến 1%.

DeepSeek thì ngược lại ở chính tác vụ đó: cả hai đều vượt qua, nhưng RTK tốn nhiều lượt hơn và đắt hơn. Ngay cả khi bỏ tác vụ này ra, chi phí vẫn cao hơn với RTK.

Đây là một bài học quan trọng: một tác vụ ngoại lệ có thể che lấp xu hướng chung của cả benchmark.

"rtk gain" không phải là thước đo chi phí

RTK ghi nhận chỉ số rtk gain là hiệu số byte đầu ra lệnh thô trừ đi đầu ra đã lọc, chia cho 4 — không phải số token bị tính phí.

Trên 445 lần thử DeepSeek có dùng RTK, công cụ báo cáo tiết kiệm 349,2 triệu token, tương đương mức giảm 89%. Nhưng khoản tiết kiệm token khổng lồ này không hề đồng nghĩa với chi phí thấp hơn.

Ví dụ điển hình: trong tác vụ train-fasttext, mô hình yêu cầu head -1 train.txt hai lần. RTK ghi nhận tiết kiệm 120,5 triệu token mỗi lần bằng cách so sánh những lần đọc giới hạn đó với toàn bộ tệp. Hai lệnh gọi này chiếm 69% bộ đếm tiết kiệm của phép so sánh — dù lệnh yêu cầu sẽ không bao giờ trả về toàn bộ tệp.

Coi rtk gain là tiền tiết kiệm giả định phần còn lại của lần thử sẽ giữ nguyên. Nhưng RTK có thể thay đổi các lượt tiếp theo của tác nhân — và chỉ số này không tính đến chi phí của những lượt đó.

Đây chính là chỗ các bài đăng mạng xã hội đi sai hướng: rtk gain đếm đầu ra bị loại bỏ, không phải tiền tiết kiệm, và nó có thể khiến một lần thử đắt đỏ trông như đã được tối ưu.

Biểu đồ so sánh chỉ số tiết kiệm token và thay đổi chi phí thực tếBiểu đồ so sánh chỉ số tiết kiệm token và thay đổi chi phí thực tế

Lỗi của RTK có thể khiến bạn trả giá đắt

Một lần thử DeepSeek git-multibranch bị kẹt trong vòng lặp. Tác nhân chạy lệnh find với một cờ mà rtk find 0.45.0 không hỗ trợ. Plugin viết lại thành rtk find, lệnh này thất bại với thông báo "Use find directly". Mỗi lần thử lại đều bị viết lại tiếp.

Tác nhân tích lũy 339 lỗi liên tiếp trước khi hết thời gian chờ, mất khoảng 12 phút. Tác vụ vẫn vượt qua, nhưng tốn gấp khoảng 9 lần so với lần thử baseline tương ứng. RTK đã sửa lỗi này trong phiên bản 0.46.0, sau khi nhóm nghiên cứu hoàn tất các lần chạy.

Đầu ra terminal chỉ chiếm phần nhỏ trong hóa đơn

Không dùng RTK, đầu ra công cụ chỉ chiếm khoảng 11% token đầu vào của Fable40% của DeepSeek.

Trong các lần thử có RTK, 31% lệnh gọi terminal của Claude Code và 51% của OpenCode thực sự dùng RTK. RTK chỉ viết lại lệnh shell: hook của Claude Code khớp với công cụ Bash, plugin OpenCode tác động lên lệnh bash. Cả hai nền tảng đều để việc đọc và tìm kiếm tệp qua các công cụ riêng biệt như Read, Grep và Glob — những công cụ này bỏ qua RTK hoàn toàn.

Đáng chú ý, khoảng một nửa số lệnh Bash của Claude Code đã tự giới hạn đầu ra bằng head, tail hoặc wc.

Trong lập trình tác nhân, ngữ cảnh được lưu đệm sau mỗi lượt, nên các lần đọc đầu ra terminal sau đó chủ yếu hiện ra dưới dạng đọc bộ đệm. Những lần đọc này chỉ tốn 1/10 token đầu vào thường với Fable và 1/30 với DeepSeek.

Lượt tăng thêm có thể xóa sạch khoản tiết kiệm

Khi tác nhân thực hiện nhiều lượt hơn, chi phí tác vụ thường tăng theo.

Với DeepSeek, các lần thử có RTK tốn nhiều lượt hơn ở 58 tác vụ, và 44 trong số đó tốn nhiều tiền hơn. Chúng tốn ít lượt hơn ở 28 tác vụ, và 23 trong số đó rẻ hơn.

Một lượt trung bình của DeepSeek có lượng đầu vào ít hơn 7% khi dùng RTK, nhưng tổng số lượt lại nhiều hơn 18%. Những lượt nhỏ hơn không cộng lại thành tổng đầu vào ít hơn.

Một lượt tác nhân tăng thêm có thể tốn nhiều hơn khoản nén tiết kiệm được. Đây chính là vấn đề lạm phát token dưới một hình thức khác.

JetBrains cũng quan sát thấy mô hình tương tự trên SkillsBench: RTK làm tăng số lượt ở mức nỗ lực thấp và không hạ được chi phí ở mức nỗ lực cao.

Kết luận: RTK không làm lập trình AI rẻ hơn

Trên Terminal-Bench 2.1, khoản tiết kiệm của Fable phụ thuộc vào một tác vụ duy nhất và không giữ vững trên toàn bộ các tác vụ. Vì vậy, RTK không nên được coi là công cụ tiết kiệm chi phí phổ quát.

Các bản ghi riêng lẻ cho thấy những mô hình tiên tiến hiện nay đã sử dụng terminal khá hiệu quả — chỉ khoảng 7% ngữ cảnh của Fable là đầu ra terminal. Các mô hình tự biết dùng những kỹ thuật như head -n hay tail -n. RTK có lẽ hữu ích hơn với các mô hình đời cũ. Ngày nay, nó là một tối ưu hóa ngách, không phải nguồn tiết kiệm tổng quát.

Đồ thị tương quan giữa số lượt và chi phí khi dùng RTKĐồ thị tương quan giữa số lượt và chi phí khi dùng RTK

Góc nhìn cho lập trình viên Việt Nam

Với anh em lập trình viên đang dùng Claude Code, Cursor hay các tác nhân AI khác, bài học ở đây khá rõ ràng: đừng tin vào con số tiết kiệm token được quảng cáo. Chỉ số quan trọng là chi phí trên mỗi tác vụ hoàn thành, chứ không phải số byte đầu ra bị cắt bỏ.

Nếu bạn đang cân nhắc tích hợp RTK, hãy đo trên chính quy trình làm việc của mình thay vì dựa vào các bài đăng lan truyền. Và nhớ rằng: một lượt tác nhân tăng thêm có thể ăn hết phần bạn tiết kiệm được từ việc nén log.

Các thử nghiệm được thực hiện với RTK 0.45.0, Claude Code 2.1.220, OpenCode 1.18.25 và Harbor 0.20.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗