이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
Google과 SemiAnalysis가 공개한 TPUv7 Ironwood의 첫 외부 추론 결과에서 Qwen3.5 397B FP8 기준 Ironwood는 100 tokens/s/user에서 B200보다 약 19%, B300보다 약 34% 낮은 토큰 비용을 기록했고, 20 tokens/s/user에서는 칩당 처리량도 두 GPU보다 높았습니다. 이 비용 우위는 낮은 칩 시간당 비용과 TPU의 ICI 네트워크, SparseCore, MXU에 맞춘 DP Attention·MoE·GDN·Paged Attention 최적화가 함께 만든 결과입니다. 소프트웨어 측면에서는 JAX와 TorchAX를 거치는 기존 경로 대신 PyTorch의 PrivateUse1 디바이스와 StableHLO·XLA 컴파일 경로를 사용하는 TorchTPU가 vLLM과 SGLang의 외부 지원 기반으로 자리 잡고 있습니다. 다만 TPUv7은 FP4를 지원하지 않고 외부 Disaggregated Serving도 아직 완전히 최적화되지 않아 일부 지연 구간에서는 B200이나 GB300 NVL72가 앞서며, Speculative Decoding·Prefill-Decode 분리·KV cache Offloading·추가 모델 지원이 상용 경쟁력의 다음 조건으로 남아 있습니다.
섹션별 상세
TPUv7 Ironwood의 첫 외부 추론 벤치마크는 Google 내부 성과를 실제 구매자 관점의 비용과 성능으로 검증하는 데 초점을 맞췄습니다. Qwen3.5 397B를 FP8과 단일 토큰 예측 방식으로 실행하고, vLLM 기반 TPU와 SGLang 기반 NVIDIA GPU를 8k1k 작업 부하에서 비교했습니다. 외부 TPU TCO와 내부 TPU 칩 시간당 비용을 따로 적용한 결과, Ironwood의 경쟁력은 절대 처리량보다 낮은 총비용과 달러당 토큰 처리량에서 가장 뚜렷하게 나타났습니다.
100 tokens/s/user의 상호작용 수준에서 Ironwood의 백만 토큰당 비용은 약 $0.181로, B200의 $0.222와 B300의 $0.276보다 낮았습니다. 같은 사용자별 생성 속도를 유지하면서 외부 TCO 기준 B200보다 약 19%, B300보다 약 34% 저렴한 결과입니다. 다만 Ironwood가 모든 지연 구간에서 우세한 것은 아니며, 약 30초의 중앙 End-to-End 지연 구간에서는 B200이 앞서는 구간도 존재합니다.
20 tokens/s/user에서는 Ironwood가 칩당 초당 총 9,364토큰을 처리해 B200의 8,903토큰과 B300의 8,925토큰을 웃돌았습니다. 낮은 시간당 비용과 이 처리량을 결합하면 B200보다 50.4%, B300보다 96.0% 많은 토큰을 달러당 처리하는 계산이 나옵니다. 내부 TPU TCO를 칩 시간당 $1.03으로 낮추면 동시성 256에서 이 차이는 B200 대비 76.7%, B300 대비 130.2%까지 커지지만, 평균 TTFT는 Ironwood 5.41초, B200 3.75초, B300 2.40초로 길어집니다.
GB300 NVL72의 Disaggregated Serving과 Ironwood의 Aggregated Serving을 비교하면 두 시스템의 실행 구성이 달라 완전한 동등 비교가 아닙니다. 현재 외부 TPU 스택에는 최적화된 Disaggregated 경로가 없어서 중간 End-to-End 지연 구간에서 GB300 NVL72가 약 30%의 달러당 성능 우위를 보입니다. Google과 협력사들이 TPUv7의 Prefill-Decode 분리 경로를 최적화하면 전체 Pareto 구간에서 경쟁할 수 있다는 전망은 아직 후속 측정으로 검증되어야 합니다.
TorchAX 기반의 기존 경로는 PyTorch 모델의 ATen 연산을 JAX 연산으로 변환하고, JAX가 StableHLO와 XLA를 거쳐 TPU 실행 파일을 만드는 구조였습니다. KV cache처럼 생성 중 변하는 상태를 명시적인 입력과 출력으로 바꾸어 jax.jit가 반복 실행 그래프를 포착하게 했지만, 모델·래퍼·프레임워크 사이의 변환 계층이 복잡해졌습니다. TorchTPU는 PyTorch의 PrivateUse1 확장 지점에서 device="tpu"인 일반 torch.Tensor를 제공하고, Eager 실행이나 torch.compile을 통해 PyTorch 코드와 서빙 엔진의 재사용 범위를 넓힙니다.
TorchTPU의 Native 경로에서도 컴파일러와 하드웨어별 커널이 사라지는 것은 아닙니다. TorchDynamo와 AOTAutograd가 FX 그래프를 만들고 TorchTPU가 이를 StableHLO로 낮춘 뒤 XLA가 TPU 실행 파일을 생성하며, 성능 병목에는 Pallas와 JAX 기반 Custom Kernel이 계속 사용됩니다. 따라서 PyTorch 인터페이스와 분산 API를 유지하면서도 Tensor Shape, Tensor Layout, MXU 활용률, SparseCore 배치처럼 TPU에 특화된 최적화는 여전히 모델별로 필요합니다.
Qwen3.5의 GQA는 32개의 Query Head와 2개의 공유 KV Head를 사용하므로 TP8에서 KV Head를 단순히 각 Rank에 분배할 수 없습니다. TPU 백엔드는 KV Head를 필요한 Rank에 복제해 불필요한 All-to-All 통신을 피하고, 높은 동시성에서는 DP8과 EP8을 결합해 요청별 KV cache를 로컬에 유지하면서 512개 Routed Expert를 분산했습니다. 이 구조는 요청 할당, Recurrent State Slot, Block Table을 함께 조정해야 하며, attention 계산과 Expert 계산의 병렬 축을 하드웨어에 맞게 분리합니다.
MoE 통신에서는 Expert ID와 Routing Weight를 별도의 All-Gather로 보내던 경로를 하나로 합쳐 DeepSeek-V3 측정에서 레이어당 약 80마이크로초를 절약했습니다. 58개 레이어에 적용하면 한 번의 Forward Pass에서 약 4.64밀리초가 줄어들며, ReduceScatter는 SparseCore와 Ironwood의 Die-to-Die 링크를 활용해 TensorCore의 행렬 연산과 통신을 겹칩니다. Grouped Matmul에서는 유효한 행 수만 전송하고 Expert Weight를 Triple Buffering하며, Expert 입력 재배열을 SparseCore로 옮겨 원래 커널 대비 8k1k 처리량을 12% 높였습니다.
Gated DeltaNet은 KV History 대신 요청마다 고정 크기의 Recurrent State를 유지하므로 Qwen3.5의 Hybrid State 관리가 핵심 과제가 됩니다. Decayed State의 현재 출력 계산과 다음 토큰을 위한 State Update를 MXU와 VPU에서 겹치고, Conv1D와 GDN을 하나의 커널로 융합해 HBM 왕복을 줄인 결과 커널 수준에서 Decode 1.41배, Prefill 1.60배, Mixed Batch 2.14배의 속도 향상이 측정됐습니다. Recurrent State를 활성 요청당 한 슬롯으로 압축하면 약 76GiB의 HBM을 회수하고 Attention Block Pool을 71% 확장할 수 있으며, 해당 구성에서 1k8k 출력 처리량이 동시성 64에서 18% 증가했습니다.
TPU의 256×256 MXU는 이전 세대의 128×128 배열보다 사이클당 MAC 수가 네 배 많지만, 행렬 차원이 타일 크기와 맞지 않으면 빈 셀도 함께 계산합니다. 예를 들어 Attention Head Dimension이 128인 Llama 3 8B는 Ironwood에서 두 Attention Matmul의 MXU 활용률이 최대 50%로 제한되고, 64이면 25%까지 낮아질 수 있습니다. 따라서 모델의 Head Dimension, Sharded KV Head 수, MoE Expert Width를 정할 때 평가 점수뿐 아니라 TPU 타일 기하와 패딩 비용을 함께 고려해야 합니다.
Ironwood는 칩당 2개의 TensorCore와 4개의 SparseCore를 갖고, 두 Compute Die를 Die-to-Die 링크로 연결하며, ICI 3D Torus를 통해 최대 9,216개 칩 규모의 Superpod으로 확장됩니다. 4×4×4 큐브를 기본 단위로 삼고 Optical Circuit Switches로 큐브 사이를 연결하는 방식은 호스트 CPU와 PCIe를 거치지 않고 칩 사이에서 직접 Activation과 Gradient를 이동시킵니다. 다음 세대 TPUv8i의 Boardfly는 비슷한 규모에서 네트워크 Hop 수를 약 16에서 약 7로 줄이고 ICI 대역폭을 19.2Tb/s, 온칩 SRAM을 384MB로 늘려 MoE와 Agentic Workload의 Tail Latency 및 KV cache 접근을 겨냥합니다.
외부 TPU 생태계의 다음 단계는 Speculative Decoding, Prefill-Decode Disaggregation, KV cache Offloading, AgentX용 다중 턴 지원, Kimi K3·GLM 5.3·Gemma 4 같은 추가 모델의 TorchTPU 지원입니다. Speculative Decoding은 Decode가 HBM 가중치 읽기에 묶이는 동안 유휴 MXU 계산을 여러 토큰 검증에 사용하고, TPU-Sync와 Mooncake Store는 TPU 사이의 KV cache 전달과 DRAM·NVMe Pooling을 담당합니다. TorchTPU가 vLLM과 SGLang에 안정적으로 통합되고 모델별 커널이 축적되면 TPU 지원을 특정 모델의 사후 포팅이 아니라 공개 모델의 초기 지원에 가깝게 가져가는 것이 목표입니다.
용어 해설
- 달러당 성능(Performance per Dollar)
- — 하드웨어의 절대 처리량이 아니라 같은 비용으로 얼마나 많은 토큰을 처리하는지 나타내는 지표입니다. 시간당 비용과 토큰 처리량을 함께 계산하므로, TPU처럼 최고 처리량이 GPU보다 낮아도 시간당 임대료나 총소유비용이 낮으면 우위를 확보할 수 있습니다. 실제 서비스의 인프라 투자 효율을 비교할 때 사용됩니다.
- 총소유비용(Total Cost of Ownership)
- — 칩 가격만이 아니라 서버 구성, 전력, 냉각, 네트워크, 운영 기간을 포함해 가속기를 사용하는 전체 비용을 추정하는 방식입니다. 이 글에서는 외부 구매자가 부담하는 TPU TCO와 Google 내부 작업에 적용한 칩 시간당 비용을 나누어 GPU와 비교합니다. 비용 곡선의 위치가 TCO 가정에 따라 크게 달라지는 이유를 설명하는 기준입니다.
- StableHLO
- — PyTorch나 JAX에서 생성된 연산 그래프를 컴파일러가 처리할 수 있도록 표현하는 중간 표현입니다. TorchTPU에서는 PyTorch 연산이 StableHLO로 낮아진 뒤 XLA를 거쳐 TPU 실행 파일로 변환됩니다. 따라서 사용자 인터페이스는 PyTorch에 가깝게 유지하면서 TPU용 컴파일 경로를 활용할 수 있습니다.
- Mixture-of-Experts
- — 모델의 모든 Expert를 매 토큰마다 실행하지 않고 Router가 일부 Expert를 선택해 계산량을 줄이는 구조입니다. 선택된 토큰이 Expert별로 불규칙하게 모이기 때문에 라우팅, 재배열, Grouped Matrix Multiplication, 결과 결합이 주요 병목이 됩니다. 이 글은 SparseCore와 TensorCore의 역할을 나누어 MoE 처리를 최적화합니다.
- Speculative Decoding
- — 작은 Draft 모델이 여러 토큰을 먼저 추측하고 큰 모델이 한 번의 Forward Pass에서 추측 결과를 검증하는 추론 기법입니다. Decode가 가중치를 HBM에서 읽는 메모리 대역폭에 묶일 때, 유휴 상태인 행렬 연산 자원을 여러 토큰 검증에 사용해 한 번의 가중치 읽기 비용을 분산합니다. 검증에서 살아남은 토큰은 원래 모델이 생성했을 결과와 같으므로 품질 저하 없이 처리량을 높이는 것이 목표입니다.
- Prefill-Decode Disaggregation
- — 입력 문맥을 처리하는 Prefill과 새 토큰을 순차 생성하는 Decode를 서로 다른 TPU 풀에서 실행하는 구조입니다. 두 단계의 계산 특성과 부하에 맞춰 각각 독립적으로 확장하고 조정할 수 있으며, KV cache를 풀 사이에서 전달해야 합니다. Google은 TPU-Sync와 llm-d 지원을 통해 이 내부 운영 방식을 외부 TPU 스택으로 옮기고 있습니다.
기술
- TPUv7 Ironwood
- B200
- B300
- GB300 NVL72
- Qwen3.5 397B
- vLLM
- SGLang
- TorchAX
- TorchTPU
- PyTorch
- JAX
- Pallas
- StableHLO
- XLA
- TorchDynamo
- AOTAutograd
- FX graph
- SparseCore
- TensorCore
- MXU
- HBM
- FP8
- FP4
- TPU-Sync
- llm-d
- Mooncake Store
- WEKA
- VAST
활용 사례
- Qwen3.5 397B 기반 단일 토큰 LLM 추론
- 고동시성 MoE 모델 Serving
- 긴 문맥과 높은 Prefix Reuse를 갖는 다중 턴 Agentic Workload
- Prefill과 Decode를 분리한 대규모 추론 서비스
- KV cache를 DRAM·NVMe Pool로 확장하는 장문 대화 서비스
- vLLM과 SGLang에서 PyTorch Native TPU Serving
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 09. 08.수집 2026. 09. 09.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
