A.T.L.A.S - 500 dolarlık GPU, kodlama benchmark'ında Claude Sonnet'i geride bıraktı

• A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization), tek bir tüketici GPU'su ile büyük model düzeyinde kod üretim performansı sunan self-hosted bir yapay zeka sistemi
• LiveCodeBench v5'te %74,6 pass@1-v(k=3) elde ederek Claude 4.5 Sonnet'i (%71,4) geride bıraktı; önceki sürüme kıyasla performansını neredeyse ikiye katladı
• 14B parametreli modeli (Qwen3-14B-Q4_K_M) dondurulmuş halde tutup kısıt tabanlı üretim, öz doğrulama ve düzeltme döngüsü, Geometric Lens aday seçimi ile yüksek performans sağlıyor
• Bulut veya API çağrısı olmadan yerel ortamda tamamen otonom çalışıyor ve yalnızca elektrik maliyeti oluşturduğu için API tabanlı modellere göre maliyet verimliliği çok yüksek
• RTX 5060 Ti 16GB GPU üzerinde yaklaşık 2 saat içinde 599 görevi işliyor; büyük modellerin kod üretme yeteneğinin kişisel donanımda yeniden üretilebildiğini gösteriyor

Benchmark sonuçları

• LiveCodeBench v5: %74,6 pass@1-v(k=3), 599 görev
  • V3 pipeline: PlanSearch + self-verified PR-CoT repair
• GPQA Diamond: %47,0, 198 görev
• SciCode: %14,7, 341 görev
• pass@k-v(k=3), tek deneme sonucu değil; 3 aday üretip Lens ile seçim yapma ve başarısız olursa tekrar tekrar düzeltme içeren bir yöntem

• V3 aşama bazlı katkı (Ablation Study)

  • A: Temel sürüm (V3 uygulanmadan) → %54,9
  • B: Phase 1 (PlanSearch + BudgetForcing + DivSampling) → %67,3 (+12,4 puan)
  • C: Phase 1+2 (Lens routing) → %67,3 (+0,0 puan)
  • D: Phase 1+3 (self-verified refinement) → %74,6 (+7,3 puan)
  • Phase 3, modelin kendi ürettiği test case'lerle iç doğrulama yapıyor; gerçek cevaplar kullanılmıyor
  • PR-CoT, Phase 3'te 42 problemin 36'sını (%85,7) kurtardı

Maliyet ve performans karşılaştırması

Sistem	LCB pass@1	Görev başına maliyet	Not
DeepSeek V3.2 Reasoning	%86,2	~$0.002	API, tek deneme
GPT-5 (high)	%84,6	~$0.043	API, tek deneme
ATLAS V3	%74,6	~$0.004	Yalnızca yerel elektrik kullanımı, best-of-3 + repair
Claude 4.5 Sonnet	%71,4	~$0.066	API, tek deneme
Claude 4 Sonnet	%65,5	~$0.066	API, tek deneme

• ATLAS'ta yalnızca elektrik maliyeti var, API maliyeti yok
• 165W GPU ile 599 görevin tamamlanması yaklaşık 1 saat 55 dakika sürüyor
• Gecikme (latency) yüksek, ancak maliyet verimliliği son derece güçlü

Nasıl çalışıyor

• Genel pipeline

  • Phase 1: Generate
    • PlanSearch: Kısıt çıkarımı ve çeşitli planlar üretme
    • Budget Forcing: Token kullanımını kontrol etme
  • Verify aşaması
    • Geometric Lens (C(x)): 5120 boyutlu self-embedding tabanlı enerji skorlama
    • Sandbox: Kodu çalıştırma ve doğrulama
  • Phase 3: Repair
    • Self-Test Generation: Modelin kendi giriş/çıkış çiftlerini üretmesi
    • PR-CoT Repair: Çoklu bakış açılı chain-of-thought tabanlı kod düzeltme
  • Tek bir llama-server instance'ı, K3s üzerinde çalışıyor ve aynı anda speculative decoding ile self-embedding üretimi yapıyor
  • Geometric Lens, adaylar arasından en iyi kodu seçiyor (karışık sonuçlu görevlerde %87,8 doğruluk)
  • Başarısız görevler, kendi testlerini üretip tekrar tekrar düzeltme için Phase 3'e aktarılıyor

Kurulum ve çalıştırma

• GitHub deposunu klonladıktan sonra yapılandırma dosyasını kopyalayın ve kurulum script'ini çalıştırın
• V3 benchmark'ını benchmark/v3_runner.py ile çalıştırın
• Ayrıntılı kurulum adımları için docs/SETUP.md dosyasına bakın

Donanım ve yeniden üretim

Kaynak	Minimum	Test ortamı
GPU VRAM	16 GB	RTX 5060 Ti 16 GB
Sistem RAM	14 GB	16 GB
Python	3.10+	3.11
OS	RHEL 9 / Ubuntu 24	RHEL 9 (Proxmox VM)

• Proxmox VM + VFIO GPU passthrough ortamında yeniden üretildi
• 16GB ve üzeri VRAM'e sahip diğer NVIDIA GPU'larda da çalışabilir; ancak sürücü ve VRAM ayarlarının uyarlanması gerekiyor
• Başlıca ayar değişkenleri:
  • --parallel slot sayısı (varsayılan 2, VRAM yetersizse 1'e düşürülüyor)
  • KV cache quantization (Q4_0)
  • Slot başına context length (varsayılan 20480 token)
  • CUDA 12.8 sürümüyle test edildi
• V3.1 ile taşınabilirliğin iyileştirilmesi planlanıyor

Yol haritası

• V3.0 (tamamlandı, 2026-03-05)

  • Qwen3-14B-Q4_K_M tabanlı, %74,6 LCB performansı
  • PlanSearch + BudgetForcing + Geometric Lens + PR-CoT pipeline'ı tamamlandı

• Bilinen sınırlamalar

  1. LCB odaklı optimizasyon: GPQA, SciCode gibi diğer benchmark'lar için optimizasyon yetersiz
  2. Phase 2 (Lens routing): Veri seti yetersizliği nedeniyle etkisi sınırlı (+0,0 puan)
  3. G(x) metric tensor devre dışı: C(x) eğitilmediği için anlamlı geometrik yapı yok
  4. Tek iş parçacıklı işleme: Görev paralelleştirmesi desteklenmiyor
  5. SandboxAdapter stdio hatası: Girdi ayırma özelliği devre dışı (V3.1'de düzeltilecek)

• V3.1 (devam ediyor)

  • Model değişimi: Qwen3-14B → Qwen3.5-9B (DeltaNet linear attention, 3-4 kat hız artışı)
  • Lens'i yeniden eğitme: Gerçek zamanlı geri bildirimle C(x)'in yeniden kalibre edilmesi
  • Phase 2 yeniden tasarımı: G(x)'in yeniden uygulanması veya kaldırılması, SandboxAdapter hatasının düzeltilmesi
  • Paralel işleme eklenmesi: Görevleri paralel çalıştırarak işlem hızını artırma
  • Genişletilmiş benchmark paketi: Kodlama dışı akıl yürütme ve bilgi değerlendirmelerini de kapsama

• Planlanan V3.1 benchmark'ları

  • Kodlama: LiveCodeBench v5, SciCode, ek kontaminasyon dirençli veri setleri
  • Akıl yürütme/bilgi: GPQA Diamond, AA-LCR, AA-Omniscience, Humanity’s Last Exam, CritPt vb.
  • Confidence Router, görev zorluğuna göre yol seçiyor:
    • Basit sorgu → RAG tabanlı hızlı akıl yürütme (~30 saniye)
    • Karmaşık kodlama problemi → tam pipeline (~20 dakika)
  • Hedef: %80-90 LCB pass@1-v(k=3) ve daha hızlı işlem süresi

Lisans

• A.T.L.A.S Source Available License v1.0 uygulanıyor

[GN⁺]

Hacker News yorumları

• Ajanlardan büyük kod blokları üretmesini beklemiyorum.
  Bunun yerine logları tarayıp birden fazla kaynak dosyayı analiz ederek testlerin neden başarısız olduğunu açıklamada çok daha faydalılar.
  Bence bu tür yetenekleri değerlendiren debugging benchmark’larına ihtiyaç var. Derleme sistemleri ya da CLI becerisini ölçen testler de güzel olurdu.

  • Ben de katılıyorum. Özellikle tüm kod tabanında tutarlı küçük değişiklikler uygularken çok yararlı oluyor.
    Örneğin uygulamanın tamamını hard delete’den soft delete’e refactor etmiştim; hem silme mantığını hem de sorguları değiştirmek gerekti.
    Elle yapmak sıkıcı ve hataya açık olurdu, ajan bunu hızla hallettiği için gerçekten minnettardım.
  • Bu tür uzun soluklu işler için SWE Bench Pro ya da Terminal Bench 2 uygun.
    SWE Bench Pro henüz aşırı optimize edilmediği için güvenilir görünüyor.
    Buna karşılık normal SWE ya da LCB, metrik şişirme yarışı yüzünden artık pek anlam ifade etmiyor.
  • Derleme sistemiyle ilgili testler CompileBench’te (Quesma’nın benchmark’ı) ele alınıyor.
    Bu arada ben Quesma’nın kurucusuyum.
  • Ben bütün gün büyük ölçekli kod üretimi yapıyorum.
    Artık ister şirkette ister yan projelerde olsun, kodu neredeyse hiç kendim yazmıyorum.
    Daha çok Rust ve TypeScript ile geliştirici araçları yapıyorum.
  • Ben de ortam kurulumunu ajana bırakıyorum.
    kubectl / helm ile deploy ediyor, sorun çıkarsa ajan doğrudan debug ediyor.
    Eskiden saatler süren işler bir anda bitiyor; şaşırtıcı derecede iyi.

• Geliştiricilere MiniMax, Kimi gibi modelleri gerçek işlerinde denemelerini tavsiye ederim.
  Ama dezavantajları da hızlıca ortaya çıkıyor — reasoning token kullanımının artması, yavaş çıktı, kalite düşüşü gibi.
  Yine de model yönlendirmesini ve reasoning budget’ını iyi yönetirseniz maliyeti ciddi biçimde düşürebilirsiniz.
  Uygulamayı ve prompt’ları optimize ederek çıktı token’larını azaltmak da önemli.

  • Ben de Kimi ile iyi sonuçlar alıyorum.
    Ama zor işlerde basit token birim fiyatından çok verimlilik önemli.
    Linkteki yaklaşım Sonnet ve Opus’ta da işe yarıyor.
    Ama MiniMax ya da Qwen henüz o seviyede değil.
    Sonuçta hangi işte hangi modelin maliyet açısından verimli olduğunu ayıran şey harness tasarımı.
  • Ben SOTA altı modeller kullanmıyorum.
    Opus 4.6 medium’u denedim ve hemen pişman oldum. Kalite farkı çok büyük.
  • Bu linkte de görüldüğü gibi, MiniMax kod dışı görevlerde düşük performans gösteriyor.
    aibenchy karşılaştırma sonuçları
  • Ben MiniMax’i her gün kod yazmak için kullanıyorum.
    Token kullanımını umursamıyorum; aylık 10 euro’luk planda her 5 saatte 1500 istek hakkı var.
    Pratikte Opus ya da Sonnet’ten daha yavaş değil.
    Benchmark’larda Anthropic modelleri daha iyi görünebilir ama gerçek işlerde fark neredeyse yok.
    MiniMax tıkanırsa Opus’a geçip sonra tekrar MiniMax’e dönebilirsiniz.
    Opus bütçeyi hızlı tüketiyor ama MiniMax fiilen sınırsız.
  • Kimi son zamanlarda debugging için ana modelim oldu.
    Sorunları Claude ya da GPT’den daha hızlı buluyor.
    Ama bağlam tutarlılığı problemi ciddi — kodu yeniden yazarken küçük sapmalar oluşup her şeyi bozabiliyor.

• Şu an durum fiyat rekabetinde bitmeyen bir yarış gibi.
  DeepSeek tek çalıştırmada tüm modelleri geçiyor ve maliyeti de yerel elektrik masrafının yarısı kadar.

  DeepSeek V3.2 Reasoning 86.2% ~$0.002 API, single-shot
  ATLAS V3 (pass@1-v(k=3)) 74.6% ~$0.004 Local electricity only, best-of-3 + repair pipeline

  • Yerelde çalıştırabiliyorsam 0.004 dolarlık elektrik masrafını seve seve kabul ederim.
  • Ama hâlâ 1989 Tiananmen Olayları gibi sorulara cevap vermiyor…
  • Birçok açık modeli test ettim ama gerçek anlamda SOTA seviyesinde olan tek model DeepSeek 3.2.
  • Bu yaklaşımı DeepSeek’e de uygulayabilirsiniz.
    Birden fazla çözüm üretip küçük bir modelle umut vadeden adayları seçiyor, test edip geri bildirim döngüsünü tekrarlıyorsunuz.
    Bir tür genetik algoritma gibi giderek yakınsıyor.
  • “Elektrik masrafından daha ucuz” tam olarak ne demek, bunu açıklayabilir misiniz?

• Küçük modeller testlere göre aşırı ince ayar yapıldığı için gerçek dünyada performansları berbat oluyor.

• Ben her zaman şüpheciyim.
  Benchmark’ı geçiyorlar ama pratikte genel kullanım kabiliyeti çoğu zaman zayıf oluyor.
  Yine de modelleri inceltme girişiminin kendisi ilginç.

  • Dile ve alana göre çok değişiyor.
    Sistem programlamada (C++, Rust) Sonnet 4.5 seviyesine hâlâ büyük fark var.
    Açık modeller sözdizimi hatalarını çözmeye fazla zaman harcıyor ve sık sık mantıksal tutarlılığı kaybediyor.
    Yeterince yerel GPU’m var ama bulut modellerinin lisans sorunları da endişe verici.
  • ATLAS’ın yaklaşımı oldukça zekice.
    Birden fazla çözüm üretiyor, sonra her kod için embedding fingerprint hesaplayarak doğruluğu tahmin ediyor.
    Küçük bir sinir ağı olan Cost Field bunu puanlayıp en olası doğru kodu seçiyor.
    Bu sayede test süresini azaltırken doğru cevabı %88 doğrulukla seçebiliyor.
  • Model küçültülünce her nöron birden fazla rol üstlenmek zorunda kalıyor; bu da genelleme yeteneğini düşürüyor.
    Hatta büyük modeller yapısal olarak daha basit olabilir.

• Ben okurken GPU fiyatı $1000 olmuş bile.

• Bu yapay zekanın yazdığı proje, kendi benchmark’ını LiveCodeBench’ten tamamen farklı bir şekilde çalıştırıyor.
  README’de ATLAS skorunun 599 LCB görevine dayanan V3 pipeline (best-of-3 + Lens + iterative repair) sonucu olduğu açıkça yazıyor.
  Buna karşılık rakip model skorları tek çalıştırma (pass@1) temelinde verildiği için karşılaştırma adil değil.
  Sonnet ya da GPT5.4 de aynı şekilde test edilse daha yüksek skor alabilir.
  README’de gerçekte kullanılmayan pek çok yapı var; bu da yapay zekayla otomatik üretilmiş kodun özensizliğini gösteriyor.

• Bu tür benchmark’ların sadece probleme özel optimizasyonlarda mı etkili olduğunu merak ediyorum.
  Sonunda genelliği sıkıştırmanın mümkün olmadığı sınırlar hakkında bir şeyler öğreneceğiz.

• “Geometric Lens routing” ifadesi kulağa çok tuhaf geliyor.
  Sanki GPT’nin uydurduğu bir terim gibi.

• Şüphelerim var ama bu tür açık model deneylerini görmek gerçekten sevindirici.
  Modeli orta-üst seviye bir PC’de yerelde çalıştırabiliyorsak bu büyük bir ilerleme.