IBM ยกระดับ Spyre Accelerator ให้เป็นแบ็กเอนด์ PyTorch ระดับชั้นหนึ่ง

IBM ระบุในบล็อกโพสต์ของ IBM Researchที่เผยแพร่เมื่อวันที่ 26 ตุลาคม 2026 ว่าการอัปเดตซอฟต์แวร์ทั่วระบบนิเวศ PyTorch ในช่วงครึ่งหลังของปี 2026 ทำให้ตัวเร่งการประมวลผลแบบดาต้าโฟลว์ Spyre ของบริษัทกลายเป็นแบ็กเอนด์ PyTorch ระดับชั้นหนึ่ง ซึ่งเป็นไปตามแผนที่ IBM และมูลนิธิ PyTorchวางไว้ในเดือนตุลาคม 2025

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

โพสต์ระบุว่า ในช่วงครึ่งหลังของปี 2026 IBM, Red Hat และผู้ร่วมงานในมูลนิธิ PyTorch ซึ่งรวมถึง Meta และ Hugging Face ได้เผยแพร่การอัปเดตที่ครอบคลุมการรองรับโมเดลตั้งแต่วันแรก โมเดลที่ไม่ขึ้นกับฮาร์ดแวร์ใน vLLM การทดสอบการถดถอยและการเผยแพร่อย่างต่อเนื่อง ตลอดจนการผสานรวมอุปกรณ์แบบเนทีฟ ในงาน PyTorch Conference 2025 นั้น IBM ระบุในโพสต์ของ IBM Researchลงวันที่ 21 ตุลาคม 2025 ว่ามีแผนเพิ่มการรองรับ Spyre ให้ลึกซึ้งยิ่งขึ้นในปี 2026 โดยให้ Spyre เข้าร่วมในเวิร์กโฟลว์การอนุมานแบบโอเพนซอร์สในฐานะแบ็กเอนด์ระดับชั้นหนึ่ง และมุ่งเน้นเส้นทางคอมไพเลอร์แบบรวม การสร้างเคอร์เนลที่ปรับแต่งให้มีประสิทธิภาพ และการจัดตารางตัวเร่งการประมวลผลหลายตัวอย่างโปร่งใส ก่อนหน้านั้น IBM ได้นำ vLLM มาใช้เป็นรันไทม์สำหรับการอนุมาน และใช้ torch.compile เป็นคอมไพเลอร์ส่วนหน้าเพื่อผสานรวมตัวเร่งการประมวลผล เช่น Spyre อีกทั้งยังมีส่วนร่วมพัฒนาปลั๊กอิน Spyre สำหรับ vLLM ซึ่งรองรับ paged attention สำหรับการอนุมานด้วยโมเดลภาษาขนาดใหญ่

คอมไพเลอร์ที่สร้างขึ้นใหม่บน Inductor

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

ในโพสต์ของมูลนิธิ PyTorchที่เผยแพร่เมื่อวันที่ 13 ตุลาคม 2026 Dave Grove, Olivier Tardieu และทีม IBM Spyre อธิบายถึงการย้ายแบ็กเอนด์ torch.compile ของ torch-spyre จาก sendnn ซึ่งเป็นสแต็กการคอมไพล์ที่สร้างขึ้นใหม่ทั้งหมด ไปใช้ backend=inductor ซึ่งเป็นแบ็กเอนด์โอเพนซอร์สที่พัฒนาต่อยอดจาก Inductor ของ PyTorch เอง ผู้เขียนรายงานว่า เมื่อวัดด้วยเครื่องมือวิเคราะห์โค้ด lizard พบว่า sendnn มีโค้ด C++ และ Python รวมประมาณ 273,000 บรรทัด ใน 6,170 ฟังก์ชัน ขณะที่ส่วนขยาย Inductor มีโค้ด Python ประมาณ 38,600 บรรทัด ใน 1,878 ฟังก์ชัน หรือน้อยกว่าราว 7 เท่า พร้อมความซับซ้อนต่อฟังก์ชันที่ต่ำกว่า

Spyre เป็นตัวเร่งการประมวลผลกำลัง 75 วัตต์ที่เชื่อมต่อผ่าน PCIe ประกอบด้วยคอร์ขนาดเล็ก 32 คอร์ที่เชื่อมต่อกันเป็นวงแหวน แต่ละคอร์มีหน่วยความจำ scratchpad ขนาด 2 MB ของตัวเองแทนการใช้แคชร่วมกัน และรับส่งข้อมูลเป็นชุดขนาดคงที่ 128 ไบต์ที่เรียกว่า sticks โพสต์ระบุว่า งานพัฒนาคอมไพเลอร์มุ่งเน้นการรับส่งข้อมูลในระดับ stick การวางแผนใช้ scratchpad และการกำหนดคอร์ในเวลาคอมไพล์

ผลการวัดที่รายงานประกอบด้วยเวลาทำงานของเคอร์เนล matmul ที่ลดลง 29–69% จากการเลือกวิธีแบ่งงานเป็นไทล์และรูปแบบการจัดวางข้อมูล เวลาทำงานมัธยฐานของเคอร์เนล softmax ที่ลดจาก 32.51 ไมโครวินาทีเหลือ 23.67 ไมโครวินาที หรือคิดเป็นการลดลง 27% จากการจัดตารางงานที่คำนึงถึง scratchpad และเคอร์เนลรูปแบบ MLP ที่รวมการทำงานหลายขั้นเข้าด้วยกัน ซึ่งเพิ่มการใช้ประโยชน์จากคอร์จากประมาณสองในสามเป็นราว 80% พร้อมลดเวลาทำงานของเคอร์เนลลงประมาณ 17% ในกราฟสังเคราะห์ที่สร้างขึ้นเพื่อทดสอบการตัดสินใจเหล่านี้ การจัดเรียงข้อมูลใหม่บนชิปแบบใหม่ช่วยแทนที่การรับส่งข้อมูลไปกลับระหว่างหน่วยความจำอุปกรณ์ซึ่งใช้เวลา 80 ไมโครวินาที ด้วยการสลับข้อมูลระหว่างคอร์ที่ใช้เวลา 1.1 ไมโครวินาที นอกจากนี้ โพสต์ยังระบุด้วยว่า ความจำเป็นที่ torch-spyre ต้องลงทะเบียนการแยกการดำเนินการเฉพาะอุปกรณ์มีส่วนผลักดันให้เกิดการปรับปรุงการรองรับแบ็กเอนด์ Inductor ภายนอกซอร์สทรี ซึ่งถูกรวมเข้ากับ PyTorch 2.12 ผ่านคำขอรวมโค้ด 2 รายการ

การผสานรวมอุปกรณ์แบบเนทีฟ

Spyre กลายเป็นอุปกรณ์ PyTorch แบบเนทีฟผ่านการลงทะเบียน PrivateUse1 ซึ่งทำให้ tensor.to(“spyre”) มีตัวตนอุปกรณ์จริง โดยพื้นที่จัดเก็บที่จัดสรรผ่านตัวจัดสรรหน่วยความจำของ PyTorch จะเก็บเทนเซอร์ไว้บนอุปกรณ์ สตรีมจะกำหนดลำดับการทำงาน และอีเวนต์รันไทม์จะเชื่อมโยงงานที่ขึ้นต่อกันระหว่างสตรีม การ์ดนี้มี 32 คอร์ที่เชื่อมต่อกันด้วยวงแหวนแบนด์วิดท์สูง แต่ละคอร์มี scratchpad ในเครื่องขนาด 2 MB และรองรับ LPDDR5 ได้สูงสุด 128 GB สำหรับเก็บเทนเซอร์และโปรแกรม นอกจากนี้ รันไทม์ปัจจุบันยังปรับโปรแกรมเมื่อเริ่มทำงาน โดยแทนที่ที่อยู่เทนเซอร์เชิงสัญลักษณ์ด้วยที่อยู่จริงตามลำดับ 3 ขั้นตอน

ทีมงานรายงานว่า ในการสาธิตด้วย Granite 3.3 8B ที่ขนาดแบตช์ 1 และความยาวลำดับ 1024 การย้ายการสร้างกราฟออกจากเส้นทางการถ่ายโอนข้อมูลช่วยเพิ่มประสิทธิภาพขั้นตอน prefill 9.9% และขั้นตอน decode 13.6% เมื่อนำงานดังกล่าวออกจากการส่งงานไปประมวลผลด้วย ผลรวมเพิ่มเป็น prefill ที่เร็วขึ้น 1.7 เท่า และ decode ที่เร็วขึ้น 2.4 เท่า โดยประมาณสามในสี่ของประสิทธิภาพที่เพิ่มขึ้นมาจากเส้นทางการประมวลผล

ผู้เขียนระบุในการสร้าง Spyre ให้เป็นอุปกรณ์ PyTorch แบบเนทีฟซึ่งเผยแพร่เมื่อวันที่ 8 ตุลาคม 2026 ว่า “ข้อดีคือทั้ง Spyre และ PyTorch ไม่จำเป็นต้องแสร้งทำเป็นอย่างอื่น” พร้อมเสริมว่า Spyre ยังคงใช้รูปแบบการทำงานแบบดาต้าโฟลว์ ขณะที่ผู้ใช้จะได้อุปกรณ์ PyTorch แบบเนทีฟที่รองรับการจัดวางเทนเซอร์ สตรีม และการคอมไพล์ในรูปแบบที่คุ้นเคย

ความสามารถในการพกพาของ vLLM และการเชื่อมต่อกับ Llm-D

Spyre เป็นตัวเร่งความเร็วแบบนอกแผนผังซอร์สโค้ด ไม่ใช่หนึ่งในแพลตฟอร์ม GPU ที่ซอฟต์แวร์ AI รองรับกันโดยทั่วไป โดยอาศัย TorchDynamo ในการติดตามกราฟของโมเดล และ TorchInductor ในการแปลงกราฟดังกล่าวให้ทำงานบนฮาร์ดแวร์เป้าหมาย ภายใน vLLM กลไกส่วนขยายอย่าง CustomOp และ PluggableLayer ช่วยให้ปลั๊กอินฮาร์ดแวร์ปรับแต่งการทำงานได้ โดยไม่ต้องสร้างซอฟต์แวร์สแต็กส่วนใหญ่ขึ้นมาใหม่

ในบทความ โมเดลใน vLLM ที่ไม่ยึดติดกับฮาร์ดแวร์ ซึ่งเผยแพร่เมื่อวันที่ 22 กันยายน 2026 โดยผู้เขียนจาก IBM, Meta และ Hugging Face ทีมงานได้อธิบายการเปลี่ยนทิศทางของ vLLM จากการกำหนดโมเดลแบบ “แบน” ที่เจาะจงกับฮาร์ดแวร์ และนำเสนอเลเยอร์ที่ไม่ยึดติดกับฮาร์ดแวร์ซึ่งพัฒนาตามหลักการออกแบบ 4 ประการ ได้แก่ คอมไพล์ได้ ขยายความสามารถได้ แยกจากเส้นทางการทำงานที่เจาะจงกับฮาร์ดแวร์ และพกพาไปใช้ได้ ขณะนี้มีการรองรับเบื้องต้นในสาขาหลักของ vLLM แล้ว และเปิดใช้งานได้ด้วย USE_HW_AGNOSTIC=1 บนแบ็กเอนด์ transformers มีการตรวจสอบเส้นทางการทำงานนี้กับปลั๊กอิน Spyre แบบนอกแผนผังซอร์สโค้ด โดยใช้โมเดลต่าง ๆ ซึ่งรวมถึง Gemma 4, Qwen3 และ Granite 4.2 ผู้เขียนรายงานว่า เมื่อใช้ GPU NVIDIA H100 เลเยอร์ที่ไม่ยึดติดกับฮาร์ดแวร์ทำให้ปริมาณโทเค็นที่ประมวลผลได้โดยรวมอยู่ในระยะไม่เกิน 3.4% จากการทำงานแบบเนทีฟ โดยคำนวณจากค่าเฉลี่ยเรขาคณิตของโมเดลรุ่นใหม่ 3 รุ่น

บทความของ IBM อธิบายว่า การผสานรวม Spyre เข้ากับ PyTorch เป็นช่องทางที่ทำให้ Spyre เชื่อมต่อกับ llm-d ได้ด้วย โดย llm-d ใช้ vLLM เพื่อประมวลผลการอนุมานแบบกระจายบนตัวเร่งความเร็วหลายประเภท ส่วน vLLM เข้าถึงตัวเร่งความเร็วแต่ละประเภทผ่าน PyTorch และเมื่ออุปกรณ์ใดมีแบ็กเอนด์ PyTorch ที่ใช้งานได้ ปลั๊กอินฮาร์ดแวร์ของ vLLM ก็สามารถเปิดให้อุปกรณ์นั้นใช้งานได้ เพื่อให้ llm-d จัดสรรงานไปประมวลผลบนอุปกรณ์ดังกล่าว

เปิดใช้งานได้ตั้งแต่วันแรกและทดสอบอย่างต่อเนื่อง

บทความวันที่ 20 สิงหาคม 2026จากทีม IBM Spyre อธิบายถึง HF-adapters ซึ่งเป็นโครงการที่ใช้เอเจนต์เขียนโค้ดร่างแพตช์ขณะรันไทม์ เพื่อให้โมเดล Hugging Face Transformers ที่ยังไม่ได้ดัดแปลงสามารถทำงานบน Spyre ได้ บทความรายงานว่า ตั้งแต่กลางเดือนเมษายนถึงปลายเดือนมิถุนายน 2026 มีอะแดปเตอร์ที่แตกต่างกัน 13 รายการ ครอบคลุมโมเดลฝังเวกเตอร์ Hugging Face ที่มียอดดาวน์โหลดสูงสุด 10,000 รุ่นจำนวน 7,960 รุ่น โดยในจำนวนนี้ 6,804 รุ่นผ่านการทดสอบตั้งแต่ต้นจนจบบน Spyre ตัวอย่างหนึ่งคือการแทนที่ torch.pow(x, 3.0) ในฟังก์ชันกระตุ้น gelu_new ด้วย x x x ซึ่งให้ผลทางคณิตศาสตร์เหมือนกัน และสแต็ก torch-spyre สามารถแปลงไปทำงานได้ ขณะที่มนุษย์ยังคงรับผิดชอบการวินิจฉัย โดยระบุตำแหน่งข้อผิดพลาดที่เกิดเฉพาะบนอุปกรณ์จากการดำเนินการแบบฟิวชัน และตรวจสอบข้อสรุปของเอเจนต์แต่ละตัวกับผลการทดสอบตั้งแต่ต้นจนจบ

ในบทความวันที่ 30 กันยายน 2026 วิศวกรจาก IBM และ Red Hat อธิบายการผสานรวมระดับ L2 ของ torch-spyre เข้ากับ Cross-Repository CI Relay ของ PyTorch ซึ่งเริ่มการทดสอบในโปรเจกต์ปลายทางเมื่อ PyTorch ต้นทางมีการเปลี่ยนแปลง และรายงานผลกลับไปยังแดชบอร์ด CI ของ PyTorch การผสานรวมนี้จับคู่ไปป์ไลน์เลือกการทดสอบแบบเอเจนต์ 4 ขั้นตอนเข้ากับเฟรมเวิร์กนำการทดสอบกลับมาใช้ซ้ำที่กำหนดด้วย YAML ผู้เขียนระบุว่า การอัปเกรดจาก PyTorch 2.13 เป็น 2.14 ทำให้ต้องประเมินการทดสอบที่เปลี่ยนแปลงประมาณ 4,000 รายการ แทนที่จะเป็นหลักหมื่นรายการ พร้อมเสริมว่าตั้งใจจะร่วมมือกับทีม PyTorch เพื่อนำส่วนที่นำกลับมาใช้ซ้ำได้เข้าไปไว้ในโครงการต้นทาง โดยใช้ PyTorch OpenReg เป็นจุดอ้างอิง

บทความของ IBM ระบุว่า สำหรับผู้ใช้ IBM Z, LinuxONE และ Power11 ประสบการณ์ที่ต้องการคือการดาวน์โหลดโมเดลจากระบบนิเวศต่าง ๆ เช่น Hugging Face แล้วใช้เวิร์กโฟลว์ที่ทำงานบน PyTorch ซึ่งแทบไม่ต่างจากเวิร์กโฟลว์ที่ใช้กับ GPU ของ Nvidia โดยจุดขยายการทำงานร่วมกันของ PyTorch ช่วยซ่อนความแตกต่างทางสถาปัตยกรรมไว้เป็นส่วนใหญ่ ผู้เขียนบทความเกี่ยวกับ vLLM ระบุว่ามีแผนจะเริ่มนำโมเดลที่ไม่ยึดติดกับฮาร์ดแวร์เข้าไว้ใน CI และค่อย ๆ เปลี่ยนมาใช้เส้นทางนี้เป็นค่าเริ่มต้นสำหรับการให้บริการโมเดลบน Spyre