Qwen 3.8-Max и Opus 5 доказывают, почему оценки не отражают стоимость

Alibaba выпустила Qwen 3.8-Max на этой неделе и представила превью-версию модели, заявив, что она уступает лишь Claude Fable 5 (их таблица в день запуска выглядела более сдержанно: модель лидирует лишь в одной из 12 категорий кодинг-агентов). Однако независимая система тестирования пришла практически к противоположному выводу: бенчмарк-тест, судя по всему использовавший Preview-версию, показал, что в оптимальном режиме Qwen 3.8-Max оказалась лишь в середине списка, а в режиме по умолчанию заняла последнее место.

Оба результата реальны и обоснованны. Разница между ними кроется в лимитах на токены и время, и это важно, поскольку данные показатели обычно не выносят в заголовки. В сносках Alibaba указано, что для тестов кодинга выделялся таймаут в пять часов, а для PaperBench — до 12 часов на один запуск. Независимый тестовый комплекс VulcanBench выделял от 45 до 60 минут реального времени. Превышение лимита времени со стороны Alibaba в 5–16 раз и объясняет столь колоссальную разницу в результатах.

Пришло время учитывать эти различия при выборе моделей, для чего нужно сделать две вещи. Во-первых, используемой метрикой должна стать стоимость успешной задачи: общие затраты (включая всё, что вы потратили на неудачные попытки) делятся на количество задач, успешно прошедших проверку. во-вторых, необходимо сделать лимиты по времени или токенам явной частью критериев приемки, а не скрытой деталью.

Цена за токен перестала определять итоговый счет

Сравнение, которое все опубликовали в первую неделю после выхода Qwen 3.8-Max, было ценовым, поскольку другой информации просто не было. Это недешевая модель. DeepSeek-V4-Flash-0731, вышедшая в публичную бета-версию API 31 июля, стоит 14 центов за миллион входных токенов и 28 центов за выходные. Qwen 3.8-Max оценивается в $2 и $6. Kimi K3 — в $3 и $15.

Эти цены говорят о меньшем, чем раньше, по причине, характерной для рассуждающих (reasoning) моделей вроде Qwen: достижение результата требует токенов на размышления. Модель, расходующая большую часть лимита токенов на рассуждения, может исчерпать их до того, как напишет ответ. В итоге вы получаете пустой результат, неотличимый от полного сбоя, но по цене полноценного запуска.

У компании Artificial Analysis есть самое наглядное опубликованное измерение того, как это влияет на реальные расходы на агентов: запуск ее индекса интеллекта (Intelligence Index) на DeepSeek-V4-Flash при максимальной нагрузке потребовал 210 миллионов выходных токенов при медиане по классу в 100 миллионов. Абсолютная стоимость все равно осталась низкой, поскольку токены стоили очень дешево. Однако многословие стоит не только денег, но и времени, и в зависимости от ваших задач это может стать критичным.

Вам нужна метрика, которая учитывает все затраты, включая безрезультатные попытки, по отношению к задачам, которые действительно были выполнены в рамках заданного бюджета времени и токенов. Именно это позволяет оценить показатель стоимости одной успешной задачи (cost-per-success).

Уровень сбоев отчасти зависит от настроек конфигурации

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

В исследовании Long-Horizon-Terminal-Bench, опубликованном в июле, 17 передовых моделей выполняли 46 задач через общую тестовую среду, получая по 90 минут на каждую попытку. Таймауты составили 79% от незавершенных запусков, в то время как на долю агентов, остановившихся самостоятельно, пришлось 19%, а на ошибки системы тестирования — 3%. Авторы аккуратно подходят к интерпретации этих цифр: зависшие запуски были далеки от завершения (средняя награда составляла от 0.10 до 0.35), поэтому нельзя утверждать, что выделение дополнительного времени привело бы к успеху. Но вывод таков: бенчмарки неявно измеряют эффективность использования времени, независимо от того, акцентируют ли они на этом внимание.

Самый наглядный опубликованный пример этого механизма взят из VulcanBench — того же открытого тестового фреймворка, который использовался для графика Qwen. В отчете от 26 июля самый низкий уровень усилий Claude Opus 5 оказался наиболее эффективным: модель решила 20 задач из 23 против 18 задач в режиме максимальной интенсивности. Дополнительные размышления не были бесполезными: высокий уровень усилий дал наименьшее число неверных ответов среди всех режимов (один против трех). Однако модель просто исчерпала отведенное время, а по таймауту засчитывается нулевой результат. Два из трех ее регрессов пришлись на прерывания в задачах, с которыми низкий уровень усилий успешно справляется, причем даже при выделении неограниченного времени в обоих случаях модель лишь сравнивается по результату с самым дешевым режимом, обходясь при этом в 3.1 раза дороже.

Это имеет прямые последствия для всех, кто проектирует каскадную маршрутизацию (routing ladder). Стандартная схема предполагает эскалацию до более глубоких рассуждений при сбое дешевой попытки — в расчете на то, что следующий уровень лучше и просто дороже. Для значительной доли комбинаций моделей и задач это предположение неверно, и вы платите цену высшего уровня лишь за то, чтобы упереться в таймаут или исчерпание лимита.

Кто уже это измеряет

За последние несколько месяцев несколько групп независимо друг от друга пришли к метрике стоимости успешной задачи, что служит самым веским доказательством ее превращения в стандарт.

VulcanBench указывает долларовые затраты на решенную задачу в качестве ключевой колонки в своих отчетах с самого начала. Long-Horizon-Terminal-Bench публикует стоимость задачи рядом с точностью, причем самый показательный пример — GPT-5.4 стоимостью примерно $26 за задачу при гораздо более низком проценте успешных прохождений по сравнению с Grok 4.5, которая обходится примерно в $11. TestEvo-Bench запускает агентов в рамках жесткого ограничения бюджета, и показатель генерации тестов для Claude Code падает с 71% до 44% при более строгом лимите.

Поставщики услуг уже поддержали идею измерения эффективности в расчете на успешную задачу. В апреле HubSpot перевела своего клиента Breeze Customer Agent на оплату по 50 центов за разрешенный диалог (по сравнению с прежним $1 за обработанный диалог). Zendesk берет плату за автоматические резолюции. Fin взимает 99 центов за результат и выставляет счет только за комплексное разрешение проблемы.

Что изменить на этой неделе

• Добавьте причину сбоя в качестве обязательного поля для каждого запуска агента, разделив исчерпание бюджета, ошибку верификатора и сбой тестового фреймворка на независимые категории вместо единого флага ошибки. Пока вы не научитесь отличать таймаут от неверного ответа, ваш показатель успешности будет измерять две разные вещи одновременно, и вы не поймете, что именно нужно исправлять.

• Вычисляйте стоимость успешной задачи для каждого уровня усилий, а не просто для модели в целом. Общие затраты (включая неудачные попытки) делите на задачи, прошедшие проверку. Полученный рейтинг не совпадет с официальным прайсом, и самым выгодным вполне может оказаться самый дешевый режим.

• Устанавливайте лимиты по токенам, а не по реальному времени (wall clock), если только задержка критически не важна для вашего уровня обслуживания (SLO). Лимит по часам оценивает скорость работы провайдера, а не качество самой модели.

• Проверьте настройки уровня усилий по умолчанию для всех развернутых решений. Qwen 3.8-Max задействует максимальный уровень рассуждений при не заданном поле effort, и в ходе независимого тестирования этот максимальный режим показал себя хуже всего. Команда, которая не уделяет внимания этому параметру, использует конфигурацию, обходящуюся дороже всего в расчете на решенную задачу.