Tokenmaxxing: Tại sao việc đo lường hiệu quả AI bằng số lượng token tiêu thụ là sai lầm?

Meta và OpenAI đang chạy các bảng xếp hạng nội bộ. Không phải dựa trên số lượng commit đã đẩy, lỗi đã sửa hay sản phẩm đã ra mắt, mà dựa trên số lượng token tiêu thụ.

Một kỹ sư của OpenAI reportedly đã "đốt" 210 tỷ token chỉ trong một tuần — tương đương với việc đọc 33 bộ Wikipedia, xử lý và vứt bỏ. Điều này dường như đang trở thành một chỉ số hiệu suất đáng để theo dõi. Hiện tượng này có một cái tên: tokenmaxxing.

Gizmodo đã ví von việc này giống như bảo lính đo thành tích chiến trường bằng số lượng đạn đã bắn. Họ hoàn toàn đúng đấy. Nhưng vấn đề thực tế tinh tế hơn và đi sâu hơn vào cách chúng ta nghĩ về năng suất của AI Agent vào năm 2026.

Vấn đề về chi phí ẩn (Overhead)

Tyler Folkman đã thực hiện một thí nghiệm trong tuần này. Ông đặt một câu hỏi đơn giản — "3 thành phố lớn nhất ở Utah là gì?" — thông qua một cuộc gọi API thô và thông qua một khung tác nhân hiện đại (Deep Agents của LangChain).

• API thô: 77 token.
• Thông qua khung tác nhân: 5.983 token. Bảy cuộc gọi LLM. Hệ số nhân là 78 lần.

Đối với một nhiệm vụ phức tạp hơn — sửa lỗi yêu cầu đọc và chỉnh sửa tệp — tỷ lệ này là 34 lần. Tác nhân tiêu thụ 151.120 token để hoàn thành công việc mà API thô có thể xử lý chỉ với 4.492 token.

Chi phí ẩn đến từ đâu? Không phải từ trí thông minh. Không phải từ khả năng. Mà là từ Scaffolding (giàn giáo).

• System prompt: ~400 token
• Todo middleware: ~400 token
• Tool schemas, hướng dẫn tác nhân con, boilerplate JSON serialization: 3.000+ token

Mọi cuộc gọi công cụ, mọi lần tạo tác nhân con, mọi cập nhật trạng thái — tất cả đều là token. Đối với một mô hình biên với cửa sổ ngữ cảnh một triệu token, đây chỉ là tiếng ồn. Nhưng đối với một mô hình cục bộ 14B với ngữ cảnh 32K, giàn giáo này tiêu tốn 19% bộ nhớ làm việc có sẵn trước khi tác nhân nhìn thấy một từ nào của nhiệm vụ thực tế của bạn.

Bây giờ hãy tưởng tượng một công ty mà các kỹ sư của họ được đánh giá dựa trên lượng token tiêu thụ. Về mặt cấu trúc, họ được khuyến khích xây dựng các kiến trúc tác nhân nhiều giàn giáo hơn, chi phí ẩn cao hơn và lãng phí hơn. Chỉ số này đang khen thưởng cho một căn bệnh.

Hiệu quả thực sự trông như thế nào?

Trong khi các kỹ sư của Meta đang leo lên bảng xếp hạng token, một nhà phát triển tên là Dan Woods đã áp dụng nghiên cứu "LLM in a Flash" của Apple vào Qwen3.5-397B — một mô hình Mixture-of-Experts (Hỗn hợp chuyên gia) với 397 tỷ tham số. Bằng cách truyền tải các trọng số chuyên gia không hoạt động từ SSD sang RAM theo yêu cầu, nó chỉ giữ khoảng 17 tỷ tham số hoạt động tại bất kỳ thời điểm nào. Trên MacBook với 48GB RAM: 5,5 token mỗi giây. Trên Apple Silicon cao cấp hơn: reportedly ~20 token mỗi giây.

Một mô hình 397 tỷ tham số chạy cục bộ, miễn phí, với chất lượng hàng đầu, và chi phí token API bằng không.

Kiến trúc này rất lớn về lý thuyết nhưng thưa thớt trong thực tế. Không phải tất cả các phần của mô hình đều cần hoạt động cho bất kỳ token nào. Hiệu quả không phải là một ràng buộc — nó là thiết kế.

Đây cũng là mô hình tư duy đúng đắn cho công việc của tác nhân. Công nghệ để làm cho token trở nên rẻ đã có ở đây. Vấn đề quan trọng là liệu công cụ đo lường của chúng ta có theo kịp để biết những token đó đã hoàn thành được gì hay không.

Chỉ số đúng đắn

Đây là những gì tôi thực sự muốn đo lường:

Agent Efficiency Ratio = Tasks Completed Successfully / (Total Token Cost × Revision Count)

Hoặc thực tế hơn:

Chỉ số	Nó đo lường gì
Tỷ lệ hoàn thành nhiệm vụ	Tác nhân có hoàn thành những gì bắt đầu không?
Tỷ lệ thành công ở lần thử đầu tiên	Tác nhân cần sửa đổi bao nhiêu lần?
Token cho mỗi nhiệm vụ hoàn thành	Đầu ra được chuẩn hóa theo chi phí
Tỷ lệ sửa đổi	Làm lại dưới dạng phân số của tổng công việc

Một tác nhân đốt 10.000 token và gửi một PR hoạt động tốt hơn một tác nhân đốt 2.000 token nhưng tạo ra thứ bạn phải sửa ba lần. Tác nhân thứ hai có số lượng token thấp hơn nhưng chi phí thất bại cao hơn.

Tại sao điều này quan trọng ngay bây giờ

Hai điều đang diễn ra đồng thời:

Các doanh nghiệp đang áp dụng tác nhân ở quy mô lớn. Karpathy nói rằng ông chưa viết một dòng code nào kể từ tháng 12 — ông chỉ chỉ đạo các tác nhân. OpenCode, giải pháp thay thế mã nguồn mở cho Claude Code, có hơn 120.000 sao GitHub và 5 triệu người dùng hàng tháng. Đây không phải là một công nghệ ngách.

Không ai có công cụ đánh giá tốt. Cơ sở hạ tầng đo lường chưa theo kịp thực tế triển khai. Con số duy nhất dễ thu thập là token, vì vậy token trở thành chỉ số đại diện — mặc dù token đo lường mức tiêu thụ, không phải giá trị.

Các công ty tìm ra cách đo lường tác nhân dựa trên kết quả trước tiên sẽ có hai lợi thế:

1. Họ sẽ xây dựng các kiến trúc tác nhân tốt hơn (tối ưu hóa cho việc hoàn thành nhiệm vụ, không phải thông lượng token).
2. Họ sẽ có thể đưa ra một trường hợp kinh doanh không sụp đổ khi ai đó hỏi "nhưng nó thực sự đã làm gì?".

Kết luận

Các công ty đo lường việc đốt token như một chỉ số năng suất là một triệu chứng, không phải là căn bệnh. Căn bệnh là chúng ta chưa có cách tốt để đo lường những gì tác nhân thực sự hoàn thành.

Sự mỉa mai: các công ty đang xây dựng cơ sở hạ tầng đánh giá ngay bây giờ — những người tìm ra tỷ lệ hoàn thành nhiệm vụ, tỷ lệ sửa đổi, kết quả trên mỗi đồng — sẽ có thể chứng minh chính xác tại sao những người ở bảng xếp hạng đang đốt token vô ích.

Ví dụ về chiến trường là đúng. Hãy tính toán lãnh thổ chiếm được, không phải số đạn đã bắn.

Håkon Åmdal xây dựng AgentLair, cơ sở hạ tầng email và danh tính cho các tác nhân AI. Ông vận hành một tác nhân Claude tự động xử lý mã, tiếp cận và vận hành — và đo lường nó theo số nhiệm vụ hoàn thành, không phải token đã đốt.