Маршрутизиране на ниво услуга в AI API Gateway: Бързо, стандартно, осигурено и пакетно без доставчици на твърдо кодиране

Маршрутизирането на ниво услуга е нивото на правилата, което решава дали дадена AI заявка заслужава първокласен капацитет с ниска латентност, нормален капацитет при поискване, резервирана пропускателна способност или намалена асинхронна обработка. Без този слой екипите на приложенията обикновено кодират специфични за доставчика флагове, имена на внедряване и партидни крайни точки директно в кода на продукта. Това затруднява управлението на забавянето, разходите, квотите и таксуването на наемателя.

Шлюзът трябва да показва намерението за натоварване, а не механиката на доставчика. Продуктовият екип трябва да може да каже „това е интерактивен отговор за поддръжка“ или „това е работа за обогатяване през нощта“, докато шлюзът картографира това намерение към правилната опция за капацитет нагоре по веригата и записва какво всъщност се е случило.

Проблемът с четеца: класовете капацитет се превръщат в логика на приложението

Екипите, използващи повече от един доставчик на модел, често започват с просто маршрутизиране на модела: изпратете този идентификатор на модела на този доставчик. Маршрутизирането става по-трудно, когато доставчиците излагат различни класове на капацитет:

• Премиум обработка на заявки с ниска латентност за пътеки, обърнати към потребителя.
• Стандартен споделен капацитет за обикновен синхронен трафик.
• Специализиран или осигурен капацитет за предвидима производителност.
• Пакетни или асинхронни API за работни натоварвания, устойчиви на забавяне.
• Поведение на разпространение, когато резервираният капацитет е изчерпан.

Ако всяко приложение се справя с тези избори само, организацията губи контрол над четири неща: кой може да използва първокласен капацитет, колко струва, какво се случва, когато капацитетът е недостъпен и дали избраното ниво е подобрило продукта достатъчно, за да оправдае разходите.

Практическият модел е да се постави неутрален спрямо доставчика слой за качество на услугата в шлюза на AI API.

Факти, върху които да надграждате

Подробностите варират в зависимост от доставчика, но няколко видими факта подкрепят дизайн на ниво шлюз.

• Факт: Някои доставчици излагат ниво на услуга на заявка за първокласна обработка. OpenAI описва бързия режим като опция на заявка, използвайки параметъра service_tier и казва, че се таксува с премия спрямо стандартната обработка. OpenAI също така заявява, че приоритетната обработка е преименувана на бърз режим на 30 юли 2026 г., докато както service_tier=priority, така и service_tier=fast се приемат за API заявки.
• Факт: Премиум обработката на заявки може да не е отделна квотна вселена. OpenAI отбелязва, че ограниченията на скоростта на бързия режим се споделят с други нива на услуги и че бързото увеличаване на трафика може да задейства поведение на скоростта на нарастване, при което част от трафика може вместо това да бъде изпратен към стандартна обработка.
• Факт: Нивото на услугата може да бъде измерение за отчитане и таксуване. OpenAI казва, че клиентите на API могат да групират данните от таблото за използване по ниво на услугата и позиция. Антропни документи стандарт, приоритет и партида като стойности на ниво на услугата в отчитането на използването на API.
• Факт: Пакетните API могат значително да намалят разходите за асинхронна работа. Ценовата документация на Anthropic казва, че неговият Batch API поддържа асинхронна обработка на голям обем с 50% отстъпка за входни и изходни токени. Документацията на Gemini Batch API на Google описва големи асинхронни работни натоварвания на 50% от стандартната цена, с компромиси за изпълнение, като например до 24 часа за някои задачи с голям обем.
• Факт: Предоставената пропускателна способност е отделен модел на капацитет. Microsoft документира предоставената пропускателна способност на Azure OpenAI като специален капацитет, за разлика от стандартните внедрявания, при които капацитетът е споделен и пропускателната способност може да варира в зависимост от търсенето. Microsoft също документира разпространението от осигурени внедрявания към стандартни внедрявания в същия ресурс на Azure OpenAI.

Препоръката е да не отразявате всеки термин на доставчик в кода на приложението. Препоръката е тези механизми да се нормализират в бизнес-ориентирани нива на шлюз.

Дефинирайте неутрални по отношение на доставчика нива на шлюз

Започнете с именуване на нива за поведение при натоварване, а не за терминология на доставчика. Полезна първа таксономия е:

<таблица> Ниво на шлюза Типично натоварване Очакване за забавяне Поза на разходите Поведение по подразбиране при понижаване interactive_fast Гласови цикли, чат на живо, потребителски действия с висока стойност Най-ниска практическа латентност Премиум разрешен Продължете стандартно или се провалете бързо, в зависимост от работния процес interactive_standard Нормален чат, поддръжка за чертане, вътрешни копилоти Синхронен Цена по подразбиране Повторен опит, резервен вариант или връщане на контролирана грешка резервиран_капацитет Предвидим производствен трафик със стабилно използване Предвидима производителност Предплатен или ангажиран капацитет Разпространява се само когато правилата го позволяват background_discount Оценки, обогатяване, обобщаване, вграждания, отчети Асинхронно Предпочита се отстъпка Поставете на опашка, докато пътят на пакета е наличен emergent_fallback Отговор при инцидент или временна ескалация на клиента Зависи от правила Контролирано изключение Изтича автоматично след прозореца за одобрение

Този списък с нива е умишлено малък. Ако създадете двадесет нива, разработчиците ще заобиколят системата. Шлюзът все още може да съпостави едно неутрално ниво към няколко вътрешни механизма, специфични за доставчика.

Отделете заявеното ниво от избраното ниво

Повикващият трябва да изпрати заявено ниво, но шлюзът трябва да запише както заявеното ниво, така и действително избраното ниво. Те не винаги са еднакви.

Примерни метаданни на заявка:

<пре><код>{ "модел": "поддръжка-чат-по подразбиране", "съобщения": [...], "метаданни": { "workflow": "customer_support_reply", "tenant_id": "tenant_123", "requested_gateway_tier": "interactive_fast", "end_user_id": "u_789" } }

Примерен запис за изпращане:

<пре><код>{ "request_id": "req_abc", "tenant_id": "tenant_123", "api_key_id": "key_live_456", "workflow": "customer_support_reply", "model_alias": "поддръжка-чат-по подразбиране", "requested_gateway_tier": "interactive_fast", "selected_provider": "доставчик_a", "selected_provider_tier": "бърз", "tier_outcome": "избрано_като_заявено", "downgrade_reason": нула, "input_tokens": 1840, "изходни_токени": 420, "latency_ms": 1420, "estimated_cost_usd": "0,0312", "settled_cost_usd": "0,0308" }

Ако премиум заявка е изпратена до стандартна обработка поради ограничения на рампата или бюджетни правила на наемателя, това трябва да се вижда:

<пре><код>{ "requested_gateway_tier": "interactive_fast", "selected_provider_tier": "стандартен", "tier_outcome": "понижен", "downgrade_reason": "tenant_premium_budget_exhausted" }

Това разграничение предотвратява подвеждащи анализи. Ако таблата за управление показват само какво е поискал обаждащият се, финансите ще виждат първокласно намерение, но не и първокласно изпълнение. Ако таблата за управление показват само резултата нагоре по веригата, продуктовите екипи няма да знаят кога на техния чувствителен към забавяне работен процес е отказан премиум капацитет.

Изградете матрица на възможностите преди маршрутизиране

Рутер от ниво на обслужване се нуждае от матрица на възможностите. Матрицата трябва да отговори: за даден модел, регион, наемател и работен процес, какви механизми за капацитет са налични?

Минимум полета:

• доставчик
• model_or_deployment
• региони
• supports_sync
• supports_batch
• supports_premium_tier
• supports_provisioned_capacity
• supports_spillover
• provider_tier_values
• billing_line_items
• known_downgrade_behavior
• tenant_allowlist

Опростен пример:

gateway_tier_map:
  interactive_fast:
    предпочитан:
      - доставчик: openai
        параметри на заявка:
          service_tier: бързо
      - доставчик: anthropic
        параметри на заявка:
          service_tier: приоритет
    резервен:
      - gateway_tier: интерактивен_стандарт
        разрешено_когато: политика.позволява_стандартно_понижаване
  background_discount:
    предпочитан:
      - доставчик: anthropic
        режим: партида
      - доставчик: gemini
        режим: партида
    резервен:
      - опашка: delayed_retry
        разрешено_когато: вярно
  резервиран_капацитет:
    предпочитан:
      - доставчик: azure_openai
        deployment_class: осигурен
    резервен:
      - доставчик: azure_openai
        deployment_class: стандартен
        разрешено_кога: политика.позволява_преливане

Тази матрица трябва да бъде конфигурация, а не разпръснат код. Промените в наименованието на доставчика, регионалната наличност и таксуването ще се променят с времето. Актуализирането на правила за шлюз е по-безопасно от повторното разполагане на всяко приложение, което извиква API.

Класифицирайте работните натоварвания, преди да изберете капацитет

Най-трудната част не е картографирането на доставчика. Той решава кои заявки кое ниво заслужават.

Добри кандидати за interactive_fast

• Гласови асистенти, при които забавянето прекъсва разговора.
• Чат, насочен към клиента, относно пътища за преобразуване или задържане с висока стойност.
• Операции на човек в цикъла, при които агент активно чака.
• Производствени инциденти, при които забавянето пряко влияе върху смекчаването.

Добри кандидати за interactive_standard

• Вътрешни втори пилоти.
• Поддържайте чертане, където човек може да понесе нормално време за реакция.
• Характеристики на продукта, при които времето за реакция има значение, но не е критично.

Добри кандидати за background_discount

• Вечерно обобщение.
• Голямо обогатяване на документи.
• Офлайн оценки.
• Групово вграждане опреснява.
• Етикетиране на анализи и генериране на отчети.

Добри кандидати за reserved_capacity

• Постоянни производствени натоварвания с голям обем.
• Договорени клиентски натоварвания с предвидими ангажименти за пропускателна способност.
• Трафик, който не може да понася вариации на шумни съседи и има достатъчно използване, за да оправдае специален капацитет.

Просто правило на политиката е: не позволявайте на обаждащите се да избират първокласен капацитет само защото предпочитат скорост. Изисквайте деклариран работен процес, разрешение за наемател и бюджетен плик.

Налагане на разрешения за клиент и API-ключ

Всеки клиент и API ключ трябва да имат разрешен набор от нива. Новите ключове трябва да са стандартни и фонови нива, а не премиум нива.

Примерна политика за наематели:

<пре><код>{ "tenant_id": "tenant_123", "allowed_gateway_tiers": [ "интерактивен_стандарт", "background_discount" ], "премиум_ниво": { "активиран": невярно, "monthly_budget_usd": "0,00", "approval_required": вярно }, "запазен_капацитет": { "активирано": вярно, "deployment_pool": "support-prod-ptu", "allow_spillover_to_standard": вярно, "spillover_monthly_budget_usd": "500,00" } }

Примерно заместване на ниво ключ:

<пре><код>{ "api_key_id": "key_voice_prod", "allowed_gateway_tiers": ["interactive_fast"], "workflow_allowlist": ["voice_control_loop"], "premium_daily_budget_usd": "75,00", "max_premium_traffic_percent": 15 }

Политиката на ниво ключ предотвратява случайно разширяване. Разработчикът не може да вземе ключ, предназначен за гласов трафик, и да го използва за скрипт за групово обобщение, освен ако работният процес също не е разрешен.

Изрично проектиране на понижаване и преливане на поведение

Поведението при понижаване е продуктово решение, а не само инфраструктурно решение. Когато премиум или осигурен капацитет не е наличен, шлюзът трябва да избере един от четирите пътя:

• Продължете по стандарт: Полезно, когато наличността е по-важна от последователността на забавянето.
• Опашка: Полезно за фонови задания и групови натоварвания.
• Бърз отказ: Полезно, когато бавният отговор би бил по-лош от липсата на отговор, като тесни цикли в реално време.
• Помолете обаждащия се да опита отново: Полезно, когато клиентът може безопасно да опита отново с отстъпка и запазен ключ за идемпотентност.

Примерна политика:

downgrade_policy:
  цикъл_за_управление на глас:
    поискано_ниво: интерактивно_бързо
    if_fast_unavailable: fail_fast
    error_code: ниво_капацитет_недостъпен
  customer_support_reply:
    поискано_ниво: интерактивно_бързо
    if_fast_unavailable: продължете_по_стандарт
    record_outcome: понижен
  nightly_document_enrichment:
    requested_tier: background_discount
    if_batch_unavailable: опашка
    max_queue_delay_hours: 24
  contracted_api_customer:
    заявено_ниво: резервиран_капацитет
    if_reserved_exhausted: преливане_към_стандарт
    require_spillover_budget: true

Не скривайте преливане. Преливането може да подобри наличността, но променя разходите и интерпретацията на SLO. Фактурите и анализите трябва да показват заявката за резервиран капацитет, преходното събитие, действително използвания стандартен капацитет и причината.

Свържете маршрутизирането на ниво услуга с таксуването

Шлюзът не може да контролира премиум разходите, ако изборът на ниво не е част от счетоводната книга. Съхранявайте тези полета за всяка заявка или работа:

• Заявено ниво на шлюз.
• Избрано ниво на доставчик или клас на капацитет.
• Резултат от ниво: избрано, понижено, надстроено, на опашка, преливане, отхвърлено.
• Причина за резултата.
• Идентификатори на клиент, API ключ, потребител и работен поток.
• Псевдоним на модел и модел или внедряване нагоре по веригата.
• Приблизителна цена преди изпращане.
• Уредени разходи, след като използването на доставчика стане известно.
• Закъснение и брой повторни опити за синхронни заявки.
• Време за пакетно подаване, време за завършване и състояние на приемане на резултат за асинхронни задания.

С тези полета шлюзът може да отговори на въпросите, които финансите и инженерингът ще зададат:

• Кои наематели са използвали премиум капацитет тази седмица?
• Кои работни процеси са довели до най-големи разходи?
• Колко често премиум заявките се понижаваха до стандартни?
• interactive_fast подобри ли латентността на p95 достатъчно, за да оправдае премията?
• Колко спести фоновата пакетна обработка в сравнение със синхронната стандартна обработка?
• Колко стандартно преливане генерира осигуреният капацитет?

Важната препоръка: фактурирайте действително използваното ниво, като същевременно показвате заявеното ниво за оперативен контекст. В противен случай наемателите ще бъдат или изненадани от цената, или подведени относно качеството на услугата.

Добавете предпазни парапети, така че премията да не стане стандартна

След като екипите открият по-бързо ниво, те може да го използват прекомерно. Поставете ограничения в шлюза преди широко разпространение.

• Премиум бюджет на наемател: Твърди месечни и дневни тавани.
• Одобрение на работния процес: Премиум разрешен само за наименувани работни процеси.
• Ограничение на споделянето на трафик: Например не повече от 10% от синхронните заявки на наемателя могат да използват interactive_fast без одобрение.
• Сигнал от стандартно към премиум: Сигнал, когато работен процес, който обикновено използва стандарт, е надстроен.
• Предупреждение за премиум скорост на изгаряне: Предупреждение, когато прогнозираните разходи надхвърлят одобрения пакет.
• Автоматично изтичане: Временните аварийни замени трябва да изтекат без ръчно почистване.
• Проверки за допустимост на пакети: Блокирайте групови задания от синхронни премиум нива, когато отговарят на критериите за пакети.

Мантините трябва да могат да се обръщат. По време на инцидент може да се наложи оторизиран оператор да предостави временно отмяна на премията. Тази замяна трябва да има причина, одобряващ, бюджет, време на изтичане и одитен запис.

Последователност на внедряване

Безопасно внедряване не започва с включване на първокласно маршрутизиране навсякъде. Започнете с измерване.

1. Добавете класификация на ниво сянка

Класифицирайте всяка заявка в предложено ниво на шлюз, но все още не променяйте маршрутизирането. Запишете предложеното ниво до съществуващите метаданни за латентност, цена и работен процес. Това разкрива колко трафик ще се премести към премиум, пакетен или резервиран капацитет, ако правилата се прилагат.

2. Създайте матрицата на възможностите

Избройте механизми на доставчици, поддържани модели, региони, ограничения, полета за отчитане и известно поведение при понижаване. Отнасяйте се към неизвестното поведение на понижаване като риск, докато не бъдете тествани.

3. Налагане на разрешения на наемател в режим на сухо изпълнение

Регистрирайте дали всяка заявка ще бъде разрешена, понижена, на опашка или отхвърлена. Споделете резултатите със собствениците на продукта преди налагането.

4. Активирайте едно ниво за една кохорта

Изберете тесен работен процес, като път за отговор на поддръжка на живо или задача за обобщаване през нощта. Активирайте съответното ниво на шлюз за малка група наематели. Измерете латентността на p50, латентността на p95, разходите, процента на понижаване, процента на грешки и ориентираните към потребителите бизнес показатели, когато има такива.

5. Разгънете само когато данните го поддържат

Ако първокласното ниво подобрява забавянето, но не и резултатите от продуктите, оставете го ограничено. Ако пакетната обработка намалява разходите, без да вреди на поведението на продукта, разширете я. Ако осигуреният капацитет не се използва, прегледайте ангажимента или насочете към него по-предвидим трафик.

Компромиси, които трябва да бъдат изрични

• Премиум нивата с ниска латентност могат да подобрят отзивчивостта, но могат да споделят ограничения на скоростта или да задействат ограничения на нарастване. Те не са заместител на оформянето на лимит на скоростта.
• Осигуреният капацитет подобрява предсказуемостта, но може да губи пари, когато използването е слабо. Стандартният или партиден капацитет може да е по-добър за пиков или толерантен към латентност трафик.
• Пакетната обработка може да намали разходите за токени, но променя поведението на продукта, тъй като отговорите са асинхронни и може да пристигнат много по-късно.
• Неутралните за доставчика имена на нива опростяват кода на приложението, но шлюзът трябва да поддържа актуална матрица на възможностите, тъй като доставчиците използват различни имена, лимити, редове за таксуване и поведение при понижаване.
• Автоматичното понижаване подобрява наличността, но може да замъгли SLO и очакванията за таксуване, освен ако шлюзът не запише действително използваното ниво.
• Строгият контрол на наемателите предотвратява изненадващи разходи, но прекалено строгите правила могат да блокират спешните производствени работни процеси, освен ако няма контролиран път за отмяна.

Прогноза: Нивото на услугата ще се превърне в първокласно измерение за маршрутизиране

Прогноза: С развитието на приложните програмни интерфейси (API) на моделите нивото на услугата ще стане също толкова важно за AI маршрутизирането, колкото изборът на модел, регионът и контекстният прозорец. Екипите няма да питат само „кой модел трябва да отговори на това?“ Те ще попитат „кой модел, под кой клас капацитет, за кой бюджет на наемател, с коя политика за понижаване?“

Препоръка: Проектирайте регистъра на шлюза и модела на правила сега, така че да могат да се добавят нови класове капацитет на доставчика, без да се променя кодът на приложението. Дори ако започнете само със стандартни и пакетни, използвайте полета като requested_gateway_tier, selected_provider_tier и tier_outcome от самото начало.

Контролен списък за действие

• Дефинирайте не повече от пет неутрални по отношение на доставчика нива на шлюз.
• Изисквайте всеки API ключ да декларира кои нива и работни процеси може да използва.
• Изградете матрица на възможностите на доставчика за първокласно, стандартно, осигурено, партидно и преливащо поведение.
• Записване на заявено ниво, избрано ниво, резултат от понижаване или разпространение, закъснение, използване и уредени разходи.
• Нови ключове по подразбиране към стандартни или фонови нива.
• Добавете премиум бюджети, ограничения за дял на трафика и сигнали.
• Направете изрично поведението на понижаване за всеки работен процес.
• Започнете със скритите показатели преди налагането.
• Първо разгръщане на премиум или осигурен капацитет за малка кохорта.
• Разширете само когато забавянето, надеждността или бизнес показателите оправдават разходите.

Заключение

Маршрутизирането на ниво услуга принадлежи към шлюза на AI API, тъй като е решение за междусекторна политика. Това засяга забавянето, разходите, квотите, разрешенията на наемателите, фактурите и оперативните очаквания. Екипите за приложения не трябва да кодират специфични за доставчика имена на нива или класове за внедряване само за да изразят спешността на работното натоварване.

Практичният шлюз разкрива неутрални нива като interactive_fast, interactive_standard, reserved_capacity и background_discount. Той съпоставя тези нива към специфични за доставчика механизми, налага разрешения на наематели, записва действителния резултат и прави първокласния капацитет умишлено изключение, а не път по подразбиране.

Свързано четене

• оформяне на лимит на скоростта преди доставчик 429s
• траен модел на шлюз за асинхронни пакетни задания
• билингова книга за оферта, резервиране, уреждане и съгласуване