System Design Space

    Глава 179

    Обновлено: 16 февраля 2026 г. в 03:00

    История появления Google TPU и их эволюции

    Прогресс части0/16

    Как Google прошла путь от TPU v1 для инференса до Ironwood: архитектурные решения, экономика AI-инфраструктуры и сравнение с GPU-подходом.

    Primary source

    book_cube TPU series

    Двухчастный разбор появления TPU и эволюции поколений.

    Открыть пост

    Эта глава собрана на основе ваших постов и официальных материалов Google: как TPU возникли из инфраструктурного bottleneck, зачем Google понадобился ASIC-подход и как архитектура эволюционировала от inference-чипа к платформе для крупномасштабного обучения и обратно к inference-first в эпоху GenAI.

    Почему TPU вообще появились

    Дать кратный прирост price/performance для ML-инференса по сравнению с доступными CPU/GPU.

    Сделать решение быстро и ввести в прод в сжатые сроки.

    Сохранить экономическую эффективность при росте ML-нагрузок в продуктах Google.

    Эволюция TPU по поколениям

    2015

    TPU v1

    Инференс
    • Разработка за ~15 месяцев от старта до deployment.
    • 28-нм техпроцесс, 700 МГц, ~40 Вт.
    • Ориентир: 92 TOPS INT8, заметный скачок энергоэффективности.
    2017

    TPU v2

    Обучение + инференс
    • Переход от «чипа для inference» к train+infer платформе.
    • TPU Pod с сетью из 256 чипов.
    • Порядок величин: 180 TFLOPS, 64 GB HBM (по источникам главы).
    2018

    TPU v3

    Рост производительности
    • Введено жидкостное охлаждение.
    • Существенно повышены compute и memory bandwidth.
    • Порядок величин: до 420 TFLOPS (по источникам главы).
    2021

    TPU v4

    Масштабирование pod-сетей
    • Оптическое circuit switching для ускорения межчиповой коммуникации.
    • Фокус на распределенное обучение моделей крупного масштаба.
    • Порядок величин: 275 TFLOPS на чип (по источникам главы).
    2023

    TPU v5e / v5p

    Оптимизация стоимости
    • Упор на cost-efficient training/inference.
    • Улучшение энергоэффективности и масштабирования подов.
    • Поддержка разреженности и более гибких workload-профилей.
    2024

    TPU v6 Trillium

    Скачок производительности
    • До 4.7x вычислительного роста на чип vs TPU v5e (по данным Google).
    • Удвоение HBM-емкости/пропускной способности и interconnect bandwidth.
    • На ~67% выше энергоэффективность vs TPU v5e (по данным Google).
    2025

    TPU v7 Ironwood

    Инференс эпохи GenAI
    • Возврат к идее inference-first, как у TPU v1, но на новом масштабе.
    • До 9,216 чипов в liquid-cooled кластере.
    • Порядок величин: 4,614 TFLOPS/чип, 192 GB HBM, 7.37 TB/s memory bandwidth.

    TPU vs GPU: как читать сравнения

    Compute и memory profile

    GPU обычно универсальнее, TPU сильнее оптимизированы под тензорные workloads и тесно интегрированы с Google Cloud стеком.

    Экономика

    В ряде источников по training/inference TPU показывают лучшую стоимость на workload, но оценки сильно зависят от модели, batch size и уровня оптимизации.

    Экосистема

    CUDA-экосистема у NVIDIA шире; TPU выигрывают в сценариях, где команда уже строит пайплайн на TensorFlow/JAX и managed-инфраструктуре GCP.

    Важный практический момент: сравнение FLOPS/токенов/доллара без общей методики легко дает искажения. Смотрите на модель, precision, batch, interconnect, software stack и ограничения по эксплуатации.

    Сильные и слабые стороны TPU-подхода

    Плюсы

    • Специализация под тензорные операции и глубокое обучение.
    • Высокая энергоэффективность и сильная TCO-экономика в ряде AI-сценариев.
    • Глубокая интеграция с Google Cloud, TensorFlow и JAX.
    • Хорошая масштабируемость через TPU Pod-подход.

    Ограничения

    • Доступность в основном через Google Cloud.
    • Меньшая универсальность для нетипичных вычислительных нагрузок.
    • Экосистема инструментов в целом уже, чем вокруг CUDA.
    • Риски vendor lock-in при глубокой привязке архитектуры к TPU-специфике.

    Что взять в собственный System Design

    • Планируйте hardware-strategy как часть архитектуры продукта, а не как «деталь инфраструктуры».
    • Оптимизируйте не только model quality, но и стоимость цикла обучения/инференса.
    • Закладывайте portability-слой, чтобы снижать риск vendor lock-in.
    • Считайте эффективность end-to-end: модель + interconnect + software stack + эксплуатация.

    Смежные главы: Зачем знать ML и AI инженеру, CPU vs GPU, Google Global Network, Performance Engineering.

    References

    Все численные сравнения в этой главе приведены как ориентиры из указанных источников и требуют валидации под конкретный workload.