GPU для ИИ — это железная часть уравнения. Нейросеть — это миллиарды умножений чисел, и всё их многообразие сводится к одному свойству: одинаковые операции над огромными массивами данных. Центральный процессор умеет всё, но выполняет десятки таких операций одновременно; графический процессор — тысячи. Поэтому там, где CPU считает модель часами, GPU справляется за секунды, а вся современная волна языковых моделей физически разместилась на GPU-ускорителях.
Название историческое: архитектура родилась для компьютерной графики, где каждый кадр — миллионы независимых вычислений цвета пикселей. Позже выяснилось, что те же свойства идеально подходят нейросетям, и сегодня ускорители для ИИ — самостоятельный класс оборудования с собственной памятью, межчиповыми связями и рыночной динамикой, мало похожей на остальную ИТ-закупку.
Какие характеристики важны бизнесу
- Память ускорителя. Главный ограничитель: модель должна поместиться в память GPU целиком. Большие модели либо не влезают, либо требуют квантизации — компактного представления весов с меньшей разрядностью.
- Пропускная способность памяти. Скорость, с которой веса подаются на вычислители, определяет время ответа не хуже самих вычислений.
- Связи между ускорителями. Для обучения и больших моделей несколько GPU работают связкой; скорость обмена между ними — отдельная характеристика.
- Энергетический пакет. Потребление и охлаждение машинного зала считаются на этапе проектирования, а не после первого счёта за электричество.
Обучение против инференса: разные требования
Обучение голодное: нужны большие массивы памяти, недели работы связок ускорителей и высокая надёжность. Инференс — повседневный: модель загружена постоянно, важны latency и стоимость одного запроса, а требования к пиковой мощности ниже. Практический вывод для большинства компаний: обучать ничего не нужно — берётся готовая модель, и весь GPU-вопрос сводится к тому, где и как её обслуживать. Разница режимов подробно разобрана в статьях батч-инференс и латентность инференса.
Облачный GPU или свой контур
Аренда GPU в облаке — старт без капитальных затрат, оплата по часам и возможность вернуть всё завтра. Минусы: данные уходят к провайдеру, тарифы волатильны, в пиковые месяцы ускорители бывают недоступны. Свой сервер с on-premise LLM — данные в контуре, стоимость предсказуема годами, но требуется закупка, помещение и обслуживание; для лёгких задач хватает и скромных конфигураций — например, локального запуска моделей через Ollama. Для промышленных нагрузок ускорители объединяют в кластеры с оркестрацией — этот уровень разобран в обзоре GPU-кластеров для LLM.
Рабочий критерий выбора — не «своё или чужое», а три вопроса: каковы требования к конфиденциальности, каков стабильный трафик и на какой срок считается проект. Высокий трафик плюс длинный горизонт обычно перевешивают в пользу своего контура; короткие эксперименты — в пользу облака.
Зачем бизнесу и где применяется у НЬЮ-ССТ
- Скорость ответов под контролем. Свой GPU-контур даёт предсказуемое время ответа ассистента независимо от соседей по облаку.
- Конфиденциальность. Модель и данные не покидают периметр компании — требование регуляторов и просто здравый смысл для чувствительных процессов.
- Экономика масштаба. При стабильной нагрузке свой контур дешевле помесячной аренды; счёт перестаёт зависеть от чужого прайса.
- Независимость от квот. Дефицит ускорителей на рынке перестаёт останавливать ваш проект.
У НЬЮ-ССТ подбор и настройка GPU-контура входят в услугу локальной LLM в контуре компании: расчёт под требуемую модель и трафик, развёртывание, мониторинг. Разработка решения — от 0,9–1,2 млн ₽; сопровождение действующего контура — от 50 000 ₽/мес.
Риски и особенности закупки
Рынок ускорителей волатилен: сроки поставки плавают, цены на вторичном рынке живут своей жизнью, часть предложений — серые каналы без гарантии. Закупать стоит по спецификации под конкретную модель и трафик, а не «по максимуму», который осядет недогруженным. Вторая группа рисков эксплуатационная: охлаждение и питание, отказоустойчивость (что происходит с сервисом при выходе одного ускорителя), мониторинг утилизации. Третья — безопасность: контур с моделью внутри по-прежнему требует защиты доступа, шифрования и регламентов; своё железо не отменяет guardrails.
Типовые ошибки
Ошибка первая — закупка до расчёта: ускорители куплены «на вырост», а модель, которая реально нужна, работает на трети мощности. Ошибка вторая — игнорирование памяти: взяли мощные карты с малым объёмом и не смогли разместить модель без агрессивной квантизации. Ошибка третья — забыть про обвязку: без очередей, балансировки и мониторинга даже идеальное железо даёт нестабильное время ответа. Ошибка четвёртая — считать только цену покупки: электричество, охлаждение и сопровождение за два года нередко сравниваются с ней.
Экономика: что считать
Сравнивайте полную стоимость владения за горизонт планирования: закупка плюс питание плюс сопровождение против облачного счёта за тот же трафик. Учтите загрузку — у облака вы платите за часы, включая простой, свой контур амортизируется равномерно. И помните про промежуточные варианты: российские хостеры с GPU и гибридные схемы, где чувствительные данные остаются у вас, а пиковые нагрузки уходят в облако.
Как считается ёмкость GPU-контура
Ёмкость считают от модели и трафика, а не наоборот. Первый шаг — модель: её размер после квантизации определяет минимальный объём памяти ускорителя. Второй — длина контекста: память нужна не только весам, но и рабочему состоянию на каждый запрос, и длинные документы в контексте съедают её быстрее, чем кажется. Третий — параллелизм: сколько запросов должны обрабатываться одновременно с выдержанным временем ответа; это определяет число ускорителей. Четвёртый — запас на пики и отказоустойчивость: контур, рассчитанный впритык, падает в чёрную пятницу собственного графика нагрузки.
Практическая арифметика выглядит так: берёте целевую модель, замеряете на одной карте реальные показатели при вашей длине контекста — токенов в секунду и время до первого токена, — затем делите пиковый трафик на пропускную способность одной карты и округляете вверх с запасом. До покупки этот расчёт проверяется арендой: день работы на облачном GPU той же серии отвечает на вопросы, которые спекуляция не закроет.
Чек-лист перед закупкой GPU
- Модель и режим квантизации зафиксированы — под них считается память, а не «на глаз больше».
- Замер на арендованном железе с вашим трафиком и длиной контекста проведён.
- Помещение: питание, охлаждение и место под запас роста проверены.
- Отказоустойчивость: поведение сервиса при выходе одного ускорителя описано.
- Программный стек и мониторинг выбраны: драйверы, среда выполнения, метрики утилизации и температуры.
- Экономика: закупка против аренды посчитана на горизонте двух лет с учётом сопровождения.
Шесть пунктов закрывают большинство историй «купили не то». Общий знаменатель один: GPU-контур проектируется от задачи, а не от каталога железа — как и любой другой элемент ИИ-системы.
Разделение GPU между задачами
Когда ускорителей больше одного, встаёт вопрос распределения: выделенные инстансы под каждую задачу или общий пул с планировщиком. Выделение проще в эксплуатации и предсказуемее по производительности — каждая задача уверена в своих ресурсах. Пул экономнее: утилизация растёт, простые простоя соседей заполняются чужой нагрузкой, — но требует оркестрации и дисциплины приоритетов: одна ненужная ночью задача не должна задерживать утренний отчёт.
Рабочая схема для компаний с несколькими ИИ-задачами: интерактивные сервисы — на выделенных ресурсах с гарантированной скоростью ответа, пакетные обработки — на общем пуле в фоновые часы. Так критичное к времени и критичное к стоимости живут в разных режимах, и конфликтов за железо не возникает. Оркестрацию таких контуров ведут штатными средствами — например, планировщиками уровня Kubernetes для LLM.
Мониторинг GPU-контура
Железо без телеметрии — чёрный ящик с вентилятором. Рабочий минимум наблюдения: утилизация вычислительных ядер и памяти по каждой карте (хронически низкая — деньги простаивают, стабильно высокая — контур на пределе), температура и скорость вентиляторов (перегрев тихо режет производительность раньше, чем ломает железо), ошибки памяти и сбросы, объём и скорость обработки — токены и запросы. Пороги алертов ставятся от SLO сервиса, а не от паспортных цифр железа: важно не «карта загружена», а «время ответа деградирует».
С чего начать
Определите модель, которая закрывает вашу задачу, и её требования к памяти и пропускной способности — от этого танцует вся спецификация. Затем посчитайте трафик и горизонт: они решат, арендовать или покупать. Расчёт конфигурации под ваш сценарий — в бесплатном разборе ИИ-ландшафта.
- модель и режим квантизации зафиксированы;
- замер на арендованном железе с вашим трафиком проведён;
- полная стоимость владения на два года посчитана против облака;
- помещение, питание и охлаждение подтверждены;
- мониторинг утилизации и температуры заложен в проект.