- A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization) là một hệ thống AI tự lưu trữ đạt hiệu năng sinh mã ở mức mô hình lớn chỉ với một GPU tiêu dùng
- Theo LiveCodeBench v5, hệ thống đạt 74.6% pass@1-v(k=3), vượt Claude 4.5 Sonnet (71.4%), đồng thời cải thiện hiệu năng gần gấp đôi so với phiên bản trước
- Giữ cố định mô hình 14B tham số (Qwen3-14B-Q4_K_M), hệ thống đạt hiệu năng cao nhờ sinh mã dựa trên ràng buộc, vòng lặp tự kiểm chứng và sửa lỗi, cùng chọn ứng viên bằng Geometric Lens
- Chạy hoàn toàn tự chủ trên môi trường cục bộ mà không cần cloud hay gọi API, chỉ phát sinh chi phí điện năng, nên có hiệu quả chi phí rất cao so với các mô hình dựa trên API
- Trên GPU RTX 5060 Ti 16GB, hệ thống xử lý 599 bài toán trong khoảng 2 giờ, cho thấy khả năng tái hiện năng lực sinh mã của mô hình lớn trên phần cứng cá nhân
Kết quả benchmark
- LiveCodeBench v5: 74.6% pass@1-v(k=3), thực hiện 599 bài toán
- Pipeline V3: PlanSearch + self-verified PR-CoT repair
- GPQA Diamond: 47.0%, 198 bài toán
- SciCode: 14.7%, 341 bài toán
- pass@k-v(k=3) không phải kết quả của một lần thử đơn lẻ, mà là cách làm tạo 3 ứng viên, chọn bằng Lens và lặp lại sửa lỗi khi thất bại
-
Mức đóng góp theo từng giai đoạn của V3 (Ablation Study)
- A: Bản cơ sở (không áp dụng V3) → 54.9%
- B: Phase 1 (PlanSearch + BudgetForcing + DivSampling) → 67.3% (+12.4pp)
- C: Phase 1+2 (Lens routing) → 67.3% (+0.0pp)
- D: Phase 1+3 (self-verified refinement) → 74.6% (+7.3pp)
- Ở Phase 3, hệ thống thực hiện kiểm chứng nội bộ bằng test case do chính mô hình tạo ra, không dùng đáp án thật
- PR-CoT khôi phục được 36 trong 42 bài toán (85.7%) ở Phase 3
So sánh chi phí và hiệu năng
| Hệ thống |
LCB pass@1 |
Chi phí mỗi bài toán |
Ghi chú |
| DeepSeek V3.2 Reasoning |
86.2% |
~$0.002 |
API, thử một lần |
| GPT-5 (high) |
84.6% |
~$0.043 |
API, thử một lần |
| ATLAS V3 |
74.6% |
~$0.004 |
Chỉ dùng điện cục bộ, best-of-3 + repair |
| Claude 4.5 Sonnet |
71.4% |
~$0.066 |
API, thử một lần |
| Claude 4 Sonnet |
65.5% |
~$0.066 |
API, thử một lần |
- ATLAS chỉ phát sinh chi phí điện năng, không có phí API
- Với GPU 165W, việc chạy 599 bài toán mất khoảng 1 giờ 55 phút
- Độ trễ (latency) dài hơn nhưng hiệu quả chi phí rất cao
Nguyên lý hoạt động
-
Toàn bộ pipeline
- Phase 1: Generate
- PlanSearch: trích xuất ràng buộc và tạo nhiều kế hoạch khác nhau
- Budget Forcing: kiểm soát lượng token sử dụng
- Giai đoạn Verify
- Geometric Lens (C(x)): chấm điểm năng lượng dựa trên embedding nội bộ 5120 chiều
- Sandbox: chạy và kiểm chứng mã
- Phase 3: Repair
- Self-Test Generation: mô hình tự tạo các cặp đầu vào/đầu ra
- PR-CoT Repair: sửa mã dựa trên chain-of-thought đa góc nhìn
- Một instance llama-server duy nhất chạy trên K3s, đồng thời thực hiện speculative decoding và tự tạo embedding
- Geometric Lens chọn đoạn mã tối ưu trong số các ứng viên (độ chính xác 87.8% trên các bài toán có kết quả pha trộn)
- Các bài toán thất bại được chuyển sang Phase 3 để tự tạo test và lặp lại sửa lỗi
Cài đặt và chạy
- Clone kho lưu trữ GitHub, sau đó sao chép tệp cấu hình và chạy script cài đặt
- Chạy benchmark V3 bằng
benchmark/v3_runner.py
- Xem quy trình cài đặt chi tiết tại docs/SETUP.md
Phần cứng và tái lập
| Tài nguyên |
Tối thiểu |
Môi trường thử nghiệm |
| GPU VRAM |
16 GB |
RTX 5060 Ti 16 GB |
| RAM hệ thống |
14 GB |
16 GB |
| Python |
3.10+ |
3.11 |
| OS |
RHEL 9 / Ubuntu 24 |
RHEL 9 (Proxmox VM) |
- Đã được tái lập trong môi trường Proxmox VM + VFIO GPU passthrough
- Có thể chạy trên các GPU NVIDIA khác với VRAM từ 16GB trở lên, nhưng cần điều chỉnh driver và cấu hình VRAM
- Các biến điều chỉnh chính:
- Số slot
--parallel (mặc định 2, giảm xuống 1 khi thiếu VRAM)
- Lượng tử hóa KV cache (Q4_0)
- Độ dài ngữ cảnh mỗi slot (mặc định 20480 token)
- Đã kiểm thử với CUDA 12.8
- V3.1 dự kiến sẽ cải thiện tính di động
Lộ trình
-
V3.0 (hoàn thành, 2026-03-05)
- Dựa trên Qwen3-14B-Q4_K_M, đạt 74.6% LCB
- Hoàn thiện pipeline PlanSearch + BudgetForcing + Geometric Lens + PR-CoT
-
Hạn chế đã biết
- Tối ưu riêng cho LCB: chưa tối ưu tốt cho các benchmark khác như GPQA, SciCode
- Phase 2 (Lens routing): hiệu quả không đáng kể do thiếu dữ liệu (+0.0pp)
- G(x) metric tensor bị vô hiệu hóa: C(x) chưa được huấn luyện nên thiếu cấu trúc hình học có ý nghĩa
- Xử lý đơn luồng: chưa hỗ trợ song song hóa bài toán
- Lỗi stdio của SandboxAdapter: tính năng phân tách đầu vào bị vô hiệu hóa (dự kiến sửa ở V3.1)
-
V3.1 (đang thực hiện)
- Thay mô hình: Qwen3-14B → Qwen3.5-9B (DeltaNet linear attention, nhanh hơn 3~4 lần)
- Huấn luyện lại Lens: hiệu chỉnh lại C(x) dựa trên phản hồi thời gian thực
- Thiết kế lại Phase 2: triển khai lại hoặc loại bỏ G(x), sửa lỗi SandboxAdapter
- Bổ sung xử lý song song: tăng tốc độ xử lý bằng chạy song song bài toán
- Mở rộng bộ benchmark: bổ sung đánh giá suy luận và tri thức ngoài lập trình
-
Benchmark dự kiến cho V3.1
- Lập trình: LiveCodeBench v5, SciCode, thêm các bộ dữ liệu chống ô nhiễm khác
- Suy luận/tri thức: GPQA Diamond, AA-LCR, AA-Omniscience, Humanity’s Last Exam, CritPt, v.v.
- Confidence Router chọn lộ trình theo độ khó của bài toán:
- Truy vấn đơn giản → suy luận nhanh dựa trên RAG (~30 giây)
- Bài toán lập trình phức tạp → toàn bộ pipeline (~20 phút)
- Mục tiêu: 80~90% LCB pass@1-v(k=3) và tốc độ xử lý nhanh hơn
Giấy phép
- Áp dụng A.T.L.A.S Source Available License v1.0
1 bình luận
Ý kiến trên Hacker News
Tôi không kỳ vọng agent sẽ tạo ra các khối mã lớn
Thay vào đó, nó hữu ích hơn nhiều trong việc rà log hoặc phân tích nhiều file nguồn để giải thích nguyên nhân test bị fail
Tôi nghĩ cần có các benchmark gỡ lỗi để đánh giá năng lực này. Sẽ tốt hơn nếu có các bài test đo cả độ thành thạo với build system hoặc CLI
Ví dụ, tôi đã refactor toàn bộ ứng dụng từ hard delete sang soft delete, nên phải sửa cả logic xóa lẫn truy vấn
Nếu làm thủ công thì vừa tẻ nhạt vừa dễ sai, còn agent xử lý rất nhanh nên tôi thực sự biết ơn
SWE Bench Pro vẫn đáng tin vì chưa bị tối ưu hóa quá mức
Trong khi đó, SWE thường hay LCB thì đã rơi vào cuộc đua thổi phồng chỉ số nên kém hiệu quả
Tiện nói luôn, tôi là nhà sáng lập Quesma
Giờ thì dù ở công ty hay dự án phụ, tôi hầu như không tự viết code nữa
Chủ yếu tôi làm công cụ cho lập trình viên bằng Rust và TypeScript
Nó triển khai bằng kubectl / helm và khi có sự cố thì tự gỡ lỗi luôn
Những việc vốn mất vài giờ giờ xong trong chớp mắt, thật sự rất ấn tượng
Tôi muốn khuyên các lập trình viên hãy thử dùng những model như MiniMax, Kimi trong công việc thực tế
Nhưng nhược điểm cũng lộ ra rất nhanh — mức dùng token suy luận tăng, đầu ra chậm, chất lượng giảm, v.v.
Dù vậy, nếu quản lý tốt việc định tuyến model và reasoning budget thì có thể tiết kiệm chi phí đáng kể
Tối ưu ứng dụng và prompt để giảm output token cũng rất quan trọng
Nhưng với các tác vụ khó, hiệu quả quan trọng hơn đơn giá token đơn thuần
Cách tiếp cận trong link cũng hiệu quả với Sonnet và Opus
Chỉ là MiniMax hay Qwen vẫn chưa đạt tới mức đó
Cuối cùng, mấu chốt là thiết kế harness để phân biệt model nào hiệu quả chi phí cho từng loại việc
Tôi thử Opus 4.6 medium rồi hối hận ngay. Chênh lệch chất lượng quá lớn
kết quả so sánh trên aibenchy
Tôi không quan tâm đến lượng token, gói 10 euro/tháng cho phép 1500 request mỗi 5 giờ
Trên thực tế nó không hề chậm hơn Opus hay Sonnet
Trên benchmark thì model của Anthropic có vẻ tốt hơn, nhưng trong công việc thực tế thì gần như không có khác biệt
Khi MiniMax bí thì tôi chuyển sang Opus, rồi quay lại MiniMax là được
Opus đốt ngân sách rất nhanh còn MiniMax thì gần như vô hạn
Nó tìm ra vấn đề nhanh hơn Claude hay GPT
Nhưng vấn đề nhất quán ngữ cảnh của nó rất nghiêm trọng — khi viết lại code, chỉ một sai lệch nhỏ cũng có thể làm hỏng toàn bộ
Hiện tại là một cuộc đua giảm giá bất tận
DeepSeek đang thắng mọi model xét theo một lần chạy duy nhất, và chi phí còn chỉ bằng khoảng một nửa tiền điện chạy local
Nó tạo ra nhiều lời giải, dùng model nhỏ để chọn ứng viên triển vọng, rồi test và lặp phản hồi
Nó dần hội tụ theo kiểu thuật toán di truyền
Các model nhỏ bị fine-tune quá mức cho bài test nên trong môi trường thực tế cho hiệu năng rất tệ
Tôi luôn hoài nghi
Benchmark thì vượt qua được nhưng thực tế lại thường thiếu tính đa dụng
Dù vậy, bản thân nỗ lực làm gọn model vẫn rất thú vị
Trong lập trình hệ thống (C++, Rust), vẫn còn khoảng cách lớn so với Sonnet 4.5
Các open model tốn quá nhiều thời gian để sửa lỗi cú pháp và thường mất tính nhất quán logic
Tôi có đủ GPU local, nhưng cũng lo về vấn đề giấy phép của model đám mây
Nó tạo nhiều lời giải, rồi tính dấu vân tay embedding (fingerprint) của từng đoạn code để dự đoán độ chính xác
Một mạng nơ-ron nhỏ tên là Cost Field sẽ chấm điểm chúng và chọn ra đoạn code có khả năng đúng cao nhất
Nhờ vậy nó giảm thời gian test mà vẫn chọn được đáp án đúng với độ chính xác 88%
Ngược lại, model lớn đôi khi lại đơn giản hơn về mặt cấu trúc
Trong lúc tôi đang đọc thì giá GPU đã thành 1.000 USD rồi
Dự án do AI viết này chạy benchmark riêng theo cách hoàn toàn khác với LiveCodeBench
README nói rõ điểm ATLAS là kết quả của pipeline V3 (best-of-3 + Lens + iterative repair) dựa trên 599 bài LCB
Trong khi đó, điểm của các model cạnh tranh lại tính theo một lần chạy duy nhất (pass@1), nên so sánh là không công bằng
Nếu test Sonnet hay GPT5.4 theo cùng cách thì điểm còn có thể cao hơn
README có nhiều cấu trúc thực tế không được dùng tới, cho thấy sự cẩu thả của code do AI tự sinh
Tôi tò mò liệu các benchmark kiểu này chỉ hiệu quả cho tối ưu hóa riêng theo bài toán hay không
Cuối cùng có lẽ chúng ta sẽ học được giới hạn rằng không thể nén tính tổng quát
Cụm từ “Geometric Lens routing” nghe quá kỳ lạ
Nó giống như một thuật ngữ do GPT bịa ra vậy
Tôi vẫn hoài nghi, nhưng những thử nghiệm open model như thế này thực sự rất đáng mừng
Nếu có thể chạy model local ngay trên một PC tầm trung đến khá thì đó là một bước tiến lớn