PyTorch 앱 TPU·트레이니움 이식, 갈아탈 기준

AI 앱의 85%가 PyTorch 위에서 만들어진다는 추산이 있다. 그런데 이 도구는 처음부터 엔비디아 GPU에 맞춰 다듬어졌다. 개발자가 따로 신경 쓰지 않으면 결과물은 저절로 ‘엔비디아 칩에서 돌아가는 앱’이 된다.

구글과 아마존이 이 기본값을 동시에 건드렸다. 구글은 TorchTPU를 오픈소스로 공개했고, 아마존은 TorchNeuron을 내놨다. 엔비디아 말고 다른 칩으로 가는 길이 두 갈래 생긴 셈이다. 다만 둘 다 ‘더 빠른 칩’을 파는 도구는 아니다. 이사 비용을 낮춰 주는 통로에 가깝다.

통로가 열렸다고 당장 짐을 쌀 이유는 없다. 옮길지 말지 판단할 재료는 칩 성능 소문보다 내 코드와 내 클라우드 계약서에 더 많이 들어 있다.

2016년 메타에서 출발, 기본값은 처음부터 엔비디아

PyTorch는 AI 모델을 설계하고, 학습시키고, 실제 서비스에서 돌리는 데 쓰는 오픈소스 도구 모음이다. AI 앱 개발자와 스타트업이 가장 널리 쓰는 도구로 꼽힌다.

출발은 2016년 메타(당시 페이스북). LLM이 세상을 바꾸리라고는 누구도 짐작하지 못하던 때다. AI 연구용 하드웨어의 표준은 이미 엔비디아 GPU였고, PyTorch의 많은 기능도 그 칩을 기준으로 설계됐다.

2022년에는 관리 주체가 바뀌었다. 메타가 PyTorch를 리눅스 재단에 넘겼다. 여러 핵심 오픈소스 프로젝트를 관리하는 비영리 단체다. 간판은 중립으로 바뀌었지만, 코드 곳곳에 밴 엔비디아 중심 설계까지 한꺼번에 바뀌지는 않았다.

그래서 생긴 구도는 이렇다.

• 새 프로젝트를 시작할 때마다 엔비디아 칩을 전제로 코드를 쓰게 된다.
• 경쟁사 칩은 성능이 좋아도 ‘옮기는 수고’라는 벽부터 넘어야 한다.
• 엔비디아의 강점을 칩 성능만으로 설명할 수 없는 이유다. 이 기본값도 강점이다.

TorchTPU와 TorchNeuron이 겨냥하는 곳이 이 벽이다. 칩 성능 경쟁으로 읽으면 핵심을 놓친다. 이미 써 둔 코드를 다른 칩으로 옮기는 비용을 누가 더 낮추느냐의 경쟁이다.

구글은 주변 도구를, 아마존은 PyTorch 본체를 손본다

목표는 같다. 기존 PyTorch 앱을 다시 짜지 않고 자사 칩과 클라우드로 데려오는 것.

• TorchTPU: 구글의 AI 칩 TPU(Tensor Processing Unit)와 구글 클라우드로 가는 길. 구글은 간단한 설정 변경만으로 이전이 가능하다고 설명한다.
• TorchNeuron: 아마존이 직접 만든 AI 칩 Trainium과 AWS로 가는 길.

차이는 각자 덧붙인 전략에서 드러난다.

구분	기존 PyTorch + 엔비디아 GPU	TorchTPU (구글)	TorchNeuron (아마존)
대상 칩	엔비디아 GPU	TPU	Trainium
연결되는 클라우드	대부분 AI 앱의 기본 실행 환경	구글 클라우드	AWS
기존 코드 이전	해당 없음(출발점)	설정 변경, 앱 재작성 불필요	앱 재작성 없이 이식
주변 도구 연동	PyTorch 기능 다수가 이 칩 기준으로 설계	메타·허깅페이스·Inferact(vLLM)·RadixArk(SGLang) 등과 직접 협업	따로 알려진 내용 없음
이전 지원 도구	—	TPU agent suite(이전·오류 수정 지원)	따로 알려진 내용 없음
추가 행보	—	LiteRT의 PyTorch 호환 개선	본가 PyTorch에 엔비디아 종속 기능 분리 코드 제출
공개 형태	리눅스 재단 관리 오픈소스	오픈소스 프로젝트	따로 알려진 내용 없음

표의 아마존 열을 보면 ‘따로 알려진 내용 없음’이 세 칸이다. 주변 도구 연동, 이전 지원 도구, 공개 형태가 모두 비어 있다. 지금 시점에서 두 도구를 같은 무게로 놓고 비교하기 어려운 이유다.

구글이 공을 들인 건 주변 도구와의 궁합이다. 메타, 허깅페이스, vLLM을 만드는 Inferact, SGLang을 만드는 RadixArk 등과 직접 협업했다. 원래 PyTorch에서 쓰던 이 도구들이 TorchTPU에서도 제대로 맞물리게 하려는 작업이다.

여기에 두 가지를 더 얹었다.

• TPU agent suite: 앱을 TPU와 구글 클라우드로 옮기면서 생기는 오류까지 잡아 주는 전용 도구.
• LiteRT 개선: 스마트폰·노트북·임베디드 기기에서 AI를 돌리는 LiteRT를 PyTorch 앱과 더 잘 맞도록 손봤다.

아마존은 출발점 자체를 건드린다. 자사 칩 전용 버전을 내고 끝내지 않았다. 본가 PyTorch 프로젝트에 엔비디아 칩과 엮여 있던 여러 기능을 떼어 내는 코드를 제출하고 있다.

이 코드가 반영되면 TorchNeuron 사용자만 덕을 보는 게 아니다. TorchNeuron을 쓰지 않는 개발자도 처음부터 하드웨어를 덜 가리는 PyTorch를 쓰게 된다. 구글이 ‘우리 칩으로 오는 길’을 닦는다면, 아마존은 길이 시작되는 지점을 중립 쪽으로 옮기려 한다.

칩 성능보다 먼저 따질 네 가지: 코드, 서빙 도구, 클라우드, 팀

‘재작성 없이 이전’이라는 문구만 믿고 움직이기엔 이르다. 아래 네 가지를 차례로 따지면 판단이 빨라진다.

기준	확인할 것	유리한 쪽
① 엔비디아 의존도	GPU 전용 확장 라이브러리·직접 만든 GPU 연산 사용 여부	PyTorch 표준 기능 비중이 높은 앱
② 서빙 도구	vLLM·SGLang·허깅페이스 등 핵심 도구의 TPU·Trainium 지원	구글 협업 목록에 든 도구를 쓰는 팀
③ 클라우드	데이터 위치, 할인 약정·크레딧, 데이터 이전 비용, 보안 심사	이미 해당 클라우드에 자리 잡은 팀
④ 팀 역량	낯선 오류를 감당할 인력이 있는지	전담 인력이 있는 팀(없다면 추론부터)

① 코드가 엔비디아 전용 기능에 얼마나 묶여 있나. PyTorch 기본 기능만으로 짠 앱과 GPU 전용 확장 라이브러리나 직접 만든 GPU 연산을 끼워 넣은 앱은 이식 난이도부터 다르다. ‘재작성 불필요’라는 설명은 PyTorch가 관리하는 범위 안의 이야기일 가능성이 크고, 그렇게 전제하는 편이 안전하다. 표준 기능 비중이 높을수록 이사 비용은 내려간다.

② 쓰고 있는 서빙 도구가 지원되나. 모델 서비스에 vLLM이나 SGLang을 쓰고 모델은 허깅페이스에서 받아 오는 팀이라면, 구글이 이 도구 제작사들과 직접 협업했다는 점이 꽤 실질적인 이점이다. 파이프라인의 핵심 도구가 협업 목록에 없다면 순서가 바뀐다. 그 도구 문서에서 TPU·Trainium 지원 여부부터 확인할 일이다.

③ 칩 선택은 곧 클라우드 선택. TPU는 구글 클라우드, Trainium은 AWS와 묶여 있다. 총비용에는 칩 성능보다 아래 항목들이 더 크게 작용할 수 있다.

• 학습 데이터가 어느 클라우드에 쌓여 있나
• 어느 클라우드와 할인 약정이나 크레딧이 있나
• 데이터를 다른 클라우드로 옮기는 비용은 얼마인가
• 사내 보안 심사 절차를 새로 밟아야 하나

④ 팀이 낯선 오류를 감당할 수 있나. 대부분의 AI 앱이 엔비디아 칩을 기준으로 만들어지니, GPU 쪽은 오류 메시지만 검색해도 참고할 사례가 많다. 새 하드웨어는 그런 사례가 상대적으로 적을 수밖에 없다. 구글이 오류 수정을 돕는 TPU agent suite를 따로 내놓은 것도 이 장벽을 의식해서로 보인다.

전담 인력이 없는 작은 팀이라면 학습보다 추론(서비스) 단계부터 시험하는 편이 부담이 적다. 학습은 오래 걸리고 중간에 멈추면 손실이 크다. 추론은 모델 하나 단위로 결과와 비용을 비교하기 쉽다.

옮기기 전 6단계 점검, 의존성 목록부터 복귀 경로까지

TorchTPU·TorchNeuron의 세부 설정 항목은 버전이 올라가면서 바뀔 수 있다. 실제 작업은 각 프로젝트 공식 문서를 따르고, 준비 순서만 아래처럼 잡아 두면 시행착오가 줄어든다.

1. 의존성 목록 훑기: 패키지 목록 파일을 열고 GPU 전용으로 빌드된 패키지에 표시해 둔다. 이 목록이 짧을수록 ‘설정 변경만으로 이전’에 가까워진다.
2. 하드웨어 지정 코드 한곳에 모으기: 장치 이름을 문자열로 직접 적은 곳, GPU가 있는지 확인하는 분기문을 코드 전체에서 찾아 설정 파일이나 환경 변수 하나로 모은다. 하드웨어를 바꿀 때 이 값 하나만 고치면 되는 구조를 목표로 한다.
3. 칩 사용 한도 확인: 새 칩은 계정별 사용 한도(쿼터)가 낮게 잡혀 있을 수 있다. 구글 클라우드는 콘솔 → IAM 및 관리자 → 할당량 및 시스템 한도(영문 IAM & Admin → Quotas & System Limits, 한국어 표기는 확실하지 않음)에서 TPU로 필터링해 확인한다. AWS는 Service Quotas 콘솔 → AWS 서비스 → Amazon EC2에서 Trainium 관련 항목을 검색한다(항목이 인스턴스 계열명으로 표시될 수 있어 검색어는 확실하지 않음).
4. 작은 모델로 정답 대조: 같은 입력을 기존 GPU 환경과 새 칩에 넣고 출력 차이를 비교한다. 연산 방식이 달라 숫자가 미세하게 어긋날 수 있다. 허용 오차를 미리 정해 두면 ‘버그냐, 정상 범위냐’를 두고 벌어지는 논쟁이 줄어든다.
5. 속도·비용은 같은 조건에서: 배치 크기, 입력 길이, 정밀도 설정을 맞춘 다음 처리량과 시간당 비용을 잰다. 조건이 다르면 비교 숫자는 의미가 없다.
6. 되돌아갈 길 남기기: 기존 GPU 환경의 컨테이너 이미지와 설정은 지우지 말고 보관한다. 전환 초기에는 두 환경을 함께 돌리면서 트래픽 일부만 새 칩으로 보내는 방식이 안전하다.

여섯 단계 가운데 2번은 결국 옮기지 않기로 하더라도 해 둘 만한 작업이다. 이유는 마지막 문단에 있다.

한국 팀은 클라우드 견적서에 비교 대상이 늘어난다

한국에서 AI 서비스를 만드는 팀에게 가장 직접적인 변화는 선택지의 개수다.

지금까지는 PyTorch로 만든 서비스를 다른 칩에서 돌리려면 손볼 게 많았다. 그 비용 탓에 엔비디아 GPU 외의 칩은 검토 대상에서 빠지기 일쑤였다. 이제 재작성 없이 옮길 수 있다는 도구가 두 개다. 클라우드 견적을 받을 때 GPU 인스턴스와 TPU·Trainium을 나란히 놓고 비교하는 일이 현실적인 업무가 된다.

시작은 ‘이미 자리 잡은 곳’에서 하는 게 합리적이다.

팀 상황	먼저 시험해 볼 것
AWS에 데이터와 계약이 쌓인 팀	TorchNeuron
구글 클라우드 크레딧이 있는 팀	TorchTPU
허깅페이스·vLLM 중심으로 서빙하는 팀	TorchTPU
스마트폰 앱에 AI 기능을 넣는 앱 개발사	LiteRT 업데이트

클라우드를 옮기는 비용까지 떠안고 칩을 바꾸면, 이식이 쉬워진 이점은 금방 상쇄된다. 지연 시간에 민감한 국내 서비스라면 확인할 게 하나 더 있다. 쓰려는 리전에서 해당 칩을 쓸 수 있는지를 콘솔에서 먼저 봐야 한다.

국내 앱 개발사에는 LiteRT 업데이트가 더 피부에 와닿을 수 있다. PyTorch로 만든 모델을 폰이나 노트북에 올리는 과정이 매끄러워진다는 뜻이기 때문이다. 다만 개선 폭을 보여 주는 구체적인 수치는 나와 있지 않다. 기존 변환 과정에서 막혔던 모델이 있다면 다시 시도해 보는 정도가 현실적이다.

채용 시장에도 변화가 생길 수 있다(추측). ‘GPU 최적화 경험’만큼이나 ‘여러 하드웨어로 모델을 옮겨 본 경험’이 이력서에서 눈에 띄는 항목이 될 가능성이 있다. 클라우드 비용이 곧 생존 문제인 스타트업일수록 이런 이식 역량의 가치는 올라갈 것으로 보인다.

확인된 것과 아직 불확실한 것

확인된 것

• 구글은 TorchTPU를 오픈소스 프로젝트로 공개했고, 설정 변경만으로 기존 PyTorch 앱을 재작성 없이 TPU·구글 클라우드로 옮길 수 있다고 설명했다.
• 아마존의 TorchNeuron은 PyTorch 앱을 재작성 없이 Trainium·AWS로 이식하게 해 준다.
• 아마존은 엔비디아 칩과 엮인 기능을 분리하는 코드를 본가 PyTorch 프로젝트에 제출하고 있다.
• 구글은 메타, 허깅페이스, Inferact, RadixArk 등과 협업했고, TPU agent suite를 내놓았으며, LiteRT를 PyTorch 앱에 맞게 업데이트했다.
• PyTorch는 2016년 메타가 개발했고 2022년 리눅스 재단으로 넘어갔다.

아직 불확실한 것

• ‘재작성 불필요’가 직접 만든 GPU 연산이나 GPU 전용 외부 라이브러리까지 포함하는지
• 같은 모델을 돌렸을 때 엔비디아 GPU 대비 TPU·Trainium의 속도와 비용 차이
• 아마존이 제출한 코드가 본가 PyTorch에 언제, 어디까지 반영될지
• TorchNeuron의 공개 방식과 주변 도구 협업 범위
• 한국 리전에서 TPU·Trainium을 어느 규모로 쓸 수 있는지

엔비디아에 남더라도 ‘갈아끼울 수 있는 코드’는 남는 장사

옮기기 쉬워졌다고 AI 개발자들이 엔비디아 하드웨어를 한꺼번에 버리지는 않을 것이다. 테크크런치도 이 대목에서는 선을 그었다. 팀에 쌓인 노하우, 익숙한 디버깅 방식, 검증된 성능 데이터. 설정 한 줄로 옮겨지지 않는 것들이다.

그렇다고 흐름이 바뀌지는 않는다. 아마존과 구글은 엔비디아의 기본값 우위를 끝내려고 분명하게 움직이고 있다.

개발팀이 손해 보지 않는 전략은 당장 칩을 바꾸는 게 아니다. ‘언제든 바꿀 수 있는 상태’를 만들어 두는 것이다.

• 하드웨어 지정을 한곳에 모은다.
• 표준 PyTorch 기능 위주로 코드를 짠다.
• 다른 칩에서 결과를 대조할 테스트를 갖춰 둔다.

이 준비만 돼 있으면 GPU 공급이 빠듯할 때나 클라우드 계약을 갱신할 때 TorchTPU나 TorchNeuron을 협상 카드로 꺼낼 수 있다. 아마존이 제출한 코드가 본가 PyTorch에 반영될수록 이 습관은 더 큰 효과를 낸다.

출처: TechCrunch