В Inflection AI мы недавно внесли значительный вклад в нашу инфраструктуру: мы перенесли наш стек вывода LLM из графических процессоров NVIDIA на акселераторы Intel Gaudi. Причинами смены являются те, с которыми почти каждое предприятие также сталкивается сегодня: нехватка поставки графических процессоров, рост цен и негибкие долгосрочные аренды означали, что построение на оборудовании NVIDIA может ограничить наши способности-и способность наших клиентов-масштабировать.
Было ясно, что нам нужен был более гибкий стек. При оценке вариантов Intel поднялась на вершину списка, поскольку он уже имеет наибольшую площадь для корпоративного оборудования во всем мире. Это означало, что если бы мы могли достичь паритета производительности на аппаратном обеспечении Intel, предприятия могли бы использовать свои существующие инвестиции в центр обработки данных для развертывания ИИ, а не соперничать на доступ к графическим процессорам NVIDIA.
Путешествие было нелегко, заняв несколько недель, и много переписываний ядра, но в конечном итоге нам удалось адаптировать и оптимизировать нашу среду выполнения вывода для достижения почти неэффективного паритета. Решая эти проблемы, мы усвоили несколько уроков, которые, по нашему мнению, широко применимы к тому, что кто -либо создает более гибкие, эффективные системы вывода.
Решение неподдерживаемой операции
Картирование архитектуры искусственного интеллекта с базовым аппаратным обеспечением ускорителя является ключом к достижению эффективных и масштабируемых рабочих нагрузок ИИ. При переезде в Гауди мы обнаружили, что полный диапазон операций Pytorch (которые сегодня превышают 2000 операций) не был полностью поддержан Synapseai, бэкэнд, который поддерживает стек ускорителя Intel. В частности, такие операции, как Pythonic (Numpy-подобная) нарезка тензора и более неясные, такие как Torch.triu_indices, не были поддержаны.
В некоторых случаях неподдерживаемые OPS вызвали сегфалты. В других Pytorch вернулся к выполнению ЦП, который вводил большие штрафы на производительность из -за передачи данных между ЦП и ГП.
Чтобы решить эти проблемы, мы переписываем неподдерживаемые или проблематичные OPS, которые одни только дали почти 15 -кратное улучшение производительности и устраняли Segfaults.
Желание против ленивого исполнения
Ленивая нагрузка и нетерпеливая дихотомия нагрузки обнаружена во многих областях вычислений, а многие программные и аппаратные стеки AI пытаются поддержать оба. Ради простоты, мы сначала попытались запустить нашу модель в режиме поджога по умолчанию Pytorch. В то время как выходы были точными, задержка была значительно выше, чем у Nvidia из-за выполнения операции «один на один».
Тем не менее, переход на ленивый режим Гауди привел к еще худшей производительности, с выполнением в два раза медленно. Динамические операции, такие как данные, зависящие от данных, и формы ввода переменных, разбивали график, вводя накладные расходы хоста от повторных операций и генерируя новые графики.
К счастью, мы увидели путь вперед, чтобы решить проблемы, с которыми мы столкнулись в ленивом режиме. Решение этой проблемы включало выявление и удаление каждой динамической операции, вызывая разрывы графика в нашем прямом проходе, а затем интеграция графиков HPU. Графики HPU аналогичны графам CUDA, поскольку они позволяют записывать и воспроизводить графики вычислений непосредственно на HPU без участия хоста. Поскольку эти абстракции работают на фиксированных формах входных тензоров, мы использовали стратегию ведения с заполнением для переменных входных форм тензора, чтобы соответствовать формам наших графиков кэшированного HPU.
Благодаря этой оптимизации мы достигли 4 -кратного ускорения, которое соперничало с производительностью нашей модели на Nvidia Adware.
Совершенствование с профилировщиками
Хотя эти модели оптимизации обеспечивали значительные улучшения, мы надеялись достичь большего. Чтобы полностью оптимизировать производительность, мы использовали стек Profiler на основе факелов Habana, чтобы получить видимость в том, как аппаратное обеспечение Gaudi используется в двух основных вычислительных двигателях: MME для операций GEMM и TPC для операций по элементам. Чтобы полностью использовать аппаратное обеспечение, оба должны были оставаться занятыми.
Первоначально наш механизм внимания работал как единое ядро, поэтому мы работали с командой Intel Habana, чтобы разделить блок внимания. В то время как MME обрабатывал умножения матрицы одного слоя, TPC может одновременно начать работать над следующим. Это был деликатный процесс из -за осложнений с увеличением накладных расходов памяти, но разблокировка параллелизма данных позволило нам подойти к теоретической максимальной пропускной способности ускорителя. В сочетании с оптимизацией модели наши методы теперь масштабируются с размерами модели от 1б до более 100b+ параметров.
Гибкая архитектура на будущее
Тяжелая работа, которая вошла в этот порт, имеет последствия далеко за пределами простого использования Гауди. Образцы проектирования аппаратного обеспечения, как правило, повторяются по разным ускорителям, что означает, что полученные идеи дадут нам преимущество в создании любой новой архитектуры в будущем.
Благодаря быстро развивающемуся аппаратному ландшафту ИИ компании не должны предполагать, что nvidia является единственным жизнеспособным вариантом. Для нас Гауди был первым реальным испытанием этой гипотезы, и это доказало, что с правильным пониманием архитектуры, производительности и гибкости не должно быть противоречия.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Рагхав Гарг является членом технического персонала AI Inflage AI, работая в основном над оптимизацией выводов и развертыванием. Рагхав возглавил усилия команды, чтобы перенести свой стек вывода LLM в акселератор Intel Gaudi. Рагхав имеет BS и MS на компьютере … Подробнее от Рагхава Гарга
