Fireworks AI утверждает, что компании переплачивают за ИИ, когда отправляют все задачи в одну большую модель: правильная маршрутизация ИИ-запросов способна сократить счёт как минимум вдвое. Для российских команд, которые считают стоимость чат-ботов, RAG-систем и внутренних copilot-инструментов, это означает простой сдвиг: сравнивать нужно не цену токена, а стоимость выполненной задачи.
Вице-президент Fireworks AI Роб Фергюсон в разговоре с The Register раскритиковал привычную схему, при которой компания покупает или арендует GPU и пытается загрузить ими собственный инференс. По его оценке, парк из 10 тысяч GPU — это около $1 млрд капитальных затрат. Если ускорители простаивают, экономика проекта быстро теряет смысл: железо дорогое, а спрос на ИИ-запросы обычно неравномерен.
Fireworks AI продаёт управляемый инференс и поддерживает развёртывание моделей в инфраструктуре заказчика, но сама старается уводить клиентов от такого сценария. Исключение — чувствительные нагрузки: для них у компании есть сервис Sovereign и партнёры, включая Microsoft. Однако Фергюсон считает, что большинству задач не требуется настолько изолированная среда, а гибкая облачная инфраструктура лучше переживает скачки нагрузки.
Главный тезис Fireworks: лучшая система — не «самая сильная» модель, а портфель моделей. Платформа Nexus и API компании должны оценивать поступившую задачу, определять её сложность и направлять на подходящую закрытую, открытую или кэшированную модель. Это отличается от простого AI-шлюза, который маршрутизирует трафик по заранее заданным правилам. В Fireworks говорят о постоянно обновляемом автоматическом маршрутизаторе, учитывающем специализацию моделей: например, одна из них может лучше справляться с JavaScript, чем с Python.
Идея не новая: на рынке управляемого инференса уже работают Together AI, Baseten и DeepInfra. Но она становится заметнее по мере того, как компании перестают экспериментировать с единичными чатами и начинают обслуживать тысячи однотипных запросов. Для извлечения данных из документов, классификации обращений, генерации тестов и первичного поиска часто не нужна дорогая frontier-модель. А вот сложный анализ кода, неоднозначные юридические документы или многошаговые агентные сценарии могут оправдать более мощный и медленный вызов.
Фергюсон связывает преимущество Fireworks с инженерной экспертизой команды, часть которой работала над PyTorch. В инференсе важны не только сами модели, но и топология вычислений, работа с разреженными архитектурами и точностью чисел с плавающей запятой. Ошибка в распределении данных между «экспертами» в mixture-of-experts-модели не обязательно даст явный сбой, но может ухудшить ответ. Для бизнеса это обычно выглядит скучнее, чем презентация очередной LLM, зато напрямую влияет на задержку, качество и загрузку GPU.
Отдельный источник расходов — повторная обработка запросов. Fireworks приводит пример работы с компанией из сферы data science: собственная система, по словам Фергюсона, обслуживала из кэша около 90% задач, тогда как при использовании Anthropic Opus доля кэширования составляла 30%. Проверить эти цифры независимо из материала нельзя, поэтому воспринимать их стоит как позицию поставщика. Но сам принцип полезен: низкая цена входного токена мало говорит о реальном бюджете, если приложение регулярно повторяет контекст, заново вызывает модель или не умеет переиспользовать результаты.
Именно поэтому Fireworks советует клиентам считать cost per task — стоимость завершённой задачи, а не стоимость миллиона токенов. В эту метрику должны попадать неудачные ответы, повторные попытки, задержки, цена контекста и необходимость подключать более дорогую модель для исправления результата. Маршрутизация ИИ-запросов здесь превращается из инфраструктурной детали в продуктовую механику: правила выбора модели нужно строить на собственных тестах качества, а не на публичных бенчмарках поставщика.
Для разработчиков это означает необходимость завести набор реальных задач и регулярно прогонять его через несколько моделей. Полезно заранее разделить запросы по риску и сложности: дешёвую модель — для массовой рутинной обработки, специализированную — для кода или извлечения структурированных данных, наиболее сильную — для редких случаев, где цена ошибки высока. Нужны и предохранители: порог уверенности, проверка формата, эскалация на следующую модель и измерение качества после запуска. Иначе автоматический роутинг станет лишь ещё одним слоем, который экономит токены, но тихо портит результат.
В споре об облаке и собственных GPU нет универсального победителя. Крупный стабильный поток и требования к локальному хранению данных могут оправдать on-premise, но для большинства команд важнее эластичность и прозрачная экономика. Следующий конкурентный фронт в ИИ-инфраструктуре, похоже, будет не вокруг того, кто предложит самую громкую модель, а вокруг того, кто точнее подберёт модель, кэш и вычисления под конкретную работу.
