Indoklás és erőfeszítés irányítása AI API-átjáróban: A gondolkodási tokenek, a késleltetés és a költségek szabályozása a szolgáltatók között

Az érvelési mélység már nem egyszerű modelllehetőség. Egyes szolgáltatók enum-stílusú erőfeszítési szinteket tesznek közzé. Mások token költségvetést, dinamikus gondolkodást vagy modellcsaládokat mutatnak be, ahol a gondolkodást nem lehet teljesen letiltani. A látható válasz rövid lehet, míg a rejtett érvelés számlázható kimeneti tokeneket fogyaszt. Ha minden alkalmazáscsapat közvetlenül állítja be ezeket a vezérlőket, akkor a költségeket, a késleltetést és a minőséget nehéz megmagyarázni.

A gyakorlati válasz az, hogy az okoskodás és az erőfeszítés vezérlését áthelyezzük az API-átjáróba. Az átjárónak osztályoznia kell a munkaterhelést, le kell képeznie egy szolgáltató-specifikus érvelési vezérlőhöz, érvényesítenie kell a bérlői költségvetést, rögzítenie kell a tényleges érvelési használatot, és láthatóvá kell tennie a leminősítési döntéseket az elemzésben. A modellazonosítónak, a szolgáltatási szintnek, a maximális teljesítménynek és az érvelési mélységnek külön irányelvdimenziónak kell lennie.

Olvasói probléma: Az egyszerű kérések megtérülnek a mélyreható érvelésért

Az érvelésre képes modelleket alkalmazó csapatok általában egy ésszerű céllal kezdenek: javítsák a minőséget a nehéz feladatok során. A probléma később jelentkezik, amikor ugyanazokat az alapértelmezett értékeket újrahasznosítja a kivonatoláshoz, a rövid összefoglalókhoz, a formázáshoz és az osztályozáshoz. Ezekhez a kérésekhez nincs szükség drága tesztidő-számításra, de ettől függetlenül kiválthatják.

Ez három működési hibát okoz:

• Költség átlátszatlansága: a felhasználó rövid választ lát, de a főkönyv rejtett érvelési tokeneket vagy szolgáltató-specifikus megfelelőket tartalmaz.
• A késleltetési idő megnövekedett interaktív munkafolyamattá válik, mert az ugyanaz a modell mögött látható. alias.
• Szabályzat töredezettsége: minden termékcsapat különböző szolgáltatói paramétereket tanul meg, és különböző korlátokat alkalmaz.

Az átjárószintű érvelési házirend megoldja az ellenőrzési problémát, mielőtt az számlázási problémává válna.

Tények: A szolgáltatói érvelési vezérlők nem egyenértékűek.AI>Openul> Az érvelésre képes API-k egy reasoning objektumot tesznek közzé a támogatott modellekhez, beleértve az olyan erőfeszítéseket, mint a none, minimal, low, medium, high és xhigh. Az alacsonyabb erőfeszítés csökkentheti az érvelési tokenek számát és javíthatja a válasz sebességét.

Az OpenAI dokumentációja azt állítja, hogy a max_output_tokens korlátozhatja az összes generált tokenek számát, beleértve az érvelési és végső kimeneti tokeneket.

Az antropikus kiterjesztett gondolkodás a budget_tokens értékkel engedélyezhető. A gondolkodási tokenek kimeneti tokenekként kerülnek kiszámlázásra, és a látható válaszszöveg mellett beleszámítanak a max_tokens-be.

Az antropikus dokumentáció azt is megjegyzi, hogy a számlázott kimeneti tokenek száma nem feltétlenül egyezik a látható válasz tokenek számával, mivel a belső gondolkodási tokenek akkor is számlázhatók, ha nem teljesen láthatók.

A Gemini gondolkodási priviccsel rendelkezők kimeneti dokumentációi is tartalmazhatnak gondolkodási primer állapotokat. használati mezők, amelyek elválasztják a gondolatjogkivonatokat és a kimeneti tokeneket.

A Gemini 2.5 stílusú vezérlői közé tartozik a thinkingBudget, amely dinamikus gondolkodást biztosít a támogatott modelleken, illetve nulla költségvetésű letiltást egyes modellcsaládoknál. Egyes modellek nem tudják letiltani a gondolkodást.

Az újabb Gemini útmutató a thinking_level értékeket ajánlja, például a minimális, az alacsony, a medium és a magas értékeket a Gemini 3.x-stílusú modellekhez a nyers numerikus költségvetések helyett.

Javaslat: Hozzon létre szolgáltatósemleges érvelési profilokat

Határozzon meg egy kis belső szókészletet, amelyet a termékcsapatok megérthetnek anélkül, hogy elolvasnák az összes szolgáltatói API-referenciát.A legtöbb átjáróhoz elegendő öt profil:

feladatok

Belső profil	Cél	Tipikus használat	Irányelv-beállítás
nincs	Tiltja le vagy csökkenti a rejtett címkézést, kivonatolást, a rejtett okok kibontását vagy minimalizálását útválasztás	Alapértelmezés nagy mennyiségű egyszerű végpontokhoz
low	Egyszerű érvelés a szerény kétértelműség miatt	Rövid támogatási válaszok, egyszerű összehasonlítások, átírási feladatok	Engedélyezett nagy vonalakban
szabvány	Kiegyensúlyozott érvelés a rutin tudásmunkához	Tervezés, kódellenőrzés, irányelvek elemzése, hosszabb szintézis	Alapértelmezés vegyes munkaterhelés esetén
mély erőfeszítés	Hibakeresés, matematikai, biztonsági felülvizsgálat, ügynöktervezés	Bérlő, kulcs, munkafolyamat és költségkeret által korlátozva
korlátozott-mély	Magas érvelés kemény plafonnal	Prémium feladatok, ahol az elszabaduló költségek és költségek nem igényelhetők. analytics

A profil az alkalmazásra vonatkozó szerződés. A szolgáltató paraméterei az adapter részleteivé válnak. Ez az ügyfélkód hordozható marad, és lehetővé teszi a platformtulajdonosok számára, hogy frissítsék a leképezéseket a szolgáltatói API-k változása esetén.

Munkaterhelési osztályok feltérképezése a szolgáltatók feltérképezése előtt

Az érvelést a terhelési szándék alapján kell megválasztani, nem pedig a személyes preferenciák vagy a modell népszerűsége alapján. Adjon hozzá egy átjárómezőt, például workload_class, amelyet az ügyfél biztosít, vagy egy jóváhagyott útvonalkonfigurációból következtet.

Példa munkaterhelési szabályzat

{
  "workload_policies": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "nincs",
      "max_reasoning_profile": "alacsony",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "nincs",
      "max_reasoning_profile": "alacsony",
      "max_output_tokens": 300
    },
    "draft_customer_reply": {
      "default_reasoning_profile": "alacsony",
      "max_reasoning_profile": "standard",
      "max_output_tokens": 1200
    },
    "code_review": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "mély",
      "max_output_tokens": 4000
    },
    "security_review": {
      "default_reasoning_profile": "mély",
      "max_reasoning_profile": "capped-deep",
      "max_output_tokens": 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "mély",
      "max_output_tokens": 5000
    }
  }
}

Ez az irányelv két hasznos dolgot tesz. Először is, megakadályozza, hogy az egyszerű végpontok költséges alapértelmezett értékeket örököljenek. Másodszor, konkrét áttekintési felületet biztosít a rendszergazdáknak: mely munkafolyamatok kérhetnek mélyreható érvelést, és milyen felső határok alatt?

Kompatibilitási mátrix készítése

Az átjáróadapternek minden szolgáltatóhoz és modellcsaládhoz karban kell tartania egy mátrixot. Legalább tárolja, hogy a modell támogatja-e az érvelés letiltását, az enum erőfeszítést, a numerikus költségvetést, a dinamikus gondolkodást, a maximális támogatott költségkeretet és az érvelési tokenek használati mezőit.

Példa mátrix alakzat

{
  "szolgáltatók": {
    "szolgáltató_a": {
      "modell_family_x": {
        "supports_reasoning": igaz,
        "control_type": "effort_enum",
        "allowed_values": ["nincs", "minimális", "alacsony", "közepes", "magas", "xhigh"],
        "can_disable": igaz,
        "reports_reasoning_tokens": igaz
      }
    },
    "szolgáltató_b": {
      "modell_family_y": {
        "supports_reasoning": igaz,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_disable": hamis,
        "reports_reasoning_tokens": igaz
      }
    },
    "szolgáltató_c": {
      "modell_family_z": {
        "supports_reasoning": igaz,
        "control_type": "gondolkodási_szint",
        "allowed_values": ["minimális", "alacsony", "közepes", "magas"],
        "can_disable": hamis,
        "reports_reasoning_tokens": igaz
      }
    }
  }
}

A kompatibilitási mátrix nem csak az emberek számára készült dokumentáció. Végrehajtható házirendnek kell lennie. A kérés útválasztójának használnia kell a feladás előtt, a számlázási főkönyvnek pedig az elszámolás során.

A belső profilok fordítása szolgáltatói paraméterekre

A szolgáltatói leképezéseknek expliciteknek és verziószámoknak kell lenniük. Ne hagyatkozz olyan homályos kifejezésekre, mint például „használj okosabb érvelést”. Az átjárónak pontosan tudnia kell, hogy melyik szolgáltatói paramétert küldte el.

Példaleképezés

{
  "reasoning_profile_mappings": {
    "nincs": {
      "effort_enum": "nincs",
      "budget_tokens": 0,
      "gondolkodási szint": "minimális"
    },
    "alacsony": {
      "effort_enum": "alacsony",
      "budget_tokens": 2048,
      "gondolkodási szint": "alacsony"
    },
    "standard": {
      "effort_enum": "közepes",
      "budget_tokens": 8192,"gondolkodási szint": "közepes"
    },
    "mély": {
      "effort_enum": "magas",
      "budget_tokens": 20000,
      "gondolkodási szint": "magas"
    },
    "capped-deep": {
      "effort_enum": "magas",
      "budget_tokens": 12000,
      "gondolkodási szint": "magas"
    }
  }
}

Ezek a számok példák, nem általános alapértelmezett értékek. A megfelelő költségvetés a modellcsaládtól, az árképzéstől, a késleltetési követelményektől és az értékelési eredményektől függ. A megvalósítás fontos részlete, hogy az átjáró birtokolja a leképezést, és minden kérésnél rögzíti a feloldott szolgáltatói paramétert.

Sikertelen bezárás, ha a leképezés nem biztonságos

A nem támogatott érvelési vezérlők nem válhatnak csendben szolgáltatói alapértelmezésekké. Az alapértelmezések drágák lehetnek, és idővel változhatnak.

Ha a kért profilt nem lehet biztonságosan hozzárendelni, használja a három eredmény egyikét:

• Engedélyezés: a szolgáltató/modell támogatja a kért profilt, és a bérlői házirend megengedi.
• Rendszerre váltás: a kért profil a legmagasabb profilú szabályzatot alkalmazza. visszaminősítés.
• Elutasítás: a profilt nem lehet biztonságosan megjeleníteni, a bérlő szigorú magatartást igényel, vagy a visszaminősítés sértené a termék elvárásait.

Példa határozati rekord

{
  "request_id": "req_123",
  "bérlő_azonosítója": "bérlő_42",
  "api_key_id": "key_abc",
  "workflow": "code_review",
  "requested_reasoning_profile": "mély",
  "applied_reasoning_profile": "standard",
  "decision": "visszaminősített",
  "decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "provider_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "erőfeszítés": "közepes"
  }
}

Ez a döntési rekord értékes a támogatás, a számlázási viták és a minőségi vizsgálatok során. Ezenkívül megakadályozza a láthatatlan minőségi regressziót a költségvetési nyomás alatt.

A költségkeret-vezérlőknek több mint maximális kimeneti tokenre van szükségük

A maximális kimeneti token korlátozás szükséges, de ez nem elegendő. Az érvelésre képes modellek esetében a modell a határokoskodás nagy részét elköltheti, és túl kevés teret hagy a végső válasznak. A felhasználó ezután fizethet a használhatatlan csonkolt válaszért.

Használjon réteges plafonokat:

• max_reasoning_profile bérlőnként, API-kulcsonként és munkafolyamatonként.
• max_thinking_budget vagy ezzel egyenértékű szolgáltatónként/modellpáronként.
kódokat generál a total_tokken_tokken_ma_x. ahol a szolgáltató együtt számolja az érvelést és a látható kimenetet.
• daily_deep_reasoning_spend bérlőnként vagy viszonteladói ügyfelenként.
• deep_reasoning_requests_per_hour nagy volumenű végpontok esetén.
• reasoning_thens for anomatily_token_ for anomatily_token_ figyelmeztetéseket.

A költségkeret-ellenőrzésnek a feladás előtt meg kell történnie. Az elszámolási lépésnek a szolgáltatói válasz megérkezése után egyeztetnie kell a tényleges használatot. Ha a szolgáltató külön jelenti a gondolkodási tokeneket, tárolja azokat külön. Ha csak a teljes kimeneti tokeneket jelenti, tárolja az elérhető legjobb normalizált mezőket, és jelölje meg a megbízhatósági szintet.

Főkönyvi mezők az érveléshez

Az analitikának meg kell mutatnia a különbséget a látható válasz hossza és a fizetett érvelési erőfeszítés között. Egy hasznos főkönyvi sornak tartalmaznia kell a következőket:

• bérlőazonosító, api_key_id, end_user_id és munkafolyamat.
• requested_model, served_model, szolgáltató és modell alias.
• requested_reasoning_profile és applied_reasoning_profile.
• provider_reasoning_param, strukturált JSON-ként tárolva.
• input_tokens,ens_out>, reasoning_tokens_or_equivalent, cached_tokens és total_billable_tokens.
• max_output_tokens és bármilyen szolgáltató-specifikus gondolkodási költségkeret.
• latency_to_code_tok>,en_en_msst_tal> és az adatfolyam befejezésének állapota.
• becsült_költség_elküldés előtt, reserved_budget, settled_cost és reconciliation_status.
• politikai_döntés, például engedélyezve, lefokozva, visszautasítva. alapértelmezés szerint nem naplózza a nyers gondolatláncot. A legtöbb irányítási és FinOps-munkához elegendő a számvetés és a politikai döntés. Az érzékeny érvelési szöveg tárolása elkerülhető adatvédelmi, megfelelőségi és megőrzési problémákat okozhat.

  Megvalósítási folyamat

  A termelési átjáró determinisztikus kérésfolyamatként valósíthatja meg az okoskodás és az erőfeszítés útválasztását.

  1. A kérés hitelesítése. A bérlő, az API-kulcs feloldása, a munkafolyamat, a csapat, a felhasználói munkafolyamatliesítése, a csapat. munkaterhelés. Ha lehetséges, használjon kifejezett ügyfélmezőt.Ismert végpontok esetén kösse össze a terhelési osztályt az útvonalkonfigurációnál.
  2. Betöltési szabályzat. Egyesítse a globális, bérlői, kulcs- és munkafolyamat-megszorításokat.
  3. Válassza ki a modelljelölteket. Használja a meglévő modellálnevet vagy modellkiválasztási házirendet, mielőtt feloldaná az okfejtés alapértelmezett vezérlőit.
  4. A kérés okának feloldása, majd a profil alkalmazása. maximumok.
  5. Ellenőrizze a kompatibilitást. Győződjön meg arról, hogy a szolgáltató/modell pár biztonságosan támogatja-e a kiválasztott profilt.
  6. A költség és a tartalék költségkeret becslése. Tartalmazza a valószínű okfejtést, ne csak a látható kimenetet.
  7. Küldés a szolgáltató natív paramétereivel. Küldje el az indoklást, a költségkeret-ellenőrzési szintet. Adapter.
  8. Normalizálja a használatot a válaszadáskor. Lehetőség szerint különítse el a bemenetet, a látható kimenetet, az érvelést, a gyorsítótárat, az eszközt és a teljes tokeneket.
  9. Rendelés és riasztás. A lefoglalt és a tényleges költségek összeegyeztetése, a kvóták frissítése és az anomáliás jelek kibocsátása.

  Ez az ellenőrzési folyamat megőrzi az indoklást. Ezenkívül a platformcsapatok egyetlen helyet biztosítanak az alapértelmezett beállítások megváltoztatásához, amikor a szolgáltatói API-k fejlődnek.

  Értékelés az alapértelmezések megváltoztatása előtt

  Ne támogassa a nagyobb érvelési erőfeszítést néhány lenyűgöző példa alapján. Futtasson kiértékeléseket, mielőtt módosítaná egy munkaterhelési osztály alapértelmezett értékét.

  Mérjen legalább négy eredményt:

  • Feladat minősége: pontosság, áttekintő elfogadása, séma érvényessége vagy az eszközhívás sikeressége.
  • Latencia: az első jogkivonatig eltelt idő és a teljes befejezési költség / költség / Cost:>
  • Hibamódok: csonkítás, elutasítás, hibás formátumú kimenet, túlzott szerszámhívások vagy időtúllépés.

  A legfontosabb mutató nem a „token kérésenként”. Egy alacsonyabb jelű válasz, amely sikertelen az érvényesítésben, az újrapróbálkozások után drágább lehet. A magasabb érvelésű válasz indokolt lehet a biztonsági felülvizsgálatnál, de pazarló a jegyek címkézésénél. Értékelés munkafolyamat szerint.

  Trade-Offs

  Az ésszerű irányítás növeli az ellenőrzést, de nem ingyenes.

  • Hordozhatóság versus szolgáltatói funkciók: a belső profilok lehetővé teszik az alkalmazáskód hordozhatóságát, de előfordulhat, hogy a haladó csapatoknak jóváhagyott menekülési nyílásra van szükségük a szolgáltató-specifikus ellenőrzésekhez.
  • bizonyosság VersusB minőségvédelem ellen. elszabadult költés, de a túl szigorú felső határok lecsonkolhatják a hasznos válaszokat, miután az érvelési tokenek már el vannak költöttek.
  • Dinamikus gondolkodás kontra kiszámíthatóság: a dinamikus szolgáltatói vezérlők javíthatják a kényelmet, de gyengítik a feladás előtti költségbecsléseket, kivéve, ha az átjáró rögzíti a tényleges használatot, és nem kényszeríti ki az elszámolási korlátokat. A költségvetési nyomás alatti érvelés megőrzi a rendelkezésre állást, de a választ telemetrikus címkével kell ellátni, és bele kell foglalni a minőségértékelésbe.
  • Analytics versus adatvédelem: az érvelési token mérőszámai hasznosak, de a nyers érvelési nyomokat nem szabad tárolni, hacsak nincs szándékos, jóváhagyott megőrzési szabályzat.

  Standard Policy Willep Előrejelzés, nem pedig ellenőrzött tény: az okfejtés a modell-útválasztás, a sebességkorlátok, a szolgáltatási szintek és a jogkivonat-költségvetések mellett a normál termelésirányítássá válik. Ahogy a szolgáltatók továbbra is különféle gondolkodási vezérlőket tesznek közzé, az alkalmazáscsapatok kevésbé lesznek hajlandók ezeket a különbségeket termékkódba kódolni.

  Azok az átjárók, amelyek az érvelést szabályozott futásidejű dimenzióként kezelik, tisztább bérlői számlázást, tisztább hordozhatóságot és a várakozási idő jobb szabályozását biztosítják.Azok az átjárók, amelyek véletlen modellparaméterként kezelik, nehezen tudják megmagyarázni, hogy a rövid válaszok néha miért kerülnek többe, mint a hosszú válaszok.

  Művelhető ellenőrzőlista

  • Belső profilok meghatározása: nincs, alacsony, standard, deep és maximális profilok és capped-deep terhelési osztály.
  • Hozzon létre egy szolgáltató/modell kompatibilitási mátrixot az érvelési vezérlőkhöz.
  • Fordítsa le a profilokat a szolgáltató natív paramétereire az illesztőrétegben.
  • Sikertelen lezárás, ha a kért profilt nem lehet biztonságosan leképezni.
  • Költségkeret lefoglalása elküldés előtt az indoklást nem ismerő profil becslésekkel,
  kért szolgáltatói profil> becslések alkalmazásával. használat, látható kimenet, késleltetés és költség.
  • Anomáliára vonatkozó figyelmeztetések hozzáadása a magas érvelési token arányhoz és a mély érveléshez a nagy mennyiségű egyszerű munkafolyamatokhoz.
  • Futtasson munkafolyamat-szintű kiértékeléseket, mielőtt megváltoztatná az alapértelmezett erőfeszítést.
  • Kerülje el a nyers érvelési szöveg alapértelmezés szerinti naplózását; ehelyett a boltok számlálását és a politikai döntéseket.

  Következtetés

  Az érvelésre képes modellek hasznosak, mert többet tudnak költeni nehéz problémákra. Ugyanez a képesség költségessé válik, ha válogatás nélkül alkalmazzák. Az átjárónak el kell döntenie, hogy mikor engedélyezett a mélyebb érvelés, hogyan illeszkedik az egyes szolgáltatókhoz, mekkora költségvetést költhet el, és hogyan mérhető az eredmény.

  A tartós minta az, hogy elválasztja az érvelési erőfeszítést a modellazonosítótól. Útvonal terhelés szerint, korlát bérlői szabályzat szerint, szolgáltatónkénti alkalmazkodás, és a tényleges használat elszámolása a főkönyvben. Ez a rejtett költségváltozóból származó érvelést a mesterséges intelligencia API költségszabályozásának explicit vezérlőfelületévé változtatja.

  Kapcsolódó olvasmány

  • belső modellálnevek és képességszerződések
  • FAQ

    Gyakran ismételt kérdések

    Lehetővé kell-e tenni az alkalmazáscsapatok számára, hogy közvetlenül állítsák be a szolgáltató natív érvelési paramétereit?

    Általában nem alapértelmezés szerint. A szolgáltató-semleges profil hordozhatóvá teszi az ügyfélkódot, és lehetővé teszi az átjáró számára a bérlői költségvetések érvényesítését. A haladó csapatok továbbra is használhatnak szolgáltató-specifikus vezérlőket egy jóváhagyott menekülési nyíláson keresztül, ellenőrzési naplózással.

    A maximális kimeneti tokenek elegendőek az érvelési költségek szabályozásához?

    Nem. Egyes érvelésre képes modelleken az érvelési tokenek és a látható válasz tokenek megosztják a generált token limitet vagy számlázási kategóriát. Egy kérés sok tokent tölthet el az érveléssel, és túl kevés teret hagyhat a végső válasz számára, ezért az átjárónak korlátoznia kell az érvelési profilt vagy a gondolkodási költségvetést is.

    Az átjárónak naplóznia kell a gondolatláncot?

    Alapértelmezés szerint nem. Költségszabályozáshoz és elemzéshez az átjárónak általában számlálására, irányelvi döntésekre, modellazonosítókra, várakozási időre és költségmezőkre van szüksége. A nyers érvelési szöveg magánéleti és megőrzési kockázatot jelenthet.

    Mikor legyen a mély érvelés az alapértelmezett?

    Csak azoknál a munkafolyamatoknál, ahol az értékelések azt mutatják, hogy a minőségjavulás indokolja a várakozási időt és a költségeket. A matematika, a többlépcsős hibakeresés, a biztonsági felülvizsgálat és a nagy értékű ügynöktervezés gyakori jelöltek; kivonatolás, formázás, osztályozás és rövid tényszerű válaszok általában nem.