A.T.L.A.S - GPU ราคา $500 เอาชนะ Claude Sonnet บนเบนช์มาร์กการเขียนโค้ด

 (github.com/itigges22)
12 คะแนน โดย GN⁺ 2026-03-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • A.T.L.A.S (Adaptive Test-time Learning and Autonomous Specialization) คือ ระบบ AI แบบโฮสต์เอง ที่ทำผลงานด้านการสร้างโค้ดได้ในระดับโมเดลขนาดใหญ่ด้วย GPU สำหรับผู้ใช้ทั่วไปเพียงตัวเดียว
  • บน LiveCodeBench v5 ทำได้ 74.6% pass@1-v(k=3) แซง Claude 4.5 Sonnet (71.4%) พร้อมยกระดับประสิทธิภาพเกือบ 2 เท่าเมื่อเทียบกับเวอร์ชันก่อนหน้า
  • แม้จะตรึง โมเดล 14B พารามิเตอร์ (Qwen3-14B-Q4_K_M) ไว้ แต่ยังคงได้ประสิทธิภาพสูงผ่าน การสร้างแบบอิงข้อจำกัด, ลูปตรวจสอบและแก้ไขด้วยตนเอง, และ การคัดเลือกผู้สมัครด้วย Geometric Lens
  • ทำงานได้แบบอัตโนมัติเต็มรูปแบบในเครื่องโลคัล โดยไม่ต้องใช้คลาวด์หรือเรียก API และมี ค่าใช้จ่ายแค่ค่าไฟฟ้า ทำให้ คุ้มค่าด้านต้นทุน สูงมากเมื่อเทียบกับโมเดลที่พึ่ง API
  • ในสภาพแวดล้อม RTX 5060 Ti 16GB GPU ประมวลผลงาน 599 ข้อได้ภายในราว 2 ชั่วโมง แสดงให้เห็นว่าสามารถ จำลองความสามารถด้านการสร้างโค้ดของโมเดลขนาดใหญ่บนฮาร์ดแวร์ส่วนบุคคล ได้

ผลลัพธ์เบนช์มาร์ก

  • LiveCodeBench v5: 74.6% pass@1-v(k=3), ทำ 599 ข้อ
    • ไปป์ไลน์ V3: PlanSearch + self-verified PR-CoT repair
  • GPQA Diamond: 47.0%, 198 ข้อ
  • SciCode: 14.7%, 341 ข้อ
  • pass@k-v(k=3) ไม่ใช่ผลจากการลองครั้งเดียว แต่เป็นวิธีที่ สร้างผู้สมัคร 3 ชุด จากนั้นให้ Lens เลือก และหากล้มเหลวจะทำการแก้ไขซ้ำ

  • การมีส่วนร่วมของแต่ละขั้นใน 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 มีการตรวจสอบภายในด้วย ชุดทดสอบที่โมเดลสร้างขึ้นเอง โดยไม่ใช้คำตอบจริง
    • PR-CoT กู้คืนปัญหาได้ 36 จาก 42 ข้อ (85.7%) ใน Phase 3

การเปรียบเทียบต้นทุนและประสิทธิภาพ

ระบบ LCB pass@1 ต้นทุนต่อโจทย์ หมายเหตุ
DeepSeek V3.2 Reasoning 86.2% ~$0.002 API, ลองครั้งเดียว
GPT-5 (high) 84.6% ~$0.043 API, ลองครั้งเดียว
ATLAS V3 74.6% ~$0.004 ใช้ไฟฟ้าในเครื่องเท่านั้น, best-of-3 + repair
Claude 4.5 Sonnet 71.4% ~$0.066 API, ลองครั้งเดียว
Claude 4 Sonnet 65.5% ~$0.066 API, ลองครั้งเดียว
  • ATLAS มี ค่าใช้จ่ายเฉพาะค่าไฟฟ้า ไม่มีค่า API
  • บน GPU 165W ใช้เวลาราว 1 ชั่วโมง 55 นาทีในการทำ 599 ข้อ
  • แม้ latency จะสูง แต่ คุ้มค่าด้านต้นทุน อย่างมาก

หลักการทำงาน

  • ไปป์ไลน์ทั้งหมด

    • Phase 1: Generate
      • PlanSearch: ดึงข้อจำกัดและสร้างแผนที่หลากหลาย
      • Budget Forcing: ควบคุมปริมาณการใช้โทเค็น
    • ขั้น Verify
      • Geometric Lens (C(x)): การให้คะแนนพลังงานจาก self-embedding ขนาด 5120 มิติ
      • Sandbox: รันและตรวจสอบโค้ด
    • Phase 3: Repair
      • Self-Test Generation: โมเดลสร้างคู่ข้อมูลเข้า/ออกขึ้นเอง
      • PR-CoT Repair: แก้ไขโค้ดด้วย chain-of-thought แบบหลายมุมมอง
    • อินสแตนซ์ llama-server เดียว ทำงานบน K3s และดำเนินทั้ง speculative decoding กับ การสร้าง self-embedding ไปพร้อมกัน
    • Geometric Lens ใช้เลือกโค้ดที่ดีที่สุดจากผู้สมัคร (ความแม่นยำ 87.8% ในงานที่ใช้ผลลัพธ์แบบผสม)
    • โจทย์ที่ล้มเหลวจะถูกส่งต่อไปยัง Phase 3 เพื่อทำ การสร้างชุดทดสอบเองและแก้ไขซ้ำ

การติดตั้งและการรัน

  • โคลนที่เก็บ GitHub จากนั้นคัดลอกไฟล์ตั้งค่าและรันสคริปต์ติดตั้ง
  • รันเบนช์มาร์ก V3 ด้วย benchmark/v3_runner.py
  • ขั้นตอนติดตั้งโดยละเอียดดูได้ที่ 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
  • สามารถใช้กับ NVIDIA GPU อื่นที่มี VRAM 16GB ขึ้นไปได้ แต่ต้องปรับแต่งไดรเวอร์และการตั้งค่า VRAM
  • ตัวแปรหลักที่ต้องปรับ:
    • จำนวนสล็อต --parallel (ค่าเริ่มต้น 2 และลดเป็น 1 ได้หาก VRAM ไม่พอ)
    • การทำ quantization ของ KV cache (Q4_0)
    • ความยาวคอนเท็กซ์ต่อสล็อต (ค่าเริ่มต้น 20480 โทเค็น)
    • ทดสอบแล้วกับ CUDA 12.8
  • มีแผนปรับปรุงความพกพาใน V3.1

โรดแมป

  • V3.0 (เสร็จสมบูรณ์, 2026-03-05)

    • ใช้ Qwen3-14B-Q4_K_M เป็นฐาน ทำผลงาน LCB ได้ 74.6%
    • สร้างไปป์ไลน์ PlanSearch + BudgetForcing + Geometric Lens + PR-CoT เสร็จสมบูรณ์

  • ข้อจำกัดที่ทราบ

    1. การปรับแต่งเฉพาะ LCB: ยังปรับให้เหมาะกับเบนช์มาร์กอื่นอย่าง GPQA, SciCode ได้ไม่ดี
    2. Phase 2 (Lens routing): ผลลัพธ์ยังน้อยมากจากข้อจำกัดของชุดข้อมูล (+0.0pp)
    3. ปิดการใช้งาน G(x) metric tensor: เนื่องจาก C(x) ยังไม่ผ่านการฝึก จึงยังไม่มีโครงสร้างเชิงเรขาคณิตที่มีความหมาย
    4. ประมวลผลแบบเธรดเดียว: ยังไม่รองรับการประมวลผลโจทย์แบบขนาน
    5. บั๊ก stdio ของ SandboxAdapter: ปิดการใช้งานฟังก์ชันแยกข้อมูลเข้า (มีกำหนดแก้ใน V3.1)

  • V3.1 (กำลังดำเนินการ)

    • เปลี่ยนโมเดล: Qwen3-14B → Qwen3.5-9B (DeltaNet linear attention, เร็วขึ้น 3~4 เท่า)
    • ฝึก Lens ใหม่: ปรับเทียบ C(x) ใหม่จากฟีดแบ็กแบบเรียลไทม์
    • ออกแบบ Phase 2 ใหม่: สร้าง G(x) ใหม่หรือตัดออก พร้อมแก้บั๊ก SandboxAdapter
    • เพิ่มการประมวลผลแบบขนาน: เร่งความเร็วด้วยการรันโจทย์หลายข้อพร้อมกัน
    • ขยายชุดเบนช์มาร์ก: รวมการประเมินด้านเหตุผลและความรู้ที่นอกเหนือจากการเขียนโค้ด

  • เบนช์มาร์กที่วางแผนไว้สำหรับ V3.1

    • การเขียนโค้ด: LiveCodeBench v5, SciCode, และชุดข้อมูลเพิ่มเติมที่ทนต่อการปนเปื้อน
    • เหตุผล/ความรู้: GPQA Diamond, AA-LCR, AA-Omniscience, Humanity’s Last Exam, CritPt เป็นต้น
    • Confidence Router จะเลือกเส้นทางตามความยากของโจทย์:
      • คำถามง่าย → การอนุมานแบบรวดเร็วด้วย RAG (~30 วินาที)
      • ปัญหาการเขียนโค้ดซับซ้อน → ไปป์ไลน์เต็มรูปแบบ (~20 นาที)
    • เป้าหมาย: 80~90% LCB pass@1-v(k=3) และ ความเร็วในการประมวลผลที่สูงขึ้น

ไลเซนส์

  • ใช้ A.T.L.A.S Source Available License v1.0

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-28
ความเห็นจาก Hacker News

  • ฉันไม่ได้คาดหวังให้เอเจนต์ สร้างโค้ดบล็อกใหญ่ๆ
    แต่กลับมีประโยชน์กว่ามากในการไล่อ่านล็อกหรือวิเคราะห์ไฟล์ซอร์สหลายไฟล์แล้วอธิบายสาเหตุที่เทสต์ล้มเหลว
    คิดว่าน่าจะต้องมี benchmark ด้านการดีบัก ที่ประเมินความสามารถแบบนี้ ถ้ามีการทดสอบที่วัดความชำนาญด้าน build system หรือ CLI ก็น่าจะดี

    • ฉันก็เห็นด้วย มีประโยชน์มากโดยเฉพาะเวลาใช้ทำ การเปลี่ยนแปลงเล็กๆ อย่างสม่ำเสมอ ทั้งโค้ดเบส
      ตัวอย่างเช่นเคยรีแฟกเตอร์ทั้งแอปจาก hard delete เป็น soft delete ซึ่งต้องแก้ทั้ง logic การลบและ query
      ถ้าทำเองจะน่าเบื่อและพลาดง่าย แต่เอเจนต์จัดการให้ได้เร็วมาก เลยรู้สึกขอบคุณจริงๆ
    • สำหรับงานระยะยาวแบบนี้ SWE Bench Pro หรือ Terminal Bench 2 เหมาะกว่า
      SWE Bench Pro ยังไม่ถูก optimize จนเกินไป เลยพอเชื่อถือได้
      ขณะที่ SWE ทั่วไปหรือ LCB ตอนนี้กลายเป็นการแข่งขันปั่นตัวเลขจนแทบไม่มีประโยชน์แล้ว
    • การทดสอบที่เกี่ยวกับ build system มีใน CompileBench (benchmark ของ Quesma)
      เผื่อบอกไว้ก่อนว่าฉันเป็นผู้ก่อตั้ง Quesma
    • ฉันทำ การสร้างโค้ดขนาดใหญ่ ทั้งวัน
      ตอนนี้แทบไม่ได้เขียนโค้ดเองแล้ว ไม่ว่าจะงานบริษัทหรือโปรเจกต์ส่วนตัว
      ส่วนใหญ่ทำงานสร้างเครื่องมือสำหรับนักพัฒนาด้วย Rust และ TypeScript
    • ฉันก็ให้เอเจนต์จัดการเรื่องตั้งค่าสภาพแวดล้อมเหมือนกัน
      deploy ด้วย kubectl / helm แล้วถ้ามีปัญหาเอเจนต์ก็ดีบักเองเลย
      งานที่เคยกินเวลาหลายชั่วโมงจบได้แทบจะทันทีจนน่าทึ่งมาก

  • อยากแนะนำให้นักพัฒนาลองเอาโมเดลอย่าง MiniMax, Kimi ไปใช้กับงานจริง
    แต่ข้อเสียก็เห็นได้เร็วเหมือนกัน — เช่น การใช้ reasoning token สูงขึ้น, การตอบช้า, คุณภาพลดลง ฯลฯ
    ถึงอย่างนั้น ถ้าจัดการ model routing และ reasoning budget ให้ดี ก็ประหยัดค่าใช้จ่ายได้มาก
    การปรับแอปและพรอมป์ต์ให้ใช้ output token น้อยลงก็สำคัญเช่นกัน

    • ฉันก็ได้ผลลัพธ์ใช้ได้จาก Kimi เหมือนกัน
      แต่กับงานยากๆ ประสิทธิภาพสำคัญกว่าการดูแค่ ราคาต่อโทเคน
      วิธีในลิงก์นั้นใช้ได้ผลกับ Sonnet และ Opus ด้วย
      แต่ MiniMax หรือ Qwen ยังไปไม่ถึงระดับนั้น
      สุดท้ายสิ่งสำคัญคือการ ออกแบบ harness เพื่อแยกให้ออกว่างานไหนโมเดลไหนคุ้มค่าที่สุด
    • ฉันไม่ใช้โมเดลที่ต่ำกว่า SOTA
      เคยลอง Opus 4.6 medium แล้วเสียใจทันที ความต่างด้านคุณภาพชัดมาก
    • ตามลิงก์นี้ MiniMax มีประสิทธิภาพต่ำใน งานที่ไม่ใช่การเขียนโค้ด
      ผลเปรียบเทียบ aibenchy
    • ฉันใช้ MiniMax เขียนโค้ดทุกวัน
      ไม่ได้สนใจเรื่องการใช้โทเคนเลย แพ็กเกจเดือนละ 10 ยูโรให้ส่งได้ 1500 ครั้งทุก 5 ชั่วโมง
      ในการใช้งานจริงก็ไม่ได้ช้ากว่า Opus หรือ Sonnet
      ใน benchmark โมเดลของ Anthropic อาจดูดีกว่า แต่กับ งานจริง แทบไม่ต่างกัน
      ถ้า MiniMax ไปต่อไม่ไหวก็สลับไป Opus แล้วค่อยกลับมา MiniMax ได้
      Opus กินงบเร็ว แต่ MiniMax แทบจะเหมือนไม่จำกัด
    • Kimi เป็น โมเดลหลักสำหรับการดีบัก ของฉันช่วงนี้
      มันหาปัญหาได้เร็วกว่าทั้ง Claude และ GPT
      แต่มี ปัญหาความสม่ำเสมอของบริบท หนักมาก — เวลา rewrite โค้ด แค่พลาดนิดเดียวก็พังทั้งงานได้

  • ตอนนี้มันคือ การแข่งขันลดราคาแบบไม่มีวันจบ
    DeepSeek ชนะทุกโมเดลเมื่อดูแบบรันครั้งเดียว และต้นทุนยังอยู่แค่ประมาณครึ่งหนึ่งของค่าไฟรันโลคัล

    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

    • ถ้ารันในเครื่องตัวเองได้ ฉันยอมจ่าย ค่าไฟ 0.004 ดอลลาร์ ได้สบาย
    • แต่ก็ยังไม่ตอบคำถามอย่าง เหตุการณ์เทียนอันเหมินปี 1989 อยู่ดี…
    • ฉันทดสอบโมเดลโอเพนหลายตัวแล้ว แต่มีแค่ DeepSeek 3.2 ที่เข้าใกล้ระดับ SOTA จริงๆ
    • เอาวิธีนี้ไปใช้กับ DeepSeek ได้เหมือนกัน
      คือสร้างหลายคำตอบ เลือกตัวเลือกที่มีแววด้วยโมเดลเล็ก จากนั้นเทสต์แล้ววนรับฟีดแบ็กซ้ำ
      ค่อยๆ ลู่เข้าหาคำตอบแบบหนึ่งใน อัลกอริทึมเชิงพันธุกรรม
    • คำว่า “ถูกกว่าค่าไฟ” หมายความว่ายังไง ช่วยอธิบายได้ไหม?

  • โมเดลเล็กหลายตัวถูก fine-tune จนเกินไป ให้เข้ากับเทสต์ พอไปใช้จริงกลับทำผลงานได้แย่มาก

  • ฉันระแวงไว้ก่อนเสมอ
    benchmark ผ่านก็จริง แต่ของจริงมักมีปัญหาเรื่อง ความเป็นงานอเนกประสงค์
    ถึงอย่างนั้น ความพยายามจะ ทำให้โมเดลเล็กลง ก็ยังน่าสนใจ

    • มันต่างกันมากตามภาษาและโดเมน
      ในงาน system programming (C++, Rust) ยังห่างจากระดับ Sonnet 4.5 มาก
      โมเดลโอเพนเสียเวลาไปกับการแก้ syntax error มากเกินไป และมักเสีย ความสอดคล้องเชิงตรรกะ
      ฉันมี GPU โลคัลพอสมควร แต่ก็ยังกังวลเรื่อง ปัญหาไลเซนส์ ของโมเดลคลาวด์
    • แนวทางของ ATLAS ถือว่าฉลาดทีเดียว
      มันสร้างหลายโซลูชัน แล้วคำนวณ embedding fingerprint ของแต่ละโค้ดเพื่อทำนายความถูกต้อง
      โครงข่ายประสาทขนาดเล็กชื่อ Cost Field จะให้คะแนน แล้วเลือกโค้ดที่น่าจะถูกที่สุด
      ทำให้ลดเวลาเทสต์ลงได้ แต่ยังเลือกคำตอบที่ถูกต้องได้ด้วยความแม่นยำ 88%
    • พอทำโมเดลให้เล็กลง นิวรอนแต่ละตัวต้องรับหลายบทบาท ทำให้ ความสามารถในการ generalize ลดลง
      กลับกัน โมเดลใหญ่กว่าอาจเรียบง่ายกว่าในเชิงโครงสร้างก็ได้

  • ระหว่างที่อ่านอยู่ ราคาการ์ด GPU ก็กลายเป็น $1000 ไปแล้ว

  • โปรเจกต์ที่ AI ตัวนี้เขียนขึ้นรัน benchmark ของตัวเองในแบบที่ ต่างจาก LiveCodeBench โดยสิ้นเชิง
    ใน README ระบุชัดว่าคะแนน ATLAS เป็นผลจาก pipeline V3 (best-of-3 + Lens + iterative repair) บนงาน LCB 599 งาน
    แต่คะแนนของโมเดลคู่แข่งเป็นการรันครั้งเดียวแบบ pass@1 เลยทำให้ เปรียบเทียบไม่ยุติธรรม
    ถ้าทดสอบ Sonnet หรือ GPT5.4 ด้วยวิธีเดียวกัน คะแนนก็น่าจะสูงกว่านี้
    ใน README ยังมีโครงสร้างหลายอย่างที่ไม่ได้ใช้จริง ซึ่งเผยให้เห็น ความหยาบของโค้ดที่ AI สร้างอัตโนมัติ

  • สงสัยว่า benchmark แบบนี้จะใช้ได้แค่กับ การ optimize เฉพาะปัญหา หรือเปล่า
    สุดท้ายเราอาจได้เรียนรู้ถึง ข้อจำกัดที่ไม่สามารถบีบอัดความเป็นทั่วไปได้

  • คำว่า “Geometric Lens routing” ฟังดูประหลาดมาก
    เหมือนเป็นคำที่ GPT ประดิษฐ์ขึ้นมาเองเฉยๆ

  • ถึงจะยังสงสัยอยู่ แต่การทดลองกับ โมเดลโอเพน แบบนี้ก็น่ายินดีมาก
    ถ้ารันโมเดลในเครื่องได้แม้บน PC ระดับกลางค่อนไปสูง ก็ถือเป็นความก้าวหน้าครั้งใหญ่