Llm-D 1.0 เปิดตัวพร้อมชุดระบบอนุมานสำหรับใช้งานจริงในงาน PyTorch Conference

ผู้ร่วมพัฒนาโครงการ llm-d ประกาศเปิดตัว llm-d 1.0 ซึ่งเป็นชุดระบบให้บริการการอนุมานแบบกระจายที่ทำงานบน Kubernetes โดยกำเนิด เมื่อวันที่ 20 ตุลาคม 2026 ในงาน PyTorch Conference North America ตามประกาศจาก IBM Research IBM ระบุว่าการเปิดตัวครั้งนี้ทำให้ llm-d ก้าวข้ามการสาธิตเทคนิคเพิ่มประสิทธิภาพแต่ละอย่าง และมีเป้าหมายเพื่อช่วยให้องค์กรนำการติดตั้งใช้งานโมเดลมาดำเนินการภายในองค์กร ขณะที่ต้นทุนการอนุมานเพิ่มสูงขึ้น

llm-d พัฒนาขึ้นเพื่อให้ติดตั้งใช้งานชุดระบบอนุมานสำหรับโมเดลใดก็ได้ บนตัวเร่งประมวลผลใดก็ได้ และในคลาวด์ใดก็ได้ Red Hat, IBM และ Google เป็นผู้ดูแลหลักของโครงการ และร่วมก่อตั้ง llm-d กับ CoreWeave และ NVIDIA ส่วน AMD, Cisco, Hugging Face, Intel, Lambda และ Mistral AI เข้าร่วมในฐานะผู้ร่วมพัฒนา Cloud Native Computing Foundation (CNCF) เป็นผู้ดูแล llm-d ในฐานะโครงการระดับแซนด์บ็อกซ์ IBM อธิบายว่าโครงการนี้เป็นทางเลือกที่ไม่ผูกกับผู้จำหน่ายรายใดรายหนึ่ง สำหรับองค์กรที่ต้องการประสิทธิภาพการอนุมานระดับแนวหน้าตามที่บริษัทเรียก โดยไม่ต้องพึ่งพาผู้ให้บริการโมเดลแบบกรรมสิทธิ์ คลาวด์ หรือแพลตฟอร์มฮาร์ดแวร์รายใดรายหนึ่งทั้งหมด

Carlos Costa วิศวกรดีเด่นแห่ง IBM Research ผู้ร่วมก่อตั้งและผู้ดูแลหลักของ llm-d กล่าวว่าเวอร์ชัน 1.0 เพิ่มความพร้อมให้สามารถใช้งาน llm-d ได้เช่นเดียวกับบริการสำคัญอื่น ๆ โดยชี้ถึง API ที่มีเสถียรภาพ การรองรับผู้เช่าหลายรายที่มีลำดับความสำคัญแตกต่างกันและใช้โครงสร้างพื้นฐานเดียวกันร่วมกัน ตลอดจนการอัปเกรดที่ไม่ทำให้การดำเนินงานหยุดชะงัก

สิ่งที่เพิ่มเข้ามาในเวอร์ชัน 1.0

บันทึกประจำรุ่น v1.0.0 ของโครงการ ซึ่งเผยแพร่บน GitHub เมื่อวันที่ 20 ตุลาคม 2026 พร้อมแท็กที่ลงนามและตรวจสอบยืนยันแล้ว ระบุคุณภาพการให้บริการสำหรับผู้เช่าหลายรายเป็นหัวข้อแรก โดยมีการควบคุมการไหลที่คำนึงถึงลำดับความสำคัญและความเป็นธรรม พร้อมการลดภาระงานอย่างมีการควบคุม ซึ่งรวมถึงกลไกอนุมัติคำขอแบบอาศัยความน่าจะเป็น การจัดสรรอย่างเป็นธรรมโดยคำนึงถึงโปรแกรม และการให้คะแนนลำดับความสำคัญของแต่ละรอบการสนทนา ทั้งหมดนี้ช่วยให้คำขอที่ไวต่อเวลาแฝงและภาระงานของเอเจนต์ที่เกิดขึ้นเป็นระยะ ๆ ใช้กลุ่มทรัพยากรร่วมกันได้ โดยไม่แย่งทรัพยากรจนอีกฝ่ายไม่ได้รับบริการเมื่อระบบมีภาระเกินขีดรองรับ การตั้งค่าควบคุมการไหลถูกรวมไว้ในฟิลด์ flowControl เดียว

เพื่อให้ระบบทำงานได้โดยไม่หยุดให้บริการ เราเตอร์ได้รับการรองรับความพร้อมใช้งานสูงด้วยระบบสำรองที่พร้อมทำงานทันทีและการอัปเดตแบบทยอยเปลี่ยนอย่างปลอดภัย ส่วนคอนโทรลเลอร์ DisaggregatedSet จะจัดการเรพลิกาสำหรับการประมวลผลช่วงเตรียมข้อมูลนำเข้าและช่วงถอดรหัสให้เป็นหน่วยเชิงตรรกะเดียวกัน พร้อมการทยอยปรับใช้ที่ประสานงานกัน การอัปเกรดแบบทำงานพร้อมกัน การกำหนดความพร้อมใช้งานโดยอิงสแนปช็อตของ Pod และการกำหนดเส้นทางตามรีวิชันแบบเนทีฟ API สำหรับกำหนดค่าเราเตอร์เข้าสู่สถานะ v1 ส่วน Responses API รองรับ previous_response_id และปรับปรุงเส้นทางคำขอของตัวเลือกเอนด์พอยต์ให้มีความน่าเชื่อถือ ประสิทธิภาพ และความสามารถในการปรับขนาดดียิ่งขึ้น นอกจากนี้ยังมีคู่มือสำหรับตัวเร่งประมวลผลที่คำนึงถึงโครงสร้างโทโพโลยี ซึ่งครอบคลุม DRA และ DRANET

การให้บริการที่คำนึงถึงเอเจนต์เพิ่มปลั๊กอิน session-state-producer และการปรับความสัมพันธ์กับเซสชันอย่างต่อเนื่อง เพื่อให้การสนทนาหลายรอบอยู่ใกล้กับบริบทที่แคชไว้ พร้อมการจัดตารางงานตามลำดับความสำคัญของแต่ละรอบการสนทนาและสถานะจาก Responses API ซึ่งช่วยให้เอเจนต์นำบริบทกลับมาใช้ซ้ำในรอบต่าง ๆ ได้ รุ่นนี้ปรับองค์ประกอบต่าง ๆ ของโครงการให้สอดคล้องกันที่ v1.0.0 เพิ่มส่วนประกอบในระบบนิเวศ ได้แก่ การผสานรวมกับ ai-dynamo/modelexpress เพื่อโหลดน้ำหนักโมเดลระหว่างเพียร์ต่อเพียร์ แพ็กเกจ llm-d-api-extensions และเครื่องมือวินิจฉัย llm-d-pd-utils อีกทั้งเลิกใช้บิลด์อิมเมจคอนเทนเนอร์ llm-d-rocm ของโครงการเอง อิมเมจสำหรับเซิร์ฟเวอร์โมเดลมีบิลด์ของ vLLM และ SGLang ครอบคลุมเป้าหมายตัวเร่งประมวลผลต่าง ๆ ส่วนคู่มือการแยกการประมวลผลช่วงเตรียมข้อมูลนำเข้าและช่วงถอดรหัสกำหนดให้ใช้ LeaderWorkerSet v0.11.1 หรือใหม่กว่า พร้อมเปิดใช้ API ของ DisaggregatedSet

เทคนิคหลักและการควบคุมการไหล

นับตั้งแต่เปิดตัว โครงการมุ่งเน้นแนวทางห้าประการเพื่อปรับปรุงการอนุมาน ได้แก่ การกำหนดเส้นทางที่คำนึงถึงแคชคำนำหน้า ซึ่งส่งคำขอไปยังโครงสร้างพื้นฐานที่อาจมีบริบทที่ใช้ร่วมกันเก็บไว้อยู่แล้ว การถ่ายโอนแคช KV ซึ่งย้ายข้อมูลที่แคชไว้ระหว่างทรัพยากร GPU, CPU และพื้นที่จัดเก็บข้อมูล การเพิ่มประสิทธิภาพการอนุมานแบบกลุ่ม การแยกการประมวลผลช่วงเตรียมข้อมูลนำเข้าออกจากช่วงถอดรหัส ซึ่งแยกการอ่านพรอมป์ต์ออกจากการสร้างคำตอบ และการประมวลผลแบบขนานสำหรับผู้เชี่ยวชาญจำนวนมาก ซึ่งกระจายโมเดลแบบ mixture-of-experts ขนาดใหญ่ไปยังตัวเร่งประมวลผลหลายตัว เทคนิคเหล่านี้มีมาก่อนเวอร์ชัน 1.0 แล้ว โดย IBM ระบุว่าสิ่งใหม่คือการผสานรวมเทคนิคเหล่านี้และยกระดับความพร้อมด้านการปฏิบัติงาน รวมถึงวินัยในการปฏิบัติการวันที่สองเพื่อรักษาประสิทธิภาพเมื่อปริมาณการรับส่งข้อมูลเปลี่ยนแปลง ฮาร์ดแวร์ขัดข้อง ซอฟต์แวร์ได้รับการอัปเดต หรือผู้ใช้ต่างรายแย่งใช้ทรัพยากรเดียวกัน

ในเวอร์ชัน 1.0 การควบคุมการไหล ความเป็นธรรม และการจัดลำดับความสำคัญมีเป้าหมายเพื่อป้องกันไม่ให้ภาระงานที่เกิดขึ้นเป็นระยะ ๆ ทำให้บริการที่ไวต่อเวลาแฝงมีภาระเกินขีดรองรับ ไม่ว่าภาระงานเหล่านั้นจะใช้ฮาร์ดแวร์เดียวกันหรือครอบคลุมตัวเร่งประมวลผลหลายชนิด และยังสามารถตรึงคำขอไว้กับโครงสร้างพื้นฐานที่เหมาะสมตลอดหลายรอบการสนทนา เพื่อรักษาแคชคำนำหน้าให้พร้อมใช้งาน llm-d ทำงานร่วมกับเอนจินอนุมานอย่าง vLLM หรือ SGLang โดยเพิ่มความสามารถด้านการกำหนดเส้นทางแบบกระจายและการปฏิบัติงานไว้บนเอนจินเหล่านั้น Stephen Watt รองประธานในสำนักงานประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของ Red Hat กล่าวว่า llm-d เชื่อมระบบนิเวศของ PyTorch และ CNCF เข้าด้วยกัน ด้วยการนำการจัดการระบบแบบเนทีฟของ Kubernetes มาใช้กับ vLLM และเอนจินอนุมานสมัยใหม่โดยตรง

ผลลัพธ์ที่สาธิตและต้นทุนที่ระบุไว้

ในโพสต์ผลการทดสอบมาตรฐานที่เผยแพร่เมื่อวันที่ 22 กรกฎาคม 2026 โครงการนี้วัดประสิทธิภาพการให้บริการโมเดล GLM-5.2 ด้วยเอเจนต์ โดยโพสต์ระบุว่าเป็นโมเดลแบบผสมผู้เชี่ยวชาญ (mixture-of-experts) ขนาด 744B พารามิเตอร์ มีพารามิเตอร์ที่ทำงานอยู่ 39B ตัว และมี 78 เลเยอร์ การวิเคราะห์ภาระงานอ้างอิงเซสชันการใช้งานจริง 219 เซสชันของ Claude Code ซึ่งคำขอจากเอเจนต์หลักมีโทเค็นอินพุตค่ามัธยฐาน 195K และส่งคืนโทเค็นเอาต์พุต 317 โทเค็น อีกทั้ง 96% ของรอบการทำงานของเอเจนต์หลักนำอินพุตกลับมาใช้ซ้ำอย่างน้อย 90% โพสต์ระบุว่าการกำหนดเส้นทางที่คำนึงถึงคำนำหน้าจับการใช้แคชซ้ำได้ 96–97% ของปริมาณที่ภาระงานเอื้อให้ทำได้ หากคิดค่าเช่า H200 ที่สมมติไว้ 2.71 ดอลลาร์ต่อ GPU-hour การให้บริการแบบโฮสต์เองบนการจัดวาง GPU สองรูปแบบซึ่งแต่ละรูปแบบใช้ GPU 64 ตัว จะมีค่าใช้จ่าย 0.05–0.08 ดอลลาร์ต่อโทเค็นอินพุตหนึ่งล้านโทเค็น และ 1.92–3.55 ดอลลาร์ต่อโทเค็นเอาต์พุตหนึ่งล้านโทเค็น โดยผู้เขียนระบุว่าตัวเลขเหล่านี้ครอบคลุมเฉพาะค่าเช่า GPU และตั้งสมมติฐานว่ามีภาระงานต่อเนื่อง

ในการสาธิตอีกครั้ง IBM และ Red Hat นำ GLM-5.2 ไปใช้งานบน GPU NVIDIA H100 จำนวน 544 ตัว โดยในบัญชีของ IBM Research ระบุว่าโมเดลนี้มีพารามิเตอร์ประมาณ 753 พันล้านตัว เป็นโมเดลแบบเปิดน้ำหนัก และมีพารามิเตอร์ที่ทำงานอยู่ประมาณ 39 พันล้านตัว IBM รายงานว่าการติดตั้งใช้งานนี้ทำได้สูงสุดมากกว่า 6.6 ล้านโทเค็นเอาต์พุตต่อนาที ขณะให้บริการเอเจนต์เขียนโค้ดพร้อมกันได้สูงสุด 3,000 ตัวโดยไม่มีการหยุดงานก่อนกำหนด และที่ระดับการทำงานซึ่งมีเอเจนต์ 2,500 ตัว ระบบรองรับคำขอได้อย่างต่อเนื่อง 7,612 รายการต่อนาที IBM ระบุว่า ณ อัตราค่าเช่าคลาวด์ในปัจจุบัน การโฮสต์ GLM-5.2 เองบน GPU H100 ด้วย llm-d มีต้นทุนต่อโทเค็นต่ำกว่าราคาของ API เชิงพาณิชย์ที่เทียบเท่ากัน 5 ถึง 10 เท่า Maroon Ayoub วิศวกรแมชชีนเลิร์นนิงระดับอาวุโสขั้นสูงในทีมวิศวกรรมระบบอนุมานของ Red Hat กล่าวว่า “การให้บริการเอเจนต์พร้อมกันหลายพันตัวโดยไม่มีการหยุดงานก่อนกำหนด ทำให้ผู้ปฏิบัติงานมีแนวทางที่น่าเชื่อถือในการเปลี่ยนผลการทดสอบมาตรฐานให้เป็นการติดตั้งใช้งานจริง”

ตามบัญชีเดียวกัน เบื้องหลังผลลัพธ์เหล่านั้น ระนาบข้อมูลแบบแยกส่วนดำเนินการถ่ายโอนแคช KV จำนวน 6.2 ล้านครั้ง โดยแต่ละครั้งมีขนาดเฉลี่ย 2.71 GiB และไม่มีการถ่ายโอนล้มเหลวเลย อีกทั้งการทดสอบมาตรฐานทั้งหมดเสร็จสิ้นโดยไม่มีข้อผิดพลาดในการให้บริการ