Перед лицом роста расходов на ИИ наиболее частым ответом является ограничение использования: лимиты потребления, количество мест и утверждения перед запуском агентов. Однако такие недифференцированные ограничения могут сдерживать полезные сценарии использования и измерять не тот показатель, как показывает анализ.
Стоимость за токен (единицу текста, обрабатываемой языковой моделью) измеряет потребление, а не результаты. Часть расходов соответствует потерям, таким как повторные запросы или неконтролируемые циклы, в то время как другая часть представляет реальную работу по доставке программного обеспечения. Счётчик не позволяет их различить, равно как и лимит расходов.
Измерять доставленное ПО
Более релевантным показателем был бы стоимость за принятый запрос на слияние, то есть общая стоимость разработки с помощью ИИ, разделённая на количество изменений, прошедших ревью и интегрированных в код, называемых « пулл-реквестами » в жаргоне. Параллельно нужно отслеживать правки и дефекты, чтобы более дешёвые изменения не маскировали снижение качества.
Если эта стоимость снижается при росте использования без ухудшения качества, разработчики превращают больше потребления в полезное ПО. Таким образом, вопрос не в количестве использованных токенов, а в объёме завершённой работы, который производит инвестиция. Для улучшения этого баланса предлагаются два рычага: резервировать дорогой вывод (инференс) для задач, которые в нём нуждаются, и снижать стоимость рутинной работы.
Адаптировать модель к задаче
Агентная разработка, в которой агент автономно пишет и изменяет код, не требует самой мощной модели на каждом этапе. Передовая модель или флагманская модель, размещённая локально, когда этого требует политика компании, может быть зарезервирована для сложного планирования и нестандартных рассуждений. Более простые задачи, такие как генерация кода, создание тестов или повторяющиеся рефакторинги, можно поручить моделям с открытыми весами (« open-weight »), эксплуатируемым непосредственно компанией.
Шлюз (« gateway ») может направлять каждый запрос в зависимости от его сложности, чувствительности данных, стоимости и задержки. Таким образом, первая модель используется только тогда, когда ситуация это оправдывает. Как резюмирует автор, « Meter the exception, not the workload », то есть: измеряйте исключение, а не рабочую нагрузку.
Модели с открытыми весами делают такое распределение всё более осуществимым. Согласно приведённым бенчмаркам в области программной инженерии, лучшие из них могут приближаться к производительности передовых моделей в определённых задачах. Это наблюдение не гарантирует эквивалентность на всех репозиториях кода или рабочих процессах. Поэтому рекомендуется оценивать кандидатов на своём собственном коде, своих тестах и критериях приёмки, прежде чем поручать им работу в продакшене.
Изменить экономику повторяющихся сценариев использования
Остаётся определить, кто владеет вычислительными мощностями. При арендованном инференсе каждый вызов добавляется к счёту. При собственных мощностях основная часть стоимости фиксируется изначально, так что каждый дополнительный вызов становится дешевле по мере роста использования.
