Разсъждение-Маршрутизиране на усилието в AI API Gateway: Контролирайте мислещите токени, латентността и разходите между доставчиците

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

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

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

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

Това създава три оперативни грешки:

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

A политиката за разсъждение на ниво шлюз решава проблема с контрола, преди той да се превърне в проблем с таксуването.

Факти: Контролите за обосновка на доставчика не са еквивалентни

Следното са факти за внедряване, а не препоръки.

• OpenAI API с възможност за разсъждение излагат reasoning обект за поддържани модели, включително стойности на усилията като none, minimal, low, medium, high и xhigh. По-малкото усилие може да намали логическите токени и да подобри скоростта на реакция.
• OpenAI документацията посочва, че max_output_tokens може да ограничи общо генерираните токени, включително както логическите, така и крайните изходни токени.
• Anthropic разширеното мислене може да бъде активирано със стойност budget_tokens. Мислещите токени се таксуват като изходни токени и се броят към max_tokens заедно с видимия текст на отговора.
• Anthropic документацията отбелязва също, че броят на таксуваните изходни токени може да не съвпада с броя на видимите токени за отговор, тъй като вътрешните мислещи токени могат да бъдат таксувани дори когато не са напълно видими.
• Gemini мислещата документация посочва, че ценообразуването на отговора може да включва и двата изхода токени и мислещи токени, с полета за използване, които разделят мисловните токени и изходните токени.
• Gemini Контролите в стил 2.5 включват thinkingBudget, с динамично мислене на поддържаните модели и деактивиране с нулев бюджет на някои семейства модели.Някои модели не могат да деактивират мисленето.
• По-новите Gemini указания препоръчват thinking_level стойности като minimal, low, medium и high за Gemini модели в стил 3.x вместо необработени числени бюджети.

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

Препоръка: Създайте профили за разсъждение, неутрални спрямо доставчика

Дефинирайте малък вътрешен речник, който продуктовите екипи могат да разберат, без да четат препратки към всеки API доставчик. За повечето шлюзове са достатъчни пет профила:

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

Картографиране на класовете на работното натоварване преди картографиране на доставчиците

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

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

{
  "workload_policies": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "none",
      "max_reasoning_profile": "low",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "none",
      "max_reasoning_profile": "low",
      "max_output_tokens": 300
    },
    "draft_customer_reply": {
      "default_reasoning_profile": "low",
      "max_reasoning_profile": "standard",
      "max_output_tokens": 1200
    },
    "code_review": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "deep",
      "max_output_tokens": 4000
    },
    "security_review": {
      "default_reasoning_profile": "deep",
      "max_reasoning_profile": "capped-deep",
      "max_output_tokens": 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "deep",
      "max_output_tokens": 5000
    }
  }
}

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

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

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

Примерна форма на матрица

{
  "providers": {
    "provider_a": {
      "model_family_x": {
        "supports_reasoning": true,
        "control_type": "effort_enum",
        "allowed_values": ["none", "minimal", "low", "medium", "high", "xhigh"],
        "can_disable": true,
        "reports_reasoning_tokens": true
      }
    },
    "provider_b": {
      "model_family_y": {
        "supports_reasoning": true,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_disable": false,
        "reports_reasoning_tokens": true
      }
    },
    "provider_c": {
      "model_family_z": {
        "supports_reasoning": true,
        "control_type": "thinking_level",
        "allowed_values": ["minimal", "low", "medium", "high"],
        "can_disable": false,
        "reports_reasoning_tokens": true
      }
    }
  }
}

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

Превод на вътрешни профили към параметри на доставчика

Съпоставянията на доставчика трябва да са изрични и с версии. Не разчитайте на неясна фраза като „използвайте по-умни разсъждения“. Шлюзът трябва да знае точно кой параметър на доставчика е изпратен.

Примерно съпоставяне

{
  "reasoning_profile_mappings": {
    "none": {
      "effort_enum": "none",
      "budget_tokens": 0,
      "thinking_level": "minimal"
    },
    "low": {
      "effort_enum": "low",
      "budget_tokens": 2048,
      "thinking_level": "low"
    },
    "standard": {
      "effort_enum": "medium",
      "budget_tokens": 8192,
      "thinking_level": "medium"
    },
    "deep": {
      "effort_enum": "high",
      "budget_tokens": 20000,
      "thinking_level": "high"
    },
    "capped-deep": {
      "effort_enum": "high",
      "budget_tokens": 12000,
      "thinking_level": "high"
    }
  }
}

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

Неуспешно затваряне, когато съпоставянето не е безопасно

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

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

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

Примерен запис на решение

{
  "request_id": "req_123",
  "tenant_id": "tenant_42",
  "api_key_id": "key_abc",
  "workflow": "code_review",
  "requested_reasoning_profile": "deep",
  "applied_reasoning_profile": "standard",
  "decision": "downgraded",
  "decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "provider_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "effort": "medium"
  }
}

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

Бюджетните контроли се нуждаят от повече от максималните изходни токени

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

Използвайте слоести тавани:

• max_reasoning_profile на клиент, API ключ и работен процес.
• max_thinking_budget или еквивалент на двойка доставчик/модел.
• max_output_tokens за общо генерирани токени, където доставчикът отчита мотивите и видимия изход заедно.
• daily_deep_reasoning_spend на клиент на наемател или дистрибутор.
• deep_reasoning_requests_per_hour за крайни точки с голям обем.
• reasoning_token_ratio_threshold за предупреждения за аномалии.

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

Полета в книгата за използване на разсъждения

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

• tenant_id, api_key_id, end_user_id и workflow.
• requested_model, served_model, доставчик и псевдоним на модела.
• requested_reasoning_profile и applied_reasoning_profile.
• provider_reasoning_param, съхранени като структурирани JSON.
• input_tokens, visible_output_tokens, reasoning_tokens_or_equivalent, cached_tokens и total_billable_tokens.
• max_output_tokens и всеки специфичен за доставчика бюджет за мислене.
• latency_to_first_token_ms, total_latency_ms и завършване на потока състояние.
• estimated_cost_before_dispatch, reserved_budget, settled_cost и reconciliation_status.
• policy_decision, като разрешено, понижено, отхвърлено или резервно.

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

Поток на внедряване

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

1. Удостоверете заявката. Разрешете клиент, API ключ, потребител, екип и работен процес.
2. Класифицирайте работното натоварване. Използвайте изрично поле за клиент, където е възможно. За известни крайни точки обвържете класа на работното натоварване при конфигурацията на маршрута.
3. Политика за зареждане. Обединяване на глобални, клиентски, ключови и ограничения на работния поток.
4. Избор на кандидати за модел. Използвайте съществуващия псевдоним на модела или политика за избор на модел, преди да разрешите мотивите контроли.
5. Разрешаване на профил на разсъждение. Започнете от заявения профил, след това приложете настройките по подразбиране и максимумите на работния процес.
6. Проверете съвместимостта. Потвърдете, че двойката доставчик/модел поддържа безопасно избрания профил.
7. Приблизителна цена и резерв бюджет. Включете вероятно използване на разсъждение, не само видим изход.
8. Изпращане с параметри на доставчика. Изпращане на enum усилие, бюджетни токени, ниво на мислене или без контрол на разсъждението според адаптера.
9. Нормализиране на използването при отговор. Отделно въвеждане, видимо изход, разсъждение, кеширане, инструмент и общи токени, където е възможно.
10. Уреждане и предупреждение. Съгласуване на резервирани и действителни разходи, актуализиране на квоти и излъчване на сигнали за аномалия.

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

Оценка преди промяна на настройките по подразбиране

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

Измерете най-малко четири резултата:

• Качество на задачата: точност, приемане от рецензент, валидност на схемата или успех на извикване на инструмент.
• Забавяне: време до първия токен и пълно завършване време.
• Цена: цена на заявка и цена на приет отговор.
• Режими на повреда: съкращаване, отказ, неправилно образуван изход, прекомерни извиквания на инструменти или изчакване.

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

Компромиси

Управлението с разсъждения добавя контрол, но не е безплатно.

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

Прогноза: Политиката за мотивиране ще стане стандартен контрол на шлюза

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

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

Приложим контролен списък

• Дефинирайте вътрешни профили: none, low, standard, deep и capped-deep.
• Присвоете профили по подразбиране и максимални профили за всяко работно натоварване клас.
• Изграждане на матрица за съвместимост на доставчик/модел за контроли на разсъжденията.
• Превеждане на профили в собствени параметри на доставчика в слоя на адаптера.
• Неуспешно закриване, когато заявен профил не може да бъде картографиран безопасно.
• Запазване на бюджет преди изпращане с помощта на разсъждение прогнози.
• Записване на заявен профил, приложен профил, параметър на доставчика, използване на аргументи, видим изход, латентност и цена.
• Добавяне на сигнали за аномалии за високи съотношения на логически токени и задълбочени аргументи в прости работни потоци с голям обем.
• Изпълнявайте оценки на ниво работен поток, преди да промените стандартното усилие.
• Избягвайте записването на суров мотивиращ текст по подразбиране; съхранява преброяване и решения за политики вместо това.

Заключение

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

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

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

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