Как Baseten Grid предлагает считать стоимость завершённой задачи по разработке

Агент для разработки готовит аккуратное изменение для падающего теста. Изменение не проходит CI, и разработчик просит попробовать снова. Вторая попытка затрагивает бо́льшую часть репозитория, а на проверку патча уходит полчаса вместо ожидаемых пяти минут. Какая модель обошлась дешевле?

4 ноября Baseten представила публичную предварительную версию Grid. Она объединяет шлюз к утверждённым моделям, маршрутизатор и централизованные средства контроля использования и защитных ограничений. Сервис может встать между поддерживаемыми инструментами разработки и моделями, чтобы команда применяла общую политику ко всем запросам. На странице раннего доступа предлагают записаться в лист ожидания.

Выберите правильный знаменатель

Стоимость принятой задачи. Оригинальная иллюстрация Telli.sh.

Цена токена показывает стоимость единицы использования модели. Команде нужно сдать работу, отвечающую критериям приёмки. Запрос может получить ответ, выполнение может дать diff, а задача всё равно останется незавершённой. Если считать эти события отдельно, эксперимент с маршрутизацией станет полезнее.

Допустим, каждый из двух маршрутов получает по 100 схожих задач. Дешёвый маршрут тратит $50 на все попытки и завершает 50 задач с приемлемым результатом. Другой тратит $90 и завершает 90 задач. В этом условном расчёте обе схемы расходуют $1 на использование моделей в расчёте на один принятый результат. Если прибавить время проверки человеком, плату за инструменты и ожидание повторов, результаты могут разойтись в любую сторону.

Оставляйте стоимость неудач в числителе. Маршрут, бросающий сложные запросы, может выглядеть эффективным, если прерванные попытки исчезают из расчёта. Сохраняйте неизменным и критерий успеха. Для правки документации может хватить одобренного diff. Миграции нужны тесты на существующих данных и способ отката.

Категория задачи имеет значение. Миграция API во всём репозитории может быть сложной из-за контекста, координации и множества мелких изменений. Однострочный патч может оказаться сложнее из-за трудноуловимой ошибки конкурентного доступа. Число файлов и длина запроса полезны как признаки лишь тогда, когда помогают предсказывать исход в вашей среде.

Смотрите на эксперимент с маршрутизатором как на выбор компромисса

Эксперимент по маршрутизации. Оригинальная иллюстрация Telli.sh.

В техническом отчёте Baseten сравнивает постоянное использование Opus 5.5 с распределением задач между этой моделью и GLM 5.3 Flash. На наборе из заданий DeepSWE, SWE Atlas QnA и Terminal-Bench компания сообщает о точке, в которой стоимость ниже на 72%, а доля пройденных задач отличается от варианта только с Opus не более чем на 0,8 процентного пункта. В отчёте маршрутизатор также сравнивается со случайным выбором при сопоставимой стоимости. Это важно, потому что передача бо́льшей доли работы дешёвой модели снижала бы средние затраты даже при случайном выборе.

Порог выражает решение о том, сколько стоит платить за вероятность успеха. Если повысить приоритет цены, больше задач можно отправить по дешёвому маршруту. Другая настройка отдаст предпочтение более сильной модели, когда результат важнее. Данные Baseten относятся к выбранным моделям, задачам и допущениям о ценах. У вашей команды будет другое распределение задач и другая цена ошибки.

В анонсе продукта приводится отдельное округлённое значение — экономия до 70% по ранним тестам. Его стоит отделять от результата эксперимента в 72% и соответствующего сравнения долей пройденных задач. Технический отчёт помогает понять, как меняется соотношение цены и результата. Команда может выбрать точку в соответствии со своими приоритетами, а затем проверить её на реальной работе.

Шлюз позволяет сделать политику видимой

В анонсе Grid описаны утверждённые модели, контроль на уровне команд и наблюдение за использованием. Команда платформы может открыть разработчикам доступ к моделям, которые организация уже оценила, и видеть, как распределяется нагрузка. Это помогает понять, куда уходят деньги, ещё до автоматического выбора маршрута.

На практике нужно принять несколько решений. Какому провайдеру можно показать закрытый код? Какая модель разрешена для конкретного репозитория? Чья команда оплачивает повторы? Кто может переопределить маршрут после инцидента? Шлюз позволяет принимать эти решения в общей точке, если администраторы понимают область действия каждого ограничения.

Шлюз к моделям и среда выполнения агента — разные точки контроля. Шлюз решает, какой модели достанется запрос. Инструмент или среда исполнения решает, может ли агент прочитать учётные данные, записать файл или выполнить сетевой запрос. Ограничения маршрутов полезны вместе с разрешениями среды выполнения. Дешёвому маршруту нужны те же ограничения на привилегированные инструменты.

Есть и вопрос доказательств. Журналы маршрутизации помогают понять, почему изменились расходы, но могут содержать код, пути и детали клиентского инцидента. Определите, что платформе разрешено записывать, кто может это видеть и как долго можно хранить сведения. Если разработчик не может посмотреть политику, трудно разобраться, почему запрос отклонён или отправлен по неожиданному маршруту.

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

1. Выберите две или три распространённые группы задач. Включите простую, например обновление тестов, и более сложную, например миграцию с требованиями к обратной совместимости.
2. До начала определите доказательства, необходимые для приёмки. Для задачи разработки это могут быть пройденный регрессионный тест, чистый diff, одобрение проверяющего и отсутствие неожиданных изменений файлов.
3. Соберите базовые данные с текущей моделью по умолчанию. Учитывайте неудачи, повторы и работу, которую разработчик завершает вручную. Сохраняйте правила безопасности и ограничения по данным, действующие в рабочей среде.
4. Сравнивайте маршруты на эквивалентных задачах. Если доступ открыт, сверяйтесь с официальной документацией по поддерживаемым инструментам и разрешениям шлюза до подключения аккаунта.
5. Решите, когда переходить на более сильную модель. После первой неудачи можно вызвать вторую модель, но бесконечные повторы могут стоить дороже, чем сразу использовать более сильную. Установите лимит и фиксируйте причину эскалации.
6. Сохраните ручное переопределение для задач, где цена ошибки велика. После пробы рассмотрите исключения вместе с общими показателями стоимости и приёмки.

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

Разберите журнал сопоставимых задач

Начать можно с месяца завершённых pull request. Отметьте исходный тип запроса, например обновление зависимости, ошибка с воспроизводимым тестом, изменение в нескольких репозиториях или расследование неудачного развёртывания без заранее известной причины. Сохраните ревизию репозитория и способ приёмки каждой задачи. Повторите часть задач на стабильном базовом варианте и с маршрутизатором. Используйте одни и те же инструменты, лимит времени и тестовую среду.

Обновление зависимости — пример с небольшой неоднозначностью. Оно успешно, если нужная зависимость обновлена, проверки совместимости пройдены, а в pull request нет посторонних изменений. Правка правил выставления счетов требует более строгой проверки. Возможно, человеку придётся разобраться в неполных требованиях. Раздельный учёт помогает понять источник снижения средних расходов. Если дешёвый маршрут хорошо справляется с зависимостями, но многократно повторяет попытки на задачах оплаты, эти группы можно развести по маршрутам.

Записывайте, сколько времени человек тратит на решение о приёмке. Допустим, базовый вариант даёт 19 принятых результатов из 20 за $19, а маршрутизатор — 18 за $9. В этом примере расходы на модель в расчёте на принятый результат составляют соответственно $1,00 и $0,50. Если проверяющие потратят ещё 20 минут, чтобы поправить один неудачный результат маршрутизатора, сравнение изменится. Организация может учесть эту доработку, сохраняя различие между долларами и минутами.

Учитывайте, на чём учился маршрутизатор

В технической статье Baseten называет DeepSWE 1.1, SWE Atlas QnA и Terminal-Bench 2.1. В исследовании Claude Opus 5.5 и GLM 5.3 Flash сравниваются на задачах, а маршрутизатор оценивается на отложенных данных. Эти детали важны, когда вы решаете, насколько широко переносить результат. Вопросы о том, где найти нужный код, имеют другую структуру затрат, чем задачи с оболочкой, внешними инструментами или изменениями нескольких файлов. Проверка заказчика должна представлять задачи, которые он действительно собирается отправлять.

В статье режимы Cost, Balanced и Intelligence описаны как настройки, меняющие порог во время запроса. Команда может использовать это различие для параллельного сравнения. Проверьте режимы на фиксированном наборе разрешённых повторов и записывайте выбранную модель, если интеграция позволяет её увидеть. Изучите расхождения. Если дорогой маршрут выбирается в основном для чувствительных или трудных задач, политика может работать как задумано. Если расхождения сосредоточены на распространённой простой задаче, стоит пересмотреть классификацию или саму политику.

Следите за самыми медленными и дорогими задачами

Средняя задержка может скрыть долгую работу над патчем, который прошёл через несколько моделей. Записывайте полное время от запроса до принятого результата и отмечайте повторы, эскалации, тайм-ауты и передачу работы. Панель, показывающая лишь время первой модели, может заявить о выигрыше в задаче, которую пришлось начинать заново. Учитывайте стоимость и время после передачи.

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

Внедрение стоит начать с узкой группы, где приёмка автоматизирована, а человек может посмотреть исключения. Затем добавьте группу, в которой нужно суждение проверяющего. Сравнивайте стоимость принятой задачи, долю эскалаций и время проверки отдельно. Если выгода сохранится после этого изменения, у организации будет больше оснований для выбора настройки по умолчанию.

Сохраняйте пригодность базового набора после смены модели

Результат прошлой недели может устареть при замене модели, инструмента или версии репозитория. Сохраняйте идентификатор модели, тестовую ревизию и правила приёмки вместе с решением о маршруте. При изменении политики повторно прогоняйте небольшую подборку представительных задач. Включите дорогие неудачи, потому что в средних значениях их стоимость легко потерять.

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

Политика должна меняться вместе с работой

Маршрутизация полезна, когда избавляет команду от одного и того же мелкого решения. Особенно полезно измерять производительность и цену на одной единице работы. Со временем модели, цены и репозиторий изменятся. Сохраняйте контрольные задачи и обновляйте тестовый набор, чтобы политика могла за ними успевать.

На обсуждение плана стоит выносить стоимость принятой работы с понятным объяснением компромиссов. С этим показателем могут вместе работать и руководитель разработки, и владелец бюджета.

Источники

• Анонс предварительной версии Baseten Grid от 4 ноября
• Технический отчёт Baseten о Router от 4 ноября

---

Чтобы сохранять рабочие разговоры и решения и быстро находить их, создайте аккаунт Telli.sh.