Tại PyTorch Conference China ở Thượng Hải tuần này, PyTorch Foundation công bố Alibaba Cloud và Cambricon gia nhập làm thành viên Platinum — mỗi bên nhận một ghế trong Governing Board và một ghế trong Technical Advisory Council — trong khi Ant Group gia nhập ở mức Gold. Nhìn bề ngoài, đây đọc như tin tức membership foundation thường lệ, kiểu thông báo chỉ đáng một đoạn trong bản tổng hợp tin rồi thôi. Mình nghĩ nó bị đánh giá thấp, và cụ thể là bị đánh giá thấp bởi các team đã xây stack inference của mình với giả định rằng roadmap PyTorch về bản chất là roadmap CUDA khoác license permissive lên trên.

Về mặt hình thức thì không phải vậy — PyTorch đã hỗ trợ backend không phải NVIDIA nhiều năm nay. Nhưng độ ưu tiên roadmap luôn đi theo ảnh hưởng governance ở mọi foundation mã nguồn mở mình từng theo dõi vận hành, và đây là lần đầu tiên các nhà sản xuất phần cứng nằm ngoài dòng NVIDIA/CUDA có được phiếu bầu trực tiếp trong board về việc nỗ lực kỹ thuật cốt lõi của PyTorch sẽ đi đâu tiếp theo.

Điều gì thực sự thay đổi

Cambricon là nhà thiết kế chip và bộ tăng tốc AI có trụ sở tại Trung Quốc, với driver stack riêng và hệ sinh thái ML toolkit riêng (phần cứng Machine Learning Unit). Có ghế Platinum nghĩa là Cambricon giờ có tiếng nói thường trực trong roadmap kỹ thuật và phân bổ nguồn lực của PyTorch — không chỉ là “backend của chúng tôi chạy được với PyTorch”, mà là “chúng tôi có phiếu bầu trong việc PyTorch ưu tiên xây cái gì tiếp theo”. Alibaba Cloud, vốn đã là người dùng PyTorch lớn qua dòng model Qwen, nhận trọng lượng governance tương tự. Ant Group gia nhập ở tier Gold, đóng góp cho tooling cloud-native và AI-platform mã nguồn mở nhưng không có ghế board.

Đây là thay đổi governance, không phải thay đổi code — không có gì trong import torch của bạn hỏng hay cải thiện tuần này. Nhưng thay đổi governance là chỉ báo dẫn đầu cho việc backend torch.compile, nỗ lực tối ưu kernel, và lớp hardware-abstraction của một framework sẽ được đầu tư vào đâu trong 18-24 tháng tới. Nếu bạn là Tech Lead mà mô hình chi phí inference hiện tại giả định “PyTorch nghĩa là GPU NVIDIA”, đây là tín hiệu đáng theo dõi, không nên bỏ qua.

Vì sao điều này quan trọng ngoài phạm vi các team thị trường Trung Quốc

Ngay cả khi team bạn không có chút liên hệ nào với silicon Cambricon hay vùng cloud Trung Quốc, hiệu ứng bậc hai mới là điều quan trọng: mỗi thành viên Platinum bổ sung có lợi ích trong phần cứng không phải CUDA sẽ đẩy các abstraction cốt lõi của PyTorch (dispatcher, backend registration, tính linh hoạt target của torch.compile) hướng tới trung lập phần cứng thực sự, thay vì chỉ trung lập-về-mặt-lý-thuyết-nhưng-thực-chất-NVIDIA. Đó là áp lực tương tự khoản đầu tư ROCm của AMD và công việc XLA/TPU của Google đã tạo ra nhiều năm nay, giờ có thêm một vendor được đầu tư tốt đẩy từ một khu vực địa lý khác, một kiến trúc chip hoàn toàn khác.

Với một team đang làm capacity planning, đây là lý do để thực sự pilot một backend không phải NVIDIA ngay bây giờ, thay vì coi “sau này vẫn có thể chuyển” là một tùy chọn miễn phí. Tính portable của backend trong PyTorch xưa nay là “về mặt kỹ thuật được hỗ trợ, thực tế đau đầu” — kernel tùy chỉnh, op bị thiếu, vách đá performance âm thầm trên đường ít người đi. Trọng lượng governance đứng sau nhiều vendor không phải CUDA là một trong số ít lực có thể thu hẹp khoảng cách đó theo thời gian một cách đáng tin cậy, vì nó biến “backend parity” từ một lời đề nghị thiện chí cộng đồng thành một hạng mục roadmap mà các vendor có ghế board có thể trực tiếp thúc đẩy.

# một smoke test portability rẻ đáng chạy ngay hôm nay,
# bất kể bạn có định chuyển backend sớm hay không
import torch

def backend_smoke_test(model, sample_input, backends=("inductor",)):
    """Compile cùng một model dưới mỗi backend có sẵn và
    so sánh output + thời gian. Rẻ bây giờ; đắt nếu phát hiện ra
    bạn cần nó trong lúc migration hardware thực sự."""
    results = {}
    for backend in backends:
        try:
            compiled = torch.compile(model, backend=backend)
            with torch.no_grad():
                out = compiled(sample_input)
            results[backend] = {"ok": True, "shape": tuple(out.shape)}
        except Exception as e:
            results[backend] = {"ok": False, "error": str(e)}
    return results

Chạy thứ gì đó như thế này với bất kỳ backend thay thế nào bạn có sẵn hôm nay (kể cả chỉ là một backend torch.compile khác trên cùng GPU) và bạn sẽ có một tín hiệu sớm về việc codebase của bạn đã tích lũy bao nhiêu nợ custom-op hoặc kernel — nợ vô hình cho tới ngày ai đó yêu cầu bạn báo giá chi phí migration.

Nhận định chiến lược cho các quyết định hạ tầng

Mình không nghĩ thông báo này nghĩa là “bắt đầu lên kế hoạch migration sang Cambricon”. Phần lớn người đọc bài này không có bề mặt triển khai nào ở Trung Quốc và không có lý do gần hạn để đụng tới silicon đó. Nhận định hành động được ở đây hẹp hơn và hữu ích hơn: coi lớp abstraction backend của PyTorch là một dependency thực sự chiến lược, không phải một vấn đề đã giải quyết xong, và xem lại các giả định về portability phần cứng của bạn theo một nhịp độ thực sự — ít nhất hàng năm — thay vì giả định rằng sự gắn kết CUDA đúng hôm nay sẽ vẫn đúng khi thành phần governance của framework thay đổi.

Các foundation mã nguồn mở là hệ thống chuyển động chậm, và ghế board không viết lại kernel qua đêm. Nhưng chúng là một trong những chỉ báo dẫn đầu đáng tin cậy nhất có sẵn cho việc ranh giới abstraction của một framework sẽ được đầu tư tiếp theo ở đâu, và một cú đẩy đa vendor, đa địa lý hướng tới parity backend không phải CUDA chính xác là kiểu tín hiệu governance đáng ghi vào sổ rủi ro hạ tầng của bạn, kể cả khi phải mất hai năm mới thực sự xuất hiện trong các tùy chọn triển khai của bạn.

Nguồn:

Xuất nội dung

Bình luận