AutoKernel: ระบบวิจัยเคอร์เนล GPU อัตโนมัติ

 (github.com/RightNow-AI)
9 คะแนน โดย GN⁺ 2026-03-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นำ Autoresearch ของ Karpathy มาประยุกต์ใช้กับการปรับแต่งเคอร์เนล GPU
  • เครื่องมือวิจัยเคอร์เนล GPU อัตโนมัติ ที่เมื่อป้อน โมเดล PyTorch เข้าไป จะทำการปรับแต่ง เคอร์เนล Triton หรือ CUDA C++ โดยอัตโนมัติ
  • มีไปป์ไลน์อัตโนมัติเต็มรูปแบบสำหรับ โปรไฟล์ ดึงออก ปรับแต่ง และตรวจสอบความถูกต้อง ของเคอร์เนลคอขวดในโมเดล
  • ใช้ การออร์เคสเตรตบนพื้นฐานของกฎของ Amdahl เพื่อจัดลำดับความสำคัญ โดยการทดลองแต่ละครั้งใช้เวลาประมาณ 90 วินาที จึงสามารถทำซ้ำได้หลายร้อยครั้งข้ามคืน
  • ผสานรวมกับ KernelBench เพื่อทำ การทดลองซ้ำ 50~300 ครั้ง กับโจทย์มากกว่า 250 รายการ ทำให้สำรวจได้อย่างเป็นระบบมากกว่าการสร้างแบบครั้งเดียว
  • รองรับ แบ็กเอนด์คู่ Triton และ CUDA C++, การตรวจสอบที่ให้ความถูกต้องมาก่อน, และ โครงสร้างแก้ไขไฟล์เดียว เพื่อช่วยให้การปรับแต่งเคอร์เนลมีประสิทธิภาพและทำซ้ำได้

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

  • AutoKernel รับโมเดล PyTorch เป็นอินพุตแล้วทำตามขั้นตอนต่อไปนี้
    • ระบุเคอร์เนลคอขวดของ GPU ด้วย การทำโปรไฟล์
    • ดึงออก และแยกเป็นเคอร์เนล Triton หรือ CUDA C++ แบบอิสระ
    • ทำซ้ำการแก้ไข เบนช์มาร์ก เก็บไว้หรือย้อนกลับ ผ่าน ลูปการปรับแต่งอัตโนมัติ
    • หลัง ตรวจสอบความถูกต้อง แล้วรายงานการเพิ่มขึ้นของความเร็วโดยรวม
  • ปรับแก้ kernel.py ตามคำแนะนำที่อยู่ใน program.md และใช้ bench.py ในการตรวจสอบความถูกต้อง 5 ขั้นตอนพร้อม การวิเคราะห์ roofline
  • การทดลองแต่ละครั้งใช้เวลาประมาณ 90 วินาที ทำได้ราว 40 ครั้งต่อชั่วโมง และประมาณ 320 ครั้งตลอดหนึ่งคืน

การรันและองค์ประกอบ

  • สภาพแวดล้อมที่จำเป็น: NVIDIA GPU(H100/A100/RTX 4090), Python 3.10+, แพ็กเกจ uv
  • องค์ประกอบสคริปต์หลัก
    • profile.py: จัดอันดับเคอร์เนลตามเวลา GPU
    • extract.py: ดึงเคอร์เนลคอขวดระดับบนออกมา
    • bench.py: เบนช์มาร์กความถูกต้องและประสิทธิภาพ 5 ขั้นตอน
    • orchestrate.py: การจัดตารางหลายเคอร์เนลบนพื้นฐานของกฎของ Amdahl
    • verify.py: ตรวจสอบทั้งโมเดลและรายงานการเพิ่มความเร็ว
  • program.md มีทั้งกลยุทธ์การปรับแต่ง 6 ขั้นตอน การจัดการความขัดแย้ง และกรอบการตัดสินใจ เพื่อให้รันอัตโนมัติระยะยาวได้

เคอร์เนลที่รองรับและโมเดลตัวอย่าง

  • รองรับ เคอร์เนล 9 ประเภท: matmul, softmax, layernorm, rmsnorm, flash_attention, fused_mlp, cross_entropy, rotary_embedding, reduce
  • แต่ละเคอร์เนลมีทั้งอิมพลีเมนต์อ้างอิงตาม PyTorch (reference.py) และเวอร์ชันเริ่มต้นของ Triton/CUDA (kernels/, kernels/cuda/)
  • โมเดลตัวอย่าง: GPT-2, LLaMA (รวม 7B), BERT-base, และโมเดลที่ผู้ใช้กำหนดเอง
  • โมเดลจาก HuggingFace ก็เชื่อมต่อได้ด้วย uv sync --extra models

การผสานรวมกับ KernelBench

  • ผสานรวมกับ KernelBench (Stanford Scaling Intelligence Lab) เพื่อทำเบนช์มาร์กมาตรฐานสำหรับเคอร์เนล GPU ที่สร้างโดย AI
  • AutoKernel สำรวจพื้นที่การปรับแต่งอย่างเป็นระบบด้วย การทดลองซ้ำ 50~300 ครั้ง ต่อโจทย์
  • เครื่องมือหลัก
    • bridge.py: โหลดโจทย์และสร้างเคอร์เนลเริ่มต้น
    • bench_kb.py: ประเมินความถูกต้องและประสิทธิภาพ
    • scorer.py: คำนวณคะแนนรวมทั้งระดับ
    • program_kb.md: คำแนะนำเอเจนต์สำหรับ KernelBench โดยเฉพาะ

การส่งออกไปยัง HuggingFace Hub

  • สามารถส่งออกเคอร์เนลที่ปรับแต่งแล้วไปยัง HuggingFace Hub และเรียกใช้ง่าย ๆ ด้วย get_kernel()
  • รองรับการส่งออกและอัปโหลดเคอร์เนล CUDA ด้วย export_hf.py

หลักการออกแบบ

  • แบ็กเอนด์คู่ Triton + CUDA C++: Triton เหมาะกับการวนซ้ำอย่างรวดเร็ว ส่วน CUDA ให้ประสิทธิภาพสูงสุด
  • ให้ความถูกต้องมาก่อน: หากผลลัพธ์ไม่ตรงกับ PyTorch จะย้อนกลับทันที
  • ใช้ การออร์เคสเตรตบนพื้นฐานของกฎของ Amdahl เพื่อกำหนดลำดับความสำคัญตามผลต่อประสิทธิภาพรวม
  • โครงสร้างแก้ไขไฟล์เดียว (kernel.py) ทำให้ติดตามและกู้คืนการเปลี่ยนแปลงได้ง่าย
  • ใช้ บันทึกแบบ TSV (results.tsv) เพื่อเก็บผลการทดลองให้อ่านง่ายและเรียบง่าย

รูปแบบการบันทึกผลลัพธ์

  • ใน results.tsv จะบันทึก หมายเลข ประเภทเคอร์เนล อัตราประมวลผล (TFLOPS) เวลาแฝง สัดส่วนเทียบกับ GPU สูงสุด การเพิ่มความเร็วเทียบกับ PyTorch ความถูกต้อง ปริมาณการใช้ VRAM และคำอธิบาย ของแต่ละการทดลอง

ที่มาของโปรเจกต์

  • ได้แรงบันดาลใจจากแนวคิด autoresearch ของ Andrej Karpathy โดยนำโครงสร้างเอเจนต์ AI อัตโนมัติสำหรับงานวิจัย LLM มาประยุกต์ใช้กับการปรับแต่งเคอร์เนล GPU
  • การผสานรวมกับ KernelBench อ้างอิงงานวิจัยของ Stanford Scaling Intelligence Lab และ AutoKernel ดำเนินการปรับแต่งแบบทำซ้ำแทนการสร้างเพียงครั้งเดียว
  • โปรเจกต์นี้พัฒนาโดย ทีม Forge ของ RightNow AI และเผยแพร่ภายใต้ MIT license

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

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

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

  • เป็นโปรเจ็กต์ที่เจ๋งมาก
    ช่วงไม่กี่สัปดาห์ที่ผ่านมา ผมก็ทำอะไรคล้าย ๆ กันอยู่เหมือนกัน แต่เป็นเวอร์ชันที่ ใช้งานได้ทั่วไปกว่ามากและออกแบบเกินความจำเป็น
    แนวทางที่โฟกัสแค่ Triton และเคอร์เนลเฉพาะทางแบบนี้ทั้งเรียบง่ายและมีประสิทธิภาพ
    แต่กราฟความคืบหน้าดูชวนสับสน มันเหมือนเป็นเบนช์มาร์ก 4096x4096x4096 fp16 matmul แต่บอกว่าดีขึ้น 1.31 เท่าเมื่อเทียบกับ cuBLAS ขณะเดียวกันกลับแสดงแค่ 187 TFLOPS หรือก็คือ ใช้ประสิทธิภาพสูงสุดได้เพียง 18.9%
    cuBLAS ทำผลงานได้ใกล้เคียงค่าสูงสุดมากกว่านี้มาก ดังนั้นน่าจะเป็นเพราะ CPU overhead หรือคอขวดอย่างอื่น
    การทำเบนช์มาร์กเป็นเรื่องยากจริง ๆ แต่ผมคิดว่าในอีก 6 เดือนข้างหน้า สาขานี้ มีอนาคตมาก

  • ถ้าสิ่งนี้ทำงานกับอะไรอย่าง llama.cpp ได้ น่าจะได้ประโยชน์มากกว่านี้อีกมาก
    เพราะมีทั้ง เคอร์เนลสำหรับ quantization และการจัดฮาร์ดแวร์ที่หลากหลาย รวมถึงมีผู้ใช้รายบุคคลจำนวนมากด้วย จึงน่าจะเพิ่มประสิทธิภาพได้มาก
    อยากให้โปรเจ็กต์นี้เข้าไปร่วมเป็นผู้มีส่วนร่วมตรงนั้น

    • เห็นด้วย
      ใน llama.cpp มี CUDA kernel ที่จูนด้วยมือ หลายแบบ เช่น Q4_K_M, Q5_K_S, Q8_0 และแต่ละแบบก็เล็งไปที่โปรไฟล์ฮาร์ดแวร์ต่างกัน
      ถ้าปรับให้เหมาะกับ GPU แต่ละรุ่นได้อัตโนมัติ มันจะเป็นการเปลี่ยนแปลงครั้งใหญ่
      ตอนนี้แม้จะเป็น quantization format เดียวกัน ประสิทธิภาพระหว่าง RTX 3090 กับ 5070 Ti ก็ยังต่างกันมาก
      สภาพแวดล้อมแบบ llama.cpp ที่มีความหลากหลายด้านฮาร์ดแวร์สูงนี่แหละ คือที่ที่ การค้นหาเคอร์เนลอัตโนมัติ จะฉายแสงได้มากที่สุด

  • เจ๋งมาก!
    ผมกำลังเพิ่มความสามารถแบบเดียวกันสำหรับ Apple Silicon อยู่
    ในโปรเจ็กต์ autoresearch-everywhere ของผม ผมกำลังทำ autoresearch ให้กลายเป็นเครื่องมือที่ใช้งานจริงจังได้

  • มันดูแปลก ๆ
    ถ้าดูจาก 4kx4kx4k fp16 GEMM แล้ว cutlass เร็วกว่าอยู่ประมาณ 3 เท่า

  • อยากรู้ว่าเคยทำเบนช์มาร์กเทียบกับระบบ auto-scheduling อย่าง Ansor ของ TVM ไหม

  • นี่เพิ่งเริ่มต้นเท่านั้น
    เอาเข้าจริง Google ก็ทำอะไรคล้ายกันมาตั้งแต่โมเดลรุ่นก่อนหน้านี้สองเจเนอเรชันแล้ว
    ในบล็อกโพสต์เดือนพฤษภาคม 2025 เรื่อง AlphaEvolve พวกเขาประกาศว่าได้เร่งความเร็วเคอร์เนลหลักของสถาปัตยกรรม Gemini ขึ้น 23% โดยใช้วิธีแบ่งการคูณเมทริกซ์ขนาดใหญ่ออกเป็น ปัญหาย่อยที่เล็กลง ทำให้เวลาฝึกลดลง 1%
    ตอนนี้เราเข้าสู่ยุคที่เทคโนโลยีแบบนี้ทำได้ “ที่บ้าน” แล้ว
    โดยเฉพาะเมื่อช่วงหลังมี การฝึกแบบอิง RL มากขึ้น การเพิ่มความเร็วในการอนุมานก็จะนำไปสู่การเพิ่มความเร็วในการฝึกด้วย

  • ผมสงสัยว่าวันไหนการปรับแต่งแบบนี้จะเข้าไปอยู่ใน โอเพนซอร์สภาษารันไทม์ อย่าง Swift หรือ Rust เพื่อรีดประสิทธิภาพออกมาให้ได้ถึงหยดสุดท้าย