กลยุทธ์การเพิ่มประสิทธิภาพ AI โดยไม่ต้องง้อ GPU

การรันโมเดล AI โดยไม่ต้องพึ่ง GPU: พลังที่ซ่อนอยู่ของการเพิ่มประสิทธิภาพซอฟต์แวร์

คำกล่าวที่ว่า 'จะทำ AI ต้องซื้อ H100' อาจถูกต้องเพียงครึ่งเดียว

หากทีมของคุณกำลังกังวลเรื่อง การเพิ่มประสิทธิภาพ AI (AI Optimization) คุณคงเคยตั้งคำถามว่า "รัน AI โดยไม่ต้องใช้ GPU ได้หรือไม่?" ซึ่งเป็นคำถามที่ทีมของเราพบเจอบ่อยที่สุดในการทำงานจริงด้านการส่งออก แม้ราคาของ NVIDIA H100 จะสูงกว่า 30,000,000 วอนต่อเหรียญ และค่าบริการ Cloud GPU อาจทำให้งบประมาณรั่วไหลได้ง่ายๆ แต่สิ่งที่เราพบจากการตรวจสอบโค้ดเบสจริงกลับต่างออกไป

วิศวกรกำลังตรวจสอบผลลัพธ์จากโปรไฟล์เลอร์โค้ดบนหน้าจอโน้ตบุ๊ก

คอขวดส่วนใหญ่ไม่ได้อยู่ที่ฮาร์ดแวร์ แต่อยู่ที่ระดับ การเพิ่มประสิทธิภาพซอฟต์แวร์ (Software Optimization) โดยเฉพาะวิธีการคำนวณเมทริกซ์ ความแตกต่างระหว่างการคำนวณแบบ Python loop ธรรมดากับการใช้ BLAS ที่ปรับแต่งมาเพื่อแคชนั้นต่างกันมากถึงหลายสิบหรือหลายร้อยเท่าบน CPU ตัวเดียวกัน เราจะมาเจาะลึกกันว่าเหตุใดการเพิ่มประสิทธิภาพในระดับซอฟต์แวร์จึงสามารถสร้างความเปลี่ยนแปลงได้อย่างมหาศาลโดยไม่ต้องเปลี่ยนฮาร์ดแวร์

จุดเริ่มต้นของการเพิ่มประสิทธิภาพการอนุมาน (Inference) LLM: เข้าใจคอขวดให้ถูกต้อง

GEMM คืออะไร? ส่วนประกอบสำคัญของการคำนวณ Transformer

โมเดลภาษาขนาดใหญ่ (LLM) อย่าง ChatGPT, Claude และ Gemini ใช้สถาปัตยกรรม Transformer ซึ่งชั้น Attention และ FFN (Feed-Forward Network) ทั้งหมดสรุปรวมอยู่ที่การคูณเมทริกซ์ หรือ GEMM (General Matrix Multiply) มีการยืนยันจากการวิจัยด้านการประมวลผล Deep Learning หลายฉบับแล้วว่า 60-80% ของการคำนวณคือ GEMM ดังนั้น ประสิทธิภาพในการทำ GEMM จึงเป็นตัวกำหนดความเร็วในการอนุมานและเรียนรู้ของ AI ทั้งระบบ

หลักการเพิ่มประสิทธิภาพ: ทำไม Cache Miss ถึงทำให้การลงทุน GPU หลักล้านกลายเป็นเรื่องเสียเปล่า

หัวใจสำคัญของการเพิ่มประสิทธิภาพซอฟต์แวร์ระดับต่ำมี 3 ประการ:

① Cache Locality: ทั้ง CPU และ GPU มีลำดับชั้นของหน่วยความจำ การเข้าถึงข้อมูลจาก L1 Cache เร็วกว่า DRAM หลายสิบเท่า หากรูปแบบการเข้าถึงข้อมูลไม่เป็นมิตรกับแคช ฮาร์ดแวร์ที่ทรงพลังที่สุดก็จะเสียเวลาส่วนใหญ่ไปกับการรอข้อมูล

② SIMD (Single Instruction Multiple Data): การใช้คำสั่งเดียวประมวลผลข้อมูลหลายชุดพร้อมกัน เช่น Intel AVX2 รองรับการประมวลผล 256 บิต (8 ค่า FP32) ต่อรอบ หากใช้ให้เต็มประสิทธิภาพ ข้อมูลที่ประมวลผลได้จะเพิ่มขึ้น 8 เท่า

③ Blocking (Tiling): เทคนิคแบ่งเมทริกซ์ขนาดใหญ่เป็นส่วนย่อยๆ ที่พอดีกับแคช เพื่อใช้ประโยชน์จากการอ่านข้อมูลซ้ำให้ได้มากที่สุด แทนการอ่านจากหน่วยความจำหลักทั้งหมด ไลบรารีอย่าง OpenBLAS หรือ oneDNN คือเครื่องมือที่นำหลักการนี้มาปรับจูนมานานหลายปี

วาดภาพไดอะแกรมการแบ่งบล็อกเมทริกซ์บนไวท์บอร์ด

ฝึกสอน LLM ด้วย Swift? การทดลองเปลี่ยนมุมมองที่พิสูจน์บทเรียนสำคัญ

การทำลายความเชื่อที่ว่า 'AI = Python'

ปัจจุบันในชุมชนนักพัฒนามีการทดลองที่น่าสนใจ เช่น llm.c ของ Andrej Karpathy ที่สร้าง GPT-2 ด้วยภาษา C หรือการใช้ Swift เพื่อวัดประสิทธิภาพการคูณเมทริกซ์ คำถามสำคัญคือ: หากเปลี่ยนภาษาหรือเฟรมเวิร์ก แต่ใช้หลักการเพิ่มประสิทธิภาพระดับต่ำอย่างถูกต้อง ผลลัพธ์จะเป็นอย่างไร?

จาก Gflop/s สู่ Tflop/s: อานุภาพของการปรับจูนระดับต่ำ

จากผลการทดลองการคูณเมทริกซ์ด้วย Swift ที่ปรับจูนจนมีประสิทธิภาพเพิ่มขึ้นอย่างก้าวกระโดดเมื่อเทียบกับโค้ดแบบ Naive (Loop ซ้อน Loop) สรุปตารางเปรียบเทียบในสภาพแวดล้อม Python + NumPy ได้ดังนี้:

ขั้นตอนการปรับจูน	วิธีการ	ประสิทธิภาพสัมพัทธ์ (เทียบกับ naive)
naive	Python ลูปซ้อนกัน	1× (ฐาน)
ปรับ Cache Locality	คำนวณหลังทำ Transpose	~10×
ใช้ BLAS	NumPy dot (ผ่าน OpenBLAS)	~200×
Mixed Precision	คำนวณหลังแปลงเป็น FP16	~250×

สิ่งที่สำคัญยิ่งกว่าตัวเลขคือ ลำดับขั้นตอนการเพิ่มประสิทธิภาพ การเปลี่ยนแปลงในระดับโค้ดสามารถสร้างความแตกต่างนี้ได้โดยไม่ต้องซื้อฮาร์ดแวร์ใหม่

สิ่งที่ต้องระวังก่อนเชื่อตัวเลขเบนช์มาร์ก

เราต้องยอมรับว่าตัวเลขการทดลอง Swift ใน Apple Silicon นั้นได้อานิสงส์จากหน่วย AMX และ Metal ในชิป M1/M2/M3 เข้ามาด้วย นอกจากนี้ การคูณเมทริกซ์เดี่ยวๆ กับการฝึกสอน LLM ทั้งระบบ (ที่รวม Backpropagation, Optimizer, Pipeline) นั้นไม่เหมือนกัน ดังนั้นการทดลองนี้จึงเป็นเครื่องยืนยันว่า การเข้าใจหลักการเพิ่มประสิทธิภาพระดับต่ำสำคัญกว่าการเลือกใช้ภาษา

นักพัฒนากำลังจดบันทึกตัวเลขผลลัพธ์เบนช์มาร์กในเทอร์มินัล

คิดใหม่เรื่อง 'การรัน AI โดยไม่มี GPU' ในบริบทของธุรกิจส่งออก

การเพิ่มประสิทธิภาพ AI ในหน้างานจริงมีข้อจำกัดที่คุณต้องเผชิญ:

เซิร์ฟเวอร์ On-premise: ธุรกิจจำนวนมากห้ามใช้ Cloud GPU ด้วยเหตุผลด้านความปลอดภัย การปรับแต่งซอฟต์แวร์จึงเป็นทางเลือกเดียว

ขาดแคลนบุคลากร IT: ทีมส่งออกส่วนใหญ่ไม่มี ML Engineer ประจำ การปรับจูน CUDA เคอร์เนลอาจยากเกินไป การปรับแก้ PyTorch เล็กๆ น้อยๆ จึงเป็นทางเลือกที่สมจริงกว่า

ข้อจำกัดด้านงบประมาณ: หากค่า Cloud GPU เดือนละหลายแสนไม่คุ้มค่า การเพิ่ม throughput ของซอฟต์แวร์บนฮาร์ดแวร์เดิมคือวิธีประหยัดที่ดีที่สุด

เช็คลิสต์ปฏิบัติการสำหรับเพิ่มประสิทธิภาพ AI ตอนนี้เลย

วัดคอขวดก่อน (Profiling): ใช้งาน torch.profiler เพื่อดูว่าจุดไหนทำงานช้าจริง อย่าเชื่อแค่ความรู้สึก
ใช้ Mixed Precision: ใช้ FP16 หรือ BF16 แทน FP32 เพื่อลดการใช้หน่วยความจำและเพิ่มความเร็วด้วย torch.autocast
ใช้ torch.compile: ใน PyTorch 2.0 ขึ้นไป torch.compile จะช่วย Optimize กราฟการคำนวณให้คุณโดยไม่ต้องแก้โค้ดเยอะ
ปรับขนาด Batch และ Memory Layout: การปรับขนาด Batch ให้สอดคล้องและทำให้ Tensor เป็น contiguous ช่วยเพิ่มประสิทธิภาพได้เห็นผลชัดเจน

ทำไมทีมของเราถึงหมกมุ่นกับเรื่องนี้?

ในงานหาผู้ซื้อต่างประเทศ ที่คอขวดของการหาข้อมูลไม่ใช่แค่โมเดล แต่อยู่ที่ความไม่สมเหตุสมผลของโค้ดจัดการข้อมูลและการประมวลผลล่วงหน้า การทำ Mixed Precision และปรับจูน Batch size ก็เพียงพอที่จะเร่งความเร็วโดยไม่ต้องเสียเงินเช่า GPU เพิ่มเติม

Grinda.ai มุ่งเน้นการถามว่า "จะทำอย่างไรให้อัลกอริทึมทำงานได้อย่างมีประสิทธิภาพสูงสุดบนทรัพยากรที่มี" ก่อนที่จะคิดว่า "จะเช่า GPU เพิ่มที่ไหนดี" นั่นคือวิถีแห่งการทำงานของเรา ที่เน้นความเร็วและต้นทุนที่นำไปใช้งานได้จริง

บทสรุป: หากต้องการ AI ที่เร็วขึ้น จงตั้งคำถามกับโค้ดของคุณก่อน

ต้นทุนและความเร็วในการใช้งาน LLM ขึ้นอยู่กับการเพิ่มประสิทธิภาพซอฟต์แวร์มากกว่าสเปกฮาร์ดแวร์ ก่อนจะซื้อ GPU ให้ลองใช้ torch.profiler วิเคราะห์งานของคุณดูเสียก่อน การซื้อฮาร์ดแวร์โดยไม่รู้ว่าคอขวดอยู่ที่ไหน เหมือนกับการเปลี่ยนยางรถยนต์ทั้งที่เครื่องยนต์ยังมีปัญหา

ต้องการปรึกษาเรื่องแนวทางการเพิ่มประสิทธิภาพ Pipeline AI สำหรับการส่งออกหรือลดค่าใช้จ่ายในการทำ Inference บน On-premise? สามารถดูรายละเอียดได้ที่ Grinda.ai เพื่อร่วมหาจุดเพิ่มประสิทธิภาพที่คุณทำได้เองโดยไม่ต้องเพิ่มงบประมาณ GPU