Выбор инфраструктуры для ИИ начинается с нагрузки: какую модель нужно запускать, сколько запросов она будет обрабатывать и сколько времени пользователь готов ждать ответ. Затем подбирают сервер и проверяют, где его можно разместить. Если начать с покупки самой мощной видеокарты, легко получить дорогую систему, которой не хватает памяти, сетевой связности или возможностей обслуживания.
Этот гайд поможет составить требования к серверу для нейросетей, сравнить аренду с собственным оборудованием и подготовить вопросы площадке. Основной пример — сервис на базе большой языковой модели, но порядок проверки подходит и для распознавания речи, обработки изображений и других ИИ-задач.
Сначала опишите задачу, затем выбирайте оборудование
Слово «ИИ» почти ничего не говорит о необходимых ресурсах. Небольшая модель классификации документов и многопользовательский чат с длинной историей диалога предъявляют разные требования. Для первого обсуждения с инженером или провайдером составьте короткий паспорт нагрузки.
- Задача: генерация текста, поиск по документам, распознавание речи, обработка изображений или обучение модели.
- Модель: название, версия, формат весов и используемая библиотека запуска. Если выбор ещё не сделан, укажите несколько кандидатов для тестирования.
- Вход и выход: типичный и максимальный размер документа, длина диалога, длительность аудио или разрешение изображения.
- Параллельность: сколько задач выполняется одновременно и как часто возникают пики.
- Ожидаемый результат: приемлемое качество, время ответа и допустимая доля ошибок.
- Данные: где они хранятся, кто имеет к ним доступ и можно ли передавать их внешнему сервису.
- Режим работы: постоянный онлайн-сервис, ночная пакетная обработка или отдельные эксперименты.
Число зарегистрированных пользователей нельзя подставлять вместо параллельности. У внутреннего помощника для ста сотрудников может быть несколько активных запросов одновременно, а одна автоматизация способна отправить большую очередь документов. Для расчёта нужны реальные сценарии обращений.
Разделите инференс, дообучение и обучение с нуля
Инференс — применение готовой модели: например, получение ответа или расшифровки. Здесь важны качество результата, задержка и число задач, которые система выдерживает одновременно. Для постоянно доступного помощника нужно оценивать работу под нагрузкой, а для ночной обработки архива — время выполнения всей очереди.
Дообучение меняет поведение модели на подготовленных примерах. Помимо весов, при обучении память занимают активации, градиенты и состояния оптимизатора. Поэтому конфигурация, успешно выдающая ответы, необязательно подходит для обучения той же модели. Документация Hugging Face отдельно разбирает эти составляющие расхода памяти.
Методы параметроэффективного дообучения, например LoRA, позволяют обучать меньше параметров, чем при полном дообучении. Это повод проверить более доступную конфигурацию, но не обещание, что любая модель поместится на одну видеокарту. Итог зависит от модели, длины примеров, размера пакета и настроек обучения.
Обучение с нуля требует самостоятельной оценки вычислений, данных и бюджета. Не закладывайте его в инфраструктуру обычного корпоративного помощника без обоснованной необходимости. Сначала проверьте готовую модель и поиск по базе знаний: возможно, задача решается без изменения её весов.
Сравните четыре способа получить вычислительные ресурсы
| Формат | Когда рассматривать | Что проверить |
|---|---|---|
| Готовая модель через API | Нужен быстрый пилот, управление сервером пока не входит в задачу | Качество на своих примерах, ограничения запросов, обработку данных, стоимость всего сценария |
| Облачная машина с GPU | Нагрузка меняется, оборудование нужно для экспериментов или отдельных запусков | Наличие нужной конфигурации, способ тарификации, постоянное хранилище и условия остановки машины |
| Аренда выделенного сервера | Нужна определённая конфигурация на длительный срок | Точный состав оборудования, доступ администратора, замену компонентов и возможности расширения |
| Собственный сервер на colocation | Оборудование уже есть или его покупка оправдана расчётом | Стоимость размещения, питание, охлаждение, удалённые работы, ремонт и вывоз оборудования |
Colocation означает размещение вашего оборудования на площадке оператора. При аренде выделенного сервера оборудование предоставляет провайдер. В обоих случаях заранее выясните, кто устанавливает драйверы, обновляет систему, следит за дисками и восстанавливает приложение после сбоя.
Не считайте один формат заведомо дешевле другого. Редко используемый собственный сервер может простаивать, а постоянно работающая облачная машина — стоить дороже ожидаемого. Для решения сравнивайте одинаковую нагрузку, одинаковое качество сервиса и полный набор расходов.
Как оценить память GPU без ложной точности
GPU — графический процессор, который также используют для вычислений нейросетей. Его видеопамять, или VRAM, часто становится одним из первых ограничений при запуске языковой модели. Начальная оценка проста: число параметров нужно умножить на число байтов, отведённых для хранения одного параметра.
Например, восемь миллиардов параметров при двух байтах на параметр занимают около 16 ГБ, то есть примерно 14,9 ГиБ. Это расчёт объёма самих весов, а не требуемой памяти сервера. Он не учитывает дополнительные структуры, временные данные и особенности реализации. Покупать видеокарту с таким же объёмом памяти только по этой формуле рискованно.
Квантизация уменьшает разрядность представления части данных модели. В документации bitsandbytes описаны варианты с 8- и 4-битными весами. Однако сокращение размера весов не означает такое же сокращение всей занятой памяти. Совместимость метода с оборудованием и качество ответов нужно проверить на выбранной модели.
Для авторегрессионной генерации важен также KV-кеш: сохранённые промежуточные данные, которые помогают не повторять часть вычислений для предыдущих токенов. Токен — единица текста, с которой работает модель; он может быть словом или его частью. Длинный контекст и несколько одновременных диалогов способны заметно увеличить расход памяти на кеш. Конкретная зависимость определяется архитектурой и механизмом кеширования.
Рабочий порядок такой: запустите точную версию модели, задайте максимальный поддерживаемый контекст, затем постепенно увеличивайте параллельность. Измерьте пиковое потребление памяти. Запас определяйте по результатам этого теста и плану роста, а не по универсальному проценту из чужой конфигурации.
Не сводите сервер для нейросетей к одной видеокарте
CPU и оперативная память
Процессор обслуживает приложение и подготовку данных. Вокруг модели могут работать обработчик файлов, извлечение текста, поиск, авторизация и очередь заданий. Проверяйте всю цепочку: если документ долго разбирается до отправки в модель, замена GPU не обязательно сократит ожидание пользователя.
Оперативная память нужна системе и соседним компонентам. Для помощника с поиском по документам отдельно оцените хранилище, индекс и процессы обновления базы знаний. Нагрузка при массовой загрузке файлов может отличаться от обычной работы чата. Не размещайте все компоненты на одном сервере автоматически: сначала измерьте, не мешают ли они друг другу.
Диски и загрузка модели
Составьте список того, что будет храниться: веса моделей, контейнеры, документы, индексы, журналы, контрольные точки обучения. Учтите временное сосуществование старой и новой версии при обновлении. Свободного места должно хватать и на рабочие операции, а не только на установку.
Проверьте время запуска после перезагрузки и восстановления из копии. Быстрая выдача ответов на уже загруженной модели ничего не говорит о том, как долго сервис будет недоступен после замены узла. Если используется временный облачный диск, заранее выясните, при каких действиях данные на нём удаляются.
Несколько GPU и связь между ними
Две видеокарты не превращаются автоматически в одну с удвоенной памятью. Программа должна поддерживать подходящий способ распределения модели или запросов. Документация vLLM различает запуск на одном узле и нескольких узлах, а также способы параллельного выполнения.
При распределении одной модели важен обмен данными между ускорителями и серверами. Проверяйте фактическую топологию соединений и поддержку выбранной схемы программным стеком. Скорость внешнего интернет-канала сама по себе не описывает скорость взаимодействия внутри вычислительного кластера.
Как проверить площадку для размещения ИИ-сервера
Даже если сервер подходит по вычислениям, площадка должна принять его по габаритам, питанию, охлаждению и условиям обслуживания. Оценивая дата-центр IMAQLIQ, можно начать с описанных на его сайте услуг размещения оборудования и аренды серверов. Для выбранной GPU-конфигурации отдельно запросите подтверждение допустимой мощности и условий охлаждения: наличие общей услуги аренды не подтверждает наличие нужного ускорителя.
Мощность и охлаждение конкретного оборудования
Отправьте оператору спецификацию сервера: высоту в стойке, глубину, массу, тип питания, число блоков питания и требования производителя. Обсудите пиковое потребление и режим длительной нагрузки. Считать только мощность GPU недостаточно: электричество потребляют и остальные компоненты системы.
Для понимания масштаба: NVIDIA указывает максимальную мощность системы DGX H100/H200 на уровне 10,2 кВт. Это пример конкретной многопроцессорной платформы, а не ориентир для любого ИИ-сервера и не характеристика какой-либо площадки. Практический вывод простой: совместимость проверяют по спецификации своего оборудования.
Уточните, какая мощность выделяется на сервер или стойку, как учитывается потребление и что происходит при превышении согласованного лимита. Если оборудование требует специального охлаждения, его наличие и параметры нужно согласовать до доставки.
Резервирование и документы
Обсудите схему подключения блоков питания и поведение оборудования при потере одного источника. Запросите порядок планового обслуживания, уведомлений и аварийной эскалации. Важен ответ на конкретный вопрос: кто и что делает, когда сервер перестал отвечать ночью.
Если оператор заявляет уровень Tier, уточните, какой документ это подтверждает и к какому объекту он относится. Uptime Institute различает сертификацию проектной документации и построенного объекта. Tier III описывает возможность планового обслуживания инженерной инфраструктуры без остановки ИТ-нагрузки; Tier IV добавляет устойчивость к отдельным отказам в рамках требований стандарта. Эти характеристики не заменяют резервирование самого приложения.
Отдельно прочитайте SLA — соглашение об уровне сервиса. Проверьте, что именно измеряется, как фиксируется инцидент, какие есть исключения и компенсации. Время первого ответа поддержки и время восстановления работоспособности — разные показатели.
Удалённые работы и доступ
Согласуйте перечень действий инженера на площадке: осмотр, проверка кабеля, замена диска, подключение консоли. Уточните стоимость, часы доступности, порядок согласования и наличие запасных деталей. Для собственного оборудования заранее определите, кто отвечает за гарантийный ремонт и доставку замены.
Удалённая консоль управления удобна для аварийных работ, но требует отдельной защиты. Уточните, как ограничивается доступ к ней, кто управляет учётными записями и как фиксируются действия. Систему администрирования не стоит делать общедоступной ради удобства подключения.
Испытайте сервис на своих сценариях
Пилот должен воспроизводить будущую работу, включая длинные запросы и одновременные обращения. Синтетический короткий промпт полезен для проверки запуска, но его недостаточно для выбора производственной конфигурации.
- Зафиксируйте условия. Запишите модель, версии драйверов и библиотек, формат весов, параметры генерации и ограничения контекста. Используйте одинаковый набор заданий при сравнении серверов.
- Проверьте качество. Выберите примеры с заранее понятными критериями. Для извлечения данных проверяйте поля, для поиска — релевантность, для ответов по документам — соответствие источникам.
- Измерьте задержки. Для потокового ответа полезны время до первого токена и интервалы между токенами. Также фиксируйте полное время выполнения запроса и ожидание в очереди.
- Наращивайте нагрузку. Начните с одного задания, затем увеличивайте число параллельных запросов. Отмечайте, когда растут задержки, появляются ошибки или заканчивается память.
- Проверьте восстановление. Перезапустите приложение в тестовой среде, проверьте загрузку модели, обработку незавершённых задач и возврат к нормальной работе.
Система метрик vLLM, например, предусматривает измерения очереди, времени до первого токена и полной задержки. Такие показатели удобно использовать вместе с наблюдением со стороны клиента: серверная метрика может не включать весь сетевой путь и работу интерфейса.
Смотрите не только на среднее значение, но и на p95 — время, в которое укладываются 95% измеренных запросов. Для чата медленные ответы особенно заметны. Для пакетной обработки дополнительно считайте число успешно завершённых заданий за час. Любой результат сравнения сохраняйте вместе с условиями теста.
Рассчитайте стоимость рабочего результата
Составьте смету на одинаковый срок и объём полезной работы. Для аренды включите вычисления, диски, резервные копии, трафик, адреса и поддержку, если они оплачиваются отдельно. Для собственного сервера добавьте покупку, размещение, ремонт, доставку и труд специалистов. Перечень уточняйте по предложению каждого поставщика.
Отдельной строкой запишите ресурсы для отказоустойчивости. Конфигурация с одним сервером и система с резервным узлом решают разные задачи, поэтому сравнивать только их цену некорректно. Если простой допустим, это тоже должно быть явным требованием, а не случайным следствием экономии.
Полезный показатель — расходы за период, делённые на число заданий, выполненных с нужным качеством и в допустимый срок. В показатель включайте повторные попытки и неудачные обработки. Для разнотипных заданий считайте стоимость отдельно: сравнение короткого ответа и анализа большого документа по цене одного запроса мало что объясняет.
Подготовьте минимум три сценария загрузки: низкий, ожидаемый и пиковый. Посмотрите, где появляются простаивающие ресурсы и где потребуется расширение. Такой расчёт помогает обсудить сроки договора, масштабирование и выход из услуги до того, как возникнет зависимость от одной конфигурации.
Продумайте восстановление и переезд заранее
Надёжность здания, сохранность данных и доступность приложения — разные задачи. Рабочий сервер не исключает ошибку обновления или случайное удаление документов. Определите RTO — целевое время восстановления, и RPO — допустимую потерю данных, выраженную во времени. Эти цели должны соответствовать задачам сервиса.
В резервную копию включите не только исходные документы, но и то, без чего нельзя восстановить систему: конфигурацию, необходимые версии моделей, адаптеры, настройки поиска и связанные данные. Секреты восстанавливайте через предусмотренный для них защищённый механизм. Храните копию вне той области отказа, от которой хотите защититься.
Проведите пробное восстановление в отдельной среде и измерьте результат. Подход AWS Well-Architected также предусматривает проверку плана восстановления, а не только наличие резервных копий. Для будущего переезда заранее выясните порядок экспорта данных, сроки освобождения ресурсов и расходы на перенос.
Частые вопросы
Нужен ли собственный GPU, если нейросеть вызывается через API?
Для самого вызова внешней модели GPU обычно не нужен: вычисления выполняет её поставщик. Вашему приложению нужны ресурсы для интерфейса, запросов, хранения и сопутствующей обработки. Если локально работают другие модели, например для распознавания или построения поискового индекса, их требования рассчитывают отдельно.
Обязательно ли использовать Kubernetes для первого ИИ-сервиса?
Нет. Небольшой пилот можно запускать с более простой схемой развёртывания, если команда умеет её обслуживать. При использовании Kubernetes важно различать проверки запуска, работоспособности и готовности принимать трафик. Загружающая веса модель не должна получать пользовательские запросы раньше, чем будет готова их обрабатывать.
Какие данные использовать, пока площадка ещё проходит проверку?
Начните с синтетических или публичных примеров, которые разрешено использовать для теста. Конфиденциальные документы не стоит загружать до проверки условий доступа, хранения, журналирования и удаления. Простая замена имени в документе не гарантирует, что остальные сведения перестали быть чувствительными.
С чем идти к провайдеру
Подготовьте один документ: сценарий работы, точную модель, результаты пилота, пиковое потребление ресурсов, требования к данным и восстановлению. Приложите спецификацию оборудования, если планируете colocation. Попросите подтвердить конфигурацию и условия письменно, а затем сравните предложения на одинаковых исходных данных.
Итог выбора — проверенная связка из модели, программного стека, сервера, площадки и процесса обслуживания. Начните с измеримого пилота: он покажет, за какие ресурсы действительно стоит платить и какие ограничения нужно устранить до запуска.