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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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