Технічний контекст
Я подивився анонс Google і одразу відзначив головне: вони більше не продають ідею одного універсального чипа. Восьме покоління TPU одразу розділили на TPU 8t для навчання та TPU 8i для інференсу. Для тих, хто займається AI implementation та збирає агентні пайплайни, це дуже розумне розгалуження.
TPU 8t заточений під великі тренування. Google заявляє суперпод до 9600 чипів, 121 ExaFLOPS у native FP4 та 2 ПБ загальної HBM-пам'яті. Плюс удвічі вища міжчипова пропускна здатність порівняно з минулим поколінням і 19,2 Tbps scale-up, тобто вони явно б'ють не тільки по compute, але й по старій проблемі з вузьким місцем на обміні даними.
TPU 8i мені здався навіть цікавішим. Там 288 ГБ HBM, 384 МБ SRAM на кристалі, окремий Collectives Acceleration Engine та обіцянка до 5 разів нижчих затримок на глобальних операціях. Для агентних систем, де модель не просто відповідає, а виконує кілька кроків міркування, викликає інструменти та тримає контекст, це вже не маркетингова дрібниця, а цілком прикладна річ.
Ще один важливий момент: Google явно будує вертикально зібрану AI architecture навколо своїх Axion Arm CPU, NUMA, мережевої топології Boardfly та власної cloud-інфраструктури. TPU 8i масштабується до 1152 чипів, 8t до 9600, і вся історія виглядає як спроба прибрати дві стіни одразу: дороге тренування та повільний інференс. Цифра про 80% better performance-per-dollar звучить агресивно, але без відкритого прайсу я б поки сприймав це як орієнтир, а не як підсумкову економіку проєкту.
Що це змінює для бізнесу та автоматизації
Якщо говорити без фанфар, виграють ті, хто будує важкі мультимодальні системи та агентний інференс у Google Cloud. Особливо там, де важлива не одна красива демка, а стабільна automation with AI під навантаженням: сапорт, аналітика, оркестрація внутрішніх процесів, copilots з інструментами.
Програють команди, які хочуть максимальну переносимість між хмарами та стеком NVIDIA/CUDA. Тут інтеграція сильна, але ціна за неї очевидна: щільна прив'язка до GCP.
На практиці це штовхає архітектурні рішення до поділу контурів: окремо тренування, окремо low-latency serving. Ми якраз такі вузькі місця й розбираємо у клієнтів у Nahornyi AI Lab: де впираємося в latency, де у вартість кроку агента, де в пам'ять, а де проблема взагалі не в моделі, а в кривій обв'язці.
Якщо у вас агент уже замислюється довше, ніж співробітник встигає зробити завдання руками, це гарний момент перезібрати систему. У Nahornyi AI Lab я допомагаю зробити AI automation без зайвого залізного романтизму: дивлюся на ваш workflow, рахую економіку та збираю архітектуру, яка реально працює в проді.