По сообщению пользователя r/LocalLLaMA, Qwen выпустила модель decision-model-preview. Официального анонса нет: в посте упоминается страница документации, а открытых весов у модели тоже нет, в заголовке темы прямо стоит «No open weights yet». Связь с Jev, вокруг которого в 2026 году было много обсуждений, автор подаёт как предположение, а не как заявление компании. Исходный пост опубликован 27 сентября 2026 года.
Второй слой новости практический: тот же пользователь протестировал модель через сторонний облачный сервис AIHubMix и остался недоволен. Средний round-trip около 645 мс против примерно 439 мс у его локального роутера, жёсткий лимит в 16 вопросов на запрос, частые 429 Too Many Requests и два провала на тестах японской грамматики. Все эти цифры описывают опыт одного человека и вывод его агента, независимого тестирования не было.
Что случилось: Qwen decision-model-preview без анонса и открытых весов
Название decision-model-preview читается буквально: decision-модель в статусе preview, то есть предварительной версии. Что именно она умеет, в источнике не раскрывается: описания функциональности, архитектуры и списка поддерживаемых задач там нет. Всё, что известно о поведении модели, получено одним пользователем через сторонний прокси.
Случаи, когда сообщения о новых моделях Qwen появлялись раньше официальных подтверждений, в проекте разбирались отдельно: какие сигналы о Qwen 3.8 действительно что-то подтверждают. Схема та же: сообщество видит сигнал, а компания его не комментирует. Похожая история была со страницей Qwen 3.8-27B на ModelScope, которая отдавала 404: технический сбой или перенос релиза.
Почему это связывают с Jev
Jev, проект decision-моделей, который продвигают как отдельный класс решений, собрал вокруг себя заметный хайп. Локальная модель автора поста называется oc/jev-1.13-free, то есть человек уже работает в этой логике. Предположение строится просто: если вокруг одного подхода к decision-задачам идёт шум, крупный игрок отвечает своей моделью в том же классе. Заголовок поста формулирует это прямым текстом: «Qwen company already rushed out a Jev competitor». Официального заявления Qwen о связи двух проектов нет, так что перед вами трактовка автора, а не подтверждённый факт.
Что подтверждено, а что нет
Подтверждено:
- существует пост в r/LocalLLaMA от 27 сентября 2026 года с описанием модели decision-model-preview;
- автор указывает, что видел страницу документации модели;
- автор описывает тесты через AIHubMix и приводит конкретные цифры, коды ошибок и оценки.
Не подтверждено:
- официальный анонс Qwen и любые комментарии компании;
- характеристики модели: размер, архитектура, контекстное окно, режимы работы;
- условия доступа и статус открытости весов;
- какой именно чекпоинт или снапшот отвечает на запросы под именем decision-model-preview.
Разделение фактов и трактовок здесь принципиально. Если вам нужна модель для продакшена, строить план на одном посте Reddit рано: сначала появится официальная информация, потом независимые замеры.
Тест через AIHubMix: задержки, лимиты и ошибки 429
Тестирование шло через AIHubMix, сторонний облачный сервис с API-ключом. Автор отдельно просит платформу не использовать, поэтому все претензии ниже относятся к связке «модель плюс этот прокси», а не к одной модели. AIHubMix не официальный эндпоинт Qwen, цифры взяты из его замеров.
Что такое round-trip и почему 645 мс — это много
Round-trip — время от отправки запроса до получения полного ответа, включая сеть и установку TLS-соединения. У AIHubMix средний показатель составил 644,9 мс, разброс от 473 до 882 мс. Локальный роутер автора 9router выдаёт около 439 мс. Разница примерно 200 мс.
В одиночном чате такое отставание почти незаметно. В агентных сценариях, где на одну задачу уходит 10-20 вызовов модели, лишние 200 мс на каждом дают 2-4 секунды дополнительного ожидания, а при переборе вариантов задержка накапливается. Разброс до 882 мс усложняет и планирование таймаутов.
Лимит в 16 вопросов и 429: как это ломает рабочий процесс
Прокси отклоняет запросы, в которых больше 16 вопросов. В посте приводится конкретный ответ сервера: запрос с 19 вопросами получил 400 Bad Request с текстом «questions: 19 exceeds the limit of 16». Для пакетной обработки, когда в одном вызове нужно разобрать десятки примеров, это стоп-фактор: придётся вручную резать батчи и следить за размером пачки.
Вторая проблема — троттлинг. Даже с паузой в 1 секунду между последовательными запросами эндпоинт часто возвращал 429 Too Many Requests. Приходится добавлять ретраи и backoff, а это снова увеличивает реальное время ответа и усложняет код клиента.
Скорее всего, лимиты заданы на стороне AIHubMix, а не самой моделью Qwen. Для пользователя это мало что меняет: работать через этот сервис в интенсивном режиме неудобно.
Тесты на японской грамматике: где decision-model-preview ошиблась
Автор собрал набор из 10 вопросов по японской грамматике и поставил задачу: оценить корректность английского черновика перевода и выставить балл. Модель должна была вернуть флаг is_flawless, диапазон оценки и краткий комментарий. Оба кейса ниже взяты из этого теста.
Кейс 1: 何か vs 何 — ложные 10/10
Фраза 何か待ってるの? означает «Ты чего-то ждёшь?». Здесь 何か — неопределённое местоимение «что-то», а не вопросительное 何 «что». Черновик перевода «what are you waiting for» теряет оттенок неопределённости и превращает вопрос в «чего именно ты ждёшь?».
decision-model-preview через AIHubMix вернула is_flawless 0.98, оценку 10_flawless и комментарий no_flaws_accurate, то есть ошибку не увидела. Локальная oc/jev-1.13-free выставила is_flawless 0.07, оценку 5_moderate_error с уверенностью 0.98 и пояснением confused_indefinite_with_wh_word. Для агента, который автоматически проверяет переводы, разница между «всё идеально» и «ошибка среднего уровня» критична: в первом случае черновик уйдёт дальше без правок и без внимания переводчика.
Кейс 2: инверсия бенефактивного направления
Бенефактив в японском показывает, кому действие приносит пользу. Конструкция 〜てやる в 外に出してやってくれませんか。 означает, что просят выпустить кого-то другого, например питомца, а не самого говорящего. Черновик «would you let me outside?» меняет получателя действия на «меня».
decision-model-preview: is_flawless 0.83 и снова 10_flawless с комментарием no_flaws_accurate. Локальная модель: 3_major_error, то есть 4/10, с пометкой recipient_reversed_self_vs_other. Направление действия определено верно.
Два кейса — не бенчмарк. Примеры взяты из одного поста, набор адаптированный, а оценки выставлял агент автора, а не носитель языка. Но конкретика полезна: она показывает, что модель уверенно ставит максимальный балл там, где ошибка есть. Оценка уверенности у decision-моделей разбиралась и на других примерах Qwen: что стоит за отказами отвечать при низкой уверенности.
Сравнение с локальной oc/jev-1.13-free: скорость, лимиты, точность
Сводка по всем измерениям из поста:
| Параметр | decision-model-preview через AIHubMix | Локальная oc/jev-1.13-free через 9router |
|---|---|---|
| Средний round-trip | 644,9 мс (473-882 мс) | около 439 мс |
| Лимит на запрос | 16 вопросов, дальше 400 Bad Request | об ограничениях не сообщается |
| Частота запросов | 429 даже при паузе 1 секунда | ограничений нет |
| Кейс 1 (何か vs 何) | 10/10, ошибка не найдена | 5-6/10, указана путаница местоимений |
| Кейс 2 (бенефактив) | 10/10, ошибка не найдена | 4/10, recipient_reversed_self_vs_other |
Чего в этом сравнении нет: других языков, задач кроме грамматической проверки, длинных контекстов, поведения под нагрузкой и работы с неоднозначными входами. Локальная конфигурация выиграла в двух тестах, по задержке и по отсутствию лимитов. Называть её лучшей моделью в целом оснований нет.
Стоит ли переходить на decision-model-preview: аргументы за и против
Автор поста рекомендует пока не переходить на новый эндпоинт и формулирует это резко: он считает текущую локальную сборку превосходящей. Его аргументы: локальный роутер быстрее примерно на 200 мс, не имеет лимитов на объём запроса и точнее разбирает сложные японские конструкции.
Кому точно не стоит спешить
- У вас уже работает локальная decision-модель и закрывает задачи: менять шило на мыло смысла нет.
- Вы работаете с японским языком и проверяете переводы автоматически. Ложные 10/10 опаснее медленного ответа, потому что ошибка уходит в готовый текст.
- Нужны пакетные запросы: лимит в 16 вопросов и 429 при паузе в 1 секунду делают интенсивную обработку болезненной.
- Вам важна предсказуемая задержка: разброс 473-882 мс плохо ложится в агентные пайплайны с жёсткими таймаутами.
Кому может быть интересно попробовать
- Вы хотите сравнить подход Qwen к decision-задачам с тем, что уже используете, и готовы выступить тестировщиком.
- Локального железа нет или оно занято другой задачей, а доступ к модели нужен сейчас.
- Ваши задачи не связаны с грамматическими нюансами, и лимиты AIHubMix вам не мешают.
Условие одно: проверяйте на своих данных и не полагайтесь на один отзыв. Два кейса с японской грамматикой показывают слабое место, но не описывают модель целиком. Если выбираете, что держать локально, пригодится разбор сравнения open-weight моделей с учётом VRAM и стоимости инференса.
Что остаётся неизвестным и почему это важно
Открытые вопросы, от которых зависит любое практическое решение:
- официальные характеристики decision-model-preview: размер, архитектура, контекстное окно, режимы работы;
- условия доступа: где модель хостится официально, есть ли бесплатный уровень, какие лимиты действуют на стороне Qwen;
- статус весов: появятся ли они и под какой лицензией;
- независимые замеры на публичных бенчмарках и на языках кроме японского;
- какой снапшот модели отвечает через сторонние прокси вроде AIHubMix.
Пока ответов нет, любой вывод держится на одном посте Reddit и выводе агента его автора. Проверить это можно так: возьмите 10-20 своих задач с заранее известными правильными ответами, прогоните обе конфигурации и сравните не только точность, но и число ложных «всё отлично». Такой тест займёт час и даст больше, чем чужая таблица. За официальными деталями следите на каналах Qwen: анонс, карточка модели и лицензия появятся там.