Исследование IBM: кэш важнее тарифов, и это удваивает расходы на ИИ

Исследование IBM Research, опубликованное 15 июля 2026 года, показывает, что автоматический выбор моделей искусственного интеллекта для бизнес-задач сложнее, чем кажется. Простая логика «отправлять простые запросы дешевым моделям, а сложные — дорогим» не работает в реальных условиях из-за скрытых факторов стоимости и задержек. Эффективность системы зависит не от характеристик отдельной модели, а от взаимодействия модели, типа нагрузки и инфраструктуры.

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

Стоимость зависит от кэширования, а не от ценника

Команда исследователей протестировала 417 задач на платформе AppWorld Test Challenge с использованием агента CodeAct. Ожидалось, что модель GPT-4.1 будет дешевле Claude Sonnet 4.6 из-за более низких тарифов на токены. Однако итоговые расходы показали обратное:

• Claude Sonnet 4.6: общие затраты составили $79 ($0.19 за задачу).
• GPT-4.1: общие затраты достигли $155 ($0.37 за задачу), что почти в два раза выше.

Парадокс объясняется механизмом кэширования. Агенты часто используют одни и те же большие объемы контекста на разных этапах работы. Модель Sonnet имеет более низкую стоимость чтения из кэша, что позволило ей компенсировать более высокую базовую цену и большее количество шагов рассуждений. Если маршрутизатор учитывает только официальные прайс-листы, он оптимизирует систему по неверным данным.

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

Сложность задачи и задержки скрыты от маршрутизатора

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

Задержка (латентность) также не зависит только от размера модели. На итоговое время ответа влияют:

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

На фоне этого: Игнорирование состояния инфраструктуры при выборе модели может привести к тому, что теоретически более быстрый алгоритм будет работать медленнее на практике.

Оптимизация вместо классификации

Команда IBM Research перешла от подхода классификации («какая модель лучше?») к подходу оптимизации («как настроить систему для лучшего результата?»). Алгоритм теперь одновременно оптимизирует стоимость, качество и задержку, оставаясь при этом легковесным (занимает около 6 мс и 2 КБ памяти на задачу).

Результаты тестов на AppWorld Test Challenge демонстрируют гибкость подхода:

• Конфигурация 1 (оптимизация скорости): точность 84%, стоимость $93, время 83 секунды. Это дало снижение затрат на 21% и задержки на 9% по сравнению с использованием только модели Opus, при потере точности всего на 4%.
• Конфигурация 2: позволяет снизить стоимость еще сильнее, жертвуя другими параметрами.
• Стандартный маршрутизатор, основанный только на сложности задачи, показал худшие результаты по стоимости при схожей точности, так как не рассматривал полный спектр компромиссов.

Операционные последствия и практические аспекты

• Необходимость пересмотра метрик: Компании должны учитывать не только стоимость токенов, но и стоимость операций с кэшем при выборе провайдера ИИ. Игнорирование этого фактора может привести к удвоению расходов на автоматизацию.
• Сложность внедрения: Маршрутизаторы должны быть способны обрабатывать не только технические параметры, но и корпоративные правила (комплаенс, географию данных), что требует интеграции с системами управления доступом и политиками безопасности.
• Риск задержек: Частая перемаршрутизация запросов на каждом шаге выполнения задачи может свести на нет выигрыш от использования быстрых моделей, увеличивая общее время отклика системы.
• Гибкость настроек: Внедрение оптимизационных алгоритмов позволяет бизнесу выбирать точку баланса между скоростью, качеством и стоимостью в зависимости от текущих приоритетов, а не быть привязанным к одной фиксированной конфигурации.