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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{
  "model": "support-chat-default",
  "messages": [...],
  "metadata": {
    "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": "support-chat-default",
  "requested_gateway_tier": "interactive_fast",
  "selected_provider": "provider_a",
  "selected_provider_tier": "fast",
  "tier_outcome": "selected_as_requested",
  "downgrade_reason": null,
  "input_tokens": 1840,
  "output_tokens": 420,
  "latency_ms": 1420,
  "estimated_cost_usd": "0.0312",
  "settled_cost_usd": "0.0308"
}

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

{
  "requested_gateway_tier": "interactive_fast",
  "selected_provider_tier": "standard",
  "tier_outcome": "downgraded",
  "downgrade_reason": "tenant_premium_budget_exhausted"
}

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

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

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

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

• provider
• model_or_deployment
• regions
• 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:
    preferred:
      - provider: openai
        request_params:
          service_tier: fast
      - provider: anthropic
        request_params:
          service_tier: priority
    fallback:
      - gateway_tier: interactive_standard
        allowed_when: policy.allows_standard_downgrade

  background_discount:
    preferred:
      - provider: anthropic
        mode: batch
      - provider: gemini
        mode: batch
    fallback:
      - queue: delayed_retry
        allowed_when: true

  reserved_capacity:
    preferred:
      - provider: azure_openai
        deployment_class: provisioned
    fallback:
      - provider: azure_openai
        deployment_class: standard
        allowed_when: policy.allows_spillover

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{
  "tenant_id": "tenant_123",
  "allowed_gateway_tiers": [
    "interactive_standard",
    "background_discount"
  ],
  "premium_tier": {
    "enabled": false,
    "monthly_budget_usd": "0.00",
    "approval_required": true
  },
  "reserved_capacity": {
    "enabled": true,
    "deployment_pool": "support-prod-ptu",
    "allow_spillover_to_standard": true,
    "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:
  voice_control_loop:
    requested_tier: interactive_fast
    if_fast_unavailable: fail_fast
    error_code: tier_capacity_unavailable

  customer_support_reply:
    requested_tier: interactive_fast
    if_fast_unavailable: proceed_on_standard
    record_outcome: downgraded

  nightly_document_enrichment:
    requested_tier: background_discount
    if_batch_unavailable: queue
    max_queue_delay_hours: 24

  contracted_api_customer:
    requested_tier: reserved_capacity
    if_reserved_exhausted: spillover_to_standard
    require_spillover_budget: true

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

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

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

• Заявено ниво на шлюз.
• Избрано ниво на доставчик или клас на капацитет.
• Резултат от ниво: избрано, понижено, надстроено, на опашка, преливане, отхвърлено.
• Причина за резултата.
• Tenant, 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
• издръжлив модел на шлюз за асинхронни пакетни задания
• счетоводна книга за оферти, резервиране, уреждане и съгласуване