ทำไมแอปพลิเคชัน AI ควรส่งเวิร์กโหลดแทนการเลือกชิป GPU เอง

นักพัฒนาซอฟต์แวร์รายหนึ่งกำลังสร้างแอปพลิเคชัน AI ที่ต้องรันงานอินเฟอเรนซ์ที่ใช้ GPU หนุนหลัง การใช้งานเริ่มต้นดูเรียบง่ายตรงไปตรงมาผ่านการเรียกใช้งานผ่าน CloudGPUProvider ระบุภูมิภาค ประเภทอินสแตนซ์ รุ่น GPU และอิมเมจคอนเทนเนอร์ ก่อนจะสั่งรันคำสั่งไพธอนเพื่อประมวลผลข้อมูล ซึ่งโค้ดลักษณะนี้ใช้งานได้จริงในตอนแรก

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

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

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

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

• รูปแบบวงจรชีวิตของ API
• โครงสร้างการเรียกเก็บล็อกและบันทึก
• กลไกการกู้คืนข้อผิดพลาด
• เครื่องมือจัดการเครือข่ายและสตอเรจ

ที่มา: Dev.to