Возможно, этого момента AMD ждала очень долго.
Недавно Wafer AI развернул Kimi K3 на AMD MI355X. Результат: модель, для которой раньше требовалось 16 GPU NVIDIA B200, распределенных между двумя серверами, теперь можно запустить на одном сервере AMD с 8 картами MI355X.
Что еще важнее, речь не просто о том, чтобы "впихнуть" модель.
В тесте с вводом 1024 токенов и выводом 400 токенов, система на MI355X показала общую пропускную способность 952 токен/с, а скорость генерации для одного пользователя составила 118 токен/с.
В расчете на один узел, ее пропускная способность примерно в 3.8 раза выше, чем у варианта на 16 картах B200. Соотношение цена/производительность также превысило показатели B200 и B300.
Но самое неожиданное – ROCm на этот раз не доставил особых хлопот.
Модели слишком велики: память становится важнее вычислительной мощности
Kimi K3 насчитывает 2.8 триллиона параметров, и только веса модели требуют более 1.5 ТБ видеопамяти, не считая KV Cache для контекста в миллион токенов.
Сервер с 8 картами B200, где каждая карта имеет 192 ГБ памяти, в сумме предлагает около 1.5 ТБ. То есть, веса модели сложно разместить полностью, не говоря уже о месте для KV Cache. Поэтому для B200 необходимы два сервера и 16 GPU.
Карта B300 имеет 288 ГБ памяти, что позволяет разместить модель в рамках одного узла. Что интересно, AMD MI355X также обладает 288 ГБ памяти, и 8 таких карт дают в сумме около 2.3 ТБ – одного сервера достаточно.
Это не просто экономия одного сервера. Когда модель работает на нескольких узлах, генерация каждого токена может требовать синхронизации данных по сети. Даже при использовании сети RoCE v2 со скоростью около 195 Гбит/с, межузловая связь замедляет декодирование.
Благодаря большей памяти, MI355X смог удержать всю модель в рамках одного узла.
Согласно итоговым результатам, пиковая общая пропускная способность 8 карт MI355X достигла 952 токен/с, скорость однопоточной генерации – 118 токен/с.
Для сравнения, общая пропускная способность двухузловой конфигурации на 16 картах B200 составила 498 токен/с, что в пересчете на один узел дает примерно 249 токен/с.
Таким образом, пропускная способность одного узла на MI355X примерно в 3.8 раза выше средней пропускной способности одного узла в двухузловой конфигурации B200. Скорость генерации для одного пользователя у MI355X (118 токен/с) также выше, чем у B200 (90 токен/с).
B300 остается решением с абсолютно наивысшей производительностью. Общая пропускная способность узла с 8 картами B300 достигла 1568 токен/с, скорость однопоточной генерации – 172 токен/с, что примерно в 1.65 раза выше общей пропускной способности MI355X.
Но цена меняет выводы. Wafer провел расчеты, исходя из предположительной стоимости: $2.5 в час за карту MI355X, $4.25 за B200 и $6 за B300.
При таком предположении, MI355X обеспечивает около 48 токен/с пиковой пропускной способности на каждый доллар; B200 – около 7 токен/с; B300 – около 33 токен/с.
B300 быстрее, но MI355X эффективнее с точки зрения стоимости. Для дата-центров, которым требуется массово запускать открытые модели, это может быть важнее, чем просто борьба за лидерство в производительности.
Еще более неожиданно: ROCm в основном работал "из коробки"
Долгое время главной проблемой GPU AMD для дата-центров была часто не аппаратная часть, а программная.
Модель, которая сразу работает на CUDA, на ROCm могла потребовать изменений в фреймворке, добавления операторов или даже переписывания низкоуровневых ядер.
Но с Kimi K3 ситуация оказалась иной.
AMD обеспечила поддержку практически одновременно с выпуском модели. В Wafer сообщили, что модель в основном запускалась на MI355X прямо "из коробки", а последующая работа была сосредоточена на решении незначительных проблем совместимости и оптимизации производительности.
Одна из проблем возникла в части спекулятивного декодирования. Сама модель Kimi K3 не предоставляет параметров черновой модели, необходимых для MTP или EAGLE, поэтому Wafer использовал внешнюю модель чернового блочного расширения.
Это решение работало напрямую в среде CUDA, но в окружении ROCm первый реальный запрос приводил к ошибке планировщика. Причина заключалась в отсутствии определения функции с именем top_k_renorm_prob в ветке ROCm.
Эта функция выполняет не очень сложную задачу: выбирает k наивысших значений из вероятностного распределения, обнуляет остальные вероятности, а затем перенормирует оставшиеся.
В итоге Wafer восполнил эту логику с помощью обычной функции PyTorch, не требуя написания GPU-ядра или перепроектирования системы спекулятивного декодирования.
После исправления, спекулятивное декодирование повысило однопоточную производительность примерно в 2.2 раза, производительность одного потока при среднем уровне параллелизма – примерно в 1.7 раза, а пиковая общая пропускная способность увеличилась примерно на 18%.
Что еще важнее, система смогла достичь пиковой пропускной способности при более высоком уровне параллелизма.
Первое слово слишком долго: в итоге добавили всего четыре нуля
Разумеется, пропускная способность – не единственный показатель для сервиса логического вывода. Для реального пользователя другой важный параметр, напрямую влияющий на восприятие, – это TTFT, время ожидания между отправкой запроса и появлением первого токена.
В этом аспекте первоначальные результаты MI355X были не самыми лучшими. При холодном старте и предзаполнении задачи объемом около 172 тыс. токенов, MI355X требовалось около 51 секунды, в то время как B300 справлялся примерно за 23 секунды.
Для моделей с поддержкой контекста в миллион токенов, задача предзаполнения может быть очень объемной. Если при работе с длинным контекстом пользователю каждый раз приходится ждать десятки секунд или даже дольше, то даже высокая скорость декодирования не сможет компенсировать проблемы с восприятием.
В конечном итоге Wafer обнаружил, что разрыв в производительности почти полностью обусловлен одним ядром внимания. Kimi K3 в конфигурации с 8-канальным тензорным параллелизмом распределяет по 12 голов внимания на каждый GPU. Однако более быстрые ядра предзаполнения MLA в AMD AITER поддерживают только определенные формы, кратные 4, 8 или 16.
12 голов не соответствовали требованиям, и система вернулась к более медленной универсальной реализации на Triton.
Решение оказалось простым: дополнить 12 голов внимания нулями до 16, вызвать существующее высокоскоростное ядро, а после вычислений взять только необходимые 12 голов. Структура модели не менялась, новые ассемблерные ядра не писались – просто добавили четыре нуля.
После оптимизации, стабильная скорость предзаполнения для ядра AITER MLA достигла около 13 тыс. токенов/с, в то время как исходный путь отката на Triton составлял примерно 4000–7000 токенов/с. Время холодного предзаполнения сократилось примерно в 2–3 раза.
Эта оптимизация не изменяет итоговую пропускную способность декодирования, но существенно сокращает время ожидания пользователем появления первого символа.
Это также показывает, что кажущийся большим разрыв в программном обеспечении между AMD и NVIDIA иногда объясняется не недостатком базовых возможностей, а просто тем, что существующие высокоскоростные ядра пока не охватывают какую-то новую форму модели.
Крепость CUDA все еще стоит, но брешь уже появилась
Один тест, конечно, не доказывает, что AMD полностью догнала NVIDIA.
B200 вынужден работать на нескольких узлах из-за нехватки памяти; B300 по-прежнему лидирует в абсолютной производительности; инструментарий ROCm, поддержка фреймворков и экосистема разработчиков также уступают CUDA.
Но открытые модели стремительно вступают в эру триллионов параметров. Когда модель становится настолько большой, что не помещается на одном сервере, объем памяти перестает быть просто цифрой в спецификациях и начинает напрямую влиять на затраты на связь, сложность развертывания и итоговую пропускную способность.
Стратегия AMD по оснащению отдельных карт большим объемом HBM превращается в реальное системное преимущество.
Если AMD сможет продолжать повышать стабильность ROCm, расширять поддержку форм для высокоскоростных ядер и обеспечивать более своевременную адаптацию "в день выхода" для новых моделей, то дата-центры будут вынуждены серьезно рассматривать эти GPU. Цена ниже, память больше, производительность достаточна, а с программным обеспечением больше не нужно "бороться" месяцами.
Что вы думаете по этому поводу?
Ссылки:
https://x.com/wafer_ai/status/2083628389903315406
https://x.com/ChiragAsarpota/status/2083864019870634151
Статья из WeChat официального аккаунта "Машинный разум" (ID: almosthuman2014), автор:关注LLM的
