Databricks рассказала, как компании держат расходы на ИИ-кодинг под контролем

Databricks опубликовала в своём блоге статью (авторы, Patrick Wendell, Akshat Bhatia, Vinay Gaba, Erich Elsen и Ivan Zhou), в которой обобщила проверенные приёмы управления расходами на ИИ-инструменты для кодинга в масштабе компании. Материал опирается на собственный опыт Databricks и на разговоры с другими digital-native компаниями, Stripe, Coinbase, Uber и Ramp. Отправная точка: ИИ-агенты в разработке дают измеримый прирост скорости, в Databricks улучшились все метрики скорости разработки, а в некоторых командах производительность выросла на порядок, но расходы на них растут экспоненциально и грозят обогнать выручку. Задача, которую решают авторы, совместить широкий доступ сотрудников к ИИ-инструментам с примерно фиксированным бюджетом на пользователя.

Главный рычаг экономии, по статье, гонка за «фронтиром эффективности» (efficiency frontier), а не за «фронтиром интеллекта» (intelligence frontier). Лаборатории соревнуются за максимальный интеллект моделей, но для повседневного кодинга важнее соотношение цена/качество, а оно улучшается у новых моделей заметно быстрее, чем сам интеллект: модели с лучшим соотношением «интеллект на доллар» выходят почти каждую неделю. Чтобы этим пользоваться, компаниям нужны собственные бенчмарки, публичные тесты плохо предсказывают реальную производительность на задачах разработки. Пример из статьи: внутренний бенчмарк Databricks показал высокую конкурентоспособность моделей GLM по цене и качеству, и компания перевела на них часть разработчиков. Но выигрыш не гарантирован: Stripe протестировала Opus 4.7 и не увидела заметного прироста качества по сравнению с Opus 4.6 при более высокой цене, поэтому не стала выкатывать Opus 4.7 внутри компании; Databricks заметила похожую просадку по стоимости при сравнении Opus 5.0 с Opus 4.8.

Чтобы быстро переключаться между моделями, компании либо просят разработчиков вручную менять «харнесс», инструмент вроде Claude Code, Codex или Cursor (это дёшево обходится компании, но дорого, самому разработчику, из-за издержек на переключение и риска привязки к одной модели), либо ставят между разработчиком и моделями мета-харнесс, который даёт единый интерфейс и сам распределяет запросы между разными харнессами и моделями. В Databricks для этого используется собственный инструмент Omnigent, выложенный компанией в открытый доступ.

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

Ещё один источник расходов, раздувание контекста: когда разработчик пишет агенту простую просьбу вроде «найди и исправь этот баг», агент подтягивает огромный объём контекста, код, инструменты, системную информацию, и к моменту обращения к модели исходный запрос пользователя составляет ничтожную долю всех передаваемых данных, поэтому основные расходы приходятся именно на этот «довесок». Здесь помогает кэширование промптов: запись в кэш стоит денег, но повторное чтение из кэша обходится намного дешевле полного инференса. По словам авторов, точная настройка харнесса и параметров кэширования в самой Databricks привела почти к 50%-ному сокращению числа генерируемых токенов и связанных с ними расходов без заметной потери качества для разработчиков.

Все эти техники, по мнению авторов, складываются в новый класс инфраструктуры, «ИИ-шлюз» (AI Gateway): центральную точку, где управляют «меню моделей», отслеживают траты по всем инструментам и следят за раздуванием контекста. В Databricks эту роль играет Unity AI Gateway, который вместе с Omnigent выложен в открытый доступ и, по словам авторов, ежедневно используется тысячами компаний. Статью рецензировали специалисты по инфраструктуре из Uber, Stripe, Coinbase и Ramp, а отзыв на черновик дал венчурный фонд Thrive Capital.

Ключевые факты

Databricks вместе со Stripe, Coinbase, Uber и Ramp обобщила проверенные приёмы борьбы с экспоненциальным ростом расходов на ИИ-кодинг.
Главный рычаг, гонка за «фронтиром эффективности» (цена/качество), а не за максимальным интеллектом модели: бенчмарк Databricks показал конкурентоспособность моделей GLM, а Stripe отказалась от Opus 4.7 из-за роста цены без прироста качества над Opus 4.6.
Вместо жёстких бюджетов компании показывают сотрудникам их траты почти в реальном времени и постепенно наращивают трение по мере роста расходов, а не отключают доступ полностью.
Настройка харнесса и кэширования промптов сократила число генерируемых токенов и расходы у Databricks почти на 50% без потери качества.
Databricks выложила в открытый доступ свои инфраструктурные компоненты, AI-шлюз Unity AI Gateway и мета-харнесс Omnigent, которыми, по её словам, ежедневно пользуются тысячи компаний.

Почему это важно

ИИ-агенты для кодинга дают измеримый прирост производительности, но расходы на них растут экспоненциально и грозят обогнать выручку компании. Databricks описывает сдвиг от гонки за самой «умной» (и дорогой) фронтир-моделью к гонке за лучшим соотношением цена/качество, «фронтиром эффективности», который движется быстрее фронтира интеллекта. Это меняет сам критерий выбора модели: не абсолютная сила, а цена за нужный уровень качества на конкретных задачах разработки.

Кому это важно

В первую очередь, платформенным и инфраструктурным командам компаний, которые уже раздали сотрудникам массовый доступ к ИИ-агентам для кодинга (Claude Code, Codex, Cursor и подобным) и столкнулись со счетами за API. Также материал полезен разработчикам инфраструктуры вроде AI-шлюзов и мета-харнессов, статья описывает, какую функциональность от них ждёт рынок.

Как это применить

Из статьи следуют конкретные шаги: строить собственные бенчмарки под свой профиль задач вместо доверия публичным рейтингам; выбирать инструменты, не привязывающие компанию к одной модели (мета-харнесс вроде Omnigent или готовность вручную менять харнессы); настраивать кэширование промптов и бороться с раздуванием контекста; вместо жёстких лимитов расходов давать сотрудникам видимость трат и мягко наращивать трение по мере их роста, а не отключать доступ полностью. Ключевые компоненты своего стека, Unity AI Gateway и Omnigent, Databricks выложила в открытый доступ.

Можно ли доверять

Материал опубликован Databricks на собственном блоге и явно продвигает её open-source продукты, Unity AI Gateway и Omnigent, это стоит учитывать. При этом выводы опираются не только на данные самой Databricks, но и на разговоры с инфраструктурными командами Stripe, Coinbase, Uber и Ramp, которые, по тексту, рецензировали статью. Конкретные цифры экономии по отдельным техникам (кроме ~50% по токенам у Databricks) в тексте не приводятся, только общая таблица с «ориентировочными» оценками, которая в извлечённый текст не попала.

Риски и подводные камни

Автоматическое переключение между моделями и харнессами добавляет инфраструктурную сложность и создаёт новую точку отказа, сам AI-шлюз. Модель «видимость плюс нарастающее трение» вместо жёстких бюджетов требует ручной настройки порогов и вряд ли сработает в компании без развитой культуры финансовой дисциплины. Наконец, статья не раскрывает абсолютных сумм расходов Databricks на ИИ-кодинг, так что о масштабе проблемы приходится судить только косвенно.