Кратко
Мы сократили стоимость GitLab Duo Code Review на 98% на Martian’s Code Review Bench без потери качества проверки, и все это за счет оптимизации обвязки (harness): на какой модели запускается каждый этап и сколько контекста каждый этап считывает. Само по себе ни одно из этих изменений не дает такого результата. Модель с открытыми весами застопорилась на нескольких объемных ревью, и именно уплотнение контекста позволило им вписаться в ограничения.
Стоимость агента в конечном итоге определяется его обвязкой: какие этапы он выполняет, что считывает каждый этап и какая модель выполняет работу. Мы взяли GitLab Duo Code Review, обвязка которого доступна в исходных текстах, измерили, куда уходят деньги, и, используя собственного агента для проведения экспериментов, меняли по одному параметру за раз, пока счета не перестали уменьшаться.
Но главная история заключается вовсе не в финальных изменениях в обвязке, а в том, как мы к ним пришли. Переход на более маленькую модель на каждом этапе ухудшил качество. Переход на модель с открытыми весами на каждом этапе сократил стоимость на 85%, но мы на этом не остановились. Хотя на первый взгляд уплотнение кажется незначительным, 98% экономии достигается только при использовании обоих факторов, поскольку окно развертывания модели с открытыми весами определяет, какие запросы она вообще может принимать. Модель задает цену. Обвязка определяет, можете ли вы ее использовать.
Мы запускали это на публичных пулл-реквестах без использования производственного трафика GitLab или клиентских данных. Качество измерялось по метрике F1 на одном публичном бенчмарке с оценкой двумя судьями. Стоимость определялась по расходу токенов по опубликованным прейскурантным ценам, в том числе для модели, которую мы хостим самостоятельно, поэтому она отражает потребление ресурсов обвязкой. Вопрос стоимости нашей собственной инфраструктуры стоит отдельно. Конфигурации выбирались и настраивались на тех же 50 пулл-реквестах, по которым они оцениваются, поэтому воспринимайте это как измеренные результаты на данном бенчмарке; то, как они поведут себя на новой кодовой базе, не проверялось. Полная методология приведена в конце.
Конвейер из четырех этапов
Duo Code Review, поток проверки кода платформы GitLab Duo Agent Platform, проверяет мердж-реквесты и оставляет комментарии. На момент тестирования по умолчанию в нем использовалась Claude Sonnet 5, а компания GitLab опубликовала этот поток, построенный на базе LangGraph, в своем репозитории ai-assist с открытым исходным кодом. Именно это вместе с публичным бенчмарком стало причиной нашего выбора.
Он выполняет четыре модельных этапа, каждый со своим промптом и максимум двумя инструментами:
- «Исследование» (Exploration) выстраивает список дерева репозитория вокруг измененных файлов.
- «Получение файлов» (File fetching) считывает связанные файлы: тесты, вызывающие компоненты, пользовательские инструкции.
- «Анализ» (Analysis) превращает полученные данные в заметки.
- «Ревью» (Review) полностью считывает дифф и большинство измененных файлов, после чего публикует комментарии.
Каждая общая оптимизация, которую мы создавали, нацелена на таких агентов кодирования, как Claude Code, которые повторно отправляют один растущий диалог, полный вывода инструментов и определений инструментов. Этапы Duo Code Review независимы: каждый начинается со свежего промпта, содержит не более двух инструментов и не имеет истории для обрезки. Наши настройки по умолчанию не имели ничего общего с этим и не изменили ни единого запроса.
Оказывается, универсального подхода к оптимизации обвязки не существует; каждая обвязка требует тщательного анализа.
Куда уходят деньги
Ревью составляет 65% счета, причем один лишь его вывод — треть от общей суммы: имея возможность свободно размышлять перед публикацией, Sonnet 5 пишет около 18 600 токенов на одно ревью, практически все из которых приходятся на рассуждения. Исследование и получение файлов, которые лишь определяют, какие файлы нужно прочитать, составляют 27%. Анализ — 9%.
Деньги уходят в основном в трех направлениях: контекст, считываемый каждым этапом, механические этапы и рассуждения в процессе ревью. Ни одно изменение само по себе не охватывает все три направления, но каждый шаг ниже затрагивает одно из них.
Находка 1: меньше контекста, больше рассуждений
Можем ли мы сократить объем данных, считываемых при ревью, без ущерба для качества? Да, и это дает меньшую экономию, чем предполагают простые расчеты.
Этап ревью формирует контекст, включающий измененные файлы целиком, а также дифф, где каждая строка помещена в тег с повтором ее типа и обоих номеров строк. Унифицированный дифф помечает ту же строку одним символом.
Мы уплотнили оба элемента на входе в поток с помощью правил, а не модели: ничего не резюмируется. Окно файлов сохраняет каждый измененный ханк плюс 25 строк с каждой стороны как для старого, так и для нового диапазонов строк, а остальное отсекает. Уплотнение диффа переписывает покадровый дифф в стандартный унифицированный дифф с теми же ханками и номерами строк.
Медианный промпт для ревью сократился с 59K до 32K токенов. Расходы на контекст ревью снизились еще сильнее — на 62%, поскольку самые большие промпты уменьшились сильнее всего.
Тем не менее стоимость ревью снизилась всего на одну пятую. При включенном уплотнении Sonnet 5 также писала больше: около 23 800 токенов вывода на одно ревью вместо 18 600, и почти все они уходили на рассуждения. Мы не выясняли точные причины этого, но данный фактор ограничивает экономию, которую может обеспечить только лишь уплотнение. Само по себе уплотнение снизило стоимость с $0.589 до $0.475 (экономия 19,4%) при F1 на уровне 47,2% и задержке 1,16x.
Находка 2: модель с открытыми весами справилась на каждом этапе
Насколько сильно помогает смена моделей? Это зависит от того, какой именно этап вы меняете.
Мы начали с того, что перенесли Claude Haiku 4.5 на один этап за раз. На этапах исследования и получения файлов модель выбирала те же файлы, что и Sonnet 5. Первые тесты на двух других этапах оказались менее удачными: качество снизилось при использовании Haiku для анализа и резко упало на этапе ревью. Одна и та же модель давала совершенно разные результаты в зависимости от того, где она применялась. Будучи оставленной на двух механических этапах, Haiku снизила счета на 15,4% при неизменном показателе F1, и на 34,6% — с учетом уплотнения.
Это был предел возможностей Haiku. Она не смогла удержать качество на этапе ревью, где сосредоточена большая часть затрат, да и при вдвое меньшей цене по сравнению с Sonnet 5 она не смогла бы существенно изменить общую сумму счета. Достижение уровня рассуждений ревью потребовало выхода за пределы семейств Claude.
Затем мы обратились к модели с открытыми весами: DeepSeek V4 Flash, первой испробованной нами модели, которую мы запускаем с помощью vLLM на чипах H100. По прейскурантной цене Together AI она обходится в 14 раз дешевле Sonnet 5 за входной токен и в 36 раз дешевле за выходной токен. При переводе на нее всех четырех этапов и отключенном уплотнении стоимость упала до $0.086 (экономия 85,3%) при F1 48,4% и задержке 0,37x. На этом бенчмарке она справилась со всеми этапами, включая ревью.
Этому способствовали две настройки обвязки. Объем усилий на рассуждения был определен путем измерений (см. раздел «Что не помогло»). Кроме того, примерно каждый седьмой вызов ревью в DeepSeek завершался без публикации; собственный шаг коррекции GitLab повторял каждый такой вызов, поэтому в итоге каждое ревью публиковалось, а повторные попытки учитывались в затратах.
Почему экономия остановилась на отметке 85%
Наша конфигурация DeepSeek принимает промпты объемом до 256K токенов; все, что превышает этот объем, остается на Sonnet 5, чтобы ревью могло завершиться. Модель поддерживает 1M, но обслуживание такого окна требует более сложного развертывания, а ее качество при работе с очень большими контекстами все еще вызывает споры. Без уплотнения некоторые промпты ревью достигают 480K, и 3 из 50 пулл-реквестов выходят за рамки лимита, генерируя 11 резервных вызовов (fallback).
Шесть процентов пулл-реквестов содержали 77% от оставшихся затрат. Причем переполняющиеся промпты — это самые крупные ревью, и они большие именно по тем причинам, о которых говорится в Находке 1.
Поэтому уплотнение возвращается в систему, на этот раз для того, чтобы промпты помещались в лимиты. Самый большой промпт ревью уменьшается с 480K до 109K. Каждое ревью помещается. Никаких возвратов к резервным моделям нет. Стоимость достигает $0.0135 за пулл-реквест, что на 97,7% ниже базового уровня, при F1 47,2% и задержке 0,35x, причем оценка второго судьи укладывается в рамки половины балла.
В этот момент экономия токенов от сжатия составляет примерно $0,006 на PR. То, что оно дает — это соответствие размеру контекстного окна. Для Claude сжатие выступает в роли оптимизации затрат. Для развертывания с окном 256K оно позволяет удерживать каждый обзор на модели с открытыми весами.
Развертывание с окном 1M также позволило бы убрать резервный вариант (fallback). Оно не уменьшило бы объем того, что читает каждый обзор, и при этом опиралось бы на модель на тех значениях длины контекста, где ее качество наименее стабильно.
Что не помогло
Результаты
Любой этап, кроме названных, работает на Sonnet 5. Ни одна настройка не изменила показатель F1 более чем на 2 пункта у каждого из судей. Обзоры финальной настройки более точны, чем у базовой (46,8% против 41,9%), но находят чуть меньше проблем (полнота 47,6% против 52,0%), при этом они используют около 9 000 токенов против 18 600 и выполняются примерно с третью от прежней задержки.
Резюме
- Затраты распределялись по трем направлениям, каждое из которых требовало своего изменения: общий контекст, механические этапы и рассуждения в обзоре.
- Haiku 4.5 сохранила качество на двух механических этапах и потеряла его на анализе и обзоре.
- Со сжатием средний промпт обзора уменьшился на 46%, в то время как объем вывода рассуждений вырос на 28%.
- На три PR из 50 приходилось 77% оставшихся затрат, пока сжатие не позволило каждому обзору поместиться в окно развертывания.
Сжатие само по себе дает экономию в 19,4%. Добавленное после смены модели, то же сжатие обеспечивает 84% от оставшихся затрат, потому что к тому моменту его задачей было уместить промпты в размер окна.
Именно такая взаимозависимость делает оптимизацию обвязки сложной и именно поэтому она приносит результаты. Настройки в этом исследовании постоянно меняли ценность друг друга. Сжатие давало пятую часть затрат на Sonnet 5 и определило исход при развертывании с окном 256K. Haiku проявила себя надежно на двух этапах и ухудшила качество на двух других. Достижение 98% потребовало поиска конфигураций в целом, и именно этот поиск принес экономию.
Конкретные настройки относятся к этому агенту, и они уже устарели: с момента проведения этого исследования GitLab перевел Duo Code Review на Sonnet 5.5. Сам метод применим шире. Измеряйте стоимость каждого этапа перед тем, как что-либо менять. Изменяйте по одной переменной за раз и заново тестируйте предыдущие изменения после внедрения каждого нового. Большинство команд не будут иметь публичного бенчмарка для работы; мы ожидаем, что этот же цикл сработает на части реального трафика, и как только конфигурация показывает себя стабильно на большей его части, она становится стандартом в обвязке.
Приложение: Как мы проводили измерения
Все элементы в таблице ниже были зафиксированы до первого запуска. Наш собственный агент помог запустить поиск в рамках этих правил, предлагая, выполняя и оценивая конфигурации.
Чтобы проверить нашу систему оценки, мы запустили ее на записанных обзорах этих PR от GitLab, которые публикует Martian: 52,3% F1 против 54,2% у Martian. Они были получены при другой конфигурации, поэтому они подтверждают нашу оценку и ничего не говорят о нашей базовой линии. Это публичные PR, поэтому их содержимое могло находиться в обучающих данных. Что мы можем исключить, так это воспроизведение моделями обзоров ответов по самому вопросу: если предоставить только название PR, URL и ссылку на коммит, обе модели показывают результат около 4% F1. Каждый файл, который читал агент, брался из зафиксированных офлайн-копий.
Спасибо команде GitLab за публикацию процесса Duo Code Review и результатов его бенчмарков, которые сделали это исследование возможным.
