MGModel Gate
Přihlaste seZačněte
Průvodce a náhled

Směrování uvažování a úsilí v bráně AI API: ovládání tokenů myšlení, latence a nákladů napříč poskytovateli

Modely schopné uvažování odhalují různé ovládací prvky pro hloubku myšlení, rozpočty tokenů, fakturaci a latenci. Snahu o uvažování považujte za řízenou runtime politiku v bráně, nikoli jako volné nastavení modelu uvnitř každé aplikace.

13 min přečtenoModel Gate Editorial Team

Hloubka uvažování již není jednoduchou možností modelu. Někteří poskytovatelé vystavují úrovně úsilí ve stylu enum. Jiní odhalují tokenové rozpočty, dynamické myšlení nebo modelové rodiny, kde myšlení nelze plně deaktivovat. Viditelná odpověď může být krátká, zatímco skryté uvažování spotřebovává zúčtovatelné výstupní tokeny. Pokud každý aplikační tým nastaví tyto ovládací prvky přímo, bude obtížné vysvětlit náklady, latenci a kvalitu.

Praktickou odpovědí je přesunout ovládání uvažování a úsilí do brány API. Brána by měla klasifikovat pracovní zátěž, namapovat ji na řízení uvažování specifické pro poskytovatele, vymáhat rozpočty nájemců, zaznamenávat skutečné využití uvažování a zviditelnit rozhodnutí o downgradu v analýze. ID modelu, úroveň služeb, maximální výstup a hloubka uvažování by měly být samostatné dimenze zásad.

Problém čtenářů: Za hluboké uvažování platí jednoduché požadavky

Týmy, které přijímají modely schopné uvažování, obvykle začínají s rozumným cílem: zlepšit kvalitu náročných úkolů. Problém se objeví později, když se stejné výchozí hodnoty znovu použijí pro extrakci, krátké souhrny, formátování a klasifikaci. Tyto požadavky nevyžadují nákladné výpočty v testovacím čase, ale mohou je přesto spustit.

Tím dochází ke třem provozním selháním:

  • Neprůhlednost nákladů: uživatel vidí krátkou odpověď, ale účetní kniha obsahuje skryté tokeny uvažování nebo ekvivalenty specifické pro poskytovatele.
  • Posun latence: za stejným pracovním postupem se stává pomalý důvod, protože se zdá, že stejný pracovní postup je pomalý. alias.
  • Fragmentace zásad: každý produktový tým se učí různé parametry poskytovatele a používá různá omezení.

Zásady uvažování na úrovni brány řeší problém s ovládáním dříve, než se z něj stane problém s fakturací.

Fakta: Kontrolní mechanismy uvažování poskytovatele nejsou rovnocenné

Následující doporučení nejsou implementace.uvažování, včetně hodnot úsilí, jako jsou none, minimální, nízké, střední, vysoké a xhigh. Menší úsilí může snížit tokeny uvažování a zlepšit rychlost odezvy.

  • Dokumentace OpenAI uvádí, že max_output_tokens může omezit celkový počet generovaných tokenů, včetně tokenů uvažování a konečného výstupu.
  • Rozšířené antropické myšlení lze aktivovat pomocí hodnoty budget_tokens. Tokeny myšlení jsou účtovány jako výstupní tokeny a započítávají se do max_tokens spolu s viditelným textem odpovědi.
  • Antropická dokumentace také poznamenává, že počet účtovaných výstupních tokenů se nemusí shodovat s viditelným počtem tokenů odezvy, protože interní tokeny myšlení mohou být účtovány, i když nejsou plně viditelné.
  • Dokumentace myšlení Gemini uvádí, že samostatná pole myšlenek Gemini a myšlení k myšlenkám mohou zahrnovat výstupy a výstupy k myšlenkám. tokeny.
  • Ovládací prvky ve stylu Gemini 2.5 zahrnují thinkingBudget s dynamickým myšlením u podporovaných modelů a deaktivací nulového rozpočtu u některých modelových rodin. Některé modely nemohou zakázat myšlení.
  • Novější pokyny pro Gemini doporučují hodnoty thinking_level, jako jsou minimální, nízké, střední a vysoké pro modely ve stylu Gemini 3.x namísto hrubých numerických rozpočtů.

    • Jednoduché ovládací prvky jako architektura – neimplementace je jednoduchá. smlouvy. Nejsou dostatečně stabilní, dostatečně přenosné nebo dostatečně srovnatelné pro správu více poskytovatelů.

    Doporučení: Vytvořte profily uvažování neutrální vůči poskytovatelům

    Definujte malý interní slovník, kterému produktové týmy porozumí, aniž byste museli číst všechny reference API poskytovatelů.Pro většinu bran stačí pět profilů:

    Interní profilÚčelTypické použitíPostoj zásad
    žádnýZakázat nebo minimalizovat tagging, skryté uvažování, kde podporováno routingVýchozí pro velkoobjemové jednoduché koncové body
    nízkáSnadné zdůvodnění pro mírnou nejednoznačnostKrátké odpovědi podpory, jednoduchá srovnání, přepisovací úlohyPovoleno široce
    standardníVyvážené uvažování pro rutinní znalostní práciPlánování, kontrola kódu, analýza zásad, delší syntézaVýchozí pro smíšenou pracovní zátěž
    hlubokébezpečnostbezpečnost, obtížné úkolyH revize, plánování agentůOmezeno nájemcem, klíčem, pracovním postupem a rozpočtem
    capped-deepVysoké uvažování s pevným stropemPrémiové úkoly, kde jsou neakceptovatelné náklady na únikVyžaduje thetabled>výslovný limit/profil/analýza. aplikační smlouva. Parametry poskytovatele se stanou detaily adaptéru. Díky tomu je klientský kód přenosný a majitelé platforem mohou aktualizovat mapování podle toho, jak se mění rozhraní API poskytovatele.

    Namapujte třídy pracovní zátěže před poskytovateli mapování

    Rozumné úsilí by mělo být vybráno na základě záměru pracovní zátěže, nikoli na základě osobních preferencí nebo oblíbenosti modelu. Přidejte pole brány, jako je workload_class, buď dodané klientem, nebo odvozené ze schválené konfigurace trasy.

    Příklad zásad pracovního zatížení

    {
  "workload_policies": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "žádné",
      "max_reasoning_profile": "nízká",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "žádné",
      "max_reasoning_profile": "nízká",
      "max_output_tokens": 300
    },
    "draft_customer_reply": {
      "default_reasoning_profile": "nízká",
      "max_reasoning_profile": "standardní",
      "max_output_tokens": 1200
    },
    "code_review": {
      "default_reasoning_profile": "standardní",
      "max_reasoning_profile": "hluboký",
      "max_output_tokens": 4000
    },
    "security_review": {
      "default_reasoning_profile": "hluboký",
      "max_reasoning_profile": "hluboký limit",
      "max_output_tokens": 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "standardní",
      "max_reasoning_profile": "hluboký",
      "max_output_tokens": 5000
    }
  }
}

    Tato zásada dělá dvě užitečné věci. Za prvé, zabraňuje tomu, aby jednoduché koncové body zdědily nákladné výchozí hodnoty. Za druhé, poskytuje administrátorům konkrétní kontrolní plochu: které pracovní postupy mohou vyžadovat hluboké zdůvodnění a pod jakými limity?

    Vytvořte matici kompatibility

    Adaptér brány by měl udržovat matici pro každého poskytovatele a rodinu modelů. Uložte minimálně, zda model podporuje deaktivaci uvažování, enum úsilí, numerický rozpočet, dynamické myšlení, maximální podporovaný rozpočet a pole použití pro logovací tokeny.

    Příklad tvaru matice

    {
  "poskytovatelé": {
    "poskytovatel_a": {
      "model_family_x": {
        "supports_reasoning": pravda,
        "control_type": "effort_enum",
        "allowed_values": ["žádné", "minimální", "nízké", "střední", "vysoké", "xhigh"],
        "can_disable": true,
        "reports_reasoning_tokens": pravda
      }
    },
    "poskytovatel_b": {
      "model_family_y": {
        "supports_reasoning": pravda,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32 000,
        "can_disable": false,
        "reports_reasoning_tokens": pravda
      }
    },
    "poskytovatel_c": {
      "model_family_z": {
        "supports_reasoning": pravda,
        "control_type": "úroveň_myšlení",
        "allowed_values": ["minimální", "nízká", "střední", "vysoká"],
        "can_disable": false,
        "reports_reasoning_tokens": pravda
      }
    }
  }
}

    Matice kompatibility není dokumentací pouze pro lidi. Měla by to být spustitelná politika. Směrovač požadavku by jej měl použít před odesláním a účetní kniha by ho měla použít během zúčtování.

    Přeložit interní profily na parametry poskytovatele

    Mapování poskytovatelů by mělo být explicitní a mělo by mít verzi. Nespoléhejte na vágní fráze, jako je „použijte chytřejší úvahy“. Brána by měla přesně vědět, který parametr poskytovatele byl odeslán.

    Příklad mapování

    {
  "reasoning_profile_mappings": {
    "žádný": {
      "effort_enum": "žádné",
      "budget_tokens": 0,
      "thinking_level": "minimální"
    },
    "nízký": {
      "effort_enum": "nízký",
      "budget_tokens": 2048,
      "thinking_level": "nízká"
    },
    "standardní": {
      "effort_enum": "střední",
      "budget_tokens": 8192,"thinking_level": "střední"
    },
    "hluboký": {
      "effort_enum": "vysoké",
      "budget_tokens": 20 000,
      "thinking_level": "vysoká"
    },
    "capped-deep": {
      "effort_enum": "vysoké",
      "budget_tokens": 12 000,
      "thinking_level": "vysoká"
    }
  }
}

    Tato čísla jsou příklady, nikoli univerzální výchozí hodnoty. Správné rozpočty závisí na rodině modelů, cenách, požadavcích na latenci a výsledcích hodnocení. Důležitým detailem implementace je, že brána vlastní mapování a zaznamenává vyřešený parametr poskytovatele pro každý požadavek.

    Fail Closed, když mapování není bezpečné

    Nepodporované ovládací prvky uvažování by se neměly v tichosti stát výchozími nastaveními poskytovatele. Výchozí hodnoty mohou být drahé a mohou se v průběhu času měnit.

    Pokud požadovaný profil nelze bezpečně namapovat, použijte jeden ze tří výsledků:

    • Povolit: poskytovatel/model podporuje požadovaný profil a zásady nájemce to povolují.
    • Downgrade: požadovaný profil je nad zásadou, takže brána použije nejvyšší schválený profil přejít na nižší verzi.
    • Odmítnout: profil nelze bezpečně reprezentovat, nájemce vyžaduje přísné chování nebo by přechod na nižší verzi porušil očekávání produktu.

    Příklad záznamu rozhodnutí

    {
  "request_id": "req_123",
  "tenant_id": "tenant_42",
  "api_key_id": "key_abc",
  "workflow": "code_review",
  "requested_reasoning_profile": "hluboký",
  "applied_reasoning_profile": "standardní",
  "decision": "sníženo",
  "decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "poskytovatel_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "úsilí": "střední"
  }
}

    Tento záznam rozhodnutí je cenný během podpory, fakturačních sporů a vyšetřování kvality. Zabraňuje také neviditelným regresím kvality během tlaku na rozpočet.

    Kontrola rozpočtu potřebuje více než maximální výstupní tokeny

    Je nutný maximální limit výstupních tokenů, ale není dostatečný. U modelů schopných uvažování může model strávit velkou část limitního uvažování a ponechat příliš málo prostoru pro konečnou odpověď. Uživatel pak může zaplatit za nepoužitelnou zkrácenou odpověď.

    Použít vrstvené stropy:

    • max_reasoning_profile na tenanta, klíč API a pracovní postup.
    • max_thinking_budget nebo ekvivalent na poskytovatele/modelový pár pro celkový počet vygenerovaných poskytovatelů
    • count_outkens. a viditelný výstup společně.
    • daily_deep_reasoning_spend na zákazníka nájemce nebo prodejce.
    • deep_reasoning_requests_per_hour pro koncové body s velkým objemem.
    • reasoning_token_ratio_threshold>

      li budget by mělo proběhnout před

      li kontrola rozpočtu pro

      li      . odeslání. Krok vypořádání by pak měl po obdržení odpovědi poskytovatele uvést do souladu skutečné využití. Pokud poskytovatel hlásí tokeny myšlení samostatně, uložte je samostatně. Pokud uvádí pouze celkové výstupní tokeny, uložte nejlepší dostupná normalizovaná pole a označte úroveň spolehlivosti.

      Pole hlavní knihy pro použití zdůvodnění

      Analytics musí ukazovat rozdíl mezi viditelnou délkou odpovědi a placeným úsilím o uvažování. Užitečný řádek hlavní knihy by měl obsahovat: