A.T.L.A.S - $500 GPU ने कोडिंग बेंचमार्क में Claude Sonnet को पीछे छोड़ा

 (github.com/itigges22)
12 पॉइंट द्वारा GN⁺ 2026-03-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization) एक self-hosted AI system है, जो एक consumer GPU पर बड़े मॉडलों के स्तर का code generation प्रदर्शन हासिल करता है
  • LiveCodeBench v5 में इसने 74.6% pass@1-v(k=3) दर्ज किया, जो Claude 4.5 Sonnet(71.4%) से आगे है, और पिछले संस्करण की तुलना में लगभग दोगुना प्रदर्शन सुधार हासिल किया
  • 14B parameter model(Qwen3-14B-Q4_K_M) को freeze रखकर constraint-based generation, self-verification·repair loop, और Geometric Lens candidate selection के जरिए उच्च प्रदर्शन हासिल किया गया
  • यह cloud या API call के बिना local environment में पूरी तरह autonomous execution करता है, और लागत केवल बिजली की होती है, इसलिए API-आधारित मॉडलों की तुलना में cost efficiency बहुत अधिक है
  • RTX 5060 Ti 16GB GPU वातावरण में यह लगभग 2 घंटे के भीतर 599 tasks प्रोसेस करता है, और बड़े मॉडलों की code generation क्षमता को personal hardware पर पुनःनिर्मित करना संभव बनाता है

बेंचमार्क परिणाम

  • LiveCodeBench v5: 74.6% pass@1-v(k=3), 599 tasks पूरे
    • V3 pipeline: PlanSearch + self-verified PR-CoT repair
  • GPQA Diamond: 47.0%, 198 tasks
  • SciCode: 14.7%, 341 tasks
  • pass@k-v(k=3) एक single-attempt result नहीं है, बल्कि 3 candidates generate करने के बाद Lens selection और failure पर iterative repair शामिल करने वाली विधि है

  • V3 चरणवार योगदान (Ablation Study)

    • A: बेसलाइन (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 में मॉडल द्वारा स्वयं बनाए गए test cases से internal verification किया जाता है; वास्तविक answer key का उपयोग नहीं होता
    • PR-CoT ने Phase 3 में 42 में से 36 (85.7%) समस्याओं को recover किया

लागत और प्रदर्शन तुलना

सिस्टम LCB pass@1 प्रति task लागत टिप्पणी
DeepSeek V3.2 Reasoning 86.2% ~$0.002 API, single attempt
GPT-5 (high) 84.6% ~$0.043 API, single attempt
ATLAS V3 74.6% ~$0.004 केवल local power उपयोग, best-of-3 + repair
Claude 4.5 Sonnet 71.4% ~$0.066 API, single attempt
Claude 4 Sonnet 65.5% ~$0.066 API, single attempt
  • ATLAS में केवल बिजली की लागत आती है, API लागत नहीं
  • 165W GPU के आधार पर 599 tasks पूरे करने में लगभग 1 घंटा 55 मिनट लगते हैं
  • latency अधिक है, लेकिन cost efficiency बहुत ऊंची है

काम करने का तरीका

  • पूरा pipeline

    • Phase 1: Generate
      • PlanSearch: constraints निकालना और विविध plans बनाना
      • Budget Forcing: token उपयोग नियंत्रण
    • Verify चरण
      • Geometric Lens (C(x)): 5120-dimensional self-embedding आधारित energy scoring
      • Sandbox: code execution और verification
    • Phase 3: Repair
      • Self-Test Generation: मॉडल स्वयं input-output pairs बनाता है
      • PR-CoT Repair: multi-perspective chain-of-thought आधारित code correction
    • single llama-server instance K3s पर चलता है, और speculative decoding तथा self-embedding generation एक साथ करता है
    • Geometric Lens candidates में से सबसे अच्छा code चुनता है (mixed-result tasks में 87.8% accuracy)
    • असफल tasks Phase 3 में भेजे जाते हैं, जहां self-test generation और iterative repair किया जाता है

इंस्टॉलेशन और रन

  • GitHub repository clone करने के बाद config file copy करें और installation script चलाएँ
  • benchmark/v3_runner.py से V3 benchmark चलाएँ
  • विस्तृत installation प्रक्रिया के लिए docs/SETUP.md देखें

हार्डवेयर और पुनरुत्पादन

संसाधन न्यूनतम टेस्ट वातावरण
GPU VRAM 16 GB RTX 5060 Ti 16 GB
सिस्टम RAM 14 GB 16 GB
Python 3.10+ 3.11
OS RHEL 9 / Ubuntu 24 RHEL 9 (Proxmox VM)
  • इसे Proxmox VM + VFIO GPU passthrough वातावरण में reproduce किया गया
  • 16GB या अधिक VRAM वाले अन्य NVIDIA GPU पर भी संभव है, लेकिन driver और VRAM settings में समायोजन की आवश्यकता हो सकती है
  • मुख्य tuning variables:
    • --parallel slots की संख्या (डिफ़ॉल्ट 2, VRAM कम होने पर 1)
    • KV cache quantization(Q4_0)
    • प्रति slot context length (डिफ़ॉल्ट 20480 tokens)
    • CUDA 12.8 version पर परीक्षण पूरा
  • V3.1 में portability सुधार की योजना है

रोडमैप

  • V3.0 (पूरा, 2026-03-05)

    • Qwen3-14B-Q4_K_M आधारित, 74.6% LCB प्रदर्शन
    • PlanSearch + BudgetForcing + Geometric Lens + PR-CoT pipeline पूरा

  • ज्ञात सीमाएँ

    1. LCB-केंद्रित optimization: GPQA, SciCode जैसे अन्य benchmarks के लिए optimization अपर्याप्त
    2. Phase 2 (Lens routing): dataset की कमी के कारण प्रभाव नगण्य (+0.0pp)
    3. G(x) metric tensor निष्क्रिय: C(x) के untrained होने से अर्थपूर्ण geometric structure अनुपस्थित
    4. single-threaded processing: task parallelization का समर्थन नहीं
    5. SandboxAdapter stdio bug: input separation feature निष्क्रिय (V3.1 में fix yojit)

  • V3.1 (प्रगति पर)

    • मॉडल बदलाव: Qwen3-14B → Qwen3.5-9B (DeltaNet linear attention, 3~4x speedup)
    • Lens retraining: real-time feedback आधारित C(x) recalibration
    • Phase 2 redesign: G(x) को फिर से implement करना या हटाना, SandboxAdapter bug fix
    • parallel processing की शुरुआत: task parallel execution से processing speed बढ़ाना
    • expanded benchmark suite: coding के अलावा reasoning·knowledge evaluation शामिल

  • नियोजित V3.1 benchmarks

    • Coding: LiveCodeBench v5, SciCode, अतिरिक्त contamination-resistant datasets
    • Reasoning/Knowledge: GPQA Diamond, AA-LCR, AA-Omniscience, Humanity’s Last Exam, CritPt आदि
    • Confidence Router task difficulty के अनुसार route चुनता है:
      • सरल queries → RAG-आधारित तेज reasoning (~30 सेकंड)
      • जटिल coding problems → पूरा pipeline (~20 मिनट)
    • लक्ष्य: 80~90% LCB pass@1-v(k=3) और और तेज processing speed

लाइसेंस

  • A.T.L.A.S Source Available License v1.0 लागू

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-03-28
Hacker News टिप्पणियाँ

  • मैं एजेंट से बड़े code blocks जनरेट करने की उम्मीद नहीं करता
    इसके बजाय यह logs खंगालने या कई source files का विश्लेषण करके test failure की वजह समझाने में कहीं ज़्यादा उपयोगी है
    मुझे लगता है कि ऐसी क्षमता को मापने के लिए debugging benchmarks की ज़रूरत है। ऐसे tests हों जो build system या CLI कौशल को मापें, तो अच्छा होगा

    • मैं भी सहमत हूँ। पूरे codebase में एकसमान छोटे बदलाव लागू करने में यह खास तौर पर उपयोगी है
      उदाहरण के लिए, मैंने पूरे app को hard delete से soft delete में refactor किया, जिसमें delete logic और queries दोनों बदलने पड़े
      हाथ से करना उबाऊ था और गलती की संभावना भी थी, इसलिए agent ने इसे जल्दी निपटा दिया, इसके लिए मैं सच में आभारी था
    • ऐसे लंबे कामों के लिए SWE Bench Pro या Terminal Bench 2 ज़्यादा उपयुक्त हैं
      SWE Bench Pro अभी तक ज़्यादा optimize नहीं हुआ है, इसलिए उस पर भरोसा किया जा सकता है
      दूसरी ओर, सामान्य SWE या LCB में numbers बढ़ा-चढ़ाकर दिखाने की होड़ के कारण उनकी उपयोगिता पहले ही कम हो चुकी है
    • build system से जुड़े tests CompileBench (Quesma का benchmark) में कवर किए जाते हैं
      संदर्भ के लिए, मैं Quesma का founder हूँ
    • मैं तो दिन भर बड़े पैमाने पर code generation ही करता हूँ
      अब कंपनी हो या side project, मैं खुद बहुत कम code लिखता हूँ
      ज़्यादातर Rust और TypeScript में developer tools बनाता हूँ
    • मैं भी environment setup agent को ही सौंप देता हूँ
      kubectl / helm से deploy करता हूँ और दिक्कत आने पर agent खुद debug करता है
      जिन कामों में पहले घंटों लगते थे, वे अब पलक झपकते खत्म हो जाते हैं, हैरानी होती है

  • मैं developers को MiniMax, Kimi जैसे models को असली काम में आज़माने की सलाह देना चाहूँगा
    लेकिन इनके नुकसान भी जल्दी सामने आ जाते हैं — reasoning token usage बढ़ना, धीमा output, quality में गिरावट वगैरह
    फिर भी model routing और reasoning budget को ठीक से संभाला जाए, तो cost में काफ़ी बचत हो सकती है
    app और prompts को optimize करके output tokens घटाना भी ज़रूरी है

    • मुझे भी Kimi से ठीक-ठाक नतीजे मिल रहे हैं
      लेकिन मुश्किल कामों में सिर्फ token unit cost से ज़्यादा efficiency मायने रखती है
      लिंक में दिया गया approach Sonnet और Opus पर भी काम करता है
      लेकिन MiniMax या Qwen अभी उस स्तर तक नहीं पहुँचे हैं
      आखिरकार, किस काम के लिए कौन-सा model cost-effective है, यह तय करने के लिए harness design ही सबसे अहम है
    • मैं SOTA से नीचे के models इस्तेमाल नहीं करता
      Opus 4.6 medium आज़माया था और तुरंत पछताना पड़ा। quality का अंतर बहुत बड़ा है
    • इस लिंक में दिखाया गया है कि MiniMax non-coding tasks में कमज़ोर है
      aibenchy तुलना परिणाम
    • मैं रोज़ाना coding के लिए MiniMax इस्तेमाल करता हूँ
      token usage की परवाह नहीं करता, 10 euro के monthly plan में हर 5 घंटे पर 1500 requests मिल जाती हैं
      असल में यह Opus या Sonnet से धीमा नहीं है
      benchmarks में Anthropic models बेहतर दिखते हैं, लेकिन real-world tasks में फ़र्क़ लगभग नहीं के बराबर है
      MiniMax अटक जाए तो Opus पर स्विच कर लो, फिर वापस MiniMax पर आ जाओ
      Opus budget जल्दी खा जाता है, लेकिन MiniMax लगभग unlimited है
    • Kimi हाल में मेरा debugging के लिए मुख्य model बन गया है
      यह Claude या GPT से तेज़ी से समस्या ढूँढ़ लेता है
      लेकिन context consistency की समस्या गंभीर है — code rewrite करते समय छोटी-सी चूक पूरी चीज़ बिगाड़ सकती है

  • अभी price competition की अंतहीन race चल रही है
    DeepSeek single-run के आधार पर सभी models को पीछे छोड़ देता है, और इसकी लागत local electricity की आधी के आसपास है

    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

    • अगर इसे local पर चला सकूँ, तो $0.004 की बिजली लागत मुझे मंज़ूर है
    • लेकिन यह अब भी 1989 Tiananmen Square घटना जैसे सवालों का जवाब नहीं देता…
    • मैंने कई open models टेस्ट किए हैं, लेकिन DeepSeek 3.2 ही सच में SOTA स्तर का है
    • DeepSeek पर भी यह approach लागू किया जा सकता है
      कई solutions जनरेट करो, फिर छोटे model से promising candidates चुनो, उन्हें test करो और feedback दोहराते रहो
      यह कुछ-कुछ genetic algorithm की तरह धीरे-धीरे converge करता है
    • “बिजली लागत से भी सस्ता” का मतलब क्या है, कोई समझा सकता है?

  • छोटे models को tests के हिसाब से हद से ज़्यादा fine-tune किया गया है, इसलिए असली माहौल में उनका प्रदर्शन बहुत खराब रहता है

  • मैं हमेशा skeptical रहता हूँ
    benchmarks पास हो जाते हैं, लेकिन असल में generality की कमी अक्सर दिखती है
    फिर भी models को slim down करने की कोशिश अपने-आप में दिलचस्प है

    • भाषा और domain के हिसाब से फ़र्क़ काफ़ी पड़ता है
      systems programming (C++, Rust) में अब भी Sonnet 4.5 स्तर से बड़ा gap है
      open models syntax errors ठीक करने में बहुत समय लगाते हैं, और अक्सर logical consistency खो देते हैं
      मेरे पास local GPUs काफ़ी हैं, लेकिन cloud models की licensing issues भी चिंता का विषय हैं
    • ATLAS का approach काफ़ी चतुर है
      यह कई solutions जनरेट करता है, फिर हर code का embedding fingerprint निकालकर accuracy की भविष्यवाणी करता है
      एक छोटा neural network, Cost Field, इसे score करता है और सबसे संभावित code चुनता है
      इसकी वजह से test time घटता है और फिर भी 88% accuracy के साथ सही answer चुना जाता है
    • model को छोटा करने पर हर neuron को कई भूमिकाएँ निभानी पड़ती हैं, जिससे generalization ability घट जाती है
      उल्टा, बड़े models संरचनात्मक रूप से ज़्यादा सरल हो सकते हैं

  • जब तक मैं पढ़ रहा था, GPU की कीमत $1000 हो चुकी थी

  • इस AI द्वारा लिखे गए project ने LiveCodeBench से बिल्कुल अलग तरीके से अपना benchmark चलाया
    README में साफ़ लिखा है कि ATLAS score 599 LCB tasks पर आधारित V3 pipeline(best-of-3 + Lens + iterative repair) का नतीजा है
    जबकि competitor models के scores single-run(pass@1) आधार पर हैं, इसलिए तुलना निष्पक्ष नहीं है
    अगर Sonnet या GPT5.4 को भी उसी तरीके से test किया जाए, तो वे और ऊँचे scores ला सकते हैं
    README में कई ऐसी structures हैं जो वास्तव में इस्तेमाल ही नहीं होतीं, जिससे AI auto-generated code की ढीली गुणवत्ता सामने आती है

  • मुझे जिज्ञासा है कि क्या ऐसे benchmarks सिर्फ problem-specific optimization पर ही असरदार हैं
    आख़िर में शायद हम यह सीखेंगे कि generality को compress न कर पाने की एक सीमा होती है

  • “Geometric Lens routing” जैसा phrase बहुत अजीब लगता है
    यह बस GPT द्वारा गढ़ा गया term लगता है

  • मैं skeptical हूँ, फिर भी ऐसे open model experiments सच में स्वागतयोग्य हैं
    अगर mid-to-high-end PC पर भी model local में चल सके, तो यह बड़ी प्रगति होगी