В Cloudflare AI Gateway добавлены псевдонимы моделей, что позволяет клиентам размещать пул моделей под одним именем, используемым приложениями. К псевдониму может применяться либо упорядоченная резервная политика, либо интеллектуальная маршрутизация, в то время как клиенты отправляют псевдоним в качестве имени модели через REST API.
шлюза.Практическое изменение заключается в разделении идентификатора модели, запрашиваемого приложением, и модели, которая в конечном итоге обрабатывает запрос. Операторы шлюза могут изменять пул, политику маршрутизации или базовые модели без повторного развертывания каждого клиента, использующего псевдоним. Cloudflare сообщает, что псевдонимы привязаны к отдельным шлюзам.
Это больше, чем просто удобство переименования моделей. Он предоставляет операторам стабильный интерфейс для приложений, в то время как доступность поставщиков, версии моделей и предпочтения маршрутизации меняются.
Стабильное имя для меняющегося пула моделей
Без уровня псевдонимов приложения обычно зависят от идентификаторов модели, специфичных для поставщика. Поэтому замена модели, добавление резервного варианта или перемещение трафика к другому провайдеру может потребовать изменения конфигурации нескольких сервисов. Он также может передавать логику повторных попыток и выбора поставщика каждому клиенту.
Реализация Cloudflare переносит эти решения в шлюз. С помощью упорядоченного резервного варианта оператор может определить предпочтительную модель и альтернативы, которые следует попробовать, если первый вариант не может обслужить запрос. Интеллектуальная маршрутизация представляет собой альтернативу, управляемую политикой, при которой шлюз выбирает данные из пула, а не следует фиксированной последовательности.
Такая схема особенно актуальна для мультимодельного API шлюза для команд. Команда разработчиков программного обеспечения может дать приложениям устойчивое имя модели, централизованно изменяя реализацию. Он также может стандартизировать идентификатор, используемый несколькими внутренними службами, сокращая количество миграций моделей, которые необходимо согласовывать с владельцами приложений.
Однако псевдоним остается привязанным к шлюзу. Организациям, использующим несколько шлюзов Cloudflare, необходимо будет отдельно управлять эквивалентными псевдонимами, если они хотят, чтобы имена и политики были согласованными в разных средах или бизнес-подразделениях.
Аварийное переключение становится проще, но наблюдаемость становится сложнее
Пулы моделей могут повысить устойчивость, поскольку приложениям больше не нужен собственный код выбора поставщика и резервный код. Если оператор меняет упорядоченный пул, приложение продолжает вызывать тот же псевдоним. Тот же механизм может поддерживать обновление модели или смену поставщика без изменения клиентского контракта.
Но стабильные идентификаторы вводят различие в учете, которое операторы не могут игнорировать. Журналы и записи использования должны сохранять как псевдоним, запрошенный клиентом, так и модель, которая фактически обслуживала запрос. В противном случае запрос, отправленный только под псевдонимом, может скрыть различия в цене, задержке, качестве вывода или обработке поставщика.
Это важно для возврата платежей и поддержки клиентов, а также для технической отладки. Когда два запроса к одному и тому же псевдониму обслуживаются разными моделями, их стоимость и поведение могут различаться, даже если конфигурация клиента не изменилась. Поэтому Плоскость управления AI API для команд разработчиков требует атрибуции на уровне выполнения, а не только подсчетов, сгруппированных по общедоступному имени модели.
Оценка также становится постоянной оперативной задачей. Изменение маршрутизации может повлиять на поведение приложения без развертывания кода, поэтому командам следует тестировать версии политики и сохранять записи о том, какая модель обслуживает каждый оцененный запрос. Предупреждение должно отличать успешный переход к обычному использованию предпочтительной модели, поскольку повторный переход на резервный вариант может указывать на проблему поставщика или исчерпание мощностей.
Последствия для реселлеров и операторов платформ
Псевдонимы полезны для платформ, публикующих каталог моделей, ориентированный на клиента. Реселлер может предоставить стабильное название продукта при замене устаревшей модели, корректировке набора поставщиков или внедрении резервного варианта. Это может сократить количество прерывающих миграцию каталогов и позволит оператору централизованно управлять доступностью.
Эта абстракция также порождает вопросы раскрытия информации и выставления счетов. Клиентам может потребоваться знать, всегда ли псевдоним сопоставляется с одной моделью, выбирает одну из нескольких моделей или меняет поведение с течением времени. Для AI API операций реселлера счета-фактуры и экспорт использования должны сделать результат маршрутизации достаточно ясным, чтобы согласовать расходы клиентов с расходами поставщика.
Операторы также должны решить, связаны ли бюджеты, ограничения скорости и политики доступа с псевдонимом, базовыми моделями или с тем и другим. Псевдоним, который может перенаправляться на модели с существенно разными ценами, не должен молча обходить предположения о расходах, установленные при настройке клиента.
Что осталось неясным
Журнал изменений Cloudflare определяет основное поведение, но не описывает критерии принятия решений, используемые интеллектуальной маршрутизацией в этом объявлении. Он также не обеспечивает измерения производительности при аварийном переключении и не объясняет, насколько быстро распространяются изменения псевдонимов.
Эти детали будут определять, насколько уверенно команды смогут использовать псевдонимы для чувствительных к задержке или жестко регулируемых рабочих нагрузок. На данный момент непосредственная выгода очевидна: приложения могут зависеть от стабильного имени модели, в то время как решения о маршрутизации передаются в шлюз. Соответствующее обязательство столь же ясно: отчетность, выставление счетов и аудит должны соответствовать модели, которая фактически выполнила запрос, а не только псевдониму, предоставленному приложением.