Короткий ответ: запустить Qwen3 на 780M можно попробовать, но подтверждённых кейсов нет
В доступных источниках нет ни одного подтверждённого отчёта о запуске Qwen3 на мини-ПК с Ryzen 7940HS и встроенной графикой Radeon 780M. Есть только вопрос пользователя с точно такой конфигурацией: 64 ГБ ОЗУ, из которых 56 ГБ выделено под iGPU. Он ищет движок или софт, который лучше работает на этом железе, и упоминает, что где-то встречал сообщение про рабочую сборку с «ngram на NVMe», но не может найти ни подробностей, ни самого обсуждения (исходный тред на r/LocalLLaMA). Это отправная точка, а не доказательство, что запуск состоялся.
Технически запуск вероятен. Qwen3 в формате GGUF работает через llama.cpp и на чистом CPU, а Vulkan-бэкенд позволяет отдать часть слоёв встроенной графике. Вопрос не в том, заведётся ли модель вообще, а в том, какой размер и какая скорость окажутся приемлемыми. Конкретных токенов в секунду для связки 7940HS + 780M в источниках нет, поэтому цифры придётся получать самостоятельно.
Держим три уровня достоверности. Подтверждено: конфигурация из вопроса и факт упоминания «ngram на NVMe» без деталей. Технически вероятно: работа Qwen3 через llama.cpp на Vulkan или CPU, гибридная раскладка слоёв, падение скорости на длинном контексте. Не подтверждено: существование готового рецепта «ngram на NVMe», который даёт ускорение именно на 780M.
Что известно из исходного обсуждения
Автор вопроса описывает мини-ПК так: «7940hs, 780m with 64gb ram (56gb allocated to igpu)». Дальше он спрашивает, удалось ли кому-то запустить Qwen3 на такой сборке, и просит подсказать движок или софт, который работает лучше. Про упомянутую конфигурацию с ngram он пишет, что видел её где-то раньше, но теперь не находит обсуждения. Никаких логов, названий моделей, квантований или замеров в сообщении нет.
Отсюда два практических вывода. Первый: конфигурация с 64 ГБ ОЗУ реальна и встречается у владельцев мини-ПК на APU. Второй: разговора о результатах не было, поэтому воспринимать тред как «кто-то уже победил 780M» нельзя.
Где заканчиваются факты и начинаются предположения
Слухи вокруг запуска LLM на встроенной графике появляются по понятной причине: в локальном AI-сообществе рядом живут четыре разные техники, и в пересказе они сливаются в одну.
- Спекулятивное декодирование: черновая модель или n-граммы предлагают токены, основная модель их проверяет.
- Prompt lookup: кандидаты берутся из уже написанного промпта или контекста по совпадению подстрок.
- mmap: файл модели лежит на диске и подгружается в память по мере обращения.
- Кэш промптов и KV-кэша на диске: повторный запуск с тем же началом диалога не пересчитывает префикс.
Каждая из этих вещей существует отдельно и на практике применяется. Ни одна из них не превращает 780M в дискретную видеокарту и не гарантирует, что Qwen3 поедет быстрее.
Что такое iGPU 780M и почему это не дискретная видеокарта
Radeon 780M встроена в APU Ryzen 7940HS. По спецификациям AMD это графика на архитектуре RDNA 3 с 12 вычислительными блоками, и работает она на той же оперативной памяти, что и процессор. Отдельной VRAM у неё нет. Всё, что вы «выделили под iGPU», остаётся физически теми же планками LPDDR5 или LPDDR5X на плате мини-ПК.
Отсюда главное следствие: объём памяти у такой сборки огромный по меркам LLM, а вот канал до этой памяти узкий. Двухканальная LPDDR5-5600 по арифметике даёт около 90 ГБ/с, LPDDR5X той же ширины при более высокой частоте чуть больше. Дискретная карта среднего уровня оперирует сотнями гигабайт в секунду. Скорость генерации токена упирается именно в то, как быстро веса модели читаются из памяти, поэтому разрыв в пропускной способности бьёт по скорости сильнее, чем разрыв в объёме.
Механика распределения зависит от платформы. В BIOS или прошивке мини-ПК задаётся размер UMA frame buffer, то есть фиксированный выкуп памяти под графику. В Linux драйвер amdgpu дополнительно использует GTT, динамический пул в системной RAM, и лимит этого пула регулируется параметром модуля. 56 ГБ, о которых говорит автор вопроса, это настройка распределения, а не физически отдельный чип памяти. Большой фикс слот удобен для тяжёлых граф, но он же уменьшает объём, доступный системе.
Как 64 ГБ RAM и 56 ГБ под iGPU влияют на выбор модели и квантования
Память в такой конфигурации почти не ограничивает размер модели. Qwen3 в GGUF на 8, 14 или 32 млрд параметров спокойно ляжет в RAM целиком, даже с учётом контекста. Ограничитель другой: сколько токенов в секунду вы готовы терпеть.
Прикинуть размер файла можно по простой формуле: число параметров умножить на биты на вес и разделить на восемь. Ниже ориентировочные значения для модели на 8 млрд параметров, посчитанные именно так, а не взятые из чужого бенчмарка.
| Квантование | Биты на вес, примерно | Оценка размера для 8B | Когда брать |
|---|---|---|---|
| Q8_0 | 8,5 | около 8,5 ГБ | Если памяти много и хочется минимум потерь качества |
| Q5_K_M | 5,7 | около 5,7 ГБ | Компромисс, если Q4 даёт заметную деградацию |
| Q4_K_M | 4,8 | около 4,8 ГБ | Рабочая точка по умолчанию для первых опытов |
| Q3_K_M | 3,9 | около 3,9 ГБ | Когда нужен запас под длинный контекст |
Реальный размер файла всегда больше оценки: добавляются метаданные и тензоры, которые квантуются иначе. Актуальный размер смотрите в карточке конкретной модели на Hugging Face перед скачиванием.
Отдельная статья расходов, про которую забывают, это KV-кэш. Он растёт линейно с длиной контекста и складывается из числа слоёв, числа голов и размерности. На 8K токенов это сотни мегабайт, на 64K уже единицы гигабайт, особенно без квантования кэша. Для 780M контекст бьёт по скорости дважды: и через дополнительную память, и через вычисления на префилле. Практический разбор того, как квантование KV-кэша меняет поведение модели, есть в материале про запуск Qwen 3 с контекстом 200K+ на 16 ГБ VRAM, и логика там та же, меняется только железо.
Третий фактор, архитектура модели. У Qwen3 есть плотные варианты и MoE-версии вроде 30B-A3B, где на каждый токен активируется примерно 3 млрд параметров из 30. Для слабого вычислителя это интересно: считать нужно меньше, а качество выше, чем у плотной модели comparable размера. Плата за это в том, что все эксперты всё равно должны лежать в памяти, и на длинном контексте преимущество частично съедается. Как такие модели ведут себя на скромном железе, видно на примере сравнения MoE-моделей 35B, 120B и 176B на GTX 1080 Ti: размер и активные параметры важнее, чем абсолютное число в названии.
Какие движки пробовать на 780M: llama.cpp, LM Studio, Ollama
Выбор невелик, и это скорее хорошо. Почти всё сводится к llama.cpp и надстройкам над ним.
llama.cpp с Vulkan: почему это первый кандидат
Vulkan-бэкенд llama.cpp позволяет отдать слои встроенной графике через графический API, без CUDA и без ROCm. Сборка включается флагом GGML_VULKAN при конфигурации CMake, готовые бинарники под Windows и Linux обычно уже содержат этот бэкенд. Дальше работает знакомая ручка: --n-gpu-layers (сокращённо -ngl) задаёт, сколько слоёв уйдёт на GPU. Значение подбирается экспериментально, начиная с небольшого и увеличивая до момента, когда модель перестаёт помещаться или скорость падает.
Часть слоёв при этом останется на CPU, и это нормальный режим для iGPU. Гибридный инференс на встроенной графике и есть основной сценарий, а не аварийный. Отдельно проверяйте поддержку flash attention на Vulkan в вашей версии: она зависит от сборки и драйвера, и включать её вслепую не стоит.
LM Studio и Ollama: когда удобство важнее тонкой настройки
LM Studio даёт графический интерфейс и перебор моделей мышкой, внутри работает тот же llama.cpp. В настройках рантайма выбирается бэкенд, в том числе Vulkan, и это самый быстрый способ проверить, видit ли система iGPU и сколько слоёв она готова взять. Минус в том, что тонкие параметры вроде квантования KV-кэша или спекулятивного декодирования доступны не всегда и не в полном объёме.
Ollama стартует одной командой и хорошо подходит для первых запусков, но контроль над распределением слоёв и бэкендом у него ниже: многое решается автоматически, а поведение зависит от версии и платформы. На дискретной карте это обычно не мешает. На iGPU разница между «само выбрало Vulkan» и «само выбрало CPU» означает кратную разницу в скорости, и понять причину без логов бывает сложно.
ROCm и HIP на встроенной графике это отдельная история. Официальная поддержка ROCm в первую очередь нацелена на дискретные карты, а работа с iGPU зависит от версии, дистрибутива и иногда требует ручной правки окружения. Если хотите посмотреть, как выглядит рабочая связка llama.cpp и ROCm на дискретной Radeon, ориентируйтесь на разбор запуска Qwen 3.6 35B A3B на RX 7600 с ROCm 7, но не ждите, что те же флаги автоматически заработают на 780M.
«ngram на NVMe»: что это может значить и почему подтверждений нет
Честная формулировка: расшифровки у нас нет. Источник потерян, автор вопроса сам его не нашёл, а без деталей фраза допускает минимум три трактовки. Разберём каждую, чтобы вы понимали, что именно проверять.
Speculative decoding и prompt lookup: что это на самом деле
Идея спекулятивного декодирования простая. Черновой механизм предлагает несколько токенов вперёд, основная модель проверяет их за один проход и принимает те, что совпали с её собственным распределением. Если угадали, получаем несколько токенов по цене одного шага. Черновиком может быть маленькая модель, а может быть поиск по n-граммам.
Prompt lookup работает ещё проще: кандидаты ищутся как совпадения подстрок в уже имеющемся тексте, в промпте или в сгенерированном фрагменте. В llama.cpp есть примеры такой логики, а в серверной части набор параметров спекулятивного декодирования менялся от версии к версии, поэтому сверяйтесь с документацией своей сборки, а не с чужими постами годичной давности.
Важный нюанс: выигрыш сильно зависит от задачи. Правка кода, пересказ документа с цитатами, работа с RAG, где ответ во многом повторяет контекст, ускоряются хорошо. Свободная генерация на произвольную тему даёт мало попаданий, и накладные расходы могут съесть весь выигрыш. На iGPU с узким каналом памяти спекулятивное декодирование иногда окупается именно потому, что проверка нескольких токенов за один проход экономит чтения весов.
NVMe и mmap: где диск реально помогает, а где нет
NVMe в контексте LLM почти всегда означает одно: файл модели лежит на быстром SSD, а движок открывает его через mmap. Страницы подгружаются по мере обращения, старт получается быстрым, оперативная память расходуется не сразу. Это стандартная практика, а не хак.
Ускорения от этого не появляется. После первого прохода нужные страницы уже в page cache, и дальше скорость определяется RAM и вычислителем. Если модель не влезает в память и система начинает вытеснять страницы обратно на диск, генерация проваливается в разы. Флаг --no-mmap в таких случаях иногда помогает стабилизировать поведение ценой более долгой загрузки.
Вторая возможная трактовка: кэш промптов и KV-кэша на диске. llama.cpp умеет сохранять состояние и переиспользовать префикс, это экономит время на повторных запросах с одинаковым началом. К ускорению самой генерации отношения не имеет.
Как проверить гипотезу самостоятельно, не превращая её в инструкцию: возьмите одну модель и одно квантование, замерьте базовую скорость, затем включите доступные в вашей сборке параметры спекулятивного декодирования или lookup и замерьте снова на двух типах задач, свободной генерации и правке кода. Разницу в процентах запишите. Если её нет, фраза про ngram на NVMe к вашему железу отношения не имеет.
Пошаговый план: как самому проверить Qwen3 на 780M
Ниже последовательность, которая даёт воспроизводимый результат за один вечер. Она не обещает конкретных токенов в секунду, зато показывает, как их получить и не запутаться.
- Проверьте распределение памяти в прошивке. Попробуйте умеренный UMA frame buffer вместо максимального: если система отдаёт графике 56 ГБ, у неё остаётся меньше запаса под page cache и фоновые задачи. Замерьте оба варианта.
- Соберите llama.cpp с Vulkan или возьмите готовый бинарник с этим бэкендом. Альтернатива для быстрого старта: LM Studio с выбранным Vulkan-рантаймом.
- Скачайте GGUF Qwen3 для начала в Q4_K_M и в размере, который заведомо влезает: 8B хватит, чтобы понять поведение железа.
- Прогоните бенчмарк по числу слоёв на GPU.
llama-bench -m qwen3-8b-q4_k_m.gguf -ngl 0,10,20,99 -p 512 -n 128Числа в -ngl подставьте свои, ориентируясь на общее число слоёв модели. -p задаёт длину обработки промпта, -n длину генерации. Отдельно снимите результат с -ngl 0, это чистый CPU-режим и ваша точка отсчёта.
- Повторите замер с контекстом, который вам реально нужен: 4K, 8K, 16K. Скорость обработки промпта и генерации на длинном контексте отличается заметно.
- Ведите лог: модель, квантование, число слоёв на GPU, размер контекста, квантование KV-кэша, tok/s на промпте и на генерации, потребление памяти. Через пять строк вы увидите закономерность, которую ни один чужой пост не даст.
Для интерактивной работы удобнее llama-server с теми же флагами, тогда замеры делаются в привычном чате, а не в консоли.
Чего ожидать по скорости и где узкое место
Декодирование токена упирается в чтение весов из памяти. Грубая верхняя оценка скорости выглядит так: пропускная способность памяти, делённая на размер модели в байтах. Для модели на 5 ГБ и канала около 90 ГБ/с потолок выходит порядка 18 токенов в секунду, и это идеальный случай без накладных расходов, без KV-кэша и без конкуренции за память с системой. Реальная цифра будет ниже, иногда существенно.
Из этой арифметики следуют практические выводы. Модель 8B в Q4 на 780M имеет шанс дать читаемый интерактив. Модель 30B в Q4 уже в шесть раз тяжелее по чтению весов, и ожидать от неё комфортного чата не стоит. MoE-вариант частично спасает ситуацию за счёт меньшего числа активных параметров, но требует, чтобы все эксперты помещались в память.
Длинный контекст добавляет вторую нагрузку. Обработка промпта на 20-30K токенов на встроенной графике может занять минуты, и это нормальное поведение, а не сбой. Если рабочий сценарий требует больших вставок текста, планируйте время ожидания заранее.
Если iGPU не тянет: альтернативы для владельца мини-ПК
Вариантов несколько, и они не исключают друг друга.
- CPU-инференс на 7940HS. Восемь ядер Zen 4 с AVX-512 дают предсказуемый, хотя и небыстрый результат. Плюс: не нужно воевать с драйверами. Минус: скорость генерации на моделях 8B и выше обычно ощущается как медленная печать.
- Уменьшение модели или квантования. Переход с 14B на 8B и с Q5 на Q4 часто даёт больше, чем любая оптимизация флагов.
- eGPU через USB4 или OCuLink, если в мини-ПК есть подходящий порт. Дискретная карта снимает вопрос пропускной способности памяти, но добавляет вопрос цены, охлаждения и стабильности внешнего подключения.
- Внешний сервер или API. Для разовых задач дешевле, чем апгрейд, и не требует возни с драйверами.
- Гибридные схемы уровня APU плюс дискретная карта. Как это выглядит в проектах, где APU и GPU объединяют в одну систему, разобрано в материале про llama-halo-hybrid на Strix Halo и Radeon R9700: там другие бюджеты и другое железо, но логика раскладки слоёв переносится.
Итог: что делать владельцу 7940HS + 780M
Подтверждённого кейса запуска Qwen3 на Ryzen 7940HS с Radeon 780M в доступных источниках нет: есть вопрос пользователя с такой конфигурацией и потерянное упоминание про ngram, которого никто не расшифровал. Технически путь есть, и он лежит через llama.cpp с Vulkan-бэкендом и GGUF-модели Qwen3. Ключевое ограничение этой сборки не 64 ГБ ОЗУ и не 56 ГБ под iGPU, а пропускная способность памяти и скромное число вычислительных блоков.
Что сделать по порядку. Соберите или скачайте llama.cpp с Vulkan, прогоните llama-bench на модели 8B в Q4_K_M с разными -ngl, включая ноль, и запишите результат. Затем повторите замер с нужной вам длиной контекста. Фразу «ngram на NVMe» проверяйте отдельным тестом на спекулятивное декодирование, а не принимайте на веру: выигрыш возможен на повторяющемся тексте и почти исчезает на свободной генерации. Если после замеров скорость не устраивает, переходите к модели поменьше, CPU-режиму или внешней карте, вместо того чтобы искать волшебный флаг.