Snowflake добавляет маршрутизацию моделей ИИ для сокращения расходов
Источник: VentureBeat · Sean Michael Kerner
Корпоративные команды, использующие ИИ-агенты в больших масштабах, сталкиваются с тем, что ни одна отдельная модель не справляется со всеми задачами одинаково хорошо: либо модель слишком дорога для простых вопросов, либо недостаточно мощна для сложных. Решением этой проблемы становится динамическая маршрутизация моделей, которая автоматически подбирает оптимальный инструмент для каждой конкретной задачи.
Шлюз Cortex AI Gateway от Snowflake теперь предлагает функцию динамической маршрутизации моделей: вместо фиксированной модели предприятия могут выбрать настройку «auto», и система направит каждый запрос к модели, обеспечивающей наилучшее соотношение качества и стоимости. По данным внутренних тестов Snowflake, эта функция способна сократить расходы на токены до трех раз на некоторых типах рабочей нагрузки. Компания выяснила, что простые вопросы часто обрабатывались ее самой мощной моделью, из-за чего ответы обходились дороже и генерировались медленнее, чем необходимо.
Это нововведение появилось на фоне общего тренда индустрии на автоматическую маршрутизацию моделей. Databricks, AWS, Google Cloud и Nvidia уже объявили о создании собственных технологий маршрутизации. При этом в Snowflake утверждают, что маршрутизация моделей — это нечто большее, чем просто соотношение цены и производительности; речь также идет об управлении доступом и контексте.
«Для создания качественных ИИ-агентов корпоративного уровня крайне важно правильно настроить контекст и управление доступом, — рассказал в интервью VentureBeat Барис Гюльтекин (Baris Gultekin), вице-президент по искусственному интеллекту в Snowflake. — Контекст, доверие и выбор модели неразрывно связаны друг с другом».
Два механизма определяют судьбу задачи
Новая функция опирается на Cortex AI Gateway — шлюз, запущенный Snowflake в июле 2026 года в качестве уровня управления для трафика моделей и агентов. По словам Гюльтекина, до появления динамической маршрутизации выбор моделей основывался на статичном списке для каждой задачи, а не на полноценной системе резервного переключения.
Сама динамическая маршрутизация, как пояснил Гюльтекин, работает на основе двух механизмов.
Первой за дело берется небольшая модель. В рамках подхода, который в Snowflake называют «паттерном советника», сначала задачу пытается решить более компактная модель. Если она не справляется с работой, она вызывает более крупную модель в качестве инструмента и продолжает выполнение с ее помощью.
Классификатор сортирует запросы по истории задач. Отдельный классификатор, обученный на прошлых запросах, автоматически направляет очевидные вопросы к более простым моделям.
Клиенты по-прежнему могут зафиксировать модель. Автоматическая маршрутизация не является обязательной. Клиенты могут ограничить маршрутизацию одной моделью или определенным набором моделей, и система будет распределять запросы строго в этих пределах.
Никакой отдельной платы. Snowflake тарифицирует ИИ исключительно по объему использованных токенов. Перенаправление запроса на более дешевую модель уменьшает итоговый счет, при этом за само решение о маршрутизации плата не взимается.
Контроль доступа следует за задачей, а не только за данными
Snowflake связывает маршрутизацию с теми же средствами контроля доступа, которые она уже использует для управления данными.
Управление начинается на уровне данных с использованием ролевого доступа. Затем оно распространяется на модели, где роли клиентов сопоставляются с наборами одобренных моделей. Наконец, оно переносится на агентов: права агента могут быть существенно уже, чем у пользователя, который его запускает.
Открытые модели могут работать в рамках собственного региона клиента, чтобы удовлетворять требованиям к локализации данных. Гюльтекин отметил, что все операции вывода (inference) — как для открытых, так и для проприетарных моделей — остаются внутри периметра безопасности Snowflake, а не перенаправляются к внешнему провайдеру. Такая региональная настройка и настройка периметра особенно важны для открытых моделей неамериканского происхождения, включая DeepSeek-V4-Flash и GLM-5.3, обе из которых разработаны в Китае.
Недавнее приобретение компании Natoma добавляет еще один уровень защиты. Эта сделка приносит более 100 коннекторов Model Context Protocol (MCP) с ограниченным и контролируемым доступом. Например, агент может получить доступ только на чтение к такому инструменту, как электронная почта, вместо расширенных разрешений.
Контекст позволяет более дешевой модели справляться с работой
Компания Snowflake недавно анонсировала инструменты Horizon Context и Cortex Sense, предоставляющие возможности работы с контекстом.
Без качественного контекста модели приходится выполнять исследовательскую работу самостоятельно: писать и тестировать код SQL, искать данные и повторять попытки при возникновении ошибок. Гюльтекин пояснил, что этот процесс обходится дорого, и для его успешного завершения обычно требуется более мощная модель. Предварительная подготовка и упаковка контекста исключают этот исследовательский этап, благодаря чему с аналогичной задачей часто может справиться более простая и дешевая модель.
Кроме того, Snowflake встраивает в этот контекст память агента. По мере того как агент используется снова и снова, его память обновляется и учитывается в будущих запросах. Системе не приходится каждый раз решать одну и ту же проблему с нуля. Память становится частью контекста, передаваемого модели.
OpenRouter, Databricks и Nvidia решают ту же задачу
В сфере маршрутизации моделей нет недостатка в технологиях. OpenRouter — один из самых известных вариантов, предоставляющий платформу, которая позволяет организациям направлять запросы на основе затрат и производительности. 11 августа компания Nvidia анонсировала технологический уровень Switchyard для оптимизации выбора ИИ-моделей. Компания Databricks также предлагает собственное решение — Smart Routing для своего шлюза Unity AI Gateway.
«Самое интересное в этой ситуации — то, как она отражает смещение точек дифференциации, — рассказал VentureBeat Санджив Мохан (Sanjeev Mohan), главный аналитик и основатель компании SanjMo. — Snowflake на самом деле продает не просто маршрутизацию, а маршрутизацию, которая никогда не покидает защищенный периметр данных, с уже настроенным контролем доступа, тегированием и распределением затрат».
Мохан добавил, что для компании, чьи данные и требования к комплаенсу уже сосредоточены вокруг Snowflake, маршрутизация, сохраняющая данные на месте и распределяющая расходы по командам, является мощным инструментом решения этой проблемы. Для компании, у которой нет такого технологического ядра, нейтральный шлюз может обеспечить более гибкую маршрутизацию по большему количеству моделей.
Мохан делит этот рынок не на единое конкурентное поле, а на три отдельных лагеря. Databricks подходит к управлению данными со стороны дата-инженерии и линейности процессов машинного обучения. Ее каталог Unity Catalog управляет данными, моделями и конвейерами для команд, занимающихся созданием и обучением моделей. Snowflake подходит к управлению со стороны аналитики и контроля доступа, определяя, кто к каким данным имеет доступ, и распределяя использование по бизнес-подразделениям. Третий лагерь включает нейтральные шлюзы, такие как OpenRouter, LiteLLM, Portkey, а также маршрутизаторы от крупных облачных провайдеров (hyperscalers), например Azure AI Foundry. Они конкурируют за счет широты выбора моделей и предотвращения привязки к одному поставщику (vendor lock-in), а не за счет глубокого управления доступом.
Выбор маршрутизатора — это выбор модели управления
Маршрутизация моделей стала базовым требованием для бизнеса. Главное решение, которое необходимо принять компаниям, заключается в том, какая модель управления уже соответствует структуре их данных и команд, а не в том, чей маршрутизатор работает быстрее или дешевле.
Ручной выбор моделей становится бременем для бюджета при масштабировании работы агентов. Подходы, которые работали, когда команда запускала всего несколько агентов, перестают работать при массовом использовании. Сотни агентов, совершающих рутинные вызовы моделей без автоматического контроля затрат, быстро формируют огромные счета.
Оценивайте модель управления, а не список функций маршрутизатора. По мнению Мохана, реальный вопрос заключается в том, какая модель управления соответствует уже развернутой инфраструктуре данных и какая из них обеспечивает достаточную прозрачность затрат, чтобы избежать неприятных сюрпризов.
Правильная отправная точка зависит от того, где уже хранятся данные компании. По словам Мохана, для пользователей экосистемы Snowflake платформа маршрутизации внутри экосистемы, учитывающая существующую модель доступа и распределяющая расходы по центрам затрат, принесет больше пользы, чем простое разнообразие моделей. Команде, ориентированной на Databricks и обеспокоенной вопросами отслеживания данных от обучения до развертывания, лучше подойдет шлюз, построенный вокруг той же логики линейности. Мультиплатформенная команда или команда с приоритетом на модели, которой требуется максимальный выбор при минимальной привязке к вендору, выиграет от использования нейтрального шлюза — это тот самый аргумент, на котором строится оценка OpenRouter.
«Специалистам я бы посоветовал начинать не с выбора маршрутизатора, а с того, где уже находятся ваши управляемые данные и технологические обязательства компании, а также с того, насколько сильно ваши маржинальные показатели зависят от стоимости вывода», — резюмировал Мохан.



