Cứ hễ thấy ai claim “giảm 95% token, giữ nguyên chất lượng” là mình dừng lại ngay. Không phải vì hoài nghi cho vui, mà vì câu hỏi thực tế luôn là: đo kiểu gì ra con số đó?
Headroom — repo 37k sao trên GitHub — là một trong những công cụ nén context nổi nhất dạo này. Đội Nous Research (nhóm đứng sau Hermes, repo 196k sao) vừa ngồi benchmark nghiêm túc trên dữ liệu thật. Kết quả thú vị hơn mình nghĩ, theo cả hai hướng.
Headroom là gì và hoạt động ra sao?
Headroom đặt mình ở vị trí trung gian giữa agent và nhà cung cấp mô hình ngôn ngữ. Trước khi nội dung nào đó (kết quả công cụ, log, file, lịch sử hội thoại) được gửi tới mô hình, Headroom nén nó lại.
Có ba cơ chế chính:
SmartCrusher / diff — chuyển JSON và git diff thành dạng đặc hơn (CSV + schema). Không mất dữ liệu, mô hình đọc trực tiếp không cần giải mã lại.
CCR (Compress-Cache-Retrieve) — thay nội dung lớn bằng một đoạn đánh dấu kiểu <<ccr:HASH>>, cất bản gốc ở local. Khi agent cần, gọi headroom_retrieve để lấy lại.
Kompress-base — mô hình học máy riêng, dùng để nén văn xuôi tự nhiên.
Về kiến trúc: chạy hoàn toàn trên máy, dữ liệu không đi đâu cả, có thể phục hồi nguyên bản. Nghiêm túc, không phải đồ chơi.
https://github.com/chopratejas/headroom
Con số 95% đến từ đâu?
Nous Research cắm Headroom vào một agent thật, chạy benchmark trên 3.000 kết quả công cụ thật lấy từ cơ sở dữ liệu session. Đây là dạng đánh giá đáng tin — không phải benchmark giả lập.
Kết quả: con số 60–95% tiết kiệm token chủ yếu đến từ CCR.
Và đây là phần đáng suy nghĩ.
Vấn đề với CCR
CCR hoạt động đúng như thiết kế — nhưng thiết kế của nó không phù hợp với cách agent dùng tool output.
Khi CCR thay một đoạn nội dung bằng <<ccr:HASH>>, agent đọc thấy marker đó và… cần dữ liệu thật để xử lý. Nên nó gọi headroom_retrieve để lấy về ngay. Kết quả: nội dung nằm trong context hai lần — một lần là marker, một lần là blob được lấy về. Tốn token hơn cả không nén.
CCR sinh ra để xử lý lịch sử hội thoại đã đi qua (kiểu proxy cache), không phải tool result mà agent đang cần dùng ngay. Dùng sai ngữ cảnh thì ngược lại với mục tiêu ban đầu.
Lưu ý thêm: Nếu model bỏ sót marker và không retrieve, nó sẽ suy luận trên thông tin thiếu. Với mức độ ảo giác của agent hiện tại, đây không phải rủi ro nhỏ.
Phần thật sự hoạt động tốt
SmartCrusher — nén JSON/diff kiểu lossless — là cơ chế đáng dùng nhất. Nous verify đàng hoàng: nén mảng 200 bản ghi, lấy lại đủ 200 hàng, không thiếu cái nào. Mô hình đọc trực tiếp CSV + schema, không cần thêm bước giải mã.
Vấn đề: trong toàn bộ lưu lượng request thật, SmartCrusher chỉ áp dụng được trên 6,2% request, mang lại tiết kiệm thực tế khoảng 0,34%.
Đọc lại cho chắc: không phải 95%. Là 0,34%. Trên dữ liệu agent thật.
Nous Research làm gì sau đó?
Sau khi đánh giá xong, họ từ chối đưa Headroom vào làm dependency. Thay vào đó, họ tự viết 40 dòng code nén riêng cho hàm search_files của mình — đạt 57,8% tiết kiệm lossless, vượt Headroom ngay ở case mạnh nhất của nó.
Điều đó không có nghĩa Headroom vô dụng. Nó có nghĩa là: hiểu nguyên lý rồi tự viết tối ưu cho đúng bài toán của mình thường hiệu quả hơn rước nguyên cả thư viện về.
Nên rút ra gì từ chuyện này?
Headroom có ý tưởng hay — đặc biệt phần JSON → CSV + schema. Nhưng kết quả thực tế phụ thuộc rất nhiều vào loại dữ liệu agent đang xử lý và cách dùng từng cơ chế.
Nếu bạn đang tìm cách giảm token cho agent:
- Nén lossless (JSON/diff → dạng đặc hơn) là hướng đúng, hiệu quả thật, không ảnh hưởng chất lượng
- Cơ chế “cất tạm rồi lấy lại” cần hiểu rõ agent của bạn xử lý thông tin lúc nào — không phải cứ marker là tiết kiệm
- Con số benchmark chung chung ít khi áp dụng đúng vào workload cụ thể của bạn — test trên dữ liệu thật của mình mới tin được
Đôi khi 40 dòng code tự viết, đúng bài toán, còn đáng hơn một dependency hoành tráng với README đẹp.
Bạn đang dùng cách nào để tối ưu token cho agent? Chia sẻ bên dưới nhé!
Để lại một bình luận