`pip install torch` giờ chỉ còn một dòng — Bài toán tồn đọng lâu năm của Python packaging cuối cùng sắp có lời giải?
(talkpython.fm)Liên minh NVIDIA·Astral·Quansight giới thiệu Wheel Next: tiêu chuẩn đóng gói thế hệ mới không phân biệt CPU hay GPU
Nguồn: Talk Python To Me, Episode #544 |
Bối cảnh: bánh xe dừng lại từ năm 2009
Khi chạy pip install numpy, chính xác thì nhị phân nào sẽ được cài? Dù CPU của bạn là AMD Zen 4 mới nhất hay Apple M4 đi nữa, wheel được cài vẫn được build để chỉ dùng tập lệnh x86-64 ở mức năm 2009.
Ngay cả khi muốn dùng các lệnh SIMD hiện đại như SSE4 hay AVX2, installer cũng không có cách nào biết hệ thống có hỗ trợ hay không. Kết quả là với các gói như PyTorch, bạn sẽ có những tệp nhị phân khổng lồ gần 900MB và các trang hướng dẫn cài đặt phức tạp như một “cuốn sách giải đố”.
Để giải quyết vấn đề này, liên minh NVIDIA, Astral và Quansight đang thúc đẩy sáng kiến Wheel Next. Trọng tâm của nó là một loạt PEP cho phép package khai báo phần cứng mà nó cần, đồng thời để các installer như uv tự động chọn đúng bản build.
Giới thiệu khách mời
Trong tập này có sự tham gia của ba nhân vật chủ chốt.
Jonathan Dekhtiar (NVIDIA) — kỹ sư mê CUDA đến mức hoàn thành cả chương trình PhD rồi gia nhập NVIDIA. Trong hơn 2 năm qua, anh tập trung cải thiện điểm giao giữa CUDA và Python, đồng thời là một trong những người thúc đẩy chính của sáng kiến Wheel Next.
Ralf Gommers (Quansight) — nhà phát triển có bằng tiến sĩ vật lý và đã dùng Python từ năm 2004. Ông là release manager của NumPy và SciPy, hiện đồng thời là đồng CEO của tổ chức phi lợi nhuận Quansight. Ông cũng là tác giả của PyPackaging Native guide, tài liệu hệ thống hóa các vấn đề của Python packaging cho native code.
Charlie Marsh (Astral) — nhà sáng lập kiêm CEO của Astral, công ty đứng sau uv, ruff và ty. Kể từ khi thành lập vào tháng 10/2022, Astral đã tập trung cải thiện tốc độ và trải nghiệm người dùng trong hệ sinh thái Python.
Vấn đề cốt lõi: “cái bẫy của mẫu số chung tối thiểu”
Khi build wheel cho x86-64, bạn chỉ có thể dùng các tính năng CPU có trước năm 2009. Những tập lệnh xuất hiện sau đó như SSE4 hay AVX2 hoàn toàn không thể dùng, vì installer không biết máy có những khả năng này hay không.
Chênh lệch hiệu năng giữa phần cứng chuẩn năm 2009 và phần cứng giai đoạn 2019~2023 trong một số trường hợp lên tới 10~20 lần.
Tình hình với ARM cũng tương tự. Mục tiêu build mặc định cho ARM hiện nay về thực chất chỉ ở mức Raspberry Pi. Điều đó có nghĩa là ngay cả trên MacBook Pro dùng chip M4 Max, bạn vẫn đang chạy nhị phân được build cho Raspberry Pi.
Theo khảo sát nhà phát triển Python của JetBrains, khoảng 40~50% lập trình viên Python làm việc trong lĩnh vực data science hoặc tính toán khoa học. Một cộng đồng khổng lồ như vậy đang lãng phí hiệu năng theo cách có hệ thống.
NumPy đã cầm cự như thế nào
NumPy đã tự giải quyết bài toán này. Họ biên dịch nhiều lần cùng một mã nguồn cho nhiều kiến trúc CPU như Haswell, Skylake..., rồi gộp chúng vào một Python extension module duy nhất. Ở runtime, hệ thống sẽ phát hiện CPU và dispatch sang đường code tối ưu nhất.
Intel đã cử kỹ sư tham gia tối ưu các đường code x86 trong nhiều năm, còn ARM cũng có maintainer NumPy chuyên trách. Nhờ vậy hiệu năng rất tốt, nhưng cách làm này chỉ ở quy mô mà số ít dự án lớn mới gánh nổi.
SciPy, scikit-learn, Pandas và Pillow đều đã có tối ưu SIMD trong code, nhưng vì không có cách đóng gói và phân phối chúng qua wheel nên trên thực tế vẫn chưa thể phát hành các tối ưu đó.
Trường hợp của PyTorch: “cuốn sách giải đố” 900MB
Wheel PyTorch trên PyPI có dung lượng khoảng 900MB. Lý do là các thư viện CUDA cho 5~6 kiến trúc GPU khác nhau đang bị gói chung vào một nhị phân duy nhất. Đội ngũ PyTorch đang phải nỗ lực rất lớn chỉ để giữ nó không vượt quá 1GB.
Nếu người dùng cần một phiên bản CUDA cụ thể, họ phải tự cấu hình một index URL riêng; còn trang hướng dẫn cài đặt của các gói như vLLM thì phức tạp như “sách giải đố”.
Nếu Wheel Next hoàn thiện thì sao?
uv pip install torch
Chỉ cần một dòng này. Installer sẽ tự động nhận diện GPU, xác định phiên bản CUDA phù hợp và tải về một slim wheel khoảng 200~250MB đã được tối ưu cho đúng phần cứng. Astral cho biết họ đã có sẵn prototype hoạt động trên một nhánh uv hỗ trợ variants.
Triết lý thiết kế của Wheel Next: không phải danh sách cố định, mà là hệ thống có thể mở rộng
Cách hiện tại hardcode platform tag vào tên tệp. Mỗi khi xuất hiện nhu cầu mới, lại phải thêm tag mới; lặp lại như vậy cuối cùng sẽ biến thành gánh nặng bảo trì vô tận.
Wheel Next đi theo hướng khác. Package có thể khai báo metadata variant tùy ý, còn installer thông qua giao diện plugin sẽ động phát hiện các thuộc tính nền tảng để chọn wheel tối ưu nhất. Thay vì gắn tag cho từng phiên bản CUDA, họ xây dựng một hệ thống tổng quát và có thể mở rộng.
Thiết kế này lấy cảm hứng từ archspec của package manager cho siêu máy tính Spack, cùng với Conda-forge và Nix.
Tình hình PEP
Các PEP chính liên quan tới sáng kiến này gồm:
| PEP | Tiêu đề | Trạng thái |
|---|---|---|
| PEP 817 | Wheel Variants Beyond Platform Tags | Draft |
| PEP 825 | Wheel Variants Package Format | Draft |
PEP 817 đã lập kỷ lục là PEP dài nhất từ trước tới nay. Chỉ riêng quá trình các PEP editor rà soát cũng đã mất hơn một tháng. Sau đó, tài liệu được tách nhỏ thành các phần dễ quản lý hơn để thảo luận riêng về installer, build backend và index server.
Python Build Standalone: đòn bẩy thầm lặng
Charlie Marsh cũng nhắc tới một chi tiết thú vị: Astral đang duy trì dự án Python Build Standalone. Khi bạn cài Python bằng uv, thứ thực sự được tải về chính là bản build từ dự án này.
Mục tiêu của Astral là phát hành bản phân phối Python nhanh nhất chỉ bằng tối ưu build, không sửa mã nguồn CPython. Charlie nói rằng ông tin mình đang có bản Python nhanh nhất hiện nay, nhưng chưa công bố phương pháp benchmark đủ chặt chẽ nên chưa muốn khẳng định chính thức.
Trong bối cảnh rất nhiều nhà phát triển đã bootstrap Python bằng uv, các lựa chọn build của Astral có thể trở thành một đòn bẩy có ảnh hưởng rất lớn tới hiệu năng Python.
Hợp tác liên ngành hiếm thấy
Tháng 3/2025, một hội nghị trực tiếp quy tụ đại diện từ khoảng 20 công ty đã được tổ chức. Đội PyTorch của Meta và đội JAX của Google đều trình bày các vấn đề riêng mà họ đang đối mặt.
Hiện các công ty và dự án mã nguồn mở đang đóng góp cho sáng kiến Wheel Next gồm:
Doanh nghiệp: NVIDIA, Astral, Quansight, Meta, AMD, Intel, Google, Red Hat, Anaconda, Huawei, Preferred Networks cùng hơn 14 tổ chức khác
Dự án mã nguồn mở: NumPy, SciPy, PyTorch, scikit-learn, JAX...
Trong quá trình prototyping, nhóm đã phải fork gần như mọi thành phần trong hệ sinh thái Python packaging như pip, warehouse(PyPI), setuptools, scikit-build-core và thư viện packaging. Tất nhiên mục tiêu cuối cùng vẫn là hợp nhất chúng trở lại.
Lộ trình sắp tới
Theo dự đoán của Ralf, xuyên suốt năm 2026 sẽ là giai đoạn review PEP và cập nhật prototype, sau đó mới tới PyPI, Twine và các công cụ tiêu thụ metadata. Có vẻ phải sau 2026 hệ sinh thái mới thật sự sẵn sàng trên diện rộng.
Tuy vậy Jonathan vẫn lạc quan. Ngay khi tiêu chuẩn này khả dụng, tốc độ chấp nhận trong hệ sinh thái ML và tính toán khoa học có thể sẽ rất nhanh, vì các package lõi đã tham gia sẵn trong working group của Wheel Next.
Tóm tắt các thuật ngữ chính
| Thuật ngữ | Giải thích |
|---|---|
| Wheel | Định dạng phân phối nhị phân tiêu chuẩn của Python package (.whl) |
| Wheel Variants | Phần mở rộng được đề xuất trong PEP 817/825, dùng để phân biệt nhiều bản build của cùng một package theo thuộc tính phần cứng |
| SIMD | Tập lệnh CPU cho phép xử lý đồng thời nhiều dữ liệu bằng một lệnh duy nhất (SSE4, AVX2, ARM Neon...) |
| Fat Binary | Nhị phân gộp mã đã biên dịch cho nhiều mục tiêu phần cứng khác nhau. NumPy và PyTorch hiện đang dùng cách này |
| Platform Tags | Thông tin về OS, kiến trúc và phiên bản Python được mã hóa trong tên tệp wheel |
| Python Build Standalone | Dự án build CPython có thể tái phân phối do Astral quản lý |
| Variant Provider Plugin | Giao diện cho phép installer động phát hiện thuộc tính phần cứng (như phiên bản driver GPU) để chọn đúng wheel variant |
Kết
“Lý tưởng nhất là người dùng bình thường không cần phải bận tâm tới tất cả chuyện này. Họ chỉ việc nhận nó một cách tự động qua uv hoặc pip.” — Charlie Marsh
Hệ thống Python packaging được thiết kế cho một thời đại đơn giản hơn. Nhưng trong bối cảnh khối lượng công việc data science và AI bùng nổ như hiện nay, thiết kế đó đang trở thành nút thắt cổ chai về hiệu năng, băng thông và trải nghiệm người dùng.
Wheel Next là một ví dụ hiếm hoi khi các đối thủ cạnh tranh như NVIDIA, AMD, Intel, Google và Meta cùng ngồi chung bàn, cùng viết PEP và cùng đầu tư vào hạ tầng dùng chung. Prototype của uv đã chứng minh tính khả thi về mặt kỹ thuật. Có thể sẽ mất thời gian để toàn bộ hệ sinh thái bắt kịp, nhưng đó là một tương lai hoàn toàn đáng để chờ đợi.
Liên kết liên quan
- wheelnext.dev — Trang chính thức của dự án Wheel Next
- PEP 817 — Wheel Variants Beyond Platform Tags
- PEP 825 — Wheel Variants Package Format
- pypackaging-native.github.io — Hướng dẫn về các vấn đề của native Python packaging
- astral.sh/pyx — Registry package pyx của Astral
Bài viết này được dịch và biên tập từ nội dung của Talk Python To Me Episode #544.
2 bình luận
May mắn là Wheel Next có sự tham gia của công ty trong nước Rableup.
https://wheelnext.dev/who_are_we/
Tất cả các công ty AI khác đều không tài trợ, hỗ trợ hoặc tham gia.
Rabble Up thật tuyệt!!