PYX: Bước tiếp theo của việc đóng gói Python

 (astral.sh)
18 điểm bởi GN⁺ 2025-08-14 | 4 bình luận | Chia sẻ qua WhatsApp
  • pyx là registry gói native cho Python do đội ngũ phát triển uv tạo ra, giúp tăng tốc cài đặt lên tới 10 lần từ PyPI, PyTorch và các nguồn riêng tư
  • Vượt ra ngoài phạm vi của registry gói truyền thống, nó cung cấp các tính năng tốc độ, bảo mật và nhận biết GPU, đồng thời hỗ trợ cả gói nội bộ lẫn các nguồn công khai như PyPI và PyTorch
  • Cung cấp URL chỉ mục chuyên dụng có thể lọc theo các tiêu chí như độ phổ biến của gói, thời điểm phát hành, tình trạng lỗ hổng, qua đó tăng cường bảo mật và tuân thủ
  • Với hỗ trợ các tiêu chuẩn mới nhất dành riêng cho Python và tích hợp trực tiếp với uv, có thể xác thực và sử dụng mà không cần cấu hình
  • Giải quyết các vấn đề lớn trong môi trường doanh nghiệp như build trùng lặp trong nhóm, độ khó khi cài PyTorch·CUDA, build bị hỏng, bất tiện trong xác thực, thông qua tích hợp server-client
  • Với khả năng nhận biết GPU, cung cấp các bản dựng sẵn của PyTorch, vLLM, FlashAttention, DeepSpeed... phù hợp với phần cứng, cùng metadata nhất quán và cấu hình tối ưu
  • Cung cấp hiệu năng vượt trội so với các registry riêng tư khác nhờ artifact được tối ưu hóa và API metadata native của uv

Tầm nhìn và bối cảnh của Astral

  • Astral là công ty xây dựng các công cụ phát triển hiệu năng cao cho hệ sinh thái Python, nổi tiếng với Ruff (linter·formatter) và uv (trình quản lý gói)
  • Lý do thành lập là vì họ cảm thấy rằng, dù Python là ngôn ngữ lập trình phổ biến nhất thế giới, nhưng lại chưa được hỗ trợ tương xứng về mặt công cụ
  • Hiện tại chuỗi công cụ của Astral ghi nhận hơn 100 triệu lượt cài đặt mỗi tháng, còn uv xử lý hơn 500 triệu yêu cầu mỗi ngày và đang tăng trưởng bùng nổ
  • Mục tiêu là biến Python thành hệ sinh thái lập trình năng suất nhất, và để làm điều đó, họ muốn xây dựng Python Cloud vượt ra ngoài các công cụ phía client

Giới thiệu pyx

  • pyx là registry gói native cho Python được thiết kế làm backend tối ưu cho uv
    • Có thể host các gói nội bộ
    • Đóng vai trò frontend có thể tăng tốc và cấu hình cho các nguồn công khai như PyPI, chỉ mục PyTorch
  • Các đặc điểm chính
    • Tốc độ cài đặt nhanh: tối ưu hóa cài đặt và build gói
      • Khi cài gói từ PyPI, PyTorch và các nguồn private nội bộ, pyx tận dụng artifact được tối ưu hóa và API metadata native của uv
      • Mang lại tốc độ nhanh hơn tới 10 lần so với registry riêng tư khác
    • Tăng cường bảo mật và tuân thủ: giảm thiểu rủi ro bằng cách hiểu rõ dependency và chuỗi cung ứng
      • Có thể tạo URL chỉ mục chuyên dụng để lọc gói
      • Kiểm soát quyền truy cập gói theo các tiêu chí như độ phổ biến, tuổi đời bản phát hành, trạng thái lỗ hổng
      • Đảm bảo các bản build có thể tái lập ở phía server
    • Hỗ trợ các tiêu chuẩn mới nhất
      • Hỗ trợ các tiêu chuẩn đóng gói và workflow mới nhất dành riêng cho Python
      • Tích hợp trực tiếp với uv để xác thực và sử dụng liền mạch mà không cần cấu hình riêng
    • Phân phối gói nhận biết GPU: đơn giản hóa việc build và phân phối liên quan đến CUDA·PyTorch
      • Cung cấp các bản dựng sẵn tùy chỉnh cho các thư viện liên quan GPU như PyTorch, vLLM, FlashAttention, DeepSpeed
      • Duy trì cấu hình tối ưu theo phần cứng và metadata nhất quán

Những vấn đề pyx muốn giải quyết

  • Khó khăn khi cài đặt các thư viện liên quan GPU như PyTorch, CUDA, FlashAttention, DeepSpeed
  • Lãng phí tài nguyên do build lặp lại cùng một gói trong nội bộ nhóm
  • Lỗi build do cập nhật setuptools
  • Sự bất tiện trong quy trình xác thực với registry nội bộ

Chiến lược tích hợp server-client

  • Giải quyết trực tiếp các vấn đề trên bằng tích hợp theo chiều dọc giữa uv (client) và pyx (server)
  • Có thể chỉ dùng uv mà không có pyx, hoặc chỉ dùng pyx mà không có uv, nhưng trải nghiệm tốt nhất đến khi dùng cùng nhau
  • Tích hợp sâu với các công cụ mã nguồn mở giúp hiện thực hóa trải nghiệm phát triển vốn trước đây không thể có

Mô hình kinh doanh

  • Các công cụ của Astral như uv, Ruff, ty sẽ mãi mãi miễn phí, mã nguồn mở và dùng giấy phép permissive
  • Thay vào đó, công ty cung cấp dịch vụ hosting trả phí như pyx để đáp ứng nhu cầu hạ tầng ở “bước tiếp theo”

Tình trạng hiện tại và kế hoạch sắp tới

  • Hiện đang vận hành cùng các đối tác ban đầu như Ramp, Intercom và fal
  • Duy trì vòng phản hồi nhanh thông qua open build cho đến trước khi GA (phát hành chính thức rộng rãi)
  • Mời các nhóm quan tâm và người hâm mộ liên hệ

Bài viết liên quan

4 bình luận

 
roxie 2025-08-15

Tôi cứ đọc tiếp và tự hỏi công ty này kiếm tiền bằng cách nào, hóa ra họ đang có kế hoạch cung cấp pyx dưới dạng trả phí.
 
ndrgrd 2025-08-14

Câu kiểu “All python packaging challenges are solved” thì nghe buồn cười thật đấy
Chẳng phải là đã giải quyết xong, mà chỉ là dọn qua một bên để nó tạm chạy được thôi đúng không haha

Python là một ngôn ngữ chủ lực được dùng trên toàn thế giới, nhưng đúng là môi trường của nó quá lộn xộn.
Trong phần bình luận trên Hacker News, người ta lo ngại vì ‘doanh nghiệp’ nhúng tay vào, nhưng lại không nghĩ rằng chính vì chẳng ai quan tâm cho đến khi doanh nghiệp đứng ra nên tình hình mới thành ra thế này.
 
aqqnucs 2025-08-14

FYI: trích dẫn điều ai đó đã nói trong phần bình luận trên Hacker News
 
GN⁺ 2025-08-14
Ý kiến trên Hacker News

  • Có lẽ bài blog này hữu ích hơn: https://astral.sh/blog/introducing-pyx

    • Dù liên kết này giải thích rõ hơn, tôi vẫn chưa thật sự hiểu họ đang cố giải quyết vấn đề gì và giải pháp đó hoạt động cụ thể ra sao

  • Tôi nghĩ mọi vấn đề về đóng gói Python đều đã được giải quyết rồi. Bài học ở đây là không có một giải pháp duy nhất phù hợp hoàn hảo cho mọi vấn đề. Việc gắn kết nhiều hơn với các công ty được VC rót vốn hoặc phụ thuộc vào hạ tầng của họ luôn là rủi ro lớn với cộng đồng FOSS

    • Ban đầu tôi được bảo dùng pip nên đã bắt đầu với nó. Nhưng nó chậm và hay gặp lỗi. Thế là tôi chuyển sang virtualenv, nhưng cái đó chỉ giải quyết được một phần vấn đề. Sau đó tôi dùng conda, đôi khi chạy ổn nhưng nó làm hỏng cấu hình shell của tôi và thường xuyên khiến phiên bản package bị rối. Rồi người ta khuyên dùng pipenv, lúc đầu khá ổn nhưng sau đó dự án bị bỏ bê, đổi người và bản mới cứ hay hỏng. Lại được giới thiệu poetry, nhưng nó chậm quá mức không dùng nổi. Thế là tôi quay về pip với venv tích hợp, nhưng lại gặp đúng những vấn đề cũ, mà tính năng còn ít hơn. Sau cùng tôi chuyển sang uv, và cái này ít nhất là hoạt động ra hồn. Nhưng dependency tôi cần lại có cách build và đóng gói khác nhau tùy hệ điều hành và GPU, nên đồng nghiệp của tôi còn không cài nổi project này lên laptop của họ. Thật mừng là các vấn đề đóng gói Python đều đã được “giải quyết”

    • Khẳng định rằng “mọi vấn đề đóng gói Python đều đã được giải quyết” thật lòng là phát biểu từ sự thiếu hiểu biết hoặc ngây thơ. Python vẫn chưa có cách xử lý dependency native một cách đáng tin cậy trên nhiều nền tảng khác nhau. pip và setuptools không nên là trùm cuối của hệ sinh thái này

    • Tôi đồng ý với mối lo đó, nhưng từ khi dùng uv tôi đã tiết kiệm được rất nhiều thời gian, nên tôi sẽ tiếp tục dùng cho đến khi mặt trái của vốn VC phá hỏng mọi thứ hoàn toàn. Hy vọng tới lúc đó cộng đồng sẽ có thể tập hợp lại theo một hướng

    • Suốt 3 tiếng vừa rồi tôi vật lộn giữa python và debian nên cơn giận với hệ sinh thái Python lại bùng lên. Chẳng có gì là đã được giải quyết cả. Trên Debian, người ta chỉ khuyến khích dùng venv, nhưng các package cài trong venv lại rất dễ không được các công cụ kiểu cmake tìm thấy. Cũng có package apt-get, và có công cụ thì chỉ tìm thấy loại đó, công cụ khác lại không. Tên package cũng chẳng nhất quán. Console của tôi còn gợi ý pipx, nhưng trải nghiệm dùng cũng na ná vậy. Chưa kể tàn dư python 2 với 3 vẫn còn sót lại, nên chỉ vì có hay không có số phiên bản trong tên mà việc tìm package cũng hay thất bại. Tôi chẳng biết c++headerparser là gì, nhưng cuối cùng lại càng tin rằng nên lôi Python ra khỏi cây build và chôn nó vào lịch sử thì hơn

    • Bạn mới tới đây à? Tôi khuyên bạn thử uống ngụm Kool Aid này. Đừng bận tâm tới logo "MongoDB" khắc trên ly. Cái đó là đồ cũ rồi

  • Tôi đã quá nhiều lần tin vào sản phẩm mã nguồn mở rồi bị tổn thương. Những lời hứa kiểu này tôi nghe không biết bao nhiêu lần. Rồi đến lúc bị mua lại, tài liệu, issue và PR tích lũy nhiều năm bị dọn dẹp gần như không báo trước. Sau đó công ty mới tung ra một sản phẩm thương mại nào đó, nhưng lại thiếu những tính năng cốt lõi mà tôi từng dùng

    • Dù tôi hiểu nỗi lo này, tôi muốn nhấn mạnh rằng pyx là một sản phẩm được tách biệt chiến lược với các công cụ hiện có của Astral. Trong thông báo chính thức cũng viết rằng: “pyx là hiện thân của chiến lược Astral, và các công cụ của Astral sẽ mãi mãi tiếp tục là miễn phí, mã nguồn mở, với giấy phép rất dễ dãi.” Mục tiêu của chúng tôi là giảm bớt lo ngại bằng cách tạo ra một sản phẩm thương mại bền vững riêng biệt, thay vì kiếm tiền từ các công cụ mã nguồn mở

    • Đó là nỗi lo hoàn toàn dễ hiểu. Tuy vậy, tôi nghĩ danh tiếng và thành tích của Astral thật sự rất ấn tượng. Tôi khá ngạc nhiên khi thấy phản ứng thận trọng như vậy trên HN. Tôi đã làm Python hơn 10 năm, và cứ khi nào Astral làm gì đó thì tôi đều thấy đáng để kỳ vọng

    • Nếu đó là tính năng thực sự có giá trị, tôi nghĩ nó đã được gộp vào pip rồi

  • Tôi rất đồng cảm với nhận xét rằng cài PyTorch, CUDA, hay FlashAttention, DeepSpeed là cực kỳ vất vả. Trên Windows (và cả WSL), còn có chuyện vài package đòi compiler của các phiên bản Visual Studio rất cũ, khiến bạn phải vất vả tự lần ra đường dẫn tải về. Tôi đang chờ một trải nghiệm phát triển tốt hơn

    • Thực ra WSL gần như là Linux, nên tôi không nghĩ phiên bản compiler Visual Studio quan trọng lắm. Binary cho WSL đều được build bằng toolchain Linux. Ngay cả trên Windows, libc cũng đã rất ổn định từ sau Win10. Các binary build bằng VC++ 2015 trở lên vẫn giữ tương thích C-ABI với nhau. Chỉ trong trường hợp ngoại lệ như ngôn ngữ hay tính năng nào đó không được compiler cũ hỗ trợ, hoặc khi cố chuyển trực tiếp object C++ qua ranh giới ABI, thì mới cần compiler cũ. Mấy trường hợp đó hiếm thôi

    • Chính những câu chuyện kiểu này khiến tôi từng dứt hẳn khỏi Ruby dù Rails rất hấp dẫn. Xem video Ruby thì ai cũng vui vẻ phát triển phần mềm, tôi cũng ghen tị, nhưng trong môi trường của tôi thì để dựng được môi trường dev phải dùng cả droplet DigitalOcean, và rồi vẫn thường chết ở bước compile cho Rails. Khoảng năm 2012 tôi rất muốn theo làn sóng Rails, nhưng quá trình thiết lập/cài đặt lúc nào cũng như ác mộng. Thế là tôi chuyển sang Python, ban đầu ổn, nhưng dạo này cứ dính AI hay CUDA là tôi lại có cảm giác thôi cứ chạy theo shell script của người khác còn đỡ hơn phải tự mình bước vào địa ngục cài đặt

    • Tôi nghĩ trong workflow xoay quanh GPU thì đóng gói Python nên đi theo hướng này. Có hai điều tôi đặc biệt mong đợi. Thứ nhất là có các index đã được kiểm chứng tương thích theo từng loại accelerator (ví dụ CUDA/ROCm/CPU riêng), để chấm dứt mớ tranh cãi về ma trận torch/cu*. Thứ hai là để client có thể truy vấn metadata nhằm song song hóa quá trình cài đặt. Nếu pyx có thể giảm vòng lặp “pip thử rồi sai” trong môi trường ML, đồng thời cung cấp cả build nhắm đúng mục tiêu phần cứng và hash có thể dự đoán được, thì sẽ tiết kiệm được rất nhiều thời gian dựng môi trường. Ngoài ra, việc giữ công cụ ở dạng mã nguồn mở nhưng kiếm tiền bằng dịch vụ hosting là mô hình tích cực cho việc xây dựng niềm tin. Tôi cũng tò mò liệu pyx có hỗ trợ các kiểm tra chuỗi cung ứng như đồ thị dependency, reverse dependency (nếu X→Y thì cái gì sẽ hỏng?), hay bằng chứng SBOM/chữ ký hay không

    • Đã có thời hệ điều hành nào cũng mặc nhiên đi kèm compiler

    • Ngày xưa lý do quyết định khiến tôi dùng anaconda chính là vì kiểu môi trường như thế này

  • Có người đùa rằng “sắp tới sẽ có tận 14 chuẩn đóng gói Python cạnh tranh nhau”. Thực ra 14 chỉ là nói đùa, vì từ lâu số đó đã còn nhiều hơn thế

    • Python packaging quả thật có rất nhiều chuẩn, nhưng tôi nghĩ phần lớn những thứ xuất hiện trong hơn 10 năm qua không hẳn là cạnh tranh với nhau. Đúng hơn đó là “kết quả tích lũy dần dần của các tính năng được xem là hữu ích”. Điều này là do quá trình chuẩn hóa packaging của Python lành mạnh và dựa trên đồng thuận hơn là độc đoán. Nếu nó mang tính độc đoán thì tôi nghĩ Python đã không đạt được thành công như hiện nay (tham khảo: tôi từng tham gia đề xuất ít nhất 5 PEP)

  • Tôi nghĩ Python packaging là phần đi ngược với Zen của Python nhất trong Python

  • Tháng 9 năm ngoái, Charlie đã tiết lộ trên Mastodon rằng anh ấy đang lên ý tưởng cho mô hình kinh doanh này https://hachyderm.io/@charliermarsh/113103564055291456

  • Tôi tò mò “registry aware về GPU” cụ thể có nghĩa là gì. Có phải uv sẽ kiểm tra thông số GPU của tôi rồi tự lấy từ Pyx ra bộ package phù hợp không? Nếu đây là registry riêng tư, có phí, dành cho khách hàng doanh nghiệp, thì công ty có thể cung cấp một registry như vậy ra bên ngoài dưới dạng instance công khai không? Tức là, nếu tôi là vendor, liệu tôi có thể vận hành một registry Pyx trả phí cho các package của mình và đưa nó cho khách hàng làm entrypoint hay không?

    • uv đã hỗ trợ dạng cơ bản của ý tưởng này rồi. Ví dụ, nếu chạy "uv pip install --torch-backend=auto torch" thì nó sẽ tự động cài phiên bản PyTorch phù hợp với GPU của bạn từ index PyTorch. pyx là phiên bản mở rộng hơn của mô hình đó. Không chỉ với PyTorch, mà với từng accelerator phần cứng khác nhau đều sẽ có những index được tuyển chọn kỹ, và trong các index đó, artifact đã build sẵn cho nhiều package, phiên bản, phiên bản Python, phiên bản PyTorch khác nhau sẽ được chuẩn bị với metadata nhất quán. Nói cách khác, khi dùng pyx, bạn có thể dễ dàng nhận được các build phù hợp cả về tương thích lẫn tốc độ, và client uv cũng có thể tự động tìm ra index pyx thích hợp (phần này được triển khai sẵn dù bạn có dùng pyx hay không, chỉ là với pyx thì mạnh hơn nhiều). Ngoài ra, việc để vendor tự vận hành registry kiểu pyx cho package của họ và dùng nó làm điểm vào cho khách hàng hiện chưa được hỗ trợ chính thức, nhưng nếu bạn thực sự quan tâm thì có thể liên hệ để bàn thêm

  • Tôi đã nói chuyện này vài tuần trước rồi, rằng sớm muộn Astral cũng sẽ có chiến lược kiếm tiền. Trọng tâm sẽ không phải Uv, mà tôi đoán sẽ là thứ giống một private PyPI được bảo vệ https://news.ycombinator.com/item?id=44712558

    • Tôi không hiểu lắm ý chính của nhận xét này. Thực ra Charlie Marsh đã trực tiếp giải thích như vậy từ tháng 9 năm ngoái rồi — một ví dụ chiến lược có thể là private package registry cho doanh nghiệp (không nhất thiết đúng y như vậy, nhưng dùng để minh họa cụ thể cho cách họ đang nghĩ về chiến lược). Astral rất minh bạch về mô hình kinh doanh của mình https://hachyderm.io/@charliermarsh/113103605702842937

    • “Kiếm tiền” có thể nghe hơi tiêu cực, nhưng họ thực sự đã làm ra những công cụ xuất sắc, nên ở góc nhìn doanh nghiệp, nếu họ giải quyết được nhiều vấn đề hơn nữa thì hoàn toàn đáng để trả tiền

    • Tôi vẫn chưa áp dụng uv và đang theo dõi xem họ sẽ đi theo hướng nào. Gần đây chúng tôi cũng phải xem xét lại việc dùng công cụ của Anaconda do thay đổi giấy phép, Qt cũng vậy. Nghĩ tới việc lại gặp thêm một rắc rối giấy phép nữa là đã thấy mệt rồi