Почему вывод AI, а не обучение, является следующим великим инженерным вызовом

В течение прошлого десятилетия основное внимание в области искусственного интеллекта было сосредоточено на обучении. Прорывы в основном были достигнуты благодаря массивным кластерам вычислений, моделям с триллионами параметров и миллиардам долларов, потраченных на обучение систем “думать”. Мы рассматривали разработку ИИ в основном как строительный проект: строительство небоскрёба интеллекта. Но теперь, когда этот небоскрёб уже построен, настоящий вызов заключается в том, чтобы обеспечить возможность миллионам людей жить и работать внутри него одновременно. Это смещает фокус исследователей и инженеров ИИ с обучения (акта создания интеллекта) на вывод (акт использования его). Хотя обучение является массивными, разовыми капитальными затратами (CapEx), вывод представляет собой непрерывные операционные расходы (OpEx), которые продолжаются бесконечно. Когда предприятия развертывают агентов, обслуживающих миллионы пользователей круглосуточно, они обнаруживают суровую реальность: вывод не является просто “обратным обучением”. Это фундаментально другая, и, возможно, более сложная, инженерная задача.

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

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

Для инженеров это смещает цели. Мы больше не оптимизируем пропускную способность (как быстро можно обработать этот массивный набор данных?). Мы оптимизируем задержку (как быстро можно вернуть один токен?) и параллелизм (сколько пользователей можно обслужить на одном GPU?). “Брутфорс”-подход, который доминировал на этапе обучения, просто добавляя больше вычислительных ресурсов, не работает здесь. Вы не можете бросить больше H100 на проблему задержки, если узким местом является пропускная способность памяти.

Стена памяти: настоящее узкое место

Малознакомая правда о выводе Большой Языковой Модели (LLM) заключается в том, что он редко ограничивается вычислениями; он ограничен памятью. На этапе обучения мы обрабатываем данные в массивных партиях, держа вычислительные блоки GPU полностью загруженными. В выводе, особенно для реальных приложений, таких как чат-боты или агенты, запросы поступают последовательно. Каждый сгенерированный токен требует от модели загрузить свои миллиарды параметров из памяти с высокой пропускной способностью (HBM) в вычислительные ядра. Это “Стена памяти“. Это как иметь двигатель Ferrari (ядро GPU) застрявшим в пробке (ограниченную пропускную способность памяти).

Этот вызов заставляет инженерные команды пересмотреть архитектуру системы до уровня кремния. Это причина, по которой мы наблюдаем рост Линейных Процессорных Единиц (LPUs), таких как те, что от Groq, и специализированных Нейронных Процессорных Единиц (NPUs). Эти чипы предназначены для обхода узкого места HBM, используя массивные объемы SRAM на чипе, рассматривая доступ к памяти как непрерывный поток данных, а не простую операцию извлечения. Для программиста это сигнализирует о конце эры “по умолчанию CUDA”. Мы должны теперь писать код, который осознает аппаратуру, понимая точно, как данные перемещаются по проводам.

Новая граница эффективности ИИ

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

• Непрерывная партионная обработка: Традиционная партионная обработка ждет, пока “автобус” заполнится, прежде чем отправиться, что вводит задержки. Непрерывная партионная обработка (пIONированная фреймворками, такими как vLLM) действует как система метро, позволяя новым запросам присоединиться или покинуть поезд GPU на каждой итерации. Она максимизирует пропускную способность, не жертвуя задержкой, решая сложную задачу планирования, которая требует глубоких знаний ОС.

• Спекулятивное декодирование: Эта техника использует небольшую, быструю и недорогую модель для создания черновика ответа, в то время как более крупная, медленная и более мощная модель проверяет его параллельно. Она основана на факте, что проверка текста намного менее вычислительно дорогая, чем его генерация.
• Управление кэшем KV: В длинных разговорах “история” (кэш Key-Value) быстро растет, потребляя большие объемы памяти GPU. Инженеры теперь реализуют ” PagedAttention“, технику, вдохновленную виртуальной памятью в операционных системах. Эта техника разбивает память на фрагменты и управляет ею не连续но.

Агентная сложность

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

1. Управление состоянием: Движок вывода должен поддерживать “состояние” процесса мышления агента на нескольких шагах, часто охватывающих минуты.
2. Бесконечные циклы: В отличие от предсказуемой прямой передачи, агент может застрять в цикле рассуждений. Инженерия надежных “сторожевых” и “предохранителей” для вероятностного кода является совершенно новой областью.
3. Переменный вычислительный объем: Один запрос пользователя может вызвать один вызов вывода, в то время как другой может вызвать пятьдесят. Управление нагрузкой и автоматическое масштабирование инфраструктуры, когда каждый запрос несет такую экстремальную дисперсию, требует совершенно новой классификации логических операций.

Мы по сути переходим от “обслуживания моделей” к “оркестровке когнитивных архитектур”.

Привнесение ИИ в повседневные устройства

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

Техники, такие как квантование (уменьшение точности с 16-битной до 4-битной или даже 1-битной) и дистилляция моделей (обучение небольшой модели-студента имитировать большую модель-учителя), становятся стандартной практикой. Но настоящий вызов заключается в развертывании этих моделей в фрагментированную экосистему миллиардов устройств, таких как Android, iOS, встроенный Linux, пользовательские датчики, каждое со своими аппаратными ограничениями. Это “кошмар фрагментации” разработки для мобильных устройств, умноженный на сложность нейронных сетей.

Итог

Мы вступаем в эру “День 2” Генеративного ИИ. День 1 был о том, чтобы продемонстрировать, что ИИ может писать стихи. День 2 – об инженерии, делая эту способность более надежной, доступной и повсеместной. Инженеры, которые определят следующее десятилетие, не обязательно являются теми, кто изобретает новые архитектуры моделей. Они являются системными инженерами, хакерами ядра и архитекторами инфраструктуры, которые могут выяснить, как обслужить миллиард токенов в секунду, не расплавляя сеть электропитания или не обанкротив компанию. Вывод ИИ больше не является просто деталью запуска. Это продукт. А оптимизация его является следующим великим инженерным вызовом.