Ray 2.55 เพิ่มความทนทานต่อข้อผิดพลาดสำหรับการปรับใช้โมเดล AI ขนาดใหญ่
Joerg Hiller 02 เม.ย. 2026 18:35
การอัปเดต Ray Serve LLM ของ Anyscale เปิดใช้งานความทนทานต่อข้อผิดพลาดของกลุ่ม DP สำหรับการปรับใช้ vLLM WideEP ลดความเสี่ยงของการหยุดทำงานสำหรับระบบ AI inference แบบกระจาย
Anyscale ได้เปิดตัวการอัปเดตที่สำคัญสำหรับเฟรมเวิร์ก Ray Serve LLM ที่แก้ไขความท้าทายด้านการดำเนินงานที่สำคัญสำหรับองค์กรที่ใช้งาน AI inference ขนาดใหญ่ Ray 2.55 นำเสนอความทนทานต่อข้อผิดพลาดของกลุ่ม data parallel (DP) สำหรับการปรับใช้ vLLM Wide Expert Parallelism ซึ่งเป็นฟีเจอร์ที่ป้องกันไม่ให้ความล้มเหลวของ GPU เดียวทำให้คลัสเตอร์ที่ให้บริการโมเดลทั้งหมดหยุดทำงาน
การอัปเดตนี้มุ่งเป้าไปที่จุดปัญหาเฉพาะในการให้บริการโมเดล Mixture of Experts (MoE) ไม่เหมือนกับการปรับใช้โมเดลแบบดั้งเดิมที่แต่ละรีพลิกาทำงานอิสระ สถาปัตยกรรม MoE เช่น DeepSeek-V3 แบ่งชั้นผู้เชี่ยวชาญออกเป็นกลุ่มของ GPU ที่ต้องทำงานร่วมกัน เมื่อ GPU หนึ่งในการกำหนดค่าเหล่านี้ล้มเหลว กลุ่มทั้งหมดซึ่งอาจครอบคลุม 16 ถึง 128 GPU จะไม่สามารถทำงานได้
ปัญหาทางเทคนิค
โมเดล MoE กระจายเครือข่ายประสาทเทียม "ผู้เชี่ยวชาญ" เฉพาะทางไปยัง GPU หลายตัว ตัวอย่างเช่น DeepSeek-V3 มีผู้เชี่ยวชาญ 256 คนต่อชั้น แต่เปิดใช้งานเพียง 8 คนต่อโทเค็น โทเค็นจะถูกส่งไปยัง GPU ใดก็ตามที่เก็บผู้เชี่ยวชาญที่ต้องการผ่านการดำเนินการ dispatch และ combine ที่ต้องการให้ rank ที่เข้าร่วมทั้งหมดมีสุขภาพดี
ก่อนหน้านี้ ความล้มเหลวของ rank เดียวจะทำให้การดำเนินการร่วมกันเหล่านี้เสีย การสืบค้นจะยังคงส่งต่อไปยังรีพลิกาที่รอดชีวิตในกลุ่มที่ได้รับผลกระทบ แต่ทุกคำขอจะล้มเหลว การกู้คืนต้องการการรีสตาร์ทระบบทั้งหมด
วิธีที่ Ray แก้ไข
Ray Serve LLM ขณะนี้ถือว่าแต่ละกลุ่ม DP เป็นหน่วยอะตอมผ่าน gang scheduling เมื่อ rank หนึ่งล้มเหลว ระบบจะทำเครื่องหมายกลุ่มทั้งหมดว่าไม่แข็งแรง หยุดการส่งทราฟฟิกไปยังกลุ่มนั้น รื้อถอนกลุ่มที่ล้มเหลว และสร้างใหม่เป็นหน่วย กลุ่มที่แข็งแรงอื่นๆ ยังคงให้บริการคำขอตลอดเวลา
ฟีเจอร์นี้เปิดใช้งานโดยค่าเริ่มต้นใน Ray 2.55 การปรับใช้ DP ที่มีอยู่ไม่ต้องการการเปลี่ยนแปลงโค้ดใดๆ เฟรมเวิร์กจัดการการตรวจสอบสุขภาพระดับกลุ่ม การกำหนดเวลา และการกู้คืนโดยอัตโนมัติ
Autoscaling ยังเคารพขอบเขตเหล่านี้ด้วย การดำเนินการ Scale-up และ scale-down เกิดขึ้นในหน่วยขนาดกลุ่มมากกว่ารีพลิกาแต่ละตัว ป้องกันการสร้างกลุ่มบางส่วนที่ไม่สามารถให้บริการทราฟฟิกได้
ผลกระทบด้านการดำเนินงาน
การอัปเดตนี้สร้างข้อพิจารณาการออกแบบที่สำคัญ: ความกว้างของกลุ่มเทียบกับจำนวนกลุ่ม ตามเกณฑ์มาตรฐาน vLLM ที่อ้างโดย Anyscale ปริมาณงานต่อ GPU ยังคงค่อนข้างคงที่ในขนาดขนานของผู้เชี่ยวชาญที่ 32, 72 และ 96 ซึ่งหมายความว่าผู้ดำเนินการสามารถปรับไปยังกลุ่มที่เล็กลงโดยไม่สูญเสียประสิทธิภาพ และกลุ่มที่เล็กลงหมายถึงรัศมีการระเบิดที่เล็กลงเมื่อเกิดความล้มเหลว
Anyscale ระบุว่าความยืดหยุ่นระดับการจัดการนี้เสริมงานความยืดหยุ่นระดับเครื่องมือที่เกิดขึ้นในชุมชน vLLM vLLM Elastic Expert Parallelism RFC กล่าวถึงวิธีที่รันไทม์สามารถปรับโทโพโลยีภายในกลุ่มได้แบบไดนามิก ในขณะที่ Ray Serve LLM จัดการว่ากลุ่มใดมีอยู่และได้รับทราฟฟิก
สำหรับองค์กรที่ปรับใช้โมเดลสไตล์ DeepSeek ในระดับใหญ่ ประโยชน์ในทางปฏิบัติชัดเจน: ความล้มเหลวของ GPU กลายเป็นเหตุการณ์เฉพาะที่มากกว่าการหยุดทำงานทั้งระบบ ตัวอย่างโค้ดและขั้นตอนการทำซ้ำมีอยู่ใน GitHub repository ของ Anyscale
แหล่งที่มาของภาพ: Shutterstock- ray
- vllm
- โครงสร้างพื้นฐาน ai
- machine learning
- distributed computing







