Google TPU возник в 2013 году из расчёта: если каждый пользователь Android задействует voice search по 3 минуты в день, компании придётся удвоить мощности дата-центров. Стандартные CPU и GPU не справлялись с матричной математикой глубокого обучения, поэтому Google создал ASIC для TensorFlow. Проект прошёл от концепта до деплоя за 15 месяцев (2013–2014), к 2015 TPU уже ускоряли Maps, Photos и Translate, а в 2016 их анонсировали на I/O.

В отличие от универсальных GPU с «багажом» (кеширование, ветвления, текстуры), TPU — доменно-специфичный чип с systolic array: данные (веса) загружаются раз, проходят через сетку умножителей без возврата в память, минимизируя Von Neumann bottleneck и HBM-доступы. Новый Ironwood усилил SparseCore для эмбеддингов (рекомендации, LLM) и расширил HBM. TPU — ключевое преимущество Google Cloud на 10 лет, с фокусом на inference; обсуждаются производство, сравнения с GPU и влияние Gemini 3.

• Google's TPUs лидируют в эффективности inference и масштабе благодаря systolic array, OCS interconnects и низкой стоимости эксплуатации по сравнению с Nvidia GPUs.
• Скепсис по поводу исполнения Google: слабая экосистема (JAX/TF vs CUDA), история провалов продуктов и зависимость от ad-бизнеса.
• Nvidia доминирует за счёт универсальности, CUDA и оптимизаций (NVLink, NVFP4), несмотря на "architectural baggage".
• Упоминания альтернатив (Groq, Cerebras, Meta покупает TPU) и рисков: новые архитектуры AI могут устареть hardware, фокус на inference vs training.
• Google имеет ресурсы для доминирования через vertical stack и cloud, но короткий "attention span" вызывает сомнения.

Анализ трёх недавних проблем

С 17 сентября 2025 года

В период с августа по начало сентября три ошибки в инфраструктуре периодически снижали качество ответов Claude. Мы устранили эти проблемы и хотим объяснить, что произошло.

В начале августа пользователи начали сообщать о снижении качества ответов. Изначально эти сообщения было сложно отличить от обычных колебаний обратной связи. К концу августа участившиеся жалобы побудили нас начать расследование, которое выявило три отдельные инфраструктурные ошибки.

Мы никогда не снижаем качество модели из-за спроса, времени суток или нагрузки на серверы. Проблемы были вызваны исключительно ошибками инфраструктуры.

Хронология событий

Наложение этих ошибок значительно усложнило диагностику. Первая ошибка появилась 5 августа, затронув около 0,8% запросов к Sonnet 4. Две другие возникли 25-26 августа.

Изменение балансировки нагрузки 29 августа увеличило количество затронутых запросов, что привело к противоречивым отчетам пользователей.

Три перекрывающиеся проблемы

1. Ошибка маршрутизации контекстного окна

5 августа некоторые запросы Sonnet 4 перенаправлялись на серверы, настроенные для контекстного окна в 1 млн токенов. Изначально ошибка затрагивала 0,8% запросов, но к 31 августа эта доля выросла до 16%.

Около 30% пользователей Claude Code столкнулись с ухудшением ответов. На Amazon Bedrock пик затронутых запросов составил 0,18%, на Google Cloud Vertex AI — менее 0,0004%.

Решение: Исправлена логика маршрутизации. Фикс развернут 4 сентября, к 16 сентября распространен на основные платформы.

2. Повреждение вывода

25 августа ошибка конфигурации на серверах TPU вызвала сбой при генерации токенов. Это приводило к появлению неожиданных символов (например, тайских или китайских в ответ на английские запросы) или синтаксических ошибок в коде.

Проблема затрагивала Opus 4.1/4 (25-28 августа) и Sonnet 4 (25 августа - 2 сентября). Сторонние платформы не пострадали.

Решение: Выявлена и откатана ошибочная конфигурация.

• Критика отсутствия юнит-тестов и акцент на использовании эвалов для тестирования моделей.
• Удивление способностью Anthropic влиять на инфраструктуру AWS Bedrock, что противоречит обязательствам AWS.
• Обсуждение технических сбоев: ошибки маршрутизации запросов, коррупция вывода и баг компилятора XLA, повлиявшие на качество Claude.
• Высокое количество инцидентов, отмеченных на статусной странице Claude, и призывы к улучшению качества и надежности сервиса.
• Критика недостаточной прозрачности отчета Anthropic, включая отсутствие данных о степени деградации и компенсаций для пользователей.
• Обсуждение проблем недетерминированности в LLM и сложностей обеспечения воспроизводимости результатов.
• Спекуляции о причинах использования разных аппаратных платформ (TPU, AWS) и их влиянии на пользовательский опыт.

Google: жидкостное охлаждение TPU в дата-центрах
Вода проводит тепло в 4000 раз лучше воздуха, поэтому Google с 2018 г. развивает жидкостное охлаждение для TPU. Система масштабируется до стоек: шесть CDU-распределителей охлаждают жидкость, как насос-радиатор в ПК; один модуль всегда в резерве для обслуживания без простоя.

CDU переносит тепло из замкнутого контура с антифризом в фасилити-водопровод; жидкости не смешиваются. Циркуляция идёт последовательно через чипы, поэтому расчёт мощности ведут по самому горячему (последнему) элементу цепи.

Для TPUv4 применён bare-die cold plate без крышки, как «delid» у энтузиастов, что повышает теплоотдачу на 60 %.

• В обсуждении подчёркивается, что гипермасштабные дата-центры Google всё больше напоминают не «компьютерный», а «промышленный тепло- и водо-менеджмент» бизнес.
• Участники вспоминают, что жидкостное охлаждение применялось десятилетиями в мейнфреймах и HPC-кластерах, поэтому «новизна» Google вызывает споры.
• Поднимается вопрос утилизации тепла: от снабжения теплиц и бассейнов до городских систем отопления.
• Обсуждаются экономика и причины перехода на жидкостное охлаждение: рост плотности мощности чипов, дорогая площадь ЦОД и потери на вентиляцию.
• Некоторые участники критикуют Google за «истощение доверия» и считают описанные технологии «не особо новыми».

Что такое GPU
Современная ML-GPU (H100/B200) — это ~100–150 независимых вычислительных блоков (SM), каждый из которых содержит матричное ядро Tensor Core, векторные ALU (CUDA-ядра) и 256 КБ кэш SMEM. Все SM делят общий L2 и HBM3-память. SM разбит на 4 подблока; каждый подблок выполняет 32 SIMD-операции за такт. GPU-ядро менее мощное, чем TPU TensorCore, но их много, поэтому общая гибкость выше.

Память
H100: 80 ГБ HBM3, 3 ТБ/с. B200: 192 ГБ, 8 ТБ/с. L2 кэш 50 МБ (H100) / 128 МБ (B200). SMEM даёт 256 КБ на SM.

GPU vs TPU на уровне чипа
TPU: 1–2 больших MXU, жёсткая синхронизация, векторная часть слабее. GPU: 100+ мелких ядер, независимые SM, но общий L2 ограничивает масштаб. GPU лучше для разнородных задач, TPU — для чистых матмул.

Сеть внутри узла
Узел = 8 GPU + 2 CPU. GPU соединены NVLink/NVSwitch (900 ГБ/с между любыми двумя). CPU-GPU идут через PCIe 5.0 (64 ГБ/с). NVSwitch-кроссбар внутри узла = полносвязная сеть.

Сеть за пределами узла
InfiniBand HDR/NDR (до 400 Гб/с) или Ethernet RoCE. GPUDirect RDMA позволяет GPU читать/писать память соседнего узла без участия CPU.

Коллективные операции
Intra-node: NCCL использует NVLink; all-reduce 8×H100 за ~3 мкс.
Cross-node: кольцо IB + NVLink; latency ~10 мкс, bandwidth лимит IB.

Roofline-модель для LLM

• Data Parallelism: ограничен IB; эффективен при малых моделях.
• Tensor Parallelism: ограничен NVLink; лучше внутри узла.
• Expert/ Pipeline Parallelism: комбинируем; pipeline глубже → меньше bubble, но больше весов на каждом GPU.
• TLDR: держи параллелизм так, чтобы IB не стал bottleneck; используй NVLink для tensor-parallel, IB для data-parallel.

Итого
GPU — это масса мелких, независимых SM, связанных быстрым NVLink внутри узла и медленным IB между узлами. Для LLM выбирай параллелизм, который минимизирует IB-трафик и максимально использует NVLink.

• Критика точности: документация местами неточна, особенно в определении «CUDA-core».
• Открытость и вендор-лок: ряд участников считают инвестиции в проприетарную экосистему NVIDIA рискованной ставкой.
• Ошибка в расчётах: Quiz 2 преувеличивает пропускную способность; реальные 3,2 ТБ/с ограничены портами NIC.
• Похвала и польза: серия всё же хорошо объясняет принципы параллелизма, применимые и к другим устройствам.
• Сравнение TPU и GPU: TPU проще масштабировать, но закрыт для продажи; GPU NVIDIA гибче, но сложнее в программировании.
• Дефицит официальных данных: NVIDIA не раскрывает полную архитектуру, поэтому полезные модели приходится собирать из сторонних источников.