Комментарии 18
На сервере с GPU RTX PRO 4000 Blackwell (24 Gb) тоже сегодня сравнивал две модели в llama.cpp router: текущую продовую qwen36-nvfp4-turbo (Qwen3.6-35B-A3B) и новую ornith15-nvfp4 (Ornith-1.5-35B-A3B, квант NVFP4 Q5K, mmproj для vision, MTP). Условия одинаковые: температура 0.2, по два прогона на каждый промпт, контекст 32k.
Ornith сначала вообще не загрузилась. В логе llama.cpp ошибка на draft-модели frspec: тензор output.weight имел размерность 32768 вместо ожидаемых 248320 (vocab). Отдельный файл mtp-…-frspec-owngen32768.gguf оказался несовместим с текущей версией llama.cpp. Решение такое же, как у Qwen: убрали model-draft из пресета, потому что MTP уже вшит в основной файл *-mtp.gguf. После этого Ornith нормально поднялась.
По скорости Qwen выиграл на всех содержательных промптах примерно в полтора–два раза. На коротком «ответь одним словом» разницы почти нет (0.11 с у обоих). На продуктовом промпте Qwen генерировал около 139 tok/s за 0.9 с, Ornith — 81 tok/s за 1.9 с. На RAG-стиле (проблема, три причины списком) — 156 против 85 tok/s, 1.2 с против 2.7 с. На JSON-задаче разрыв самый большой: 181 против 81 tok/s, 0.2 с против 0.9 с. MTP accept у Qwen на длинных ответах тоже лучше (например, 74/156 против 51/498 на rag-промпте).
По качеству картина другая, но не в пользу Ornith как замены prod. Qwen короче и точнее следует инструкции. На «кратко объясни клиенту про проблему» дала компактный абзац на три–четыре предложения. Ornith развернула ответ с заголовками, списками и пояснением терминов — смысл тот же, но ответ в полтора раза длиннее. На «верни только JSON с steps ["a","b","c"]» Qwen вернула ровно то, что просили. Ornith сохранила JSON-обёртку, но вместо букв a, b, c подставила три полноценных предложения. Для RAG и API, где важны краткость и предсказуемый формат, это минус. Ornith сильнее там, где нужен «разговорный» текст с markdown-структурой — но это решается промптом, а не сменой модели.
Итог: prod оставил на qwen36-nvfp4-turbo. ornith15-nvfp4 остаётся для ручных и vision-экспериментов, но в проде переключаться не стал.
Про PRO 4000 интересно, спасибо, долго на нее смотрел в ДНС: 179к -> 219к -> 249к буквально за месяц. сейчас останавливает шина/bandwidth, выглядит интереснее взять 3090 чем платить 249к.
Qwen искренне смущает своим философским подходом к любому заданию :)
В Ornith по моему советуют сейчас MTP отключать, посмотрите.
Пустой ответ на генерацию Ansible-плейбука в 2-битном кванте -это не баг. Модель просто сжалась до уровня, когда осознала всю тщетность бытия девопса и решила промолчать, чтобы не расстраивать автора.
Спасибо за замеры. Таблица по VRAM и реальному контексту отличная, заберу в закладки. За инфу по 2-битным квантам отдельный респект, избавили от желания экспериментировать с IQ2)))

🧠 MoE (Mixture of Experts) — эксперты, а не обычная dense-модель.
👁️ Мультимодальная — вероятно, работает с текстом и визуальными данными.
⚡ Flash — приоритет на скорость и эффективность.
🧬 Next — используется новая архитектура, которая станет основой будущего семейства Qwen4.
Про пустые ответы на UD-IQ2_XXS: прежде чем списывать их на квант, я бы посмотрела raw-выдачу — генерация нулевой длины и «сгенерировался стоп-токен первым» выглядят в API одинаково, но чинятся по-разному, и на агрессивных квантах второе встречается заметно чаще. Второе: 22/22 почти во всех строках означает, что набор задач не разделяет конфигурации — метрика насыщена, и деградацию на ней не увидеть в принципе, поэтому вывод «Q5/Q6 достаточно» держится скорее на отсутствии сигнала, чем на его наличии. Не планируете добить набор десятком задач, где ошибается хотя бы треть конфигураций, и прогнать каждую в 3-5 сидов?
То же самое хотел написать, из этого набора задач можно сделать вывод "9B модели хватит всем и для всего", что, очевидно, не так.
Это первое, второе - мерить только генерацию токенов без префилла? Ну, у всех, конечно, свои сценарии работы, но агентский сейчас как минимум один из самых популярных, стартовый контекст агента - десятки тысяч токенов, без метрики pp сравнение ведеокарт мягко говоря неполное.
я соглашусь, вчера интересный пост был на HN, разбирал у себя отдельно уже после того как выпустил статью: https://daniel.csylabs.com/ru/2026-08-25-prefill-decode-apple-m5-ultra-ru
про 9В - честно говоря я очень серьезно задумываюсь, чтобы дать больше нагрузку на эту модель
На моём железе - локальный сервер (rtx)
GPU: 2× RTX 3060 12GB.
CPU: i7-4820K.
RAM: 32GB DDR3 (4x8GB).
MB: ASUS P9X79 LE.
OS: MX Linux 25.2 XFCE (systemd)
На тестовой задаче результаты такие:
/usr/local/bin/llama-server -m /srv/models/Tiel-Coder-35B-A3B-MTP-UD-Q3_K_XL/Tiel-Coder-35B-A3B-MTP-UD-Q3_K_XL.gguf -t 6 -c 131072 -b 2048 -ngl 999 --host 0.0.0.0 --port 8080 --parallel 1 --tensor-split 68,60 --spec-type draft-mtp --temp 0.55 --top-p 0.95 --top-k 40 --min-p 0.05 --repeat-penalty 1.0 -ctk q8_0 -ctv q8_0 --kv-unified -fa on -ub 1536 --load-mode mmap --jinja
авг 26 17:20:59 rtx run-llama.sh[29548]: 3.05.093.583 I slot print_timing: id 0 | task 2 | prompt eval time = 834.40 ms / 794 tokens ( 1.05 ms per token, 951.58 tokens per second)
авг 26 17:20:59 rtx run-llama.sh[29548]: 3.05.093.590 I slot print_timing: id 0 | task 2 | eval time = 77149.87 ms / 6092 tokens ( 12.67 ms per token, 78.95 tokens per second)
авг 26 17:20:59 rtx run-llama.sh[29548]: 3.05.093.591 I slot print_timing: id 0 | task 2 | total time = 77984.26 ms / 6886 tokens
авг 26 17:20:59 rtx run-llama.sh[29548]: 3.05.093.604 I slot print_timing: id 0 | task 2 | graphs reused = 2510
авг 26 17:20:59 rtx run-llama.sh[29548]: 3.05.093.609 I slot print_timing: id 0 | task 2 | draft acceptance = 0.46848 ( 3560 accepted / 7599 generated), mean len = 2.41
авг 26 17:20:59 rtx run-llama.sh[29548]: 3.05.093.709 I slot release: id 0 | task 2 | stop processing: n_tokens = 6887, truncated = 0

Селф-хост Ornith-1.5 и Qwen3.8: тестирую 18 квантов на одной карте и похоже не покупаю RTX5090