Reasoning-Effort Routing v prehodu AI API: nadzirajte žetone za razmišljanje, zakasnitev in stroške med ponudniki

Globina sklepanja ni več enostavna možnost modela. Nekateri ponudniki razkrijejo ravni napora v slogu enum. Drugi izpostavljajo žetonske proračune, dinamično razmišljanje ali modelne družine, kjer razmišljanja ni mogoče popolnoma onemogočiti. Vidni odgovor je lahko kratek, medtem ko skrito razmišljanje porablja zaračunljive izhodne žetone. Če vsaka aplikacijska skupina nastavi te kontrole neposredno, postanejo stroški, zakasnitev in kakovost težko razložljivi.

Praktičen odgovor je premakniti nadzor razmišljanja in truda v prehod API. Prehod bi moral razvrstiti delovno obremenitev, jo preslikati v kontrolo sklepanja, specifičnega za ponudnika, uveljaviti proračune najemnikov, zabeležiti dejansko uporabo argumentov in narediti odločitve o nižji različici vidne v analitiki. ID modela, stopnja storitve, največji rezultat in globina sklepanja bi morali biti ločene dimenzije pravilnika.

Težava bralca: Enostavne zahteve plačujejo za globoko sklepanje

Ekipe, ki sprejmejo modele, zmožne sklepanja, običajno začnejo z razumnim ciljem: izboljšati kakovost težkih nalog. Težava se pojavi pozneje, ko se iste privzete vrednosti ponovno uporabijo za ekstrakcijo, kratke povzetke, oblikovanje in klasifikacijo. Te zahteve ne potrebujejo dragih izračunov v preskusnem času, vendar jih lahko še vedno sprožijo.

To povzroči tri napake pri delovanju:

• Nepreglednost stroškov: uporabnik vidi kratek odgovor, vendar knjiga vsebuje skrite žetone sklepanja ali ustreznike, specifične za ponudnika.
• Premik zakasnitve: potek dela, ki je bil videti interaktiven, postane počasen, ker je razmišljanje povečano za istim vzdevkom modela.
• Razdrobljenost pravilnika: vsaka skupina izdelkov se nauči različnih parametrov ponudnika in uporabi različne omejitve.

Politika sklepanja na ravni prehoda reši težavo nadzora, preden postane težava z zaračunavanjem.

Dejstva: Kontrole sklepanja ponudnika niso enakovredne

Sledi so dejstva o implementaciji, ne priporočila.

• API-ji, ki so zmožni sklepanja OpenAI, razkrivajo objekt reasoning za podprte modele, vključno z vrednostmi napora, kot so none, minimal, low, medium, high in xhigh. Manjši napor lahko zmanjša žetone razmišljanja in izboljša hitrost odziva.
• Dokumentacija OpenAI navaja, da lahko max_output_tokens omeji skupne ustvarjene žetone, vključno z žetoni sklepanja in končnimi izhodi.
• Antropično razširjeno razmišljanje je mogoče omogočiti z vrednostjo budget_tokens. Miselni žetoni se zaračunavajo kot izhodni žetoni in se štejejo k max_tokens poleg vidnega besedila odgovora.
• Anthropic dokumentacija tudi ugotavlja, da se število zaračunanih izhodnih žetonov morda ne ujema s številom vidnih žetonov odziva, ker se interni miselni žetoni lahko zaračunajo, tudi če niso v celoti vidni.
• Dokumentacija razmišljanja Gemini navaja, da lahko cena odgovora vključuje izhodne žetone in razmišljanje žetone, s polji uporabe, ki ločujejo miselne žetone in izhodne žetone.
• Kontrole v slogu Gemini 2.5 vključujejo thinkingBudget z dinamičnim razmišljanjem na podprtih modelih in onemogočanjem ničelnega proračuna na nekaterih družinah modelov. Nekateri modeli ne morejo onemogočiti razmišljanja.
• Novejša navodila za Gemini priporočajo vrednosti thinking_level, kot so minimalna, nizka, srednja in visoka za modele v slogu Gemini 3.x namesto neobdelanih numeričnih proračunov.

Posledica osnovne arhitekture je preprosta: ne izpostavljajte izvornih kontrol sklepanja ponudnika kot edine pogodbe. Niso dovolj stabilni, dovolj prenosljivi ali dovolj primerljivi za upravljanje več ponudnikov.

Priporočilo: ustvarite profile sklepanja, nevtralne do ponudnika

Določite majhen interni besednjak, ki ga lahko skupine izdelkov razumejo, ne da bi prebrale vsako referenco API-ja ponudnika.Za večino prehodov zadostuje pet profilov:

Profil je pogodba, usmerjena v aplikacijo. Parametri ponudnika postanejo podrobnosti adapterja. To ohranja kodo odjemalca prenosljivo in lastnikom platforme omogoča posodabljanje preslikav, ko se spreminjajo API-ji ponudnika.

Preslikajte razrede delovne obremenitve pred preslikavo ponudnikov

Razmišljanje je treba izbrati glede na namen delovne obremenitve, ne glede na osebne preference ali priljubljenost modela. Dodajte polje prehoda, kot je workload_class, ki ga zagotovi odjemalec ali izhaja iz odobrene konfiguracije poti.

Primer pravilnika o delovni obremenitvi

{
  "workload_policies": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "brez",
      "max_reasoning_profile": "nizek",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "brez",
      "max_reasoning_profile": "nizek",
      "max_output_tokens": 300
    },
    "osnutek_odgovora_stranke": {
      "default_reasoning_profile": "nizko",
      "max_reasoning_profile": "standard",
      "max_output_tokens": 1200
    },
    "code_review": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "globoko",
      "max_output_tokens": 4000
    },
    "varnostni_pregled": {
      "default_reasoning_profile": "globoko",
      "max_reasoning_profile": "capped-deep",
      "max_output_tokens": 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "globoko",
      "max_output_tokens": 5000
    }
  }
}

Ta pravilnik ima dve uporabni stvari. Prvič, preprečuje, da bi preproste končne točke podedovale drage privzete vrednosti. Drugič, daje skrbnikom konkretno površino za pregled: kateri delovni tokovi smejo zahtevati poglobljeno razmišljanje in pod kakšnimi omejitvami?

Izdelajte matriko združljivosti

Vmesnik prehoda mora vzdrževati matriko za vsakega ponudnika in družino modelov. Shranite vsaj to, ali model podpira onemogočanje sklepanja, napor enum, numerični proračun, dinamično razmišljanje, največji podprti proračun in polja uporabe za žetone sklepanja.

Primer oblike matrike

{
  "ponudniki": {
    "ponudnik_a": {
      "model_family_x": {
        "supports_reasoning": drži,
        "control_type": "effort_enum",
        "allowed_values": ["brez", "minimalno", "nizko", "srednje", "visoko", "xvisoko"],
        "can_disable": res,
        "reports_reasoning_tokens": res
      }
    },
    "ponudnik_b": {
      "model_family_y": {
        "supports_reasoning": drži,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_onemogoči": napačno,
        "reports_reasoning_tokens": res
      }
    },
    "ponudnik_c": {
      "model_family_z": {
        "supports_reasoning": drži,
        "control_type": "raven_razmišljanja",
        "allowed_values": ["minimalna", "nizka", "srednja", "visoka"],
        "can_onemogoči": napačno,
        "reports_reasoning_tokens": res
      }
    }
  }
}

Matrika združljivosti ni dokumentacija samo za ljudi. Moral bi biti izvršljiv pravilnik. Usmerjevalnik zahtev naj bi ga uporabil pred pošiljanjem, knjiga obračunavanja pa med poravnavo.

Prevedi notranje profile v parametre ponudnika

Preslikave ponudnika morajo biti eksplicitne in imeti različice. Ne zanašajte se na nejasne fraze, kot je »uporabite pametnejše sklepanje«. Prehod bi moral natančno vedeti, kateri parameter ponudnika je bil poslan.

Primer preslikave

{
  "reasoning_profile_mappings": {
    "brez": {
      "effort_enum": "brez",
      "budget_tokens": 0,
      "raven_razmišljanja": "minimalna"
    },
    "nizko": {
      "effort_enum": "nizko",
      "budget_tokens": 2048,
      "raven_razmišljanja": "nizka"
    },
    "standard": {
      "effort_enum": "srednje",
      "budget_tokens": 8192,"raven_razmišljanja": "srednja"
    },
    "globoko": {
      "effort_enum": "visoko",
      "budget_tokens": 20000,
      "raven_razmišljanja": "visoka"
    },
    "capped-deep": {
      "effort_enum": "visoko",
      "budget_tokens": 12000,
      "raven_razmišljanja": "visoka"
    }
  }
}

Te številke so primeri in ne splošne privzete vrednosti. Pravi proračuni so odvisni od družine modelov, cen, zahtev glede zakasnitve in rezultatov ocenjevanja. Pomembna podrobnost implementacije je, da je prehod lastnik preslikave in beleži parameter razrešenega ponudnika za vsako zahtevo.

Neuspešno zaprtje, ko preslikava ni varna

Nepodprti kontrolniki sklepanja ne bi smeli tiho postati ponudnikovi privzeti. Privzete nastavitve so lahko drage in se lahko sčasoma spremenijo.

Uporabite enega od treh rezultatov, ko zahtevanega profila ni mogoče varno preslikati:

• Dovoli: ponudnik/model podpira zahtevani profil in pravilnik najemnika to dovoljuje.
• Znižaj: zahtevani profil je nad pravilnikom, zato prehod uporabi najvišji odobreni profil in zabeleži znižanje.
• Zavrni: profila ni mogoče varno predstaviti, najemnik zahteva strogo vedenje ali pa bi znižanje kršilo pričakovanja izdelka.

Primer zapisa odločitve

{
  "request_id": "req_123",
  "tenant_id": "najemnik_42",
  "api_key_id": "ključ_abc",
  "workflow": "code_review",
  "requested_reasoning_profile": "globoko",
  "applied_reasoning_profile": "standard",
  "odločitev": "znižano",
  "decision_reason": "najemnik_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "ponudnik_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "napor": "srednje"
  }
}

Ta zapis odločitev je dragocen med podporo, spori glede zaračunavanja in preiskavami kakovosti. Preprečuje tudi nevidne regresije kakovosti med proračunskim pritiskom.

Kontrole proračuna potrebujejo več kot največjo količino izhodnih žetonov

Potrebna je največja omejitev izhodnih žetonov, vendar ne zadostuje. Pri modelih, ki so zmožni sklepanja, lahko model porabi velik delež mejnega sklepanja in pusti premalo prostora za končni odgovor. Uporabnik lahko nato plača za neuporaben okrnjen odgovor.

Uporabite večplastne zgornje meje:

• max_reasoning_profile na najemnika, ključ API in potek dela.
• max_thinking_budget ali enakovredno na par ponudnik/model.
• max_output_tokens za skupno ustvarjeno žetone, pri katerih ponudnik šteje razlogovanje in vidne rezultate skupaj.
• daily_deep_reasoning_spend na stranko najemnika ali preprodajalca.
• deep_reasoning_requests_per_hour za končne točke velike količine.
• reasoning_token_ratio_threshold za anomalijo opozorila.

Preverjanje proračuna se mora izvesti pred odpremo. Korak poravnave bi moral nato uskladiti dejansko uporabo, potem ko prispe odgovor ponudnika. Če ponudnik ločeno poroča o mislečih žetonih, jih shranite ločeno. Če poroča samo o skupnih izhodnih žetonih, shrani najboljša razpoložljiva normalizirana polja in označi raven zaupanja.

Polja glavne knjige za uporabo sklepanja

Analitika mora pokazati razliko med vidno dolžino odgovora in plačanim trudom sklepanja. Uporabna vrstica glavne knjige mora vsebovati:

• tenant_id, api_key_id, end_user_id in workflow.
• requested_model, served_model, ponudnik in model vzdevek.
• requested_reasoning_profile in applied_reasoning_profile.
• provider_reasoning_param, shranjen kot strukturiran JSON.
• input_tokens, visible_output_tokens, reasoning_tokens_or_equivalent, cached_tokens in total_billable_tokens.
• max_output_tokens in kateri koli proračun za razmišljanje, specifičen za ponudnika.
• latency_to_first_token_ms, total_latency_ms in stanje dokončanja toka.
• estimated_cost_before_dispatch, reserved_budget, settled_cost in reconciliation_status.
• policy_decision, kot je dovoljeno, znižano, zavrnjeno ali nadomestno.

Ne prijavljajte se privzeto neobdelana veriga misli. Za večino upravljanja in dela FinOps zadostujejo štetja in politične odločitve. Shranjevanje občutljivega obrazložitvenega besedila lahko povzroči težave z zasebnostjo, skladnostjo in hrambo, ki se jim je mogoče izogniti.

Potek implementacije

Proizvodni prehod lahko implementira usmerjanje razumnega truda kot deterministični cevovod zahtev.

1. Preverite pristnost zahteve. Razrešite najemnika, ključ API-ja, uporabnika, ekipo in potek dela.
2. Razvrstite delovna obremenitev. Kjer je mogoče, uporabite eksplicitno polje odjemalca.Za znane končne točke povežite razred delovne obremenitve pri konfiguraciji poti.
3. Pravilnik nalaganja. Združite globalne omejitve, najemnike, ključe in potek dela.
4. Izberite kandidate za modele. Uporabite vzdevek obstoječega modela ali pravilnik o izbiri modela, preden razrešite kontrolnike sklepanja.
5. Razrešite profil sklepanja. Začnite z zahtevanim profilom, nato uporabite privzete nastavitve poteka dela in največje vrednosti.
6. Preverite združljivost. Potrdite, da par ponudnik/model varno podpira izbrani profil.
7. Ocenite stroške in rezervirajte proračun. Vključite verjetno uporabo sklepanja, ne samo vidnega rezultata.
8. Pošiljanje s parametri, ki izvirajo iz ponudnika. Pošljite enum napor, proračunske žetone, raven razmišljanja ali brez nadzora sklepanja glede na adapter.
9. Normalizirajte uporabo ob odzivu. Ločite vhod, vidni izhod, sklepanje, predpomnjeno shranjevanje, orodje in skupne žetone, kjer je to mogoče.
10. Poravnajte in opozorite. Uskladite rezervirane in dejanske stroške, posodobite kvote in oddajajte signale nepravilnosti.

Ta cevovod ohranja revizijski nadzor sklepanja. Prav tako daje ekipam platforme enotno mesto za spreminjanje privzetih nastavitev, ko se API-ji ponudnika razvijajo.

Ocena pred spreminjanjem privzetih nastavitev

Ne spodbujajte večjega razmišljanja, ki temelji samo na nekaj impresivnih primerih. Izvedite ocene, preden spremenite privzete vrednosti za razred delovne obremenitve.

Izmerite vsaj štiri rezultate:

• Kakovost naloge: natančnost, sprejem pregledovalca, veljavnost sheme ali uspeh klica orodja.
• Zakasnitev: čas do prvega žetona in skupni čas dokončanja.
• Cena: cena na zahtevo in cena na sprejeto odgovor.
• Načini napake: obrezovanje, zavrnitev, napačno oblikovan izhod, čezmerni klici orodja ali časovna omejitev.

Ključna metrika ni »žetoni na zahtevo«. Odgovor z nižjim žetonom, ki ne uspe preveriti veljavnosti, je lahko po ponovnih poskusih dražji. Bolj utemeljen odgovor je lahko upravičen za varnostni pregled, vendar potraten za označevanje vstopnic. Ocenite glede na potek dela.

Kompromisi

Razmišljanje o upravljanju dodaja nadzor, vendar ni brezplačno.

• Prenosljivost v primerjavi s funkcijami ponudnika: interni profili ohranjajo kodo aplikacije prenosljivo, vendar napredne ekipe morda potrebujejo odobreno zasilno loputo za kontrole, specifične za ponudnika.
• Proračunska gotovost v primerjavi s kakovostjo: težko omejitve ščitijo najemnike pred nenadnimi izdatki, vendar prestroge omejitve lahko skrajšajo uporabne odgovore, potem ko so žetoni sklepanja že porabljeni.
• Dinamično razmišljanje v primerjavi s predvidljivostjo: dinamične kontrole ponudnika lahko izboljšajo udobje, vendar oslabijo ocene stroškov pred odpremo, razen če prehod beleži dejansko uporabo in uveljavlja omejitve poravnave.
• Razpoložljivost znižanja v primerjavi z doslednost: znižanje sklepanja med proračunskim pritiskom ohranja razpoložljivost, vendar mora biti odziv označen v telemetriji in vključen v vrednotenje kakovosti.
• Analitika v primerjavi z zasebnostjo: meritve žetona sklepanja so uporabne, vendar sledi neobdelanega sklepanja ne bi smeli shranjevati, razen če obstaja namerna, odobrena politika hrambe.

Napoved: Politika sklepanja bo postala Nadzor standardnega prehoda

To je napoved, ne preverjeno dejstvo: prizadevanje za sklepanje bo postalo običajni nadzor proizvodnje poleg usmerjanja modela, omejitev stopnje, ravni storitev in proračunov žetonov. Ker ponudniki še naprej izpostavljajo različne kontrole razmišljanja, bodo imele aplikacijske ekipe manj apetita za trdo kodiranje teh razlik v kodo izdelka.

Prehodi, ki razmišljanje obravnavajo kot regulirano dimenzijo časa izvajanja, bodo imeli jasnejše zaračunavanje najemnikom, čistejšo prenosljivost in boljši nadzor nad zakasnitvijo.Prehodi, ki ga obravnavajo kot naključni parameter modela, bodo težko razložili, zakaj kratki odgovori včasih stanejo več kot dolgi.

Uporabni kontrolni seznam

• Definirajte notranje profile: none, low, standard, deep in capped-deep.
• Dodelite privzete in največje profile vsak razred delovne obremenitve.
• Izdelajte matriko združljivosti ponudnika/modela za sklepanje kontrol.
• Prevedite profile v izvorne parametre ponudnika v adapterski plasti.
• Napaka zaprta, ko zahtevanega profila ni mogoče varno preslikati.
• Rezervirajte proračun pred odpošiljanjem z ocenami, ki upoštevajo razloge.
• Zabeležite zahtevani profil, uporabljeni profil, parameter ponudnika, sklepanje uporaba, vidni izhod, zakasnitev in stroški.
• Dodajte opozorila o anomalijah za visoka razmerja žetonov sklepanja in globoko sklepanje v enostavnih delovnih tokovih velikega obsega.
• Zaženite ocene na ravni delovnega toka, preden spremenite privzeto prizadevanje.
• Izogibajte se privzetemu beleženju surovega obrazložitvenega besedila; štetja shramb in odločitve o politiki namesto tega.

Zaključek

Modeli, zmožni sklepanja, so uporabni, ker lahko porabijo več računalništva za težke težave. Ta ista zmogljivost postane draga, če se uporablja brez razlikovanja. Prehod se mora odločiti, kdaj je dovoljeno globlje sklepanje, kako se preslika na posameznega ponudnika, koliko proračuna lahko porabi in kako se meri rezultat.

Trajni vzorec je ločiti trud sklepanja od ID-ja modela. Usmerjanje glede na delovno obremenitev, omejitev glede na politiko najemnika, prilagajanje glede na ponudnika in poravnavo dejanske uporabe v knjigi. To spremeni razmišljanje iz spremenljivke skritih stroškov v eksplicitno nadzorno površino za nadzor stroškov API-ja AI.

Sorodno branje

• knjiga obračunavanja, ki rezervira in poravna vsak klic modela
• notranji vzdevki modela in pogodbe o zmogljivosti
• obračunavanje pretočnih žetonov za končna uporaba in delni odgovori