Reasoning-Effort Routing u AI API Gatewayu: Kontrolirajte Thinking Tokene, latenciju i troškove među pružateljima

Dubina rasuđivanja više nije opcija jednostavnog modela. Neki pružatelji izlažu razine napora u stilu enuma. Drugi izlažu simbolične proračune, dinamičko razmišljanje ili uzorne obitelji u kojima se razmišljanje ne može u potpunosti onemogućiti. Vidljivi odgovor može biti kratak dok skriveno razmišljanje troši naplative izlazne tokene. Ako svaki aplikacijski tim postavlja ove kontrole izravno, trošak, kašnjenje i kvalitetu postaje teško objasniti.

Praktični odgovor je premjestiti kontrolu razumnog napora na API pristupnik. Gateway bi trebao klasificirati radno opterećenje, preslikati ga na kontrolu obrazloženja specifičnog za pružatelja usluga, nametnuti proračune stanara, zabilježiti stvarnu upotrebu obrazloženja i učiniti odluke o vraćanju na stariju verziju vidljivima u analitici. ID modela, razina usluge, maksimalni rezultat i dubina obrazloženja trebaju biti zasebne dimenzije politike.

Problem čitatelja: Jednostavni zahtjevi plaćaju za duboko razmišljanje

Timovi koji usvajaju modele sposobne za zaključivanje obično počinju s razumnim ciljem: poboljšati kvalitetu teških zadataka. Problem se pojavljuje kasnije, kada se iste zadane vrijednosti ponovno koriste za izdvajanje, kratke sažetke, oblikovanje i klasifikaciju. Ti zahtjevi ne zahtijevaju skupo računanje testnog vremena, ali ga ipak mogu pokrenuti.

Ovo stvara tri operativna kvara:

• Neprozirnost troškova: korisnik vidi kratak odgovor, ali knjiga sadrži skrivene tokene obrazloženja ili specifične za pružatelja usluga ekvivalenti.
• Odstupanje latencije: tijek rada koji je izgledao interaktivno postaje spor jer se trud u razmišljanju povećao iza istog pseudonima modela.
• Fragmentacija pravila: svaki tim proizvoda uči različite parametre pružatelja usluga i primjenjuje različita ograničenja.

A politika rezoniranja na razini pristupnika rješava problem kontrole prije nego što postane problem naplate.

Činjenice: Kontrole rezoniranja davatelja nisu ekvivalentne

Sljedeće su činjenice o implementaciji, a ne preporuke.

• OpenAI API-ji s mogućnošću rezoniranja izlažu reasoning objekt za podržane modele, uključujući vrijednosti napora kao što su none, minimal, low, medium, high i xhigh. Manji napor može smanjiti tokene razmišljanja i poboljšati brzinu odgovora.
• OpenAI dokumentacija navodi da max_output_tokens može ograničiti ukupno generirane tokene, uključujući i tokene obrazloženja i konačne izlaze.
• Anthropic prošireno razmišljanje može se omogućiti s vrijednošću budget_tokens. Razmišljajući tokeni naplaćuju se kao izlazni tokeni i ubrajaju se u max_tokens zajedno s vidljivim tekstom odgovora.
• Anthropic dokumentacija također napominje da broj naplaćenih izlaznih tokena možda neće odgovarati broju vidljivih tokena odgovora, jer se interni misleći tokeni mogu naplatiti čak i kada nisu u potpunosti vidljivi.
• Gemini dokumentacija za razmišljanje navodi da cijena odgovora može uključivati oba izlaza tokeni i tokeni razmišljanja, s poljima upotrebe koja odvajaju tokene misli i tokene izlaza.
• Gemini Kontrole u stilu 2.5 uključuju thinkingBudget, s dinamičkim razmišljanjem na podržanim modelima i onemogućavanjem nultog proračuna na nekim obiteljima modela.Neki modeli ne mogu onemogućiti razmišljanje.
• Novije Gemini smjernice preporučuju thinking_level vrijednosti kao što su minimal, low, medium i high za Gemini 3.x modele u stilu umjesto sirovih numeričkih proračuna.

Osnovna implikacija arhitekture je jednostavna: nemojte izlagati kontrole rasuđivanja izvorne za pružatelja kao jedini ugovor. Nisu dovoljno stabilni, dovoljno prenosivi ili dovoljno usporedivi za upravljanje s više pružatelja usluga.

Preporuka: Stvorite profile za zaključivanje neutralne prema pružatelju usluga

Definirajte mali interni vokabular koji timovi proizvoda mogu razumjeti bez čitanja svake reference API pružatelja usluga. Za većinu gatewaya dovoljno je pet profila:

Profil je ugovor okrenut prema prijavi. Parametri davatelja usluga postaju detalji adaptera. Ovo održava kôd klijenta prenosivim i omogućuje vlasnicima platforme da ažuriraju mapiranja kako se API-ji pružatelja mijenjaju.

Mapiranje klasa radnog opterećenja prije mapiranja pružatelja

Razumovanje treba odabrati prema namjeri radnog opterećenja, a ne prema osobnim preferencijama ili popularnosti modela. Dodajte polje pristupnika kao što je workload_class, koje je dostavio klijent ili izvedeno iz odobrene konfiguracije rute.

Primjer pravila o radnom opterećenju

{
  "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
    }
  }
}

Ovo pravilo čini dvije korisne stvari. Prvo, sprječava jednostavne krajnje točke da naslijede skupe zadane postavke.Drugo, daje administratorima konkretnu površinu za pregled: kojim radnim tokovima je dopušteno zahtijevati duboko obrazloženje i pod kojim ograničenjima?

Izradite matricu kompatibilnosti

Prilagodnik pristupnika trebao bi održavati matricu za svakog pružatelja i obitelj modela. Minimalno pohranite podržava li model onemogućavanje rezoniranja, enum napor, numerički proračun, dinamičko razmišljanje, maksimalni podržani proračun i polja upotrebe za tokene rezoniranja.

Primjer oblika matrice

{
  "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
      }
    }
  }
}

Matrica kompatibilnosti nije dokumentacija samo za ljude. To bi trebala biti izvršna politika. Usmjerivač zahtjeva trebao bi ga koristiti prije slanja, a knjiga naplate bi ga trebao koristiti tijekom poravnanja.

Prevedi interne profile u parametre pružatelja

Mapiranje pružatelja treba biti eksplicitno i s verzijama. Nemojte se oslanjati na nejasnu frazu kao što je "upotrijebite pametnije razmišljanje". Gateway bi trebao točno znati koji je parametar davatelja usluga poslan.

Primjer mapiranja

{
  "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"
    }
  }
}

Ovi brojevi su primjeri, a ne univerzalne zadane vrijednosti. Pravi proračuni ovise o obitelji modela, cijeni, zahtjevima latencije i rezultatima procjene. Važan detalj implementacije je da pristupnik posjeduje mapiranje i bilježi riješeni parametar pružatelja za svaki zahtjev.

Neuspješno zatvoreno kada mapiranje nije sigurno

Nepodržane kontrole obrazloženja ne bi trebale tiho postati zadane postavke pružatelja. Zadane postavke mogu biti skupe i mogu se mijenjati tijekom vremena.

Koristite jedan od tri ishoda kada se traženi profil ne može sigurno mapirati:

• Dopusti: pružatelj/model podržava traženi profil, a pravila zakupca dopuštaju it.
• Snižavanje: traženi profil je iznad pravila, tako da gateway primjenjuje najviši odobreni profil i bilježi snižavanje.
• Odbaci: profil se ne može sigurno predstaviti, zakupac zahtijeva strogo ponašanje ili bi spuštanje na staru verziju prekršilo proizvod očekivanja.

Primjer zapisa odluke

{
  "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"
  }
}

Ovaj zapis odluke vrijedan je tijekom podrške, sporova oko naplate i ispitivanja kvalitete. Također sprječava nevidljive regresije kvalitete tijekom proračunskog pritiska.

Kontrole proračuna trebaju više od maksimalnih izlaznih tokena

Maksimalno ograničenje izlaznih tokena je neophodno, ali nije dovoljno. Za modele sposobne za rasuđivanje, model može potrošiti veliki dio ograničenog promišljanja i ostaviti premalo prostora za konačni odgovor. Korisnik zatim može platiti za neupotrebljiv skraćeni odgovor.

Koristite slojevita ograničenja:

• max_reasoning_profile po zakupcu, API ključu i tijeku rada.
• max_thinking_budget ili ekvivalentno po paru pružatelj/model.
• max_output_tokens za ukupno generirano tokena gdje pružatelj broji obrazloženje i vidljivi izlaz zajedno.
• daily_deep_reasoning_spend po korisniku zakupca ili preprodavača.
• deep_reasoning_requests_per_hour za krajnje točke velike količine.
• reasoning_token_ratio_threshold za upozorenja o anomalijama.

Provjera proračuna trebala bi se izvršiti prije otpreme. Korak poravnanja trebao bi zatim uskladiti stvarnu upotrebu nakon što stigne odgovor pružatelja. Ako pružatelj zasebno prijavljuje tokene razmišljanja, pohranite ih odvojeno.Ako izvješćuje samo o ukupnom broju izlaznih tokena, pohranite najbolja dostupna normalizirana polja i označite razinu pouzdanosti.

Polja knjige za korištenje rasuđivanja

Analitika mora pokazati razliku između vidljive duljine odgovora i plaćenog napora rasuđivanja. Korisni red glavne knjige trebao bi sadržavati:

• tenant_id, api_key_id, end_user_id i workflow.
• requested_model, served_model, pružatelj i alias modela.
• requested_reasoning_profile i applied_reasoning_profile.
• provider_reasoning_param, pohranjeno kao strukturirano JSON.
• input_tokens, visible_output_tokens, reasoning_tokens_or_equivalent, cached_tokens i total_billable_tokens.
• max_output_tokens i bilo koji proračun za razmišljanje specifičan za pružatelja usluga.
• latency_to_first_token_ms, total_latency_ms i završetak streama status.
• estimated_cost_before_dispatch, reserved_budget, settled_cost i reconciliation_status.
• policy_decision, kao što je dopušteno, smanjeno, odbijeno ili zamjensko.

Ne bilježi sirovi lanac misli prema zadanim postavkama. Za većinu poslova upravljanja i FinOps-a dovoljni su brojači i političke odluke. Pohranjivanje osjetljivog obrazloženog teksta može stvoriti probleme privatnosti, usklađenosti i zadržavanja koji se mogu izbjeći.

Tijek implementacije

Proizvodni pristupnik može implementirati usmjeravanje obrazloženja kao deterministički cjevovod zahtjeva.

1. Provjerite autentičnost zahtjeva. Razriješite stanara, API ključ, korisnik, tim i tijek rada.
2. Klasificirajte radno opterećenje. Koristite eksplicitno polje klijenta gdje je to moguće. Za poznate krajnje točke, vežite klasu radnog opterećenja pri konfiguraciji rute.
3. Pravilo učitavanja. Spojite globalna ograničenja, ograničenja zakupca, ključa i tijeka rada.
4. Odaberite kandidate za model. Koristite postojeći pseudonim modela ili pravilo odabira modela prije rješavanja razloga kontrole.
5. Razriješite profil obrazloženja. Počnite od traženog profila, zatim primijenite zadane i maksimalne vrijednosti tijeka rada.
6. Provjerite kompatibilnost. Potvrdite da par pružatelj/model sigurno podržava odabrani profil.
7. Procijenite cijenu i rezervirajte proračun. Uključi vjerojatnu upotrebu obrazloženja, ne samo vidljivi izlaz.
8. Odašiljanje s izvornim parametrima pružatelja. Pošalji enum napor, proračunske tokene, razinu razmišljanja ili bez kontrole razmišljanja prema adapteru.
9. Normaliziraj upotrebu na odgovor. Odvojeni unos, vidljiv izlaz, obrazloženje, predmemorija, alat i ukupni tokeni gdje je to moguće.
10. Podmirenje i upozorenje. Uskladite rezervirani i stvarni trošak, ažurirajte kvote i emitirajte signale anomalije.

Ovaj cjevovod održava kontrolu obrazloženja revizijskom.Također daje platformskim timovima jedinstveno mjesto za promjenu zadanih postavki kada se API-ji pružatelja razvijaju.

Procjena prije promjene zadanih postavki

Nemojte promicati napornije razmišljanje temeljeno samo na nekoliko impresivnih primjera. Pokrenite procjene prije promjene zadanih vrijednosti za klasu radnog opterećenja.

Izmjerite najmanje četiri ishoda:

• Kvaliteta zadatka: točnost, prihvaćanje recenzenta, valjanost sheme ili uspjeh poziva alata.
• Kašnjenje: vrijeme do prvog tokena i ukupno dovršenje vrijeme.
• Cijena: cijena po zahtjevu i cijena po prihvaćenom odgovoru.
• Načini neuspjeha: skraćivanje, odbijanje, neispravan izlaz, prekomjerni pozivi alata ili vremensko ograničenje.

Ključna metrika nije "tokeni po zahtjevu". Odgovor s nižim tokenom koji ne prođe provjeru valjanosti može biti skuplji nakon ponovnih pokušaja. Obrazloženiji odgovor može biti opravdan za sigurnosni pregled, ali rasipan za označavanje ulaznica. Procijenite prema tijeku rada.

Ustupci

Upravljanje obrazloženjem dodaje kontrolu, ali nije besplatno.

• Prenosivost u odnosu na značajke pružatelja usluga: interni profili održavaju aplikacijski kod prenosivim, ali napredni timovi mogu trebati odobreni otvor za izlaz za pojedine pružatelje usluga kontrole.
• Sigurnost proračuna nasuprot kvaliteti: stroga ograničenja štite stanare od nenamjernog trošenja, ali pretjerano stroga ograničenja mogu skratiti korisne odgovore nakon što su tokeni za rezoniranje već potrošeni.
• Dinamičko razmišljanje nasuprot predvidljivosti: dinamičke kontrole pružatelja mogu poboljšati praktičnost, ali oslabiti procjene troškova prije otpreme osim ako pristupnik ne bilježi stvarnu upotrebu i ne provodi ograničenja poravnanja.
• Dostupnost na nižu verziju nasuprot dosljednosti: obrazloženje snižavanja tijekom proračunskog pritiska čuva dostupnost, ali odgovor treba biti označen u telemetriji i uključen u procjenu kvalitete.
• Analitika nasuprot privatnost: metrika tokena rasuđivanja je korisna, ali sirovi tragovi rasuđivanja ne bi se trebali pohranjivati osim ako ne postoji namjerna, odobrena politika zadržavanja.

Predviđanje: Politika rasuđivanja postat će standardna kontrola pristupnika

Ovo je predviđanje, a ne provjerena činjenica: napor rasuđivanja postat će normalna kontrola proizvodnje uz model usmjeravanje, ograničenja stope, razine usluga i proračuni tokena. Kako pružatelji nastave izlagati različite kontrole razmišljanja, aplikacijski timovi imat će manje apetita za tvrdo kodiranje tih razlika u kod proizvoda.

Pristupnici koji razmišljanje tretiraju kao upravljanu dimenziju vremena izvođenja imat će jasniju naplatu stanara, čišću prenosivost i bolju kontrolu nad kašnjenjem.Pristupnici koji ga tretiraju kao slučajni parametar modela teško će objasniti zašto kratki odgovori ponekad koštaju više od dugih.

Kontrolni popis koji se može učiniti

• Definirajte interne profile: none, low, standard, deep i capped-deep.
• Dodijelite zadane i maksimalne profile svakom radnom opterećenju klasa.
• Izradite matricu kompatibilnosti pružatelja/modela za kontrole rasuđivanja.
• Prevedite profile u izvorne parametre pružatelja usluga u prilagodnom sloju.
• Neuspješno zatvoreno kada se traženi profil ne može mapirati na siguran način.
• Rezervirajte proračun prije slanja koristeći rasuđivanje procjene.
• Zabilježite zatraženi profil, primijenjeni profil, parametar pružatelja, korištenje obrazloženja, vidljivi izlaz, latenciju i cijenu.
• Dodajte upozorenja o anomalijama za visoke omjere tokena obrazloženja i duboko obrazloženje u jednostavnim tijekovima rada velikog volumena.
• Pokrenite procjene na razini tijeka rada prije promjene zadanih napor.
• Izbjegavajte zapisivanje neobrađenog obrazloženog teksta; umjesto toga pohranjujte brojeve i odluke o politici.

Zaključak

Modeli sposobni za rasuđivanje korisni su jer mogu potrošiti više računanja na teške probleme. Ta ista sposobnost postaje skupa kada se primjenjuje neselektivno. Gateway bi trebao odlučiti kada je dopušteno dublje razmišljanje, kako se preslikava na svakog davatelja usluga, koliko proračuna može potrošiti i kako se mjeri rezultat.

Trajni obrazac je odvojiti napor razmišljanja od ID-a modela. Usmjerite prema radnom opterećenju, ograničite prema politici zakupca, prilagodite po pružatelju i podmirite stvarnu upotrebu u glavnu knjigu. To pretvara razmišljanje iz skrivene varijable troška u eksplicitnu kontrolnu površinu za AI API kontrolu troškova.

Povezana literatura

• glavna knjiga naplate koja rezervira i podmiruje svaki poziv modela
• interni aliasi modela i mogućnosti ugovori
• račun tokena strujanja za konačnu upotrebu i djelomične odgovore