GPU зачастую появляется в смете ИИ-проекта еще до того, как команда успела проверить будущую нагрузку. На этом этапе легко выбрать конфигурацию с большим запасом и позже обнаружить, что выбранной модели нужна совсем другая инфраструктура или часть мощности простаивает.
При выборе видеокарты важно сначала понять сценарий работы модели и проверить его на пилоте, а уже после переходить к конкретному классу ускорителей и формату их использования. В гайде разберем, как связать задачу, модель и реальную нагрузку с выбором GPU, чтобы инфраструктура соответствовала проекту уже на старте и могла расти вместе с ним.
За одним запросом на GPU скрываются разные задачи
За запросом «GPU под ИИ» могут стоять совершенно разные цели, ведь видеокарта нужна и для корпоративных ассистентов, и для периодического дообучения LLM на собственных данных, а также для разработки модели с нуля. Во всех случаях используются GPU, но требования к самим ускорителям и инфраструктуре кардинально отличаются:
| Сценарий | Что делает компания | Что важно для инфраструктуры | Типичный старт |
| Инференс | Запускает уже готовую модель и обрабатывает пользовательские запросы | Скорость ответа, стабильная производительность, число одновременных пользователей | 1–2 GPU |
| Файн-тюнинг | Адаптирует готовую модель под собственную задачу | Достаточный объем памяти и приемлемое время эксперимента | 1–4 GPU |
| Обучение с нуля | Создает новую базовую модель | Большой объем вычислений и масштабирование между множеством GPU | Многокарточный сервер или кластер |
Корпоративному чат-боту и исследовательскому проекту по созданию собственной LLM формально нужны «GPU для ИИ», но требования к инфраструктуре у этих задач существенно различаются. В связи с этим первый вопрос перед арендой или покупкой оборудования должен звучать так: для каких задач нужен GPU? Разберем каждый сценарий по отдельности.
Инференс: готовой модели важны скорость ответа и стабильная производительность
Самый распространенный корпоративный сценарий — инференс. Модель уже обучена, а задача инфраструктуры состоит в том, чтобы быстро принимать запросы и возвращать ответы. Так работает корпоративный ИИ-ассистент, поиск по внутренним документам, классификация обращений, генерация текстов и множество других прикладных сервисов.
Не стоит автоматически выбирать самый мощный ускоритель. Сначала нужно понять, какая модель используется и какая нагрузка ожидается.
Если внутренним ассистентом периодически пользуются несколько десятков сотрудников, инфраструктурные требования будут одними. Если тот же тип модели обслуживает публичный сервис с тысячами одновременных пользователей, совершенно другими.
Для многих корпоративных задач отправной точкой могут стать RTX PRO 6000 Blackwell Server Edition с 96 ГБ памяти или дата-центровые A100/A800 с объемом памяти до 80 ГБ. Однако привязывать конкретный GPU исключительно к числу параметров модели тоже неправильно.
Например, модель класса 70B может запускаться в разных форматах. Квантование позволяет уменьшить объем памяти, необходимый для хранения весов, поэтому одна и та же LLM в разных конфигурациях предъявляет разные требования к GPU.
На итоговую потребность влияют также длина контекста и количество одновременно обрабатываемых запросов. Надежнее развернуть модель на минимальной подходящей конфигурации и провести нагрузочный тест.
Файн-тюнинг: важно, какую модель настраиваем
Вторая ситуация возникает, когда компания планирует обучить собственную нейросеть. После уточнения задачи часто выясняется, что речь идет об адаптации готовой DeepSeek, Qwen или другой открытой LLM под конкретную предметную область, терминологию или формат ответа. Такой подход называется файн-тюнингом.
Современные методы вроде LoRA и QLoRA позволяют адаптировать большие модели без полного переобучения всех их параметров. За счет этого требования к памяти и вычислениям заметно снижаются. В документации Hugging Face, например, приводится возможность QLoRA-дообучения модели порядка 65 млрд параметров на одном GPU с 48 ГБ памяти. Это не универсальная конфигурация для любой модели, но показатель того, насколько далеко современный файн-тюнинг ушел от идеи обязательного большого кластера.
Для корпоративного проекта разумно начинать с аренды одного GPU с достаточным объемом памяти. Если эксперимент выполняется слишком долго или выбранная модель требует больше ресурсов, конфигурацию можно расширить до двух или четырех карт. Покупать несколько дорогостоящих ускорителей ради периодической нагрузки означает оплачивать не только само обучение, но и недели потенциального простоя между экспериментами.
Кроме того, иногда файн-тюнинг вообще не нужен. Если компания хочет, чтобы ассистент знал внутренние регламенты, договоры или продуктовую документацию, задача не всегда требует дообучения модели. Информация внутри компании меняется. Сегодня появился новый тариф, завтра обновился регламент, через месяц изменилась инструкция. Постоянно переобучать модель вслед за каждым таким изменением неудобно.
В подобных случаях логичнее оставить готовую LLM и передавать ей актуальные корпоративные данные во время запроса. Файн-тюнинг имеет смысл прежде всего тогда, когда нужно изменить устойчивое поведение модели, например научить ее отвечать в определенном формате или лучше работать с повторяющимся специализированным типом задачи.
Обучение с нуля: это уже отдельный класс проектов
Если компания действительно создает базовую языковую модель с нуля, требования к инфраструктуре резко возрастают. Здесь GPU месяцами обрабатывают огромные массивы данных и обновляют все параметры модели, поэтому одна или несколько карт уже не решают задачу.
Для pre-training используют многокарточные серверы и кластеры. Один из вариантов для таких нагрузок — NVIDIA H200 с 141 ГБ HBM3e и NVLink, который обеспечивает быстрый обмен данными между ускорителями. В зависимости от размера модели и объема обучения инфраструктура может включать от 8 до 256 таких GPU.
Масштаб хорошо показывает пример Meta (признана в РФ экстремистской организацией и запрещена). Для обучения Llama 3.1 405B компания использовала более 16 тыс. NVIDIA H100, а весь процесс потребовал десятки миллионов GPU-часов. H100 здесь отражает конкретную конфигурацию исторического проекта Meta (признана в РФ экстремистской организацией и запрещена), тогда как H200 сегодня можно рассматривать для аналогичных задач pre-training, где критичны объем памяти и работа большого числа ускорителей в связке.
Небольшую специализированную модель можно обучать на гораздо более скромной инфраструктуре, но фундаментальные модели уже требуют отдельного бюджета на вычисления, сеть и хранение данных. Для корпоративного ассистента, поиска по документам, автоматизации поддержки или обработки текстов такой масштаб обычно не нужен.
Только после сценария есть смысл выбирать класс GPU
Когда задача определена, можно переходить к конкретным ускорителям. Для первичной оценки достаточно ориентироваться на три параметра: объем памяти, производительность на целевой модели и итоговую стоимость выполнения задачи.
| Задача | Разумная стартовая конфигурация | Когда нужны дополнительные ресурсы |
| Пилот готовой LLM | 1 облачный GPU | Если модель не помещается или не хватает производительности |
| Корпоративный инференс крупной модели | RTX PRO 6000 96 ГБ или A100/A800 80 ГБ | При росте числа пользователей или требований к скорости |
| Файн-тюнинг | 1 GPU с достаточным объемом памяти | Если эксперимент занимает слишком много времени |
| Регулярное дообучение | 2–4 GPU | Если эксперименты идут постоянно и ресурсов стабильно не хватает |
| Очень крупный инференс | H200 или несколько GPU | При высокой постоянной нагрузке |
| Обучение крупной модели с нуля | Многокарточный сервер или кластер | Масштаб определяется самой моделью и объемом данных |
Данное сравнение не показывает, что RTX PRO 6000 всегда подходит для одной задачи, а H200 — всегда для другой. Оно скорее показывает точку, с которой разумно начинать тестирование — именно тест на собственной модели позволяет понять, нужен ли следующий класс оборудования.
Прежде чем добавлять второй GPU, нужно понять, чего именно не хватает текущей конфигурации. Ограничение может быть связано с объемом памяти, количеством одновременных запросов или временем выполнения задачи:
- В одном случае модель физически требует большего объема памяти.
- В другом она прекрасно работает на одном GPU, но растет количество пользователей.
- В третьем все укладывается в имеющиеся ресурсы, однако бизнес хочет сократить время выполнения задачи.
Для бюджета эти ситуации различаются — если проблема заключается в пиковом количестве запросов, дополнительная мощность может понадобиться только несколько часов в сутки. Если же модель постоянно занимает всю доступную память и работает круглосуточно, требования будут уже другими.
После выбора модели нужно снять фактический профиль нагрузки: сколько запросов приходит в обычное время, что происходит на пиках, насколько сильно загружен GPU и какую скорость ответа бизнес считает приемлемой. Только после этого понятно, нужна ли вторая карта, более мощный ускоритель или вообще ничего менять не требуется.
Дальше выбираем не GPU, а способ его получить
Когда модель и нагрузка уже известны, нужно решить, покупать оборудование или арендовать. Здесь удобно выделить три стадии зрелости проекта.
Пилот и непредсказуемая нагрузка — облачный GPU
На старте параметры проекта еще меняются. Команда может заменить модель, пересмотреть требования или вообще отказаться от гипотезы. В такой ситуации облачный сервер с GPU снижает стоимость ошибки. Можно начать с одной конфигурации, проверить модель, а затем увеличить или уменьшить ресурсы.
Аренда GPU-мощностей особенно удобна и при нагрузке с выраженными пиками. Компания не обязана постоянно держать максимальную мощность только ради нескольких часов высокой активности.
Стабильная высокая нагрузка — выделенный сервер
Если проект работает постоянно и использует значительную часть ресурсов, протестируйте и сравните обычный GPU Cloud с выделенным физическим сервером. Компания получает предсказуемую конфигурацию и эксклюзивный доступ к ресурсам, но ей не приходится самостоятельно покупать GPU, размещать оборудование и заниматься его обслуживанием — это делает провайдер.
Собственная инфраструктура — после расчета полной экономики
Покупка GPU становится логичным вариантом тогда, когда нагрузка уже хорошо измерена, конфигурация достаточно стабильна, а расчет полной стоимости показывает преимущество собственного оборудования.
Никогда не берите GPU «на вырост»
Во время пилота может многое измениться, в том числе и сама модель — более компактная LLM иногда показывает почти такое же качество на конкретной задаче, как гораздо более крупная. Развиваются методы квантования и оптимизации, появляются новые поколения ускорителей. GPU-сервер, купленный сегодня под предполагаемую будущую архитектуру, через год может оказаться либо избыточным, либо не соответствующим новой конфигурации.
На старте безопаснее арендовать минимальную рабочую конфигурацию GPU и увеличивать ее только по результатам тестов. При необходимости такая схема позволяет двигаться дальше без смены подхода. Например, у ITGLOBAL.COM в облачном пуле доступны несколько классов ускорителей и конфигураций под разную нагрузку. RTX PRO 6000 Blackwell Server Edition можно арендовать с 12, 24, 48 или 96 ГБ видеопамяти, A100/A800 — с 10, 20, 40 или 80 ГБ, а H200 доступна с полными 141 ГБ памяти на карту, в том числе в конфигурации с двумя GPU. Это позволяет начать пилот с минимально достаточного варианта, а после нагрузочного тестирования перейти на более емкую конфигурацию или увеличить число ускорителей.
Для проектов со стабильной нагрузкой у провайдера также есть выделенные GPU-серверы. В результате инфраструктура может меняться вместе с проектом, а не фиксироваться до появления реальных данных о нагрузке.
Пять вопросов, которые стоит задать до аренды GPU: чек-лист
В итоге предварительный выбор можно провести без глубокого погружения в архитектуру ускорителей.
1. Что мы делаем с моделью?
Запускаем готовую, дообучаем существующую или действительно создаем новую.
2. Какая модель прошла пилот?
Выбирать сервер под модель, которая еще может поменяться, рано.
3. Сколько памяти ей действительно требуется?
Ориентироваться стоит на фактическую конфигурацию модели, включая способ ее запуска, а не только на количество параметров.
4. Как выглядит нагрузка?
Нужно отличить постоянное использование от краткосрочных пиков. Для последних облачная аренда особенно удобна.
5. Что ограничивает производительность сейчас?
Дополнительный GPU имеет смысл брать только тогда, когда понятно, что именно он исправит. Например, поможет ли он решить проблему нехватки памяти, увеличить число одновременно обслуживаемых запросов или сократить длительность вычислений.
Сначала задача, потом GPU
Для того чтобы правильно выбрать GPU для бизнеса, нужно понять, что именно компания собирается делать с моделью. Затем выбрать саму модель и проверить ее на реальной нагрузке. После этого определить, сколько памяти и производительности действительно требуется, и только затем выбирать конкретный класс ускорителя.
Такая последовательность помогает избежать двух противоположных ошибок:
- купить мощную конфигурацию под прогнозируемую нагрузку и годами оплачивать простаивающие ресурсы;
- сэкономить на старте и обнаружить ограничения уже после выхода сервиса в промышленную эксплуатацию.
Облачная аренда GPU делает эту схему удобной — начать можно с минимальной конфигурации, а каждый следующий ресурс добавлять только после того, как проект доказал в нем необходимость. В результате ИТ-директору не придется угадывать, какой GPU понадобится бизнесу через три года.
Читайте также: