Нейросети на ноутбуке: 35-миллиардная модель выдаёт 99 токенов/с без видеокарты

Энтузиаст из сообщества llama.cpp опубликовал подробный разбор того, как разогнать Ornith-1.0-35B на машине с процессором Ryzen AI MAX+ 395 и встроенной графикой Radeon 8060S. Исходная скорость модели составляла 68-74 токена в секунду, а после серии экспериментов удалось выжать 99 токенов в секунду на повторяемом коде и почти 80 на полном агентном прогоне из 43 задач. При этом качество ответов не пострадало.

Для тех, кто работает с нейросетями на ноутбуке, это конкретный рецепт: какие ручки крутить, что бесполезно, а что реально ускоряет инференс (генерацию ответа моделью) на доступном железе.

Что понадобится

• Железо: процессор AMD Ryzen AI MAX+ 395 (или аналог с интегрированной графикой Radeon и общей памятью CPU/GPU), минимум 24 ГБ оперативной памяти, пропускная способность до 256 ГБ/с
• Операционная система: Ubuntu (Linux)
• Софт: llama.cpp с поддержкой Vulkan backend, актуальная сборка из репозитория
• Модель: Ornith-1.0-35B в квантизации Q4_K_M (занимает 19-21 ГБ)
• Дополнительно: скрипт graft-ornith-mtp.py для подключения MTP-головки (speculative decoding, когда модель заранее «угадывает» следующие токены и проверяет их пачкой)
• Время: несколько часов на эксперименты с параметрами, сама настройка занимает минуты

Пошаговая инструкция

1. Установите llama.cpp с Vulkan backend. Соберите актуальную версию из репозитория с поддержкой Vulkan. Убедитесь, что test-backend-ops проходит успешно (в описанном эксперименте прошли 3160 тестов).

2. Скачайте модель Ornith-1.0-35B-Q4_K_M. Квантизация Q4_K_M (сжатие весов модели до 4 бит с сохранением качества) позволяет уместить 35-миллиардную модель в 19-21 ГБ общей памяти.

3. Настройте базовые параметры запуска. Используйте следующую конфигурацию:

GGML_VK_ALLOW_GRAPHICS_QUEUE=1 \
GGML_VK_DISABLE_COOPMAT=1 \
GGML_VK_MAX_NODES_PER_SUBMIT=50 \
./llama-server \
  --ctx-size 131072 \
  --parallel 1 \
  --batch-size 2048 \
  --ubatch-size 1024 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --n-gpu-layers all \
  --device Vulkan0 \
  --no-mmap

1. Используйте graphics queue вместо compute queue. Параметр GGML_VK_ALLOW_GRAPHICS_QUEUE=1 при ubatch=1024 дал прирост по сравнению со стандартной compute-очередью. Самый большой ubatch при этом не победил: 1024 оказался оптимальным значением.

2. Оставьте KV-cache на Q8, не переключайте на Q4. Эксперимент показал, что Q4 KV-cache проиграл 7,5% по prefill (обработке входного контекста) и 3,7% по decode (генерации). Экономия памяти не покрыла стоимость деквантизации на Vulkan backend.

3. Подключите MTP-головку для speculative decoding. Скрипт graft-ornith-mtp.py берёт дополнительный prediction-слой из MTP-GGUF файла, проверяет имена тензоров, копирует базовые блоки и записывает параметр nextn_predict_layers=1. Это не дообучение (fine-tuning), а подключение совместимой головки, которая позволяет модели «предсказывать» сразу несколько следующих токенов.

4. Включите n-gram reuse для повторяющегося кода. На агентных задачах, где модель часто генерирует похожие конструкции (вызовы инструментов, шаблоны кода), точное повторное использование уже сгенерированных n-грамм (последовательностей токенов) даёт заметный прирост.

5. Селективно переквантуйте самые тяжёлые expert-тензоры. Не все эксперты в MoE-модели одинаково чувствительны к точности: некоторые можно сжать сильнее без потери качества.

6. Замеряйте только парными A/B-прогонами. Используйте одинаковые промпты, прогрев, повторные запуски и серверную метрику timings.predicted_per_second. Итоговую скорость считайте как weighted decode: сумма сгенерированных токенов делится на сумму времени генерации.

Что НЕ сработало и почему это полезно знать?

Далеко не все гипотезы дали результат. Вот что оказалось тупиком:

• Row merging в K-quant matvec: перебор значений rows=1/2/4/8 через параметр GGML_VK_DMMV_RM_KQ дал прирост менее одного процента. На архитектуре RDNA укрупнение tile уменьшает число dispatch-вызовов, но увеличивает давление на регистры и снижает число одновременно работающих waves (параллельных потоков вычислений на GPU).
• Патчи отдельных Vulkan-ядер: каждый по отдельности давал доли процента, потому что основное узкое место не в вычислениях, а в чтении весов экспертов из памяти.
• Q4 KV-cache: на этом конкретном Vulkan backend не окупился. Автор эксперимента отмечает, что на CUDA, HIP или Metal результат может быть другим.

Рабочий результат получился только из комбинации MTP, n-gram reuse, селективной квантизации и настроек runtime.

Ornith-1.0-35B обошла модель в 10 раз крупнее на агентных задачах

Отдельно стоит сказать о самой модели. По опубликованным бенчмаркам, Ornith-1.0-35B набрала 64,2% на Terminal-Bench 2.1 (с Terminus-2) против 53,5% у Qwen3.5-397B-A17B, модели, которая в 11 раз больше по числу параметров.

Ornith обучалась именно под агентный кодинг: работу с терминалом, инструментами, памятью и повторными попытками после ошибок. На других бенчмарках (SWE-bench Verified, SWE-bench Pro, NL2Repo, ClawEval) Qwen немного впереди, но для локального ИИ-агента, который живёт на вашей машине, компактность и заточенность Ornith перевешивают.

Что делать с этим прямо сейчас?

Авторам Дзена и копирайтерам: если вы используете локальные нейросети на ноутбуке для генерации черновиков или рерайта, описанные настройки llama.cpp применимы к любой MoE-модели, не только к Ornith. Разница между 68 и 99 токенами в секунду на практике означает, что текст на 2000 слов генерируется за секунды, а не за минуту.

Разработчикам и техническим предпринимателям: полный набор параметров запуска из инструкции выше, это готовый конфиг для агентного кодинга без облака. Ornith помещается в 21 ГБ, а значит, работает на машинах с 32 ГБ общей памяти.

Тем, кто в России и СНГ: облачные API от OpenAI и Anthropic доступны с ограничениями и через посредников. Локальный запуск нейросети на ноутбуке с AMD снимает зависимость от VPN и подписок. Из российских облачных альтернатив для кодинга есть YandexGPT и GigaChat, но ни одна из них пока не заточена под агентные задачи с терминалом так, как Ornith.

Комбинация MTP, n-gram reuse и селективной квантизации превратила 35-миллиардную модель из медленного эксперимента в рабочий локальный инструмент: 80 токенов в секунду на разнородных задачах, 99 на повторяемом коде, ноль зависимости от облака и подписок.