AI-инструменты для написания кода приносят огромную пользу: в Databricks агентный кодинг заметно улучшил все метрики скорости разработки, а в некоторых командах дал прирост производительности на порядок. Но почти каждая компания, внедряющая AI-инструменты в масштабе, сталкивается с одной и той же проблемой — экспоненциально растущими расходами. Такая динамика неустойчива: без контроля затраты рано или поздно обгонят выручку. Взрывной рост расходов ставит компании в парадоксальную ситуацию: с одной стороны, есть желание максимально ускорить AI-трансформацию и дать сотрудникам мощные инструменты, с другой — приходится мириться с совокупным профилем затрат, который грозит свести на нет или даже обратить вспять тот самый эффект эффективности, ради которого всё затевалось.
К счастью, несколько компаний из числа первых крупных внедренцев пришли к набору подходов, решающих эту задачу и обеспечивающих «двойной мандат»: (а) широкий доступ к AI-инструментам с минимальными препятствиями и (б) удержание совокупных затрат в примерно фиксированных рамках на пользователя. Материал описывает проверенные методы управления расходами, основанные на опыте Databricks и разговорах с несколькими другими digital-native компаниями, включая Stripe, Coinbase, Uber и Ramp. В таблице ниже собраны текущие техники и связанная с ними экономия; цифры ориентировочные, получены на основе неформального опроса команд разработки:
Часть этих техник легко реализовать с помощью софта, который у многих компаний уже есть. Другие требуют новой инфраструктуры — особенно те, что модифицируют клиенты конечных пользователей или перераспределяют трафик между моделями. В Databricks в открытый доступ или бесплатно выложены ключевые компоненты инфраструктуры: мета-харнесс для конечных пользователей (Omnigent) и AI Gateway (Unity AI Gateway). Для полноты картины также рассмотрен софт, который используют другие опрошенные компании.
«Граница эффективности» для моделей кодинга
Главный рычаг снижения затрат — переход на более эффективные модели по мере их выхода. Простая формулировка «модели подешевле» скрывает за собой нетривиальную связь между стоимостью модели и качеством её работы.
В обиходе термин frontier model (модель переднего края) означает «модель с максимальным интеллектом», а лаборатории переднего края в основном сосредоточены на наращивании пикового интеллекта. Такие модели уже способны решать новые задачи в математике или кибербезопасности. Но при развёртывании AI в масштабе куда важнее другая граница — граница эффективности. Граница эффективности определяется набором моделей, которые дают лучшую цену при заданном уровне интеллекта. Большинство повседневных задач кодинга не требуют математических доказательств или новых открытий в безопасности, поэтому в совокупности важна стоимость моделей, которые проходят порог качества для типовой инженерной работы. Эта «граница эффективности» продвигается гораздо быстрее границы интеллекта: новые модели с лучшим соотношением интеллекта к цене выходят почти каждую неделю.
Рычаг снижения затрат №1: переход на open source и более дешёвые модели
Быстрое внедрение новых, более эффективных моделей даёт самую крупную экономию среди всех техник. Но чтобы этим воспользоваться, компании сначала нужно понять, какие модели действительно превосходят уже используемые. Сделать это непросто, поскольку публичные бенчмарки плохо отражают реальную производительность на задачах кодинга. Чтобы оценивать новые модели, многие компании строят собственные автоматизированные тесты, которые считают более репрезентативными для своего внутреннего пула задач разработки. Databricks недавно опубликовала пример такого бенчмарка, в котором модели GLM показали очень конкурентное соотношение цены и производительности. Этот бенчмарк стал основанием для внедрения GLM среди внутренних разработчиков. Часто новые модели не сдвигают границу эффективности, и тесты дают отрицательный результат: в Stripe обнаружили, что Opus 4.7 не даёт заметного прироста качества по сравнению с Opus 4.6, зато увеличивает расходы, — и отказались открывать Opus 4.7 внутри компании. В Databricks наблюдали похожую регрессию по стоимости при сравнении Opus 5.0 с 4.8.
Гибкость харнеса и моделей
Поскольку основная экономия приходит от перехода на новые модели, использование пользовательских инструментов, допускающих гибкий выбор модели, становится критически важным для сдерживания расходов. Инструмент, который чаще всего применяется вместе с конкретной моделью, называется харнесс. Проприетарные модели переднего края всё чаще проектируются совместно с конкретными харнессами, из-за чего определённые харнессы «лучше работают» с определёнными моделями. Если компания хочет сохранить независимость от модели, есть примерно два подхода:
Просить пользователей переключать харнессы. Один из подходов — дать разработчикам набор харнессов (Claude Code, Codex или Cursor) и просить их переключаться между ними, когда компания хочет перевести расходы на более дешёвые модели. Это позволяет пользователям работать в предпочитаемом харнессе, когда это возможно, но недостаток в том, что издержки переключения для отдельного разработчика могут быть высоки. Если такие издержки становятся слишком велики, харнесс сам превращается в фактическую привязку к семейству моделей, ограничивая возможность перераспределить расходы на более конкурентные варианты.
Использовать мета-харнесс. Более новый и набирающий популярность подход — применять мета-харнесс, который показывает разработчикам единый пользовательский интерфейс, а сам направляет запросы в разные харнессы (как проприетарные, так и открытые). Такой подход обеспечивает независимость от модели и харнесса одновременно, а также снижает издержки переключения для разработчика. В Databricks это режим по умолчанию для разработчиков, использующих Omnigent. Некоторые из опрошенных компаний создали собственные внутренние мета-харнессы, интегрированные с их инструментарием разработки.
Рычаг снижения затрат №2: динамическая маршрутизация запросов и задач
Вместо того чтобы просить пользователей самим выбирать подходящую под задачу модель, растущий массив исследований показывает: автоматический выбор модели и инструмента может дополнительно повысить эффективность агентных рабочих процессов кодинга. Подходы к маршрутизации делятся примерно на три категории:
- Маршрутизация на уровне запроса: между клиентом (например, харнессом для кодинга) и базовыми моделями находится проксирующий сервис с состоянием. Он старается направить каждый запрос на вывод к самой дешёвой модели, способной с ним справиться. Маршрутизация для агентных сценариев должна также учитывать серверное кеширование, поскольку холодное попадание в кеш обходится очень дорого при большом контексте. Новая волна продуктов показывает многообещающие ранние результаты в маршрутизации. Примеры: Cursor Router, AutoRouter от OpenRouter, функция Router компании Ramp и собственная функция Smart Routing в Unity AI Gateway от Databricks.
- Маршрутизация на уровне задачи (мета-харнесс): процесс на стороне клиента распределяет пользовательские задачи по разным харнессам в зависимости от их сложности. Задача пользователя может быть простой («переименуй этот компонент из X в Y») или открытой, требующей исследования («изучи варианты снижения задержки»). Диспетчер, часто называемый мета-харнессом, определяет, какой уровень модели нужен для задачи, и передаёт всю задачу целиком этой модели. Omnigent — пример мета-харнесса, поддерживающего такой паттерн.
- Паттерны эскалации/делегирования: один харнесс работает с парой моделей — дорогой, высокоинтеллектуальной и дешёвой рабочей. В некоторых подходах, например в Advisor Tool от Claude, ведущую роль играет более дешёвая модель, которая эскалирует задачу, если считает, что нужна более мощная модель. Существует и обратный паттерн: в Devin Fusion от Cognition основной цикл ведёт более дорогая модель, избирательно передавая часть работы более дешёвой.
Внутренние результаты Databricks показывают, что Smart Router в AI Gateway стабильно снижает среднюю стоимость задачи более чем на 30%, при этом качество остаётся сопоставимым с самой дорогой моделью в рабочем наборе. Другие опрошенные компании отмечают похожие результаты.
Рычаг снижения затрат №3: прозрачность, предохранители и бюджеты для разработчиков
Может показаться удивительным, что вся статья не свелась к простому «дайте пользователям месячный бюджет — и дело с концом». Жёсткие бюджеты, при которых доступ полностью отключается по достижении порога расходов, во всех опрошенных компаниях применяются лишь как крайняя мера. На это есть две причины. Во-первых, если разработчик упирается в потолок бюджета, полное отключение доступа к AI-инструментам сильно бьёт по продуктивности — такого исхода не хочет ни компания, ни сотрудник. Во-вторых, среди «больших тратчиков» нередко оказываются как раз те, кто добился колоссального роста эффективности благодаря AI и выдаёт огромный объём работы. Ограничивать таких пользователей контрпродуктивно.
Вместо жёсткого лимита расходов на пользователя большинство компаний применяют более гибкий и постепенный подход, делая упор на прозрачность для конечных пользователей и нарастающее сопротивление по мере роста трат.
Прозрачность. У каждой опрошенной компании есть механизм почти мгновенной обратной связи по текущим расходам, причём многие также дают конкретные советы о том, как снизить траты за счёт менее дорогих моделей. Важно, чтобы пользователи видели свои расходы по всем инструментам сразу — это помогает выбирать инструмент с наибольшей отдачей.
Дашборд разработчика в Databricks с текущими расходами
- Ограничители трат. Разработчиков могут просить выполнить определённые действия или получить согласование по мере роста расходов. Простейшая форма такого ограничителя — снимаемый самим пользователем предупреждающий сигнал о том, что темп трат превысил порог. В Databricks такие самоснимаемые ограничители оказались полезным механизмом против случайных или непреднамеренных трат. Дальше могут вводиться ограничители, требующие явного согласования бюджета — часто через управленческую цепочку.
- Понижение уровня модели. Если разработчик упёрся в ограничитель, его могут перевести на более дешёвую модель вместо полного отключения от токенов. Поскольку самые дешёвые модели обходятся радикально дешевле моделей переднего края по интеллекту, это позволяет разработчику продолжать работу без огромных постоянных трат.
- Приостановка доступа. В предельном случае большинство систем сохраняют возможность полностью отключить пользователя от доступа к токенам. Как отмечалось выше, это обычно временная мера и отправная точка для разговора о том, как эффективнее использовать AI.
Рычаг снижения затрат №4: сокращение накладных расходов на токены
Когда пользователь вводит в AI-агента для кодинга относительно простой запрос («пожалуйста, найди и исправь эту ошибку»), агент затем собирает огромный объём релевантного контекста, вызывает множество инструментов, ищет по кодовой базе и подключает навыки или системную информацию, предоставленную компанией. К моменту дорогостоящего вывода LLM исходная формулировка пользователя составляет лишь ничтожную долю данных, поданных в систему, — то есть затраты определяются в основном контекстом, который пользователь явно не указывал. Техники борьбы с раздуванием контекста пока новы, но уже прорабатывается несколько многообещающих подходов:
- Принудительное более частое сжатие (компакция) активного контекста.
- Использование «менее болтливых» (более экономных по токенам) харнессов или настройка существующих для снижения накладных расходов.
- Аудит популярных инструментов и снижение их многословности.
- Стимулирование разработчиков разбивать задачи на более мелкие единицы работы, сужая область контекста.
При больших контекстах заметную роль в общей производительности играет также кеширование промптов. И проприетарные, и открытые LLM позволяют включать кеширование промптов и настраивать срок хранения кеша. Запись в кеш стоит денег, но чтение из кеша резко снижает стоимость вывода. Баланс между этими затратами зависит от конкретной нагрузки компании, поэтому ручная настройка параметров кеширования по умолчанию для повышения доли попаданий в кеш может дать значительное снижение общих затрат.
В Databricks относительно простая настройка харнесса и параметров кеширования привела почти к 50%-ному сокращению числа генерируемых токенов и связанных с этим расходов без заметного снижения качества для разработчиков. Работа над техниками в этой области продолжается, и есть основания полагать, что возможна ещё существенная оптимизация.
Резкое снижение числа токенов на сессию за счёт устранения лишних вызовов вывода и сокращения записей в кеш.
Паттерн проектирования AI Gateway
Все описанные техники предполагают ряд неявных технических требований. Чтобы быстро использовать преимущества новых моделей, компании нужно центральное место, где управляется «меню моделей», а инструментарий конечных пользователей должен поддерживать смешивание моделей. Чтобы обеспечить прозрачность бюджета по нескольким AI-инструментам сразу, нужна единая система наблюдаемости расходов. Чтобы бороться с раздуванием контекста, компании нужен способ отслеживать типичные результаты вызовов инструментов и принудительно применять сжатие или компакцию. Все эти потребности решает новый класс инфраструктурного софта, который лучше всего описать как AI Gateway. AI Gateway — это центральная точка, где происходит следующее:
- Управление ёмкостью и проксирование доступа к базовым моделям (как проприетарным, так и открытым).
- Отслеживание и обеспечение соблюдения бюджета, включая сложные политики — например, постепенно нарастающее сопротивление и понижение уровня модели.
- Управление конфигурацией инструментов для конечных пользователей — для соблюдения списков разрешённых моделей, настроек компакции и других локально регулируемых параметров.
- Логирование трасс сессий кодинга для последующего анализа эффективности и бенчмаркинга.
В Databricks для всех этих задач активно используется Unity AI Gateway.
Собираем всё воедино
Экспоненциальный рост расходов на AI-кодинг — не неизбежность, а решаемая инженерная и управленческая задача. Компании, которым удалось её укротить, следуют общей стратегии: гонятся за границей эффективности, а не границей интеллекта, внедряют инструменты, сохраняющие гибкость выбора модели, разумно маршрутизируют работу к самой дешёвой подходящей модели, заменяют жёсткие бюджеты прозрачностью и постепенным сопротивлением, а также сокращают накладные расходы на токены, которые доминируют в реальных затратах. Ни одна из этих техник не требует жертвовать приростом продуктивности, ради которого AI и внедрялся; вместе они позволяют организациям выполнить двойной мандат — широкий доступ с минимальными препятствиями в рамках предсказуемого бюджета.
Формируется новый набор инфраструктурных абстракций, дающих компаниям инструменты для управления расходами. В Databricks ключевые компоненты собственного стека управления затратами выпущены как open source или бесплатный софт: Unity AI Gateway для централизованного управления и Omnigent для инструментария разработчиков. Тысячи компаний используют эти компоненты ежедневно. Databricks приглашает другие компании делиться результатами и сравнивать техники по мере быстрого развития этого технологического ландшафта.
Благодарности: спасибо руководителям инфраструктурных команд Uber, Stripe, Coinbase и Ramp за комментарии и рецензии к этому материалу. Спасибо Thrive Capital за отзыв о ранней версии текста.