Reasoning-Effort Routing i en AI API Gateway: Kontroller tenketokens, latens og kostnader på tvers av leverandører
Resonneringskompetente modeller avslører ulike kontroller for tenkedybde, tokenbudsjetter, fakturering og latens. Behandle resonnementarbeid som en styrt kjøretidspolicy i gatewayen, ikke som en løs modellinnstilling i hver applikasjon.
Å resonnere dybde er ikke lenger et enkelt modellalternativ. Noen leverandører avslører innsatsnivåer i enum-stil. Andre avslører symbolske budsjetter, dynamisk tenkning eller modellfamilier der tenkning ikke kan deaktiveres fullstendig. Det synlige svaret kan være kort mens skjult resonnement bruker fakturerbare utdatatokens. Hvis hvert applikasjonsteam setter disse kontrollene direkte, blir kostnad, latens og kvalitet vanskelig å forklare.
Det praktiske svaret er å flytte resonnement-innsatskontroll inn i API-porten. Gatewayen bør klassifisere arbeidsbelastningen, kartlegge den til en leverandørspesifikk resonneringskontroll, håndheve leietakerbudsjetter, registrere faktisk resonnementbruk og gjøre nedgraderingsbeslutninger synlige i analyser. Modell-ID, tjenestenivå, maksimal utgang og resonneringsdybde bør være separate policydimensjoner.
Leserproblem: Enkle forespørsler betaler for dyp resonnement
Team som tar i bruk resonneringskompetente modeller starter vanligvis med et rimelig mål: forbedre kvaliteten på vanskelige oppgaver. Problemet dukker opp senere, når de samme standardinnstillingene gjenbrukes for utvinning, korte sammendrag, formatering og klassifisering. Disse forespørslene trenger ikke kostbare testtidsberegninger, men de kan fortsatt utløse den.
Dette skaper tre driftsfeil:
- Kostnadsopasitet: brukeren ser et kort svar, men hovedboken inneholder skjulte resonnementsymboler eller leverandørspesifikke ekvivalenter.
- Latensmodellen blir en langsom arbeidsflyt som ser ut som en langsom arbeidsflyt bak: alias.
- Politikfragmentering: hvert produktteam lærer forskjellige leverandørparametere og bruker forskjellige tak.
En resonneringspolicy på gateway-nivå løser kontrollproblemet før det blir et faktureringsproblem.
Fakta: Leverandørens begrunnelse Kontroller er ikke likeverdige, Følgende er ikke implementert
- OpenAI-resonnementkompatible APIer viser et
reasoning-objekt for støttede modeller, inkludert innsatsverdier somnone,minimal,low,medium,highog.xhigh Lavere innsats kan redusere resonnement-tokens og forbedre responshastigheten. - OpenAI-dokumentasjon sier at
max_output_tokenskan begrense det totale antallet genererte tokens, inkludert både resonnement- og endelige output-tokens. - Antropisk utvidet tenkning kan aktiveres med en
budget_tokens-verdi. Tenketokens faktureres som utdatatokens og teller motmax_tokensved siden av synlig svartekst. - Antropisk dokumentasjon bemerker også at antall fakturerte utdatatokener kanskje ikke stemmer overens med antallet synlige svartokener, fordi interne tenkningstokener kan faktureres selv når de ikke er fullt synlige.
- Tvilling-tenkningsdokumentasjon kan inkludere både dokumentasjons- og dokumentasjonsmåter. med bruksfelt som skiller tanke- og utdata-tokens.
- Gemini 2.5-kontroller inkluderer
thinkingBudget, med dynamisk tenkning på støttede modeller og nullbudsjett deaktivering på enkelte modellfamilier. Noen modeller kan ikke deaktivere tenkning. - Nyere Gemini-veiledning anbefaler
tenkenivå-verdier somminimal,lav,middelsoghøyfor modeller i Gemini 3.x-stil i stedet for ubehandlede numeriske budsjetter/kjernebudsjetter:
. eksponere leverandør-innfødte resonneringskontroller som den eneste kontrakten. De er ikke stabile nok, bærbare nok eller sammenlignbare nok for styring av flere leverandører.
Anbefaling: Opprett leverandørnøytrale resonnementprofiler
Definer et lite internt vokabular som produktteam kan forstå uten å lese hver leverandørs API-referanse.For de fleste gatewayer er fem profiler nok:
| Intern profil | Formål | Typisk bruk | Retningslinjer | ||
|---|---|---|---|---|---|
ingen | Støttet | Deaktivert | Deaktivert | Deaktivert | Deaktivert | Standard for enkle endepunkter med høyt volum |
lav | Lett resonnement for beskjeden tvetydighet | Korte støttesvar, enkle sammenligninger, omskrivingsoppgaver | bredt | ||
standard | Balansert resonnement for rutinemessig kunnskapsarbeid | Planlegging, kodegjennomgang, policyanalyse, lengre syntese | Standard for blandede arbeidsbelastninger | ||
dypcoded | Feiling, matematikk, sikkerhetsgjennomgang, agentplanlegging | Begrenset av leietaker, nøkkel, arbeidsflyt og budsjett | |||
capped-deep | Høy resonnement med et hardt tak | Premiumkostnadsoppgaver er uakseptable | > og analyse
Profilen er den søknadsrettede kontrakten. Leverandørparametere blir adapterdetaljer. Dette holder klientkoden portabel og lar plattformeiere oppdatere kartlegginger etter hvert som leverandørens API-er endres.
Kart arbeidsbelastningsklasser før kartleggingsleverandører
Resonneringsinnsats bør velges ut fra arbeidsbelastningsintensjon, ikke fra personlige preferanser eller modellpopularitet. Legg til et gateway-felt som workload_class, enten levert av klienten eller utledet fra en godkjent rutekonfigurasjon.
Eksempel på arbeidsbelastningspolicy
{
"workload_policies": {
"extract_invoice_fields": {
"default_reasoning_profile": "ingen",
"max_reasoning_profile": "lav",
"max_output_tokens": 800
},
"classify_support_ticket": {
"default_reasoning_profile": "ingen",
"max_reasoning_profile": "lav",
"max_output_tokens": 300
},
"draft_customer_reply": {
"default_reasoning_profile": "lav",
"max_reasoning_profile": "standard",
"max_output_tokens": 1200
},
"code_review": {
"default_reasoning_profile": "standard",
"max_reasoning_profile": "dyp",
"max_output_tokens": 4000
},
"security_review": {
"default_reasoning_profile": "dyp",
"max_reasoning_profile": "avkortet-dyp",
"max_output_tokens": 6000
},
"agent_plan": {
"default_reasoning_profile": "standard",
"max_reasoning_profile": "dyp",
"max_output_tokens": 5000
}
}
}
Denne policyen gjør to nyttige ting. For det første forhindrer det enkle endepunkter i å arve kostbare standardinnstillinger. For det andre gir det administratorer en konkret gjennomgangsoverflate: hvilke arbeidsflyter har lov til å be om dype resonnementer, og under hvilke tak?
Bygg en kompatibilitetsmatrise
Gatewayadapteren bør opprettholde en matrise for hver leverandør og modellfamilie. Lagre minimum om modellen støtter deaktivering av resonnement, enum-innsats, numerisk budsjett, dynamisk tenkning, maksimalt støttet budsjett og bruksfelt for resonnement-tokens.
Eksempel Matrix Shape
{
"leverandører": {
"provider_a": {
"model_family_x": {
"supports_reasoning": sant,
"control_type": "effort_enum",
"allowed_values": ["ingen", "minimal", "lav", "middels", "høy", "xhøy"],
"can_disable": sant,
"reports_reasoning_tokens": sant
}
},
"provider_b": {
"model_family_y": {
"supports_reasoning": sant,
"control_type": "budsjett_tokens",
"min_budsjett_tokens": 1024,
"max_budget_tokens": 32000,
"can_disable": usant,
"reports_reasoning_tokens": sant
}
},
"provider_c": {
"model_family_z": {
"supports_reasoning": sant,
"control_type": "tenkenivå",
"allowed_values": ["minimal", "lav", "middels", "høy"],
"can_disable": usant,
"reports_reasoning_tokens": sant
}
}
}
}
En kompatibilitetsmatrise er ikke dokumentasjon kun for mennesker. Det bør være kjørbar policy. Forespørselsruteren bør bruke den før utsendelse, og faktureringsreskontroen bør bruke den under oppgjør.
Oversett interne profiler til leverandørparametere
Tilleggstilordninger bør være eksplisitte og versjonerte. Ikke stol på en vag setning som «bruk smartere resonnement». Gatewayen skal vite nøyaktig hvilken leverandørparameter som ble sendt.
Eksempel på kartlegging
{
"reasoning_profile_mappings": {
"ingen": {
"effort_enum": "ingen",
"budsjett_tokens": 0,
"thinking_level": "minimal"
},
"lav": {
"effort_enum": "lav",
"budsjett_tokens": 2048,
"thinking_level": "lav"
},
"standard": {
"effort_enum": "medium",
"budsjett_tokens": 8192,"thinking_level": "middels"
},
"dyp": {
"effort_enum": "høy",
"budsjett_tokens": 20000,
"thinking_level": "høy"
},
"capped-deep": {
"effort_enum": "høy",
"budsjett_tokens": 12000,
"thinking_level": "høy"
}
}
}
Disse tallene er eksempler, ikke universelle standardverdier. De riktige budsjettene avhenger av modellfamilien, priser, latenskrav og evalueringsresultater. Den viktige implementeringsdetaljen er at gatewayen eier tilordningen og registrerer den løste leverandørparameteren for hver forespørsel.
Feil lukket når en tilordning er usikker
Resonneringskontroller som ikke støttes, bør ikke stille bli standardleverandører. Standardverdier kan være kostbare, og de kan endre seg over tid.
Bruk ett av tre utfall når en forespurt profil ikke kan kartlegges på en sikker måte:
- Tillat: leverandøren/modellen støtter den forespurte profilen og leietakerpolicyen tillater det.
- Nedgrader: bruker den forespurte profilen over og den godkjente profilen er over og bruker den høyeste profilen. nedgradere.
- Avvis: Profilen kan ikke representeres trygt, leietakeren krever streng oppførsel, eller nedgradering vil bryte med produktforventningene.
Eksempel på beslutningsoppføring
{
"request_id": "req_123",
"tenant_id": "tenant_42",
"api_key_id": "key_abc",
"workflow": "code_review",
"requested_reasoning_profile": "dyp",
"applied_reasoning_profile": "standard",
"decision": "nedgradert",
"decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
"served_provider": "provider_a",
"served_model": "model_family_x",
"provider_reasoning_param": {
"innsats": "middels"
}
}
Denne beslutningsposten er verdifull under støtte, faktureringstvister og kvalitetsundersøkelser. Det forhindrer også usynlige kvalitetsregresjoner under budsjettpress.
Budsjettkontroller trenger mer enn maksimale utdatatokener
En maksimal utgangstokengrense er nødvendig, men den er ikke tilstrekkelig. For modeller som kan resonnere kan modellen bruke en stor del av grenseresonnementet og gi for lite rom for det endelige svaret. Brukeren kan da betale for et ubrukelig avkortet svar.
Bruk lagdelte tak:
max_reasoning_profileper leietaker, API-nøkkel og arbeidsflyt.max_thinking_budgeteller tilsvarende per leverandør/modellpar.maks. teller resonnement og synlig utgang sammen.daily_deep_reasoning_spendper leietaker eller forhandlerkunde.deep_reasoning_requests_per_hourfor endepunkter med høyt volum.reasoning_tokenly_ratio_th varsler.
Budsjettsjekken bør skje før utsendelse. Oppgjørstrinnet bør deretter avstemme faktisk bruk etter at leverandørsvaret kommer. Hvis leverandøren rapporterer tenkesymboler separat, lagre dem separat. Hvis det bare rapporterer totale utdata-tokens, lagrer du de beste tilgjengelige normaliserte feltene og merker konfidensnivået.
Ledger-felt for resonnementbruk
Analytics må vise forskjellen mellom synlig svarlengde og betalt resonnementinnsats. En nyttig hovedbokrad bør inkludere:
tenant_id,api_key_id,end_user_idogworkflow.requested_model,served_model, provider og model alias.requested_reasoning_profileogapplied_reasoning_profile.provider_reasoning_param, lagret som strukturert JSON.input_tokens,visible_code_out,reasoning_tokens_or_equivalent,cached_tokensogtotal_billable_tokens.max_output_tokensog ethvert leverandørspesifikt tankebudsjett.latency_to_first_token_codems>,status., estimated_cost_before_dispatch,reserved_budget,settled_costogreconciliation_status.policy_decision, for eksempel tillatt, nedgradert, avvist, eller ikke logulra. tankekjede som standard. For de fleste styrings- og FinOps-arbeid er tellinger og politiske beslutninger nok. Lagring av sensitiv resonneringstekst kan skape problemer med personvern, samsvar og oppbevaring som kan unngås.Implementeringsflyt
En produksjonsgateway kan implementere ruting for resonnement-innsats som en deterministisk forespørselspipeline.
- Autentiser forespørselen. Løs leietaker, API-arbeidsflytnøkkel, bruker, team, gruppe, team, team og bruker. arbeidsmengde. Bruk et eksplisitt klientfelt der det er mulig.For kjente endepunkter, bind arbeidsbelastningsklasse ved rutekonfigurasjon.
- Innlastingspolicy. Slå sammen globale, leietaker, nøkkel- og arbeidsflytbegrensninger.
- Velg modellkandidater. Bruk det eksisterende modellaliaset eller modellvalgspolicyen før du løser resonneringskontroller.
- begynn med standard arbeidsprofilen.Begynn med arbeidsprofilen. og maksimumsverdier.
- Kontroller kompatibilitet. Bekreft at leverandør/modellparet støtter den valgte profilen på en sikker måte.
- Estimer kostnad og reservebudsjett. Inkluder sannsynlig resonnementbruk, ikke bare synlig utgang.
- Send ut med leverandør-innfødte parametere. Send enums-innsatsen i henhold til enum-innsatsen, kontrollnivået. adapter.
- Normaliser bruk ved respons. Separat inndata, synlig utdata, resonnement, bufret, verktøy og totalt antall tokens der det er mulig.
- Avgjøre og varsle. Avstemme reserverte og faktiske kostnader, oppdater kvoter og avgi uregelmessige signaler.
Denne revisjonen kan kontrolleres. Det gir også plattformteam et enkelt sted for å endre standardinnstillinger når leverandør-API-er utvikler seg.
Evaluering før endring av standarder
Ikke fremme høyere resonnementarbeid basert kun på noen få imponerende eksempler. Kjør evalueringer før du endrer standardverdier for en arbeidsbelastningsklasse.
Mål minst fire utfall:
- Oppgavekvalitet: nøyaktighet, godkjenning av anmelder, skjemavaliditet eller suksess for verktøyanrop.
- Latens: tid til første token og total forespørsel per forespørsel og total kostnad per forespørsel og total kostnad pr. akseptert svar.
- Feilmoduser: avkorting, avslag, feil utdata, overdreven verktøykall eller tidsavbrudd.
Nøkkelberegningen er ikke «tokens per forespørsel». Et svar med lavere token som mislykkes i valideringen kan bli dyrere etter gjenforsøk. Et mer fornuftig svar kan være berettiget for sikkerhetsgjennomgang, men sløsing for merking av billetter. Evaluer etter arbeidsflyt.
Avveininger
Begrunnelse for styring gir kontroll, men det er ikke gratis.
- Portabilitet versus leverandørfunksjoner: interne profiler holder applikasjonskoden bærbar, men avanserte team kan trenge en godkjent fluktluke for leverandørspesifikke kontroller. fra løpende forbruk, men altfor stramme tak kan avkorte nyttige svar etter at resonnement-tokens allerede er brukt.
- Dynamisk tenkning versus forutsigbarhet: dynamiske leverandørkontroller kan forbedre brukervennligheten, men de svekker kostnadsestimater før utsendelse med mindre gatewayen registrerer faktisk bruk og håndhever oppgjørsgrade> i forhold til oppgjør. konsistens: nedgradering av resonnement under budsjettpress bevarer tilgjengeligheten, men svaret bør merkes i telemetri og inkluderes i kvalitetsevaluering.
- Analytics versus personvern: resonnement-token-beregninger er nyttige, men rå resonnementspor bør ikke lagres med mindre det er en bevisst, godkjent Retention Policy:h>
- Retention for Retention/Retention. a Standard Gateway Control
Dette er en prediksjon, ikke et verifisert faktum: resonnementarbeid vil bli en normal produksjonskontroll sammen med modellruting, rategrenser, tjenestenivåer og tokenbudsjetter. Ettersom leverandører fortsetter å avsløre ulike tenkekontroller, vil applikasjonsteam ha mindre appetitt på å hardkode disse forskjellene i produktkode.
Gatewayer som behandler resonnement som en styrt kjøretidsdimensjon vil ha klarere leietakerfakturering, renere portabilitet og bedre kontroll over latens.Gatewayer som behandler det som en tilfeldig modellparameter, vil slite med å forklare hvorfor korte svar noen ganger koster mer enn lange.
Handlingsbar sjekkliste
- Definer interne profiler:
ingen,lav,standard,deepogdeepogmaximal-design-profiler. arbeidsbelastningsklasse.
- Definer interne profiler:
- Bygg en leverandør-/modellkompatibilitetsmatrise for resonneringskontroller.
- Oversett profiler til leverandørnative parametere i adapterlaget.
- Feil lukket når en forespurt profil ikke kan kartlegges på en sikker måte.
- Reserver budsjett før utsendelse ved hjelp av resonnement-bevisste estimater.
- Reserver profil, visible parameter, visible ventetid og kostnader.
- Legg til uregelmessige varsler for høye resonnement-token-forhold og dype resonnementer i enkle arbeidsflyter med høyt volum.
- Kjør evalueringer på arbeidsflytnivå før du endrer standardinnsats.
- Unngå å logge rå resonneringstekst som standard; lagre tellinger og politiske beslutninger i stedet.
Konklusjon
Modeller med resonnement er nyttige fordi de kan bruke mer data på vanskelige problemer. Den samme egenskapen blir dyr når den brukes tilfeldig. Porten bør bestemme når dypere resonnement er tillatt, hvordan den tilordnes hver leverandør, hvor mye budsjett den kan forbruke og hvordan resultatet måles.
Det varige mønsteret er å skille resonnementinnsats fra modell-ID. Rut etter arbeidsmengde, tak etter leietakerpolicy, tilpass per leverandør og avregner faktisk bruk i hovedboken. Det gjør resonnement fra en skjult kostnadsvariabel til en eksplisitt kontrolloverflate for AI API-kostnadskontroll.
Relatert lesing