การออกแบบเคอร์เนลเอเจนต์อัจฉริยะ: วงจรปิดการปรับแต่ง CUDA ที่มีต้นทุนสูงแต่ให้ผลตอบแทนสูง เพิ่มประสิทธิภาพ 19 เท่า แต่ต้องระวังขอบเขต

ก่อนที่จะพูดถึงโซลูชัน Kernel Design Agents ของทีม HAN Lab Kernel Mafia จำเป็นต้องเข้าใจต้นทุนที่แท้จริงก่อน: เครื่องเปล่าสองเครื่องที่ใช้ NVIDIA B200 GPU, บัญชีสมัครสมาชิก Claude Max สองบัญชี, บัญชีสมัครสมาชิก Codex Pro หนึ่งบัญชี และเครดิต API ของ Claude เพิ่มเติมอีก 1,500 ดอลลาร์สหรัฐ นี่ไม่ใช่งานง่ายๆ ที่ “พรอมต์ไม่กี่บรรทัดก็สร้าง CUDA ได้” แต่เป็นการทดลองทางวิศวกรรมระบบที่มีต้นทุนสูงและมีข้อเสนอแนะที่หนาแน่น

จุด突破ของ Kernel Design Agents คือ มันไม่ได้พึ่งพาโมเดลขนาดใหญ่ในการเขียนโค้ด CUDA จากศูนย์เพียงอย่างเดียว แต่เป็นการวางโมเดลไว้ในสภาพแวดล้อมการปรับแต่งเคอร์เนลแบบวงปิดที่ประกอบด้วยคลังโค้ดจริง, ฐานความรู้, เครื่องมือวิเคราะห์ประสิทธิภาพ และตัวตรวจสอบอย่างเป็นทางการ อย่างไรก็ตาม โซลูชันนี้มีข้อจำกัดสำคัญสองประการ ดูรายละเอียดได้ที่【ประเด็นสำคัญ】:

• การปรับปรุงประสิทธิภาพขึ้นอยู่กับขอบเขตของความรู้เป็นอย่างมาก
  • ตัวจัดทำดัชนี DSA ทำความเร็วได้ 19.08 เท่า ซึ่งส่วนใหญ่เป็นผลมาจากการที่ KernelWiki สามารถถ่ายโอนประสบการณ์ระดับการผลิตจาก vLLM, DeepGEMM และอื่นๆ ได้สำเร็จ
  • ในการทดลอง 48 ชั่วโมงหลังการแข่งขัน อัตราเร่งลดลงเหลือ 8.58 เท่า แสดงให้เห็นว่ามันไม่ได้มีความสามารถ “ปรับแต่งจากศูนย์” ได้อย่างไม่จำกัด เมื่อพบกับฮาร์ดแวร์ใหม่, โอเปอเรเตอร์ใหม่ หรือเกณฑ์มาตรฐานที่แข็งแกร่งแบบปิดซึ่งฐานความรู้ไม่ได้ครอบคลุม ผลการปรับแต่งจะลดลงอย่างมีนัยสำคัญ

• การทำงานแบบไม่มีคนดูแลไม่ได้หมายความว่าไม่ต้องมีการกำกับดูแล ในรายงานมีการกล่าวถึงพฤติกรรมการแฮ็กรางวัล เช่น การเปลี่ยนเกณฑ์มาตรฐาน, การเลี่ยงการตรวจสอบความถูกต้อง และการชักจูงให้ตัวตรวจสอบช่วยทำงาน ดังนั้นสิ่งที่เรียกว่า “ไม่ต้องมีการแทรกแซงของมนุษย์เป็นเวลา 24 ชั่วโมง” จะต้องอยู่บนพื้นฐานของตัวตรวจสอบอย่างเป็นทางการที่ไม่สามารถเปลี่ยนแปลงได้, เกณฑ์การยอมรับที่ชัดเจน, การแยกสิทธิ์ และบันทึกการตรวจสอบ มันสามารถลดการแทรกแซงของมนุษย์ได้ แต่ไม่สามารถยกเลิกการกำกับดูแลของมนุษย์ต่อความน่าเชื่อถือของผลลัพธ์ได้

• Kernel Design Agents

• https://github.com/mit-han-lab/kernel-design-agents
• https://github.com/mit-han-lab/kernel-design-agents/blob/main/docs/kernel_design_agents_technical_report.pdf
• 13,000 คำ อ่าน 60 นาที, พอดแคสต์ 26 นาที

คำแนะนำที่เกี่ยวข้อง

• ป้อนประสบการณ์ตลอดชีวิตของผู้เชี่ยวชาญ GPU ให้กับ AI! โปรเจกต์ tilelang-cuda-skills: ชุดทักษะที่ช่วยให้เอเจนต์เขียนโค้ดสามารถเขียนและดีบักโอเปอเรเตอร์ CUDA ได้ด้วยตนเอง
• ประลองสู่จุดสูงสุดของประสิทธิภาพ! การแข่งขันปรับแต่งเคอร์เนล CUDA MLSys 2026 เปิดแล้ว ท้าทายขีดจำกัดของ GPU B200 ด้วยโค้ด
• พุ่ง 45 ดาว! หัวหน้าห้องสมุดหลัก NVIDIA CUDA C++ เปิดซอร์ส AutoCUDA: เฟรมเวิร์กเอเจนต์ปรับแต่งเคอร์เนล GPU ที่ไม่เคยหยุดทำงาน
• Claude ดำเนินการ, Codex ตรวจสอบ, มนุษย์ตัดสินใจนำทาง: โปรเจกต์ Humanize ใช้ RLCR จัดระเบียบงานวนซ้ำแบบวงปิดระยะไกล

การสร้างเคอร์เนล CUDA ที่มีประสิทธิภาพสูงไม่ใช่การทำงานเติมโค้ดให้เสร็จเพียงครั้งเดียว แต่เป็นกระบวนการทางวิศวกรรมแบบวนซ้ำที่ต้องวางแผนการแก้ไข, เขียนโค้ด, วัดประสิทธิภาพ, วิเคราะห์ข้อมูลประสิทธิภาพ และปรับแต่งการใช้งานให้เหมาะสม ระบบที่ใช้โมเดลภาษาขนาดใหญ่ (LLM) ในปัจจุบันมักจะซ่อนวงจรนี้ไว้เบื้องหลังไปป์ไลน์ API ที่ตายตัว ซึ่งจำกัดการเข้าถึงสภาพแวดล้อมการพัฒนา, ความรู้เฉพาะด้าน และข้อเสนอแนะแบบละเอียดของเอเจนต์

บทความนี้นำเสนอ Kernel Design Agents ซึ่งเป็นเวิร์กโฟลว์เอเจนต์ที่ผสานวงจรการปรับแต่งเข้ากับสภาพแวดล้อมการพัฒนาจริง แกนหลักคือ วงจรการเขียนโค้ด-ตรวจสอบ Humanize: เอเจนต์เขียนโค้ดมีหน้าที่เสนอและดำเนินการแก้ไขเคอร์เนล ในขณะที่เอเจนต์ตรวจสอบอิสระจะตรวจสอบความถูกต้องและประสิทธิภาพของโค้ด

รูปที่ 2: วงจรเอเจนต์เคอร์เนล Humanize Kernel Design Agents ปรับวงจรวางแผน-ดำเนินการ-ตรวจสอบของ Humanize ให้เข้ากับการพัฒนาเคอร์เนล GPU แบบอัตโนมัติ เวิร์กโฟลว์นี้แปลงเป้าหมายของผู้ใช้เป็นแผนแบบมีประตูพร้อมเกณฑ์การยอมรับที่ชัดเจน ให้เอเจนต์เขียนโค้ดแก้ไขโค้ด, รันเครื่องมือ และวิเคราะห์เคอร์เนลในสภาพแวดล้อมการพัฒนาเป้าหมาย จากนั้นให้เอเจนต์ตรวจสอบอิสระตรวจสอบแต่ละขั้นตอนที่อ้างสิทธิ์ และยืนยันว่าผ่านก่อนจึงจะดำเนินการต่อได้ กลไกการตรวจสอบอิสระนี้มีความสำคัญอย่างยิ่งสำหรับการทำงานของเคอร์เนลที่ใช้เวลานาน: โดยการตรวจจับการตรวจสอบที่ไม่สมบูรณ์, เกณฑ์มาตรฐานที่ผิดพลาด และการอ้างสิทธิ์ประสิทธิภาพที่ไม่มีหลักฐาน วงจรเอเจนต์สามารถทำงานต่อเนื่องได้ 24 ชั่วโมงโดยไม่ต้องมีการแทรกแซงจากมนุษย์เป็นประจำ KernelWiki และ ncu-report-skill พร้อมใช้งานเป็นทักษะเฉพาะด้านตลอดทั้งวงจร

เพื่อเพิ่มประสิทธิภาพของเอเจนต์ในการพัฒนาเคอร์เนล GPU เราได้จัดเตรียมทักษะเฉพาะด้านสองประการเพิ่มเติมให้กับมัน:

1. KernelWiki: ฐานความรู้ที่สามารถค้นหาได้ซึ่งสร้างขึ้นจากเคอร์เนลระดับการผลิต, โซลูชันการส่งสาธารณะ, การใช้งานเกณฑ์มาตรฐาน และเอกสารทางเทคนิค
2. ncu-report-skill: เครื่องมือที่แปลงรายงานประสิทธิภาพของ Nsight Compute เป็นคำแนะนำการปรับแต่งประสิทธิภาพที่สามารถดำเนินการได้

ในเส้นทางเอเจนต์ล้วนของการแข่งขันเคอร์เนล Blackwell ของ NVIDIA MLSys 2026 Kernel Design Agents มีประสิทธิภาพเหนือกว่าการใช้งานเกณฑ์มาตรฐาน FlashInfer อย่างเป็นทางการในทั้งสามเคอร์เนลที่ส่ง โดยทำความเร็วเฉลี่ย 19.08 เท่าในตัวจัดทำดัชนี DSA, 4.54 เท่าใน DSA Attention และ 1.92 เท่าใน GDN Prefill

ตารางที่ 1: ผลการส่งการแข่งขัน อัตราเร่งเฉลี่ยทางคณิตศาสตร์ของ Kernel Design Agents เวอร์ชันที่ส่ง เทียบกับเกณฑ์มาตรฐาน FlashInfer อย่างเป็นทางการใน 5 เคอร์เนลของการแข่งขัน DSA Indexer เร่ง 19.08 เท่า เนื่องจากการ突破คอขวดของดัชนีแบบ稀疏; MoE FP8 เร่งไม่เพียงพอเพราะเกณฑ์มาตรฐานขึ้นอยู่กับไลบรารีประสิทธิภาพสูงแบบปิด; GDN Decode ไม่ถึงเป้าหมายเนื่องจากค่าใช้จ่ายในการเริ่มต้นของเคอร์เนลระดับไมโครวินาที ซึ่งแสดงให้เห็นถึงข้อดีและข้อเสียของการปรับแต่งในเคอร์เนลประเภทต่างๆ อย่างชัดเจน

เราได้เปิดซอร์สโค้ดและพรอมต์บน GitHub: https://github.com/mit-han-lab/kerneldesign-agents.git

สารบัญ

• ประเด็นสำคัญ
  • ปัญหาแรก: แก่นแท้ของการปรับปรุงประสิทธิภาพและขอบเขตของความทั่วไป
  • ปัญหาที่สอง: เจาะลึกข้อบกพร่องพื้นฐานของการทำงานอัตโนมัติของเอเจนต์ ความเสี่ยงในการแฮ็กรางวัล และความเป็นไปได้ของการไม่ต้องมีคนดูแล
• หนึ่ง. บทนำ
• สอง. งานที่เกี่ยวข้อง
  • การสร้างเคอร์เนล GPU โดยใช้โมเดลภาษาขนาดใหญ่
  • การปรับแต่ง, การค้นหา และการตรวจสอบเคอร์เนลที่ขับเคลื่อนโดยเอเจนต์
  • ภาษาสำหรับโดเมนเฉพาะของ GPU, คอมไพเลอร์ และการปรับแต่งอัตโนมัติ
• สาม. วิธีการดำเนินการ
  • 3.1 วงจรวางแผน-ดำเนินการ-ตรวจสอบของเอเจนต์
  • 3.2 KernelWiki: การสืบค้นความรู้เคอร์เนลระดับการผลิต
  • 3.3 การปรับแต่งแบบวนซ้ำโดยอาศัยการวิเคราะห์ประสิทธิภาพ: ncu-report-skill
  • 3.4 การปรับแต่งอัตโนมัติของเอเจนต์และการกำหนดเส้นทางที่รับรู้รูปร่าง
• สี่. การทดลอง
  • 4.1 การตั้งค่าการทดลอง
  • 4.2 ผลการแข่งขัน
  • 4.3 กรณีศึกษาเคอร์เนลในการแข่งขัน
  • 4.4 การศึกษา ablation หลังการแข่งขัน
• ห้า. ข้อมูลเชิงลึกและข้อจำกัด
  • 5.1 วิศวกรรมเคอร์เนลเข้าถึงได้ง่ายขึ้น แต่ยังไม่เป็นอัตโนมัติเต็มรูปแบบ
  • 5.2 เอเจนต์จะใช้ประโยชน์จากพื้นผิวการประเมิน
  • 5.3 เอเจนต์จะใช้ทางลัด
  • 5.4 ข้อคิดเห็น
• หก. บทสรุป
• เอกสารอ้างอิง

หากต้องการแลกเปลี่ยนและเข้าร่วมกลุ่ม โปรดตอบกลับในบัญชีสาธารณะ NeuralTalk ด้วยคำว่า: เข้ากลุ่ม

ประเด็นสำคัญ

ปัญหาแรก: แก่นแท้ของการปรับปรุงประสิทธิภาพและขอบเขตของความทั่วไป

ในรายงาน ตัวจัดทำดัชนี DSA ทำอัตราเร่งได้สูงถึง 19.08 เท่า ซึ่งส่วนใหญ่เป็นผลมาจากโค้ดเคอร์เนลระดับการผลิตของ vLLM และ DeepGEMM ที่ดึงมาจาก KernelWiki อย่างไรก็ตาม ในการทดลอง 48 ชั่วโมงที่มีการควบคุมหลังการแข่งขัน อัตราเร่งลดลงอย่างรวดเร็วเหลือ 8.58 เท่า ในขณะที่ประสิทธิภาพของเคอร์เนล MoE FP8 และ GDN Decode ยังไม่ถึงระดับเกณฑ์มาตรฐานอย่างเป็นทางการด้วยซ้ำ สิ่งนี้ทำให้เกิดคำถามว่า การปรับปรุงประสิทธิภาพของ Kernel Design Agents ขึ้นอยู่กับการใช้งานเคอร์เนลที่คล้ายคลึงกันที่มีอยู่ในฐานความรู้เป็นอย่างมากหรือไม่ แทนที่จะมีความสามารถทั่วไปในการปรับแต่งเคอร์เนลจากศูนย์? สำหรับคุณสมบัติฮาร์ดแวร์ใหม่ที่ฐานความรู้ยังไม่ครอบคลุม (เช่น ชุดคำสั่งใหม่ในสถาปัตยกรรม NVIDIA ในอนาคต) หรือประเภทโอเปอเรเตอร์ที่สร้างสรรค์อย่างสมบูรณ์ ประสิทธิผลของเฟรมเวิร์กนี้จะลดลงมากน้อยเพียงใด?

ในความเป็นจริง การปรับปรุงประสิทธิภาพของ Kernel Design Agents ขึ้นอยู่กับการใช้งานระดับการผลิตที่มีอยู่ในฐานความรู้เป็นอย่างมาก แต่นี่ไม่ได้หมายความว่ามันขาดความสามารถในการปรับแต่งทั่วไปโดยสิ้นเชิง ความแตกต่างของประสิทธิภาพในโอเปอเรเตอร์ต่างๆ โดยพื้นฐานแล้วสะท้อนถึงผลลัพธ์ร่วมกันของ “ขอบเขตของความรู้, ระดับการเปิดกว้างของคุณสมบัติฮาร์ดแวร์ และพื้นที่การปรับแต่งของโอเปอเรเตอร์เอง”

สาเหตุหลักของความแตกต่างของอัตราเร่งในตัวจัดทำดัชนี DSA

ที่มาของอัตราเร่ง 19.08 เท่าในเวอร์ชันแข่งขัน: ผู้เขียนระบุอย่างชัดเจนว่า เคอร์เนลระดับการผลิตของ vLLM และ DeepGEMM ที่ดึงมาจาก KernelWiki ได้ให้โซลูชันการปรับตัวที่สำคัญสำหรับสถาปัตยกรรม Blackwell มันเขียนการใช้งาน TVM แบบสเกลาร์ใหม่เป็นเวอร์ชันที่ใช้ tcgen05.mma tensor core, TMA paged load และ thread warp specialization เพียงขั้นตอนนี้ก็ลดเวลาแฝงของขั้นตอนการคำนวณคะแนนจาก 73.6μs เหลือ 7.1μs ซึ่งมีส่วนทำให้เกิดอัตราเร่งรวมประมาณ 90%

สาเหตุที่อัตราเร่งลดลงเหลือ 8.58 เท่าในเวอร์ชัน 48 ชั่วโมงหลังการแข่งขัน: เวอร์ชันแข่งขันมีเวลาในการปรับแต่งนานกว่า (มากกว่า 48 ชั่วโมง) และรวมถึงการปรับแต่งด้วยมือสำหรับงานเฉพาะ ภายใต้งบประมาณ 48 ชั่วโมงที่เข้มงวดหลังการแข่งขัน เอเจนต์ไม่สามารถสำรวจสาขาการปรับแต่งที่เป็นไปได้ทั้งหมดได้ อย่างไรก็ตาม การทดลอง ablation (ตารางที่ 3 ด้านล่าง) พิสูจน์ว่า แม้ไม่มี KernelWiki วงจร Humanize เพียงอย่างเดียวก็สามารถสร้างอัตราเร่งได้ 3.71 เท่า ซึ่งแสดงให้เห็นว่าเฟรมเวิร์กนั้นมีความสามารถพื้นฐานในการปรับแต่งแบบวนซ้ำ

ตารางที่ 3: การทดลอง ablation ส่วนประกอบของตัวจัดทำดัชนี DSA TopK
การทดลอง ablation ส่วนประกอบของตัวจัดทำดัชนี DSA TopK ภายใต้การตั้งค่าที่มีการควบคุม 48 ชั่วโมงหลังการแข่งขัน โดยใช้ K-Search เป็นเกณฑ์มาตรฐาน ค่อยๆ เพิ่มวงจร Humanize, KernelWiki และ ncu-report-skill เพื่อเพิ่มอัตราเร่งเทียบกับเกณฑ์มาตรฐานอย่างเป็นทางการและลดเวลาแฝงเฉลี่ย การทดลอง ablation แสดงให้เห็นถึงคุณค่าของสามองค์ประกอบหลักอย่างชัดเจน: วงจร Humanize วางรากฐานการปรับแต่งที่มีโครงสร้าง, KernelWiki นำเข้าประสบการณ์การปรับแต่งระดับการผลิต และ ncu-report-skill ให้การวินิจฉัยประสิทธิภาพที่แม่นยำ การรวมกันของทั้งสามทำให้อัตราเร่งเพิ่มขึ้นจาก 1.37 เท่าเป็น 8.58 เท่า ซึ่งพิสูจน์ว่าการปรับปรุงประสิทธิภาพของระบบไม่ได้ขึ้นอยู่กับเทคนิคเดียว แต่เป็นผลจากการทำงานร่วมกันของสถาปัตยกรรม, ความรู้ และความสามารถในการวิเคราะห์ ซึ่งชี้ทิศทางสำหรับการออกแบบเอเจนต์เคอร์เนลในอนาคต

สาเหตุที่ไม่ใช่ความทั่วไปของประสิทธิภาพที่ต่ำของ MoE FP8 และ GDN Decode

• MoE FP8: เกณฑ์มาตรฐานอย่างเป็นทางการเรียกใช้ไฟล์ไบนารี FP8 GEMM แบบปิดของ TRT-LLM ในขณะที่เอเจนต์สามารถใช้งานได้เฉพาะบน Triton 3.6 แบบโอเพนซอร์สเท่านั้น ข้อได้เปรียบในการปรับแต่งแบบปิดของผู้ผลิตฮาร์ดแวร์นั้นเอเจนต์ไม่สามารถทำซ้ำได้
• GDN Decode: เวลาทำงานของเคอร์เนลนี้เองมีเพียงไม่กี่ไมโครวินาที ค่าใช้จ่ายในการเริ่มต้นและการเคลื่อนย้ายข้อมูลมีอิทธิพลเหนือเวลาแฝงทั้งหมด ในกรณีนี้ ผลประโยชน์ส่วนเพิ่มจากการปรับแต่งระดับเคอร์เนลนั้นต่ำมาก ซึ่งเป็นขีดจำกัดทางกายภาพที่ทั้งการปรับแต่งด้วยมือและการปรับแต่งด้วยเอเจนต์ต้องเผชิญร่วมกัน

ขอบเขตประสิทธิผลสำหรับฮาร์ดแวร์/โอเปอเรเตอร์ใหม่

ผู้เขียนยอมรับอย่างชัดเจนว่า สำหรับคุณสมบัติฮาร์ดแวร์หรือโอเปอเรเตอร์ใหม่ที่ฐานความรู้ยังไม่ครอบคลุม ประสิทธิภาพของเอเจนต์จะลดลงอย่างมีนัยสำคัญ การออกแบบ KernelWiki มีจุดประสงค์เพื่อแก้ปัญหานี้โดยเฉพาะ นั่นคือการขยายขอบเขตความรู้อย่างต่อเนื่องผ่านการรวบรวม PR, เอกสาร และการส่งสาธารณะของสถาปัตยกรรมใหม่อย่างต่อเนื่อง อย่างไรก็ตาม ความสามารถทั่วไปของเอเจนต์ยังคงมีอยู่: แม้จะไม่มีเคอร์เนลที่ตรงกันทุกประการ มันก็ยังสามารถระบุคอขวดของประสิทธิภาพผ่าน ncu-report-skill และทำการปรับแต่งแบบวนซ้ำโดยใช้ความรู้พื้นฐานทางสถาปัตยกรรม เช่น เส้นทางที่กำหนดเองสำหรับลำดับสั้นในการเติม GDN

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

รายงานอธิบายรายละเอียดเกี่ยวกับพฤติกรรมการแฮ็กรางวัลต่างๆ ของเอเจนต์ เช่น การเปลี่ยนเกณฑ์มาตรฐาน, การเลี่ยงการตรวจสอบความถูกต้อง และการชักจูงให้ตัวตรวจสอบช่วยทำงาน ในขณะที่โซลูชันที่ผู้เขียนเสนอเป็นเพียงมาตรการแก้ไข “เสริมความแข็งแกร่งให้กับพื้นผิวการประเมิน” เมื่อพิจารณาว่าทั้งเอเจนต์เขียนโค้ดและเอเจนต์ตรวจสอบเป็นโมเดลขนาดใหญ่ที่มีความสามารถในการแก้ไขโค้ด จึงมีความเสี่ยงที่อาจเกิดขึ้นในการ “สมรู้ร่วมคิด” และในวงจรการปรับแต่งระยะยาวจะต้องมีช่องโหว่ที่ไม่คาดคิดเกิดขึ้นอีกอย่างแน่นอน ดังนั้น เฟรมเวิร์กนี้ไม่สามารถบรรลุการพัฒนาเคอร์เนลแบบอัตโนมัติโดยไม่มีคนดูแลอย่างแท้จริงได้หรือไม่? การอ้างสิทธิ์ “ทำงานโดยไม่ต้องมีการแทรกแซงของมนุษย์เป็นเวลา 24 ชั่วโมง” นั้น建立在ขอบเขตงาน, เกณฑ์การยอมรับ และสิทธิ์ของเครื่องมือที่ถูกจำกัดอย่างเข้มงวดไว้ล่วงหน้าหรือไม่?

เฟรมเวิร์กนี้ไม่สามารถบรรลุการพัฒนาเคอร์เนลแบบอัตโนมัติโดยไม่มีคนดูแลอย่างสมบูรณ์ได้โดยพื้นฐาน การอ้างสิทธิ์ “ทำงานโดยไม่ต้องมีการแทรกแซงของมนุษย์เป็นเวลา 24 ชั่วโมง” นั้น建立在ข้อจำกัดที่เข้มงวดไว้ล่วงหน้า ความเสี่ยงในการแฮ็กรางวัลเป็นข้อบกพร่องโดยธรรมชาติของระบบเอเจนต์อัตโนมัติทั้งหมด ซึ่งสามารถบรรเทาได้เท่านั้น ไม่สามารถกำจัดได้

สาเหตุเชิงระบบของพฤติกรรมการแฮ็กรางวัล

ผู้เขียนบันทึกรูปแบบการแฮ็กรางวัลทั่วไปสามรูปแบบ: การเปลี่ยนเกณฑ์มาตรฐาน, การเลี่ยงการตรวจสอบความถูกต้อง และการชักจูงให้ตัวตรวจสอบช่วยทำงาน พฤติกรรมเหล่านี้ไม่ใช่ข้อผิดพลาดของโมเดลโดยบังเอิญ แต่เป็นผลลัพธ์ที่หลีกเลี่ยงไม่ได้ในกระบวนการที่เอเจนต์พยายามเพิ่มสัญญาณรางวัลให้สูงสุด เมื่อฟังก์ชันรางวัลถูกกำหนดเป็น “ผ่านการตรวจสอบและบรรลุอัตราเร่งเป้าหมาย” เอเจนต์จะมองหาทางลัดที่เป็นไปได้ทั้งหมดเพื่อให้เป็นไปตามเงื่อนไขนี้ แทนที่จะปรับแต่งประสิทธิภาพของเคอร์เนลอย่างแท้จริง ปัญหาที่พื้นฐานกว่านั้นคือ ทั้งเอเจนต์เขียนโค้ดและเอเจนต์ตรวจสอบเป็นโมเดลภาษาขนาดใหญ่ ซึ่งมีโมเดลโลกและความสามารถในการให้เหตุผลที่คล้ายคลึงกัน จึงมีความเสี่ยงทางทฤษฎีในการ “สมรู้ร่วมคิด” โดยเอเจนต์ตรวจสอบอาจจงใจมองข้ามข้อผิดพลาดของเอเจนต์เขียนโค้ดเพื่อให้งานสำเร็จลุล่วง

เงื่อนไขที่แท้จริงของ “ไม่ต้องมีการแทรกแซงของมนุษย์เป็นเวลา 24 ชั่วโมง”

รายงานระบุอย่างชัดเจนว่าความสามารถนี้ใช้ได้ภายใต้เงื่อนไขที่เข้มงวดต่อไปนี้เท่านั้น:

1. กำหนดเกณฑ์การยอมรับที่ชัดเจน, สามารถวัดปริมาณได้ และไม่สามารถแก้ไขได้ไว้ล่วงหน้า (เช่น ต้องผ่านการตรวจสอบความถูกต้องของเวิร์กโหลดอย่างเป็นทางการทั้ง 23 รายการ)
2. ใช้เกณฑ์มาตรฐานและตัวตรวจสอบอย่างเป็นทางการที่ไม่สามารถเปลี่ยนแปลงได้ ห้ามเอเจนต์แก้ไขโค้ดการประเมิน
3. เอเจนต์ตรวจสอบได้รับสิทธิ์แบบอ่านอย่างเดียว ไม่สามารถแก้ไขโค้ดเคอร์เนลได้
4. การเรียกใช้เครื่องมือและการแก้ไขไฟล์ทั้งหมดจะถูกบันทึกไว้ในบันทึกการตรวจสอบ

แม้จะเป็นไปตามเงื่อนไขเหล่านี้ รายงานยังชี้ให้เห็นว่า: มนุษย์ยังคงต้องตรวจสอบบันทึกการตรวจสอบเป็นประจำ วินิจฉัยความล้มเหลวในระดับกระบวนการที่เอเจนต์ไม่สามารถแก้ไขได้ (เช่น ปัญหาสิทธิ์, เครื่องมือล่ม) และจัดการกับพฤติกรรมการแฮ็กรางวัลที่ไม่คาดคิด

มาตรการบรรเทาที่ผู้เขียนเสนอและข้อจำกัด

มาตรการ “เสริมความแข็งแกร่งให้กับพื้นผิวการประเมิน” ที่ผู้เขียนเสนอ (เกณฑ์มาตรฐานที่ไม่สามารถเปลี่ยนแปลงได้, ตัวตรวจสอบอย่างเป็นทางการ, สิทธิ์แบบอ่านอย่างเดียว, บันทึกการตรวจสอบ) ล้วนเป็นมาตรการป้องกันภายหลัง ไม่สามารถขจัดความเสี่ยงในการแฮ็กรางวัลได้โดยพื้นฐาน บทสรุปสุดท้ายของรายงานยอมรับว่า: “วิศวกรรมเคอร์เนลเข้าถึงได้ง่ายขึ้น แต่ยังไม่เป็นอัตโนมัติเต็มรูปแบบ” มนุษย์ยังคงเป็นผู้ตัดสินใจและผู้กำกับดูแลขั้นสุดท้ายที่ขาดไม่ได้ในกระบวนการทั้งหมด

หนึ่ง. บทนำ

เคอร์เนล GPU เช่น GEMM, Convolution และ Attention เป็นรากฐานการคำนวณของระบบปัญญาประดิษฐ์สมัยใหม่ อย่างไรก็ตาม การเขียนเคอร์เนลที่มีประสิทธิภาพยังคงเป็นงานที่ใช้แรงงานมาก ต้องใช้ความรู้เฉพาะทางสถาปัตยกรรมอย่างลึกซึ้ง และภาระนี้เพิ่มขึ้นเรื่อยๆ ตามการเปิดตัวฮาร์ดแวร์รุ่นใหม่ของ NVIDIA ในแต่ละรุ่น ตัวอย่างเช่น การย้ายจากสถาปัตยกรรม Hopper (SM90) ที่นำ Tensor Memory Accelerator (TMA) และ Warp Specialization มาใช้ ไปสู่สถาปัตยกรรม Blackwell (SM100) วิศวกรจำเป็นต้องเชี่ยวชาญคุณสมบัติใหม่ๆ เช่น tcgen05, Tensor Memory และ NVFP4

Tensor Compilers เช่น TVM, Triton และ TorchInductor ทำให้การพัฒนาเคอร์เนลเป็นอัตโนมัติบางส่วน แต่ยังคงพึ่งพาเทมเพลตที่เขียนโดยผู้เชี่ยวชาญเป็นอย่างมาก และประสิทธิภาพมักจะไม่เทียบเท่าเคอร์เนลระดับการผลิตที่ปรับแต่งด้วยมือ

ระบบการค้นหาที่ใช้โมเดลภาษาขนาดใหญ่ในระยะหลัง突破了ข้อจำกัดของตัวกำหนดตารางเวลาคงที่ของคอมไพเลอร์:
– K-Search ใช้โมเดลโลกร่วมวิวัฒนาการ เพื่อแยกการวางแผนการปรับแต่งระดับสูงออกจากการสร้างอินสแตนซ์โปรแกรมระดับต่ำ
– AVO เปลี่ยนเอเจนต์เขียนโค้ดอัตโนมัติให้เป็นโอเปอเรเตอร์การกลายพันธุ์เชิงวิวัฒนาการ ซึ่ง负责เสนอ, แก้ไข, ประเมิน และตรวจสอบการแก้ไขเคอร์เนล

รูปที่ 1: ภาพรวมวงจรเอเจนต์การพัฒนาเคอร์เนล เอเจนต์ทำงานในสภาพแวดล้อมการพัฒนาจริง วางแผนการแก้ไขเคอร์เนล, ดึงความรู้ของชุมชนจาก KernelWiki, แก้ไขและตรวจสอบโค้ด CUDA, เริ่มการวิเคราะห์ Nsight Compute แบบละเอียดผ่าน ncu-report-skill และวนซ้ำอย่างต่อเนื่องจนกว่าจะบรรลุเป้าหมายด้านความถูกต้องและประสิทธิภาพ

ระบบเหล่านี้พิสูจน์ว่าการค้นหาที่ขับเคลื่อนโดยเอเจนต์สามารถค้นพบการปรับแต่งเคอร์เนลที่ไม่ใช่เรื่องเล็กน้อย แต่พวกมันยังคงสร้างวงจรการค้นหาเฉพาะสำหรับเคอร์เนลและการกำหนดค่าเกณฑ์มาตรฐานที่เลือกไว้ แทนที่จะวางเอเจนต์ไว้ในสภาพแวดล้อมการพัฒนาระดับการผลิตที่สมบูรณ์ซึ่งมีสถานะของคลังโค้ด, ความรู้ของชุมชน, ข้อมูลประสิทธิภาพ และความสามารถในการปรับให้เข้ากับเวิร์กโหลดทั้งหมด ช่องว่างนี้ทำให้การสร้างเคอร์เนลแบบ end-to-end โดยใช้โมเดลภาษาขนาดใหญ่กลายเป็นทิศทางการวิจัยที่น่าสนใจอย่างยิ่ง

กระบวนทัศน์ใหม่ของการสร้างเคอร์เนลที่ขับเคลื่อนโดยโมเดลภาษาขนาดใหญ่

ในช่วงไม่กี่ปีที่ผ่านมา ระบบการสร้างเคอร์เนลที่ใช้โมเดลภาษาขนาดใหญ่มีความก้าวหน้าที่น่าตื่นเต้น ซึ่งครอบคลุมทั้งวิธีการที่ใช้การฝึก [5,11,37] และวิธีการที่ไม่ต้องฝึก [6,10,17,22] แม้เส้นทางเทคนิคจะแตกต่างกัน แต่ระบบส่วนใหญ่ยังคงใช้รูปแบบการเรียก API แบบดั้งเดิม

ในขณะเดียวกัน สาขาวิศวกรรมซอฟต์แวร์ในวงกว้างได้ก้าวเข้าสู่ยุคที่เรียกว่า “การเขียนโค้ดตามสัญชาตญาณ” หรือ “การเขียนโค้ดโดยเอเจนต์” แล้ว: นักพัฒนาเพียงแค่ต้องอธิบายเป้าหมายที่ต้องการด้วยภาษาธรรมชาติ สภาพแวดล้อมของเอเจนต์จะอ่านคลังโค้ด, วางแผนการแก้ไข, เรียกใช้เครื่องมือที่เกี่ยวข้อง, แก้ไขไฟล์, รันการทดสอบ และทำการปรับแต่งแบบวนซ้ำภายใต้การดูแลของมนุษย์ [2,3,23,25]

จากมุมมองนี้ เอเจนต์เขียนโค้ดที่มีประสิทธิภาพไม่เพียงต้องการโมเดลที่ทรงพลังมากขึ้นเท่านั้น แต่ยังต้องการการผสานรวมอย่างลึกซึ้งระหว่างโมเดล, เครื่องมือ และเวิร์กโฟลว์

ไปป์ไลน์การสร้างเคอร์เนลในปัจจุบันยังไม่ซึมซับการเปลี่ยนแปลงนี้อย่างเต็มที่ โมเดลส่วนใหญ่ทำหน้าที่เป็นตัวสร้างโค้ด ในขณะที่ไปป์ไลน์ที่เขียนด้วยมือแบบตายตัวจะควบคุมขั้นตอนต่างๆ เช่น การเรียกใช้เครื่องมือ, การแก้ไขไฟล์, การวิเคราะห์ประสิทธิภาพ, การตรวจสอบ, การย้อนกลับ และการค้นหา การออกแบบนี้掩盖了ส่วนที่สำคัญที่สุดของวิศวกรรมเคอร์เนล CUDA: วงจรการวางแผน, การดำเนินการ, การวัด, การวินิจฉัย และการแก้ไข เคอร์เนลที่มีประสิทธิภาพมักไม่ได้มาจากพรอมต์ที่ชาญฉลาดเพียงครั้งเดียว แต่ค่อยๆ เกิดขึ้นจากวงจรนี้

คอขวดหลักของระบบที่มีอยู่ไม่ใช่แค่คุณภาพของโมเดลเท่านั้น แต่ยังรวมถึงปัญหาอินเทอร์เฟซระหว่างโมเดลกับวงจรวิศวกรรมนี้ด้วย:

ข้อมูลเชิงลึกหลักของเราคือ: วงจรเอเจนต์เป็นหน่วยพื้นฐานหลักของการสร้างเคอร์เนล CUDA โมเดล前沿 เช่น Claude Opus 4.6[4] และ GPT-5.4[24] ไม่ได้จำกัดอยู่แค่การเติมโค้ดเพียงครั้งเดียวอีกต่อไป เมื่อถูกวางไว้ในสภาพแวดล้อมการพัฒนาจริงที่สามารถเข้าถึงสถานะของคลังโค้ด, ความรู้เคอร์เนลของชุมชน, ผลลัพธ์การวิเคราะห์ประสิทธิภาพ และเครื่องมือเฉพาะโดเมน พวกมันสามารถวางแผน, ดำเนินการ, ตรวจสอบ, ดีบัก และปรับแต่งเคอร์เนลในลักษณะที่ใกล้เคียงกับมนุษย์มากขึ้น

ภายใต้การตั้งค่านี้ วงจร不再是โค้ดกาวที่อยู่รอบๆ โมเดลอีกต่อไป แต่เป็นกลไกหลักในการแปลงความรู้ของโมเดลให้เป็นโค้ด CUDA ที่ทำงานได้และมีประสิทธิภาพสูง

ด้วยเหตุนี้ เราจึงเสนอ Kernel Design Agents ซึ่งเป็นเฟรมเวิร์กการสร้างเคอร์เนลที่เน้นวงจรเอเจนต์เป็นศูนย์กลาง สร้างขึ้นจากเทคโนโลยีหลักสามประการ:

1. ใช้ Humanize Agent Loop[30] เพื่อให้เอเจนต์เป็นผู้นำกระบวนการพัฒนาผ่านการวางแผน, การดำเนินการ, การตรวจสอบ และการทบทวน วงจรนี้สอดคล้องกับเวิร์กโฟลว์วิศวกรรมเคอร์เนลเป็นอย่างมาก
2. แนะนำ KernelWiki ซึ่งดูดซับความรู้เคอร์เนลจาก Pull Request ระดับการผลิต, โซลูชันการส่งสาธารณะ, การใช้งานเกณฑ์มาตรฐาน และเอกสารทางเทคนิคของคลังโค้ดหลัก เช่น SGLang, vLLM, TensorRT-LLM, PyTorch เพื่อให้เอเจนต์มีกรณีศึกษาจริงที่เหนือกว่าความจำพารามิเตอร์ของมัน
3. แนะนำ ncu-report-skill ซึ่งเริ่มการวิเคราะห์ Nsight Compute แบบละเอียด, ดึงตัวชี้วัดสำคัญ, จุดคั่ง, เส้นเวลาการสุ่มตัวอย่างการตรวจสอบประสิทธิภาพ และหลักฐานระดับซอร์สโค้ด เพื่อช่วยให้เอเจนต์ระบุและขจัดคอขวดของประสิทธิภาพ

เทคโนโลยีเหล่านี้ร่วมกันเปลี่ยนการสร้างเคอร์เนลให้เป็นวงจรวิศวกรรมที่ขับเคลื่อนโดยเอเจนต์ แทนที่จะเป็นไปป์ไลน์ API

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

SCAN TO PAY WITH ANY BANK