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

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

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

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

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

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

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

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

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

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

• API с възможност за разсъждение на OpenAI разкриват обект reasoning за поддържани модели, включително стойности на усилие като none, minimal, low, medium, high и xhigh. По-малкото усилие може да намали логическите токени и да подобри скоростта на реакция.
• Документацията на OpenAI посочва, че max_output_tokens може да ограничи общо генерираните токени, включително както логическите, така и крайните изходни токени.
• Антропичното разширено мислене може да бъде активирано със стойност 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": "няма",
      "max_reasoning_profile": "нисък",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "няма",
      "max_reasoning_profile": "нисък",
      "max_output_tokens": 300
    },
    "draft_customer_reply": {
      "default_reasoning_profile": "нисък",
      "max_reasoning_profile": "стандартен",
      "max_output_tokens": 1200
    },
    "code_review": {
      "default_reasoning_profile": "стандартен",
      "max_reasoning_profile": "дълбоко",
      "max_output_tokens": 4000
    },
    "преглед_за_сигурност": {
      "default_reasoning_profile": "дълбоко",
      "max_reasoning_profile": "capped-deep",
      "max_output_tokens": 6000
    },
    "агентски_план": {
      "default_reasoning_profile": "стандартен",
      "max_reasoning_profile": "дълбоко",
      "max_output_tokens": 5000
    }
  }
}

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

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

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

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

{
  "доставчици": {
    "доставчик_a": {
      "model_family_x": {
        "supports_reasoning": вярно,
        "control_type": "effort_enum",
        "allowed_values": ["няма", "минимален", "нисък", "среден", "висок", "xвисок"],
        "can_disable": вярно,
        "reports_reasoning_tokens": вярно
      }
    },
    "provider_b": {
      "model_family_y": {
        "supports_reasoning": вярно,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_disable": невярно,
        "reports_reasoning_tokens": вярно
      }
    },
    "provider_c": {
      "model_family_z": {
        "supports_reasoning": вярно,
        "control_type": "thinking_level",
        "allowed_values": ["минимална", "ниска", "средна", "висока"],
        "can_disable": невярно,
        "reports_reasoning_tokens": вярно
      }
    }
  }
}

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

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

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

Примерно картографиране

{
  "reasoning_profile_mappings": {
    "няма": {
      "effort_enum": "няма",
      "budget_tokens": 0,
      "thinking_level": "минимално"
    },
    "ниско": {
      "effort_enum": "нисък",
      "budget_tokens": 2048,
      "thinking_level": "ниско"
    },
    "стандартен": {
      "effort_enum": "среден",
      "budget_tokens": 8192,"ниво_на_мислене": "средно"
    },
    "дълбоко": {
      "effort_enum": "висок",
      "budget_tokens": 20000,
      "thinking_level": "високо"
    },
    "capped-deep": {
      "effort_enum": "висок",
      "budget_tokens": 12000,
      "thinking_level": "високо"
    }
  }
}

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

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

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

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

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

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

{
  "request_id": "req_123",
  "tenant_id": "tenant_42",
  "api_key_id": "ключ_abc",
  "работен процес": "преглед на_код",
  "requested_reasoning_profile": "дълбоко",
  "applied_reasoning_profile": "стандартен",
  "решение": "понижен",
  "decision_reason": "teant_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "доставчик_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "усилие": "средно"
  }
}

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

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

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

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

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

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

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

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

• 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 на доставчиците се развиват.

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

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

Измерете поне четири резултата:

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

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

Компромиси

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

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

Прогноза: Политиката за разсъждение ще стане Стандартен контрол на шлюза

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

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

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

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

Заключение

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

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

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

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