AsmEvo: ให้เอเจนต์แก้ GPU kernel ที่ "ไม่มีซอร์สโค้ดแล้ว" — รื้อไบนารีที่คอมไพล์เสร็จ แก้แอสเซมบลี แล้วเร็วขึ้นเฉลี่ย 1.35 เท่าบน MI308X

งานปรับจูน GPU kernel ด้วย LLM ที่ผ่านมาทั้งหมดตั้งอยู่บนสมมติฐานเดียวกัน: คุณมีซอร์สโค้ด เครื่องมือที่มีอยู่ทำงานบน CUDA, Triton, HIP หรือ tensor program แล้ววัดความถูกต้องเทียบกับ reference implementation

เปเปอร์ AsmEvo: Agentic Assembly-Level Optimization of AMD GPU Kernels with Functional Equivalence Verification ที่ขึ้น arXiv เมื่อ 21 ส.ค. 2026 เลือกโจทย์ที่โหดกว่านั้น: คุณไม่มีซอร์สโค้ด มีแต่ไบนารีที่คอมไพล์เสร็จแล้ว และไบนารีตัวนั้นคือ oracle เดียวที่บอกได้ว่าอะไรถูก

ฟังดูเหมือนโจทย์เทียม แต่มันคือสถานการณ์จริงของงาน ML infra ทุกวันนี้ — kernel จำนวนมากในสแตกที่คุณรันอยู่ ไม่มีซอร์สที่แก้ได้ เพราะถูกเจนเนอเรตขึ้นมา, มาในรูปไลบรารีปิด, หรือซอร์สที่มีอยู่ห่างจากเครื่องจริงมากเกินกว่าจะเห็นว่ายังเหลืออะไรให้รีดได้

วิธีทำงาน: รื้อ ประกอบใหม่ แล้วห้ามเชื่อจนกว่าจะพิสูจน์

รับ AMDGPU code object K0 เข้ามาหนึ่งตัว AsmEvo ทำห้าขั้น:

1. กู้คืนให้ประกอบใหม่ได้ (code-object recovery) — แปลงไบนารีกลับเป็นรูปแบบที่ reassemble ได้จริง ไม่ใช่แค่ disassembly ไว้อ่าน
2. แก้ระดับล่างด้วยเอเจนต์ระยะยาว — ให้เอเจนต์เสนอการแก้ไขทีละจุด โดยชี้เป้าด้วย profiling ว่าเวลาไปหมดที่ช่วงไหน (hot-window editing) แทนที่จะไล่แก้ทั้งไฟล์
3. ประกอบกลับโดยรักษา ABI — สร้าง object ใหม่ที่ metadata และ ABI ยังตรงเดิม เพื่อให้เสียบแทนของเดิมได้โดยไม่ต้องแตะโค้ดรอบข้าง
4. ตรวจสอบแบบ differential — รัน candidate เทียบกับ K0 ภายใต้ launch configuration เดียวกัน แล้ว รับเฉพาะตัวที่ให้ผลลัพธ์ตรงกัน
5. จับเวลาหลังผ่านความถูกต้องเท่านั้น (correctness-gated timing) พร้อม fallback แบบ patch ทับที่เดิมอย่างระมัดระวังเมื่อการประกอบใหม่มีความเสี่ยง

ลำดับของขั้นที่ 4 กับ 5 คือหัวใจ และเป็นจุดที่แยกงานนี้ออกจากเดโม “AI เขียน kernel เร็วขึ้น 10 เท่า” ที่เราเห็นกันบ่อย ๆ — ความเร็วจะถูกวัดก็ต่อเมื่อผ่านความถูกต้องแล้ว ไม่ใช่วัดความเร็วก่อนแล้วค่อยหวังว่าจะถูก การกลับลำดับสองข้อนี้คือความต่างระหว่างตัวเลขที่เอาไปใช้ได้กับตัวเลขที่เอาไปขึ้นสไลด์

ตัวเลข

บน MI308X กับ KernelBench: ปรับปรุงได้ 29 จาก 30 kernel ที่เลือกมา ได้ speedup เฉลี่ยเชิงเรขาคณิต 1.35 เท่า และ สูงสุด 3.88 เท่า

บน MI300X กับเวิร์กโหลดโปรดักชัน ซึ่งเป็นส่วนที่น่าสนใจกว่ามาก:

เป้าหมาย	geomean	สูงสุด
ไบนารี AITer ทั้งหมดที่ทดสอบ	1.09×	1.31×
kernel แอสเซมบลีจาก Triton ที่ vLLM/SGLang ใช้	1.18×	1.34×
KernelBench (MI308X)	1.35×	3.88×

โดยรักษา functional equivalence ไว้ทุกกรณี

ตัวเลข 1.09× และ 1.18× ดูเล็กเมื่อเทียบกับ 3.88× แต่ผมคิดว่ามันคือตัวเลขที่มีความหมายที่สุดในเปเปอร์ทั้งฉบับ เพราะสองแถวบนคือ โค้ดที่วิศวกรมนุษย์ปรับจูนมาแล้ว และรันอยู่จริงในระบบเสิร์ฟโมเดลที่คนใช้กันทั่วโลก การรีด 9–18% ออกจากของที่ถูกจูนมาแล้ว ต่างจากการรีด 288% ออกจาก kernel ตัวอย่างในเบนช์มาร์กโดยสิ้นเชิง — อย่างหลังบอกว่าเบสไลน์ห่วย อย่างแรกบอกว่าเครื่องมือเก่ง

และในสเกลของฟลีต inference จริง 9% คือเงินก้อนใหญ่

ทำไม “ไม่มีซอร์สโค้ด” ถึงเป็นโจทย์ที่ถูกต้อง

จุดที่ทำให้ผมสนใจงานนี้คือมันยอมรับความจริงที่วงการมักหลบ: ระดับที่แก้ได้ กับระดับที่เร็วจริง ไม่ใช่ระดับเดียวกัน

เมื่อคุณเขียน Triton แล้วคอมไพเลอร์แปลงลงไปเป็นแอสเซมบลี สิ่งที่เกิดขึ้นระหว่างทางคือชุดการตัดสินใจของคอมไพเลอร์ที่คุณควบคุมได้แค่ทางอ้อม — จัดสรรรีจิสเตอร์, จัดตารางคำสั่ง, จังหวะการซ่อน latency ของหน่วยความจำ ถ้าคอมไพเลอร์ตัดสินใจพลาดในลูปที่ร้อนที่สุด คุณจะแก้จากชั้น Triton ไม่ถึง ต่อให้เขียนใหม่กี่รอบก็ตาม

AsmEvo ข้ามชั้นนั้นไปเลย และผลที่ได้บน kernel ของ vLLM/SGLang ก็คือหลักฐานว่า ยังมีของเหลือให้เก็บอยู่จริง ในโค้ดที่ทุกคนเชื่อว่าจูนสุดทางแล้ว

ข้อจำกัดที่ควรพูดตรง ๆ: งานนี้ผูกกับ AMDGPU code object โดยเฉพาะ ไม่ใช่เครื่องมือทั่วไปที่ย้ายไป NVIDIA ได้ทันที (SASS ของ NVIDIA เป็นสถาปัตยกรรมปิดกว่าและไม่มี toolchain ประกอบกลับที่เปิดเท่ากัน) และเปเปอร์ยังไม่ระบุว่าเป็นโอเพนซอร์สหรือไม่ ตัวเลขทั้งหมดมาจากผู้เขียน ยังไม่มีการทำซ้ำอิสระ

มุมมอง AI Curator

งานนี้น่าสนใจในฐานะ ตัวอย่างของงานที่เหมาะกับเอเจนต์อย่างแท้จริง มากกว่าในฐานะเครื่องมือ AMD

ลองดูรูปร่างของโจทย์: พื้นที่คำตอบใหญ่มหาศาล, มีฟังก์ชันประเมินที่เป็นกลไกล้วนและตรวจสอบได้ (ผลลัพธ์ตรงกับ K0 ไหม, เร็วขึ้นกี่ไมโครวินาที), ต้นทุนของคำตอบผิดเป็นศูนย์เพราะถูกกรองทิ้งอัตโนมัติ และมนุษย์ทำงานนี้ได้ช้าและเบื่อมาก นี่คือรูปทรงเดียวกับที่ AlphaTensor, AlphaDev และ NanoGPT speedrun ทำงานได้ดี — และเป็นคนละรูปทรงกับ “ให้เอเจนต์เขียนฟีเจอร์ใหม่ในโค้ดเบสองค์กร” ที่ยังล้มเหลวบ่อย เพราะโจทย์หลังไม่มี verifier ที่บอกได้ว่าถูกหรือผิด

บทเรียนที่ผมคิดว่าเอาไปใช้ได้ทันทีกับทีมทั่วไปคือขั้นที่ 4 และ 5: ถ้าคุณจะปล่อยเอเจนต์ทำงานยาว ๆ ให้ลงทุนสร้าง verifier ก่อนสร้างเอเจนต์ งานที่มีสวิตช์ผ่าน/ไม่ผ่านแบบกลไกล้วน (เทสต์, differential test, property test, การเทียบเอาต์พุตกับเวอร์ชันเดิม) คือที่ที่เอเจนต์ให้ผลตอบแทนสูงสุด ส่วนงานที่ต้องใช้รสนิยมมนุษย์ตัดสินว่า “ดีขึ้นไหม” คือที่ที่มันเผาโทเคนแล้วได้ของที่ต้องรีวิวหนักกว่าเดิม เปเปอร์นี้ไม่ได้บอกเรื่องนั้นตรง ๆ แต่โครงสร้างของมันบอกไว้ทั้งหมด

ในบริบทฮาร์ดแวร์ ผมคิดว่าจังหวะเวลาของงานนี้ไม่ใช่เรื่องบังเอิญ ปัญหาใหญ่ที่สุดของ AMD ไม่เคยเป็นซิลิคอน แต่เป็นซอฟต์แวร์ — ช่องว่างของ CUDA คือเหตุผลที่คนยอมจ่ายแพงกว่า ถ้าเครื่องมือแบบนี้เก็บ 10–18% ที่หายไปจากช่องว่างคอมไพเลอร์กลับมาได้แบบอัตโนมัติ มันคือการปิดช่องว่างด้วยเอเจนต์แทนที่จะรอให้ ROCm ตามทัน ซึ่งเป็นเส้นทางที่เร็วกว่ามาก

สำหรับไทยและ SEA ที่กำลังพูดเรื่อง sovereign AI และการสร้าง AI factory กันหลายโครงการ ประเด็นนี้ตรงกว่าที่คิด: ต้นทุนต่อโทเคนของคุณไม่ได้ถูกกำหนดโดยการ์ดที่คุณซื้อเท่านั้น แต่โดยว่าซอฟต์แวร์รีดการ์ดใบนั้นได้ดีแค่ไหน และในโลกที่การจัดหา GPU ระดับสูงยังถูกจำกัดด้วยเงื่อนไขการส่งออกและคิวส่งของ ความสามารถในการซื้อฮาร์ดแวร์ทางเลือกแล้วยังรีดประสิทธิภาพออกมาได้ คือความสามารถเชิงยุทธศาสตร์ ไม่ใช่แค่เรื่องเทคนิค งานแบบ AsmEvo ทำให้ตัวเลือกที่สองแพงน้อยลงหนึ่งขั้น

แหล่งข่าว

• AsmEvo: Agentic Assembly-Level Optimization of AMD GPU Kernels with Functional Equivalence Verification — arXiv:2608.20711, ส่ง 21 ส.ค. 2026
• KernelBench — เบนช์มาร์กที่ใช้วัดในเปเปอร์
• vLLM และ SGLang — เอ็นจิ้นเสิร์ฟที่ kernel ถูกนำมาทดสอบ