Эта статья — авторский разбор первой главы книги Chris Fregly, «AI Systems Performance Engineering: Optimizing Model Training and Inference Workloads with GPUs, CUDA, and PyTorch», O'Reilly Media, 2026 (Copyright © 2026 Flux Capacitor, LLC).
Прямые цитаты из книги выделены отдельными блоками с пометкой «Цитата из книги». Всё остальное — оригинальный анализ автора статьи: прогнозы, оценка того, как эти прогнозы сыграли, практические выводы и визуализации. Цитаты приводятся в ограниченном объёме в целях обзора и критического анализа.
«В конце 2024 года китайский стартап DeepSeek.AI поразил AI-сообщество, обучив фронтирную большую языковую модель без доступа к самым современным GPU NVIDIA. Из-за экспортных ограничений инженеры DeepSeek не могли получить топовые ускорители Blackwell или Hopper, поэтому использовали локально доступные альтернативы, включая NVIDIA H800. Они применили собственные ядра и продвинутые методы оптимизации, чтобы выжать максимум из менее производительного железа».
«DeepSeek масштабировалась до тысяч ограниченных GPU, соединённых интерконнектами с пониженной пропускной способностью, используя новаторские программные и алгоритмические оптимизации для преодоления этих барьеров».
Кейс DeepSeek ценен не столько самим фактом «догнать и перегнать» фронтир на слабом железе, сколько тем, что он обнажает истинную иерархию узких мест в современных AI-системах. Когда у вас нет топовых GPU, вы перестаёте думать о FLOPS и начинаете думать о том, чего у вас действительно мало: о пропускной способности интерконнектов, о латентности коллективных операций, о времени простоя GPU в ожидании данных.
Именно этот сдвиг фокуса — с «сколько мы можем посчитать» на «как быстро мы можем передать данные между вычислениями» — и есть суть инженерной работы с производительностью. На топовом железе это узкое место часто маскируется избытком ресурсов. На ограниченном — оно выходит на первый план и требует настоящей инженерии.
В книге упоминается модель «~680-Billion Parameter» и стоимость обучения «<$6 млн». В технических отчётах DeepSeek-V3 фигурирует 671 млрд параметров, а стоимость обучения базовой модели V3 оценивается в $5,576 млн. Reasoning-вариант R1 — это отдельная модель, построенная поверх V3; её RL-фаза, по данным статьи в Nature (сентябрь 2025), обошлась в $294 тыс. и потребовала 512 GPU H800 на 80 часов. Полный стек V3+R1 — около $5,87 млн.
Ограниченный доступ к железу — не приговор. Ключевой ресурс при ограничениях — не FLOPS, а пропускная способность интерконнектов и качество коммуникаций. Инженерная работа над узкими местами может дать больше, чем замена железа.
Ожидалось, что экспортные ограничения надолго затормозят развитие китайских AI-лабораторий, а для обучения фронтирных моделей потребуется только топовое железо.
Прогноз не оправдался: DeepSeek-R1 показала сопоставимое качество рассуждений при кратно меньших заявленных затратах. Реакция рынка — падение акций NVIDIA на ~17% за день — подтвердила, что эффективность стала самостоятельным фактором финансового риска для производителей железа.
Не списывайте со счетов «второсортное» железо. Сначала оптимизируйте коммуникации, затем — вычисления. Замеряйте не только FLOPS, но и время простоя GPU в ожидании данных.
«Инженер по производительности AI-систем — это специализированная роль, сосредоточенная на оптимизации производительности AI-моделей и лежащих в их основе систем… Роль сочетает экспертизу в области аппаратного обеспечения, программного обеспечения и алгоритмов. Эти специализации должны проектироваться совместно (codesign)».
Формула «hardware + software + algorithms» на практике означает, что performance-инженер — это не «ML-инженер, который знает CUDA», и не «системный администратор, который разбирается в нейросетях». Это отдельная профессия, которая возникает на стыке трёх культур и говорит на трёх языках одновременно.
Практический тест на принадлежность к этой роли прост: если вы можете объяснить исследователю, почему изменение порядка операций в attention-слое ускорит обучение на 15%, а инфраструктурщику — зачем нужен новый драйвер NVIDIA, вы — performance-инженер. Если только одно из двух — вы специалист в смежной области.
Аппаратное обеспечение, программное обеспечение и алгоритмы
Performance-инженер — узловая роль: она связывает железо, софт и алгоритмы. Компетенции в одной области без двух других не дают полного эффекта.
Ожидалось, что по мере роста моделей роль будет становиться всё более востребованной, а требования к специалистам — расширяться в сторону междисциплинарности.
Прогноз подтвердился: спрос на performance-инженеров в AI-инфраструктуре растёт, а разрыв в зарплатах между «обычными» ML-инженерами и performance-инженерами увеличивается. Кейс DeepSeek показал, что именно такие специалисты дают кратный эффект при ограничениях.
Стройте T-образный профиль: глубокая экспертиза в одной области + широкое понимание двух других. Учитесь говорить с исследователями, инфраструктурой и DevOps на их языке.
«Для выявления узких мест нужно итеративно использовать NVIDIA Nsight Systems и NVIDIA Nsight Compute вместе с профилировщиком PyTorch. Важно настроить автоматизированные тесты производительности для выявления регрессий на ранних этапах цикла разработки».
Ключевое слово здесь — итеративно. Профилирование — это не отчёт, который делают один раз перед релизом, а непрерывный цикл: замер, гипотеза, изменение, повторный замер. Инженеры, которые относятся к профилированию как к разовому мероприятию, обычно оптимизируют не то, что нужно.
Второй важный момент — автоматизация регрессионных тестов. Производительность имеет свойство тихо деградировать: обновление библиотеки, рефакторинг кода, изменение драйвера — и вот уже throughput упал на 10%, а никто не заметил. CI-пайплайн с бенчмарками и алертами — это не «nice to have», а базовая гигиена production-системы.
Практическая рекомендация: начните с Nsight Systems — он показывает картину целиком (где GPU простаивает, где происходит синхронизация). Затем, когда нашли подозрительное ядро, переходите к Nsight Compute — он показывает детали: occupancy, memory throughput, warp stall reasons.
Профилирование — непрерывный цикл, а не разовое действие. Автоматизированные тесты производительности в CI ловят регрессии раньше, чем они дойдут до продакшена.
Предполагалось, что по мере усложнения стека (распределённые системы, MoE, mixed precision) роль автоматизированного профилирования и регрессионного тестирования будет только расти.
Прогноз оправдался: современные фреймворки (PyTorch, TensorRT-LLM) включают встроенные профайлеры и CI-пайплайны с бенчмарками. MLPerf стал де-факто стандартом воспроизводимых измерений.
Внедряйте профайлинг в CI с первого дня. Не оптимизируйте вслепую. Помните, что переписывание узкого места на C++ или перенос на GPU часто даёт больше, чем микрооптимизации в Python.
«Масштабирование небольших исследовательских нагрузок до крупных производственных на сверхмасштабных кластерах гарантирует, что при переходе от 8 GPU к 80 000 GPU система будет масштабироваться с минимальными накладными расходами. Это требует оптимизации коммуникации с использованием NCCL… NVIDIA Inference Xfer Library (NIXL) обеспечивает высокую пропускную способность, низкую задержку и точечную передачу данных».
Главный враг масштабирования — коммуникационные накладные расходы, а не нехватка FLOPS. Это становится очевидным при переходе от одного узла к кластеру: пока все GPU в одном NVLink-домене, коммуникации почти бесплатны. Как только трафик уходит за пределы домена — на InfiniBand или Ethernet — latency и bandwidth становятся доминирующим фактором.
Именно поэтому DeepSeek смогла обойти ограничения H800: они перепроектировали коммуникационные паттерны под топологию. Вместо стандартных коллективов NCCL они использовали кастомные ядра, которые координировали передачу данных параллельно с вычислениями (алгоритм DualPipe). Это не «оптимизация кода» в обычном смысле — это переосмысление того, как данные движутся по системе.
Практический вывод: прежде чем докупать GPU, убедитесь, что вы эффективно используете те, что есть. Часто 10% улучшения в коммуникациях дают больше, чем 20% дополнительных GPU.
Главный враг масштабирования — коммуникационные накладные расходы. NCCL и NIXL — базовые инструменты, а выбор стратегии параллелизма (DP / TP / PP / EP) определяется топологией кластера.
Ожидалось, что с ростом кластеров до десятков тысяч GPU коммуникация станет доминирующим фактором, и потребуются новые алгоритмы коллективных операций.
Прогноз подтвердился: появились NIXL, SHARP, NVLink Switch System на 72 и 576 GPU в одном домене. NCCL обзавёлся алгоритмами PAT и CollNet. Именно работа с коммуникациями позволила DeepSeek масштабироваться на H800.
Начинайте с топологии: знайте, где NVLink, где InfiniBand, где Ethernet. Не пытайтесь «заткнуть» коммуникации железом — сначала оптимизируйте алгоритмы коллективов (SHARP, PAT, дерево vs кольцо).
«Важно оптимизировать то, как модели используют ресурсы: ядра CPU, память GPU, пропускную способность интерконнектов и дисковый ввод-вывод… Такие техники, как NVIDIA Multi-Instance GPU [MIG], могут разделять ресурсы GPU для лучшего совместного использования».
GPU — не единственный ресурс, и не всегда главный. На практике узкое место часто оказывается на CPU-стороне: DataLoader не успевает готовить батчи, NUMA-миграции добавляют latency, дисковый I/O становится bottleneck. Инженеры, которые смотрят только на GPU-метрики, часто пропускают эти проблемы.
MIG и MPS — это инструменты повышения утилизации, а не «магическое ускорение». Если задача не загружает GPU целиком, MIG позволяет запустить несколько задач параллельно и поднять общую утилизацию. Но для tightly-coupled training-нагрузок, где все GPU должны работать синхронно, MIG скорее навредит.
GPU — не единственный ресурс. Память, интерконнекты, дисковый I/O и CPU-привязка влияют на итоговую производительность так же сильно. MIG и MPS — способы поднять утилизацию, когда задача не загружает GPU целиком.
Предполагалось, что по мере роста моделей проблемы с памятью и OOM станут более острыми, а MIG/MPS будут всё чаще использоваться для мультитенантности.
Прогноз оправдался: MIG и MPS стали стандартом для inference-кластеров, а управление памятью (PagedAttention, offloading, quantized KV cache) превратилось в отдельное большое направление оптимизации.
Привязывайте потоки к NUMA-узлам, где живут GPU. Мониторьте память фреймворка и избегайте фрагментации. Используйте MIG там, где задача не требует полного GPU. Не забывайте про CPU-сторону.
«Кросс-командное сотрудничество абсолютно критично. Важно работать рука об руку с исследователями, специалистами по данным и разработчиками приложений, а также с инфраструктурными командами… Инженер по производительности находится на стыке этих междисциплинарных доменов и говорит на языке AI, информатики и системной инженерии».
Этот раздел часто воспринимается как «мягкая» часть, но на практике коммуникация — такой же навык оптимизации, как и работа с CUDA. Многие перспективные оптимизации не доезжают до продакшена именно потому, что performance-инженер не смог объяснить исследователю, зачем менять код, или инфраструктурщику, зачем обновлять драйвер.
Практический приём: перед тем как предлагать оптимизацию, сформулируйте её в терминах, понятных собеседнику. Для исследователя — «это ускорит эксперименты на 20%, вы сможете проверить больше гипотез». Для инфраструктуры — «это снизит потребление энергии на 15% без потери производительности». Одна и та же оптимизация — разные аргументы.
Оптимизация почти всегда находится на пересечении команд. Один инженер не может «в одиночку» выжать максимум: нужны исследователи, инфраструктура, DevOps и storage-команда.
Ожидалось, что междисциплинарность будет расти, а роль performance-инженера — всё больше напоминать роль «технического дирижёра» между командами.
Прогноз подтвердился: в крупных AI-компаниях появились отдельные performance-команды, которые согласуют изменения между research, infra и product.
Учитесь говорить на языках соседних команд. Коммуникация — такой же навык оптимизации, как и работа с CUDA.
«В инженерии производительности жизненно важно измерять всё и доверять данным, а не предположениям. Публикуя свою работу, другие могут учиться, воспроизводить и строить на ваших находках… Во время Open-Source Week в феврале 2025 года DeepSeek выпустила набор open-source репозиториев на GitHub, включая FlashMLA, DeepGEMM, DeepEP, EPLB, DualPipe и Fire-Flyer File System (3FS)».
Открытые оптимизации DeepSeek — это готовая библиотека инфраструктурных решений, которую можно изучать и перенимать. FlashMLA, DeepGEMM, DeepEP, EPLB, DualPipe, 3FS — каждый из этих проектов решает конкретную задачу, с которой сталкиваются команды, работающие с большими моделями.
Но ещё важнее — методологический посыл: DeepSeek не просто заявила «мы обучили модель дёшево», а предоставила инструменты для воспроизведения. Это переводит разговор из плоскости «верю — не верю» в плоскость «проверяю и воспроизвожу». Именно так должна работать инженерия производительности.
MLPerf в этом контексте — отраслевой стандарт, который позволяет сравнивать железо и софт воспроизводимо. Цифры 2,6x и 3,4x на Blackwell vs Hopper — это не маркетинг, а результат стандартизированного бенчмарка, который можно повторить.
Улучшение пропускной способности обучения на GPU: GB200 NVL72 vs. Hopper
Улучшение пропускной способности инференса на GPU: GB200 NVL72 vs. Hopper
Открытые оптимизации DeepSeek — это готовая библиотека инфраструктурных решений. MLPerf — воспроизводимый стандарт для сравнения железа.
Ожидалось, что открытость ускорит развитие всей области и что отраслевые бенчмарки станут основным языком сравнения поколений железа.
Прогноз подтвердился: код DeepSeek был быстро разобран сообществом, а MLPerf v5.0 показал 2,6x и 3,4x прироста на Blackwell.
Публикуйте свои оптимизации и читайте чужие open-source проекты. Не доверяйте «vibe-оптимизациям» — измеряйте и воспроизводите.
«DeepSeek оказалась ограничена использованием GPU NVIDIA H800 из-за экспортных ограничений США. H800 — экспортно-совместимый вариант GPU Hopper. По сравнению с H100 он снижает пропускную способность интерконнекта NVLink и производительность FP64, сохраняя ёмкость HBM. DeepSeek поставила задачу обучить массивную MoE-модель… используя кластер из 2048 GPU H800. Эта MoE-модель активирует около 37 миллиардов параметров на входной токен… Для каждого токена DeepSeek-V3 использует 1 общего эксперта плюс 8 экспертов, выбранных маршрутизатором из 256 экспертов».
Ключевая идея кейса — разрежённость (sparsity) как способ уложить гигантскую модель в разумное железо. MoE с топ-9 из 256 экспертов даёт 671 млрд параметров при 37 млрд активных на токен. Это не «сжатие модели» — это архитектурное решение, которое позволяет модели иметь огромную ёмкость, но использовать только часть её на каждом шаге.
DualPipe — вторая ключевая инновация. Это алгоритм, который перекрывает вычисления и коммуникации так, чтобы GPU не простаивали в ожидании данных. На H800 с урезанным NVLink это критично: стандартные коллективы NCCL не успевают, поэтому DeepSeek написала кастомные ядра, которые координируют передачу данных параллельно с вычислениями.
Третий урок — холодный старт + RL для reasoning-модели. Вместо дорогого human feedback DeepSeek использовала минимальное количество размеченных данных и сделала ставку на обучение с подкреплением. Результат: R1 достигла уровня o1 при стоимости RL-фазы в $294 тыс. и 80 часах на 512 H800.
Mixture-of-Experts (MoE): выбор активных экспертов для каждого токена
MoE + топ-9 из 256 экспертов = 671 млрд параметров при 37 млрд активных на токен. DualPipe и кастомные CUDA-ядра позволяют обойти слабости H800. Холодный старт + RL — жизнеспособная альтернатива дорогому human feedback.
Ожидалось, что MoE станет доминирующей архитектурой для гигантских моделей, а RL-обучение reasoning-моделей будет смещаться от human feedback к автоматизированным схемам.
Прогноз подтвердился: MoE-модели (DeepSeek, Mixtral, Switch Transformer) стали нормой. RL-фаза R1 за 80 часов на 512 H800 показала, что reasoning можно «дообучать» дёшево.
Разрежённость (MoE) — не «модная фича», а способ уложить гигантскую модель в разумное железо. Изучайте DualPipe и подобные схемы перекрытия коммуникаций.
«Модели со 100 триллионами параметров — амбициозная веха, часто сравниваемая с примерными 100 триллионами синаптических связей в человеческом неокортексе… Для грубой оценки: плотная модель со 100 триллионами параметров, обученная на ~29 триллионах токенов, потребовала бы порядка 1,2 × 10²⁹ операций с плавающей запятой… Даже с разреженностью MoE это демонстрирует, что одной грубой силы недостаточно».
100 трлн параметров — это не просто «ещё в 100 раз больше». Это качественно другой уровень системных требований. Если для 1 трлн параметров ещё можно было использовать относительно стандартные подходы, то для 100 трлн нужно переосмыслить всё: хранение весов (200 ТБ только под веса), передачу данных, оптимизаторы (Adam утроит память — нужно искать memory-efficient альтернативы), activation checkpointing (обязателен), distributed checkpointing (обязателен).
Хорошая новость: направление понятно. MoE, FP4/NVFP4, memory-efficient оптимизаторы (Adafactor, Shampoo), distributed checkpointing — всё это уже исследуется и внедряется. Moonshot AI Kimi K2 (1 трлн параметров, 32 млрд активных) показал реалистичность MoE-подхода. FP4 и NVFP4 стали поддерживаться аппаратно.
Плохая новость: разрыв между «возможно» и «доступно» всё ещё велик. 100 трлн параметров потребуют кластеров на десятки тысяч GPU, гетерогенных сред, новых алгоритмов. Это работа не на один год.
100 трлн параметров — это ~10²⁹ FLOPs на обучение и ~200 ТБ только под веса. Решение — разрежённость (MoE), низкая точность, эффективные оптимизаторы, activation checkpointing и распределение по тысячам GPU.
Ожидалось, что к 100 трлн параметров человечество придёт не за счёт «грубой силы», а за счёт совместной эволюции железа, софта и алгоритмов.
Прогноз подтвердился: Moonshot AI Kimi K2 (1 трлн параметров) уже показал реалистичность MoE-подхода. FP4 и NVFP4 стали поддерживаться аппаратно. Оптимизаторы вроде Adafactor и Shampoo активно исследуются.
Не пытайтесь масштабировать «в лоб». Изучайте MoE, низкую точность, memory-efficient оптимизаторы и distributed checkpointing. Готовьтесь работать с кластерами на десятки тысяч GPU.
«NVIDIA построила новый класс AI-суперкомпьютеров для нагрузок масштаба триллионов параметров. NVIDIA Grace Blackwell GB200 NVL72 (2024) и GB300 NVL72 Ultra… NVIDIA называет эти стоечные системы "AI-суперкомпьютерами в стойке". Каждая стойка GB200 NVL72 объединяет 36 суперчипов Grace Blackwell, соединённых через NVLink с NVSwitch… Полная стойка GB200 NVL72 теоретически достигает ~1,44 эксафлопс для FP4… Потребление составляет около 120–132 кВт на стойку».
NVL72 — это смена парадигмы. Раньше масштабирование означало «добавить ещё узлов и соединить их сетью». Теперь стойка сама по себе является одним большим ускорителем с 72 GPU в едином NVLink-домене и ~130 ТБ/с совокупной пропускной способности. Это меняет всё: как вы думаете о параллелизме, как планируете данные, как строите inference-серверы.
Практическое следствие: если ваша модель помещается в один NVL72, вы можете использовать более агрессивные стратегии параллелизма (TP через все 72 GPU, EP с экспертами на разных GPU), которые были бы невозможны на традиционном кластере. Но это требует понимания топологии: где NVLink, где NVSwitch, где InfiniBand. Удалённый доступ к памяти через NVLink — неоднороден.
Энергопотребление ~130 кВт на стойку — это отдельный вызов. Жидкостное охлаждение становится обязательным, а планирование мощности — частью инженерной задачи.
NVL72 = 72 GPU в одном NVLink-домене с ~130 ТБ/с совокупной пропускной способности. 1,44 эксафлопс FP4, 30 ТБ памяти, ~130 кВт. Это новый класс систем, где стойка ведёт себя как один большой ускоритель.
Ожидалось, что такие системы станут строительным блоком «AI-фабрик» и что дорожная карта NVIDIA продолжит удваивать производительность и память каждое поколение.
Прогноз подтвердился: GB300 Ultra уже анонсирован, Vera Rubin и Feynman — на подходе. Облачные провайдеры предоставляют NVL72 по запросу, а NVLink Switch System позволяет объединять до 576 GPU в один домен.
Изучайте топологию NVL72: где NVLink, где NVSwitch, где InfiniBand. Учитесь использовать единый домен для DP/TP/PP/EP. Помните, что удалённый доступ к памяти через NVLink неоднороден.
«Термин "механическая симпатия" (mechanical sympathy), первоначально введённый инженером Мартином Томпсоном по аналогии с чемпионом Формулы-1 Джеки Стюартом… в вычислениях означает написание программного обеспечения, глубоко учитывающего особенности оборудования… Классический пример — FlashAttention, алгоритм, который перестраивает механизм внимания трансформера с учётом иерархии памяти GPU».
Механическая симпатия — это не «техника», а методология. Это способ думать о системе, при котором вы не просто пишете код, а спрашиваете: «Как это будет исполняться на конкретном железе? Где данные? Сколько раз они перемещаются? Какие блоки простаивают?»
FlashAttention (2–4x ускорение), DeepSeek MLA, Transformer Engine, FP4 + микрошкалирование — всё это примеры такого подхода. Каждый из них даёт кратный прирост, потому что перепроектирует алгоритм под конкретную архитектуру, а не пытается «универсально оптимизировать».
Добродетельный цикл «железо, алгоритмы, железо» ускоряется. Каждое поколение GPU добавляет новые числовые форматы и блоки (FP4, SFU для softmax), а алгоритмы (FlashAttention-3, MLA) сразу их используют. Разрыв между «просто запустить модель» и «выжать из неё максимум» растёт. Это одновременно и вызов, и возможность для инженеров.
Механическая симпатия — это методология: писать софт под конкретное железо. FlashAttention (2–4x), DeepSeek MLA, Transformer Engine, FP4 + микрошкалирование — всё это примеры такого подхода.
Ожидалось, что добродетельный цикл «железо, алгоритмы, железо» будет ускоряться, а совместное проектирование станет обязательным для фронтирных результатов.
Прогноз подтвердился: каждое поколение GPU добавляет новые числовые форматы и блоки, а алгоритмы сразу их используют. Разрыв между «просто запустить модель» и «выжать из неё максимум» растёт.
Изучайте железо до уровня иерархии памяти, Tensor Cores и SFU. Перепроектируйте алгоритмы под конкретные архитектуры — это даёт больше, чем «универсальные» оптимизации.
Инженерия производительности AI-систем — это дисциплина на стыке железа, софта и алгоритмов. DeepSeek доказала: при жёстких ограничениях именно глубокое понимание аппаратной иерархии и умение перепроектировать вычисления под неё позволяют достигать фронтирных результатов при кратно меньших затратах. Каждый из 11 блоков даёт конкретный урок: где оптимизировать, что прогнозировать и как это применять на практике. По мере движения к моделям в сотни триллионов параметров совместное проектирование перестаёт быть опцией и становится единственным путём вперёд.
Источники: Chris Fregly, «AI Systems Performance Engineering» (O'Reilly, 2026), Глава 1 — цитаты приводятся в ограниченном объёме в целях обзора и критического анализа. Технический отчёт DeepSeek-V3; публикации DeepSeek Open Infra Week; MLPerf Training/Inference v5.0; документация NVIDIA GB200 NVL72; Stanford AI Index; Nature (сентябрь 2025).
This article is an original analysis of Chapter 1 of Chris Fregly, «AI Systems Performance Engineering: Optimizing Model Training and Inference Workloads with GPUs, CUDA, and PyTorch», O'Reilly Media, 2026 (Copyright © 2026 Flux Capacitor, LLC).
Direct quotes from the book are marked with separate blocks labeled «Quote from the book». Everything else is the article author's original analysis: forecasts, assessment of how those forecasts played out, practical takeaways, and visualizations. Quotes are provided in limited volume for review and critical analysis purposes.
«In late 2024, the Chinese startup DeepSeek.AI stunned the AI community by training a frontier large language model without access to NVIDIA's most advanced GPUs. Due to export restrictions, DeepSeek's engineers could not obtain top-tier Blackwell or Hopper accelerators, so they used locally available alternatives, including the NVIDIA H800. They applied custom kernels and advanced optimization techniques to squeeze maximum performance out of less capable hardware».
«DeepSeek scaled to thousands of constrained GPUs connected by reduced-bandwidth interconnects, using innovative software and algorithmic optimizations to overcome these barriers».
The DeepSeek case is valuable not so much for the fact of «catching up to the frontier on weak hardware» as for the fact that it reveals the true hierarchy of bottlenecks in modern AI systems. When you don't have top-tier GPUs, you stop thinking about FLOPS and start thinking about what you actually lack: interconnect bandwidth, collective operation latency, GPU idle time waiting for data.
It is precisely this shift of focus — from «how much can we compute» to «how fast can we move data between computations» — that is the essence of performance engineering. On top-tier hardware, this bottleneck is often masked by an excess of resources. On constrained hardware, it comes to the fore and demands real engineering.
The book mentions a «~680-Billion Parameter» model and a training cost of «<$6M». DeepSeek-V3 technical reports cite 671B parameters, with base V3 training cost estimated at $5.576M. The R1 reasoning variant is a separate model built on top of V3; its RL phase, per a Nature article (September 2025), cost $294K and required 512 H800 GPUs for 80 hours. The full V3+R1 stack is about $5.87M.
Limited hardware access is not a death sentence. The key resource under constraints is not FLOPS but interconnect bandwidth and communication quality. Engineering work on bottlenecks can deliver more than replacing hardware.
It was expected that export restrictions would slow Chinese AI labs for a long time and that training frontier models would require only top-tier hardware.
The forecast did not hold: DeepSeek-R1 delivered comparable reasoning quality at a fraction of the claimed cost. The market reaction — NVIDIA stock down ~17% in a day — confirmed that efficiency has become an independent financial risk factor for hardware makers.
Don't write off «second-tier» hardware. First optimize communication, then compute. Measure not only FLOPS but also GPU idle time waiting for data.
«An AI systems performance engineer is a specialized role focused on optimizing the performance of AI models and the systems underlying them… The role combines expertise in hardware, software, and algorithms. These specializations must be co-designed».
The formula «hardware + software + algorithms» in practice means that a performance engineer is not «an ML engineer who knows CUDA» and not «a sysadmin who understands neural networks». It is a separate profession that emerges at the intersection of three cultures and speaks three languages simultaneously.
A practical test of belonging to this role is simple: if you can explain to a researcher why changing the order of operations in an attention layer will speed up training by 15%, and to an infrastructure engineer why a new NVIDIA driver is needed, you are a performance engineer. If only one of the two — you are a specialist in an adjacent field.
Hardware, Software, and Algorithms
The performance engineer is a central role: it connects hardware, software, and algorithms. Expertise in one area without the other two does not deliver full effect.
It was expected that as models grow, the role would become increasingly in demand and highly paid, and requirements would expand toward interdisciplinarity.
The forecast held: demand for performance engineers in AI infrastructure is growing, and the salary gap between «ordinary» ML engineers and performance engineers is widening. DeepSeek's case showed that these specialists deliver outsized effect under constraints.
Build a T-shaped profile: deep expertise in one area plus broad understanding of the other two. Learn to speak the languages of researchers, infrastructure, and DevOps.
«To identify bottlenecks, you need to iteratively use NVIDIA Nsight Systems and NVIDIA Nsight Compute along with the PyTorch profiler. It is important to set up automated performance tests to detect regressions early in the development cycle».
The key word here is iteratively. Profiling is not a report done once before release but a continuous loop: measure, hypothesize, change, re-measure. Engineers who treat profiling as a one-time event usually optimize the wrong thing.
The second important point is automated regression testing. Performance tends to silently degrade: a library update, a code refactor, a driver change — and suddenly throughput has dropped 10%, and no one noticed. A CI pipeline with benchmarks and alerts is not a «nice to have» but basic hygiene for a production system.
Practical recommendation: start with Nsight Systems — it shows the big picture (where the GPU is idle, where synchronization happens). Then, when you've found a suspicious kernel, move to Nsight Compute — it shows details: occupancy, memory throughput, warp stall reasons.
Profiling is a continuous loop, not a one-off action. Automated performance tests in CI catch regressions before they reach production.
It was assumed that as the stack grows more complex (distributed systems, MoE, mixed precision), the role of automated profiling and regression testing would only grow.
The forecast held: modern frameworks (PyTorch, TensorRT-LLM) now include built-in profilers and CI pipelines with benchmarks. MLPerf became the de facto standard for reproducible measurement.
Wire profiling into CI from day one. Don't optimize blindly. Remember that rewriting a bottleneck in C++ or moving it to the GPU often pays more than micro-optimizations in Python.
«Scaling small research workloads to large production ones on hyperscale clusters ensures that when moving from 8 GPUs to 80,000 GPUs, the system scales with minimal overhead. This requires optimizing communication using NCCL… NVIDIA Inference Xfer Library (NIXL) provides high throughput, low latency, and point-to-point data transfer».
The main enemy of scaling is communication overhead, not a lack of FLOPS. This becomes obvious when moving from a single node to a cluster: while all GPUs are in one NVLink domain, communication is almost free. As soon as traffic leaves the domain — to InfiniBand or Ethernet — latency and bandwidth become the dominant factor.
That is exactly why DeepSeek could bypass H800's limitations: they redesigned communication patterns for the topology. Instead of standard NCCL collectives, they used custom kernels that coordinated data transfer in parallel with computation (the DualPipe algorithm). This is not «code optimization» in the usual sense — it is a rethink of how data moves through the system.
Practical takeaway: before buying more GPUs, make sure you're effectively using the ones you have. Often a 10% improvement in communication yields more than 20% more GPUs.
The main enemy of scaling is communication overhead. NCCL and NIXL are baseline tools, and the choice of parallelism strategy (DP / TP / PP / EP) is dictated by cluster topology.
It was expected that as clusters grow to tens of thousands of GPUs, communication would become the dominant factor, requiring new collective algorithms.
The forecast held: NIXL, SHARP, and the NVLink Switch System with 72 and 576 GPUs in a single domain have emerged. NCCL gained PAT and CollNet algorithms. It was precisely work on communications that let DeepSeek scale on H800.
Start with topology: know where NVLink is, where InfiniBand is, where Ethernet is. Don't try to «patch» communications with more hardware — first optimize collective algorithms (SHARP, PAT, tree vs ring).
«It is important to optimize how models use resources: CPU cores, GPU memory, interconnect bandwidth, and disk I/O… Techniques such as NVIDIA Multi-Instance GPU [MIG] can partition GPU resources for better sharing».
The GPU is not the only resource, and not always the main one. In practice, the bottleneck often turns out to be on the CPU side: the DataLoader can't prepare batches fast enough, NUMA migrations add latency, disk I/O becomes the bottleneck. Engineers who look only at GPU metrics often miss these problems.
MIG and MPS are tools for raising utilization, not «magic acceleration». If a task doesn't load the GPU fully, MIG allows several tasks to run in parallel and raise overall utilization. But for tightly-coupled training workloads where all GPUs must work synchronously, MIG will rather hurt.
The GPU is not the only resource. Memory, interconnects, disk I/O, and CPU affinity influence final performance just as strongly. MIG and MPS are ways to raise utilization when a task doesn't load the GPU fully.
It was assumed that as models grow, memory and OOM problems would become more acute, and MIG/MPS would be increasingly used for multi-tenancy.
The forecast held: MIG and MPS became standard for inference clusters, and memory management (PagedAttention, offloading, quantized KV cache) turned into a whole subfield of optimization.
Pin threads to the NUMA nodes where GPUs live. Monitor framework memory and avoid fragmentation. Use MIG where a task doesn't need a full GPU. Don't forget the CPU side.
«Cross-team collaboration is absolutely critical. It is important to work hand in hand with researchers, data specialists, and application developers, as well as infrastructure teams… The performance engineer sits at the intersection of these interdisciplinary domains».
This section is often perceived as the «soft» part, but in practice communication is as much an optimization skill as working with CUDA. Many promising optimizations never reach production precisely because the performance engineer could not explain to a researcher why the code needs changing, or to an infrastructure engineer why the driver needs updating.
Practical technique: before proposing an optimization, formulate it in terms the listener understands. For a researcher — «this will speed up experiments by 20%, you can test more hypotheses». For infrastructure — «this will cut energy consumption by 15% without losing performance». The same optimization — different arguments.
Optimization almost always lives at the intersection of teams. A single engineer cannot squeeze out the maximum alone: you need researchers, infrastructure, DevOps, and storage teams.
It was expected that interdisciplinarity would grow and the performance engineer's role would increasingly resemble a «technical conductor» between teams.
The forecast held: large AI companies now have dedicated performance teams that coordinate changes across research, infra, and product.
Learn to speak the languages of neighboring teams. Communication is as much an optimization skill as working with CUDA.
«In performance engineering, it is vital to measure everything and trust data, not assumptions. By publishing your work, others can learn, reproduce, and build on your findings… During Open-Source Week in February 2025, DeepSeek released a set of open-source repositories on GitHub, including FlashMLA, DeepGEMM, DeepEP, EPLB, DualPipe, and Fire-Flyer File System (3FS)».
DeepSeek's open-source optimizations are a ready-made library of infrastructure solutions to study and adopt. FlashMLA, DeepGEMM, DeepEP, EPLB, DualPipe, 3FS — each of these projects solves a specific problem faced by teams working with large models.
But even more important is the methodological message: DeepSeek did not just claim «we trained a model cheaply» — it provided tools for reproduction. This shifts the conversation from «believe it or not» to «I verify and reproduce». That is how performance engineering should work.
MLPerf in this context is an industry standard that allows hardware and software to be compared reproducibly. The 2.6x and 3.4x figures on Blackwell vs Hopper are not marketing — they are the result of a standardized benchmark that can be repeated.
Training throughput improvement per GPU: GB200 NVL72 vs. Hopper
Inference throughput improvement per GPU: GB200 NVL72 vs. Hopper
DeepSeek's open-source optimizations form a ready-made library of infrastructure solutions. MLPerf is the reproducible standard for comparing hardware.
It was expected that openness would accelerate the whole field and that industry benchmarks would become the primary language for comparing hardware generations.
The forecast held: DeepSeek's code was quickly picked apart by the community, and MLPerf v5.0 showed 2.6x and 3.4x gains on Blackwell.
Publish your optimizations and read others' open-source projects. Don't trust «vibe optimizations» — measure and reproduce.
«DeepSeek was constrained to using NVIDIA H800 GPUs due to US export restrictions. The H800 is an export-compatible variant of the Hopper GPU. Compared to the H100, it reduces NVLink interconnect bandwidth and FP64 performance, while preserving HBM capacity. DeepSeek set out to train a massive MoE model… using a cluster of 2048 H800 GPUs. This MoE model activates about 37 billion parameters per input token… For each token, DeepSeek-V3 uses 1 shared expert plus 8 experts selected by the router out of 256 experts».
The key idea of the case is sparsity as a way to fit a giant model into reasonable hardware. MoE with top-9 of 256 experts gives 671B parameters with 37B active per token. This is not «model compression» — it is an architectural decision that allows the model to have enormous capacity while using only part of it at each step.
DualPipe is the second key innovation. It is an algorithm that overlaps computation and communication so GPUs don't idle waiting for data. On H800 with reduced NVLink this is critical: standard NCCL collectives can't keep up, so DeepSeek wrote custom kernels that coordinate data transfer in parallel with computation.
The third lesson is cold start + RL for a reasoning model. Instead of expensive human feedback, DeepSeek used minimal labeled data and bet on reinforcement learning. The result: R1 reached o1-level quality at an RL phase cost of $294K and 80 hours on 512 H800s.
Mixture-of-Experts (MoE): selecting active experts for each token
MoE + top-9 of 256 experts = 671B parameters with 37B active per token. DualPipe and custom CUDA kernels let you bypass H800's weaknesses. Cold start + RL is a viable alternative to expensive human feedback.
It was expected that MoE would become the dominant architecture for giant models and that RL-based reasoning training would shift from human feedback to automated schemes.
The forecast held: MoE models (DeepSeek, Mixtral, Switch Transformer) became the norm. R1's RL phase at 80 hours on 512 H800s showed that reasoning can be post-trained cheaply.
Sparsity (MoE) is not a «fashion feature» but a way to fit a giant model into reasonable hardware. Study DualPipe and similar communication-overlap schemes.
«Models with 100 trillion parameters are an ambitious milestone, often compared to the roughly 100 trillion synaptic connections in the human neocortex… As a rough estimate: a dense model with 100 trillion parameters trained on ~29 trillion tokens would require on the order of 1.2 × 10²⁹ floating-point operations… Even with MoE sparsity, this demonstrates that brute force alone is not enough».
100 trillion parameters is not just «100x more». It is a qualitatively different level of system requirements. If 1 trillion parameters could still use relatively standard approaches, 100 trillion requires rethinking everything: weight storage (200 TB just for weights), data transfer, optimizers (Adam would triple memory — memory-efficient alternatives are needed), activation checkpointing (mandatory), distributed checkpointing (mandatory).
The good news: the direction is clear. MoE, FP4/NVFP4, memory-efficient optimizers (Adafactor, Shampoo), distributed checkpointing — all of this is already being researched and implemented. Moonshot AI's Kimi K2 (1T parameters, 32B active) showed the viability of the MoE approach. FP4 and NVFP4 gained hardware support.
The bad news: the gap between «possible» and «available» is still large. 100 trillion parameters will require clusters of tens of thousands of GPUs, heterogeneous environments, new algorithms. This is not a one-year project.
100T parameters means ~10²⁹ FLOPs for training and ~200 TB just for weights. The solution is sparsity (MoE), low precision, memory-efficient optimizers, activation checkpointing, and distribution across thousands of GPUs.
It was expected that humanity would reach 100T parameters not through «brute force» but through co-evolution of hardware, software, and algorithms.
The forecast held: Moonshot AI's Kimi K2 (1T parameters) already showed the viability of the MoE approach. FP4 and NVFP4 gained hardware support. Optimizers like Adafactor and Shampoo are actively researched.
Don't try to scale «head-on». Study MoE, low precision, memory-efficient optimizers, and distributed checkpointing. Prepare to work with clusters of tens of thousands of GPUs.
«NVIDIA has built a new class of AI supercomputers for trillion-parameter-scale workloads. NVIDIA Grace Blackwell GB200 NVL72 (2024) and GB300 NVL72 Ultra… NVIDIA calls these rack-scale systems "AI supercomputers in a rack". Each GB200 NVL72 rack combines 36 Grace Blackwell superchips connected via NVLink with NVSwitch… A full GB200 NVL72 rack theoretically achieves ~1.44 exaFLOPS for FP4… Power consumption is about 120–132 kW per rack».
NVL72 is a paradigm shift. Previously, scaling meant «add more nodes and connect them with a network». Now a rack itself is one large accelerator with 72 GPUs in a single NVLink domain and ~130 TB/s aggregate bandwidth. This changes everything: how you think about parallelism, how you plan data, how you build inference servers.
Practical consequence: if your model fits in one NVL72, you can use more aggressive parallelism strategies (TP across all 72 GPUs, EP with experts on different GPUs) that would be impossible on a traditional cluster. But this requires understanding the topology: where NVLink is, where NVSwitch is, where InfiniBand is. Remote memory access over NVLink is non-uniform.
Power consumption of ~130 kW per rack is a separate challenge. Liquid cooling becomes mandatory, and power planning becomes part of the engineering task.
NVL72 = 72 GPUs in a single NVLink domain with ~130 TB/s aggregate bandwidth. 1.44 exaFLOPS FP4, 30 TB memory, ~130 kW. This is a new class of systems where a rack behaves like one large accelerator.
It was expected that such systems would become the building block of «AI factories» and that NVIDIA's roadmap would keep doubling performance and memory every generation.
The forecast held: GB300 Ultra is already announced, Vera Rubin and Feynman are on the way. Cloud providers offer NVL72 on demand, and the NVLink Switch System allows up to 576 GPUs in a single domain.
Study NVL72 topology: where NVLink is, where NVSwitch is, where InfiniBand is. Learn to use the single domain for DP/TP/PP/EP. Remember that remote memory access over NVLink is non-uniform.
«The term "mechanical sympathy," originally coined by engineer Martin Thompson by analogy with Formula 1 champion Jackie Stewart… in computing means writing software that deeply accounts for hardware characteristics… A classic example is FlashAttention, an algorithm that restructures the transformer attention mechanism with GPU memory hierarchy in mind».
Mechanical sympathy is not a «technique» but a methodology. It is a way of thinking about a system where you don't just write code but ask: «How will this execute on specific hardware? Where is the data? How many times does it move? Which units are idle?»
FlashAttention (2–4x speedup), DeepSeek MLA, Transformer Engine, FP4 + microscaling — all are examples of this approach. Each delivers outsized gains because it redesigns the algorithm for a specific architecture rather than trying to «universally optimize».
The virtuous cycle «hardware, algorithms, hardware» is accelerating. Each GPU generation adds new numeric formats and units (FP4, SFU for softmax), and algorithms (FlashAttention-3, MLA) immediately use them. The gap between «just running a model» and «squeezing the maximum out of it» keeps growing. This is both a challenge and an opportunity for engineers.
Mechanical sympathy is a methodology: write software for specific hardware. FlashAttention (2–4x), DeepSeek MLA, Transformer Engine, FP4 + microscaling are all examples of this approach.
It was expected that the virtuous cycle «hardware, algorithms, hardware» would accelerate, and co-design would become mandatory for frontier results.
The forecast held: each GPU generation adds new numeric formats and units, and algorithms immediately use them. The gap between «just running a model» and «squeezing the maximum out of it» keeps growing.
Study hardware down to the level of memory hierarchy, Tensor Cores, and SFUs. Redesign algorithms for specific architectures — this pays more than «universal» optimizations.
AI systems performance engineering is a discipline at the intersection of hardware, software, and algorithms. DeepSeek proved that under tight constraints, deep understanding of the hardware hierarchy and the ability to redesign computations for it enable frontier results at a fraction of the cost. Each of the 11 blocks delivers a concrete lesson: where to optimize, what to forecast, and how to apply it in practice. As we move toward models with hundreds of trillions of parameters, co-design ceases to be optional and becomes the only way forward.
Sources: Chris Fregly, «AI Systems Performance Engineering» (O'Reilly, 2026), Chapter 1 — quotes provided in limited volume for review and critical analysis purposes. DeepSeek-V3 technical report; DeepSeek Open Infra Week publications; MLPerf Training/Inference v5.0; NVIDIA GB200 NVL72 documentation; Stanford AI Index; Nature (September 2025).
