Цлоудфларе је објавио Ауто Роутер у јавној бета верзији за АИ Гатеваи, додајући аутоматски избор модела свом слоју мрежног пролаза уместо да сваку одлуку о рутирању препушта коду апликације. Нова функција процењује сваки захтев, процењује врсту задатка који се тражи и бира моделе који испуњавају услове користећи очекивани квалитет, цену токена, кашњење и сигнале доступности.

Издање је важно јер рутирање модела постаје кључни део АИ инфраструктуре предузећа. За тимове који користе неколико провајдера, тежак проблем више није само приступ моделима. Одлучује који модел треба да обради дати захтев, под којим ограничењима трошкова и кашњења, са довољно видљивости да се одлука касније објасни.

Цлоудфлареов одговор је да стави више те логике у АИ Гатеваи. Аутоматски рутер може прво да испроба изабрани модел и да се врати на други модел који испуњава услове ако добављач не може да испуни захтев. То гатеваи чини политиком и тачком извршења, а не само пролазним проксијем за API позиве.

Шта се променило

Пре овог издања, многи тимови су се бавили избором модела у коду апликације, оквирима оркестрације или прилагођеним услугама рутирања. Тај приступ може да функционише, али ствара поновљени инжењерски рад у производима и тимовима. Свака апликација мора да кодира правила о трошковима, преференције модела, резервно понашање и руковање специфично за провајдера.

Аутоматски рутер премешта део те одлуке у Цлоудфларе АИ Гатеваи. Цлоудфларе каже да рутер користи класификатор на ивици за процену типа и сложености задатка. Затим оцењује моделе који испуњавају услове на основу неколико практичних димензија: очекиваног квалитета одговора, цене токена, кашњења и да ли је модел доступан да испуни захтев.

Та комбинација је значајна. Једноставно правило рутирања као што је „прво користите најјефтинији модел“ може погоршати квалитет излаза на тежим задацима. Правило које увек шаље саобраћај ка граничном моделу може потрошити буџет на рутинске послове класификације, екстракције, преписивања или форматирања. Аутоматски рутер је дизајниран да захтева компромис по захтеву, док и даље ради у оквиру скупа модела који је тим дозволио.

Понашање резерви такође мења оперативну слику. Ако изабрани провајдер не може да испуни захтев, АИ Гатеваи може да покуша са другим моделом који испуњава услове. За производне системе, то може смањити утицај прекида рада добављача, ограничења брзине или пролазних кварова капацитета. То такође значи да тимови морају пажљиво да размисле о томе шта значи „испуњава услове“, јер се резервни модел може разликовати по понашању, цени, кашњењу, прозору контекста или безбедносном профилу.

Зашто је то важно за контролу трошкова

Потрошња ЛЛМ-а се све више обликује одлукама о усмеравању. Иста функција окренута кориснику може укључивати кратке упите, дугачке упите, кеширани контекст, позиве алата, генерисање кода и нискоризичне позадинске послове. Слање целог тог саобраћаја на један модел је једноставно, али ретко економично.

Аутоматски рутер одражава шири помак ка АИ API контроли трошкова на нивоу мрежног пролаза. Уместо да третирају избор модела као избор искључиво у власништву програмера, предузећа могу да почну да управљају њиме као заједничком платформом. То је посебно релевантно за организације са више тимова који граде АИ функције на истом налогу добављача.

Практични ефекат није загарантована уштеда у свакој примени. Цлоудфларе каже да Ауто Роутер може смањити потрошњу АИ уз одржавање перформанси, али стварни резултати ће зависити од мешавине радног оптерећења, који модели су дозвољени, прагова квалитета, брзих образаца и толеранције за промену провајдера. Компанија која се бави углавном тешким радним оптерећењем расуђивања може имати мање користи од компаније са великим обимом рутинског сумирања, издвајања, класификације и аутоматизације подршке.

И поред тога, правац је јасан.Оптимизација трошкова се све мање односи на ручно бирање једног модела и више на дефинисање ограничења: који су модели одобрени, када се могу користити јефтинији модели, када су потребни премијум модели и када је резервни модел прихватљив.

На кога то утиче

Програмери који праве апликације са више модела су најдиректнија публика. Аутоматски рутер може смањити количину кода за рутирање који треба да одржавају, посебно када се апликације већ налазе иза Цлоудфларе АИ Гатеваи-а. Уместо повезивања сваког задатка са фиксним моделом, тимови могу да дефинишу скуп модела који испуњава услове и да препусте мрежном пролазу да одлучује унутар тих граница.

Тимови за платформу и инфраструктуру су погођени јер мрежни пролаз постаје контролна раван АИ. Они ће морати да одлуче да ли су политике рутирања глобалне, специфичне за пројекат, специфичне за окружење или везане за ризик производа. Бот за корисничку подршку, интерни помоћник за кодирање и ток посла за усклађеност не би требало нужно да деле исто понашање аутоматског рутирања.

Тимови за финансије и операције такође имају удела. Ако аутоматско рутирање промени који модел обрађује захтев, атрибуција трошкова мора да остане јасна. Нижи комбиновани рачун за токене је користан само ако тимови и даље могу да разумеју који производи, клијенти, пројекти или API кључеви су генерисали потрошњу. Ту аналитика коришћења и означавање постају подједнако важни као и сама одлука о рутирању.

B2B LLM клијенти и корисници сличних платформи требало би да прочитају издање као део већег кретања на тржишту. Све се више очекује да обједињени приступ API укључује управљање, аналитику, контролу буџета и политику рутирања. Каталог модела је само један слој; оперативна правила око тог каталога постају диференцијатор.

Практичне последице

Прва последица је дизајн политике. Тимови који усвајају аутоматско рутирање треба да документују која радна оптерећења могу толерисати замену модела. Интерно сумирање може бити ниског ризика. Анализа уговора, регулисана комуникација са клијентима, промене кода или коришћење агентских алата могу захтевати строжа ограничења и експлицитни преглед.

Друго је тестирање. Аутоматско рутирање чини евалуацију важнијом, а не мање. Тимови би требало да упореде излазе у свим прихватљивим моделима које дозвољавају, посебно за рубне случајеве, дугачке упите, структурирани излаз, захтеве осетљиве на безбедност и терминологију специфичну за домен. Ако мрежни пролаз може да бира између модела, скуп за процену треба да покрије цео скуп рута, а не један подразумевани модел.

Трећи је видљивост. Програмерима су потребни дневники који показују који је модел изабран, да ли је дошло до резервног, какво је кашњење и коришћење токена и како су трошкови додељени. Без тог записа, аутоматско рутирање може постати тешко за отклањање грешака када корисник пријави промењено понашање или када финансијски тим пита зашто је рачун померен.

Четврто је дисциплина набавке. Аутоматски рутер може олакшати додавање нових провајдера или модела, али сваки додатак проширује површину политике. Предузећа треба да одлуче да ли је модел одобрен за експериментисање, интерна оптерећења, саобраћај купаца у производњи, осетљиве податке или регулисану употребу. Те категорије би требало да се одразе у конфигурацији мрежног пролаза, а не закопане у неформалним тимским конвенцијама.

Оно што остаје неизвесно

Највеће отворено питање је колико добро аутоматски рутер ради у стварним пословним оптерећењима предузећа. Цлоудфларе је описао дизајн и предвиђене уштеде, али резултати производње ће варирати. Рутеру који ради добро за општа упутства ће можда бити потребно пажљиво подешавање специјализованих кодних база, правног језика, медицинског садржаја, финансијске анализе или рада са специфичним знањем компаније.

Такође је нејасно како ће тимови уравнотежити аутоматску оптимизацију са предвидљивошћу. Нека предузећа могу поздравити промену модела због трошкова и отпорности. Други могу преферирати стабилно понашање модела из разлога ревизије, евалуације или корисничког искуства.Вероватни исход није једна универзална политика, већ вишеслојне контроле: строго рутирање за осетљиве токове посла, флексибилно рутирање за рутинске послове и одвојени експерименти за нове моделе кандидата.

Објављивање Цлоудфларе-а је и даље важно јер означава јасан правац производа. Вишемоделно рутирање више није само образац архитектуре апликације. Постаје функција гејтвеја којим се управља, а то ће повећати очекивања за сваку АИ платформу која тврди да помаже предузећима да контролишу трошкове, поузданост и управљање међу моделима.