RU2818034C1 - Способ и система запуска приложений в симулируемой среде - Google Patents

Abstract

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

Description

ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

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

-доступность полного количества вычислительных ресурсов на этапе отладки ограничена.

- обучение современных нейросетей, в частности больших языковых моделей требует огромных ресурсов. Нейросеть GPT-3, представитель класса больших нейронных сетей, имеет 175 миллиардов параметров. Ее обучение потребовало вычислений на 1024 видеокартах NVIDIA TESLA А100 в течении 34 дней, последующие модели будут требовать еще больше ресурсов. Сборка и настройка кластера такого размера занимает значительное время, возможность отлаживать приложение до ее завершения будет полезна.

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

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

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

[003] Также интерес представляет задача по оптимизации набора аппаратуры кластера под конкретный класс приложений, с учетом пропускной способности и задержек каналов связи, их топологии и конфигурации.

[004] Модельный кластер

Стандартный способ, используемый как в научных статьях, так и на практике -запуск реального приложения на небольшом вычислительном кластере со всеми необходимыми аппаратными ресурсами (CPU, GPU, RAM). Это позволяет оценить как нагрузку на сеть, так и ожидаемое время вычисления.

[005] Однако, такой подход сталкивается с некоторыми ограничениями:

- требуется доступ к необходимому для хранения нейросети количеству видеокарт на протяжении всего тестирования. Например, для обучения описанной ранее нейросети GPT3 требуется не менее 40 видеокарт NVIDIA А100, что накладывает ограничение на минимальный размер кластера.

- различия в поведении библиотек при разном количестве GPU. В частности, популярная библиотека DeepSpeed в режиме ZeRO равномерно распределяет некоторые параметры нейросетей по всем GPU, а значит потребление видеопамяти и объем передачи данных по сети будут отличаться от полноразмерного запуска.

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

[006] Из уровня техники известны способы и системы, связанные с автономным определением области действия облачных узлов для сценариев использования машинного обучения больших данных, раскрытые в заявке US 20210174248 A1, опубл. 21.06.2022, которые могут быть рассмотрены в качестве наиболее близкого аналога к представленному техническому решению. В частности, в данном документе раскрываются автоматизированный инструмент, способ и система определения области применения, которые для каждой из нескольких комбинаций значений параметров (i) устанавливают комбинацию значений параметров, описывающих сценарий использования, (ii) выполняют приложение машинного обучения в соответствии с комбинацией значений параметров в целевой облачной среде и (iii) измеряют вычислительные затраты на выполнение приложения машинного обучения. Рекомендация относительно конфигурации центрального процессора, графического процессора и памяти для целевой облачной среды для выполнения приложения машинного обучения генерируется на основе измеренных вычислительных затрат.

[007] Также в качестве наиболее близкого аналога могут быть рассмотрены способы отделения задач конвейерной передачи данных от потока выполнения высокопроизводительной вычислительной задачи (например, распределенного глубокого обучения модели) в распределенной вычислительной системе, раскрытые в заявке US 20200174840 A1, опубл. 04.06.2020. Известный способ включает в себя этапы получения клиентского запроса на подготовку ресурсов для выполнения вычислительного задания, подготовки ресурсов ускорителя одного или нескольких серверных узлов ускорителя в распределенной вычислительной системе для выполнения задач, связанных с потоком выполнения вычислительного задания, и подготовки логических узлов в распределенной вычислительной системе для создания конвейера потока данных, который сконфигурирован для выполнения операций потока данных, связанных с вычислительным заданием для предоставления данных в подготовленные ресурсы ускорителя для выполнения задач, связанных с потоком выполнения вычислительного задания. Операции потока данных включают, например, операции ввода/вывода хранилища данных, операции предварительной обработки данных и промежуточные операции данных, которые отделены от потока выполнения вычислительного задания. [008] Недостатком известных решений является то, что они требуют наличия всех необходимых для запуска приложения вычислительных ресурсов.

СУЩНОСТЬ ТЕХНИЧЕСКОГО РЕШЕНИЯ

[009] Технической проблемой или задачей, поставленной в данном техническом решении, является создание простого и надежного способа и устройства запуска приложений в симулируемой среде.

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

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

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

- на основе конфигурации BP разворачивают компоненты, симулирующие BP;

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

- размещают конфигурации BP и приложение по меньшей мере в одной изолированной среде;

- осуществляют выполнение программного кода по меньшей мере в одной изолированной среде в соответствии с конфигурацией BP;

- посредством подменных библиотек перенаправляют запросы, адресованные BP, к компонентам, симулирующие BP;

- генерируют ответы на упомянутые запросы, адресованные BP, посредством их обработки компонентами, симулирующими BP;

- возвращают сгенерированные ответы на упомянутые запросы по меньшей мере в одну изолированную среду;

- завершают выполнение программного кода в изолированной среде.

[0012] В одном из частных примеров осуществления способа конфигурации BP содержат:

- описание моделей видеокарт, представленное в виде набора параметров;

- описание моделей сетевых карт, представленное в виде набора параметров;

- информацию о количестве симулируемых серверов и набор параметров для каждого симулируемого сервера;

- параметры сетевых соединений;

- приложение для запуска.

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

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

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

[0016] В другом частном примере осуществления способа полученные запросы и состояние симулируемых BP регистрируются журнале.

[0017] В другом частном примере осуществления способа дополнительно выполняют этап обновления состояния симулируемых BP после генерации ответа на упомянутые запросы, адресованные BP.

[0018] В другом частном примере осуществления способа дополнительно выполняют этапы, на которых:

- разворачивают сервер RPC;

- размещают адрес сервера RPC по меньшей мере в одной изолированной среде;

причем упомянутое перенаправление запросов и сгенерированных ответов выполняется с использованием сервера RPC.

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0020] Признаки и преимущества настоящего изобретения станут очевидными из приводимого ниже подробного описания изобретения и прилагаемых чертежей, на которых:

На Фиг. 1 представлен пример реализации системы обработки информации.

На Фиг. 2 представлен пример общего вида вычислительного устройства.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

[0021] Ниже будут описаны понятия и термины, необходимые для понимания данного технического решения.

[0022] В данном техническом решении под системой подразумевается, в том числе компьютерная система, ЭВМ (электронно-вычислительная машина), ЧПУ (числовое программное управление), ПЛК (программируемый логический контроллер), компьютеризированные системы управления и любые другие устройства, способные выполнять заданную, четко определенную последовательность операций (действий, инструкций).

[0023] Под устройством обработки команд подразумевается электронный блок либо интегральная схема (микропроцессор), исполняющая машинные инструкции (программы).

[0024] Устройство обработки команд считывает и выполняет машинные инструкции (программы) с одного или более устройств хранения данных. В роли устройства хранения данных могут выступать, но не ограничиваясь, жесткие диски (HDD), флеш-память, ПЗУ (постоянное запоминающее устройство), твердотельные накопители (SSD), оптические приводы.

[0025] Программа - последовательность инструкций, предназначенных для исполнения устройством управления вычислительной машины или устройством обработки команд.

[0026] Сигнал - материальное воплощение сообщения для использования при передаче, переработке и хранении информации.

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

[0028] В соответствии со схемой, приведенной на фиг.1, система обработки информации 100 содержит соединенные каналами связи менеджер 10 платформы, устройство 20 пользователя, по меньшей мере один сервер 30 исполнения изолированных сред и по меньшей мере один сервер 40 симулятора. Каналы связи могут быть реализованы на базе широко известных технологий проводной и беспроводной связи для обеспечения обмена данными, причем передача данных по упомянутым каналам осуществляет посредством сигналов, для обработки которых элементы системы 100, отправляющие или принимающие данные, оснащаются средствами преобразования сигналов, например, ЦПА, АЦП и пр.

[0029] Менеджер 10 платформы может быть реализован на базе широко известных вычислительных устройств и оснащен: модулем 11 управления серверами, модулем 12 сбора данных и по меньшей одним интерфейсом связи (13 или 14). Указанные модули могут быть, например, реализованы на базе логических элементов на транзисторах, размещенные на единой печатной плате.

[0030] Менеджер 10 контролирует работу серверов 30 и 40, отвечая за инициализацию, конфигурацию и завершение работы. Именно с менеджером 10 взаимодействует устройство 20 пользователя. В качестве основного интерфейса связи с устройством 20 может быть использован консольный интерфейс 13. В качестве альтернативного интерфейса может быть использован программный интерфейс 14 для языка Python, который предоставляет ограниченные возможности для конфигурации, однако может быть более удобен некоторым пользователям. Также данный интерфейс 14 позволяет создавать конфигурационные файлы более простым способом, чем с использованием генератора конфигураций или ручного написания благодаря краткости описания и автоматическому управлению конфигурационным файлом.

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

[0032] Сервер 30 может быть реализован на базе широко известных вычислительных устройств и оснащен: по меньшей мере одной изолированной средой (31, 32 или 33) и модулем 34 обмена данными. Указанные элементы сервера 30 могут быть, например, реализованы на базе логических элементов на транзисторах, размещенных на единой печатной плате. Функция изоляции среды может быть реализована посредством одной из широко известных технологий, такой как виртуальные машины или контейнеры, или же достигаться за счет использования в качестве модулей 31-33 дифференцированных вычислительных устройств, соединенными с модулем 34 обмена данными, при этом устройства 31-34 в свою очередь могут быть реализованы известными методами на базе логических элементов.

[0033] Сервер 40 может быть реализован на базе широко известных вычислительных устройств и оснащен: модулем 41 приема удаленных вызовов (RPC), модулем 42 симуляции компонентов, модуль 43 запуска, модуль 44 управления журналом и модуль 45 хранения данных. Указанные элементы сервера 40 могут быть, например, реализованы на базе логических элементов на транзисторах, размещенных на единой печатной плате.

[0034] На первом этапе пользователь устройства 20 формирует запрос на запуск приложения, содержащий конфигурации вычислительных ресурсов (BP), требуемых для запуска приложения. Например, пользователем может быть сформирован запрос на запуск программного кода, предназначенного для обучения нейросети GPT3 при помощи фреймворка Megatron LM, исполняемого с использованием 16 вычислительных устройств, оснащенных 4 видеоускорителями каждое.

[0035] Сформированный запрос на запуск приложения далее по команде пользователя передается от устройства 20 в адрес менеджера 10 и посредством по меньшей мере одного интерфейса 13 или 14 поступает в модуль 12 сбора данных. Конфигурации BP могут, например, содержать:

- описание моделей видеокарт, представленное в виде набора параметров, причем каждый параметр характеризует модель видеокарты, объем памяти и параметры, которые CUDA API может запросить у видеокарты. Например, набор параметров может содержать следующие данные: видеокарта Nvidia А100, содержит 80 ГБ видеопамяти, параметр compute capability равен 8.6;

- описание моделей сетевых карт, представленное в виде набора параметров. Среди параметров встречаются количество портов, допустимая скорость передачи. К примеру, набор параметров может содержать следующие данные: Mellanox ConnectX-6 имеет 2 порта и поддерживает связь на скорости 200 Гбит/с;

- информацию о количестве симулируемых серверов и набор параметров для каждого симулируемого сервера, причем каждый симулируемый сервер требует запуска одной изолированной среды, в которой будет размещен и запущен один экземпляр приложения. Среди параметров указываются ID сервера, количество и модели подключенных видеокарт и сетевых карт, топология соединений внутри сервера и пропускные способности этих соединений. К примеру, набор параметров может содержать следующие данные: кластер содержит 8 серверов, каждый из которых содержит 4 видеокарты А100 и 2 сетевых карты Mellanox ConnectX-6, видеокарты подключены к NVLink Switch при помощи технологии NVLink, с пропускной способностью 450 ГБ/с, также каждая видеокарта и сетевая карта соединена с процессором при помощи технологии PCIe 4.0 с пропускной способностью 31.5 ГБ/с;

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

- приложение для запуска, например, представленное в виде программного кода или ссылки на образ контейнера с приложением.

[0036] Далее модуль 11 управления серверами извлекает из модуля 12 конфигурации BP и направляет их вместе с командой на развертывание компонентов, симулирующих BP, по меньшей мере одному серверу 40 симулятора (в зависимости от конфигурации BP), которые поступают в модуль 43 запуска. В соответствии с поступившей командой модуль 43 осуществляет разворачивание известными методами на модуле 41 сервера RPC и компонентов в модуле 42, симулирующих BP. После того, как упомянутый сервер RPC и компоненты были развернуты, модуль 43 направляет адрес сервера RPC в модуль 11.

[0037] Далее менеджер 1 переходит к этапу разворачивания симулируемых серверов. В частности, модуль 11 направляет команду всем экземплярам сервера 30 исполнения изолированных сред для разворачивания симулируемых серверов в соответствии с конфигурацией BP (набором параметров для каждого симулируемого сервера) на упомянутом сервере 30, причем каждому симулируемому серверу соответствует изолированная среда (на Фиг. 1 отображен вариант с 3 симулируемыми средами: 31, 32 и 33), в которой размещены подменные библиотеки, например, экосистемы CUDA, предназначенные для передачи команд, адресованных BP, к симулируемым BP, посредством отправки запросов на сервер RPC. Каждая изолированная среда отделена от других компонентов сервера средствами изоляции, используемыми в инфраструктуре, и взаимодействует с другими изолированными средами посредством модуля 34 обмена данными. Изоляция может быть достигнута, к примеру, с использованием технологии docker. В таком случае, упомянутый модуль 34 может быть выполнен на базе средств docker bridge или иной виртуальной сети.

[0038] После того, как запрошенное пользователем количество симулируемых серверов оказывается развернуто, модуль 11 имеет информацию об адресах сервера RPC и всех изолированных сред. Модуль 11 направляет по меньшей мере одному серверу 30 исполнения изолированных сред конфигурации BP, приложение и адреса сервера RPC и всех изолированных сред. Полученные данные размещаются сервером 30 по меньшей мере в одной в оной изолированной среде и в частном случае размещаются в каждой изолированной среде (31, 32 и 33).

[0039] Далее модуль 11 направляет серверу 30 команду на запуск копий приложения в изолированных средах и сервер 30 осуществляет запуск приложения в изолированных средах посредством запуска (выполнения) программного кода в соответствии с конфигурацией BP. В случае, если программный код, исполняемый в среде (к примеру, 31), предписывает серверу 30 задействовать сетевые ресурсы с использованием функционала операционной системы для передачи пакетов данных экземпляру приложения, размещенному в другой среде (к примеру, 32), то сервер 30 использует модуль 34 обмена данными, реализующий функции виртуальной сети для передачи упомянутых пакетов данных из среды 31 в среду 32. Например, если сервер 30 размещен в кластере Kuberneties, использующем Docker для контейнеризации, то модуль 34 может быть реализован на базе Docker Bridge.

[0040] В случае, если программный код, исполняемый в среде 31, предписывает серверу 30 задействовать BP (например, предписывает выделить память с использованием CUDA Runtime, выполнить перемножение матриц с использованием CuBLAS, или произвести обмен данными между видеокартами с использованием NCCL), то сервер 30 обращается к подменным библиотекам, предназначенным для передачи команд, адресованных BP, к симулируемым BP, в частности к серверу RPC в соответствии с адресом сервера RPC, сохраненным в изолированной среде, посредством направления соответствующего запроса. Запросы, адресованные BP, могут содержать параметры BP, характеризующие, например, ID BP, ID функции, количество требуемых ресурсов и прочее.

[0041] Например, при запуске приложения Megatron LM исполняемый программный код может содержать команду на выделение памяти на видеокарте посредством вызова функции cudaMalloc, для выполнения которой сервером 30 предоставляется идентификатор видеокарты и необходимый объем памяти. Соответственно, для вызова функция cudaMalloc сервер 30 обращается к подменной библиотеке, которая, в свою очередь механизмом удаленного вызова перенаправляет запрос для вызова функции cudaMalloc к серверу RPC, передавая идентификатор видеокарты и необходимый объем памяти.

[0042] Упомянутый запрос, адресованный BP, поступает в модуль 41 RPC, на котором развернут сервер RPC, после чего модуль 41 передает полученный запрос в модуль 44 управления журналом для его регистрации в журнале размещенном, например, в модуле 45 хранения данных. Например, для регистрации запроса модулем 44 может быть извлечены из упомянутого запроса ID функции и ее параметры и сохранены в модуле 45.

[0043] Также упомянутый запрос направляется модулем 41 в модуль 42 симуляции компонентов, который на основе хранимой информации о состоянии симулируемых BP, параметров BP, содержащихся в запросе (например, ID функции и количества требуемых ресурсов), генерирует ответ на запрос и, при необходимости, обновляет состояние симулируемых BP. Изначальное состояние симулируемых BP задается модулем 43 в момент инициализации модуля 42 на основании данных, полученных от пользователя. В частном варианте реализации представленного решения список состояний симулируемых BP, параметров BP и соответствующих им ответов может быть заранее задан в памяти модуля 42 разработчиком. В другом варианте разработчик реализует в модуле 42 алгоритм, позволяющий по набору состояний симулируемых BP и параметров, содержащихся в запросе, построить ответ.

[0044] Например, информация о состоянии симулируемых BP может характеризовать доступный объем памяти видеокарты в соответствии с конфигурацией BP, а параметры BP, содержащиеся в запросе, могут указывать на то, что требуется выделить заданный объем памяти видеокарты. Модуль 42 сравнивает доступный объем памяти с требуемым значением памяти и если требуемое значение памяти не превышает доступный объем памяти, то модуль 42 обновляет информацию о доступном объеме памяти посредством увеличения на величину требуемого значения памяти.

[0045] Информация об обновленном состоянии симулируемых BP и сгенерированный ответ на запрос направляются в модуль 44 для хранения в модуле 45. Также сгенерированный ответ на запрос и указатель успешного выполнения запроса направляются в модуль 41, который возвращает полученные данные серверу 30 в изолированную среду и завершает удаленный вызов RPC.

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

[0047] В результате использования предлагаемого решения удалось:

- запустить обучение нейросети GPT3 при помощи фреймворка Megatron LM;

- обнаружить в исходном коде несколько ошибок, препятствовавших успешному обучению;

- подобрать параметры параллелизма для запуска на 3072 видеокартах

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

[0048] Для тестирования прототипа предлагаемого изобретения использовалось приложение, выполняющее задачу обучения GPT3 с использованием фреймворка MegatronLM в течение одной эпохи. Прототип успешно справился с задачей выполнения программного кода приложения. Выполнение кода данного приложения на реальном кластере потребовало бы не менее 1024 видеокарт-часов и 8192 ядер-часов на CPU (при использовании Nvidia Т4 и Intel 6226R). Выполнение кода данного приложения с использованием прототипа изобретения потребовало 850 ядер-часов на CPU Intel 6226R и не требовало использования видеокарт.

[0049] Помимо тестирования больших задач (сотни GPU), проект может применяться маленькими командами для проверки приложений для нескольких GPU. Для таких команд аренда даже нескольких GPU для теста представляет значительную статью расхода. В общем виде (см. фиг.2) вычислительное устройство содержит объединенные общей шиной информационного обмена один или несколько процессоров (201), средства памяти, такие как ОЗУ (202) и ПЗУ (203), интерфейсы ввода/вывода (204), устройства ввода/вывода (205), и устройство для сетевого взаимодействия (206).

[0050] Процессор (201) (или несколько процессоров, многоядерный процессор и т.п.) может выбираться из ассортимента устройств, широко применяемых в настоящее время, например, таких производителей, как: Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™ и т.п. Под процессором или одним из используемых процессоров в устройстве (200) также необходимо учитывать графический процессор, например, GPU NVIDIA или Graphcore, тип которых также является пригодным для полного или частичного выполнения способа, а также может применяться для обучения и применения моделей машинного обучения в различных информационных системах.

[0051] ОЗУ (202) представляет собой оперативную память и предназначено для хранения исполняемых процессором (201) машиночитаемых инструкций для выполнение необходимых операций по логической обработке данных. ОЗУ (202), как правило, содержит исполняемые инструкции операционной системы и соответствующих программных компонент (приложения, программные модули и т.п.). При этом, в качестве ОЗУ (202) может выступать доступный объем памяти графической карты или графического процессора.

[0052] ПЗУ (203) представляет собой одно или более устройств постоянного хранения данных, например, жесткий диск (HDD), твердотельный накопитель данных (SSD), флэш-память (EEPROM, NAND и т.п.), оптические носители информации (CD-R/RW, DVD-R/RW, BlueRay Disc, MD) и др.

[0053] Для организации работы компонентов устройства (200) и организации работы внешних подключаемых устройств применяются различные виды интерфейсов В/В (204). Выбор соответствующих интерфейсов зависит от конкретного исполнения вычислительного устройства, которые могут представлять собой, не ограничиваясь: PCI, AGP, PS/2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS/Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232 и т.п.

[0054] Для обеспечения взаимодействия пользователя с устройством (200) применяются различные средства (205) В/В информации, например, клавиатура, дисплей (монитор), сенсорный дисплей, тач-пад, джойстик, манипулятор мышь, световое перо, стилус, сенсорная панель, трекбол, динамики, микрофон, средства дополненной реальности, оптические сенсоры, планшет, световые индикаторы, проектор, камера, средства биометрической идентификации (сканер сетчатки глаза, сканер отпечатков пальцев, модуль распознавания голоса) и т.п.

[0055] Средство сетевого взаимодействия (206) обеспечивает передачу данных посредством внутренней или внешней вычислительной сети, например, Интранет, Интернет, ЛВС и т.п. В качестве одного или более средств (206) может использоваться, но не ограничиваться: Ethernet карта, GSM модем, GPRS модем, LTE модем, 5G модем, модуль спутниковой связи, NFC модуль, Bluetooth и/или BLE модуль, Wi-Fi модуль и др.

[0056] Конкретный выбор элементов устройства (200) для реализации различных программно-аппаратных архитектурных решений может варьироваться с сохранением обеспечиваемого требуемого функционала.

[0057] Модификации и улучшения вышеописанных вариантов осуществления настоящего технического решения будут ясны специалистам в данной области техники. Предшествующее описание представлено только в качестве примера и не несет никаких ограничений. Таким образом, объем настоящего технического решения ограничен только объемом прилагаемой формулы изобретения.

Claims (26)

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

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

- на основе конфигурации BP разворачивают компоненты, симулирующие BP;

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

- размещают конфигурации BP и приложение по меньшей мере в одной изолированной среде;

- осуществляют выполнение программного кода по меньшей мере в одной изолированной среде в соответствии с конфигурацией BP;

- посредством сервера исполнения изолированных сред, содержащего подменные библиотеки, перенаправляют запросы, адресованные BP, к компонентам, симулирующим BP;

- генерируют ответы на упомянутые запросы, адресованные BP, посредством их обработки компонентами, симулирующими BP;

- возвращают сгенерированные ответы на упомянутые запросы по меньшей мере в одну изолированную среду;

- завершают выполнение программного кода в изолированной среде.

2. Способ по п. 1, характеризующийся тем, что конфигурации BP содержат:

- описание моделей видеокарт, представленное в виде набора параметров;

- описание моделей сетевых карт, представленное в виде набора параметров;

- информацию о количестве симулируемых серверов и набор параметров для каждого симулируемого сервера;

- параметры сетевых соединений;

- приложение для запуска.

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

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

5. Способ по п. 1, характеризующийся тем, что компоненты, симулирующие BP, генерируют ответы на упомянутые запросы на основе хранимой информации о состоянии симулируемых BP и параметров BP, содержащихся в запросе.

6. Способ по п. 1, характеризующийся тем, что полученные запросы и состояние симулируемых BP регистрируются журнале.

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

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

- разворачивают сервер RPC;

- размещают адрес сервера RPC по меньшей мере в одной изолированной среде;

причем упомянутое перенаправление запросов и сгенерированных ответов выполняется с использованием сервера RPC.

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

Images