[원문 유형] Tele-news 주요채널 텔레그램 원문 묶음
[범위] Tele-news 주요채널
[묶음 주기] 10분
[통합 구간] 2026-10-09T03:20:00+00:00 ~ 2026-10-09T03:30:00+00:00
[작성 기준] 아래 글은 서로 다른 채널·작성자의 독립 원문을 수송 편의상 하나의 시간 구간으로 묶은 것이다. 서로 다른 출처의 사실·판단·전망을 하나의 합의나 결론으로 합치지 말고 채널별 귀속을 보존한다. 같은 사건을 다루더라도 공통 이슈 키만 재사용하고, 출처별 사실·해석·반응·전망은 각각 남긴다. 외부 링크와 첨부는 실제 원문으로 사용하고, 텔레그램 문구는 발견 경로·보조 설명으로 구분한다. 시간흐름순 정리는 원문 게시 순서와 각 출처의 판단 강도·조건을 보존한다.


===== 통합 원문 2 / 9 =====
[채널] 돌비콩의 투자정복
[게시일시] 2026.10.09 12:20:31
[텔레그램 게시물] https://t.me/dolbikong/4984
[원문 수집 기준] 외부 링크가 있으면 링크를 따라 확보한 실제 본문·첨부 파일이 주 분석 원문이다. 텔레그램 게시물은 발견 경로와 보조 설명으로 보존하며 외부 원문과 구분해 반영한다.

[현재 텔레그램 게시물 본문]
🔋구글 AI 인프라 총괄이 말하는 진짜 병목 source

1. 데이터센터는 이제 PU/TPU에 맞춰 전력, 냉각, 네트워크까지 함께 설계하는 거대한 전용 컴퓨터에 가까워지고 있음

2. 구글은 FLOPS보다 실제 워크로드가 얼마나 제대로 돌아가는지를 뜻하는 Goodput을 훨씬 중요하게 봄

3. 가속기 10만 개 규모에서는 하루에도 여러 번 장애가 발생하기 때문에 성능보다 안정성과 복구 능력이 중요함

3. 구글의 목표는 토큰 생성 능력을 6개월마다 2배 늘리는 것. 그 개선의 상당 부분은 모델과 소프트웨어에서 나옴

4. 이게 하드웨어 수요 감소를 뜻하진 않음. 추론 수요는 빠르게 증가해 기존 장비로는 부족, 데이터센터를 계속 건설 중

5. 특히 장시간 작동하는 에이전트가 늘어나면 CPU, DRAM, 스토리지, 네트워크가 훨씬 많이 필요해짐

6. 네트워크에서는 광통신의 중요성이 커지고 있으며 구글은 Optical Circuit Switching을 활용해 장애가 발생한 TPU 랙을 우회함

7. 구글이 장기적으로 가장 근본적인 병목이라고 지목한 것은 전력임

8. 데이터센터 전력은 수년 전부터 전력회사와 계획해야 하며, 송전망/발전/ESS까지가 데이터센터 투자의 일부임

9. 심지어 구글이 우주 데이터센터까지 실제로 검토하는 가장 큰 이유 역시 지구에서의 전력 공급 제약 때문임

✍️인프라 경쟁 단위는 GPU → 서버 → 랙 → 데이터센터 → 전력망으로 확장됨. HBM만 보면 된다는 thesis는 깨지고 있음. 가장 구조적이고 대체하기 어려운 병목은 전력
[source] https://www.youtube.com/watch?v=bGph8GwB3Sk
[Google's AI Infrastructure Chief, Amin Vahdat, on the Physics & Economics of Frontier AI] https://youtube.com/watch?v=bGph8GwB3Sk

[외부 원문 1]
[URL] https://www.youtube.com/watch?v=bGph8GwB3Sk
[제목] Google's AI Infrastructure Chief, Amin Vahdat, on the Physics & Economics of Frontier AI

[유튜브 영상 전사 원문]
[영상 ID] bGph8GwB3Sk
[채널] Sequoia Capital
[실제 게시일] 2026.10.06
[영상] https://www.youtube.com/watch?v=bGph8GwB3Sk
[전사 제공자] youtube_transcript_api

[261006] Google's AI Infrastructure Chief, Amin Vahdat, on the Physics & Economics of Frontier AI Sequoia Capital

하드웨어 분야 에는 특정한 작업 부하에 더 전문화 될수록 유연성은 떨어지지만 하드웨어의 속도는 더 빨라지고 전력 효율성은 높아지는 기회가 있습니다. 그래서 이것은 일종의 예술 이자 무엇을 설계 할 것인지, 그리고 그 작업 부하가 얼마나 지속될 것인지에 대한 예측 입니다. 다시 말해, 한두 달 이나 석 달 뒤에 사라질 작업 이라면 그 기간 동안 규모가 크 더라도 이를 포착 할 수 있는 기회는 매우 짧 습니다. 따라서 어느 정도 지속 가능 해야 합니다. 또한, 그 작업에 전문화 함으로써 정확히 어떤 이득을 얻을 수 있을지 예측할 수 있어야 하죠. >> 아민 베다 트 (Amin Vedat) 님을 쇼에 모시게 되어 매우 기쁩니다. 아민, 오늘 함께 해 주셔서 감사 합니다. >> 이곳에 오게 되어 정말 기쁩니다. 정말 기대 됩니다. >> 저는 오늘 주제가 매우 기대 되는데, 우리는 인류 역사상 가장 큰 자본 지출 (Capex) 구축 의 한가운데에 있기 때문 입니다. 당신은 그 중심에 있고요. 구글 한 곳 에서만 올해 2 천억 달러 이상을 자본 지출로 사용할 것으로 예상 되며, 대부분은 데이터 센터 구축에 투입 됩니다. 당신은 그 모든 것의 중심에 있습니다. 당신은 작년 말 구글의 AI 인프라 책임자로 임명 되었습니다. 그러니 당신은 인류 역사상 가장 자본 집약적 인 구축 노력 중 하나를 이끄는 인물 인 셈 이죠. 그래서 오늘 당신과이 주제로 깊이 이야기 할 수 있어 정말 기쁩니다. >> 물론 구글을 포함한 업계 전반에 걸쳐 정말 엄청난 해 입니다. 솔직히 말해 이런 상황을 본 적이 없는 것 같습니다. 구글은 물론 이고, 당신이 말했듯이 인류 역사상 구축 규모와 변화의 속도 측면에서 정말 믿을 수 없을 정도 입니다. >> 본격적으로 들어가기 전에, 청중을 위해 AI 데이터 센터 란 무엇 이며 비 AI 데이터 센터와 어떻게 다른지 간단히 설명해 주 시겠습니까? >> 아주 좋은 질문 입니다. AI 데이터 센터와 비 AI 데이터 센터는 실제로 많은 유사점을 가지고 있으며 근본적으로 크게 다르지는 않습니다. 즉, 콘크리트로 이루어져 있다는 점은 같죠. 건물 내부 말입니다. 전기 시설, 기계 시설, 냉각 시스템으로 구성 됩니다. 줄 지어 분배 되는 전력 설비가 있죠. 그곳에는 엄청난 양의 네트워크 인프라 가 있습니다. 다른 말로 하면, 대규모 연산 장치 들을 서로 연결 하는 것 입니다. 상당한 양의 스토리지 인프라도 들어 갑니다. 제가 보기에 AI 인프라에서 가장 큰 차이점은 바로 전문화 라고 생각 합니다. 과거에 데이터 센터 를 구축 할 때는 20 년, 25 년, 30 년을 내다 보는 건물 투자 였고, 그 기간 동안 어떻게 발전해 나갈지를 고민 했습니다. 서버가 들어갈 수도 있었죠. 네트워킹 이나 스토리지가 필요할 수도 있고요. 가속기, GPU, TPU 등 무엇 이든 그 안에 들어갈 수 있었습니다. 하지만 25 년에서 30 년 이라는 계획 기간이 존재 했죠. 하드웨어의 수명 은 6 년 정도일 수 있습니다. 그래서 여러 세대를 미리 계획 해야만 하는 거죠. AI 데이터 센터는 종종 더 목적 에 맞게 구축 되곤 합니다. 다시 말해, 우리는 종종 하드웨어와 건물을 함께 설계 합니다. 예를 들어, 이 건물 에는 스토리지를 많이 넣지 않겠다고 결정할 수도 있죠. 왜 일까요? 스토리지 랙은 전력이 10, 20, 30, 40 킬로와트 정도 필요할 수 있기 때문 입니다. 반면, 오늘날 수백 킬로와트에 달하는 TPU 랙 이나 GPU 랙 옆에 그걸 둔다고 생각 해보세요. 메가 와트 수준에 이를 수도 있습니다. 사람들은 향후 몇 년 내에 그런 수준이 될 거라고 이야기 합니다. 한 줄에 스토리지 랙 30 개를 넣는 건물과 AI 랙 한두 개를 넣는 건물의 설계는 매우 다를 수밖에 없습니다. 크기만 생각해 보더라도 그렇습니다. 전력과 그 전력이 건물 전체 에 어떻게 분배 될지 등을 생각 해보세요. 네트워킹도 마찬가지 입니다. 스토리지 랙에 필요한 네트워킹 양은 아주 적죠. 특히 AI 랙과 비교 하면 하드 드라이브 위주의 스토리지 랙은 더욱 그렇습니다. 그래서 모든 것을 호환 가능 하게 만들 려고 하면, 아마 너무 크게 짓 거나 과도 하게 설계 하게 될 겁니다. 30 년 이라는 기간 동안 범용성을 유지 하는 것은 어렵죠. AI 데이터 센터 는 목적에 맞게 더 특화 되어야 하며, 냉각 이나 전력 분배에 이르기까지 하드웨어 와 공동 설계 되어야 합니다. 즉, 훨씬 더 많은 공동 최적화 가 필요 합니다. >> 당신들이 제 포트폴리오 기업 중 하나 인 'Ineffable Intelligence' 에 대규모 베어 메탈 클러스터를 납품 했을 때, 출고 되는 사진을 봤습니다. 정말 아름답 더군요. >> 그렇습니다. 맞습니다. >> 제 말은, 인류 역사상 가장 큰 건설 프로젝트를 보는 것처럼 데이터 센터를 바라 보면 "와, 인류가 해낼 수 있는 기념비적 인 업적 이다" 라는 생각이 든다는 겁니다. >> 네, 좋은 사진을 찍었 죠. 그런데 사실 이건 고작 몇 개의 랙일 뿐입니다. 케이블 링과 광섬유 분배는 정말 아름답 습니다. 아름다움은 보는 사람의 눈에 달렸다고 하지만, 저나 여러분, 그리고 청중 분들께는 정말 멋진 광경 이죠. 우리가 소셜 미디어에이 사진을 올렸을 때 사람들이 인에 퍼블 (Ineffable) 에 열광 했는데, 저도 그들이 하는 일의 엄청난 팬 이고 팀 도 정말 훌륭 합니다. 많은 주목을 받았습니다. 인에 퍼블을 위한 훌륭한 랙도 좋지만, 사실 사람들은 광섬유의 모습과 그 프랙탈 같은 구조를 보는 걸 정말 좋아 했어요. 실제로 저희가 올린 게시물 중 가장 인기 있었던 것 중 하나가 바로 그거 였죠. 네, 정말 그렇습니다. 저희도 그 점에 대해 매우 기대 하고 있습니다. >> 맞아요, 그 사진을 보고 소름 이 돋았 죠. >> 음. >> 이런 대규모 구축 과정에서 어떻게 측정 하고 스스로 책임을 지시 나요? 방송 직전 에 FLOPS가 허울 뿐인 지표 이며, 다른 대안 지표를 선호 한다고 말씀 하셨죠. 조금 더 자세히 설명해 주실 수 있나요? >> 네, 한 가지 주목할 점은 FLOPS 든 다른 어떤 칩 중심의 지표 든 모두 이론적 인 수치 라는 것 입니다. 다시 말해, 어떤 칩 이든 특정 조건 하에서 낼 수 있는 최대 FLOPS를 의미 하죠. 결국 우리가 정말 중요 하게 생각 하는 건 워크 로드 별로 실질적인 성능이 얼마나 나오 느냐 하는 겁니다. 그게 바로 우리가 주목 하는 부분 이죠. 단일 칩으로 성능이 결정 되는 경우는 거의 없습니다. FLOPS, HBM, SRAM 용량 등도 매우 중요 하지만, 결국 2 개, 4 개, 8 개, 16 개, 천 개, 만 개 이상의 칩이 어떻게 구성 되느냐가 관건 입니다. TPU 나 GPU 같은 가속기 뿐만 아니라 데이터를 공급 하는 CPU, 그리고 이들을 연결 하는 네트워크까지 모두 포함 해서 말이죠. 그래서, 어떤 워크 로드를 실행 하고 있고 그 워크 로드의 성능은 어떠한지 가 중요한 것 입니다. 흥미로운 지표 중 하나는 FLOPS 활용도 입니다. 예를 들어 특정 워크 로드에서 이론적 으로 테라 플롭스 나 페타 플롭스를 낼 수 있다면, 그중 실제로는 어느 정도의 비율을 달성 하고 있느냐는 거죠. 그게 바로 굿풋 (goodput) 의 척도 입니다. >> 굿풋 이란 무엇 인가요? >> 잘 알려진 용어 인 처리량 ( throughput) 을 생각 하시면 됩니다. >> 네. >> 그것이 가능한 처리량 이라면 , 이제 다른 고려 사항들도 생각해 보죠. 하나는 워크 로드 자체의 고유 한 특성 으로 인한 속도 저하 이고, 또 다른 중요한 측면은 신뢰성 입니다. 우리가 어떻게 책임 을 다할 것인가 하는 측면 에서 볼 때, 동기식 워크 로드 에서 칩 오류가 발생 한다면, 학습, 서빙, 에이전트 워크 로드 등 많은 작업이 동기식 으로 돌아 갑니다. 수많은 구성 요소가 동시에 함께 작동 하고 있죠. 이제 수천, 수만, 십만 개의 구성 요소가 동시에 작동 하며 마이크로 초나 밀리 초 단위로 긴밀 하게 조율 되어야 한다고 가정 해 봅시다. 그중 하나만 실패 해도 전체 시스템이 멈출 수 있습니다. 그렇지 않나요? 모두가 어려운 질문 에 대한 답을 내기 위해 서로 의 역할을 다할 것이라고 믿고 있기 때문 입니다. 하나 가 멈 추면, 무엇이 잘못 되었는지, 어떤 것이 멈췄 는지, 그리고 과거 어느 시점 의 연산 체크 포인트가 남아 있는지 파악 해야 합니다. 그 체크 포인트를 어떻게 복구 할까요? 어떻게 다시 시작 할까요? 최악의 경우, 처음 부터 다시 시작 해야 할 수도 있습니다. 정말 최악 이겠지만, 특히 추론 측면 에서는 그런 일이 실제로 발생할 수 있습니다. 여기서 핵심은 만약 다시 돌아가서 수많은 연산을 반복 해야 하거나, 오류 원인을 파악 하기 위해 작업을 멈추고 기다려야 한다면, 그 모든 과정이 작업 이라는 점 입니다. 결과를 얻는 데 전혀 도움이 되지 않죠. 그렇지 않나요? 종이 위에 문제를 푼다 고 가정 해 봅시다. 1 단계, 2 단계, 3 단계, 4 단계가 있습니다. 실수를 해서 1 단계 로 다시 돌아 가야 한다면, 네 , 여전히 작업을 하고 있는 것은 맞습니다. 그게 바로 처리량 입니다. 작업은 하고 있지만, 정작 답을 도출 하는 데 유효한 작업량 (Goodput) 은 얼마 일까요? 기본적으로 문제를 해결 하는 데 걸린 총 시간 입니다. 그게 바로 중요한 것 입니다. 만약 오류 가 발생 하고, 복구 해야 하며 , 작업이 중단 되는 어떤 상황 이든 발생 한다면, 그것이 바로 문제의 일부 입니다. 그렇다면 우리는 어떻게 책임 을 다할 수 있을까요? 이론적 인 벤치 마크 처리량 이나 수치가 아니라, 실제 워크 로드에서 발생 하는 오류를 포함한 결과물, 즉 실질적인 유효 작업량을 전달 하는 것 입니다. 불행한 현실은 10만 개의 가속기 규모 에서는, >> 제가 하려던 말은 그 정도 규모 라면 항상 무언가가 고장 나고 있다는 것 입니다. >> 항상 말이죠. 아시 다시피, 이 각각의 칩 들은 경이로운 기술의 결정체 입니다. 제 말 은, 제조 가능한 최첨단 기술 의 정점에 있다는 뜻 입니다. 그렇지 않나요? 그래서 다시 말하지만, 저 에게는 그것이 놀라 울 따름 입니다. 그리고 사실, 이 칩 들은 그냥 하나의 칩이 아닙니다. 이 패키지는 많은 경우 두 개, 네 개, 여덟 개, 어쩌면 그 이상의 칩렛들 로 구성 되어 함께 작동 하죠. 물론 옆 에는 HBM이 있고 네트워크 연결도 있으며, 공동 패키지 광학 같은 것들도 있을 수 있습니다. 비판 하려는 건 아니지만, 고장 날 수 있는 것들이 너무 많습니다. 그런데 이런 걸 10 만 개나 가지고 있다면, 무언가는 반드시 고장 나게 마련 이죠. 그에 대비 하고, 거의 실시간으로 감지 하며, 거의 실시간으로 복구 할 수 있어야 합니다. 그 모든 과정 을 수행 하는 것은 정말 엄청난 텔레 메 트리 문제를 해결 하는 것과 같습니다. 마치 초 단위, 분 단위는 물론 이고, 일부 작업의 경우 몇 시간, 며칠, 심지어 몇 주 동안 계속 해서 건초 더미 에서 바늘을 찾는 것과 같죠. 그저 지속적 이고 온라인 상태로 말입니다. 우리가 스스로에게 책임을 묻는 방식 은 데이터 센터에서 실제로 중요한 워크 로드에 대해 얼마나 많은 유효 처리량 (good put) 을 제공 하느냐 입니다. ' >> 유효 처리량' 은 구글 용어 인가요, 아니면 업계 용어 인가요? >> 구글 용어 이긴 하지만, 점점 더 많은 업계 사람들이 이를 사용 하기 시작 하고 있다고 생각 합니다. >> 감을 잡기 위해 묻자 면, 10만 개의 가속기 규모 라면 1 분에 한 번, 아니면 하루에 한 번꼴 로 고장이 나나요? 얼마나 자주 발생 하나요? >> 10만 개의 가속기 라, 어디 보자. 제 생각 에는 그 규모 라면 분명 하루 에도 여러 번, 아마도 정확한 구성에 따라서 는 한 시간에 여러 번 무언가 가 고장 날 겁니다. >> 그렇다면 가장 흔한 고장 원인은 무엇 인가요? >> 그게 바로 문제 입니다. 사실, 아주 좋은 질문 입니다. 만약 흔한 고장 원인이 있었다면, 우리는 이미 그걸 알아 내서 해결 했을 겁니다. 그것은 끊임없이 발견 되는 긴 꼬리 ( long tail) 와도 같습니다. 새로운 제품이 도입 될 때 마다 우리가 미처 생각지 못한 문제가 발생 하곤 하죠. 솔직히 많은 경우, 그야말로 최첨단 기술 이기 때문에 네트워크 관련 문제 일 수 있습니다. 이것들을 초고속 으로 연결 하는 방식과 관련 이 있을 수도 있죠. 하드웨어 와 관련된 문제 일 수도 있습니다. 그런 문제 들은 우리가 해결해 나갑니다. 하지만 소프트웨어 문제도 상당히 많을 수 있습니다. 그래서 이것이 우리가 스스로 에게 책임을 묻는 또 다른 측면 입니다. 다시 말해, 칩이 특정 수준의 플롭스 (flops) 성능을 낼 수는 있습니다. 하지만 컴파일러 버그, 런타임 버그, 모델 문제, 그 외 다른 운영체제 문제 등이 있으면 소용 없죠. 그것은 결국 전체 시스템 성능에 영향을 미치게 됩니다. 즉, 완벽 하고 매우 신뢰할 수 있는 하드웨어를 갖췄 더라도 , 소프트웨어 문제로 인해 피해를 볼 수 있다는 겁니다. >> 음. Nvidia 나 TPU 팀과 같은 가속기 기업 들이 제공 하는 표준 참조 스택이 있나요? 예 를 들어, 우리 가속기를 중심 으로 구축 할 수 있는 최적의 시스템은 이것 이고, 그 시스템에 맞춰 구축 하기만 하면 된다는 식의 가이드 말입니다. 아니면 반도체 기업 들이 제공 하는 것 외에 데이터 센터를 얼마나 독자적 으로 설계 해야 하는 건가요? >> 네, 맞습니다. 음, 참조 스택 은 존재 합니다. 제 생각에 Nvidia는 정말 대단한 종합 시스템 기업 입니다. 물론 반도체 기업 이긴 하지만, 단순한 반도체 기업 그 이상 이죠. 그들은 매우 강력한 참조 스택을 제공 합니다. 하지만 많은 경우, 저희가 확인한 바로는 대부분의 고객 이 그 참조 스택을 활용 하되, 다수는 자신들만의 방식으로 특화 하기도 합니다. 다시 말해, 고객 들은 각자의 특정 사용 사례에 맞는 최적화 기회 나 더 필요한 작업을 발견 할 수 있다는 의미 입니다. 그래서 그들은 그렇게 작업을 수행 하게 되죠. 마찬가지로 TPU 측에서도 저희는 참조 스택을 보유 하고 있습니다. 대부분 의 사용자가 이를 활용 하지만, 많은 이들이 이를 자신들에게 맞게 특화 하기도 합니다. >> 음. 알겠습니다. 전반적인 용량 측면에서 질문 드리면, Google이 서빙 용량을 6 개월 마다 거의 두 배로 늘려야 한다고 팀에 말씀 하셨는데, 사실 인가요? >> 음, 확실히 해두 자면, 이는 결국 서빙 관점에서 바라본 유효 가용 용량을 의미 합니다. 바로 토큰 생성 능력 입니다. 그래서 용량 이라고 하면, 저는 이것을 소프트웨어와 하드웨어의 결합 이라고 말씀 드리고 싶습니다. 하드웨어 에는 어떤 고유 한 수준의 플롭스 ( FLOPS) 가 있을 수 있습니다. 제가 여기서 말씀 드리는 것은 6 개월 마다 플롭스 수를 반드시 두 배로 늘려야 한다는 뜻은 아닙니다. 그것도 하나의 방법 이긴 하죠. 하지만 6 개월 마다 토큰을 생성 하는 하드웨어의 능력을 두 배로 키워야 한다는 것 입니다. 그리고 그 능력의 상당 부분은 하드웨어 만큼이나 소프트웨어에서 나올 것 입니다. 즉, 모델 최적화를 통해서 그런 결과를 낼 수도 있습니다. 또는 런타임 최적화를 통해서도 가능할 수 있죠. 아마도 수십, 수백 가지의 개별 최적화가 지속적으로 적용 되면서이 모든 것이 가능 해지는 것일 겁니다. 하지만 네, 용량 개선 속도는 정말 놀랍 습니다. >> 지난 몇 년간 데이터 센터를 구축해 왔고, 모델과 소프트웨어 분야 에서도 몇 년간 진전이 있었 으니까요. 와트 당 지능으로 측정 했을 때, 실리콘 자체에서 기인 한 용량 증가분과 모델, 또는 기타 소프트웨어 및 다른 주요 구성 요소에서 기인 한 용량 증가분의 경험적 분석 결과는 어떻게 되나요? >> 네, 정말 좋은 질문 입니다. 정확한 분석 수치는 없지만, 저희 경험상 와트 당 지능 측면에서의 이점은 대부분 모델 개선에서 비롯 된다고 말씀 드리고 싶습니다. 참고 로, 와트 당 지능은 정말 훌륭한 지표 입니다. 저희도 와트 당 굿풋 (good put) 을 중요 하게 여기 는데, 왜 와트가 분모가 되어야 하는지에 대해서는 나중에 다시 이야기 할 수 있을 것 같습니다. 굿풋 은 와트 당 제공 되는 지능을 측정 하는 척도가 될 수 있습니다. 다시 말해, 굿풋은 작업 부하 별로 특화된 지표 입니다. 하지만 저는 성과의 대부분은 모델 측면에서 온다고 말씀 드리고 싶습니다 . 소프트웨어 시스템도 상당히 기여 하죠. 왜 일까요? 소프트웨어는 보유한 하드웨어를 실제로 효과적으로 활용할 수 있게 해주기 때문 입니다. 그리고 하드웨어 자체도 매우 놀랍 습니다. 다시 말해, 우리는 지금 전년 대비 2 배 이상의 성능 향상이 충분히 가능한 세상에 살고 있습니다. 따라서 하드웨어가 이를 뒷받침 하며, 원한다면 일종의 무료 승수 효과를 얻을 수 있습니다. 공짜는 아니지만 요. 하지만 그 위의 모든 사람들은 그것이 매년 모두를 끌어 올리는 승수 역할을 할 것이라고 기대할 수 있습니다. >> TPU 프로그램과 공동 설계에 대해 좀 더 이야기 해보고 싶습니다. 구글은 10 년도 더 전에 자체 실리콘을 만들기 시작 했죠. 당시 로서는 반대 의견이 많은 결정 이었습니다 . TPU 프로그램은 어떻게 발전해 왔나요? >> 상당히 많이 발전 했습니다. 2013 년에 프로그램이 시작 되었을 때는 정말 주류에 반하는 결정 이었습니다. 2013 년 당시의 상황을 떠올려 보면, 그 시절 상식으로는 가장 똑똑 하고 현명한 사람들 조차 단일 작업 부하 를 위해 맞춤형 가속기를 만들지는 않을 것이라고 말했 을 겁니다. 왜냐하면 무어의 법칙이 존재 했고, 18 개월 이나 24 개월 마다 성능이 두 배로 향상 되고 있었 으니까요. 표준 프로그래밍 모델을 활용할 수 있고, C ++ 코드 나 Java, Python 등 무엇 이든 사용할 수 있으니까요. >> 칩의 씁쓸한 교훈 이군요. >> 네, 정확 합니다. 칩에 대한 씁쓸한 교훈은 전문화가 결코 성공 하지 못한다는 것이죠. 하지만이 경우 에는 특정 애플리케이션 하나 나 소수의 애플리케이션이 엄청난 혜택 을 볼 수 있었고, 이를 지원 하려면 상상할 수 없을 만큼 많은 범용 CPU가 필요 했기 때문 입니다. 2013 년 당시에는 일종의 도박 이었고, 회사 내부 에서도 성공 할지 확신 하지 못하는 사람들이 꽤 있었습니다. 도박 이었지만, 결과적으로는 엄청나게 성공적인 도박이 되었습니다. 첫 번째 칩은 오직 추론 만을 위한 것이 었 습니다. 두 번째 칩은 같은 아이디어를 활용 해 학습용 칩을 만들 수 있겠다는 생각에서 시작 되었습니다. 그 후 점점 더 많은 사용 사례에 채택 되기 시작 했습니다. 두 번째 칩이 나올 무렵, 트랜스포머가 발명 되었습니다. 이는 매우 중요한 순간 이었고, 실제로 TPU 프로그램을 완전히 바꿔 놓았 습니다. 물론 저희는 추천 시스템이 TPU에서 매우 잘 작동 한다는 것을 알게 되었고, 관련 사용 사례 들이 추가로 등장 했습니다. 변화 와 발전은 범위와 영향력이 확대 되는 과정 이었다고 말할 수 있습니다. 다시 말해, 추론 서비스를 위한 몇 가지 애플리케이션 이라는 영향력 있는 사용 사례에서 시작된 것 입니다. 처음 에는 주로 언어 번역과 음성 인식 이었고, 이후 학습, 트랜스포머, 추천 시스템으로 이어 졌으며, 생성 형 AI 시대 가 도래 하면서 더 크고 확장 성 있는 시스템으로 일반화 되었습니다. >> 트랜스포머가 등장한 순간이 중요 했다고 언급 하셨는데, TPU는 특정 아키텍처 였지만 트랜스포머 전용은 아니 었던 점이 궁금 합니다. 작업 부하 에 맞춰 칩을 어느 정도로 특화 해야 할지, 그 미묘한 균형을 어떻게 잡으시 나요? >> 정말 좋은 질문 입니다. 결국 핵심은 적용 가능성 이라고 생각 합니다. 제 말은, 특정 작업 부하에 대한 칩의 적용 범위를 의미 합니다. 즉, 저희 는 매 세대 마다이 문제를 고민해 왔습니다. 더 특화 해야 할까요? 약 2 년 혹은 그보다 조금 더 전 저희가 직면 했던 질문은, 2026 년에 칩을 하나로 할지 아니면 두 개로 할지 였습니다. 추론과 학습을 동시에 수행 하면서 둘 다 잘 해낼 수 있는 하나의 칩을 만들 수도 있고, 두 개의 칩을 만들 수도 있었습니다. 하나는 추론에 더 특화 하고, 다른 하나는 학습에 더 특화 하는 방식 이었죠. 이러한 분석과 연구를 통해 올해 두 개의 칩을 출시 하게 되었습니다. 추론을 위한 8I와 학습을 위한 8T 인데, 몇 년 전만 해도 그렇지 않았지만 2026 년이 되면 추론과 서비스 수요가 폭발 할 것이라고 판단 했기 때문 입니다. 따라서 수명 기간 동안 시장 의 30, 40, 50, 60%를 차지할 것으로 예상 되는 서비스 작업에 훨씬 더 빠른 칩을 갖추는 것이 매우 타당 하다고 판단 했습니다. 추론 시장 점유율을 2%나 5%로 예상 한다면, 설령 전용 칩이 2 배 더 빠르다 하더라도 경제성이 없을 수 있습니다. 그렇지 않나요? 완벽 하게 최적화 되지는 않았 더라도 범용 칩 을 선택 하는 편이 통일성 등 을 고려할 때 더 나 으니까요. 결국 '더 특화 할 것인가?' 라는 계산의 문제가 됩니다. 그 워크 로드가 얼마나 큰 가요? 앞으로 3 ~ 4 년 뒤에는 그 워크 로드가 얼마나 커질 것으로 예상 됩니까? 특정 워크 로드에 대한 지속적인 성장세 인가요? 아시 다시피 하드웨어 분야 에서는 특정 워크 로드에 특화 할수록 유연성은 떨어지지만, 속도는 빨라지고 전력 효율은 더 좋아지는 기회가 있습니다. 그래서 무엇을 설계 하고 그 워크 로드가 얼마나 지속될 지를 예측 하는 것이 일종의 예술 이자 기술 입니다. 다시 말해, 한두 달 이나 석 달 뒤에 사라질 워크 로드 라면 그 기간 동안 규모가 크 더라도 대응할 수 있는 시간적 여유가 매우 촉박 합니다. 따라서 어느 정도 지속 가능 해야 합니다. 또한, 그에 특화 했을 때 정확히 어떤 이득을 얻을 수 있을지 예측할 수 있어야 합니다. >> 대략 적인 트레이드 오프를 따져 보면, 새로운 프로그램 을 지원 하는 데는 큰 고정 비용이 발생 합니다. >> 맞습니다. >> 결국 해당 프로그램에 대한 수요가 비용을 정당화 할 만큼 충분할 것이라고 판단 해야 하죠. >> 정확 합니다. 어느 정도는 저희 8i와 8t 칩의 경우처럼, 두 칩 모두 서로의 워크 로드 를 처리 할 수 있습니다. 이 점도 핵심 입니다. 만약 8i가 추론만 가능 하고 학습은 전혀 할 수 없다면 어떨까요? 즉, 학습 성능이 전혀 없는 경우죠. 반대로 8t가 학습 에는 뛰어나지만 추론 성능이 제로 라면, 그것 또한 결정적인 한계가 되었을 겁니다. 왜 그럴까요? 하드웨어의 수명 인 6 년 동안 각각이 얼마나 필요 할지 미리 정확히 예측 해야 하기 때문 입니다. 이번 경우는 두 칩 모두 특화된 작업에서 더 뛰어나 면서도 상황이 좋았 습니다. 하지만 필요 하다면, 한쪽의 용량이 남을 경우 두 칩 모두 서로의 작업을 수행 할 수 있습니다. 특화 정도에 따라 너무 지나치게 특화 하면 유연성과 대체 가능성을 잃을 수도 있습니다. >> 대략 적인 트레이드 오프가 프로그램 크기와 관련이 있다고 본다면, 현대 AI 시장 의 상당 부분이 트랜스포머 기반 인 것처럼 보입니다. 그렇다면 도발적인 질문을 하나 던져 보죠. 왜 트랜스포머 아키텍처를 칩에 그냥 박아 버리지 않는 건가요? >> 네, 트랜스포머 기반 인 것은 맞지만, 그다음 단계의 질문 은 결국 트랜스포머가 벡터 및 행렬 곱셈 연산에 관한 것이라는 점 입니다. 그리고 아시 다시피 소프트 맥스처럼 기본적으로는 선형 대수 프리미티브의 범위에 속 하죠 . 저희를 비롯한 다른 기업들 도 이러한 연산 들을 하드웨어에 어느 정도 내장 하고 있습니다. 모두 트랜스포머 기반 이기는 하지만, 모델 아키텍처 라는 것은 결국 '레이어가 몇 개인가' 의 문제 입니다. 레이어를 어떤 방식으로 통과 하게 되나요? 레이어 간의 이동은 어떻게 이루어 지나요 ? 각 차원에 대해 정확히 어떤 형태의 행렬과 벡터를 적용 하나요? 단순히 트랜스포머가 아니라, 본인의 모델에 맞게 더 특화 시킬 수도 있습니다. 그것이 다음 단계의 전문화 입니다. 이미 그 부분을 고민 하고 있는 여러 기업이 있다고 생각 합니다. 그 방향 역시 매우 흥미 롭다고 생각 합니다. >> 그렇다면 현재 시점에서 고객 들이 TPU와 GPU를 거의 대체 가능한 동등한 것으로 보 나요, 아니면 각각 더 적합한 문제 세트가 따로 있나요? >> 분명히 각 장치에 더 적합한 문제 세트가 존재 합니다. 우선 GPU가 TPU 보다 더 범용 적이 라는 점이 있죠. 그건 분명한 사실 입니다. 구글과 구글 클라우드 에는 훌륭한 제품 들이 많이 있습니다. 저희는 GPU도 많이 판매 하고 있습니다. 내부적으로도 GPU를 사용 하지만, 결국은 해결 하려는 문제의 세부 사항에 따라 달라진다고 봅니다. 고객들의 워크 로드에 두 장치 간 중복 되는 부분이 있기는 하지만, 고객 들은 각자 워크 로드를 평가 하고 선택지를 고려 합니다. 구글 이 지향 하는 것은 고객에게 선택권을 주는 것 입니다. 즉, 고객의 요구에 맞는 적절한 솔루션을 갖추고, 그들의 필요를 가장 잘 충족 하는 솔루션을 제공 하고자 합니다 . >> 칩에서 네트워크, 소프트웨어 에 이르는 공동 설계 (co-design) 를 옹호 하는 이유는 무엇 인가요? 그리고 공동 설계를 반대 하는 이유는 무엇 인가요? >> 네. 공동 설계를 통해 얻을 수 있는 엄청난 최적화 기회 들이 있습니다. 따라서 만약 N -계층 스택이 있고 원하는 구성 요소를 자유롭게 선택 하고 싶다면 어떤 상황이 그려 질지 상상해 보십시오. 여러 클라우드 환경에서 실행 하거나, 다양한 하드웨어와 소프트웨어 제품을 사용 하고 있다고 가정 해 보겠습니다. 그럴 때 추상화 계층을 설계 할 수 있을 것 입니다. 기본적 으로 "나는 어떤 하드웨어 에서든 실행될 수 있다" 는 의미 겠죠. 어떤 소프트웨어 에서든 실행될 수 있고요. 어떤 네트워크 토폴로지, 그러니까 어떤 네트워크 환경 에서도 실행 가능 합니다. 문제 없죠. 제 시스템은 완전히 적응 형이 될 겁니다. 그럴 가능성이 매우 높 으니 이제 엄청난 능력을 갖추게 되는 셈 이죠. 어디로 든 이동할 수 있으니까요. 새로운 자원이 생기면 하룻밤 사이에 바로 가동 할 수 있습니다. 어떤 환경 이든 활용할 수 있도록 시스템을 설계 했기 때문이죠. 특정인 의 인프라에 맞춰 하드 코딩 하거나 특화 하지 않았 으니까요. 단점 이라면 아마 성능 측면에서 많은 부분을 포기 해야 할 겁니다. 완벽 하게 대체 가능 하고, 누구의 하드웨어, 소프트웨어, 네트워크, 스토리지, 컴퓨팅 스택 등 무엇 이든 유연 하게 대응 한다면 말이죠. 그래서 공동 설계가 필요한 겁니다. 각 계층 사이 에는 완전한 범용성을 추구 할 경우 큰 임피던스 불일치가 발생 하거든요. 각 계층에서 10%, 20% , 또는 2 배 정도의 차이가 날 수 있는데, 이런 최적화 기회 를 곱해 나가다 보면 결국 전력 대비 지능 이나 전력 대비 처리량 등 엄청난 엔드 투 엔드 기회를 활용할 수 있게 됩니다. 전력 공급 이나 전력 가용성 소프트웨어 최적화까지 모든 면에서 말이죠. 그래서 장점은 언제 어디 서든 실행 가능 하고 종속 되지 않는다는 점 입니다. 단점은 상당한, 아니 아마도 매우 큰 성능 차이를 포기 해야 한다는 것 입니다. >> 음. 제가 이해 하기로 오픈 AI 는 주로 단일 컴퓨팅 스택 기반으로 구축 했고, 앤 스로 픽은 더 이기종 적인 컴퓨팅 스택으로 구축 한 것으로 압니다. 공동 설계가 그들이 매우 다르다고 알려진 모델 아키텍처로 수렴 하게 된 이유 중 하나 라고 생각 하시나요? >> 음, 추측 하기 어렵 네요. 오픈 AI와 앤 스로 픽이 무엇 을 하는지에 대해 추측 하고 싶지는 않습니다. 그저 하나 의 가능성 일 뿐이죠. 그들이 구체적으로 무엇을 하는지 알지 못하는 상태에서, 그들이 왜 다른 아키텍처를 선택 하게 되었는지에 대한 이유는 매우 많을 것이라고 생각 합니다. >> 그렇다면 구글의 경우는 어떤가요? 구글 팀과 딥 마인드 사이의 협업 관계가 어떤지 궁금 합니다. 모델 개발 단계별로 누가 참여 하고, 공동 설계에 관한 의사 결정을 어떻게 함께 내리시는 지 궁금 합니다. >> 구글에서 일하는 것 중 가장 즐겁고 솔직히 보람찬 부분은 , 하드웨어와 모델의 공동 설계를 위해 딥 마인드 팀과 정말 어깨를 나란히 하고 일할 기회가 있다는 점 입니다. 소비자 서비스와 클라우드를 통해 이를 확장 할 수 있다는 측면에서 세 번째 요소가 존재 합니다. 잠시 제쳐두고 나중에 다시 이야기 하겠지만, 딥 마인드 ( DeepMind) 와의 관계는 정말 깊은 파트너십 입니다. 과거 의 예를 들자면 그들이 모델 최적화 방안을 내놓은 적이 있습니다. 예를 들어, 트랜스포머 나 특정 연산에 대해 그들이 원하는 작업이 있는데, 저희는 아직 미완성 인 칩을 개발 중인 상황 이었죠. 그때 그들이 "맙소사, 여기에 대한 하드웨어 지원이 있다면 어떨까?" 라고 말합니다. 우리의 엔드 투 엔드 학습 이나 서빙 속도가 훨씬 빨라지고 효율적일 수 있을 텐데 말이죠. 하드웨어 설계를 실제로 변경 하려면 무엇이 필요 할까요? 이제 수용 하기 위한 실행 단계에 들어갈 수도 있습니다. 그러면 우리 엔지니어들과 연구원 들이 며칠, 일주일, 혹은 2 주일 동안 한방에 모여 집중적으로 논의 합니다. " 좋아요, 이건 할 수 있습니다. " 라고요. "원하시는 걸 그대로 구현 하기는 어려울 것 같습니다.""하지만 다른 방식은 가능 합니다.""그럼 모델 아키텍처를이 방향으로 조금 바꾸면 우리가 원하던 것의 90%정도는 달성 할 수 있지 않을까요?" 네, 그러면 다시 돌아가서 하드웨어를 조정할 수 있습니다. 아니면 이렇게 말할 수도 있죠. " 있잖아요?""테이프 아웃 (설계 완료 후 제조) 을 일주일 미루 겠습니다.""아니면 2 주라 도요. 왜냐하면 이런 수준의 이점 이라면 충분히 그럴 가치가 있으니까요." 네, 마찬가지로 우리가 로드맵을 계획 할 때도 어느 시점 에나 여러 세대의 칩이 동시에 개발 중 입니다. 생산 중인 칩 들이 있습니다. 그게 첫 번째 죠. 생산을 위해 작업 중인 칩들도 있습니다. 이미 제조사에서 돌아 왔고, 우리 는 그것들을 디버깅 하며 작동 하게 만들고 있습니다. 구현 단계에 있어 곧 테이프 아웃 되어 제조사로 넘어갈 칩들도 있습니다. 설계 단계 에 있는 칩들도 있죠. 그리고 개념 단계에 있는 칩들도 있습니다. 생산부터 구상까지 5 ~ 6 단계에 걸친 수년에 걸친 파이프 라인 인 셈 인데, 생산 중인 칩에 대한 딥 마인드와 의 협업은 매우 중요 합니다. 함께 협력 하여 전력 대비 제공 되는 인텔리전스 나 처리 성능을 극대화 할 수 있기 때문 입니다. 우리는 모델 내에서 무슨 일이 일어나는지, 하드웨어에서 무슨 일이 일어나는지, 그리고 그 사이의 모든 과정 을 정확히 알고 있습니다. 또한 막 테이프 아웃을 앞둔 칩들에 대해서도 깊이 있게 협업 합니다. 왜 냐고요? 왜냐하면 우리가 개입 할 수 있으니까요. 우리는 칩, 말 그대로 칩 아키텍처를 진행 중에 변경할 수 있는데, 이는 타 회사와 협력 했다면 어렵 거나 불가능 했을 일 입니다. 불가능한 건 아니지만, 훨씬 더 힘들었 겠죠, 그렇죠? " 세상에, 이 칩 완성까지 몇 주나 몇 달 밖에 안 남았 는데 , 지금 당장 같은 방에 모여 앉아 프로그램을 뒤엎을 지 결정 하자" 고 말하는 건 말입니다. "가능은 하겠지만, 훨씬 힘들었을 거라고 봅니다 ." 물론 설계 중인 칩의 경우, 우리가 함께 평가할 수 있는 아키텍처가 아주 많습니다. 우리는 딥 마인드의 동료들 에게 물어볼 수 있죠. "모델 아키텍처가 어디로 향하고 있다고 보 나요?""2 ~ 3 년 후에 는 말이죠." 우리가 할 수 있는 일들에 대한 파레토 최적화가 여기 있습니다. 모델 아키텍처가 나아갈 방향 에 대한 파레토 최적화도 여기 있고요. 우리는 워크 로드가 다양한 하드웨어 아키텍처에 어떻게 매핑 될지 예측할 수 있는 깊이 있고 상당한 수준의 시뮬레이션 인프라를 갖추고 있습니다. 깊이 있고 빠른 반복 작업 이죠. 팀 들이 서로 분리 되어 작업 하는 것이 결코 아닙니다. 같은 건물, 같은 공간에서 함께 작업 하는 경우가 아주 많습니다. 깊이 있는 일상적 상호 작용 이죠. 저는 코레 이나 데미스와 일주일에 몇 번씩 대화 합니다. 그래서이 일의 정말 즐거운 측면 이죠. >> 정말 멋지네요. 결국 그들의 모델은 칩 설계 에도 도움을 줄 것 입니다. >> 우리는 미래의 제미 나이를 위한 하드웨어를 설계 하는 데 에도 제미 나이를 사용 하고 있습니다. >> 정말 굉장 하네요. 그 부분은 잠시 후에 다시 이야기 해 보고 싶습니다. 협력 자체에 관해서 인데, 하드웨어를 다룰 때가 딥 마인드 팀이 소프트웨어 측면에서 다루는 것 보다 주기 시간이 훨씬 느려서 생기는 임피던스 불일치가 여전히 있지 않나요 ? 그리고 계획 주기 역시 훨씬 앞서 있을 것 같고요. >> 물론 입니다. >> 그렇다면 실제로 조정할 여지 는 얼마나 되나요? >> 네, 정말 좋은 질문 입니다. 우리는 2, 3, 4, 5 년 앞을 내다 보고 하드웨어를 계획 하고 있습니다. 의심 할 여지가 없죠. 즉, 방금 발표 한 TPU v8 과 AT에 대해 이야기 했지만, 9 , 10 버전과 다른 몇몇 제품 들이 개념 단계에서 실행 단계 등으로 넘어 가고 있다고 상상 하시면 됩니다. 그것들은 몇 년 뒤의 일일 수도 있죠. 만약 모델 아키텍처 작업을 한다면, 기본적으로 수년 후를 생각 하며 일 하지는 않을 테니까요. >> 네. >> 하지만 저는 이것 이야말로 우리 회사가 함께 성장해 온 방식의 위대한 점 이라고 생각 합니다. 다시 말해, 구글 리서치와 딥 마인드, 그리고 트랜스포머의 발명까지, 이 모든 것이 서로 겹치는 공간 안에서 일어나고 있었습니다. 즉, 하드웨어에 영향을 줄 수 있다는 점에 익숙해 진 연구원 들의 세대가 전체적으로 형성된 것이죠. 그리고 하드웨어가 수년에 걸친 주기로 운영 된다는 사실도 알고 있습니다. 또한 그들은 출시를 앞둔 칩에 1%나 0.5%정도의 작은 개선을 가져올 변경 사항이 있다면, 굳이 우리를 찾아 오지 않을 것이라는 점도 알고 있습니다 . 왜냐하면 그들은 소프트웨어처럼 단순히 변경 목록을 작성 해서 2 주 안에 제품으로 배포 할 수 있는 것이 아니라는 사실을 충분히 알고 있기 때문 입니다. 테이프 아웃 (설계 완료 및 제작) 을 중단 하는 것은 실제로 큰일 이니까요. 하지만 그들은 정말 좋은 기회가 있다면, 우리가 함께 협력 해서 그것을 반영 할 방법을 찾을 것임을 잘 알고 있습니다. 그래서 말씀 드렸듯이, 혜택이 오는 측면 에서 이는 곱셈과 같은 효과 를 냅니다. 하드웨어는 모든 조류를 끌어 올리는 역할을 하니까요, 그렇죠? 딥 마인드 팀의 상당 부분이 그렇고, 우리는 그 점에 정말 감사 합니다. 정말 놀라운 팀 이죠. 하지만 그 팀의 상당수는 어떻게 로드맵에 영향을 줄 수 있을지를 고민 하고 있습니다. 왜냐하면 그것은 실제로 파이프 라인 이기 때문 입니다. 2 년 전에 냈던 아이디어가 지금 실제로 운영 되고 있는 식 이죠. 그리고 그것이 구글의 모든 워크 로드를 더 빠르게 처리 하도록 돕고 있습니다. 그건 정말 기분 좋은 일 이죠. >> 전적으로 동의 합니다. 하지만 5 년 후에 어떤 워크 로드가 가장 일반적 일지, 어떤 알고리즘 혁신이 일어날 지 예측 하는 것은 불가능한 일처럼 보입니다. 어, 불가능한 과제처럼 보이지 않나요? >> 불가능한 과제처럼 보인다는 말씀은 이해 합니다만, 아주 놀라운 사실이 하나 있습니다 . 사실 저희는이 내용을 아주 자세하게 작성 하는 작업을 진행 중이고, 그 과정이 매우 즐겁 습니다. 놀라운 점은 TPU 아키텍처가 아주 세밀한 수준 은 아니더라도 중간 정도의 세부 수준에서 볼 때 TPU V1 이후로 크게 변하지 않았다는 것 입니다. CPU의 명령어 집합 아키텍처를 생각 하면 이해 하기 쉽습니다. 로드, 스토어, 덧셈, 뺄셈, 분기 명령 등이 있는데, 그 오랜 기간 동안 그 위에서 구동 되는 소프트웨어 는 무엇을 해왔 을까요? TPU도 마찬가지 입니다. 저희 에게는 몇 가지 기본적인 명령어와 필수적인 프리미티브가 있습니다. 물론 , 그동안 확장 해 오긴 했습니다. 명령어 집합이 전혀 변하지 않았다는 뜻은 아닙니다. 하지만 수치 연산 을 초대형 행렬 곱셈 장치에 특화 시키는 기본 요소들, 음, 벡터 연산과 스 캐터-개더 연산을 관리 하는 스파 스 코어 등, 원격 로드-스토어를 정의 하는 5 ~ 6 가지 핵심 요소가 있습니다. 그것도 하나 죠. 사실 우리는 ICI 네트워크를 통해 원격 메모리 를 읽고 쓸 수 있습니다. 기본 원리는 이미 존재 했고, 이를 여러 세대의 모델과 수많은 세대의 심층 신경망 알고리즘 및 모델 구조 에까지 확장 해 왔습니다. >> 좋습니다. 워크 로드 변화에 대해 이야기 하자면, 지난 1 년 정도, 제 생각 엔 올해 초 부터 시작된 가장 큰 변화 중 하나는 장기 호라이즌 에이전트의 부상 인 것 같습니다. >> 네. >> 그리고 그것은 과거의 빠른 LLM 대화와는 다른 형태의 워크 로드 라고 생각 합니다. 음, 데이터 센터의 요구 사항 측면 에서는 어떤 의미 인가요? >> 네, 저는 이것에 두 가지 거대한 측면이 있다고 생각 합니다. 하나는 더 이상 인간 과, 뭐라 부르든, 가속기 간의 상호 작용이 아니라는 점 입니다. 다시 말해, 웹 브라우저 나 휴대폰 등에서 프롬프트를 입력 할 때, 물론 프롬프트에 대한 응답으로 많은 작업이 발생 하게 됩니다. 하지만 응답이 돌아 오면, 그것을 읽어야 하죠. 생각을 해야 하고, 아마 후속 질문이 생길 수도 있습니다. 그렇게 되면 상호 작용 시간 은 수 초가 걸릴 것 입니다. 이제 장기 호라이즌 에이전트 의 경우, 모델로 요청이 얼마나 빨리 전송 될지 자연스럽게 속도 제한을 걸 인간 루프가 존재 하지 않습니다. 그래서 상호 작용 시간이 수 초에서 수십 초 였던 것이 이제 밀리 초 단위 로 넘어 가게 되는 것이죠. 응답을 받는 즉시 구문 분석 을 하고, 어느 정도 추론을 한 다음, 다음 요청이 무엇이 될지 파악할 수 있습니다. 그게 첫 번째 큰 변화 입니다. 두 번째 큰 변화는 그 모든 추론과 구문 분석이 아마도 CPU에서 일어날 것이라는 점 입니다. 그리고 그 CPU는 아마도 모델에 다음 프롬프트 를 보내기 전에 어떤 다른 상태를 수집 해야 할지 고민 해야 할 것 입니다. 즉, 저는 이 응답을 통해 무언가를 배웠다는 뜻 이죠. 다음 단계 를 진행할 텐데, 이때 로컬 DRAM 이나 다른 CPU의 DRAM, 혹은 SSD 나 HDD 등 어딘가에서 컨텍스트를 가져와야 할 필요 가 있습니다. 이제는 엄청난 규모의 오케스트레이션도 이루어져야 합니다. 설계 방식이 상당히 크게 변하고 있는데, 가속기 컴퓨팅에 대한 수요는 증가 하는 반면 CPU, 네트워킹, 스토리지, 즉 기존 데이터 센터 CPU 등에 대한 수요도 폭발적으로 늘고 있습니다. >> 그렇다면 GPU 랙 옆에 CPU를 더 많이 배치 한다는 뜻 인가요? >> 네, GPU 나 TPU 랙의 경우가 그렇습니다. 이것이 최적화와 전문화 라는 문제로 돌아가는 핵심 질문 입니다. CPU 랙을 GPU 나 TPU 옆에 많이 배치 하기 시작 하면, CPU 랙과 비교 했을 때 TPU 랙이 요구 하는 밀도와 네트워크 요건에 완전히 특화 할 수 없게 된다는 뜻 입니다. TPU 랙은 CPU 랙 보다 더 높은 밀도를 가질 것 입니다. 아마도 CPU 랙 보다 더 많은 네트워킹이 필요할 것 입니다 . 즉, 이제는 건물 설계 방식 이 바뀌어야 한다는 것 입니다. 또 다른 선택 지는 통일성을 유지 하면서 TPU 나 GPU는 한 건물에 몰아 넣고, CPU 는 옆 건물에 두는 방식 입니다. 그리고 하드 드라이브는 또 다른 요구 사항이 있으니 반대편 건물에 배치 해야 할 수도 있습니다. 이제는 건물들 사이에 상당한 수준의 네트워킹이 필요 하게 됩니다. 건물을 벗어나 면 네트워킹 복잡성이 상당히 증가 합니다. 신뢰성 측면 이나 비용 측면에서 지연 시간이 늘어 납니다. 수용 가능한 수준 일 수도 있겠지만, 구성 요소 간의 대기열로 인해 지연 시간이 수백 마이크로 초, 혹은 그 이상으로 늘어날 수도 있습니다. 고려해야 할 사항 들이 매우 흥미로운 방식으로 바뀌는 것이죠. >> 음, 그렇군요. 일이 힘드시 겠어요. >> 재미 있습니다. >> 재미 있어요. >> 네. >> 네트워킹 측면 에서는 어떤 일이 벌어 지고 있나요? 구글 은 광학 기술을 포함한 최신 네트워킹 분야에서 항상 앞서 나갔다고 들었 습니다. 광 네트워킹의 현주소에 대해 한 말씀 해주실 수 있나요? >> 저희 구글은 15, 16 년 전쯤에 데이터 센터 내의 단일 광섬유에 여러 신호를 실을 수 있는 파장 분할 다중화 기술을 도입 한 최초의 기업 중 하나 였습니다. 실제로 저희는 랙 간의 모든 통신에 그 기술을 활용 하고 있습니다. 동시에 파장 분할 다중화와 함께 광 회선 교환 이라는 기술도 도입 했습니다 . 광 회선 교환은 기존의 전기 패킷 교환 방식과 달리 데이터를 전적으로 광 영역 에서 전송 하고 이동 시키는 기술 입니다. 이 기술의 대단한 점을 설명해 드리 자면, 패킷 스위치 에서는 패킷을 받으면 헤더를 전기적 도메인에서 확인 하여 패킷이 어디로 향하는 지 파악 합니다. 헤더 에는 "이 패킷을 어디로 보내야 하지?" 라는 정보를 담은 IP 주소가 있을 수 있습니다. 그러면 테이블 에서 해당 목적지를 조회 하여 어떤 포트로 전송 할지 결정 합니다. 즉, 초당 수십억 , 수백억, 어쩌면 수조 개의 패킷이 엄청난 속도로 들어 오면 이를 계속 전달 하는 것이죠. 광 회로 스위칭은 " 전기적 도메인 에서는이 비트 들을 건드리지 않겠다" 고 말합니다. 대신 입력 포트에 대해 빛을 보낼 출력 포트가 어디 인지 파악 하는 방식을 취 합니다. 아 시겠 나요? 이를 수행 하는 방법 에는 여러 가지가 있습니다. 우리 가 처음 시작한 방식은 MEMS 스위치 라고 하는데, 미세 전기 모터가 3D 공간에서 거울 을 제어 하는 방식 입니다. 그래서 이제 128 개나 256 개 포트 등을 가진 장치를 프로그래밍 방식으로 제어 할 수 있게 되었습니다. 들어오는 광섬유의 모든 입력 포트를 출력 포트에 매핑 하고, 빛이 거울에 비쳐 올바른 출력 포트로 반사 되도록 거울의 각도를 조절 하는 것이죠. 처음에 우리가 이 작업을 수행 한 이유는 두 가지로, 랙 그룹 간의 지역성 을 생성 하기 위해서 였습니다. 예를 들어 컴퓨팅 클러스터와 스토리지 클러스터가 있고, 둘 다 검색 서비스를 지원 한다고 가정 해 봅시다. 두 클러스터가 서로 통신을 많이 할 것을 알았 기에, 거울을 구성 하여 두 클러스터 사이에 순수 하게 광학적 인 지름길을 만들었 습니다. 랙 클러스터 들 말이죠. 이것이 첫 번째 이유 였습니다. 두 번째 이유 는 광섬유를 실제로 옮기지 않고도 네트워크를 확장 하거나 축소 할 수 있기를 원했기 때문 입니다. 세부 사항을 다 설명 하진 않겠지 만, 칠판에 그려 본다면 광 회로 스위치를 사용 하면 사람이 직접 개입 할 필요 없이 컨트롤러가 네트워크의 스파인 구조를 재구성 하여 네트워크를 확장 하거나 축소 할 수 있습니다. 이제 TPU로 넘어가 보죠. TPU는 토러스 토폴로지를 가지고 있어 모든 TPU를 서로 직접 연결 합니다. 앞서 처리량 (throughput) 과 유효 처리량 (goodput) 에 대해 이야기 했었죠. 우리가 할 수 있는 것 중 하나는 TPU 랙에 장애가 발생 하면 광섬유를 옮기지 않고도 다른 TPU 랙 으로 대체 할 수 있다는 점 입니다. 다시 말씀 드리지만, 손짓으로 설명 하거나 화이트 보드에 그려야 하겠지만, 기본적으로 항상 여분의 랙이 준비 되어 있다고 말할 수 있습니다. 그래서 랙에 장애가 발생 하면 빛을 그 새로운 랙으로 다시 보냅니다 . 그 작업은 밀리 초 단위로 이루어질 수 있습니다. >> 그렇다면 왜 굳이 광섬유를 사용 하나요? >> 완전한 자유 공간 통신이 아닌 상태에서 말이죠. 네, 아주 좋은 질문 입니다. 음, 감쇠 손실 문제로 대역폭이 급격히 떨어질 것 입니다. 게다가 매우 큰 건물 전체 에서 3 차원으로 연결해 주는 광섬유의 이점 없이 모든 것을 조준 한다는 것은 거의 불가능에 가까울 정도로 어려운 일 입니다. 음, 저희도 그 부분에 대해 논의 해 봤습니다. 사실 그에 관해 아주 흥미로운 논의 들이 오 갔습니다. 하지만 네, 대부분 은 광섬유를 통하지만, 광 회로 스위치에 도달 하면 본질적으로 빛이 말 그대로 작은 칩 위로 쏟아 지게 됩니다. 그래서 그게 하나의 큰 방향 인데, 음, 사실 그 외에도 아주 많습니다. 제 생각 에는 데이터 센터에서 네트워킹의 성능과 필요성이 폭발적으로 증가 하고 있다고 봅니다. >> 정말 멋지네요. 그것 만으로도 대화를 한참 이어갈 수 있겠 어요. >> 네, 정말 멋진 일 이죠. >> 이더 볼 (eth ball) 사진으로 돌아가서 보면, 수많은 케이블 들이 제 눈을 사로 잡더군요. >> 정확 합니다. 네, 그리고 그 케이블 중 일부는 결국 저희 데이터 센터의 광 회로 스위치로 연결 됩니다. >> 이해가 됩니다. 좋습니다, 이제 전력에 관한 이야기로 넘어가 보죠. 와트 당 굿풋 ( good put) 이나 와트 당 다른 단위들에 대해 계속 말씀 하셨 잖아요. 그걸 들으니 ' 와트 당' 이라는 표현이 전력 이 어떤 면에서 제약 사항 이거나 부족한 자원, 혹은 비용이 많이 드는 문제 라는 생각이 드네요. >> 네, 그래서 종종 "저희가 직면 한 가장 큰 제약 사항은 무엇 인가요?" 라는 질문을 받곤 합니다. 그런데 사실 우리가 직면 한 가장 큰 제약은 하나로 정의 할 수 없습니다. 모두가 제약 조건 이니까요. 전부 정말 어려운 문제들 입니다. 음, 그것들은 계속 해서 변하기도 하죠. 하지만 근본적으로 답 해야 한다면, 전력이 우리가 직면 한 가장 근본적인 제약 이라고 말씀 드리고 싶습니다. 다른 것들은 해결 방법을 알고 있고, 단지 시간을 두고 해결 해야 할 문제처럼 보이 거든요. 전력 이라, 네, 말씀 하신 방식이 참 좋네요. 그건 장기적으로 구속력을 갖는 문제 이고, 저희가 아직...뭐, 핵 발전 같은 것도 있긴 하지만요. 어쩌면 원자력이 풍부한 청정 에너지를 제공 해서 많은 문제를 확실히 해결해 줄지도 모르죠. 언제 그런 일이 일어날 지, 그리고 언제 대규모로 가능할 지는 여전히 미지수 입니다. >> 그렇다면 실제로는 어떻게 운영 되나요? 새로운 데이터 센터를 구축 한다고 가정 해 봅시다. 1 기가 와트의 전력이 필요 합니다. PG&E에 전화 해서 "저기, 1 기가 와트의 전력을 좀 보내 주세요" 라고 말할 수 는 없을 것 같은데요. 전력 공급은 실제로 어떻게 이루어 지나요? 직접 터빈을 돌리는 방식처럼 수직 계열화를 해야 하나요, 아니면 전력 부족 문제를 어떻게 해결 하시나요 ? >> 네, 정말 중요 하고도 큰 질문 입니다. 구글이 선호 하는 모델은 항상 유틸리티 업체에 연결 하는 방식, 즉 전력망에 연결 하는 것 입니다. 그러니까 전력 회사에 전화 하는 것과 같은 셈 이죠. >> 아, 그러니까 PG&E에 그냥 전화 할 수는 없다는 말씀 이시군요? >> 정확 합니다. 데이터 센터가 위치한 지역의 전력 회사에 아주 정중 하게 연락을 취하는 거죠. 물론 수년 전에 미리 통보 해야 합니다. 즉, 1 기가 와트 규모 라면 "당장 내일 1 기가 와트가 필요 해요 . 언제부터 요금을 청구 할 수 있나요?" 라고 말할 수 있는 성격의 것이 아닙니다. 함께 계획을 세워야 하는 일 이죠. 저희는 전력 회사와 협력 할 때 인프라 구축 비용을 저희 가 부담 하는 문제를 매우 중요 하게 생각 합니다. 이 주제 만으로도 긴 대화가 필요할 텐데, 비용 지불 방식 때문에 자칫 하면 저희를 위해 용량을 증설 하는 과정 에서 다른 사람들의 전기 요금이 인상 될 수도 있기 때문 입니다. 이론적으로 저희는 송전선 신설 및 업그레이드, 추가 변전소 건설 등에 드는 비용도 저희 가 부담 하도록 보장 합니다. 그래서 아주 긴 계획 과정이 필요 합니다. 예를 들어 저희 가 2028 년에 1 기가 와트가 필요 하다고 가정 해 봅시다. 그런데 전력 회사는 2029 년 에야 1 기가 와트를 공급할 수 있다고 할 수 있죠. 2028 년 에는 700 메가 와트만 가능할 수도 있습니다. 그럼 이제 나머지 300 메가 와트를 어떻게 해결할 것인가 하는 문제가 남게 됩니다. 글쎄요, 한 가지 답은 그냥 기다리는 것 입니다. 또 다른 대안은 " 좋습니다, 그렇다면 그 전력 의 일부를 우리가 직접 생산할 방법은 없을까?" 라고 생각 하는 것 입니다. 어쩌면 태양 광 전지판을 활용할 수도 있겠죠. 또는 백업용 배터리 등을 사용 하거나, 다른 에너지 원을 활용할 수도 있을 겁니다. 그렇게 되면 우리는 다시 전력 회사 와 협력 하게 됩니다. 또한 지역 내에서 자체적으로 전력 을 생산 하면서, 전력 회사가 기가 와트 규모로 완전히 가동 될 때 조차 우리가 전력 을 다시 그리드에 공급할 수 있는 역량을 유지 하는 조합 도 가능 합니다. 그들이 필요 로 할 때 그 전력을 공급할 수 있게 되는 것이죠, 맞나요? 다시 말해, 일 년 중 가장 더운 2 주처럼 주거용 전력 수요가 폭증 하는 시기가 있을 수 있습니다. 우리가 자체 생산 한 전력이 있다면, 그때 그리드에 다시 공급할 수 있는 것 입니다. 결국 우리 에게는 전력 회사들과 수년간 협력 하는 과정이 꼭 필요 합니다. >> 왜 전력 회사들과 협력 하는 것을 선호 하시나요? 자체적 으로 수직 계열화를 구축 하는 대신 말이죠. >> 네, 주된 이유는 양쪽 모두 에게 유연성과 이점이 있기 때문 입니다. 한 가지 관점은 '통계적 다중화' 또는 '대수의 법칙' 이라고 볼 수 있습니다. 만약 우리가 1 기가 와트의 전력이 필요 하고, 이를 99.99% 이상의 신뢰도로 확보 하고 싶다고 가정 해 봅시다. 아마도 2 기가 와트 규모의 전력 설비를 구축 해야 할 것 입니다. 그렇지 않나요? 99.99% 나 99.999%수준의 안정성을 위해서는 1 + 1 중복성이 필요 합니다. 그건 비용이 많이 드는 일 이죠. 게다가 이상적인 친환경 에너지 원을 데이터 센터 바로 옆에 확보 하는 것도 어려운 과제 일 수 있습니다. 이제 데이터 센터 와 파트너십을 맺는 다면, 우리가 직접 생산 한 전력 중 일부를 그리드에 덜 필요한 시기에 제공 하고, 필요할 때는 전력을 가져올 수도 있습니다. 즉, 더 큰 기반에서 통계적 다중화를 활용 함으로써 결과적으로 모두가 윈윈 하게 되는 것 입니다. 우리도 이득을 보고, 그리드 도 이득을 보며, 주거 시설도 혜택을 받는 등 모두가 좋아지는 것이죠. 우리는 그런 방식을 선호 합니다. 물론 아주 드문 경우에 ' 비하인드 더 미터 (behind the meter)' 방식으로 진행할 수도 있지만, 그때도 1 년 뒤에는 전력 회사와 협력 할 것이라는 전제 하에 움직 입니다. 우리는 항상 그리드 와 연결 되기를 원 하니까요. 그건 다시 말해 우리 에게도 도움이 되고, 전력망 에도 도움이 되는 일 입니다. >> 일리가 있네요. 데이터 센터 규모는 어떻게 결정 하시나요 ? >> 그건 일종의 예술 이자 상당한 논쟁의 여지가 있는 부분 이죠. 글쎄요, 10 년, 15 년 전쯤 구글 내부에서 큰 논쟁이 있었습니다. 모든 것을 하나의 데이터 센터에 몰아 넣어야 할까? 당시에는 1 기가 와트 규모를 생각 했었죠. 그게 >> 단순 했던 시절 이었죠. >> 네, 지금과는 다른 시대 였죠. 10 ~ 15 년 전에는 1 기가 와트 급 데이터 센터를 만들 려고 했으니까요. 가장 분명한 우려는 단일 장애 지점 (single point of failure) 문제 였겠죠. 맞습니다. 30 년 이라는 장기적인 관점에서 보면 큰 문제 였죠. 반면에 오늘날의 학습 워크 로드를 생각 하면 클수록 더 좋습니다. 맞아요. 네트워킹 관점 에서는 가능한 한 작은 거리에 집중 시키는 게 유리 하니까요. 하지만 다시 말해, 단일 장애 지점 문제와 이제는 전력 확보 문제 라는 두 가지 이슈가 있죠. 10 ~ 15 년 전에는 1 기가 와트가 엄청나게 컸지만 상상 은 가능 했죠. 하지만 지금 구글의 전체 요구 사항을 한곳에 다 수용 하는 건 국내 어디 서든, 전 세계 어디 서든 불가능 합니다. 결코 가능한 일이 아니죠. 그렇다면 지금 최적의 규모는 어느 정도 일까요? 이를 위한 모델과 시뮬레이터 등이 있습니다. 하지만 상황에 따라 다르죠. 어떤 곳은 네트워크 가장자리 에 위치 하거나 수십 메가 와트 규모의 국가 일 수도 있습니다. 실제로 이라크 같은 곳의 ISP와 협력 하기도 하죠. 말 그대로 이라크가 될 수도 있는 겁니다. 여기는 학습용 클러스터 이고요. 그럼 아마 1 기가 와트에 더 가까워 지겠죠. 다른 부지 들은 수백 메가 와트 규모가 될 수도 있고요. >> 흥미 롭 네요. 포트폴리오 수명 주기 관리는 어떻게 생각 하시는지 궁금 합니다. 제 생각 에는 가장 크고 최신 인 클러스터는 최신 프런티어 모델을 학습 하는 데 사용될 것 같은데요. 그러고 나서 나머지는 재활용 해서 추론을 실행 하는 방식 인가요? 그게 타당한 프레임 워크 인가요? 아니면 추론 전용 클러스터를 따로 구축 하기도 하시나요? 전체적으로 어떻게 운영 되나요? >> 아주 타당한 프레임 워크 라고 생각 합니다. 충분히 일리가 있는 말씀 이시네요. 하지만 추론에 대한 수요 때문에 단순히 예전 학습 클러스터가 더 이상 학습에 충분히 사용 되지 않는다는 이유 만으로 그것을 추론의 기반으로 삼을 수는 없습니다 . 또한 생각해 보면, 특정 해 에는 학습 클러스터를 소수의 대규모 사이트로 다시 중앙 집중화 할 수도 있습니다. 그리고 그 사이의 네트워크 거리를 짧게 유지 하는 데 따르는 이점도 있죠. 따라서 그들이 세계 어디에 있든 아마도 같은 대륙에 위치 하게 될 것 입니다. 심지어 특정 연도 에는 같은 대륙의 같은 지역에 있을 수도 있습니다. 그렇게 되면 다른 대륙 에는 서비스 용량이 충분 하지 않게 될 수 있습니다. 기타 등등 이죠. 그래서 결국 에는 전 세계 다른 곳에 전문화 된 추론 시설을 구축 해야 합니다. 그러니까, 제 생각에 당신의 직관은 정확 하지만, 전적으로 그렇지는 않습니다. 다시 말해, 여기는 학습 클러스터 라고 확실히 정해 두어야 합니다. 네, 아마도 몇 년 후에는 서비스 용으로 사용될 수도 있겠죠. 하지만 우리는 서비스 클러스터도 별도로 구축 해야만 합니다. >> 그렇다면 서비스 클러스터는 학습 클러스터와 다른 가요? 더 규모가 작은 가요? 메가 와트 당 비용이 더 저렴한 가요? >> 사실 반드시 더 저렴한 것은 아닙니다. 왜냐하면 서비스의 경우 컴퓨팅, 네트워킹, 스토리지를 함께 배치 해야 할 필요성이 더 크기 때문 입니다. 그 지점에서 우리는 전문화 할 수 없는 상황에 직면 하게 됩니다. 학습의 경우 대규모 밀집도와 균일 한 배포 등이 이루어 지지만, 서비스의 경우 스토리지, 컴퓨팅, 가속기를 적절히 조합 해야 합니다. 게다가이 부분은 더 자세히 다룰 수 있는 아주 흥미로운 측면 인데, 서비스 측면 에서는 한곳에 너무 많은 것을 집중 시키고 싶어 하지 않죠. 전 세계 곳곳에서 워크 로드를 처리 하고 싶어 할 겁니다. 하지만 결국 우리는 개별 모델 엔드 포인트를 가지게 되고, 실제로 모델의 변형이 생길 수도 있습니다. 그래서 이제 우리는 지역적 특성까지 고려 하여이 모델 들을 전 세계로 분산 시켜야 합니다. 따라서 규모는 더 작아 질 것 입니다. 아마도 추론 측면 에서는 수직적 통합 수준이 더 낮을 것 입니다. >> 정말 흥미 롭 네요. 그럼 5 년 전에 데이터 센터를 만들었 다면, 5 년 전의 최첨단 가속기는 지금과 많이 달랐을 텐데요. >> 음, 맞습니다. >> 오늘날 만들어 지는 것들 보다 훨씬 효율이 떨어지죠. >> 네, 맞습니다. >> 그럼 실제로 예전 데이터 센터로 돌아가서 칩을 교체 하기도 하나요? 칩의 실제 유용한 수명이 어느 정도 인가에 대한 논쟁이 계속 되고 있다는 점과 관련이 있다고 생각 합니다. >> 네. 네, 제가 예전에 했던 말인데, 예상 보다 반응이 커서 놀랐 습니다. 저희가 7 년 된 TPU를 여전히 100%활용 하고 있다고 말 했었죠. >> 와. >> 어, 그리고 >> 저도 봤습니다. 이게 그렇게 중요한 의미가 있는 줄은 몰랐 거든요. >> 네, 그냥 한 말이 었는데 듣는 사람들 에게는 꽤 의미심장 하게 받아 들여진 모양 이더군요. 네, 구형 GPU도 있지만, 저희 구형 TPU 들의 활용도가 매우 높습니다. 물론 저희도 교체는 합니다. 결국 감가 상각 수명이 약 6 년 이라는 문제가 있죠. 그래서 완전히 감가 상각이 끝나고 차세대 제품의 전력 효율 등을 고려 하면, 교체 하고 업그레이드 하는 것이 합리적 입니다. 칩만 바꾸는 것이 아니라 시스템 전체를 교체 하는 것이죠. 즉, 저희는 '포드 (pod)' 단위로 생각 합니다. 예를 들어, TPU v4 포드 는 9,600 개의 칩으로 구성 될 수 있습니다. 그리고 140 여 개의 랙으로 이루어 지죠. 그러면 저희는 그 포드를 들어 내고 TPU v12, v13, v14 포드 등으로 교체 하게 됩니다. 항상 완벽 하게 들어 맞지는 않을 수도 있습니다. 즉, 새로운 포드의 공간이 기존 포드가 빠져 나간 자리에 딱 맞지 않을 수도 있다는 뜻 입니다. 그럴 경우 저희가 그 차이를 고려해야 하죠. 어떻게 개조 할지 방법을 찾아야 합니다. TPU가 몇 세대 나 더 나올지 모르기 때문에 미리 계획 할 수는 없습니다. 그래서 기존 장비를 철거 하고 새 TPU로 최대한 빨리 교체 하는 것은 나름의 노하우가 필요한 어려운 작업 입니다. >> 개방형 표준에 대해 공개적 으로 글을 쓰신 적이 있죠. 그 부분에 대해 한 말씀 해주 시겠습니까? >> 네, 우리가 앞서 이야기 했던 상호 운용성 문제와 관련이 있다고 봅니다. 저희는 수직적 통합을 지원 하고 최대한의 성능을 끌어낼 수 있도록 만들고 있지만, 동시에 특정 시스템에 종속 되거나 폐쇄적 인 환경을 강요 하지 않는 것을 매우 중요 하게 생각 합니다. 그러니까, 음, 한 가지 예를 들어 보죠. 구글 에서는 JAX 라는 모델 개발 프레임 워크 를 개발 했습니다. 저희는 아주 좋아 하죠. 정말 훌륭 하다고 생각 하며 내부적으로 도 광범위 하게 사용 하고 있습니다. 많은 고객이 PyTorch 를 선호 합니다. 그렇죠? 그래서 우리가 "자, TPU에서 실행 하고 싶다면 JAX를 사용해야 합니다. 그게 최고 니까요" 라고 말할 수도 있겠죠. 조금 과장 하는 것 같기도 하지만, 뭐 아닐 수도 있고요. 우리는 그게 최고 라고 생각 하고, 워낙 뛰어 나니 그게 유일한 선택지 라고 할 수도 있겠죠. 아니면 이렇게 말할 수도 있습니다. " 보세요, JAX가 좋다 면 저희도 JAX를 좋아 합니다. JAX가 마음 에 드시면 사용 하시면 됩니다. 하지만 PyTorch를 선호 하신 다면 수정 없이 모델을 실행할 수 있는 torch TPU가 준비 되어 있습니다." 사실 우리는 역사 속의 수많은 사례를 통해 이런 모습을 봐 왔습니다. 저는 IP (인터넷 프로토콜) 의 예를 들어 왔죠. 왜 인터넷 프로토콜이 승리 했을 까요? 사실 IP와 경쟁 하던 프로토콜은 많았 습니다 . 70 년대와 80 년대 초의 아주 오래된 이야기 죠. 왜 IP가 이겼을 까요? 그건 IP가 오픈 표준 이었기 때문 입니다. 모래 시계의 잘록한 허리처럼 위로는 어떤 소프트웨어 든, 아래로는 어떤 하드웨어 든 구동 될 수 있었 으니까요. 즉 , 오픈 표준 이자 상호 운용이 가능 했기 때문 입니다. IP를 가진 누구든 라우터 포트에 연결만 하면 인터넷의 일부가 될 수 있었죠. 정말 멋진 일 이었습니다. 그 덕분에 인터넷이 전 세계로 폭발적 으로 성장 하고 퍼져 나갈 수 있었습니다. 그래서 우리는 플러그인 지점 측면에서 이러한 오픈 표준을 진심으로 신뢰 합니다. 물론 아주 특수한 무언가를 연결 하고 싶다면 그렇게 할 수 있습니다. 그렇죠? 저희 프레임 워크에 연결할 더 나은 방법이 있다고 생각 하신 다면 얼마 든지 그렇게 하셔도 됩니다. 하지만 우리 는 오픈 표준, 가급적 오픈 소스로 둘러싸인 표준을 진심 으로 지원 하고자 합니다. >> 이건 어느 한 공급 업체의 폐쇄 적이고 독점적 인 표준 으로 두기 에는 너무나 크고 중요한 인프라 구축 이니까요 . >> 네, 우리는 정말 그렇게 믿습니다. 또한 선택권이 보장 되어야 하죠. 예를 들어 저희가 TPU, GPU, 그 외 다양한 가속기를 전적으로 지원 하고 제공 하는 이유도 바로 그 때문 입니다. >> 네. AI 도입 이후 팀의 일상 업무는 어떻게 바뀌 었나요? 어떤 부분에서 가장 큰 변화 가 일어나고 있나요? >> 음, 가장 쉽게 답변 하자면 소프트웨어 엔지니어링 분야 일 것 입니다. 외부 에도 이미 상당히 많이 알려진 내용 이죠. 음, 그래서 저는 구글과 저희 팀이 소프트웨어 개발 역량 측면에서 AI를 매우 효과적으로 활용 하고 있다고 생각 합니다. 테스트, 출시, 심지어 설계 지원 등에서도 말이죠. 하지만 외부 적으로 는 덜 알려졌 을지 몰라도 하드웨어 측면 에서도 상당한 변화가 있었습니다. 다시 말해, 오늘 아침에 수치를 확인해 봤는데 저희 하드웨어 엔지니어들도 AI를 사용 하고 있습니다. 토큰 수로 따져 보자면, 최선의 지표는 아닐지 몰라도 어쨌든 지표는 되는 셈 이죠. 저희 하드웨어 엔지니어 들은 소프트웨어 엔지니어들 만큼이나 AI를 많이 사용 하고 있습니다. 그 결과 생산성이 향상 되었고, 설계 시작부터 테이프 아웃 까지 걸리는 시간이 줄어들고 있습니다. 제품 구동까지 걸리는 시간도 줄어들고 있죠 . 즉, 생산성이 크게 향상 되고 있는 겁니다. 하지만 예상치 못했던 다른 변화도 있습니다. 데이터 센터를 설계 하는 방식이 크게 달라졌 거든요. 다시 말해, ' 기가 와트 급 건물을 지을 지, 100MW 규모의 캠퍼스로 할지, 아니면 200MW 캠퍼스로 할지' 를 평가 하는 방식이 바뀌 었 습니다. 과거 에는 매우 상세 하고 스프레드 시트에 의존 하며 사람이 일일이 주도 하는 과정 이었죠. 지금도 어느 정도는 그렇지만, 이제는 AI가 많이 개입 되어 기획 및 개발 측면의 과정을 정말 효율적으로 만들어 주고 있습니다. >> 흥미 롭 네요. >> 그러면 추론 모델 같은 건가요? >> 아직 추론 모델 이라고 하기 까진 이릅니다. 인간의 판단 을 대체 하는 것은 아니지만, 필요한 정보를 한곳에 모으기 가 훨씬 쉬워 졌고 의사 결정 을 내리는 사람들에게 적절한 정보를 제공해 주는 역할을 합니다. >> 좋습니다. 좀 엉뚱 하면서도 재미있는 두 가지 질문으로 마무리 해 보겠습니다. >> 네. >> 음, 첫 번째 질문 입니다. 궤도 데이터 센터에 대해서요 . 구글이이 문제를 꽤 진지 하게 고민 하고 있다는 것을 알고 있습니다. 이에 대해 언급 하실 필요는 없지만, 사람들이 궤도 컴퓨팅에 대해 진지 하게 수치를 계산 하고 있다는 사실이 지구상에 심각한 제약 조건이 있다는 것을 의미 하는 걸까요? 그리고 궤도 데이터 센터에 대해 어떻게 생각 하시나요? >> 네, 흥미로운 방향 입니다. 저희는 실제로 이를 추진하고 있으며, 단순히 농담조가 아니라 저희가 투자 하는 중요한 '문샷 (Moonshot)' 프로젝트 중 하나로 여기고 있습니다. 이건 대화 초반에 말씀 하신 내용으로 돌아가는 건데, 근본적인 제약 조건 으로 에너지와 에너지 생산이 핵심 적인 도전 과제 라고 지적 하신 부분이 정확 하다고 봅니다. 결론적으로 근본적인 관점에서 보면, 우주 에서는 대기 중의 감쇠 현상 등이 없기 때문에 약 40% 정도 더 많은 전력을 얻을 수 있습니다. 즉, 태양 광 발전 용량이 1.4 배 정도 더 크다는 뜻 이죠. 그게 첫 번째 부분 입니다. 하지만 태양 동기 궤도 에서는 태양 전지판이 햇빛을 받는 시간이 98 ~ 100%에 달합니다. 지상에서의 28 ~ 30%, 많아야 35%와 비교 하면 엄청난 수치 죠. 그렇군요. 다시 말해, 태양 이라는 엄청난 에너지 원이 있기 때문에 가용 한 전력량이 막대 합니다. 앞서 말한 1.4 배 의 효율에 하루 일조 시간 기준 3 ~ 4 배의 이점을 곱하는 셈 이죠. 그러면 배터리를 사실상 고려 대상에서 제외 할 수 있게 됩니다. 이제 진정 으로 가능성 있는 무언가를 만들 수 있게 되는 거죠. 물론 탄소 배출도 없고요. 장점이 아주 많죠. 도전 과제도 많고요. >> 네. >> 맞습니다. 정말 수많은 도전 과제가 있죠. 그렇다면 냉각 문제는 어떨까요? 순진 하게 생각 하면 우주에서 냉각 하는 게 더 쉽다고 생각할 수도 있죠. 사실은 더 어렵 습니다. 신뢰성 문제도 있고요. 이런 장비 들이 가끔 고장 난다는 이야기를 했었죠 . 그래서 수리가 훨씬 어려워 집니다. 불가능한 건 아니지만, 우주 에서는 더 힘든 일 이죠. 네트워킹도 마찬가지 고요. >> 클러스터와 연결 하는 문제 죠. >> 정확 합니다. 어쩌면이 모델 이 유망한 방향이 될지도 모르겠네요. 아마도 중복성을 확보 하는 것이 도움이 될 겁니다. 질문자 님이 말씀 하신 자유 공간 광통신이 이제 현실이 될 겁니다. 아마 이런 부품들 사이에 광섬유를 일일이 연결 하지는 않을 테니까요. 그래서 실제로 자유 공간 통신이 이루어질 겁니다. 레이저를 수신기에 조준 하고 실시간으로 보정 하는 방식을 쓰게 되겠죠. 이런 문제 들은 해결 불가능한 장애물은 아닙니다. 근본적으로 발목을 잡을 요소 는 없죠. >> 마지막 질문 입니다. 계속 해서 당신이 만든 그 엄청난 슈퍼 컴퓨터의 이미지가 머릿속을 떠나지 않네요. 그래서 드리는 질문 입니다. 10 년 후 가장 최첨단 슈퍼 컴퓨터는 어떤 모습 일까요? >> 세상에. 네. 10 년 이라는 시간 은 참 애매한 경계선 이라, 진지 하게 2036 년의 컴퓨터가 어떤 모습 일지 고민 하는 사람이 분명 있을 겁니다. 그렇게 먼 미래를 내다 보는 사람도 몇 명은 있겠죠. 하지만와, 불확실성의 범위가 너무나도 넓 습니다. 다시 말해, 현재 추세를 보면 통합 의 수준이 엄청날 것이라는 점은 분명 합니다. Ineffable을 위해 우리가 구성 했던 아름다운 광섬유와 VR200 랙을 보셨 겠지만 요. 제 생각 에는 훨씬 더 고도로 통합 된 형태 가 될 것 같습니다. 2036 년 에는 광섬유가 아예 사라지 지는 않겠지만, 랙 관점에서 보면 훨씬 더 긴밀 하게 통합 될 것이고 랙에서 나오는 광섬유는 작은 다발 정도일 것으로 생각 합니다. 다시 말해, 모듈 형 제조 관점에서 보면 2036 년 에는 이러한 랙 들이 중앙에서 제조 될 가능성이 높습니다. 72 개든 144 개든 288 개든, 아니면 아마도 그보다 더 많은 576 개나 1152 개든, GPU의 배수 중 원하는 것을 선택 하세요. 이네 퍼블 (Ineffable) 사례에 대해 이야기 했으니 TPU도 마찬가지 일 겁니다. 랙에 깊숙이 통합 되어 있죠. 랙 하나가 수 메가 와트 급이 될까요? 정확히는 알 수 없지만 2036 년 이니까 상상해 볼 수 있겠죠. 단일 랙에 수 메가 와트가 될 수도 있습니다. 이제 물과 전력, 광섬유를 연결 하는 겁니다. 그렇죠? 랙을 밀어 넣고 그 세 가지를 연결 하면 바로 가동 을 시작 하는 거죠. >> 알겠습니다, 그럼 커다란 외계 구체 같은 모습은 아니 겠네요. >> 우주에 있는 거요. 2036 년 이라면 불가능 하다고 말할 순 없겠죠. 바로 우주로 발사 되어 우주 정거장의 로봇 팔 이 잡아서 적절한 모듈에 연결 하는 식일 수도 있으니까요. 어쩌면 2036 년 에는 가능 할지도 모릅니다. >> 재밌 네요. >> 생각만 해도 즐겁 습니다. >> 이번 대화 정말 즐거웠 습니다. 지금은 역사상 가장 강렬 하고 거대한 자본 지출 빌드 업이 이루어지는 시기 지만, 저는 이것이 기술적 인 >> 혁명 이라고 생각 합니다. >> 정말 아름다운 혁명 이죠. 기술의 아름다움과 제약 사항 들, 그리고이 모든 것을 어떻게 균형 잡아야 하는지에 대해 깊이 이해 하고 계시는 것 같습니다. 구글은 아주 잘 운영 되고 있네요. >> 감사 합니다. >> 시간 내어 하시는 일을 공유해 주셔서 감사 합니다. >> 정말 즐거웠 습니다. 우리는 이 시대를 살아가고 있으니 우리가 직접 정의 해 나갈 수 있는 거죠. 정말 감사 합니다. 훌륭한 대화 였습니다. >> 감사 합니다. >> 네, 감사 합니다.


[외부 원문 2]
[URL] https://www.youtube.com/watch?v=bGph8GwB3Sk
[제목] Google's AI Infrastructure Chief, Amin Vahdat, on the Physics & Economics of Frontier AI

[유튜브 영상 전사 원문]
[영상 ID] bGph8GwB3Sk
[채널] Sequoia Capital
[실제 게시일] 2026.10.06
[영상] https://www.youtube.com/watch?v=bGph8GwB3Sk
[전사 제공자] youtube_transcript_api

[261006] Google's AI Infrastructure Chief, Amin Vahdat, on the Physics & Economics of Frontier AI Sequoia Capital

하드웨어 분야 에는 특정한 작업 부하에 더 전문화 될수록 유연성은 떨어지지만 하드웨어의 속도는 더 빨라지고 전력 효율성은 높아지는 기회가 있습니다. 그래서 이것은 일종의 예술 이자 무엇을 설계 할 것인지, 그리고 그 작업 부하가 얼마나 지속될 것인지에 대한 예측 입니다. 다시 말해, 한두 달 이나 석 달 뒤에 사라질 작업 이라면 그 기간 동안 규모가 크 더라도 이를 포착 할 수 있는 기회는 매우 짧 습니다. 따라서 어느 정도 지속 가능 해야 합니다. 또한, 그 작업에 전문화 함으로써 정확히 어떤 이득을 얻을 수 있을지 예측할 수 있어야 하죠. >> 아민 베다 트 (Amin Vedat) 님을 쇼에 모시게 되어 매우 기쁩니다. 아민, 오늘 함께 해 주셔서 감사 합니다. >> 이곳에 오게 되어 정말 기쁩니다. 정말 기대 됩니다. >> 저는 오늘 주제가 매우 기대 되는데, 우리는 인류 역사상 가장 큰 자본 지출 (Capex) 구축 의 한가운데에 있기 때문 입니다. 당신은 그 중심에 있고요. 구글 한 곳 에서만 올해 2 천억 달러 이상을 자본 지출로 사용할 것으로 예상 되며, 대부분은 데이터 센터 구축에 투입 됩니다. 당신은 그 모든 것의 중심에 있습니다. 당신은 작년 말 구글의 AI 인프라 책임자로 임명 되었습니다. 그러니 당신은 인류 역사상 가장 자본 집약적 인 구축 노력 중 하나를 이끄는 인물 인 셈 이죠. 그래서 오늘 당신과이 주제로 깊이 이야기 할 수 있어 정말 기쁩니다. >> 물론 구글을 포함한 업계 전반에 걸쳐 정말 엄청난 해 입니다. 솔직히 말해 이런 상황을 본 적이 없는 것 같습니다. 구글은 물론 이고, 당신이 말했듯이 인류 역사상 구축 규모와 변화의 속도 측면에서 정말 믿을 수 없을 정도 입니다. >> 본격적으로 들어가기 전에, 청중을 위해 AI 데이터 센터 란 무엇 이며 비 AI 데이터 센터와 어떻게 다른지 간단히 설명해 주 시겠습니까? >> 아주 좋은 질문 입니다. AI 데이터 센터와 비 AI 데이터 센터는 실제로 많은 유사점을 가지고 있으며 근본적으로 크게 다르지는 않습니다. 즉, 콘크리트로 이루어져 있다는 점은 같죠. 건물 내부 말입니다. 전기 시설, 기계 시설, 냉각 시스템으로 구성 됩니다. 줄 지어 분배 되는 전력 설비가 있죠. 그곳에는 엄청난 양의 네트워크 인프라 가 있습니다. 다른 말로 하면, 대규모 연산 장치 들을 서로 연결 하는 것 입니다. 상당한 양의 스토리지 인프라도 들어 갑니다. 제가 보기에 AI 인프라에서 가장 큰 차이점은 바로 전문화 라고 생각 합니다. 과거에 데이터 센터 를 구축 할 때는 20 년, 25 년, 30 년을 내다 보는 건물 투자 였고, 그 기간 동안 어떻게 발전해 나갈지를 고민 했습니다. 서버가 들어갈 수도 있었죠. 네트워킹 이나 스토리지가 필요할 수도 있고요. 가속기, GPU, TPU 등 무엇 이든 그 안에 들어갈 수 있었습니다. 하지만 25 년에서 30 년 이라는 계획 기간이 존재 했죠. 하드웨어의 수명 은 6 년 정도일 수 있습니다. 그래서 여러 세대를 미리 계획 해야만 하는 거죠. AI 데이터 센터는 종종 더 목적 에 맞게 구축 되곤 합니다. 다시 말해, 우리는 종종 하드웨어와 건물을 함께 설계 합니다. 예를 들어, 이 건물 에는 스토리지를 많이 넣지 않겠다고 결정할 수도 있죠. 왜 일까요? 스토리지 랙은 전력이 10, 20, 30, 40 킬로와트 정도 필요할 수 있기 때문 입니다. 반면, 오늘날 수백 킬로와트에 달하는 TPU 랙 이나 GPU 랙 옆에 그걸 둔다고 생각 해보세요. 메가 와트 수준에 이를 수도 있습니다. 사람들은 향후 몇 년 내에 그런 수준이 될 거라고 이야기 합니다. 한 줄에 스토리지 랙 30 개를 넣는 건물과 AI 랙 한두 개를 넣는 건물의 설계는 매우 다를 수밖에 없습니다. 크기만 생각해 보더라도 그렇습니다. 전력과 그 전력이 건물 전체 에 어떻게 분배 될지 등을 생각 해보세요. 네트워킹도 마찬가지 입니다. 스토리지 랙에 필요한 네트워킹 양은 아주 적죠. 특히 AI 랙과 비교 하면 하드 드라이브 위주의 스토리지 랙은 더욱 그렇습니다. 그래서 모든 것을 호환 가능 하게 만들 려고 하면, 아마 너무 크게 짓 거나 과도 하게 설계 하게 될 겁니다. 30 년 이라는 기간 동안 범용성을 유지 하는 것은 어렵죠. AI 데이터 센터 는 목적에 맞게 더 특화 되어야 하며, 냉각 이나 전력 분배에 이르기까지 하드웨어 와 공동 설계 되어야 합니다. 즉, 훨씬 더 많은 공동 최적화 가 필요 합니다. >> 당신들이 제 포트폴리오 기업 중 하나 인 'Ineffable Intelligence' 에 대규모 베어 메탈 클러스터를 납품 했을 때, 출고 되는 사진을 봤습니다. 정말 아름답 더군요. >> 그렇습니다. 맞습니다. >> 제 말은, 인류 역사상 가장 큰 건설 프로젝트를 보는 것처럼 데이터 센터를 바라 보면 "와, 인류가 해낼 수 있는 기념비적 인 업적 이다" 라는 생각이 든다는 겁니다. >> 네, 좋은 사진을 찍었 죠. 그런데 사실 이건 고작 몇 개의 랙일 뿐입니다. 케이블 링과 광섬유 분배는 정말 아름답 습니다. 아름다움은 보는 사람의 눈에 달렸다고 하지만, 저나 여러분, 그리고 청중 분들께는 정말 멋진 광경 이죠. 우리가 소셜 미디어에이 사진을 올렸을 때 사람들이 인에 퍼블 (Ineffable) 에 열광 했는데, 저도 그들이 하는 일의 엄청난 팬 이고 팀 도 정말 훌륭 합니다. 많은 주목을 받았습니다. 인에 퍼블을 위한 훌륭한 랙도 좋지만, 사실 사람들은 광섬유의 모습과 그 프랙탈 같은 구조를 보는 걸 정말 좋아 했어요. 실제로 저희가 올린 게시물 중 가장 인기 있었던 것 중 하나가 바로 그거 였죠. 네, 정말 그렇습니다. 저희도 그 점에 대해 매우 기대 하고 있습니다. >> 맞아요, 그 사진을 보고 소름 이 돋았 죠. >> 음. >> 이런 대규모 구축 과정에서 어떻게 측정 하고 스스로 책임을 지시 나요? 방송 직전 에 FLOPS가 허울 뿐인 지표 이며, 다른 대안 지표를 선호 한다고 말씀 하셨죠. 조금 더 자세히 설명해 주실 수 있나요? >> 네, 한 가지 주목할 점은 FLOPS 든 다른 어떤 칩 중심의 지표 든 모두 이론적 인 수치 라는 것 입니다. 다시 말해, 어떤 칩 이든 특정 조건 하에서 낼 수 있는 최대 FLOPS를 의미 하죠. 결국 우리가 정말 중요 하게 생각 하는 건 워크 로드 별로 실질적인 성능이 얼마나 나오 느냐 하는 겁니다. 그게 바로 우리가 주목 하는 부분 이죠. 단일 칩으로 성능이 결정 되는 경우는 거의 없습니다. FLOPS, HBM, SRAM 용량 등도 매우 중요 하지만, 결국 2 개, 4 개, 8 개, 16 개, 천 개, 만 개 이상의 칩이 어떻게 구성 되느냐가 관건 입니다. TPU 나 GPU 같은 가속기 뿐만 아니라 데이터를 공급 하는 CPU, 그리고 이들을 연결 하는 네트워크까지 모두 포함 해서 말이죠. 그래서, 어떤 워크 로드를 실행 하고 있고 그 워크 로드의 성능은 어떠한지 가 중요한 것 입니다. 흥미로운 지표 중 하나는 FLOPS 활용도 입니다. 예를 들어 특정 워크 로드에서 이론적 으로 테라 플롭스 나 페타 플롭스를 낼 수 있다면, 그중 실제로는 어느 정도의 비율을 달성 하고 있느냐는 거죠. 그게 바로 굿풋 (goodput) 의 척도 입니다. >> 굿풋 이란 무엇 인가요? >> 잘 알려진 용어 인 처리량 ( throughput) 을 생각 하시면 됩니다. >> 네. >> 그것이 가능한 처리량 이라면 , 이제 다른 고려 사항들도 생각해 보죠. 하나는 워크 로드 자체의 고유 한 특성 으로 인한 속도 저하 이고, 또 다른 중요한 측면은 신뢰성 입니다. 우리가 어떻게 책임 을 다할 것인가 하는 측면 에서 볼 때, 동기식 워크 로드 에서 칩 오류가 발생 한다면, 학습, 서빙, 에이전트 워크 로드 등 많은 작업이 동기식 으로 돌아 갑니다. 수많은 구성 요소가 동시에 함께 작동 하고 있죠. 이제 수천, 수만, 십만 개의 구성 요소가 동시에 작동 하며 마이크로 초나 밀리 초 단위로 긴밀 하게 조율 되어야 한다고 가정 해 봅시다. 그중 하나만 실패 해도 전체 시스템이 멈출 수 있습니다. 그렇지 않나요? 모두가 어려운 질문 에 대한 답을 내기 위해 서로 의 역할을 다할 것이라고 믿고 있기 때문 입니다. 하나 가 멈 추면, 무엇이 잘못 되었는지, 어떤 것이 멈췄 는지, 그리고 과거 어느 시점 의 연산 체크 포인트가 남아 있는지 파악 해야 합니다. 그 체크 포인트를 어떻게 복구 할까요? 어떻게 다시 시작 할까요? 최악의 경우, 처음 부터 다시 시작 해야 할 수도 있습니다. 정말 최악 이겠지만, 특히 추론 측면 에서는 그런 일이 실제로 발생할 수 있습니다. 여기서 핵심은 만약 다시 돌아가서 수많은 연산을 반복 해야 하거나, 오류 원인을 파악 하기 위해 작업을 멈추고 기다려야 한다면, 그 모든 과정이 작업 이라는 점 입니다. 결과를 얻는 데 전혀 도움이 되지 않죠. 그렇지 않나요? 종이 위에 문제를 푼다 고 가정 해 봅시다. 1 단계, 2 단계, 3 단계, 4 단계가 있습니다. 실수를 해서 1 단계 로 다시 돌아 가야 한다면, 네 , 여전히 작업을 하고 있는 것은 맞습니다. 그게 바로 처리량 입니다. 작업은 하고 있지만, 정작 답을 도출 하는 데 유효한 작업량 (Goodput) 은 얼마 일까요? 기본적으로 문제를 해결 하는 데 걸린 총 시간 입니다. 그게 바로 중요한 것 입니다. 만약 오류 가 발생 하고, 복구 해야 하며 , 작업이 중단 되는 어떤 상황 이든 발생 한다면, 그것이 바로 문제의 일부 입니다. 그렇다면 우리는 어떻게 책임 을 다할 수 있을까요? 이론적 인 벤치 마크 처리량 이나 수치가 아니라, 실제 워크 로드에서 발생 하는 오류를 포함한 결과물, 즉 실질적인 유효 작업량을 전달 하는 것 입니다. 불행한 현실은 10만 개의 가속기 규모 에서는, >> 제가 하려던 말은 그 정도 규모 라면 항상 무언가가 고장 나고 있다는 것 입니다. >> 항상 말이죠. 아시 다시피, 이 각각의 칩 들은 경이로운 기술의 결정체 입니다. 제 말 은, 제조 가능한 최첨단 기술 의 정점에 있다는 뜻 입니다. 그렇지 않나요? 그래서 다시 말하지만, 저 에게는 그것이 놀라 울 따름 입니다. 그리고 사실, 이 칩 들은 그냥 하나의 칩이 아닙니다. 이 패키지는 많은 경우 두 개, 네 개, 여덟 개, 어쩌면 그 이상의 칩렛들 로 구성 되어 함께 작동 하죠. 물론 옆 에는 HBM이 있고 네트워크 연결도 있으며, 공동 패키지 광학 같은 것들도 있을 수 있습니다. 비판 하려는 건 아니지만, 고장 날 수 있는 것들이 너무 많습니다. 그런데 이런 걸 10 만 개나 가지고 있다면, 무언가는 반드시 고장 나게 마련 이죠. 그에 대비 하고, 거의 실시간으로 감지 하며, 거의 실시간으로 복구 할 수 있어야 합니다. 그 모든 과정 을 수행 하는 것은 정말 엄청난 텔레 메 트리 문제를 해결 하는 것과 같습니다. 마치 초 단위, 분 단위는 물론 이고, 일부 작업의 경우 몇 시간, 며칠, 심지어 몇 주 동안 계속 해서 건초 더미 에서 바늘을 찾는 것과 같죠. 그저 지속적 이고 온라인 상태로 말입니다. 우리가 스스로에게 책임을 묻는 방식 은 데이터 센터에서 실제로 중요한 워크 로드에 대해 얼마나 많은 유효 처리량 (good put) 을 제공 하느냐 입니다. ' >> 유효 처리량' 은 구글 용어 인가요, 아니면 업계 용어 인가요? >> 구글 용어 이긴 하지만, 점점 더 많은 업계 사람들이 이를 사용 하기 시작 하고 있다고 생각 합니다. >> 감을 잡기 위해 묻자 면, 10만 개의 가속기 규모 라면 1 분에 한 번, 아니면 하루에 한 번꼴 로 고장이 나나요? 얼마나 자주 발생 하나요? >> 10만 개의 가속기 라, 어디 보자. 제 생각 에는 그 규모 라면 분명 하루 에도 여러 번, 아마도 정확한 구성에 따라서 는 한 시간에 여러 번 무언가 가 고장 날 겁니다. >> 그렇다면 가장 흔한 고장 원인은 무엇 인가요? >> 그게 바로 문제 입니다. 사실, 아주 좋은 질문 입니다. 만약 흔한 고장 원인이 있었다면, 우리는 이미 그걸 알아 내서 해결 했을 겁니다. 그것은 끊임없이 발견 되는 긴 꼬리 ( long tail) 와도 같습니다. 새로운 제품이 도입 될 때 마다 우리가 미처 생각지 못한 문제가 발생 하곤 하죠. 솔직히 많은 경우, 그야말로 최첨단 기술 이기 때문에 네트워크 관련 문제 일 수 있습니다. 이것들을 초고속 으로 연결 하는 방식과 관련 이 있을 수도 있죠. 하드웨어 와 관련된 문제 일 수도 있습니다. 그런 문제 들은 우리가 해결해 나갑니다. 하지만 소프트웨어 문제도 상당히 많을 수 있습니다. 그래서 이것이 우리가 스스로 에게 책임을 묻는 또 다른 측면 입니다. 다시 말해, 칩이 특정 수준의 플롭스 (flops) 성능을 낼 수는 있습니다. 하지만 컴파일러 버그, 런타임 버그, 모델 문제, 그 외 다른 운영체제 문제 등이 있으면 소용 없죠. 그것은 결국 전체 시스템 성능에 영향을 미치게 됩니다. 즉, 완벽 하고 매우 신뢰할 수 있는 하드웨어를 갖췄 더라도 , 소프트웨어 문제로 인해 피해를 볼 수 있다는 겁니다. >> 음. Nvidia 나 TPU 팀과 같은 가속기 기업 들이 제공 하는 표준 참조 스택이 있나요? 예 를 들어, 우리 가속기를 중심 으로 구축 할 수 있는 최적의 시스템은 이것 이고, 그 시스템에 맞춰 구축 하기만 하면 된다는 식의 가이드 말입니다. 아니면 반도체 기업 들이 제공 하는 것 외에 데이터 센터를 얼마나 독자적 으로 설계 해야 하는 건가요? >> 네, 맞습니다. 음, 참조 스택 은 존재 합니다. 제 생각에 Nvidia는 정말 대단한 종합 시스템 기업 입니다. 물론 반도체 기업 이긴 하지만, 단순한 반도체 기업 그 이상 이죠. 그들은 매우 강력한 참조 스택을 제공 합니다. 하지만 많은 경우, 저희가 확인한 바로는 대부분의 고객 이 그 참조 스택을 활용 하되, 다수는 자신들만의 방식으로 특화 하기도 합니다. 다시 말해, 고객 들은 각자의 특정 사용 사례에 맞는 최적화 기회 나 더 필요한 작업을 발견 할 수 있다는 의미 입니다. 그래서 그들은 그렇게 작업을 수행 하게 되죠. 마찬가지로 TPU 측에서도 저희는 참조 스택을 보유 하고 있습니다. 대부분 의 사용자가 이를 활용 하지만, 많은 이들이 이를 자신들에게 맞게 특화 하기도 합니다. >> 음. 알겠습니다. 전반적인 용량 측면에서 질문 드리면, Google이 서빙 용량을 6 개월 마다 거의 두 배로 늘려야 한다고 팀에 말씀 하셨는데, 사실 인가요? >> 음, 확실히 해두 자면, 이는 결국 서빙 관점에서 바라본 유효 가용 용량을 의미 합니다. 바로 토큰 생성 능력 입니다. 그래서 용량 이라고 하면, 저는 이것을 소프트웨어와 하드웨어의 결합 이라고 말씀 드리고 싶습니다. 하드웨어 에는 어떤 고유 한 수준의 플롭스 ( FLOPS) 가 있을 수 있습니다. 제가 여기서 말씀 드리는 것은 6 개월 마다 플롭스 수를 반드시 두 배로 늘려야 한다는 뜻은 아닙니다. 그것도 하나의 방법 이긴 하죠. 하지만 6 개월 마다 토큰을 생성 하는 하드웨어의 능력을 두 배로 키워야 한다는 것 입니다. 그리고 그 능력의 상당 부분은 하드웨어 만큼이나 소프트웨어에서 나올 것 입니다. 즉, 모델 최적화를 통해서 그런 결과를 낼 수도 있습니다. 또는 런타임 최적화를 통해서도 가능할 수 있죠. 아마도 수십, 수백 가지의 개별 최적화가 지속적으로 적용 되면서이 모든 것이 가능 해지는 것일 겁니다. 하지만 네, 용량 개선 속도는 정말 놀랍 습니다. >> 지난 몇 년간 데이터 센터를 구축해 왔고, 모델과 소프트웨어 분야 에서도 몇 년간 진전이 있었 으니까요. 와트 당 지능으로 측정 했을 때, 실리콘 자체에서 기인 한 용량 증가분과 모델, 또는 기타 소프트웨어 및 다른 주요 구성 요소에서 기인 한 용량 증가분의 경험적 분석 결과는 어떻게 되나요? >> 네, 정말 좋은 질문 입니다. 정확한 분석 수치는 없지만, 저희 경험상 와트 당 지능 측면에서의 이점은 대부분 모델 개선에서 비롯 된다고 말씀 드리고 싶습니다. 참고 로, 와트 당 지능은 정말 훌륭한 지표 입니다. 저희도 와트 당 굿풋 (good put) 을 중요 하게 여기 는데, 왜 와트가 분모가 되어야 하는지에 대해서는 나중에 다시 이야기 할 수 있을 것 같습니다. 굿풋 은 와트 당 제공 되는 지능을 측정 하는 척도가 될 수 있습니다. 다시 말해, 굿풋은 작업 부하 별로 특화된 지표 입니다. 하지만 저는 성과의 대부분은 모델 측면에서 온다고 말씀 드리고 싶습니다 . 소프트웨어 시스템도 상당히 기여 하죠. 왜 일까요? 소프트웨어는 보유한 하드웨어를 실제로 효과적으로 활용할 수 있게 해주기 때문 입니다. 그리고 하드웨어 자체도 매우 놀랍 습니다. 다시 말해, 우리는 지금 전년 대비 2 배 이상의 성능 향상이 충분히 가능한 세상에 살고 있습니다. 따라서 하드웨어가 이를 뒷받침 하며, 원한다면 일종의 무료 승수 효과를 얻을 수 있습니다. 공짜는 아니지만 요. 하지만 그 위의 모든 사람들은 그것이 매년 모두를 끌어 올리는 승수 역할을 할 것이라고 기대할 수 있습니다. >> TPU 프로그램과 공동 설계에 대해 좀 더 이야기 해보고 싶습니다. 구글은 10 년도 더 전에 자체 실리콘을 만들기 시작 했죠. 당시 로서는 반대 의견이 많은 결정 이었습니다 . TPU 프로그램은 어떻게 발전해 왔나요? >> 상당히 많이 발전 했습니다. 2013 년에 프로그램이 시작 되었을 때는 정말 주류에 반하는 결정 이었습니다. 2013 년 당시의 상황을 떠올려 보면, 그 시절 상식으로는 가장 똑똑 하고 현명한 사람들 조차 단일 작업 부하 를 위해 맞춤형 가속기를 만들지는 않을 것이라고 말했 을 겁니다. 왜냐하면 무어의 법칙이 존재 했고, 18 개월 이나 24 개월 마다 성능이 두 배로 향상 되고 있었 으니까요. 표준 프로그래밍 모델을 활용할 수 있고, C ++ 코드 나 Java, Python 등 무엇 이든 사용할 수 있으니까요. >> 칩의 씁쓸한 교훈 이군요. >> 네, 정확 합니다. 칩에 대한 씁쓸한 교훈은 전문화가 결코 성공 하지 못한다는 것이죠. 하지만이 경우 에는 특정 애플리케이션 하나 나 소수의 애플리케이션이 엄청난 혜택 을 볼 수 있었고, 이를 지원 하려면 상상할 수 없을 만큼 많은 범용 CPU가 필요 했기 때문 입니다. 2013 년 당시에는 일종의 도박 이었고, 회사 내부 에서도 성공 할지 확신 하지 못하는 사람들이 꽤 있었습니다. 도박 이었지만, 결과적으로는 엄청나게 성공적인 도박이 되었습니다. 첫 번째 칩은 오직 추론 만을 위한 것이 었 습니다. 두 번째 칩은 같은 아이디어를 활용 해 학습용 칩을 만들 수 있겠다는 생각에서 시작 되었습니다. 그 후 점점 더 많은 사용 사례에 채택 되기 시작 했습니다. 두 번째 칩이 나올 무렵, 트랜스포머가 발명 되었습니다. 이는 매우 중요한 순간 이었고, 실제로 TPU 프로그램을 완전히 바꿔 놓았 습니다. 물론 저희는 추천 시스템이 TPU에서 매우 잘 작동 한다는 것을 알게 되었고, 관련 사용 사례 들이 추가로 등장 했습니다. 변화 와 발전은 범위와 영향력이 확대 되는 과정 이었다고 말할 수 있습니다. 다시 말해, 추론 서비스를 위한 몇 가지 애플리케이션 이라는 영향력 있는 사용 사례에서 시작된 것 입니다. 처음 에는 주로 언어 번역과 음성 인식 이었고, 이후 학습, 트랜스포머, 추천 시스템으로 이어 졌으며, 생성 형 AI 시대 가 도래 하면서 더 크고 확장 성 있는 시스템으로 일반화 되었습니다. >> 트랜스포머가 등장한 순간이 중요 했다고 언급 하셨는데, TPU는 특정 아키텍처 였지만 트랜스포머 전용은 아니 었던 점이 궁금 합니다. 작업 부하 에 맞춰 칩을 어느 정도로 특화 해야 할지, 그 미묘한 균형을 어떻게 잡으시 나요? >> 정말 좋은 질문 입니다. 결국 핵심은 적용 가능성 이라고 생각 합니다. 제 말은, 특정 작업 부하에 대한 칩의 적용 범위를 의미 합니다. 즉, 저희 는 매 세대 마다이 문제를 고민해 왔습니다. 더 특화 해야 할까요? 약 2 년 혹은 그보다 조금 더 전 저희가 직면 했던 질문은, 2026 년에 칩을 하나로 할지 아니면 두 개로 할지 였습니다. 추론과 학습을 동시에 수행 하면서 둘 다 잘 해낼 수 있는 하나의 칩을 만들 수도 있고, 두 개의 칩을 만들 수도 있었습니다. 하나는 추론에 더 특화 하고, 다른 하나는 학습에 더 특화 하는 방식 이었죠. 이러한 분석과 연구를 통해 올해 두 개의 칩을 출시 하게 되었습니다. 추론을 위한 8I와 학습을 위한 8T 인데, 몇 년 전만 해도 그렇지 않았지만 2026 년이 되면 추론과 서비스 수요가 폭발 할 것이라고 판단 했기 때문 입니다. 따라서 수명 기간 동안 시장 의 30, 40, 50, 60%를 차지할 것으로 예상 되는 서비스 작업에 훨씬 더 빠른 칩을 갖추는 것이 매우 타당 하다고 판단 했습니다. 추론 시장 점유율을 2%나 5%로 예상 한다면, 설령 전용 칩이 2 배 더 빠르다 하더라도 경제성이 없을 수 있습니다. 그렇지 않나요? 완벽 하게 최적화 되지는 않았 더라도 범용 칩 을 선택 하는 편이 통일성 등 을 고려할 때 더 나 으니까요. 결국 '더 특화 할 것인가?' 라는 계산의 문제가 됩니다. 그 워크 로드가 얼마나 큰 가요? 앞으로 3 ~ 4 년 뒤에는 그 워크 로드가 얼마나 커질 것으로 예상 됩니까? 특정 워크 로드에 대한 지속적인 성장세 인가요? 아시 다시피 하드웨어 분야 에서는 특정 워크 로드에 특화 할수록 유연성은 떨어지지만, 속도는 빨라지고 전력 효율은 더 좋아지는 기회가 있습니다. 그래서 무엇을 설계 하고 그 워크 로드가 얼마나 지속될 지를 예측 하는 것이 일종의 예술 이자 기술 입니다. 다시 말해, 한두 달 이나 석 달 뒤에 사라질 워크 로드 라면 그 기간 동안 규모가 크 더라도 대응할 수 있는 시간적 여유가 매우 촉박 합니다. 따라서 어느 정도 지속 가능 해야 합니다. 또한, 그에 특화 했을 때 정확히 어떤 이득을 얻을 수 있을지 예측할 수 있어야 합니다. >> 대략 적인 트레이드 오프를 따져 보면, 새로운 프로그램 을 지원 하는 데는 큰 고정 비용이 발생 합니다. >> 맞습니다. >> 결국 해당 프로그램에 대한 수요가 비용을 정당화 할 만큼 충분할 것이라고 판단 해야 하죠. >> 정확 합니다. 어느 정도는 저희 8i와 8t 칩의 경우처럼, 두 칩 모두 서로의 워크 로드 를 처리 할 수 있습니다. 이 점도 핵심 입니다. 만약 8i가 추론만 가능 하고 학습은 전혀 할 수 없다면 어떨까요? 즉, 학습 성능이 전혀 없는 경우죠. 반대로 8t가 학습 에는 뛰어나지만 추론 성능이 제로 라면, 그것 또한 결정적인 한계가 되었을 겁니다. 왜 그럴까요? 하드웨어의 수명 인 6 년 동안 각각이 얼마나 필요 할지 미리 정확히 예측 해야 하기 때문 입니다. 이번 경우는 두 칩 모두 특화된 작업에서 더 뛰어나 면서도 상황이 좋았 습니다. 하지만 필요 하다면, 한쪽의 용량이 남을 경우 두 칩 모두 서로의 작업을 수행 할 수 있습니다. 특화 정도에 따라 너무 지나치게 특화 하면 유연성과 대체 가능성을 잃을 수도 있습니다. >> 대략 적인 트레이드 오프가 프로그램 크기와 관련이 있다고 본다면, 현대 AI 시장 의 상당 부분이 트랜스포머 기반 인 것처럼 보입니다. 그렇다면 도발적인 질문을 하나 던져 보죠. 왜 트랜스포머 아키텍처를 칩에 그냥 박아 버리지 않는 건가요? >> 네, 트랜스포머 기반 인 것은 맞지만, 그다음 단계의 질문 은 결국 트랜스포머가 벡터 및 행렬 곱셈 연산에 관한 것이라는 점 입니다. 그리고 아시 다시피 소프트 맥스처럼 기본적으로는 선형 대수 프리미티브의 범위에 속 하죠 . 저희를 비롯한 다른 기업들 도 이러한 연산 들을 하드웨어에 어느 정도 내장 하고 있습니다. 모두 트랜스포머 기반 이기는 하지만, 모델 아키텍처 라는 것은 결국 '레이어가 몇 개인가' 의 문제 입니다. 레이어를 어떤 방식으로 통과 하게 되나요? 레이어 간의 이동은 어떻게 이루어 지나요 ? 각 차원에 대해 정확히 어떤 형태의 행렬과 벡터를 적용 하나요? 단순히 트랜스포머가 아니라, 본인의 모델에 맞게 더 특화 시킬 수도 있습니다. 그것이 다음 단계의 전문화 입니다. 이미 그 부분을 고민 하고 있는 여러 기업이 있다고 생각 합니다. 그 방향 역시 매우 흥미 롭다고 생각 합니다. >> 그렇다면 현재 시점에서 고객 들이 TPU와 GPU를 거의 대체 가능한 동등한 것으로 보 나요, 아니면 각각 더 적합한 문제 세트가 따로 있나요? >> 분명히 각 장치에 더 적합한 문제 세트가 존재 합니다. 우선 GPU가 TPU 보다 더 범용 적이 라는 점이 있죠. 그건 분명한 사실 입니다. 구글과 구글 클라우드 에는 훌륭한 제품 들이 많이 있습니다. 저희는 GPU도 많이 판매 하고 있습니다. 내부적으로도 GPU를 사용 하지만, 결국은 해결 하려는 문제의 세부 사항에 따라 달라진다고 봅니다. 고객들의 워크 로드에 두 장치 간 중복 되는 부분이 있기는 하지만, 고객 들은 각자 워크 로드를 평가 하고 선택지를 고려 합니다. 구글 이 지향 하는 것은 고객에게 선택권을 주는 것 입니다. 즉, 고객의 요구에 맞는 적절한 솔루션을 갖추고, 그들의 필요를 가장 잘 충족 하는 솔루션을 제공 하고자 합니다 . >> 칩에서 네트워크, 소프트웨어 에 이르는 공동 설계 (co-design) 를 옹호 하는 이유는 무엇 인가요? 그리고 공동 설계를 반대 하는 이유는 무엇 인가요? >> 네. 공동 설계를 통해 얻을 수 있는 엄청난 최적화 기회 들이 있습니다. 따라서 만약 N -계층 스택이 있고 원하는 구성 요소를 자유롭게 선택 하고 싶다면 어떤 상황이 그려 질지 상상해 보십시오. 여러 클라우드 환경에서 실행 하거나, 다양한 하드웨어와 소프트웨어 제품을 사용 하고 있다고 가정 해 보겠습니다. 그럴 때 추상화 계층을 설계 할 수 있을 것 입니다. 기본적 으로 "나는 어떤 하드웨어 에서든 실행될 수 있다" 는 의미 겠죠. 어떤 소프트웨어 에서든 실행될 수 있고요. 어떤 네트워크 토폴로지, 그러니까 어떤 네트워크 환경 에서도 실행 가능 합니다. 문제 없죠. 제 시스템은 완전히 적응 형이 될 겁니다. 그럴 가능성이 매우 높 으니 이제 엄청난 능력을 갖추게 되는 셈 이죠. 어디로 든 이동할 수 있으니까요. 새로운 자원이 생기면 하룻밤 사이에 바로 가동 할 수 있습니다. 어떤 환경 이든 활용할 수 있도록 시스템을 설계 했기 때문이죠. 특정인 의 인프라에 맞춰 하드 코딩 하거나 특화 하지 않았 으니까요. 단점 이라면 아마 성능 측면에서 많은 부분을 포기 해야 할 겁니다. 완벽 하게 대체 가능 하고, 누구의 하드웨어, 소프트웨어, 네트워크, 스토리지, 컴퓨팅 스택 등 무엇 이든 유연 하게 대응 한다면 말이죠. 그래서 공동 설계가 필요한 겁니다. 각 계층 사이 에는 완전한 범용성을 추구 할 경우 큰 임피던스 불일치가 발생 하거든요. 각 계층에서 10%, 20% , 또는 2 배 정도의 차이가 날 수 있는데, 이런 최적화 기회 를 곱해 나가다 보면 결국 전력 대비 지능 이나 전력 대비 처리량 등 엄청난 엔드 투 엔드 기회를 활용할 수 있게 됩니다. 전력 공급 이나 전력 가용성 소프트웨어 최적화까지 모든 면에서 말이죠. 그래서 장점은 언제 어디 서든 실행 가능 하고 종속 되지 않는다는 점 입니다. 단점은 상당한, 아니 아마도 매우 큰 성능 차이를 포기 해야 한다는 것 입니다. >> 음. 제가 이해 하기로 오픈 AI 는 주로 단일 컴퓨팅 스택 기반으로 구축 했고, 앤 스로 픽은 더 이기종 적인 컴퓨팅 스택으로 구축 한 것으로 압니다. 공동 설계가 그들이 매우 다르다고 알려진 모델 아키텍처로 수렴 하게 된 이유 중 하나 라고 생각 하시나요? >> 음, 추측 하기 어렵 네요. 오픈 AI와 앤 스로 픽이 무엇 을 하는지에 대해 추측 하고 싶지는 않습니다. 그저 하나 의 가능성 일 뿐이죠. 그들이 구체적으로 무엇을 하는지 알지 못하는 상태에서, 그들이 왜 다른 아키텍처를 선택 하게 되었는지에 대한 이유는 매우 많을 것이라고 생각 합니다. >> 그렇다면 구글의 경우는 어떤가요? 구글 팀과 딥 마인드 사이의 협업 관계가 어떤지 궁금 합니다. 모델 개발 단계별로 누가 참여 하고, 공동 설계에 관한 의사 결정을 어떻게 함께 내리시는 지 궁금 합니다. >> 구글에서 일하는 것 중 가장 즐겁고 솔직히 보람찬 부분은 , 하드웨어와 모델의 공동 설계를 위해 딥 마인드 팀과 정말 어깨를 나란히 하고 일할 기회가 있다는 점 입니다. 소비자 서비스와 클라우드를 통해 이를 확장 할 수 있다는 측면에서 세 번째 요소가 존재 합니다. 잠시 제쳐두고 나중에 다시 이야기 하겠지만, 딥 마인드 ( DeepMind) 와의 관계는 정말 깊은 파트너십 입니다. 과거 의 예를 들자면 그들이 모델 최적화 방안을 내놓은 적이 있습니다. 예를 들어, 트랜스포머 나 특정 연산에 대해 그들이 원하는 작업이 있는데, 저희는 아직 미완성 인 칩을 개발 중인 상황 이었죠. 그때 그들이 "맙소사, 여기에 대한 하드웨어 지원이 있다면 어떨까?" 라고 말합니다. 우리의 엔드 투 엔드 학습 이나 서빙 속도가 훨씬 빨라지고 효율적일 수 있을 텐데 말이죠. 하드웨어 설계를 실제로 변경 하려면 무엇이 필요 할까요? 이제 수용 하기 위한 실행 단계에 들어갈 수도 있습니다. 그러면 우리 엔지니어들과 연구원 들이 며칠, 일주일, 혹은 2 주일 동안 한방에 모여 집중적으로 논의 합니다. " 좋아요, 이건 할 수 있습니다. " 라고요. "원하시는 걸 그대로 구현 하기는 어려울 것 같습니다.""하지만 다른 방식은 가능 합니다.""그럼 모델 아키텍처를이 방향으로 조금 바꾸면 우리가 원하던 것의 90%정도는 달성 할 수 있지 않을까요?" 네, 그러면 다시 돌아가서 하드웨어를 조정할 수 있습니다. 아니면 이렇게 말할 수도 있죠. " 있잖아요?""테이프 아웃 (설계 완료 후 제조) 을 일주일 미루 겠습니다.""아니면 2 주라 도요. 왜냐하면 이런 수준의 이점 이라면 충분히 그럴 가치가 있으니까요." 네, 마찬가지로 우리가 로드맵을 계획 할 때도 어느 시점 에나 여러 세대의 칩이 동시에 개발 중 입니다. 생산 중인 칩 들이 있습니다. 그게 첫 번째 죠. 생산을 위해 작업 중인 칩들도 있습니다. 이미 제조사에서 돌아 왔고, 우리 는 그것들을 디버깅 하며 작동 하게 만들고 있습니다. 구현 단계에 있어 곧 테이프 아웃 되어 제조사로 넘어갈 칩들도 있습니다. 설계 단계 에 있는 칩들도 있죠. 그리고 개념 단계에 있는 칩들도 있습니다. 생산부터 구상까지 5 ~ 6 단계에 걸친 수년에 걸친 파이프 라인 인 셈 인데, 생산 중인 칩에 대한 딥 마인드와 의 협업은 매우 중요 합니다. 함께 협력 하여 전력 대비 제공 되는 인텔리전스 나 처리 성능을 극대화 할 수 있기 때문 입니다. 우리는 모델 내에서 무슨 일이 일어나는지, 하드웨어에서 무슨 일이 일어나는지, 그리고 그 사이의 모든 과정 을 정확히 알고 있습니다. 또한 막 테이프 아웃을 앞둔 칩들에 대해서도 깊이 있게 협업 합니다. 왜 냐고요? 왜냐하면 우리가 개입 할 수 있으니까요. 우리는 칩, 말 그대로 칩 아키텍처를 진행 중에 변경할 수 있는데, 이는 타 회사와 협력 했다면 어렵 거나 불가능 했을 일 입니다. 불가능한 건 아니지만, 훨씬 더 힘들었 겠죠, 그렇죠? " 세상에, 이 칩 완성까지 몇 주나 몇 달 밖에 안 남았 는데 , 지금 당장 같은 방에 모여 앉아 프로그램을 뒤엎을 지 결정 하자" 고 말하는 건 말입니다. "가능은 하겠지만, 훨씬 힘들었을 거라고 봅니다 ." 물론 설계 중인 칩의 경우, 우리가 함께 평가할 수 있는 아키텍처가 아주 많습니다. 우리는 딥 마인드의 동료들 에게 물어볼 수 있죠. "모델 아키텍처가 어디로 향하고 있다고 보 나요?""2 ~ 3 년 후에 는 말이죠." 우리가 할 수 있는 일들에 대한 파레토 최적화가 여기 있습니다. 모델 아키텍처가 나아갈 방향 에 대한 파레토 최적화도 여기 있고요. 우리는 워크 로드가 다양한 하드웨어 아키텍처에 어떻게 매핑 될지 예측할 수 있는 깊이 있고 상당한 수준의 시뮬레이션 인프라를 갖추고 있습니다. 깊이 있고 빠른 반복 작업 이죠. 팀 들이 서로 분리 되어 작업 하는 것이 결코 아닙니다. 같은 건물, 같은 공간에서 함께 작업 하는 경우가 아주 많습니다. 깊이 있는 일상적 상호 작용 이죠. 저는 코레 이나 데미스와 일주일에 몇 번씩 대화 합니다. 그래서이 일의 정말 즐거운 측면 이죠. >> 정말 멋지네요. 결국 그들의 모델은 칩 설계 에도 도움을 줄 것 입니다. >> 우리는 미래의 제미 나이를 위한 하드웨어를 설계 하는 데 에도 제미 나이를 사용 하고 있습니다. >> 정말 굉장 하네요. 그 부분은 잠시 후에 다시 이야기 해 보고 싶습니다. 협력 자체에 관해서 인데, 하드웨어를 다룰 때가 딥 마인드 팀이 소프트웨어 측면에서 다루는 것 보다 주기 시간이 훨씬 느려서 생기는 임피던스 불일치가 여전히 있지 않나요 ? 그리고 계획 주기 역시 훨씬 앞서 있을 것 같고요. >> 물론 입니다. >> 그렇다면 실제로 조정할 여지 는 얼마나 되나요? >> 네, 정말 좋은 질문 입니다. 우리는 2, 3, 4, 5 년 앞을 내다 보고 하드웨어를 계획 하고 있습니다. 의심 할 여지가 없죠. 즉, 방금 발표 한 TPU v8 과 AT에 대해 이야기 했지만, 9 , 10 버전과 다른 몇몇 제품 들이 개념 단계에서 실행 단계 등으로 넘어 가고 있다고 상상 하시면 됩니다. 그것들은 몇 년 뒤의 일일 수도 있죠. 만약 모델 아키텍처 작업을 한다면, 기본적으로 수년 후를 생각 하며 일 하지는 않을 테니까요. >> 네. >> 하지만 저는 이것 이야말로 우리 회사가 함께 성장해 온 방식의 위대한 점 이라고 생각 합니다. 다시 말해, 구글 리서치와 딥 마인드, 그리고 트랜스포머의 발명까지, 이 모든 것이 서로 겹치는 공간 안에서 일어나고 있었습니다. 즉, 하드웨어에 영향을 줄 수 있다는 점에 익숙해 진 연구원 들의 세대가 전체적으로 형성된 것이죠. 그리고 하드웨어가 수년에 걸친 주기로 운영 된다는 사실도 알고 있습니다. 또한 그들은 출시를 앞둔 칩에 1%나 0.5%정도의 작은 개선을 가져올 변경 사항이 있다면, 굳이 우리를 찾아 오지 않을 것이라는 점도 알고 있습니다 . 왜냐하면 그들은 소프트웨어처럼 단순히 변경 목록을 작성 해서 2 주 안에 제품으로 배포 할 수 있는 것이 아니라는 사실을 충분히 알고 있기 때문 입니다. 테이프 아웃 (설계 완료 및 제작) 을 중단 하는 것은 실제로 큰일 이니까요. 하지만 그들은 정말 좋은 기회가 있다면, 우리가 함께 협력 해서 그것을 반영 할 방법을 찾을 것임을 잘 알고 있습니다. 그래서 말씀 드렸듯이, 혜택이 오는 측면 에서 이는 곱셈과 같은 효과 를 냅니다. 하드웨어는 모든 조류를 끌어 올리는 역할을 하니까요, 그렇죠? 딥 마인드 팀의 상당 부분이 그렇고, 우리는 그 점에 정말 감사 합니다. 정말 놀라운 팀 이죠. 하지만 그 팀의 상당수는 어떻게 로드맵에 영향을 줄 수 있을지를 고민 하고 있습니다. 왜냐하면 그것은 실제로 파이프 라인 이기 때문 입니다. 2 년 전에 냈던 아이디어가 지금 실제로 운영 되고 있는 식 이죠. 그리고 그것이 구글의 모든 워크 로드를 더 빠르게 처리 하도록 돕고 있습니다. 그건 정말 기분 좋은 일 이죠. >> 전적으로 동의 합니다. 하지만 5 년 후에 어떤 워크 로드가 가장 일반적 일지, 어떤 알고리즘 혁신이 일어날 지 예측 하는 것은 불가능한 일처럼 보입니다. 어, 불가능한 과제처럼 보이지 않나요? >> 불가능한 과제처럼 보인다는 말씀은 이해 합니다만, 아주 놀라운 사실이 하나 있습니다 . 사실 저희는이 내용을 아주 자세하게 작성 하는 작업을 진행 중이고, 그 과정이 매우 즐겁 습니다. 놀라운 점은 TPU 아키텍처가 아주 세밀한 수준 은 아니더라도 중간 정도의 세부 수준에서 볼 때 TPU V1 이후로 크게 변하지 않았다는 것 입니다. CPU의 명령어 집합 아키텍처를 생각 하면 이해 하기 쉽습니다. 로드, 스토어, 덧셈, 뺄셈, 분기 명령 등이 있는데, 그 오랜 기간 동안 그 위에서 구동 되는 소프트웨어 는 무엇을 해왔 을까요? TPU도 마찬가지 입니다. 저희 에게는 몇 가지 기본적인 명령어와 필수적인 프리미티브가 있습니다. 물론 , 그동안 확장 해 오긴 했습니다. 명령어 집합이 전혀 변하지 않았다는 뜻은 아닙니다. 하지만 수치 연산 을 초대형 행렬 곱셈 장치에 특화 시키는 기본 요소들, 음, 벡터 연산과 스 캐터-개더 연산을 관리 하는 스파 스 코어 등, 원격 로드-스토어를 정의 하는 5 ~ 6 가지 핵심 요소가 있습니다. 그것도 하나 죠. 사실 우리는 ICI 네트워크를 통해 원격 메모리 를 읽고 쓸 수 있습니다. 기본 원리는 이미 존재 했고, 이를 여러 세대의 모델과 수많은 세대의 심층 신경망 알고리즘 및 모델 구조 에까지 확장 해 왔습니다. >> 좋습니다. 워크 로드 변화에 대해 이야기 하자면, 지난 1 년 정도, 제 생각 엔 올해 초 부터 시작된 가장 큰 변화 중 하나는 장기 호라이즌 에이전트의 부상 인 것 같습니다. >> 네. >> 그리고 그것은 과거의 빠른 LLM 대화와는 다른 형태의 워크 로드 라고 생각 합니다. 음, 데이터 센터의 요구 사항 측면 에서는 어떤 의미 인가요? >> 네, 저는 이것에 두 가지 거대한 측면이 있다고 생각 합니다. 하나는 더 이상 인간 과, 뭐라 부르든, 가속기 간의 상호 작용이 아니라는 점 입니다. 다시 말해, 웹 브라우저 나 휴대폰 등에서 프롬프트를 입력 할 때, 물론 프롬프트에 대한 응답으로 많은 작업이 발생 하게 됩니다. 하지만 응답이 돌아 오면, 그것을 읽어야 하죠. 생각을 해야 하고, 아마 후속 질문이 생길 수도 있습니다. 그렇게 되면 상호 작용 시간 은 수 초가 걸릴 것 입니다. 이제 장기 호라이즌 에이전트 의 경우, 모델로 요청이 얼마나 빨리 전송 될지 자연스럽게 속도 제한을 걸 인간 루프가 존재 하지 않습니다. 그래서 상호 작용 시간이 수 초에서 수십 초 였던 것이 이제 밀리 초 단위 로 넘어 가게 되는 것이죠. 응답을 받는 즉시 구문 분석 을 하고, 어느 정도 추론을 한 다음, 다음 요청이 무엇이 될지 파악할 수 있습니다. 그게 첫 번째 큰 변화 입니다. 두 번째 큰 변화는 그 모든 추론과 구문 분석이 아마도 CPU에서 일어날 것이라는 점 입니다. 그리고 그 CPU는 아마도 모델에 다음 프롬프트 를 보내기 전에 어떤 다른 상태를 수집 해야 할지 고민 해야 할 것 입니다. 즉, 저는 이 응답을 통해 무언가를 배웠다는 뜻 이죠. 다음 단계 를 진행할 텐데, 이때 로컬 DRAM 이나 다른 CPU의 DRAM, 혹은 SSD 나 HDD 등 어딘가에서 컨텍스트를 가져와야 할 필요 가 있습니다. 이제는 엄청난 규모의 오케스트레이션도 이루어져야 합니다. 설계 방식이 상당히 크게 변하고 있는데, 가속기 컴퓨팅에 대한 수요는 증가 하는 반면 CPU, 네트워킹, 스토리지, 즉 기존 데이터 센터 CPU 등에 대한 수요도 폭발적으로 늘고 있습니다. >> 그렇다면 GPU 랙 옆에 CPU를 더 많이 배치 한다는 뜻 인가요? >> 네, GPU 나 TPU 랙의 경우가 그렇습니다. 이것이 최적화와 전문화 라는 문제로 돌아가는 핵심 질문 입니다. CPU 랙을 GPU 나 TPU 옆에 많이 배치 하기 시작 하면, CPU 랙과 비교 했을 때 TPU 랙이 요구 하는 밀도와 네트워크 요건에 완전히 특화 할 수 없게 된다는 뜻 입니다. TPU 랙은 CPU 랙 보다 더 높은 밀도를 가질 것 입니다. 아마도 CPU 랙 보다 더 많은 네트워킹이 필요할 것 입니다 . 즉, 이제는 건물 설계 방식 이 바뀌어야 한다는 것 입니다. 또 다른 선택 지는 통일성을 유지 하면서 TPU 나 GPU는 한 건물에 몰아 넣고, CPU 는 옆 건물에 두는 방식 입니다. 그리고 하드 드라이브는 또 다른 요구 사항이 있으니 반대편 건물에 배치 해야 할 수도 있습니다. 이제는 건물들 사이에 상당한 수준의 네트워킹이 필요 하게 됩니다. 건물을 벗어나 면 네트워킹 복잡성이 상당히 증가 합니다. 신뢰성 측면 이나 비용 측면에서 지연 시간이 늘어 납니다. 수용 가능한 수준 일 수도 있겠지만, 구성 요소 간의 대기열로 인해 지연 시간이 수백 마이크로 초, 혹은 그 이상으로 늘어날 수도 있습니다. 고려해야 할 사항 들이 매우 흥미로운 방식으로 바뀌는 것이죠. >> 음, 그렇군요. 일이 힘드시 겠어요. >> 재미 있습니다. >> 재미 있어요. >> 네. >> 네트워킹 측면 에서는 어떤 일이 벌어 지고 있나요? 구글 은 광학 기술을 포함한 최신 네트워킹 분야에서 항상 앞서 나갔다고 들었 습니다. 광 네트워킹의 현주소에 대해 한 말씀 해주실 수 있나요? >> 저희 구글은 15, 16 년 전쯤에 데이터 센터 내의 단일 광섬유에 여러 신호를 실을 수 있는 파장 분할 다중화 기술을 도입 한 최초의 기업 중 하나 였습니다. 실제로 저희는 랙 간의 모든 통신에 그 기술을 활용 하고 있습니다. 동시에 파장 분할 다중화와 함께 광 회선 교환 이라는 기술도 도입 했습니다 . 광 회선 교환은 기존의 전기 패킷 교환 방식과 달리 데이터를 전적으로 광 영역 에서 전송 하고 이동 시키는 기술 입니다. 이 기술의 대단한 점을 설명해 드리 자면, 패킷 스위치 에서는 패킷을 받으면 헤더를 전기적 도메인에서 확인 하여 패킷이 어디로 향하는 지 파악 합니다. 헤더 에는 "이 패킷을 어디로 보내야 하지?" 라는 정보를 담은 IP 주소가 있을 수 있습니다. 그러면 테이블 에서 해당 목적지를 조회 하여 어떤 포트로 전송 할지 결정 합니다. 즉, 초당 수십억 , 수백억, 어쩌면 수조 개의 패킷이 엄청난 속도로 들어 오면 이를 계속 전달 하는 것이죠. 광 회로 스위칭은 " 전기적 도메인 에서는이 비트 들을 건드리지 않겠다" 고 말합니다. 대신 입력 포트에 대해 빛을 보낼 출력 포트가 어디 인지 파악 하는 방식을 취 합니다. 아 시겠 나요? 이를 수행 하는 방법 에는 여러 가지가 있습니다. 우리 가 처음 시작한 방식은 MEMS 스위치 라고 하는데, 미세 전기 모터가 3D 공간에서 거울 을 제어 하는 방식 입니다. 그래서 이제 128 개나 256 개 포트 등을 가진 장치를 프로그래밍 방식으로 제어 할 수 있게 되었습니다. 들어오는 광섬유의 모든 입력 포트를 출력 포트에 매핑 하고, 빛이 거울에 비쳐 올바른 출력 포트로 반사 되도록 거울의 각도를 조절 하는 것이죠. 처음에 우리가 이 작업을 수행 한 이유는 두 가지로, 랙 그룹 간의 지역성 을 생성 하기 위해서 였습니다. 예를 들어 컴퓨팅 클러스터와 스토리지 클러스터가 있고, 둘 다 검색 서비스를 지원 한다고 가정 해 봅시다. 두 클러스터가 서로 통신을 많이 할 것을 알았 기에, 거울을 구성 하여 두 클러스터 사이에 순수 하게 광학적 인 지름길을 만들었 습니다. 랙 클러스터 들 말이죠. 이것이 첫 번째 이유 였습니다. 두 번째 이유 는 광섬유를 실제로 옮기지 않고도 네트워크를 확장 하거나 축소 할 수 있기를 원했기 때문 입니다. 세부 사항을 다 설명 하진 않겠지 만, 칠판에 그려 본다면 광 회로 스위치를 사용 하면 사람이 직접 개입 할 필요 없이 컨트롤러가 네트워크의 스파인 구조를 재구성 하여 네트워크를 확장 하거나 축소 할 수 있습니다. 이제 TPU로 넘어가 보죠. TPU는 토러스 토폴로지를 가지고 있어 모든 TPU를 서로 직접 연결 합니다. 앞서 처리량 (throughput) 과 유효 처리량 (goodput) 에 대해 이야기 했었죠. 우리가 할 수 있는 것 중 하나는 TPU 랙에 장애가 발생 하면 광섬유를 옮기지 않고도 다른 TPU 랙 으로 대체 할 수 있다는 점 입니다. 다시 말씀 드리지만, 손짓으로 설명 하거나 화이트 보드에 그려야 하겠지만, 기본적으로 항상 여분의 랙이 준비 되어 있다고 말할 수 있습니다. 그래서 랙에 장애가 발생 하면 빛을 그 새로운 랙으로 다시 보냅니다 . 그 작업은 밀리 초 단위로 이루어질 수 있습니다. >> 그렇다면 왜 굳이 광섬유를 사용 하나요? >> 완전한 자유 공간 통신이 아닌 상태에서 말이죠. 네, 아주 좋은 질문 입니다. 음, 감쇠 손실 문제로 대역폭이 급격히 떨어질 것 입니다. 게다가 매우 큰 건물 전체 에서 3 차원으로 연결해 주는 광섬유의 이점 없이 모든 것을 조준 한다는 것은 거의 불가능에 가까울 정도로 어려운 일 입니다. 음, 저희도 그 부분에 대해 논의 해 봤습니다. 사실 그에 관해 아주 흥미로운 논의 들이 오 갔습니다. 하지만 네, 대부분 은 광섬유를 통하지만, 광 회로 스위치에 도달 하면 본질적으로 빛이 말 그대로 작은 칩 위로 쏟아 지게 됩니다. 그래서 그게 하나의 큰 방향 인데, 음, 사실 그 외에도 아주 많습니다. 제 생각 에는 데이터 센터에서 네트워킹의 성능과 필요성이 폭발적으로 증가 하고 있다고 봅니다. >> 정말 멋지네요. 그것 만으로도 대화를 한참 이어갈 수 있겠 어요. >> 네, 정말 멋진 일 이죠. >> 이더 볼 (eth ball) 사진으로 돌아가서 보면, 수많은 케이블 들이 제 눈을 사로 잡더군요. >> 정확 합니다. 네, 그리고 그 케이블 중 일부는 결국 저희 데이터 센터의 광 회로 스위치로 연결 됩니다. >> 이해가 됩니다. 좋습니다, 이제 전력에 관한 이야기로 넘어가 보죠. 와트 당 굿풋 ( good put) 이나 와트 당 다른 단위들에 대해 계속 말씀 하셨 잖아요. 그걸 들으니 ' 와트 당' 이라는 표현이 전력 이 어떤 면에서 제약 사항 이거나 부족한 자원, 혹은 비용이 많이 드는 문제 라는 생각이 드네요. >> 네, 그래서 종종 "저희가 직면 한 가장 큰 제약 사항은 무엇 인가요?" 라는 질문을 받곤 합니다. 그런데 사실 우리가 직면 한 가장 큰 제약은 하나로 정의 할 수 없습니다. 모두가 제약 조건 이니까요. 전부 정말 어려운 문제들 입니다. 음, 그것들은 계속 해서 변하기도 하죠. 하지만 근본적으로 답 해야 한다면, 전력이 우리가 직면 한 가장 근본적인 제약 이라고 말씀 드리고 싶습니다. 다른 것들은 해결 방법을 알고 있고, 단지 시간을 두고 해결 해야 할 문제처럼 보이 거든요. 전력 이라, 네, 말씀 하신 방식이 참 좋네요. 그건 장기적으로 구속력을 갖는 문제 이고, 저희가 아직...뭐, 핵 발전 같은 것도 있긴 하지만요. 어쩌면 원자력이 풍부한 청정 에너지를 제공 해서 많은 문제를 확실히 해결해 줄지도 모르죠. 언제 그런 일이 일어날 지, 그리고 언제 대규모로 가능할 지는 여전히 미지수 입니다. >> 그렇다면 실제로는 어떻게 운영 되나요? 새로운 데이터 센터를 구축 한다고 가정 해 봅시다. 1 기가 와트의 전력이 필요 합니다. PG&E에 전화 해서 "저기, 1 기가 와트의 전력을 좀 보내 주세요" 라고 말할 수 는 없을 것 같은데요. 전력 공급은 실제로 어떻게 이루어 지나요? 직접 터빈을 돌리는 방식처럼 수직 계열화를 해야 하나요, 아니면 전력 부족 문제를 어떻게 해결 하시나요 ? >> 네, 정말 중요 하고도 큰 질문 입니다. 구글이 선호 하는 모델은 항상 유틸리티 업체에 연결 하는 방식, 즉 전력망에 연결 하는 것 입니다. 그러니까 전력 회사에 전화 하는 것과 같은 셈 이죠. >> 아, 그러니까 PG&E에 그냥 전화 할 수는 없다는 말씀 이시군요? >> 정확 합니다. 데이터 센터가 위치한 지역의 전력 회사에 아주 정중 하게 연락을 취하는 거죠. 물론 수년 전에 미리 통보 해야 합니다. 즉, 1 기가 와트 규모 라면 "당장 내일 1 기가 와트가 필요 해요 . 언제부터 요금을 청구 할 수 있나요?" 라고 말할 수 있는 성격의 것이 아닙니다. 함께 계획을 세워야 하는 일 이죠. 저희는 전력 회사와 협력 할 때 인프라 구축 비용을 저희 가 부담 하는 문제를 매우 중요 하게 생각 합니다. 이 주제 만으로도 긴 대화가 필요할 텐데, 비용 지불 방식 때문에 자칫 하면 저희를 위해 용량을 증설 하는 과정 에서 다른 사람들의 전기 요금이 인상 될 수도 있기 때문 입니다. 이론적으로 저희는 송전선 신설 및 업그레이드, 추가 변전소 건설 등에 드는 비용도 저희 가 부담 하도록 보장 합니다. 그래서 아주 긴 계획 과정이 필요 합니다. 예를 들어 저희 가 2028 년에 1 기가 와트가 필요 하다고 가정 해 봅시다. 그런데 전력 회사는 2029 년 에야 1 기가 와트를 공급할 수 있다고 할 수 있죠. 2028 년 에는 700 메가 와트만 가능할 수도 있습니다. 그럼 이제 나머지 300 메가 와트를 어떻게 해결할 것인가 하는 문제가 남게 됩니다. 글쎄요, 한 가지 답은 그냥 기다리는 것 입니다. 또 다른 대안은 " 좋습니다, 그렇다면 그 전력 의 일부를 우리가 직접 생산할 방법은 없을까?" 라고 생각 하는 것 입니다. 어쩌면 태양 광 전지판을 활용할 수도 있겠죠. 또는 백업용 배터리 등을 사용 하거나, 다른 에너지 원을 활용할 수도 있을 겁니다. 그렇게 되면 우리는 다시 전력 회사 와 협력 하게 됩니다. 또한 지역 내에서 자체적으로 전력 을 생산 하면서, 전력 회사가 기가 와트 규모로 완전히 가동 될 때 조차 우리가 전력 을 다시 그리드에 공급할 수 있는 역량을 유지 하는 조합 도 가능 합니다. 그들이 필요 로 할 때 그 전력을 공급할 수 있게 되는 것이죠, 맞나요? 다시 말해, 일 년 중 가장 더운 2 주처럼 주거용 전력 수요가 폭증 하는 시기가 있을 수 있습니다. 우리가 자체 생산 한 전력이 있다면, 그때 그리드에 다시 공급할 수 있는 것 입니다. 결국 우리 에게는 전력 회사들과 수년간 협력 하는 과정이 꼭 필요 합니다. >> 왜 전력 회사들과 협력 하는 것을 선호 하시나요? 자체적 으로 수직 계열화를 구축 하는 대신 말이죠. >> 네, 주된 이유는 양쪽 모두 에게 유연성과 이점이 있기 때문 입니다. 한 가지 관점은 '통계적 다중화' 또는 '대수의 법칙' 이라고 볼 수 있습니다. 만약 우리가 1 기가 와트의 전력이 필요 하고, 이를 99.99% 이상의 신뢰도로 확보 하고 싶다고 가정 해 봅시다. 아마도 2 기가 와트 규모의 전력 설비를 구축 해야 할 것 입니다. 그렇지 않나요? 99.99% 나 99.999%수준의 안정성을 위해서는 1 + 1 중복성이 필요 합니다. 그건 비용이 많이 드는 일 이죠. 게다가 이상적인 친환경 에너지 원을 데이터 센터 바로 옆에 확보 하는 것도 어려운 과제 일 수 있습니다. 이제 데이터 센터 와 파트너십을 맺는 다면, 우리가 직접 생산 한 전력 중 일부를 그리드에 덜 필요한 시기에 제공 하고, 필요할 때는 전력을 가져올 수도 있습니다. 즉, 더 큰 기반에서 통계적 다중화를 활용 함으로써 결과적으로 모두가 윈윈 하게 되는 것 입니다. 우리도 이득을 보고, 그리드 도 이득을 보며, 주거 시설도 혜택을 받는 등 모두가 좋아지는 것이죠. 우리는 그런 방식을 선호 합니다. 물론 아주 드문 경우에 ' 비하인드 더 미터 (behind the meter)' 방식으로 진행할 수도 있지만, 그때도 1 년 뒤에는 전력 회사와 협력 할 것이라는 전제 하에 움직 입니다. 우리는 항상 그리드 와 연결 되기를 원 하니까요. 그건 다시 말해 우리 에게도 도움이 되고, 전력망 에도 도움이 되는 일 입니다. >> 일리가 있네요. 데이터 센터 규모는 어떻게 결정 하시나요 ? >> 그건 일종의 예술 이자 상당한 논쟁의 여지가 있는 부분 이죠. 글쎄요, 10 년, 15 년 전쯤 구글 내부에서 큰 논쟁이 있었습니다. 모든 것을 하나의 데이터 센터에 몰아 넣어야 할까? 당시에는 1 기가 와트 규모를 생각 했었죠. 그게 >> 단순 했던 시절 이었죠. >> 네, 지금과는 다른 시대 였죠. 10 ~ 15 년 전에는 1 기가 와트 급 데이터 센터를 만들 려고 했으니까요. 가장 분명한 우려는 단일 장애 지점 (single point of failure) 문제 였겠죠. 맞습니다. 30 년 이라는 장기적인 관점에서 보면 큰 문제 였죠. 반면에 오늘날의 학습 워크 로드를 생각 하면 클수록 더 좋습니다. 맞아요. 네트워킹 관점 에서는 가능한 한 작은 거리에 집중 시키는 게 유리 하니까요. 하지만 다시 말해, 단일 장애 지점 문제와 이제는 전력 확보 문제 라는 두 가지 이슈가 있죠. 10 ~ 15 년 전에는 1 기가 와트가 엄청나게 컸지만 상상 은 가능 했죠. 하지만 지금 구글의 전체 요구 사항을 한곳에 다 수용 하는 건 국내 어디 서든, 전 세계 어디 서든 불가능 합니다. 결코 가능한 일이 아니죠. 그렇다면 지금 최적의 규모는 어느 정도 일까요? 이를 위한 모델과 시뮬레이터 등이 있습니다. 하지만 상황에 따라 다르죠. 어떤 곳은 네트워크 가장자리 에 위치 하거나 수십 메가 와트 규모의 국가 일 수도 있습니다. 실제로 이라크 같은 곳의 ISP와 협력 하기도 하죠. 말 그대로 이라크가 될 수도 있는 겁니다. 여기는 학습용 클러스터 이고요. 그럼 아마 1 기가 와트에 더 가까워 지겠죠. 다른 부지 들은 수백 메가 와트 규모가 될 수도 있고요. >> 흥미 롭 네요. 포트폴리오 수명 주기 관리는 어떻게 생각 하시는지 궁금 합니다. 제 생각 에는 가장 크고 최신 인 클러스터는 최신 프런티어 모델을 학습 하는 데 사용될 것 같은데요. 그러고 나서 나머지는 재활용 해서 추론을 실행 하는 방식 인가요? 그게 타당한 프레임 워크 인가요? 아니면 추론 전용 클러스터를 따로 구축 하기도 하시나요? 전체적으로 어떻게 운영 되나요? >> 아주 타당한 프레임 워크 라고 생각 합니다. 충분히 일리가 있는 말씀 이시네요. 하지만 추론에 대한 수요 때문에 단순히 예전 학습 클러스터가 더 이상 학습에 충분히 사용 되지 않는다는 이유 만으로 그것을 추론의 기반으로 삼을 수는 없습니다 . 또한 생각해 보면, 특정 해 에는 학습 클러스터를 소수의 대규모 사이트로 다시 중앙 집중화 할 수도 있습니다. 그리고 그 사이의 네트워크 거리를 짧게 유지 하는 데 따르는 이점도 있죠. 따라서 그들이 세계 어디에 있든 아마도 같은 대륙에 위치 하게 될 것 입니다. 심지어 특정 연도 에는 같은 대륙의 같은 지역에 있을 수도 있습니다. 그렇게 되면 다른 대륙 에는 서비스 용량이 충분 하지 않게 될 수 있습니다. 기타 등등 이죠. 그래서 결국 에는 전 세계 다른 곳에 전문화 된 추론 시설을 구축 해야 합니다. 그러니까, 제 생각에 당신의 직관은 정확 하지만, 전적으로 그렇지는 않습니다. 다시 말해, 여기는 학습 클러스터 라고 확실히 정해 두어야 합니다. 네, 아마도 몇 년 후에는 서비스 용으로 사용될 수도 있겠죠. 하지만 우리는 서비스 클러스터도 별도로 구축 해야만 합니다. >> 그렇다면 서비스 클러스터는 학습 클러스터와 다른 가요? 더 규모가 작은 가요? 메가 와트 당 비용이 더 저렴한 가요? >> 사실 반드시 더 저렴한 것은 아닙니다. 왜냐하면 서비스의 경우 컴퓨팅, 네트워킹, 스토리지를 함께 배치 해야 할 필요성이 더 크기 때문 입니다. 그 지점에서 우리는 전문화 할 수 없는 상황에 직면 하게 됩니다. 학습의 경우 대규모 밀집도와 균일 한 배포 등이 이루어 지지만, 서비스의 경우 스토리지, 컴퓨팅, 가속기를 적절히 조합 해야 합니다. 게다가이 부분은 더 자세히 다룰 수 있는 아주 흥미로운 측면 인데, 서비스 측면 에서는 한곳에 너무 많은 것을 집중 시키고 싶어 하지 않죠. 전 세계 곳곳에서 워크 로드를 처리 하고 싶어 할 겁니다. 하지만 결국 우리는 개별 모델 엔드 포인트를 가지게 되고, 실제로 모델의 변형이 생길 수도 있습니다. 그래서 이제 우리는 지역적 특성까지 고려 하여이 모델 들을 전 세계로 분산 시켜야 합니다. 따라서 규모는 더 작아 질 것 입니다. 아마도 추론 측면 에서는 수직적 통합 수준이 더 낮을 것 입니다. >> 정말 흥미 롭 네요. 그럼 5 년 전에 데이터 센터를 만들었 다면, 5 년 전의 최첨단 가속기는 지금과 많이 달랐을 텐데요. >> 음, 맞습니다. >> 오늘날 만들어 지는 것들 보다 훨씬 효율이 떨어지죠. >> 네, 맞습니다. >> 그럼 실제로 예전 데이터 센터로 돌아가서 칩을 교체 하기도 하나요? 칩의 실제 유용한 수명이 어느 정도 인가에 대한 논쟁이 계속 되고 있다는 점과 관련이 있다고 생각 합니다. >> 네. 네, 제가 예전에 했던 말인데, 예상 보다 반응이 커서 놀랐 습니다. 저희가 7 년 된 TPU를 여전히 100%활용 하고 있다고 말 했었죠. >> 와. >> 어, 그리고 >> 저도 봤습니다. 이게 그렇게 중요한 의미가 있는 줄은 몰랐 거든요. >> 네, 그냥 한 말이 었는데 듣는 사람들 에게는 꽤 의미심장 하게 받아 들여진 모양 이더군요. 네, 구형 GPU도 있지만, 저희 구형 TPU 들의 활용도가 매우 높습니다. 물론 저희도 교체는 합니다. 결국 감가 상각 수명이 약 6 년 이라는 문제가 있죠. 그래서 완전히 감가 상각이 끝나고 차세대 제품의 전력 효율 등을 고려 하면, 교체 하고 업그레이드 하는 것이 합리적 입니다. 칩만 바꾸는 것이 아니라 시스템 전체를 교체 하는 것이죠. 즉, 저희는 '포드 (pod)' 단위로 생각 합니다. 예를 들어, TPU v4 포드 는 9,600 개의 칩으로 구성 될 수 있습니다. 그리고 140 여 개의 랙으로 이루어 지죠. 그러면 저희는 그 포드를 들어 내고 TPU v12, v13, v14 포드 등으로 교체 하게 됩니다. 항상 완벽 하게 들어 맞지는 않을 수도 있습니다. 즉, 새로운 포드의 공간이 기존 포드가 빠져 나간 자리에 딱 맞지 않을 수도 있다는 뜻 입니다. 그럴 경우 저희가 그 차이를 고려해야 하죠. 어떻게 개조 할지 방법을 찾아야 합니다. TPU가 몇 세대 나 더 나올지 모르기 때문에 미리 계획 할 수는 없습니다. 그래서 기존 장비를 철거 하고 새 TPU로 최대한 빨리 교체 하는 것은 나름의 노하우가 필요한 어려운 작업 입니다. >> 개방형 표준에 대해 공개적 으로 글을 쓰신 적이 있죠. 그 부분에 대해 한 말씀 해주 시겠습니까? >> 네, 우리가 앞서 이야기 했던 상호 운용성 문제와 관련이 있다고 봅니다. 저희는 수직적 통합을 지원 하고 최대한의 성능을 끌어낼 수 있도록 만들고 있지만, 동시에 특정 시스템에 종속 되거나 폐쇄적 인 환경을 강요 하지 않는 것을 매우 중요 하게 생각 합니다. 그러니까, 음, 한 가지 예를 들어 보죠. 구글 에서는 JAX 라는 모델 개발 프레임 워크 를 개발 했습니다. 저희는 아주 좋아 하죠. 정말 훌륭 하다고 생각 하며 내부적으로 도 광범위 하게 사용 하고 있습니다. 많은 고객이 PyTorch 를 선호 합니다. 그렇죠? 그래서 우리가 "자, TPU에서 실행 하고 싶다면 JAX를 사용해야 합니다. 그게 최고 니까요" 라고 말할 수도 있겠죠. 조금 과장 하는 것 같기도 하지만, 뭐 아닐 수도 있고요. 우리는 그게 최고 라고 생각 하고, 워낙 뛰어 나니 그게 유일한 선택지 라고 할 수도 있겠죠. 아니면 이렇게 말할 수도 있습니다. " 보세요, JAX가 좋다 면 저희도 JAX를 좋아 합니다. JAX가 마음 에 드시면 사용 하시면 됩니다. 하지만 PyTorch를 선호 하신 다면 수정 없이 모델을 실행할 수 있는 torch TPU가 준비 되어 있습니다." 사실 우리는 역사 속의 수많은 사례를 통해 이런 모습을 봐 왔습니다. 저는 IP (인터넷 프로토콜) 의 예를 들어 왔죠. 왜 인터넷 프로토콜이 승리 했을 까요? 사실 IP와 경쟁 하던 프로토콜은 많았 습니다 . 70 년대와 80 년대 초의 아주 오래된 이야기 죠. 왜 IP가 이겼을 까요? 그건 IP가 오픈 표준 이었기 때문 입니다. 모래 시계의 잘록한 허리처럼 위로는 어떤 소프트웨어 든, 아래로는 어떤 하드웨어 든 구동 될 수 있었 으니까요. 즉 , 오픈 표준 이자 상호 운용이 가능 했기 때문 입니다. IP를 가진 누구든 라우터 포트에 연결만 하면 인터넷의 일부가 될 수 있었죠. 정말 멋진 일 이었습니다. 그 덕분에 인터넷이 전 세계로 폭발적 으로 성장 하고 퍼져 나갈 수 있었습니다. 그래서 우리는 플러그인 지점 측면에서 이러한 오픈 표준을 진심으로 신뢰 합니다. 물론 아주 특수한 무언가를 연결 하고 싶다면 그렇게 할 수 있습니다. 그렇죠? 저희 프레임 워크에 연결할 더 나은 방법이 있다고 생각 하신 다면 얼마 든지 그렇게 하셔도 됩니다. 하지만 우리 는 오픈 표준, 가급적 오픈 소스로 둘러싸인 표준을 진심 으로 지원 하고자 합니다. >> 이건 어느 한 공급 업체의 폐쇄 적이고 독점적 인 표준 으로 두기 에는 너무나 크고 중요한 인프라 구축 이니까요 . >> 네, 우리는 정말 그렇게 믿습니다. 또한 선택권이 보장 되어야 하죠. 예를 들어 저희가 TPU, GPU, 그 외 다양한 가속기를 전적으로 지원 하고 제공 하는 이유도 바로 그 때문 입니다. >> 네. AI 도입 이후 팀의 일상 업무는 어떻게 바뀌 었나요? 어떤 부분에서 가장 큰 변화 가 일어나고 있나요? >> 음, 가장 쉽게 답변 하자면 소프트웨어 엔지니어링 분야 일 것 입니다. 외부 에도 이미 상당히 많이 알려진 내용 이죠. 음, 그래서 저는 구글과 저희 팀이 소프트웨어 개발 역량 측면에서 AI를 매우 효과적으로 활용 하고 있다고 생각 합니다. 테스트, 출시, 심지어 설계 지원 등에서도 말이죠. 하지만 외부 적으로 는 덜 알려졌 을지 몰라도 하드웨어 측면 에서도 상당한 변화가 있었습니다. 다시 말해, 오늘 아침에 수치를 확인해 봤는데 저희 하드웨어 엔지니어들도 AI를 사용 하고 있습니다. 토큰 수로 따져 보자면, 최선의 지표는 아닐지 몰라도 어쨌든 지표는 되는 셈 이죠. 저희 하드웨어 엔지니어 들은 소프트웨어 엔지니어들 만큼이나 AI를 많이 사용 하고 있습니다. 그 결과 생산성이 향상 되었고, 설계 시작부터 테이프 아웃 까지 걸리는 시간이 줄어들고 있습니다. 제품 구동까지 걸리는 시간도 줄어들고 있죠 . 즉, 생산성이 크게 향상 되고 있는 겁니다. 하지만 예상치 못했던 다른 변화도 있습니다. 데이터 센터를 설계 하는 방식이 크게 달라졌 거든요. 다시 말해, ' 기가 와트 급 건물을 지을 지, 100MW 규모의 캠퍼스로 할지, 아니면 200MW 캠퍼스로 할지' 를 평가 하는 방식이 바뀌 었 습니다. 과거 에는 매우 상세 하고 스프레드 시트에 의존 하며 사람이 일일이 주도 하는 과정 이었죠. 지금도 어느 정도는 그렇지만, 이제는 AI가 많이 개입 되어 기획 및 개발 측면의 과정을 정말 효율적으로 만들어 주고 있습니다. >> 흥미 롭 네요. >> 그러면 추론 모델 같은 건가요? >> 아직 추론 모델 이라고 하기 까진 이릅니다. 인간의 판단 을 대체 하는 것은 아니지만, 필요한 정보를 한곳에 모으기 가 훨씬 쉬워 졌고 의사 결정 을 내리는 사람들에게 적절한 정보를 제공해 주는 역할을 합니다. >> 좋습니다. 좀 엉뚱 하면서도 재미있는 두 가지 질문으로 마무리 해 보겠습니다. >> 네. >> 음, 첫 번째 질문 입니다. 궤도 데이터 센터에 대해서요 . 구글이이 문제를 꽤 진지 하게 고민 하고 있다는 것을 알고 있습니다. 이에 대해 언급 하실 필요는 없지만, 사람들이 궤도 컴퓨팅에 대해 진지 하게 수치를 계산 하고 있다는 사실이 지구상에 심각한 제약 조건이 있다는 것을 의미 하는 걸까요? 그리고 궤도 데이터 센터에 대해 어떻게 생각 하시나요? >> 네, 흥미로운 방향 입니다. 저희는 실제로 이를 추진하고 있으며, 단순히 농담조가 아니라 저희가 투자 하는 중요한 '문샷 (Moonshot)' 프로젝트 중 하나로 여기고 있습니다. 이건 대화 초반에 말씀 하신 내용으로 돌아가는 건데, 근본적인 제약 조건 으로 에너지와 에너지 생산이 핵심 적인 도전 과제 라고 지적 하신 부분이 정확 하다고 봅니다. 결론적으로 근본적인 관점에서 보면, 우주 에서는 대기 중의 감쇠 현상 등이 없기 때문에 약 40% 정도 더 많은 전력을 얻을 수 있습니다. 즉, 태양 광 발전 용량이 1.4 배 정도 더 크다는 뜻 이죠. 그게 첫 번째 부분 입니다. 하지만 태양 동기 궤도 에서는 태양 전지판이 햇빛을 받는 시간이 98 ~ 100%에 달합니다. 지상에서의 28 ~ 30%, 많아야 35%와 비교 하면 엄청난 수치 죠. 그렇군요. 다시 말해, 태양 이라는 엄청난 에너지 원이 있기 때문에 가용 한 전력량이 막대 합니다. 앞서 말한 1.4 배 의 효율에 하루 일조 시간 기준 3 ~ 4 배의 이점을 곱하는 셈 이죠. 그러면 배터리를 사실상 고려 대상에서 제외 할 수 있게 됩니다. 이제 진정 으로 가능성 있는 무언가를 만들 수 있게 되는 거죠. 물론 탄소 배출도 없고요. 장점이 아주 많죠. 도전 과제도 많고요. >> 네. >> 맞습니다. 정말 수많은 도전 과제가 있죠. 그렇다면 냉각 문제는 어떨까요? 순진 하게 생각 하면 우주에서 냉각 하는 게 더 쉽다고 생각할 수도 있죠. 사실은 더 어렵 습니다. 신뢰성 문제도 있고요. 이런 장비 들이 가끔 고장 난다는 이야기를 했었죠 . 그래서 수리가 훨씬 어려워 집니다. 불가능한 건 아니지만, 우주 에서는 더 힘든 일 이죠. 네트워킹도 마찬가지 고요. >> 클러스터와 연결 하는 문제 죠. >> 정확 합니다. 어쩌면이 모델 이 유망한 방향이 될지도 모르겠네요. 아마도 중복성을 확보 하는 것이 도움이 될 겁니다. 질문자 님이 말씀 하신 자유 공간 광통신이 이제 현실이 될 겁니다. 아마 이런 부품들 사이에 광섬유를 일일이 연결 하지는 않을 테니까요. 그래서 실제로 자유 공간 통신이 이루어질 겁니다. 레이저를 수신기에 조준 하고 실시간으로 보정 하는 방식을 쓰게 되겠죠. 이런 문제 들은 해결 불가능한 장애물은 아닙니다. 근본적으로 발목을 잡을 요소 는 없죠. >> 마지막 질문 입니다. 계속 해서 당신이 만든 그 엄청난 슈퍼 컴퓨터의 이미지가 머릿속을 떠나지 않네요. 그래서 드리는 질문 입니다. 10 년 후 가장 최첨단 슈퍼 컴퓨터는 어떤 모습 일까요? >> 세상에. 네. 10 년 이라는 시간 은 참 애매한 경계선 이라, 진지 하게 2036 년의 컴퓨터가 어떤 모습 일지 고민 하는 사람이 분명 있을 겁니다. 그렇게 먼 미래를 내다 보는 사람도 몇 명은 있겠죠. 하지만와, 불확실성의 범위가 너무나도 넓 습니다. 다시 말해, 현재 추세를 보면 통합 의 수준이 엄청날 것이라는 점은 분명 합니다. Ineffable을 위해 우리가 구성 했던 아름다운 광섬유와 VR200 랙을 보셨 겠지만 요. 제 생각 에는 훨씬 더 고도로 통합 된 형태 가 될 것 같습니다. 2036 년 에는 광섬유가 아예 사라지 지는 않겠지만, 랙 관점에서 보면 훨씬 더 긴밀 하게 통합 될 것이고 랙에서 나오는 광섬유는 작은 다발 정도일 것으로 생각 합니다. 다시 말해, 모듈 형 제조 관점에서 보면 2036 년 에는 이러한 랙 들이 중앙에서 제조 될 가능성이 높습니다. 72 개든 144 개든 288 개든, 아니면 아마도 그보다 더 많은 576 개나 1152 개든, GPU의 배수 중 원하는 것을 선택 하세요. 이네 퍼블 (Ineffable) 사례에 대해 이야기 했으니 TPU도 마찬가지 일 겁니다. 랙에 깊숙이 통합 되어 있죠. 랙 하나가 수 메가 와트 급이 될까요? 정확히는 알 수 없지만 2036 년 이니까 상상해 볼 수 있겠죠. 단일 랙에 수 메가 와트가 될 수도 있습니다. 이제 물과 전력, 광섬유를 연결 하는 겁니다. 그렇죠? 랙을 밀어 넣고 그 세 가지를 연결 하면 바로 가동 을 시작 하는 거죠. >> 알겠습니다, 그럼 커다란 외계 구체 같은 모습은 아니 겠네요. >> 우주에 있는 거요. 2036 년 이라면 불가능 하다고 말할 순 없겠죠. 바로 우주로 발사 되어 우주 정거장의 로봇 팔 이 잡아서 적절한 모듈에 연결 하는 식일 수도 있으니까요. 어쩌면 2036 년 에는 가능 할지도 모릅니다. >> 재밌 네요. >> 생각만 해도 즐겁 습니다. >> 이번 대화 정말 즐거웠 습니다. 지금은 역사상 가장 강렬 하고 거대한 자본 지출 빌드 업이 이루어지는 시기 지만, 저는 이것이 기술적 인 >> 혁명 이라고 생각 합니다. >> 정말 아름다운 혁명 이죠. 기술의 아름다움과 제약 사항 들, 그리고이 모든 것을 어떻게 균형 잡아야 하는지에 대해 깊이 이해 하고 계시는 것 같습니다. 구글은 아주 잘 운영 되고 있네요. >> 감사 합니다. >> 시간 내어 하시는 일을 공유해 주셔서 감사 합니다. >> 정말 즐거웠 습니다. 우리는 이 시대를 살아가고 있으니 우리가 직접 정의 해 나갈 수 있는 거죠. 정말 감사 합니다. 훌륭한 대화 였습니다. >> 감사 합니다. >> 네, 감사 합니다.



===== 통합 원문 3 / 9 =====
[채널] 세상의 (부)족한 것들에 대해서
[게시일시] 2026.10.09 12:23:14
[텔레그램 게시물] https://t.me/runoutof/483720
[원문 수집 기준] 외부 링크가 있으면 링크를 따라 확보한 실제 본문·첨부 파일이 주 분석 원문이다. 텔레그램 게시물은 발견 경로와 보조 설명으로 보존하며 외부 원문과 구분해 반영한다.

[현재 텔레그램 게시물 본문]
엔비디아, '루빈' HBM4 12단 유지 전망...HBM 수요 둔화 우려 기우

키워드: #부족

HBM 수요가 유지되면 범용 D램 공급 부족도 이어질 가능성이 크다. HBM 생산에는 범용 D램보다 3배 이상의 생산능력이 투입되기 때문이다. HBM 생산 확대가 범용 D램 공급을 제약하고, 결과적으로 메모리 가격을...

본문보기
[본문보기] https://www.mdtoday.co.kr/news/articleView.html?idxno=617980&igsh=M1RVxcpryQpEte==
[엔비디아, '루빈' HBM4 12단 유지 전망..."HBM 수요 둔화 우려 기우" - 메디컬투데이] https://mdtoday.co.kr/news/articleView.html?idxno=617980&igsh=M1RVxcpryQpEte==

[외부 원문 1]
[URL] https://www.mdtoday.co.kr/news/articleView.html?idxno=617980&igsh=M1RVxcpryQpEte==
[제목] 엔비디아,

발행일: 2026-10-09 12:08 (금)
로그인
회원가입
모바일웹
한국어 영어 일본어 중국어 베트남어 독일어 불어 스페인어
정책
보건·복지 노동 환경 교육
의료
의료산업 병원·약국 학술·연구 병원뉴스 닥터뉴스 단체·학회 행사 사건·사고
제약·바이오
헬스케어
건강
내과 성형외과 가정의학과 치과 정형외과 신경과 피부과 산부인과 안과 정신건강의학과 외과 소아청소년과 이비인후과 비뇨의학과 신경외과 마취통증의학과 재활의학과 암 응급의학과 영상의학과
웰빙
웰빙 뷰티 육아·교육 DRUG FOOD 실버 DIET 性 여성 흡연·음주
경제·산업
재계 전기·전자 유통 자동차·모빌리티 중공업·방산 에너지·화학 항공·해운 ICT 건설·부동산 산업일반 기업탐방 ISSUE(사고·노동·안전·환경)
파이낸스
SPORTS+
야구 해외야구 축구 해외축구 골프 e스포츠 스포츠일반 연예 생활문화
피플
인사 경조 칼럼 통계 인물(인터뷰) 기타
Global Biz
아메리카 일본 중국 유럽 중동·동남아 K-COMPANY
가
가
기사의 본문 내용은 이 글자크기로 변경됩니다.
신현정 기자
입력 2026.10.09 12:21
댓글 0
구글 선호 검색 출처로 추가
가
가
기사의 본문 내용은 이 글자크기로 변경됩니다.
이 기사를 공유합니다
엔비디아의 차세대 인공지능(AI) 가속기 '루빈'에 탑재될 6세대 고대역폭메모리(HBM4)가 당초 우려와 달리 12단 구성을 중심으로 유지될 것이라는 분석이 나왔다. (사진=DB)
[mdtoday = 신현정 기자] 엔비디아의 차세대 인공지능(AI) 가속기 '루빈'에 탑재될 6세대 고대역폭메모리(HBM4)가 당초 우려와 달리 12단 구성을 중심으로 유지될 것이라는 분석이 나왔다. 업계 일각에서 불거진 HBM 적층 단수 축소설이 메모리 시장 전반에 드리운 불안감을 걷어낼 수 있을지 주목된다.
시장조사업체 카운터포인트리서치는 8일 최근 제기된 HBM 탑재량 축소설을 자체 점검한 결과 메모리 수요 둔화 우려는 오해라고 밝혔다.
카운터포인트리서치는 메모리 수요 성장에 대한 확신이 10월 들어 오히려 강화됐다고 평가했다. 업계에서는 엔비디아가 주요 HBM 공급사에 적층 단수를 기존 12단에서 8단으로 낮춰 달라고 요청했다는 주장이 제기돼 왔다.
이 같은 주장이 사실이라면 HBM 탑재량 감소로 범용 D램 생산이 늘어나고, 메모리 가격이 하락할 수 있다는 전망이 나올 수 있다. 그러나 카운터포인트리서치는 대부분의 루빈 탑재 제품이 12단 구성으로 수렴하는 추세라고 분석했다. AI 연산에서는 비용 절감보다 데이터 처리에 필요한 메모리 대역폭과 용량을 확보하는 일이 더 중요하기 때문이라고 설명했다.
ASIC 시장에서도 HBM 적층 단수 축소를 뒷받침하는 흐름은 확인되지 않았다. 카운터포인트리서치는 시장에서 4단 제품은 확인되지 않았다고 밝혔다. 이에 따라 HBM 탑재량이 크게 줄어들 것이라는 우려에는 근거가 제한적이라는 분석이 나온다.
HBM 수요가 유지되면 범용 D램 공급 부족도 이어질 가능성이 크다. HBM 생산에는 범용 D램보다 3배 이상의 생산능력이 투입되기 때문이다. HBM 생산 확대가 범용 D램 공급을 제약하고, 결과적으로 메모리 가격을 뒷받침하는 구조다.
삼성전자는 이날 3분기 매출 195조원, 영업이익 107조4000억원을 기록한 것으로 잠정 집계됐다고 발표했다. 전년 동기와 비교하면 매출은 86.1%, 영업이익은 782.5% 증가한 수치다. 국내 기업이 분기 영업이익 100조원을 넘어선 것은 이번이 처음이다.
카운터포인트리서치는 삼성전자가 역대 최대 실적을 기록했음에도 최근 반도체 업체에서 나타난 큰 폭의 어닝 서프라이즈는 없었던 원인으로 환율을 지목했다. 삼성전자는 달러 매출 비중이 높아 달러·원 환율이 급격히 하락하면 달러 수익을 원화로 환산할 때 부담이 커진다는 설명이다.
카운터포인트리서치는 HBM 수요 확대와 공급 구조를 고려하면 삼성전자의 역대 최대 실적이 일회성에 그치지 않을 가능성이 있다고 내다봤다.
삼성전자와 SK하이닉스의 HBM4 양산이 시작된 만큼, 고부가 메모리 수요가 두 기업의 실적에 지속적인 영향을 미칠 것으로 전망된다.
메디컬투데이 신현정 기자(choice0510@mdtoday.co.kr)
관련기사
"최대 7.5억" 삼성전자 DS 특별성과급 세부안 확정… 내년 3월 자사주 지급
삼전닉스 출신 27명 중국행…26명은 이미 떠났다
[분석] 삼전·하이닉스 55조 자사주 매입 마무리..."수급 우려 불필요"
한미반도체, 삼성전기서 245억 장비 수주
나인원한남 263억 최고가 매매...새 주인 알고 보니 곽동신 한미반도체 회장 장남
신현정 기자 choice0510@mdtoday.co.kr
키워드
#삼성전자 #SK하이닉스 #엔비디아 #고대역폭메모리 #HBM4 양산
저작권자 © 메디컬투데이 무단전재 및 재배포, AI학습 및 활용 금지
더보기
내 댓글 모음
닫기
제2형 당뇨병, 생활 리듬 규칙적일수록 혈당 조절 목표 달성률 높아
2026.10.09
빛만 받으면 세균·바이러스 제거…병원용 '자가 소독 섬유' 개발
2026.10.09
간암에 전기 소작술·CAR-NK 면역세포치료 병합했더니 항암 효과 증가
2026.10.09
폐암 발생 수년 전 나타나는 '면역 이상 신호' 발견…조기 진단·예방 가능성
2026.10.09
디지털 헬스케어 도입했더니…의료진 업무 오히려 늘어나는 역설
2026.10.09
[국감현장] 국민연금 국고 지원 앞당길수록 효과 커…정부도 확대 필요성 공감
네덜란드 법원, 알테오젠 기술 적용 '키트루다 SC' 특허 침해 인정…유럽 8개국 판매금지
[국감현장] 똑똑플란트치과 사망사고 국감 도마…허위·과장 의료광고 지적
[국감현장] 국감서 다시 불거진 李 대통령 헬기 이송 논란…부산대병원장 "충분히 수술 가능했다"
전자담배 단기 노출, 폐조직 손상·항바이러스 방어 약화
편의점 상비약 확대 공언했지만…후보 검토·의견수렴 모두 ‘전무’
제2형 당뇨병, 생활 리듬 규칙적일수록 혈당 조절 목표 달성률 높아
간암에 전기 소작술·CAR-NK 면역세포치료 병합했더니 항암 효과 증가
폐암 발생 수년 전 나타나는 '면역 이상 신호' 발견…조기 진단·예방 가능성
디지털 헬스케어 도입했더니…의료진 업무 오히려 늘어나는 역설
1
[단독] 회삿돈으로 에어비앤비 투기한 삼성맨들…들통나자 "로펌 부모 앞세워 역고소 으름장"
2
도경완, 5년 8개월 만에 KBS 돌아온다…장윤정 사로잡은 '필살 레시피'
3
‘학교를 안 갔어’ 김량하, 10년 친구와 결혼…신부는 모델 김희
4
유승호·임세주, 6년 열애 뒤 결별…뒤늦게 알려진 두 사람의 인연
5
테이 타완 "자리 너무 차지해 미안…송강에게 사과 전해"
제2형 당뇨병, 생활 리듬 규칙적일수록 혈당 조절 목표 달성률 높아
빛만 받으면 세균·바이러스 제거…병원용 '자가 소독 섬유' 개발
간암에 전기 소작술·CAR-NK 면역세포치료 병합했더니 항암 효과 증가
폐암 발생 수년 전 나타나는 '면역 이상 신호' 발견…조기 진단·예방 가능성
디지털 헬스케어 도입했더니…의료진 업무 오히려 늘어나는 역설
제2형 당뇨병, 생활 리듬 규칙적일수록 혈당 조절 목표 달성률 높아
빛만 받으면 세균·바이러스 제거…병원용 '자가 소독 섬유' 개발
간암에 전기 소작술·CAR-NK 면역세포치료 병합했더니 항암 효과 증가
폐암 발생 수년 전 나타나는 '면역 이상 신호' 발견…조기 진단·예방 가능성
디지털 헬스케어 도입했더니…의료진 업무 오히려 늘어나는 역설

[외부 원문 2]
[URL] https://www.mdtoday.co.kr/news/articleView.html?idxno=617980&igsh=M1RVxcpryQpEte==
[제목] 엔비디아,

발행일: 2026-10-09 12:08 (금)
로그인
회원가입
모바일웹
한국어 영어 일본어 중국어 베트남어 독일어 불어 스페인어
정책
보건·복지 노동 환경 교육
의료
의료산업 병원·약국 학술·연구 병원뉴스 닥터뉴스 단체·학회 행사 사건·사고
제약·바이오
헬스케어
건강
내과 성형외과 가정의학과 치과 정형외과 신경과 피부과 산부인과 안과 정신건강의학과 외과 소아청소년과 이비인후과 비뇨의학과 신경외과 마취통증의학과 재활의학과 암 응급의학과 영상의학과
웰빙
웰빙 뷰티 육아·교육 DRUG FOOD 실버 DIET 性 여성 흡연·음주
경제·산업
재계 전기·전자 유통 자동차·모빌리티 중공업·방산 에너지·화학 항공·해운 ICT 건설·부동산 산업일반 기업탐방 ISSUE(사고·노동·안전·환경)
파이낸스
SPORTS+
야구 해외야구 축구 해외축구 골프 e스포츠 스포츠일반 연예 생활문화
피플
인사 경조 칼럼 통계 인물(인터뷰) 기타
Global Biz
아메리카 일본 중국 유럽 중동·동남아 K-COMPANY
가
가
기사의 본문 내용은 이 글자크기로 변경됩니다.
신현정 기자
입력 2026.10.09 12:21
댓글 0
구글 선호 검색 출처로 추가
가
가
기사의 본문 내용은 이 글자크기로 변경됩니다.
이 기사를 공유합니다
엔비디아의 차세대 인공지능(AI) 가속기 '루빈'에 탑재될 6세대 고대역폭메모리(HBM4)가 당초 우려와 달리 12단 구성을 중심으로 유지될 것이라는 분석이 나왔다. (사진=DB)
[mdtoday = 신현정 기자] 엔비디아의 차세대 인공지능(AI) 가속기 '루빈'에 탑재될 6세대 고대역폭메모리(HBM4)가 당초 우려와 달리 12단 구성을 중심으로 유지될 것이라는 분석이 나왔다. 업계 일각에서 불거진 HBM 적층 단수 축소설이 메모리 시장 전반에 드리운 불안감을 걷어낼 수 있을지 주목된다.
시장조사업체 카운터포인트리서치는 8일 최근 제기된 HBM 탑재량 축소설을 자체 점검한 결과 메모리 수요 둔화 우려는 오해라고 밝혔다.
카운터포인트리서치는 메모리 수요 성장에 대한 확신이 10월 들어 오히려 강화됐다고 평가했다. 업계에서는 엔비디아가 주요 HBM 공급사에 적층 단수를 기존 12단에서 8단으로 낮춰 달라고 요청했다는 주장이 제기돼 왔다.
이 같은 주장이 사실이라면 HBM 탑재량 감소로 범용 D램 생산이 늘어나고, 메모리 가격이 하락할 수 있다는 전망이 나올 수 있다. 그러나 카운터포인트리서치는 대부분의 루빈 탑재 제품이 12단 구성으로 수렴하는 추세라고 분석했다. AI 연산에서는 비용 절감보다 데이터 처리에 필요한 메모리 대역폭과 용량을 확보하는 일이 더 중요하기 때문이라고 설명했다.
ASIC 시장에서도 HBM 적층 단수 축소를 뒷받침하는 흐름은 확인되지 않았다. 카운터포인트리서치는 시장에서 4단 제품은 확인되지 않았다고 밝혔다. 이에 따라 HBM 탑재량이 크게 줄어들 것이라는 우려에는 근거가 제한적이라는 분석이 나온다.
HBM 수요가 유지되면 범용 D램 공급 부족도 이어질 가능성이 크다. HBM 생산에는 범용 D램보다 3배 이상의 생산능력이 투입되기 때문이다. HBM 생산 확대가 범용 D램 공급을 제약하고, 결과적으로 메모리 가격을 뒷받침하는 구조다.
삼성전자는 이날 3분기 매출 195조원, 영업이익 107조4000억원을 기록한 것으로 잠정 집계됐다고 발표했다. 전년 동기와 비교하면 매출은 86.1%, 영업이익은 782.5% 증가한 수치다. 국내 기업이 분기 영업이익 100조원을 넘어선 것은 이번이 처음이다.
카운터포인트리서치는 삼성전자가 역대 최대 실적을 기록했음에도 최근 반도체 업체에서 나타난 큰 폭의 어닝 서프라이즈는 없었던 원인으로 환율을 지목했다. 삼성전자는 달러 매출 비중이 높아 달러·원 환율이 급격히 하락하면 달러 수익을 원화로 환산할 때 부담이 커진다는 설명이다.
카운터포인트리서치는 HBM 수요 확대와 공급 구조를 고려하면 삼성전자의 역대 최대 실적이 일회성에 그치지 않을 가능성이 있다고 내다봤다.
삼성전자와 SK하이닉스의 HBM4 양산이 시작된 만큼, 고부가 메모리 수요가 두 기업의 실적에 지속적인 영향을 미칠 것으로 전망된다.
메디컬투데이 신현정 기자(choice0510@mdtoday.co.kr)
관련기사
"최대 7.5억" 삼성전자 DS 특별성과급 세부안 확정… 내년 3월 자사주 지급
삼전닉스 출신 27명 중국행…26명은 이미 떠났다
[분석] 삼전·하이닉스 55조 자사주 매입 마무리..."수급 우려 불필요"
한미반도체, 삼성전기서 245억 장비 수주
나인원한남 263억 최고가 매매...새 주인 알고 보니 곽동신 한미반도체 회장 장남
신현정 기자 choice0510@mdtoday.co.kr
키워드
#삼성전자 #SK하이닉스 #엔비디아 #고대역폭메모리 #HBM4 양산
저작권자 © 메디컬투데이 무단전재 및 재배포, AI학습 및 활용 금지
더보기
내 댓글 모음
닫기
제2형 당뇨병, 생활 리듬 규칙적일수록 혈당 조절 목표 달성률 높아
2026.10.09
빛만 받으면 세균·바이러스 제거…병원용 '자가 소독 섬유' 개발
2026.10.09
간암에 전기 소작술·CAR-NK 면역세포치료 병합했더니 항암 효과 증가
2026.10.09
폐암 발생 수년 전 나타나는 '면역 이상 신호' 발견…조기 진단·예방 가능성
2026.10.09
디지털 헬스케어 도입했더니…의료진 업무 오히려 늘어나는 역설
2026.10.09
[국감현장] 국민연금 국고 지원 앞당길수록 효과 커…정부도 확대 필요성 공감
네덜란드 법원, 알테오젠 기술 적용 '키트루다 SC' 특허 침해 인정…유럽 8개국 판매금지
[국감현장] 똑똑플란트치과 사망사고 국감 도마…허위·과장 의료광고 지적
[국감현장] 국감서 다시 불거진 李 대통령 헬기 이송 논란…부산대병원장 "충분히 수술 가능했다"
전자담배 단기 노출, 폐조직 손상·항바이러스 방어 약화
편의점 상비약 확대 공언했지만…후보 검토·의견수렴 모두 ‘전무’
제2형 당뇨병, 생활 리듬 규칙적일수록 혈당 조절 목표 달성률 높아
간암에 전기 소작술·CAR-NK 면역세포치료 병합했더니 항암 효과 증가
폐암 발생 수년 전 나타나는 '면역 이상 신호' 발견…조기 진단·예방 가능성
디지털 헬스케어 도입했더니…의료진 업무 오히려 늘어나는 역설
1
[단독] 회삿돈으로 에어비앤비 투기한 삼성맨들…들통나자 "로펌 부모 앞세워 역고소 으름장"
2
도경완, 5년 8개월 만에 KBS 돌아온다…장윤정 사로잡은 '필살 레시피'
3
‘학교를 안 갔어’ 김량하, 10년 친구와 결혼…신부는 모델 김희
4
유승호·임세주, 6년 열애 뒤 결별…뒤늦게 알려진 두 사람의 인연
5
테이 타완 "자리 너무 차지해 미안…송강에게 사과 전해"
제2형 당뇨병, 생활 리듬 규칙적일수록 혈당 조절 목표 달성률 높아
빛만 받으면 세균·바이러스 제거…병원용 '자가 소독 섬유' 개발
간암에 전기 소작술·CAR-NK 면역세포치료 병합했더니 항암 효과 증가
폐암 발생 수년 전 나타나는 '면역 이상 신호' 발견…조기 진단·예방 가능성
디지털 헬스케어 도입했더니…의료진 업무 오히려 늘어나는 역설
제2형 당뇨병, 생활 리듬 규칙적일수록 혈당 조절 목표 달성률 높아
빛만 받으면 세균·바이러스 제거…병원용 '자가 소독 섬유' 개발
간암에 전기 소작술·CAR-NK 면역세포치료 병합했더니 항암 효과 증가
폐암 발생 수년 전 나타나는 '면역 이상 신호' 발견…조기 진단·예방 가능성
디지털 헬스케어 도입했더니…의료진 업무 오히려 늘어나는 역설


===== 통합 원문 4 / 9 =====
[채널] Korean Alpha
[게시일시] 2026.10.09 12:23:48
[텔레그램 게시물] https://t.me/korean_alpha/883752
[원문 수집 기준] 외부 링크가 있으면 링크를 따라 확보한 실제 본문·첨부 파일이 주 분석 원문이다. 텔레그램 게시물은 발견 경로와 보조 설명으로 보존하며 외부 원문과 구분해 반영한다.

[연계된 텔레그램 원문]
[원문 게시물] https://t.me/korean_alpha/879908
✔️YZi Labs 투자 SmartX, 얼리 액세스 오픈

YZi Labs EASY Residency S4 선정 프로젝트 SmartX가 얼리 액세스 신청을 오픈했습니다.

SmartX는 Meme, Perps, 주식, 예측시장 등을 하나의 앱에서 거래할 수 있는 온체인 소셜 트레이딩 플랫폼인데요. 현재 별도 비용 없이 웨이트리스트 참여가 가능합니다.

간단한 테스트 완료 후 결과를 X에 공유하면 랭킹이 활성화되며, 가입 시점 + 친구 초대 Boost에 따라 순위가 결정됩니다.

🔖 참여방법
1️⃣ SmartX 얼리 액세스 신청 
2️⃣테스트 완료 → 이미지 다운로드 → X에 게시

🔖 보상
• 1위: 싱가포르 여행 + 창업자 프라이빗 디너 + iPhone Duo
• 2~3위: WHOOP + 커뮤니티 보상 풀 5%/3%
• 4~100위: 커뮤니티 보상 풀 52% 순위별 분배
• 101~500위: 보상 풀 40% 분배 + SmartX 앱 얼리 액세스
• 501~5,000위: SmartX 앱 얼리 액세스
• 순위별 첫 1~3개월 수수료 20~50% 할인
트윗원문

[현재 텔레그램 게시물 본문]
✔️SmartX 시즌1 리더보드 공개, 시즌2 참여 시작

YZi Labs의 초기 투자를 받은 SmartX가 시즌1 초대 이벤트 리더보드를 공개했습니다.

- 시즌1 순위 확인: 리더보드 
- 시즌2: 신규 참여 가능 

✍️아직 참여하지 않은 분들은 시즌2부터 참여할 수 있습니다.
현재는 초대 이벤트 외에 별다른 활동은 없어 보이네요. 이번 KBW에도 참가했던 프로젝트인 만큼 향후 행보를 지켜보겠습니다!
[리더보드] https://smartx.io/waitlist/leaderboard/
[신규 참여 가능] https://www.smartx.io/waitlist/?invite=8iwm1sa8

[외부 원문 1]
[URL] https://x.com/SmartXTerminal/status/2102029641498423553?s=20
[제목] SmartX (@SmartXTerminal) on X

SmartX
@SmartXTerminal
The SmartX waitlist is now open. What kind of trader are you? Take the Trader Type Test and claim your place in Chapter One of SmartX — The personalized social trading app for on-chain markets. Win an iPhone Duo, enter the Genesis 100, and share up to 10,000 USDT in rewards. smartx.io/waitlist
00:00
1:38 PM · Sep 21, 2026 ·
302.3K
Views
138
202
586
68
SmartX
@SmartXTerminal
The SmartX waitlist is now open. What kind of trader are you? Take the Trader Type Test and claim your place in Chapter One of SmartX — The personalized social trading app for on-chain markets. Win an iPhone Duo, enter the Genesis 100, and share up to 10,000 USDT in rewards. smartx.io/waitlist
00:00
1:38 PM · Sep 21, 2026 ·
302.3K
Views
138
202
586
68
SmartX
@SmartXTerminal
Sep 21
⏭️How to climb: Join early to start higher. Every referral who completes the test earns you Boost. #1 wins an iPhone Duo, a Singapore trip to private dinner with our founder, and limited Genesis merch. Genesis 100 will be permanently recorded on-chain. Top 5000 all get Show more
SmartX Waitlist: Chapter One Begins
From smartx.io
1
2
16
3.2K
Farmercist - TOKEN2049 🇸🇬👨‍🌾
@Farmercist
Sep 22
Okay I’m onboarding into SmartX waitlist 🦅
4
1.1K


===== 통합 원문 6 / 9 =====
[채널] Korean Alpha
[게시일시] 2026.10.09 12:24:28
[텔레그램 게시물] https://t.me/korean_alpha/883754
[원문 수집 기준] 외부 링크가 있으면 링크를 따라 확보한 실제 본문·첨부 파일이 주 분석 원문이다. 텔레그램 게시물은 발견 경로와 보조 설명으로 보존하며 외부 원문과 구분해 반영한다.

[현재 텔레그램 게시물 본문]
Join Catalyst Waitlist For Early Access 

- 30 Million$ Funding 
- Free of Cost
- Possible Rewards For Early Users 

🪡 https://catalyst.app/?r=fx82p

[외부 원문 1]
[URL] https://catalyst.app/?r=fx82p
[제목] Catalyst | Intelligence at Your Fingertips

Prediction markets Follow market odds, trader activity, and positions across events.
Stocks Explore company performance, earnings, and price history.
Options Explore contracts, trading activity, and unusual options flow.
Perpetuals Track prices, funding rates, and open interest across markets.
Sentiment Follow changes in market sentiment and trader positioning.
Social activity Follow posts from people and sources relevant to your research.
Fund flows Track money moving into and out of funds over time.
Portfolio Track your holdings, allocation, transactions, and performance.
News Follow headlines and developments across markets and topics.


===== 통합 원문 8 / 9 =====
[채널] 용산의 현인
[게시일시] 2026.10.09 12:26:52
[텔레그램 게시물] https://t.me/petrojimmy/15192
[원문 수집 기준] 외부 링크가 있으면 링크를 따라 확보한 실제 본문·첨부 파일이 주 분석 원문이다. 텔레그램 게시물은 발견 경로와 보조 설명으로 보존하며 외부 원문과 구분해 반영한다.

[현재 텔레그램 게시물 본문]
#인사이트 

월마트의 주가는 20년간 연평균 10%를 하회했지만 종국에 달성한 놀라운 모습을 보여줬다. 

1억원을 넣었으면 약 7억원이 되는셈. 

위대한 수익의 시작은 위대한 기업을 찾았다는 안목이지만

수익의 대부분은 기다림에서 왔다