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