«На xhigh — 18 из 18, на low — 15 из 18 за восьмую часть токенов»: AWS измерила цену reasoning-усилия агентов на Grok 4.7 в Amazon Bedrock

Почему уровень рассуждений стал прикладным вопросом

По сообщению AWS, Grok 4.7 от SpaceXAI теперь доступна в Amazon Bedrock, который предлагает выбор базовых моделей от нескольких поставщиков. По словам SpaceXAI, Grok 4.7 обучена работать дольше над более сложными задачами и понимает, когда нужно проверять собственную работу, — и это важнее всего именно для агентов, которые ведут задачу через множество шагов и по ходу должны проверять то, что находят.

Такой агент делает больше, чем поиск по данным: он формирует вариант ответа, сверяет его с уже известным и уточняет, пока ответ не сойдётся. Grok 4.7 предоставляет настройку reasoning-усилия, управляющую тем, сколько рассуждений происходит перед ответом, и для агентских нагрузок практический вопрос — какой уровень запускать.

Авторы собрали tool-calling агента на Grok 4.7 и проверили его на трёх задачах, требующих именно поиска: диагностика отказа двух сервисов по наблюдаемым алертам, планирование обслуживания при взаимодействующих ограничениях и выбор оптимального набора миграций в рамках бюджета. У каждой задачи ровно один верный ответ, подтверждённый полным перебором, все три прогонялись на каждом уровне усилия по шесть раз — всего 72 запуска агента. Верными оказались 67 из них.

Токены авторы считали вместо денег и объяснили почему: цены на токены меняются, а именно счётчики токенов лежат в основе собственных издержек, поэтому измерение, выраженное в токенах, остаётся валидным.

Что SpaceXAI сообщает о Grok 4.7

По данным SpaceXAI, Grok 4.7 использует более крупную базовую модель, чем Grok 4.6, и обучена более длинным прогоном обучения с подкреплением на более сложной смеси задач, взвешенной в сторону проблем, требующих многих часов работы; компания сообщает, что модель лучше проверяет собственную работу и лучше управляет длинным контекстом.

Опубликованные SpaceXAI бенчмарки следуют этой логике: наибольшие приросты над Grok 4.6 приходятся на категории, измеряющие длительную работу, а не одноходовые ответы. Terminal-Bench 4.0, многочасовая работа в терминале, вырос с 20,3% до 37,6%; EEBench, электротехника, — с 53,0% до 64,0%; Harvey Legal Agent Benchmark, юридическая работа, — с 15,8% до 19,6%; CursorBench 4.0, более длительное программирование, — с 40,4% до 46,3%; HealthBench Professional, клинические рассуждения, — с 48,5% до 56,7%; AA Briefcase v1.1, многочасовая офисная работа, — с 1 546 до 1 657. Авторы подчёркивают, что это опубликованные SpaceXAI результаты на момент выхода модели, и следующий полезный шаг для собственной нагрузки — измерить её на задачах, похожих по форме.

SpaceXAI указывает окно контекста 500K токенов с текстовым и графическим входом и текстовым выходом. В Amazon Bedrock модель поддерживает настраиваемое reasoning-усилие, вызов инструментов и структурированный вывод.

Как получить доступ к Grok 4.7

Grok 4.7 работает на эндпоинте bedrock-runtime и доступна через профиль кросс-регионального инференса: профиль us.xai.grok-4.7 маршрутизирует запросы внутри географии США и подходит при требованиях к резидентности данных, а global.xai.grok-4.7 работает в коммерческих регионах AWS и нужен, когда ограничений на резидентность нет и требуется максимальная ёмкость. Кросс-региональный инференс распределяет запросы между несколькими регионами AWS, давая более высокую пропускную способность без ручного управления ёмкостью по регионам, а в запросах указывается один из профилей вместо «голого» идентификатора модели.

Модель поддерживает OpenAI-совместимые Chat Completions и Responses API, а также Converse API в Amazon Bedrock. В Converse рассуждения возвращаются блоком reasoningContent рядом с блоком text, а в inferenceConfig следует задавать только maxTokens, вынося специфичные для модели параметры, например reasoning-усилие, в additionalModelRequestFields.

Политике IAM нужно разрешение bedrock:InvokeModel и на профиле инференса, и на дефолтном проекте аккаунта: оба ресурса включаются в один оператор политики, и разрешение на дефолтный проект требуется дополнительно к профилю. Токены рассуждений считаются выходными и расходуют max_completion_tokens до того, как появится текст ответа, поэтому лимит нужно закладывать с запасом на оба; если он исчерпан во время рассуждений, ответ вернётся без текста, и в коде агента стоит проверять пустое содержимое, повышая лимит при его появлении. В своих прогонах авторы использовали лимит 32 768 токенов, чего хватало с запасом на всех уровнях. Уровней усилия четыре — low, medium, high и xhigh, — но они могут меняться от версии модели к версии, поэтому список уровней стоит сверять с сервисом, а не зашивать в код.

Как устроены задачи и как их измеряли

Большинство агентских оценок проверяют усердие: прочитать запись, отфильтровать, сложить — такие задачи иметь полезно, но чтобы увидеть вклад reasoning-усилия, задача должна требовать поиска, поскольку ответ нельзя вычитать из данных, его нужно предложить, а затем проверить. Авторы построили синтетическую среду из 20 сервисов, открытых через семь инструментов, и три задачи поверх неё.

В задаче two_fault_diagnosis два сервиса молча отказали в 03:00, а ещё 12 подняли алерты; отказавшие сервисы не поднимают алертов сами, поэтому ответа среди «шумящих» сервисов нет — всего 190 возможных пар, и только одна объясняет наблюдаемые алерты ровно. В maintenance_schedule восемь сервисов нужно пропатчить за четыре ночи по два за ночь при десяти ограничениях и правиле, что два сервиса одной команды никогда не делят ночь: 2 520 возможных расписаний, из которых валидно одно, а правило по командам зависит от данных, которые агенту нужно найти. В migration_budget нужно выбрать кандидатов на миграцию так, чтобы максимизировать снижение риска в рамках бюджета, включая транзитивные предпосылки: 53 допустимых набора, из которых оптимален один, а выбор по лучшему соотношению даёт набор, отстающий от оптимума на девять пунктов.

Четыре практики делают такое измерение заслуживающим доверия. Нужно проговаривать каждое правило, на которое опирается оценщик: если промпт оставляет крайний случай открытым, разумный ответ может быть оценён как неверный, и измерение начинает оценивать спецификацию, а не модель, поэтому промпт диагностики прямо говорит, что отказавший сервис не поднимает собственного алерта. Нужно доказать, что у задачи ровно один ответ: среда достаточно мала для полного перебора, и каждый вариант проверялся до запусков. Нужно оценивать обязательную финальную строку, а не весь ответ: каждый промпт просит завершать ответ строкой вида FINAL: auth, checkout, и оценщик читает только её, так что ответ, обсуждающий другие кандидаты по ходу рассуждений, оценивается по своему выводу. И нужно отслеживать формат отдельно от корректности, потому что отсутствующая финальная строка — это другой сигнал, чем неверная: во всех 72 ответах авторов оцениваемая финальная строка присутствовала. Дополнительно параметры инструментов ограничиваются перечислением (enum) там, где допустимые значения известны, чтобы каждый вызов инструмента адресовал реальный ресурс.

Результаты и что они значат

Шесть прогонов каждой задачи на каждом уровне усилия, 72 прогона, 67 верных ответов. В задачах two_fault_diagnosis и migration_budget уровни medium, high и xhigh дали по 6 верных из 6 (на low — 5 из 6), а в maintenance_schedule шесть верных ответов нашлись только на xhigh. По всем трём задачам сразу: low — 15 из 18, medium и high — по 17 из 18, xhigh — 18 из 18.

Цена усилия в токенах растёт заметно быстрее качества: средние выходные токены на прогон составили 1 184 на low, 6 430 на medium, 6 778 на high и 9 147 на xhigh, то есть 1,0x, 5,4x, 5,7x и 7,7x относительно low. При этом среднее число вызовов инструментов почти не меняется — 17,2, 18,7, 17,8 и 18,1, — а медианное время прогона составляет 18, 98, 89 и 106 секунд.

Авторы делают три наблюдения: на xhigh верными оказались все без исключения прогоны, medium и high ответили по 17 из 18, а при шести прогонах на задачу и уровень различия между уровнями скорее индикативны, чем статистически убедительны, хотя направление оказалось согласованным на всех трёх задачах. Практический вывод формулируется так: это ясный компромисс, который можно подбирать под каждый запрос, измеряя его на собственных задачах и отслеживая в продакшене.