• Ведущие исследователи, включая одного из соавторов оригинальной статьи "Attention is all you need", открыто заявляют, что уходят от трансформеров и ищут «следующую большую идею», вызывая вопрос, действительно ли это поиск новой архитектуры или просто PR-ход.
• Участники обсуждения отмечают, что трансформеры стали не только архитектурой, но и целой инфраструктурой: от GPU и TPU до всего стека LLM-стека, что делает любую альтернативу экономически невыгодной.
• Некоторые комментаторы поднимают вопрос о том, что если следующий прорыв будет зависеть от новой архитектуры, то это может быть не только научный, но и экономический выбор, который может быть не в интересах общества или даже безопасности.
• Другие спорят, что фокус на трансформерах может отвлекать от других направлений, таких как обучение с подкреплением, которые могут быть более критически важны для AGI.
• И хотя некоторые участники высказывают, что трансформеры могли быть "пыльной доской" для следующего прогресса, другие считают, что они могут быть просто "сингуларностью в зародыше", и что мы должны быть осторожны в том, чтобы не убить золотую курицу, которая может быть просто медленно варится.

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

С 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 за «истощение доверия» и считают описанные технологии «не особо новыми».

Google и Meta заключили 6-летний контракт на облачные услуги стоимостью более $10 млрд. Ранее Meta в основном полагалась на AWS и Microsoft Azure, теперь расширяет партнёрство с Google Cloud. Сделка усиливает позиции Google в борьбе за крупных клиентов и отражает общий рост инвестиций в ИИ-инфраструктуру.

• Meta тратит $65B+ на собственные дата-центры, но пока они строятся, арендует мощности у Google как у «перестраховки».
• Сделка может быть просто объединением старых GCP-проектов в единый корпоративный контракт.
• Google нужен контракт, чтобы остановить отток клиентов и продемонстрировать спрос на свои TPUs.
• Meta ценит именно уникальные TPU Google, которых нет у AWS/Azure.
• Спор о «лучшем» облаке: одни считают GCP слабым, кроме BigQuery и Cloud Run, другие ставят GCP выше «ненадёжного» Azure.

Tiny-TPU: почему и как

Мы решились на безумное: собрать собственный TPU, не имея опыта в железе. Движимы желанием «переизобрести» ускоритель, а не копировать Google, мы пошли «кривым» путём: сначала пробуем самые простые идеи, потом читаем документацию. Цель — научиться думать без ИИ и понять, как устроены нейросети и чипы.

TPU — это ASIC, заточенный под матричные умножения (до 95 % вычислений в трансформерах). В отличие от GPU, он не умеет рисовать кадры, зато делает одно дело быстро и эффективно.

Как работает железо

• Тактовый цикл — базовая единица времени (пико-наносекунды). Всё происходит между «тиками».
• Verilog описывает логику:

  always @(posedge clk) c <= a + b;
  

  Регистры обновляются раз в цикл, а не мгновенно, как в софте.

Путь к игрушечному TPU

1. XOR-MLP 2→2→1 — разобрали вручную: прямой и обратный проходы, градиенты.
2. Философия — рисуем всё на бумаге, кодим без ИИ, проверяем «тупые» идеи.
3. Результат — работающий «той» TPU, который учится и выводит. Это не клон Google-TPU, а наша версия «как бы мы сделали».

Слайды и код: GitHub, Twitter, Drive.

• Проект описывает «игрушечный TPU», реализованный пока только в симуляции на Verilog.
• Участники обсуждают следующий шаг — запуск на FPGA (LiteX, отсутствие опыта пока не мешает).
• Вопросы о конечной цели: потребительские устройства, edge-вычисления или просто proof-of-concept.
• Некоторые советуют перейти с SystemVerilog на Chisel, как 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 не раскрывает полную архитектуру, поэтому полезные модели приходится собирать из сторонних источников.