В этом материале
Первый предмет разговора — проверяемый узел и условия его использования. Поставщик, владелец машины и оператор инференса должны заранее определить свои роли.
У поставщика серверов может быть демонстрационный парк, временно свободная конфигурация или клиент, который купил GPU и ещё не определил нагрузку. Для такого оборудования полезен проверяемый сценарий применения. Пилот инференса позволяет обсудить возможности конкретного узла до расширения поставки.
Разговор с интегратором стоит строить вокруг совместной технической проверки, а не вокруг обещания немедленно продать определённое количество токенов.
Разделите три разных предложения
Поставка нового сервера, предоставление демонстрационной машины и знакомство с владельцем свободного парка — разные форматы. В первом случае обсуждается оборудование к покупке, во втором — ограниченный доступ к существующему ресурсу, в третьем — прямое решение владельца.
Уточните формат в первом сообщении. Если оборудование принадлежит клиенту, его согласие нельзя заменить интересом поставщика. На этапе знакомства достаточно общей конфигурации; персональные контакты и документы передаются по согласованному порядку.
Подготовьте паспорт демонстрационного узла
Включите точные модели GPU, VRAM, CPU, RAM, накопители, соединения между устройствами и параметры площадки. Сохраните версию драйвера и программного окружения. Название готового сервера без состава компонентов оставляет слишком много неопределённости для теста.
Для моделей, использующих несколько GPU, важна топология. Документация vLLM о масштабировании различает подходы распределённого выполнения. Наличие нескольких ускорителей в спецификации само по себе не определяет подходящую архитектуру сервиса.
Сделайте тест полезным обеим сторонам
Согласуйте одну или несколько нагрузок, которые отражают предполагаемое применение сервера. Отчёт должен связывать результат с моделью, форматом весов и профилем запросов. Пиковое число без условий неудобно и оператору, и поставщику: его нельзя честно перенести в следующий проект.
Практический формат отчёта — таблица «конфигурация, тест, ограничение, дальнейшее действие». Например, если узел ограничен памятью, обсуждают другую модель или режим. Если проблема в охлаждении, сначала устраняют условия эксплуатации, а не меняют коммерческую презентацию.
Для поставщика дополнительным результатом может стать перечень подтверждённых конфигураций с описанными ограничениями. Его удобно использовать во внутренних обсуждениях: какой хост подходит выбранной модели, что ограничивает масштабирование и какие вопросы остаются открытыми. Публиковать такой результат от имени заказчика следует только после согласования.
Установите срок и ответственность
Демонстрационное использование должно иметь срок, расписание, перечень изменений и правило возврата. Укажите, кто обеспечивает физический доступ, поддержку и связь при инциденте. Разделите диагностику оборудования и сопровождение модели.
Для аппаратной проверки можно использовать применимые процедуры из руководства NVIDIA DCGM. Набор проверок зависит от устройства и окружения. Технический отчёт не заменяет гарантийные условия производителя или поставщика.
Практические выводы
Укажите, какое действие предлагаете: выделить узел на пилот, оценить клиентский парк или обсудить конфигурацию будущей поставки.
После проверки проще решить, какие следующие шаги имеют основания. Вопросы регулярной работы описаны в материале о подключении пула, а критерии технического решения — в плане пилота.