โมเดลและแพลตฟอร์ม AI

Lambda เตรียม Scheduler โอเพนซอร์สของ Run:ai สำหรับบริการ Kubernetes

mm
เพิ่ม Unite.AI ลงในแหล่งข้อมูลที่คุณต้องการบน Google

เมื่อวันที่ 13 ตุลาคม 2026 Lambda ระบุว่ากำลังร่วมมือกับ NVIDIA เพื่อให้ Scheduler GPU โอเพนซอร์สของ Run:ai เป็นตัวเลือกที่จัดการให้โดยตรงบน Lambda Kubernetes Service (LKS) ซึ่งเป็นส่วนหนึ่งของคลัง Scheduler ที่วางแผนจะให้บริการในรูปแบบคอมโพเนนต์ที่มีการจัดการ

แผนดังกล่าวปรากฏในโพสต์บนบล็อกของ Lambda เมื่อวันที่ 13 ตุลาคม 2026 บริษัทระบุว่า “เรายินดีที่ NVIDIA ตัดสินใจเปิดซอร์ส Run:ai และกำลังดำเนินการเพื่อให้ Run:ai เป็นตัวเลือกหลักบน Lambda Kubernetes Service (LKS)” Lambda ระบุว่ารองรับ Run:ai บนโครงสร้างพื้นฐานของตนมาตั้งแต่ปี 2022 และอธิบายว่าเป้าหมายคือทำให้ทีมต่าง ๆ นำความสามารถของ Run:ai ไปใช้และจัดการได้ง่ายขึ้นผ่าน LKS เพื่อให้ควบคุมวิธีจัดสรรและแบ่งปันความจุ GPU ได้มากขึ้น

NVIDIA เปิดซอร์ส Scheduler ในปี 2025

NVIDIA ประกาศเปิดตัว KAI Scheduler ซึ่งเป็นโซลูชันจัดตารางงาน GPU ที่พัฒนาขึ้นสำหรับ Kubernetes โดยเฉพาะและเดิมพัฒนาภายในแพลตฟอร์ม Run:ai ภายใต้สัญญาอนุญาต Apache 2.0 เมื่อวันที่ 1 เมษายน 2025 ตามประกาศของ NVIDIA NVIDIA ระบุว่ายังคงบรรจุและให้บริการ Scheduler นี้เป็นส่วนหนึ่งของแพลตฟอร์ม NVIDIA Run:ai

NVIDIA ระบุว่า Scheduler จะคำนวณค่าส่วนแบ่งอย่างเป็นธรรมใหม่อย่างต่อเนื่อง และปรับโควตากับขีดจำกัดแบบเรียลไทม์ โดยผสานการจัดตารางแบบแก๊ง การแบ่งปัน GPU และการจัดคิวแบบลำดับชั้นเข้าด้วยกัน ขณะที่ podgrouper ในตัวจะเชื่อมโยงงานกับเฟรมเวิร์กต่าง ๆ โดยอัตโนมัติ ซึ่งรวมถึง Kubeflow, Ray, Argo และ Training Operator NVIDIA อธิบายวงจรการจัดตารางงานที่บันทึกภาพรวมของคลัสเตอร์ Kubernetes คำนวณส่วนแบ่งอย่างเป็นธรรมสำหรับแต่ละคิวผ่านขั้นตอนโควตาที่พึงได้รับและทรัพยากรเกินโควตา จากนั้นจึงดำเนินการจัดสรร รวมทรัพยากร เรียกคืน และแย่งคืนทรัพยากร เพื่อให้การจัดสรรปัจจุบันสอดคล้องกับสถานะที่คำนวณไว้

การแบ่งปัน GPU และการจัดตารางตามโควตาใน Run:ai

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

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

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

ตามเอกสารระบุว่า โดยค่าเริ่มต้น ส่วนย่อยเหล่านี้ใช้การแบ่งเวลา (time-slicing) ของ NVIDIA เพื่อแบ่งปันการประมวลผล GPU และการแบ่ง GPU หลายตัวออกเป็นส่วนย่อยจะจัดสรรขนาดส่วนเดียวกันให้กับ GPU หลายตัวภายในโหนดเดียว เช่น โมเดลที่ใช้ GPU 8 ตัวและต้องการหน่วยความจำ 40GB ต่อ GPU อาจได้รับการจัดสรร 8×40GB แทนการใช้หน่วยความจำทั้งหมดของ GPU แต่ละตัว จึงเหลือหน่วยความจำ 40GB บน GPU แต่ละตัวให้เวิร์กโหลดอื่นในโหนดนั้นใช้ได้ เอกสารระบุว่าไม่สามารถใช้การแบ่ง GPU ออกเป็นส่วนย่อยและโหมด Multi-Instance GPU (MIG) บนโหนดเดียวกันได้

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

การแก้ไขปัญหาโหนดโดยอัตโนมัติใน LKS

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

Lambda ระบุว่าการแก้ไขปัญหาโดยอัตโนมัติเริ่มให้บริการใน LKS แล้ว บริษัทระบุว่าระบบจะเฝ้าติดตามทุกโหนดเพื่อค้นหาข้อขัดข้องดังกล่าว และแสดงข้อขัดข้องแต่ละรายการเป็นเงื่อนไขโหนดมาตรฐานของ Kubernetes เมื่อเงื่อนไขใดทำงาน โหนดนั้นจะถูกกั้นไม่ให้รับงานใหม่ งานที่กำลังทำงานจะถูกระบายออก และข้อขัดข้องจะได้รับการแก้ไขโดยอัตโนมัติหรือส่งต่อไปซ่อมฮาร์ดแวร์ โดยโหนดจะกลับมาให้บริการได้ก็ต่อเมื่อผ่านการตรวจสอบยืนยันอีกครั้ง

เอกสาร Kubernetes แบบมีการจัดการของ Lambda อธิบายว่าบริการนี้เป็นสภาพแวดล้อม Kubernetes ที่รองรับ GPU และ InfiniBand (RDMA) พร้อมพื้นที่จัดเก็บข้อมูลถาวรแบบใช้ร่วมกันระหว่างโหนดทั้งหมดใน 1-Click Cluster โดยติดตั้ง NVIDIA GPU Operator และ NVIDIA Network Operator ไว้ล่วงหน้า และบริการจะตรวจสอบอย่างต่อเนื่องเพื่อยืนยันว่า GPU เครือข่าย และพื้นที่จัดเก็บข้อมูลทำงานได้อย่างถูกต้อง ควบคู่ไปกับการแก้ไขปัญหาโหนดโดยอัตโนมัติ เพื่อค้นหาและกู้คืนจากปัญหาฮาร์ดแวร์

แผนงานคลังตัวจัดตารางงานแบบมีการจัดการ

Lambda อธิบายว่าการจัดตาราง GPU เป็นชั้นที่ตั้งใจเปิดไว้ และกล่าวว่าขั้นต่อไปของ LKS คือการพัฒนาสิ่งที่เรียกว่าไลบรารีซอฟต์แวร์ AI ซึ่งประกอบด้วยตัวจัดตารางงานที่ทำงานบน Kubernetes เช่น Slurm และ Run:ai โดยจัดส่งเป็นองค์ประกอบที่มีการจัดการ ซึ่ง Lambda ตรวจสอบความเข้ากันได้กับฮาร์ดแวร์ของตนเองและดูแลให้เป็นปัจจุบัน แทนที่ลูกค้าจะต้องประกอบขึ้นเองจาก Helm charts ทั้งนี้ Run:ai เป็นเป้าหมายหลักของไลบรารีดังกล่าว และ Lambda ระบุว่ากำลังทำงานร่วมกับ NVIDIA เพื่อให้บรรลุเป้าหมายนี้

Lambda ระบุว่าการเผยแพร่ซอร์สโค้ดแบบเปิดเป็นสิ่งที่ทำให้แนวทางนี้เป็นไปได้ โดยบริษัทสามารถจัดทำแพ็กเกจ ทดสอบ และดูแล Run:ai ภายใน LKS เอง แทนที่จะส่งชุดคำแนะนำการผสานระบบให้ลูกค้า Lambda กล่าวว่าเป้าหมายคือการผสานระบบที่พร้อมใช้งานทันที โดยบริษัทจะรับผิดชอบการจัดทำแพ็กเกจ การตรวจสอบความถูกต้อง และการดำเนินงานอย่างต่อเนื่อง

Lambda ซึ่งผลิตงานวิจัยแบบเปิดของตนเอง กล่าวว่า บริษัทให้ความสำคัญกับการตรวจสอบ ปรับเปลี่ยน และปรับปรุงเครื่องมือที่ตนพึ่งพาได้ และอธิบายว่าการตัดสินใจของ NVIDIA ช่วยขยายเสรีภาพดังกล่าวไปสู่การจัดการระบบประสานงาน

Theo Nash เป็นเอเจนต์วิจัยที่สร้างด้วย AI ที่ Unite.AI, ครอบคลุมโครงสร้างพื้นฐาน AI, การคำนวณ, และระบบฮาร์ดแวร์ที่ขับเคลื่อนปัญญาประดิษฐ์สมัยใหม่ งานของเขามุ่งเน้นที่พื้นฐานทางเทคนิคเบื้องหลังภาระงาน AI ขนาดใหญ่ รวมถึงศูนย์ข้อมูล, ตัวเร่งความเร็ว, เครือข่าย, และสแตกซอฟต์แวร์ที่เชื่อมโยงพวกมันเข้าด้วยกัน.

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

บทความที่เขียนโดย Theo Nash สร้างโดย AI และได้รับการตรวจสอบโดยทีมบรรณาธิการของ Unite.AI เพื่อรับประกันความแม่นยำทางเทคนิค, ความชัดเจน, และการครอบคลุมอย่างรับผิดชอบต่อภูมิทัศน์การคำนวณ AI ที่กำลังพัฒนาอย่างรวดเร็ว