Как мы запустили Ornith‑35B на ноутбуке с 8 ГБ VRAM и разогнали её до 99 ток/с на AMD Strix Halo

Согласно опубликованным бенчмаркам, Ornith‑1.0‑35B показала себя лучше Qwen3.5‑397B‑A17B в тех тестах, где модель должна не просто написать код, а самостоятельно работать в терминале и пользоваться инструментами. На Terminal‑Bench 2.1 с Terminus‑2 разница составила 64,2% против 53,5%.

Ornith не сильнее Qwen во всех задачах: на SWE‑bench Verified, SWE‑bench Pro, NL2Repo и ClawEval Qwen немного впереди. Но для локального coding‑агента результат выглядел интересно. Ornith занимает на порядок меньше памяти и обучалась именно под agentic coding — работу с терминалом, инструментами, памятью и повторными попытками после ошибок.

Мы проверили модель на открытом срезе из 43 задач. В него вошли tool calling, генерация кода, исправление репозиториев, работа с памятью и длинным контекстом:

Локальный прогон подтвердил, что модель хорошо подходит для агентного кодинга.

После этого появилась другая мысль: Ornith явно можно ускорить на Ubuntu‑машине с Ryzen AI MAX+ 395, Radeon 8060S и пропускной способностью памяти до 256 ГБ/с.

Модель занимала около 19–21 ГБ, помещалась в общей памяти целиком, но выдавала только 68–74 ток/с.

Для увеличения скорости нужно было перебрать следующие гипотезы:

• изменить K‑quant matvec и число строк, обрабатываемых одним Vulkan dispatch;

• объединить MUL_MAT_ID dispatch и подобрать размер workgroup;

• проверить graphics queue вместо compute queue;

• подобрать batch и ubatch;

• уменьшить KV‑cache с Q8 до Q4;

• добавить MTP и подобрать глубину draft;

• селективно переквантовать самые тяжёлые expert‑тензоры;

• использовать exact n‑gram reuse на повторяющемся agent/code‑трафике.

Один Vulkan‑патч дал меньше процента. Рабочий результат получился только из комбинации MTP, n‑gram reuse, селективной квантизации и настроек runtime: 79,661 ток/с на полном 43‑task прогоне и 99,088 ток/с на повторяемом code‑потоке без потери балла.

Железо и исходная скорость

Для получения убедительного результата в работе участвовали две разные машины:

На сервере модель целиком помещалась в общей памяти CPU и Radeon. Это избавляло от PCIe paging, но не превращало DDR5 в HBM. Ornith — MoE‑модель: на каждом токене включается только часть экспертов, однако их веса всё равно приходится читать из памяти. При batch 1 арифметики относительно мало, а чтений много. В результате GPU может показывать высокую загрузку, пока decode ограничен трафиком весов, деквантизацией и маршрутизацией экспертов.

В первом общем замере исходный Ornith-1.0-35B-Q4_K_M выдавал около 68,7 ток/с на длинном decode. После обновления llama.cpp и выравнивания параметров короткий контрольный тест показал 74,066 ток/с. Напрямую сравнивать эти значения нельзя: бинарники и конфигурации различались. Все проценты дальше относятся только к парным A/B‑прогонам.

Целью был максимально быстрый batch‑1 decode при контексте 131 072 и сохранении качества на агентных задачах. Для сравнения изменений использовались только парные A/B‑прогоны.

Чтобы не получить красивую цифру только на коротком тесте, мы использовали одинаковые prompt, прогрев, повторные запуски и серверную метрику timings.predicted_per_second. На полном агентном прогоне считался weighted decode:

weighted_decode = сумма сгенерированных токенов / сумма decode-времени

Если просто усреднить скорости запросов, короткие ответы получают слишком большой вес. Здесь все токены делятся на всё фактическое время генерации.

Качество проверялось на том же срезе Orion с одинаковыми task ID и offset. Состав и исходный результат приведены в таблице в начале статьи.

Все изменения Vulkan перед замерами проходили test-backend-ops: 3160 успешных тестов для четырёх значений row merge и ещё 790 для отдельного MUL_MAT_ID‑патча.

Попытки ускорить Ornith на Ubuntu

Логично было начать с matvec: MoE постоянно читает квантованные expert weights, значит небольшой выигрыш в K‑quant ядре должен повторяться на каждом токене. В форк добавили runtime‑переключатель GGML_VK_DMMV_RM_KQ, чтобы проверять row merging 1/2/4/8 без пересборки.

В изолированном тесте без MTP rows=1 показал 75,886 против 75,400 ток/с чистого b9994 — всего +0,64%. После включения MTP профиль нагрузки изменился, и лучшим снова оказался исходный rows=2:

Укрупнение tile уменьшает число dispatch, но увеличивает live state и давление на регистры. На RDNA это снижает число одновременно работающих waves, поэтому «больше строк за раз» не обязательно быстрее.

Другие варианты тоже не дали нужного скачка:

Один Vulkan‑патч не мог дать целевые 96 ток/с, потому что почти не менял главный объём работы — чтение весов экспертов. Измерительный переключатель и отрицательные результаты остались в форке, но выдавать доли процента за большой прорыв не имело смысла.

Затем проверили очередь и размер ubatch. При ubatch=1024 graphics queue оказалась быстрее стандартной compute queue:

Самый большой ubatch не победил:

В рабочем профиле остались:

GGML_VK_ALLOW_GRAPHICS_QUEUE=1GGML_VK_DISABLE_COOPMAT=1GGML_VK_MAX_NODES_PER_SUBMIT=50

--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

Логично было попробовать и Q4 KV‑cache: меньше байт должно помочь на длинном контексте. На 62 630 входных и 512 выходных токенах результат оказался хуже:

Q4 проиграл 7,5% по prefill и 3,7% по decode. Для этого Vulkan backend экономия памяти не покрыла стоимость деквантизации и работы с scale/metadata, поэтому в production остался Q8. На CUDA, HIP или Metal результат может быть другим.

Что действительно сработало

После опытов с ядрами стало понятно, что нужно не быстрее выполнять тот же объём работы, а уменьшать его.

Первой частью стала совместимая MTP‑головка. Ornith и Qwen3.6‑35B‑A3B MTP‑only используют архитектуру qwen35moe. Скрипт graft-ornith-mtp.py берёт дополнительный prediction‑слой из MTP‑GGUF, проверяет имена тензоров, копирует базовые блоки и записывает nextn_predict_layers=1. Это не fine‑tuning и не новая обученная модель: к target добавляется совместимая голова для speculative decoding.

Глубокий draft здесь оказался невыгоден. Для MoE лишние draft‑токены способны включить новые маршруты экспертов, которые target потом всё равно должен проверить. Лучшей стала глубина 2. Порог p_min тоже выбирался замерами:

Финальные параметры speculation:

--spec-type ngram-mod,draft-mtp--spec-draft-n-max 2--spec-draft-n-min 1--spec-draft-p-min 0.20--spec-ngram-mod-n-min 48--spec-ngram-mod-n-max 64--spec-ngram-mod-n-match 24

Вторая часть — селективная квантизация. Двадцать ffn_down_exps‑тензоров перевели в Q4_0, остальные оставили по плану Q4_K_M. Target уменьшился с 20 681,07 до 19 377,09 MiB, средняя плотность — с 4,89 до 4,58 BPW.

llama-quantize \  --tensor-type-file scripts/ornith-down-experts-q4_0.txt \  ornith-1.0-35b-MTP-graft-Q4_K_M.gguf \  ornith-1.0-35b-MTP-graft-down-Q4_0.gguf \  Q4_K_M

Финальный файл:

ornith-1.0-35b-MTP-graft-down-Q4_0.gguf20 329 342 112 bytes (18,933 GiB)SHA-256: 365a7c02dfd320b9696f189d6dc12bd2b0eabb9f8e58ba9fc8cab3af93c0234b

Третья часть — exact n‑gram reuse. Агент постоянно повторяет system prompt, tool schemas, фрагменты кода и вывод инструментов. ngram-mod предлагает уже встречавшуюся последовательность, а target её проверяет. В одном SWE‑turn aggregate acceptance достиг 93,5%, в среднем принимался 61 n‑gram токен, а короткие интервалы доходили до 155–176 ток/с. На новом нерегулярном 11K‑ответе было около 65 ток/с. Поэтому 177,48 ток/с — реальный пик, но не постоянная скорость модели.

Speculative decoding остаётся target‑verified: ошибочный draft отклоняется. Селективная квантизация, напротив, меняет сам target численно, поэтому после неё обязательно требовался отдельный тест качества.

Результат на Ubuntu

По шагам скорость складывалась так:

99 ток/с — среднее пяти прогонов повторяемого code‑потока, а не новая нижняя граница. Для production важнее полный одинаковый прогон 43 задач:

Wall time сократился вдвое, но приписывать все 50,2% только быстрому decode нельзя. Агент прошёл разные траектории: запросов было 232 против 223, изменилось число входных и выходных токенов. Сопоставимая цифра здесь — +29,6% weighted decode.

По классам качество не изменилось:

В SWE Multilingual hybrid хотя бы дошёл до grader вместо AGENT_DEAD, но балл остался нулевым. Общий итог обеих версий — 40,8333/43.

После Ubuntu — перенос на Windows

Когда профиль стабильно заработал на Ubuntu, логично было попробовать ту же модель на обычном ноутбуке. Здесь задача была уже не приблизиться к пропускной способности памяти, а вообще разумно разместить 35B при 8 ГБ VRAM и получить пригодную для работы скорость.

Сначала собрали и запустили патченный Vulkan‑вариант llama.cpp под Windows. Модель загрузилась, а настройки дали небольшой прирост, но повторить Ubuntu‑эффект было невозможно: здесь всё определяло размещение 35B между 8 ГБ VRAM и системной памятью. Для численного A/B использовали официальный CUDA‑контейнер b10066 — так baseline и hybrid сравнивались на одном runtime.

Обычный split на 15 GPU layers выглядел терпимо только на коротком prompt. На реалистичном 1K скорость падала примерно до 1,2 ток/с: MoE‑эксперты оказывались разрезаны между CPU и GPU, и обмен данными съедал весь throughput.

Рабочей оказалась другая схема:

--ctx-size 16384--parallel 1--n-gpu-layers all--cpu-moe--no-mmap--batch-size 2048--ubatch-size 512--flash-attn on--cache-type-k q8_0--cache-type-v q8_0

Attention и плотные части остаются на RTX 4060, крупные MoE‑эксперты — в host RAM. Модель не помещается целиком в VRAM, но перестаёт постоянно гонять промежуточные данные через неудачную границу слоёв.

На официальном CUDA‑контейнере llama.cpp b10066 (86a9c79f8) получились такие значения; везде генерировалось по 128 токенов:

Первый baseline 1K — холодный выброс из‑за expert cache/thrashing, поэтому обещать ускорение в 5,3 раза по нему нельзя. На более показательных 8K hybrid без speculation быстрее baseline на 23,8%, а на repeated code — на 21,8%. MTP особенно хорошо работает на предсказуемом потоке, но на коротком неповторяемом 1K оказался на 3,2% медленнее no‑spec.

По ресурсам схема спокойно уложилась в доступные 8 ГБ VRAM. Host RAM ниже — память всей системы, не только RSS процесса:

Hybrid‑файл на 798,6 MiB меньше baseline. MTP добавил около 438 MiB VRAM относительно no‑spec, но общий расход остался небольшим.

После raw‑тестов прогнали четыре одинаковых workspace с теми же prompt, verifier, approval=auto, лимитом 24 шага и timeout 900 секунд:

Обе версии пропустили одни и те же проверки cli_exit_zero и final_contract: изменения и deterministic tests были выполнены, но агент завершил цикл без обязательного финального контракта Orion. Это общий сбой завершения агента, а не регрессия новых весов.

LM Studio не приняла полную модель

После удачного запуска через llama.cpp попробовали открыть тот же GGUF в LM Studio. Полная версия не загрузилась: runtime LM Studio 2.14.0 не поддержал MTP metadata и дополнительный prediction‑слой.

Просто переименовать metadata было нельзя. Получился бы файл, который, возможно, открывается, но неверно интерпретирует структуру модели. Поэтому для LM Studio пришлось убрать MTP‑голову и оставить тот же селективно оптимизированный 40‑слойный target:

Это не другая обученная модель и не ухудшенная копия весов. Из неё удалена только часть, которую текущий runtime LM Studio не умеет использовать. Цена совместимости — отсутствие speculative boost.

Нативный /api/v0/completions в LM Studio показал:

LM Studio был быстрее b10066 no‑spec на том же наборе тензоров по raw decode: +12,7% на 1K, +17,5% на 8K и +24,3% на repeated code. Но в Orion картина оказалась другой:

Качество снова совпало, но end‑to‑end время выросло. Orion повторял verification‑guard шаги, а Java‑сценарий дошёл до внешнего timeout уже после изменений и тестов. Это одна из причин не ранжировать агентные runtime только по tok/s.

Все финальные профили в одной таблице

Где результаты могут отличаться

Тестировались один Strix Halo и один ноутбук; на Ubuntu использовался llama.cpp b9994, на Windows — b10066 и LM Studio 2.14.0. Основной quality‑срез содержит 43 задачи, ноутбучный — четыре coding‑сценария. Повторяемый code‑тест запускался пять раз.

99 ток/с — результат предсказуемого потока, не скорость на любом запросе. При prompt 62,6K получилось 70,29 ток/с, а на 128K значение может быть ещё ниже. Время агентной задачи зависит также от числа шагов, инструментов, verifier и timeout.

Target‑verified speculation не меняет принятый вывод модели, но селективная квантизация меняет сам target — поэтому понадобился отдельный quality A/B. Полностью сопоставимого энергетического A/B для финального Ubuntu‑профиля нет, поэтому улучшение энергоэффективности не заявляется.

Код, модели и логи

Новые замеры и практические рецепты запуска, cсылки на полную MTP‑версию и отдельный GGUF для LM Studio публикуются в Telegram‑канале Vibe Orion.

Что получилось в итоге

В начале мы ожидали, что основное ускорение придёт из Vulkan. Оно оказалось почти незаметным. Для batch‑1 MoE важнее было сократить движение весов и не заставлять target заново генерировать то, что можно безопасно предсказать или точно взять из контекста.

На Ubuntu комбинация MTP, n‑gram reuse, селективной квантизации и настроек runtime дала +29,6% weighted decode без изменения балла 43‑task среза. После этого ту же модель удалось запустить на Windows‑ноутбуке с 8 ГБ VRAM: --cpu-moe сократил время четырёх coding‑задач на 21,2% при том же качестве. Для LM Studio пришлось убрать встроенную MTP‑голову и выпустить отдельный совместимый GGUF.

Полезный результат этой работы — понимание из чего складывается прирост, на каких запросах он исчезает и какой профиль можно оставить работать на сервере каждый день.