Модель Qwen 3.8 27B запустили на NPU от AMD через FastFlowLM, и скорость декодирования при этом составила около 1 токена в секунду. Об этом 30 сентября 2026 года сообщил пользователь /u/TuskNaPrezydenta2020 в сообществе r/LocalLLaMA, назвав результат "killer 1 tps decode" (пост в r/LocalLLaMA).
Оговорка, без которой новость читается неправильно: это публикация в сообществе, а не анонс AMD или команды FastFlowLM. В посте нет ни версии инструмента, ни модели процессора, ни объёма памяти, ни параметров запуска, ни методики замера. Всё, что можно утверждать по источнику: 27-миллиардную модель прогнали на NPU AMD, и заявленная скорость генерации близка к 1 tps.
Практический смысл цифры прост. 1 токен в секунду - это меньше слова в секунду, медленнее, чем человек читает вслух. Для чата, ассистента или автодополнения кода такой режим не годится, а вот для фоновых задач, где ответ можно подождать, иногда да.
Что случилось: Qwen 3.8 27B запустили на AMD NPU через FastFlowLM
В обычном сценарии локального инференса LLM вычисления идут на дискретной видеокарте или на CPU. Здесь задействован NPU, отдельный нейросетевой блок внутри процессора AMD, который обычно занимается задачами вроде шумоподавления, эффектов камеры и ускорения локальных AI-функций в приложениях.
Что известно из публикации:
- модель - Qwen 3.8 27B;
- аппаратная часть - NPU AMD;
- инструмент - FastFlowLM;
- скорость декодирования - около 1 токена в секунду;
- автор - /u/TuskNaPrezydenta2020, дата - 30 сентября 2026 года.
Чего в источнике нет: модели процессора, поколения NPU, версии FastFlowLM, операционной системы, типа квантования, длины контекста и объёма оперативной памяти. Без этих деталей результат остаётся единичным отчётом, который никто пока не воспроизвёл публично (исходный пост). Проверить заявленные 1 tps на своей машине напрямую не с чем, сравнивать нечего.
Ирония в заголовке поста считывается легко. Слово "killer" тут работает наоборот: 1 tps - это не рекорд, а техническая демонстрация того, что задача в принципе решается на NPU.
FastFlowLM: что это за инструмент и как он запускает LLM на NPU
FastFlowLM - рантайм для запуска больших языковых моделей на NPU. Ниша узкая: это не замена llama.cpp, Ollama или LM Studio, которые рассчитаны на GPU и CPU, а инструмент под конкретный класс ускорителей.
Логика работы у подобных рантаймов одна. Модель переводят в формат, понятный ускорителю, веса квантуют, граф вычислений раскладывают по доступным блокам, а память распределяют так, чтобы уложиться в лимиты устройства. Всё остальное - инженерные детали: какие операторы поддерживает драйвер, где данные лежат в кэше, сколько слоёв можно выполнить параллельно.
Как FastFlowLM взаимодействует с NPU AMD
NPU в процессорах AMD - блок для матричных вычислений с пониженной точностью. Программный стек к нему состоит из драйвера устройства и библиотек уровня ONNX Runtime с провайдером от AMD: рантайм отдаёт NPU граф модели, а тот исполняет его на своих блоках. Точный набор библиотек и версий внутри FastFlowLM публично раскрыт не полностью, и в исходном посте его тоже нет.
Два практических следствия. Первое: без актуального драйвера NPU не задействуется, даже если процессор оснащён этим блоком. Второе: модель должна существовать в поддерживаемом формате, то есть обычный GGUF-файл из llama.cpp сам по себе не подойдёт.
Отдельный контекст - интерес AMD к команде FastFlowLM. Их оптимизации инференса встраивают в ROCm, и в разборе партнёрства AMD и FastFlowLM речь идёт о приросте до 40% на MI300X. Направлений у инструмента два: NPU в клиентских процессорах и серверные ускорители Instinct.
Какие NPU AMD поддерживаются и что нужно для запуска
"NPU AMD" - это не одна железка, а несколько поколений. Первое поколение XDNA появилось в Ryzen 7040 и Ryzen 8040, второе, XDNA 2, - в Ryzen AI 300 и Ryzen AI Max. Поколения различаются производительностью, набором поддерживаемых операторов и зрелостью драйверов, поэтому совместимость стоит проверять для конкретного чипа, а не для бренда в целом.
В исходном посте модель процессора не названа, так что официального списка совместимых NPU из новости не следует. Перед установкой ориентируйтесь на документацию FastFlowLM и AMD Ryzen AI Software, а не на заголовок поста.
Ключевые факторы, которые определяют, получится ли запуск:
- объём оперативной памяти: у NPU нет собственной VRAM, он работает с системной RAM;
- пропускная способность памяти: генерация токенов упирается именно в неё;
- поддержка нужных операторов в драйвере и рантайме;
- наличие версии модели, сконвертированной под NPU.
Требования к драйверам и программному обеспечению
Для NPU нужны драйвер устройства и стек AMD Ryzen AI Software. Без обновлённого драйвера приложение просто не увидит ускоритель. Поддержка Linux у Ryzen AI исторически отстаёт от Windows, поэтому на Linux шансы запустить NPU-инференс без ручной сборки компонентов ниже. Операционная система в исходном посте не указана, и этот момент придётся выяснять самостоятельно.
Отдельное ограничение касается размера модели. 27B - крупная модель, и чем больше весов нужно держать в памяти, тем выше шанс упереться в лимиты ноутбучной платформы. На NPU первых поколений запуск такой модели может оказаться невозможным по памяти, а не по скорости.
Скорость 1 токен в секунду: что это значит на практике
Переведём в понятные величины. При 1 tps ответ на 500 токенов генерируется больше 8 минут, на 2000 токенов - около 33 минут, на 10 000 токенов - почти три часа. Человек читает со скоростью 200-300 слов в минуту, то есть 3-5 слов в секунду, и модель отстаёт от темпа чтения в несколько раз.
В русском языке на одно слово часто приходится больше одного токена, поэтому реальная выдача текста окажется ещё скромнее, чем в английском. Ориентир по комфорту у интерактивных сценариев такой: 5-10 токенов в секунду воспринимаются нормально, 2-3 tps уже раздражают, 1 tps ощущается как зависший интерфейс.
Где 1 tps терпимо:
- пакетная обработка: ночью прогнать сотню документов через суммаризацию;
- фоновые задачи без дедлайна: разметка, черновые заголовки, классификация;
- эксперименты с NPU: понять, что блок умеет и как ведёт себя под нагрузкой;
- энергосберегающие сценарии, когда важен расход батареи, а не время ответа.
Где не терпимо совсем: чат, ассистент, автодополнение кода, агентные пайплайны с длинными ответами и циклом вызовов инструментов, любые сервисы с обещанным временем ответа. Агентная задача, где модель должна выдать 20 000 токенов, растянется примерно на 5,5 часа.
Ещё один неизвестный параметр - скорость обработки промпта (prefill). В посте она не приведена, а именно она часто определяет, сколько придётся ждать первого токена на длинном контексте.
NPU против GPU для локального инференса LLM
Сравнивать эти два варианта проще всего по трём осям: скорость, память и энергопотребление.
| Критерий | NPU в процессоре AMD | Дискретная GPU |
|---|---|---|
| Скорость декодирования на модели около 27B | около 1 tps по данным поста | десятки токенов в секунду на конфигурациях с достаточной VRAM |
| Память | общая системная RAM | собственная VRAM с высокой пропускной способностью |
| Энергопотребление | единицы и десятки ватт в составе SoC | сотни ватт у топовых карт под нагрузкой |
| Доступность | только новые Ryzen с NPU | любая сборка с подходящей картой |
Разрыв в скорости измеряется десятками раз. В подборке пользовательских замеров по Qwen3.8-27B конфигурация на RTX 3090 с 64 ГБ DDR4 и AMD 7950x в квантовании Q5_K_M выдаёт примерно 30-32 токена в секунду. Это уже пригодно для практической работы, в отличие от 1 tps.
При сравнении конфигураций важно не смешивать prefill и decode и фиксировать квантование: разбор запуска Qwen 3.8 27B на одной RTX 5090 как раз показывает, насколько цифры зависят от формата весов, MTP и типа KV-кэша. Один и тот же токен в секунду в разных замерах может означать разное.
Отставание NPU объясняется не одной лишь вычислительной мощностью. Декодирование LLM упирается в пропускную способность памяти: на каждый токен нужно прочитать веса модели. У дискретной карты своя память с высокой пропускной способностью, у NPU в клиентских чипах - общая LPDDR вместе с CPU. По этой причине встроенная графика тех же Ryzen AI часто оказывается практичнее для LLM: доступ к памяти у неё тот же, но поддержка в массовых рантаймах вроде llama.cpp намного лучше.
Стоит ли пробовать FastFlowLM: кому подходит и какие ограничения
Эксперимент оправдан, если у вас уже есть машина на Ryzen с NPU и хочется понять, что этот блок умеет, а задача не чувствительна к задержке. Ещё один разумный мотив - разгрузить GPU и CPU, оставив фоновую генерацию на NPU, и заодно снизить энергопотребление.
Тратить время не стоит, если нужен рабочий инструмент под повседневные задачи: интерактивный чат, ассистент, автодополнение кода, продакшен с обязательствами по времени ответа. В этих сценариях GPU или облачный API окажутся и быстрее, и предсказуемее. Если вопрос упирается в оплату зарубежных сервисов, а локальная карта не проходит, часть пользователей закрывает его через виртуальную карту зарубежного банка с пополнением в рублях.
Ограничения, которые нужно принять до старта:
- скорость около 1 tps на модели 27B;
- неизвестный список поддерживаемых NPU и моделей;
- возможные проблемы совместимости драйверов, особенно на Linux;
- скудная публичная документация и отсутствие воспроизводимой методики замера;
- высокий порог входа по времени: настройка может занять больше, чем сам эксперимент.
Минимальный чек-лист для проверки на своей машине:
- Уточнить модель процессора и наличие NPU: сведения есть в характеристиках и в диспетчере задач Windows.
- Обновить драйверы и установить актуальный Ryzen AI Software.
- Сверить в документации FastFlowLM список поддерживаемых моделей и форматов.
- Замерить отдельно prefill и decode на коротком промпте с фиксированной длиной ответа.
- Сравнить результат с тем же промптом на GPU или CPU, чтобы понять реальный разрыв.
Перспективы NPU для LLM: что будет дальше
AMD, Intel и Qualcomm продолжают развивать NPU, а поддержка ускорителей растёт в ONNX Runtime, DirectML и других фреймворках. Направление живое: блоки становятся быстрее, драйверы зрелее, инструментов под ними больше.
Но есть структурное ограничение. Генерация токенов упирается в пропускную способность памяти, а NPU в клиентских процессорах делит LPDDR с CPU и графикой. Рост вычислительной производительности сам по себе не даёт кратного ускорения декодирования. Картина может меняться заметнее за счёт квантования, спекулятивного декодирования, MTP и более эффективной работы с KV-кэшем, а не за счёт одних только TOPS.
Практический ориентир на сегодня: для серьёзной локальной работы с LLM собирайте конфигурацию вокруг GPU с достаточным объёмом VRAM, а NPU держите как второй вариант для фоновых задач и экспериментов. Если хочется проверить его на своей машине, начните с короткого промпта и замера decode: честное число для своей конфигурации вы получите за полчаса и не станете верить чужому заголовку.