การจัดตารางงาน GPU โดยใช้ Inference GPU Pool ที่ว่างอยู่

การจัดตารางงาน GPU โดยใช้ Inference GPU Pool ที่ว่างอยู่: กรณีศึกษาการเพิ่มประสิทธิภาพโครงสร้างพื้นฐานของ LG AI Research

บทความนี้ที่เปิดเผยโดยทีม Platform&Infra ของ LG AI Research ว่าด้วยการนำทรัพยากร GPU ที่ว่างอยู่ซึ่งเกิดขึ้นระหว่างการให้บริการโมเดลภาษาขนาดใหญ่ (LLM) กลับมาใช้ซ้ำกับงานวิจัยและการทดลองอย่างไร โดยทั่วไปบริษัทที่ให้บริการ AI มักต้องเตรียม GPU ไว้ล่วงหน้าตามระดับทราฟฟิกสูงสุด ทำให้ในช่วงเวลาที่ทราฟฟิกลดลง GPU ราคาแพงเหล่านี้ว่างอยู่โดยกินเพียงหน่วยความจำเท่านั้น ทางสถาบันได้สร้างไปป์ไลน์ที่จัดสรร GPU ในช่วงเวลาว่างนี้ให้กับงานฝึกและงานประเมินผลโดยอัตโนมัติ จนสามารถจัดหาทรัพยากรประมวลผลได้โดยไม่ต้องซื้ออุปกรณ์เพิ่ม

นิยามปัญหาหลัก

• ข้อจำกัดของออโตสเกลลิงสำหรับบริการ LLM: ต่างจากเว็บเซอร์วิสทั่วไป LLM มีการใช้ GPU ต่อหนึ่งคำขอที่ผันผวนตามความยาวของโทเค็นขาเข้า·ขาออกและโครงสร้างของโมเดล ดังนั้นตัวชี้วัดแบบดั้งเดิมอย่างอัตราการใช้ CPU หรือการใช้หน่วยความจำจึงวัดภาระงานจริงได้ยาก
• ขนาดของทรัพยากรที่ว่างอยู่: ในสภาพแวดล้อมที่ replica (สำเนาอินสแตนซ์ของบริการ) หนึ่งตัวใช้ GPU 4 ใบ พบว่าในช่วงเวลากลางคืนที่ไม่หนาแน่น (20:00–8:00 ของวันถัดไป) มี GPU ว่างเฉลี่ยวันละ 52 ใบ เป็นเวลาราว 12 ชั่วโมง

แนวทางแก้ไข

• ใช้ตัวชี้วัดภายในของ vLLM: แทนที่จะใช้ตัวชี้วัดของระบบทั่วไป ทีมงานใช้เกณฑ์ออโตสเกลลิงจากตัวชี้วัดที่เอนจินอนุมาน LLM อย่าง vLLM มีให้ เช่น throughput แบบเรียลไทม์และสถานะการรอในคิว เพื่อให้ปรับทรัพยากรได้อย่างแม่นยำตามลักษณะเฉพาะของ LLM
• รันงานแบบ Best-effort: รันงานวิจัยบน GPU ที่ว่างในช่วงกลางคืน แต่หากทราฟฟิกกลับมาเพิ่มขึ้นก็สามารถหยุดงานวิจัยได้ทุกเมื่อและคืน GPU ให้บริการทันที จึงไม่กระทบเสถียรภาพของบริการ
• ไปป์ไลน์บนพื้นฐาน Argo Workflows: กำหนดงานเป็นหน่วย Docker image และแบ่งขั้นตอนอย่างการเตรียมข้อมูล การพรีเทรน การปรับจูนแบบมีผู้สอน การเรียนรู้แบบเสริมกำลัง และการประเมินผล ออกเป็นสเต็ปเพื่อให้รันแบบลำดับหรือขนานได้

จุดเด่นของหลักการออกแบบ

• ความเป็นสากล: ไม่ว่าจะเป็นงานฝึกหรือ inference หรือใช้เฟรมเวิร์กใดก็ตาม หากห่อเป็น Docker image ก็สามารถรันได้ทันที
• การขยายตัวและความยืดหยุ่น: แม้จะมีประเภทงานใหม่เพิ่มเข้ามา ก็สามารถรองรับได้โดยไม่ต้องแก้โค้ดของไปป์ไลน์
• การทำซ้ำได้: การตั้งค่าทั้งหมดถูกส่งเข้ามาเป็นพารามิเตอร์ภายนอกแทนการเขียนไว้ในโค้ด ส่วนอินพุตและเอาต์พุตถูกจัดการบนคลาวด์สตอเรจ จึงรับประกันผลลัพธ์เดิมภายใต้เงื่อนไขเดียวกัน นอกจากนี้โครงสร้างแบบ Stateless ที่ไปป์ไลน์ไม่เก็บสถานะยังช่วยเพิ่มเสถียรภาพในการปฏิบัติการ

ผลลัพธ์ในการปฏิบัติการ

• ปริมาณการใช้งานสะสม: ในช่วงราว 3 เดือนตั้งแต่เดือนพฤศจิกายน 2025 ถึงมกราคม 2026 มีการรันงาน 85 งาน และมีการใช้ GPU สะสมถึง 95,000 GPU ชั่วโมง
• แนวโน้มการเพิ่มขึ้น: ปริมาณการใช้ GPU ในเดือนมกราคมเพิ่มขึ้นราว 70% เมื่อเทียบกับเดือนพฤศจิกายน และเมื่อคำนวณเป็นการใช้งานตลอด 24 ชั่วโมง ให้ผลเทียบเท่ากับการได้ GPU ใหม่เพิ่มราว 55 ใบ
• การลดต้นทุน: หากแปลงปริมาณการประมวลผลเท่ากันเป็นต้นทุนบน public cloud ภายใต้สัญญา 3 ปี จะเทียบได้กับการประหยัดราว 75 ล้านวอนในเดือนมกราคมเพียงเดือนเดียว และสะสมราว 185 ล้านวอนตลอด 3 เดือน

แผนต่อไป

• ยกระดับตัวชี้วัดสำหรับการสเกล: มีแผนจะจำแนกรูปแบบการใช้งานของแต่ละบริการให้ละเอียดขึ้น เพื่อทำให้ตรรกะการจัดสรรทรัพยากรแม่นยำยิ่งขึ้น
• ขยายการจัดตารางแบบตลอดเวลา: ต้องการต่อยอดโดยใช้ Kubernetes และโมเดล EXAONE ที่พัฒนาขึ้นเอง เพื่อขยายจากการรันเฉพาะกลางคืนไปสู่ระบบที่เริ่มงานได้ทันทีเมื่อมีทรัพยากรว่าง
• ปรับปรุง UX: มีแผนจัดเตรียมอินเทอร์เฟซที่ช่วยให้นักวิจัยทำงานได้อย่างเข้าใจง่าย ตั้งแต่การขอรันงานไปจนถึงการมอนิเตอร์

กรณีศึกษานี้ชี้ให้เห็นถึงความพยายามในการแก้โจทย์ร่วมของอุตสาหกรรมเรื่องการขาดแคลน GPU ไม่ใช่ด้วยการขยายฮาร์ดแวร์ แต่ด้วยการปรับปรุงโครงสร้างการปฏิบัติการ โดยเฉพาะแนวทางที่หลบข้อจำกัดในการวัดภาระงานเฉพาะของบริการ LLM ด้วยตัวชี้วัดภายในของ vLLM และกำหนดให้งานวิจัยเป็นแบบ Best-effort เพื่อรักษาทั้งเสถียรภาพของบริการและอัตราการใช้ทรัพยากรซึ่งเป็นเป้าหมายที่มักขัดกัน พร้อมกันนั้นผลลัพธ์เชิงปริมาณที่ลดต้นทุนได้ราว 180 ล้านวอนโดยไม่ต้องลงทุนเพิ่ม ก็เป็นโมเดลการปฏิบัติการที่องค์กรอื่นซึ่งดูแลโครงสร้างพื้นฐาน GPU สามารถนำไปอ้างอิงได้อย่างมาก