Ключевые выводы: как лимит мощности влияет на скорость и энергоэффективность MI50
Практические тесты AMD MI50 с ограничением энергопотребления через LACT дают чёткий ответ: скорость генерации токенов слабо зависит от лимита мощности. При 100 Вт карта выдаёт 97.5% производительности от базовых 190 Вт. При 50 Вт - 70% производительности, но энергоэффективность возрастает почти в 4 раза: с 0.458 до 0.173 t/s/W. Обработка промпта деградирует быстрее генерации - этот этап сильнее привязан к вычислительной мощности ядер. Для инференс-нагруженных систем оптимальный баланс - 50 Вт. Вы получаете приемлемую скорость, минимальное тепловыделение и радикальное снижение счетов за электричество.
Если вы собираете бюджетный кластер на устаревших ускорителях, эти цифры напрямую влияют на выбор блока питания, системы охлаждения и итоговую стоимость эксплуатации. Мы уже разбирали, как запустить GLM-5.2 на 16 AMD MI50 через llama.cpp RPC - там вопрос энергопотребления встаёт особенно остро, когда в стойке работают десятки карт.
Тестовый стенд и методика: как мы измеряли энергопотребление MI50
Тесты проводились на AMD MI50 - ускорителе с архитектурой GCN пятого поколения, который остаётся рабочим вариантом для бюджетного инференса. Ограничение мощности задавалось через LACT - открытый инструмент для управления частотой и напряжением AMD GPU под Linux. Этот инструмент позволяет точно выставить лимит в ваттах без вмешательства в BIOS или прошивку.
Измерялись три метрики:
- Скорость генерации токенов (t/s) - ключевой показатель для инференса, определяющий задержку ответа модели.
- Фактическое энергопотребление (Вт) - замерялось аппаратно, а не оценивалось по датчикам.
- Энергоэффективность (t/s/W) - отношение скорости генерации к потребляемой мощности.
Нагрузка имитировала типичный инференс-сценарий: обработка промпта фиксированной длины и последующая генерация ответа. Модель и параметры запроса сохранялись неизменными на всех точках замера. Это позволило изолировать влияние именно лимита мощности, исключив другие переменные.
Зависимость скорости генерации токенов от лимита мощности
Зависимость оказалась нелинейной и удивительно пологой. При снижении лимита со 190 Вт до 100 Вт - почти вдвое - производительность упала всего на 2.5%. Дальнейшее снижение до 75 Вт дало более заметное, но всё ещё умеренное падение. И только на 50 Вт скорость генерации опустилась до 70% от базовой. Цифры по точкам:
- 190 Вт - 100% (базовый уровень)
- 150 Вт - ~99%
- 100 Вт - 97.5%
- 75 Вт - ~85%
- 50 Вт - 70%
Практический вывод: если вы гонитесь за минимальной задержкой, снижение лимита до 100 Вт практически ничего не стоит. Вы экономите 90 Вт тепловыделения, теряя лишь 2.5% скорости. Это прямой выигрыш для любой системы с ограниченным охлаждением.
Почему генерация токенов так слабо зависит от мощности?
Архитектурная причина - в характере нагрузки. Генерация токенов при инференсе упирается в пропускную способность памяти (memory bandwidth), а не в вычислительную мощность ядер. Каждый новый токен требует чтения весов модели из VRAM, и узким местом становится именно шина памяти. Снижение частоты GPU через лимит мощности замедляет вычисления, но память продолжает работать практически на той же скорости. Ядра простаивают в ожидании данных - поэтому их замедление почти не сказывается на итоговой производительности.
Этот же эффект мы наблюдали при оптимизации ядер llama.cpp под AMD GPU: выигрыш достигается не разгоном ядер, а более эффективной работой с памятью и планированием вычислений.
Обработка промпта: почему этот этап страдает сильнее
Обработка промпта деградирует быстрее генерации при снижении лимита мощности. Это фундаментальное различие между двумя этапами инференса. Префилл (prefill) - это вычислительно интенсивная фаза: модель обрабатывает весь входной контекст параллельно, загружая тензорные ядра на полную. Здесь пропускная способность памяти перестаёт быть единственным узким местом - вычисления становятся значимым фактором.
Снижение лимита мощности напрямую ограничивает частоту вычислительных блоков. Память продолжает работать быстро, но ядра не успевают обрабатывать данные с той же скоростью. Результат - пропорционально больший рост времени префилла по сравнению с генерацией. Для задач с длинными промптами - анализ документов, RAG-системы с большим контекстом - этот эффект становится критичным. Вы рискуете получить неприемлемую задержку на входе, даже если генерация остаётся быстрой.
Энергоэффективность: поиск оптимальной точки
Метрика t/s/W радикально меняет картину. На 190 Вт энергоэффективность минимальна - 0.458 t/s/W. При 100 Вт она растёт до ~0.97 t/s/W. На 50 Вт достигается 0.173 t/s/W - почти четырёхкратный прирост относительно базового режима. Абсолютные цифры зависят от модели и размера батча, но тренд однозначен: чем ниже лимит, тем больше токенов вы получаете на каждый потраченный ватт.
Компромисс выглядит так: вы теряете 30% скорости генерации, но снижаете энергопотребление почти в 4 раза. Тепловыделение падает пропорционально - кулеры работают тише, система охлаждения не перегружена, срок службы компонентов увеличивается. Для сервера с 8 или 16 картами разница между 190 Вт и 50 Вт на каждой - это сотни ватт экономии и принципиально иные требования к охлаждению стойки.
50W vs 100W: что выбрать для инференс-нагруженных систем
Выбор зависит от приоритетов:
- Минимальная задержка - 100 Вт. Вы получаете 97.5% максимальной скорости, почти вдвое снижая энергопотребление относительно базовых 190 Вт. Это режим для систем, где важна каждая миллисекунда ответа, но есть бюджет на электричество и охлаждение.
- Максимальная эффективность - 50 Вт. Вы получаете 70% скорости при четырёхкратном выигрыше в энергоэффективности. Это режим для систем с постоянной нагрузкой инференса: ночные обработки, потоковые запросы, фоновая генерация. Тепловыделение минимально, шум кулеров не мешает, счета за электричество радуют.
Для большинства инференс-нагруженных сценариев 50 Вт - это точка наилучшего баланса. Потеря 30% скорости редко критична, когда карта работает круглосуточно, а выигрыш в энергоэффективности накапливается с каждым часом работы. Если вы экспериментируете с бюджетными сборками, посмотрите наш разбор инференса GLM-5.2 на 16 MI50 - там энергопотребление всего кластера становится ключевым фактором окупаемости.
Практическое применение: настройка лимита мощности через LACT
LACT (Linux AMD Configuration Tool) - утилита с открытым исходным кодом для управления параметрами AMD GPU. Установка на Ubuntu/Debian:
sudo apt install lact
sudo systemctl enable --now lactdПосле запуска GUI или командной строки вы увидите доступные карты. Для установки лимита в 50 Вт:
lact set-power-cap 0 50Где 0 - индекс GPU в системе, 50 - лимит в ваттах. Проверить текущее потребление можно через:
lact info 0 | grep powerНастройка применяется мгновенно, без перезагрузки. Для сохранения между перезагрузками добавьте команду в systemd-сервис или конфигурационный файл LACT. Инструмент также позволяет управлять кривой вентиляторов и частотами - полезно для тонкого тюнинга под конкретную модель и нагрузку.
Ограничения и применимость результатов
Результаты получены на AMD MI50 с конкретной моделью и нагрузкой инференса. Для других ускорителей - MI60, MI100, потребительских Radeon - оптимальный лимит может отличаться. Архитектурно близкие карты на GCN (Vega) покажут схожую картину, но точные цифры нужно проверять экспериментально.
Для задач обучения нейросетей эти выводы неприменимы. Тренировка нагружает тензорные ядра значительно сильнее, и снижение лимита мощности приведёт к пропорциональному падению скорости. Сценарии с длинными промптами - обработка документов на десятки тысяч токенов - требуют осторожного подхода: возможно, стоит поднять лимит до 75-100 Вт, чтобы не терять скорость на префилле.
Эти тесты - часть системного подхода к оптимизации инференса на устаревшем железе. Мы также разбирали спекулятивный декодинг на MoE-моделях и запуск DeepSeek-V4-Flash на B300 - везде прослеживается один принцип: понимание узких мест даёт кратный выигрыш эффективнее, чем наращивание мощностей.