ผู้ให้บริการ GPU บนคลาวด์ที่รองรับ Kubernetes

ความหมายของการสนับสนุน Kubernetes สำหรับการเช่า GPU ประมวลผล

เมื่อผู้ให้บริการ GPU บนคลาวด์โฆษณาการสนับสนุน Kubernetes หมายความว่าคุณสามารถกำหนดตารางงาน GPU ลงในคอนเทนเนอร์ที่จัดการโดย Kubernetes แทนที่จะต้องวางงานด้วยตนเองบนเครื่องเช่าแต่ละเครื่อง ในทางปฏิบัติสิ่งนี้ขึ้นอยู่กับชุดส่วนประกอบเล็กๆ ที่ทำงานร่วมกัน: ปลั๊กอินอุปกรณ์ NVIDIA (หรือเทียบเท่าสำหรับ AMD) ซึ่งเปิดเผย GPU ให้กับ kubelet เป็นทรัพยากรที่สามารถกำหนดตารางได้เหมือนกับ nvidia.com/gpu; runtime คอนเทนเนอร์ที่ตั้งค่าด้วย NVIDIA Container Toolkit เพื่อให้คอนเทนเนอร์เห็นไดรเวอร์; และเวอร์ชันไดรเวอร์และ CUDA ที่ตรงกันภายในอิมเมจของคุณ ผู้ให้บริการหลายรายจัดแพ็กเกจนี้ผ่าน NVIDIA GPU Operator ซึ่งติดตั้งไดรเวอร์ ปลั๊กอินอุปกรณ์ และการตรวจสอบโดยอัตโนมัติบนแต่ละโหนด ดังนั้นคุณไม่จำเป็นต้องฝังไดรเวอร์ไว้ในอิมเมจของตัวเอง.

คำว่า “ใช่” ในการเปรียบเทียบข้างต้นสามารถหมายถึงสองสิ่งที่แตกต่างกันอย่างมีนัยสำคัญ และควรรู้ว่าคุณได้รับแบบใด:

• Kubernetes ที่จัดการพร้อมกลุ่มโหนด GPU — ผู้ให้บริการดูแลแผงควบคุมให้คุณและอนุญาตให้คุณเพิ่มโหนดงานที่มี GPU; คุณส่วนใหญ่เขียนไฟล์ manifest และร้องขอทรัพยากร GPU.
• อินสแตนซ์ GPU ที่คุณสามารถเชื่อมต่อกับคลัสเตอร์ของคุณเอง — ผู้ให้บริการมอบ VM GPU ดิบหรือฮาร์ดแวร์เปล่า และคุณติดตั้งและดำเนินการ Kubernetes (หรือดิสทริบิวชันเช่น k3s) ด้วยตัวเอง.

ทั้งสองอย่างถือเป็น “การสนับสนุน Kubernetes” อย่างถูกต้อง แต่ภาระงานปฏิบัติการแตกต่างกันมาก ตรวจสอบการเปรียบเทียบข้างต้นและเอกสารของผู้ให้บริการเพื่อดูว่าแผงควบคุมถูกจัดการหรือคุณต้องรับผิดชอบเอง.

เหตุผลที่สำคัญสำหรับเวิร์กโฟลว์ GPU จริง

Kubernetes มีประโยชน์เมื่อใช้ GPU ในงานที่ต้องการการประสานงานมากกว่าการใช้กล่องเดียวที่ทำงานนานๆ:

• การให้บริการการอนุมานในระดับใหญ่ — การปรับขนาดอัตโนมัติของสำเนาหลายชุดเบื้องหลังบริการ การเปิดตัวเวอร์ชันโมเดลใหม่โดยไม่หยุดทำงาน และการจัดกลุ่มโมเดลเล็กๆ หลายตัวบนโหนดที่ใช้ร่วมกัน นี่คือกรณีที่แข็งแกร่งที่สุดสำหรับ Kubernetes บน GPU.
• การฝึกอบรมแบบกระจายหลายโหนด — เฟรมเวิร์กและโอเปอเรเตอร์ (เช่น Kubeflow training operators หรือการจัดตารางแบบ MPI/Volcano-style gang scheduling) ประสานงานพ็อดงานหลายตัวข้ามโหนด GPU หลายโหนด ซึ่งสำคัญเมื่อเครื่องเดียวไม่สามารถเก็บโมเดลได้หรือคุณต้องการการฝึกอบรมที่เร็วขึ้นตามเวลาจริง.
• งานแบตช์และพายป์ไลน์ — การจัดคิวการรันปรับแต่ง การเตรียมข้อมูล หรือการเรนเดอร์เป็น Kubernetes Jobs พร้อมการลองใหม่และโควตาทรัพยากร แทนการดูแลเซสชัน SSH.

สำหรับโน้ตบุ๊กแบบโต้ตอบเดียวหรือการรันปรับแต่งหนึ่งครั้งบน GPU เดียว Kubernetes มักเป็นภาระเกินความจำเป็น — อินสแตนซ์เช่าแบบธรรมดาที่มี SSH หรือจุดเชื่อมต่อ Jupyter ง่ายกว่า คุณค่าจะปรากฏเมื่อคุณมีเวิร์กโหลดหลายงาน หลาย GPU หรือความต้องการการกู้คืนและการปรับขนาดอัตโนมัติ.

ฟีเจอร์การแชร์และการกำหนดตาราง GPU ที่ควรมองหา

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

• การแบ่งเวลาการใช้งาน (Time-slicing) — ปลั๊กอินอุปกรณ์ประกาศ GPU ทางกายภาพหนึ่งตัวเป็นหน่วยที่สามารถกำหนดตารางได้หลายหน่วย ให้พ็อดหลายตัวแชร์กันอย่างร่วมมือ (ไม่มีการแยกหน่วยความจำอย่างเข้มงวด).
• Multi-Instance GPU (MIG) — รองรับบนการ์ดศูนย์ข้อมูลในรุ่น Ampere และรุ่นหลัง แบ่ง GPU หนึ่งตัวออกเป็นอินสแตนซ์ที่แยกฮาร์ดแวร์อย่างสมบูรณ์พร้อมหน่วยความจำและส่วนประมวลผลเฉพาะ.
• MPS (Multi-Process Service) — อนุญาตให้เคอร์เนลจากกระบวนการต่างๆ ทำงานพร้อมกันบน GPU ตัวเดียวโดยมีค่าใช้จ่ายต่ำกว่าการแบ่งเวลาการใช้งาน.

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

การแลกเปลี่ยนและสิ่งที่ควรตรวจสอบก่อนตัดสินใจ

Kubernetes เพิ่มความสามารถแต่ก็เพิ่มส่วนประกอบที่ต้องจัดการด้วย ชั่งน้ำหนักสิ่งเหล่านี้กับอินสแตนซ์เช่าธรรมดา:

• การจัดตำแหน่งไดรเวอร์และ CUDA — CUDA toolkit ในอิมเมจคอนเทนเนอร์ของคุณต้องเข้ากันได้กับไดรเวอร์ที่ติดตั้งบนโหนด GPU GPU Operator ช่วยลดความยุ่งยากนี้ แต่ความไม่ตรงกันของเวอร์ชันเป็นสาเหตุที่พบบ่อยที่สุดของพ็อดที่กำหนดตารางได้แต่ล่ม.
• เครือข่ายสำหรับการฝึกอบรมหลายโหนด — งานแบบกระจายต้องการแบนด์วิดท์สูง มองหาอินเทอร์คอนเน็คความเร็วสูง (เช่น RDMA/InfiniBand หรือการเชื่อมต่อโหนดต่อโหนดที่รวดเร็ว) และตรวจสอบว่าผู้ให้บริการรองรับ CNI และปลั๊กอินอุปกรณ์ที่เกี่ยวข้องหรือไม่; เครือข่ายพ็อดธรรมดาอาจเป็นคอขวดของการดำเนินงานร่วมกัน.
• การจัดเก็บข้อมูล — การฝึกอบรมและการบันทึกสถานะต้องการไดรเวอร์ CSI และโวลุ่มถาวร โดยควรมีการจัดเก็บข้อมูลที่รวดเร็วและใช้ร่วมกันได้ที่พ็อดของคุณสามารถเมานต์ข้ามโหนดได้.
• โหนดแบบ Spot/interruptible — โหนด GPU แบบ preemptible ที่ราคาถูกเหมาะกับ Kubernetes หากเวิร์กโหลดของคุณทนต่อการถูกไล่ออกได้; ตรวจสอบให้แน่ใจว่าคลัสเตอร์จัดการการระบายโหนดและการกำหนดตารางใหม่ได้อย่างราบรื่น.
• รูปแบบการคิดเงิน — คุณยังคงจ่ายสำหรับโหนด GPU พื้นฐานไม่ว่าพ็อดจะใช้งานหรือไม่ รวมถึงค่าธรรมเนียมแผงควบคุมที่จัดการ โหนด GPU ที่ว่างเปล่าเป็นต้นทุนที่ไม่เห็นได้ชัด; การปรับขนาดกลุ่มโหนดอัตโนมัติให้เหลือศูนย์เป็นวิธีแก้ไข.

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

คำถามที่พบบ่อย

การสนับสนุน Kubernetes หมายความว่าไดรเวอร์ถูกติดตั้งบนโหนด GPU แล้วหรือไม่?

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

ฉันสามารถรันเวิร์กโหลดมากกว่าหนึ่งงานต่อ GPU บน Kubernetes ได้หรือไม่?

โดยปกติไม่ — Kubernetes จัดสรร GPU ทั้งตัวให้กับพ็อด หากต้องการแชร์การ์ด คุณต้องเปิดใช้งานฟีเจอร์เฉพาะ เช่น การแบ่งเวลาการใช้งาน (time-slicing), MPS หรือการแบ่งส่วน MIG แบบฮาร์ดแวร์ ตรวจสอบการเปรียบเทียบข้างต้นว่าผู้ให้บริการเปิดเผยฟีเจอร์ใดก่อนสมมติว่าคุณสามารถวางโมเดลเล็กหลายตัวบน GPU ตัวเดียวได้.

Kubernetes คุ้มค่าหรือไม่สำหรับงาน GPU เดียว?

โดยทั่วไปไม่ สำหรับโน้ตบุ๊กหนึ่งตัว จุดเชื่อมต่ออนุมานหนึ่งจุด หรือการรันปรับแต่งหนึ่งครั้ง อินสแตนซ์เช่าธรรมดาที่มี SSH หรือ Jupyter ที่โฮสต์ง่ายกว่าและหลีกเลี่ยงภาระของคลัสเตอร์ Kubernetes จะคุ้มค่าก็ต่อเมื่อคุณมีเวิร์กโหลดพร้อมกันหลายงาน การฝึกอบรมหลาย GPU หรือหลายโหนด การปรับขนาดอัตโนมัติของอนุมาน หรือความต้องการการลองใหม่และเปิดตัวอัตโนมัติ.

ฉันควรตรวจสอบอะไรสำหรับการฝึกอบรมแบบกระจายหลายโหนดบน Kubernetes?

ตรวจสอบอินเทอร์คอนเน็คความเร็วสูงระหว่างโหนด GPU (เช่น RDMA หรือ InfiniBand) การสนับสนุนการจัดตารางแบบ gang/queue เพื่อให้พ็อดงานทั้งหมดเริ่มพร้อมกัน โอเปอเรเตอร์ฝึกอบรมสำหรับเฟรมเวิร์กของคุณ และการจัดเก็บข้อมูลที่รวดเร็วและใช้ร่วมกันสำหรับชุดข้อมูลและจุดบันทึกสถานะ หากไม่มีสิ่งเหล่านี้ งานแบบกระจายจะติดขัดรอการกำหนดตารางบางส่วนหรือเกิดคอขวดที่เครือข่ายและการจัดเก็บข้อมูลแทนที่จะเป็นการประมวลผล.