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 tokenske proračune, dinamičko razmišljanje ili model 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 te kontrole izravno, trošak, kašnjenje i kvalitetu postaje teško objasniti.

Praktični odgovor je premjestiti kontrolu razumnog napora u 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 učinak i dubina razmišljanja 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. Za te zahtjeve nije potrebno skupo računanje testnog vremena, ali ga ipak mogu pokrenuti.

To stvara tri operativna kvara:

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

Politika obrazloženja na razini pristupnika rješava problem kontrole prije nego što postane problem naplate.

Činjenice: Kontrole obrazloženja pružatelja nisu ekvivalentne

Sljedeće su činjenice implementacije, a ne preporuke.

• API-ji s mogućnošću rasuđivanja OpenAI izlažu objekt reasoning 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 rasuđivanja i poboljšati brzinu odgovora.
• Dokumentacija OpenAI navodi da max_output_tokens može ograničiti ukupno generirane tokene, uključujući i tokene rasuđivanja i konačne izlazne tokene.
• Antropsko prošireno razmišljanje može se omogućiti s vrijednošću budget_tokens. Tokeni za razmišljanje naplaćuju se kao izlazni tokeni i ubrajaju se u max_tokens uz vidljivi tekst odgovora.
• Antropska dokumentacija također napominje da broj naplaćenih izlaznih tokena možda neće odgovarati broju tokena za vidljivi odgovor, jer se interni tokeni za razmišljanje mogu naplatiti čak i kada nisu u potpunosti vidljivi.
• Dokumentacija o razmišljanju Gemini navodi da cijena odgovora može uključivati i izlazne tokene i razmišljanje tokena, s poljima upotrebe koja odvajaju tokene misli i tokene izlaza.
• Kontrole u stilu Gemini 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.
• Nove smjernice za Gemini preporučuju vrijednosti thinking_level kao što su minimal, low, medium i high za modele u stilu Gemini 3.x umjesto sirovih numeričkih proračuna.

Implikacija temeljne arhitekture je jednostavna: nemojte izlagati izvorne kontrole obrazloženja davatelja kao jedini ugovor. Nisu dovoljno stabilni, dovoljno prenosivi ili dovoljno usporedivi za upravljanje s više pružatelja usluga.

Preporuka: Stvorite profile rezoniranja neutralne prema pružatelju usluga

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

Profil je ugovor okrenut prema aplikaciji. Parametri pružatelja 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 usluga

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

{
  "pravila_radnog opterećenja": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "ništa",
      "max_reasoning_profile": "nizak",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "ništa",
      "max_reasoning_profile": "nizak",
      "max_output_tokens": 300
    },
    "skica_odgovora_kupca": {
      "default_reasoning_profile": "nizak",
      "max_reasoning_profile": "standard",
      "max_output_tokens": 1200
    },
    "pregled_koda": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "duboko",
      "max_output_tokens": 4000
    },
    "sigurnosni_pregled": {
      "default_reasoning_profile": "duboko",
      "max_reasoning_profile": "capped-deep",
      "max_output_tokens": 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "duboko",
      "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. Najmanje 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

{
  "pružatelji": {
    "provider_a": {
      "model_family_x": {
        "supports_reasoning": točno,
        "control_type": "efort_enum",
        "allowed_values": ["none", "minimal", "low", "medium", "high", "xhigh"],
        "can_disable": točno,
        "reports_reasoning_tokens": točno
      }
    },
    "provider_b": {
      "model_family_y": {
        "supports_reasoning": točno,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_disable": netočno,
        "reports_reasoning_tokens": točno
      }
    },
    "provider_c": {
      "model_family_z": {
        "supports_reasoning": točno,
        "control_type": "razina_razmišljanja",
        "allowed_values": ["minimalna", "niska", "srednja", "visoka"],
        "can_disable": netočno,
        "reports_reasoning_tokens": točno
      }
    }
  }
}

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 verzirano. Nemojte se oslanjati na nejasnu frazu poput "upotrijebite pametnije razmišljanje". Gateway bi trebao točno znati koji je parametar pružatelja poslan.

Primjer mapiranja

{
  "reasoning_profile_mappings": {
    "ništa": {
      "effort_enum": "ništa",
      "budget_tokens": 0,
      "razina_razmišljanja": "minimalna"
    },
    "nisko": {
      "effort_enum": "nisko",
      "budget_tokens": 2048,
      "razina_razmišljanja": "niska"
    },
    "standard": {
      "efort_enum": "srednje",
      "budget_tokens": 8192,"razina_razmišljanja": "srednja"
    },
    "duboko": {
      "effort_enum": "visoko",
      "budget_tokens": 20000,
      "razina_razmišljanja": "visoka"
    },
    "capped-deep": {
      "effort_enum": "visoko",
      "budget_tokens": 12000,
      "razina_razmišljanja": "visoka"
    }
  }
}

Ovi brojevi samo 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 zatraženi profil ne može sigurno mapirati:

• Dopusti: pružatelj/model podržava zatraženi profil i pravila zakupca to dopuštaju.
• Smanji verziju: zatraženi profil je iznad pravila, tako da pristupnik primjenjuje najviši odobreni profil i bilježi prelazak na stariju verziju.
• Odbijanje: profil se ne može sigurno predstaviti, zakupac zahtijeva strogo ponašanje ili bi prelazak na stariju verziju prekršio očekivanja proizvoda.

Primjer zapisa odluke

{
  "request_id": "req_123",
  "stanar_id": "stanar_42",
  "api_key_id": "ključ_abc",
  "workflow": "code_review",
  "requested_reasoning_profile": "duboko",
  "applied_reasoning_profile": "standard",
  "odluka": "spušteno",
  "decision_reason": "stanar_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "pružatelj_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "napor": "srednji"
  }
}

Ova evidencija odluka je vrijedna 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

Ograničenje maksimalnog izlaznog tokena je neophodno, ali nije dovoljno. Za modele sposobne za rasuđivanje, model može potrošiti velik dio ograničenog promišljanja i ostaviti premalo prostora za konačni odgovor. Korisnik tada 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 ekvivalent po paru pružatelja/modela.
• max_output_tokens za ukupno generirane 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 anomaliju upozorenja.

Provjera proračuna trebala bi se dogoditi 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 ukupnim izlaznim tokenima, 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 uključivati:

• tenant_id, api_key_id, end_user_id i workflow.
• requested_model, served_model, provider i model alias.
• requested_reasoning_profile i applied_reasoning_profile.
• provider_reasoning_param, pohranjen kao strukturirani 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 status dovršetka streama.
• estimated_cost_before_dispatch, reserved_budget, settled_cost i reconciliation_status.
• policy_decision, kao što je dopušteno, smanjeno, odbijeno ili rezervno.

Nemojte se prijavljivati 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. Autentificirajte zahtjev. Razriješite zakupca, API ključ, korisnika, tim i tijek rada.
2. Klasificirajte radno opterećenje. Koristite eksplicitno klijentsko polje gdje je to moguće.Za poznate krajnje točke, povežite klasu radnog opterećenja pri konfiguraciji rute.
3. Pravila učitavanja. Spojite globalna ograničenja, ograničenja zakupca, ključa i tijeka rada.
4. Odaberite kandidate za modele. Koristite postojeći pseudonim modela ili pravila odabira modela prije rješavanja kontrola obrazloženja.
5. Razriješite profil obrazloženja. Počnite od traženog profila, zatim primijenite zadane postavke tijeka rada i maksimumi.
6. Provjerite kompatibilnost. Potvrdite da par pružatelj/model sigurno podržava odabrani profil.
7. Procijenite trošak i rezervirajte proračun. Uključite vjerojatnu upotrebu obrazloženja, ne samo vidljivi rezultat.
8. Odašiljanje s izvornim parametrima pružatelja. Pošaljite enum napor, proračunske tokene, razinu razmišljanja ili kontrolu bez razmišljanja prema adapter.
9. Normalizirajte upotrebu nakon odgovora. Odvojite ulaz, vidljivi izlaz, obrazloženje, predmemoriju, alat i ukupne tokene gdje je to moguće.
10. Podmirite i upozorite. Uskladite rezervirani i stvarni trošak, ažurirajte kvote i emitirajte signale anomalije.

Ovaj cjevovod održava kontrolu razmišljanja revizijskom. Također daje platformskim timovima jedinstveno mjesto za promjenu zadanih postavki kada se API-ji pružatelja razviju.

Procjena prije promjene zadanih postavki

Nemojte promicati veće napore na temelju rasuđivanja 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 vrijeme završetka.
• Cijena: cijena po zahtjevu i cijena po prihvaćenom odgovor.
• 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

Razumno upravljanje 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 kontrole specifične za pružatelja usluga.
• Proračunska sigurnost u odnosu na kvalitetu: teško ograničenja štite stanare od nenamjernog trošenja, ali pretjerano stroga ograničenja mogu skratiti korisne odgovore nakon što su tokeni za obrazloženje već potrošeni.
• Dinamičko razmišljanje nasuprot predvidljivosti: dinamičke kontrole pružatelja mogu poboljšati praktičnost, ali slabe 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 konzistentnost: smanjivanje obrazloženja tijekom proračunskog pritiska čuva dostupnost, ali odgovor bi trebao biti označen u telemetriji i uključen u procjenu kvalitete.
• Analitika nasuprot privatnosti: metrika tokena obrazloženja je korisna, ali sirovi tragovi obrazloženja ne bi se trebali pohranjivati osim ako ne postoji namjerna, odobrena politika zadržavanja.

Predviđanje: Politika obrazloženja postat će Kontrola standardnog pristupnika

Ovo je predviđanje, a ne provjerena činjenica: pokušaj razmišljanja postat će normalna kontrola proizvodnje uz usmjeravanje modela, ograničenja stope, razine usluge i proračune 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.

Gatewayi koji razmišljanje tretiraju kao upravljanu dimenziju vremena izvođenja imat će jasniju naplatu zakupaca, č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.

Primjenjivi kontrolni popis

• Definirajte interne profile: none, low, standard, deep i capped-deep.
• Dodijelite zadane i maksimalne profile svaku klasu radnog opterećenja.
• Izradite matricu kompatibilnosti pružatelja/modela za kontrole rasuđivanja.
• Prevedite profile u izvorne parametre pružatelja u sloju adaptera.
• Neuspješno zatvoreno kada se traženi profil ne može mapirati na siguran način.
• Rezervirajte proračun prije slanja korištenjem procjena svjesnih obrazloženja.
• Zabilježite traženi profil, primijenjeni profil, parametar pružatelja, obrazloženje upotreba, vidljivi izlaz, latencija i trošak.
• Dodajte upozorenja o anomalijama za visoke omjere tokena obrazloženja i duboko razmišljanje u jednostavnim radnim tokovima velikog volumena.
• Pokrenite procjene na razini tijeka rada prije promjene zadanog napora.
• Izbjegavajte bilježenje sirovog teksta obrazloženja prema zadanim postavkama; umjesto toga brojanje pohrane 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. Pristupnik bi trebao odlučiti kada je dopušteno dublje razmišljanje, kako se preslikava na svakog pružatelja, koliki proračun 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.

Povezano čitanje

• knjiga naplate koja rezervira i podmiruje svaki poziv modela
• interni aliasi modela i ugovori o mogućnostima
• račun tokena strujanja za konačna uporaba i djelomični odgovori