Введение в системы машинного обучения

Русский перевод первого тома учебника «Machine Learning Systems» (Harvard University) целиком: шестнадцать глав, четыре вводных части, приложения, глоссарий и список литературы вместе с рисунками, диаграммами и комментариями в коде. Перевод прошел сквозную вычитку: текст, формулы, рисунки, диаграммы, комментарии в коде и ссылки.

• Введение: зачем инженерии нужны принципы, отличные от традиционных, и как менялось узкое место в развитии ИИ.
• Системы машинного обучения: облачные, периферийные, мобильные и микроконтроллерные системы, а также стена памяти.
• Рабочий процесс машинного обучения: жизненный цикл ML от постановки задачи до мониторинга, распространение ограничений и пример скрининга диабетической ретинопатии.
• Инженерия данных: данные как исходный код, гравитация данных и налог на подачу, каскады качества, разметка, хранение и хранилища признаков, а также пример распознавания ключевых слов.
• Вычисления в нейронных сетях: от логики к арифметике, перцептрон и функции активации, обратное распространение ошибки, память при обучении и выводе, а также история распознавания рукописных цифр.
• Архитектуры нейронных сетей: MLP, CNN, RNN, трансформеры и DLRM как физические контракты с аппаратурой: паттерны данных, индуктивные смещения, арифметическая интенсивность, маячные модели и схема выбора архитектуры.
• Фреймворки машинного обучения: фреймворк как компилятор для кремниевого контракта, три проблемы (исполнение, дифференцирование, абстракция аппаратуры), стратегии исполнения и слияние ядер, автоматическое дифференцирование и контрольные точки, модули и тензоры, развертывание от облака до микроконтроллеров.
• Обучение моделей: железный закон производительности обучения, конвейер обучения и выявление узких мест, смешанная точность, FlashAttention, накопление градиентов и масштабирование на несколько ускорителей и машин.
• Отбор данных: отношение информации к вычислениям, статическое прореживание и дедупликация, динамический отбор с учебным планом и активным обучением, полуконтролируемое и самоконтролируемое обучение, синтетические данные и доменный разрыв, модели стоимости и распределенный отбор.
• Сжатие моделей: прореживание, дистилляция, квантование и квантование с учетом обучения, поиск нейронной архитектуры, структурные аппроксимации, слияние операторов, адаптивные вычисления, разреженность и выбор техники под физические ограничения.
• Аппаратное ускорение: специализация аппаратуры, примитивы вычислений ИИ, тензорные ядра и систолические массивы, тайлинг и числовая точность.
• Бенчмаркинг: рамка бенчмаркинга, системные бенчмарки и уровни детализации, компоненты бенчмарка, измерение энергопотребления и MLPerf.
• Обслуживание моделей: парадигмы обслуживания, бюджет задержки, архитектура системы обслуживания, теория очередей и хвостовая задержка.
• MLOps: технический долг, конвейеры CI/CD и хранилища признаков, мониторинг дрейфа и стоимость наблюдаемости, развертывание и откаты, A/B-тестирование, Edge AI, дежурство и управление, пример ClinAIOps.
• Ответственная инженерия: ответственность как инженерное ограничение, оценка справедливости по подгруппам и компромиссы с точностью, объяснимость и регуляторные требования, стоимость владения и углеродный след, управление данными, родословная и аудит.
• Заключение: синтез тринадцати количественных принципов, маячные модели, каскад ограничений, будущие направления и горизонт от узла к парку.
• Принципы основ, Принципы построения, Принципы оптимизации, Принципы развертывания: введения к четырем частям книги с формулировками принципов.
• Приложения: Таксономия D·A·M, Основы данных, Основы алгоритмов, Основы машины, Системные допущения; Глоссарий и Список литературы (записи, которые цитируются в томе, на языке оригинала).
• Предисловие и служебные разделы: Посвящение, Предисловие, Заметка автора, О книге, Благодарности, Примечание об использовании ИИ, Обозначения.

Сведения об авторстве и лицензии — на странице Уведомление об авторстве. Что изменено при переносе и как переведены рисунки — на странице Происхождение материалов.

Посвящение

Памяти моего отца, который научил меня учиться. С благодарностью моей матери, которая научила меня отдавать.

Предисловие

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

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

Меня тревожит, что большая часть этого прогресса достигнута сообществом, которое — не по своей вине — никогда не учили мыслить о том, что оно строит, в системных категориях. Инженеры умеют вызвать model.fit(), но не могут объяснить, почему обучение медленное. Исследователи подбирают гиперпараметры, не понимая ограничений пропускной способности памяти, которые делают одни выборы непрактичными. Практики развертывают модели в эксплуатацию, не имея рамки для рассуждений о задержке, пропускной способности и режимах отказа.

Блестящий алгоритм без хорошо спроектированной системы, которая его поддерживает, похож на мощный двигатель без шасси и тормозов. Далеко он не уедет, а уж надежно — тем более.

Этот разрыв — не дефицит талантов. Это дефицит учебных программ. У области просто не было учебников, которых она заслуживает. Эта книга, Введение в системы машинного обучения, появляется точно в нужный момент, чтобы осветить этот критически важный и часто упускаемый из виду аспект революции ML.

Почему важно системное мышление

Моя карьера опиралась на силу системного мышления: выявлять узкие места, понимать взаимодействие компонентов и проектировать с расчетом на производительность, надежность, экономическую эффективность и простоту использования во всем стеке. К этому выводу нельзя прийти, опираясь только на первые принципы: нужно было думать о системе.

Системы ML требуют ровно той же дисциплины. Нейронная сеть — не математическая абстракция, парящая вне физических ограничений. Это вычисление, которое должно исполняться на кремнии с конечной пропускной способностью памяти, конечными энергетическими бюджетами и конечной способностью к коммуникациям. Арифметическая интенсивность, модель Roofline и эффекты иерархии памяти — не продвинутые темы, которые проходят после основ. Они и есть основы.

Почему системы ML заслуживают серьезного учебника

Назначение учебника — не только каталогизировать текущий передний край. Его задача — дать концептуальный каркас, который позволит студентам понять этот передний край и продвинуть его самим. Архитектуры нейронных сетей, описанные на этих страницах, будут развиваться, а описанные ускорители — вытеснены. Но некоторые основы не изменятся: иерархии памяти никуда не денутся, арифметическая интенсивность останется ключевой мерой. Принципы конвейеризации, компромиссов между задержкой и пропускной способностью, квантования и точности отражают физические и математические реальности, которые не устаревают. Тот, кто действительно их понимает, сможет рассуждать о любой новой системе, которую отрасль выпустит через год или через десять лет.

Меня поражает и масштаб того, что пытается сделать эта книга. Недостаточно объяснить, как работает обучение; нужно также разобрать инженерию данных, оптимизацию моделей, аппаратное ускорение, развертывание, бенчмаркинг, ответственный ИИ и устойчивость. Это не разрозненные темы, сложенные вместе для полноты. Это взаимосвязанные стороны одной инженерной дисциплины. Решение на уровне данных влияет на поведение модели, которое влияет на задержку вывода, которая влияет на стоимость развертывания, а та — на сообщества, способные или не способные получить доступ к результирующей системе. Книга правильно рассматривает эту интеграцию как предмет первого ранга.

Особенно радует количественная методология, которая проходит через каждую главу. Утверждения подкреплены измерениями, компромиссы выражены числами. Студентов учат оценивать, измерять и проверять, а не полагаться на интуицию. Разница между инженером и дилетантом — именно в этой способности к строгим рассуждениям, опирающимся на измерения.

Почему открытый доступ важен для следующего поколения

Я приветствую решение сделать этот бесценный ресурс свободно доступным.

Когда я в соавторстве с Джоном Хеннесси писал Computer Architecture: A Quantitative Approach, мы обсуждали, как сделать материал максимально доступным. Мы добивались от издателя снижения цены и даже выпустили недорогое издание для международных студентов, предназначенное для продаж за пределами Северной Америки. Эти заботы стали еще острее, когда ML превратился в инфраструктуру — в такую же важную для современного мира вещь, как электрическая сеть или интернет.

Решение опубликовать эту книгу как свободно доступный образовательный ресурс — не компромисс. Это заявление о ценностях. Системы ML внедряются во всех секторах экономики на всех континентах. Инженеры, которые их строят и поддерживают, придут отовсюду. Если фундаментальное образование, необходимое для такой работы, доступно только студентам обеспеченных вузов, мы усилим разрыв в экспертизе, который отражает общественные вопросы о том, кто выигрывает от ИИ и кто несет его издержки.

Еще более впечатляет то, что проект вышел далеко за рамки открытого доступа к статичному тексту. Сопутствующая экосистема — интерактивные лаборатории, фреймворк TinyTorch для сборки с нуля, наборы для аппаратного развертывания, материалы для преподавателей и глобальная сеть университетов, которые принимают курс, — отражает знакомую педагогическую максиму: слышу — забываю, вижу — запоминаю, делаю — понимаю.

Модель открытого исходного кода также делает сам учебный план лучше. Ошибки исправляются, примеры оттачиваются, новые главы появляются в ответ на то, что действительно нужно области. Как мы убедились с Computer Architecture: A Quantitative Approach, сообщество авторов, сложившееся вокруг книги, может обеспечить такой уровень контроля качества, какой не сможет дать ни одна команда авторов в одиночку, как бы опытна она ни была.

Последнее слово

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

Хочется надеяться, что инженерия систем ML последует этой традиции. Ей нужны навыки мышления, которые приходят от серьезного отношения к системам: думать о взаимодействиях, измерять на правильном уровне абстракции, честно говорить о компромиссах и нести ответственность перед реальной производительностью, а не перед фольклором бенчмарков. Эта книга воплощает такие навыки.

Введение в системы машинного обучения — больше, чем учебник. Это призыв к системному мышлению в эпоху ИИ, руководство по созданию устойчивых ML-приложений и свидетельство силы открытого образования.

Мы переживаем исключительный момент. За мою карьеру каждое десятилетие приносило крупный прорыв: микропроцессор в 1970-х, персональный компьютер в 1980-х, интернет в 1990-х, смартфон в 2000-х и ИИ в 2010-х. Первые четыре изменили бизнес и общество, однако ИИ, похоже, окажет самое большое влияние из всех.

Системы, которые создаются сегодня, определят, как внедряется интеллект, кто из него извлекает пользу и чего он стоит — в деньгах, в энергии и в углеродном следе. Нам нужны инженеры, которые их строят, и они должны владеть системными навыками на максимальном уровне.

Эта книга — важный шаг к тому, чтобы любой мог их освоить.

Заметка автора

Мир торопится строить системы ИИ, но пока не занимается их инженерией.

Эта фраза и объясняет, зачем существует эта книга. Модель, которая побеждает на бенчмарке, еще не является системой, и расстояние между ними — не деталь реализации. Это инженерия: работа по тому, чтобы нечто выдерживало ограничения, с которыми нельзя договориться. Демонстрация ни перед кем не отвечает. Система отвечает перед бюджетами задержки, пределами памяти, энергетическими рамками и ценой ошибки на глазах у реальных пользователей.

Что делает эту область самостоятельной дисциплиной, так это необычная связанность. Процессор подчиняется физике машины: тактам, строкам кэша и теплу, которое он может отвести. Статистическая модель подчиняется математике обучения: смещению, дисперсии и тому, как обобщение меняется вместе с данными и емкостью модели. ML-система должна отвечать перед обоими сразу, в одном и том же решении, и они не всегда согласованы. Изменение, которое радует аппаратуру, может лишить модель точности или пропускной способности, необходимых для сходимости; изменение, которое помогает модели, может потребовать от кремния больше памяти или полосы, чем тот способен дать. Удерживайте это напряжение в поле зрения, и область перестанет выглядеть набором инструментов: она превратится в структуру, о которой можно рассуждать.

Эта книга передает вам такую структуру. Не модный в этом году фреймворк и не самый быстрый ускоритель этого квартала, а способ мышления, который их переживет. Фреймворки меняются, аппаратура обновляется каждые несколько лет, бенчмарки сбрасываются; силы под ними остаются теми же. Если книга сработает, вы закончите ее, способные взглянуть на любую ML-систему — от датчика, потребляющего микроватты, до серверной фермы, потребляющей мегаватты, — и увидеть, как один и тот же небольшой набор сил определяет, что возможно.

Учебники, которые повлияли на меня в студенческие годы, не давали мне одних фактов. Они давали способ видеть, а факты выстраивались вокруг него. Именно это я и попытался сделать здесь.

— Vijay Janapa Reddi
Кембридж, Массачусетс
2026

О книге

Для кого эта книга

Эта книга для всех, кто хочет понять, как на самом деле работают системы машинного обучения: от математики, которая определяет нейронную сеть, до аппаратуры, которая ее исполняет, и инженерных решений, благодаря которым она работает эффективно.

Большинство читателей не станут архитекторами ML-аппаратуры или инженерами компиляторов. Но каждый практик, который строит, обучает, оптимизирует или развертывает модель, принимает решения, которые зависят от понимания системы под кодом. Книга дает эту системную основу студентам, впервые сталкивающимся с системами ML, практикующим инженерам, которые укрепляют свои знания, и исследователям, которым нужно рассуждать о производительности и развертывании.

Зачем нужен учебник по системам

В 1968 году конференция НАТО в Гармиш-Партенкирхене (Германия) помогла утвердить программную инженерию как самостоятельную дисциплину на фоне опасений, что программные системы стали слишком сложными для кустарного программирования (Naur and Randell, 1969). Надежное программное обеспечение требовало собственных принципов, методов и строгости. Спустя десятилетия Хеннесси и Паттерсон сделали количественный анализ центральным в обучении архитектуре компьютеров, систематизировав то, как инженеры измеряют, предсказывают и оптимизируют производительность процессоров (Hennessy and Patterson, 2017). Оба примера показывают, как общие методы делают сложную инженерную работу систематической и пригодной для обучения.

У машинного обучения есть свой момент Гармиша.

Последнее десятилетие исследования ML доминировало мышление, ориентированное на модель, сосредоточенное на поиске новых алгоритмов и архитектур. Этот фокус важен, но модель — не система. Нейронная сеть, которая хорошо работает в исследовательском блокноте, бесполезна, если не может уложиться в ограничения задержки, если ее конвейер данных не справляется с нужным объемом или если ее энергетическая стоимость превышает экономическую ценность. Разрыв между работающей моделью и производственной системой — не просто пробел в реализации; это пробел в фундаментальных инженерных принципах.

Эта книга рассматривает инженерию систем ML не как набор инструментов, таких как Kubernetes, PyTorch и CUDA, а как дисциплину, опирающуюся на количественные границы, модели и принципы проектирования. Как инженеры-строители опираются на фундаментальную физику и принципы конструкций, инженеры ИИ должны явно формулировать управляющие принципы, лежащие в основе модели каждой системы:

• Железный закон систем ML: декомпозиция на перемещение, вычисления и накладные расходы, где перекрытие учитывается по критическому пути.
• Гравитация данных: давление размещения, которое создают большие объемы данных и ограниченные сети.
• Учет энергии: стоимость отдельных событий и их число определяют, что доминирует, перемещение или вычисления.
• Закон Амдала: последовательная доля конвейера ограничивает общее системное ускорение.

Информатика изучает то, что вычислимо. Исследования ML изучают то, что обучаемо. Инженерия ИИ изучает то, что можно построить, учитывая физику реальной аппаратуры и реальных данных.

Я написал эту книгу, чтобы помочь заложить такой фундамент и сделать для систем ИИ то, что Хеннесси и Паттерсон сделали для архитектуры компьютеров: заменить интуицию измерением, а искусство — инженерией. Цель — учить системному рассуждению до реализации, рассматривая данные, алгоритмы и аппаратуру не как отдельные изолированные части, а как единую связанную задачу оптимизации.

Представьте коробку с кубиками LEGO. Одни и те же соединяемые детали строят космический корабль, замок или целый город. Наборы меняются, кубики — нет. С системами ML то же самое. Сверточная сеть для классификации изображений, трансформер для генерации текста и агент обучения с подкреплением для робототехники — очень разные приложения, но под ними лежат одни и те же строительные блоки: вычислительные графы, иерархии памяти, конвейеры данных, циклы оптимизации и компромиссы между задержкой, пропускной способностью и энергией. Владение этими блоками делает незнакомые системы понятными.

Поэтому книга учит устойчивым принципам, а не нынешним инструментам. Доминирующие фреймворки за десятилетие сменились с Theano на TensorFlow и затем на PyTorch. Аппаратура эволюционировала от переиспользованных графических процессоров к специально созданным тензорным ускорителям, и новые архитектуры появляются каждый год. Любой учебник, который учит нынешним инструментам, устареет до следующего издания. Строительные блоки остаются.

Что охватывает книга

Книга сосредоточена на одном вычислительном узле: одном хосте с одним-восемью ускорителями, обычно с отдельной памятью устройств, соединенной межсоединением. Она также вводит многоускорительное обучение и эксплуатационные операции там, где они проясняют проектирование на уровне узла; рассмотрение масштаба парка выходит за ее рамки.

Содержание организовано в четыре части, каждая из которых играет свою роль в системном рассуждении:

• Часть I: Основы систем ML развивает словарь, ментальные модели и сквозной рабочий процесс, которые направляют любой ML-проект, от характеристик, отличающих системы ML от традиционного программного обеспечения, до конвейеров инженерии данных, которые их питают.
• Часть II: Разработка и обучение связывает математические основы с работающими системами через вычисления глубокого обучения, нейронные архитектуры, фреймворки и процедуры обучения.
• Часть III: Оптимизация и ускорение рассматривает эффективность данных, сжатие моделей, аппаратное ускорение и методологию бенчмаркинга, необходимую для строгого измерения прогресса.
• Часть IV: Развертывание и эксплуатация охватывает инфраструктуру обслуживания, эксплуатационные практики и ответственную инженерию для систем, которые должны быть справедливыми, прозрачными и заслуживающими доверия в продакшене.

Эти четыре части прокладывают путь через стек систем ML — слоистую абстракцию, построенную по образцу классического стека компьютерных систем. Каждый слой предоставляет абстракцию слою над собой и использует слой под собой: от аппаратуры внизу через фреймворки, модели, обучение и обслуживание к эксплуатации и приложениям наверху. Данные проходят через все слои как сквозная связь, подобно шине данных в архитектуре компьютера.

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

Данные рядом со стеком — не просто украшение. Их равномерная заливка отражает, насколько данные важны для задач каждой главы: это отдельное измерение, независимое от интенсивности слоев. Соединительные линии между каждым слоем и полосой данных показывают, какие слои взаимодействуют с данными в контексте главы. Три главы показывают, как меняется взгляд.

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

Рядом с текстом стоят также небольшие визуальные подсказки в тех местах, где связь легче всего понять глазами. Это не пронумерованные рисунки, на которые нужно ссылаться; это вспомогательные средства чтения. Лестница показывает разрыв масштабов, эскиз тренда — направление, миниатюра Roofline указывает режим узкого места, а полоса доминирования показывает, какой член управляет суммой. Если миниатюра использует логарифмическую шкалу, это сказано прямо на изображении.

Каждая часть опирается на предыдущую. Тех, кто впервые знакомится с областью, рекомендуется читать последовательно, а следующие индивидуальные маршруты помогают под конкретные профессиональные цели:

Рекомендуемые маршруты чтения

Читатели с разным опытом и целями могут выбрать индивидуальные маршруты:

• Полный маршрут (все главы по порядку): для студентов и читателей, новых в системах ML. Начните с части I, затем переходите к частям II, III и IV. Этот маршрут развивает каждое понятие с первых принципов.
• Маршрут инженера ML (системная глубина для практиков): для инженеров, которые уже обучают и развертывают модели, но хотят понять системы под ними. Бегло просмотрите часть I ради словаря, затем сосредоточьтесь на главах «Фреймворки машинного обучения», «Обучение моделей», «Аппаратное ускорение», «Бенчмаркинг» и «Обслуживание моделей».
• Маршрут оптимизации (ориентированный на эффективность): для инженеров, которые работают над эффективностью моделей, периферийным развертыванием или системами с ограниченными ресурсами. После части I переходите сразу к главам «Отбор данных», «Сжатие моделей», «Аппаратное ускорение» и «Бенчмаркинг».

Условные обозначения

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

Жирным выделяются первые определения

Термин жирным в основном тексте — его формальное первое введение в томе. Каждый термин получает такое выделение ровно один раз. Последующие упоминания идут без выделения: к этому моменту термин уже входит в рабочий словарь, который глава переносит дальше.

Каждая система машинного обучения несет двойную задачу: она должна одновременно управлять статистической неопределенностью и физическими ограничениями.

Жирный шрифт — обязательство запомнить термин, потому что он будет повторяться. Соответствующая запись указателя в конце книги ведет к определяющему упоминанию (в подразделе «определение»), так что к нему можно вернуться. Ключевые технические термины также собраны в глоссарии.

Жирный шрифт выполняет и вторую, структурную роль: как функциональная метка в начале пункта внутри выделенного блока или маркированного итога, например Рекомендация, Компромисс или Результат. В этом контексте жирный шрифт — опорная конструкция, а не первое определение.

Курсив выполняет конкретные риторические задачи

Курсив не используется для общего выделения. Каждый курсивный фрагмент книги выполняет одну из немногих конкретных задач:

• Прямое противопоставление: обучение и вывод, логическое и физическое.
• Невозможность, сформулированная как физический, математический или логический закон: «системы с задержкой менее 10 мс не могут использовать удаленную облачную инфраструктуру — этого не позволяет физика».
• Слово как слово: «термин градиент обозначает вектор частных производных».
• Названия произведений: Computer Architecture: A Quantitative Approach.
• Тезис-вывод: одно курсивное предложение, которое передает управляющее понимание раздела, например Данные — это исходный код.

Курсивное слово выполняет одну из этих задач. Слово без курсива не несет скрытого выделения.

У выделенных блоков есть визуальная идентичность, соответствующая их задаче

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

Когда блок содержит таблицу, рисунок или уравнение, этот артефакт — часть педагогической единицы блока, а не украшение. Профиль маячной модели и есть ее характеристика; промежуточные таблицы блока «Расчет на салфетке» и есть разобранная математика. Если читать эти артефакты отдельно, теряется дуга изложения. Самостоятельные справочные таблицы, напротив, стоят между абзацами как пронумерованные артефакты, к которым читатель возвращается по перекрестным ссылкам. Обе формы допустимы; визуальный признак (блок или отдельная таблица) показывает читателю, с чем он имеет дело.

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

Учебная платформа

Эта книга — одна из частей более широкой образовательной экосистемы. Полный текст, интерактивные блокноты, лекционные слайды, упражнения, практические лабораторные работы и дополнительные материалы для каждой главы свободно доступны на mlsysbook.ai.

Открытый учебник

Эта книга имеет открытый исходный код. Полный текст, рисунки и система сборки доступны на mlsysbook.ai/git, и я приглашаю каждого читателя участвовать в работе. Эта открытость продуманная. Если инженерия ИИ должна стать общей дисциплиной, а не набором изолированных практик, ее базовые тексты должны быть доступны каждому. Область систем ML формируют практики из промышленности, академической среды и сообщества открытого исходного кода по всему миру. Учебник по этой области должен отражать такое разнообразие и быть доступным всем, независимо от географии и институциональной принадлежности.

Вклад читателей — исправление ошибки, предложение более ясного объяснения, добавление рабочего примера или предложение нового материала — существенно улучшил каждую главу. Задачи и запросы на слияние служат механизмом такой совместной работы. Книга становится лучше, потому что ее читатели участвуют в ее создании.

Предварительные требования

Читателю понадобятся две вещи:

• Программирование: уверенное владение Python, включая функции, классы и базовую обработку данных с NumPy.
• Математика: знакомство с линейной алгеброй, базовым математическим анализом и теорией вероятностей на уровне бакалавриата.

Две дополнительные области полезны, но не обязательны:

• Компьютерные системы: знакомство с иерархиями памяти и основами архитектуры компьютеров углубляет главы об оптимизации и аппаратуре.
• Основы машинного обучения: предварительное знакомство с понятиями обучения с учителем дает полезный контекст, но часть II выстраивает необходимые основы с первых принципов.

За пределами книги

Эта книга развивает фундамент для одного узла, одновременно вводя распределенное исполнение, эксплуатацию в продакшене и управление там, где они влияют на сквозную систему. Сложные многоузловые топологии, коллективные алгоритмы в масштабе парка и устойчивость кластеров выходят за рамки текста в распределенные системы большого масштаба. Освоение этой книги готовит читателя к навигации по более широкому инженерному ландшафту.

Использование книги в курсе

Эта книга выросла из курса CS249r в Гарвардском университете и программы профессионального сертификата TinyML на edX. Курс TinyML учил системам ML на самом ограниченном конце спектра: микроконтроллеры, работающие на милливаттах с килобайтами памяти. Эта работа показала, что физические ограничения, управляющие встраиваемыми устройствами (пропускная способность памяти, плотность вычислений и энергия на операцию), — те же ограничения, которые управляют графическими процессорами центров обработки данных. Физика масштабируется; меняются только числа. Это понимание сформировало книгу: владение основами систем на самом малом масштабе готовит инженеров к любому масштабу.

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

• Части I–II образуют вводный полусеместровый курс об основах систем ML и о том, как такие системы строятся и обучаются.
• Части III–IV образуют прикладной полусеместровый курс об их оптимизации, развертывании и эксплуатации.

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

Лекционные слайды, задания и материалы для преподавателей доступны на mlsysbook.ai.

Благодарности

Истоки

Эта книга обязана своим появлением одному разговору. Во время академического отпуска в Google Пит Уорден пригласил меня заняться, как тогда казалось, невыполнимой задачей для TinyML: запустить небольшую модель распознавания речи на микроконтроллере. Эта работа над TensorFlow Lite for Microcontrollers выявила нечто фундаментальное. Ограничения, которые управляют устройством с памятью от 16 КБ до 256 КБ, — те же, что управляют ускорителем в центре обработки данных, даже когда масштаб совершенно иной. Пропускная способность, задержка, энергия и память подчиняются одной и той же физике в обоих случаях. Это понимание стало зерном, из которого выросла книга.

Работа над TinyML привела к онлайн-курсу на HarvardX, который я вел вместе с Лоуренсом Моронеем и который вырос до более чем 100 000 студентов по всему миру. Брайан Плэнчер помог построить учебную программу по TinyML. Маркело Ровай, профессор, впервые познакомившийся с материалом через курс TinyML, позднее разработал практические лабораторные работы и наборы, которые сопровождают эту книгу. Зак Шелби открыл платформу Edge Impulse для студенческого использования. Массимо Банци и команда Arduino вместе с Эриком Паном и Seeed Studio сотрудничали с нами в разработке и предоставлении аппаратных наборов, которые сделали практическое обучение возможным. Марко Дзеннаро принес этот материал в развивающиеся страны через ICTP и высказал мысль, что эти принципы заслуживают полноценного учебника. Преподавание в таком масштабе без учебника сделало эту потребность очевидной.

Эта потребность превратилась в книгу в рамках курса CS249r в Гарвардском университете. В 2023 году семестровый проект курса состоял в том, чтобы написать конспекты лекций: каждая группа студентов брала на себя тему, изучала ее и вместе со мной превращала в главу. Эта работа заложила основу каждой главы книги. Исходная идея состояла в том, что письмо заставляет думать глубже, чем чтение. Затем мы открыли все это на GitHub, и то, что начиналось как черновые конспекты, с каждым семестром переписывалось и совершенствовалось.

Поскольку работа на GitHub продолжается, книга опирается на сообщество, вклад которого развивается вместе с проектом. Новые участники присоединяются по мере того, как читатели сообщают о проблемах, улучшают объяснения и дополняют поддерживающие материалы. Такая благодарность может зафиксировать лишь один момент этой продолжающейся истории. Актуальный список участников и правила внесения вклада доступны по адресу https://mlsysbook.ai/git.

Галерея участников в русском издании не воспроизводится: актуальный список ведется в английском репозитории, и его можно посмотреть по адресу mlsysbook.ai/git.

Коллеги и соратники

За пределами курса и сообщества GitHub мои более ранние совместные проекты сформировали интеллектуальный фундамент книги. Работа в Google повлияла на значительную часть системного мышления, изложенного на этих страницах. Этот период начался с моделирования производительности для первой системы на кристалле (SoC) Pixel, которое опиралось на мой опыт в архитектуре компьютеров. Совместная работа с Марком Хиллом над аналитическим моделированием в духе Roofline для гетерогенных SoC научила меня рассуждать об аппаратуре из первых принципов — тому количественному мышлению, которое проходит через каждую главу. Этот акцент на аналитическом моделировании естественно привел к систематической оценке, а систематическая оценка — к MLPerf. В MLPerf участвовало много людей из MLCommons, но ближе всего я работал с Питером Маттсоном, Дэвидом Кантером, Кэрол-Жан У, Кристин Ченг, Гюнтером Шмюлинг, Коди Колеманом и Клиффом Янгом. Эта совместная работа определила то, как я думаю о строгом измерении ML-систем.

Борис Мурманн и Сон Хан убедили меня на ранних этапах, что проект стоит продолжать. По мере написания я обращался за обратной связью к коллегам из промышленности и академической среды. Практики из Arm, Google, Intel, Meta, Microsoft, Qualcomm, STMicroelectronics и других организаций предлагали взгляд, опирающийся на производственные системы, а академические рецензенты из университетов Европы, Азии и Америк проверяли материал на соответствие собственным исследованиям и преподаванию. Их совокупная обратная связь сделала каждую главу точнее. Эвгений Гузев из Qualcomm и Пит Бернард из Edge AI Foundation поддержали просветительскую работу проекта и помогли построить вокруг него сообщество.

Эта петля обратной связи распространилась на аудитории по всему миру, где преподаватели проверяли материал, когда он еще был сырым. Софи Шао из UC Berkeley, Сяофань (Фред) Цзян из Колумбийского университета, Тушар Кришна и Дивья Махаджан из Технологического института Джорджии и Венькай Гуань из Миннесотского университета в Морисе были среди первых, а преподаватели из IIT Bombay, NUST Pakistan, De La Salle University на Филиппинах и университетов Европы, Латинской Америки и Африки с тех пор использовали книгу в своих курсах. Их готовность преподавать по незавершенному учебнику дала бесценную обратную связь и подтвердила, что потребность в этом материале не ограничена каким-либо одним учреждением или страной.

Студенты и участники

Мои студенты из Лаборатории вычислительных систем для периферии в Гарварде сформировали эту книгу способами, которые я не могу проследить полностью. Некоторые из них выполнили фундаментальную работу, которая помогла утвердить TinyML как область; их исследования и идеи, возникшие за годы совместной работы, вошли в техническое содержание книги. Эта когорта помогла запустить направление, а затем помогла мне написать о нем: Энди Ченг, Арья Чанд, Брайан Плэнчер, Колби Банбери, Элизабет Суитор, Эмма Чен, Икечукву Ученду, Джейсон Джаббур, Джейсон Йик, Джеффри Ма, Джессика Квайе, Марк Мазумдер, Мэтью Стюарт, Максимилиан Лам, Радхика Гошал, Шветанк Пракаш, Шриватсан Кришнан, Юнь-Шунь Сяо и Цзышэнь Ван. Кай Клайнбард, тогда работавший в Harvard Extension School, создал онлайн-наставника по генеративному ИИ SocratiQ. Нэим Хошневис из Harvard Kempner Institute построил необходимую инфраструктуру, включая GitHub Actions и стандарты документирования. Желько Хрчек подготовил диаграммы TikZ и участвовал в верстке PDF, композиции страниц и окончательном визуальном оформлении книги.

Работа также опиралась на поддержку Harvard Data Science Initiative, Harvard Extension School и Национального научного фонда; Edge AI Foundation и ICTP — за образовательную работу и стипендии; а также Arduino, Edge Impulse, Google и Seeed Studio — за аппаратное обеспечение, инструменты и инфраструктуру, которые сделали практические лабораторные возможными.

В MIT Press Сьюзан Хартман поверила в этот проект и провела его от эксперимента с открытым исходным кодом к опубликованной книге. Ее поддержка, редакторское чутье и дружба сделали эту книгу реальностью так, как не смог бы сделать один GitHub. Я в равной мере благодарен MIT Press за согласие сохранить книгу в открытом доступе. Учебник о дисциплине, которую формирует сообщество открытого исходного кода, должен быть доступен всем, кто в ней участвует. То, что MIT Press разделил эту убежденность, сыграло решающую роль.

Наконец, я благодарю мою жену Кари и моих дочерей Нору и Майю. Эта книга писалась в часы, которые принадлежали им: поздние ночи, которые начинались в десять и заканчивались в два-три часа утра, выходные, которые растворялись в правках, годы утр, когда я был рядом, но не совсем. Помимо упрямства, меня поддерживало сообщество открытого исходного кода. Каждая звезда на GitHub была сигналом, что кому-то это небезразлично, что кто-то учится, что работа важна. Цена была реальной, и они платили ее терпением, которого я не всегда заслуживал.

Примечание об использовании ИИ

Каждая глава этой книги была исследована, написана и переписана мной. На протяжении всей работы я также использовал инструменты ИИ. Изложенное ниже — больше, чем раскрытие, которого MIT Press требует от авторов, использующих ИИ. Это заявление о стандарте, которому я подчинял книгу, и о том, что означает авторство, когда инструменты так способны.

Стандарт — прослеживаемость. Производные величины в этих главах подкреплены вычислительными ячейками на Python, исходный код которых поставляется вместе с книгой. Цитаты сверялись с источниками, перекрестные ссылки — со стабильными якорями. Специально созданный движок моделирования инфраструктуры, которым книга пользуется для системных расчетов, доступен по адресу https://mlsysbook.ai/mlsysim. Набор предкоммитных тестов проверяет машинно-проверяемые части этих инвариантов на каждом коммите: согласованность единиц, разрешение встроенных ссылок, целостность перекрестных ссылок, каноничность обозначений и гигиену цитирования. Инструменты ИИ сделали часть этой строгости механически выполнимой, а инфраструктура обеспечения делает эту работу поддающейся аудиту.

Авторство — это мышление. Какие понятия входят в книгу, а какие нет. Как выстроить главы так, чтобы каждая идея появлялась только тогда, когда у читателя уже есть инструменты для ее понимания. Какие рабочие примеры прослеживать от начала до конца и какие числа вычислять, чтобы читатель мог независимо проверить аргумент. На каком уровне подавать каждое объяснение: достаточно строго для инженера-аспиранта и достаточно конкретно для студента, впервые сталкивающегося с системным мышлением. Где студенты застрянут, потому что я преподавал этот материал и видел, как они застревают. Это решения, которые не может принять ни один инструмент, потому что для них нужно знать читателя. Инструменты ИИ я использовал на протяжении всего процесса, чтобы генерировать формулировки, исследовать альтернативы и проверять свои рассуждения на прочность. Решения мои.

На практике ИИ оказался по-настоящему полезен при написании кода: вычислительных ячеек, предкоммитных проверок и рабочих примеров, которые по сути являются программами. Он помог обозреть литературу, которую я затем читал в оригинале, набросать фрагменты, которые я затем существенно переписывал, и проверить рукопись на согласованность по сотням перекрестных ссылок, тысячам записей указателя и десяткам тысяч строк текста. На протяжении всей работы инструменты предлагали, а я утверждал.

Эта практика старше нынешнего момента. В 1683 году Джозеф Моксон издал первое англоязычное руководство по печатному делу, Mechanick Exercises on the Whole Art of Printing, используя станок, который в нем описывал. Три века спустя Дональд Кнут написал The TeXbook в TeX — системе верстки, которую он создал, когда остался недоволен версткой собственных книг. Книга об инфраструктуре систем машинного обучения, написанная без инфраструктуры, которую она описывает, была бы противоречием. Создатель инструмента документирует инструмент с помощью инструмента.

Системы машинного обучения нельзя сертифицировать так, как сертифицируется традиционная логика. Этот разрыв верификации в равной мере относится и к авторству с помощью ИИ. Стандарт, которому я подчинял эту книгу, — тот стандарт, которого я хочу требовать от каждой системы, которую мы выпускаем: инструмент может предлагать, но ратифицировать может только инженер. MIT Press не указывает ИИ-инструменты как авторов, потому что они не могут принять на себя этическую и юридическую ответственность за свою работу. То же верно для любой инженерной системы. Авторство — это принятие этой ответственности, и она принадлежит человеку.

Обозначения

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

Рассмотрим простое утверждение: «Увеличение $B$ повышает пропускную способность». Для исследователя ML $B$ означает размер батча. Для инженера-аппаратчика $B$ означает пропускную способность. Обе трактовки верны в своих областях, но в ML-системах нам нужны оба понятия в одном уравнении — отсюда необходимость единого последовательного соглашения.

Железный закон систем машинного обучения

Для последовательных фаз исполнения декомпозиция производительности по железному закону такова:

$$T=\underset{\text{Время памяти}}{\underbrace{\frac{D_{\text{vol}}}{\text{BW}}}}+\underset{\text{Время вычислений}}{\underbrace{\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}}}}+\underset{\text{Накладные расходы задержки}}{\underbrace{L_{\text{lat}}}}$$

Каждая переменная выбрана намеренно, чтобы не совпадать с обычной ML-терминологией.

Почему эти выборы важны

Без аккуратных обозначений предложения становятся двусмысленными:

«Уменьшение $D$ улучшает производительность».

У предложения два возможных прочтения:

• Уменьшение размера набора данных (меньше обучающих примеров) может ускорить обучение, но может снизить точность.
• Уменьшение перемещаемого объема данных (например, за счет сжатия или квантования) может ускорить вывод, а влияние на точность зависит от метода и калибровки.

С нашими обозначениями можно записать точно:

«Уменьшение $D_{\text{vol}}$ за счет квантования FP32 в INT8 сокращает трафик памяти параметров вчетверо, а $D$ (обучающие данные) остается неизменным».

Наше обозначение устраняет эту неоднозначность: «$\text{BW}$ ограничивает пропускную способность» допускает только одно прочтение.

Варианты с индексами

Прямой корень называет величину, а индекс указывает, какой ее экземпляр имеется в виду. Соглашение разводит близкие измерения по разным обозначениям, не сводя их к одному символу:

• ${\text{BW}}_{\text{disk}}$, ${\text{BW}}_{\text{network}}$, ${\text{BW}}_{\text{accelerator}}$: пропускная способность в трех точках пути данных
• $D_{\text{vol}}$, $R_{\text{peak}}$, $L_{\text{lat}}$, ${\eta }_{\text{hw}}$: члены железного закона, каждый из которых отделен от общего ML-символа
• $E_{\text{move}}$, $E_{\text{compute}}$, $E_{\text{total}}$: один энергетический бюджет, разделенный на части, которые можно обменивать

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

Уравнение деградации

Уравнение деградации — подогнанная локальная модель. Одно лишь расхождение не определяет направление изменения точности, поэтому $\lambda$ оценивается по размеченным исходам. Некоторые символы ниже, например $\tau$, встречаются в тексте глав, а не в уравнении.

$$\text{Точность}(t)\approx {\text{Точность}}_0-\lambda \cdot \mathcal{D}(P_t\Vert P_0)$$

Следствие для энергии

При эффективных стоимостях на байт и на операцию энергия нагрузки приближенно равна:

$$E_{\text{total}}\approx D_{\text{vol}}\times E_{\text{move}}+O\times E_{\text{compute}}$$

Обозначения глубокого обучения

Книга следует стандартным соглашениям глубокого обучения (Goodfellow et al., 2016) с явным различением системных переменных.

Латинские матрицы и векторы набираются полужирным ($\mathbf{W}$, $\mathbf{x}$); скаляры, размерности, индексы и отдельные элементы матриц остаются курсивом ($N$, $d$, $i$, $W_{ij}$). Общий символ параметров $\theta$ — единственное обычное исключение, и он остается курсивом. Локальная матричная алгебра следует тому же правилу полужирного: операнды-матрицы полужирные ($\mathbf{A}$, $\mathbf{B}$, $\mathbf{C}$), как в общем матричном умножении (GEMM) $\mathbf{C}=\alpha \mathbf{AB}+\beta \mathbf{C}$. Полужирная форма отмечает матричный операнд и отличается от курсивного скалярного размера батча $B$, который в скалярных контекстах остается размером батча.

Обозначения производительности, обслуживания и памяти

Повторно используемые величины производительности и обслуживания следуют тому же правилу избегания коллизий, что и железный закон. Скорости обозначаются через $R$ или описательные греческие символы; число запросов — через $Q_{\text{req}}$, а не перегруженным $N$; загрузка очереди — через $\rho$ с индексом, чтобы голое $\rho$ оставалось доступным для других моделей отношений.

Единицы измерения и точность

• Физические единицы: книга во всем тексте использует метрические единицы СИ — метры, килограммы, секунды, ватты и градусы Цельсия, в соответствии со стандартной инженерной и научной практикой. Если исходные данные были приведены во внесистемных единицах, книга переводит их в СИ и в скобках указывает исходные значения. Между числом и единицей всегда ставится пробел (например, 100 мс, 2 ТБ/с).
• Данные и память: книга использует только десятичные приставки СИ: КБ = $10^3$ байт, МБ = $10^6$, ГБ = $10^9$, ТБ = $10^{12}$. Двоичные приставки в тексте не встречаются; все емкости, пропускные способности и размеры моделей приводятся в десятичных единицах (например, 80 ГБ, 2 ТБ/с, 102 МБ).
• Вычисления: обозначения различают число операций и скорости. Общий объем работы измеряется в FLOP (например, GFLOP, TFLOP), а пропускная способность — в FLOP/s с десятичными приставками (например, GFLOP/s, TFLOP/s).
  • 1 TFLOP = $10^{12}$ FLOP
  • 1 TFLOP/s = $10^{12}$ FLOP в секунду
  • Арифметическая интенсивность обычно выражается в FLOP/байт как единичное отношение (операции с плавающей запятой на перемещенный байт). Это единица отношения, а не символ общего объема работы или пропускной способности.
• Валюта: суммы в долларах обозначаются знаком доллара ($); если не указано иное, стоимости в долларах — это доллары США (USD).
• Точность:
  • FP64: двойная точность (8 байт)
  • FP32: одинарная точность (4 байта)
  • TF32: TensorFloat-32 (режим вычислений тензорных ядер с 19-битным представлением; входы и хранение остаются FP32)
  • FP16: половинная точность (2 байта, стандартный диапазон)
  • BF16: brain float (2 байта, широкий динамический диапазон)
  • FP8: четверть точности (1 байт, формат E4M3 или E5M2)
  • FP4: 4-битный формат с плавающей запятой
  • INT8: 8-битное целое (1 байт)
  • INT4: 4-битное целое; более низкие целочисленные точности следуют тому же шаблону записи INTn заглавными буквами (например, INT3, INT2)

Краткая справка: разрешение коллизий

Частые точки коллизий в литературе по системам машинного обучения:

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

Введение

Назначение

Почему для построения систем машинного обучения нужны инженерные принципы, так сильно отличающиеся от тех, что управляют традиционными вычислительными системами?

Системы машинного обучения подчиняются законам физики. Данные движутся по иерархии памяти, ограниченной пропускной способностью, арифметика выполняется на кремнии, ограниченном мощностью, а предсказания должны поспевать в пределах окна задержки. Эти ограничения — не детали реализации: они определяют решения, начиная от архитектуры модели и заканчивая целевой платформой развертывания. Системы машинного обучения также отличаются от традиционных вычислительных систем тем, что их поведение задается данными, а не только явной логикой или состоянием аппаратуры. Когда обычная программа ведет себя неправильно, инженер часто может проследить исходный код или изучить состояние аппаратуры; когда ведет себя неправильно система машинного обучения, код может выполняться корректно, но выученное поведение дает сбой, потому что данные были неполными, смещенными, устаревшими или перестали быть репрезентативными. Поэтому инженеры машинного обучения одновременно управляют статистической неопределенностью и физическими ограничениями выполнения. Модель, которая помещается в дата-центре, может оказаться бесполезной на телефоне; конвейер обучения, который сходится за неделю на одном ускорителе, на другом займет месяц; точная модель, обученная на данных прошлого года, может незаметно деградировать. Традиционные практики — тестирование, модульность, контроль версий и анализ производительности — по-прежнему необходимы, но их недостаточно. В масштабе системы оптимизация одного слоя может переместить узкое место в другой, поэтому корректность, эффективность и пригодность к развертыванию нельзя проектировать независимо друг от друга. Поэтому первая задача — диагностика: улучшение самого заметного компонента может не изменить сквозного поведения, если связывающим оказывается другое ограничение. Эта книга строит дисциплину, опирающуюся на физические пределы вычислений. Алгоритмические решения влияют на весь стек вплоть до машины, а аппаратные ограничения возвращаются обратно к проектированию модели.

Цели обучения

• Объяснить, почему поведение, заданное данными, и физические ограничения отличают системы машинного обучения от традиционного программного обеспечения
• Применить взгляд «данные — алгоритм — машина», чтобы диагностировать узкие места в перемещении данных, арифметике и пределах машины
• Проанализировать переход ИИ от символических правил к глубокому обучению через призму «горького урока»
• Вычислить члены железного закона производительности, чтобы рассуждать о пропускной способности, задержке и отдаче от вычислений
• Синтезировать перспективы жизненного цикла, развертывания, деградации и пяти опор в инженерные суждения о системах машинного обучения

Системы ИИ сегодня

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

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

Это сочетание порождает двойное требование. Каждая система машинного обучения должна доказать, что выученное поведение заслуживает доверия, и что машина способна выдавать это поведение в пределах доступного времени, памяти, энергии и стоимости. Точная, но слишком медленная модель непригодна; быстрая модель, обученная на нерепрезентативных данных, ошибается с машинной скоростью. Различие яснее всего видно на границах отказов. Дефект в коде может вызвать громкий сбой, тогда как дефект в данных может оставить каждую инструкцию выполненной корректно, а качество предсказаний незаметно ухудшается. В масштабе оба требования охватывают весь стек. Разговорные сервисы координируют пулы GPU¹, одновременно управляя памятью, сетями и теплом. Системы помощи водителю должны объединять потоки данных с датчиков за миллисекунды. Google обрабатывает 8,5 млрд поисковых запросов в день при строгих целевых значениях задержки. Такие системы работают только тогда, когда выученное поведение и физическое выполнение проектируются вместе. Это совместное проектирование начинается с перехода от логики, заданной кодом, к поведению, заданному данными.

Смена парадигмы: ориентация на данные

Этот сдвиг меняет то, как строится программное обеспечение. Вместо того чтобы писать поведение напрямую, инженеры создают процесс, который выучивает поведение из данных. Когда традиционная программа дает сбой, инженер часто может проследить ветвление, изучить кадр стека и исправить путь выполнения. Когда система машинного обучения теряет точность без изменения кода, причиной может стать сдвиг распределения данных, изменившийся процесс разметки или модель, которая больше не отражает поведение в эксплуатации. Андрей Карпаты² описал этот переход как переход от Software 1.0 к Software 2.0 (Karpathy, 2017). Как показывает «Смена парадигмы от Software 1.0 к Software 2.0», Software 1.0 кодирует операционную логику в инструкциях, тогда как Software 2.0 выучивает эту логику на примерах. Поэтому его сбои могут оставаться незаметными, пока оценка или мониторинг не покажут, что поведение изменилось.

Software 2.0 не отменяет код. Инженеры по-прежнему строят конвейеры данных, циклы обучения, инструменты оценки и инфраструктуру обслуживания. Меняется то, где находится поведение приложения. Часть его хранится в выученных весах, которые сформированы данными, поэтому одна только проверка кода не объяснит, что система будет делать.

Смена парадигмы от Software 1.0 к Software 2.0: В Software 2.0 «программист» не пишет логику, а курирует набор данных, который оптимизационный процесс использует, чтобы написать логику. Поэтому отладка смещается вверх по течению: от кода к данным. Аналогия с «компилятором» приблизительна: в отличие от детерминированного компилятора процесс обучения стохастичен и может выдавать разные «исполняемые файлы» из одного и того же «исходного кода».

Ориентация на данные меняет то, что инженеры должны создавать и поддерживать. В исследовании производственных систем Google обнаружено, что код модели занимает лишь малую часть инженерной поверхности (Sculley et al., 2015). Окружающая система — сбор данных, проверка, извлечение признаков, управление ресурсами, обслуживание и мониторинг — оказалась больше и долговечнее.

Производственная работа с ML — в основном окружающая система, а не только код модели.

Этот дисбаланс порождает скрытый технический долг. Каждый окружающий компонент кодирует допущения о том, как выбирается пример, что означает метка, когда вычисляется признак, какая версия попадает в обслуживание и как обнаруживается деградация. Ни одно из этих допущений не видно в матричном умножении, которое дает предсказание, однако любое из них может изменить результат. Одна лишь модель не исправит устаревший прокси, сломанный конвейер признаков или отсутствующий сигнал обратной связи.

Производственные данные, таким образом, — не пассивный вход. Это измерение мира, собранное через конкретный продукт и преобразованное меняющимся конвейером. Если это измерение перестает отражать целевую величину, модель может оставаться численно здоровой, а система — ошибаться. Google Flu Trends дает показательный пример. У сервиса был огромный и своевременный поток поисковых данных, но смысл этих данных менялся под моделью.

Когда поисковые журналы приняли внимание за болезнь (2014)

Контекст: Google Flu Trends (GFT) оценивал активность гриппа по закономерностям в агрегированных поисковых запросах (Ginsberg et al., 2009; Lazer et al., 2014). Его привлекательность состояла в скорости и масштабе, с которыми поисковые запросы поступали по сравнению с клиническими отчетами. Если люди искали симптомы гриппа, когда заболевали, объем запросов казался своевременным прокси заражения.

Режим отказа: прокси оказался нестабильным. Новостные публикации меняли то, что люди искали, а автодополнение меняло то, как они формулировали запросы. Объем запросов начал измерять общественное внимание и поведение продукта в такой же степени, как и болезнь. В сезон 2012–2013 годов GFT оценивал долю визитов к врачу по поводу гриппоподобных заболеваний примерно вдвое выше, чем сообщали CDC, и завышал оценку в 100 из 108 недель.

Системный урок: решением стал не просто больший набор поисковых данных и не лучше настроенная модель. Исследователи объединили поисковые сигналы с клиническими данными сентинельного наблюдения CDC и со временем перекалибровали связь. Объем данных — не истина: поведенческому прокси нужны цикл обратной связи с доверенным измерением и постоянные свидетельства того, что прокси все еще отражает величину, которую система претендует оценивать.

Google Flu Trends дал сбой без традиционного программного дефекта. Код не менялся, но фактически работающая программа изменилась, потому что распределение входов и связь между прокси и целью сдвинулись. По принципу «данные как код» обучающие данные не просто попадают в фиксированную программу; они помогают определить операционную логику, которую реализует модель. Инженеры по-прежнему пишут процедуру оптимизации, но примеры формируют веса модели³ через стохастический градиентный спуск⁴ и родственные методы. Поэтому изменение набора данных может так же неизбежно менять поведение системы, как изменение исходного кода.

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

Логику Software 1.0 часто можно разбить на пути выполнения и граничные условия. Обученная система работает в многомерном пространстве входов, которое технически конечно, но на практике не перечислимо. Задача ImageNet 2012 года делает эту проблему конкретной. Решающая победа AlexNet⁵ помогла запустить эпоху глубокого обучения, однако эталонный тест мог проверить лишь ничтожную долю входов, с которыми может столкнуться модель. Каждый вход — это RGB-изображение $224\times 224$ с $256^{150528}$ возможными конфигурациями пикселей, и это число содержит 362 508 цифр. Набор валидации ImageNet Large Scale Visual Recognition Challenge (ILSVRC) содержит лишь 50 000 изображений (Krizhevsky et al., 2012; Russakovsky et al., 2015). Пусть Полное пространство входов обозначает число возможных входов, а Покрытие тестовой выборкой — число входов, которое набор тестов реально проверяет. Их разрыв создает разрыв верификации («разрыв верификации»):

$$\text{Разрыв верификации}=\text{Полное пространство входов}-\text{Покрытие тестовой выборкой}\approx \text{Полное пространство входов}$$

Разрыв не делает тестирование бесполезным; он меняет то, что тестирование может установить. Оценка до развертывания дает статистические свидетельства по выборке входов, а мониторинг в эксплуатации проверяет, по-прежнему ли рабочая совокупность и наблюдаемые результаты подтверждают эти свидетельства. Статистическая надежность заменяет ожидание исчерпывающего доказательства.

Покрытие тестами — ничтожная доля пространства входов.

Разрыв верификации отмечает более глубокое изменение в том, что инженеры могут утверждать. Традиционные утверждения часто описывают конкретное выполнение, в котором данный вход и состояние ведут программу по определенному пути. Утверждения о производительности ML описывают поведение на совокупности. Фиксированная модель может выдавать один и тот же результат на один и тот же вход, тогда как ее измеренная точность меняется вместе с совокупностью. Данные дают закономерности, на которых учится система, но их шум, дрейф и пропуски тоже создают неопределенность. Поэтому устойчивость не может означать сопротивление любым изменениям. Она требует делать изменения наблюдаемыми и адаптироваться, когда свидетельства перестают подтверждать допущения системы, — это форма вероятностной инженерии.

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

Смена парадигмы

Прежде чем проследить историю ИИ, проверьте, как вы понимаете смену парадигмы в том, как мы создаем программное обеспечение:

• Software 1.0 и 2.0: можете ли вы отличить Software 1.0 (явные инструкции) от Software 2.0 (цели оптимизации)?
• Сдвиг в отладке: можете ли вы указать, какие данные нужно проверить, когда точность падает без изменения кода?
• Разрыв верификации: можете ли вы объяснить, почему конечное тестовое покрытие не может установить статистическую надежность на всем производственном распределении входов?

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

Эволюция узких мест ИИ

Каждая крупная эпоха в искусственном интеллекте столкнулась с жестким системным пределом задолго до того, как ее алгоритмические идеи были исчерпаны. Когда Алан Тьюринг⁶ предложил оценивать машинный интеллект по наблюдаемому результату, а не по внутренней сущности (Turing, 1950), вычислительной технике не хватало объема памяти для хранения знаний о реальном мире и пропускной способности памяти для вычисления сложных моделей. Ранние системы разошлись по фундаментальной линии разлома: персептрон Фрэнка Розенблатта (Rosenblatt, 1958) пытался выучивать веса по сенсорным входам, тогда как ELIZA Джозефа Вайценбаума⁷ (Weizenbaum, 1966) выполняла вручную заданные подстановки по шаблонам. Обе системы упирались в физические реалии: однослойные персептроны не имели механизмов обучения многослойных сетей и нелинейных представлений, а сценарии на основе правил ломались, когда ввод пользователя отклонялся от заранее заданных шаблонов. Последующие эпохи столкнулись с узким местом приобретения знаний, потому что ручной ввод знаний не масштабировался. Современные системы сталкиваются с другим ограничением — вычислительной пропускной способностью.

Хронология в «Хронологии развития ИИ» показывает, как часто упоминается искусственный интеллект в опубликованных книгах; это прокси внимания, а не прямая мера объема исследований. Она выявляет повторяющуюся закономерность: интенсивный оптимизм, за которым следовали «зимы ИИ»⁸, когда финансирование обрушивалось, часто после того, как ограничения систем обнажали разрыв между амбициями и реальными возможностями. Возрождения сочетали алгоритмические достижения с новыми данными и инженерной инфраструктурой. Каждое возрождение снимало одно узкое место и обнажало следующее.

Хронология развития ИИ: Хронологическая кривая-прокси показывает упоминания искусственного интеллекта в опубликованной литературе (Michel et al., 2011); светло-коричневые полосы отмечают два периода «зим ИИ» (1974–1980, 1987–1993). Выноски отмечают статью Тьюринга 1950 года (Turing, 1950), Дартмутскую конференцию (McCarthy et al., 1955), персептрон (Rosenblatt, 1958), ELIZA (Weizenbaum, 1966), Deep Blue (Campbell et al., 2002) и GPT-3 (Brown et al., 2020).

Эпоха до машинного обучения: узкие места логики и знаний

До того как машинное обучение сложилось в самостоятельную дисциплину, инженеры пытались строить интеллектуальные системы в рамках двух последовательных парадигм, и каждая упиралась в фундаментальный барьер масштабирования. Символический ИИ кодировал интеллект в виде логических правил и натыкался на узкое место логики, когда эти правила не могли охватить неоднозначность реального мира. Экспертные системы кодировали интеллект в виде знаний предметной области и натыкались на узкое место знаний, когда получение и поддержка этих знаний обходились дороже, чем стоила сама система. Оба провала показывают один и тот же архитектурный тупик: созданные вручную представления не масштабируются.

Эра символического ИИ и узкое место логики

Первая эпоха инженерии ИИ (1950–1970-е годы) пыталась свести интеллект к манипулированию символами — символическому ИИ; позже этот подход оформился в гипотезу физической системы символов (Newell and Simon, 1976). Исследователи на Дартмутской конференции 1956 года⁹ (McCarthy et al., 1955) предположили, что отдельные аспекты интеллекта можно точно описать и смоделировать машинами. Уже тогда Артур Сэмюэл из IBM показал другой путь: в 1959 году программа для игры в шашки улучшалась в ходе игры с самой собой. Его работа ввела термин «машинное обучение» (Samuel, 1959), хотя доминирующей парадигмой оставался символический подход. Система STUDENT Дэниела Боброва¹⁰ — типичный пример этого подхода (Bobrow, 1964).

Эти системы могли давать впечатляющие демонстрации, однако в эксплуатации они были хрупкими. Их успех зависел от вручную закодированных правил, которые сопоставляли каждую допустимую форму ввода с символическим представлением. STUDENT мог решить задачу по алгебре, если переводил английский текст в уравнения, но небольшое изменение формулировки могло помешать такому переводу. Трудности выходили за пределы языка. Работа Ганса Моравека¹¹ над автономной навигацией в Стэнфорде показала, что задачи, которые людям кажутся тривиальными (видеть, ходить, хватать), инженерно решать гораздо труднее, чем задачи, которые даются людям с трудом, например шахматы или алгебру.

STUDENT (1964)

STUDENT отделял интерпретацию языка от алгебры:

язык     "Два числа в сумме дают 30; одно из них вдвое больше другого."
разбор   x + y = 30, x = 2y
решение  x = 20, y = 10

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

Эра экспертных систем и узкое место знаний

В эпоху экспертных систем инженеры сузили задачу. Вместо универсальных систем рассуждений они кодировали глубокие знания конкретной предметной области. MYCIN, созданный для диагностики инфекций крови, позволял выражать медицинские знания в виде продукционных правил (Shortliffe et al., 1975).

MYCIN (1976)

MYCIN делал свои рассуждения явными. Факты о пациенте запускали читаемые продукционные правила:

факты    окраска=грамположительная, форма=кокк, расположение=скопления
правило  ЕСЛИ факты совпадают ТО организм=стафилококк (уверенность=0.7)
цикл     сопоставить факты -> сработало правило -> обновить уверенность -> повторить

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

MYCIN хорошо показал себя в отдельных тестах, но его успех обнажил узкое место приобретения знаний.¹² Вопрос уже не в том, может ли правило выразить экспертизу. Вопрос в том, как неявное суждение попадает в систему и остается согласованным по мере роста базы правил.

Более быстрые машины могли вычислять больше правил, но не могли быстрее извлекать человеческое суждение. Масштабируемому ИИ требовался способ выводить полезные границы решений из примеров, а не заставлять инженеров заранее перечислять эти границы.

Этот переход не отменил человеческого проектирования; он изменил то, что проектируют инженеры. Вместо кодирования каждого решения они выбирали примеры, представления, цели и измерения, на основе которых решение можно выучить. Поэтому следующая эпоха заменила узкое место приобретения знаний новым вопросом: какие свидетельства должен видеть обучающийся?

Эра статистического обучения и узкое место инженерии признаков

1990-е годы ознаменовались переходом к статистическому обучению и вероятностным системам. Вместо жестко заданной логики системы оценивали вероятности по данным ($p(y\mid x)$). Этот переход подпитывался доступностью цифровых данных и «необъяснимой эффективностью»¹³ больших наборов данных.

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

Ранние системы обнаружения спама

Статистические фильтры перевели решение из вручную написанного правила в вероятность, оцененную по размеченным письмам:

правила: если встречается "free" или "winner" -> спам
обучение: размеченное письмо -> правдоподобия слов -> P(спам | письмо)

Сопровождение никуда не делось. Оно переместилось от редактирования списков ключевых слов к курированию репрезентативных примеров и проверке того, что выученные вероятности по-прежнему отражают современную почту.

Обучение границы решения по данным устранило одно узкое место, но обнажило другое. Статистические алгоритмы, например машины опорных векторов (SVM), могли надежно обучаться только после того, как люди превращали сырые входы в структурированные признаки. В компьютерном зрении, например, инженеры годами разрабатывали вручную математические преобразования, такие как SIFT (Scale-Invariant Feature Transform) и HOG (Histogram of Oriented Gradients), чтобы выделять границы, углы и сводки текстуры, прежде чем подавать их классификатору. Обучающийся алгоритм корректировал границу, а инженеры решали, какие свидетельства он может видеть. Перенос на новую задачу часто означал перестройку всего стека предобработки, превращая кажущееся ограничение алгоритма в узкое место инженерии признаков. Традиционный конвейер делает эти ручные усилия видимыми, потому что несколько вручную созданных этапов предшествовали любому обучению.

Этот гибридный подход сочетал признаки, созданные инженерами, со статистическим обучением. Алгоритм Виолы — Джонса¹⁴ (Viola and Jones, 2001) — типичный пример этой эпохи: он обеспечивал обнаружение лиц в фас в реальном времени с помощью простых прямоугольных признаков и каскадных классификаторов. Он показал, что хорошо спроектированные признаки могут обеспечить практические приложения с низкой задержкой, но лишь в узких областях, где эксперты могли вручную создать подходящие представления.

Традиционный конвейер компьютерного зрения

Обычная система зрения отделяла представление от классификации:

изображение -> изменение размера -> признаки HOG/SIFT -> SVM -> метка

Обучалась только последняя граница решения. Переход от лиц к пешеходам или к другой области означал переработку извлекателя признаков и часто всего конвейера предобработки.

Эра глубокого обучения и узкое место инфраструктуры

Глубокое обучение изменило то, какая часть системы обучается. Вместо признаков, спроектированных людьми, нейронные сети выучивали представления непосредственно из сырых входов, таких как пиксели и аудиосигналы. Процесс обучения теперь мог формировать и представление, и границу решения, что позволило «сквозное» обучение.

Прорыв не был только алгоритмическим. Сверточные нейронные сети (CNN) существовали и раньше (LeCun et al., 1998; LeCun et al., 2015), но AlexNet соединил архитектуру и обучение с совместным проектированием системы: модель, процедура обучения и отображение на аппаратуру выбирались вместе (Krizhevsky et al., 2012). Его параллельные матричные операции соответствовали возможностям GPU. При 60 миллионах параметров, распределенных между двумя GPU GTX 580, AlexNet показал ошибку top-5 в 15,3 процента, что на 41,6 процента лучше следующего лучшего результата того года. Этапы обработки на «схеме архитектуры AlexNet» показывают, как модель выучивает все более богатые представления изображения, прежде чем выдать один из 1000 выходных классов.

Архитектура AlexNet: сеть, которая запустила революцию глубокого обучения на ImageNet 2012 (Krizhevsky et al., 2012). Два параллельных потока GPU обрабатывают входные изображения $224\times 224$ через сверточные слои (зеленые блоки), которые выделяют пространственные признаки при уменьшающемся разрешении, и сходятся через три полносвязных слоя в 1000 выходных классов. При 60 миллионах параметров, обученных на двух GPU GTX 580, AlexNet показал ошибку top-5 в 15,3 процента, что на 41,6 процента лучше результата второго места.

Аппаратура по-прежнему определяла, что можно выучить. Имея всего 3 ГБ видеопамяти (Video Random-Access Memory, VRAM) на каждую GTX 580 AlexNet разделял сверточные и полносвязные слои между двумя потоками GPU. Эта ранняя модельно-параллельная схема предвосхитила современное обучение на нескольких GPU. Глубокое обучение уменьшило потребность в признаках, созданных вручную, но перенесло связывающее ограничение на инфраструктуру, необходимую для хранения данных, перемещения параметров и координации вычислений.

Глубокое обучение фактически обменяло узкое место инженерии признаков на новое узкое место вычислений. Модели вроде GPT-3 (175 млрд параметров) показывают масштаб этой новой задачи. Brown et al. (2020) сообщают об обучении примерно на 300 млрд токенах из отфильтрованного веб-текста, книг и Википедии. По плотной аппроксимации обучения из книги ($C\approx 6\times N\times D$: 2 FLOP на параметр в прямом проходе и 4 — в обратном; выведена в разделе «Обучение моделей»), такой масштаб произведения параметров и токенов соответствует примерно 314 зетта-FLOP вычислений ($1\text{ зетта-FLOP}=10^{21}\text{ FLOP}$). Сам набор токенов занимает примерно 420 ГБ. Поскольку исходная статья не указывает точный кластер, пересчет этого бюджета вычислений в машинное время дает примерно 350–400 GPU-лет на современных облачных GPU (например, NVIDIA V100). Это иллюстративная системная оценка, а не зафиксированный результат измерений. Основная инженерная задача сместилась от описания кошачьего уха к координации распределенного обучения большого масштаба без сбоев.

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

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

Горький урок

Экспертные системы вкладывали инженерные усилия в кодирование знаний предметной области; системы глубокого обучения вкладывают те же усилия в освоение все большего объема данных и вычислений. Горький урок описывает историческую закономерность: общие методы, которые используют растущий объем вычислений, стабильно превосходят подходы, кодирующие человеческий опыт. Ричард Саттон¹⁵ сформулировал эту мысль в эссе «Горький урок» 2019 года (Sutton, 2019). Саттон писал: «Самый важный урок, который можно извлечь из 70 лет исследований ИИ, состоит в том, что общие методы, опирающиеся на вычисления, в конечном счете оказываются наиболее эффективными, и с большим отрывом».

«Эволюция производительности ИИ по парадигмам» сопоставляет представительные эталонные достижения с аппаратной базой. Его последний столбец прослеживает переход от вычисления правил на одном потоке CPU к кластерам из тысяч ускорителей; в качестве иллюстративной опорной точки обучения передовых моделей используется 2,5 млн эталонных GPU-дней (Patel and Wong, 2023).

Эволюция производительности ИИ по парадигмам: представительные системы иллюстрируют рост вычислительного масштаба по эпохам. Детали обучения GPT-4 — оценочные ориентиры, а не официально раскрытые данные.

Точность top-5 на ImageNet и Massive Multitask Language Understanding (MMLU) (см. главу «Бенчмаркинг») измеряют разные способности, но движутся по одной системной траектории. Масштаб оборудования вырос от выполнения на одном CPU-узле до кластеров мощностью в мегаватты, что подтверждает наблюдение Саттона: методы, созданные для использования сырых вычислений, стабильно опережают представления, настроенные вручную.

Более ранние вехи в автоматизированных играх демонстрировали ту же траекторию, управляемую аппаратурой. В шахматах Deep Blue от IBM в 1997 году победил чемпиона мира Гарри Каспарова¹⁶, объединив специализированное шахматное железо, масштабный перебор и знания о шахматах. Его функция оценки кодировала человеческие шахматные эвристики, но именно масштаб перебора, обеспеченный специализированным кремнием, был ключом к тому, чтобы превратить эти знания в игру чемпионского уровня. В го AlphaGo от DeepMind¹⁷ (Silver et al., 2016) достиг сверхчеловеческих результатов: он сочетал обучение с учителем на партиях экспертов с обучением с подкреплением через игру с самим собой и поиск по дереву, направляемый нейронной сетью, вместо опоры на вручную заданную стратегию игры в го.

Урок «горький», потому что нашей интуиции свойственно ошибаться. Естественно считать, что путь к искусственному интеллекту — это кодирование человеческой экспертизы. Однако снова и снова системы, которые используют вычисления для обучения на данных, при достаточном масштабе превосходят системы, опирающиеся на человеческие знания. Закономерность сохранялась в эпохи символического ИИ, статистического обучения и глубокого обучения.

Современные языковые модели, такие как GPT-4, и системы генерации изображений, такие как DALL-E, наглядно иллюстрируют этот принцип. Их возможности возникают не из лингвистических или художественных теорий, закодированных людьми, а из обучения универсальных нейронных сетей на огромных объемах данных с использованием значительных вычислительных ресурсов. Оценки для моделей масштаба GPT-3 дают примерно 1,3 ГВт·ч энергии¹⁸ (Patterson et al., 2021), а обслуживание таких моделей миллионов пользователей превращает вывод в непрерывную задачу по питанию, охлаждению и планированию мощностей дата-центра.

Применение горького урока на практике требует инженерной дисциплины, которая далеко выходит за пределы проектирования алгоритмов. Когда возможности модели растут вместе с сырыми вычислениями, связывающими становятся пропускная способность памяти,¹⁹ задержка межсоединений, отвод тепла и пропускная способность конвейера данных (см. главу «Аппаратное ускорение»).

Масштабирование вычислений превращает модель машинного обучения в артефакт физических систем: такой, которым управляют бюджеты мощности, иерархии памяти и накладные расходы на коммуникацию. Проектирование таких систем требует рассматривать перемещение данных, выполнение арифметики и эксплуатационную надежность как единую задачу. Эта более широкая ответственность и есть инженерия ИИ, которая формально разбирается в «Инженерии ИИ как дисциплине». Чтобы обосновать эту дисциплину, нужно определить ее основной объект через эксплуатационные реалии конкретного производственного сервиса.

Определение систем машинного обучения

Вернемся к фильтру спама, введенному в истории статистического обучения. В производственном масштабе тот же, казалось бы, простой классификатор работает с глобальным потоком почты, измеряемым сотнями миллиардов отправленных и полученных сообщений в день (Statista Research Department, 2024). Крупные провайдеры должны за миллисекунды решить, какие сообщения заслуживают внимания, а какие следует отправить в карантин.

Эта обманчиво простая задача показывает, чем системы машинного обучения отличаются от традиционного программного обеспечения. Вызов начинается с данных. Фильтр обучается на миллионах размеченных примеров и должен постоянно адаптироваться по мере того, как спамеры меняют тактику, вместо того чтобы программисты вручную кодировали каждый шаблон спама. Затем задача становится алгоритмической: модель должна обобщать эти примеры на сообщения, которых она никогда не видела, и балансировать точность и полноту, чтобы законные письма не скрывались. Наконец, то же решение становится инфраструктурной задачей. Провайдеры должны ежедневно обрабатывать миллиарды писем, хранить и обновлять модели по мере эволюции спама и обслуживать предсказания с задержкой менее 100 мс в горизонтально масштабируемых дата-центрах. Классификатор, таким образом, — лишь один компонент развивающейся системы из данных, программного обеспечения и аппаратуры.

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

Системы машинного обучения

Системы машинного обучения — это программные системы, основное поведение которых определяется параметрами, выученными из данных, а не явно запрограммированными правилами. Поэтому производительность одновременно зависит от качества данных, выбора алгоритма и мощности аппаратуры.

1. Значение: требования сквозные. Фильтр спама полезен только тогда, когда его обучающие данные отражают текущие атаки, его модель отделяет вредоносную почту от законной, а путь обслуживания классифицирует каждое сообщение в пределах бюджета доставки. Отказ любого слоя меняет результат, который видит пользователь.
2. Отличие: в отличие от традиционного программного обеспечения точность системы машинного обучения может меняться, когда меняется мир, даже если ее код и веса остаются прежними. Распределение производственных входов может сместиться относительно того, чему выучилась модель, и незаметно изменить качество без ошибки или исключения.
3. Типичная ошибка: модель — это не вся система. Конвейеры данных, преобразования признаков, инфраструктура обслуживания, мониторинг и циклы обратной связи окружают выученные параметры и часто составляют основную инженерную нагрузку (Sculley et al., 2015).

Определение выделяет три диагностических оси: данные, которые описывают задачу, алгоритм, который превращает эти примеры в поведение, и машину, которая выполняет это поведение в рамках эксплуатационного бюджета. Таксономия D·A·M придает этим осям многократно используемую форму.

Один и тот же видимый пользователю симптом может возникать из любой из трех осей. Пропущенное фишинговое письмо может означать, что репрезентативных примеров не хватало, что выученная граница решения была недостаточной или что путь обслуживания не уложился в бюджет задержки. Если считать каждый промах проблемой модели, легко улучшить не тот компонент. Полезная системная таксономия должна разделять эти причины, не делая вид, что они независимы.

Каждое объяснение требует разных свидетельств. Гипотеза о данных отправляет инженера к покрытию, меткам и сдвигу распределения. Гипотеза об алгоритме — к срезам ошибок, емкости модели и цели обучения. Гипотеза о машине — к задержке, пропускной способности, памяти и загрузке. Эти расследования не взаимозаменяемы. Более быстрое железо не добудет примеры, которые никогда не собирались, а больший набор данных не исправит путь обслуживания, который не укладывается в срок из-за заполненной памяти.

Релевантное ограничение — то, ослабление которого улучшает сквозной результат. Идея связывающего ограничения не дает командам оптимизировать самый заметный компонент вместо того, который определяет итог. Поэтому назначение D·A·M операционное: оно указывает следующую гипотезу для проверки и класс воздействий, способных изменить поведение системы. Диагноз предварителен. Как только вмешательство снимает одно ограничение, систему нужно измерить заново, потому что теперь может связывать другая ось. D·A·M — это цикл, а не разовая метка.

Таксономия D·A·M

Таксономия D·A·M — это диагностическая рамка, которая классифицирует любое узкое место производительности системы машинного обучения по трем осям. Данные (Data) определяют, какие примеры и байты система должна обработать; алгоритм (Algorithm) определяет структуру модели и объем работы, необходимый для обучения или предсказания; машина (Machine) определяет доступную мощность аппаратуры для выполнения этой работы. Цель — определить, какая ось является связывающим ограничением.

1. Значение: диагностическая сила конкретна даже до того, как в рассказ входит подробная арифметика железа. Если фильтр спама пропускает новую фишинговую кампанию, потому что обучающий набор никогда не содержал такой тактики, связывающая ось — данные. Если обучающие примеры адекватны, но модель не может выразить закономерность, связывающая ось — алгоритм. Если и то и другое адекватно, но сервис не может классифицировать сообщения достаточно быстро во время всплеска трафика, связывающая ось — машина. Количественная диагностика начинается с вопроса, какая ось ограничивает систему.
2. Отличие: в отличие от традиционного анализа производительности программ, который рассматривает код и данные как отдельные задачи, таксономия D·A·M учитывает, что выбор алгоритма напрямую определяет и размер обучающего набора данных (трансформеру нужно на порядки больше данных, чем линейной модели, чтобы обобщать), и машину, необходимую для его запуска.
3. Типичная ошибка: распространено заблуждение, будто три оси независимы. Переход от простого классификатора к большей модели может потребовать больше памяти, другой инфраструктуры обслуживания и более широкого распределения данных. Оси движутся вместе.

«Треугольник осей D·A·M» показывает эти три оси как взаимозависимый диагностический треугольник, где изменение требований вдоль любого ребра напрямую меняет ограничения двух остальных.

Треугольник осей D·A·M: данные (Data), алгоритм (Algorithm) и машина (Machine) — три взаимозависимые части системы машинного обучения. Двусторонние связи подчеркивают, что изменение одной части может менять требования к двум другим.

Треугольник задает операционный протокол для анализа первопричин. Он превращает сквозной симптом — деградацию точности, нарушения хвостовой задержки или перерасход бюджета — в три систематических пути измерения: проверку входных свидетельств (Data), характеристику математической нагрузки (Algorithm) и профилирование физического выполнения на аппаратуре (Machine). Диагноз заслуживает доверия только тогда, когда ослабление выявленного ограничения улучшает поведение системы целиком.

Двусторонние связи на «Треугольнике осей D·A·M» подчеркивают, что вмешательство в одну вершину часто переносит связывающее ограничение в другую. Переход на более быстрые ускорители (Machine) может оставить исполнительные блоки простаивающими, если ввод-вывод хранилища не успевает подавать входные батчи (Data). Увеличение объема набора данных (Data) может обнажить архитектуру модели, которой не хватает выразительной емкости, чтобы усвоить новые закономерности (Algorithm). Масштабирование емкости модели, чтобы закрыть этот разрыв (Algorithm), может превысить объем памяти ускорителя и вызвать неэффективные обращения к памяти, выгрузку данных (spilling) или ошибки нехватки памяти (Machine). Инженерия системы машинного обучения требует определить текущее связывающее ограничение и предвидеть, куда переместится узкое место после его ослабления.

Хотя треугольник разделяет три оси, чтобы упростить первичную диагностику, реальные системы работают на их границах. Форматы данных определяют трафик памяти, архитектуры моделей задают загрузку функциональных блоков аппаратуры, а бюджеты развертывания перекраивают и представление данных, и проектирование алгоритма. «Ландшафт пересечений D·A·M» показывает эти попарные границы и их общий центр.

Ландшафт пересечений D·A·M: данные, алгоритм и машина начинаются как три разные диагностические линзы, но практические системы машинного обучения живут на их границах. Попарные пересечения отвечают на вопросы, из чего система может учиться, как перемещается информация и как вычисления выполняются эффективно. Их центр — инженерия систем машинного обучения, где все три ограничения должны балансироваться вместе.

Диаграмма Венна упорядочивает эти связи от внешних границ к центру: Data и Algorithm определяют, из чего система может учиться; Data и Machine — как перемещается информация; Algorithm и Machine — как вычисления выполняются эффективно. В центре все три вопроса должны получить ответ одновременно. Это пересечение и определяет инженерию систем машинного обучения.

Эти пересечения отражают физические компромиссы, которые определяют реализацию. Отбор данных и динамика обучения разрешают границу Data–Algorithm, устанавливая, какой объем эмпирического сигнала нужен для сходимости. Инженерия данных и аппаратное ускорение управляют интерфейсом Data–Machine, где ширина шин, линии PCIe и пропускная способность хранилища определяют, как быстро тензоры доходят до исполнительных блоков. Фреймворки, компиляция и планирование ядер разрешают границу Algorithm–Machine, отображая плотную линейную алгебру на исполнительные блоки и минимизируя простои памяти.

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

Анализ D·A·M дает диагностическую рамку, но инженерия реальных систем также требует вертикальной иерархии, которая связывает физические пределы кремния с миссией приложения целиком.

Четырехуровневая иерархия от кремния до миссии

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

1. Аппаратура (кремний). Физическая основа (двигатель) задает пиковую вычислительную пропускную способность $(R_{\text{peak}})$, пропускную способность памяти $(\text{BW})$ и объем памяти. Конкретные аппаратные двойники воплощают эти величины, когда сценарии развертывания требуют числовых ограничений.
2. Системы (платформы). Интегрированная единица развертывания (автомобиль) задает рабочую область через свой бюджет мощности, тепловые пределы и межсоединения на уровне узла. Примеры включают узел обучающего кластера или сенсорный узел мощностью менее ватта.
3. Нагрузки (модели). Алгоритмический спрос (маршрут) складывается из числа операций $(O)$, объема перемещаемых данных $(D_{\text{vol}})$ и их раскладки. Конкретные нагрузки, например GPT-4 и Wake Vision (набор данных для визуальных «слов пробуждения», рассчитанный на микроконтроллеры), воплощают эти требования для отдельных миссий.
4. Миссии (сценарии). Контекст применения (пункт назначения) находится на вершине стека, где система развертывается для решения конкретной задачи. Миссия задает требования вроде времени работы от батареи, задержки в критичных по безопасности ситуациях или потолков стоимости в облаке, которые определяют конфигурацию каждого нижележащего уровня.

Эта иерархия гарантирует, что оптимизация системы никогда не выполняется в архитектурном вакууме. Микрооптимизация матричного ядра имеет смысл, только если она расширяет рабочую область платформы или укладывается в срок критичной миссии. Анализ жизненного цикла в «Инженерии на протяжении жизненного цикла ML» сопоставляет каждую повторяющуюся миссию с ее нагрузкой и связывающим ограничением, связывая пропускную способность кремния с эксплуатационными целями.

Ландшафт систем машинного обучения: четыре парадигмы развертывания

Ландшафт систем машинного обучения охватывает диапазон примерно в $10^6$ раз по вычислительной мощности и в $10^5$ раз по объему памяти. «Четыре парадигмы развертывания» сопоставляет ограничения памяти, вычислений и энергии для четырех парадигм развертывания, которые задают ограничения для всех последующих глав.

Парадигма	Представительная система	Память	Вычисления	Энергия
Облако	Ускорительный узел дата-центра	Большая память устройства плюс хранилище ($\approx 10^{11}\text{Б}$)	Самый производительный уровень ($\approx 10^{15}\text{оп/с}$)	Питание, управляемое дата-центром
Периферия	Робототехнический или промышленный шлюз	Локальная память в рамках ограничений развертывания ($\approx 10^{11}\text{Б}$)	Бюджет локального ускорителя или CPU ($\approx 10^{14}\text{оп/с}$)	Питание от сети, автомобиля или объекта
Мобильные	Смартфон или SoC класса носимых устройств	Общая память приложений ($\approx 10^{10}\text{Б}$)	Нейронные, графические и CPU-блоки класса телефона ($\approx 10^{13}\text{оп/с}$)	Батарея и тепловой лимит
TinyML	Узел на микроконтроллере	Память килобайтного масштаба ($\approx 10^6\text{Б}$)	Всегда включенные вычисления сенсора ($\approx 10^9\text{оп/с}$)	Батарея милливаттного класса

Четыре парадигмы развертывания: представительные ограничения памяти, вычислений и энергии для облачных, периферийных, мобильных систем и TinyML. Они показывают разброс в несколько порядков величины, из-за которого простое переиспользование модели между уровнями невозможно. Точные аппаратные примеры и расчеты пиковых скоростей приведены в главах о железе.

Если читать столбцы памяти и вычислений от облака к TinyML, видно, что крайние точки различаются в $10^5$ раз по памяти и в $10^6$ раз по вычислениям. Именно поэтому инженеры не могут просто уменьшить облачную модель, чтобы она заработала на периферии: каждый уровень требует принципиального перепроектирования осей D·A·M.

Разброс в несколько порядков величины между этими четырьмя парадигмами напрямую переходит в финансовые и эксплуатационные издержки. Архитектура, которая спокойно помещается в памяти ускорителя дата-центра, не может работать без изменений на устройстве класса микроконтроллера. Чтобы преодолеть этот физический разрыв, нужно сбалансировать качество данных, алгоритмическую сложность и возможности аппаратуры с общим экономическим ограничением: полезной работой на доллар.

Полезная работа на доллар

Исследователи часто оптимизируют точность, тогда как инженеры систем должны оптимизировать полезную работу на доллар. Пусть $O_{\text{total}}$ обозначает общее число операций, выполненных при всех предъявлениях примеров, а эффективность затрат — полезные операции, выполненные за доллар. «Масштабирование стоимости» задает согласованную по размерностям модель стоимости первого порядка:

$$\text{Стоимость вычислений}\approx \frac{O_{\text{total}}}{\text{Полезные операции на доллар}}$$

Каждая ось D·A·M по-разному улучшает это отношение. Лучшие данные могут уменьшить число предъявлений примеров, необходимых для достижения целевого качества. Более эффективные алгоритмы уменьшают число операций на пример, а более экономичное железо увеличивает полезные операции на доллар.

Системная инженерия балансирует этот компромисс. Прирост эффективности затрат на 10 процентов позволяет выполнить примерно на 10 процентов больше полезных операций при том же бюджете, но то, направить ли их на больше данных, дополнительные эпохи обучения или более емкую модель, зависит от эластичности кривой обучения для нагрузки. Если ошибка масштабируется как $D^{-\alpha }$ от размера набора данных $D$, эмпирический выигрыш от расширения набора данных на 10 процентов определяется величиной $\alpha \log (1,1)$, а не произвольным фиксированным процентом. Инженер систем должен оценить эту эластичность для целевой нагрузки, чтобы понять, где распределение ресурсов дает наибольшую предельную отдачу.

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

Системы ML и традиционное программное обеспечение

В рамках таксономии D·A·M системы машинного обучения объединяют данные, которые задают поведение, алгоритмы, извлекающие статистические закономерности, и машины, которые выполняют обучение и вывод.²⁰ Чтобы понять, чем инженерия таких систем отличается от традиционного программного обеспечения, стоит начать с того, как они выходят из строя в эксплуатации.

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

Например, в системе помощи водителю обычное управляющее программное обеспечение сообщает о неисправностях аппаратуры или связи через коды диагностических неисправностей и аппаратные сторожевые таймеры. Конвейер восприятия на основе ML вводит режим отказа, невидимый для этих таймеров. Точность обнаружения пешеходов может снизиться с 95 до 85 процентов за несколько месяцев: сезонные сдвиги приносят зимнее солнце под низким углом, сильные осадки или объемную одежду, которой в обучающем распределении было мало. Встроенный ускоритель продолжает запускать ядра компьютерного зрения с полной частотой кадров и не выдает ни одной аппаратной ошибки, однако автомобиль работает с повышенным риском для безопасности, который ускользает от стандартной телеметрии операционной системы.

Масштаб такой деградации серьезен в критичных для безопасности системах. Модель восприятия, работающая на 10 Гц, обрабатывает 36 000 кадров в час. Доля ложноотрицательных срабатываний в 0,1 процента относится только к кадрам с реальными пешеходами, а абсолютное число пропусков зависит от частоты встреч с пешеходами, временной фильтрации, эвристик слияния данных датчиков и ограничений области эксплуатационного назначения (ODD). Деградация на 10 процентных пунктов, с 95 до 85 процентов, напрямую умножает частоту попадания в опасные ситуации для последующей управляющей логики в тех граничных случаях, где обнаружение и так было ненадежным.

Этот режим отказа задействует все три оси D·A·M одновременно. По оси данных входные распределения дрейфуют, когда условия окружающей среды, поведение пользователей или калибровка физических датчиков уходят от обучающей базы (Gama et al., 2014; Quiñonero-Candela et al., 2009). По оси алгоритма модель применяет фиксированные веса параметров к входам, которые нарушают исходные предположения о распределении, порождая искаженные вероятности без численных исключений вроде NaN или бесконечностей. По оси машины ускорители запускают ядра и с максимальной пропускной способностью передают тензоры через иерархии памяти, растиражируя искаженные выходы на миллионы выводов без единого аппаратного прерывания.

Поскольку этот режим отказа не порождает исключений операционной системы и аппаратных сбоев, его обнаружение требует количественных сигналов, которые измеряют расхождение распределений. Как время выполнения аппаратуры раскладывается на физические компоненты задержки, так и деградацию модели можно приблизить как функцию сдвига распределения. Пусть ${\text{Точность}}_0$ обозначает базовую точность при развертывании, $\mathcal{D}(P_t\Vert P_0)$ — статистическую дивергенцию между текущим производственным распределением $P_t$ и обучающим распределением $P_0$, а $\lambda$ — локально подобранную чувствительность к этой мере сдвига. Эта зависимость, формализованная в «уравнении деградации» и показанная на рисунке ниже, и есть уравнение деградации:

$$\text{Точность}(t)\approx {\text{Точность}}_0-\lambda \cdot \mathcal{D}(P_t\Vert P_0)$$

Точность может незаметно снижаться по мере дрейфа распределений.

Эта линеаризация первого порядка отражает локальные тенденции, когда размеченная истина подтверждает эмпирическую зависимость. Дрейф данных возникает, когда $P_t$ отличается от $P_0$, и качество вывода падает, хотя бинарные файлы модели и среда выполнения остаются байт в байт одинаковыми. Приближение перестает работать при сильном коллапсе распределения, а метрика дивергенции $\mathcal{D}(\cdot \Vert \cdot )$ намеренно остается общей — обычно ее вычисляют через дивергенцию Кульбака — Лейблера (KL), расстояние полной вариации или расстояние Вассерштейна. Поскольку одна лишь статистическая дивергенция не определяет ни знак, ни тяжесть падения точности без обратной связи по меткам, диагностическая рамка выделяет три конкретных инженерных рычага:

1. Повысить исходную точность $({\text{Точность}}_0)$. Больший объем обучающих данных, уточненные целевые функции и архитектуры большей емкости поднимают базовую производительность, сдвигая пересечение вверх, не меняя чувствительность к дрейфу.
2. Снизить чувствительность к распределению $(\lambda )$. Аугментация данных, адаптация к домену и регуляризованные представления выравнивают кривую деградации, сохраняя производительность на более широком распределении входов.
3. Отслеживать дрейф и результаты ($\mathcal{D}(P_t\Vert P_0)$). Слежение за статистической дивергенцией в потоках входных признаков дает ранний сигнал тревоги, а отложенные размеченные метки проверяют, привел ли наблюдаемый дрейф к функциональной деградации.

На практике знать, когда пересматривать модель, так же важно, как знать, как ее обучать. Автоматизированная система обслуживания может выдавать тревогу, когда дивергенция распределения пересекает эксплуатационный порог $\mathcal{D}(P_t\Vert P_0)>\tau$, и запускать конвейеры переобучения, когда размеченные метки подтверждают деградацию производительности. Без автоматизированного мониторинга дрейфа система вывода слепа к меняющимся входам. Глава «MLOps» развивает инфраструктуру мониторинга и стратегии оповещения, которые реализуют этот принцип.

Тихая деградация возникает не только из внешних сдвигов среды. Часто она порождается внутренними архитектурными дефектами, известными как перекос обучения и обслуживания (training-serving skew). В производственных системах ML признаки обычно реализуются в двух разных программных стеках: офлайновом пакетном конвейере (например, на Spark или SQL), который строит обучающие наборы из исторических хранилищ данных, и онлайновом микросервисе (написанном на C++, Go или Rust), который вычисляет признаки при выводе в реальном времени с ограничениями задержки в миллисекунды. Если онлайновая логика извлечения признаков расходится с офлайновой даже незначительно — например, считает скользящие средние вместо окон с фиксированным шагом, применяет разные нормировки часовых поясов или заполняет пропуски противоречивыми значениями по умолчанию, — модель получает представления признаков, которые нарушают ее предположения обучения. Бинарный файл модели выполняется без ошибок, буферы памяти остаются корректными, задержка обслуживания остается в норме, но точность предсказаний при развертывании рушится. Перекос обучения и обслуживания по сути является дефектом синхронизации распределенной системы, который проявляется как алгоритмический сбой.

Эти режимы отказа меняют весь инженерный жизненный цикл. Традиционный мониторинг программного обеспечения отслеживает состояние хостов: загрузку CPU, занятость памяти, сетевой ввод-вывод и коды статуса HTTP. Эксплуатация машинного обучения должна отслеживать эти инфраструктурные метрики наряду с качеством данных, распределениями признаков и точностью предсказаний. Поскольку система ML может тихо отказать, когда инфраструктурные метрики выглядят нормальными, проектирование системы должно включать непрерывную оценку от приема данных до обслуживания выводов.

Тихая деградация относится к первой половине требования к системам ML: выученное поведение должно оставаться статистически надежным в нестационарном мире. Вторая половина требования относится к физическому выполнению: машина должна оценивать и обновлять это поведение в строгих бюджетах задержки, памяти, энергии и денег. Поскольку масштаб вычислений по-прежнему определяет возможности ML, системная инженерия требует количественных рассуждений о пропускной способности памяти, арифметической пропускной способности и накладных расходах на коммуникацию, которые физически управляют этим масштабом.

Железный закон систем машинного обучения

Физическая цена вычислительного масштаба становится конкретной в двух знакомых сбоях. Задание обучения простаивает, когда хранилище не может подавать данные ускорителю; путь вывода не укладывается в срок, когда состояние модели движется по памяти или сети слишком медленно. Симптомы различаются, но оба сбоя расходуют один и тот же конечный бюджет времени: на перемещение данных, вычисления и постоянные накладные расходы. Железный закон систем машинного обучения делает эту общую структуру явной, раскладывая полное время выполнения $T$ (секунды) на эти три физические стоимости («железный закон»):

$$T=\underset{\text{Член данных}}{\underbrace{\frac{D_{\text{vol}}}{\text{BW}}}}+\underset{\text{Член вычислений}}{\underbrace{\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}}}}+\underset{\text{Член задержки}}{\underbrace{L_{\text{lat}}}}$$

Это уравнение — математический стержень всей книги. Оно раскладывает полное время, необходимое для любой задачи ML, будь то обучение модели в течение недель или вывод за миллисекунды, на три члена, которые напрямую соответствуют физическим ограничениям двойного требования, введенного в «Системах ИИ сегодня»:

1. Член данных $(D_{\text{vol}}/\text{BW})$ представляет физическую цену перемещения битов. $D_{\text{vol}}$ — объем перемещенных данных (байты), а $\text{BW}$ — пропускная способность памяти или сети (байт/с). Загружаются ли терабайты из облачного хранилища или извлекаются веса из памяти с высокой пропускной способностью, производительность часто ограничивает физика ввода-вывода. Часть I развивает эту основу.
2. Член вычислений $(O/(R_{\text{peak}}\cdot {\eta }_{\text{hw}}))$ представляет цену арифметики. $O$ — число операций с плавающей запятой (FLOP), $R_{\text{peak}}$ — теоретическая пиковая пропускная способность аппаратуры (FLOP/s), а ${\eta }_{\text{hw}}$ — безразмерная реализованная загрузка аппаратуры $(0\le {\eta }_{\text{hw}}\le 1)$. Части II и III развивают этот член.
3. Член задержки $(L_{\text{lat}})$ представляет неустранимую «пошлину» на оркестрацию системы, сетевое взаимодействие и сериализацию (секунды). Эта фиксированная задержка доминирует при развертывании в реальном времени. Часть IV развивает этот член.

Аналогия с железным законом

Название «железный закон» следует за железным законом производительности процессора Паттерсона и Хеннесси (Hennessy and Patterson, 2017). Закон P&H — это мультипликативная декомпозиция (тождество, раскладывающее время CPU на множители), тогда как это уравнение — аддитивная модель первого порядка, которая приближает производительность при упрощающих допущениях.

Аддитивная форма предполагает последовательное выполнение. Когда перемещение и вычисления перекрываются, сумму заменяет нижняя граница по критическому пути из «конвейерного варианта»:

$$T_{\text{pipelined}}\ge \max \left(\frac{D_{\text{vol}}}{\text{BW}},\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}}\right)+L_{\text{lat}}$$

Эта формулировка через максимум — системный аналог перекрытия асинхронных передач данных прямым доступом к памяти (DMA) с работой арифметико-логического устройства (ALU): время более медленной стадии конвейера скрывает задержку более быстрой. Равенство требует идеального перекрытия и предполагает, что $L_{\text{lat}}$ остается вне перекрывающихся фаз.

Даже в аддитивной форме железный закон полезен: как и закон Амдала (Amdahl, 1967), его ценность в том, чтобы определить, какое физическое ограничение доминирует, прежде чем начинать оптимизацию. Уточненное рассмотрение, включая конвейеризацию и методы перекрытия, которые превращают аддитивную модель в формулировку через максимум, используемую на практике, приведено в приложении о таксономии D·A·M.

Раскладка времени выполнения имеет смысл, только если инженер может определить, какой член доминирует на критическом пути. Модель Roofline отвечает на вопрос о границе «перемещение против вычислений» с помощью точки перегиба: ниже перегиба доминирует перемещение данных, выше — пропускная способность арифметики (формальный вывод приведен в приложении о машинных основах, в разделе о модели Roofline). Каждый метод оптимизации, разобранный в этой книге, воздействует на одну из этих переменных: перемещает меньше данных ($D_{\text{vol}}$), выполняет меньше операций ($O$), эффективнее использует аппаратуру (${\eta }_{\text{hw}}$) или скрывает задержку оркестрации ($L_{\text{lat}}$). Оценка обучения уровня GPT-3 делает это воздействие конкретным: показывает, как изменение эффективности распространяется через железный закон.

Обучение GPT-3

Задача: сколько времени займет обучение модели уровня GPT-3 на эталонном кластере из 1024 ускорителей?

Дано:

• Операции $(O)$: $\approx 3,14\times 10^{23}\text{FLOP}$
• Пиковая производительность $(R_{\text{peak}})$: 312 TFLOP/s
• Эффективность $({\eta }_{\text{hw}})$: ≈ 45 процентов (типично для крупномасштабного распределенного обучения)
• Масштаб $(N_{\text{accel}})$: 1024 ускорителя

Расчет:

Поскольку предобучение крупных языковых моделей имеет высокую арифметическую интенсивность и асинхронно конвейеризует загрузку данных за матричным умножением, член вычислений доминирует на критическом пути. Выделив этот член для $N_{\text{accel}}$ параллельных ускорителей, получаем:

$$T_{\text{train}}\approx \frac{O}{N_{\text{accel}}\cdot R_{\text{peak}}\cdot {\eta }_{\text{hw}}}\approx \frac{3,14\times 10^{23}}{1024\times 312\times 10^{12}\times 0,45}\approx 25\text{дней}$$

Результат: 25 дней.

Системный вывод: если повысить загрузку аппаратуры $({\eta }_{\text{hw}})$ с 45 процентов до 60 процентов за счет лучшего планирования и более эффективного исполнения, время обучения сократится до 19 дней, сэкономив 6 дней дорогостоящего вычислительного времени.

Уравнение согласовано по размерностям, потому что каждый член сводится к секундам. Складывать FLOP с байтами так же нельзя, как метры с килограммами: железный закон складывает время с временем и временем. Формальный разбор в приложении о машинных основах (анализ размерностей) проверяет эту согласованность и показывает, как учет единиц измерения предотвращает типичные ошибки моделирования.

Железный закон описывает время выполнения, но время — не единственное физическое ограничение. Для устройств с батарейным питанием на периферии и для кластеров ускорителей масштаба склада одинаково верно, что рассеивание энергии и тепловые пределы часто связывают систему раньше, чем достигаются пределы пропускной способности. Перемещение битов по иерархии памяти взимает энергетическую пошлину, которая по своей логике параллельна задержке члена данных.

Перемещение байта обходится примерно в 145 раз дороже, чем операция FP16: это и есть энергетическая пошлина на перемещение данных.

Пусть $D_{\text{vol}}$ — полный объем перемещенных данных (байты), $E_{\text{move}}$ — энергия на перемещение байта, $O$ — полное число операций, а $E_{\text{compute}}$ — энергия на операцию. «Энергетическая стоимость» формализует эту связь, следуя наблюдению Горовица о том, что перемещение данных может доминировать в энергии арифметики (Horowitz, 2014):

$$E_{\text{total}}\approx \underset{\text{Член перемещения}}{\underbrace{D_{\text{vol}}\times E_{\text{move}}}}+\underset{\text{Член вычислений}}{\underbrace{O\times E_{\text{compute}}}}$$

Для одного обращения перемещение данных может стоить гораздо дороже арифметики, поэтому $E_{\text{move}}\gg E_{\text{compute}}$. При энергетических константах, принятых в этом тексте, перемещение одного байта из внешней динамической памяти с произвольным доступом (DRAM) требует примерно в 145,5 раза больше энергии, чем умножение FP16, и в 800 раз больше, чем умножение INT8 (8-битное целое) (Horowitz, 2014). Доминирует ли перемещение во всей нагрузке, зависит также от числа и ширины передач относительно числа операций. Физическая причина разрыва на одно обращение в том, что перемещение данных требует заряжать и разряжать провода на больших расстояниях, тогда как арифметика выполняется локально в схемах вычислительного блока. Поэтому сокращение лишнего перемещения данных $(D_{\text{vol}})$ может улучшать и скорость, и энергоэффективность.

Железный закон

Железный закон $(T\approx \frac{D_{\text{vol}}}{\text{BW}}+\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}}+L_{\text{lat}})$ — аналитический стержень этой книги. Прежде чем двигаться дальше, проверьте, что вы умеете оперировать его членами:

• Член данных $(D_{\text{vol}}/\text{BW})$: назовите физический ресурс, ограничивающий этот член, и укажите один режим нагрузки, в котором он доминирует.
• Член вычислений $(O/(R_{\text{peak}}\cdot {\eta }_{\text{hw}}))$: назовите величину аппаратуры и коэффициент загрузки, ограничивающие этот член.
• Член задержки $(L_{\text{lat}})$: назовите, какие издержки остаются, когда перемещение данных и арифметика уже оптимизированы.
• Пиковая пропускная способность: если вы удвоите $R_{\text{peak}}$, какой член улучшится и почему остальные члены не изменятся?

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

Отдача от вычислений (RoC) как экономическая линза

Следуя количественной традиции Хеннесси и Паттерсона, отдача от вычислений (RoC) измеряет прирост точности на каждый дополнительный доллар инвестиций в инфраструктуру. При измерении точности по фиксированной шкале RoC имеет единицы «пункты точности на доллар».

$$\text{RoC}=\frac{\Delta \text{Точность}}{\Delta \text{Стоимость вычислений}}$$

Это отношение показывает экономическую границу. Прирост точности на 1 процентный пункт может не пройти проверку RoC, если для него требуется в 10 раз больше $O$ (полного числа операций). Каждая оптимизация в следующих главах нацелена либо на числитель (извлечь больше сигнала из тех же данных), либо на знаменатель (снизить стоимость выполнения вычислений). Если RoC отрицателен или ничтожен, система переусложнена, независимо от ее технической изощренности. Эта экономическая линза превращает «точность» из исследовательской цели в инженерный бюджет.

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

Маячные модели: железный закон на практике

Железный закон организует базовые инженерные императивы этого курса. Член данных требует надежных конвейеров приема, проверки и признаков (глава «Инженерия данных»). Член вычислений требует максимизировать арифметическую интенсивность и загрузку аппаратуры в специализированных архитектурах ускорителей (часть III). Член задержки требует жесткого контроля задержки сериализации, накладных расходов на коммуникацию и джиттера обслуживания (главы «Обслуживание моделей» и «MLOps»). Вместе эти члены превращают абстрактные системные требования в практические физические ограничения.

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

Каждая маячная модель выделяет отдельный случай нагрузки для железного закона. ResNet-50 проверяет пропускную способность вычислений, когда алгоритм многократно переиспользует выученные параметры, а GPT-2/Llama — пределы пропускной способности памяти при авторегрессивной генерации. Для языковых моделей авторегрессивное декодирование генерирует по одному токену за раз; KV-кеш (Key-Value) хранит состояние внимания от предыдущих токенов (механизм внимания подробно вводится в главе «Архитектуры нейронных сетей»), а предзаполнение — это первый проход, который обрабатывает запрос до начала генерации. Режим работы определяет доминирующее узкое место: декодирование с малым батчем передает веса и состояние KV-кеша достаточно быстро, чтобы обнажить пропускную способность памяти, тогда как предзаполнение и обслуживание с большим батчем смещают узкое место к пропускной способности арифметики или коммуникации.

Железный закон делает эти различия математически точными. ResNet-50 применяет одни и те же весовые фильтры во многих пространственных позициях и, при батчинге, ко многим входным примерам; это переиспользование арифметики делает $O/(R_{\text{peak}}\cdot {\eta }_{\text{hw}})$ доминирующим членом, поскольку процессор должен поддерживать высокую арифметическую пропускную способность, а объем данных остается компактным в кеше. GPT-2, напротив, загружает миллиарды уникальных весовых параметров для каждого сгенерированного токена, используя каждый вес только один раз, прежде чем загрузить следующий; его член $D_{\text{vol}}/\text{BW}$ доминирует, потому что ограничением становится пропускная способность памяти, а не арифметика. Применение одного и того же уравнения к двум нагрузкам дает противоположные стратегии оптимизации: удвоение $R_{\text{peak}}$ ускоряет батчевый ResNet-50, как только переиспользование увеличивает число операций на перемещенный байт, но почти не меняет декодирование GPT-2; удвоение пропускной способности памяти $\text{BW}$ ускоряет декодирование, ограниченное памятью, но не меняет сверточные вычисления, насыщающие арифметику. Остальные маячные модели выделяют другие физические границы железного закона: DLRM испытывает нагрузку на объем памяти, потому что таблицы эмбеддингов размером в несколько гигабайт, сопоставляющие миллионы идентификаторов пользователей и товаров, не помещаются в память одного ускорителя и требуют распределенного масштабирования; MobileNetV2 и распознавание ключевых слов проверяют уравнения задержки ($L_{\text{lat}}$) и энергии на устройствах с батарейным питанием и микроконтроллерах, где вывод должен укладываться в миллисекундные сроки при милливаттном бюджете мощности. «Маячные модели как эталонные нагрузки» объясняет, почему каждая маячная модель служит диагностическим инструментом для конкретного узкого места.

Маячные модели как эталонные нагрузки: каждая нагрузка выделяет отдельное узкое место, что позволяет систематически исследовать, как системные ограничения влияют на разные архитектурные паттерны. Количественные характеристики и детали архитектур приведены в главе «Архитектуры нейронных сетей».

Декодирование GPT-2 ограничено пропускной способностью, потому что доминирует член данных.

Отслеживая эти нагрузки от приема данных до развертывания на периферии, каждая глава показывает, как архитектурный выбор распространяет физические и экономические ограничения на всю систему. Каждая маячная модель проявляет свои ограничения по осям D·A·M, обеспечивая проверку инженерных принципов в разных режимах систем. Разделение ролей между повторяющимися примерами книги продуманно: четыре парадигмы развертывания задают оболочку, в которой должна работать система; пять маячных моделей предоставляют нагрузки, которые ее испытывают; а четыре инженерные миссии и три производственных кейса (Waymo, FarmBeats и AlphaFold в разделе «Производственные системы выявляют общие проблемы») сочетают оболочку с нагрузкой в реальных ограничениях.

Тот же диагностический взгляд применим ретроспективно к прорыву, который открыл эпоху глубокого обучения. Система AlexNet сочетала сверточную архитектуру, чьи параллельные матричные операции соответствовали возможностям GPU, с 1,3 млн размеченными изображениями из обучающей части задачи ImageNet 2012 года²¹ (Deng et al., 2009). Поэтому снижение ошибки отражало согласованность работы по осям D·A·M, а не одну только алгоритмическую новизну.

Совместное проектирование по осям D·A·M означает, что оптимизация одного компонента часто переносит нагрузку на другой. Успех совместного проектирования AlexNet обошелся по средствам 2012 года (два потребительских GPU на неделю), но современные фундаментальные модели требуют вычислений для обучения примерно на 7 порядков величины больше. Если железный закон определяет, насколько быстро работает система, то инженерная рамка по-прежнему нужна, чтобы рассуждать о том, насколько эффективно она использует эти ресурсы.

Три измерения эффективности ML

Вопрос об эффективности выявляет напряжение, впервые введенное горьким уроком в разделе «Горький урок». Масштаб движет прогресс ИИ, но все большие наборы данных и бюджеты вычислений сужают участие до самых ресурсно богатых организаций. Даже эти организации в конце концов упираются в физические пределы: мощность дата-центров, пропускную способность памяти и убывающую отдачу от добавления новых параметров.

Распространенные публичные оценки обучения моделей уровня GPT-4 дают бюджет вычислений около 2,5 млн GPU-дней, что означает миллионы долларов расходов на вычисления и заметное воздействие на окружающую среду. Многие исследовательские институты и компании не могут позволить себе конкурировать за счет грубого масштабирования. Эти ограничения по стоимости и доступу делают эффективное использование имеющихся вычислений дополнительным путем к прогрессу.

Эффективность — это диагностика узкого места, а не отдельный прием. Ландшафт D·A·M («Ландшафт пересечений D·A·M») теперь становится картой действий. Отбор данных улучшает то, из чего система может учиться; алгоритмическая эффективность уменьшает работу, необходимую для обучения или предсказания; вычислительная эффективность согласует эту работу с машиной. Оставшееся пересечение — как перемещается информация — проходит через все три, потому что каждое улучшение должно выдержать путь через память и коммуникацию.

Алгоритмическая эффективность — самый ранний рубеж — снижает вычислительные требования за счет лучшего проектирования моделей и процедур обучения. Ее цель — получать больше полезного поведения на операцию, так что возможности растут, не масштабируя каждый ресурс синхронно. Когда алгоритмы потребовали еще больше вычислений, второй критичной осью стала вычислительная эффективность. Она максимизирует загрузку аппаратуры, согласуя логику алгоритма с физикой машины и превращая теоретическую мощность процессора в полезную работу. Совсем недавно третьей осью стал отбор данных: он извлекает больше обучающего сигнала из ограниченного числа примеров и тем самым уменьшает общий член числа операций $O$ железного закона. Хронология в «Исторические тенденции эффективности» ставит эти три измерения рядом до того, как последовательность глав представит их в порядке построения. Вместе эти три измерения дают инженерные инструменты для преодоления стен данных, алгоритма и машины, которые одним только масштабированием не решить.

Исторические тенденции эффективности: три цветовые последовательности соотносят алгоритмическую эпоху, вычислительную эпоху и эпоху отбора данных. Даты под каждым блоком обозначают его интервал: 1980–2010, 2010–2022 и 2023 — настоящее время.

Эти три измерения развивались в разных исторических эпохах, но системная инженерия подходит к ним в обратном порядке. На практике первым идет отбор данных: отсев избыточных обучающих примеров уменьшает общее число шагов обучения еще до того, как модель обучается. Затем следует сжатие модели, которое уменьшает объем параметров и число арифметических операций. Аппаратное ускорение идет последним: оно эффективно отображает оставшиеся операции на физическую иерархию памяти и вычислительные блоки ускорителя. Оптимизация выше по конвейеру раньше оптимизации ниже по конвейеру гарантирует, что дорогостоящие аппаратные ресурсы выполняют только необходимые вычисления.

Траектория архитектур моделей во времени показывает, как развиваются эти измерения. «Траектория алгоритмической эффективности» делает видимым влияние алгоритмической эффективности модель за моделью: одинаковые целевые показатели точности требуют все меньше вычислений по мере совершенствования архитектур.

Траектория алгоритмической эффективности: коэффициент эффективности обучения относительно AlexNet (базовый уровень 2012 года) для классификации ImageNet. Большинство последующих архитектур достигают сопоставимой точности меньшими вычислительными ресурсами, хотя отдельные точки различаются. Траектория от AlexNet (1$\times$) через VGG (Visual Geometry Group), ResNet, MobileNet и ShuffleNet до EfficientNet (44$\times$) демонстрирует снижение требуемых вычислений в 44,5 раза за семь лет, независимо от улучшений аппаратуры (Hernandez and Brown, 2020). Точки начала 2020-х годов и пунктирная аппроксимация через все отмеченные точки — дополнение авторов, а не доказательство продолжения тренда Эрнандеса — Брауна.

Величину улучшений эффективности можно измерить. Между 2012 и 2019 годами вычислительные ресурсы, необходимые для обучения нейронной сети до уровня AlexNet на классификации ImageNet, снизились примерно в 44,5 раза (Hernandez and Brown, 2020). Это улучшение, которое вдвое сокращалось примерно каждые 15 месяцев, опережало прирост аппаратной эффективности, предсказанный законом Мура,²² и показывает, что алгоритмические инновации движут эффективность так же сильно, как и аппаратные достижения.

Одновременно суммарные вычисления для обучения в опубликованных передовых запусках следовали гораздо более крутому ритму, чем закон Мура: подобранное время удвоения составляет примерно 3,4 месяца (Amodei and Hernandez, 2018). Эта суммарная тенденция публикаций — не то же самое, что отношение конечных точек между двумя ключевыми моделями, но она объясняет, почему оптимизация эффективности не является необязательной. Без нее в разработке ИИ могли бы участвовать лишь самые ресурсно богатые организации.

Эти измерения опираются на эмпирическую методику, которая отслеживала вычисления для обучения сотен опубликованных моделей (см. главу «Бенчмаркинг»). Расхождение между спросом, удваивающимся каждые 3,4 месяца, и плотностью транзисторов, удваивающейся примерно каждые два года, и определяет системный разрыв. Одна лишь динамика кремния не может угнаться за этим спросом; чтобы не отставать, нужны накапливающиеся улучшения эффективности в алгоритмах, программных средах выполнения и аппаратных архитектурах (см. главу «Аппаратное ускорение»).

Выигрыши архитектура за архитектурой рассказывают лишь половину истории. Алгоритмические улучшения не могли компенсировать растущие суммарные вычисления для обучения. «Эпоха масштаба» сравнивает иллюстративные конечные точки эпохи AlexNet и уровня GPT-4, отличные от суммарного тренда с 3,4-месячным удвоением, и показывает, почему оптимизация эффективности необходима на каждом уровне стека.

Эпоха масштаба: иллюстративные оценки вычислений для обучения (FLOP) в зависимости от года в логарифмической шкале. Если раннее глубокое обучение (синий) показывало быстрый рост, то эпоха трансформеров (красный) заметно ускорила этот тренд. От AlexNet (2012) до иллюстративных опорных точек обучения уровня GPT-4 (2023) требования к вычислениям выросли примерно на 7 порядков величины (в 16,7 млн раз), что намного быстрее закона Мура. Это сравнение конечных точек отличается от исследований суммарного тренда вычислений для обучения (Amodei and Hernandez, 2018; Sevilla et al., 2022) и используется здесь, чтобы мотивировать специализированную инфраструктуру, описанную в этой книге.

Вместе эти два рисунка выявляют кажущееся противоречие, которое определяет экономику современной разработки ИИ. «Траектория алгоритмической эффективности» показывает рост эффективности в 44,5 раза, тогда как «Эпоха масштаба» показывает рост спроса на вычисления примерно на 7 порядков величины. Однако графики фиксируют разные величины. Первый спрашивает, сколько вычислений нужно, чтобы достичь примерно фиксированной цели по возможностям, тогда как второй позволяет цели расти и фиксирует получившийся бюджет обучения. Эффективность снижает стоимость данной возможности; масштаб определяет, на что тратятся вычисления, ставшие более доступными. Кажущееся противоречие поэтому — экономическая обратная связь, а не разногласие между измерениями.

Парадокс эффективности

Эта динамика — аналог в системах ML парадокса Джевонса. В экономике ресурсов рост эффективности использования ресурса часто увеличивает, а не уменьшает общее потребление. В ИИ выигрыш в эффективности финансирует более крупные модели и более широкие наборы данных, а не более скромные бюджеты вычислений. Если EfficientNet требует в 44,5 раза меньше вычислений, чем AlexNet, чтобы достичь той же точности, организации могут вложить сэкономленное в более крупные модели и более широкие данные. Именно так GPT-3 потребовал на порядки больше вычислений, чем AlexNet, несмотря на выигрыши эффективности на FLOP. Петля обратной связи, в которой эффективность позволяет масштабировать, а масштаб требует эффективности, определяет современный ландшафт инженерии ИИ.

Эта экономическая петля обратной связи показывает, почему эффективность нельзя рассматривать как набор изолированных оптимизаций. Отбор данных (глава «Отбор данных»), сжатие моделей (глава «Сжатие моделей») и аппаратное ускорение (глава «Аппаратное ускорение») должны балансироваться с конкретными ограничениями развертывания. Чтобы одновременно управлять статистической эффективностью и требованиями физического выполнения, нужна единая системная дисциплина.

Инженерия ИИ как дисциплина

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

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

Инженерия ИИ

Инженерия ИИ — это дисциплина проектирования, развертывания и сопровождения систем машинного обучения, которые приводят статистически оцененное поведение к детерминированным целевым показателям надежности, соблюдая эксплуатационные ограничения по всем трем осям D·A·M: качеству данных (Data), корректности алгоритма (Algorithm) и эффективности машины (Machine).

1. Значение: исследования ML обычно оптимизируют только ось алгоритма ($O$ и сходимость). Инженерия ИИ совместно оптимизирует все три оси, ограничивая $D_{\text{vol}}$ требованиями управления данными, $O/(R_{\text{peak}}\cdot {\eta }_{\text{hw}})$ — требованиями задержки в производстве, а совокупное энергопотребление — бюджетами энергии и стоимости. Производственная система, которая в исследованиях достигает 95 процентов точности, но нарушает требование задержки 100 мс в эксплуатации, — провальная система, каким бы ни был ее результат на алгоритмической метрике.
2. Отличие: в отличие от исследований машинного обучения, которые нацелены на одну цель (потерю на валидации) на статическом наборе данных, инженерия ИИ работает с многоцелевой поверхностью ограничений (задержка, пропускная способность, точность, стоимость, справедливость и устойчивость) на распределении, которое непрерывно смещается после развертывания.
3. Типичная ошибка: распространено заблуждение, будто инженерия ИИ — это просто «программная инженерия для ML». Спецификация системы здесь вероятностная. Выход системы ML статистически корректен или некорректен относительно смещающегося распределения, а не верен или неверен относительно фиксированного детерминированного контракта. Поэтому непрерывный мониторинг — структурное требование, а не эксплуатационный выбор.

Формула «стохастические системы с детерминированной надежностью» связывает инженерию ИИ с более ранним дисциплинарным сближением. Вычислительная техника возникла в конце 1960-х и начале 1970-х годов²³, когда вычислительные системы стали слишком сложными, чтобы электротехника или информатика решали их задачи по отдельности, и объединила обе дисциплины вокруг комплексной задачи создания надежных компьютеров из ненадежных физических компонентов. Инженерия ИИ сталкивается с такой же задачей на границе данных, алгоритмов и инфраструктуры. В этой таксономии «инженерия ИИ» обозначает более широкую интеллектуальную дисциплину, а «инженерия систем машинного обучения» — практическую работу по проектированию, развертыванию и сопровождению таких систем в производственных ограничениях.

Инженерия на протяжении жизненного цикла ML

Алгоритмический прорыв требует эффективного приема и предобработки данных, распределенных вычислений на сотнях или тысячах ускорителей, надежной инфраструктуры обслуживания для соблюдения жестких окон задержки и непрерывной телеметрии на основе реальной производительности. Эти обязательства образуют повторяющийся жизненный цикл, а не последовательность, которая заканчивается развертыванием. Объект инженерии теперь — не только код: это код, данные, поведение модели, контекст развертывания и свидетельства мониторинга, развивающиеся вместе. Обратная связь из эксплуатации может вернуть развернутую систему к сбору данных и обучению, превращая привычную линейную траекторию в цикл.

Структурное различие сначала проявляется в инструментах. Десятилетия устоявшейся практики поддерживают поведение, заданное кодом, через систему контроля версий, которая ведет точную историю, конвейеры непрерывной интеграции, автоматизирующие тестирование, и инструменты статического анализа, измеряющие качество. Поведение, выученное из данных, ускользает от этих инструментов, потому что меняющийся артефакт уже не является диффом, написанным разработчиком. Глава «Рабочий процесс машинного обучения» развивает специализированные процессы, которых требуют эти задачи.

Более глубокое различие — важность непрерывной обратной связи. Петли на «Жизненном цикле системы ML» показывают почему. Когда мониторинг фиксирует деградацию производительности, системе нужен не только патч кода. Она может вернуться через сбор данных, подготовку, обучение и оценку перед повторным развертыванием, и итерация становится частью эксплуатационной архитектуры, а не только процесса разработки.

Жизненный цикл системы ML: блок-схема из шести блоков, описывающая сбор данных, подготовку, обучение модели, оценку, развертывание и мониторинг. Две петли обратной связи отличают этот цикл от линейной разработки программ: оценка возвращается к подготовке, если результаты недостаточны, а мониторинг запускает новый сбор данных, когда производительность падает.

Поскольку модель машинного обучения формирует поведение непосредственно из обучающих данных, а не из явной исходной логики, реальные сдвиги распределений меняют результаты выполнения, не изменив ни одной строки кода. Это расхождение ломает привычные процессы разработки программ: Git и текстовый контроль версий не справляются с родословными наборов данных размером в несколько терабайт, а модульные тесты не могут подтвердить стохастические выходы при смещающихся распределениях. Решение этих эксплуатационных задач требует специализированной инфраструктуры. Глава «Инженерия данных» развивает версионирование наборов данных и отслеживание происхождения, а глава «MLOps» задает мониторинг во время выполнения для сдвига распределений. Однако требования каждого этапа жизненного цикла не одинаковы: связывающие физические ограничения зависят от эксплуатационной миссии, которой должна служить система.

От парадигм к миссиям

Верхний уровень иерархии превращает абстрактные системы в конкретные инженерные миссии. Каждая миссия наследует одну из четырех парадигм развертывания, введенных в разделе «Четырехуровневая иерархия от кремния до миссии», и сочетает ее с нагрузкой конкретного сценария. Четыре миссии из «Четырех инженерных миссий» — это сценарии применения, которые повторяются на протяжении всей книги и связанных с ней лабораторных работ. Они служат сквозными проверками инженерных решений. Двукратное увеличение пропускной способности памяти — академический результат, пока не доказано, что оно продлевает время работы от батареи умного дверного звонка или обеспечивает задержку, необходимую для критичного к безопасности автономного восприятия.

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

Четыре инженерные миссии: каждой парадигме развертывания сопоставлена повторяющаяся нагрузка сценария и ее связывающее ограничение.

Контекст развертывания задает жизненный цикл

Контекст развертывания определяет, какие давления жизненного цикла доминируют. Одни и те же этапы применимы ко всем системам ML, но дата-центр мощностью в мегаватты и встроенное устройство мощностью в милливатты создают разные узкие места для сбора данных, обновления моделей, мониторинга и обслуживания.

На одном конце спектра облачные системы ML обучают большие модели и обслуживают миллионы пользователей, обменивая обильные вычислительные ресурсы на ограничения мощности, операционную сложность и высокую стоимость. Глава «Системы машинного обучения» разбирает их архитектурные паттерны, а глава «Аппаратное ускорение» развивает аппаратную основу, которая делает такой масштаб экономически оправданным.

На другом конце системы TinyML работают на микроконтроллерах²⁴ и встроенных устройствах. Их память в килобайтах и бюджеты мощности в милливаттах делают осуществимость важнее качества модели: устройство умного дома должно распознавать команду, расходуя меньше энергии, чем светодиодная лампочка, а датчику, возможно, придется годами обнаруживать аномалии от одной батарейки. Рамка эффективности из раздела «Три измерения эффективности ML» задает управляющие принципы, а глава «Сжатие моделей» развивает методы, которые делают такое развертывание возможным.

Между этими полюсами размещение становится задачей распределения ограничений. Периферийные системы ML переносят вычисления ближе к источникам данных, чтобы снизить задержку²⁵ и требования к полосе пропускания. Мобильные системы ML делят память, тепловой запас и батарею с каждым другим приложением, обменивая сырую скорость на локальность и приватность. Гибридные системы распределяют работу между уровнями, балансируя задержку, приватность, пропускную способность и контроль обновлений.

Каждая позиция на этом спектре развертывания создает свои узкие места, которые определяют, какие измерения эффективности важнее всего, как показано в «Приоритетах эффективности по контексту развертывания»:

Приоритеты эффективности по контексту развертывания: каждая среда развертывания создает свои узкие места и требует подобранных стратегий оптимизации. Облачные системы оптимизируют пропускную способность и стоимость; периферийные — память и энергию; системы TinyML требуют экстремальной эффективности по всем измерениям.

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

Посмотрим, как одно решение о развертывании каскадно проходит через всю систему. Чувствительные к задержке приложения, такие как автономные автомобили или обнаружение мошенничества в реальном времени, требуют периферийных или встроенных архитектур, несмотря на ограниченные ресурсы, тогда как большие языковые модели естественно тяготеют к централизованной облачной инфраструктуре. Однако этот первичный архитектурный выбор определяет гораздо больше, чем то, где происходят вычисления. Облачные системы должны оптимизировать стоимость в масштабе, балансируя дорогие кластеры GPU, хранилище и пропускную способность сети, а это, в свою очередь, определяет, как часто модели переобучаются, какие исторические данные сохраняются и как распределяется нагрузка вывода. Периферийные и мобильные системы сталкиваются с фиксированными лимитами ресурсов, которые ограничивают сложность модели и частоту обновлений, вынуждая к агрессивному сжатию модели²⁶ и тщательному планированию. Самые строгие ограничения возникают во встроенных средах и средах TinyML, где важен каждый байт памяти и каждый милливатт мощности.

Операционная сложность растет по мере того, как системы становятся более распределенными. Централизованные облачные архитектуры выигрывают от зрелых инструментов развертывания и управляемых сервисов, тогда как периферийным и гибридным системам приходится координировать сбор данных с датчиков с разной связностью, отслеживать модели, развернутые на тысячах устройств, проводить поэтапные выкатки с возможностью отката и агрегировать сигналы мониторинга с географически распределенных узлов (глава «MLOps»). Соображения о данных создают конкурирующие давления. Требования к приватности или регуляторы суверенитета данных могут толкать вычисления к периферии, тогда как потребность в больших обучающих данных тянет к централизованной облачной агрегации. Обновления моделей также ведут себя по-разному на всем спектре. Облачные архитектуры позволяют быстро итерировать благодаря централизованному управлению трафиком, тогда как периферийные развертывания требуют удаленных обновлений с аккуратным управлением пропускной способностью и возможностью отката.

На практике выбор развертывания редко бывает простой альтернативой «или — или». Производственные архитектуры ML часто охватывают несколько уровней, чтобы согласовать конфликтующие физические и статистические требования. Система может разделить вычисления между периферийными устройствами, чтобы уложиться в окна ответа менее миллисекунды и требования к приватности данных, а выборочную телеметрию направлять в централизованные облачные кластеры для непрерывного обучения и переоценки моделей. Выбор встроенной или периферийной цели ограничивает гораздо больше, чем объем параметров. Он определяет сбор данных на входе, обучение с учетом квантования, оценку с аппаратурой в контуре, протоколы развертывания по воздуху (OTA) и агрегацию удаленной телеметрии. Физические пределы выполнения на одном уровне неизбежно перестраивают каждую фазу инженерного жизненного цикла.

Производственные системы выявляют общие проблемы

Пример развертывания становится инженерным инструментом, когда раскрывает связывающее ограничение, стоящее за проектом. Три производственные системы — Waymo, FarmBeats и AlphaFold — охватывают крайние точки спектра развертывания и показывают, как одинаковые компромиссы по осям D·A·M заставляют прибегать к совершенно разным инженерным решениям:

• Автономное вождение²⁷ упирается в критичную для безопасности задержку и актуальность данных. Открытый набор данных Waymo содержит данные камер и LiDAR, собранные в разных условиях вождения (Sun et al., 2020), и иллюстрирует мультимодальные входы и географическое покрытие, которые должен обрабатывать стек восприятия. В более широком случае используется типичный высокоответственный гибридный паттерн: вывод на борту автомобиля для низкой задержки и облачная инфраструктура для обучения и оценки.
• FarmBeats²⁸ (Vasisht et al., 2017) упирается в связность и актуальность данных. Платформа точного земледелия Microsoft подключает полевые датчики к локальному шлюзовому ПК для обработки на периферии. Сеть в свободных телевизионных диапазонах (TV white space) переносит данные по всей ферме, тогда как более слабое интернет-соединение «ферма — облако» ограничивает синхронизацию.
• AlphaFold (Jumper et al., 2021) упирается в вычислительно емкое обучение и курированные научные данные. Система предсказания структуры белков от DeepMind решила полувековую задачу вычислительного предсказания структуры белков с точностью, близкой к экспериментальной. AlphaFold представляет вычислительно емкий облачный паттерн развертывания. Первичное обучение использовало 128 ядер TPUv3 примерно в течение недели, затем около четырех дней дообучения; в основе лежали экспериментально определенные структуры из Protein Data Bank.

Эти системы дополняют маячные модели, показывая, как одни и те же базовые проблемы (качество данных, сложность модели и масштаб инфраструктуры) проявляются при совершенно разных ограничениях. Вместо того чтобы изучать каждую систему изолированно, их разбирают через призму таксономии D·A·M. Тот же феномен дрейфа данных, который затрагивает модели восприятия Waymo при меняющейся погоде, влияет и на обнаружение болезней культур FarmBeats в течение сезонов роста, хотя инженерные решения различаются в зависимости от ограничений машины.

Взаимозависимости по осям D·A·M создают конкретные инженерные узкие места в данных, алгоритмах и инфраструктуре. Изучение крайних случаев развертывания показывает эти ограничения в самых жестких формах.

Данные реального мира по природе зашумлены и асинхронны. Автономные автомобили обрабатывают большие мультимодальные потоки датчиков LiDAR²⁹ и камер (Sun et al., 2020), что требует аппаратно синхронизированного захвата и фильтрации от деградации датчиков из-за дождя, тумана или бликов на объективе. Масштаб усугубляет эти проблемы качества на каналах с ограниченной пропускной способностью: FarmBeats должна фильтровать и агрегировать телеметрию агродатчиков на локальном периферийном шлюзе, прежде чем синхронизировать данные через прерывистое соединение «ферма — облако», тогда как AlphaFold во время обучения требует высокопроизводительного доступа к курированным экспериментально определенным структурам из Protein Data Bank.

Дрейф данных создает постоянное эксплуатационное бремя поверх проблем качества и масштаба. Статистические свойства входных данных меняются со временем, и модели настолько надежны, насколько их выравнивание с текущим распределением (Gama et al., 2014; Quiñonero-Candela et al., 2009; Koh et al., 2021). Открытый набор данных Waymo сообщает о заметных разрывах между доменами в Сан-Франциско, Финиксе и Маунтин-Вью (Sun et al., 2020)³⁰; обнаружение таких региональных сдвигов требует непрерывного мониторинга статистики входов до того, как они превратятся в сбои системы.

На границе алгоритма и инфраструктуры вычислительная интенсивность задает верхнюю границу возможностей. Фундаментальные модели масштаба GPT-3 («Эпоха глубокого обучения и узкое место инфраструктуры») требуют зетта-FLOP вычислений, а даже меньшие научные модели, такие как AlphaFold, требовали недель специализированного обучения на ускорителях. Системные инженеры должны оптимизировать «FLOP/s на ватт», чтобы сделать такие модели экономически и экологически жизнеспособными. Однако одного сырого масштаба недостаточно. Разрыв обобщения остается центральным алгоритмическим риском: модель может показывать 99 процентов точности на бенчмарках, но лишь 75 процентов в реальном мире. Для критичных к безопасности систем автономного вождения Waymo сокращение этого разрыва — требование, от которого зависят жизни, и оно требует методов устойчивости, которые охватывают длинный хвост граничных случаев.

В производственном развертывании разрыв между обучением и обслуживанием описывает различие между гибкой средой, где рождаются модели, и жесткой средой, в которой они работают. Компромиссы между задержкой и пропускной способностью задают архитектуру. Системы восприятия в духе Waymo требуют решений с низкой задержкой по безопасности на периферии, тогда как AlphaFold работает в облаке, а время его вывода зависит от длины белка и конфигурации. Многоуровневая координация добавляет сложности: голосовые ассистенты выполняют легкое распознавание ключевых слов на микроконтроллерах (TinyML), чтобы гарантировать мгновенное пробуждение в жестких бюджетах милливатт, но передают сложные запросы на естественном языке облачным кластерам GPU.

Наконец, по мере масштабирования систем их влияние на общество становится инженерной задачей первого класса, которая пересекает все три оси D·A·M. Справедливость и смещения нужно контролировать заранее, поскольку модели могут непреднамеренно усваивать общественные предубеждения, присутствующие в обучающих данных. Ответственная инженерия требует систематического аудита качества по демографическим подгруппам, чтобы обеспечить равные результаты. Требования к прозрачности и приватности дополнительно ограничивают проект. Многие глубокие сети работают как «черные ящики», однако в таких областях, как здравоохранение или финансы, заинтересованным сторонам нужна интерпретируемость. Системы также должны быть устойчивы к атакам вывода³¹, которые пытаются извлечь чувствительные обучающие данные из предсказаний модели.

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

Рамка пяти опор

Производственным системам ML нужна эксплуатационная рамка, которая распределяет ответственность между конвейерами данных, математическими формулировками, аппаратным выполнением и управлением, не разрывая их физических связей (Paleyes et al., 2022). Традиционная инженерия программ изолирует компоненты за модульными интерфейсами; в системах машинного обучения абстракции протекают, потому что ошибки распространяются через статистические распределения и физические состояния аппаратуры. Система может выйти из строя не только из-за программных дефектов, но и из-за незаметного дрейфа распределений, исчерпания пропускной способности памяти или теплового ограничения частоты (thermal throttling).

Как показано на «Рамке пяти опор», эти обязанности организованы в пять взаимосвязанных дисциплин, опирающихся на общий технический фундамент. Каждая опора очерчивает эксплуатационную границу, а фундамент под ними обеспечивает физические и экономические пределы — пропускную способность вычислений, объем памяти, пропускную способность межсоединений и бюджеты мощности, — которые управляют выполнением.

Рамка пяти опор: архитектурный фундамент инженерии систем ML, организованный в пять основных дисциплин: инженерия данных, системы обучения (обучение моделей), инфраструктура развертывания (развертывание моделей), эксплуатация и мониторинг (эксплуатация и сопровождение), а также этика и управление. Опоры поддерживаются базовыми практиками эффективности, оценки и надежности.

Разбор конкретного сбоя показывает, как эти границы распределяют эксплуатационную ответственность. Предположим, что детектор слова пробуждения на устройстве после обновления модели перестал срабатывать для пользователей в комнатах с сильной реверберацией. Диагностика начинается с конвейера входных данных: отфильтровал ли прием реверберационные акустические профили, были ли метки повреждены при предобработке и может ли родословная конвейера проследить точные обучающие разбиения, использованные для обновления? Опора инженерии данных (глава «Инженерия данных») управляет системами приема, проверки, версионирования и родословной, которые определяют, что алгоритм может математически извлечь.

Если набор данных содержит репрезентативные акустические образцы, сбой может проистекать из дефектов сходимости или масштабирования выполнения. Опора систем обучения (глава «Обучение моделей») управляет границей между проектированием алгоритма и физическими вычислениями: координирует распределенные кластеры ускорителей, оптимизирует коммуникацию по топологиям межсоединений, организует восстановление из контрольных точек при аппаратных сбоях и балансирует численную точность и стоимость вычислений.

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

После развертывания основной режим отказа становится временным. Опора эксплуатации и мониторинга отвечает за состояние системы после запуска, когда производственные распределения данных дрейфуют, акустическая среда меняется, а точность вывода незаметно падает, тогда как стандартные инфраструктурные метрики — загрузка CPU, запас памяти и пропускная способность сети — остаются в норме. Эта дисциплина объединяет телеметрию, канареечные выкатки, автоматические механизмы отката и конвейеры непрерывной оценки, чтобы обнаружить незаметную деградацию модели до того, как она повлияет на пользователей.

Наконец, профиль сбоев может показывать систематическое смещение по демографическим группам, например повышенные ошибки для определенных акцентов или диапазонов высоты голоса, а непрерывная запись звука создает строгие обязательства по приватности и регулированию. Опора этики и управления (глава «Ответственная инженерия») переводит нормативные требования в проверяемые инженерные ограничители: она устанавливает происхождение данных, агрегацию с сохранением приватности, аудит справедливости, пределы безопасности и регуляторную подотчетность на протяжении всего жизненного цикла системы.

Альтернативные таксономии часто строго организуют эти задачи по программному компоненту или линейной фазе жизненного цикла. Структура из пяти опор вместо этого отражает эксплуатационные границы производственных инженерных команд и сохраняет их физические связи. Конвейеры данных на входе задают пределы сходимости; выбор распределенного обучения определяет объем памяти и задержку на этапе обслуживания; среды выполнения развертывания определяют, какие операции телеметрии возможны; а политики управления накладывают необсуждаемые ограничения на все четыре опоры. Выделение этики и управления в самостоятельную инженерную опору не дает безопасности, приватности и справедливости превратиться в необязательные проверки «постфактум» под давлением сроков.

Вместе опоры переводят концептуальные оси таксономии D·A·M («Четырехуровневая иерархия от кремния до миссии») и хронологические этапы жизненного цикла («Инженерия на протяжении жизненного цикла ML») в эксплуатационную ответственность инженеров. Инженерия данных опирается на ось Data; системы обучения и инфраструктура развертывания ведут компромиссы между сложностью алгоритма (Algorithm) и аппаратными ограничениями машины (Machine); эксплуатация и мониторинг отслеживают временную стабильность всех трех осей; а этика и управление задают эксплуатационные границы, в которых должна работать система. Эта таксономия отражает фундаментальный переход машинного обучения от изолированных алгоритмических экспериментов к дисциплинированной системной инженерии, где главная цель — поддерживать предсказуемое, эффективное и надежное выполнение на физической аппаратуре.

Эта последовательность определяет архитектуру книги. Понимание систем ML требует сначала анализа физических инвариантов аппаратуры и конвейеров данных, затем — масштабирования распределенных алгоритмов обучения на кластерах ускорителей и, наконец, оптимизации компиляции и обслуживания во время выполнения при жестких рамках задержки и энергии.

Организация книги

Пять опор определяют, что координируют инженеры систем ML; четыре части этой книги задают педагогическую последовательность, по которой ими овладевают. Организующий принцип — контекст прежде теории: физические пределы аппаратуры и узкие места приема данных определяют выбор алгоритмов, а не наоборот. Читатель сначала усваивает эксплуатационные границы и словарь (часть I), затем строит модели (часть II), оптимизирует вычислительную эффективность (часть III) и развертывает системы в соответствии с производственными соглашениями об уровне обслуживания (часть IV). В «Организации книги» эта четырехчастная последовательность описана подробнее.

Организация книги: четыре части следуют педагогической последовательности от контекста (Основы) через теорию (Построение) к практике (Оптимизация, Развертывание). Каждая часть опирается на словарь и рамки предыдущих, поэтому методы оптимизации части III предполагают знакомство с архитектурами моделей части II, а практики развертывания части IV — владение частями II и III.

Часть I закладывает физический и архитектурный словарь раньше, чем появляется аппарат моделей. Эта вступительная глава рассматривает инженерию систем ИИ как дисциплину, управляемую физическими ограничениями, и вводит таксономию D·A·M, измерения эффективности и модель пяти опор. Глава «Системы машинного обучения» описывает спектр развертывания от облачных дата-центров до микроконтроллеров TinyML мощностью в милливатты и показывает, как тепловой расчетный предел, глубина иерархии памяти и бюджеты задержки определяют каждый уровень. Глава «Рабочий процесс машинного обучения» прослеживает сквозной жизненный цикл от постановки задачи до производственного обслуживания и указывает, где накапливаются петли обратной связи и технический долг. Глава «Инженерия данных» анализирует узкие места ввода-вывода хранилищ, конвейеры извлечения, преобразования и загрузки (ETL) и хранилища признаков, показывая, что пропускная способность приема данных задает эксплуатационный потолок для выполнения моделей дальше по конвейеру.

Часть II переводит эти ограничения среды в навыки построения моделей. Глава «Вычисления в нейронных сетях» выводит базовые вычислительные ядра — матричные умножения, свертки и механизмы внимания — и анализирует их вычислительные графы. Глава «Архитектуры нейронных сетей» объединяет эти примитивы в полные топологии сетей. Обе главы опираются на пять маячных моделей из раздела «Маячные модели: железный закон на практике» (ResNet-50, GPT-2/Llama, MobileNetV2, DLRM и распознавание ключевых слов), чтобы привязать вычислительные требования к стандартизированным нагрузкам. Глава «Фреймворки машинного обучения» разбирает вычислительные графы, автоматическое дифференцирование и среды выполнения в PyTorch и TensorFlow. Глава «Обучение моделей» описывает распределенное выполнение, синхронизацию градиентов, управление памятью оптимизатора и сохранение контрольных точек при ограничениях памяти ускорителя.

Часть III меняет условия железного закона, чтобы максимизировать эффективность без потери точности. Глава «Отбор данных» снижает число FLOP при обучении, отфильтровывая избыточные примеры, отбирая подмножества с высокой информативностью и ускоряя достижение сходимости. Глава «Сжатие моделей» снимает нагрузку на пропускную способность памяти и уменьшает объем параметров с помощью квантования после обучения, прореживания весов и дистилляции знаний, так что модели помещаются в жесткие бюджеты SRAM и HBM ускорителя. Глава «Аппаратное ускорение» разбирает микроархитектурные механизмы GPU и специализированных интегральных схем (ASIC) и показывает, как систолические массивы, тензорные ядра и иерархии памяти с высокой пропускной способностью обеспечивают высокую арифметическую интенсивность. Глава «Бенчмаркинг» задает строгие протоколы для измерения устойчивой пропускной способности вычислений, хвостовой задержки и энергоэффективности, отделяя настоящие аппаратные узкие места от артефактов измерений.

Часть IV развертывает эти оптимизированные артефакты в производственных средах, где доминируют динамика выполнения, незаметный дрейф данных и эксплуатационные ограничения. Глава «Обслуживание моделей» проектирует движки вывода, которые управляют динамическим батчингом запросов, выделением памяти KV-кеша и планированием ядер в строгих соглашениях об уровне обслуживания по задержке. Глава «MLOps» строит непрерывные конвейеры телеметрии, чтобы следить за состоянием предсказаний, обнаруживать дрейф распределений и проводить канареечные выкатки до того, как незаметная деградация модели повлияет на пользователей. Глава «Ответственная инженерия» встраивает проверку безопасности, аудит смещений и ограничения дифференциальной приватности прямо в жизненный цикл системы. Глава «Заключение» подводит итог полной методологии и готовит читателя к переходу от мастерства на одном узле к оркестрации распределенного парка машин.

Эта книга охватывает режим одного узла: один хост с одним-восемью ускорителями, каждый из которых обычно использует локальную память устройства и обменивается данными по межсоединению внутри узла, такому как PCIe или NVLink. Связывающее ограничение зависит от нагрузки и может быть объемом памяти устройства, пропускной способностью памяти, пропускной способностью вычислений или коммуникацией по межсоединению. В масштабе парка, где тысячи узлов координируются через сетевые структуры, узкое место смещается к бисекционной пропускной способности — совокупной емкости по разрезу сетевого кластера. Указания о путях чтения, учебных результатах, предварительных требованиях и о том, как извлечь максимум из учебника, содержатся в предисловии.

Аналитические рамки из разделов «Три измерения эффективности ML» и «Рамка пяти опор» работают, только если инженеры также отказываются от допущений, перенесенных из соседних областей. Каждая зрелая дисциплина накапливает интуицию, которая работает в ее границах, но подводит за их пределами. Инженерия систем машинного обучения особенно уязвима к таким заимствованным допущениям, потому что стоит на стыке программной инженерии, статистики и проектирования аппаратуры. Традиционное программное обеспечение предполагает детерминированное выполнение; классическая статистика предполагает стационарные распределения данных при нулевой стоимости вычислений; проектирование аппаратуры предполагает фиксированные потоки инструкций. Смешение этих взглядов без столкновения с их противоречиями прямо ведет к хрупким системам и напрасным вычислениям.

Заблуждения и ловушки

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

Заблуждение и ловушка

Заблуждение: лучшие алгоритмы автоматически дают лучшие системы.

Инженеры часто полагают, что алгоритмическая изощренность определяет производительность системы, но это игнорирует железный закон («Железный закон систем машинного обучения»). Vision Transformers показывают, что архитектура и масштабное предобучение дают сильные результаты распознавания изображений (Dosovitskiy et al., 2021), но полезность в производстве по-прежнему зависит от бюджетов вычислений, перемещения памяти и задержки. В производстве модель, которая на 1 процент точнее, но нарушает требования задержки, фактически бесполезна. Поэтому выбор производственной модели — это задача условной оптимизации: максимизировать качество решения при ограничениях на задержку, память, энергию, стоимость и надежность. Скрытый технический долг, окружающий производственные модели, показывает, что код модели — лишь видимый центр гораздо большей системы. Хорошо спроектированная система с более простой моделью может превзойти более изощренную архитектуру без надежной инфраструктуры.

Заблуждение и ловушка

Ловушка: рассматривать системы ML как традиционное программное обеспечение, которое случайно включает модель.

Инженеры применяют к системам ML традиционные практики тестирования и развертывания, но эти системы отказывают качественно иначе («ML по сравнению с традиционным программным обеспечением»). Традиционные ошибки часто дают немедленные исключения или сбои; системы ML могут незаметно деградировать неделями или месяцами, прежде чем это заметит кто-то. A/B-тесты в обычном программном обеспечении могут быстро показать ясный сигнал, тогда как сравнение моделей ML может потребовать более длительных окон наблюдения, чтобы обнаружить небольшие различия точности в подгруппах. Модульные тесты проверяют детерминированные пути выполнения; системам ML нужна инфраструктура мониторинга, чтобы ловить ненадежные предсказания, дрейф данных и сбои калибровки. Команды, которые развертывают ML только с конвейерами непрерывной интеграции и непрерывной доставки (CI/CD), рискуют получить незаметные сбои: наборы тестов и проверки состояния показывают «все в порядке», пока качество предсказаний для пользователей падает.

Заблуждение и ловушка

Заблуждение: высокая точность на эталонных наборах данных говорит о готовности к производству.

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

Заблуждение и ловушка

Ловушка: оптимизация отдельных компонентов без учета взаимодействий в системе.

Инженеры оптимизируют задержку вывода изолированно, но закон Амдала определяет сквозную производительность. Команда сокращает вывод модели с 45 мс до 15 мс и ожидает пропорционального улучшения. Однако предобработка занимает 60 мс, а постобработка добавляет 25 мс, поэтому общая задержка снижается лишь с 130 мс до 100 мс. Это улучшение на 23 процента, а не ожидаемые 67 процентов. Ландшафт D·A·M («Ландшафт пересечений D·A·M») показывает, что оси Data, Algorithm и Machine образуют взаимозависимую систему, где оптимизация одного компонента переносит узкие места, а не устраняет их. Выигрыш на уровне компонента не определяет сквозного улучшения: результат зависит от того, какую долю всего пути занимает оптимизируемый компонент.

Оптимизация только вывода почти не меняет сквозную задержку.

Заблуждение и ловушка

Заблуждение: системы ML можно развернуть один раз и оставить работать бесконечно.

Развернутые системы ML не сохраняют статичную производительность во времени: сдвиги распределения в среде ухудшают замороженную модель, даже если исполняемый код остается нетронутым. В этом иллюстративном сценарии рекомендательная система, развернутая с точностью 85 процентов, падает до 80,2 процента за 6 месяцев по мере изменения покупательских паттернов, теряя 4,8 процентного пункта без каких-либо изменений кода. Поэтому жизненный цикл ML («Инженерия на протяжении жизненного цикла ML») рассматривает мониторинг результатов и переобучение на основе доказательств как эксплуатационные требования. Системы обнаружения мошенничества и обработки естественного языка сталкиваются с тем же риском: поведение пользователей меняется, появляются враждебные паттерны, словарь дрейфует, тогда как бинарный файл сервиса остается прежним. Без непрерывного мониторинга системы выглядят здоровыми, в то время как качество предсказаний незаметно разрушается. Организации, которые воспринимают развертывание как однократную передачу, обнаруживают сбои только после жалоб клиентов или ухудшения бизнес-метрик, которые вынуждают к экстренному аудиту.

Заблуждение и ловушка

Ловушка: считать, что одной экспертизы в ML достаточно для инженерии систем ML.

Организации нанимают исследователей ML, ожидая готовых к производству систем, но рамка пяти опор («Рамка пяти опор») требует интегрированной экспертизы в алгоритмах, программном обеспечении, системах и эксплуатации. Команды с сильными навыками ML, но ограниченным опытом систем, могут не выполнить целевые показатели пропускной способности, потому что дизайн API, структура хранения и инфраструктура обслуживания определяют реальную производительность. И наоборот, программная инфраструктура, построенная без понимания ML, может внести ошибки предобработки или признаков, которые ухудшат поведение модели без явных сбоев системы. Примеры развертывания показывают, что производственный ML требует согласованного внимания к данным, моделям, инфраструктуре и организационным процессам, а не только к алгоритмическому качеству (Paleyes et al., 2022). Эффективные команды объединяют исследователей ML, инженеров программного обеспечения и специалистов по эксплуатации, а не ждут, что одна роль освоит все навыки. Производственные сбои обычно возникают на стыках между выученными весами, физической аппаратурой выполнения и эксплуатационными процессами.

Итоги

Системы машинного обучения должны выполнять два требования одновременно: выученное поведение должно оставаться заслуживающим доверия, а машина должна обеспечивать это поведение в физических и экономических пределах. Переход к Software 2.0 объясняет, почему поведение, выученное из данных, может незаметно отказать при изменении распределений. История парадигм ИИ и горький урок объясняют, почему прогресс снова и снова приходил от систем, которые умели использовать больше вычислений, а не от вручную закодированной экспертизы. Таксономия D·A·M локализует связывающее ограничение, а уравнение деградации, железный закон и рамки энергии и эффективности превращают эти ограничения в количественные диагнозы.

Жизненный цикл, спектр развертывания и производственные примеры показывают, почему непрерывная итерация и проектирование с учетом контекста обязательны. Пять маячных моделей (ResNet-50, GPT-2/Llama, MobileNetV2, DLRM и распознавание ключевых слов, подробно описанные в главе «Архитектуры нейронных сетей») повторяются на протяжении всей книги, чтобы привязать эти принципы к реальным нагрузкам.

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

Ключевые выводы: ограничения определяют архитектуру

• Узкие места D·A·M мигрируют, а не исчезают. Ограничения по данным, алгоритму и машине взаимодействуют, поэтому улучшение одной оси часто обнажает другую. Системная привычка — спросить, какая ось теперь связывает, и выбрать вмешательство, которое снимает это ограничение, не создавая более крупного сбоя ниже по потоку.
• Выученное поведение может незаметно деградировать. Традиционное программное обеспечение обычно ломается при изменении кода или его окружения; системы ML могут деградировать, когда код и инфраструктура остаются неизменными, потому что мир смещается относительно обучающего распределения. Метрики дрейфа превращают этот сдвиг в поводы для расследования, а не в неожиданную потерю точности.
• Железный закон делает задержку диагностичной. Перемещение данных, вычисления и накладные расходы расходуют один и тот же бюджет времени. Сокращение вывода с 45 мс до 15 мс дает лишь улучшение на 23 процента, когда доминируют предобработка (60 мс) и постобработка (25 мс), поэтому оптимизируйте член, который связывает сквозное поведение.
• Масштаб побеждает внутри физических пределов. Горький урок объясняет, почему общие методы с большим объемом вычислений вытеснили вручную созданные системы, но масштаб помогает только тогда, когда данные, архитектура и машина могут его поддержать. Выигрыши эффективности в 44,5 раза сосуществовали с ростом вычислений примерно на 7 порядков величины.
• Инженерия ИИ — это непрерывное совместное проектирование. Контекст развертывания, мониторинг жизненного цикла и пять инженерных опор — не дополнения на потом; именно так стохастическое выученное поведение доводится до детерминированных целевых показателей надежности от облачного обучения до эксплуатации TinyML.

Все, что введено в этой главе, подтверждает одну мысль: система машинного обучения управляется физикой, а не намерением. Ее поведение отражает то, что допускают данные, арифметика и аппаратура. Горький урок, железный закон, уравнение деградации и таксономия D·A·M образуют единый словарь для рассуждений о поведении, которое выучено, а не полностью задано, и которое может деградировать, если за ним не следить. Признание этих ограничений реальной спецификацией и превращает набор методов в дисциплину.

От замысла к архитектуре

Выбор места, где должна работать модель ML, определяется физическими законами. Скорость света делает удаленные облачные серверы бесполезными для экстренного торможения. Термодинамика не позволяет моделям класса дата-центров работать на мобильном устройстве. Физика памяти создает пределы пропускной способности, которые не может преодолеть более быстрый чип. Четыре парадигмы развертывания — это место, где эти законы сходятся. Глава «Системы машинного обучения» выводит эксплуатационную оболочку каждой парадигмы из физики и разрабатывает рамку принятия решений для выбора между ними, когда требования конфликтуют.

1. GPU (графический процессор): изначально созданный для отрисовки графики видеоигр — задачи, которая требует тысяч простых параллельных вычислений для пикселей. Такое соответствие аппаратуры и алгоритма оказалось решающим для нейронных сетей, где та же массивно-параллельная арифметика напрямую отображается на умножение матриц. Поэтому GPU стали основным физическим фактором масштабирования современного обучения. ↩

2. Андрей Карпаты: один из основателей OpenAI и бывший директор по ИИ в Tesla, который применил глубокое обучение к парку автономных автомобилей. Его тезис «Software 2.0» (2017) сформулировал мысль о том, что веса нейронной сети стали новым «исходным кодом». Из этого следует новая инженерная реальность: вместо отладки явной логики инженеры должны курировать данные, которые определяют поведение программы, и вести их версии, поскольку модель с миллионами параметров нельзя напрямую исправить или рассуждать о ней. ↩

3. Веса модели: выученные числовые параметры нейронной сети. Модель масштаба GPT-3 (Generative Pre-trained Transformer 3) хранит 175 млрд таких значений, занимая 350 ГБ при точности FP16 — 16-битном формате с плавающей запятой, в котором на значение приходится два байта (Brown et al., 2020). Число параметров определяет объем весов и сильно влияет на трафик памяти при обслуживании и на стоимость (см. главу «Вычисления в нейронных сетях»). ↩

4. Стохастический градиентный спуск (SGD): алгоритм выучивает параметры модели, обрабатывая небольшие случайно выбранные группы примеров («батчи»), а не весь набор данных целиком. Это обменивает статистический шум на скорость вычислений. Размер батча также влияет на машину: слишком маленький батч может не загрузить параллельные процессоры ускорителя, и значительная часть его потенциальных вычислений пропадает впустую. ↩

5. AlexNet: Алекс Крижевский, Илья Суцкевер и Джеффри Хинтон обучили эту сверточную нейронную сеть на двух GPU. На ILSVRC 2012 ее ошибка top-5 составила 15,3 процента, то есть правильного класса не оказалось среди пяти наиболее вероятных предсказаний; это заметно лучше, чем 26,2 процента у системы, занявшей второе место (Krizhevsky et al., 2012). «Эпоха глубокого обучения и узкое место инфраструктуры» возвращается к ее архитектуре и совместному проектированию системы. ↩

6. Алан Тьюринг: его «Игра в имитацию» (1950) переформулировала интеллект как задачу измерения результата: оценивайте систему по тому, что она делает, а не по тому, чем она является. Этот инженерный подход сохраняется в каждой метрике систем машинного обучения, которую мы используем сегодня: точность, задержка, пропускная способность и FLOP/s на ватт — все это измерения результата. Именно поэтому железный закон («Железный закон систем машинного обучения») раскладывает производительность на наблюдаемые измеримые члены, а не на внутренние архитектурные свойства. ↩

7. ELIZA: программа 1966 года для естественного языка, которая использовала правила сопоставления шаблонов, а не выученные параметры. Ее сценарии могли сохранять и извлекать отдельные входы, но эта ограниченная рукописная память не давала выученного состояния беседы. Каждая новая вариация ввода требовала еще одного правила, и сопровождение росло быстрее возможностей. Так проявилось узкое место знаний, которое позже ограничивало экспертные системы. ↩

8. «Зимы ИИ» как системные отказы: первая «зима ИИ» (1974–1980) развернулась на фоне сокращения финансирования; отчет Лайтхилла 1973 года критиковал разрыв между обещаниями ИИ и результатами (Lighthill, 1973). Вторая «зима» (1987–1993) связана с обвалом рынка и финансирования вокруг экспертных систем и специализированных машин Lisp, которые проиграли по экономике универсальным рабочим станциям (Hendler, 2008). С системной точки зрения этой книги оба эпизода показывают, что амбиции алгоритмов опережали имеющуюся инфраструктуру, рыночную поддержку и инженерную зрелость, а не просто нехватку хитроумных алгоритмов. ↩

9. Дартмутская конференция (1956): семинар, организованный вокруг термина «искусственный интеллект», который уже использовался в заявке на него в 1955 году (McCarthy et al., 1955). Участники рассматривали интеллект через язык, абстракцию, решение задач и самосовершенствование, почти не обращая внимания на физические ограничения памяти и вычислений, которые позже стали центральными. Именно это не зависящее от вычислений допущение, что лучший алгоритм всегда может преодолеть аппаратное ограничение, и призвана исправить эта книга: каждая следующая глава доказывает, что системные ограничения — полноценные проектные переменные, а не запоздалая мысль. ↩

10. STUDENT: программа Дэниела Боброва 1964 года из MIT разбирала ограниченные текстовые задачи на английском языке, символически представляла связи между их величинами и передавала полученные уравнения решателю алгебры. Это ранний пример разделения понимания языка и формальных рассуждений: если представление было верным, решение становилось простым, а охват зависел от рукописных преобразований (Bobrow, 1964). ↩

11. Парадокс Моравека: робототехник из Carnegie Mellon Ганс Моравек заметил, что высокоуровневые рассуждения (шахматы) требуют мало вычислений, тогда как низкоуровневое восприятие (ходьба) требует массового параллелизма (Moravec, 1988). Этот парадокс объясняет центральный факт инженерии систем машинного обучения: задачи, которые кажутся людям «легкими» (зрение, речь, управление движением), требуют наибольшего числа FLOP/s, пропускной способности памяти и специализированного оборудования, что и стимулировало революцию ускорителей, определяющую современную инфраструктуру ML. ↩

12. Узкое место приобретения знаний: работа Фейгенбаума по инженерии знаний строила прикладной ИИ вокруг практической трудности извлечения, представления и поддержки экспертных знаний (Feigenbaum, 1984). В системных терминах это узкое место было проблемой пропускной способности: выявление знаний и сопровождение правил ограничивались последовательной пропускной способностью человека-эксперта. В отличие от вычислительных узких мест, которые поддаются более быстрому железу, это было первым в ИИ ограничением вида «не масштабируется» и прямым мотивом для последовавшей парадигмы, основанной на данных. ↩

13. Необъяснимая эффективность данных: наблюдение, что простая статистическая модель, обученная на огромных объемах данных, может превзойти более сложную модель, обученную на меньших данных (Halevy et al., 2009). Халеви и коллеги иллюстрировали этот эффект большими веб-корпусами, а не универсальным множителем частоты ошибок; выигрыш зависит от задачи, модели, качества данных и исходной точки. Результат поддержал переход от хрупких рукописных систем к вероятностным моделям и сделал сбор, хранение и предобработку данных, а также распределенное обучение центральными инженерными задачами. ↩

14. Алгоритм Виолы — Джонса: скорость в реальном времени обеспечивал каскад классификаторов, который использовал простые прямоугольные признаки, созданные вручную, чтобы сразу отбрасывать области, не являющиеся лицами. Метод был разработан и оценен для обнаружения лиц в фас и иллюстрирует компромисс эпохи: экспертно спроектированные признаки могли быть быстрыми и эффективными, но представление было привязано к задаче. Первые два слоя сами по себе могли отбросить более 80 процентов отрицательных подокон, используя всего двенадцать из более чем 6000 признаков (Viola and Jones, 2001). ↩

15. Ричард Саттон: пионер обучения с подкреплением, эссе которого 2019 года зафиксировало закономерность, прослеженную в «Эволюции узких мест ИИ»: от символического ИИ через экспертные системы к глубокому обучению, где общие методы, использующие вычисления, стабильно превосходили вручную спроектированную экспертизу. Урок «горький», потому что доменно-специфичная логика оказывается обесценивающимся активом, а устойчивое преимущество принадлежит системной инженерии, способной освоить рост сырых вычислений примерно в миллиард раз с 1970-х годов. ↩

16. Deep Blue: шахматная система IBM (Campbell et al., 2002) победила чемпиона мира Гарри Каспарова в 1997 году благодаря сочетанию системных решений: перебор примерно 200 миллионов позиций в секунду на 480 специализированных шахматных процессорах плюс шахматно-специфичная оценка и знания. Deep Blue стал ранней публичной демонстрацией того, что специально созданный кремний может усиливать перебор и закодированные знания предметной области; он предвосхитил стратегию ускорителей под конкретные задачи, которая определяет современное ML-железо. ↩

17. AlphaGo: AlphaGo сначала учился на партиях людей-экспертов, затем улучшался с помощью обучения с подкреплением на играх с самим собой, заменив вручную заданную стратегию го конвейером «данные и вычисления», который может исследовать пространство задачи в огромном вычислительном масштабе. После трех дней обучения игре с самим собой AlphaGo Zero превзошел исходный AlphaGo, выиграв со счетом 100:0 (Silver et al., 2017). ↩

18. Энергия обучения GPT-3 (Generative Pre-trained Transformer 3): Patterson et al. (2021) оценили, что один запуск обучения GPT-3 потребил около 1 287 МВт·ч и выбросил 552 тонны CO₂-эквивалента, что примерно соответствует годовому потреблению электричества 120 средних американских домохозяйств при базовом уровне 10,7 МВт·ч/домохозяйство-год. Перемещение данных по иерархии памяти составляет значительную долю этого энергетического следа, поскольку перенос операндов между уровнями памяти требует на порядки больше энергии, чем локальные арифметические операции (Horowitz, 2014). ↩

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

20. Вывод (inference): от лат. inferre («вносить» или «заключать»). В инженерии ML вывод — это фаза развертывания, в которой обученная модель применяет выученные закономерности к новым входам. Системное различие важно: обучение оптимизируют по пропускной способности (максимизировать примеры в секунду), а вывод — по задержке (минимизировать миллисекунды на предсказание). Эти противоположные цели требуют принципиально разных конфигураций аппаратуры и программных стеков (см. главу «Обслуживание моделей»). ↩

21. ImageNet: статья 2009 года сообщала о 3,2 млн изображений в 5 247 синсетах; позднее полный набор данных вырос примерно до 14,2 млн изображений в 21 841 синсете. Обучающая часть задачи 2012 года, которую использовал AlexNet, содержала примерно 1,3 млн размеченных изображений (Deng et al., 2009; Russakovsky et al., 2015) (см. главу «Инженерия данных»). ↩

22. Закон Мура: наблюдение Гордона Мура 1965 года описывало быстрый рост числа компонентов, которые экономически выгодно разместить на кристалле (Moore, 1998). Позднее отраслевые обзоры часто выражали этот ритм как примерно удвоение каждые два года. ↩

23. Вычислительная техника (computer engineering): оформилась как академическая дисциплина, когда в 1971 году Case Western Reserve открыл первую аккредитованную программу, признав, что ни электротехника, ни информатика в отдельности не могут решить задачу создания надежных компьютеров из ненадежных компонентов. Инженерия систем машинного обучения повторяет это сближение: решающее ограничение — не алгоритм и не аппаратура по отдельности, а их интеграция при бюджетах задержки, энергии и качества данных, которые не охватывает учебная программа ни одной из дисциплин. ↩

24. Микроконтроллеры: однокристальные компьютеры с килобайтами памяти и бюджетом мощности в милливаттах. Для TinyML память и энергия определяют осуществимость раньше, чем качество модели. ↩

25. Задержка: от лат. latere («скрываться»): задержка незаметна, пока не вызывает сбой. При 30 м/с каждая миллисекунда добавляет 3 см пути до начала торможения, что и делает $L_{\text{lat}}$ ограничением периферии. ↩

26. Сжатие моделей: семейство методов, включая квантование, прореживание и дистилляцию, которые уменьшают объем хранения или вычислений модели. Эффект на размер и точность зависит от модели, метода, нагрузки и целевой аппаратуры. ↩

27. Гибридный рабочий процесс автономного вождения: этот типичный процесс создает задачу синхронизации, которой нет в чисто облачных или чисто периферийных системах. Модель на борту должна проходить контроль и регрессионное тестирование до развертывания, тогда как облачная инфраструктура может обучать и оценивать улучшенные версии на новых данных вождения. Возникает разрыв управления версиями между развернутой и заново обученной моделью, и любое удаленное обновление модели для автомобилей, критичных к безопасности, требует строгой валидации. ↩

28. FarmBeats: система использует линки в свободных телевизионных диапазонах как высокоскоростной внутрифермерский канал от датчиков к шлюзовому ПК, где локальная обработка снижает зависимость от более слабого интернет-соединения с облаком. Возникающее ограничение — своевременная синхронизация данных по каналу «ферма — облако», а не доставка модели определенного размера (Vasisht et al., 2017). ↩

29. LiDAR (light detection and ranging): этот датчик — главная причина, по которой автомобиль называют «блуждающим дата-центром»: импульсные лазеры создают плотное трехмерное облако точек окружения. Необработанный поток одного блока может превышать 100 мегабайт в секунду, создавая одновременно проблему объема в терабайтах и проблему качества, поскольку сигнал легко искажается помехами от дождя или тумана. ↩

30. Дрейф данных: расхождение между распределением обучающих данных ($P_0$) и производственным распределением ($P_t$). Дрейф может менять производительность без изменения кода, но само расхождение не определяет, падает ли точность; чтобы установить деградацию, нужен мониторинг результатов (см. главу «MLOps»). ↩

31. Атака вывода (inference attack): угроза безопасности, при которой злоумышленник запрашивает модель, чтобы вывести чувствительные сведения об обучающей выборке. Такие атаки используют склонность сверхпараметризованных моделей запоминать уникальные закономерности обучающих данных, что создает прямой компромисс между емкостью модели и риском для приватности и мотивирует защитные методы, такие как дифференциальная приватность и возмущение выходов. ↩

Принципы основ

Системы машинного обучения подчиняются эвристике, которая выглядит простой: сложность часто переходит из одного места в другое, а не исчезает, хотя хорошее проектирование способно убрать случайную сложность. Сложность перетекает между тремя областями таксономии D·A·M: данными как информацией, алгоритмом как логикой и машиной как физикой. Упрощение одной области может перегрузить другие. Конвейер признаков, созданный вручную, уменьшает алгоритмическую сложность, но требует больше усилий инженерии данных. Более крупная модель поглощает беспорядочные данные, но перекладывает сложность на аппаратуру, которая должна ее обучать и обслуживать. Эта эвристика сохранения сложности лежит в основе всей книги. Количественные границы, модели и принципы, введенные в книге, описывают ограничения, которые возникают там, где сейчас находится сложность.

Архитектуры, фреймворки и оптимизации успешны только тогда, когда учитывают ограничения, которые накладывают аппаратура, математика и теория информации. Как инженер-строитель не может игнорировать гравитацию, так и инженер ML не может игнорировать физические законы, управляющие данными, вычислениями и пропускной способностью системы. Часть I закладывает эти основы: не набор лучших практик, которые меняются вместе с фреймворками, и не мнения, которые расходятся между командами, а устойчивые физические ограничения и количественные модели инженерии ML. Первое ограничение начинается с самих данных, где привычная граница между программой и входом начинает исчезать.

Принцип «данные как код»

Инвариант: данные функционируют как исходный код ML-системы. Изменение обучающего набора может изменить выученное поведение системы. Здесь выученное поведение означает обученное отображение входов в выходы; $f$ обозначает процесс обучения, а $\approx$ отмечает качественную зависимость, а не предсказательное равенство. Архитектура модели, инициализация, конфигурация оптимизатора и стохастичность обучения входят в процедуру обучения. $$\text{Выученное поведение}\approx f(\text{обучающие данные},\text{процедура обучения})$$

Следствие: инженерия данных требует той же строгости, что и программная инженерия. Наборы данных следует версионировать (как в Git), покрывать модульными тестами (проверки качества данных) и отлаживать. Удаление строки обучающих данных может изменить пересобранную модель так же, как удаление строки кода может изменить скомпилированный артефакт.

Если данные функционируют как исходный код, то они не просто логический артефакт: у них есть и физические свойства, которые ограничивают архитектуру системы, когда данные и вычисления находятся в разных местах.

Принцип гравитации данных

Инвариант: по мере роста объема данных ($D_{\text{vol}}$) перенос набора данных может стоить больше, чем отправка гораздо меньшего запроса или кода по тому же ограниченному каналу (McCrory, 2010).

Здесь стоимость означает одну метрику переноса за раз — например, затраченное время передачи или число переданных байтов — при одинаковых условиях канала; она не объединяет задержку и пропускную способность в одну величину. $$\text{Стоимость переноса набора данных}\gg \text{Стоимость переноса запроса или кода}\text{в этом режиме}$$

Следствие: большие наборы данных могут стать гравитационным центром архитектуры. Системы могут переносить вычисления к данным, отправляя запросы или код на уровень хранения, а не переносить данные к вычислениям, многократно скачивая большие наборы.

Вместе эти два принципа показывают, что данные могут быть одновременно логической программой и физическим якорем ML-системы. Часть I развивает эти следствия как цепочку зависимостей. Ограничения развертывания определяют, где система может исполняться; жизненный цикл переносит эти ограничения через постановку задачи, данные, моделирование, валидацию и эксплуатацию; а инженерия данных делает их обязательными в версионируемых и протестированных артефактах конвейера. Игнорирование любого звена возвращает сложность в виде издержек интеграции: точная модель, которую нельзя запустить, рабочий процесс, который не может воспроизвести свои входы, или конвейер, выходы которого больше не соответствуют условиям развертывания.

Системы машинного обучения

Назначение

Почему развертывание одной и той же модели на телефоне и в дата-центре требует принципиально разной инженерии?

Определяющая идея инженерии систем машинного обучения состоит в том, что ограничения определяют архитектуру. Скорость света задает абсолютный нижний предел того, как быстро далекие серверы могут ответить. Термодинамика ограничивает объем вычислений в заданном объеме до того, как тепло становится неуправляемым. Физика памяти делает перемещение данных часто более дорогим, чем их обработка. Это не ограничения инженерии, которые ждут лучших технологий; это постоянные физические границы, которые делят мир на принципиально различные режимы эксплуатации. Дата-центр может обучать модели с миллиардами параметров, но не может гарантировать низкую задержку ответов пользователям, находящимся в тысячах километров. Смартфон может отвечать мгновенно, но его бюджет памяти составляет лишь долю от дата-центра. Микроконтроллер может работать от батарейки-таблетки годами, но вычислительных ресурсов у него хватает лишь на простой детектор ключевых слов. Одна и та же модель, один и тот же алгоритм, примененный к тем же данным, требует принципиально разной инженерии в каждом режиме не потому, что меняется физика, а потому что доминируют разные ограничения. Команды, которые относятся к развертыванию как к второстепенной детали — обучают в одной среде и откладывают целевые ограничения до запуска, — слишком поздно выясняют, что целевая среда аннулирует месяцы архитектурных решений. Поэтому инженерная задача состоит не в том, чтобы найти универсально лучшее развертывание, а в том, чтобы определить ограничение, которое связывает в предполагаемом режиме эксплуатации. В терминах D·A·M понимание этих режимов превращает развертывание из эксплуатационной детали в задачу совместного проектирования первого порядка, в которой локальность данных, структура алгоритма и ограничения машины совместно определяют, что возможно.

Цели обучения

• Объяснить, как физические ограничения создают парадигмы развертывания от облака до TinyML
• Применить железный закон и принцип узкого места для классификации нагрузок, ограниченных вычислениями, памятью и вводом-выводом
• Сопоставить архетипы нагрузок с парадигмами развертывания на примерах маячных моделей
• Сравнить облако, периферию, мобильные устройства и TinyML по эксплуатационным ограничениям и количественным компромиссам
• Применить рамку решения для выбора парадигмы с учетом ограничений по приватности, задержке, вычислениям и стоимости
• Проанализировать гибридные схемы, сочетающие парадигмы для выполнения системных ограничений
• Оценить решения о развертывании, распространенные заблуждения и универсальные принципы, переносимые между масштабами

Рамка парадигм развертывания

Рассмотрим два крайних случая: детектор слова пробуждения на смарт-часах и рекомендательный движок в дата-центре. Детектор слова пробуждения представляет нагрузку TinyML, работающую при бюджетах мощности в милливаттах и лимитах памяти в килобайтах; рекомендательный движок — нагрузку облачного ML, которой нужны терабайты таблиц эмбеддингов и инфраструктура мегаваттного масштаба. Эти системы решают разные задачи при противоположных физических ограничениях, а их поддерживающая инфраструктура резко различается по масштабу и устройству. Поэтому развертывание перестает быть второстепенной эксплуатационной деталью и становится решением первого порядка: оно дополняет таксономию D·A·M, показанную на «Ландшафте пересечений D·A·M», и выводит инфраструктуру на первый план наряду с данными и алгоритмами.

Физические ограничения определяют, где может работать модель ML, и формируют возможное так, как не способен переопределить ни один алгоритмический выбор. Важно, что инженерная задача выходит далеко за пределы весов параметров: в производственных системах обученная модель составляет лишь малую часть всей эксплуатационной кодовой базы (Sculley et al., 2015). Окружающая инфраструктура — конвейеры приема данных, извлечение признаков, среды выполнения обслуживания, телеметрия и менеджеры аппаратных ресурсов — должна напрямую соответствовать физической оболочке платформы-хоста.

Мощность у парадигм простирается от мегаватт (облако) до милливатт (TinyML).

Три физических вектора — задержка, рассеяние мощности и пропускная способность памяти — делят развертывание ML на четыре различные парадигмы, каждая из которых сформирована аппаратными компромиссами, а не произвольными категориями продуктов. Централизация вычислений в облачном ML дает эластичные вычисления и большую емкость памяти, но каждый вывод несет сетевую задержку по глобальным каналам. Перенос нагрузок в периферийное ML устраняет этот сетевой цикл и сохраняет чувствительные данные на месте (Shi et al., 2016), однако ограничивает доступные вычисления энергетикой и бюджетами охлаждения локальной стойки. На устройствах с батарейным питанием мобильное ML обеспечивает отзывчивое взаимодействие прямо в смартфонах и планшетах, но должен работать в пассивной тепловой оболочке, где устойчивые вычисления запускают троттлинг. На крайнем маломощном полюсе TinyML работает на микроконтроллерах (Janapa Reddi et al., 2022), где бюджеты мощности в милливаттах и память килобайтного масштаба требуют компактных моделей и целочисленной арифметики. Охватывая девять порядков величины по мощности — от мегаватт в дата-центрах до милливатт во встроенных датчиках («Спектр распределенного интеллекта»), — эти парадигмы отражают инженерные компромиссы между централизованной емкостью и локальным выполнением.

Спектр распределенного интеллекта: уровни развертывания образуют непрерывный ряд, определяемый физическими ограничениями и охватывающий девять порядков величины по мощности. Переход от централизованной облачной инфраструктуры к TinyML на устройстве обменивает сырую вычислительную емкость и эластичное масштабирование на детерминированную задержку, локальность данных и независимость от сети.

Если «Спектр распределенного интеллекта» иллюстрирует качественную топологию распределенного интеллекта, то «Спектр развертывания (концептуальный)» количественно описывает эксплуатационные оболочки по месту обработки, задержке «туда и обратно», потреблению мощности и объему памяти. Этот разброс мощности в девять порядков величины отражает три неизбежные физические границы: скорость света (задающую нижние пределы задержки), пределы термодиссипации (ограничивающие вычисления на ватт) и энергию передачи сигналов в памяти (стену памяти).

Спектр развертывания (концептуальный): четыре парадигмы охватывают девять порядков величины по мощности (от МВт до мВт) и по памяти (от ТБ до КБ). Этот концептуальный обзор задает каждую парадигму через ее режим эксплуатации; конкретный аппаратный спектр позже привязывает эти категории к конкретным платформам и количественным порогам решения. Аппаратные характеристики и физические константы, лежащие в основе этих величин, перечислены в приложении о системных допущениях.

Архитектурная опора: стек одного узла

Чтобы ориентироваться в этих режимах эксплуатации, инженерные решения опираются на четырехуровневую модель стека одного узла, которая уточняет машинную сторону таксономии D·A·M для одного хоста, тогда как данные и алгоритм входят через требования нагрузки. На верхнем уровне стека приложение задает миссию через целевую пропускную способность обучения или задержку вывода. Главы «Обучение моделей» и «Обслуживание моделей» развивают механизмы, которые определяют, сможет ли система ее выполнить. ML-фреймворк переводит код модели в исполнимые операции (глава «Фреймворки машинного обучения»). Операционная система оркестрирует ресурсы и перемещает данные между памятью хоста и памятью ускорителя. Само железо, определяемое емкостью памяти с высокой пропускной способностью (HBM), пропускной способностью памяти, межсоединениями внутри узла, такими как NVLink, и пропускной способностью вычислений, задает физические пределы, а стена памяти остается повторяющимся ограничением (глава «Аппаратное ускорение»).

Этот стек задает кремниевый контракт главы: фиксированную сделку по производительности, которую конкретный кусок кремния предлагает модели и которая определяется пропускной способностью памяти, пиковой скоростью вычислений и постоянными накладными расходами. Каждая глава первой половины книги анализирует один или несколько из этих уровней, поскольку понимание того, как они взаимодействуют внутри одной машины, — технологическая предпосылка для освоения больших распределенных масштабов.

Эти физические ограничения взаимодействуют с железным законом систем машинного обучения («Железный закон систем машинного обучения»), который раскладывает сквозную задержку на перемещение данных, вычисления и накладные расходы. Разные среды развертывания подчеркивают разные ограничения: обучение в облаке может быть ограничено вычислениями, мобильные системы сталкиваются со стенами мощности, а устройства TinyML часто упираются в предел емкости памяти. Сочетая физические ограничения с железным законом, мы получаем количественный словарь для рассуждений о том, какая парадигма подходит данной нагрузке и почему. Чтобы конкретно опереться на этот анализ, пять маячных моделей (ResNet-50, GPT-2, DLRM для рекомендаций с большими эмбеддингами, MobileNetV2 и детектор ключевых слов для обнаружения слова пробуждения) охватывают спектр развертывания и выделяют разные системные узкие места. Эти эталонные нагрузки повторяются на протяжении всей книги, обеспечивая единую основу для сравнения методов оптимизации между главами, нагрузками и уровнями развертывания.

Физические ограничения: почему существуют парадигмы

Система безопасности с бюджетом реакции 10 мс не может ждать межконтинентального цикла «туда и обратно», а модель с миллиардом параметров не втиснуть в микроконтроллер одним лишь лучшим кодом. Это не ошибки реализации; это следствия физических законов скорости света, термодинамики мощности и передачи сигналов в памяти. То, где работает система, перестраивает кремниевый контракт между моделью и аппаратурой. Три ограничения задают инженерные компромиссы впереди: световой барьер, стену мощности и стену памяти.¹

Световой барьер

Световой барьер задает абсолютный нижний предел задержки². Пусть $\text{Расстояние}$ обозначает длину пути в одну сторону, а $c_{\text{fiber}}$ — скорость распространения в оптическом волокне. «Физика задержки» задает минимальное время «туда и обратно»:

$$L_{\text{lat,min}}=\frac{2\times \text{Расстояние}}{c_{\text{fiber}}}\approx \frac{2\times \text{Расстояние}}{200000\text{ км/с}}$$

Для оптического волокна $c_{\text{fiber}}\approx 200000$ км/с — примерно две трети от значения в вакууме, поскольку свет распространяется в стекле медленнее, чем в вакууме.

От Калифорнии до Вирджинии (примерно 3 600 км по прямой) требуется ~36 мс «туда и обратно» до начала любых вычислений. Реальные сервисы добавляют маршрутизацию, протокольные накладные расходы, очереди и задержку обработки. Приложения, которым нужен отклик менее 10 мс, не могут использовать удаленную облачную инфраструктуру — этого не позволяет физика. Это ограничение порождает потребность в периферийном ML и TinyML: когда бюджеты задержки жесткие, вычисления должны переместиться ближе к источнику данных.

Стена мощности

Стена мощности возникла потому, что термодинамика ограничивает объем вычислений в заданном объеме. Динамическая мощность КМОП-схем подчиняется «масштабированию мощности», где $C$ — эффективная емкость, $V$ — напряжение, а $f$ — тактовая частота. При сохранении эффективной емкости $C$ постоянной на локальном рабочем диапазоне, где напряжение растет пропорционально частоте $(V\propto f)$, динамическая мощность растет как $f^3$. Эта кубическая зависимость возникает, когда тактовые частоты поднимают за номинальные пределы, что требует более высоких напряжений питания для поддержания скорости переключения транзисторов. Когда масштабирование напряжения полностью останавливается на номинальных пределах, динамическая мощность масштабируется линейно с частотой, но ограничения теплоотвода все равно не дают непрерывно наращивать тактовую частоту.

$$\text{Мощность}\propto C\times V^2\times f\text{где }V\propto f⟹\text{Мощность}\propto f^3$$

При этом иллюстративном допущении удвоение тактовой частоты требует примерно в 8 раз больше динамической мощности. Прекращение масштабирования Деннарда³ положило конец «бесплатному» ускорению за счет частоты и вынудил индустрию к параллелизму (многоядерность) и специализации (GPU, Tensor Processing Unit (TPU)). Мобильные устройства упираются в жесткие тепловые пределы при 3–5 Вт; их превышение вызывает «троттлинг» — устройство снижает производительность, чтобы не перегреться. На практике это означает, что мобильная модель, работающая на 60 FPS в течение одной минуты, может снизиться до 15 FPS, когда устройство нагреется. Этот физический предел порождает мобильное ML: устройства с батарейным питанием не могут просто запускать модели облачного масштаба локально.

Стена памяти

Стена памяти (Wulf and McKee, 1995) отражает расширяющийся разрыв пропускной способности⁴. Простой набросок на уровне книги, использующий характерные годовые коэффициенты роста, показывает, почему разрыв нарастает:

$$\frac{\text{Темп роста вычислений}}{\text{Темп роста пропускной способности памяти}}\approx \frac{1,6}{1,2}\approx 1,33$$

В «стене памяти» числитель и знаменатель — безразмерные годовые коэффициенты роста. Отношение выше 1 означает, что возможности вычислений уходят от пропускной способности памяти, поэтому каждое поколение аппаратуры делает перемещение данных все большей долей проблемы производительности, если только нагрузка не увеличивает локальность или арифметическую интенсивность.

Характерные тенденции, стоящие за этим отношением: процессоры удваивали вычислительную мощность примерно каждые 18 месяцев, тогда как пропускная способность памяти улучшалась лишь примерно на 20 процентов в год. Этот расширяющийся разрыв делает перемещение данных частым узким местом и источником энергетических затрат в нагрузках ML. Физически, хотя арифметическая операция в арифметико-логическом устройстве (ALU) на кристалле перемещает заряды на считанные микрометры локального провода (расходуя десятки-сотни фемтоджоулей), выборка операнда из внешней DRAM требует заряжать емкостные дорожки печатных плат (PCB) и контактные площадки ввода-вывода длиной в сантиметры, расходуя сотни пикоджоулей, — на два-три порядка больше энергии на одно обращение. Это ограничение касается всех парадигм, но особенно остро для TinyML, где устройствам доступны лишь килобайты памяти. «Понимание стены памяти в ИИ» (глава «Аппаратное ускорение») развивает архитектурные ответы на стену памяти, включая HBM и иерархии SRAM на кристалле.

Физические ограничения и развертывание

Решения о развертывании определяются физикой, а не предпочтениями. Проверьте себя:

• Световой барьер: можете ли вы объяснить, почему скорость света делает облачное ML непригодным для задач безопасности с порогом $<10\text{ мс}$?
• Стена мощности: можете ли вы объяснить, почему термодинамика (отвод тепла) не позволяет запускать модели дата-центра на мобильных устройствах?
• Стена памяти: можете ли вы объяснить, почему перемещение данных часто дороже вычислений (по времени и энергии)?

Эти физические законы объясняют, почему существуют четыре парадигмы. Физика создает границы; требования регулирования приватности, экономические стимулы и суверенитет данных усиливают и заостряют их, но не создают их. Никакое регулирование не может ускорить свет, и никакая экономическая модель не отменит термодинамику.

Возможности вычислений опережают пропускную способность памяти; расширяющийся разрыв и есть стена памяти.

Эти физические ограничения не действуют изолированно. На практике ML-система ограничена тем физическим пределом, который первым связывает ее основной ресурс. Количественная оценка этих пределов требует аналитических инструментов: железного закона для раскладки времени выполнения на составляющие, принципа узкого места для выявления лимитирующей стадии и архетипов нагрузок для классификации потребностей модели в ресурсах.

Анализ нагрузок

Для рекомендательного движка или детектора слова пробуждения вопрос нагрузки состоит в том, какой член свяжет первым на целевом железе. Центральный аналитический инструмент для ответа на этот вопрос о кремниевом контракте — железный закон систем машинного обучения, введенный в «Железном законе систем машинного обучения». Здесь $T$ — полное время, $D_{\text{vol}}$ — перемещенные байты, $\text{BW}$ — пропускная способность, $O$ — полное число операций, $R_{\text{peak}}$ — пиковая скорость вычислений, ${\eta }_{\text{hw}}$ — эффективность аппаратуры, а $L_{\text{lat}}$ — постоянные накладные расходы; «железный закон» суммирует эти издержки для последовательного пути выполнения:

$$T=\frac{D_{\text{vol}}}{\text{BW}}+\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}}+L_{\text{lat}}$$

«Железный закон» раскладывает полную задержку на три члена: перемещение данных $(D_{\text{vol}}/\text{BW})$, вычисления $(O/(R_{\text{peak}}\cdot {\eta }_{\text{hw}}))$ и постоянные накладные расходы $(L_{\text{lat}})$. Для одного вывода эти издержки просто складываются — каждая платится последовательно. Однако в производственных системах задачи обрабатываются непрерывным потоком, и анализ смещается от задержки одной задачи к выявлению того, какой член ограничивает систему. Ответ полностью зависит от среды развертывания: модель, которая при обучении ограничена вычислениями, при выводе может стать ограниченной памятью; система, эффективно работающая в облаке, может упереться в пределы мощности на мобильных устройствах. В конвейерном производственном обслуживании аппаратная конкурентность меняет эту линейную сумму: более быстрые стадии скрываются за той подсистемой, которая насытится первой.

Принцип узкого места

Железный закон описывает стоимость каждого члена. Принцип узкого места определяет, какой член важен. В конвейерной ML-нагрузке выявление узкого места имеет значение, потому что оптимизация быстрых операций не дает никакой выгоды, пока самая медленная стадия остается прежней. Современные ускорители используют конвейерное выполнение, чтобы совмещать перемещение данных с вычислениями: пока ускоритель вычисляет батч $n$, система памяти предварительно загружает батч $n+1$. Когда перемещение данных, вычисления и ввод-вывод полностью перекрываются в установившемся режиме, пусть $T_{\text{network}}$ обозначает время удаленной передачи, а $T_{\text{bottleneck}}$ — получающееся время на задачу, включая постоянные накладные расходы. Более быстрые стадии скрываются за самой медленной перекрывающейся стадией, поэтому сумма железного закона становится максимумом, как формализует «уравнение узкого места»:

$$T_{\text{bottleneck}}=\max \left(\frac{D_{\text{vol}}}{\text{BW}},\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}},T_{\text{network}}\right)+L_{\text{lat}}$$

• $\frac{D_{\text{vol}}}{\text{BW}}$ (память): время перемещения данных между памятью и процессором.
• $\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}}$ (вычисления): время выполнения вычислений.
• $T_{\text{network}}$: время сетевого обмена (при переносе вычислений).
• $L_{\text{lat}}$ (накладные расходы): постоянная задержка (запуск ядра, накладные расходы среды выполнения).

Когда система ограничена памятью $(D_{\text{vol}}/\text{BW}>O/(R_{\text{peak}}\cdot {\eta }_{\text{hw}}))$, более быстрые процессоры $(R_{\text{peak}})$ не дают ускорения, так же как расширение шоссе не помогает движению, ограниченному узким мостом. Инженеры должны определить доминирующий член до оптимизации. Когда кандидатом является сетевая передача, перенос вычислений добавляет энергию к анализу, основанному на времени. Поэтому решение «локально или перенести» должно взвешивать джоули так же, как миллисекунды.

Энергия передачи данных

Задача: должен ли датчик с батарейным питанием обрабатывать данные локально (вывод на NPU устройства) или отправлять их в облако, когда энергия передачи сталкивается с энергетической стеной батареи?

Дано:

• Данные $(D_{\text{vol}})$: 1 МБ (иллюстративный объем полезной нагрузки).
• Энергия передачи $(E_{\text{tx}})$: 100 мДж/МБ (Wi-Fi/LTE).
• Энергия вычислений $(E_{\text{op}})$: 0,1 мДж/вывод (иллюстративная опорная точка MobileNetV2 на нейропроцессоре).

Расчет:

1. Облачный подход: $E_{\text{cloud}}\approx D_{\text{vol}}\times E_{\text{tx}}$ = 1 МБ $\times$ 100 мДж/МБ = 100 мДж.
2. Локальный подход: $E_{\text{local}}\approx$ вывод = 0,1 мДж.

Системный вывод: передача сырых данных обходится в 1 000 раз дороже, чем их локальная обработка. Даже если бы облако работало с бесконечной скоростью $(T\approx 0)$, заданный бюджет батареи все равно предпочитает локальный вывод передаче сырых данных. Ограничение машины (батарея) определяет выбор развертывания.

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

Железный закон как диагностика развертывания

Железный закон, введенный в «Железном законе систем машинного обучения», служит диагностикой развертывания на протяжении всей главы: он выражает полное время $T$, необходимое для нагрузки, как сумму перемещения данных, арифметики и задержки: $$T=\frac{D_{\text{vol}}}{\text{BW}}+\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}}+L_{\text{lat}}$$ Эта декомпозиция диагностическая: она количественно показывает, как объем данных $(D_{\text{vol}})$, вычислительная мощность $(R_{\text{peak}})$ и постоянная задержка $(L_{\text{lat}})$ совместно задают бюджет времени нагрузки. В отличие от закона Амдала, который фокусируется на параллельном ускорении, железный закон связывает работу модели с перемещением данных и постоянной задержкой на границе развертывания. Частое заблуждение состоит в том, что эти члены независимы; на деле это оси компромиссов. Увеличение размера батча может улучшить коэффициент загрузки и повторное использование данных, смещая ядро, ограниченное памятью, к поведению, ограниченному вычислениями, но одновременно увеличивая рабочий набор и время обслуживания батча.

Ось машины задает оболочку развертывания.

Железный закон количественно описывает стоимость каждого ингредиента; принцип узкого места определяет скорость конвейера. Как эмпирическое правило, аддитивную форму из «железного закона» используют при анализе задержки одной задачи, а форму через максимум из «уравнения узкого места» — при анализе пропускной способности непрерывного потока задач.

Архетипы нагрузок

Принцип узкого места сводит оптимизацию к выявлению доминирующего ограничения для данной нагрузки. Ответ зависит от таксономии D·A·M на «Ландшафте пересечений D·A·M», которая раскладывает любую систему ML на Data, Algorithm и Machine. Разные среды развертывания создают разные узкие места вдоль этих осей, поэтому одно и то же семейство моделей может требовать разной инженерии при переходе от облачного сервера с терабайтами памяти к микроконтроллеру с килобайтами. Железный закон превращает эту диагностику в четыре архетипа нагрузок.⁵ Это не категории моделей; это повторяющиеся физические узкие места, которые определяют, какие инженерные шаги могут помочь.

Первое разделение отделяет системы, ограниченные арифметикой, от систем, ограниченных перемещением данных. «Вычислительный зверь» выполняет много расчетов на каждый загруженный байт, поэтому прогресс достигается за счет более высокой арифметической пропускной способности, лучшей загрузки и большего параллелизма; эталонный случай — обучение больших нейронных сетей. «Пожиратель полосы пропускания» (bandwidth hog), напротив, ждет перемещения плотных весов или активаций, поэтому более широкие шины памяти и лучшее повторное использование данных важнее дополнительных пиковых FLOP/s; авторегрессивная генерация текста иллюстрирует этот режим.

Второе разделение охватывает нагрузки, где связывающее ограничение вообще не плотная арифметика. Нагрузки «разреженного разброса» (sparse scatter) определяются нерегулярными поисками в таблицах и плохой локальностью кеша, поэтому емкость памяти, задержка доступа и коммуникация определяют производительность рекомендательных систем с огромными таблицами эмбеддингов. Нагрузки «жесткого ограничения» (tiny constraint) работают в противоположной оболочке: энергия на вывод и объем памяти, а не сырая скорость, определяют, вообще ли может работать постоянное восприятие.

Пять эталонных нагрузок

Пять маячных моделей, сведенных в «Пять маячных моделей», повторяются в этой книге как конкретные нагрузки, которые охватывают спектр развертывания и выделяют разные системные узкие места. Полное описание архитектур и биографии моделей приведены в главе «Архитектуры нейронных сетей».

Маячная модель	Архетип	Парадигма развертывания
ResNet-50	Вычислительный зверь	Обучение в облаке, вывод на периферии
GPT-2/Llama	Пожиратель полосы пропускания	Вывод в облаке
DLRM	Разреженный разброс	Только облако (распределенно)
MobileNetV2	Вычислительный зверь (эффективный)	Мобильные, периферийные
Распознавание ключевых слов (KWS)	Жесткое ограничение	TinyML, постоянная работа

Пять маячных моделей: повторяющиеся нагрузки, которые используются на протяжении книги, чтобы опереть железный закон на конкретную практику. Каждая маячная модель сочетает архетип (вычислительный зверь, пожиратель полосы пропускания, разреженный разброс, жесткое ограничение) с парадигмой развертывания, в которой она преимущественно работает, и выделяет отдельное системное узкое место.

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

Первая маячная модель, ResNet-50, классифицирует изображения по 1000 категориям; обработка каждого изображения требует примерно 8,2 GFLOP и использует 25,6 млн параметров (102,4 МБ при FP32) (He et al., 2016). Ее применяют в медицинской диагностике по изображениям, конвейерах восприятия автономных автомобилей и как основу систем модерации контента; ее регулярная, плотная по вычислениям структура делает ее каноническим эталоном производительности аппаратных ускорителей.

Языковые модели GPT-2/Llama иллюстрируют авторегрессивную генерацию текста (Radford et al., 2019; Touvron et al., 2023). Эти модели порождают текст по одному токену за раз. При декодировании с малым батчем на каждый токен может потребоваться перемещать через память почти все параметры модели (для GPT-2 — 1,5 млрд параметров, для Llama — от 7 до 70 млрд параметров). Такой последовательный шаблон доступа создает авторегрессивное узкое место, которое определяет стоимость обслуживания (Pope et al., 2023).

Рекомендательная маячная модель DLRM представляет нагрузку рекомендаций с тяжелыми эмбеддингами, лежащую в основе крупномасштабных систем вида «вам также может понравиться» (Naumov et al., 2019). Она сопоставляет пользователей и товары векторам эмбеддингов, которые хранятся в таблицах, способных превышать 100 ГБ эмбеддингов; поэтому связывающим ограничением становится емкость памяти, а не вычисления.

Мобильная маячная модель MobileNetV2 создана для эффективных мобильных задач компьютерного зрения, таких как классификация, детекция и сегментация (Sandler et al., 2018). Она решает ту же задачу классификации изображений, что и ResNet, но использует раздельные по глубине свертки (depthwise separable convolutions), которые разделяют пространственную фильтрацию и смешивание каналов, сокращая вычисления в 13,7 раза и позволяя выполнять вывод в реальном времени на смартфонах при 3–5 Вт.

TinyML-маячная модель распознавание ключевых слов (KWS) представляет архетип постоянного восприятия. Системы KWS обнаруживают короткие триггерные фразы компактными моделями, созданными для микроконтроллеров с ограниченными ресурсами (Zhang et al., 2017); в сценарии умного дверного звонка тот же шаблон становится локальным триггером «Динь-дон» или «Привет». Эта нагрузка имеет примерно 200 тыс. параметров и умещается примерно в 800 КБ, что относит ее к режиму TinyML с килобайтной памятью и бюджетом в милливаттах.

Осуществимость развертывания оценивается иерархически: сначала проверяется физическое соответствие памяти, и только потом — задержка выполнения. На «карте ограничений умного дверного звонка» горизонтальные полосы показывают спрос на ресурс в процентах от предложения относительно вертикального порога насыщения 100 процентов для микроконтроллера ESP32-S3; сравниваются емкость памяти на уровне 1 и задержка на уровне 2 в соответствии с соглашением об уровне обслуживания (SLA).

Карта ограничений умного дверного звонка: каждая полоса — это спрос, деленный на предложение, поэтому пунктирная линия отмечает точку, где уровень ровно насыщен. Модель занимает небольшую часть бюджета памяти ESP32-S3 в 4 МБ (уровень 1: ПРОЙДЕНО), но ее базовая задержка 101 мс вдвое превышает намеренно ужесточенную цель взаимодействия 50 мс (уровень 2: НЕ ПРОЙДЕНО), хотя она укладывается в канонический бюджет сценария 200 мс.

Разброс требований к вычислениям и объему памяти объясняет, почему ни одна парадигма развертывания не подходит всем нагрузкам. Распознаватель ключевых слов может работать примерно при 20 MFLOP и 800 КБ, тогда как ResNet-50 требует около 8,2 GFLOP и примерно 102,4 МБ на изображение. Эталонный пример DLRM уже достигает 100 ГБ, а производственные рекомендательные системы в духе DLRM могут превышать 100 ТБ. Языковые модели добавляют режим, в котором доминирует пропускная способность: миллиарды параметров многократно потоково передаются из памяти при авторегрессивном выводе. Эти пять маячных моделей служат конкретными опорами на протяжении всей книги, и каждая выделяет отдельное системное узкое место, к которому возвращаются в каждой главе.

Железный закон и архетипы нагрузок приобретают практический смысл, когда их сопоставляют с реальным кремнием. Достигает ли ускоритель высокой загрузки или простаивает в ожидании памяти, зависит от баланса системы: отношения пиковой вычислительной пропускной способности к пропускной способности памяти и емкости ввода-вывода на разных аппаратных платформах.

Баланс системы и аппаратура

Физические ограничения переводят компромиссы «задержка против пропускной способности» в инженерные решения через конкретные числа. В «Числах задержек для проектирования систем ML» приведены задержки по порядку величины, которые должны учитываться при каждом решении о развертывании: они охватывают восемь порядков величины — от наносекундных вычислительных операций до сотен миллисекунд на межрегиональные сетевые вызовы. Подробные аппаратные задержки и ограничения пропускной способности рассмотрены в главе «Аппаратное ускорение». Операция с задержкой $>X$ не может попасть на критический путь системы, бюджет задержки которой составляет $X$ мс.⁶

Числа задержек для проектирования систем ML: порядки величины задержек в вычислениях, памяти, сети и операциях ML, которые определяют осуществимость развертывания. Охватывая восемь порядков величины, от наносекундных вычислительных операций до сотен миллисекунд на межрегиональные сетевые вызовы, эти физические ограничения формируют архитектурные решения. Полный краткий справочник, включая энергетические отношения и правила масштабирования, см. в приложении о числах, которые стоит знать.

Четыре парадигмы развертывания становятся точнее, когда опираются на конкретное железо. Если «Спектр развертывания (концептуальный)» определил парадигмы концептуально, то «Аппаратный спектр (конкретные платформы)» привязывает их к конкретным устройствам, емкостям памяти и энергетическим оболочкам.⁷ Девять порядков величины по мощности вместе с метриками эффективности использования энергии дата-центра (PUE)⁸ и разбросом стоимости от миллионов долларов до $10 определяют, какая парадигма экономически подходит данной нагрузке.

Эти различия аппаратуры определяют, какой член железного закона связывает первым в разных режимах развертывания («Принцип узкого места»).

Баланс системы по парадигмам

Конвейерная форма железного закона систем машинного обучения из «Железного закона систем машинного обучения» добавляет к каноническим членам вычислений и памяти ${\text{BW}}_{\text{IO}}$, пропускную способность ввода-вывода хранилища или сети. «Расширенный железный закон» формализует получающуюся нижнюю границу полного времени выполнения $T$:

$$T\ge \max \left(\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}},\frac{D_{\text{vol}}}{\text{BW}},\frac{D_{\text{vol}}}{{\text{BW}}_{\text{IO}}}\right)+L_{\text{lat}}$$

Здесь $O$ — полное число операций, $R_{\text{peak}}$ — пиковая скорость вычислений, ${\eta }_{\text{hw}}$ — эффективность использования аппаратуры, $D_{\text{vol}}$ — объем данных, $\text{BW}$ — пропускная способность памяти, ${\text{BW}}_{\text{IO}}$ — пропускная способность ввода-вывода (хранилища или сети), а $L_{\text{lat}}$ — постоянные накладные расходы. Нижняя граница показывает, какой ресурс (вычисления, память или ввод-вывод) ограничивает производительность; равенство требует идеального перекрытия без дополнительных простоев. Доминирующий член зависит от нагрузки и режима развертывания. Более быстрые ускорители помогают обучению в облаке, ограниченному вычислениями; декодирование больших языковых моделей (LLM) и периферийные нагрузки, ограниченные памятью, выигрывают сильнее от сокращения перемещаемых байтов или роста пропускной способности. «Доминирующее узкое место по парадигмам» разбирает все четыре парадигмы, разделяя облако на обучение и вывод LLM, а приложение о диагностике узких мест по таксономии D·A·M сопоставляет каждый доминирующий член с оптимизациями, которые работают, и с теми, что тратят усилия впустую, превращая эту диагностику в план действий.

Парадигма	Доминирующее ограничение	Почему	Фокус оптимизации
Обучение в облаке	$O/(R_{\text{peak}}\cdot {\eta }_{\text{hw}})$ (вычисления)	Память и сеть в избытке; предел пропускной способности задают FLOP/s	Максимизировать загрузку ускорителя, размер батча
Вывод LLM в облаке	$D_{\text{vol}}/\text{BW}$ (пропускная способность памяти)	Последовательная генерация многократно перемещает состояние модели	Увеличить повторное использование; сократить перемещаемые байты
Вывод на периферии	$D_{\text{vol}}/\text{BW}$ (пропускная способность памяти)	Ограниченная локальная пропускная способность; модели часто ограничены памятью	Меньшие модели; меньше переносов в памяти
Мобильные устройства	Энергия (неявно)	Батарея = $\int \text{Мощность}\cdot dt$; тепловой троттлинг	Пониженная точность; циклическое включение
TinyML	Модель должна помещаться на кристалле (емкость)	Память килобайтного масштаба; модель должна помещаться на кристалле	Крошечные модели и арифметика с фиксированной точкой

Доминирующее узкое место по парадигмам: какой член железного закона ограничивает производительность в каждой парадигме развертывания, физическая причина его доминирования и получающийся фокус оптимизации. Доминирующий член полностью меняет стратегию оптимизации: обучение в облаке максимизирует загрузку вычислений, тогда как вывод LLM должен бороться с пропускной способностью памяти.

Вывод при batch=1 находится на стороне Roofline, ограниченной памятью.

Анализ Roofline классифицирует узкие места, сравнивая арифметическую интенсивность нагрузки — отношение выполненных операций с плавающей запятой к байту перемещенной памяти ($\text{FLOP/байт}$) — с точкой баланса машины ($R_{\text{peak}}/\text{BW}$) (Williams et al., 2009). Здесь изложение неформальное; формальный вывод модели, определение арифметической интенсивности и точки перегиба, которая разделяет режимы, ограниченные памятью и вычислениями, приведены в приложении о машинных основах (раздел о модели Roofline). В этой рамке одна и та же модель ResNet-50 может переходить от поведения при обучении, ограниченного вычислениями, при больших размерах батча к выводу одного изображения (batch=1), более чувствительному к памяти. Выбор парадигмы развертывания должен учитывать этот сдвиг.

Этот эксплуатационный сдвиг отражает структуру таксономии D·A·M («Ландшафт пересечений D·A·M»): каждая система ML балансирует Data, Algorithm и Machine. В «D·A·M × фаза» показано, как каждый компонент ведет себя по-разному в зависимости от того, обучается ли система (выучивает закономерности) или обслуживает (применяет их).

D·A·M × фаза: одна и та же модель предъявляет принципиально разные требования к Data, Algorithm и Machine в зависимости от того, обучается система или обслуживает. Когда узкие места неожиданно смещаются, проверьте, какая фаза сейчас оптимизируется.

Количественное сравнение применяет этот анализ к выводу ResNet-50 на высокопроизводительном ускорителе дата-центра и мобильном NPU. Эти значения стоит воспринимать как привязки к конкретной аппаратуре на момент написания: арифметика касается скорости вычислений, пропускной способности памяти и размера батча, тогда как архитектуру ускорителей, стоящую за цифрами, объясняет глава «Аппаратное ускорение».

ResNet-50 в облаке и на мобильном устройстве

Задача: ограничен ли вывод ResNet-50 вычислениями или памятью на (а) высокопроизводительном ускорителе дата-центра и (б) флагманском мобильном NPU?

Дано (из маячных моделей):

• ResNet-50: 8,2 GFLOP на вывод, 25,6 млн параметров (102,4 МБ в FP32, 51,2 МБ в FP16)

Анализ:

(а) Облачный ускоритель дата-центра (batch=1, FP16)

• Пиковые вычисления: 312 TFLOP/s (FP16)
• Пропускная способность памяти: 2,04 ТБ/с
• Время вычислений: $T_{\text{comp}}=\frac{8,20\times 10^9}{3,12\times 10^{14}}=0,026\text{мс}$
• Время памяти (веса плюс активации): $T_{\text{mem}}=\frac{5,63\times 10^7}{2,04\times 10^{12}}=0,028\text{мс}$
• Результат: узкое место — память (в 1,1 раза медленнее вычислений)
• Анализ: вычисления на перемещенный байт $=\frac{8,20\times 10^9}{5,63\times 10^7}=146\text{FLOP/байт}$. Это отношение показывает, сколько арифметики выполняет нагрузка на каждый загруженный байт. Если отношение превышает соотношение вычислений и пропускной способности аппаратуры $(R_{\text{peak}}/\text{BW})$, нагрузка ограничена вычислениями; если ниже — памятью. При выводе одного изображения малый размер батча дает ограниченное повторное использование, что объясняет, почему даже высокопроизводительные ускорители могут быть ограничены памятью при batch = 1.

(б) Мобильное устройство: флагманский NPU (batch=1, INT8)

• Пиковые вычисления: ~35 TOPS (INT8) — типично для современных мобильных NPU
• Пропускная способность памяти: ~51,2 ГБ/с (LPDDR5)
• Размер модели: 25,6 МБ (квантована до INT8)
• Время вычислений: $T_{\text{comp}}=\frac{8,20\times 10^9\text{INT8-операций}}{3,50\times 10^{13}\text{INT8-операций/с}}=0,23\text{мс}$
• Время памяти (веса плюс активации): $T_{\text{mem}}=\frac{2,82\times 10^7}{5,12\times 10^{10}}=0,55\text{мс}$
• Результат: узкое место — память (в 2,3 раза медленнее вычислений)

Системный вывод: обе платформы ограничены памятью при выводе одного изображения. Более быстрая пропускная способность памяти A100 (2,04 ТБ/с против 51,2 ГБ/с: в 39,8 раза) переходит примерно в 19,9 раза более быстрый вывод; одни лишь пиковые вычисления не являются определяющим сравнением. Поэтому методы сокращения байтов и более низкой точности могут обойти простую покупку большего пикового FLOP/s для развертывания.

ResNet-50 становится ограниченным вычислениями, когда батчинг и повторное использование данных поднимают вычисления на перемещенный байт выше точки баланса аппаратуры, $I>R_{\text{peak}}/\text{BW}$, где $I=O/D_{\text{vol}}$. Конкретно при батчевом выводе статические веса модели передаются по шине памяти только один раз и затем повторно используются для всех $B$ примеров батча. Это распределяет передачу весов на $B$ входов, повышая арифметическую интенсивность, пока время вычислений не превысит время передачи из памяти. Точка перехода зависит от архитектуры и реализации, потому что трафик активаций, перемещение входов и выходов, повторное использование кеша и детали выполнения среды меняют эффективный объем перемещаемых байтов на вывод.

Сжатие моделей становится необходимым по мере ужесточения бюджета аппаратуры. Переход от облака к периферии и затем к TinyML сжимает доступные ресурсы по всем измерениям. «Аппаратный спектр (конкретные платформы)» количественно описывает эту динамику конкретными примерами: память падает с 128 ТБ (облако) до 512 КБ (TinyML), то есть примерно в 250 миллионов раз, а энергия — от мегаватт до милливатт. Этот разрыв ресурсов острее всего на микроконтроллерах — основной аппаратной платформе TinyML, где емкости памяти и хранилища не вмещают обычные модели ML.

Аппаратный спектр (конкретные платформы): представительные устройства, которые реализуют каждую парадигму развертывания из «Спектра развертывания (концептуальный)». Если концептуальная таблица задает режимы эксплуатации, то эта таблица дает конкретные процессоры, емкости памяти, энергетические оболочки и ценовые ориентиры, которые практики используют, чтобы сопоставить нагрузки с аппаратурой. DGX Spark находится на верхнем конце периферийного спектра; большинство периферийных развертываний используют гораздо меньшие устройства (например, Jetson Orin Nano). Мы включаем его, чтобы показать верхнюю границу необлачного развертывания. Само семейство NVIDIA Jetson охватывает широкий ряд моделей: от Jetson Orin Nano (7–15 Вт) через Jetson Orin NX (10–25 Вт) до Jetson AGX Orin (15–60 Вт); в этой книге цифры мощности Jetson следует сверять с конкретной моделью, названной в контексте.

Аппаратный спектр превращает диагностику узкого места в тест на соответствие. Платформы из «Аппаратного спектра (конкретные платформы)» — результат десятилетий эволюции аппаратуры: от сопроцессоров с плавающей запятой в 1980-х через графические процессоры 2000-х к современным доменно-специфичным ускорителям ИИ. Глава «Аппаратное ускорение» прослеживает эту историческую траекторию и архитектурные принципы, которые ее определили. Здесь важнее всего следствие: качественно разное железо встречается на разных точках инфраструктуры, поэтому каждую нагрузку нужно сопоставлять с тем уровнем, оболочка вычислений, памяти, энергии и стоимости которого ее может удовлетворить.

Каждая парадигма занимает отдельную область спектра развертывания, управляется физическими ограничениями (световой барьер, стена мощности, стена памяти) и количественно описывается аналитическими инструментами (железный закон, принцип узкого места), введенными в «Анализе нагрузок». Количественные пороги из «Порогов решения о развертывании» помогают практикам определить, укладывается ли нагрузка в оболочку вычислений, пропускной способности, мощности и задержки целевой платформы.

Пороги решения о развертывании: практичные оболочки, которые практики используют, чтобы определить осуществимость развертывания для каждой парадигмы из «Аппаратного спектра (конкретные платформы)». Эти значения отвечают на вопрос «может ли моя нагрузка работать здесь?», задавая уровень вычислений, пропускную способность памяти и энергетическую оболочку, которые обеспечивает каждая парадигма. Каждая цифра мощности обозначает типичный класс парадигмы, а не жесткий потолок; в частности, периферийная оболочка простирается от маломощных встроенных модулей до устройств уровня рабочих станций.

«Пороги решения о развертывании» завершает тест на соответствие: каждая парадигма представляет эксплуатационную оболочку, определенную своим связывающим ресурсом. Переход от складских дата-центров к микроконтроллерам проходит физический градиент, в котором сырая пропускная способность вычислений обменивается на энергетическую эффективность и эффективность по памяти.

Облачное ML: вычислительная мощность

Подумайте, чего стоило обучить GPT-3:⁹ 3 634,3 PFLOP-дней вычислений, 10 000 GPU V100, работавших примерно 15 дней и потреблявших мегаватты мощности (Patterson et al., 2021). Ни один смартфон, периферийный сервер или одна машина не смогли бы завершить такой запуск обучения по практичному графику. Требовался кластер масштаба дата-центра с достаточной совокупной вычислительной мощностью, памятью и хранилищем. Это определяющее предложение облачного ML: когда задержку можно терпеть, он предлагает вычислительный масштаб, с которым не сравнится ни одна другая парадигма.

Централизация этих ресурсов по коммунальной модели (utility)¹⁰ позволяет провайдерам собирать специализированные топологии ускорителей под разные требования к железу. Эта инфраструктура — естественный дом для трех из четырех архетипов нагрузок: нагрузок «вычислительный зверь», как обучение ResNet, которому нужны устойчивые TFLOP/s на тысячах ускорителей; нагрузок «пожиратель полосы пропускания», как вывод больших языковых моделей, которым выгодна пропускная способность HBM в ТБ/с; и нагрузок «разреженный разброс», как рекомендательные системы, которым нужны терабайты таблиц эмбеддингов и высокоскоростные межсоединения для шаблонов коммуникации «все со всеми».

Облачные развертывания масштабируются от экземпляров с одним ускорителем и серверов с несколькими GPU до распределенных кластеров, охватывающих складские дата-центры. Системная инженерия такого масштаба начинается с одного узла: прежде чем координировать вычисления между сетевыми хостами, инженер должен понять насыщение шины памяти, пропускную способность PCIe и NVLink и загрузку ускорителей внутри одной машины.

Этот компромисс между емкостью и расстоянием определяет облачную парадигму.

Облачное ML

Облачное машинное обучение — парадигма развертывания, которая обменивает задержку на эластичные вычисления, размещая нагрузки ML в централизованных дата-центрах и отделяя вычислительную мощность от физического расположения источников данных и пользователей.

1. Значение: развертывание в облаке доминирует над членом $R_{\text{peak}}$: один облачный регион может предоставить по запросу тысячи ускорителей, обеспечивая совокупную пропускную способность, с которой не сравнится типичная установка на собственной площадке по стоимости. Компромисс — член $L_{\text{lat}}$: минимальная задержка «туда и обратно» 10–100 мс (задаваемая скоростью света на континентальных расстояниях) делает облако непригодным для любой нагрузки, которой нужен отклик менее 10 мс.
2. Отличие: в отличие от периферийного ML, который ставит детерминированность задержки и локальность данных на первое место при фиксированном $R_{\text{peak}}$, облачное ML ставит эластичный $R_{\text{peak}}$ на первое место ценой переменного $L_{\text{lat}}$.
3. Типичная ошибка: распространено заблуждение, будто облачное ML означает «неограниченные вычисления». На деле штраф за расстояние $(L_{\text{lat}})$ и узкое место приема данных $(D_{\text{vol}}/\text{BW})$ — физические ограничения, которые не может устранить никакая программная оптимизация, и они задают жесткий нижний предел времени отклика для любой нагрузки, данные которой возникают вне дата-центра.

Централизация задает облачную сделку: объединение эластичных вычислений в кластерах складского масштаба снимает локальные ограничения емкости, но вводит физическое расстояние и сетевую задержку. На «Карте ограничений облачного ML» дерево ограничений слева направо показывает этот компромисс: связывающее ограничение масштаба соединено с системным ответом, границами отказов и подходящими нагрузками.

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

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

Штраф за расстояние

Задача: рассмотрим систему мониторинга безопасности для робота-манипулятора. Логика безопасности требует сквозного времени отклика 10 мс, чтобы предотвратить травму, поэтому штраф за расстояние, налагаемый световым барьером, имеет значение. Модель работает в высокопроизводительном облачном дата-центре на расстоянии 1 500 км. Можно ли уложиться в бюджет безопасности?

Физика:

1. Свет в волокне: ~200 000 км/с.
2. Распространение «туда и обратно»: (1 500 км $\times$ 2)/200 000 км/с = 15 мс.
3. Результат: одно лишь распространение «туда и обратно» требует 15 мс, что превышает сквозной бюджет 10 мс (запас −5 мс) еще до того, как модель выполнит хоть один вывод.

Системный вывод: физика делает облачное ML невозможным для этого приложения. Модель должна переехать на периферию.

Облачная инфраструктура и масштаб

Облачное ML концентрирует вычислительные ресурсы в централизованных объектах физических размеров, недоступных локальным устройствам. Конструкции суперкомпьютеров TPU объединяют тысячи специализированных чипов ускорителей в системы масштаба дата-центра, которые дают пропускную способность в пониженной точности от PFLOP/s до EFLOP/s (Jouppi et al., 2023). «Аппаратный спектр (конкретные платформы)» количественно показывает, что облачные системы дают на порядки больше вычислений и пропускной способности памяти, чем мобильные устройства, при соответственно более высокой мощности и эксплуатационных затратах. Эти объекты делают возможными нагрузки, непрактичные на устройствах с ограниченными ресурсами, но их удаленное расположение создает прямые компромиссы: сетевая задержка «туда и обратно» исключает жесткие сроки реального времени, а эксплуатационные расходы напрямую растут с использованием.

Физическая реальность этой пропускной способности видна на полу объекта, см. «Масштаб облачного дата-центра»: тысячи чипов ускорителей¹¹ организованы в ряды стоек с жидкостным охлаждением; каждая стойка потребляет киловатты мощности, чтобы поддерживать совокупные вычисления, к которым не приблизится ни одна отдельная машина.

Масштаб облачного дата-центра: специализированные объекты ускорителей объединяют тысячи чипов TPU в стойках с жидкостным охлаждением, чтобы дать матричную пропускную способность экзафлопсного масштаба. Эта централизованная инфраструктура делает реалистичными обучение крупных моделей и обслуживание с высокой пропускной способностью, но влечет потребление мощности мегаваттного масштаба и штраф за расстояние до сети со скоростью света. Источник изображения: Pichai, 2023.

Облачное ML хорошо справляется с обработкой огромных объемов данных благодаря параллельным архитектурам, позволяя обучаться на наборах, которым нужны сотни терабайт хранилища и PFLOP-вычисления — ресурсы, которые остаются непрактичными на ограниченных устройствах. Методы обучения из главы «Обучение моделей» и архитектуры ускорителей из главы «Аппаратное ускорение» показывают, как распределенные системы координируют и поддерживают эту пропускную способность.

Централизация также меняет способы обслуживания и управления моделями. Облачные API делают обученные модели доступными по всему миру на мобильных, веб-платформах и платформах IoT. Общая инфраструктура позволяет инженерным командам работать вместе с единым контролем версий, а модели оплаты по мере использования¹² переводят первоначальные капитальные затраты (CapEx) в зависящие от использования операционные расходы (OpEx), которые растут вместе со спросом.

Распространено заблуждение, что огромные вычислительные ресурсы облачного ML делают его универсально лучшим. Большая вычислительная емкость и хранилище не превращаются автоматически в оптимальное решение для каждой нагрузки. Инвариант гравитации данных из приложения о базовых данных объясняет почему: по мере роста объема данных стоимость перемещения данных к вычислениям $(C_{\text{move}}(D_{\text{vol}})\gg C_{\text{move}}(\text{Вычисления}))$ в конце концов начинает доминировать. Компромиссы, показанные на «Карте ограничений облачного ML», становятся конкретными там, где сильны периферийные и встроенные развертывания: контуры управления с задержкой менее 10 мс в робототехнике, локальное хранение медицинских записей с чувствительными данными, предсказуемые амортизированные затраты без повторяющихся облачных платежей или автономная работа в средах без связи. Оптимальную парадигму развертывания диктует связывающее физическое ограничение, а не неограниченная пропускная способность.

Компромиссы и ограничения облачного ML

Преимущества облачного ML несут присущие компромиссы, которые формируют решения о развертывании. Наиболее значима задержка: удаленная сетевая задержка делает облачную обработку непригодной, когда сквозной путь превышает бюджет отклика приложения. Непредсказуемый джиттер сети дополнительно усложняет предсказуемость производительности и отладку в географически распределенной инфраструктуре.

Приватность и безопасность создают дополнительные границы для облачного развертывания. Передача чувствительных данных в удаленные дата-центры расширяет поверхность раскрытия и усложняет соблюдение нормативных требований. Организации, которые работают с данными, подпадающими под такие регламенты, как Общий регламент защиты данных (GDPR)¹³ или HIPAA (Health Insurance Portability and Accountability Act)¹⁴, должны выбирать, документировать и поддерживать меры защиты, соответствующие данным, системе и применимым правовым обязанностям. Подходы, сохраняющие приватность, могут сокращать объем чувствительных данных, покидающих исходную среду, но они дополняют, а не заменяют инфраструктурные средства контроля.

Управление затратами вносит эксплуатационную сложность, которая требует анализа TCO¹⁵, а не наивных сравнений цен за единицу. Разобранное сравнение TCO облака и периферии показывает разрыв между ценником и реальной стоимостью системы.

В разобранном сравнении «Годовой TCO облачного вывода» перечисляет ежегодные затраты на GPU, сеть, балансировщик нагрузки и наблюдаемость для иллюстративной облачной реализации по публичным прайс-листам, а «Годовой TCO периферийного вывода» — соответствующие затраты на аппаратуру, питание, охлаждение, сеть и труд DevOps для периферийного сервера на собственной площадке.

Годовой TCO облачного вывода: ежегодные затраты на GPU, сеть, балансировщик нагрузки и наблюдаемость для облачной реализации фиксированной емкости для нагрузки зрения масштаба ResNet-50.

Годовой TCO периферийного вывода: поставленные по статьям затраты на аппаратуру, питание, охлаждение, сеть и труд DevOps для реализации периферийного сервера на собственной площадке; труд оказывается доминирующим компонентом этого сценария.

Облако и периферия: TCO

Задача: система зрения обслуживает 1 млн ежедневных выводов масштаба ResNet-50 (задержка 10 мс, ответ 100 КБ). Если учесть все затраты (часы GPU, исходящий трафик сети, питание, охлаждение и труд; они перечислены в «Годовом TCO облачного вывода» и «Годовом TCO периферийного вывода»), что дешевле за 3 года — облако или развертывание на периферии на собственной площадке?

Расчет: сценарий предусматривает фиксированный пул из 4 облачных GPU-экземпляров и один фиксированный сервер на собственной площадке. Большинство затрат постоянны, тогда как исходящий трафик облака зависит от нагрузки. Поэтому отношение двух годовых сумм не является корректной точкой безубыточной загрузки. Корректное сравнение при заявленной рабочей точке — годовой разрыв затрат из «уравнения безубыточности периферии»:

$$\text{Годовой разрыв затрат}=\text{Годовая TCO облака}-\text{Годовая TCO периферии}$$

При заявленной рабочей точке 1 млн выводов в день разрыв составляет ~$35 288 в год − ~$21 610 в год = ~$13 678 в год. Умножение этого трафика на отношение годовых сумм ошибочно принимало бы выделенную мощность за расход на каждый вывод.

Результат: при этой рабочей точке периферия стоит примерно на 38,8 процента меньше. Поскольку фиксированная облачная конфигурация уже стоит больше полной суммы периферии до учета исходящего трафика, зависящего от нагрузки, эти допущения не дают положительной точки пересечения по трафику. Корректная точка безубыточности требует облачных ресурсов, масштабируемых по спросу, явной лестницы мощности или обоснованной цены за запрос.

Системный вывод: в TCO периферии доминирует труд (~$15 000 ÷ ~$21 610 в год ≈ 69,4 процента), а не аппаратура. Организациям без имеющихся мощностей DevOps следует учитывать полную стоимость сопровождения инфраструктуры на собственной площадке.

Помимо прямых финансовых затрат, облачные развертывания несут особые эксплуатационные ограничения. Непредсказуемые всплески нагрузки усложняют бюджетирование и требуют автоматизированного мониторинга и систем управления затратами. Зависимость от сети создает опасность для доступности: любой разрыв связи между клиентами и дата-центром немедленно ухудшает работу сервиса или останавливает его. Проприетарные облачные API усугубляют это привязкой к поставщику, создавая трение переносимости программного обеспечения при переносе нагрузок между провайдерами. Даже с этими эксплуатационными ограничениями централизованная инфраструктура остается уникально подходящей для потребительских приложений, которым нужна эластичная мощность в глобальном масштабе.

Крупномасштабное обучение и вывод

Вычислительные преимущества облачного ML наиболее заметно проявляются в потребительских приложениях, которым нужен огромный масштаб. Виртуальные ассистенты вроде Siri и Alexa иллюстрируют гибридные архитектуры, характерные для современных систем ML: детекция слова пробуждения может работать на специализированном железе мощностью от доли до нескольких милливатт прямо на устройстве, обеспечивая постоянное прослушивание без постоянной активации основного процессора; первичное распознавание речи может выполняться на устройстве ради приватности и отзывчивости; а сложное понимание и генерация естественного языка могут использовать облачную инфраструктуру для доступа к более крупным моделям и более широким знаниям.

Экономика определяет эту архитектуру не меньше, чем задержка. Попытка обрабатывать голосовые взаимодействия миллиардов устройств целиком в облаке упирается одновременно в экономический и инфраструктурный потолок. Количественная оценка «стены голосового ассистента» показывает оба предела сразу.

Стена голосового ассистента

Задача: в этом иллюстративном сценарии емкости 1 млрд устройств голосовых ассистентов (смартфоны, умные колонки, наушники), каждое из которых отправляет по 20 запросов в день как трафик слова пробуждения. Во что обошлось бы масштабирование инфраструктуры, если бы все запросы обслуживались облачным ML, и сколько эквивалентов выделенных дата-центров потребовала бы пиковая нагрузка?

Экономическая стена: во-первых, стоимость обслуживания трафика слова пробуждения из облака.

• Стоимость в облаке: ~$0,50 на устройство в год → 1 млрд устройств = $500 000 000 в год. При этих допущениях экономически неприемлемо для бесплатной функции.
• Альтернатива TinyML: локальная детекция слова пробуждения при 0,1–1 мВт, менее $0,01 на устройство в год. Осуществимо в смоделированном масштабе.

Инфраструктурная стена: во-вторых, число дата-центров, которое потребовала бы пиковая нагрузка.

Пять параметров определяют требуемую емкость кластера:

1. Объем запросов: 1 млрд устройств $\times$ 20 запросов/день = 20 млрд запросов/день.
2. Потребность в GPU: каждому запросу нужно ~200 мс времени GPU. Итого: 1 111 111 GPU-часов в день.
3. Емкость сценария: эквивалент дата-центра с 10 000 GPU дает 240 000 GPU-часов в день.
4. Средняя потребность: ~4,6 выделенных дата-центра только для голосового вывода.
5. Пиковая реальность: запросы сосредоточены в часы бодрствования (пик примерно в 4,5 раза выше среднего), что требует ~20,8 дата-центра в пике.

Верхняя граница пропускной способности: в-третьих, рассмотрим отдельный контрфактический случай — передачу самого аудио. Если бы каждое устройство непрерывно передавало аудио (16 кГц, 16 бит), каждое передавало бы ~32 КБ/с. По 1 млрд устройств совокупный поток составил бы 32 ТБ/с — это иллюстративная верхняя граница, а не модель запросов.

Системный вывод: обслуживание голосовых взаимодействий полностью из облака создает неустойчивое узкое место конкурентности в глобальном масштабе: даже до учета операционных расходов пиковые объемы запросов требуют выделенной мощности дата-центра, которая превышает выполнимое распределение парка. Локальная детекция слова пробуждения заменяет это централизованное узкое место распределенным выводом милливаттного масштаба.

Конвейер голосового ассистента иллюстрирует базовый системный принцип: ограничения определяют иерархическую архитектуру. Разбиение конвейера на фильтр слова пробуждения на устройстве и облачную языковую модель снимает одновременно энергетический лимит клиента и стену конкурентности дата-центра. Гибридный подход сокращает сквозную задержку по сравнению с чисто облачной обработкой, сохраняя доступ к вычислительной емкости, нужной для сложного понимания языка.

Крупномасштабные рекомендательные движки демонстрируют облачную сделку в форме, ограниченной емкостью памяти. Системы на основе архитектур вроде DLRM¹⁶ используют разреженные таблицы эмбеддингов, чтобы сопоставить миллионы пользователей и товаров плотным векторам. Поскольку эти таблицы обычно превышают терабайты совокупного размера, ни один ускоритель не может хранить параметры модели. Вместо этого таблицы шардируются между распределенной памятью хостов и пулами ускорителей, что требует высокоскоростных межсоединений для коммуникации «все со всеми» при прямом и обратном проходах. Централизованные дата-центры предоставляют объединенную емкость памяти и кластерные сети с низкой задержкой, необходимые для размещения таких разреженных моделей при непрерывном приеме потоковых взаимодействий пользователей.

Эти приложения имеют общую черту: они обменивают задержку на масштаб, принимая задержку удаленного пути в обмен на вычислительные ресурсы, которые нельзя обеспечить локально. Системы обнаружения мошенничества, анализирующие миллионы транзакций, рекомендательные движки, обрабатывающие терабайты таблиц эмбеддингов, и языковые модели, генерирующие текст токен за токеном, — все они опираются на эту сделку. Однако, как показала стена голосового ассистента, существуют приложения, где никакой объем облачных вычислений не компенсирует физику расстояния. Когда бюджеты задержки опускаются ниже того, что допускает удаленный путь, или когда объемы данных превышают то, что способны переносить сети, вычисления должны переместиться ближе к источнику данных.

Периферийное ML: задержка и приватность

Когда удаленный путь превышает бюджет задержки нагрузки, облачный вывод становится физически невозможным. Штраф за расстояние налагает сетевую задержку еще до начала вычислений: ограничения скорости света и транзитные узлы в глобальных сетях добавляют десятки и сотни миллисекунд задержки распространения. Для тормозного пути автономного автомобиля или промышленного контура безопасности¹⁷ сетевой цикл «туда и обратно» в 100 мс съедает весь бюджет отклика еще до того, как вычислится хоть один слой. Перенос вычислений рядом с источником данных устраняет этот член удаленной передачи.

Периферийное ML обменивает эластичную облачную мощность на детерминированную задержку менее 100 мс и локальное хранение данных. В терминах архетипов периферийное развертывание сдвигает связывающее ограничение: нагрузка «пожиратель полосы пропускания», ограниченная памятью в облаке, при переносе через глобальные каналы может оказаться ограниченной задержкой удаленного пути. Локальное железо с достаточной памятью устраняет штраф сетевого транзита и возвращает узкое место к локальной пропускной способности памяти и вычислениям. По железному закону из «расширенного железного закона» локальное выполнение убирает из пути запроса член переноса $D_{\text{vol}}/{\text{BW}}_{\text{IO}}$, оставляя время выполнения ограниченным локальными вычислениями и передачей из памяти.

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

Периферийное ML

Периферийное машинное обучение — парадигма развертывания, оптимизированная под детерминированность задержки и локальность данных за счет размещения вычислений физически рядом с источниками данных.

1. Значение: она обходит штраф за расстояние $(L_{\text{lat}})$ облака, обменивая эластичный масштаб на фиксированную локальную вычислительную емкость $(R_{\text{peak}})$.
2. Отличие: в отличие от облачного ML, который ставит на первое место пропускную способность, периферийное ML ставит детерминированность и приватность. В отличие от TinyML, периферийное ML может по-прежнему использовать ускорители уровня рабочих станций, например GPU общего назначения (GPGPU).
3. Типичная ошибка: распространено заблуждение, будто периферийное ML — это определенный класс аппаратуры. На деле это парадигма размещения: она охватывает шлюзы IoT и серверы на собственной площадке, объединенные физической близостью к источнику данных.

Перенос вычислений на локальные серверы убирает дальнюю передачу из пути запроса ценой управления распределенной инфраструктурой. На «Карте ограничений периферийного ML» дерево ограничений показывает, как физическая близость к датчикам определяет локальную фильтрацию и выделенное аппаратное ускорение, одновременно обнажая фиксированные границы емкости.

Сырые данные периферии могут быть шире сетевого канала.

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

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

Узкое место пропускной способности

Задача: рассмотрим систему контроля качества на производственной линии с 100 камерами, работающими при 30 FPS и разрешении 1080p. Становится ли потоковая передача видео узким местом пропускной способности и снижает ли периферийное ML ее настолько, что обработка возможна локально?

Физика:

1. Сырая скорость данных с одной камеры: 1920 $\times$ 1080 $\times$ 3 байта $\times$ 30 FPS ≈ 186,6 МБ/с.
2. Общая скорость данных: 100 камер $\times$ 186,6 МБ/с = 18,7 ГБ/с.
3. Нагрузка на облачную передачу: загрузка сырых потоков камер — прежде всего задача пропускной способности, приема, хранения и обработки; плата за исходящий трафик облака взимается за данные, которые передаются из облака. Если бы сырой поток впоследствии выгружался по тарифу $0,09/ГБ за исходящую передачу, одна лишь плата за передачу достигла бы $4,4 млн/мес.
4. Реальность сети: даже выделенная линия 10 Гбит/с (1,25 ГБ/с) не может выдержать нагрузку: она требует в 14,9 раза больше пропускной способности, чем есть.

Системный вывод: физика делает потоковую передачу в облако невозможной для этого приложения. Периферийная обработка здесь не опциональна, а обязательна. Если периферийный сервер передает только метаданные дефектов (1 КБ на обнаружение, примерно 20 событий/с по всей линии), пропускная способность падает примерно в 933 120 раз.

Насыщение канала несжатыми потоками датчиков демонстрирует барьер пропускной способности централизованного приема. Для периферийных устройств с батарейным питанием (беспроводные камеры, дроны, носимые устройства) энергетическая стоимость беспроводной связи накладывает еще более жесткий физический потолок: при параметрах полезной нагрузки и радио из прикидочного расчета «Энергия передачи данных» радиопередача потребляет в 1000 раз больше энергии, чем локальный вывод. Передача сырой телеметрии по сотовым или Wi-Fi каналам быстро истощает бортовые энергетические резервы. На рисунке «Иллюстративные опорные точки энергии на вывод» энергетический спектр по уровням развертывания охватывает восемь порядков величины, показывая, почему периферийным и встроенным системам нужны специализированные маломощные архитектуры, а не непрерывная беспроводная передача потока.

Иллюстративные опорные точки энергии на вывод: разрыв в энергии в восемь порядков величины отделяет ключевое распознавание TinyML с ограниченной батареей (~10 мкДж) от запросов к фундаментальным моделям в облаке (~1 кДж) в логарифмической шкале. Этот физический разрыв объясняет, почему постоянное периферийное восприятие требует специализированных маломощных архитектур, а не непрерывной беспроводной передачи в облако. (Отмеченные значения — педагогические опорные точки сценария, а не результаты моделей полной системы.)

Преимущества периферийного ML и сложности развертывания

Периферийные системы охватывают носимые устройства, промышленные контроллеры и шлюзы на собственной площадке, которые обрабатывают данные локально¹⁸, не завися от центральных серверов. Хотя восьмипорядковый энергетический разброс между парадигмами отражает разные требования нагрузок и границы учета, физический управляющий принцип остается прежним: рассеяние мощности строго ограничено емкостью батареи или пассивным теплоотводом.

Этот тепловой предел напрямую задает потолок памяти и пропускной способности. Поскольку периферийные ускорители работают в строгих бюджетах мощности 5–50 Вт, они не могут поддерживать широкие мощные физические интерфейсы, которые нужны памяти с высокой пропускной способностью (HBM). Вместо этого периферийные архитектуры опираются на LPDDR или общую системную DRAM: емкость памяти ограничивает масштаб параметров модели, а пропускная способность памяти ограничивает эксплуатационную производительность. Чтобы уместить современные нейронные сети в эти физические рамки, нужны методы сжатия модели из главы «Сжатие моделей» — квантование, прореживание и архитектурная дистилляция, — которые уменьшают объем весов и трафик активаций до бюджетов аппаратуры.

Инвариант локальности данных

Решение между локальной периферийной обработкой и удаленной облачной обработкой определяется компромиссом между пропускной способностью и задержкой. Удаленное выполнение неосуществимо, когда его полный путь нарушает срок обслуживания; в остальных случаях более быстрый осуществимый путь следует из сравнения полного локального и удаленного времени.

Инвариант локальности данных

Инвариант локальности данных сначала проверяет полный удаленный путь на соответствие сроку обслуживания. Пусть $T_{\text{remote}}$ — полное время удаленного пути, $T_{\text{deadline}}$ — срок, ${\text{BW}}_{\text{network}}$ — пропускная способность для переноса вычислений, $L_{\text{lat,network}}$ — сетевая задержка, а $R_{\text{peak,remote}}$ и ${\eta }_{\text{hw,remote}}$ — скорость и эффективность удаленных вычислений: $$T_{\text{remote}}=\frac{D_{\text{vol}}}{{\text{BW}}_{\text{network}}}+L_{\text{lat,network}}+\frac{O}{R_{\text{peak,remote}}\cdot {\eta }_{\text{hw,remote}}},\text{удаленный путь осуществим}⟺T_{\text{remote}}\le T_{\text{deadline}}$$

Соответствующее $T_{\text{local}}$ — полное время локального пути. Если оба пути осуществимы, сравните $T_{\text{local}}$ и $T_{\text{remote}}$; любой путь может быть отвергнут сроком. Здесь $L_{\text{lat,network}}$ учитывает полное время сетевого цикла «туда и обратно» (распространение, маршрутизацию и протокольные рукопожатия), тогда как время передачи обратной полезной нагрузки обычно опускают, потому что результаты вывода (например, метка класса или рамка) на порядки меньше сырого входа $D_{\text{vol}}$.

1. Значение: инвариант задает точку перехода, за которой добавление удаленных вычислений $(R_{\text{peak}})$ почти не помогает, потому что передача доминирует в $T_{\text{remote}}$. Локальный путь предпочтителен, только когда проверены его собственное полное время выполнения и ресурсные пределы.
2. Отличие: в отличие от железного закона, который раскладывает один путь выполнения, инвариант локальности сравнивает два полных пути друг с другом и с явным сроком обслуживания.
3. Типичная ошибка: распространено заблуждение, будто 5G/6G «решает» вопрос локальности. Хотя эти технологии улучшают ${\text{BW}}_{\text{network}}$, они не устраняют задержку распространения и протоколов, поэтому удаленный путь все равно может не уложиться в жесткий срок обслуживания.

Эксплуатационные компромиссы напрямую следуют из формулировки локальности. Локальное выполнение устраняет время сетевого транзита ($D_{\text{vol}}/{\text{BW}}_{\text{network}}+L_{\text{lat,network}}$), обеспечивая детерминированность задержки для замкнутого контура управления всякий раз, когда локальное выполнение удовлетворяет $T_{\text{local}}\le T_{\text{deadline}}$. Потребление пропускной способности восходящего канала падает от битрейта сырых датчиков до легкой событийной телеметрии, что снижает сетевые перегрузки и повторяющиеся транзитные платежи. Локальная обработка также сокращает поверхность атак на данные, сохраняя сырые потоки датчиков внутри границ собственной площадки, хотя данные в покое все равно требуют локального контроля доступа. Кроме того, периферийные узлы обеспечивают устойчивость к разделению сети: локальный вывод продолжает работать во время сбоев глобальной сети, пока остаются работоспособными локальное питание и линии датчиков.

И наоборот, периферийное развертывание обменивает сетевой транзит на строгие физические и эксплуатационные границы. Типичное периферийное железо работает в пределах 1–8 ГБ памяти и теплового бюджета 5–50 Вт, что намного ниже возможностей облачных серверов.¹⁹ Эти ресурсные пределы делают объем модели, буферы активаций, состояние среды выполнения и тепловые циклы работы связывающими ограничениями. С эксплуатационной точки зрения управление распределенной инфраструктурой вносит нелинейную сложность: координация обновлений ПО и версий моделей на тысячах разнородных, физически доступных устройств требует специализированных конвейеров развертывания,²⁰ где стоимость отката и незаметные сбои создают эксплуатационные проблемы, которых нет в централизованных дата-центрах.

На практике точку перехода по локальности хорошо иллюстрирует проверка одного кадра высокоскоростного датчика против жесткого срока кадра.

Точка перехода по локальности

Задача: должна ли система избегания препятствий дрона (4K, 60 FPS) переносить вычисления в облако или здесь возникает точка перехода по локальности?

Дано:

• Данные $(D_{\text{vol}})$: кадр 4K ≈ 24,9 МБ.
• Пропускная способность $({\text{BW}}_{\text{network}})$: домашний широкополосный доступ 100 Мбит/с (восходящий).
• Ответ удаленной сети и вычислений: 110 мс (цикл «туда и обратно» + удаленные вычисления).

Расчет:

1. Время передачи: 24,9 МБ $\times$ 8 бит/100 Мбит/с = 1 990,7 мс.
2. Полный удаленный путь: передача + 110 мс удаленного ответа = 2 100,7 мс, против интервала кадра 16,7 мс.

Системный вывод: удаленный путь не укладывается в интервал кадра еще до учета запаса цикла управления, а более быстрые удаленные вычисления не могут устранить время передачи. Перенос в облако при этих допущениях поэтому неосуществим; локальный путь все равно нужно измерить, чтобы подтвердить, что он укладывается в срок.

Реалистичное развертывание в розничной торговле показывает, как эти ограничения превращаются в требования к пропускной способности, аппаратуре и стоимости парка. Рассмотрим сеть умных магазинов, которая развертывает детекцию людей в 500 магазинах, по 20 камер на магазин, работающих при 15 FPS. В «Требованиях к размеру периферийного вывода» частота вывода на магазин пересчитывается через число операций YOLOv8-nano на кадр, и получается пропускная способность, которую каждый магазин должен поддерживать.

Требования к размеру периферийного вывода: целевая пропускная способность на магазин для сценария детекции людей в розничной торговле.

«Варианты периферийных ускорителей» сравнивает пропускную способность, мощность, стоимость единицы и стоимость парка для трех кандидатов периферийных ускорителей, включая встроенные GPU-ускорители.

Варианты периферийных ускорителей: пропускная способность, мощность и стоимость трех кандидатов периферийных ускорителей в масштабе парка.

Размер периферийного вывода

Задача: исходя из целевой пропускной способности из «Требований к размеру периферийного вывода» и кандидатов из «Вариантов периферийных ускорителей», какой периферийный ускоритель (TPU размера USB, встроенный GPU класса рабочей станции или универсальный мини-ПК) обеспечивает нужную пропускную способность при наименьшей трехлетней стоимости парка?

Расчет: размер определяем по тому, что устойчиво выдает одна плата, а не по пиковым значениям из паспорта. Плата Coral Dev Board заявлена с пиковой производительностью 4 TOPS, но после снижения на 50 процентов дает около 2 TOPS, поэтому количество плат на магазин равно 5,22 TOPS требуемых ÷ 2 TOPS на плату = 2,6 платы, что округляется вверх до 3 плат на магазин.

За 3 года на 500 магазинов сравнение TCO этой конфигурации такое: аппаратура $225 000 + питание (0,006 кВт $\times$ 500 $\times$ 8760 ч/год $\times$ 3 года $\times$ $0,12/кВт·ч = $9 460,8) = $234 460,8 всего, против базового варианта с одним выделенным облачным GPU на магазин примерно $9 855 000.

Результат: один Coral сам по себе недостаточен, но сегментированная конфигурация из 3 плат на магазин — самый дешевый периферийный вариант: она дает 6 TOPS и примерно в 1,3 раза меньшие капитальные затраты на аппаратуру в расчете на магазин, чем Jetson. Jetson остается более простым вариантом одного устройства, когда сложность интеграции важнее стоимости аппаратуры.

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

Физическая доступность усиливает эти эксплуатационные проблемы. В отличие от серверов, размещенных в дата-центрах с контролем доступа, периферийное железо, установленное в торговых залах или на общественной инфраструктуре, физически доступно злоумышленникам. Такая открытость требует аппаратно обеспечиваемых механизмов защиты: цепочек безопасной загрузки, которые предотвращают несанкционированное изменение прошивки, шифрованного локального хранилища для весов модели и промежуточных активаций, а также корпусов, показывающих вскрытие. Кроме того, капитальные затраты растут линейно с размером развертывания: оснащение 1000 площадок периферийным железом по $500–2000 на площадку требует $500 000–2 000 000 первоначальных капитальных затрат до монтажа, кабелей и эксплуатации парка. Окупается ли эта первоначальная инвестиция более низкой совокупной стоимостью владения по сравнению с повторяющимся облачным выводом, зависит от коэффициентов загрузки, местных тарифов на энергию и накладных расходов на обслуживание площадки.

Системы реального времени: промышленность и IoT

Периферийные приложения различаются по областям, но каждое делает один и тот же аргумент о локальности конкретным: система не может ждать сеть, не может отправить данные, не может раскрыть сырой сигнал или не может остановиться во время сбоя связи. Автономные автомобили — требовательное приложение, потому что решения восприятия и управления, критичные к безопасности, должны укладываться в миллисекундные бюджеты. Бортовые системы обрабатывают потоки нескольких камер и других датчиков через локальное железо; удаленный облачный путь не может выдержать жесткий контур управления, если одна лишь сетевая задержка превышает срок.

Умная розничная торговля показывает практические преимущества периферийного ML для приложений, чувствительных к приватности и требовательных к пропускной способности. Магазин без касс²¹ может обрабатывать потоки многих камер на локальных периферийных серверах, отслеживая перемещения покупателей и выбор товаров, не передавая сырое видео непрерывно по глобальному каналу. Эта архитектура снижает спрос на пропускную способность и риск передачи, но сама по себе не обеспечивает приватность: хранение, доступ, вторичное использование и средства управления по-прежнему определяют соответствие требованиям и риски системы.

Промышленный интернет вещей²² использует периферийное ML там, где отзывчивость на уровне миллисекунд напрямую влияет на эффективность производства и безопасность работников. Производственные объекты развертывают периферийные системы ML для контроля качества в реальном времени и предиктивного обслуживания.²³

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

Многие промышленные и розничные периферийные системы стационарны и подключены к сетевому питанию: например, периферийный сервер завода, потребляющий сотни ватт круглосуточно, остается жизнеспособным. Мобильные устройства, напротив, перемещаются вместе с пользователями, без проводов, на строго ограниченных батарейных резервах. Когда вычисления переходят от стационарной инфраструктуры к мобильному устройству без проводов, энергопотребление вытесняет задержку как главное управляющее ограничение: $\text{Энергия}=\text{Мощность}\times T$. Доминирующая цель оптимизации смещается от сырого времени выполнения к энергии на вывод, что принципиально меняет пространство проектирования аппаратуры и алгоритмов.

Мобильное ML: автономный интеллект

Периферийное ML решает проблему расстояния, которая ограничивает облачные развертывания, переводя вычисления ближе к данным. Многие периферийные системы — стационарные шлюзы, заводские серверы и розничная техника, тогда как пользователи носят телефоны и планшеты через меняющуюся среду. Перенос той же локальности на переносное устройство вводит другое ограничение: батарею. В отличие от периферийных серверов с питанием от сети, которые могут непрерывно потреблять сотни ватт, мобильные устройства должны работать часами или днями на фиксированных энергетических бюджетах.

Мобильное ML решает эту задачу, встраивая машинное обучение непосредственно в переносные устройства — смартфоны и планшеты, — обеспечивая отзывчивые персонализированные возможности. Эта парадигма выигрывает там, где локальность данных, автономная работа и мгновенный отклик важнее вычислительного масштаба; она поддерживает такие приложения, как распознавание речи, вычислительная фотография²⁴ и мониторинг здоровья. Локальная обработка снижает риск передачи, но сама по себе не гарантирует приватность. Эти устройства с батарейным питанием должны уравновешивать производительность с энергоэффективностью и управлением теплом, поэтому они подходят для частых коротких задач ИИ.

Мобильная среда вводит критическое ограничение, которого нет в стационарных развертываниях: энергия на вывод становится параметром проектирования первого порядка. По железному закону из «расширенного железного закона» облачные и периферийные системы оптимизируют минимизацию $T$, полной задержки. Мобильные системы сталкиваются с дополнительным ограничением: $\text{Энергия}=\text{Мощность}\times T$, а стена мощности, описанная «масштабированием мощности», ограничивает устойчивую мощность значением 3–5 Вт. В терминах архетипов нагрузку «вычислительный зверь», например классификацию изображений, нужно преобразовать в более компактную модель зрения,²⁵ сократив FLOP в 13,7 раза при сохранении достаточной точности для приложения. Это не просто оптимизация: это качественный сдвиг в компромиссе «вычисления на байт», когда пиковая пропускная способность приносится в жертву устойчивой работе в тепловой оболочке 3–5 Вт.

Эта граница батареи и тепла задает определяющую форму мобильной парадигмы.

Мобильное ML

Мобильное машинное обучение — парадигма развертывания, ограниченная расчетной тепловой мощностью (TDP) и энергией батареи.

1. Значение: ее ограничивает способность пассивного охлаждения отводить тепло мощностью в несколько ватт, поэтому архитектуры должны ставить устойчивую энергоэффективность выше пиковой пропускной способности $(R_{\text{peak}})$.
2. Отличие: в отличие от периферийного ML, у которого может быть активное охлаждение, мобильное ML должно работать в пределах личного энергетического бюджета. В отличие от TinyML, оно по-прежнему предоставляет полноценную ОС и вычислительную мощность в несколько ватт.
3. Типичная ошибка: распространено заблуждение, будто производительность мобильного ML — фиксированная величина. На деле это ограничение, меняющееся во времени: производительность часто падает, когда устройство достигает теплового предела, и срабатывает троттлинг, снижающий рабочий цикл $({\eta }_{\text{hw}})$.

Обработка на устройстве обеспечивает мгновенный отклик и локальность данных, но работает в строгих электрохимических и термодинамических границах. Четырехветвевая таксономия из «Карты ограничений мобильного ML» связывает общий аккумулятор телефона и корпус с пассивным охлаждением с необходимыми слияниями ядер NPU и пределами теплового троттлинга.

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

Ограничение батареи ограничивает суммарное потребление энергии во времени. Даже если бы мы могли игнорировать время работы от батареи для подключенного к сети планшета или короткой демонстрации, термодинамика накладывает вторую границу. Электрическая мощность в конце концов превращается в тепло, которое устройство должно рассеять. Дата-центр использует активное охлаждение, чтобы отвести это тепло. Тонкое мобильное устройство полагается главным образом на пассивный теплообмен через корпус и поверхности. Так возникает тепловая стена — жесткий потолок устойчивого потребления мощности, который существует независимо от емкости батареи.

Карта ограничений мобильного ML: обработка на устройстве дает отзывчивость, приватность, автономную работу и персонализацию, но общий аккумулятор телефона и пассивная тепловая оболочка делают устойчивую энергоэффективность главным проектным ограничением.

Налог на батарею

Задача: рассмотрим развертывание детектора объектов «в реальном времени» в фоновом режиме на смартфоне. Модель потребляет 2 Вт непрерывной мощности при работе. У телефона стандартная батарея 15 Вт·ч. Может ли эта функция работать весь день? Это и есть налог на батарею, который превращает время работы от аккумулятора в ограничение энергетического бюджета мобильного ML.

Физика:

1. Идеальное время работы: $\frac{15\text{Вт}\cdot \text{ч}}{2\text{Вт}}=7,5\text{ч}$
2. Реальность: пользователь ждет, что телефон проработает 24 часа. Непрерывная работа одной этой функции в течение дня потребовала бы 320 процентов суточного энергетического бюджета телефона.

Системный вывод: модель нельзя просто «развернуть». Методы из главы «Сжатие моделей» должны снижать и объем работы модели, и рабочий цикл, чтобы функция могла работать весь день.

Устойчивая тепловая производительность заметно ниже пиковых значений.

Это различие важно для инженерных решений: налог на батарею — задача бюджета, принципиально разрешимая снижением частоты запусков модели или увеличением емкости батареи. Тепловая стена — физический потолок. Более емкая батарея не поднимет максимальную устойчивую мощность, которую может рассеять пассивный корпус; изменения рабочего цикла и программного обеспечения могут только снизить выделение тепла. Устойчивая работа выше тепловой оболочки запускает аппаратный троттлинг независимо от оставшейся энергии батареи. Поэтому два ограничения бьют в разные точки железного закона: батарея ограничивает суммарное число операций за заряд ($O$, проинтегрированное по времени), тогда как тепловая стена ограничивает мгновенную скорость ($R_{\text{peak}}\cdot {\eta }_{\text{hw}}$), которую кремний способен поддерживать.

Тепловая стена

Задача: неоптимизированная модель зрения требует пиковых 12 Вт вычислений. Можно ли развернуть ее на мобильном устройстве или она упирается в тепловую стену и мобильный предел мощности?

Сценарий: мобильная система на кристалле (SoC) допускает примерно 3 Вт для пассивного охлаждения. Допустим, неоптимизированная модель все равно выпускается; типичная трассировка троттлинга для такого пассивно охлаждаемого устройства идет в три шага:

1. Рост температуры: при 12 Вт температура устройства растет примерно на 1 °C/с.
2. Тепловой порог: в течение 60 с аппаратура достигает точки теплового срабатывания (80 °C), что включает троттлинг ОС.
3. Троттлированная пропускная способность: модель на 100 FPS внезапно падает до 30 FPS, чтобы уложиться в тепловую оболочку.

Расчет: допустим иллюстративное снижение активной мощности в 4 раза после перепроектирования FP32 → INT8 (см. главу «Сжатие моделей»): 12 Вт ÷ 4 = 3 Вт, что приходится ровно на потолок пассивного охлаждения 3 Вт без запаса. Этот коэффициент — входной параметр сценария, а не универсальная гарантия для всей системы, которую дает одно лишь квантование.

Системный вывод: даже снижение мощности в 4 раза не создает теплового запаса: оно лишь едва достигает устойчивого предела. Физика задает жесткий потолок, который не может превысить никакая оптимизация.

Преимущества мобильного ML и ресурсные ограничения

Мобильные устройства демонстрируют промежуточные ограничения: 8–16 ГБ оперативной памяти (от среднего класса до флагманов), 128 ГБ–1 ТБ хранилища, 15–45 TOPS вычислений ИИ на нейропроцессорах²⁶ при потреблении 3–5 Вт. Архитектуры систем на кристалле²⁷ объединяют вычисления и память, чтобы минимизировать энергетические затраты. Емкость памяти ограничивает объем модели, а пропускная способность 51,2–77 ГБ/с ограничивает скорость перемещения весов и активаций. Ограничения батареи (емкость 15 Вт·ч–22 Вт·ч) делают оптимизацию энергии критичной: добавление 1 Вт непрерывной обработки ML к телефону, который иначе работает 24 часа, сократит время работы примерно до 9,2–11,5 часа в зависимости от емкости батареи. Специализированные мобильные фреймворки для вывода на устройстве обеспечивают аппаратно оптимизированный вывод для времени отклика интерфейса 5–50 мс.

Мобильное ML хорошо справляется с отзывчивыми сценариями при сильной локальности данных. Обработка в реальном времени может достигать задержки менее 10 мс для некоторых задач, обеспечивая время отклика интерфейса 5–50 мс в интерактивных приложениях. Локальная обработка чувствительных входов сокращает передачу данных и центральное хранение, а анклавы на устройстве, такие как Secure Enclave от Apple, дополнительно защищают биометрические данные,²⁸ хотя сила гарантий приватности в конечном счете зависит от всей системы и модели угроз. Функции навигации, перевода и обработки медиа также могут работать без сети, если их модели и данные помещаются в мобильный бюджет. Персонализация завершает картину: модели могут использовать сигналы устройства и контекст пользователя, оставляя сырые данные локальными.

Эти преимущества требуют принять жесткие ресурсные ограничения. По сравнению с облачными развертываниями мобильные приложения часто работают в гораздо более тесных бюджетах памяти, хранилища и задержки, что ограничивает размер модели и поведение батчей. Время работы от батареи заметно для пользователя, а тепловой троттлинг может существенно ограничивать устойчивую производительность: пиковая пропускная способность NPU может заметно превышать то, что устройство способно поддерживать при длительной нагрузке. Сложность разработки множится по платформам, требуя отдельных реализаций и тщательной настройки производительности, а разнородность устройств требует нескольких вариантов модели. Проверка в магазине приложений и поэтапные релизы также могут замедлять итерации по сравнению с сервисом, полностью контролируемым его оператором.

Персональный ассистент и обработка медиа

Во всех мобильных приложениях центральная системная задача в том, что несколько коротких конвейеров должны делить один и тот же бюджет батареи и тепла. Вычислительная фотография демонстрирует задачу запуска нескольких конвейеров ML в тепловой оболочке. Современные флагманы обрабатывают каждый снимок через несколько стадий ML: портретный режим²⁹ использует оценку глубины и сегментацию, ночной режим выравнивает несколько кадров с шумоподавлением на основе ML, а слияние HDR, сверхразрешение и оптимизация сцены идут последовательно. Инженерная задача — не отдельная модель, а конвейер: эти модели должны делить бюджет мощности 3–5 Вт и уложиться в воспринимаемую пользователем задержку затвора, что требует аккуратного планирования по CPU, GPU и NPU, чтобы избежать теплового троттлинга.

Голосовые взаимодействия демонстрируют многоуровневую архитектуру мобильного ML. Детекция слова пробуждения работает непрерывно на выделенном маломощном ядре, тогда как распознавание речи и предсказание клавиатуры используют более мощные нейроуровни. Каждый уровень работает при своей мощности, показывая, как мобильное ML распределяет нагрузки между разнородными блоками обработки внутри одной системы на кристалле.

Мониторинг здоровья и дополненная реальность доводят мобильное ML до пределов устойчивой производительности. Носимые устройства вроде Apple Watch обрабатывают данные ЭКГ и акселерометра на устройстве, чтобы сократить передачу данных, тогда как фреймворки AR требуют бюджета кадра 16,7 мс при 60 FPS для одновременной локализации, отслеживания рук и понимания сцены. Эти приложения задают предел того, что могут устойчиво выдерживать устройства с батарейным питанием и пассивным охлаждением, и определяют границу, за которой одной лишь мобильной оптимизации недостаточно.

Эти успехи могут создать обманчивое ощущение легкости. Типичная ловушка — попытка развернуть на мобильных или периферийных устройствах модели, обученные на настольных компьютерах, без изменения архитектуры. Модели, разработанные на мощных рабочих станциях, часто не работают на устройствах с ограниченными ресурсами. Настольный конвейер ResNet-50 может потребовать гигабайты, если учесть активации, батчи, буферы предобработки и накладные расходы среды выполнения, хотя одни веса FP32 занимают около 102,4 МБ. Такой конвейер, требующий 8,2 GFLOP на вывод, не может работать без изменений на типичной периферийной цели с 512 МБ ОЗУ и процессором 1 GFLOP/s. Помимо простых нарушений ресурсов, модели, оптимизированные под настольные системы, могут использовать операции, которых нет в мобильном железе, предполагать числовые форматы, недоступные во встроенных системах, или требовать пакетной обработки, несовместимой с выводом отдельных примеров. Успешное развертывание требует архитектурно-ориентированного проектирования с самого начала: семейство моделей, арифметические форматы и реализационные решения должны соответствовать целевому устройству.

Мобильное ML показывает, что полезный интеллект может работать в тепловой оболочке 3–5 Вт от батареи. Однако смартфоны по-прежнему стоят сотни долларов, требуют гигабайт памяти и ежедневной зарядки, которая требует внимания пользователя. Эти требования делают их непригодными для обширного класса приложений: мониторинга влажности почвы на ферме в тысячу акров, обнаружения структурных напряжений в тросах мостов или прослушивания редких видов в отдаленном лесу. Такие сценарии требуют не только меньшей мощности, но и качественно иного инженерного режима: устройство стоит доллары, а не сотни, память измеряется килобайтами, а не гигабайтами, и система работает без присмотра месяцами или годами. Методы мобильной оптимизации помогают, но они не могут преодолеть разрыв в доступной памяти в 10 000 раз. Нужен не уменьшенный смартфон, а принципиально другой класс аппаратуры и алгоритмов.

TinyML: повсеместное восприятие

Представьте, что вы оснащаете датчиками каждый поддон на складе, каждый трос подвесного моста, каждый улей на пасеке. Чтобы поставить «глаза и уши» на такое количество физических объектов — десятки тысяч или миллионы, — устройство должно стоить доллары, а не сотни долларов, и измеряться миллиметрами, а не сантиметрами. Смартфоны слишком дороги и слишком велики; нужно повсеместное восприятие при стоимости единицы менее десяти долларов и физических размерах в миллиметрах.

TinyML завершает спектр развертывания, доводя интеллект до физических пределов: маломощное ML с низкой стоимостью на сильно ограниченных встроенных устройствах (Janapa Reddi et al., 2022). Устройства стоимостью менее $10 и потребляющие меньше одного милливатта³⁰ мощности делают повсеместное³¹ восприятие экономически практичным в массовом масштабе; MLPerf Tiny и MCUNet показывают, как такие ограничения оцениваются и оптимизируются на практике (Banbury et al., 2021; Lin et al., 2020). Это область архетипа «жесткого ограничения», где цель оптимизации смещается от максимизации пропускной способности к минимизации энергии на вывод. При работе с циклическим включением модель распознавания ключевых слов, потребляющая 10 мкДж на вывод, может работать годами от батарейки-таблетки, достигая миллионократного улучшения энергоэффективности за счет обмена емкости модели на долговечность работы. На «Масштабе аппаратуры TinyML» аннотированные отладочные платы показывают этот физический масштаб: интегрированные микроконтроллеры, массивы датчиков и штыревые разъемы, предназначенные для работы компактных моделей в изолированных средах.

Масштаб аппаратуры TinyML: отладочные платы микроконтроллеров объединяют датчики, вычислительные ядра и маломощные радиомодули на одной подложке, работая в строгих рамках SRAM килобайтного масштаба и мощности в милливаттах. Такой компактный форм-фактор смещает цель оптимизации от пиковой пропускной способности к энергии на вывод, позволяя работать многие годы от батареек-таблеток. Источник изображения: рисунок 6 в Janapa Reddi et al., 2022, распространяется по лицензии CC BY 4.0.

Работа на таком физическом масштабе требует микроконтроллеров (MCU)³², которые убирают энергозатратную инфраструктуру обычных вычислений. Мобильные и периферийные процессоры опираются на внешнюю динамическую память (DRAM), высокоскоростные шины памяти и среды выполнения операционных систем, которые потребляют сотни милливатт просто на регенерацию ячеек памяти и переключение линий шины. Микроконтроллеры полностью отказываются от внешних шин памяти, интегрируя ядро процессора, энергонезависимую флеш-память и статическую память (SRAM) на одном кремниевом кристалле (Banbury et al., 2021; Lin et al., 2020; Janapa Reddi et al., 2022). Хотя отказ от внешней сигнализации снижает активную мощность до доли милливатта, а мощность сна — до микроватт, он накладывает безжалостный потолок памяти. SRAM на кристалле физически ограничена площадью кремниевого кристалла: поскольку каждая ячейка SRAM требует шесть транзисторов ($6\text{T}$), увеличение емкости напрямую поднимает стоимость производства. Поэтому модель TinyML должна выполняться в пределах десятков-сотен килобайт SRAM без виртуальной памяти, подкачки или файла подкачки, которые смягчали бы переполнение. Получающийся энергетический разрыв между TinyML и облачным выводом («Иллюстративные опорные точки энергии на вывод») составляет не менее шести порядков величины³³, а для облачных запросов LLM достигает восьми порядков, позволяя непрерывную многолетнюю работу от батареек-таблеток.³⁴

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

TinyML

TinyML — область машинного обучения постоянного восприятия, ограниченная памятью килобайтного масштаба и мощностью милливаттного масштаба.

1. Значение: она требует, чтобы веса и код помещались во флеш-памяти, а активации и состояние среды выполнения — в SRAM на кристалле, что позволяет непрерывный вывод при бюджетах мощности в милливаттах.
2. Отличие: в отличие от мобильного ML, который использует процессоры мощностью в несколько ватт и полноценную ОС, TinyML работает на микроконтроллерах с прошивкой без ОС или на операционной системе реального времени.
3. Типичная ошибка: распространено заблуждение, будто TinyML — это просто «маленькие модели». На деле это парадигма, ограниченная энергией: главная метрика — энергия на вывод (микроджоули), а не только число параметров.

Это определение переосмысляет железный закон систем машинного обучения. В терминах «расширенного железного закона» TinyML накладывает физическое предусловие по емкости памяти, которое время выполнения не отражает: объем модели $M_{\text{model}}$ и объем активаций должны оставаться в пределах емкости памяти $C_{\text{mem}}$. Когда полная память измеряется килобайтами, структура модели и выделение памяти в среде выполнения определяют осуществимость еще до начала оптимизации задержки, а каждое лишнее перемещение данных тратит часть энергетического бюджета. Поэтому цель смещается от сырой пропускной способности к энергии на вывод и соответствию памяти.

Как читать числа энергии на вывод

Значения энергии из «Энергии на вывод по парадигмам» сочетают расчетные оценки энергии устройств с отдельными масштабными опорами; это не контролируемые измерения полной системы. Иллюстративная граница ResNet-50 только на A100 составляет менее 1 мс и около ~0,3 Дж, тогда как весь сервер при учете CPU, памяти и накладных расходов может потреблять около ~1 кВт. Значения в последнем столбце показывают, сколько выводов может обеспечить номинальная энергия одной батареи; это не время работы от батареи, и в них не учтены датчики, режим сна и связь.

Этот разрыв энергоэффективности TinyML помогает понять, почему локальные модели с низким энергопотреблением привлекательны для постоянного восприятия. Фактическое время работы все еще зависит от частоты выводов, мощности сна, датчиков, связи и остальной части устройства.

Энергетический разрыв между парадигмами — не вопрос степени, а масштаба: он охватывает восемь порядков величины, очерченных на «Иллюстративных опорных точках энергии на вывод». «Энергия на вывод по парадигмам» опирается на этот диапазон конкретными числами, переводя энергетическую стоимость каждой парадигмы в число выводов, которые может обеспечить одна батарея смартфона.

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

Работа при бюджетах мощности менее милливатта позволяет непрерывно вести восприятие без сетевого питания, но вынуждает хранить полное состояние вывода в SRAM на кристалле. Четырехколоночная таксономия из «Карты ограничений TinyML» показывает, как память килобайтного масштаба и циклические состояния сна позволяют постоянные нагрузки, одновременно ограничивая обновления модели.

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

Преимущества TinyML и эксплуатационные компромиссы

TinyML работает на крайних значениях аппаратных параметров. По сравнению с облачными системами развертывания TinyML обычно дают примерно в $10^6$–$10^9$ раз меньше памяти, в зависимости от того, измеряется ли бюджет микроконтроллера мегабайтами или килобайтами, при бюджетах мощности в милливаттах. Эти жесткие ограничения позволяют месяцами или годами работать автономно³⁵, но требуют специализированных алгоритмов, сжатия моделей и тщательного системного совместного проектирования. Устройства варьируются от отладочных комплектов размером с ладонь до чипов миллиметрового масштаба,³⁶ обеспечивая повсеместное восприятие там, где сеть, питание или обслуживание обходятся дорого. Типичные отладочные комплекты включают Arduino Nano 33 BLE Sense (256 КБ ОЗУ, 1 МБ флеш-памяти, 20–40 мВт) и ESP32-CAM (520 КБ ОЗУ, 4 МБ флеш-памяти, 50–250 мВт).

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

Эти возможности требуют существенных компромиссов. Вычислительные ограничения жесткие: микроконтроллеры обычно имеют от $10^5$ до $10^6$ байт ОЗУ, что вынуждает модели и промежуточные активации уместиться в диапазоне от десятков килобайт до нескольких мегабайт в зависимости от нагрузки. Микроконтроллеры придерживаются строгого двухуровневого разделения памяти: статические веса модели и скомпилированный код находятся в энергонезависимой флеш-памяти (часто несколько мегабайт), тогда как изменяемые активации и буфер среды выполнения (тензорная арена) должны помещаться в гораздо меньшую SRAM на кристалле (часто менее 256 КБ). В результате пиковый объем промежуточных активаций — а не хранение статических параметров — часто оказывается связывающим барьером, который не дает модели выполниться. Встроенная разработка также требует совместного проектирования на всех уровнях стека: инженеры вручную управляют пулами памяти, отлаживают прошивку без абстракций ОС и оптимизируют ядра операторов непосредственно под ограниченные наборы инструкций.

Работа в этих физических границах создает особые проблемы жизненного цикла и надежности. Устройство, собирающее энергию из окружающей среды, может удовлетворять своему долгосрочному среднему бюджету мощности, но все равно выйти из строя, когда запасенная энергия исчерпывается до следующего сбора. Поэтому его рабочий цикл должен учитывать и энергию на вывод, и время доступности энергии. Качество модели также может страдать от агрессивного квантования и прореживания: перевод 32-битных весов с плавающей запятой в 8-битные целые (INT8) экономит память, но может ухудшить точность и устойчивость на входах датчиков вне обучающего распределения. Кроме того, гибкость после развертывания резко ограничена: модели компилируются прямо в монолитные образы прошивки, поэтому обновления в полевых условиях зависят от медленных и рискованных процессов перепрошивки. Фрагментация экосистемы³⁷ между производителями микроконтроллеров и фреймворками ML создает дополнительные накладные расходы и трудности переносимости.

Экологический и медицинский мониторинг

Режим работы TinyML становится необходимым, когда бюджеты мощности, стоимость единицы и физическая изоляция исключают все платформы более высокого уровня. Детекция слова пробуждения — самый знакомый потребительский пример: специализированный маломощный компонент слушает непрерывно, обрабатывает звук локально и включает более мощные компоненты, только когда обнаружена фраза пробуждения, снижая среднее потребление мощности.³⁸ Точное земледелие использует то же давление локальности с другой стороны: FarmBeats применяла датчики, камеры, дроны и локальную обработку на шлюзе, чтобы сократить перемещение сырых данных там, где связь на ферме была дорогой (Vasisht et al., 2017). TinyML доводит логику локальности дальше, когда сам узел восприятия должен работать при бюджетах в милливаттах.

Охрана дикой природы использует TinyML для удаленного экологического мониторинга: аудиосенсоры на солнечных батареях обрабатывают непрерывные акустические потоки на устройстве для определения видов. Передача периодических сводок обнаружений вместо сырого непрерывного звука сокращает восходящий поток данных с 4,3 ГБ в день до 400 КБ в день, то есть в 10 750 раз, что экономит энергию в развертываниях вне электросети. Медицинские носимые устройства применяют ту же логику локальной обработки к физиологическому мониторингу. Чувствительность, частота дискретизации, мощность и срок службы батареи — это целевые показатели проверки, специфичные для устройства, а не универсальные свойства аппаратуры TinyML. Локальная обработка минимизирует непрерывную беспроводную передачу и защищает приватность пользователя, тогда как полное время работы остается ограниченным потреблением датчика, мощностью радиомодуля, рабочим циклом и энергией сна.

Эти четыре парадигмы образуют эксплуатационный континуум, ограниченный скоростью света, теплоотводом и передачей сигналов в памяти. При проектировании системы ML инженерия начинается с систематического сопоставления ограничений приложения с этими физическими границами.

Выбор парадигмы

Архитектор, выбирающий, где запускать функцию ML, редко оптимизирует одно измерение. Правило приватности может запрещать облачную обработку, бюджет задержки — удаленный вывод, объем памяти может превышать возможности мобильного устройства, а целевая стоимость — исключать постоянно работающее периферийное железо. Облако, периферия, мобильные устройства и TinyML — это эксплуатационные оболочки для таких конфликтов, поэтому выбор между ними требует единой рамки сравнения и структурированного процесса решения.

Сравнительный анализ компромиссов

Решения о развертывании требуют оценки компромиссов «задержка против пропускной способности» между парадигмами в разных физических и эксплуатационных оболочках. Выбор между облачными, периферийными, мобильными и TinyML-целями требует одновременного балансирования задержки, рассеяния мощности, финансовой стоимости, раскрытия данных и сложности программного обеспечения. В «Сравнении парадигм по четырнадцати измерениям» эти четыре парадигмы сопоставлены по четырнадцати аппаратным и системным измерениям, которые задают базовые оболочки, определяющие осуществимость развертывания.

Сравнение парадигм по четырнадцати измерениям: всестороннее сопоставление по четырнадцати измерениям, важным для решений о развертывании. Облачное ML дает самые сильные вычисления, тогда как локальная обработка может сокращать передачу и подверженность централизованного хранения, но сама по себе не гарантирует приватность. Эта таблица служит основным справочником для системных архитекторов, оценивающих варианты развертывания.

Этот контраст отражает фундаментальное напряжение между локальностью данных и вычислительным масштабом. Удаленная обработка расширяет сетевую поверхность атак и требует надежного транспортного шифрования и изоляции арендаторов; локальная обработка ограничивает сырые данные устройством, снижая риск на входе, но не устраняя физических рисков побочных каналов. Архетипы нагрузок из «Анализа нагрузок» напрямую соотносятся с этими границами: каждый архетип тяготеет к парадигмам, которые снимают его основное узкое место.

Чтобы визуализировать эти многомерные компромиссы, «Лепестковые диаграммы сравнения парадигм» оценивает четыре парадигмы по порядковой шкале 0–10 по двум ортогональным эксплуатационным профилям: подграфик (а) сопоставляет сырую пропускную способность с задержкой и тепловой эффективностью, а подграфик (б) оценивает эксплуатационную автономность по независимости от связи, локальности данных, детерминированному отклику в реальном времени и работе без сети.

Лепестковые диаграммы сравнения парадигм: две лепестковые диаграммы сравнивают производительность и эксплуатационные характеристики облачной, периферийной и мобильной парадигм и TinyML по порядковым оценкам 0–10. Левая диаграмма сопоставляет вычислительную мощность, возможность низкой задержки, масштабируемость и энергоэффективность; правая — независимость от связи, локальность данных, работу в реальном времени и работу без сети. В обеих диаграммах больший многоугольник означает более сильные показатели: облачное ML достигает пика по вычислениям и масштабируемости, а TinyML — по энергоэффективности, локальности данных и работе без сети.

Расходящиеся профили на «Лепестковых диаграммах сравнения парадигм» показывают, что ни один уровень развертывания не доминирует по всем эксплуатационным метрикам. Вместо этого каждая парадигма переносит инженерную сложность в свою подсистему. Облачные развертывания требуют экспертизы в распределенном консенсусе, многоарендной сети и динамическом управлении затратами. Периферийные развертывания и TinyML накладывают жесткие физические ограничения на тепловую оболочку и емкость памяти, требуя оптимизации «на голом железе», абстракции гетерогенного оборудования и удаленной оркестрации парка. Мобильные развертывания работают на оборудовании, принадлежащем пользователю; это снижает затраты на инфраструктуру, но вводит фрагментацию драйверов конкретных платформ, агрессивный троттлинг фоновых задач операционной системы и строгие энергетические бюджеты.

Распространенный архитектурный провал — выбирать цель развертывания только по точности модели, а аппаратные ограничения считать второстепенными деталями оптимизации. Неадаптированная модель, которая в офлайн-оценке дает 99 процентов точности, становится нежизнеспособной, если ее объем памяти вызывает подкачку на мобильном железе или если непрерывный вывод запускает тепловой троттлинг за секунды. Физические инварианты — емкость памяти, пределы теплоотвода и задержка сетевого транзита — должны служить ранними критериями отсева еще до начала разработки модели, отсекая недопустимые цели развертывания до того, как будут потрачены ресурсы на обучение.

Рамка решения

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

Отсев решений о развертывании: четыре уровня организуют вопросы приватности, задержки, потребности в вычислениях и стоимости, затем связывают их ветви с вариантами облака, периферии, мобильных устройств и TinyML. Сходящиеся ветви и ветвь низкой стоимости, ведущая и к мобильным, и к TinyML-вариантам, делают эту схему инструментом отсева, а не детерминированным выбором.

Блок-схема работает как грубый фильтр, а не как детерминированный алгоритм с одним путем. Верхние барьеры накладывают жесткие физические и регуляторные ограничения, которые исключают целые ветви независимо от того, насколько желанны их нижние варианты. Если регуляторные правила или суверенитет данных запрещают передачу за пределы устройства, удаленная облачная обработка исключается сразу. Аналогично, если физические сроки меньше времени сетевого цикла «туда и обратно», парадигмы, зависящие от сети, отбрасываются независимо от вычислительной мощности сервера. Когда ветви сходятся на уровне стоимости — где и мобильное ML, и TinyML выступают как недорогие варианты, — рамка сужает пространство проектирования до управляемого набора кандидатов для подробного бенчмаркинга.

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

Экстренное торможение автомобиля

Сценарий: система машинного зрения автономного автомобиля выполняет детекцию пешеходов в реальном времени для экстренного торможения при жестком сквозном бюджете задержки 100 мс.

Диагностика: сценарий предполагает 50–150 мс сетевой задержки «туда и обратно» для переноса в облако и 10–30 мс на локальную детекцию объектов на автомобильном периферийном ускорителе (300 GFLOP/s). При этих допущениях одна лишь удаленная ветвь заставляет автомобиль проехать 2,8 м до начала торможения.

Системный урок: жесткие ограничения реального времени для безопасности исключают перенос в облако независимо от доступности вычислений. Ограничения задержки задают архитектуру периферийного ML, а облачные соединения сохраняются для офлайн-обучения моделей и агрегации телеметрии.

Прохождение физических и экономических барьеров отсева устанавливает техническую осуществимость, но архитектор должен также учитывать эксплуатационную сопровождаемость. Развертывание модели на тысячах периферийных узлов или миллионах микроконтроллеров создает постоянные накладные расходы жизненного цикла: автоматизированные обновления прошивки, внеполосную телеметрию, распределенный мониторинг дрейфа и восстановление после отказов оборудования. Организация, приспособленная к облачной эксплуатации, может не иметь встроенных инструментальных цепочек и инфраструктуры физического тестирования, необходимых для поддержки периферийных или TinyML-целей в масштабе.

Помимо эксплуатационных требований конкретных уровней железа стоит предшествующий системный вопрос: оправдывает ли функция вообще развертывание машинного обучения. Глубокие нейронные сети налагают заметное бремя сопровождения, которого традиционное программное обеспечение избегает. Прежде чем принимать любую архитектуру ML, инженер должен оценить, может ли детерминированная эвристика решить задачу при малой доле эксплуатационных затрат.

Налог на сложность

Рассмотрим задачу классификации, которую можно решить либо детерминированными эвристическими правилами, либо конвейером глубокого обучения. Эвристика требует пятидесяти строк кода, почти не расходует вычисления, требует примерно одного часа в месяц на обновление правил и не демонстрирует дрейфа распределения. Система ML может потребовать всего пятьдесят строк определения модели, но вносит около 2 000 строк вспомогательной инфраструктуры для приема признаков, журналирования телеметрии, мониторинга дрейфа и управления драйверами GPU, а также 40 часов в месяц на диагностику дрейфа данных и сопровождение конвейеров.

Модель ML, которая повышает точность с 90 до 95 процентов, дает чистый отрицательный результат по инженерным усилиям, если при этом расширяет эксплуатационное сопровождение в 40 раз. Инженерия систем машинного обучения сосредоточена на минимизации этих накладных расходов с помощью устойчивых архитектур; когда постоянные затраты на сопровождение превышают ценность предельных статистических выигрышей, детерминированное программное обеспечение остается правильным системным решением.

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

Проектирование системы

Центральный компромисс часто — точность против сложности.

Барьеры решения

• Базовый уровень: измерили ли вы точность простой эвристики (регулярные выражения, логистическая регрессия) до обучения глубокой сети?
• Стоимость инфраструктуры: оправдывает ли прирост точности на 2 процента от трансформера десятикратный рост стоимости вывода и бремя сопровождения по сравнению с меньшей моделью?

Работа с этими компромиссами показывает, что выбор парадигмы — это архитектурная оптимизация, ограниченная физическими инвариантами вычислений, коммуникации и хранения. Рамка решения задает базовую осуществимость, а главы «Бенчмаркинг» и «MLOps» описывают соответствующие практики измерения и эксплуатационного жизненного цикла; однако в реальных приложениях часто возникают взаимно несовместимые ограничения. Интеллектуальной системе может понадобиться обучение петабайтного масштаба вместе с откликом менее миллисекунды и приватностью без связи. Когда ни один уровень сам по себе не может удовлетворить эти конфликтующие физические границы, системная инженерия преодолевает разрыв, распределяя нагрузку между несколькими средами эксплуатации.

Гибридные архитектуры

Рамка решения («Отсев решений о развертывании») сужает набор осуществимых парадигм для приложения, проверяя кандидатные системы на соответствие отдельным физическим ограничениям. Однако производственные нагрузки редко работают при едином ограничении на протяжении всего жизненного цикла. Управление в реальном времени требует контуров отклика менее миллисекунды, непрерывное восприятие — оболочек мощности менее милливатта, а представление большой емкости — кластеров ускорителей с памятью в несколько гигабайт. Ни одна аппаратная платформа не удовлетворяет всем трем требованиям одновременно: размещение всей нагрузки в облаке нарушает сроки задержки и пределы сетевой пропускной способности, а ее ограничение микроконтроллером лишает память и арифметической пропускной способности. Производственные системы разрешают это противоречие с помощью гибридных архитектур, распределяя вычислительный конвейер между несколькими аппаратными уровнями так, чтобы каждая стадия выполнялась там, где ее связывающее ограничение обходится дешевле всего. Разделение труда определяют три схемы интеграции.

Схемы интеграции

Три основные гибридные схемы ML различаются тем, какая физическая граница определяет разбиение: разделение «обучение — обслуживание» (train-serve split), иерархическая обработка или постепенное развертывание. Выбор схемы — решение по железному закону: каждая стадия вычислений должна выполняться там, где ее связывающий член — будь то пропускная способность $R_{\text{peak}}$, локальный нижний предел задержки $L_{\text{lat}}$ или емкость памяти — дает наименьший системный штраф.

При разделении «обучение — обслуживание» обучение выполняется в централизованных дата-центрах, а вывод работает локально на периферийных, мобильных или встроенных устройствах. Такое разделение снимает фундаментальную асимметрию между оптимизацией модели и ее выполнением. Обучению нужны обратное распространение, хранение состояния оптимизатора (например, векторы моментов и дисперсий в Adaptive Moment Estimation (Adam), которые требуют в 8–16 раз больше памяти, чем сами параметры) и высокопроизводительный пакетный параллелизм на плотных структурах ускорителей. Вывод же выполняет только прямой проход, обрабатывает малые батчи или отдельные токены и должен удовлетворять жестким локальным ограничениям по задержке и приватности. В основе экономики этого разделения лежит амортизация: высокая фиксированная стоимость обучения распределяется на миллионы запросов прямого прохода, обслуживаемых локально без повторяющихся расходов на сетевую передачу.³⁹

Гибридное ML

Гибридное машинное обучение — стратегия развертывания, которая распределяет конвейер ML между двумя и более уровнями развертывания, назначая каждую стадию в соответствии с ее ограничениями по задержке, вычислениям, данным и эксплуатации.

1. Значение: гибридные архитектуры используют аддитивную структуру железного закона: периферийный уровень может сокращать $L_{\text{lat}}$ для чувствительных ко времени предобработки и вывода, а облачный уровень может давать $R_{\text{peak}}$, нужный для обучения, переобучения и тяжелого пакетного вывода. Разделение следует инварианту локальности данных: сравните полные локальный и удаленный пути каждой стадии, отбросьте пути, не укладывающиеся в срок обслуживания, и затем выберите из осуществимых альтернатив.
2. Отличие: в отличие от развертывания только в облаке (которое принимает штраф за расстояние для всех стадий) или только на периферии (которое принимает ограниченный $R_{\text{peak}}$ для всех стадий), гибридное ML динамически назначает каждую стадию конвейера уровню, где минимизирован ее связывающий член железного закона.
3. Типичная ошибка: распространено заблуждение, будто гибридное ML — это просто «запуск двух моделей». На деле участвующие уровни должны разделять синхронизированное состояние — определения признаков, версии моделей и логику предобработки, — чтобы их пути давали согласованные результаты. Без такой синхронизации на границах уровней возникает перекос обучения и обслуживания.

При иерархической обработке вычисления каскадируются по уровням, последовательно отфильтровывая и агрегируя данные и согласуя объем коммуникации с доступной пропускной способностью межсоединений. Потоки датчиков на физической периферии часто превышают пропускную способность восходящего канала глобальной сети (WAN); непрерывная передача сырой несжатой телеметрии в дата-центр насыщает сетевые каналы и тратит мощность радиомодуля. Чтобы не допустить насыщения сети, ранние уровни фильтруют данные локально: маломощные детекторы аномалий работают на микроконтроллерах TinyML, периферийные шлюзы агрегируют и сопоставляют временные признаки с нескольких датчиков, а облачные кластеры получают только аномальные события или агрегированные сводки для глобальной аналитики. При обслуживании вывода иерархическая обработка часто принимает форму каскада уверенности. Компактная модель с низкой задержкой на локальном устройстве сначала оценивает вход. Если уверенность предсказания превышает калиброванный порог $\tau$, устройство сразу возвращает результат, полностью минуя сеть. Только неоднозначные или низкоуверенные входы запускают передачу полезной нагрузки по WAN к большой облачной модели, что минимизирует медианную задержку обслуживания при сохранении пиковой точности модели.

При постепенном развертывании инженерная команда выводит семейство специализированных вариантов модели из единой архитектуры или общего обучающего корпуса, подгоняя каждый вариант под объем памяти, арифметическую интенсивность и тепловые пределы конкретного уровня. Вместо того чтобы навязывать одну модель всем устройствам, разработчики применяют структурированное сжатие — посттренировочное квантование, прореживание и дистилляцию знаний, — чтобы получить артефакты для каждого уровня вдоль кривой Парето «точность — эффективность». Современные голосовые интерфейсы иллюстрируют такую многоуровневую последовательность: непрерывная детекция слова пробуждения работает в рамках бюджета SRAM постоянно включенного микроконтроллера (занимая десятки килобайт для эталонных нейросетей TinyML и потребляя от доли милливатта до милливатт на специализированном маломощном железе); локально обнаруженные триггерные фразы будят нейропроцессорный блок на устройстве, который разбирает акустические признаки; а неограниченное семантическое понимание передается большим моделям масштаба параметров в облачной инфраструктуре.

Когда доступны три схемы интеграции, выбор становится задачей сопоставления ограничений: нужно взять ту схему, профиль компромиссов которой совпадает с доминирующим узким местом системы. В «Руководстве по выбору гибридной схемы» суммированы компромисс, условия, благоприятствующие каждой схеме, и условия, которые ее не рекомендуют.

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

Производственные развертывания редко реализуют эти схемы по отдельности: сложные системы сочетают их на разных фазах конвейера. Например, автономный автомобиль сочетает постепенное развертывание, чтобы уместить специализированные визуальные базовые сети (backbone) в бортовую вычислительную оболочку; иерархическую обработку, которая разрешает конфликт между немедленным экстренным торможением на локальном железе в миллисекундном масштабе и планированием траектории в масштабе секунд; и разделение «обучение — обслуживание», которое загружает аномальные фрагменты вождения в облачные кластеры для переобучения на уровне парка. Распределенные парадигмы обучения с сохранением приватности, например федеративное обучение, расширяют эту композицию в случаях, когда сырые обучающие данные не могут покидать клиентские устройства из-за регуляторных или приватных ограничений.

Интеграция производственных систем

Производственные гибридные системы координируют несколько уровней через структурированные каналы взаимодействия. Как показано на «Взаимодействиях гибридной системы», многоуровневые архитектуры поддерживают два встречных потока: скомпилированные артефакты моделей развертываются вниз от облачных кластеров обучения к периферийным, мобильным и TinyML-целям выполнения, тогда как сырые потоки датчиков, отфильтрованные признаки и телеметрия вывода поднимаются вверх к централизованным хранилищам данных.

Взаимодействия гибридной системы: данные поднимаются вверх от датчиков через уровни обработки к облачной аналитике, а обученные модели развертываются вниз к точкам вывода на периферии, в мобильных устройствах и TinyML. Пять типов связей (развертывание, данные, результаты, помощь и синхронизация) задают распределенную архитектуру, в которой каждая парадигма вносит уникальные возможности.

Производственные системы демонстрируют эти схемы интеграции, размещая границу каждого уровня у отдельного физического узкого места:

1. Детекция дефектов на производстве: сборочные линии с высокой частотой циклов требуют детерминированного визуального контроля менее 10 мс. Передача потоков камер высокого разрешения по WAN в дата-центр нарушает сроки контроля и исчерпывает пропускную способность восходящего канала завода. Система использует разделение «обучение — обслуживание»: централизованная облачная инфраструктура с модулями из нескольких ускорителей обучает модели зрения высокой емкости на исторических базах дефектов, затем компилирует и квантует веса для выполнения на периферийных серверах цеха и во встроенных умных камерах. Эти ускорители на площадке выполняют вывод через локальные интерфейсы камер PCIe или MIPI, гарантируя ограниченную задержку без внешних сетевых зависимостей.
2. Мониторинг сельского хозяйства: развернутые на сотнях гектаров удаленные почвенные зонды работают от батареек-таблеток или небольших солнечных сборщиков и обмениваются данными по маломощным радиоканалам LPWAN или LoRa с низкой скоростью передачи и высокой энергией на бит. Непрерывная передача телеметрии влажности и температуры исчерпывает запас батареи за дни. Иерархическая обработка оставляет высокочастотную выборку и базовое обнаружение аномалий микроконтроллерам TinyML, работающим при бюджетах мощности менее милливатта. Когда появляются аномалии, локальные периферийные шлюзы агрегируют измерения по пространственным кластерам зондов и передают по сотовой магистрали только сжатые сводки на уровне поля в облачные серверы, отвечающие за расписание орошения по всей ферме.
3. Носимый фитнес-трекинг: умные часы с батарейным питанием работают в жесткой тепловой оболочке, где рассеяние непрерывно работающего процессора должно оставаться ниже $1\text{ мВт}$. Система применяет постепенное развертывание в архитектуре шлюзов: легкие целочисленные ядра работают на встроенном микроконтроллере, отслеживая движение в реальном времени и обнаруживая пороги частоты сердечных сокращений; промежуточные биометрические данные синхронизируются по Bluetooth Low Energy (BLE) с парным смартфоном, который использует мобильные нейродвижки и гигабайты DRAM для классификации сложных паттернов активности; наконец, смартфон передает периодические сжатые сводки по Wi-Fi или сотовым сетям в облачную инфраструктуру для долгосрочного моделирования здоровья.

Почему гибридные подходы работают

Хотя четыре уровня развертывания различаются на порядки величины по доступной энергии, объему памяти и вычислительной пропускной способности, они опираются на одни и те же системные основания. На «Сближении систем ML» структурная иерархия показывает, как разные цели развертывания зависят от общих принципов управления данными, абстракций выполнения «аппаратура — ПО» и планирования ресурсов.

Сближение систем ML: несмотря на огромные различия ресурсов между облачным, периферийным, мобильным уровнями и TinyML, все развертывания сходятся на трех общих системных основах: конвейеры данных, управление ресурсами и архитектура «аппаратура — ПО». Эти общие опоры, в свою очередь, поддерживают единые требования к оптимизации производительности, эксплуатационному мониторингу и надежной инженерии.

Это архитектурное сближение объясняет, почему инженерные оптимизации переносятся в обе стороны между масштабами железа: они нацелены на одни и те же физические узкие места. На всех уровнях чтение операнда из внешней памяти стоит на порядки больше энергии и задержки, чем арифметическая операция. Поскольку стена памяти управляет и встроенным микроконтроллером, и складским ускорителем, методы, разработанные в условиях крайних периферийных ограничений, напрямую снимают узкие места в дата-центре. Представления с пониженной точностью (например, FP8, INT8 и INT4), изначально созданные, чтобы уместить веса модели в мегабайты мобильной DRAM или килобайты SRAM микроконтроллера, решают ту же экономическую задачу в облачных кластерах: вдвое сокращают трафик DRAM и умножают эффективную пропускную способность тензорных ядер («Сжатие моделей»). Аналогично, слияние операторов и статическая подготовка памяти, разработанные для предотвращения выгрузки за пределы кристалла в мобильных SoC, напрямую уменьшают трафик HBM при облачном авторегрессивном декодировании. В обратную сторону методы разбиения вычислительных графов между распределенными облачными кластерами (глава «Обучение моделей») дают базовый формализм для разбиения стадий конвейера между разнородными мобильными SoC, содержащими отдельные CPU, GPU и нейропроцессорные блоки.

Общая системная основа распространяется на инженерию данных (глава «Инженерия данных»), сжатие моделей (глава «Сжатие моделей») и эксплуатационные жизненные циклы (глава «MLOps»). Эти инженерные принципы применимы, будь целью выполнения многоузловой модуль TPU или сверхмаломощный микроконтроллер ESP32. Поскольку базовые абстракции остаются инвариантными, инвариантны и их уязвимости: дрейф распределения данных, устаревание модели и деградация телеметрии повторяются на каждом уровне, требуя единой дисциплины мониторинга по всей гибридной иерархии.

Гибридные схемы ML

Гибридные архитектуры работают тогда, когда работа распределена между уровнями, а не когда один и тот же конвейер копируется повсюду.

Схемы интеграции

• Разделение «обучение — обслуживание»: можете ли вы объяснить, почему обучение в облаке и обслуживание на периферии или мобильном устройстве часто экономически оптимальны, даже когда модель работает локально?
• Иерархическая обработка: можете ли вы описать, что делает каждый уровень в конвейере «датчик → периферия → облако», и почему перенос части решений вниз сокращает одновременно задержку и пропускную способность?
• Постепенное развертывание: можете ли вы объяснить, как одно семейство моделей становится несколькими развернутыми артефактами (облако, периферия, мобильные устройства, TinyML) благодаря систематическому сжатию?

Проверки здравомыслия проекта

• Выбор границы: для конкретного приложения можете ли вы обосновать, где должна проходить граница уровней (задержка, приватность, пропускная способность, мощность), а не только то, какую модель использовать?
• Синхронизация состояния: можете ли вы указать, какие определения признаков, версии моделей и логика предобработки должны оставаться синхронизированными между уровнями?

Системная энтропия: почему развертывание — не конец

Во всех парадигмах развертывания, обобщенных на «Сближении систем ML», системы ML имеют эксплуатационную уязвимость, которой нет у классического программного обеспечения. В традиционных вычислениях скомпилированный бинарный файл работает по детерминированному контракту: пока ячейки памяти сохраняют заряд, шины процессора передают биты без искажений, а входные буферы удовлетворяют заявленным предусловиям, процедура сортировки или обращения матрицы выполняется одинаково миллионы раз. Машинное обучение нарушает это постоянство. По таксономии D·A·M алгоритм ($A$) и машина ($M$) после развертывания остаются статичными: веса модели находятся в памяти, а среда выполнения исполняет один и тот же вычислительный граф при каждом прямом проходе. Но распределение эксплуатационных данных ($D$) непрерывно меняется по мере изменения поведения пользователей, дрейфа калибровки датчиков и колебаний среды. Поскольку параметры модели представляют собой эмпирическую подгонку под фиксированное обучающее распределение $P_{\text{train}}$, любое расхождение живого распределения $P_{\text{live}}$ порождает системную энтропию: постоянное ухудшение качества предсказаний, которое происходит даже тогда, когда код, веса модели и среда выполнения остаются побайтно идентичными.

Диагностическое приближение из «уравнения деградации качества систем ML» формализует эту скорость деградации: качество системы снижается по мере роста статистического расстояния $\mathcal{D}(P_{\text{train}},P_{\text{live}})$ между обучающим и живым распределениями, масштабированного чувствительностью модели $S_{\text{shift}}$ к сдвигу распределения:

$$\Delta \text{Качество}\approx -S_{\text{shift}}\cdot \mathcal{D}(P_{\text{train}},P_{\text{live}})$$

Поскольку движки вывода сообщают об успехе, пока матричные умножения завершаются без числовых исключений и ошибок памяти, статистическая деградация остается невидимой для традиционного мониторинга инфраструктуры. Модель без мониторинга продолжает выдавать предсказания с высокой уверенностью, тогда как ее эксплуатационная полезность неуклонно падает. Поэтому надежность системы требует непрерывной статистической телеметрии, чтобы обнаруживать, когда дрейф распределения требует обновления модели, — эксплуатационная дисциплина, разобранная в главе «MLOps».

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

Крах Zillow Offers (2021)

Контекст: Zillow, площадка для торговли недвижимостью, запустила «Zillow Offers», чтобы покупать дома напрямую в рамках бизнеса iBuying, который зависел от прогноза цен на жилье и экономики перепродажи (Zillow Group, 2021).

Механизм: Zillow сообщила, что покупала дома по ценам выше своих пересмотренных оценок будущих цен продажи, а ограничения пропускной способности перепродажи задерживали некоторые сделки (Zillow Group, 2021). Неопределенность прогноза превратилась в риск запасов, потому что система связывала оценки цен с обязательствами по покупке.

Последствия: Zillow списала 304 миллиона долларов жилищных запасов, сократила 25 процентов персонала (2000 сотрудников) и окончательно закрыла подразделение Offers.

Реакция: более безопасная конструкция ограничивала бы риск запасов, сохраняла ручные переопределения и ставила автоматические выключатели между неопределенностью прогноза и решениями о покупке.

Системный урок: сдвиг распределения превращает статистическую деградацию в серьезный деловой риск, когда программное обеспечение напрямую связывает предсказания с действиями в балансе. Производственные системы в динамичной среде требуют автоматических выключателей и петель обратной связи, которые ограничивают реальный риск, когда живые распределения ошибок расширяются.

Провал Zillow Offers показывает, что система машинного обучения включает и предсказательную модель, и эксплуатационную петлю обратной связи, которая действует на ее выходы. Рассмотрение развертывания как окончательной передачи, при которой обученная модель замораживается и оставляется работать без присмотра, игнорирует реальность системной энтропии. Статистическая деградация данных ($D$) неизбежно подрывает гарантии алгоритма ($A$) и машины ($M$). Защита производственного конвейера требует инженерных мер по всей архитектуре — от телеметрии дрейфа входов и шлюзов валидации до автоматических выключателей. Однако управление системной энтропией — лишь одна часть эксплуатационной дисциплины; перемещение по физическим ограничениям развертывания также требует отказа от укоренившихся допущений, перенесенных из классической инженерии программного обеспечения.

Заблуждения и ловушки

Помимо статистической деградации, инженеры нередко попадают в архитектурные заблуждения о развертывании ML. Физические ограничения, управляющие перемещением данных, теплоотводом и балансом аппаратуры, создают контринтуитивное поведение, которое ставит под сомнение стандартную интуицию инженерии программного обеспечения. Приведенные ниже заблуждения и ловушки описывают типичные режимы отказа, в которых системы критически не соответствуют своим физическим эксплуатационным оболочкам.

Заблуждение и ловушка

Заблуждение: одна парадигма развертывания решает все задачи ML.

Физические ограничения создают жесткие границы, которые не может охватить ни одна парадигма. Обсуждение стены памяти в «Балансе системы и аппаратуре» показывает, что пропускная способность памяти, ее емкость и задержка доступа растут гораздо медленнее сырых арифметических вычислений, создавая разные физические узкие места на уровнях развертывания. «Сравнение парадигм по четырнадцати измерениям» перечисляет иллюстративные эксплуатационные оболочки, а не границы задержки, основанные только на физике. Система робототехники реального времени, которой нужен отклик менее 10 мс, не может использовать удаленный облачный путь, сетевой цикл «туда и обратно» которого превышает этот бюджет, а модель языка с миллиардом параметров не может уместиться в 256 КБ SRAM микроконтроллера независимо от сжатия. Устойчивые архитектуры часто сочетают парадигмы, используя облачные ресурсы для распределенного обучения и пиковой емкости, а локальный вывод или предобработку датчиков выполняя на клиентских устройствах.

Связанное заблуждение предполагает, что перенос вычислений ближе к пользователю всегда сокращает задержку, не учитывая задержку выполнения, которую вносят процессоры периферии с тепловыми ограничениями или меньшей пропускной способностью, — компромисс, разобранный в разделе «Бенчмарки вывода».

Заблуждение и ловушка

Ловушка: полагаться на оптимизацию модели, чтобы преодолеть мобильные ограничения по мощности и теплу.

Методы сжатия не могут преодолеть фундаментальные термодинамические пределы. Рассмотрим смартфон с батареей 15 Вт·ч. Легкая нагрузка вывода, потребляющая 1 Вт, работает $\frac{15\text{Вт}\cdot \text{ч}}{1\text{Вт}}=15$ ч, а интенсивная нагрузка, потребляющая 5 Вт — типичная для неоптимизированных фундаментальных моделей на устройстве, — истощает ту же батарею за $\frac{15\text{Вт}\cdot \text{ч}}{5\text{Вт}}=3$ ч.

Устойчивая работа на 5 Вт также вызывает сильный тепловой троттлинг, поскольку корпус смартфона рассчитан примерно на 3 Вт для установившегося пассивного рассеяния. Хотя квантование параметров FP32 в INT8 дает иллюстративное четырехкратное снижение объема памяти, динамическая энергия переключения и статическая утечка не уменьшаются пропорционально. Непрерывный конвейер вывода, превышающий пассивную тепловую оболочку, неизбежно вызывает динамическое масштабирование частоты, вынуждая инженеров снижать рабочие циклы, перестраивать архитектуры моделей или переносить вычисления на специализированный кремний ускорителей.

Заблуждение и ловушка

Заблуждение: TinyML — это уменьшенное мобильное ML.

Граница между TinyML и мобильным развертыванием качественная: физические ограничения вынуждают к принципиально разным алгоритмическим и исполнительным моделям. Как установлено в «Преимуществах TinyML и эксплуатационных компромиссах», микроконтроллеры имеют от 256 КБ до 1 МБ SRAM, тогда как мобильные платформы имеют 8–16 ГБ LPDDR DRAM — разница в емкости в 10 000 раз, которая определяет, что помещается в памяти. Там, где мобильные системы выполняют модели с десятками миллионов параметров, архитектуры TinyML ограничены десятками или сотнями тысяч параметров, требуя специализированных операций раздельных по глубине сверток и планирования слоев, направленного на минимизацию пиковой памяти активаций. Бюджеты рабочей мощности демонстрируют еще более резкий разрыв: мобильный вывод потребляет 3–5 Вт, тогда как TinyML рассчитан на 1–10 мВт, чтобы работать внутри оболочек сбора энергии. Команды, которые применяют мобильные методы оптимизации напрямую в средах TinyML, обнаруживают, что посттренировочного квантования из FP32 в INT8 недостаточно, когда совокупная рабочая память должна помещаться в 64 КБ SRAM, что вынуждает к полной алгоритмической переработке.

Заблуждение и ловушка

Ловушка: минимизация вычислительных ресурсов минимизирует общую стоимость.

Оптимизация вычислительных ресурсов на вывод изолированно часто увеличивает операционные расходы и замедляет темп развертывания. Как подчеркивает рамка решения в «Рамке решения», выбор архитектуры требует оценки совокупной стоимости владения (TCO) по всему жизненному циклу системы, а не только счетов за серверы. В этом сценарии облачный сервис вывода, стоящий $2 000/мес. за вычисления, выглядит дорого по сравнению с $500/мес. амортизированного периферийного железа. Однако распределенный периферийный парк вносит повторяющиеся эксплуатационные расходы: сетевая инженерия ($3 000/мес.), полевое сопровождение оборудования ($500/мес.) и инженерия надежности парка ($2 000/мес.). Это доводит общие эксплуатационные затраты периферии до $6 000/мес. — рост в 3 раза относительно облачной базы. Кроме того, если облачный управляемый сервис выходит в производство за два месяца, а собственная периферийная инфраструктура требует шести, четырехмесячная задержка влечет серьезные альтернативные издержки. Грамотная системная инженерия балансирует вычислительную эффективность со скоростью разработки, управляемостью парка и эксплуатационным сопровождением.

Более быстрая стадия модели не ускоряет конвейер камеры линейно.

Заблуждение и ловушка

Заблуждение: оптимизация модели линейно переходит в ускорение системы.

Закон Амдала⁴⁰ определяет, что сквозное ускорение строго ограничено временем выполнения неускоренных стадий. Формализованное через принцип узкого места («Принцип узкого места») и выведенное в приложении (см. раздел о законе Амдала для сильного масштабирования), достижимое ускорение системы равно ${\text{Ускорение}}_{\text{overall}}=\frac{1}{(1-p)+\frac{p}{s}}$, где $p$ — доля общего времени выполнения, подлежащая ускорению, а $s$ — коэффициент ускорения этой изолированной доли. Рассмотрим нажатие кнопки спуска камеры смартфона. Как показано на рисунке выше, конвейер захвата обрабатывает сырые кадры сенсора через 100 мс обработки сигнала изображения (ISP: автоэкспозиция и баланс белого), 60 мс классификации сцены с помощью ML и 40 мс тонального отображения и слияния HDR — всего 200 мс. Ускорение стадии нейросети в 10 раз (6 мс вместо 60 мс) снижает полную задержку с 200 мс до 146 мс. Несмотря на десятикратное ускорение модели, сквозная задержка улучшается лишь в 1,37 раза. Даже снижение задержки модели до нуля $(s=\infty )$ дает максимальное ускорение в 1,43 раза, ограниченное оставшимися 70 процентами неускоренного выполнения конвейера. Оптимизация ML-системы требует профилирования всего графа выполнения; ускорение изолированной стадии дает убывающую отдачу, как только эта стадия перестает быть узким местом критического пути.

Заблуждение и ловушка

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

Три ограничения задают пределы отдачи от масштабирования данных, как проанализировано для архетипов нагрузок в «Анализе нагрузок». Во-первых, алгоритмическая емкость ($A$) насыщается: когда бюджет параметров модели фиксирован, дополнительные обучающие данные не могут преодолеть представительные узкие места, как только архитектура исчерпывает свою выразительную способность. Во-вторых, качество данных ($D$) важнее сырого объема: шум меток, ошибки калибровки датчиков и артефактные корреляции загрязняют обновления градиентов, поэтому масштабированные испорченные корпуса усиливают систематическое смещение вместо улучшения обобщения. В-третьих, согласованность распределения определяет полезность в реальном мире: высококачественные данные эксплуатации из той же области стабильно дают лучшую точность обслуживания по сравнению с массивными наборами данных вне области, которые не отражают физической среды производства.

Заблуждение и ловушка

Заблуждение: один бинарный файл модели может эффективно обслуживать любую периферийную аппаратную цель.

Команды часто компилируют один артефакт модели и развертывают его одинаково на разных устройствах, рассматривая развертывание как этап упаковки, а не как задачу совместного проектирования с аппаратурой. На практике компиляция под конкретное железо и понижение ядер фиксируют важные эффективности, которые теряют универсальные бинарные файлы. Например, выполнение квантованных операций INT8 на специализированном нейропроцессорном блоке (NPU) дает заметно большую пропускную способность на ватт, чем выполнение той же модели на универсальном CPU, поскольку тензорные движки INT8 с фиксированной функцией избегают накладных расходов на декодирование инструкций и энергии тракта с плавающей запятой. Кроме того, слияние операторов сохраняет промежуточные тензоры активаций в SRAM на кристалле или регистровых файлах, а не выгружает их в энергозатратную внешнюю DRAM. Аналогично, настройка раскладки памяти, выравнивающая каналы тензоров с векторными регистрами ускорителя, устраняет некоалесцированные обращения к памяти. Как установлено в анализе парадигм развертывания в «Рамке парадигм развертывания», аппаратные архитектуры накладывают расходящиеся ограничения на выполнение: бинарный файл, скомпилированный для CPU Arm Cortex-A78, не использует плотно связанную SRAM-скретчпад и систолические массивы NPU Arm Ethos-U. Переносимый артефакт модели служит лишь промежуточным представлением; производственное развертывание требует компиляции и профилирования под целевую среду выполнения, аппаратный делегат, иерархию памяти и тепловую оболочку.

Итоги

Инженерия систем ML управляется физической реальностью: каждая цель развертывания задает собственный аппаратный контракт. Железный закон систем ML ($T=\frac{D_{\text{vol}}}{\text{BW}}+\frac{O}{R_{\text{peak}}\cdot {\eta }_{\text{hw}}}+L_{\text{lat}}$) объединяет эти физические пределы в единую модель выполнения: задержка распространения дает фиксированную задержку ($L_{\text{lat}}$), стена памяти ограничивает перемещение данных ($D_{\text{vol}}/\text{BW}$), а тепловые бюджеты мощности ограничивают устойчивые вычисления. На уровнях облака, периферии, мобильных устройств и TinyML категориальная энергетическая оболочка от мегаватт до милливатт охватывает девять порядков величины, тогда как представительные системы занимают внутри нее более узкие диапазоны.

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

Одна модель, разная инженерия

• Физические ограничения определяют осуществимость: скорость света (около 36 мс межконтинентального цикла «туда и обратно»), стена мощности, стена памяти и бюджеты задержки создают жесткие границы, которые инженерия не может преодолеть, а может только обходить.
• Выявляйте узкие места до оптимизации: одна и та же модель ограничена вычислениями в обучении, но ограничена памятью в выводе. Железный закон и принцип узкого места указывают, какое ограничение доминирует; оптимизация не того члена дает нулевое ускорение.
• Архетипы нагрузок определяют осуществимость развертывания: «вычислительный зверь», такой как обучение крупномасштабных моделей зрения, часто требует облачных ресурсов; «жесткое ограничение», такое как распознавание ключевых слов, требует эффективности микроконтроллера. Одна и та же стратегия оптимизации не может обслужить оба; инженеры должны сопоставлять архетип нагрузки с парадигмой развертывания.
• Мощность развертывания охватывает девять порядков: инфраструктура облачного дата-центра работает на уровне мегаватт, тогда как системы TinyML нацелены на милливатты. Этот разрыв открывает совершенно разные классы приложений, а не является ограничением.
• Гибридные архитектуры распространены в производственных системах: голосовые ассистенты охватывают TinyML (слово пробуждения), мобильное ML (речь в текст) и облако (понимание языка). Когда одной парадигмы недостаточно, схемы интеграции (разделение «обучение — обслуживание», иерархическая обработка, постепенное развертывание) формализуют способы сочетания парадигм.
• Системное ускорение подчиняется закону Амдала, а не выигрышам на уровне модели: в разобранном конвейере камеры 10-кратно более быстрая модель дает лишь 1,37-кратное ускорение системы, когда ML занимает 30 процентов конвейера. Профилируйте всю систему перед оптимизацией любого компонента.
• Развертывание начинает петлю обратной связи: живые данные могут расходиться с условиями обучения, пока код и веса остаются неизменными, поэтому мониторинг и ограниченная эксплуатационная экспозиция — часть архитектуры системы.

Парадигмы развертывания — не произвольные предпочтения проектирования; это непрерывные эксплуатационные области, продиктованные физическими законами. Выбор цели развертывания меняет то, какой член железного закона, скорее всего, будет связывать: обучение в дата-центре может упираться в пиковые вычисления ($O/R_{\text{peak}}$), мобильный вывод может столкнуться с пропускной способностью памяти ($D_{\text{vol}}/\text{BW}$), а удаленный вывод в реальном времени может ограничиваться задержкой распространения ($L_{\text{lat}}$). Системная инженерия начинается с измерения этого связывающего ограничения. Оптимизация архитектуры модели или программных сред выполнения без учета нижележащего аппаратного контракта порождает хрупкие системы, которые ломаются под давлением реальной эксплуатации.

От теории к процессу

Хотя физические ограничения и рамка решения, установленные в «Рамке решения», определяют, где ML-система может физически выполняться, одной физической осуществимости недостаточно для успеха эксплуатации со временем. Как показало списание Zillow на $304 млн (Zillow Group, 2021), развертывание моделей в производстве требует сдерживания неопределенности прогноза и управления эксплуатационным риском на протяжении всего программного жизненного цикла. «Рабочий процесс машинного обучения» вводит жизненный цикл разработки ML — систематический инженерный процесс, который ведет систему от постановки задачи через развертывание, мониторинг и сопровождение.

1. Парадигма развертывания: отдельный режим эксплуатации, границы которого задает физика, а не соглашение. Спектр от облака до TinyML охватывает девять порядков величины по мощности, потому что термодинамические и электромагнитные ограничения создают жесткие стены, которые никакая программная оптимизация не может преодолеть, и это вынуждает к качественно разным системным архитектурам на каждом уровне. Неверное определение границы парадигмы тратит инженерные усилия: оптимизировать облачную модель ради прироста пропускной способности на 5 процентов бессмысленно, если бюджет задержки приложения в 10 мс требует развертывания на периферии. ↩

2. Задержка: время между отправкой запроса и получением результата, соответствующее $T$ в железном законе. Световой барьер делает этот пол неустранимым: скорость света в волокне задает минимум ~36 мс «туда и обратно» по континентальной части США, поглощая весь бюджет задержки системы безопасности на 10 мс до начала любых вычислений. Каждая миллисекунда, потраченная на расстояние, — это миллисекунда, недоступная для вывода модели, поэтому световой барьер вынуждает выбирать парадигму, а не просто оптимизировать. ↩

3. Масштабирование Деннарда: названо по работе Dennard et al. (1974) из IBM, где описаны соотношения масштабирования MOSFET, при которых уменьшение приборов позволяло снижать напряжение и ток при сохранении примерно постоянной плотности мощности. По мере того как масштабирование напряжения замедлялось и энергия становилась архитектурным ограничением первого порядка, рост производительности сместился к параллелизму и специализации: многоядерным процессорам, GPU и TPU (Hennessy and Patterson, 2019; Esmaeilzadeh et al., 2011). ↩

4. Пропускная способность памяти (стена памяти): термин «стена памяти» ввели Wulf и McKee в 1995 году; они предсказали, что разрыв производительности процессора и памяти в конце концов станет доминировать в производительности системы, и это предсказание оказалось точным для нагрузок ML, в которых перемещение весов или активаций может ограничивать производительность. В железном законе пропускная способность $(\text{BW})$ стоит в знаменателе члена данных $D_{\text{vol}}/\text{BW}$, поэтому удвоение перемещаемых байтов без соответствующего роста пропускной способности увеличивает время перемещения данных. Итоговое узкое место зависит от арифметической интенсивности, размера батча, повторного использования данных, шаблона доступа и баланса аппаратуры, а не только от размера модели. ↩

5. Архетип нагрузки: классификация нагрузок ML по их доминирующему узкому месту железного закона, а не по семейству модели. Различие важно, потому что стратегия оптимизации принципиально иная: нагрузка, ограниченная вычислениями, выигрывает от более быстрой арифметики $(R_{\text{peak}})$, а нагрузка, ограниченная пропускной способностью, — от более широких шин памяти или меньшего числа перемещаемых байтов за счет повторного использования, слияния, сжатия или более низкой точности. Неверное определение архетипа тратит усилия оптимизации на не тот член железного закона, например когда команды добавляют FLOP/s ускорителя в конвейер вывода, ограниченный памятью, и не получают никакого ускорения. ↩

6. Критический путь: самая длинная последовательная цепочка зависимых операций в конвейере. Правило решения в предыдущем предложении строгое: если сетевой вызов между регионами на 200 мс оказывается где-либо на критическом пути, система с общим бюджетом 100 мс гарантированно не уложится, как бы быстро ни работали все остальные стадии. Вывод модели не обязан быть самой долгой стадией; предобработка и постобработка могут доминировать, делая критический путь длиннее, чем предполагает одно лишь выполнение модели. ↩

7. Спектр стоимости аппаратуры ML: инфраструктура ИИ охватывает шесть порядков величины по стоимости — от микроконтроллеров за $10 до кластеров ускорителей за многие миллионы долларов. Такой диапазон в миллион раз означает, что выбор парадигмы развертывания одновременно является решением физики и экономики. Даже внутри выбора отдельных устройств одна и та же целевая точность может достигаться на недорогом микроконтроллере лишь после существенного сокращения модели или на дорогом ускорителе дата-центра с гораздо большим бюджетом ресурсов, и профили задержки, мощности и эксплуатационных затрат при этом принципиально различаются. ↩

8. Эффективность использования энергии дата-центра (PUE, Power usage effectiveness): эта метрика отделяет накладные расходы энергии инфраструктуры, включая охлаждение и распределение питания, от энергии, которая поставляется вычислительному оборудованию. Даже при PUE 1,06 в масштабе дата-центра остается заметная энергия, не идущая на вычисления. TinyML не требует выделенного охлаждения помещения, хотя датчики, связь, потери преобразования и энергия режима сна все еще входят в полный энергетический бюджет системы. Эти затраты уровня устройства находятся за пределами PUE. ↩

9. Масштаб обучения больших языковых моделей (LLM): только централизованные дата-центры могут агрегировать достаточно $R_{\text{peak}}$ для запусков обучения на 3 634,3 PFLOP-дней (Patterson et al., 2021). Удаленный вывод добавляет сетевую задержку, поэтому чисто облачное выполнение оказывается невозможным, когда сквозной путь превышает бюджет задержки приложения. ↩

10. Облако как коммунальные вычисления (utility): коммунальная модель позволяет провайдерам предлагать специализированный портфель аппаратуры, который экономически невыгодно поддерживать одной организации. Это дает прямой доступ по требованию к конкретным архитектурам, нужным каждому архетипу нагрузки: плотным модулям ускорителей для вычислительных зверей, узлам с HBM для пожирателей полосы пропускания и системам большой памяти с быстрыми межсоединениями для разреженного разброса. Поэтому команда может арендовать специально созданный суперкомпьютерный модуль стоимостью $10 млн+ на несколько часов, а не владеть им. ↩

11. Tensor processing unit (TPU): специализированная интегральная схема (ASIC), которая дает пропускную способность масштаба PFLOP/s, жестко зашивая архитектуру под матричные умножения, доминирующие в нагрузках ML. Эта крайняя специализация обменивает универсальную гибкость на улучшение производительности на ватт более чем в 10 раз по сравнению с универсальным ускорителем на той же задаче ML. Высокая стоимость развертывания таких ускорителей в масштабе дата-центра поэтому оправдана только для массивных, устойчивых вычислений ML. ↩

12. Оплата по мере использования: облачная экономическая модель, в которой пользователи платят за потребленные часы ускорителей, а не за принадлежащее им оборудование. Эластичное ценообразование превращает фиксированную стоимость простаивающего $R_{\text{peak}}$ в переменную стоимость, пропорциональную фактической загрузке, но постоянные нагрузки 24/7 могут стоить в облаке дороже эквивалентного собственного оборудования, амортизированного за три года; эта точка перехода задает анализ совокупной стоимости владения (TCO) в «Годовом TCO облачного вывода». ↩

13. GDPR (General Data Protection Regulation): статья 17 предоставляет право на стирание, когда применимы указанные основания (European Parliament and Council of the European Union, 2016). Для системы ML запрос на стирание требует проследить, где сохраняются данные человека: в исходных хранилищах, производных признаках, журналах, кешах и артефактах моделей. Переобучение может быть одной из мер, но регламент не предписывает переобучать каждую модель, которая встречалась с этими данными. ↩

14. HIPAA: Правило безопасности обязывает регулируемые организации внедрять разумные и соответствующие административные, физические и технические меры защиты электронной защищенной медицинской информации, включая контроль доступа и аудита (U.S. Department of Health and Human Services, 2005). Правило технологически нейтрально и не требует анклавов конфиденциальных вычислений; конкретные средства контроля и их издержки производительности зависят от анализа рисков системы и реализации. ↩

15. Совокупная стоимость владения (TCO, Total cost of ownership): измеряет разрыв между ценником и реальной стоимостью системы, включая все прямые и косвенные затраты (питание, охлаждение, труд) за срок службы системы и сопоставляя первоначальные капитальные затраты (CapEx) с повторяющимися операционными (OpEx). Для GPU на собственной площадке цена покупки — лишь одна из составляющих трехлетней TCO наряду с эксплуатационными расходами. ↩

16. Deep learning recommendation model (DLRM): архитектура Meta 2019 года, которая служит примером архетипа «разреженный разброс». Таблицы эмбеддингов производственных рекомендательных систем могут превышать 100 ТБ, поэтому DLRM ограничен емкостью памяти и пропускной способностью коммуникации $\text{BW}$, а не сырым $R_{\text{peak}}$. Эта инверсия типичного допущения о вычислительной ограниченности вынуждает к специализированным кластерным конструкциям, где дефицитным ресурсом является память, а не арифметика. ↩

17. Промышленный интернет вещей (IIoT): область, где ограничения задержки задает физическая безопасность, а не восприятие пользователя. Контур безопасности с бюджетом остановки 5 мс не может допустить удаленный цикл в 100 мс, поэтому его детекция и решение об остановке должны оставаться локальными. Этот выбор убирает член дальней сети, но оставляет периферийную систему ограниченной ее локальной вычислительной емкостью $(R_{\text{peak}})$. ↩

18. Барьер данных интернета вещей (IoT): McKinsey оценивает, что развертывания IoT могут создать триллионы долларов экономической стоимости к 2030 году, но эти развертывания зависят от непрерывных потоков данных с датчиков, распределенных по домам, фабрикам, фермам, транспорту и инфраструктуре (McKinsey Global Institute, 2021). Во многих из этих сред совокупный $D_{\text{vol}}$ от сырых потоков превышает доступный бюджет восходящего канала или бюджет задержки централизованного приема, поэтому локальная периферийная обработка становится архитектурным требованием, а не просто оптимизацией стоимости. ↩

19. Ограничения периферийного сервера: в типичных периферийных оболочках 1–8 ГБ могут вместить примерно 1–8 миллиардов весов INT8 до учета активаций, состояния среды выполнения и других буферов, поэтому одно лишь число параметров не задает универсального потолка «только миллионы». Устойчивые вычисления дополнительно ограничены мощностью, охлаждением и тепловым циклом работы. ↩

20. Координация периферийного парка: управление тысячами распределенных периферийных устройств приводит к режимам отказа, которых нет в централизованном облаке: прерывистая связность вызывает дрейф версий модели, разнородность железа требует оптимизации под каждую цель, а физическая доступность делает откат прошивки дорогим. Эти эксплуатационные паттерны рассматриваются в главе «MLOps». ↩

21. Розничная торговля без касс: магазин может объединять наблюдения камер с событиями полок и состоянием транзакций локально, а затем передавать только выбранные события или агрегаты. Граница приватности должна при этом включать и эти производные записи, потому что сокращение передачи сырого видео не определяет хранение, доступ или вторичное использование. ↩

22. Индустрия 4.0: четвертая промышленная революция встраивает ML в контур обратной связи «датчик — исполнительное устройство» на производственных линиях. Системное следствие: задержка контура управления $(L_{\text{lat}})$ должна быть меньше физического процесса, которым он управляет: сварочный робот, который обнаруживает дефект на частоте 60 Гц, имеет интервал опроса 16,7 мс, что требует развертывания, полный путь отклика которого укладывается в этот срок. ↩

23. Предиктивное обслуживание: модели анализируют данные датчиков, например вибрацию и температуру, чтобы оценить состояние оборудования и риск отказа. Непрерывный мониторинг делает частоту опроса датчиков, рабочий цикл, мощность и локальное хранилище первоклассными ограничениями. Узлы с батарейным питанием могут требовать средней работы менее 1 Вт, тогда как промышленные шлюзы с сетевым питанием могут использовать гораздо большую оболочку. ↩

24. Вычислительная фотография: использует алгоритмы ML (например, слияние нескольких кадров, нейронное шумоподавление), чтобы преодолеть физические пределы малых сенсоров мобильных камер. Это иллюстрирует компромисс мобильных вычислений: многостадийный конвейер должен выполняться в пределах воспринимаемой пользователем задержки затвора и при общем тепловом бюджете 3–5 Вт. ↩

25. Сокращение модели зрения для мобильных устройств: архитектуры в духе MobileNet сокращают вычисления в распространенных слоях зрения, сохраняя полезную точность для мобильных задач. Архитектурные детали приведены в главе «Архитектуры нейронных сетей»; системный вывод здесь в том, что мобильное развертывание часто требует смены семейства модели, а не просто переноса той же модели на телефон. ↩

26. Нейропроцессорный блок (NPU): специализированный аппаратный блок в мобильной системе на кристалле, схемы которого рассчитаны на тензорные операции низкой точности. Такая специализация может повышать энергоэффективность по сравнению с выполнением на CPU, помогая нагрузкам ИИ уложиться в мобильные энергетические бюджеты. ↩

27. Система на кристалле (SoC): мобильные SoC объединяют ядра CPU, GPU и NPU с кешами и контроллерами памяти, чтобы снизить затраты на перемещение данных. Мобильная DRAM обычно вынесена за пределы кристалла, а осуществимый размер модели зависит от емкости, точности, рабочей памяти, пропускной способности и задержки. ↩

28. Face ID: Apple выполняет сопоставление лиц внутри Secure Enclave и шифрует сохраненные математические представления так, что они доступны только этой подсистеме и не покидают устройство (Apple, 2024a; Apple, 2024b). Apple сообщает о случайной вероятности ложного совпадения ниже 1 из 1 000 000 для одного зарегистрированного образа; для некоторых групп и конфигураций вероятность выше. Пример показывает, как локальный вывод и аппаратная изоляция могут сокращать риск передачи, поддерживая аутентификацию с низкой задержкой. ↩

29. Конвейер портретного режима: это не одна модель, а последовательность моделей реального времени для оценки глубины, сегментации и рендеринга. Основная инженерная задача — управлять совокупной задержкой и мощностью конвейера, а не производительностью какой-то отдельной модели. Весь конвейер должен выполняться в пределах воспринимаемой пользователем задержки затвора и делить тепловой бюджет 3–5 Вт, что вынуждает к компромиссам планирования между CPU, GPU и NPU, чтобы избежать троттлинга. ↩

30. Порог 1 мВт: сбор энергии из окружающей среды может питать устройство неограниченно долго, только если долгосрочная собранная мощность превышает среднюю нагрузку всей системы. Доступная мощность зависит от источника и среды: солнечная ячейка размером с ноготь может давать ~10 мВт на улице, но ~10 мкВт в помещении, термоэлектрические генераторы на теплых трубах — ~100 мкВт, а RF-энергия от близких передатчиков — ~10 мкВт. Этот переход может изменить модель развертывания от «ограниченного батареей срока службы» к «развернул и забыл», но зависит от источника, среды и нагрузки. ↩

31. Повсеместные вычисления (ubiquitous computing): видение Марка Вайзера представляло вычисления, вплетенные в повседневную среду, пока они не уходят из прямого внимания (Weiser, 1991). TinyML — один из современных путей к этому видению: когда стоимость и мощность интеллектуального датчика становятся достаточно низкими для массового развертывания, цель оптимизации смещается от производительности (пропускной способности) к мощности (энергии на вывод), то есть к главному компромиссу архетипа «жесткого ограничения». ↩

32. Микроконтроллер (MCU): однокристальный компьютер, конструкция которого ставит минимальную стоимость и мощность выше производительности, что и создает упомянутое «радикальное ограничение». Многие цели TinyML имеют лишь десятки-сотни килобайт встроенной SRAM и не имеют виртуальной памяти; некоторые высокопроизводительные микроконтроллеры могут подключать внешнюю память. Поэтому полная модель, активации и состояние среды выполнения должны помещаться в память, фактически доступную цели, часто на порядки меньшую, чем у смартфона. ↩

33. Энергетический разрыв TinyML: этот разрыв коренится в философии проектирования аппаратуры: облачные GPU оптимизированы для сырой пропускной способности и потребляют сотни ватт, тогда как микроконтроллеры TinyML спроектированы для состояний сна почти с нулевой мощностью. Для обычного облачного вывода один запрос может потреблять около 10 джоулей, тогда как специализированное устройство TinyML — около 10 микроджоулей, разрыв в 1 000 000 раз. Запросы облачных LLM могут увеличить сравнение еще сильнее, как количественно показано в «Энергии на вывод по парадигмам». ↩

34. Питание от батарейки-таблетки: батарейка CR2032 (225 мАч при 3 В, ~675 мВт·ч) в идеале питает полноценную систему мощностью 10–50 мкВт около 1,5–7,7 года. Эта модель «развернул и забыл» стимулирует развитие прерывистых вычислений, при которых устройство спит между выводами, растягивая энергетический бюджет на годы автономной работы. ↩

35. Ограничения обучения на устройстве: полное обучение на устройстве должно сохранять выходы промежуточных слоев, чтобы последующие обновления весов могли вычислить градиенты, поэтому потребляется память, пропорциональная глубине модели. При выводе активации каждого слоя можно отбросить, как только их использует следующий слой. При объеме ОЗУ 256 КБ–2 МБ потребности памяти обратного распространения превышают доступную SRAM; TinyTL замораживает веса и обновляет только смещения, чтобы сократить память активаций (Cai et al., 2020). Это ограничение памяти в основном оставляет устройствам TinyML роль вывода, а обновления модели доставляются через прошивку, а не обучаются на месте. ↩

36. Диапазон устройств TinyML: этот физический диапазон отражает прямой компромисс между контекстом развертывания и вычислительными возможностями. Системы миллиметрового масштаба ставят приоритет минимальной мощности (~140 мкВт) для одной функции и длительной работы, тогда как платы размером с ладонь обменивают больший размер и более высокую мощность на возможность обрабатывать несколько сложных потоков датчиков. Этот выбор совместного проектирования создает разницу в мощности более чем в 10 000 раз и в площади примерно в 100 раз по всему спектру устройств TinyML. ↩

37. Фрагментация экосистемы TinyML: TinyML охватывает семейства микроконтроллеров вроде Arm Cortex-M, RISC-V и Xtensa, каждое с разными наборами инструкций, компоновкой памяти, ядрами и фирменными инструментальными цепочками; облачные и мобильные стеки тоже различаются, но их среды выполнения обычно скрывают больше этого аппаратного разнообразия. Модель, оптимизированная под один микроконтроллер, может потребовать перенастройки и повторной проверки для другого, умножая инженерные затраты на развертывание на многих устройствах. ↩

38. Постоянно включенная детекция слова пробуждения: небольшая специализированная модель слушает акустическую сигнатуру фразы пробуждения и работает как шлюз питания для процессора приложений, потребляющего больше мощности. Допустимый бюджет детектора зависит от платформы, но даже несколько лишних милливатт, потребляемых непрерывно, могут заметно сократить время работы от батареи. Архитектура удается только тогда, когда постоянно работающий путь потребляет значительно меньше средней мощности, чем компоненты, которые он не дает пробуждать. ↩

39. Асимметрия стоимости «обучение — обслуживание»: обучение обычно требует многих прямых и обратных проходов, тогда как один запрос вывода использует обученный артефакт для одного или нескольких прямых проходов. Обучение не является однократным в буквальном смысле, потому что модели могут переобучаться, а стоимость вывода заметно меняется в зависимости от размера модели, длины последовательности, батчирования и накладных расходов сервиса. Экономическое обоснование разделения — амортизация: повторное использование позволяет распределить фиксированную стоимость каждого цикла обучения на множество обслуженных предсказаний. ↩

40. Закон Амдала: сформулирован Амдалом (Amdahl, 1967) для масштабирования многопроцессорных систем; этот принцип напрямую применим к конвейерам развертывания ML, где модель — лишь одна стадия среди многих. В примере с камерой вывод ML составляет 60 мс из 200 мс; даже ускорение модели в 100 раз дает лишь примерно 1,4–2-кратное улучшение сквозной задержки, потому что остальной конвейер не меняется. Команды, которые бенчмаркают задержку модели изолированно, систематически переоценивают выигрыш развертывания. ↩

Рабочий процесс машинного обучения

Назначение

Почему, прежде чем идти по какому-либо одному пути, необходимо увидеть всю карту?

Таксономия D·A·M называет компоненты любой системы ML, а место развертывания определяет физические ограничения, которым должен удовлетворять каждый компонент. Команды часто рассматривают их как отдельные задачи: одна команда собирает данные, другая проектирует модель, третья закупает оборудование. Но самый глубокий урок таксономии в том, что эти компоненты взаимодействуют. Собранные данные ограничивают, какие алгоритмы возможны. Выбранный алгоритм определяет, какое оборудование способно его выполнить. Целевое оборудование меняет то, какие данные можно обработать. Потяните за любую одну нить, и вся система сдвинется. Эти взаимодействия проявляются между компонентами и во времени. Модель, которая хорошо работает при запуске, может деградировать по мере сдвига распределения данных, и тогда нужно разбираться в причинах и, если есть основания, обновлять модель или данные. Оптимизация каждой части в отрыве от остальных именно так и приводит к тому, что команды создают точные модели, которые невозможно развернуть, и эффективные конвейеры, которые подают на вход не те данные. Инженер данных, который видит, как решения по предобработке ограничивают последующие архитектуры, строит иные конвейеры, чем тот, кто воспринимает подготовку данных как изолированную задачу; разработчик модели, который с первого дня знает бюджет памяти целевого устройства, принимает другие архитектурные решения, чем тот, кто гонится за точностью в вакууме. Прежде чем вникать в детали любого отдельного компонента, нужна полная карта того, как ML-система создается, оценивается и поддерживается как единое целое. Рабочий процесс ML приводит эту карту в движение через итеративное D·A·M-совместное проектирование данных, алгоритма и машины, пока возникающие возможности системы не начнут соответствовать требованиям реального мира.

Цели обучения

• Описать шесть этапов жизненного цикла ML как согласованные решения о данных, алгоритме и машине с обратной связью
• Сравнить рабочие процессы ML с традиционным программным обеспечением по признакам дрейфа, недетерминированности и операционной обратной связи
• Проанализировать, как ограничения постановки задачи распространяются через данные, моделирование, валидацию и развертывание
• Рассчитать стоимость интеграции при позднем обнаружении ограничений по принципу распространения ограничений рабочего процесса
• Оценить компромиссы между точностью, эффективностью, воспроизводимостью и готовностью к развертыванию на разных этапах жизненного цикла
• Спроектировать петли обратной связи, которые связывают сигналы мониторинга с переобучением, сопровождением и пересмотренными требованиями

Жизненный цикл ML

Типичный сбой развертывания иллюстрирует опасность несогласованной инженерии. День 1: «Построить диагностическую модель для сельских клиник». День 90: точность 95 процентов на тестовой выборке. День 120: точность 96 процентов после месяца подбора архитектуры. День 150: модель передана инженерам развертывания. День 151: инженеры развертывания сообщают, что модели требуется 4 ГБ памяти. День 152: кто-то проверяет целевое устройство: планшеты в передвижных клиниках с 512 МБ доступной памяти. День 153: пять месяцев работы выброшены.

Точность модели была отличной. Навыки команды в машинном обучении были отличными. Сбой был сбоем рабочего процесса. Ограничение развертывания, которое должно было формировать каждое решение с первого дня, обнаружили только тогда, когда работа была завершена. Ограничение по памяти планшета должно было распространиться назад, на первое совещание по архитектуре, отсекая модели, которые вообще стоило рассматривать. Вместо этого команда оптимизировала каждый компонент в отрыве от остальных (сбор данных, выбор архитектуры, обучение), и проблема интеграции проявилась только при сборке частей вместе. Задокументированное развертывание системы скрининга диабетической ретинопатии (DR) выявило похожие пробелы в рабочем процессе и инфраструктуре.¹

Системы ML объединяют данные, алгоритм и машину в условиях физических ограничений, которые делят развертывание на облачное, периферийное, мобильное и TinyML. Каждое из них накладывает жесткие физические пределы на пропускную способность вычислений, объем памяти и рассеяние тепла. Чтобы соединить эти компоненты в работающую систему, нужно организовать распространение ограничений между данными, алгоритмом и машиной.

Рабочий процесс ML — это инженерная рамка, призванная предотвращать сбои интеграции: она делает ограничения явными на каждом этапе разработки и прослеживает, как они распространяются между данными, алгоритмом и машиной. Здесь проходит переход от исследователя моделей к системному инженеру. Исследователь оптимизирует отдельные элементы: более удачную архитектуру, более чистый набор данных, более быстрый ускоритель. Системный инженер организует эти элементы в производственные системы, которые надежно приносят пользу. Сбой на 153-й день не был вызван изолированным дефектом моделирования, данных или оборудования; он возник из неуправляемого взаимодействия всех трех. Рабочий процесс дает ментальную карту, которая удерживает технические решения связанными с большой системой.

Жизненный цикл машинного обучения — это рамка оркестрации такой работы: структурированный итеративный процесс², который направляет разработку, оценку и улучшение систем ML (Amershi et al., 2019). Формальное определение подчеркивает непрерывное управление, а не однократный выпуск.

Жизненный цикл машинного обучения

Жизненный цикл машинного обучения — это итеративный инженерный процесс создания, развертывания, мониторинга и обновления систем ML, в котором данные с поздних этапов могут возвращаться на ранние, поскольку качество модели может меняться после развертывания.

1. Значение: жизненный цикл — это замкнутая петля, а не линейный конвейер. Расхождение распределений $\mathcal{D}(P_t\Vert P_0)$ между текущим трафиком и трафиком обучения служит сигналом тревоги, повышающим вероятность потери точности; точная зависимость определяется моделью, метками, функцией потерь и распределением при эксплуатации. Полный прогон переобучения требует вычислений стоимостью $O/(R_{\text{peak}}\cdot {\eta }_{\text{hw}})$, тогда как частичные или инкрементальные обновления могут обойтись дешевле. Скорость дрейфа и задержка валидации поэтому превращают сопровождение жизненного цикла в задачу бюджетирования, а не только инженерную задачу.
2. Отличие: в отличие от традиционного ПО, поведение которого меняется при изменении кода, конфигурации, зависимостей или окружения, поведение ML может меняться и тогда, когда меняется сам мир. Точность развернутой модели может снижаться из-за сдвига распределения, даже если код, инфраструктура и конфигурация остаются прежними.
3. Типичная ошибка: частое заблуждение состоит в том, что жизненный цикл заканчивается развертыванием. На самом деле развертывание — это начало петли обратной связи: мониторинг в эксплуатации выявляет дрейф, дрейф запускает расследование, а данные о результатах определяют, должна ли переобученная модель вернуться на этап развертывания.

Здесь жизненный цикл описывает сами этапы, а рабочий процесс — инженерную дисциплину их организации: жизненный цикл — это то, что проходят, рабочий процесс — это то, как управляется прохождение. Это различие требует системного мышления: анализа того, как части системы связаны между собой, а не рассмотрения их изолированно. Закономерности, сформулированные в разделе «Системное мышление» и проиллюстрированные подробным разбором случая, объясняют, почему системам ML нужны интегрированные инженерные подходы, а не последовательная оптимизация компонентов.