Запуск крупных языковых моделей локально долгое время считался уделом машин с мощными дискретными видеокартами. Тест на ASUS Vivobook S 16 M3607HA — ноутбуке с AMD Ryzen 7 260, встроенной Radeon 780M и 32 ГБ DDR5-5600 — показывает, что 20-миллиардная модель openai/gpt-oss-20b в формате MXFP4 GGUF на таком железе работает, хотя и с оговорками.

GPT-OSS 20B — открытая модель OpenAI с 20 миллиардами параметров. Формат GGUF используется в экосистеме llama.cpp и совместимых инструментах, в том числе LM Studio, и позволяет запускать модели на CPU и интегрированной графике без специализированных фреймворков. MXFP4 — один из агрессивных форматов квантизации: веса модели хранятся в 4-битном представлении, что существенно снижает требования к памяти по сравнению с полноточными вариантами. Без квантизации 20B-модель потребовала бы порядка 40 ГБ только для весов — на 32 ГБ RAM это невозможно.

Context LengthPromptНазначениеtok/secСгенерировано токеновИспользовано контекста
16384Prompt 1Базовая скорость + фактология9,98153211,9%
16384Prompt 2Reasoning + код9,32207621,9%
16384Prompt 3Удержание контекста8,6674428,2%
32768Prompt 1Базовая скорость + фактология10,0416566,3%
32768Prompt 2Reasoning + код9,17248612,6%
32768Prompt 3Удержание контекста8,05151818,2%
65536Prompt 1Базовая скорость + фактология10,638682,0%
65536Prompt 2Reasoning + код9,4918445,0%
65536Prompt 3Удержание контекста8,5412607,3%

Тест проводился через LM Studio 0.4.16 с фиксированными настройками: GPU Offload 20, 8 потоков CPU, Evaluation Batch Size 512. Менялся только лимит контекста — 16384, 32768 и 65536 токенов. Для каждого значения прогонялись три сценария: проверка фактологии с контрольными маркерами, написание Python-скрипта для потоковой обработки многогигабайтного лог-файла и самоаудит предыдущего ответа.

Пик потребления RAM: 27,6 ГБ при контексте 16384, 28,7 ГБ при 32768 и 30,0 ГБ при 65536 из 31,3 ГБ доступных.

Скорость генерации оказалась стабильной: от 8,05 до 10,63 tok/sec в зависимости от сценария, средняя по всем прогонам — около 9 tok/sec. Примечательно, что увеличение лимита контекста с 16384 до 65536 не привело к заметному замедлению. Средние значения по трём сценариям составили 9,32 tok/sec для 16384, 9,09 tok/sec для 32768 и 9,55 tok/sec для 65536. Автор оговаривается, что разница статистически незначима: при большем контексте ответы оказались короче, а фактически использованная часть окна — меньше.

Главным ограничителем стала RAM. Radeon 780M работает на shared memory — она не имеет собственной видеопамяти и использует общую оперативную память системы. Это означает, что 32 ГБ делятся между Windows, моделью и встроенной графикой одновременно. При контексте 65536 пиковое потребление достигало 30,0 ГБ из доступных 31,3 ГБ — свободного остатка почти не остаётся для фоновых задач. При контексте 16384 пик составлял 27,6 ГБ, что оставляет чуть больше пространства для манёвра.

С практической задачей — написанием Python-скрипта для потоковой обработки лог-файлов с поддержкой argparse, подсчётом HTTP-статусов, IP-адресов и строк с ERROR/WARNING — модель справилась. Однако в сценарии самоаудита допускала ошибки: неточно воспроизводила собственные предыдущие ответы и характеристики железа. Больший лимит контекста сам по себе не улучшил качество ответов.

Для сравнения: 9 tok/sec — это примерно 540 слов в минуту, что вполне комфортно для чтения и итеративной работы с кодом, хотя заметно медленнее облачных API. Аналогичные по размеру модели (Llama 3.1 70B, Mistral Large) на том же железе были бы недоступны даже в квантизованном виде — они требуют минимум 40–48 ГБ RAM. 20B-класс с агрессивной квантизацией сейчас фактически является верхней границей для ноутбуков с 32 ГБ.

Вывод из теста практический: запускать openai/gpt-oss-20b MXFP4 на ноутбуке с 32 ГБ RAM без дискретной видеокарты можно. Комфортнее работать с контекстом 16384 или 32768 — при 65536 запас памяти становится слишком маленьким для параллельной работы браузера или других приложений. NPU в тестах не задействовался, диск нагружался менее чем на 1%.