Спонсоров За последние два десятилетия предприятия довели управление центрами обработки данных до уровня искусства. Стандартизация и автоматизация означают повышение эффективности как с точки зрения необработанных вычислений, так и с точки зрения энергопотребления. Такие технологии, как виртуализация и контейнеризация, означают, что пользователи и разработчики могут более эффективно использовать ресурсы, вплоть до возможности самостоятельного развертывания.
Однако архитектуры x86 общего назначения, которые питают современные центры обработки данных, просто не подходят для выполнения рабочих нагрузок AI. Исследователи искусственного интеллекта обошли эту проблему, перепрофилировав технологию графического процессора для ускорения операций искусственного интеллекта, и именно это привело к головокружительным инновациям в машинном обучении за последнее десятилетие.
Однако это представляет проблему для предприятий, которые хотят выполнять рабочие нагрузки ИИ. Как правило, подход «центральный процессор плюс ускоритель» означал покупку одного блока, который объединяет графические процессоры и вычислительные ресурсы на базе x86. Это может вызвать тревогу у команд, занимающихся инфраструктурой предприятия. Хотя такие системы теоретически могут быть подключены и работать, они могут занимать много места в стойке и могут предъявлять другие требования к питанию и охлаждению по сравнению с обычными вычислительными системами. Они также могут быть негибкими, с фиксированным соотношением вычислительных ресурсов и графического ускорителя, что ограничивает гибкость при совмещении нескольких рабочих нагрузок с различными требованиями к вычислительным ресурсам хоста.
По мере того как исследователи и специалисты по обработке данных работают с все более крупными моделями и наборами данных - теперь мы в безопасности в диапазоне параметров, превышающем триллион с лишним, - сохранение темпа за счет увеличения мощности ИИ становится вопросом покупки еще одной новой системы. Потом еще один. И другой. Но это мало что делает для устранения дисбаланса между вычислительными ресурсами хоста и ускорением ИИ.
А остальная часть вашего хорошо настроенного центра обработки данных? Что ж, вы не можете эффективно использовать его, когда все рабочие облака ИИ находятся в изолированном месте. Это заставляет опытных ИТ-директоров и менеджеров инфраструктуры по понятным причинам нервничать в связи с перспективой превращения узкоспециализированных, ориентированных на ИИ комплектов в разрозненные хранилища ресурсов на их глазах.
Распаковка AI
Таким образом, хотя Ола Тёрудбаккен, старший вице-президент по системам в Graphcore, говорит, что ИИ, или машинный интеллект, неизбежно станет четвертой опорой центра обработки данных наряду с (традиционными) вычислениями, сетями и хранилищами, он также говорит, что это не должно быть черным. коробчатые системы.
Британский производитель систем искусственного интеллекта утверждает, что мощь искусственного интеллекта необходимо отделить от вычислительных ресурсов хоста и упаковать в форме, которая не только легко вписывается в современные центры обработки данных, но и в полной мере использует их преимущества.
Именно здесь на сцену выходит семейство систем IPU-POD. IPU-POD - это семейство конфигураций системы, основанное на IPU-M2000, блейд-сервере высотой 1U, обеспечивающем 1 петафлоп вычислительных ресурсов ИИ. Каждая машина содержит четыре блока обработки GC200, Mk2 Colossus Intelligence или IPU, каждый из которых имеет 1472 независимых ядра или плитки, каждый из которых может запускать шесть параллельных потоков и которые совместно используют 900 МБ внутренней памяти на одном кристалле.
Отправной точкой для ИТ-директора / технического директора, желающего оснастить свой центр обработки данных вычислительными ресурсами ИИ, которые лучше подходят для работы их центра обработки данных, являются IPU-POD16 и IPU-POD64.
IPU-POD64 состоит из шестнадцати IPU-M2000, коммутаторов данных и управления, а также на выбор 1 или 4 хост-сервера, которые дезагрегированы. Он обеспечивает вычислительную мощность 16 петафлопс в формате FP16.16 и занимает примерно 20RU места в стойке, распределенных по одной или нескольким стойкам, в зависимости от распределения серверов. IPU-POD16 - это более вводный продукт для тех, кто хочет изучить эту технологию и начать свой путь к инновациям. IPU-POD16 поставляется в двух вариантах: прямое подключение, которое представляет собой предварительно настроенную систему plug-and-play, и альтернативу, в которой используются переключатели. Оба варианта используют один хост-сервер и обеспечивают вычислительную мощность 4 петафлопс FP16.16.
Масштабирование встроено в каждый IPU-M2000 с помощью собственной микросхемы шлюза, разработанной Graphcore. Это устройство поддерживает связь со скоростью 100 Гбит / с в каждом направлении по бокам от соседних стоек IPU-POD. В рамках межсоединения IPU-Fabric эти соединения могут быть прямыми или через коммутаторы для дополнительной гибкости и предотвращения аварийного переключения. Основой для горизонтального масштабирования является IPU Fabric от Graphcore с общей пропускной способностью 2.8 Тбит / с. Шестнадцать M2000 масштабируются в стойке, образуя IPU-POD64. Для межстоечной связи IPU Fabric можно настроить в коммутируемой топологии «тор» для поддержки тысяч IPU и до 3 IPU-M1024, создавая массивно-параллельную систему, обеспечивающую 2000 экзафлопс вычислений.
Такой дезагрегированный подход играет на пользу стремлению как гипермасштабируемых компаний, так и предприятий минимизировать количество серверных SKU, которые им необходимо поддерживать. «Системы Graphcore эффективно подключены к сети», - говорит Тёрудбаккен. Клиенты просто устанавливают программное обеспечение Graphcore Poplar, которое поддерживает стандартные отраслевые структуры машинного обучения, на свои предпочтительные серверы, чтобы обеспечить вычислительные ресурсы хоста для системы на основе IPU. Важно отметить, что емкость сервера можно увеличивать или уменьшать постепенно, в зависимости от рассматриваемой рабочей нагрузки ИИ. Таким образом, в то время как рабочие нагрузки типа NLP обычно требуют более низкого соотношения вычислительных ресурсов хоста и операций ввода-вывода, рабочие нагрузки компьютерного зрения обычно создают более высокие нагрузки на хост.
По словам Тёрудбаккена, дезагрегация также имеет преимущества с точки зрения отказоустойчивости. «Если у вас произошел сбой - а серверы действительно выходят из строя, верно - вы можете воспользоваться стандартными протоколами аварийного переключения, предоставляемыми сетевым стеком. Итак, если сервер или виртуальная машина выйдет из строя, вы можете перенести их на другой, на резервный сервер или резервную виртуальную машину ».
IPU Fabric разработана для поддержки скомпилированных коммуникаций и крупномасштабных. Когда специалисты по обработке данных компилируют свой код с помощью Poplar, их модель отображается в системе IPU-POD как непрерывный ресурс IPU, по сути, как если бы это был один гигантский IPU, вплоть до отдельных ядер на процессорах, создавая оптимальный шаблон связи для поддержки доступная модель машинного обучения, будь то на одном IPU или с масштабированием до 1000. Результатом, по словам Graphcore, является детерминированная связь без джиттера, даже если система масштабируется до огромной степени.
Но, по словам Тёрудбаккена, пользователь «на самом деле не особо заботится об оборудовании или системах - им в основном нужна очень масштабируемая платформа, на которой они могут запускать свой код».
Что касается того, насколько быстро работает этот код, последние тесты Graphcore показали, что время обучения на BERT-Large может быть сокращено более чем вдвое с использованием системы IPU-POD по сравнению с системой на базе графического процессора DGX A100, с более чем в три раза большей пропускной способностью для вывода при самая низкая задержка. При работе с рабочей нагрузкой цепи Маркова методом Монте-Карло IPU-M2000 провел обучение менее чем за три часа по сравнению с 48 часами для графического процессора A100.
Улучшения еще более заметны с более современными моделями. IPU-M2000 обеспечил десятикратное увеличение пропускной способности обучения на EfficientNet-B4 и в 18 раз при оптимизированной конфигурации IPU. Таким образом, IPU-M2000 обеспечил 60-кратное увеличение пропускной способности и 16-кратное сокращение задержки по сравнению с системой с графическим процессором. Это, несомненно, порадует специалистов по данным, но у их коллег по инфраструктуре могут быть гораздо более прозаические опасения, начиная с таких вопросов, как «оптимально ли работает система и может ли она выйти из строя?» Системы IPU-POD полностью поддерживаются программным пакетом управления, обеспечивающим управление системами и наблюдение.
Состоящие из стандартных корпоративных инструментов с открытым исходным кодом, таких как OpenBMC, RedFish DTMF, Prometheus и Grafana, они снабжены хорошо документированными открытыми API-интерфейсами для интеграции систем управления. предупреждение об этом на раннем этапе », - говорит Тёрудбаккен. «Итак, вы можете отправить сотрудника службы поддержки для его замены или, если у вас есть модуль DIMM, который вот-вот выйдет из строя, то же самое».
Команды, занимающиеся инфраструктурой, также будут очень обеспокоены тем, что они получают максимальную отдачу от своих инвестиций в свое оборудование для искусственного интеллекта, что означает, что оно поддерживает как можно больше рабочих нагрузок, рабочих мест и команд.
А я для кого?
Хотя архитектуру IPU-POD можно масштабировать до десятков тысяч IPU, создавая заманчивую основу для аналитиков данных, на которых они могут запускать свои модели, как говорит Тёрудбаккен, в реальности будет немного случаев, когда один пользователь берет на себя все вычислительная мощность ИИ: «Обычно у вас будет несколько пользователей, и у вас будет несколько клиентов, которые просто используют систему». Это означает, что необходимо надежное управление ресурсами. Программный стек Graphcore позволяет создавать «виртуальные IPU» и «что позволяет нам в основном разделить модуль на несколько виртуальных модулей, которые полностью изолированы. IPU или система в одном виртуальном модуле не может взаимодействовать с любым другим IPU в соседнем модуле ».
Это связано с поддержкой стандартных отраслевых инструментов оркестровки, таких как SLURM и Kubernetes, так что виртуальные машины или контейнеры, работающие на хосте, могут быть связаны с VPOD в системе IPU. Как говорит Тёрудбаккен, независимо от того, разговаривает ли он на гипермасштабируемом уровне или на отдельной стойке, в то время как специалист по анализу данных сосредоточен на том, чтобы иметь как можно больше возможностей для запуска модели, их менеджер или компания захотят получить некоторую уверенность в том, что «этот ресурс мой и только мой. . »
Это оправдывает ожидание, что многие организации могут получить свой первый опыт работы с IPU через гипермасштабирование или собственные облачные сервисы Graphcore, Graphcloud, которые были запущены в январе. Тем не менее, Тёрудбаккен ожидает, что многие в конечном итоге захотят использовать машинный интеллект локально именно по причинам конфиденциальности, секретности и задержек. При этом они будут работать с некоторыми очень традиционными уравнениями относительно общей стоимости владения. Один из возможных вопросов, по его словам, заключается в следующем: «Сколько энергии вы фактически потребляете, чтобы выполнить, скажем, задание BERT? В течение года? Если посмотреть как на уровне коробки, так и на уровне системы, решение выглядит очень привлекательно ».
С точки зрения капиталовложений уравнение еще более простое. «Единственный новый компонент, который им действительно нужно добавить к этому, - это система IPU-POD на базе IPU-M2000. Остальное - сеть и хранилище - это то, что у многих людей уже есть ».
И это, возможно, настолько беспроблемно, насколько это возможно при внедрении машинного интеллекта в свой центр обработки данных.
При поддержке Graphcore
