- A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization) adalah sistem AI self-hosted yang menghadirkan performa pembuatan kode setara model besar hanya dengan satu GPU konsumen
- Berdasarkan LiveCodeBench v5, sistem ini mencatat 74.6% pass@1-v(k=3) dan melampaui Claude 4.5 Sonnet (71.4%), sekaligus mencapai peningkatan performa hampir dua kali lipat dibanding versi sebelumnya
- Dengan model 14B parameter (Qwen3-14B-Q4_K_M) yang dibekukan, performa tinggi dicapai lewat constraint-based generation, loop verifikasi dan perbaikan mandiri, serta seleksi kandidat Geometric Lens
- Sistem ini berjalan sepenuhnya secara otonom di lingkungan lokal tanpa cloud atau panggilan API, dengan biaya hanya listrik, sehingga sangat efisien secara biaya dibanding model berbasis API
- Di lingkungan RTX 5060 Ti 16GB GPU, sistem memproses 599 tugas dalam sekitar 2 jam, menunjukkan bahwa kemampuan generasi kode model besar bisa direplikasi di hardware pribadi
Hasil benchmark
- LiveCodeBench v5: 74.6% pass@1-v(k=3), 599 tugas
- Pipeline V3: PlanSearch + self-verified PR-CoT repair
- GPQA Diamond: 47.0%, 198 tugas
- SciCode: 14.7%, 341 tugas
- pass@k-v(k=3) bukan hasil dari satu percobaan tunggal, melainkan metode yang mencakup pembuatan 3 kandidat, seleksi dengan Lens, lalu perbaikan berulang jika gagal
-
Kontribusi tiap tahap V3 (Ablation Study)
- A: bentuk dasar (tanpa 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)
- Pada Phase 3, model menjalankan verifikasi internal menggunakan test case yang dibuat sendiri, tanpa memakai jawaban benar yang sebenarnya
- PR-CoT memulihkan 36 dari 42 masalah (85.7%) pada Phase 3
Perbandingan biaya dan performa
| Sistem |
LCB pass@1 |
Biaya per tugas |
Catatan |
| DeepSeek V3.2 Reasoning |
86.2% |
~$0.002 |
API, satu percobaan |
| GPT-5 (high) |
84.6% |
~$0.043 |
API, satu percobaan |
| ATLAS V3 |
74.6% |
~$0.004 |
Hanya memakai listrik lokal, best-of-3 + repair |
| Claude 4.5 Sonnet |
71.4% |
~$0.066 |
API, satu percobaan |
| Claude 4 Sonnet |
65.5% |
~$0.066 |
API, satu percobaan |
- ATLAS hanya menimbulkan biaya listrik, tanpa biaya API
- Dengan GPU 165W, penyelesaian 599 tugas memakan sekitar 1 jam 55 menit
- Latency lebih panjang, tetapi efisiensi biaya sangat tinggi
Cara kerja
-
Pipeline keseluruhan
- Phase 1: Generate
- PlanSearch: ekstraksi constraint dan pembuatan berbagai rencana
- Budget Forcing: mengendalikan penggunaan token
- Tahap Verify
- Geometric Lens (C(x)): energy scoring berbasis embedding internal 5120 dimensi
- Sandbox: eksekusi dan verifikasi kode
- Phase 3: Repair
- Self-Test Generation: model membuat sendiri pasangan input-output
- PR-CoT Repair: perbaikan kode berbasis chain-of-thought multi-perspektif
- Satu instance llama-server berjalan di atas K3s sambil melakukan speculative decoding dan pembuatan embedding internal secara bersamaan
- Geometric Lens memilih kode terbaik di antara kandidat (akurasi 87.8% pada tugas hasil campuran)
- Tugas yang gagal dipindahkan ke Phase 3 untuk pembuatan self-test dan perbaikan berulang
Instalasi dan eksekusi
- Clone repositori GitHub, lalu salin file konfigurasi dan jalankan skrip instalasi
- Jalankan benchmark V3 dengan
benchmark/v3_runner.py
- Prosedur instalasi rinci tersedia di docs/SETUP.md
Hardware dan reproduksi
| Sumber daya |
Minimum |
Lingkungan pengujian |
| GPU VRAM |
16 GB |
RTX 5060 Ti 16 GB |
| RAM sistem |
14 GB |
16 GB |
| Python |
3.10+ |
3.11 |
| OS |
RHEL 9 / Ubuntu 24 |
RHEL 9 (Proxmox VM) |
- Direproduksi di lingkungan Proxmox VM + VFIO GPU passthrough
- Bisa dijalankan di GPU NVIDIA lain dengan VRAM 16GB atau lebih, tetapi perlu penyesuaian driver dan pengaturan VRAM
- Variabel penyesuaian utama:
- jumlah slot
--parallel (default 2, turunkan ke 1 jika VRAM kurang)
- kuantisasi KV cache (Q4_0)
- panjang konteks per slot (default 20480 token)
- pengujian selesai pada CUDA 12.8
- V3.1 direncanakan untuk meningkatkan portabilitas
Roadmap
-
V3.0 (selesai, 2026-03-05)
- Berbasis Qwen3-14B-Q4_K_M, performa 74.6% LCB
- Pipeline PlanSearch + BudgetForcing + Geometric Lens + PR-CoT selesai dibangun
-
Keterbatasan yang diketahui
- Optimasi khusus LCB: optimasi untuk benchmark lain seperti GPQA dan SciCode masih kurang
- Phase 2 (Lens routing): dampaknya minim karena kekurangan dataset (+0.0pp)
- G(x) metric tensor dinonaktifkan: C(x) belum terlatih sehingga belum ada struktur geometris yang bermakna
- Pemrosesan single-thread: belum mendukung paralelisasi tugas
- Bug stdio SandboxAdapter: fitur pemisahan input dinonaktifkan (akan diperbaiki di V3.1)
-
V3.1 (sedang berjalan)
- Pergantian model: Qwen3-14B → Qwen3.5-9B (DeltaNet linear attention, peningkatan kecepatan 3~4x)
- Pelatihan ulang Lens: rekalibrasi C(x) berbasis feedback real-time
- Desain ulang Phase 2: implementasi ulang atau penghapusan G(x), perbaikan bug SandboxAdapter
- Penerapan pemrosesan paralel: meningkatkan kecepatan lewat eksekusi tugas paralel
- Benchmark suite yang diperluas: mencakup evaluasi penalaran dan pengetahuan di luar coding
-
Benchmark V3.1 yang direncanakan
- Coding: LiveCodeBench v5, SciCode, dan dataset tambahan yang tahan kontaminasi
- Penalaran/pengetahuan: GPQA Diamond, AA-LCR, AA-Omniscience, Humanity’s Last Exam, CritPt, dll.
- Confidence Router memilih jalur berdasarkan tingkat kesulitan tugas:
- kueri sederhana → penalaran cepat berbasis RAG (~30 detik)
- masalah coding kompleks → pipeline penuh (~20 menit)
- Target: 80~90% LCB pass@1-v(k=3) dan kecepatan pemrosesan yang lebih tinggi
Lisensi
- Menggunakan A.T.L.A.S Source Available License v1.0
1 komentar
Komentar Hacker News
Saya tidak mengharapkan agen untuk menghasilkan blok kode besar
Sebaliknya, agen jauh lebih berguna untuk menelusuri log atau menganalisis banyak berkas sumber lalu menjelaskan penyebab kegagalan pengujian
Menurut saya kita butuh benchmark debugging untuk menilai kemampuan seperti ini. Akan bagus jika ada pengujian yang mengukur kemahiran dalam build system atau CLI
Misalnya saya pernah merefaktor seluruh aplikasi dari hard delete ke soft delete, jadi logika penghapusan dan query semuanya harus diubah
Kalau dikerjakan manual itu membosankan dan rawan kesalahan, jadi saya sangat berterima kasih karena agen bisa menanganinya dengan cepat
SWE Bench Pro masih cukup bisa dipercaya karena belum terlalu dioptimalkan berlebihan
Sebaliknya, SWE biasa atau LCB sudah kurang berguna karena terjebak dalam perlombaan menggelembungkan angka
Sebagai catatan, saya adalah pendiri Quesma
Sekarang saya hampir tidak pernah menulis kode sendiri lagi, baik untuk perusahaan maupun proyek sampingan
Saya terutama membuat developer tools dengan Rust dan TypeScript
Saya melakukan deployment dengan kubectl / helm, dan saat ada masalah agen langsung melakukan debugging
Pekerjaan yang dulu memakan waktu berjam-jam sekarang selesai dalam sekejap, sampai terasa mengejutkan
Saya ingin mendorong para developer untuk benar-benar mencoba model seperti MiniMax dan Kimi dalam pekerjaan nyata
Namun kekurangannya juga cepat terlihat — penggunaan token penalaran yang meningkat, output lambat, penurunan kualitas, dan sebagainya
Meski begitu, biaya bisa banyak dihemat jika routing model dan reasoning budget dikelola dengan baik
Mengoptimalkan aplikasi dan prompt untuk mengurangi token output juga penting
Tetapi untuk tugas yang sulit, efisiensi lebih penting daripada sekadar harga token
Pendekatan pada tautan itu juga efektif untuk Sonnet dan Opus
Hanya saja MiniMax atau Qwen belum sampai di level itu
Pada akhirnya kuncinya adalah desain harness yang bisa membedakan model mana yang paling efisien untuk tugas tertentu
Saya sempat mencoba Opus 4.6 medium lalu langsung menyesal. Perbedaan kualitasnya terlalu besar
hasil perbandingan aibenchy
Saya tidak peduli dengan penggunaan token, di paket 10 euro per bulan saya bisa melakukan 1500 request setiap 5 jam
Dalam praktiknya, model ini tidak lebih lambat daripada Opus atau Sonnet
Di benchmark model Anthropic memang terlihat lebih baik, tetapi dalam pekerjaan nyata perbedaannya hampir tidak ada
Kalau MiniMax mentok, saya pindah ke Opus, lalu kembali lagi ke MiniMax
Opus cepat menghabiskan anggaran, tetapi MiniMax pada dasarnya nyaris tak terbatas
Ia menemukan masalah lebih cepat daripada Claude atau GPT
Namun masalah konsistensi konteks sangat serius — saat menulis ulang kode, sedikit deviasi bisa merusak semuanya
Sekarang ini kita sedang berada dalam perlombaan harga tanpa akhir
DeepSeek mengalahkan semua model dalam sekali jalan, dan biayanya juga sekitar setengah dari listrik lokal
Caranya adalah menghasilkan beberapa jawaban, memilih kandidat yang menjanjikan dengan model kecil, lalu mengulang pengujian dan umpan balik
Ini perlahan konvergen seperti semacam algoritma genetika
Model kecil terlalu di-fine-tune berlebihan untuk lulus pengujian, sehingga performanya buruk sekali di lingkungan nyata
Saya selalu skeptis
Benchmark bisa lolos, tetapi dalam praktiknya sering kali generalisasinya buruk
Meski begitu, upaya untuk merampingkan model itu sendiri tetap menarik
Dalam pemrograman sistem (C++, Rust), jaraknya masih sangat jauh dari level Sonnet 4.5
Model terbuka menghabiskan terlalu banyak waktu untuk memperbaiki kesalahan sintaks, dan sering kehilangan konsistensi logis
Saya punya cukup banyak GPU lokal, tetapi saya juga khawatir soal masalah lisensi model cloud
Ia menghasilkan beberapa solusi, lalu menghitung embedding fingerprint dari tiap kode untuk memprediksi akurasinya
Jaringan saraf kecil bernama Cost Field memberi skor pada hasil itu lalu memilih kode yang paling mungkin benar
Berkat itu, waktu pengujian berkurang sambil tetap memilih jawaban yang benar dengan akurasi 88%
Justru model besar bisa jadi lebih sederhana secara struktural
Saat saya sedang membaca, harga GPU sudah menjadi $1000
Proyek yang ditulis AI ini menjalankan benchmark sendiri dengan cara yang sama sekali berbeda dari LiveCodeBench
README menyatakan bahwa skor ATLAS adalah hasil dari pipeline V3 (best-of-3 + Lens + iterative repair) berdasarkan 599 tugas LCB
Sementara itu, skor model pesaing didasarkan pada eksekusi tunggal (pass@1), jadi perbandingannya tidak adil
Sonnet atau GPT5.4 juga bisa mencetak skor lebih tinggi jika diuji dengan cara yang sama
README juga memiliki banyak struktur yang sebenarnya tidak digunakan, yang memperlihatkan kerapuhan kode hasil generasi otomatis AI
Saya penasaran apakah benchmark seperti ini hanya efektif untuk optimisasi khusus masalah
Pada akhirnya, kita akan belajar tentang batas bahwa generalitas tidak bisa dikompresi
Ungkapan “Geometric Lens routing” terdengar sangat aneh
Rasanya seperti sekadar istilah yang dibuat GPT
Meski skeptis, eksperimen model terbuka seperti ini benar-benar disambut baik
Jika model bisa dijalankan secara lokal bahkan di PC kelas menengah ke atas, itu kemajuan besar