Microsoft актуализира нивото на AI Gateway на Azure API Management с набор от контроли, които имат по-малко значение за експериментирането на модела и повече за производствените операции: стабилни псевдоними на модела, достъп до Microsoft Entra, по-подробни роли на AI Gateway, политики с обхват на шлюза и отчитане на използването за поточно предавани OpenAI-съвместими отговори на Chat Completions.
Изданието от 24 септември не е стартиране на модел. Това е актуализация на контролната равнина за екипи, които вече имат множество приложения, доставчици, внедрявания или работни натоварвания на агенти, движещи се през шлюз. Това го прави важно за екипите на платформата, които се опитват да запазят достъпа до модела гъвкав, без да позволяват маршрутизирането, удостоверяването, политиката и отчитането на токени да бъдат разпръснати в кода на приложението.
Какво се промени в Azure AI Gateway
Основната промяна са псевдонимите на модела. Вместо да изисква приложение да извиква директно конкретен модел на бекенд каталог, Azure API Management AI Gateway вече може да изложи стабилно име на модел, обърнато към клиента. Целта на бекенда може да се промени, докато приложението продължава да извиква псевдонима.
Тази абстракция е полезна от гледна точка на обикновен софтуер, но е особено полезна за LLM операции. Имената на моделите, внедряванията, регионите и доставчиците могат да се променят по-бързо от циклите на издаване на корпоративни приложения. Псевдонимът дава на екипите на платформата начин да преместят трафика към по-ново внедряване, да стандартизират именуването между екипите или да скрият сложността на бекенда от клиентските приложения.
Актуализацията също така добавя поддръжка за токени за достъп на Microsoft Entra като опция за удостоверяване за клиенти на шлюз. API ключовете остават често срещани в интеграциите на AI, но дълготрайните ключове са трудни за управление в мащаб. Достъпът, базиран на Entra, дава на предприятията друг път: достъп, базиран на самоличност, който може да се впише по-добре в съществуващите политики за достъп, практики за условен достъп и управление на жизнения цикъл на служител или принципал на услугата.
Microsoft също разшири опциите за присвояване на роли. Ролите на AI Gateway вече могат да се присвояват през шлюз или да се ограничават по-тясно до псевдоним на модел или MCP сървър. Това има значение, защото AI шлюзовете все по-често разполагат с повече от един вид ресурси. Един екип може да се нуждае от права за управление на конкретен псевдоним за вътрешен асистент, докато друг екип управлява MCP сървър, който излага бизнес инструменти на агенти.
Защо улавянето на поточно използване има значение
Най-оперативно значимата промяна може да е по-малко видима за разработчиците, използващи API. Отговорите за поточно предаване на OpenAI-съвместими завършвания на чат вече включват обект за използване, дори когато клиентите не изискват stream_options.include_usage.
Това затваря често срещана пропуска в счетоводството. Поточното предаване е привлекателно за насочени към потребителя копилоти, асистенти за кодиране и интерфейси на агенти, защото намалява възприеманото забавяне. Но ако използването на токени не е надеждно уловено за всеки поточен отговор, таблата за управление на разходите, налагането на квоти, бюджетните броячи и анализите на използването могат да се отклонят от реалността.
Чрез принудително улавяне на поточно използване на слоя на шлюза, Azure API Management може да подобри телеметрията надолу по веригата, без да разчита на всеки екип на приложението да запомни правилната опция за заявка. За фирми, работещи със споделени AI платформи, това е разликата между консултантското отчитане на разходите и приложимото приписване на разходите.
Тук е и мястото, където актуализацията се свързва с по-широка Enterprise LLM API инфраструктура. Много организации са преминали етапа, когато един екип извиква един модел с един ключ. Сега те се нуждаят от централно маршрутизиране, възможност за проверка, контрол на правилата и сигнали за разходите, които оцеляват при смяна на модела и пренаписване на приложения.
Кой е засегнат
Директната аудитория е инженерство на платформа, облачна инфраструктура, сигурност и екипи за опит на разработчици, използващи Azure API Management като AI шлюз. Разработчиците на приложения може да изпитат промените най-вече като по-прости крайни точки и по-малко решения за обработка на идентификационни данни, но последиците от управлението стоят по-високо в стека.
За екипите по сигурността достъпът Entra намалява зависимостта от статични API ключове за достъп до шлюза. Това не елиминира необходимостта от ключово управление навсякъде, тъй като доставчиците нагоре по веригата, идентификационните данни за внедряване и достъпът от услуга към услуга все още може да изискват отделни контроли. Но дава на ориентираните към Microsoft предприятия позната равнина на идентичност за една важна част от пътя на трафика на AI.
За екипите на платформи псевдонимите на модела намаляват свързването между приложенията и внедряванията на задния модел. Това може да направи миграциите по-малко разрушителни. Може също така да направи моделите за връщане назад и управление на трафика по-чисти, тъй като псевдоним на шлюз може да се превърне в договор, докато внедряването на бекенда остава регулируемо.
За финансите, операциите и продуктовите лидери промяната на поточно използване трябва да направи разходите на AI по-лесни за приписване.Стрийминг работните натоварвания често са работните натоварвания, които бизнес потребителите действително виждат: помощни пилоти, асистенти по продажбите, кодови помощници и вътрешни агенти на знания. Ако тези натоварвания са недостатъчно или непоследователно отчетени, контролът на бюджета и анализът на възвръщаемостта на инвестициите стават по-слаби.
Практически последствия и отворени въпроси
Практическият краткосрочен ефект е, че екипите на базирана на Azure AI платформа могат да преместят повече управление в шлюза. Вместо да разпръскват имена на модели, проверки на политики и предположения за телеметрия в хранилища на приложения, те могат да концентрират повече от тази логика в управлявана контролна точка.
Политиките с обхват на шлюза са част от същия модел. Microsoft казва, че политиките могат да прилагат предпазни огради в съвместими модели, псевдоними и MCP сървъри. Това би трябвало да намали отклонението в правилата, когато се добавят нови модели или сървъри с инструменти. Освен това помага да се избегне познат режим на повреда: едно приложение получава актуализираното правило за безопасност, регистриране или маршрутизиране, докато друго запазва по-стара реализация, тъй като логиката е вградена локално.
Все още има въпроси, които купувачите и създателите да тестват в собствените си среди. Изданието описва новите възможности, но екипите все пак ще трябва да потвърдят как псевдонимите отговарят на техния процес на внедряване, как се държи наследяването на политики в сложни конфигурации на шлюза и как обектите за използване се вливат в техните съществуващи системи за телеметрия и таксуване. Предприятията също ще трябва да решат кои работни натоварвания трябва да използват незабавно достъп до Entra и кои интеграции все още изискват модели, базирани на API ключ.
По-широкият сигнал е ясен: AI шлюзовете се превръщат в инфраструктура за управление, а не само в прокси слоеве. Изборът на модел все още има значение, но по-трудният проблем на предприятието е контролирането на това кой може да използва кой модел или инструмент, съгласно коя политика, с каква разходна пътека. Актуализацията на Microsoft избутва Azure API Management още повече в тази роля.