A.T.L.A.S – Eine 500-Dollar-GPU übertrifft Claude Sonnet in Coding-Benchmarks

• A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization) ist ein selbst gehostetes KI-System, das mit einer einzelnen Consumer-GPU Code-Generierungsleistung auf dem Niveau großer Modelle erreicht
• Laut LiveCodeBench v5 erzielte es 74,6 % pass@1-v(k=3) und übertraf damit Claude 4.5 Sonnet (71,4 %); gegenüber der vorherigen Version wurde nahezu eine Verdopplung der Leistung erreicht
• Mit einem eingefrorenen 14B-Parameter-Modell (Qwen3-14B-Q4_K_M) wird hohe Leistung durch constraintsbasierte Generierung, eine Schleife aus Selbstvalidierung und Korrektur sowie Geometric-Lens-Kandidatenauswahl erzielt
• Es läuft vollständig autonom in einer lokalen Umgebung ohne Cloud oder API-Aufrufe; Kosten fallen nur für Strom an, was im Vergleich zu API-basierten Modellen eine sehr hohe Kosteneffizienz bietet
• In einer Umgebung mit RTX 5060 Ti 16GB GPU verarbeitet es 599 Aufgaben in rund 2 Stunden und zeigt, dass sich die Code-Generierungsfähigkeiten großer Modelle auf persönlicher Hardware reproduzieren lassen

Benchmark-Ergebnisse

• LiveCodeBench v5: 74,6 % pass@1-v(k=3), 599 Aufgaben
  • V3-Pipeline: PlanSearch + self-verified PR-CoT repair
• GPQA Diamond: 47,0 %, 198 Aufgaben
• SciCode: 14,7 %, 341 Aufgaben
• pass@k-v(k=3) ist kein Ergebnis eines einzelnen Versuchs, sondern ein Verfahren, das die Erzeugung von 3 Kandidaten, Lens-Auswahl und bei Fehlschlag wiederholte Korrektur umfasst

• Beitrag der einzelnen V3-Stufen (Ablation Study)

  • A: Basisversion (ohne 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)
  • In Phase 3 wird die interne Validierung mit vom Modell selbst erzeugten Testfällen durchgeführt; echte Referenzantworten werden nicht verwendet
  • PR-CoT stellte in Phase 3 36 von 42 Problemen (85,7 %) wieder her

Kosten- und Leistungsvergleich

System	LCB pass@1	Kosten pro Aufgabe	Anmerkung
DeepSeek V3.2 Reasoning	86,2 %	~$0.002	API, einzelner Versuch
GPT-5 (high)	84,6 %	~$0.043	API, einzelner Versuch
ATLAS V3	74,6 %	~$0.004	nur lokaler Stromverbrauch, best-of-3 + repair
Claude 4.5 Sonnet	71,4 %	~$0.066	API, einzelner Versuch
Claude 4 Sonnet	65,5 %	~$0.066	API, einzelner Versuch

• Bei ATLAS fallen nur Stromkosten an, keine API-Kosten
• Mit einer 165W-GPU dauert die Bearbeitung von 599 Aufgaben etwa 1 Stunde 55 Minuten
• Die Latenz ist höher, aber die Kosteneffizienz ist sehr hoch

Funktionsweise

• Gesamte Pipeline

  • Phase 1: Generate
    • PlanSearch: Extraktion von Constraints und Erzeugung verschiedener Pläne
    • Budget Forcing: Steuerung des Token-Verbrauchs
  • Verify-Stufe
    • Geometric Lens (C(x)): Energy Scoring auf Basis selbst erzeugter 5120-dimensionaler Embeddings
    • Sandbox: Ausführung und Verifikation von Code
  • Phase 3: Repair
    • Self-Test Generation: Das Modell erzeugt selbst Ein-/Ausgabe-Paare
    • PR-CoT Repair: Code-Korrektur auf Basis von Chain-of-Thought mit mehreren Perspektiven
  • Eine einzelne llama-server-Instanz läuft auf K3s und führt gleichzeitig speculative decoding und die Erzeugung eigener Embeddings aus
  • Geometric Lens wählt unter den Kandidaten den besten Code aus (87,8 % Genauigkeit bei Aufgaben mit gemischten Ergebnissen)
  • Fehlgeschlagene Aufgaben werden zu Phase 3 weitergeleitet, wo Selbsttest-Erzeugung und iterative Korrektur erfolgen

Installation und Ausführung

• GitHub-Repository klonen, dann Konfigurationsdatei kopieren und das Installationsskript ausführen
• V3-Benchmark mit benchmark/v3_runner.py ausführen
• Das detaillierte Installationsverfahren steht in docs/SETUP.md

Hardware und Reproduzierbarkeit

Ressource	Minimum	Testumgebung
GPU-VRAM	16 GB	RTX 5060 Ti 16 GB
System-RAM	14 GB	16 GB
Python	3.10+	3.11
OS	RHEL 9 / Ubuntu 24	RHEL 9 (Proxmox-VM)

• Reproduziert in einer Umgebung mit Proxmox-VM + VFIO-GPU-Passthrough
• Funktioniert auch auf anderen NVIDIA-GPUs mit mindestens 16 GB VRAM, erfordert aber Anpassungen bei Treibern und VRAM-Einstellungen
• Wichtige Tuning-Parameter:
  • Anzahl der --parallel-Slots (Standard 2, bei zu wenig VRAM auf 1 reduzieren)
  • KV-Cache-Quantisierung (Q4_0)
  • Kontextlänge pro Slot (Standard 20480 Token)
  • Tests mit CUDA 12.8 abgeschlossen
• In V3.1 sind Verbesserungen bei der Portabilität geplant

Roadmap

• V3.0 (abgeschlossen, 2026-03-05)

  • Basiert auf Qwen3-14B-Q4_K_M, 74,6 % LCB-Leistung
  • PlanSearch + BudgetForcing + Geometric Lens + PR-CoT-Pipeline fertiggestellt

• Bekannte Einschränkungen

  1. LCB-spezifische Optimierung: Für andere Benchmarks wie GPQA und SciCode noch nicht ausreichend optimiert
  2. Phase 2 (Lens routing): Geringer Effekt wegen zu kleiner Datensätze (+0,0pp)
  3. G(x)-Metriktensor deaktiviert: C(x) ist untrainiert, daher keine sinnvolle geometrische Struktur
  4. Single-Thread-Verarbeitung: Keine Parallelisierung von Aufgaben unterstützt
  5. SandboxAdapter-stdio-Bug: Funktion zur Eingabetrennung deaktiviert (Fix in V3.1 geplant)

• V3.1 (in Arbeit)

  • Modellwechsel: Qwen3-14B → Qwen3.5-9B (DeltaNet lineare Attention, 3- bis 4-fache Geschwindigkeitssteigerung)
  • Lens-Neutrainierung: Rekalibrierung von C(x) auf Basis von Echtzeit-Feedback
  • Neudesign von Phase 2: G(x) neu implementieren oder entfernen, SandboxAdapter-Bug beheben
  • Einführung von Parallelverarbeitung: Höhere Verarbeitungsgeschwindigkeit durch parallele Ausführung von Aufgaben
  • Erweiterte Benchmark-Suite: Einschließlich Reasoning- und Wissensevaluierung jenseits von Coding

• Geplante V3.1-Benchmarks

  • Coding: LiveCodeBench v5, SciCode, zusätzliche kontaminationsresistente Datensätze
  • Reasoning/Wissen: GPQA Diamond, AA-LCR, AA-Omniscience, Humanity’s Last Exam, CritPt usw.
  • Confidence Router wählt je nach Aufgabenschwierigkeit den Pfad:
    • Einfache Anfragen → schnelles RAG-basiertes Reasoning (~30 Sekunden)
    • Komplexe Coding-Probleme → vollständige Pipeline (~20 Minuten)
  • Ziel: 80–90 % LCB pass@1-v(k=3) und höhere Verarbeitungsgeschwindigkeit

Lizenz

• A.T.L.A.S Source Available License v1.0

[GN⁺]

Hacker-News-Kommentare

• Ich erwarte von Agenten keine großen Codeblöcke
  Stattdessen sind sie viel nützlicher, wenn es darum geht, Logs zu durchforsten oder mehrere Quelldateien zu analysieren und die Ursache fehlgeschlagener Tests zu erklären
  Ich denke, wir brauchen Debugging-Benchmarks, die genau diese Fähigkeiten bewerten. Tests, die Build-Systeme oder CLI-Kompetenz messen, wären gut

  • Stimme ich auch zu. Besonders nützlich ist das, wenn man im gesamten Codebestand kleine konsistente Änderungen anwenden muss
    Ich habe zum Beispiel eine ganze App von Hard Delete auf Soft Delete refaktoriert und musste sowohl die Löschlogik als auch die Queries anpassen
    Von Hand wäre das langweilig und fehleranfällig gewesen, deshalb war ich wirklich dankbar, dass der Agent das schnell erledigt hat
  • Für solche langfristigen Aufgaben sind SWE Bench Pro oder Terminal Bench 2 geeignet
    SWE Bench Pro ist noch nicht übermäßig optimiert und deshalb vertrauenswürdig
    Normales SWE oder LCB haben dagegen durch den Wettlauf um aufgeblähte Zahlen schon stark an Aussagekraft verloren
  • Tests rund um Build-Systeme werden in CompileBench behandelt, dem Benchmark von Quesma
    Zur Transparenz: Ich bin Gründer von Quesma
  • Ich mache den ganzen Tag nur umfangreiche Codegenerierung
    Inzwischen schreibe ich kaum noch selbst Code, weder in der Firma noch in Side Projects
    Ich entwickle hauptsächlich Developer-Tools in Rust und TypeScript
  • Ich überlasse dem Agenten auch die Einrichtung der Umgebung
    Die Deployments laufen mit kubectl / helm, und wenn Probleme auftreten, debuggt der Agent sie direkt selbst
    Dinge, die früher Stunden gedauert haben, sind plötzlich in kürzester Zeit erledigt, das ist erstaunlich

• Ich würde Entwicklern empfehlen, Modelle wie MiniMax oder Kimi einmal in echter Arbeit auszuprobieren
  Die Nachteile zeigen sich aber auch schnell — mehr Reasoning-Tokens, langsame Ausgaben, sinkende Qualität usw.
  Trotzdem kann man mit gutem Modell-Routing und sauber verwaltetem Reasoning-Budget viel Geld sparen
  Wichtig ist auch, App und Prompt zu optimieren, um die Zahl der Output-Tokens zu senken

  • Ich bekomme mit Kimi ebenfalls ordentliche Ergebnisse
    Bei schwierigen Aufgaben ist Effizienz aber wichtiger als der reine Tokenpreis
    Der im Link beschriebene Ansatz funktioniert auch bei Sonnet und Opus
    MiniMax oder Qwen kommen da allerdings noch nicht ganz mit
    Entscheidend ist am Ende das Harness-Design, also sauber zu unterscheiden, welches Modell für welche Aufgabe kosteneffizient ist
  • Ich nutze keine Modelle unterhalb des SOTA-Niveaus
    Ich habe Opus 4.6 medium ausprobiert und es sofort bereut. Der Qualitätsunterschied ist zu groß
  • Wie in diesem Link zu sehen ist, ist MiniMax bei Nicht-Coding-Aufgaben schwach
    aibenchy-Vergleichsergebnis
  • Ich nutze MiniMax jeden Tag zum Coden
    Der Tokenverbrauch ist mir egal, im 10-Euro-Monatstarif sind alle 5 Stunden 1500 Anfragen möglich
    In der Praxis ist es nicht langsamer als Opus oder Sonnet
    In Benchmarks sehen die Anthropic-Modelle besser aus, aber bei realen Aufgaben ist der Unterschied kaum spürbar
    Wenn MiniMax nicht weiterkommt, wechsle ich zu Opus und gehe danach wieder zu MiniMax zurück
    Opus verbrennt das Budget schnell, MiniMax ist dagegen praktisch unbegrenzt
  • Kimi ist in letzter Zeit mein bevorzugtes Modell fürs Debugging
    Es findet Probleme schneller als Claude oder GPT
    Allerdings hat es ernste Probleme mit der Kontextkonsistenz — bei Umschreibungen von Code reichen kleine Abweichungen, um alles kaputtzumachen

• Im Moment ist es ein endloses Rennen im Preiswettbewerb
  DeepSeek schlägt alle Modelle bei Single-Run-Betrachtung und kostet nur etwa die Hälfte des lokalen Strompreises

  DeepSeek V3.2 Reasoning 86.2% ~$0.002 API, single-shot
  ATLAS V3 (pass@1-v(k=3)) 74.6% ~$0.004 nur lokaler Strom, best-of-3 + Repair-Pipeline

  • Wenn ich es lokal laufen lassen kann, würde ich 0,004 Dollar Stromkosten durchaus in Kauf nehmen
  • Aber auf Fragen wie zu den Tian’anmen-Protesten von 1989 antwortet es immer noch nicht…
  • Ich habe mehrere Open Models getestet, aber nur DeepSeek 3.2 ist wirklich auf SOTA-Niveau
  • Man kann diesen Ansatz auch auf DeepSeek anwenden
    Man erzeugt mehrere Lösungen, lässt ein kleines Modell vielversprechende Kandidaten auswählen und iteriert dann mit Tests und Feedback weiter
    Das konvergiert schrittweise fast wie ein genetischer Algorithmus
  • Kann jemand erklären, was mit „billiger als Stromkosten“ gemeint ist?

• Kleine Modelle sind für Tests übermäßig feinabgestimmt und liefern in realen Umgebungen miserable Leistung

• Ich bin immer skeptisch
  Benchmarks werden zwar bestanden, aber in der Praxis fehlt oft die Allgemeingültigkeit
  Trotzdem ist der Versuch an sich interessant, Modelle zu verschlanken

  • Das hängt stark von Sprache und Bereich ab
    In der Systemprogrammierung (C++, Rust) gibt es weiterhin einen großen Abstand zum Niveau von Sonnet 4.5
    Open Models verbringen zu viel Zeit damit, Syntaxfehler zu beheben, und verlieren dabei oft die logische Konsistenz
    Ich habe zwar genug lokale GPUs, mache mir aber auch Sorgen über Lizenzprobleme bei Cloud-Modellen
  • Der Ansatz von ATLAS ist ziemlich clever
    Es erzeugt mehrere Lösungen und berechnet für jeden Code einen Embedding-Fingerprint, um die Korrektheit vorherzusagen
    Ein kleines neuronales Netz namens Cost Field bewertet das und wählt den Code mit der höchsten Erfolgswahrscheinlichkeit aus
    Dadurch wird die Testzeit verkürzt, und trotzdem wird mit 88 % Genauigkeit die richtige Antwort ausgewählt
  • Wenn man ein Modell verkleinert, muss jedes Neuron mehrere Rollen übernehmen, wodurch die Generalisierungsfähigkeit leidet
    Ein großes Modell kann strukturell sogar einfacher sein

• Während ich das gelesen habe, ist der GPU-Preis schon auf $1000 gestiegen

• Dieses von KI geschriebene Projekt fährt seinen eigenen Benchmark auf eine Art, die sich vollständig von LiveCodeBench unterscheidet
  Im README steht ausdrücklich, dass der ATLAS-Score auf den Ergebnissen der V3-Pipeline (best-of-3 + Lens + iterative repair) über 599 LCB-Aufgaben basiert
  Die Scores der Vergleichsmodelle beruhen dagegen auf Single-Run-Werten (pass@1), also ist der Vergleich unfair
  Auch Sonnet oder GPT5.4 würden bei gleichem Testverfahren höhere Werte erzielen
  Im README gibt es viele Strukturen, die tatsächlich gar nicht verwendet werden, was die Schlampigkeit von automatisch erzeugtem KI-Code zeigt

• Ich frage mich, ob solche Benchmarks nur für problemspezifische Optimierung wirksam sind
  Am Ende werden wir wohl lernen, dass es eine Grenze der nicht komprimierbaren Allgemeinheit gibt

• Der Ausdruck „Geometric Lens routing“ klingt extrem seltsam
  Es wirkt einfach wie ein Begriff, den GPT erfunden hat

• Ich bin zwar skeptisch, aber solche Open-Model-Experimente begrüße ich wirklich
  Wenn man Modelle selbst auf einem besseren Mittelklasse-PC lokal ausführen kann, wäre das ein großer Fortschritt