소식 · · 읽는 시간 14분

Google TorchTPU 오픈소스 공개: PyTorch를 TPU에서 그대로 돌릴 때 달라지는 기본값과 도쿄 v6e

이 글의 차례
  1. 4월 발표와 이번 공개의 차이
  2. 같은 주에 나온 두 백엔드
  3. 돌아가는 것과 빠른 것 사이
  4. 제3자 측정은 서빙 하나
  5. 서울에서 가장 가까운 TPU
  6. 한국 팀에 바뀌는 것
  7. 커뮤니티 반응
  8. 한계
  9. 출처

Google이 2026년 10월 20일 PyTorch Conference 2026에서 TorchTPU를 오픈소스로 공개했습니다. TorchTPU는 Google TPU를 PyTorch의 장치(tpu)로 붙이는 백엔드이고, Meta의 PyTorch 팀과 함께 만들었습니다. 라이선스는 Apache 2.0이고, PyPI에는 0.2.0 판이 올라왔습니다. 코드를 옮기는 일은 model.to("cuda")를 model.to("tpu")로 바꾸는 데서 시작합니다. 다만 한국 팀이 먼저 알아야 할 것은 두 가지입니다. 첫째, TorchTPU의 행렬 곱 기본 정밀도는 BF16이라 CUDA에서 FP32로 돌던 코드는 숫자가 조금 달라질 수 있습니다. 둘째, Google Cloud 문서의 TPU 리전 목록에 서울은 없고, 아시아 태평양에서 TorchTPU 대상 세대(v5e 이후)를 쓸 수 있는 곳은 도쿄의 v6e 하나입니다.

하루 전에는 AWS가 Trainium용 TorchNeuron을 발표했습니다. 이 글에서는 이번 공개로 새로 생긴 것, 두 백엔드의 같은 축 비교, "돌아간다"와 "빠르다" 사이의 거리, 제3자 측정, 리전 문제를 다룹니다.

4월 발표와 이번 공개의 차이

TorchTPU라는 이름은 처음이 아닙니다. Google은 2026년 4월 7일 개발자 블로그에서 TorchTPU의 설계를 먼저 소개했습니다. 그 글에서 공개 GitHub 저장소는 2026년 안에 할 일 목록에 들어 있었습니다. 이번 10월 20일 공개로 바뀐 것은 실제로 설치할 수 있다는 점입니다. GitHub 저장소 google-pytorch/torch_tpu가 열렸고, pip install torch_tpu==0.2.0으로 설치합니다. 지원 Python은 3.11 이상입니다.

공개 범위는 백엔드 하나보다 넓습니다. PyTorch 블로그는 TorchTPU, vLLM-TorchTPU, SGLang-TorchTPU, TorchTitan 네 저장소를 이번 PyTorch Conference에서 연다고 썼습니다. Google Cloud 블로그는 여기에 Ray 지원, 강화학습 프레임워크 VeRL의 TPU 백엔드(미리보기), 이식·진단·추론 성능 튜닝을 자동화하는 TPU agent suite(초기 미리보기)를 더했습니다. Hugging Face는 Transformers v5에서 device_map="tpu"로 모델을 TPU에 올릴 수 있고, 그동안 쓰던 Optimum TPU는 더 필요하지 않다고 밝혔습니다.

이전 방식이 무엇이었는지도 짚어야 합니다. 2020년부터 PyTorch를 TPU에서 돌리는 공식 경로는 PyTorch/XLA였습니다. PyTorch 블로그는 이 방식이 컴파일 구간을 표시하려고 소스 코드를 고쳐야 했고, 컴파일 지연이 컸고, eager 실행을 지원하지 않았다고 직접 적었습니다. TorchTPU는 반대로 eager 실행을 최우선에 두고, 런타임에 JAX 의존성을 두지 않는다는 원칙으로 만들었습니다.

같은 주에 나온 두 백엔드

AWS는 10월 19일 TorchNeuron을 발표했고(오픈소스 공개 베타는 10월 20일), Google은 10월 20일 TorchTPU를 공개했습니다. 두 회사 모두 자사 AI 칩을 PyTorch의 공식 확장 지점(PrivateUse1)으로 등록했습니다. TorchNeuron의 코드 변화와 제약은 AWS TorchNeuron 정리 글에서 다뤘습니다. 두 백엔드를 같은 항목으로 놓으면 다음과 같습니다. 각 회사의 발표 문서와 README에서 직접 정리했습니다.

항목Google TorchTPUAWS TorchNeuron
공개 형태오픈소스, PyPI 0.2.0오픈소스, 공개 베타
라이선스Apache 2.0Apache 2.0
장치 이름tpuneuron
대상 하드웨어TPU v5e 이후 세대에서 검증Trn2, Trn3
Python3.11 이상3.12~3.14
Hugging Face 검증 규모약 5,000개 모델약 100,000개 모델
torch.compile shape현재 dynamic=False로 자동 설정dynamic=False만 지원

두 백엔드는 출발점이 같고 첫 판의 제약도 닮았습니다. 둘 다 입력 shape가 바뀔 때마다 다시 컴파일하는 정적 shape 방식에서 시작합니다. TorchTPU는 이것을 "일시적 제약"이라고 부르고, 최대 크기를 미리 정해 두는 bounded dynamism을 개발 중이라고 밝혔습니다. PyTorch 블로그에 따르면 인과 언어 모델 839개로 이 기능을 시험해 834개(99%)에서 수치가 맞았습니다.

검증 규모의 숫자는 그대로 비교하면 안 됩니다. TorchNeuron의 약 100,000개는 다운로드 기준 실사용을 넓게 덮는 모델 수입니다. TorchTPU의 약 5,000개는 다운로드 상위 모델에서 고른 수이고, 대신 통과율을 공개했습니다. 4,917개 중 4,821개(98%)가 오류 없이 돌았고, 아키텍처 대표 모델 657개 중 638개(97%)가 GPU 기준과 수치가 맞았습니다. 같은 기준으로 잰 비교가 아니므로 어느 쪽이 더 넓다고 판단할 수는 없습니다.

돌아가는 것과 빠른 것 사이

PyTorch 블로그는 "model.to("tpu")로 바꾸기만 해서는 TPU 최고 성능을 낼 수 없다"고 먼저 적었습니다. 모델의 shape, 분산 방식, 연산이 GPU 쪽에 맞춰져 있을 수 있기 때문입니다. 한 줄 변경이 약속하는 것은 실행이지 속도가 아닙니다. 그 차이가 얼마인지는 Google이 공개한 FLUX 이미지 모델 학습 사례가 보여 줍니다. 그림 1은 최적화를 하나씩 더할 때 학습 1단계 시간이 어떻게 줄었는지 직접 정리한 것입니다.

그림 1. TorchTitan FLUX 학습 1단계 시간. eager 기본 11.49초에서 최적화를 모두 더하면 2.78초. PyTorch 블로그의 Google 발표 수치로 직접 정리

단계 하나로 가장 큰 배수를 낸 것은 torch.compile입니다. eager 기본 대비 2.07배이던 속도가 컴파일을 켜자 3.80배가 됐고, 이 단계만 보면 5.55초에서 3.02초로 줄었습니다. 줄어든 초로 따지면 분산 방식 SimpleFSDP가 9.95초에서 6.52초로 가장 많이 줄였습니다. 마지막 모델별 그래프 재작성까지 더하면 11.49초가 2.78초가 되고, 이 4.13배는 두 값을 나눠 직접 계산했습니다. 중간에 들어간 Pallas SplashAttention은 TPU 전용 커널입니다. 그러니 이 사례의 최종 성능은 코드 한 줄이 아니라 TPU 전용 커널과 컴파일 설정까지 얹은 결과입니다.

손을 덜 댄 코드의 수치도 있습니다. Google은 표준 PyTorch 모듈만으로 작성한 Muse Glimmer 30B 모델을 TPU v7 칩 4개로 학습해 MFU(모델 연산 활용률) 38%를 얻었다고 밝혔습니다. 시퀀스 길이 5,120 기준입니다. 원래 GPU용으로 쓰인 TorchTitan 구현을 가져와 FlexAttention을 표준 attention으로 바꾸고 torch.compile과 SimpleFSDP를 적용한 경우는 36%였습니다. FlexAttention은 아직 TorchTPU에서 지원하지 않는다고 블로그에 적혀 있습니다. 이 수치들은 전부 Google이 직접 잰 값입니다.

정밀도 기본값은 코드를 옮길 때 가장 놓치기 쉬운 차이로 보입니다. PyTorch 블로그의 비교표에 따르면 CUDA의 기본 정밀도 모드는 highest(순수 FP32)이고, TorchTPU의 기본은 medium입니다. medium은 곱셈 입력을 BF16으로 바꾸고 누적만 FP32로 합니다. FP32에 가까운 결과가 필요하면 high나 highest를 고를 수 있지만, 연산 비용이 각각 약 3배와 약 6배로 늘어납니다. GPU에서 손실 곡선을 맞춰 둔 학습 코드를 그대로 옮긴다면 첫 비교 실험에서 이 차이를 먼저 의심해야 합니다.

제3자 측정은 서빙 하나

TorchTPU 자체의 학습 성능을 제3자가 잰 자료는 찾지 못했습니다. 제3자 측정이 있는 쪽은 추론 서빙입니다. 반도체 분석 회사 SemiAnalysis는 2026년 9월 7일 자사 벤치마크 InferenceX에 TPU v7(Ironwood)을 미리보기로 올렸습니다. 측정 대상은 TorchTPU 기반 vLLM이 FP8로 서빙한 Qwen3.5 397B입니다. 당시 TorchTPU는 비공개 베타였습니다.

결과는 한쪽으로만 기울지 않았습니다. SemiAnalysis는 FP8 집약(aggregated) 서빙에서 TPU v7이 B200·B300보다 달러당 성능이 최대 50% 높다고 요약했습니다. 구체적인 측정점에서는 사용자당 초당 20토큰 조건의 달러당 토큰이 B200보다 50.4%, B300보다 96.0% 많았습니다. SemiAnalysis는 이 50~96% 우위가 모든 지연 목표가 아니라 이 측정점에만 해당한다고 밝혔습니다. 같은 문단에서 고동시성 결과에는 지연 시간의 대가가 따른다며 예를 들었는데, 동시 요청 256개에서 첫 토큰까지 걸린 평균 시간은 TPU 5.41초, B200 3.75초, B300 2.40초로 TPU가 가장 느렸습니다. FP4 서빙에서는 TPU v7에 네이티브 FP4 연산이 없어 NVIDIA GPU가 앞선다고 했습니다. Google 내부 TCO를 적용해 집약 서빙 TPU v7과 분리(disaggregated) 서빙 GB300 NVL72를 비교한 조건에서는, 중간 지연 구간에서 GB300이 달러당 성능으로 약 30% 앞선다고 적었습니다.

이 측정이 완전히 독립적이라고 보기는 어렵습니다. SemiAnalysis는 같은 글에서 Google 담당자 15명의 이름과 Inferact 팀을 들어 감사를 표했고, 결과를 "Official Preview"로 표시했습니다. PyTorch 블로그는 이 결과를 "third-party inference audit"이라고 부릅니다. 벤더와 함께 준비한 제3자 측정으로 읽는 것이 맞아 보입니다.

서울에서 가장 가까운 TPU

TorchTPU를 쓰려면 TPU가 있는 곳에 가야 합니다. 2026년 10월 20일 갱신된 Google Cloud TPU 리전 문서에서 TorchTPU가 검증한 세대(v5e 이후)를 쓸 수 있는 영역을 직접 정리했습니다.

지역TPU7x(Ironwood)v6ev5e·v5p
북미us-central1의 2개 영역5개 영역5개 영역
유럽없음europe-west4europe-west4
아시아 태평양없음asia-northeast1(도쿄)없음
남미없음southamerica-west1없음

아시아 태평양에서 TorchTPU 대상 세대는 도쿄의 v6e 하나입니다. 서울(asia-northeast3)에는 TPU가 하나도 없습니다. 아시아 태평양에 있는 나머지 TPU는 대만 asia-east1 영역의 v2-8 하나뿐이고, v2는 TorchTPU가 검증했다고 밝힌 범위 밖입니다. Google이 공개한 성능 수치 대부분이 나온 TPU v7(문서 표기 TPU7x)은 미국 중부에만 있습니다. 문서는 칩 수가 많은 구성일수록 수량이 제한된다고 덧붙였습니다. 실제 가용 여부는 콘솔에서 다시 확인해야 합니다.

한국 팀에 바뀌는 것

TorchTPU가 바꾸는 것은 TPU를 시험해 보는 비용입니다. 이전에는 PyTorch 팀이 TPU를 쓰려면 PyTorch/XLA의 방식에 맞춰 코드를 고치거나 JAX를 새로 배워야 했습니다. 이제는 기존 코드를 eager로 돌려 보면서 어디서 막히는지부터 확인할 수 있습니다. Hugging Face 모델을 쓰는 팀이라면 device_map="tpu" 한 줄로 첫 실험을 시작할 수 있습니다.

지역 조건은 하루 전 TorchNeuron과 반대 방향입니다. TorchNeuron이 도는 Trn2는 서울과 도쿄 모두에 없었습니다. TorchTPU는 서울에는 없지만 도쿄에 v6e가 있습니다. 서울 리전에 남아야 하는 서비스는 두 백엔드 모두 직접 쓰기 어렵습니다. 국외 리전을 쓸 수 있는 팀에게는 지연 시간 면에서 도쿄 v6e가 두 칩 가운데 가장 가까운 선택지로 보입니다. 다만 개인정보가 오가는 서빙이라면 국외 이전 검토가 먼저입니다.

시험 순서도 정할 수 있습니다. 첫 단계는 eager로 정확도를 GPU와 맞추는 일이고, 여기서 BF16 기본 정밀도를 의식해야 합니다. 그다음 분산 방식을 정하고 torch.compile을 켜면서 입력 shape를 패딩이나 버킷으로 고정합니다. FLUX 사례에서도 속도의 큰 몫은 분산 방식과 컴파일에서 나왔고, TPU 전용 커널의 몫(6.52초에서 5.55초)은 그보다 작았습니다. 그래서 커널 작업은 뒤로 미뤄도 되는 것으로 보입니다. 길이가 제각각인 텍스트 생성 서빙이라면 Google과 파트너가 TPU용으로 최적화하고 있는 vLLM-TorchTPU 같은 서빙 엔진을 쓰는 편이 직접 튜닝보다 현실적으로 보입니다.

커뮤니티 반응

Hacker News에서는 공개 당일 올라온 GitHub 저장소 링크 게시물이 확인한 시점에 333점, 댓글 73개였습니다. 반기는 쪽의 댓글은 이전 경험과 비교했습니다. 사용자 ismailmaj는 이렇게 썼습니다. "I remember the days when you had to fight XLA to make PyTorch run on TPUs, it seems we finally got first-party support!" 다른 사용자 mathisfun123은 TorchTPU를 PyTorch/XLA의 대체로 읽었습니다.

유보하는 쪽은 하드웨어를 어디서 쓰느냐를 물었습니다. "Are there TPUs outside Google Cloud?"라는 질문과 "where can I buy a TPU?"라는 댓글이 달렸습니다. 사용자 atty는 Google의 온프레미스 TPU 판매를 두고, 자기 회사가 GCP를 비교적 많이 쓴다고 밝히며 이렇게 적었습니다. "We've evaluated them but decided to stick with Nvidia, at least for one more generation." 소프트웨어 문턱이 낮아진 것과 별개로, 하드웨어 접근성이 다음 문턱이라는 반응으로 보입니다. Reddit과 X에서는 확인한 시점까지 의미 있는 토론을 찾지 못했습니다.

한계

항목내용
직접 실행TPU에서 TorchTPU를 돌려 보지 않았다. 표와 그림은 공식 발표 수치를 정리한 것
성능 수치학습 성능은 전부 Google 발표. 제3자 측정은 서빙 하나이고, 벤더와 함께 준비한 미리보기
FLUX 사례사례 전체는 TPU v6e·v7x에서 평가했다고 적혀 있지만, 단계별 시간 측정의 세대와 칩 수는 따로 적혀 있지 않다
비교표두 회사의 검증 방식이 달라 Hugging Face 검증 규모는 같은 기준이 아니다
리전 정보2026-10-20 갱신 문서 기준. 콘솔의 실제 가용 수량과 다를 수 있다
가격이 글은 TPU 요금을 다루지 않았다. 리전마다 요금이 달라 따로 확인이 필요하다

이 글의 비교는 첫 공개 판 기준입니다. TorchTPU는 bounded dynamism의 정식화와 차세대 TPUv8용 FP8·FP4 지원을, TorchNeuron은 FP8 정식 지원을 다음 과제로 밝혔습니다. TorchNeuron은 동적 shape를 첫 판에서 의도적으로 뺐다고만 적었습니다. 그러므로 표의 제약 항목은 릴리스마다 바뀔 수 있습니다.

출처

1 / 1