หยุดออกแบบโครงสร้างพื้นฐาน AI รอบ GPU

ทำไม MSP ควรเริ่มจากภาระงาน ไม่ใช่ฮาร์ดแวร์

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

ปัญหาไม่ได้อยู่ที่การคำนวณไม่สำคัญ แต่มันสำคัญอย่างยิ่ง

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

คำถามแรกไม่ควรเป็น “GPU ใดที่เราควรซื้อ?”

“ภาระงานอะไรที่เรากำลังพยายามสนับสนุน?” ควรเป็นจุดโฟกัส

การเปลี่ยนแปลงที่ดูเหมือนเล็กน้อยนี้ส่งผลต่อการตัดสินใจด้านโครงสร้างพื้นฐานเกือบทุกอย่างที่ตามมา

ไม่มีโครงสร้างพื้นฐาน AI มาตรฐาน

หนึ่งในความเข้าใจผิดที่ใหญ่ที่สุดในตลาดคือเชื่อว่ามีแผนผังมาตรฐานสำหรับโครงสร้างพื้นฐาน AI แต่จริง ๆ แล้วไม่มี

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

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

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

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

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

องค์กรที่เริ่มต้นด้วยคลาวด์ แพลตฟอร์มฮาร์ดแวร์ หรือผู้จำหน่ายที่ชอบ ไม่ได้กำหนดโครงสร้างพื้นฐาน AI อย่างถูกต้อง ผู้นำจะเริ่มจากภาระงานและออกแบบสถาปัตยกรรมรอบวัตถุประสงค์ทางธุรกิจ

การฝึกอบรมเป็นหัวข้อข่าวเด่น การสรุปผล (Inference) ส่งมอบคุณค่าทางธุรกิจ

ความหลงใหลของอุตสาหกรรมต่อการฝึกอบรมเป็นเหตุผลอีกประการหนึ่งที่การสนทนาเกี่ยวกับโครงสร้างพื้นฐาน AI อาจมุ่งไปในทิศทางที่ผิด

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

อย่างไรก็ตาม ส่วนใหญ่ขององค์กรไม่ได้สร้างโมเดลแนวหน้าใหม่ พวกเขากำลังสร้างแอปพลิเคชันบริการลูกค้า, ระบบ AI เสียง, ผู้ช่วยร่วมงานสำหรับพนักงาน, ผู้ช่วยความรู้, เครื่องมือค้นหา, แพลตฟอร์มสรุปเอกสาร, ระบบตรวจจับการฉ้อโกง, และแอปพลิเคชันเชิงปฏิบัติอื่น ๆ อีกหลายสิบรายการโดยใช้โมเดลที่ได้รับการฝึกแล้ว

เหล่านั้นเป็นภาระงาน inference และ inference ทำให้สมการโครงสร้างพื้นฐานเปลี่ยนไป แทนที่จะปรับให้เหมาะสมเฉพาะกับการคำนวณสูงสุด องค์กรอาจต้องปรับให้เหมาะสมกับเวลาตอบสนองที่เร็ว, ความหน่วงต่ำ, ค่าใช้จ่ายการดำเนินงานที่คาดการณ์ได้, และประสิทธิภาพที่สม่ำเสมอ

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

ดังนั้นการออกแบบสภาพแวดล้อม AI ทุกอย่างเหมือนกับว่าคุณกำลังฝึกโมเดลพื้นฐานจึงมักเป็นแนวทางที่ผิดและมักมีค่าใช้จ่ายที่ไม่จำเป็น

เป้าหมายของลูกค้า MSP ส่วนใหญ่ไม่ได้คือการสร้างคลัสเตอร์ GPU ที่ใหญ่ที่สุดในโลก แต่คือการนำแอปพลิเคชัน AI ไปสู่การผลิตอย่างรวดเร็ว, เชื่อถือได้, ปลอดภัย, และคุ้มค่า

ความท้าทายคือการหาสมดุลที่เหมาะสมระหว่างประสิทธิภาพ, ความปลอดภัย, ความสามารถขยาย, ความทนทาน, และต้นทุนสำหรับภาระงานที่พวกเขากำลังใช้งานจริง

บางที GPU อาจไม่ใช่คอขวดของคุณ

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

“เราต้องการ GPU กี่ตัว?” ไม่ใช่คำถามที่ควรถาม แต่ควรเป็น “อะไรจะทำให้แอปพลิเคชันนี้ช้าลงในหกเดือนข้างหน้า?”

คำตอบอาจอยู่ในส่วนอื่นของสถาปัตยกรรม

การจัดเก็บเป็นตัวอย่างที่ดี AI ใช้ข้อมูลจำนวนมหาศาล – และชุดข้อมูลเหล่านั้นเติบโตตามเวลา แม้ GPU ที่ทรงพลังมากก็อาจเสียเวลารอคอยแทนที่จะทำงาน หากการจัดเก็บไม่สามารถส่งข้อมูลได้เร็วพอ ข้อมูลนั้นยังต้องได้รับการปกป้อง, สำรอง, เก็บรักษา, ปลอดภัย, และจัดการตลอดอายุการใช้งาน

เช่นเดียวกัน เครือข่ายก็สำคัญ อัตราการส่งข้อมูล, ความหน่วง, การจราจรแบบ east-west, และการสื่อสารระหว่างคลัสเตอร์ AI ทั้งหมดส่งผลต่อประสิทธิภาพของแอปพลิเคชัน สภาพแวดล้อมการคำนวณที่ออกแบบดีไม่สามารถชดเชยเครือข่ายที่ออกแบบแย่ได้ตลอดเวลา

นอกจากนี้ ความปลอดภัยต้องเป็นส่วนหนึ่งของสถาปัตยกรรมตั้งแต่แรก คำถามที่ต้องตอบก่อนการผลิตรวมถึง: ข้อมูลที่ละเอียดอ่อนอยู่ที่ไหน, เครือข่ายถูกแบ่งส่วนอย่างไร, ภาระงานสื่อสารผ่านการเชื่อมต่อส่วนตัวหรือสาธารณะหรือไม่, และวิธีการจัดการข้อกำหนดด้านการปฏิบัติตามและอธิปไตย

อีกปัจจัยที่มักมองข้ามง่ายคือการเชื่อมต่อ แม้ว่ามันอาจไม่สร้างหัวข้อข่าวที่ดึงดูดสายตา ความหลากหลายของไฟเบอร์, ความหลากหลายของเส้นทาง, ความสัมพันธ์การเชื่อมต่อแบบ peering, และความใกล้ชิดทางภูมิศาสตร์ สามารถส่งผลสำคัญต่อประสบการณ์ผู้ใช้ – ยังไม่พูดถึงความทนทานของแพลตฟอร์ม

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

โครงสร้างพื้นฐานทางกายภาพก็ต้องได้รับความสนใจเช่นกัน ความพร้อมของไฟฟ้า, ความจุการทำความเย็น, ความหนาแน่นของแร็ค, และความสามารถในการขยาย กำหนดว่าการปรับใช้ที่ประสบความสำเร็จในวันนี้สามารถรองรับการเติบโตในวันพรุ่งนี้ได้หรือไม่.

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

นี่คือเหตุผลที่สถาปัตยกรรมสำคัญ

ลองนึกถึงรถแข่ง – แม้ว่าจะมีเครื่องยนต์ที่ดีที่สุดก็ไม่ได้หมายความว่าจะชนะ ระบบส่งกำลัง, ยาง, ระบบกันสะเทือน, สนามแข่ง, และโดยเฉพาะคนขับก็มีความสำคัญเช่นกัน โครงสร้างพื้นฐาน AI ทำงานในลักษณะเดียวกัน

องค์กรที่สร้างคุณค่ามากที่สุดจาก AI ไม่ได้จำเป็นต้องเป็นผู้ที่มีคลัสเตอร์ GPU ขนาดใหญ่ที่สุด พวกเขาจะเป็นผู้ที่เข้าใจว่าชั้นต่าง ๆ ของโครงสร้างพื้นฐานทำงานร่วมกันอย่างไร.

นั่นคือความแตกต่างระหว่างการซื้อโครงสร้างพื้นฐานและการออกแบบมัน

กรอบการวางแผนแบบเน้นภาระงานเป็นอันดับแรก

MSP มีโอกาสเปลี่ยนแปลงการสนทนาเกี่ยวกับโครงสร้างพื้นฐาน

แทนที่จะเริ่มต้นด้วย:

• GPU ใด?
• คลาวด์ใด?
• ผู้จำหน่ายใด?

เริ่มต้นด้วยภาระงาน:

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

คำตอบควรกำหนดสถาปัตยกรรม ไม่ใช่ในทางกลับกัน

โอกาสสำหรับ MSP

การเปลี่ยนแปลงนี้ทำให้บทบาทของ MSP เปลี่ยนไป

ลูกค้าไม่ต้องการพันธมิตรอีกคนที่สามารถขายโครงสร้างพื้นฐานให้พวกเขาได้ แต่ต้องการพันธมิตรที่ช่วยให้พวกเขาตัดสินใจโครงสร้างพื้นฐานได้ดียิ่งขึ้น

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

ด้วยวิธีนี้ คุณสามารถควบคุมต้นทุน, ปรับปรุงประสิทธิภาพ, และระบุความเสี่ยงด้านการดำเนินงานและความปลอดภัยก่อนที่แอปพลิเคชันจะเข้าสู่การผลิต

โมเดลธุรกิจที่ดีกว่าสำหรับ MSP ก็ถูกสร้างขึ้นเช่นกัน

MSP สามารถสร้างบริการที่มีมูลค่าสูงและต่อเนื่องรอบการออกแบบสถาปัตยกรรม, การปรับใช้, การเพิ่มประสิทธิภาพ, ความปลอดภัย, การจัดการวงจรชีวิต, การวางแผนความจุ, และการปรับปรุงอย่างต่อเนื่อง – แทนการแข่งขันโดยเน้นที่กำไรจากฮาร์ดแวร์ที่ลดลง

คุณค่าไม่ได้อยู่ที่การแนะนำ GPU ล่าสุดหรือแพลตฟอร์มคลาวด์ใหม่ที่สุด แต่คือการรู้ว่าเมื่อใดที่ลูกค้าต้องการ, เมื่อใดที่ไม่ต้องการ, และสิ่งอื่นใดที่ต้องออกแบบรอบพวกมัน

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

MSP ที่เข้าใจความแตกต่างนี้จะอยู่ในตำแหน่งที่จะกลายเป็นสิ่งที่มีคุณค่ามากกว่าผู้จัดหาโครงสร้างพื้นฐาน

พวกเขาจะเป็นผู้ที่ลูกค้าไว้วางใจเพื่อช่วยตัดสินใจว่าโครงสร้างพื้นฐานที่พวกเขาจริง ๆ ต้องการคืออะไร