Kubernetes Patterns (Рубрика #Architecture)

В последнее время я читаю много информации про Kubernetes для прохождения повторной сертификации.
Среди читаемого есть как мануалы с официального сайта, так и интересные книги с платформы O'Reilly и даже playbook'и от katacoda.com.
Но сегодня я решил всвпомнить про книгу "Kubernetes Patterns", которая не так полезна в сертификации, как в понимании того, какие абстракции дает K8s разработчикам в построеннии их сервисов.
По структуре книга напоминает классическую книгу “Design Patterns” банды четырех, которая содержала creational, structural и behavioral паттерны. Но у нас здесь 5 категорий паттернов:
- Foundation patterns - базовые блоки k8s, на основе которых строится все остальное
- Behavioral patterns - поведенческие паттерны, которые позволяют добиться желаемого поведения, например, запуска периодических job или приложения синглтона
- Structural patterns - структурные паттерны, которые показывают как можно расширить функционал основного контейнера добавив другие контейнеры в pod
- Configuration patterns - конфигурационные паттерны, которые позволяют эффективнее управлять конфигурацией ваших приложений
- Advanced patterns - продвинутые паттерны, которые раскрывают темы того, как работает сам k8s и как его можно расширять

Подробнее можно почитать в статье в моем блоге

#Software #Infrastructure #Kubernetes #Patterns #Architecture #DistributedSystems

Вчера я получил отбивку о том, что успешно сдал экзамен CKA (Certified K8s Administrator Exam) и сразу после этого решил написать обзор по отличному курсу подготовки к этому экзамену от Sander van Vugt. Курс доступен на платформе O'Reilly, в нем 11 часов видео и при большом желании его можно успеть посмотреть за 1 день. Краткий обзор курса в статье - https://bit.ly/CKAPrepCourse

А теперь кратко зачем я заморочился с изучением деталей K8s и сдачей экзамена, в котором надо решить 17 практических задач за 2 часа
Я считаю, что K8s достаточно интересно спроектирован
- декларативное описание целевого состояния вместо императивного
- концепция control loop’ов для поддержания состояния
- подход с тотальным decoupling частей k8s (labels и концепция селекторов)
- отличный способ для имплементации 12 factor app
- крутой пример проектирования с продумыванием точек расширения
...

Рекомендую изучение K8s для улучшения понимания как проектировать системы
#Kubernetes #Infrastructure #Architecture #Software #ExternalReview

Retrospective on "In-Datacenter Performance Analysis of a Tensor Processing Unit" (Рубрика #AI)

Интересная заметка на две страницы про то, как и почему появился TPU в Google, продолжая тему прошлого поста про железо для ML/AI. TPU оказался отличным решением и поддерживал продуктовизацию deep learning инициатив внутри Google уже 10 лет подряд, начиная с начала 2015 года, когда он появился в проде. Завтра будет заметка побольше про всю историю эволюции TPU, а для завтравки рекомендую прочитать этот мини whitepaper, где есть такое объяснение старту проекта

A key signal soon afterward was that matrix multiplication exceeded 1% of CPU fleet cycles in Google Wide Profiling. Another signal was the analysis by Jeff Dean (a Google Fellow, now the Chief Scientist) that processing a few minutes of speech or video by 100M users would require doubling or tripling the size of the CPU fleet. Other options were clearly required.

#AI #Infrastructure #Engineering #Architecture

[1/2] История появления Google TPU и их эволюции (Рубрика #Engineering)

Буквально вчера я рассказывал про доклад "CodeFest Russia: Куда катится железо для нейронок?", а сегодня я решил рассказать про то, как у Google появились свои процессоры для перемножения матриц. Собственно все начиналось еще в начале 2000х годов, когда Google активно внедряла ML модели к себе в продукты (поиск, переводчик, фото). Они делали это настолько успешно, что с появлением сложных нейронных сетей (а мы помним феерию с CNN сетями и ImageNet в 2012) захотели внедрить и их к себе в продукты, но вычислительная мощность как обучения, так и инференса расла экспоненциально. В 2013 году Google осознали, что если ничего не менять, то придется удваивать количество датацентров на существующем оборудовании (существующих тогда CPU и GPU). В итоге, ребята подумали и придумали проект создания TPU с такими целями
- Создать Application-Specific Integrated Circuit (ASIC), который обеспечит 10-кратное преимущество в соотношении стоимость/производительность при выполнении инференса по сравнению с GPU
- Построить решение быстро (ASAP или в сжатые сроки)
-Достичь высокой производительности на масштабе с новыми рабочими нагрузками "из коробки", оставаясь при этом экономически эффективным

Досталось рулить проектом Норману Джупи (Norman "Norm" Jouppi), выдающийся компьютерный архитектор и Google Fellow. Норман до этого успел отличиться в проектировании MIPS процессоров. А непосредственно до Google он он работал в HP Labs, где руководил лабораторией передовых архитектур. Интересно, что по словам Джонатана Росса, одного из первых инженеров TPU (впоследствии основателя компании Groq), три отдельные группы в Google разрабатывали ИИ-ускорители, но именно дизайн TPU был в итоге выбран для реализации.

Если говорить про результаты, то они получились хорошими, особенно, если учесть то, что уже доступна седьмая версия TPU. А вот как они выглядили в динамике (я ориентировался на статью "TPU transformation: A look back at 10 years of our AI-specialized chips" от Google Cloud)

1. TPU v1 (2015) - Инференс
Он разработан с рекордной скоростью - всего за 15 месяцев с момента начала проекта до развёртывания в дата-центрах Google в начале 2015 года. Такая скорость была достигнута благодаря использованию "устаревшего" 28-нанометрового техпроцесса и относительно низкой тактовой частоты 700 МГц, что позволило относительно просто уложиться в сроки. Энергопотребление было 40 Вт, а производительность 92 TOPS для 8-битных целых чисел. Этот процессор был предназначен только для инференса. Чип показал производительность в 15-30 раз выше, чем современные ему CPU и GPU, с 30-80-кратным преимуществом по энергоэффективности.
2. TPU v2 (2017) - Инференс + Обучение
Уже в конце 2014 года, когда TPU v1 находился в производстве, Google осознала, что возможность обучения становится ограничивающим фактором для создания моделей. TPU v2, представленный в 2017 году, стал революционным шагом — это была уже не просто микросхема, а полноценная суперкомпьютерная система. Ключевые нововведения TPU v2:
- Поддержка как обучения, так и инференса
- TPU Pod - сеть из 256 чипов TPU v2 с высокопропускной межсоединительной сетью
- Производительность: 180 TFLOPS
- Память: 64 ГБ HBM
3. TPU v3 (2018) - Жидкостное охлаждение
TPU v3 ввёл жидкостное охлаждение для эффективного управления теплом, что позволило работать на более высоких уровнях производительности. Производительность выросла до 420 TFLOPS, была улучшена межсоединительная сеть и пропускная способность памяти.

Продолжение истории в следующем посте.

#AI #ML #Software #Engineering #Architecture #Infrastructure #Data

[2/2] История появления Google TPU и их эволюции (Рубрика #Engineering)

Продолжу рассказ про TPU от Google с 2021 года, а точнее с TPU v4.
4. TPU v4 (2021) - Optical Circuit Switching
TPU v4 представил оптическое переключение цепей для ускорения связи между чипами, что критически важно для работы со всё более сложными ИИ-моделями. Производительность составила 275 TFLOPS на чип, с улучшенными оптическими межсоединениями.
5. TPU v5 и v5e (2023) - Оптимизация затрат
TPU v5e и v5p сфокусированы на экономически эффективном обучении на масштабе, с улучшенной энергоэффективностью, динамическим масштабированием и поддержкой разреженности.
6. TPU v6 Trillium (2024) - Оптимизация производительности
Trillium, шестое поколение TPU, предлагает впечатляющий скачок в 4.7 раза по вычислительной производительности на чип по сравнению с TPU v5e. А также обладает следующими характеристиками
- Удвоенная ёмкость и пропускная способность High Bandwidth Memory (HBM)
- Удвоенная пропускная способность межчиповых соединений
- На 67% более энергоэффективен, чем TPU v5e
- Масштабируется до 256 TPU в одном поде с низкой задержкой
7. TPU v7 Ironwood (2025) - опять инференс
Ironwood, представленный в апреле 2025 года, стал заново TPU, специально разработанным для инференса (как TPU v1). Революционные характеристики Ironwood:
- Масштабирование до 9,216 чипов с жидкостным охлаждением
- 42.5 экзафлопс вычислительной мощности (в 24 раза больше самого мощного суперкомпьютера El Capitan)
- 4,614 TFLOPS на чип с 192 ГБ HBM памяти (в 6 раз больше, чем у Trillium)
- 2-кратная энергоэффективность по сравнению с Trillium

Если суммировать то видно, что процессоры Google прошли большой путь. Правда, остается вопроса, а как они чувствуют себя в сравнении с NVidia? И ниже есть ответ на этот вопрос
- NVIDIA H100: 3,958 TFLOPS (FP8), 80 ГБ HBM3, пропускная способность памяти 3.35 ТБ/с
- NVIDIA H200: 3,958 TFLOPS (FP8), 141 ГБ HBM3e, пропускная способность памяти 4.8 ТБ/с
- TPU v6 Trillium: ~2 PFLOPS FP16 для тензорных операций
- TPU v7 Ironwood: 4,614 TFLOPS на чип, 192 ГБ HBM, 7.37 ТБ/с пропускной способности

Как видим по FLOPS все норм. А если смотреть на эффективность по независимым исследованиям, то TPU v5e показывает в 50-70% более низкую стоимость на миллиард токенов для обучения крупных моделей по сравнению с кластерами NVIDIA H100. TPU v5e также потребляет значительно меньше энергии, чем H100 для аналогичной рабочей нагрузки (H100 может потреблять в ~5 раз больше энергии, чем чип TPU v5e под нагрузкой). В реальных задачах показатели примерно такие
- Для обучения GPT-масштабных моделей: TPU более экономически эффективны в 4-10 раз по сравнению с GPU
- Для инференса: TPU v5e обеспечивает в 3 раза больше пропускной способности на доллар
- TPU v4 показал производительность 1.2-1.7 раза быстрее и использует 1.3-1.9 раза меньше энергии, чем NVIDIA A100

В итоге, у TPU есть как преимущества, так и недостатки
(+) Специализация для тензорных операций и глубокого обучения
(+) Высокая энергоэффективность и экономическая эффективность
(+) Интеграция с Google Cloud и оптимизация для TensorFlow/JAX
(+) Масштабируемость в экосистеме Google Cloud
(-) Доступность только через Google Cloud
(-) Меньшая гибкость по сравнению с GPU для различных типов вычислений
(-) Ограниченная экосистема разработки по сравнению с CUDA
(-) Меньший объём памяти на чип по сравнению с новейшими GPU (до недавнего времени)

Если подводить итоги, то кажется, что у Google все хорошо со своей линейкой процессоров для Gen AI / ML задач и они дальше продолжат отстраивать эту инфру, которая дает им значимое конкурентное преимущество в эпоху лета Gen AI приложений. А вот для остальных эти процессоры означают vendor lock при прямом использовании или ориентир, куда стоит стремиться, если смотреть в будущее.

#AI #ML #Software #Engineering #Architecture #Infrastructure #Data

[2/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Аспекты инженерной культуры (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta и поговорим про аспекты инженерной культуры, которая позволяет быть компании успешной. Если сокращать, то эти аспекты звучат так
- Принцип "Move fast"
- Открытость технологий
- Research in production
- Единая инфраструктура и стандартизация

А теперь давайте поговорим про каждый пункт подробнее.

Принцип "Move fast"
С первых дней в Facebook закрепилась культура быстрого развития и итераций. Это выражается в агрессивной практике непрерывного развёртывания ПО - новый код доставляется в продакшн как можно скорее. Большинство продуктовых сервисов пишутся в виде serverless функций на простых языках вроде PHP, Python, Erlang, что упрощает и ускоряет цикл разработки и деплоя изменений. Команды могут легко менять приоритеты и запускать новые продукты без долгих бюрократических процессов.

Открытость технологий
Meta придерживается открытой инженерной культуры как внутри, так и вне компании. Внутри действует единый монорепозиторий для всего кода, причём в большинстве проектов нет жёстко закреплённых владельцев - любой инженер может внести улучшения непосредственно, что поощряет переиспользование решений и кросс-командный вклад.Внешне компания делится разработками с сообществом: Meta открыто публикует аппаратные дизайны через проект Open Compute и открывает исходный код ключевых систем (таких как фреймворк ИИ PyTorch, база данных RocksDB, библиотека рекомендаций ReAgent и др.)

Research in production
В Meta нет отдельной академической исследовательской лаборатории по системам, а все инновации рождаются прямо в продуктах. Команды инфраструктуры постоянно внедряют новые решения и затем оформляют опыт в научные статьи. Такой подход гарантирует, что исследования сфокусированы на реальных проблемах и проверены в боевых условиях, что повышает практическую ценность и надёжность предлагаемых решений. Интересно, что во многих классических компаниях в отличие от Meta сделано по другому. Там отдельные RnD лабы публикуют материалы о космических результатах, которые найдены на кончике пера и еще не доехали на продакшен, а может никогда не доедут (так как все понимают, что в продакшен окружении они просто не работают)

Единая инфраструктура и стандартизация
В Meta стараются избегать разрозненных групп технологий - вместо этого продвигается глобальная оптимизация. На уровне аппаратуры все сервисы работают на унифицированном парке серверов: для вычислительных (не AI) нагрузок выбран один тип стандартного сервера (ранее с 64 ГБ RAM, теперь 256 ГБ). В отличие от облачных провайдеров, предлагающих множество конфигураций под любые клиентские нужды, Meta может сама оптимизировать своё ПО под ограниченный набор оборудования, избегая распыления на зоопарк железа. То же с софтом: разные продукты, бывало, применяли разные хранилища (Cassandra, HBase и собственный ZippyDB), но со временем все консолидировались на одном решении - ZippyDB для хранения пар «ключ-значение». Для каждой распространённой потребности (деплой, конфигурации, service mesh, тестирование производительности и т.д.) используется единый инструмент, принятый повсеместно внутри компании. Стандартизация дополняется модульностью: Meta предпочитает строить системы из переиспользуемых компонентов, а не как монолиты.

Все эти принципы демонстрируются через пример с запуском приложения Threads (конкурента Twitter/X) - 5 месяцев на разработкку небольшой командой и подготовка инфры за 2 дня до запуска, что прошел успешно.

В конце этой части приводится первый инсайт

Insight 1 : Despite many challenges, it is feasible for a large organization to maintain a culture of moving fast, using a common infrastructure, and sharing a monorepo without strictly enforcing code ownership.

В следующем посте мы поговорим про подходы к обработке пользовательских запросов.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[3/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Сквозная обработка пользовательских запросов (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1 и 2). Мы поговорим про обработку пользовательских запросов, которая спроектирована end-to-end для достижения нужного уровня качества (latency, scalability, reliability, ...) и стоимости.

Глобальная сеть и точки присутствия (PoP)
Чтобы минимизировать задержки, Meta динамически направляет запросы пользователя к ближайшему своему узлу. Когда пользователь открывает, например, facebook.com, DNS Meta возвращает IP ближайшего point of presence (PoP) - небольшого edge датацентра, который завершает входящее соединение от пользователя и проксирует трафик в основные регионы датацентров Meta по заранее установленным долгоживущим соединениям (внутри своей WAN сети). Это позволяет сократить время установления соединения и сбалансировать нагрузку между регионами

CDN и кеширование статичного контента
Если пользовательский запрос касается статического контента, то ответ может быть дан напрямую на уровне PoP, если там содержится свежий кеш. Meta также размещает кеш-серверы внутри сетей интернет-провайдеров при большом объёме трафика.

Маршрутизация динамических запросов
Если запрос не относится к статическому контенту (то есть требует генерации ответа на лету), PoP перенаправляет его во внутреннюю сеть Meta. Специальный балансировщик нагрузки в выбранном регионе ЦОД принимает входящий поток и распределяет запросы по фронтенд-серверам. В Meta фронтенд реализован как масштабируемый serverless слой: каждый пользовательский запрос обрабатывается отдельной фронтенд-функцией, которая может вызывать множество бэкенд-сервисов для составления ответа. Здесь появляется второй инсайт от автора статьи

Insight 2 : Meta’s global infrastructure consists of CDN sites, edge datacenters, and main datacenters. Because of the high volume of our internal cross-datacenter traffic, we have built a private WAN to connect our datacenters, rather than relying on the public Internet.

Асинхронная обработка и офлайн-вычисления
Для задач, не критичных к мгновенному ответу, широко применяется асинхронная обработка. Фронтенд-функции могут ставить события в очередь, которые будут обработаны отдельно специальными фоновыми функциями без блокировки ответа пользователю. Такие event-driven функции запускаются параллельно, их выполнение оптимизировано под пропускную способность (throughput), а не задержки (latency), и они не влияют на время ответа основного запроса. В то же время всё, что происходит при обработке запросов, генерирует огромные объёмы данных, которые непрерывно сбрасываются в хранилище данных (data warehouse). Дальше офлайн-системы Meta используют накопленные данные для пакетных и стриминговых вычислений, которые потом используются онлайн-сервисами при обработке новых пользовательских запросов. Здесь появляется третий инсайт от автора статьи

Insight 3 : Using a data warehouse as an intermediate layer to decouple online and offline processing simplifies the architecture and enables independent optimizations.

Это является ключевым принципом устойчивости и эффективности при гипермасштабе.

Топология и масштаб инфраструктуры
Масштаб инфраструктуры примерно следующий
- Регионов в компании десятки, в каждом регионе множество датацентров, в каждом из которых сотни тысяч серверов
- PoPs сотни, в каждом из них от сотен до тысяч серверов
- CDN site тысячи, в каждом из них типично десятки серверов, но иногда бывают и сотни
- MSB (main switchboards) - штука для секционирования питания внутри датацентров, их дюжины в датацентрах, типично MSB обслуживает десятки тысяч серверов

В следующем посте мы поговорим про подходы, что обеспечивают продуктивность инженеров Meta.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[4/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Повышение продуктивности разработки (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2 и 3). Мы поговорим про то, какие аспекты позволяют быть разработчикам внутри Meta более продуктивными.

Continuous deployment и автоматизация
Одной из главных целей общей инфраструктуры Meta является ускорение работы разработчиков. В компании довели до экстрима подходы CI/CD, добившись практически полного автоматического выпуска обновлений. 97% сервисов Meta разворачиваются без ручного участия инженеров - изменения поставляются через автоматические пайплайны деплоя (более 30к пайплайнов следят за обновлениями). Около 55% сервисов используют реально непрерывный деплой, остальные ~42% - развёртываются роботами по расписанию (как правило, ежедневно или еженедельно). Например, фронтенд-платформа Meta (serverless-функции, обслуживающие пользовательские запросы) релизится каждые три часа, а она работает на 500к+ серверов и ее код ежедневно меняют 10к+ разработчиков.

Конфигурация как код и мгновенные изменения
В Meta разграничение между “кодом” и “настройками” практически стёрто - конфигурационные изменения обрабатываются теми же конвейерами, что и программный код. Каждый день более 100к изменений конфигураций автоматически применяется на продакшене с помощью внутренней системы управления настройками. Они затрагивают порядка 10к различных сервисов и 1M+ запущенных процессов по всему миру (настройки параметров балансировки нагрузки, включение feature flags, настройки A/B тестов, ...). Практически каждый инженер Meta, пишущий код, также вносит правки в “живые” конфиги:
- Они хранятся в репе как код
- Проходят peer-review
- Раскатываются через CD pipelines
- Агенты по принципу publish-subscribe раскатывают изменения на сервисы
- Приложения применяют новые параметры на лету, без перезапуска процессов
Из этого следует четвертый инсайт статьи

Insight 4 : Even for a large organization with O(10,000) services, it is feasible to adopt continuous deployment at extreme scales and speeds. Specifically, 97% of our services adopt fully automated deployments without manual intervention, and 55% deploy every code change instantly.

Инструменты для качества и быстрого отката
Стремление “выпускать сразу” неизбежно повышает риски сбоев, поэтому в Meta разработаны многоуровневые средства для безопасного развертывания. Перед полным выкатом новый код проходит автоматические тесты и канареечные прогоны. В случае обнаружения проблем хорошо отлажены механизмы мгновенного отката до предыдущей стабильной версии.

Serverless functions как основа разработки
Более 10 000 разработчиков Meta используют FaaS ежедневно, а это устраняет необходимость в управлении инфраструктурой: код автоматически масштабируется и разворачивается и оптимально использует инфру. Использование FaaS интегрировано в IDE (облегчен доступ к социальному графу и бэкенд‑системам). FaaS - это stateless архитектура, которая опирается на внешние кэш‑системы и базы данных, что обеспечивает предсказуемое поведение и простоту горизонтального масштабирования.У Meta есть две FaaS платформы:
- FrontFaaS для обработки пользовательских запросов (PHP, Python, Erlang, Haskell) с low latency
- XFaaS для обработки асинхронных, событийных функций с резкими пиковыми нагрузками. Они оптимизируются через глобальный балансировщик, отложенное выполнение и квот‑троттлинг, чтобы избежать оверпровижининга.
Эту часть обобщает пятый инсайт

Insight 5 : Serverless functions have become the primary coding paradigm for product development at Meta. More than 10,000 Meta engineers write code for serverless functions, exceeding the number of engineers writing regular service code by 50%.

В следующем посте мы поговорим про то, как Meta уменьшает свои затраты на инфраструктуру.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[5/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Снижение затрат на оборудование (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3 и 4) и обсудим снижение затрат на инфру.

All global datacenters as a computer
Подход Meta к восприятию своей инфры отлично описывается очередным инсайтом

Insight 6 : Meta is evolving from the practice of “the datacenter as a computer” to the vision of “all global datacenters as a computer.” In this model, the infrastructure autonomously determines and migrates deployments across global datacenters in response to workload changes, eliminating the need for user involvement. We have successfully demonstrated this approach for databases, ML systems, and diverse services operating at the scale of O(100,000) servers and O(100,000) GPUs.

Hardware and software co-design
Но при этому появляется потребность в совместном проектировании софта и железа для него
- Graceful degradation: эффективная инфраструктура должна уметь адаптивно деградировать при экстремальных ситуациях, чтобы не держать постоянный избыточный запас мощности про запас. В Meta система Defcon умеет отключать функциональность по уровням приоритетности, освобождая ресурсы для ключевых сервисов
- Экономия на proxy в service mesh: в индустрии распространена архитектура service mesh с sidecar proxy per service, который перехватывает и маршрутизирует запросы. Meta разработала свою систему ServiceRouter (~1% RPC-запросов проходят через proxy, а 99% - маршрутизируются напрямую с помощью встроенной в каждый сервис библиотеки). Это экономит 100k+ серверов
- Многоуровневое хранение данных: чтобы оптимизировать расходы на хранение, данные разделяются на категории по частоте доступа и допустимой задержке
-- Горячие данные (соцграф, ленты, кеши) хранятся в высокопроизводительных системах (RAM + SSD)
-- Тёплые данные (фото/видео пользователей, кликстрим) хранятся в распределенной файловой системе Tectonic на обычных HDD-дисках (1 server ~36 HDD + 2SSD для metadata)
-- Холодные данные (оригинальные видео высокого качества) архивируются на ультраплотных storage-серверах с большим числом медленных дисков (1 server ~216 HDD)
- Локальные SSD вместо сетевых хранилищ: в индустрии облачных сервисов считается хорошей практикой выносить хранение отдельно на блочное устройство для простоты миграций и балансировки нагрузки. Но в Meta ради экономии и низкой latency предпочитают локальные SSD даже для stateful-сервисов, где это возможно. От этого возникают сложности, которые Meta решает централизованно через систему управления шардированием (Shard Manager), которая абстрагирует размещение фрагментов данных и обеспечивает автоматический ребаланс
- Дешёвое оборудование с надёжностью через софт: в публичных облаках оборудование часто дублируется, потому что приложения клиентов могут быть не готовы к сбоям. Meta выбрала противоположный подход - использовать более простое и дешёвое железо, но заставить всё ПО быть устойчивым к отказам. В итоге, очередной инсайт звучит так

Insight 7 : To reduce hardware costs, we use software solutions to overcome the limitations of lower-cost hardware. Although this approach adds complexity to the software stack, we consider the trade-off worthwhile due to the significant cost savings.

In-house hardware design
Для всего описанного выше Meta сама разрабатывает конструкции ЦОДов (Open Compute датацентры), а также значительную часть оборудования. Контроль над дизайном позволяет убирать всё лишнее и повышать эффективность (особенно эффективность использования электроэнергии, что сейчас является бутылочным горлышком для ДЦ)

Insight 8 : To reduce hardware costs and power consumption, Meta designs its own datacenters, servers, racks, and network switches, and shares these designs through open source.

В следующем посте мы поговорим про то, как инженеры в Meta проектируют свои системы.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[6/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Проектирование масштабируемых систем (Рубрика #Infrastructure)

В этом посте мы продолжим рассматривать крутую статью от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4 и 5) и обсудим как ребята подходят к проектированию масштабируемых приложений.

Централизация vs децентрализация
Инфраструктура планетарного масштаба исторически ассоциируется с децентрализованными архитектурами (BGP, BitTorrent, и т.п.). Они хорошо масштабируются без SPOF (single point of failure). Однако опыт Meta показал, что в пределах датацентра, где ресурсы относительно надёжны и управляются одной организацией, централизованные контроллеры зачастую упрощают систему и при этом обеспечивают достаточную масштабируемость. А часто это еще позволяет принимать более глобально оптимальные решения, чем множество локальных агентов. Поэтому Meta сознательно отошла от многих изначально распределённых дизайнов в сторону управляемых централизованно. Например,
- Внутренняя сеть ЦОД (Fabric) по-прежнему использует протокол BGP для совместимости, но маршрутизацией управляет центральный контроллер, который при перегрузках или обрыве линков переоптимизирует пути трафика взамен медленной сходящейся динамики BGP
- В магистральной глобальной сети (WAN) Meta изначально применяла децентрализованный протокол резервирования полосы (RSVP-TE), но затем перешла на центральный контроллер, рассчитывающий оптимальные пути для потоков между датацентрами и заранее прокладывающий резервные каналы на случай типовых отказов. Это позволило значительно эффективнее использовать пропускную способность каналов и упростило управление сетью.

В общем случае подход Meta можно сформулировать таким инсайтом

Insight 9 : In a datacenter environment, we prefer centralized controllers over decentralized ones due to their simplicity and ability to make higher-quality decisions. In many cases, a hybrid approach - a centralized control plane combined with a decentralized data plane-provides the best of both worlds.

В качестве примера подробнее разбирается гибридный service mesh под названием ServiceRouter (попытка получить “лучшее из двух миров”). ServiceRouter обслуживает миллиарды вызовов в секунду между микросервисами, распределёнными по миллионам программных маршрутизаторов уровня L7. В традиционных решениях service mesh (например, Istio) каждое приложение сопровождается локальным прокси, через который проходят все исходящие и входящие вызовы. В ServiceRouter Meta от этой схемы отказались (как упоминалось, ~99% запросов идут без sidecar-прокси). Вместо этого
- Control plane централизован - он агрегирует всю информацию о сервисах и глобальных метриках сети, вычисляет оптимальные правила маршрутизации и сохраняет их в RIB (outing Information Base), построенной поверх распределенной базы данных Delos с Paxos протоколом (то есть она распределена и отказоустойчива). Таким образом, центральные контроллеры ServiceRouter ответственны только за вычисление глобальных решений, а непосредическая работа по маршрутизации лежит на data plane.
- Data plane в виде отдельных L7 routers децентрализован - они автоматически подтягивают из RIB нужные им сведения (кэшируют небольшой необходимый поднабор) и работают автономно, без постоянного участия центрального координатора

Благодаря такому дизайну достигаются
- Простота управления - центрально видна вся картина
- Масштабируемость - нет узкого места, через которое прошёл бы весь трафик
В итоге, удаётся обеспечить полный функционал сервис-меша (балансировка, retries, discovery, мониторинг) при минимальном расходе ресурсов и с возможностью глобального оптимального распределения нагрузки.

В последнем посте из серии мы поговорим про будущие направления развития инфраструктуры и архитектуры Meta (это одна из самых интересных частей)

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

[7/7] Meta’s Hyperscale Infrastructure: Overview and Insights - Будущие направления развития (Рубрика #Infrastructure)

Этот пост финальный в рассмотрении крутой обзорной статьи от запрещенной в России компании Meta (предыдущие выпуски: 1, 2, 3, 4, 5 и 6). Здесь мы обсудим как автор видит дальнейшее развитие инфраструктуры, архитектуры и проникновение AI в системы компании. Отмечу, что эта часть была мне очень интересна - сложить пазл о том, как развивалась история это одно, а сделать качественное предсказание - это уже задачка со звездочкой.

AI и новая архитектура дата-центров
AI-нагрузки уже стали главным потребителем ресурсов Meta: к концу десятилетия они займут более половины мощностей ЦОД. В отличие от классических веб-сервисов, обучение моделей требует сотен терабайт данных, мощных GPU и сверхбыстрых сетей. Это ведёт к смене парадигмы — от scale-out (много дешёвых узлов) к scale-up, когда создаются крупные AI-кластеры, напоминающие суперкомпьютеры. Meta выстраивает полный стек под AI: от PyTorch и моделей до собственных чипов (MTIA), сетевых решений, хранилищ и систем охлаждения. Всё проектируется комплексно, чтобы работать синхронно. В будущем датацентры наполовину станут «машинами для обучения ИИ» - это изменит всю их архитектуру.

Эра специализированного железа
После эпохи унификации серверов начинается обратный процесс: расцвет кастомных ASIC и ускорителей. Гиперскейлеры могут позволить себе проектировать собственные чипы для AI-тренинга, компрессии, шифрования, видео-кодирования, In-Network-/In-Storage-Processing и т.д. Meta ожидает, что ЦОДы превратятся в гетерогенные кластеры из множества типов оборудования. Главный вызов - научить софт эффективно использовать столь разнородные ресурсы. Для этого потребуются новые уровни абстракций и оркестрации. Но выигрыш в энергоэффективности и стоимости на миллионах серверов окупит усилия.

Краевые датацентры и метавселенная
Meta прогнозирует бурный рост инфраструктуры на «краю» сети — мини-ЦОД, близких к пользователям. Это нужно для AR/VR, облачного гейминга и IoT, где критична задержка <25 мс. Компания строит модель Global Data-center-as-a-Computer: приложения будут автоматически выполняться там, где ближе пользователь, без участия разработчика. Архитектура станет многоуровневой - крупные регионы + сеть микро-ЦОД, объединённых общей системой оркестрации.

Прорыв в средствах разработки
Meta ожидает качественного скачка продуктивности инженеров за счет двух факторов
1. Массовое внедрение AI-ассистентов (Copilot, GPT-4 и др.), которые автоматизируют генерацию кода, поиск багов и рефакторинг и так далее
2. Появление вертикально интегрированных платформ, где разработчик описывает только бизнес-логику, а инфраструктура скрыта под капотом.
Пример - внутренний проект FrontFaaS, ускоряющий создание веб-интерфейсов. Похожие фреймворки появятся и в других доменах, радикально повышая индивидуальную продуктивность.

Совместное развитие
Автор подчёркивает: за 20 лет гиперскейлеры задали темп всей индустрии, и ИИ лишь ускорит этот процесс. Чтобы инновации распространялись быстрее, нужно делиться опытом. Meta призывает публиковать открытые проекты и исследования — как она делает сама. Статья служит именно этой цели: показать, из каких «кирпичиков» строится инфраструктура Meta и какие принципы могут вдохновить инженеров по всему миру.

В общем, это действительно качественная статья от Meta, которую было интересно прочитать. В будущем я планирую найти и разобрать похожие статьи и от других компаний.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #Software #DevEx #DevOps

ТОП-10 финтехов в мире по их капитализации (Рубрика #Fintech)

Я с большим интересом слежу развитием и планами мировых бигтехов, но внезапно понял, что не уделяю похожего внимания игрокам с более близкого мне рынка финансов. В этом посте я решил это исправить и рассказать про ТОП-10 финтехов. Для каждой компании приведены сведения о капитализации, годе основания, числе сотрудников, ключевых бизнес-продуктах, особенностях ИТ-инфраструктуры и планах развития. Получился такой список в формате: название (год основания), капитализация в млрд USD, штат, какой основной продукт (одним предложением), где инфра (своя vs cloud или гибрид), какой план развития

1. Visa (1958), 694 млрд USD,, 31k сотрудников, глобальная платежная система, 4 собственных ДЦ + интеграции с облаками для клиентов, рост за пределами карточного бизнеса
2. Tencent (1998), 607 млрд USD, 105k сотрудников, суперприложение WeChat с мобильными платежами и финуслугами, собственная облачная платформа Tencent Cloud + гиперскейл дата-центры, глобальная экспансия финтех-продуктов
3. Mastercard (1966), 529 млрд USD, 35k сотрудников, мультирейл платформа для карточных и мгновенных платежей, частное облако + AWS/Azure, рост с фокусом на open banking и аналитику
4. Intuit (1983), 185 млрд USD, 18k сотрудников, SaaS-платформа для налогов и бухгалтерии (TurboTax, QuickBooks), полностью в AWS, ставка для роста на генеративный ИИ
5. Stripe (2010), 91 млрд USD, 8.5k сотрудников, API-инфраструктура для онлайн-платежей и финуслуг, облачная архитектура (AWS), план расширения в офлайн и на международные рынки
6. Fiserv (1984), 88 млрд USD, 38k сотрудников, процессинг и IT-сервисы для банков и ритейла, гибридная ИТ-инфра (legacy + облако), план в модернизации платформ и экспансии POS-бизнеса
7. Ant Group (2014), 79 млрд USD, 16.6k сотрудников, Alipay и экосистема финуслуг в Китае, облако Alibaba + своя OceanBase, план экспансии вне Китая Alipay+ и финтех B2B-сервисов
8. PayPal (1998), 70 млрд USD, 24k сотрудников, глобальная система онлайн-платежей и кошелек (включая Venmo), гибридная ИТ (ДЦ + GCP/Azure), ставка на AI, крипто и офлайн-коммерцию
9. Nubank (2013), 63 млрд USD, 7.7k сотрудников, цифровой банк №1 в Латинской Америке, облако AWS, экспансия по ЛатАм и запуск финтех-платформы
10. Coinbase (2012), 62 млрд USD, 3.7k сотрудников, криптобиржа и кастодиальные сервисы, облачная архитектура + собственные ноды, глобальный рост и развитие Coinbase Cloud

Итого, видим, что у нас есть
- 2 компании старого толка с собственными ДЦ: Visa, Mastercard. Они живут в своих ДЦ + подключают облака или для удобства подключения клиентов или для новых нагрузок типа AI
- 2 компании с гибридным подходом: PayPal, Fiserv. Они сочетают свои серверы и облачные мощности. Например, PayPal переносит значительную часть сервисов в Google Cloud, оставаясь в гибридной модели
- 4 компании поверх облаков: Stripe, Nubank, Coinbase, Intuit. Первые три изначально строились как cloud-native, а последний переехал в облако в районе 2018 года
- 2 финтеха поверх бигтеха: Tencent (WeChat Pay) и Ant Group (AliPay). Они живут поверх облаков от своих бигтех родителей: Tencent Cloud и Alibaba Cloud, а значит могут практиковать вертикальную интеграцию, как hyperscalers

#Infrastructure #Architecture #Fintech #Strategy #Engineering #Software #DevOps

[2/3] Google's AI‑powered next‑generation global network: Built for the Gemini era - Вызовы на сети в эру AI (Рубрика #Infrastructure)

Продолжая рассказ про эволюцию сетей Google, стоит сказать, что сейчас они видят новый поворотный момент - взрывное развитие искусственного интеллекта, что предъявляет к сети беспрецедентные требования (например, обучение больших моделей резко меняют профиль нагрузки на сеть). На самом деле там есть целых четыре отдельных вызова, что приводят к изменению дизайн-принципов развертывания сетей

1. WAN как новая LAN
Обучение современных foundation models требует объединения тысяч TPU/GPU. И то, что раньше размещалось в пределах одного датацентра, теперь распределено географически (континент как датацентр - примерно тот же посыл у запрещенной в России Meta). Сеть должна масштабироваться на порядок больше прежнего, чтобы связать удалённые кластеры так, словно они в одном локальном сегменте. При этом трафик от распределённого обучения идёт всплесками, которые нужно эффективно обнаруживать и маршрутизировать без потери производительности.

2. Нулевая терпимость к сбоям
Процессы обучения моделей ИИ и крупномасштабный inference очень чувствительны к перебоям. Остановка обучения из-за сетевого сбоя - неприемлема из-за простев дорого железа. От сети теперь ожидают практически 100% доступности, без ощутимых перерывов, а значит сеть должна быть спроектирована так, чтобы любые отказоустойчивые механизмы срабатывали мгновенно и вообще не влияли на долгий процесс обучения.

3. Повышенные требования безопасности и контроля
Данные, на которых обучаются модели, и сами модели - ценный и чувствительный ресурс. Их нужно защищать как от утечек, так и от несанкционированных изменений. Кроме того, по мере распространения ИИ растут требования к соблюдению региональных регуляторных норм и к контролю данных "на лету" (в транзите). Сеть должна обеспечивать изоляцию, шифрование, соответствие политикам разных стран и компаний, чтобы ИИ-сервисы оставались надёжными и законопослушными.

4. Операционное совершенство при возросшей сложности
Масштаб, растущий на порядок, не может управляться по-старому. Google применяет лучшие практики SRE и уже использует машинное обучение для управления сетью, но теперь ставится цель минимизировать человеческий фактор. Сеть должна работать с минимумом ручного вмешательства, потому что линейное наращивание инфраструктуры иначе приведёт к неуправляемому росту сложности и затрат. Новые подходы требуются для автоматизации, быстрого выявления и устранения проблем, оптимизации емкости.

Отсюда появляются новые дизайн принципы сетей, которые мы обсудим в следующий раз.

#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign

[3/3] Google's AI‑powered next‑generation global network: Built for the Gemini era - Новые принципы дизайна сетей (Рубрика #Infrastructure)

Продолжая рассказ про эволюцию сетей Google, стоит рассказать про то как новые подходы к архитектуре сетей решает вызовы, озвученные в прошлом посте

1. Экспоненциальная масштабируемость
Сеть должна гибко выдерживать лавинообразный рост трафика и данных, особенно в регионах, где сосредоточены ИИ-вычисления. Принцип "WAN - это новая LAN" реализуется через отказ от монолитна в пользу горизонтального масштабирования (архитектура multi-shard network). Шарды независимы - у каждого свой набор контроллеров и каналов. Это позволяет параллельно наращивать пропускную способность - с 2020 по 2025 год пропускная способность глобального WAN Google увеличилась в 7 раз. Кроме того, такая сегментация упрощает управление: каждая «шардинговая» подсеть более контролируема по размеру.

2. Надёжность выше традиционных “пяти девяток”.
В индустрии обычно говорят о 99.9% или 99.99% доступности, но для критичных AI нагрузок выжны long tail выбросы (нужен детерминизм и бесперебойная работа сети). На практике сеть должна локализовать проблемы и автоматически их обходить до того, как пользователи или процессы заметят сбой. Для этого
- Шарды изолированы друг от друга (сбои не кореллируют)
- Дополнительно введена изоляция по регионам, чтобы локальные неполадки не каскадировались глобально
- Создана технология Protective ReRoute для быстрого обнаружения потерь связи и перенаправления трафика за секунды
После включения Protective ReRoute суммарное время простоев по инцидентам сократилось на до 93%.

3. Программируемость, управляемая намерениями (Intent-driven programmability)
Сеть Google обслуживает миллиарды пользователей и множество корпоративных клиентов с разными требованиями, например
- Кому-то критична задержка
- Кому-то важно шифрование
- А кто-то должен географически раскидывать данные (с учетом регуляторики)

Для удовлетворения таких разных требований ребята сделали сеть полностью программируемой (SDN) на основе высокоуровневых политик (intent), то есть созданы
- Единые модели представления сети (например, модель MALT - Multi-Abstraction-Layer Topology)
- Открытые API для управления
- Централизованные SDN-контроллеры, которые могут трактовать намерения операторов или приложений и применять их к сети.
Такая гибкость позволяет задать политики для конкретных приложений или данных (например, чтобы определённый тип трафика шёл только через узлы в заданной стране для соблюдения суверенитета данных, или чтобы критичные сервисы всегда имели резервные каналы). А высокоуровневое управление не требует ручного конфигурирования (как в SQL достаточно указать что нужно, а умная сеть подстроится под запрос)

4. Автономная сеть
Сети уже прошли путь вида: ручное управление -> автоматизированное (скрипты) -> автоматическое (по жестким правилам). Новая цель в том, чтобы сделать сеть самоуправляемой при помощи машинного обучения и "цифрового двойника", где модели постоянно обучаются на телеметрии.Так сеть сможет симулировать и предвидеть сбои, быстро локализовать причину неполадок и даже оптимизировать планирование ёмкости каналов на будущее.
После внедрения этих инструментов время реакции на сбой сократилось с часов до минут, что существенно повысило эффективность и устойчивость работы сети без участия человека.

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

В последнем посте мы сравним эту стать/ про инфру от Google и статью от запрещенной в России Meta.

#Software #DevOps #Architecture #Economics #DistributedSystem #SystemDesign

Meta looks to power trading supports its AI energy needs (Рубрика #AI)

В ноябре 2025 года стало известно о нетривиальном шаге запрещенной в России компании Meta, которая получила разрешение американских регуляторов на торговлю электроэнергией на оптовом рынке. Такой шаг призван удовлетворить стремительно растущий спрос ее центров обработки данных (ЦОД) на электричество для решений искусственного интеллекта (AI). По сути, Meta создает собственное направление энерготрейдинга, чтобы напрямую закупать электроэнергию, заключать долгосрочные контракты с электростанциями и при необходимости перепродавать излишки мощности на рынке. Интересно, что в документе "Meta’s Hyperscale Infrastructure: Overview and Insights", что я разбирал раньше, было рассказано как раз о энергии, как о главном лимитирующем факторе для датацентров и инфры (условно, железо можно и обновить, а вот новые мощности по питанию обеспечить сложнее)

Тезисы тут примерно такие
- Сейчас мы наблюдаем взрывной рост потребности в энергии для AI, которые требуют огромных вычислительных ресурсов
- Существующая энергосистема с трудом справляется с такими темпами роста нагрузки, что уже вызвало в отдельных регионах США рекордный рост цен на мощность на оптовых аукционах
- Традиционных подходов к закупке энергии недостаточно - разработчики новых электростанций нуждаются в “якорных” покупателях, готовых брать на себя долгосрочные обязательства по закупке энергии. Например, Meta для своего нового ДЦ в Луизиане потребовалось вкладываться в строительство трех газовых станций, чтобы запитать ДЦ (они закоммитились только на это потратить 1.6 млрд $)
- А закупая электричество оптом можно не только снижать издержки за счет оптовых закупок, но и получать прибыль в периоды избытка продавая её обратно в сеть по пиковым ценам

В итоге, Meta создала дочернюю компанию Atem Energy LLC и получила разрешение на торговлю электроэнергией оптом от федеральной комиссии по регулированию энергетики США (FERC). Компания планирует изначально сотрудничать с опытными партнёрами-трейдерами и сконцентрироваться на работе на рынке США

Интересно, что Meta пошла по стопам других корпораций, получавших аналогичные лицензии. На оптовом рынке уже есть Google Energy, Apple Energy, Energy LLC, Amazon Energy. В общем, Meta не прокладывает абсолютно новый путь, но масштаб её усилий в энергетике - один из крупнейших на сегодня в Big Tech.

Если подумать, то для инфраструктуры ЦОДов это может значить следующее
- Снятие энергетических ограничений на рост ИИ - раньше именно энергия была лимитирующим фактором
- Увеличение капитальных затрат на дата-центры - теперь при планировании новых центров обработки данных компаний уровня Meta или Google необходимо учитывать и строительство параллельной энергоструктуры (это приведет к росту стоимости ЦОД проектов)
- Дизайн будущих дата-центров - появляется стимул размещать их ближе к источникам энергии: например, строить кампусы рядом с зонами богатых ВИЭ-ресурсов (ветер, солнце) или возле действующих крупных электростанций, чтобы минимизировать нагрузку на сети.
- Новые стандарты надежности и устойчивости - включение дата-центров в активное управление энергопотреблением (через торги, регулирование нагрузки) повышает устойчивость энергосистем, но и задаёт новые стандарты самим ЦОД. Например, Google уже заключает demand response-контракты с энергокомпаниями, согласившись переносить часть вычислений на непиковое время во избежание перегрузок сети

В сумме, инициатива Meta сигнализирует всему ИИ-сектору: эры дешёвого и гарантированного электричества больше нет, и дальнейший прогресс ML/AI тесно увязан с энергетической инфраструктурой. Те, кто сумеют интегрироваться с энергосистемой (через инвестиции или партнерства), получат фору в гонке ИИ, а те, кто проигнорируют - рискуют столкнуться с энергетическим дефицитом, замедляющим их инновации.

#Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #AI #Economics

[1/2] How did we get to where we are in AI? (Рубрика #AI)

Пару недель назад Джефф Дин (Jeff Dean), Chief Data Science at Google, выступал в Stanford AI Club, где он приводил ретроспективу последних 15+ лет развития искусственного интеллекта. Он объяснял как сочетание трех факторов: масштабирования вычислений (scale), новых алгоритмов и специализированного железа привело к появлению современных больших мультимодальных моделей, таких как Gemini 3.0. Сам Джефф - это легендарная фигура в мире CS и software engineering, который с 1999 году работает в Google, сейчас он Chief Data Science, а вообще приложил руку к MapReduce, BigTable, Spanner, TensorFlow и сейчас к Gemini 3. Ниже представлен список whitepaper, который Джефф Дин выделил как ключевые точки развития технологий (в части из них он был соавтором)

2012 - Large Scale Distributed Deep Networks
До этого момента нейросети тренировались на локальных машинах. Дин и команда создали программную архитектуру для распределенного обучения на тысячах CPU. Это позволило тренировать модели в 50-100 раз больше, чем кто-либо до этого. В самом whitepaper говорится про использование параллелизма данных и моделей (Data/Model Parallelism) и асинхронного стохастического градиентного спуска.

2012 - Building high-level features using large scale unsupervised learning
В этом эксперименте нейросеть "смотрела" 10 миллионов случайных кадров из YouTube без разметки. В итоге, модель самостоятельно научилась распознавать концепции (например, кошек, человеческие лица) просто наблюдая за данными. Это доказало эффективность unsupervised learning на больших масштабах.

2013 - Distributed Representations of Words and Phrases and their Compositionality
В этой whitepaper речь шла про алгоритм Word2Vec для построения векторных представлений слов и переходом восприятия слова как дискретного значения к вектору в многомерном пристранстве. В итоге, оказалось, что слова с похожим смыслом оказываются рядом в векторном пространстве. Более того, арифметические операции над векторами сохраняют семантику (знаменитый пример: King - Man + Woman = Queen).

2014 - Sequence to Sequence Learning with Neural Networks
Авторы представили алгоритм Seq2Seq с использованием рекуррентных сетей (LSTM) для задач перевода последовательностей. Работало это примерно так: одна сеть кодирует входную фразу (например, на английском) в вектор, а другая декодирует его в выходную (например, на французском). Этот подход отработал хорошо и стал базой для машинного перевода на года.

2015 - Distilling the Knowledge in a Neural Network
Авторы описали метод сжатия знаний огромной модели в маленькую и быструю. Концепт был в том, что маленькая модель ("студент") учится не только на правильных ответах, но и подражая распределению вероятностей большой модели ("учителя"). Это позволяет запускать мощный ИИ на мобильных устройствах.

2017 - In-Datacenter Performance Analysis of a Tensor Processing Unit
Рассказ про то, как ребята в Google поняли, что надо придумать что-то вместо CPU и GPU для работы нейросетей. Так ребята решили делать TPU (tensor process unit), чью историю я разбирал отдельно. Сделали в 2015 и запустили, а рассказали про это в 2017. Ну и дальше Джефф еще вспоминает в лекции про конфигурируемый суперкомпьютер TPU v4: An Optically Reconfigurable Supercomputer for Machine Learning with Hardware Support for Embeddings, что сделали в 2017, а рассказли в whitepaper в 2023

2017 - Attention Is All You Need
Знаменитая статья, что принесла в мир революционную архитектуру трансформеров, что позволило отказаться от RNN (рекуррентных сетей) в пользу механизма внимания (Self-Attention). Концепт в том, что теперь модель может "смотреть" на все слова в предложении одновременно, а не по очереди - это позволяет балансировать куда ей обращать внимание + есть параллелизм по входу. Это обеспечило кратный рост скорости обучения и качества, став основой для всех современных LLM (GPT, Gemini, Claude).

Продолжение обзора во второй части.

#AI #ML #Software #Engineering #Architecture #Infrastructure #Data

[2/2] How did we get to where we are in AI? (Рубрика #AI)

Продолжая рассказ про выступление Джеффа Дина надо рассказать, а какие ключевые whitepapers выходили после Attention Is All You Need и дальше поделится выводами о том, где мы сейчас

2017 - Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer
Статья про распространенный сейчас подход с разряженными сетями или mixture of experts (MOE). В статье показывается как с помощью условного вычисления можно строить "возмутительно большие" сети с десятками и сотнями миллиардов параметров, почти не увеличивая вычислительные затраты по сравнению с обычными моделями.​

2018 - BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding
Авторы показали, что одну большую двунаправленную трансформерную модель можно один раз предобучить на сыром тексте, а потом с минимальными доработками дообучать под десятки разных NLP‑задач, получая state‑of‑the‑art без спецархитектур под каждую задачу.

2021 - An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale
В этой статье авторы применили подход трансформеров для классификации изображений. Интерес в том, что это можно делать без CNN - достаточно взять "чистый" трансформер и кормить ему изображение как последовательность элементов фиксированного размера (тот самый "16×16 слов" в названии).

2022 - Pathways: Asynchronous Distributed Dataflow for ML
Статья про асинхронный распределённый поток данных, когда вычисление задаётся как граф операторов, обменивающихся futures. А дальше единый контроллер может параллельно планировать и шедулить гетерогенные задачи на кластере TPU, скрывая зависимости в data‑plane и упрощая программную модель и управление ресурсами. В общем, это обеспечивает масштабирование вычислений на масштабе Google

2022 - Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
Открытие было в том, что модели лучше решают задачи, если просить их "подумать шаг за шагом". Если в промпте показать модели пример рассуждения, она начинает генерировать промежуточные шаги вычислений, что резко повышает точность в математике и логике.

Напоследок Джефф упоминает релиз новой модели Gemini 3.0, которая объединяет все предыдущие достижения, которые помогли ей выбить SOTA по многим бенчам.

В итоге, если посмотреть лекцию и полистать whitepaper, то можно сделать примерно следующие выводы
- Масштаб имеет значение. Прогресс последних 15 лет был обеспечен не только новыми идеями, но и грубой вычислительной мощностью. Рост количества параметров и объема данных неизменно приводил к появлению новых способностей (emergent capabilities), которых не было у маленьких моделей (например, понимание юмора или решение задач по физике).
- Специализация железа неизбежна. Универсальные процессоры (CPU) больше не являются драйвером прогресса. Будущее за специализированными чипами (как TPU), заточенными под низкоточную линейную алгебру. Энергоэффективность становится ключевым ограничением для дальнейшего роста моделей.
- Разреженные модели (Sparse Models) - путь к эффективности. Дин подчеркнул эффект перехода к архитектурам (таким как MoE), где для обработки одного запроса активируется лишь малая часть нейросети (1-5%). Это позволяет делать модели колоссальными по объему "знаний", но быстрыми в работе.
- Мультимодальность как стандарт. ИИ перестает быть просто "текстовым". Современные системы нативно понимают и генерируют видео, аудио и изображения. Пример из видео: модель может прочитать рукописные рецепты на разных языках, перевести их, сгенерировать картинки блюд и написать код готового веб-сайта.
- ИИ как помощник в науке и творчестве. Основное позитивное влияние ИИ ожидается в ускорении научных открытий (AlphaFold, материаловедение) и снижении порога входа в сложные навыки (программирование, дизайн).
- В развитии этой технологии существуют риски. Например, сгенерированный контент становится неотличимым от реального, и нужны технические и социальные механизмы защиты.

#AI #ML #Software #Engineering #Architecture #Infrastructure #Data

GigaChat 3 Ultra Preview - тяжёлый open source (Рубрика #AI)

Только сегодня дочитал статью Сбера про релиз GigaChat 3 Ultra, которая была опубликована еще в конце ноября на Хабре. Чтиво мне показлось интересным и заслуживающим изучения, но если кратко суммировать тезисы из статьи, то ребята выкатили новое поколение моделей с открытыми весами под MIT:
- GigaChat 3 Ultra Preview - флагманская MoE‑модель на ~702B параметров, из которых ~36B активны на шаге генерации. Это первая настолько большая, изначально русскоязычная open‑source‑модель такого масштаба, совместимая со стандартным OSS‑инструментарием (HuggingFace, vLLM, sglang и т.п.).
- GigaChat 3 Lightning - компактная ~10B‑MoE для локального запуска и быстрого дообучения.

Дальше внутри статьи ребята рассказали про отдельные моменты
- Данные
Pretrain‑корпус раздули до ~14 трлн токенов: 10 языков (от китайского до узбекского и казахского), много кода/математики и ~5,5 трлн синтетики (Q&A, reverse‑prompts, задачи по олимпиадному программированию и т.д.).
- Инфра для данных
Развернули собственный open‑source YT‑кластер: 10 000 ядер и >5 ПБ хранения, чтобы сэмплирование и токенизация выполнялись за минуты вместо дней. Вчера я был на конфе Giga Salut, где интересно пообщался с ребятами как раз на эту тему (с чего переезжали на YT и какие результаты были)
- Архитектура
Ultra - это огромная MoE‑модель, вдохновлённая DeepSeek V3: 256 экспертов, MTP (multi‑token prediction), MLA (multi‑head latent attention), полный стек, совместимый с существующими OSS‑тулзами для инференса и обучения.
- Обучение
Учить MoE модель было сложно: дикий объём коммуникаций между GPU, дисбаланс нагрузки по экспертам, инфраструктурный ад с чекпойнтами на 10+ ТБ и бенчмарками, требующими десятки GPU.
- Alignment
Общий конвейер выглядел так
-- Stage 1.5 - крупный диалоговый pretrain, чтобы модель нормально общалась;
-- RL по цепочкам рассуждений (Chain‑of‑Thought RL);
-- SFT на вручную вылизанных датасетах.
При этом Ultra Preview пока без этапа CoT‑RL.

Также в модель добавили B2C‑фичи: интерпретатор Python‑кода, переработанный поиск (по сути, готовый RAG‑слой) и долговременная память о пользователе.

В чем прорыв этого релиза
- Масштаб. GigaChat Ultra - крупнейший на сегодня open‑source‑LLM‑проект в России и Европе и одна из топ‑5 открытых моделей мира по числу параметров
- Обучение с нуля. Это не дообучение западной модели: веса и датасет - свои, модель нативно учится на русском и актуальных данных, без наследования чужих ограничений
- Совместимость со стеком OSS. Архитектура максимально приближена к DeepSeek V3, так что дообучение и деплой можно строить на уже существующих тулзах (vLLM, sglang, Megatron, Torchtitan и т.п.).
- Качество. Ultra уверенно обгоняет GigaChat 2 Max по ключевым бенчмаркам (MERA, MMLU‑Pro, GSM8K, HumanEval+ и др.) и лидирует в русскоязычных тестах. Но пока нет результатов большого количества других бенчей

В общем, ребята из Сбера - молодцы. Приятно видеть открытые релизы и техрепорты про технологии российских компаний.

#AI #ML #Software #Engineering #Architecture #Infrastructure #Data