Google이 8세대 TPU에서 강조한 숫자 가운데 가장 중요한 값은 12.6 FP4 PFLOPS가 아니라 두 가지 시스템입니다. TPU 8t는 대규모 사전 학습과 임베딩 처리에 맞췄고, TPU 8i는 후속 학습과 동시 요청이 많은 추론·서빙에 맞췄습니다[1]. 실행 유닛의 일부 기능만 달라진 것이 아닙니다. HBM과 온칩 메모리 용량, 전용 가속기, 칩 사이 연결 구조, 팟 규모, 호스트 CPU와 데이터센터 네트워크가 함께 달라집니다.
이 구분은 가속기 성능표가 자주 가리는 문제를 드러냅니다. 학습은 한 단계의 응답시간보다 정해진 집합 통신을 오랫동안 높은 사용률로 수행하는 능력이 중요합니다. 자기회귀 추론에서는 토큰 하나를 만들 때마다 상태를 읽고, 리덕션과 전문가 라우팅을 끝낸 뒤 다음 단계로 넘어갑니다. 수천 개 칩이 일정한 형태로 그래디언트를 교환할 때 효율적인 네트워크가 임의의 전문가에게 토큰을 보낼 때는 너무 많은 홉을 요구할 수 있습니다. 반대로 지연시간을 줄인 작은 팟은 몇 달 동안 이어지는 학습에 필요한 총 연산량과 메모리를 충분히 묶지 못할 수 있습니다.
공개 자료만으로 두 설계의 방향은 확인할 수 있지만 클라우드 서비스의 우열까지 판단하기는 어렵습니다. 성능과 비용 개선은 모두 7세대 Ironwood 대비 값이며, 고객용 서비스는 아직 제공 예정입니다[2][3]. 따라서 공개 구조와 공급사 예상 효과를 구분하고, 도입에 필요한 시험 항목을 제시합니다.
한 가지 시스템 구성으로 풀기 어려운 두 작업
TPU 8t와 TPU 8i는 같은 소프트웨어 환경과 Arm 기반 Axion 호스트 CPU를 사용하지만 자원 배분은 다릅니다. TPU 8t 한 칩은 HBM 216 GB, Vmem 128 MB, HBM 대역폭 6,528 GB/s와 최대 FP4 12.6 PFLOPS를 제공합니다. TPU 8i는 HBM 288 GB, Vmem 384 MB, HBM 대역폭 8,601 GB/s와 최대 FP4 10.1 PFLOPS를 제공합니다[1]. TPU 8i의 최대 FP4 연산량은 약 20% 적지만 HBM 용량은 33% 많고, HBM 대역폭은 약 32% 높으며, 온칩 메모리는 3배입니다.
제품 이름보다 이 비율이 설계 의도를 잘 보여 줍니다. TPU 8t는 더 큰 학습 영역에서 연산기를 계속 사용하는 데 자원을 배분했습니다. TPU 8i는 상태를 가까이 두고 동기화에 걸리는 시간을 줄이는 데 더 많은 면적과 연결 자원을 사용했습니다. 두 칩 모두 다른 쪽 작업을 실행할 수는 있지만, 비용이 큰 메모리와 네트워크의 구성이 서로 다른 병목에 맞춰져 있습니다.
두 시스템의 Axion CPU 헤드는 입력 전처리와 실행 제어 때문에 TPU가 기다리는 시간을 줄입니다. 모든 호스트 병목이 사라진다는 뜻은 아니지만, Google은 토큰화와 데이터 변환도 가속기 사용률을 결정하는 시스템 문제로 다룹니다.
학습 영역을 넓힌 TPU 8t
TPU 8t는 3차원 토러스 칩 연결 구조를 유지하면서 슈퍼팟 하나를 9,600개 칩까지 확장합니다. Google은 이 구성을 121 exaflops와 공유 HBM 2 PB 규모로 설명하고, Pathways와 JAX로 백만 개가 넘는 TPU를 하나의 학습 클러스터에서 운용할 수 있다고 발표했습니다[2]. 두 숫자는 같은 범위를 뜻하지 않습니다. 슈퍼팟은 칩을 직접 묶는 스케일업 영역이고, Virgo는 더 많은 슈퍼팟을 데이터센터에서 연결하며, 소프트웨어는 여러 데이터센터의 작업을 조정합니다. 백만 개 칩을 하나의 평평한 네트워크처럼 이해하면 실제 계층 구조와 장애 범위를 놓치게 됩니다.
칩 내부에서는 세 종류의 대기시간을 줄입니다. SparseCore는 임베딩 조회의 불규칙한 메모리 접근과 일부 데이터 의존형 집합 통신을 맡아 MXU가 유효하지 않은 연산을 처리하는 상황을 줄입니다. VPU와 MXU의 균형을 조정해 양자화, 소프트맥스, 계층 정규화를 행렬 연산과 더 많이 겹쳐 실행합니다. FP4를 하드웨어에서 직접 처리해 FP8보다 값 하나를 옮기는 비트 수를 절반으로 줄이고 MXU 처리량을 높입니다[1]. FP4에서 목표 정확도를 유지하는 모델과 학습 방법이 전제되지만, 세 기능 모두 최대치보다 실제 가동 시간을 높이려는 선택입니다.
데이터 입출력 경로도 학습 규모에 맞춰 넓혔습니다. Google에 따르면 칩 사이 연결(ICI) 대역폭은 Ironwood보다 2배이고, Virgo의 데이터센터 스케일아웃 원시 대역폭은 최대 4배입니다. Virgo는 포트 수가 많은 스위치로 네트워크 계층을 두 단계까지 줄이고, 여러 독립 평면을 사용해 13만 4,000개 이상의 TPU 8t를 47 Pb/s 양분 대역폭으로 연결합니다[1]. 양분 대역폭만으로 혼잡과 재전송, 집합 통신 스케줄링, 실제 응용 프로그램 효율을 알 수는 없으므로 이 값은 워크로드 단위로 확인해야 합니다.
저장장치도 학습의 핵심 경로에 포함됩니다. TPUDirect RDMA는 HBM과 네트워크 인터페이스 사이 전송에서 호스트 CPU와 DRAM을 거치지 않습니다. TPUDirect Storage는 TPU와 Managed Lustre 사이에 직접 접근 경로를 제공합니다. Google은 Managed Lustre 10T와 함께 사용할 때 직접 저장장치 경로의 전송 대역폭이 2배이고 Ironwood 학습보다 저장장치 접근이 최대 10배 빠르다고 설명합니다[1]. 모든 저장장치가 10배 빨라진다는 뜻은 아닙니다. 핵심은 체크포인트와 복구, 대규모 멀티모달 입력처럼 일반적인 가속기 벤치마크에서 빠지는 시간이 비싼 연산기를 세우지 않게 만든다는 점입니다.
기다리는 시간을 줄인 TPU 8i
TPU 8i는 장시간 평균 사용률보다 서로 의존하는 추론 단계의 지연시간을 줄이는 데 초점을 맞췄습니다. Vmem 384 MB는 이전 세대의 3배이며 TPU 8t와 비교해도 3배입니다. Google은 더 큰 KV 캐시를 온칩 메모리에 둘 수 있어 긴 문맥을 디코딩할 때 코어가 기다리는 시간을 줄인다고 설명합니다[1]. 모든 대형 모델과 동시 요청의 KV 상태를 이 용량 안에 넣을 수 있다는 뜻은 아닙니다. 배치 크기와 양자화, 상태 배치에 따라 HBM 접근은 계속 필요하지만 토큰마다 기다리는 일부 접근을 줄일 수 있습니다.
집합 통신 가속기(Collectives Acceleration Engine, CAE)는 Ironwood 코어 다이에 있던 SparseCore 네 개를 대신해 두 개 Tensor Core 다이 옆의 칩렛 다이에 배치됩니다. 자기회귀 디코딩에서 필요한 리덕션과 동기화를 처리하며, Google은 온칩 집합 통신 지연시간이 최대 5배 줄었다고 보고합니다[1]. 이는 특정 통신 동작의 결과이지 추론 전체가 5배 빨라졌다는 의미는 아닙니다. 메모리 접근이나 전문가 통신, 호스트 스케줄링, 소프트웨어 직렬 실행이 병목이면 실제 개선 폭은 작아집니다.
Boardfly는 같은 방향을 패키지 밖으로 확장합니다. TPU 8i 트레이는 칩 네 개로 기본 단위를 만들고, 보드 여덟 개를 구리 케이블로 연결해 하나의 그룹을 구성하며, 36개 그룹은 광회로 스위치로 연결됩니다. Google 자료에는 최대 설치 칩 1,152개와 최대 활성 칩 1,024개가 따로 제시됩니다. 1,024개 칩 기준으로 가장 먼 칩까지의 경로는 8 × 8 × 16 토러스의 16홉에서 Boardfly의 7홉으로 줄어듭니다. 네트워크 지름은 56% 작아지고, 통신 비중이 큰 워크로드의 지연시간은 최대 50% 개선됐다고 보고합니다[1]. 설치·활성 용량과 최장 경로, 응용 프로그램 지연시간은 구분해야 합니다.
통신 형태를 따라 달라진 네트워크
밀집 모델 학습은 텐서 배치와 통신 순서를 실행 전에 정할 수 있는 경우가 많습니다. 토러스는 인접 칩 사이의 규칙적인 통신에 여러 차원의 링크를 사용하고, 모든 칩을 직접 연결하지 않아도 큰 영역으로 확장할 수 있습니다. 대신 가장 먼 칩으로 가려면 여러 차원을 지나야 합니다. 임의의 칩 사이에서 all-to-all 통신이 발생하면 홉 수가 지연시간으로 나타납니다.
추론과 전문가 혼합(MoE) 서빙에서는 토큰이 어느 전문가로 갈지 모델 상태와 게이트 결과에 따라 달라지고, 다음 토큰은 현재 통신이 끝나야 시작할 수 있습니다. 고차수 계층망은 더 많은 직접 연결과 스위칭 자원을 사용해 최장 경로를 줄이는 대신 케이블과 광회로 스위치, 라우팅, 재구성 제어를 복잡하게 만듭니다. 따라서 Boardfly는 정상 상태의 평균 지연시간뿐 아니라 링크 장애와 그룹 분리, 광경로 변경 중의 꼬리 지연시간까지 시험해야 합니다.
스케줄러가 풀어야 할 문제도 달라집니다. TPU 8t는 대규모 메시와 연산·통신 중첩을 유지해야 하고, TPU 8i는 요청과 KV 상태를 작은 영역에 배치해야 합니다. 하드웨어 홉 수는 입장 제어가 요청을 의도한 영역 안에 유지할 때만 서비스 지연시간으로 이어집니다.
서로 다른 하드웨어를 감추고 활용해야 하는 소프트웨어
Google은 JAX, Pallas, Mosaic, XLA, Pathways, Keras, vLLM과 미리보기 단계의 네이티브 PyTorch 지원을 두 시스템의 공통 환경으로 제시합니다[1]. Pallas와 Mosaic은 커널 개발자가 SparseCore와 CAE를 직접 활용할 수 있게 합니다. XLA는 일반 모델 코드에서 Boardfly 배치와 CAE 동기화의 세부 사항을 감추는 역할을 합니다. 네이티브 PyTorch 지원은 JAX 중심으로 모델을 다시 작성하지 않으려는 팀의 진입 비용을 낮추려는 시도입니다.
응용 프로그램 코드는 이식할 수 있어야 하지만, 성능을 내려면 컴파일러가 토폴로지와 메모리 특성을 알아야 합니다. 같은 모델이 두 TPU에서 모두 실행돼도 샤딩과 집합 통신, 사용자 커널이 한쪽에만 맞으면 사용률은 달라집니다. 도입 시험에서는 변경 없이 컴파일되는 연산자의 비율, 커널 교체 시간, FP4 정확도, 재컴파일, 디버깅과 전용 경로의 유지 비용을 기록해야 합니다. 미리보기 단계인 PyTorch 지원도 기능 동작과 폭넓은 성능 최적화를 나누어 평가해야 합니다.
시장 비교가 아닌 자사 세대 비교
Google은 Ironwood와 비교해 TPU 8t의 학습 비용 대비 성능이 최대 2.7배, TPU 8i의 추론 비용 대비 성능이 최대 80% 높고, 두 칩의 전력 대비 성능이 최대 2배라고 발표했습니다[1]. 용도별 설계가 경제적 이점으로 이어진다는 방향은 확인할 수 있습니다. 하지만 외부 GPU 시스템과 비교하려면 가격과 워크로드, 지연시간 목표, 랙 입력 전력, 냉각 범위, 실제 사용률, 예약 조건과 오차 범위가 필요합니다.
비교 대상도 Google의 7세대 TPU입니다. 따라서 공개 결과는 Google 시스템이 한 세대 동안 얼마나 개선됐는지를 공급사가 고른 조건에서 측정한 값입니다. TPU 8t가 Vera Rubin 클러스터보다 목표 정확도까지 빨리 학습하는지, TPU 8i가 같은 모델과 정확도, 토큰 지연시간, 실제 전력에서 다른 추론 ASIC보다 유리한지는 아직 알 수 없습니다. 가능성을 부정하는 것이 아니라 공개 근거가 아직 그 비교를 뒷받침하지 않는다는 뜻입니다.
서비스 제공 상태도 따로 확인해야 합니다. 4월 발표는 두 시스템을 고객에게 제공할 예정이라고 밝혔고, 현재 제품 페이지도 관심 등록으로 안내합니다[2][3]. 발표와 일반 주문 가능 상태는 다릅니다. 지역별 용량과 할당 대기시간, 장기 사용 가격, 점검 중 동작, 지원 조건을 알아야 실제 프로젝트 일정에 맞출 수 있습니다.
완료한 작업량을 기준으로 한 도입 시험
TPU 8t는 실제 학습 그래프와 데이터셋, 체크포인트 정책을 넣어 시험해야 합니다. 정해진 모델 품질에 도달하는 시간을 기준으로 삼고 컴파일, 데이터 입력, 체크포인트 저장, 작업자 장애 뒤 재시작, 일부 칩을 사용하지 못하는 시간까지 포함해야 합니다. 할당한 가속기 수와 실제 연산한 가속기 수, 벽면 입력 전력을 따로 기록하면 9,600개 칩 영역과 Direct Storage, Virgo가 정상 학습 구간 밖에서도 유효한 작업을 유지하는지 확인할 수 있습니다.
TPU 8i에는 단일 처리량 값이 아니라 서빙 조건표가 필요합니다. 입력 길이와 출력 길이, 배치 크기, 동시 요청 수, MoE 라우팅 쏠림, KV 캐시 압력을 바꿔 가며 시험합니다. 모델 품질과 정밀도 정책을 고정한 뒤 첫 토큰 시간, 토큰 간 지연시간, p50·p95·p99 완료 지연시간, SLO 안에서 처리한 초당 요청 수와 실제 전력을 측정해야 합니다. 그룹이나 링크 장애 뒤에도 같은 시험을 반복해야 합니다. 평균 집합 통신은 빨라도 재구성 과정에서 긴 꼬리 지연시간이 생기면 대화형 서비스의 목표를 충족하지 못할 수 있습니다.
비용 범위도 두 시스템에서 같아야 합니다. TPU 사용료뿐 아니라 Axion 호스트, 스케일아웃 네트워크, 저장장치, 예약 할인, 여유 용량, 냉각과 이식·운영 인력을 포함해야 합니다. 이 총비용을 목표 품질에 도달한 학습 횟수 또는 SLO 안에 끝난 추론 요청 수로 나누는 편이 타당합니다. 최대 FP4당 가격은 응용 프로그램이 그 연산을 완료한 작업으로 바꿀 수 있음을 확인한 뒤에야 용량 계획에 쓸 수 있습니다.
칩이 아니라 시스템을 나눈 8세대 TPU
TPU 8의 의미는 AI 전체 수명주기를 한 가지 팟 구조에 억지로 맞추지 않았다는 데 있습니다. TPU 8t는 행렬 연산과 임베딩, 저장장치, 대규모 패브릭을 하나의 학습 처리량 시스템으로 구성했습니다. TPU 8i는 일부 최대 FP4를 줄이는 대신 HBM과 3배의 Vmem, 집합 통신 가속기, 최장 경로가 짧은 네트워크를 선택했습니다. 성능표에도 차이가 보이지만 실제 분리는 데이터가 놓이는 위치와 통신 구조에서 만들어집니다.
다른 가속기도 같습니다. 학습과 강화학습, 에이전트 서비스의 요구가 달라질수록 공급사는 범용 플랫폼을 유지하거나 작업 단계별 제품을 나눠야 합니다. 중요한 것은 전용 블록의 수가 아니라 상태 이동과 운영 경로를 늘리지 않으면서 실제 작업을 알맞은 자원에 배치하는 소프트웨어입니다.
현재 공개 자료에서 검증할 수 있는 가설은 분명합니다. 총 학습 처리량이 중요하면 넓고 규칙적인 계층망을 사용하고, 매 단계의 집합 통신이 사용자 지연시간을 좌우하면 작고 네트워크 지름이 짧은 계층망을 사용합니다. TPU 8t와 TPU 8i는 이 선택을 실제 시스템으로 구체화했습니다. 가격과 랙 전력, 장애 동작, 이식 노력, 독립적인 응용 프로그램 결과가 최종 가치를 결정할 것입니다.
출처와 저작권 안내
이 글은 공개된 Google Cloud 아키텍처 설명, Google Cloud Next 2026 인프라 발표, 현재 TPU 제품 페이지와 Hot Chips 2026 공개 프로그램을 바탕으로 독립적으로 작성한 편집 리뷰입니다[1][2][3][4]. 인증이 필요한 Hot Chips 발표 슬라이드와 세션 영상은 기술 근거로 사용하지 않았습니다. 원문 도판은 전재하지 않았으며, 개념 하드웨어 이미지와 토폴로지 비교도, 근거 구분 도판, 카드 모티프는 모두 이 글을 위해 새로 구성하고 코드로 제작했습니다. 원문과 제품 정보의 저작권은 Google LLC와 Hot Chips 2026 등 각 권리자에게 있습니다.