SoL-Pi giảm 45–49% token trong EdgeBench — chưa có nghĩa coding agent của bạn sẽ rẻ đi một nửa
NVlabs báo cáo SoL-Pi dùng ít token hơn Pi đáng kể trên EdgeBench. Điều quan trọng là hiểu capability gate và thử lại trên workload của chính bạn trước khi suy rộng con số.
Xong bài này bạn làm được Tránh mua hoặc đổi harness chỉ vì một benchmark headline; thay vào đó đo cost cùng capability gate trên task đại diện của chính nhóm.
Một headline “coding agent dùng ít hơn gần nửa token” rất dễ dẫn tới kết luận: đổi harness là hóa đơn API sẽ giảm gần một nửa. Nghiên cứu SoL-Pi của NVIDIA/NVlabs đáng chú ý hơn thế — và cũng hẹp hơn thế.
Trang dự án SoL-Pi báo cáo rằng trên EdgeBench, harness này dùng 45–49% ít token hơn Pi và chi phí theo giá API tương đương giảm khoảng một phần ba, trong khi giữ khoảng 94% điểm trung bình của Pi trên hai model backend được đánh giá. Nhóm nghiên cứu cũng công bố Terminal-Bench 4: SoL-Pi giải 15/63 task, trong khi Codex và Pi đều giải 18/63, với tổng chi phí API-equivalent thấp hơn.
Những con số đó là bằng chứng cho một thiết kế harness cụ thể trong các benchmark cụ thể. Chúng không phải cam kết rằng repository của bạn sẽ giảm 45–49% token mà không đổi chất lượng.
SoL-Pi tối ưu phần nào của coding agent?
Điểm thú vị của công trình là nó không chỉ đổi model. Nhóm nghiên cứu dùng các vòng auto-research để tìm cách giảm công việc thừa ở harness — lớp tổ chức tool calls, context, observations và delegation quanh model. Từ 152 hướng đề xuất, bốn cơ chế sống sót vào harness cuối:
- Action Fusion: gộp một edit với lệnh kiểm tra tiếp theo vào cùng chuỗi cục bộ, giảm một model round trip khi pattern phù hợp.
- Online Context Compact: cân nhắc compact context ở ranh giới subtask thay vì chỉ đợi context phình lớn.
- ObservationPack: lưu tool output lớn ở local, giữ handle/excerpt trong context và chỉ gọi lại phần cần thiết.
- Evidence-Preserving Reducer: rút gọn log chẩn đoán nhưng buộc phần tóm tắt phải kiểm được với log đã lưu.
Đây là một hướng tối ưu hợp lý: nhiều token của agent dài phiên không đến từ “suy nghĩ mới”, mà từ việc gửi lại context, log hoặc observations cũ.
Con số 45–49% nằm trong một hàng rào chất lượng
SoL-Pi không tìm cách giảm token bằng mọi giá. Trang dự án mô tả một capability floor: ứng viên tiết kiệm phải giữ các metric năng lực trong tolerance đã khai báo, đồng thời cải thiện ít nhất một metric efficiency.
Điểm này quan trọng hơn headline. Nếu một harness giảm 50% token bằng cách bỏ test, dừng sớm hoặc xóa evidence mà reviewer cần, đó không phải cùng loại tiết kiệm.
Ngay trong kết quả công bố cũng có trade-off cần đọc đủ. Trên EdgeBench, SoL-Pi giữ khoảng 94% điểm trung bình của Pi. Trên Terminal-Bench 4, nó giải ít task hơn Pi trong bảng kết quả công bố. Vì vậy câu đúng là: nghiên cứu cho thấy có thể tìm được các cơ chế harness tiết kiệm đáng kể dưới capability constraints của họ. Câu “SoL-Pi làm mọi coding agent rẻ hơn một nửa mà không mất gì” không được dữ liệu đó chứng minh.
Nếu muốn áp dụng ý tưởng, hãy đo workload của mình
Bạn không cần bắt đầu bằng việc thay toàn bộ agent stack. Chọn ba task đại diện, chẳng hạn:
- sửa bug có regression test rõ;
- refactor nhỏ có build/test gate;
- đọc log dài rồi sửa một lỗi cấu hình có verifier.
Giữ cùng repo snapshot, cùng model backend, cùng reasoning setting nếu có thể và cùng acceptance test. Chạy harness hiện tại và harness thử nghiệm. Ghi lại:
| Metric | Baseline | Thử nghiệm |
|---|---|---|
| Task đạt verifier | có/không | có/không |
| Tổng token | đo thực tế | đo thực tế |
| Chi phí | đo thực tế | đo thực tế |
| Số lượt model | đo thực tế | đo thực tế |
| Test/build cuối | pass/fail | pass/fail |
| Evidence đủ review | có/không | có/không |
Ví dụ này là khung đánh giá giả lập, không phải kết quả thử SoL-Pi của AI NEWSROOM.
Thứ tự đọc bảng cũng quan trọng: xem verifier và evidence trước, rồi mới nhìn token. Nếu baseline pass còn bản tiết kiệm fail, bạn chưa chứng minh được efficiency gain cho task đó.
Bốn ý tưởng có thể dùng ngay cả khi không cài SoL-Pi
Nghiên cứu còn hữu ích như một checklist để soi harness hiện tại.
Tool calls có bị tách vô ích? Nếu agent luôn sửa file rồi ngay lập tức chạy cùng một test, có thể có chỗ tối ưu orchestration mà không cần thêm model call.
Tool output có bị gửi lại quá nhiều? Log build hàng nghìn dòng không nên tự động quay lại mọi prompt nếu agent chỉ cần vài đoạn.
Context có được compact theo trạng thái công việc? Kết thúc một subtask là tín hiệu tốt hơn một ngưỡng token cứng trong một số workflow.
Tóm tắt có giữ đường về evidence gốc? Compression chỉ hữu ích nếu khi cần, reviewer hoặc agent vẫn truy lại được dòng log/file chính xác.
Các câu hỏi này không chứng minh implementation của bạn sẽ đạt con số SoL-Pi. Chúng giúp tìm nơi token đang bị tiêu vào repetition thay vì tiến triển.
Đừng tối ưu hóa một metric đứng một mình
Với coding agent, token rẻ hơn có thể đổi thành review đắt hơn nếu context bị cắt sai, test bị bỏ hoặc evidence biến mất. Vì vậy metric cuối nên là chi phí cho một task đạt acceptance gate, không phải token trên một phiên chat.
SoL-Pi đưa ra một bằng chứng mạnh rằng harness là một bề mặt tối ưu quan trọng, không chỉ model. Nhưng bài học thực dụng nhất không phải “hãy kỳ vọng giảm 49%”. Đó là: đóng băng capability gate trước, đo efficiency sau, và chỉ giữ cơ chế tiết kiệm khi nó vẫn đưa task qua cùng cánh cửa kiểm chứng.
Nguồn để đối chiếu
- NVlabs — SoL-Pi project page: phương pháp auto-research, bốn cơ chế, capability floor và kết quả EdgeBench/Terminal-Bench công bố.
- arXiv 2609.20519: paper của dự án để kiểm tra chi tiết phương pháp và evaluation.