Типичные ошибки в тендерах на GPU‑серверы и как их избежать: практический чек‑лист перед закупкой
В проектах с GPU и высокопроизводительными серверами самые большие деньги уходят не на сами карты и шасси, а на последствия неправильно написанного ТЗ: нагрузка не влезает в память, узкие места в CPU или сети, сервера не вписываются в ограничения ЦОД, TCO за три года оказывается в разы выше ожидаемого.[web:271][web:281] Чтобы не платить за переделки и «латание» архитектуры, ИТ‑директору и закупкам нужен прозрачный чек‑лист, с которым можно сверяться ещё до публикации тендера.
1. Ошибка №1: «чем больше мощность, тем лучше» без привязки к нагрузке
Одна из самых дорогих ошибок — описывать требуемые GPU и серверы формулой «чем выше класс, тем лучше», не указывая, какие именно модели и сценарии нужно поддержать. В результате одни поставщики предлагают топовые H100, другие — A100 или L‑серии, третьи — связки из нескольких средних карт, а сравнение превращается в оценку презентаций, а не реальной пригодности под ваши задачи.[web:272][web:282]
- Типичные формулировки уровня «GPU класса H100/A100» и «сервер с 64 ядрами и 1 ТБ ОЗУ» не дают поставщику понимания, это будет обучение, онлайн‑инференс, офлайн‑батчи или виртуализация, а значит, выбор будет сделан по принципу «на всякий случай потолок», с соответствующей ценой.[web:277][web:280]
- Без указания размера моделей, требуемого batch size и целевых метрик (QPS, tokens/s, латентность) высок риск взять слишком мощные и дорогие GPU, которые будут недогружены, или, наоборот, недостаточно ёмкие по памяти карты, которые потребуют сложного шардирования и удвоения числа серверов.[web:272][web:280]
Правильный подход — в явном виде описать рабочие нагрузки: тип моделей (LLM, CV, графовые, классические ML), их примерную размерность (7B/13B/70B), диапазон batch size и целевые показатели по задержке и производительности. Одной фразой это можно зафиксировать как: «Цель — стабильная работа модели X при задержке Y и Z tokens/s, поставщик обязан описать воспроизводимую методику замера».[web:272][web:282]
2. Ошибка №2: смотреть только на GPU, забывая про баланс платформы
Даже идеально подобранный GPU‑пул мало что даёт, если его постоянно голодом морят слабые CPU, узкие SSD или медленная сеть. Многие компании в ТЗ подробно расписывают требования к видеокартам, но формулируют CPU, ОЗУ, NVMe и сеть как «or better», оставляя широкое поле для экономии со стороны поставщика там, где этого делать нельзя.[web:271][web:282]
| Тип узла | Ключевые элементы «баланса» | Что часто забывают указать |
|---|---|---|
| Узлы обучения | Полное заполнение каналов ОЗУ, несколько NVMe с высокой суммарной пропускной способностью, сеть не ниже 2×25G или 100G | Минимальное число и тип NVMe, требуемый IOPS/throughput, жёсткое требование к сетевой скорости и количеству портов |
| Узлы онлайн‑инференса | CPU с высокой частотой, достаточный объём ОЗУ под кеши, сеть с низкой латентностью и резервированием | Требуемая латентность на запрос, минимальная конфигурация для L4/L7 балансировки и сервис‑меша |
| Хранилища и дата‑ингест | Масштабируемые NVMe/Tiered Storage, сеть с высокой пропускной способностью и отказоустойчивостью | Явное указание профиля нагрузки: последовательный/случайный IO, горячие и холодные данные |
В ТЗ стоит прямо прописать, что недопустимо компенсировать стоимость GPU путём снижения классов CPU, уменьшения числа модулей ОЗУ или перехода с NVMe на медленные SATA‑диски. Такой запрет фиксирует минимальный «баланс платформы» и снимает стимул у поставщика «спасти маржу» за счёт критичных узлов.[web:271][web:277]
3. Ошибка №3: игнорировать ограничения ЦОД по мощности, охлаждению и стойкам
В RFP на GPU‑кластер часто не попадает ключевая реальность: в ЦОД есть строгие ограничения по мощности на стойку, по типу охлаждения и по количеству доступных шкафов. В результате выигрывает предложение с максимально плотно упакованными GPU‑серверами, а после поставки выясняется, что по 30–40 кВт на шкаф ЦОД не тянет, кондиционирование не рассчитано, а свободных стоек нет.[web:271][web:273][web:283]
- Вопросы вроде «какая доступна мощность по кВт на стойку», «какой тип шкафов и глубина у нас в зале», «какая схема холодных/горячих коридоров» должны обсуждаться до публикации тендера и быть явно описаны в вводной части ТЗ.[web:273][web:283]
- Стоит также требовать от поставщика расчёта суммарного энергопотребления, числа стоек и оценки тепловой нагрузки, чтобы можно было сразу отсеять «бумажные» проекты, не вписывающиеся в ваши физические ограничения.[web:271][web:281][web:283]
4. Ошибка №4: расплывчатое «H100 или эквивалент» без метрик
Формулировка «NVIDIA H100 или аналог по производительности» без конкретных цифр по вычислительной мощности, объёму памяти и пропускной способности приводит к тому, что каждый участник тендера трактует «аналог» по‑своему. Кто‑то предлагает A100‑80 GB, кто‑то — L40S, кто‑то — несколько средних карт вместо одной крупной; сопоставить такие варианты по реальной эффективности практически невозможно.[web:272][web:282]
Надёжнее всего вместо «or equivalent» описывать требуемый класс так: минимальное число TFLOPS в нужной точности (FP16/BF16/FP8), минимальный объём и суммарная пропускная способность видеопамяти, обязательная поддержка определённых инструкции и тензорных блоков. Дополнительно можно указать целевой показатель производительности на эталонном бенчмарке или на вашем типовом наборе моделей — например, не менее N tokens/s при обслуживании модели K‑го размера.[web:272][web:280]
5. Ошибка №5: недооценивать важность программного стека и лицензий
Закупка «голого железа» без требований к программной среде часто приводит к тому, что уже на этапе ввода в эксплуатацию приходится дополнительно тратить недели на подбор версий драйверов, фреймворков и ОС. В худшем случае какие‑то из ключевых библиотек оказываются несовместимы с выбранной платформой, а часть стоимости железа фактически пропадает.[web:270][web:274]
- В ТЗ стоит заранее указать поддерживаемые версии ОС (например, конкретные LTS‑релизы Linux), список требуемых фреймворков (PyTorch, TensorFlow и т.п.), а также наличие или отсутствие требований к контейнеризации, оркестрации и планировщикам (Kubernetes, Slurm и др.).[web:270][web:277]
- Полезно отдельно вынести в ТЗ вопрос лицензий: какие компоненты должны быть включены в стоимость (драйверы enterprise‑уровня, мониторинг, виртуализация, кластерный софт), а также попросить поставщика описать стратегию обновлений и поддержки по безопасности на весь срок эксплуатации.[web:270][web:281]
6. Ошибка №6: смотреть только на цену закупки, игнорируя TCO на 3–5 лет
Ориентация исключительно на минимальную цену при выборе GPU‑кластеров почти гарантированно приводит к завышенному TCO: дешёвые, но прожорливые по энергии конфигурации, слабая поддержка, дорогие в будущем расширения и запчасти. С учётом высоких теплопакетов современных GPU энергопотребление и охлаждение могут составлять ощутимую часть совокупных затрат.[web:271][web:281][web:284]
| Компонент TCO (3–5 лет) | Что учитывать в тендере |
|---|---|
| Капзатраты на оборудование | Цена GPU, серверов, сетевого и систем хранения с учётом требуемого резерва и потенциального расширения |
| Электроэнергия и охлаждение | Среднюю мощность кластера, стоимость кВт·ч, коэффициент PUE ЦОД, дополнительные расходы на модернизацию охлаждения |
| Поддержка и сервис | Стоимость гарантии, расширенной поддержки, SLA по замене, наличие локального сервиса и SLA по реагированию |
| Персонал и операции | Время инженеров, обучение, внедрение мониторинга и автоматизации, стоимость простоев при инцидентах |
Оптимально включить в критерии оценки не только стоимость закупки, но и описание TCO, требуя от поставщиков дать оценку энергозатрат, охлаждения, сервисного сопровождения и планов по расширению кластера. Это уменьшает вероятность того, что выиграет «дешёвое» решение с очень дорогой эксплуатацией.[web:271][web:281][web:284]
7. Ошибка №7: отсутствие чётких критериев приёмки и нагрузочного тестирования
Формула «доставлено и установлено = принято» никак не защищает от ситуаций, когда кластер формально собран, но на целевых нагрузках не выдаёт ожидаемую производительность или работает нестабильно. Без заранее зафиксированного плана тестирования любые споры по результатам превращаются в долгие переговоры и взаимные обвинения.[web:271][web:273]
- В ТЗ имеет смысл прописать обязательный набор проверок: сверку конфигурации (CPU, GPU, память, диски, сеть), нагрузочные тесты GPU‑подсистемы и хранилищ, проверку сети и базового мониторинга, а также минимально допустимый уровень производительности в бенчмарках или на типовых задачах.[web:271][web:273]
- Важно также описать, что происходит, если по результатам тестов заявленные характеристики не достигаются: обязанность поставщика оптимизировать конфигурацию, заменить компоненты или предоставить дополнительный ресурс до достижения заданных параметров.[web:271][web:273]
8. Чек‑лист для ИТ‑директора перед публикацией тендера
Перед тем как отдавать ТЗ закупкам или публиковать RFP, полезно пройтись по собственной короткой анкете. Она помогает убедиться, что в документации нет «дырок», которые потом станут источником переплат и конфликтов с поставщиком, и что архитектура реально вписывается в технические и организационные ограничения вашей компании.[web:274][web:276]
- Описаны ли явно целевые рабочие нагрузки (виды моделей, примерный размер, тип — обучение, онлайн‑инференс, офлайн‑батчи) и указаны ли целевые метрики производительности?
- Учтены ли и отражены ли в ТЗ ограничения ЦОД по мощности, охлаждению, стойкам и сети, и обязаны ли участники тендера показать, как их решения вписываются в эти границы?
- Заменены ли расплывчатые формулировки вроде «or better», «аналог», «высокопроизводительный» на измеримые показатели по FLOPS, памяти, пропускной способности и задержке?
- Указаны ли требования к программному стеку (ОС, драйверы, фреймворки, оркестрация), модели лицензирования и стратегия обновлений на 3–5 лет вперёд?
- Включены ли в критерии оценки не только цена закупки, но и TCO, а также качество сервиса и условия расширения кластера в будущем?
- Зафиксирован ли в ТЗ план приёмо‑сдаточных испытаний и нагрузочных тестов, а также порядок действий, если оборудование не достигает заявленных характеристик?
