IBM đưa bộ tăng tốc Spyre trở thành backend PyTorch hạng nhất

IBM cho biết trong bài blog của IBM Research đăng ngày 26 tháng 10 năm 2026 rằng các bản cập nhật phần mềm được triển khai trên toàn hệ sinh thái PyTorch trong nửa cuối năm 2026 đã đưa bộ tăng tốc luồng dữ liệu Spyre của hãng trở thành backend PyTorch hạng nhất, hiện thực hóa kế hoạch mà IBM và PyTorch Foundation đã đề ra vào tháng 10 năm 2025.

IBM mô tả Spyre là bộ tăng tốc AI theo luồng dữ liệu của hãng, được tối ưu cho suy luận và thiết kế dành cho các nhóm doanh nghiệp chạy AI bên cạnh ứng dụng và dữ liệu trên các hệ thống IBM Z, LinuxONE và Power. Khả năng tính toán với độ chính xác thấp hơn của Spyre nhắm đến các tác vụ xử lý ma trận chuyên sâu trong quá trình tạo ngôn ngữ và các mô hình nhúng. Khác với GPU thông thường, vốn thực thi kernel dưới dạng các luồng lệnh trên những nhóm luồng được lập lịch, Spyre khởi chạy tính toán khi dữ liệu đến các đơn vị tính toán.

Trong nửa cuối năm 2026, IBM, Red Hat và các cộng tác viên trong PyTorch Foundation, bao gồm Meta và Hugging Face, đã triển khai các bản cập nhật về khả năng hỗ trợ mô hình ngay từ ngày đầu, mô hình không phụ thuộc phần cứng trong vLLM, kiểm thử hồi quy và phát hành liên tục, cũng như tích hợp thiết bị gốc, theo bài viết. Tại PyTorch Conference 2025, trong bài đăng của IBM Research ngày 21 tháng 10 năm 2025, IBM cho biết hãng dự định tăng cường hỗ trợ Spyre trong năm 2026, để Spyre tham gia vào các quy trình suy luận mã nguồn mở với vai trò backend hạng nhất, đồng thời tập trung vào các tuyến đường trình biên dịch thống nhất, tạo kernel được tối ưu hóa và lập lịch minh bạch cho nhiều bộ tăng tốc. Đến thời điểm đó, IBM đã chọn vLLM làm môi trường chạy suy luận và torch.compile làm trình biên dịch frontend để tích hợp các bộ tăng tốc như Spyre; hãng cũng đóng góp một plugin Spyre cho vLLM, cho phép sử dụng attention phân trang trong suy luận mô hình ngôn ngữ lớn.

Tái xây dựng trình biên dịch dựa trên Inductor

Trọng tâm của việc tích hợp là torch-spyre, một backend PyTorch biên dịch mã PyTorch thông thường thành kế hoạch thực thi cho Spyre. Phần lớn logic của mô hình đi qua trình biên dịch PyTorch mà không bị thay đổi; khi chưa thể chuyển đổi một phép toán sang dạng phù hợp một cách hiệu quả, bộ chuyển đổi có thể thay thế phép toán đó bằng một dạng tương đương về mặt toán học mà trình biên dịch có thể xử lý.

Trong bài đăng của PyTorch Foundation được công bố ngày 13 tháng 10 năm 2026, Dave Grove, Olivier Tardieu và Nhóm IBM Spyre mô tả việc chuyển backend torch.compile của torch-spyre từ sendnn—một ngăn xếp biên dịch được xây dựng hoàn toàn từ đầu—sang backend=inductor, một backend mã nguồn mở được xây dựng bằng cách mở rộng chính Inductor của PyTorch. Theo các tác giả, khi đo bằng công cụ phân tích mã lizard, sendnn có tổng cộng khoảng 273.000 dòng mã C++ và Python trong 6.170 hàm, còn phần mở rộng Inductor có khoảng 38.600 dòng mã Python trong 1.878 hàm—ít hơn khoảng 7 lần số dòng mã, với độ phức tạp trung bình của mỗi hàm thấp hơn.

Spyre là bộ tăng tốc công suất 75 watt, kết nối qua PCIe, gồm 32 lõi nhỏ nối với nhau theo cấu trúc vòng. Mỗi lõi có bộ nhớ scratchpad riêng dung lượng 2 MB thay vì dùng bộ nhớ đệm chung; dữ liệu được truyền theo các khối cố định 128 byte gọi là stick. Theo bài viết, công việc phát triển trình biên dịch tập trung vào việc di chuyển dữ liệu theo đơn vị stick, lập kế hoạch sử dụng bộ nhớ scratchpad và phân công lõi tại thời điểm biên dịch.

Các số liệu được báo cáo bao gồm mức giảm 29–69% thời gian chạy kernel matmul nhờ lựa chọn phân ô và bố cục dữ liệu; thời gian chạy kernel softmax trung vị giảm từ 32,51 micro giây xuống 23,67 micro giây—tương đương giảm 27%—nhờ lập lịch có xét đến bộ nhớ scratchpad; và một kernel hợp nhất kiểu MLP giúp mức sử dụng lõi tăng từ khoảng hai phần ba lên khoảng 80%, đồng thời giảm thời gian chạy kernel khoảng 17%. Trên một đồ thị tổng hợp được tạo ra để kiểm tra các quyết định đó, phương thức bố trí lại dữ liệu mới trên chip đã thay thế một lượt truyền dữ liệu khứ hồi qua bộ nhớ thiết bị kéo dài 80 micro giây bằng thao tác xáo trộn dữ liệu giữa các lõi chỉ mất 1,1 micro giây. Bài viết cũng lưu ý rằng nhu cầu đăng ký các phép phân rã riêng cho thiết bị của torch-spyre đã góp phần thúc đẩy cải tiến khả năng hỗ trợ backend Inductor ngoài cây mã nguồn; những cải tiến này được đưa vào PyTorch 2.12 thông qua hai yêu cầu kéo đã được hợp nhất.

Tích hợp thiết bị gốc

Spyre trở thành thiết bị PyTorch gốc thông qua đăng ký PrivateUse1, nhờ đó tensor.to(“spyre”) có định danh thiết bị thực: bộ cấp phát của PyTorch lưu trữ tensor thường trú trên thiết bị, các luồng cung cấp ngữ nghĩa thứ tự thực thi và các sự kiện thời gian chạy kết nối những tác vụ phụ thuộc lẫn nhau giữa các luồng. Card này có 32 lõi kết nối bằng một vòng truyền dữ liệu băng thông cao, mỗi lõi có bộ nhớ scratchpad cục bộ 2 MB, cùng tối đa 128 GB LPDDR5 dành cho tensor và chương trình; môi trường chạy hiện tại sẽ vá chương trình khi khởi chạy, thay thế các địa chỉ tensor ký hiệu bằng địa chỉ thực qua ba bước theo thứ tự.

Trong một buổi trình diễn với Granite 3.3 8B ở kích thước lô 1 và độ dài chuỗi 1024, việc chuyển quá trình dựng đồ thị ra khỏi đường truyền dữ liệu giúp cải thiện tốc độ prefill 9,9% và decode 13,6%, theo nhóm nghiên cứu. Khi loại bỏ công việc đó khỏi cả quá trình điều phối tính toán, mức cải thiện tổng thể đạt 1,7 lần đối với prefill và 2,4 lần đối với decode; khoảng ba phần tư mức tăng đến từ đường xử lý tính toán.

“Điểm mấu chốt là cả Spyre lẫn PyTorch đều không phải giả vờ trở thành thứ khác”, các tác giả viết trong Xây dựng Spyre thành thiết bị PyTorch gốc, được công bố ngày 8 tháng 10 năm 2026. Họ cho biết thêm rằng Spyre vẫn giữ nguyên mô hình thực thi theo luồng dữ liệu, trong khi người dùng có được một thiết bị PyTorch gốc với cách bố trí tensor, luồng và biên dịch quen thuộc.

Khả năng chuyển đổi của vLLM và mối liên hệ với Llm-D

Spyre là một bộ tăng tốc ngoài cây, chứ không phải một trong những nền tảng GPU được phần mềm AI hỗ trợ phổ biến nhất. Công nghệ này dựa vào TorchDynamo để truy vết đồ thị mô hình và TorchInductor để chuyển đồ thị đó thành mã phù hợp với phần cứng đích. Trong vLLM, các cơ chế mở rộng như CustomOp và PluggableLayer cho phép plugin phần cứng tùy chỉnh hoạt động mà không cần triển khai lại phần lớn ngăn xếp phần mềm.

Trong Các mô hình không phụ thuộc phần cứng trong vLLM, được các tác giả đến từ IBM, Meta và Hugging Face công bố ngày 22 tháng 9 năm 2026, nhóm nghiên cứu mô tả quá trình vLLM chuyển sang các định nghĩa mô hình “phẳng” dành riêng cho phần cứng, đồng thời giới thiệu các lớp không phụ thuộc phần cứng được xây dựng dựa trên bốn nguyên tắc thiết kế: có thể biên dịch, có thể mở rộng, tách biệt khỏi các đường dẫn dành riêng cho phần cứng và có tính di động. Hỗ trợ ban đầu đã được đưa vào nhánh chính của vLLM và có thể bật bằng USE_HW_AGNOSTIC=1 trên phần phụ trợ transformers. Hướng triển khai này đã được xác thực bằng plugin ngoài cây của Spyre trên các mô hình như Gemma 4, Qwen3 và Granite 4.2; theo các tác giả, trên GPU NVIDIA H100, các lớp không phụ thuộc phần cứng đạt tổng thông lượng token chênh lệch không quá 3,4% so với bản triển khai gốc, tính theo trung bình nhân trên ba mô hình mới đây.

Bài đăng của IBM giải thích rằng khả năng tích hợp Spyre với PyTorch cũng là cách Spyre kết nối với llm-d: llm-d chạy suy luận phân tán trên vLLM qua nhiều loại bộ tăng tốc; vLLM tiếp cận từng bộ tăng tốc thông qua PyTorch; và khi một thiết bị đã có phần phụ trợ PyTorch hoạt động, plugin phần cứng của vLLM có thể đưa thiết bị đó vào hệ thống để llm-d lập lịch công việc trên thiết bị.

Triển khai ngay từ ngày đầu và kiểm thử liên tục

Trong một bài đăng ngày 20 tháng 8 năm 2026, Nhóm Spyre của IBM giới thiệu HF-adapters, một dự án sử dụng các tác tử lập trình để soạn bản vá trong thời gian chạy, giúp các mô hình Hugging Face Transformers thông thường có thể chạy trên Spyre. Bài đăng cho biết, từ giữa tháng 4 đến cuối tháng 6 năm 2026, 13 bộ chuyển đổi riêng biệt đã hỗ trợ 7.960 trong số 10.000 mô hình nhúng Hugging Face được tải xuống nhiều nhất; trong đó, 6.804 mô hình vượt qua bài kiểm thử đầu-cuối trên Spyre. Một ví dụ thay phép tính torch.pow(x, 3.0) trong hàm kích hoạt gelu_new bằng phép tính tương đương về mặt toán học x x x, vốn có thể được ngăn xếp torch-spyre chuyển đổi thành mã. Con người vẫn đảm nhiệm công việc chẩn đoán, xác định các lỗi chỉ xảy ra trên thiết bị do những phép toán hợp nhất gây ra và đối chiếu kết luận của từng tác tử với kết quả đầu-cuối.

Trong một bài đăng ngày 30 tháng 9 năm 2026, các kỹ sư của IBM và Red Hat mô tả việc tích hợp L2 của torch-spyre với Cross-Repository CI Relay của PyTorch. Cơ chế này kích hoạt kiểm thử ở các dự án phụ thuộc khi PyTorch có thay đổi ở dự án nguồn, đồng thời gửi kết quả trở lại bảng điều khiển CI của PyTorch. Tích hợp này kết hợp quy trình chọn kiểm thử bốn giai đoạn có sử dụng tác tử với một khuôn khổ khai báo bằng YAML để tái sử dụng kiểm thử. Theo các tác giả, khi nâng cấp từ PyTorch 2.13 lên 2.14, việc này đồng nghĩa với đánh giá khoảng 4.000 bài kiểm thử đã thay đổi thay vì hàng chục nghìn bài; họ cho biết thêm rằng dự định phối hợp với nhóm PyTorch để đóng góp ngược các thành phần có thể tái sử dụng, lấy PyTorch OpenReg làm điểm tham chiếu.

Theo bài đăng của IBM, người dùng IBM Z, LinuxONE và Power11 sẽ có thể lấy mô hình từ các hệ sinh thái như Hugging Face và sử dụng gần như những quy trình làm việc dựa trên PyTorch tương tự như khi dùng GPU Nvidia; các điểm mở rộng dùng chung của PyTorch sẽ che giấu phần lớn khác biệt về kiến trúc. Các tác giả bài đăng về vLLM cho biết họ dự định bắt đầu đưa các mô hình không phụ thuộc phần cứng vào CI và dần chuyển sang hướng triển khai này làm mặc định khi phục vụ mô hình trên Spyre.