Как подготовить ТЗ на GPU-сервер

1. Опишите задачу и зафиксируйте модель

Начните с результата: ответы сотрудникам по базе знаний, обработка документов, распознавание изображений или другая конкретная операция. Разделите инференс — работу уже обученной модели — и обучение либо дообучение. Это разные профили нагрузки; конфигурация, достаточная для ответов пользователям, не подтверждает возможность обучения.

Укажите ссылку на модель, точную версию весов, формат и лицензионные ограничения. Добавьте примеры входных данных и критерии качества ответа. Если модель ещё выбирается, перечислите допустимые варианты и назначьте этап проверки. Формулировка «нужен сервер для AI» не задаёт ни объём памяти, ни критерий полезности результата.

2. Определите нагрузку и предел ожидания

Опишите обычный поток и пик отдельно: сколько запросов приходит одновременно, какова длина входа и ответа, допустима ли очередь. Для текстовой модели размер контекста считают в токенах — частях текста, с которыми работает модель. Среднее число пользователей без этих сведений недостаточно для расчёта.

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

3. Рассматривайте сервер как целую систему

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

4. Согласуйте эксплуатацию и ответственность

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

SLA — соглашение об уровне сервиса — должно описывать конкретные обязательства, границы ответственности и порядок измерения. Разделите время реакции и время восстановления. Укажите окна обслуживания, резервирование, порядок возврата данных и доступ администраторов. Наличие нескольких GPU само по себе не делает сервис отказоустойчивым.

5. Превратите требования в проверку перед заказом

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

В предложении сопоставьте каждый пункт ТЗ с конфигурацией, результатом проверки или открытым вопросом. Условия, которые ещё не проверены, оформите как отдельный этап с ответственным и критерием завершения. До заказа согласуйте состав поставки, приёмку, гарантию и необходимые работы на площадке.

Результат ТЗ — проверяемая связка «задача → нагрузка → конфигурация → приёмка». Она помогает выбрать оборудование по рабочему сценарию и не подменять измерения названием ускорителя.