DruckFin

구글 대담: TPU, 분산 시스템, 프런티어 AI 모델의 공동 설계

구글 데브랩스(Dev Labs) 파이어사이드 챗: 제프 딘·빌 지아의 AI 시스템 확장 전략 (2026년 9월 20일)

소개 및 구글의 창립 초기

진행자: 여러분, 환영합니다. 뜨거운 호응과 함께 참석해 주셔서 진심으로 감사합니다. 이번이 벌써 7번째 데브랩스 행인데, 개최할 때마다 규모와 내용 면에서 모두 진화하고 있으며 이번이 단연 최고입니다. 관심이 뜨거웠고 보내주신 피드백에도 감사드립니다. 오늘 진행 방식은 몇 가지 질문을 통해 TPU의 진화 과정을 살펴보는 것으로 시작하겠습니다. 제프는 더 이상 긴 설명이 필요 없는 분이죠. 구글의 30번째 입사자였습니다. 먼저 그 이야기부터 시작해 보겠습니다. 그리고 빌도 함께 자리해 질문을 던져주실 텐데요, AI 인프라 실행 현황과 비전, 그리고 향후 몇 년간의 실행 계획에 대해서도 인사이트를 나누어 주실 예정입니다. 좋습니다, 시작해 볼까요? 제프, 구글의 30번째 입사자였던 시절에 대해 조금 더 말씀해 주시죠.

제프 딘: 네, 그렇습니다.

진행자: 1999년이네요. 여기 계신 대부분 분들은 그때 태어나지 않았거나, 태어났어도 기저귀를 차고 있었을 텐데요. 당시 분위기는 어땠나요?

제프 딘: 정말 재미있었습니다. 제가 합류했을 당시에는 팔로알토 시내의 아주 작은 사무실에 모두 모여 있었어요. 지금의 T모바일 매장 위층에 샌드위치처럼 끼어 있는 정도의 규모였죠. 우리는 정말 고품질의 검색 제품을 만들고자 했습니다. 저는 이전 직장에서 정보 검색, 특히 웹의 그래프 구조를 활용해 기존 페이지 정보를 보강하는 등의 작업을 통해 이에 대한 경험을 조금 쌓은 상태였습니다. 그래서 구글은 연구실 분위기에서 벗어나 내 작업이 사람들에게 직접 쓰이는 환경에서 그 아이디어를 시도해 볼 수 있는 자연스러운 장소처럼 느껴졌고 정말 재미있었습니다. 에너지가 넘쳤고, 트래픽은 매주 약 7%씩 성장했습니다. '1.07의 52제곱'을 해보면 매년 엄청난 규모로 불어나는 셈이죠. 매주 화요일 정오마다 시스템이 다운되지 않도록 안간힘을 썼습니다. 정말 흥미진진한 시간이었고, 회사가 계속 성장하면서 점점 더 많은 일들을 해낼 수 있게 된 것은 언제나 가슴 뛰는 일입니다.

진행자: 그렇다면 2001년에는 어떤 일이 일어났나요? 시계를 조금 더 빨리 감아보겠습니다.

제프 딘: 시스템이 다운되는 것을 막기 위해 우리가 했던 일 중 하나는 전체 검색, 인덱싱, 쿼리 처리 시스템을 끊임없이 재작성하여 효율성을 높이고 더 나은 데이터 구조와 압축된 표현 방식을 사용하는 것이었습니다. 2001년에 이르러 우리는 인덱스 크기와 인덱스 처리 용량을 확장하는 방식이 인덱스를 점점 더 많은 파티션, 즉 '샤드(shard)'로 쪼개어 인덱스 덩치를 키우는 구조라는 점을 깨달았습니다. 그리고 더 많은 쿼리를 동시에 처리하기 위해 각 샤드의 복제본을 계속 늘려나갔죠. 결국 데이터센터마다 7개의 샤드와 각각 10개의 복제본이 있던 것이 어느덧 60개의 샤드와 각 20개의 복제본에 달하는 지점에 이르렀습니다. 그러다 계산을 해보니, 인덱스를 디스크에 두는 대신 20개 복제본과 60개 파티션을 돌리던 1,200대 기기의 메모리에 웹 전체 인덱스를 통째로 올릴 수 있다는 사실을 깨달았습니다. 정말 재미있는 순간이었죠. 단 3일 만에 전체 검색 시스템 속도를 약 4배나 끌어올렸습니다.

TPU의 탄생: 음성 인식에서 커스텀 ASIC까지

진행자: 그리고 2013년에는 일종의 개략적인 추정(back-of-the-envelope calculation)을 하셨죠.

제프 딘: 그렇습니다. 저는 딥러닝 학습 인프라와 딥러닝 모델 학습 작업을 시작했습니다. 그것이 올바른 추상화라고 생각했기 때문입니다. 사실 저는 1990년 학부생 시절 신경망을 처음 접했고, 신경망의 병렬 학습을 주제로 학부 졸업 논문을 썼습니다. 그냥 이게 올바른 방향이라고 느꼈거든요. 프로세서 1대 대신 비실비실한 프로세서 32대를 엮으면 놀라운 모델을 학습시킬 수 있을 거라고 생각했습니다. 물론 32대가 아니라 100만 배 이상의 컴퓨팅 파워가 필요하다는 사실이 나중에 밝혀졌지만요. 하지만 무어의 법칙 등에 따른 성능 향상 덕분에 2008년이나 2009년 무렵부터 그런 컴퓨팅 환경이 갖춰지기 시작했습니다. 그러다 2011년에 음성, 비전, 언어 모델을 위한 대규모 분산 학습 프로젝트를 본격적으로 시작했습니다. 당시 데이터센터에는 CPU가 정말 많았습니다. 대규모 비전 모델을 학습시키기 위해 약 1만 6,000개의 CPU 코어를 사용했고, 놀라운 성능 향상을 얻어냈습니다. 음성 모델에서도 마찬가지였고, 모델 품질이 엄청나게 향상되었습니다. 음성 인식 깊은 모델(deep acoustic speech model)을 구축하려고 시도한 두 달 만에 음성 인식 분야의 지난 20년 연구 역사에 버금가는 단어 오류율(word error rate) 개선을 이뤄냈습니다. 그래서 '어머나, 이거 정말 대단한 일이 되겠는데'라는 생각이 들었죠. 하지만 이걸 어떻게 서비스할 것인가가 문제였습니다.

당시 저는 이런 계산을 해보았습니다. '만약 1,000만 명의 사람들이 하루에 몇 분씩 스마트폰에 대고 말하기 시작한다면, 우리는 이걸 어떻게 서비스해야 할까?' 계산해 보니, 구글의 작고 은밀한 어느 한 부서의 더 나은 음성 인식 모델 하나를 배포하기 위해서만으로도 구글이 보유한 전체 컴퓨터 대수를 두 배로 늘려야 했습니다. 비현실적일 뿐더러 지나치게 과도한 일처럼 느껴졌습니다. 그래서 우리는 특화된 하드웨어가 해답이라는 결론을 내렸습니다. 그것이 바로 TPU 패밀리의 탄생 비화입니다. 저정밀 선형 대수 연산에만 특화되어 그 외의 기능은 전혀 하지 않는 전용 가속기를 만들고자 했던 것입니다. 그래야만 음성 모델이나 비전 모델 등을 훨씬 더 효율적으로 서비스할 수 있으니까요. 결과적으로 2015년에 칩이 완성되었을 때, 당시의 일반 CPU 및 GPU에 비해 전력당 성능이 30배에서 80배까지 뛰어난 것으로 나타났습니다. 그것이 첫 번째 버전이었습니다.

빌 지아: 맞습니다. TPU v1은 추론을 주요 타깃으로 삼았죠. 그리고 그 이후 세대들은 주로 학습과 추론을 모두 겨냥해 발전해 왔습니다. 최근 들어서는 학습과 추론의 성격이 다소 다르기 때문에 이 두 갈래를 다시 분리하기 시작했고요.

진행자: 2017년에 논문을 발표하셨고 채택되었습니다. 50년 역사상 가장 많이 인용된 논문이지요—

제프 딘: 네, ISCA 역사상 그렇습니다. TPU v1에 관한 논문은 공동 저자가 많아서 저자가 35명 정도 됩니다. 컴퓨터 아키텍처의 50년 역사에 비추어 볼 때 비교적 최근의 일인데도 그렇게 많이 인용되었다니 기쁜 일입니다.

TPU 아키텍처, 소프트웨어 스택, 광 스위칭의 진화

빌 지아: 구글이 최고 수준의 소프트웨어 기업으로 평가받아 왔으면서도 하드웨어 로드맵을 과감히 밀어붙였다는 점이 정말 놀랍습니다. 하드웨어를 다룬다는 것은 별개의 문제입니다. 훌륭한 TPU를 만들기 위해서는 수많은 보드 디자인, 칩셋 디자인, 그리고 TPU 자체의 설계가 필요하니까요. 뿐만 아니라 컴파일러와 프레임워크도 완벽하게 작동해야 합니다. 초기에는 TPU 컴파일러인 XLA와 텐서플로(TensorFlow)를 강하게 밀어붙이셨죠. TPU를 위한 이러한 소프트웨어 스택을 구축하던 초기 여정이 어땠는지 소개 부탁드립니다.

제프 딘: 머신러닝 개발자나 연구원으로서 우리가 원하는 것은 고수준의 아이디어를 표현하기만 하면, 이면에서 성능을 극대화하기 위해 어떤 복잡한 일을 해야 하는지 깊이 고민하지 않아도 대규모 시스템 위에서 마법처럼 실행되는 것입니다. 즉, 훌륭한 컴파일러, 뛰어난 인터커넥트, 그리고 '내가 지금 로컬 머신의 칩 4개와 대화하고 있는지, 아니면 대규모 분산 환경의 1만 개 칩과 대화하고 있는지'에 대한 추상화를 매끄럽게 처리해 주는 프레임워크가 필요하다는 뜻입니다. 개발자가 이 두 환경을 두고 서로 다른 방식을 고민하거나 일일이 신경 쓸 필요가 없어야 합니다.

진행자: 다양한 TPU 세대들의 발전 과정과 앞으로 나아갈 방향에 대해 말씀해 주시죠.

제프 딘: 네. TPU v1은 슬롯에 꽂는 단순한 PCIe 카드 형태였습니다. 당시 우리는 어떻게 쓸지도 모른 채 일단 그 카드를 잔뜩 구매했죠. 당시 재무책임자(CFO)를 코너에 몰고 이렇게 말했습니다. "이거 많이 사야 합니다. 쓸 데가 있을 거거든요. 용도는 아직 불확실하지만 제발 많이 사게 해주세요"라고요. 그래서 실제로 그렇게 했습니다. 그리고 TPU v2는 단일 칩이 아니라 2D 토러스(torus)로 상호 연결된 수많은 칩으로 구성된 슈퍼컴퓨터 급의 시스템으로, 학습을 염두에 두고 설계된 최초의 시스템이었습니다. 세대를 거치면서 TPU v3부터는 수냉식 냉각(liquid cooling)을 도입했습니다. 시스템 내 칩 표면까지 배관이 연결되어 있다는 것은 늘 가슴 뛰는 일이지만, 누수가 발생하면 큰일 나기 때문에 긴장을 놓을 수 없습니다.

그 다음은 TPU v4입니다. 팟(pod)의 규모가 커짐에 따라—TPU v2와 v3는 256개 칩과 1,024개 칩 사이에 고정 배선이 되어 있었습니다—시스템이 점점 더 거대해지면 개별 칩이나 보드, 시스템에서 고장이 발생하기 마련입니다. 일부 부품이 고장 나더라도 훨씬 더 큰 팟의 전체 토폴로지를 계속 활용할 수 있어야 하므로 결함 허용성(fault-tolerance)이 더욱 중요해집니다. 그래서 TPU v4에서는 머신 랙 사이에 광학 재구성 가능 네트워크(optical reconfigurable network)라는 개념을 도입했습니다.

진행자: 데이터센터 바닥 곳곳에 있는 장비들을 레고 블록처럼 조립할 수 있게 된 셈이네요?

제프 딘: 데이터센터의 여러 통로에 흩어져 있으면서도, 미세 조정이 가능한 초소형 거울이 달린 재미있는 스위치들을 통해 이 8개의 랙이 마치 바로 옆에 붙어 있는 것처럼 작동하게 만듭니다. 이것이 정말 유용했습니다. TPU v5, v6, v7은 모두 점점 더 정밀도가 낮은 연산 포맷을 도입했으며, 이는 성능 향상에 엄청난 도움이 되었습니다. 다만 일부 FLOPS는 16비트, 일부는 8비트, 일부는 4비트인 상황에서 단순 비교하기는 다소 까다롭지만요. 머신러닝 알고리즘에서 이를 활용할 수만 있다면 저정밀 포맷은 성능을 극대화하는 훌륭한 방법입니다.

패스웨이즈(Pathways): 비정규성과 대규모 분산 학습의 조율

진행자: 첫 번째 TPU가 2015년, 논문이 2017년에 나왔으니 이제 전설적인 업적이 되었습니다. 그리고 2018년에는 패스웨이즈(Pathways)가 등장했죠. 패스웨이즈에 대해, 그리고 왜 그것이 그토록 중요한지에 대해 이야기해 보죠.

제프 딘: 네. 우리는 훨씬 더 불규칙하고 희소한(sparse) 모델의 학습을 처리하기 위해 패스웨이즈를 개발하기 시작했습니다. 또한 대규모 분산 학습 시스템을 구동할 수 있는 단일 프로그래밍 모델과 단일 프로세스를 제공하는 기반 시스템 인프라로서의 의미도 컸습니다. 프로그래머 입장에서는 단일 파이썬(Python) 프로세스가 마치 8,000개의 장치와 연결되어 있는 것처럼 보이고, "좋아, 8,000개 장치 전체에 걸쳐 AllReduce를 수행하고 싶어"라고 명령하면 특별한 작업을 직접 구현하지 않아도 시스템이 알아서 처리해 주는 편이 훨씬 좋습니다.

XLA 컴파일러를 비롯한 저수준 소프트웨어가 그 일부를 담당하고, 그보다 약간 상위 레벨에서 패스웨이즈가 수많은 칩 간의 데이터 이동을 조율합니다. 동일한 TPU 팟 내의 칩끼리 통신해야 할 경우 팟 내부의 고속 링크인 ICI를 사용합니다. 하지만 여러 팟에 걸쳐 있거나 이 팟의 칩과 저 팟의 칩 간에 통신이 필요할 때는 패스웨이즈가 데이터센터 네트워크를 통해, 혹은 오클라호마·텍사스·아이오와 등에 있는 팟들을 엮어 학습 작업을 수행할 때는 광역 네트워크(WAN)를 통해서도 전송을 조율합니다. 덕분에 개발자는 "내게는 방대한 컴퓨팅 자원이 있고, 시스템이 알아서 최적으로 활용할 것이다"라는 편리한 추상화를 누릴 수 있습니다.

하드웨어·인프라와의 제미니(Gemini) 모델 공동 설계

빌 지아: 정말 놀랍습니다. 제프, 당신은 아주 초기부터 TPU 네트워크 설계, TPU 자체 설계, 컴파일러 및 프레임워크, 그리고 데이터 이동 전체와 네트워크 트래픽 재구성 등을 조율하는 패스웨이즈에 이르기까지 AI 인프라 스택 전반에 깊이 관여해 오셨습니다. 이제 당신은 현재의 제미니(Gemini) 모델과 미래의 제미니 모델 설계에도 깊이 관여하고 계시죠. 이로써 제미니 모델은 전체 인프라 스택과 함께 공동 설계(co-design)될 수 있게 되었습니다. 관점의 전환을 통해 우리가 이미 얻어낸 이점은 무엇이며, 모델의 최첨단 한계를 계속 밀어붙이기 위해 어떤 미래 구상을 갖고 계신지 궁금합니다.

제프 딘: TPU 전 세대들은 우리가 ML 컴퓨팅의 열성적인 헤비 유저라는 사실로부터 큰 혜택을 받았습니다. 우리 안에는 기존 워크로드와는 다른 방식으로 하드웨어를 압박할 새로운 연구 아이디어의 한계를 끊임없이 시험하려는 사람들이 많습니다. 알파벳(Alphabet)이라는 하나의 울타리 아래 모든 것이 갖춰져 있기 때문에, 미래 TPU 세대 설계자, 컴파일러 및 인프라 소프트웨어 설계자, 그리고 머신러닝 연구원들 간에 활발한 상호작용이 가능합니다. 연구원들이 "소규모에서는 이런 방식이 잘 작동하는데, 1~2년 뒤 대규모 미래 학습 실행에서도 이것이 매우 중요해질 것 같으니 하드웨어가 이를 지원해 주었으면 좋겠다"고 제안할 수 있는 것이죠.

컴퓨터 아키텍처 설계자가 고립된 상태에서, 지금 설계하는 칩이 향후 유효성을 가져야 할 2년에서 6년 뒤의 급변하는 AI 분야가 어디로 향할지 혼자 예측하는 것은 정말 어렵습니다. "이런 방식으로 작동할 것 같다"는 인사이트를 많이 얻을수록, 그리고 소통과 반복을 거듭할수록 좋습니다. 단순히 "우리가 이걸 해야 할 것 같다"고 주장하는 데 그치지 않고, 하드웨어 팀이 "그건 어렵지만 이렇게 하면 가능할 텐데, 그게 도움이 될까?"라고 묻고, 우리가 "네, 정확히 그런 방식에 가까운 작업을 가능하게 해줄 겁니다, 아니면 그보다 더 나을 수도 있죠"라고 답하는 식의 주고받음이 일어납니다. 이러한 피드백 루프야말로 효과적인 공동 설계를 이뤄내는 데 핵심적입니다.

대규모 신뢰성: 10만 개의 TPU 전반에 걸친 유풋(Goodput)과 결함 허용성

빌 지아: 어제 기조연설 무대에서 이런 이야기를 했습니다. 제미니 모델의 규모를 키워감에 따라—매달 신뢰성 문제를 논의하기 위해 같은 회의실에 모이던 기억이 납니다. 저는 인프라를 담당하고 제프는 구글 딥마인드(Google DeepMind)를 대표하죠. 우리는 "제미니 모델이 점점 더 커지고, 모델 학습에 수많은 TPU가 투입되며, 궁극적으로는 10만 개의 TPU를 사용해 모델을 학습시키게 된다"고 말했습니다. 이때 우리가 함께 주시하는 단 하나의 핵심 지표가 바로 '유풋(Goodput)'입니다.

처음에는 유풋이 좋지 않았습니다. 당시 우리가 나눈 말이 기억납니다. 배드풋(badput)이 유풋을 압도한다고 요. 초기에는 60% 수준이었습니다. 모델의 사전 학습을 위해 더 많은 TPU를 확장해 나갈수록 과정은 매우 복잡해집니다. 더 큰 규모가 필요하고, 더 많은 데이터가 필요하며, 더 많은 병렬성이 필요합니다. 유풋은 처음에는 50%, 60%, 70% 수준이었지만 그것만으로는 턱없이 부족했습니다. 하지만 요약하자면, 이제 우리는 대규모 학습 인프라를 활용해 훨씬 더 복잡한 모델을 학습시키며, 유풋을 95%, 심지어 98%까지 끌어올릴 수 있게 되었습니다.

제프 딘: 그렇습니다. 이는 더 나은 운영 관행, 배포 시 칩에 대한 철저한 품질보증(QA) 테스트, 그리고 시스템의 일부가 다운되더라도 장애를 원활하게 처리하며 전진할 수 있는 소프트웨어적 조치 등 수많은 요소들이 결합된 결과라고 생각합니다. 이 모든 것들이 모여 커다란 차이를 만들어 냅니다.

빌 지아: 맞습니다. 우리가 모델도 소유하고, 데이터도 소유하며, 전체 하드웨어와 네트워크, 모든 소프트웨어 스택과 운영 팀까지 직접 보유하고 있다는 것 자체가 또 다른 엄청난 강점입니다.

제프 딘: 만약 개별 TPU 트레이를 더 큰 시스템의 일부로 보지 않는다면, "뭐 일주일 뒤에 순회 점검할 때 수리하면 되지"라고 생각할 수 있습니다. 하지만 그 트레이가 실제로 가동 중인 팟의 일부이고 그 안에 고장 난 트레이가 포함되어 있다면, 수리해야 할 폭발 반경(blast radius)이 생각보다 훨씬 크기 때문에 즉시 달려가서 고쳐야 합니다.

진행자: 그렇다면 1만 개도 아닌 10만 개의 칩을 다룰 때, 신뢰성은 더 이상 소프트웨어 패치 문제라기보다는 시스템 설계의 문제에 가깝다고 봐야 할까요? 혹은 물리학(physics)에 더 가까울까요?

제프 딘: 신뢰성은 기본적으로 시스템 전체의 속성(property)이며, 견고하게 만들어야 할 요소들이 매우 많습니다. 신뢰할 수 없는 부품들로부터 신뢰할 수 있는 전체 시스템을 구축하는 것, 이것이 바로 구글 창립 초기부터 이어져 온 방식입니다. 우리는 검색 트래픽을 처리하기 위해 값싼 저가형 소비자용 PC를 대량으로 구매했고, 그 위에 견고한 소프트웨어 시스템을 구축하여 개별 기기의 고장을 극복하고 시스템이 제공해야 할 기능을 안정적으로 구현해 냈습니다. 분산 파일 시스템의 경우 데이터를 여러 기기에 복제해 두기 때문에, 특정 데이터 복제본이 다운되더라도 언제나 살아남는 복제본이 존재하도록 하는 식이죠.

대규모 AI 학습 시스템에서도 똑같은 방식을 적용할 수 있습니다. 20개의 팟으로 구성된 기본 설정에서 그중 하나가 다운되더라도, 20번째 팟을 수리하는 동안 나머지 19개의 팟으로 학습을 계속 진행할 수 있습니다.

운영 조율 및 사일런트 데이터 코럽션(Silent Data Corruption) 대응

진행자: 빌, 어제 기조연설에서 OCS와 주피터(Jupiter)에 대해 살짝 언급하셨는데요. 이 기술들이 신뢰성과 어떻게 맞물려 있는지 조금 더 설명해 주시겠습니까?

빌 지아: 네, 오랜 여정이었습니다. 가장 먼저 우리는 매 1만 개의 칩과 모든 부품에서 발생하는 인터럽트(interrupt)가 하루에 몇 번이나 일어나는지 살펴봅니다. 이를 최소화해야 합니다. 학습 클러스터를 확장해 나가는 과정에서 인터럽트가 너무 빈번하게 발생하면 좋지 않으니까요. 그래서 첫 번째로 한 일은 하드웨어 신뢰성을 개선하는 것이었습니다.

그뿐만 아니라, 어제도 언급했듯이 사전 학습이 시작되기도 전에 소프트웨어가 전체 플릿(fleet)과 모든 단일 구성 요소를 스캔합니다. "현재 너의 활력 징후(vital sign)는 어떠한가?"라고 묻는 것이죠. 만약 활력 징후에 문제가 있다면 학습이 시작되기 전에 미리 수리하거나 아예 제외해 버립니다. 이것이 첫 번째 단계입니다.

두 번째 단계는 본격적인 학습이 시작된 이후입니다. 학습이 시작될 때 하드웨어의 활력 징후가 매우 좋았더라도, 학습은 몇 주 동안 지속되기 때문에 여전히 문제가 발생할 수 있습니다. 어떤 특정 부품과 서버에 문제가 생겼는지 실시간으로 식별한 뒤, 이를 찾아내어 격리·교체하고 수리해야 합니다. 이것이 두 번째 단계입니다.

또한 제프가 언급했듯 방대한 운영 조율(operational coordination)이 필요합니다. 데이터센터가 전체 데이터센터 랙의 전원을 정비하고 있는데 그 랙이 마침 학습을 수행 중이라면 곤란하겠죠. 따라서 우리는 데이터센터 인프라 팀, 사이트 신뢰성 엔지니어(SRE), 그리고 모든 ML 연구원 및 엔지니어들과 긴밀히 조율합니다. 싱크를 완벽하게 맞춰야만 하는 엄청난 조율 작업입니다.

제프는 제미니 모델 설계와 소프트웨어 설계 측면도 크게 주도하고 있습니다. 때로는 문제가 발생하기도 하지만, 학습 과정 자체가 데이터 병렬성(data parallelism)과 모델 병렬성(model parallelism)을 함께 결합하고 있습니다. 만약 문제가 발생한 지점이 특정 데이터 복제본 내부라면, 나머지 복제본들이 계속해서 구동되는 식입니다. 가중치(weights)를 자동으로 평균 내기 때문에 특정 복제본 하나가 다운되었다고 해서 전체 작업이 방해받지 않습니다. 이처럼 다각적이고 종합적인 개선이 이루어지고 있습니다. 덧붙일 말씀 있으신가요?

제프 딘: 없습니다. 발생할 수 있는 모든 장애 시나리오를 사전에 예측하기란 정말 어렵습니다. 따라서 원인이 무엇이었는지 정확히 알지 못하더라도 장애를 감지할 수 있는 견고한 시스템을 구축하는 것이 중요합니다. 가끔은 칩 온도가 올라갈 때 "2 + 2 = 5" 같은 연산 오류를 내며 신뢰성 문제를 일으키는 칩들이 존재합니다.

빌 지아: 그것이 가장 악명 높은 '사일런트 데이터 코럽션(silent data corruption)' 오류입니다. 정말 끔찍한 일이죠.

제프 딘: 맞습니다. 칩 자체에서 발생할 수도 있고, 불안정한 네트워크 링크나 다른 곳에서 발생할 수도 있습니다. 우리는 구글 창립 초기의 원칙들을 지금도 많이 적용하고 있습니다. 당시에는 저가형 소비자용 PC를 구매했기 때문에 ECC(오류 정정 코드)는커녕 메모리에 패리티(parity)조차 없었습니다. 그런 컴퓨터들을 대량으로 사용하다 보면 메모리에서 무작위 비트 뒤집기(bit flip) 현상이 발생하기 마련입니다. 우리가 수행하는 많은 연산들은 이러한 비트 뒤집기에 강건(robust)해야 했습니다. 예를 들어 10억 개의 웹 페이지를 처리할 때 그중 하나를 누락하더라도 세상이 무너지지는 않는 식입니다. 하드웨어 계층 상단에서 소프트웨어 체크sum을 통해 비정상적인 상황을 무시하고 처리함으로써, 특정 기기나 네트워크 링크가 신뢰할 수 없는 환경에서도 시스템이 견고하게 작동하도록 만들었습니다.

오픈소스 전략: JAX, StableHLO, 그리고 TPU용 PyTorch

진행자: 이제 주제를 조금 바꿔 오픈소스에 대해 이야기해 보겠습니다. 구글은 오픈소스를 깊이 신뢰하는 기업이죠. 청중석에 학계 관계자분들이나 파트너사 분들도 많이 계신 것으로 압니다. 구글의 AI 인프라 전략이 '통제된 자원(gated resource)'으로 남지 않도록 하는 것과 어떻게 맞닿아 있는지 살펴보고 싶습니다. 오늘 우리가 나눈 이야기들을 세상과 공유하기 위해 JAX와 StableHLO, 그리고 오픈소스의 진화 과정을 어떻게 다루고 있는지, 이것이 어떻게 폐쇄적인 자원이 되지 않도록 보장하는지 말씀해 주시죠.

제프 딘: 저희에게는 더 넓은 생태계와 상호작용하는 것이 정말 중요합니다. 소스코드를 공개하여 사람들이 직접 코드를 보고, 수정하고, 개선에 기여할 수 있도록 하며, 우리만의 비밀로 감싸두는 대신 여러 조직에 걸친 협업 프로젝트로 만드는 것이 핵심입니다. 텐서플로를 오픈소스화하고, JAX를 오픈소스화하며, XLA 컴파일러를 위한 StableHLO 표현 방식을 오픈소스화한 이유도 바로 그 때문입니다. 앞으로도 더 많은 것들을 오픈소스화할 것입니다. 구글은 오랜 기간 동안 리눅스(Linux) 커널 등 오픈소스 프로젝트에 대규모 기여를 해왔습니다. 대개 우리는 집단적인 오픈소스 노력에 가장 큰 기여를 하는 조직 중 하나입니다. 우리는 그것을 믿고, 모두가 함께 협력할 때 생태계 전체가 혜택을 받는다고 확신하기 때문입니다.

진행자: 파이토치(PyTorch)와 메타(Meta)에서의 경험에 대해 이야기하기에 완벽한 타이밍이군요.

빌 지아: 네, 이 파이어사이드 챗 직전에도 제프와 이야기를 나누었습니다. 제프는 AI 인프라 오픈소스 전략을 오랜 기간 이끌어 왔습니다. 제프가 언급했듯 과거에 구글은 텐서플로와 JAX를 오픈소스화했고, 쿠버네티스(Kubernetes)와 안드로이드(Android) 역시 구글이 창조하고 오픈소스화한 뛰어난 사례들입니다. 이제 우리는 TPU를 커뮤니티에 적극적으로 개방하고 구글 클라우드(Google Cloud) 상의 TPU를 강조하면서 이 오픈소스 전략에 더욱 박차를 가하고 있습니다.

실제로 우리는 JAX 코어를 오픈소스화했을 뿐만 아니라, 그 위에 구축된 수많은 상위 라이브러리들도 함께 선보이고 있습니다. 예를 들어 강화학습(RL)을 위한 'TuneX'라는 라이브러리는 JAX 코어 기반으로 구축되어 있으며 이 역시 오픈소스화했습니다. 체크포인팅(checkpointing) 처리, 추론 처리 등 JAX 상위에 수많은 상위 라이브러리 프레임워크를 구축하여 오픈소스화하고 있으며, 사람들이 이를 활용해 TPU를 직접 사용할 수 있도록 지원하고 있습니다. 이것이 첫 번째 축입니다.

물론 고객이 있는 곳으로 찾아가야 하겠죠. 오픈소스 커뮤니티에 이미 존재하는 성숙한 제품들도 기꺼이 수용할 것입니다. 파이토치는 매우 성숙하고 커뮤니티에서 널리 쓰이는 도구입니다. 그래서 우리는 TPU 위에서 파이토치를 적극 수용하기로 했습니다. 현재 'Torch-TPU'라는 프로젝트를 진행 중이며, 현재 프라이빗 프리뷰(private preview) 단계입니다. 앞으로 몇 달 뒤인 다음 분기에 퍼블릭 프리뷰(public preview)를 진행하고, Q4에는 GitHub을 통해 정식 공개하여 누구나 사용할 수 있도록 할 계획입니다. 어제도 말씀드렸듯이 Torch-TPU를 사용하면 몇 줄의 간단한 코드 수정만으로 백엔드 장치를 TPU로 지정할 수 있으며, 이를 통해 모든 학습과 추론이 TPU 위에서 실행되기를 바랍니다. 컴파일 모드(compiled mode)와 즉시 실행 모드(eager mode)를 모두 지원하고 있습니다. 이것이 프레임워크 수준의 노력입니다.

또한 청중석에 계신 분들 중 vLLM이나 SGLang 사용자가 많을 것으로 생각합니다. 이와 같은 상위 레벨의 오픈소스 추론 프레임워크 역시 TPU 상에서 원활히 구동될 수 있도록 해당 프로젝트들과 긴밀히 소통하고 있습니다. 우리 자체의 기술을 오픈소스화하는 것과 커뮤니티의 성숙한 오픈소스 제품을 적극 수용하는 것, 이 두 가지를 동시에 강력하게 추진하고 있습니다.

머신러닝을 통한 하드웨어 설계 자동화

진행자: 청중석에 1·2년 차 박사과정 학생들도 많이 와 계시네요. 박사과정 학생이신 분 손 한번 들어보시겠어요? 그들이 어떤 부분에 집중해야 할까요? 학부생들도 섞여 있다고 합니다.

제프 딘: 아, 커리어의 그 시기에 있다는 것 자체가 정말 흥미진진한 일입니다. 자신이 진정으로 즐거워하고 중요하다고 생각하는 일을 찾아내어, 세상에 임팩트를 남기는 방향으로 특정 분야를 발전시킬 수 있는 시기니까요. 정말 재미있고 멋진 때입니다.

진행자: 인프라 관점에서 특별히 염두에 두고 계신 물리적 병목 현상이 하나 있다면 무엇인가요?

제프 딘: 너무나 많습니다. 저는 점차 더 특화된 하드웨어(specialized hardware)가 대세가 될 것이라고 확신합니다. 그것이 훨씬 더 효율적인 시스템을 만드는 유일한 길이기 때문입니다. 오늘날 소수의 핵심 워크로드들이 전 세계 컴퓨팅의 엄청난 부분을 차지하게 될 세상이 되었습니다. 이를 생각해보면 하드웨어 특화(specialization)는 자연스럽게 요구되는 필수 과제입니다. 다만 특화된 하드웨어의 문제는, 앞으로 우리가 하고자 하는 작업이 미래에 바뀔 경우, 사랑을 담아 2년 동안 하드웨어로 구현해 낸 장비가 정작 그때는 더 이상 유효하지 않을 수 있다는 점입니다.

따라서 특화 프로세스가 제대로 작동하게 하려면 하드웨어 설계 과정의 훨씬 더 많은 부분을 자동화해야 합니다. 현재의 하드웨어 설계 방식은 방대한 인력 팀이 필요합니다. 어떤 이들은 고수준 사양을 받아 저수준 RTL(Register-Transfer Level) 코드로 작성합니다. 그리고 사람이 수작업으로 번역했기 때문에 첫 번째 팀이 제대로 일했는지 검증하는 또 다른 팀이 필요합니다. 그 뒤에는 칩의 물리적 배치(layout)를 정성껏 수행하는 또 다른 팀이 붙습니다. 이는 너무 비효율적입니다. 강화학습이나 진화 연산 등을 통해 탐색 가능한 자동화된 루프를 대폭 늘릴 수 있다면, 그리고 현재의 EDA 도구들이 대개 빠르게 실행되도록 설계되어 있지 않은 한계를 극복해 루프를 충분히 빠르게 돌릴 수만 있다면, 설계 과정에서 훨씬 더 자동화된 탐색 루프를 구축하고 설계 주기를 엄청나게 압축할 수 있는 기회가 열리게 됩니다.

예컨대 150명이 2년 걸려 만들던 신규 칩을 10명이 3개월 만에 설계할 수 있게 된다면, 세상에는 훨씬 더 특화된 하드웨어가 넘쳐나게 될 것입니다. 미래에 대한 베팅의 부담도 훨씬 줄어들 것입니다. "2년~6년 뒤에 어떤 컴퓨팅을 해야 할까"라는 막연한 고민이 "3개월~4년 뒤"의 문제로 바뀌며, 훨씬 더 감당하기 쉬운 베팅이 되는 것입니다.

추론 워크로드, 에이전트 시스템, 그리고 툴(Tool)의 병목

빌 지아: 1~2년 전만 해도 업계 전체와 구글, 그리고 많은 프런티어 랩들의 주된 관심사는 모델을 어떻게 하면 최고로 만들 것인가에 있었습니다. 사전 학습과 사후 학습을 성공시키는 데 집중했기 때문에 하드웨어 전략의 상당 부분이 학습(training) 쪽에 치우쳐 있었습니다. 그러나 대형 모델들이 성숙해짐에 따라 이제 수많은 트래픽이 에이전트(agent) 세계와 추론(inference) 영역으로 이동하고 있습니다. 제프, 하드웨어 설계 관점에서 추론 트래픽에 집중하고 강조하기 위해 하드웨어를 어떻게 설계해야 하는지 의견을 나눠주신다면요?

제프 딘: 추론과 학습은 다소 다릅니다. 추론의 경우 기본적으로 모델이 이미 존재하고, 그 모델에 대한 수많은 요청(request)을 빠르게 서비스하는 것이 목적입니다. 따라서 변하지 않는 정보의 이동을 최소화해야 합니다. 변하지 않는 것은 모델 가중치(weights)이고, 매번 바뀌는 것은 요청과 KV 캐시(KV cache) 등입니다. 그러므로 데이터 이동을 최소화하는 데 극도로 효율적인 시스템을 설계해야 합니다.

또한 단순한 프롬프트와 응답의 단계를 넘어, 에이전트가 여러 작업을 수행하고, 툴(tool)을 호출할지 결정하고, 툴이 실행되고, 그 결과가 돌아오면 이를 모델의 컨텍스트에 결합하여 다음 행동을 결정하는 복잡한 독립적 흐름으로 진화함에 따라 우리는 한 가지 사실을 깨닫게 될 것입니다. 바로 우리의 모든 툴들이 인간의 속도에 맞춰 설계되었기 때문에 지나치게 느리다는 점입니다. 툴의 일환으로 코드를 컴파일하고 있다면 컴파일러가 느리다는 사실에 큰 좌절을 겪게 될 것입니다. 만약 추론 하드웨어를 초고속으로 만든다면, 코드를 컴파일하는 속도보다 더 빠르게 코드를 생성할 수 있을 것이며, 실행하는 것보다 훨씬 빠른 것은 두말할 나위도 없습니다.

그래서 우리가 해온 작업 중 하나는 내부 툴들의 속도를 높여 더 유용하게 만드는 것입니다. 프로그래밍 언어 간의 변환 작업은 꽤 효과적으로 수행될 수 있다는 점이 밝혀졌습니다. 우리가 원하는 바에 대한 완벽하고 구체적인 사양이 이미 존재하기 때문입니다. 파이썬 같은 인터프리터 언어로 작성된 전체 프로그램이 있을 때, 우리는 Go, Rust, C++ 등 원하는 언어로 된 정확히 동일한 프로그램을 얻고자 합니다. 에이전트는 실제로 이 작업을 아주 훌륭하게 해낼 수 있습니다. 이는 우리가 에이전트와 나누는 일반적인 코딩 상호작용—예컨대 "웹서버를 만들어줘"라고 요청하면 에이전트가 사용자가 원치 않았을 온갖 가정과 세부사항을 스스로 채워 넣어야 하는 상황—과는 꽤 다릅니다. 완벽하게 사양이 지정된 툴이 주어지면 에이전트는 유닛 테스트를 전부 실행하고, 모든 유닛 테스트를 새로운 시스템에 맞춰 번역하며, 양쪽 시스템에서 동일하게 동작하는지 나란히(side-by-side) 검증하는 등 놀라운 일을 해낼 수 있습니다.

빌 지아: 구글 내부에도 '프로젝트 턴(Project Tern)'이라는 실전 사례가 있습니다. 많은 모델들이 텐서플로로 구축되어 있었지만 우리가 JAX로 마이그레이션하는 과정에서, 모든 텐서플로 모델을 JAX로 변환하고 모든 유닛 테스트와 코드 테스트를 자동으로 수행하는 작업을 진행하고 있습니다.

진행자: 그런데 제출하셨던 논문 중 NeurIPS에서 거절당했던 일화가 있죠. '임팩트가 작다'는 평가를 받았던 증류(distillation) 논문 말입니다.

제프 딘: 아, 맞습니다. 동기 부여를 주는 이야기죠. 격려가 되었으면 합니다. 증류 기술이 얼마나 중요한지를 보여주는 사례입니다. 동료인 제프 힌튼(Geoff Hinton), 오리올 비냘스(Oriol Vinyals)와 함께 거대 앙상블 모델을 증류 기법을 통해 학생 모델(student model)로 압축하는 방법에 대해 썼던 논문입니다.

빌 지아: 몇년도였죠?

제프 딘: 2015년 혹은 2016년이었습니다. 애초에 우리는 비전(vision)을 위한 거대한 전문화된 모델 앙상블을 학습시키는 맥락에서 이 아이디어를 생각했습니다. 논문에 담았던 실험 중 하나는 2만 개의 비전 클래스가 있을 때 동물용 모델, 자동차용 모델 등을 따로 학습시킨 뒤 이를 통합된 단일 모델로 증류해 내는 것이었습니다. 당시에는 거절당했지만 괜찮습니다. 아라비아(arXiv)에 올려두었고 사람들은 어쨌든 읽었으니까요.

진행자: 낙담하지 마십시오.

제프 딘: 바로 그렇습니다.

Q&A: 범용 하드웨어 대 특화 슈퍼컴퓨터

진행자: 자, 이제 시간이 몇 분 남지 않았습니다. 몇 가지 질문을 받겠습니다. 마이크를 들고 계신 분들이 있네요. 저기 앞쪽에 한 분 계십니다. 자리에서 일어나 간단한 자기소개와 배경을 말씀해 주시면 감사하겠습니다.

청중 (잉): 제 이름은 잉입니다. 10년 동안 구글 브레인(Google Brain)에서 일했습니다. 다시 뵙게 되어 반갑습니다. 빌과 제프에게 질문드리고 싶습니다. 구글의 초기 성장을 이끌었던 2000년대 초반에는 범용 소프트웨어와 범용 컴퓨팅에 대해 이야기했습니다. 하지만 오늘날 AI 슈퍼컴퓨터는 초기 슈퍼컴퓨팅 프레임워크와 유사하게 점점 더 특화되고 있습니다. 하드웨어와 머신러닝 시스템의 이 두 가지 다른 설계 패턴을 어떻게 바라보십니까? 미래에는 다시 범용 하드웨어로 회귀해야 할까요, 아니면 계속해서 슈퍼컴퓨팅 머신을 구축해 나가야 할까요? 감사합니다.

제프 딘: 우리가 검색을 위해 범용 하드웨어를 통해 확장할 수 있었던 이유는 검색이 매우 훌륭한 문제였기 때문입니다. 검색을 쪼개어 보면 기기 간 통신이 거의 필요 없고 단일 기기에서 처리해야 할 작업량이 대부분입니다. 따라서 인터커넥트 측면에서 이국적인(exotic) 장비가 전혀 필요 없었습니다. 당시 기기에는 100메가비트 이더넷이 장착되어 있었고, 40대의 기기가 랙당 1기가비트 업링크를 공유했기 때문에 약 4대 1의 오버서브스크립션(oversubscription) 환경이었습니다. 하지만 각 기기에 "팔로알토 식당" 같은 텍스트를 보내고 10개의 검색 결과 스니펫을 돌려받는 구조였기 때문에 그것으로 충분했습니다. 반면 학습(training)은 방대한 연결성이 요구되는 한계를 지속적으로 밀어붙입니다.

이상적으로는 단일 칩 하나로 학습을 끝낼 수 있다면 가장 좋겠지만, 그것은 너무 오래 걸리거나 칩에 다 담기지 않습니다. 결국 문제를 수많은 칩에 나누어 파티셔닝해야 합니다. 모델 병렬성이든 데이터 병렬성이든 방식을 어떻게 자르든 간에 결과적으로 꽤 많은 통신이 발생하게 됩니다. 이것이 바로 기기 간에 보다 이국적이고 고성능의 인터커넥트가 필요한 이유입니다. 가능한 한 많은 칩에 분산시키지 않아도 되도록 칩당 최대 성능을 극대화해야 하지만, 여전히 방대한 규모로 분산시켜야만 합니다. 그래서 우리가 수냉식을 사용해 그러한 환경에서 각 칩의 성능을 극대화하려는 것입니다.

추론의 경우, 특화된 하드웨어를 사용할 수 있겠지만 소형 모델의 경우 그리 이국적일 필요는 없습니다. 하지만 모델 규모가 커지기 시작하면, 이더넷 범용 하드웨어 및 범용 네트워크에 비해 꽤 이국적인 통신 요구사항이 대두되기 시작합니다. 물론 학습에 비해서는 훨씬 더 주류의 범용(mainstream and commodity)에 가깝습니다. 답변이 되었기를 바랍니다.

Q&A: 오픈소스 기여, CUDA 패러티, 그리고 개발자를 위한 AI 에이전트

진행자: 바로 여기에 또 다른 질문이 있네요.

청중 (안드라): 제프, 안녕하세요. 우버(Uber)에서 온 안드라입니다. JAX와 OpenXLA 생태계, 특히 오픈소스 커뮤니티가 구축해 온 이 생태계에 대해 질문이 있습니다. 지금은 안드로이드와 iOS에 비견될 만한 AI 인프라의 시대처럼 느껴집니다. 젊은 엔지니어들이 OpenXLA의 라이브러리 기능들에 어떻게 기여할 수 있다고 보십니까? 대다수의 사용자들은 강력한 CUDA 사용자이거나 CUDA 라이브러리를 기반으로 라이브러리나 기능을 구축해 온 사람들입니다. OpenXLA 관점에서 젊은 엔지니어들이 기여할 수 있는 방안은 무엇인가요?

빌 지아: 우선 OpenXLA와 JAX, 그리고 JAX 상위의 스택들은 전면적으로 오픈소스화되었습니다. 그것이 하나의 작업 영역입니다. 또 다른 작업 영역은 Torch-TPU입니다. 현재 우리는 내부적으로 메타와 협력하여 이를 개발 중이지만, 궁극적으로는 GitHub에 올려 커뮤니티의 모든 연구원과 엔지니어들이 기여할 수 있도록 할 것입니다. 이 두 가지 노력을 병행하고 있습니다. 오픈소스 리포지토리에 기여하고자 하는 커뮤니티의 젊은 엔지니어라면 누구든지 구글과 환영하며 함께 협력할 수 있습니다. 이 오픈소스 리포지토리를 어떻게 함께 발전시킬 수 있을지 논의할 수 있습니다.

게다가 궁극적으로 많은 사용자들이 TPU나 GPU를 위해 JAX 스택이나 PyTorch 스택을 사용하게 될 것입니다. 현재 커뮤니티 사용자들은 사용 중 문제가 발생하면 숙련된 엔지니어가 있다는 이유로 구글이나 엔비디아(Nvidia)에 연락하거나, 누군가 질문을 이해하고 유사한 경험으로 답변해 주기를 바라며 커뮤니티 토론 게시판에 글을 올립니다. 하지만 제 생각에 그 방식은 너무 느립니다. 오픈소스 전략에서 커뮤니티가 기여할 수 있는 진정한 도약은 이것입니다. GPU든 TPU든 상관없이 구동되는 JAX 에이전트와 PyTorch 에이전트가 있다고 상상해 보십시오. 커뮤니티의 모든 이들이 그 에이전트를 강력하게 훈련시키는 데이터 소스에 기여한다면, 내게는 'TPU 동료 에이전트'가 생기는 것입니다. 학습, 사후 학습, 추론을 실행할 때 굳이 구글에 연락하거나 토론 게시판을 뒤질 필요 없이 이 에이전트를 직접 사용하여 도움을 받을 수 있습니다. 에이전트가 질문의 상당 부분을 해결해 줄 수 있다면 엄청난 일일 것입니다. 하지만 이를 위해서는 우리 모두의 데이터 포인트와 경험이 필요하므로 커뮤니티 전체의 기여가 필수적입니다.

제프 딘: 오픈소스 기여와 관련하여 메타적인 관점에서 한마디 덧붙이자면, 기여하는 방법은 다양합니다. 다양한 리포지토리의 소유자들과 소통하며 "이런 작업을 해보려고 하는데 유용할까요?", 혹은 "제가 작업할 만한 아이디어가 있습니까?"라고 먼저 확인하는 것이 좋습니다. 누군가에게 5,000줄의 코드를 턱 하니 던져주며 "자, 여기 있습니다"라고 하기 전에, 어떤 점이 유용한지에 대해 사전 동의나 가이드를 얻는 것이 훨씬 좋은 방법입니다. 기여하고 싶지만 당장 구체적인 아이디어가 없다면, 유용하게 쓰일 수 있는 개발 과제들의 방대한 목록이 이미 대기하고 있는 경우가 많습니다.

청중 (안드라): 답변 감사합니다. 제가 겪어본 바로는 많은 함수나 모듈 커널이 여전히 CUDA에 강하게 의존하고 있다는 점이 망설여지는 부분이었습니다. CUDA 함수에 대응하는 호환성을 갖추기 위해 JAX, OpenXLA, 혹은 Torch-TPU를 사용해 동등한 무언가를 구현하는 추세가 형성되고 있는지, 그리고 그것이 올바른 방향인지 궁금합니다.

빌 지아: 네, 궁극적으로 그렇습니다. 구글 내부적으로 TPU상의 내부 JAX 스택과 PyTorch 스택을 검토할 때, 모든 CUDA 함수를 살펴보고 우리 쪽 함수들과 비교합니다. 최소한 동등하거나 그 이상이 되도록 보장하고 있습니다. 따라서 그것은 반드시 달성해야 할 필수 과제입니다. 그 계층에서 저수준 TPU SDK 작업물들도 오픈소스화하고자 합니다.

제프 딘: 또한 사람들은 훨씬 더 높은 수준의 추상화 관점에서 사고하기를 원합니다. 최고 성능을 얻기 위해 TPU 커널 언어든 GPU 커널 언어든 상관없이 일일이 커널 코드를 작성하며 병렬화를 고민하기보다는, JAX나 PyTorch의 표현식 수준에서 생각하는 것이 원하던 바일 것입니다. 컴파일러와 하부 시스템이 그러한 성능을 알아서 제공해주고, 개발자는 '행렬 곱셈(matrix multiply)'과 같은 아름다운 추상화 위에서만 사고할 수 있기를 바랍니다.

Q&A: 네트워크 확장, 3차원 토러스, 그리고 동기식 학습

진행자: 마지막 질문을 받을 시간이 된 것 같습니다. 마지막으로 한 분만 질문해 주시죠.

청중 (존): 안녕하세요, 뉴욕대학교(NYU)의 존입니다. 수년간 네트워크 분야를 연구해 왔습니다. 빌 지아와 다른 연사분께서 발표하신 확장성에 깊은 인상을 받았습니다. 이 TPU들이 3차원 토러스(3D torus)로 연결되어 있다고 들었습니다. 울트라 이더넷 컨소시엄(Ultra Ethernet Consortium) 등이 연구하는 팻트리(fat-tree) 인터커넥트와 비교했을 때, TPU나 GPU를 수만 개 혹은 심지어 100만 개 규모로 확장할 때 이 3차원 토러스 구조가 그러한 초대규모 환경에서 올투올(all-to-all) 통신을 여전히 거뜬히 처리할 수 있습니까?

제프 딘: TPU v5e나 TPU v4의 가장 거대한 팟은 제 기억으로 9,600여 개의 칩으로 구성되어 있습니다. 그것이 바로 우리가 3D 토러스를 활용하는 규모입니다. 그 이상의 규모에서는 3D 토러스로 연결된 수많은 팟들 상위에 소프트웨어 추상화 계층으로서 패스웨이즈를 활용합니다. 이 패스웨이즈는 데이터센터 내의 패브릭이나, 혹은 오클라호마의 건물에 있는 팟 5개와 아이오와의 건물에 있는 팟 8개를 고속 WAN 링크로 묶은 멀티 메트로(multi-metro) 학습 설정 등 데이터센터 네트워크를 활용합니다. 이 방식이 지금까지 확장에 꽤 잘 작동해 왔습니다.

수행하려는 연산을 매핑할 때 데이터 병렬 차원과 모델 병렬 차원이 공존하도록 구성하는 것이 유용합니다. 대개 모델 병렬 측면은 단일 팟 혹은 팟의 슬라이스 내에서 처리하고, 데이터 병렬 복제본들은 그러한 팟이나 팟 슬라이스들에 걸쳐 배치하는 방식을 선호합니다. 이 방식이 우리에게는 매우 잘 맞아떨어졌습니다. 토러스 기반 네트워크의 장점은 데이터센터 바닥에 복잡한 배선을 깔 필요 없이 로컬로 연결하기가 매우 쉽다는 점입니다.

진행자: 거울이 달린 재미있는 광 스위치만 빼고요.

제프 딘: 빌, 덧붙일 말씀 있으신가요?

빌 지아: 네, 정확히 그렇습니다. 랙 내부와 큐브 내부에는 ICI가 있습니다. 그리고 OCS를 사용하여 이를 9,600개 규모로 확장합니다. 더 나아가서는 패스웨이즈 소프트웨어가 조율하는 데이터센터 패브릭을 활용합니다. 10만 개 이상의 칩으로 넘어갈 때는 클라우드 데이터센터 네트워크를 사용하여 모든 것을 서로 연결합니다. 이러한 확장성은 우리에게 아주 훌륭하게 작동하고 있습니다.

제프 딘: 그리고 그러한 규모에서도 우리는 완전 동기식 학습(fully synchronous training)을 수행할 수 있습니다. 이는 ML의 재현성(reproducibility)과 해석 가능성 측면에서 큰 장점입니다. 언젠가 비동기식 학습이 다시 부각될 수도 있겠지만, 지금까지는 동기식 학습을 꽤 먼 지점까지 성공적으로 밀어붙여 왔으며 앞으로 어떻게 될지 지켜보겠습니다.

진행자: 아름다운 마무리네요. 시간이 다 되었습니다. 제프, 그리고 빌, 소중한 시간 내주셔서 진심으로 감사합니다. 파티오 쪽 외부에는 유명한 제프 딘 밈(meme)이 새겨진 볼펜과 데브랩스 티셔츠가 포함된 멋진 굿즈들이 준비되어 있습니다. 여러분 모두 감사합니다!