โซลูชันสร้างสรรค์ของนักพัฒนาคนหนึ่งสำหรับแก้ปัญหาการติดตั้ง PyTorch ข้ามแพลตฟอร์มที่มีชื่อเสียงในด้านความยุ่งยากได้เจออุปสรรคใหญ่ วิธีการนี้ซึ่งใช้ URL ของ wheel โดยตรงเพื่อจัดการกับ hardware accelerator และระบบปฏิบัติการที่แตกต่างกัน กลับกลายเป็นว่าไม่เข้ากันกับข้อกำหนดการเผยแพร่ของ PyPI
โซลูชันเดิมพยายามแก้ไขความหงุดหงิดที่แพร่หลายในชุมชน Python machine learning การติดตั้ง PyTorch มักจะล้มเหลวหรือติดตั้งเวอร์ชันที่ไม่ถูกต้องขึ้นอยู่กับการตั้งค่าฮาร์ดแวร์ของผู้ใช้ - ไม่ว่าจะมี GPU ของ NVIDIA, กราฟิกของ AMD, Intel XPU accelerator หรือต้องการเวอร์ชันที่ใช้ CPU เท่านั้น ความซับซ้อนเพิ่มขึ้นเมื่อต้องรองรับระบบปฏิบัติการและเวอร์ชัน Python ที่แตกต่างกัน
ข้อจำกัดการเผยแพร่ของ PyPI สร้างอุปสรรคใหม่
การแก้ไขที่เสนอใช้ PEP 508 dependency specifications เพื่อลิงก์โดยตรงไปยังไฟล์ wheel ของ PyTorch ที่โฮสต์บนเซิร์ฟเวอร์ของ PyTorch สิ่งนี้ช่วยให้นักพัฒนาสามารถระบุ URL ของ wheel ที่แน่นอนสำหรับการกำหนดค่าฮาร์ดแวร์ที่แตกต่างกัน รวมกับข้อจำกัดเวอร์ชัน Python อย่างไรก็ตาม สมาชิกในชุมชนได้ชี้ให้เห็นข้อบกพร่องที่สำคัญอย่างรวดเร็ว: PyPI ห้ามการอ้างอิงโดยตรงในการแจกจ่ายที่อัปโหลดอย่างชัดเจน
ตามแนวทางของ PyPI เซิร์ฟเวอร์ดัชนีสาธารณะไม่ควรอนุญาตการอ้างอิงโดยตรงใน package metadata นโยบายนี้มีอยู่เพราะการอ้างอิงโดยตรงมีไว้สำหรับผู้รวมซอฟต์แวร์ ไม่ใช่ผู้เผยแพร่ ข้อจำกัดนี้หมายความว่าแพ็กเกจใดๆ ที่ใช้วิธีการนี้ไม่สามารถอัปโหลดไปยัง PyPI ได้ ซึ่งจำกัดประโยชน์ใช้สอยสำหรับการแจกจ่ายสาธารณะอย่างรุนแรง
รูปแบบการระบุ Dependency ของ PEP 508:
- รูปแบบพื้นฐาน:
package-name @ wheel-url; python_version == "version" - รองรับข้อจำกัดของฮาร์ดแวร์และการกำหนดเป้าหมายเวอร์ชัน Python
- ถูกบล็อกโดย PyPI สำหรับการแจกจ่ายแพ็กเกจสาธารณะ
- มีจุดประสงค์สำหรับผู้รวมซอฟต์แวร์ ไม่ใช่ผู้เผยแพร่
ชุมชนแนะนำ Package Manager ทางเลือก
นักพัฒนาที่มีประสบการณ์ในการสนทนาเน้นย้ำว่า conda และ mamba ยังคงเป็นโซลูชันที่เชื่อถือได้มากที่สุดสำหรับการติดตั้ง PyTorch package manager เหล่านี้สามารถตรวจจับการกำหนดค่าฮาร์ดแวร์และติดตั้งเวอร์ชันที่เหมาะสมโดยอัตโนมัติ ต่างจาก pip พวกมันจัดการแพ็กเกจที่คอมไพล์แล้วได้อย่างมีประสิทธิภาพมากกว่าและหลีกเลี่ยงข้อผิดพลาดทั่วไปของการติดตั้งแพ็กเกจ CUDA ขนาดใหญ่บนระบบที่ไม่รองรับ
ฉันพบว่ามันเป็น package manager เดียวสำหรับ python ที่จะตรวจจับฮาร์ดแวร์ของฉันได้อย่างน่าเชื่อถือและติดตั้งเวอร์ชันที่ถูกต้องของ dependency ทุกตัว
สมาชิกในชุมชนหลายคนยังเน้นเครื่องมือใหม่ๆ เช่น Pixi ซึ่งรวมการจัดการแพ็กเกจ conda และ PyPI ในอินเทอร์เฟซเดียว เครื่องมือทางเลือกเหล่านี้มีการตรวจจับฮาร์ดแวร์ที่ดีกว่าและสามารถเลือกเวอร์ชัน PyTorch ที่ดีที่สุดสำหรับระบบเฉพาะโดยอัตโนมัติ
ตัวเลือกการติดตั้ง PyTorch แยกตามแพลตฟอร์ม:
| แพลตฟอร์ม | เครื่องมือที่แนะนำ | การตรวจจับฮาร์ดแวร์ | รองรับ CUDA |
|---|---|---|---|
| Linux | conda/mamba | อัตโนมัติ | รองรับ |
| Windows/Mac | pip (ค่าเริ่มต้น) | แบบแมนนวล | รองรับจำกัด |
| ข้ามแพลตฟอร์ม | Pixi | อัตโนมัติ | รองรับ |
| เฉพาะทาง | torchruntime | อัตโนมัติ | รองรับ |
 |
|---|
| องค์ประกอบนามธรรมนี้จับแก่นแท้ของโซลูชันที่เป็นนวัตกรรมใหม่ที่เกิดขึ้นในขอบเขตของการติดตั้ง PyTorch |
ปัญหาการแพ็กเกจในวงกว้างยังคงอยู่
โซลูชันที่ล้มเหลวเน้นให้เห็นปัญหาที่ลึกกว่าของการแพ็กเกจ Python สำหรับไลบรารีที่เฉพาะเจาะจงกับฮาร์ดแวร์ ความซับซ้อนของ PyTorch เกิดจากความจำเป็นในการปรับให้เหมาะสมสำหรับ GPU หลายสิบประเภทและระบบปฏิบัติการหลายตัว สิ่งนี้สร้างความไม่ตรงกันพื้นฐานกับระบบการแพ็กเกจของ Python ซึ่งถือว่าแพลตฟอร์มฮาร์ดแวร์ที่แตกต่างกันอย่างมีนัยสำคัญเป็นสิ่งเดียวกัน
นักพัฒนาบางคนประสบความสำเร็จกับเครื่องมือเฉพาะทาง เช่น torchruntime ซึ่งจัดการการติดตั้ง PyTorch แยกจากการจัดการแพ็กเกจทั่วไป คนอื่นๆ ยืนยันว่าวิธีการที่เชื่อถือได้เพียงอย่างเดียวคือการหลีกเลี่ยง PyTorch dependencies ในโค้ดที่คอมไพล์แล้วทั้งหมด โดยใช้เทคนิคเช่น ctypes เพื่อโหลดไลบรารีแบบไดนามิก
การสนทนาเผยให้เห็นว่าแม้วิธีแก้ปัญหาเชิงสร้างสรรค์จะยังคงเกิดขึ้นต่อไป แต่ความตึงเครียดพื้นฐานระหว่างข้อจำกัดการแพ็กเกจของ Python และข้อกำหนดการปรับให้เหมาะสมเฉพาะฮาร์ดแวร์ยังคงไม่ได้รับการแก้ไข จนกว่าการแพ็กเกจ Python จะพัฒนาให้เข้าใจแพลตฟอร์มฮาร์ดแวร์ได้ดีขึ้น หรือ PyTorch จะทำให้โมเดลการแจกจ่ายง่ายขึ้น นักพัฒนาจะยังคงเผชิญกับฝันร้ายการติดตั้งเหล่านี้ต่อไป