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

Globina razmišljanja 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 sklepanje porablja zaračunljive izhodne žetone. Če vsaka aplikacijska ekipa 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 API prehod. 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 politike.

Težava bralca: Enostavne zahteve plačujejo za globoko razmišljanje

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 dragega izračuna v času preizkusa, vendar ga lahko še vedno sprožijo.

To povzroči tri operativne napake:

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

A politika razmišljanja na ravni prehoda reši težavo nadzora, preden postane težava zaračunavanja.

Dejstva: Kontrole sklepanja ponudnika niso enakovredne

Naslednje so dejstva o implementaciji, ne priporočila.

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

Posledica jedrne arhitekture je preprosta: ne izpostavljajte kontrolnikov sklepanja, ki izvirajo iz ponudnika. kot edina pogodba. 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 referenco vsakega ponudnika API. Za večino prehodov je dovolj pet profilov:

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

Preslikava razredov delovne obremenitve pred preslikavo ponudnikov

Prizadevanje za sklepanje 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": "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
    }
  }
}

Ta pravilnik omogoča 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, enum napor, numerični proračun, dinamično razmišljanje, največji podprti proračun in polja uporabe za žetone sklepanja.

Primer oblike matrike

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

Združljivostna matrika 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": {
    "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"
    }
  }
}

Te številke so primeri, ne univerzalne 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 privzeti ponudniki. 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 dovoljuje it.
• Znižanje: zahtevani profil je nad pravilnikom, zato prehod uporabi najvišji odobren profil in zabeleži znižanje.
• Zavrni: profila ni mogoče varno predstaviti, najemnik zahteva strogo vedenje ali pa bi znižanje kršilo izdelek pričakovanja.

Primer zapisa odločitve

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

Ta zapis odločitve 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čje število izhodnih žetonov

Omejitev največjega izhodnega žetona je potrebna, 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 skrajšani odgovor.

Uporabi večplastne zgornje meje:

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

Preverjanje proračuna bi se moralo opraviti pred pošiljanjem. 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 prikazati razliko med vidno dolžino odgovora in plačanim trudom sklepanja. Uporabna vrstica glavne knjige mora vključevati:

• tenant_id, api_key_id, end_user_id in workflow.
• requested_model, served_model, ponudnik in vzdevek modela.
• 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 dokončanje toka stanje.
• estimated_cost_before_dispatch, reserved_budget, settled_cost in reconciliation_status.
• policy_decision, na primer dovoljeno, znižano, zavrnjeno ali nadomestno.

Privzeto ne beleži neobdelanih misli. Za večino upravljanja in dela FinOps so dovolj š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, API ključ, uporabnik, ekipa in potek dela.
2. Razvrstite delovno obremenitev. Uporabite izrecno polje odjemalca, kjer je to mogoče. Za znane končne točke povežite razred delovne obremenitve pri konfiguraciji poti.
3. Pravilnik nalaganja. Združite globalne, najemniške, ključne in delovne omejitve.
4. Izberite kandidate za model. Uporabite vzdevek obstoječega modela ali pravilnik o izbiri modela, preden razrešite sklepanje kontrolniki.
5. Razrešite obrazložitveni profil. Začnite z zahtevanim profilom, nato uporabite privzete in največje vrednosti poteka dela.
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 le vidnega izhoda.
8. Pošiljanje s parametri, ki izvirajo iz ponudnika. Pošlji enum napor, proračunske žetone, raven razmišljanja ali brez nadzora sklepanja glede na adapter.
9. Normaliziraj uporabo ob odgovoru. Ločen vnos, viden izhod, sklepanje, predpomnilnik, orodje in skupni žetoni, kjer je to mogoče.
10. Poravnava in opozarjanje. Uskladite rezervirane in dejanske stroške, posodobite kvote in oddajajte signale nepravilnosti.

Ta cevovod ohranja nadzor sklepanja, ki ga je mogoče revidirati.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 le na nekaj impresivnih primerih. Zaženite 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 popolno dokončanje čas.
• Cena: cena na zahtevo in cena na sprejet odgovor.
• Načini napake: obrezovanje, zavrnitev, nepravilno 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

Upravljanje z obrazložitvijo 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 posamezne ponudnike nadzor.
• Proračunska gotovost v primerjavi s kakovostjo: stroge omejitve ščitijo najemnike pred nenadnimi stroški, prestroge omejitve pa lahko skrajšajo uporabne odgovore, potem ko so žetoni za sklepanje že porabljeni.
• Dinamično razmišljanje v primerjavi s predvidljivostjo: dinamične kontrole ponudnika lahko izboljšajo priročnost, vendar oslabi ocene stroškov pred odpošiljanjem, razen če prehod beleži dejansko uporabo in uveljavlja omejitve poravnave.
• Razpoložljivost znižanja v primerjavi z doslednostjo: znižanje razpoložljivosti med proračunskim pritiskom ohranja razpoložljivost, vendar mora biti odziv označen v telemetriji in vključen v oceno kakovosti.
• Analitika v primerjavi zasebnost: meritve žetona sklepanja so uporabne, vendar se sledi neobdelanega sklepanja ne smejo shranjevati, razen če obstaja premišljena, odobrena politika hrambe.

Napoved: Politika sklepanja bo postala standardni nadzor prehoda

To je napoved, ne preverjeno dejstvo: trud sklepanja bo poleg modela postal normalen nadzor proizvodnje usmerjanje, omejitve stopenj, ravni storitev in proračuni ž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 razsežnost izvajalnega časa, 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.

Kontrolni seznam za ukrepanje

• Določite notranje profile: none, low, standard, deep in capped-deep.
• Dodelite privzete in največje profile vsaki delovni obremenitvi razred.
• Izdelajte matriko združljivosti ponudnika/modela za nadzor razmišljanja.
• Prevedite profile v izvorne parametre ponudnika v sloju adapterja.
• Zapri se zaradi napake, ko zahtevanega profila ni mogoče varno preslikati.
• Rezervirajte proračun pred pošiljanjem z upoštevanjem sklepanja ocene.
• Zabeležite zahtevani profil, uporabljeni profil, parameter ponudnika, uporabo sklepanja, vidni izhod, zakasnitev in stroške.
• Dodajte opozorila o nepravilnostih za visoka razmerja žetonov sklepanja in globoko sklepanje v enostavnih potekih dela z velikim obsegom.
• Zaženite ocene na ravni poteka dela, preden spremenite privzeto napor.
• Izogibajte se privzetemu zapisovanju neobdelanega obrazložitvenega besedila; namesto tega shranjujte štetje in odločitve o politiki.

Zaključek

Modeli, ki so 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 bi se moral 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, prilagoditev glede na ponudnika in poravnavo dejanske uporabe v knjigi. To spremeni razmišljanje iz spremenljivke skritih stroškov v eksplicitno nadzorno površino za AI API nadzor stroškov.

Sorodno branje

• knjiga obračunavanja, ki rezervira in poravna vsak klic modela
• notranji vzdevki modela in zmogljivost pogodbe
• obračunavanje pretočnih žetonov za končno uporabo in delne odgovore