จบในบรรทัดเดียวด้วย `pip install torch` — การบ้านเรื้อรังของ Python packaging กำลังถูกแก้ได้ในที่สุดหรือไม่
(talkpython.fm)NVIDIA·Astral·Quansight ร่วมกันเปิดตัว Wheel Next: มาตรฐานแพ็กเกจจิ้งยุคถัดไปที่ไม่แบ่งแยก CPU·GPU
ที่มา: Talk Python To Me, Episode #544 |
เบื้องหลัง: วงล้อที่หยุดอยู่กับปี 2009
เมื่อรัน pip install numpy จะมีไบนารีตัวไหนถูกติดตั้ง? ไม่ว่าคุณจะใช้ CPU รุ่นใหม่อย่าง AMD Zen 4 หรือ Apple M4 ก็ตาม wheel ที่ถูกติดตั้งนั้นถูก build มาให้ใช้ได้แค่ ชุดคำสั่ง x86-64 ระดับปี 2009 เท่านั้น
แม้จะอยากใช้คำสั่ง SIMD รุ่นใหม่อย่าง SSE4 หรือ AVX2 ตัว installer ก็ไม่มีทางรู้ได้ว่าระบบรองรับความสามารถเหล่านี้หรือไม่ ผลลัพธ์คือสำหรับแพ็กเกจอย่าง PyTorch เราได้ไฟล์ไบนารีขนาดมหึมาเกือบ 900MB และหน้าเอกสารการติดตั้งที่ซับซ้อนราวกับ “หนังสือปริศนา”
NVIDIA, Astral และ Quansight กำลังผลักดันโครงการ Wheel Next เพื่อแก้ปัญหานี้ โดยมีแกนหลักเป็นชุด PEP ที่เปิดทางให้แพ็กเกจประกาศฮาร์ดแวร์ที่ต้องการ และให้ installer อย่าง uv เลือก build ที่ถูกต้องได้โดยอัตโนมัติ
แนะนำผู้ร่วมรายการ
ตอนนี้มีบุคคลสำคัญ 3 คนเข้าร่วม
Jonathan Dekhtiar (NVIDIA) — วิศวกรที่หลงใหลใน CUDA จนเรียนต่อถึงระดับ PhD ก่อนเข้าร่วม NVIDIA ตลอดกว่า 2 ปีที่ผ่านมาเขาทำงานเพื่อปรับปรุงจุดเชื่อมต่อระหว่าง CUDA กับ Python และเป็นหนึ่งในแรงผลักดันหลักของ Wheel Next
Ralf Gommers (Quansight) — นักพัฒนาที่มีพื้นฐานปริญญาเอกด้านฟิสิกส์ และใช้งาน Python มาตั้งแต่ปี 2004 เขาเป็น release manager ของ NumPy และ SciPy และปัจจุบันเป็น co-CEO ขององค์กรสาธารณประโยชน์ Quansight อีกทั้งยังเป็นผู้เขียน PyPackaging Native guide ที่จัดระเบียบปัญหา native Python packaging อย่างเป็นระบบ
Charlie Marsh (Astral) — ผู้ก่อตั้งและ CEO ของ Astral ผู้สร้าง uv, ruff, ty หลังจากก่อตั้งบริษัทในเดือนตุลาคม 2022 เขามุ่งเน้นการยกระดับความเร็วและประสบการณ์ใช้งานของ ecosystem ฝั่ง Python มาโดยตลอด
ปัญหาหลัก: “กับดักของตัวหารร่วมต่ำสุด”
เมื่อ build wheel สำหรับ x86-64 ก็จะใช้ได้แค่ความสามารถของ CPU ก่อนปี 2009 เท่านั้น คำสั่งที่ออกมาหลังจากนั้นอย่าง SSE4 หรือ AVX2 ใช้ไม่ได้เลย เพราะ installer ไม่สามารถรู้ได้ว่าระบบมีความสามารถเหล่านี้หรือไม่
ช่องว่างด้านประสิทธิภาพระหว่างฮาร์ดแวร์ระดับปี 2009 กับฮาร์ดแวร์ช่วง 2019~2023 อาจสูงถึง 10~20 เท่า แล้วแต่กรณี
ฝั่ง ARM ก็เผชิญสถานการณ์คล้ายกัน เป้าหมาย build พื้นฐานสำหรับ ARM ในปัจจุบันแทบจะอยู่ที่ระดับ Raspberry Pi นั่นหมายความว่าแม้บน MacBook Pro ที่ใช้ชิป M4 Max ก็ยังรันไบนารีที่ build มาในระดับ Raspberry Pi
จากผลสำรวจนักพัฒนา Python ของ JetBrains นักพัฒนา Python ราว 40~50% ทำงานในสาย data science หรือ scientific computing ชุมชนขนาดใหญ่นี้จึงกำลังสูญเสียประสิทธิภาพไปอย่างเป็นระบบในระดับมหาศาล
NumPy อยู่รอดมาได้อย่างไร
NumPy แก้ปัญหานี้ด้วยตัวเอง โดยนำซอร์สโค้ดชุดเดียวกันไป compile หลายครั้ง ให้รองรับสถาปัตยกรรม CPU หลายแบบ เช่น Haswell และ Skylake แล้วจึงรวมกลับมาเป็น Python extension module ตัวเดียว Runtime จะตรวจจับ CPU แล้ว dispatch ไปยัง code path ที่เหมาะสมที่สุด
Intel ส่งวิศวกรเข้ามาช่วยปรับแต่ง code path ฝั่ง x86 มาหลายปี และฝั่ง ARM ก็มีผู้ดูแล NumPy โดยเฉพาะ ผลคือได้ประสิทธิภาพที่ยอดเยี่ยม แต่แนวทางนี้มีขนาดงานระดับที่ มีเพียงไม่กี่โปรเจ็กต์ใหญ่เท่านั้นที่รับภาระได้
SciPy, scikit-learn, Pandas และ Pillow มีการทำ SIMD optimization ไว้ในโค้ดแล้ว แต่ยังไม่มีวิธีบรรจุและแจกจ่ายมันผ่าน wheel ได้ จึงยังไม่สามารถปล่อยใช้งานจริงได้
กรณีของ PyTorch: “หนังสือปริศนา” ขนาด 900MB
wheel ของ PyTorch บน PyPI มีขนาดราว 900MB เพราะ CUDA library สำหรับ GPU architecture 5~6 แบบถูกมัดรวมอยู่ในไบนารีเดียว ทีม PyTorch ต้องทุ่มเทอย่างมากเพื่อไม่ให้ขนาดเกิน 1GB
ผู้ใช้ที่ต้องการ CUDA เวอร์ชันเฉพาะยังต้องไปตั้งค่า index URL แยกเอง และหน้าแนะนำการติดตั้งของแพ็กเกจอย่าง vLLM ก็ซับซ้อนราวกับ “หนังสือปริศนา”
แล้วถ้า Wheel Next เสร็จสมบูรณ์จะเกิดอะไรขึ้น?
uv pip install torch
แค่บรรทัดเดียวก็พอ installer จะตรวจจับ GPU อัตโนมัติ ระบุ CUDA เวอร์ชันที่เหมาะสม และดาวน์โหลด slim wheel ขนาดราว 200~250MB ที่ optimize มาสำหรับฮาร์ดแวร์นั้น Astral ได้สร้าง prototype ที่ใช้งานได้แล้วบนสาขา variant-enabled ของ uv
ปรัชญาการออกแบบของ Wheel Next: ไม่ใช่รายการตายตัว แต่เป็นระบบที่ขยายได้
แนวทางปัจจุบันคือ hardcode platform tag ลงในชื่อไฟล์ หากมีความต้องการใหม่ก็ต้องเพิ่ม tag ใหม่เข้าไป และหากทำแบบนี้ซ้ำ ๆ สุดท้ายก็จะกลายเป็นภาระการดูแลรักษาที่ไม่มีวันจบ
Wheel Next ต่างออกไป แพ็กเกจสามารถประกาศ metadata ของ variant แบบใดก็ได้ และ installer สามารถตรวจจับคุณสมบัติของแพลตฟอร์มแบบไดนามิกผ่าน plugin interface เพื่อเลือก wheel ที่เหมาะสมที่สุด แทนที่จะต้องสร้าง tag แยกสำหรับแต่ละเวอร์ชันของ CUDA ก็เปลี่ยนไปสร้าง ระบบที่เป็นสากลและขยายต่อได้
แนวคิดการออกแบบนี้ได้แรงบันดาลใจจาก archspec ของ package manager สำหรับซูเปอร์คอมพิวเตอร์อย่าง Spack, รวมถึง Conda-forge และ Nix
สถานะของ PEP
PEP หลักที่เกี่ยวข้องกับโครงการนี้มีดังนี้:
| PEP | ชื่อเรื่อง | สถานะ |
|---|---|---|
| PEP 817 | Wheel Variants Beyond Platform Tags | Draft |
| PEP 825 | Wheel Variants Package Format | Draft |
PEP 817 สร้างสถิติเป็น PEP ที่ยาวที่สุดเท่าที่เคยมีมา แค่การตรวจทานโดย PEP editors ก็ใช้เวลานานกว่าหนึ่งเดือน หลังจากนั้นจึงถูกแยกออกเป็นหน่วยที่จัดการได้ง่ายขึ้น เพื่อให้สามารถอภิปรายแยกกันได้ในส่วนของ installer, build backend และ index server
Python Build Standalone: คันโยกเงียบ ๆ
Charlie Marsh กล่าวถึงข้อเท็จจริงที่น่าสนใจอย่างหนึ่งว่า Astral เป็นผู้ดูแลโครงการ Python Build Standalone เวลาเราติดตั้ง Python ด้วย uv สิ่งที่ถูกดาวน์โหลดจริงก็คือ build จากโครงการนี้
เป้าหมายของ Astral คือการออก Python distribution ที่เร็วที่สุด โดยอาศัยเพียงการ optimize ขั้นตอน build โดยไม่แตะซอร์สโค้ดของ CPython Charlie บอกว่าเขาคิดว่าตอนนี้พวกเขามี Python ที่เร็วที่สุด แต่ยังไม่อยากประกาศอย่างเป็นทางการ เพราะยังไม่ได้เผยแพร่วิธีการ benchmark ที่เข้มงวดเพียงพอ
เมื่อพิจารณาว่านักพัฒนาจำนวนมากกำลัง bootstrap Python ผ่าน uv อยู่แล้ว การเลือก build ของ Astral จึงกลายเป็นคันโยกสำคัญที่อาจส่งผลมหาศาลต่อประสิทธิภาพของ Python
ความร่วมมือข้ามอุตสาหกรรมที่ไม่เคยมีมาก่อน
ในเดือนมีนาคม 2025 มีการจัด summit แบบออฟไลน์ที่ตัวแทนจากราว 20 บริษัทมาพบกันในที่เดียว ทีม PyTorch จาก Meta และทีม JAX จาก Google ต่างนำเสนอปัญหาของตัวเอง
ปัจจุบันบริษัทและโครงการโอเพนซอร์สที่ร่วมสนับสนุน Wheel Next มีดังนี้:
บริษัท: NVIDIA, Astral, Quansight, Meta, AMD, Intel, Google, Red Hat, Anaconda, Huawei, Preferred Networks และอื่น ๆ รวมมากกว่า 14 แห่ง
โครงการโอเพนซอร์ส: NumPy, SciPy, PyTorch, scikit-learn, JAX เป็นต้น
ระหว่างการทำ prototype มีการ fork องค์ประกอบแทบทุกส่วนของ ecosystem ด้าน Python packaging มาทดลอง ไม่ว่าจะเป็น pip, warehouse (PyPI), setuptools, scikit-build-core และไลบรารี packaging แน่นอนว่าเป้าหมายสุดท้ายคือรวมทุกอย่างกลับเข้าหากันอีกครั้ง
กำหนดการต่อจากนี้
ตามการคาดการณ์ของ Ralf ตลอดปี 2026 จะยังเป็นช่วงของการตรวจทาน PEP และอัปเดต prototype จากนั้นจึงค่อยเป็นคิวของ PyPI, Twine และเครื่องมือที่ใช้ metadata อื่น ๆ ที่จะได้รับการอัปเดต ดูแล้วทั้ง ecosystem น่าจะพร้อมจริงหลังปี 2026 เป็นต้นไป
แต่ Jonathan มองโลกในแง่ดี เขาเชื่อว่าเมื่อมาตรฐานพร้อมใช้งานเมื่อใด อัตราการนำไปใช้ใน ecosystem สาย ML และ scientific computing จะรวดเร็ว เพราะแพ็กเกจหลัก ๆ ได้เข้าร่วมใน working group ของ Wheel Next อยู่แล้ว
สรุปคำสำคัญ
| คำศัพท์ | คำอธิบาย |
|---|---|
| Wheel | ฟอร์แมตมาตรฐานสำหรับแจกจ่ายแพ็กเกจไบนารีของ Python (.whl) |
| Wheel Variants | ส่วนขยายที่เสนอใน PEP 817/825 ใช้แยกหลาย build ของแพ็กเกจเดียวกันตามคุณสมบัติของฮาร์ดแวร์ |
| SIMD | คำสั่ง CPU ที่ประมวลผลข้อมูลหลายชุดพร้อมกันด้วยคำสั่งเดียว (เช่น SSE4, AVX2, ARM Neon) |
| Fat Binary | ไบนารีที่รวมโค้ดซึ่ง compile สำหรับฮาร์ดแวร์หลายเป้าหมายไว้ในไฟล์เดียว ปัจจุบัน NumPy และ PyTorch ใช้อยู่ |
| Platform Tags | ข้อมูล OS, architecture และ Python version ที่เข้ารหัสอยู่ในชื่อไฟล์ wheel |
| Python Build Standalone | โครงการ build ของ CPython ที่สามารถนำไปแจกจ่ายต่อได้ ซึ่ง Astral เป็นผู้ดูแล |
| Variant Provider Plugin | อินเทอร์เฟซที่ทำให้ installer ตรวจจับคุณสมบัติของฮาร์ดแวร์แบบไดนามิก (เช่น เวอร์ชันไดรเวอร์ GPU) แล้วเลือก wheel variant ที่ถูกต้อง |
ทิ้งท้าย
“ในอุดมคติแล้ว ผู้ใช้ทั่วไปไม่ควรต้องสนใจเรื่องทั้งหมดนี้เลย ควรได้มันมาโดยอัตโนมัติผ่าน uv หรือ pip เท่านั้น” — Charlie Marsh
ระบบ Python packaging ถูกออกแบบมาในยุคที่ทุกอย่างเรียบง่ายกว่านี้มาก แต่เมื่อภาระงานด้าน data science และ AI เพิ่มขึ้นอย่างระเบิดในปัจจุบัน การออกแบบเดิมกลับกลายเป็นคอขวดทั้งในด้านประสิทธิภาพ แบนด์วิดท์ และประสบการณ์ใช้งาน
Wheel Next เป็นกรณีหายากที่คู่แข่งอย่าง NVIDIA, AMD, Intel, Google และ Meta มานั่งโต๊ะเดียวกัน เขียน PEP ร่วมกัน และลงทุนในโครงสร้างพื้นฐานที่ใช้ร่วมกัน prototype ของ uv ได้พิสูจน์ความเป็นไปได้ทางเทคนิคไปแล้ว แม้การทำให้ทั้ง ecosystem เดินตามจะยังต้องใช้เวลา แต่ก็เป็นอนาคตที่คุ้มค่าแก่การรอคอยอย่างยิ่ง
ลิงก์ที่เกี่ยวข้อง
- wheelnext.dev — เว็บไซต์ทางการของโครงการ Wheel Next
- PEP 817 — Wheel Variants Beyond Platform Tags
- PEP 825 — Wheel Variants Package Format
- pypackaging-native.github.io — คู่มือปัญหา native Python packaging
- astral.sh/pyx — pyx แพ็กเกจรีจิสทรีของ Astral
บทความนี้แปลและเรียบเรียงจาก Talk Python To Me Episode #544
2 ความคิดเห็น
โชคดีที่ Wheel Next มีบริษัทเกาหลีอย่าง Lablup เข้าร่วมอยู่ด้วย
https://wheelnext.dev/who_are_we/
บริษัท AI อื่น ๆ ทั้งหมดไม่ได้ให้การสนับสนุน ช่วยเหลือ หรือเข้าร่วมเลย
LabelUp เจ๋งมาก!!