Хостинг для приложений искусственного интеллекта: расчет мощности ЦП, графических процессоров и систем хранения данных

Сначала сузить сферу применения ИИ

Выбор оборудования начинается с постановки задачи, а не с выбора графического процессора. При Заключение Существующая модель обрабатывает входные данные и, например, генерирует ответы. Тонкая настройка адаптирует предварительно обученную модель к дополнительным данным или конкретной задаче; полное обучение, напротив, формирует веса модели в рамках отдельного цикла обучения.

Эти задачи приводят к разным профилям нагрузки: чат-сервис должен реагировать на запросы, тогда как задача обучения обрабатывает данные в течение длительного времени и сохраняет промежуточные результаты. Для AI-хостинг Поэтому тебе следует определить, что для тебя важнее: время отклика, количество обработанных запросов, продолжительность обучения или, например, затраты на выполнение конкретной задачи.

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

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

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

Процессор и оперативная память в стадии разработки

Даже если модель работает на графическом процессоре (GPU), центральный процессор (CPU) также участвует в обработке данных. Он может принимать запросы, токенизировать текст, считывать файлы и подготавливать входные данные для обработки моделью. Если эта подготовка происходит слишком медленно, графический процессор остается без работы; в таком случае даже более мощный ускоритель не обязательно устранит это узкое место.

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

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

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

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

Правильное понимание принципов работы графического процессора (GPU) и видеопамяти (VRAM)

При инференсе, полностью выполняемом на графическом процессоре, веса модели должны помещаться в доступной памяти графического процессора. Потребность в VRAM Но на этом дело не заканчивается: среда выполнения требует дополнительных областей для промежуточных результатов и временных буферов. Поэтому карта, в которую веса как раз помещаются с расчётной точки зрения, ещё не является надёжной основой для продуктивной работы.

При авторегрессионном генерации текста к этому добавляется кэш «ключ-значение». Он сохраняет уже вычисленные состояния ключей и значений, чтобы их можно было повторно использовать на последующих этапах генерации. Длинные контексты и одновременная обработка запросов могут увеличить эту дополнительную потребность в памяти; насколько сильно — зависит от модели и способа обработки.

В документации к Transformers 4.48.2, среди прочего, описываются квантование кэша и выгрузка как способы экономии VRAM. При этом эффективность зависит от реализации и нагрузки; дополнительная обработка или передача данных могут снизить скорость. Поэтому следует одновременно проверять потребление памяти и время отклика, а не автоматически рассматривать экономию памяти как прирост производительности.

При обучении вычисления по инференции тем более недостаточны. Помимо весов возникает потребность в памяти для хранения градиентов, состояний оптимизатора и сохраненных активаций. Объем этих данных зависит, в частности, от оптимизатора, точности и метода обучения; более длинные последовательности или большие пакеты данных могут, в частности, увеличить объем памяти, необходимый для хранения активаций.

Для выполнения, полностью резидентного на GPU, доступный объем VRAM должен вмещать необходимые веса и данные выполнения. Гибридные методы могут хранить часть данных обработки или веса модели за пределами графического процессора; их пригодность и затраты на передачу данных зависят от времени выполнения. Это следует отличать от выгрузки кэша ключ-значение, описанной в Transformers 4.48.2.

Рассмотрите модель, время выполнения и запланированную степень параллелизма в совокупности и проверьте пиковые значения использования памяти при репрезентативной нагрузке. Достаточного объёма памяти для выбранного способа реализации ещё не достаточно, чтобы гарантировать желаемое время отклика или загрузку системы.

Приблизительный расчет объёма памяти модели

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

Наглядный пример вычисления, не являющийся результатом измерения: Семь миллиардов параметров, умноженных на два байта, дают 14 миллиардов байтов для весов. Если разделить это число на 1 073 741 824 байта на GiB, получится примерно 13,0 GiB. При этом предполагается, что все рассматриваемые веса действительно представлены в едином формате — по два байта на параметр; другие форматы или дополнительные представления изменят результат расчёта.

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

Для обучения расчёта весов явно недостаточно. В документации к Transformers 4.35.0 для примерной конфигурации со смешанной точностью с использованием AdamW указано 18 байт на параметр плюс активации. В эти данные включены и другие компоненты, такие как градиенты и состояния оптимизатора; размер активаций зависит, в частности, от длины последовательности и размера пакета.

Эти 18 байт не являются универсальным множителем для любого обучения: оптимизаторы, степень точности и методы обучения могут влиять на необходимый объем. Поэтому ни из этого числа, ни из значения 13,0 GiB нельзя сделать вывод о рекомендуемом размере VRAM. При выборе решающее значение имеют конкретное время выполнения и ожидаемые пиковые значения использования памяти при типичной нагрузке.

Сравнение рабочих нагрузок и узких мест

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

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

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

При тонкой настройке можно Накопление градиента позволяют использовать больший эффективный размер пакета, хотя одновременно обрабатываются только небольшие отдельные пакеты. Градиенты нескольких шагов накапливаются перед обновлением параметров. Это может помочь при ограниченном объеме памяти, но не гарантирует увеличения пропускной способности; дополнительные этапы обработки могут занять время.

Также стоит уделить особое внимание подаче данных: если предварительная обработка или загрузка отстают от скорости обработки модели, более мощный графический процессор не всегда поможет. И наоборот, быстрый конвейер данных не сможет компенсировать недостаточный объем VRAM. Поэтому сравнивайте альтернативные варианты с одинаковыми входными данными и понятным профилем нагрузки.

Планирование подключений систем хранения и графических процессоров

При планировании хранилища целесообразно разделить данные по типу и способу доступа: наборы обучающих данных читаются неоднократно, а веса модели загружаются перед использованием. И тем, и другим требуется надёжный источник, из которого их можно будет вновь предоставить после смены хоста. Одной только ёмкости недостаточно; на работу системы влияют также время загрузки и схемы доступа.

Временные рабочие данные могут храниться на локальном накопителе NVMe, если требуется быстрая рабочая область. Уточните у поставщика, сохранятся ли эти данные после перезагрузки и смены хоста. Контрольные точки и резервные копии, напротив, требуют тщательно спланированного хранения и проверенного пути восстановления; локальный рабочий каталог не является автоматически независимой резервной копией.

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

GPUDirect Storage при наличии соответствующих аппаратных, программных и файловых системных условий обеспечивает более прямой путь передачи данных между хранилищем и памятью графического процессора. Это особенно интересно в тех случаях, когда ввод-вывод находится на критическом пути, а приложение использует поддерживаемый канал. Если ЦП сначала должен декодировать или предварительно обработать данные, это может ограничить преимущества данной технологии.

При использовании нескольких графических процессоров следует различать репликацию и распределение. Репликация предоставляет копии модели для распределения запросов; она не превращает отдельные области VRAM в единое общее хранилище автоматически. В документации по vLLM 0.20.1 описывается именно такой способ предоставления данных с параллельной обработкой; из этого не следует никаких выводов относительно других версий среды выполнения.

В свою очередь, тензорный и конвейерный параллелизм распределяют части обработки и создают потребность в обмене данными. Для этого проверьте соединения между графическими процессорами, а в случае использования нескольких серверов — сетевую топологию и поддержку со стороны модели и среды выполнения. В документации по vLLM 0.8.5 рассматриваются эти стратегии распределенного обслуживания; конкретные рекомендации привязаны к данной версии.

Обнаружение узких мест при нагрузке

Конструктивное сравнение начинается с задокументированного профиль нагрузки. Укажите версию модели, степень точности, конкретную аппаратную конфигурацию и версию среды выполнения. Укажите типичную и максимальную длину контекста, длину вывода, а также количество одновременных запросов. Это позволит впоследствии проверить изменение инфраструктуры при тех же условиях.

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

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

Отслеживайте пиковые значения загрузки памяти графического процессора и оперативной памяти, а также загрузки системы хранения данных и времени ожидания. На существующей системе NVIDIA команда чтения показывает nvidia-smi в зависимости от устройства и драйвера, в том числе состояние графического процессора и загрузку памяти. Он не изменяет рабочую конфигурацию, но не заменяет измерений, проводимых приложением.

Низкая загрузка графического процессора сама по себе не свидетельствует ни о проблемах с ЦП, ни о проблемах с хранилищем. Сравните эти показатели во времени с временем ожидания данных, динамикой запросов и загрузкой хранилища, стараясь изменять при каждом сравнении только один значимый параметр. Также задокументируйте ограничения теста, например, если в нём ещё не учтены редкие пики нагрузки или особенно длительные вводные операции.

Надежное обеспечение работы инфраструктуры ИИ

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

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

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

Локальное рабочее хранилище не является автоматически постоянным и не заменяет независимое резервное копирование. Уточните у поставщика, что происходит с локальными данными при перезапуске, замене хоста или истечении срока действия договора. Храните необходимые данные отдельно от рабочей среды и проверьте возможность их восстановления на практике, включая время, необходимое для восстановления работоспособности.

В случае распределенных заданий мониторинг охватывает не только отдельные графические процессоры, но и узлы, сетевые соединения, а также ход выполнения всего приложения. Запланируйте, с какой сохраненной точки задание будет перезапущено после сбоя и какие ресурсы должны быть для этого доступны. Если части модели распределены по нескольким серверам, их соединения также влияют на работу; при этом рекомендации, приведенные в документации vLLM версии 0.8.5, зависят от конкретной версии.

Выбор модели хостинга и сервера с графическим процессором

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

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

Для выбора инфраструктуры машинного обучения необходима информация о конкретную версию графического процессора в частности: объем VRAM, пропускная способность памяти, поддерживаемые форматы вычислений и форм-фактор. Не следует без проверки переносить максимальные значения одной линейки продуктов на каждую ее модификацию. Сравнивайте характеристики производительности только с учетом условий тестирования и конкретной модели, а не принимайте решение, ориентируясь исключительно на теоретическое пиковое значение.

В спектр возможностей также входит тип масштабирования: реплицированные экземпляры могут распределять запросы, тогда как разделение модели требует поддержки со стороны среды выполнения и топологии соединений. В документации vLLM параллелизм обработки данных рассматривается в версии 0.20.1, а распределённое обслуживание — в версии 0.8.5; эти утверждения не следует переносить на другую версию без проверки.

Сначала определите модель и профиль нагрузки, затем оцените объем хранилища и маршрут передачи данных, а также запросите подходящие предложения. Затем проверьте время отклика, количество ошибок и потребность в ресурсах с помощью репрезентативных запросов или обучающих данных. Дополнительные аспекты для оценки вы найдете в разделе GPU-хостинг для веб-приложений. Без такого сравнения рабочих нагрузок невозможно сформулировать универсальную рекомендацию по выбору графического процессора.