# Jev, DeepSeek, Qwen: качество, масштабирование и исходные вероятности

24 сентября 2026. Фиксируется до основных результатов Qwen и новых скоростных замеров. Исходные prompt и публичные поднаборы неизменны. GLM исключена по просьбе пользователя из-за появления reasoning; её неполный прогон сохранён в glm-aborted-study и не входит в отчёт. Gemini исключены из отчёта. Никаких post-calibration, новых dev-порогов, улучшенных prompt из precision-audit.

Jev 1.13.0 — native API. DeepSeek V4.1 Flash — OpenRouter/Together. Qwen3.8 27B — OpenRouter/Parasail, FP8 по каталогу endpoint. Провайдеры закреплены, allow_fallbacks=false, require_parameters=true. У обеих LLM reasoning.enabled=false; ненулевой или отсутствующий reasoning_tokens вызывает остановку. На одиночных бинарных и трёхклассовых заданиях max_tokens=1, temperature=1, logprobs/top_logprobs=20. API-проба Qwen вернула один токен, полный бинарный вектор и ноль reasoning. Qwen3.8 Flash проверена только на доступность: её Alibaba endpoint ограничивает top_logprobs пятью; выбрана 27B для более широкого экспорта. Никакого восстановления недостающих вероятностей через 1-p.

Качество Qwen: ANLI 300; ContractNLI 510 одиночных вопросов и те же 30 договоров по 17 вопросов; BANKING77 385. ANLI/Contract Q1 — argmax полного вектора трёх кодов, BANKING77 и Q17 — выбранные короткие коды без JSON, temperature=0, max_tokens=128. Невалидный ответ — ошибка. Бинарный ContractNLI — 510 прежних пар договор/гипотеза, 48 противоречий. Score = exp(lp1)/(exp(lp0)+exp(lp1)); оба класса обязательны. Данные Jev/DeepSeek берём из сохранённых исходных исследований; Qwen вызывается позднее, поэтому это ограничение сравнения. Эталон не передаётся модели.

Отчёт: macro-F1 отдельно по задачам; бинарная PR-кривая и Average Precision; исходные Brier/ECE и reliability diagrams с количеством примеров. Одна пороговая точка — первая достижимая с recall >=80%, без интерполяции, с фактическим recall и TP/FP. Это описание test-кривой, не рабочий порог. Bootstrap 2000 по целым договорам для разностей AP и precision в этой точке.

Скорость: прежние три договора contract-606/57/21, 17 трёхклассовых вопросов каждый, 51 решение на блок. Q1/C1, Q4/C1, Q17/C1, Q1/C4, Q1/C16. Q4 разбивает 17 вопросов на 4+4+4+4+1. Три повтора, порядок моделей циклически меняется. Jev возвращает native probabilities; обе LLM — короткие коды temperature=0/max_tokens=128 без схемы и logprobs. Это скорость выдачи меток; одиночный Q1 здесь тоже полный короткий ответ, не усечение одним токеном. Для одиночной классификации с logprobs задержка дополнительно берётся из соответствующего quality-прогона, без смешивания режимов.

Все скоростные блоки выполняются последовательно одним curl 8.22 на RackNerd, исходящий IP 107.172.73.82. Wall time исключает SSH и чтение результатов, включает первые соединения, reuse и возможный cache провайдера. Сохраняем usage/cache. Главные значения — время всех 51 решений и p50/p95 отдельного вызова; latency не делится на число вопросов. Три повтора — контроль конкретного API-прогона, не SLA и не измерение GPU. Ответы и корректность по каждому режиму сохраняются, чтобы ускорение не скрывало ошибки.

Сырые результаты и ошибки сохраняются. Для quality/binary до двух повторов идентичного payload после transport timeout, 429 или 5xx; никаких смен модели/провайдера/парсера. Ошибка speed останавливает серию для диагностики. План: 1735 новых quality/binary вызовов и 1539 speed, плюс 5 pilot. Ожидаемая стоимость несколько долларов, грубая верхняя граница $15. Секреты только в процессе и SSH stdin, не в артефактах.

Проверка sampled token: один Qwen-ответ выбрал текстовый токен «Not», при этом все три кода 0/1/2 присутствовали в logprobs. Для mode=vector/binary используем argmax/score допустимых кодов независимо от sampled token, как в исходной методике. Сам текстовый токен не является решением; несовпадение фиксируем как validOutput=false. Для mode=codes без logprobs неверный формат по-прежнему делает весь ответ невалидным. Первичная чрезмерная проверка sampled label исправлена, raw не менялись и повторный API-вызов не делался.

Во втором повторе DeepSeek Q1/C4 один запрос получил HTTP 503 Service unavailable от Together. После проверки raw весь блок из 51 запроса повторяется с тем же payload, отдельным batchId -repeat1. Первичный незавершённый блок сохраняется и исключается целиком из медиан/качества скоростного контроля; число неудачных API-вызовов и исключённых записей явно указано в verification.json и отчёте. Частично завершённые блоки не склеиваются. Допускается максимум два таких повтора блока, только после явной диагностики.

Поправка к учёту надёжности после диагностики: повтор блока DeepSeek тоже дал HTTP 503, уже на другом вопросе. Основная скоростная серия теперь сохраняет ПЕРВЫЙ проход каждого блока, включая все HTTP-ошибки, а не выбирает успешный повтор. Диагностический -repeat1 исключён; оригинальный блок включён. Ошибка — явный результат status!=200, без метки и вероятностей, считается ошибкой в accuracy и доле полных ответов; время всех запросов, включая неудачные, входит в wall/p50/p95. Никакой подмены провайдера или восстановления ответа. Стоимость неответивших вызовов неизвестна, суммы считают только сообщённый usage. Остальные запланированные блоки продолжаются тем же маршрутом; повреждённый транспорт или неоднозначные logprobs по-прежнему останавливают запуск. Это исправляет селекцию по успешности, а не маскирует сбои.