IBM, Spyre 가속기를 PyTorch의 일급 백엔드로 만들다

IBM은 2026년 10월 26일에 게시된 IBM Research 블로그 게시물에서 2026년 하반기에 PyTorch 생태계 전반에 적용된 소프트웨어 업데이트를 통해 자사의 Spyre 데이터플로 가속기가 PyTorch의 일급 백엔드가 됐다고 밝혔다. 이는 IBM과 PyTorch Foundation이 2025년 10월에 제시한 계획을 실현한 것이다.

IBM은 Spyre를 추론에 최적화된 자사의 데이터플로 AI 가속기로 설명하며, IBM Z, LinuxONE, Power 시스템에서 애플리케이션 및 데이터와 함께 AI를 실행하는 엔터프라이즈 팀을 위해 설계됐다고 밝혔다. Spyre의 저정밀도 연산은 언어 생성 및 임베딩 모델의 행렬 연산 중심 작업을 겨냥한다. 예약된 스레드 그룹을 통해 명령어 스트림 형태로 커널을 실행하는 기존 GPU와 달리, Spyre는 데이터가 연산 엔진에 도착하는 즉시 연산을 시작한다.

게시물에 따르면 2026년 하반기에 IBM, Red Hat, 그리고 Meta와 Hugging Face를 포함한 PyTorch Foundation 협력사들은 모델의 첫날부터 사용할 수 있는 지원, vLLM에서의 하드웨어 독립적 모델, 지속적인 회귀 테스트 및 릴리스 테스트, 네이티브 디바이스 통합을 아우르는 업데이트를 내놓았다. 2025년 10월 21일자 IBM Research 게시물에서 IBM은 PyTorch Conference 2025를 맞아 2026년에 Spyre 지원을 한층 강화할 계획이라고 밝혔다. 여기에는 Spyre를 오픈 소스 추론 워크플로의 일급 백엔드로 활용하는 방안과 통합 컴파일러 경로, 최적화된 커널 생성, 여러 가속기의 투명한 스케줄링에 중점을 두는 내용이 포함됐다. 당시 IBM은 이미 vLLM을 추론 런타임으로, torch.compile을 Spyre와 같은 가속기를 통합하기 위한 프런트엔드 컴파일러로 채택한 상태였다. 또한 대규모 언어 모델 추론에 페이징 어텐션을 사용할 수 있도록 하는 Spyre 플러그인을 vLLM에 기여했다.

Inductor 기반으로 재구축된 컴파일러

통합의 중심에는 PyTorch 백엔드인 torch-spyre가 있다. 이 백엔드는 일반적인 PyTorch 코드를 Spyre에서 실행할 수 있는 실행 계획으로 컴파일한다. 모델 로직의 대부분은 변경 없이 PyTorch 컴파일러를 거치며, 아직 효과적으로 변환할 수 없는 연산이 있으면 어댑터가 이를 컴파일러가 처리할 수 있는 수학적으로 동등한 형태로 대체할 수 있다.

2026년 10월 13일에 게시된 PyTorch Foundation 게시물에서 Dave Grove, Olivier Tardieu, IBM Spyre 팀은 torch-spyre의 torch.compile 백엔드를 완전히 처음부터 구축한 컴파일 스택인 sendnn에서 backend=inductor로 옮긴 과정을 설명했다. backend=inductor는 PyTorch 자체 Inductor를 확장해 만든 오픈 소스 백엔드다. 저자들에 따르면 lizard 코드 분석기로 측정했을 때 sendnn은 6,170개 함수에 걸쳐 C++ 및 Python 코드 약 273,000줄로 구성된 반면, Inductor 확장판은 1,878개 함수에 걸쳐 Python 코드 약 38,600줄로 구성됐다. 줄 수는 약 7분의 1로 줄었으며 함수당 복잡도도 낮아졌다.

Spyre는 75와트 전력의 PCIe 연결 가속기로, 링을 통해 서로 연결된 소형 코어 32개로 구성된다. 각 코어에는 공유 캐시 대신 2MB 스크래치패드가 있으며, 데이터는 스틱이라고 하는 고정 크기 128바이트 단위로 이동한다. 게시물에 따르면 컴파일러 작업은 스틱 단위 데이터 이동, 스크래치패드 계획, 컴파일 시점의 코어 할당에 집중됐다.

보고된 측정 결과에는 타일링 및 레이아웃 선택을 통해 행렬 곱셈 커널 시간이 29~69% 줄어든 사례, 스크래치패드를 고려한 스케줄링으로 소프트맥스 커널의 중앙값 시간이 32.51마이크로초에서 23.67마이크로초로 감소해 27% 단축된 사례가 포함된다. 또 융합된 MLP 스타일 커널은 코어 활용률을 약 3분의 2에서 약 80%로 높이는 동시에 커널 시간을 약 17% 줄였다. 이러한 결정을 시험하도록 만든 합성 그래프에서는 새로운 온칩 레이아웃 변경 방식이 디바이스 메모리를 왕복하는 데 걸리던 80마이크로초를 코어 간 1.1마이크로초 셔플로 대체했다. 게시물은 torch-spyre가 디바이스별 분해 규칙을 등록해야 했던 점이 Inductor의 외부 백엔드 지원 개선을 이끄는 데에도 기여했으며, 그 개선 사항은 병합된 풀 리퀘스트 두 건을 통해 PyTorch 2.12에 반영됐다고 덧붙였다.

네이티브 디바이스 통합

Spyre는 PrivateUse1 등록을 통해 네이티브 PyTorch 디바이스가 되며, 이에 따라 tensor.to(“spyre”)는 실제 디바이스 정체성을 갖는다. PyTorch 할당자의 스토리지는 텐서가 디바이스에 상주하도록 하고, 스트림은 실행 순서를 보장하며, 런타임 이벤트는 서로 다른 스트림에서 종속된 작업을 연결한다. 카드에는 고대역폭 링으로 연결된 코어 32개가 탑재되어 있고, 각 코어에는 2MB의 로컬 스크래치패드가 있다. 또한 텐서와 프로그램을 위한 LPDDR5 메모리를 최대 128GB까지 지원한다. 현재 런타임은 프로그램을 실행 시점에 패치하며, 세 단계의 정해진 순서에 따라 기호 주소로 표시된 텐서 주소를 실제 주소로 바꾼다.

팀에 따르면 배치 크기 1, 시퀀스 길이 1024로 Granite 3.3 8B를 시연한 결과, 그래프 생성을 데이터 전송 경로에서 분리해 프리필 속도가 9.9%, 디코드 속도가 13.6% 향상됐다. 이 작업을 연산 디스패치에서도 제거하자 전체 성능은 프리필에서 1.7배, 디코드에서 2.4배 빨라졌으며, 향상분의 약 4분의 3은 연산 경로에서 비롯됐다.

저자들은 2026년 10월 8일에 게시된 네이티브 PyTorch 디바이스로 Spyre 구축하기에서 “Spyre도 PyTorch도 다른 무언가인 척할 필요가 없다는 점이 장점”이라고 썼다. 이어 Spyre는 데이터플로 실행 모델을 유지하면서 사용자는 익숙한 텐서 배치, 스트림, 컴파일 기능을 갖춘 네이티브 PyTorch 디바이스를 사용할 수 있다고 덧붙였다.

vLLM의 이식성과 Llm-D 연동

Spyre는 AI 소프트웨어에서 가장 일반적으로 지원되는 GPU 플랫폼 중 하나가 아니라 외부 소스 트리 방식의 가속기다. 모델 그래프를 추적하는 데 TorchDynamo를, 해당 그래프를 대상 하드웨어에 맞게 낮추는 데 TorchInductor를 사용한다. vLLM에서는 CustomOp 및 PluggableLayer와 같은 확장 메커니즘을 통해 하드웨어 플러그인이 소프트웨어 스택의 상당 부분을 다시 구현하지 않고도 동작을 맞춤 설정할 수 있다.

2026년 9월 22일 IBM, Meta, Hugging Face 소속 저자들이 발표한 vLLM의 하드웨어 독립형 모델에서는 하드웨어별 “플랫” 모델 정의로 전환하는 vLLM의 방향을 설명하고, 네 가지 설계 원칙에 기반한 하드웨어 독립형 레이어를 소개했다. 이 레이어는 컴파일 가능하고, 확장 가능하며, 하드웨어별 경로와 분리되고, 이식 가능해야 한다. 초기 지원은 vLLM의 메인 브랜치에 반영됐으며, transformers 백엔드에서 USE_HW_AGNOSTIC=1을 설정해 활성화할 수 있다. 이 방식은 Gemma 4, Qwen3, Granite 4.2를 비롯한 모델에서 Spyre 외부 소스 트리 플러그인을 사용해 검증됐다. 저자들에 따르면 NVIDIA H100 GPU에서 하드웨어 독립형 레이어의 전체 토큰 처리량은 최신 모델 세 개의 기하평균 기준으로 네이티브 구현의 3.4% 이내였다.

IBM 게시물에 따르면 Spyre의 PyTorch 통합은 llm-d와 연결되는 방식이기도 하다. llm-d는 vLLM을 기반으로 여러 종류의 가속기에서 분산 추론을 수행하고, vLLM은 PyTorch를 통해 각 가속기에 연결된다. 따라서 기기에서 작동하는 PyTorch 백엔드만 갖춰지면 vLLM 하드웨어 플러그인이 해당 기기를 노출할 수 있어 llm-d가 그 기기에 작업을 할당할 수 있다.

첫날부터 지원하고 지속적으로 테스트

2026년 8월 20일자 게시물에서 IBM Spyre 팀은 기본 Hugging Face Transformers 모델이 Spyre에서 실행되도록 런타임 패치를 작성하는 코딩 에이전트를 활용하는 프로젝트 HF-adapters를 소개했다. 게시물에 따르면 2026년 4월 중순부터 6월 말까지 서로 다른 어댑터 13개가 가장 많이 다운로드된 Hugging Face 임베딩 모델 10,000개 중 7,960개를 지원하게 됐으며, 그중 6,804개가 Spyre에서 엔드투엔드 테스트를 통과했다. 한 예로 gelu_new 활성화 함수의 torch.pow(x, 3.0)을 수학적으로 동일한 x x x로 바꾸면 torch-spyre 스택에서 연산을 낮출 수 있다. 사람은 진단 작업을 계속 맡아 융합 연산에서 비롯되는 기기 전용 오류의 원인을 찾고, 각 에이전트의 결론을 엔드투엔드 결과와 대조한다.

2026년 9월 30일자 게시물에서 IBM과 Red Hat의 엔지니어들은 PyTorch의 Cross-Repository CI Relay와 torch-spyre의 L2 통합을 설명했다. 이 통합은 업스트림 PyTorch 변경 사항이 있을 때 다운스트림 테스트를 실행하고 결과를 PyTorch CI 대시보드에 다시 보고한다. 이 통합에는 에이전트 기반 4단계 테스트 선정 파이프라인과 선언형 YAML 테스트 재사용 프레임워크가 결합돼 있다. 저자들에 따르면 PyTorch 2.13에서 2.14로 업그레이드할 때는 변경된 테스트 약 4,000개를 평가하면 됐으며, 이는 수만 개를 평가하는 것보다 적은 수다. 저자들은 재사용 가능한 부분을 업스트림에 반영하기 위해 PyTorch 팀과 협력할 계획이라고 덧붙이며, PyTorch OpenReg를 기준점으로 삼았다.

IBM 게시물에 따르면 IBM Z, LinuxONE, Power11 사용자가 기대하는 환경은 Hugging Face와 같은 생태계에서 모델을 가져와 Nvidia GPU를 사용할 때와 대체로 동일한 PyTorch 기반 워크플로를 이용하는 것이다. 공유되는 PyTorch 확장 지점이 아키텍처 간 차이의 상당 부분을 감춰준다. vLLM 게시물의 저자들은 CI에 하드웨어 독립형 모델을 포함하는 작업을 시작하고, Spyre에서 모델을 제공할 때 점차 이 방식을 기본 경로로 전환할 계획이라고 밝혔다.