MGModel Gate
Log indKom i gang
Vejledning og indsigt

Begrundelse-indsats-routing i en AI API-gateway: Kontroller tænke-tokens, latens og omkostninger på tværs af udbydere

Fornuftsdygtige modeller afslører forskellige kontroller for tænkningsdybde, tokenbudgetter, fakturering og latenstid. Behandl ræsonnementindsats som en styret runtime-politik i gatewayen, ikke som en løs modelindstilling i hver applikation.

7 min læstModel Gate Editorial Team

Ræsonneringsdybde er ikke længere en simpel modelmulighed. Nogle udbydere afslører indsatsniveauer i enum-stil. Andre afslører symbolske budgetter, dynamisk tænkning eller modelfamilier, hvor tænkning ikke kan deaktiveres fuldstændigt. Det synlige svar kan være kort, mens skjult ræsonnement bruger fakturerbare output-tokens. Hvis hvert applikationsteam indstiller disse kontroller direkte, bliver omkostninger, latens og kvalitet svære at forklare.

Det praktiske svar er at flytte ræsonnement-indsatskontrol ind i API-gatewayen. Gatewayen bør klassificere arbejdsbyrden, kortlægge den til en udbyderspecifik begrundelseskontrol, håndhæve lejerbudgetter, registrere faktisk brug af ræsonnement og gøre nedgraderingsbeslutninger synlige i analyser. Model-id, serviceniveau, maksimalt output og begrundelsesdybde bør være separate politikdimensioner.

Læserproblem: Simple anmodninger betaler for dyb ræsonnement

Team, der anvender ræsonnement-kompatible modeller, starter normalt med et rimeligt mål: at forbedre kvaliteten på svære opgaver. Problemet opstår senere, når de samme standarder genbruges til udtrækning, korte resuméer, formatering og klassificering. Disse anmodninger behøver ikke dyre testtidsberegninger, men de kan stadig udløse det.

Dette skaber tre driftsfejl:

  • Omkostningsopacitet: brugeren ser et kort svar, men hovedbogen indeholder skjulte ræsonnementstokens eller udbyderspecifikke ækvivalenter.
  • Latency-modellen blev en langsommelig arbejdsgang, der så ud til, at den samme årsag til interaktiv arbejdsgang blev langsommelig: alias.
  • Politikfragmentering: hvert produktteam lærer forskellige udbyderparametre og anvender forskellige grænser.

En begrundelsespolitik på gatewayniveau løser kontrolproblemet, før det bliver et faktureringsproblem.

Fakta: Leverandørens begrundelseskontrol er ikke ækvivalent,

Følgende er ikke implementeret. anbefalinger.

  • OpenAI-ræsonnement-kompatible API'er afslører et reasoning-objekt for understøttede modeller, herunder indsatsværdier såsom none, minimal, low, medium, high og .xhigh Lavere indsats kan reducere ræsonnementstokens og forbedre responshastigheden.
  • OpenAI-dokumentation angiver, at max_output_tokens kan begrænse det samlede antal genererede tokens, inklusive både begrundelses- og endelige outputtokens.
  • Antropisk udvidet tænkning kan aktiveres med en budget_tokens-værdi. Tænke-tokens faktureres som output-tokens og tæller mod max_tokens sammen med synlig svartekst.
  • Antropisk dokumentation bemærker også, at faktureret output-token-antal muligvis ikke stemmer overens med antallet af synlige respons-tokens, fordi interne tænke-tokens kan faktureres, selv når de ikke er fuldt synlige.
  • Gemini-tænknings-dokumentation-tilstande og tankegange kan inkludere både output-tokens og tankegange. med brugsfelter, der adskiller tanke-tokens og output-tokens.
  • Gemini 2.5-kontrolelementer omfatter thinkingBudget med dynamisk tænkning på understøttede modeller og nul-budget deaktivering på nogle modelfamilier. Nogle modeller kan ikke deaktivere tænkning.
  • Nyere Gemini-vejledning anbefaler thinking_level-værdier såsom minimal, lav, medium og høj for modeller i Gemini 3.x-stil i stedet for rå numeriske/kernebudgetter:
    • <> Det er ikke en simpel arkitekt:<>. afsløre udbyder-native ræsonnement kontroller som den eneste kontrakt. De er ikke stabile nok, bærbare nok eller sammenlignelige nok til styring af flere udbydere.

    Anbefaling: Opret udbyderneutrale begrundelsesprofiler

    Definer et lille internt ordforråd, som produktteams kan forstå uden at læse hver udbyders API-reference.For de fleste gateways er fem profiler nok:

    den dybere indsatsden dybere indsats opgaver
    Intern profilFormålTypisk brugPolitikstilling
    ingenDeaktiveretDeaktiveretDeaktiveretDeaktiveret
    Deaktiveretdeaktiveret
    Deaktiveret
    Deaktiveret
    Understøttet ekstraktion, tagging, routingStandard for simple endepunkter i høj volumen
    lavLet begrundelse for beskeden tvetydighedKorte supportsvar, enkle sammenligninger, omskrivningsopgaver bredt
    standardBalanceret ræsonnement for rutinemæssigt vidensarbejdePlanlægning, kodegennemgang, politikanalyse, længere synteseStandard for blandede arbejdsbelastninger
    dybe indsatsFejlretning, matematik, sikkerhedsgennemgang, agentplanlægningBegrænset af lejer, nøgle, arbejdsgang og budget
    capped-deepHøjt ræsonnement med et hårdt loftPremiumomkostninger er uacceptableUacceptable
    and analytics

    Profilen er den ansøgningsorienterede kontrakt. Udbyderparametre bliver adapterdetaljer. Dette holder klientkoden bærbar og giver platformsejere mulighed for at opdatere kortlægninger, efterhånden som udbyder-API'er ændres.

    Kortlæg arbejdsbelastningsklasser før kortlægningsudbydere

    Ræsoneeringsindsatsen bør vælges ud fra arbejdsbyrdes hensigt, ikke ud fra personlige præferencer eller modelpopularitet. Tilføj et gatewayfelt såsom workload_class, enten leveret af klienten eller udledt af en godkendt rutekonfiguration.

    Eksempel på arbejdsbelastningspolitik

    {
  "workload_policies": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "ingen",
      "max_reasoning_profile": "lav",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "ingen",
      "max_reasoning_profile": "lav",
      "max_output_tokens": 300
    },
    "draft_customer_reply": {
      "default_reasoning_profile": "lav",
      "max_reasoning_profile": "standard",
      "max_output_tokens": 1200
    },
    "code_review": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "dyb",
      "max_output_tokens": 4000
    },
    "security_review": {
      "default_reasoning_profile": "dyb",
      "max_reasoning_profile": "deep-dyp",
      "max_output_tokens": 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "dyb",
      "max_output_tokens": 5000
    }
  }
}

    Denne politik gør to nyttige ting. For det første forhindrer det simple endepunkter i at arve dyre standarder. For det andet giver det administratorer en konkret gennemgangsflade: Hvilke arbejdsgange har tilladelse til at anmode om dyb begrundelse, og under hvilke lofter?

    Byg en kompatibilitetsmatrix

    Gateway-adapteren bør opretholde en matrix for hver udbyder og modelfamilie. Gem som minimum, om modellen understøtter deaktivering af ræsonnement, enum-indsats, numerisk budget, dynamisk tænkning, maksimalt understøttet budget og brugsfelter for ræsonnementstokens.

    Eksempel Matrix Shape

    {
  "udbydere": {
    "provider_a": {
      "model_familie_x": {
        "supports_reasoning": sandt,
        "control_type": "indsats_enum",
        "allowed_values": ["ingen", "minimal", "lav", "medium", "høj", "xhøj"],
        "can_disable": sandt,
        "reports_reasoning_tokens": sandt
      }
    },
    "provider_b": {
      "model_family_y": {
        "supports_reasoning": sandt,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_disable": falsk,
        "reports_reasoning_tokens": sandt
      }
    },
    "provider_c": {
      "model_family_z": {
        "supports_reasoning": sandt,
        "control_type": "tænkeniveau",
        "allowed_values": ["minimal", "lav", "medium", "høj"],
        "can_disable": falsk,
        "reports_reasoning_tokens": sandt
      }
    }
  }
}

    En kompatibilitetsmatrix er ikke kun dokumentation for mennesker. Det skal være en eksekverbar politik. Anmodningsrouteren skal bruge den før afsendelse, og faktureringsbogholderen skal bruge den under afregning.

    Oversæt interne profiler til udbyderparametre

    Udbydertilknytninger skal være eksplicitte og versionerede. Stol ikke på en vag sætning som "brug smartere ræsonnement." Gatewayen skal vide nøjagtigt, hvilken udbyderparameter der blev sendt.

    Eksempel på kortlægning

    {
  "reasoning_profile_mappings": {
    "ingen": {
      "effort_enum": "ingen",
      "budget_tokens": 0,
      "thinking_level": "minimal"
    },
    "lav": {
      "effort_enum": "lav",
      "budget_tokens": 2048,
      "thinking_level": "lav"
    },
    "standard": {
      "effort_enum": "medium",
      "budget_tokens": 8192,"thinking_level": "medium"
    },
    "dyb": {
      "effort_enum": "høj",
      "budget_tokens": 20000,
      "thinking_level": "høj"
    },
    "capped-deep": {
      "effort_enum": "høj",
      "budget_tokens": 12000,
      "thinking_level": "høj"
    }
  }
}

    Disse tal er eksempler, ikke universelle standarder. De rigtige budgetter afhænger af modelfamilien, priser, latenskrav og evalueringsresultater. Den vigtige implementeringsdetalje er, at gatewayen ejer kortlægningen og registrerer den løste udbyderparameter for hver anmodning.

    Fejl lukket, når en kortlægning er usikker

    Ikke-understøttede ræsonnementkontroller bør ikke stille blive standardstandarder for udbydere. Standardværdier kan være dyre, og de kan ændre sig over tid.

    Brug et af tre resultater, når en anmodet profil ikke kan kortlægges sikkert:

    • Tillad: udbyderen/modellen understøtter den anmodede profil, og lejerpolitikken tillader det.
    • Downgrade: den anmodede profil , så den højest godkendte profil er ovenfor, gælder, og den godkendte profil er ovenfor. nedgradering.
    • Afvis: Profilen kan ikke repræsenteres sikkert, lejeren kræver streng adfærd, eller nedgradering ville overtræde produktforventningerne.

    Eksempel på beslutningspost

    {
  "request_id": "req_123",
  "tenant_id": "tenant_42",
  "api_key_id": "key_abc",
  "workflow": "code_review",
  "requested_reasoning_profile": "dyb",
  "applied_reasoning_profile": "standard",
  "decision": "nedgraderet",
  "decision_reason": "lejer_månedlige_deep_reasoning_budget_exceeded",
  "served_provider": "provider_a",
  "served_model": "model_familie_x",
  "provider_reasoning_param": {
    "indsats": "medium"
  }
}

    Denne beslutningspost er værdifuld under support, faktureringstvister og kvalitetsundersøgelser. Det forhindrer også usynlige kvalitetsregressioner under budgetpres.

    Budgetkontrol har brug for flere end maks. outputtokens

    En maksimal outputtokengrænse er nødvendig, men den er ikke tilstrækkelig. For modeller, der kan ræsonnere, kan modellen bruge en stor del af grænsen til at ræsonnere og give for lidt plads til det endelige svar. Brugeren kan derefter betale for et ubrugeligt trunkeret svar.

    Brug lagdelte lofter:

    • max_reasoning_profile pr. lejer, API-nøgle og arbejdsgang.
    • max_thinking_budget eller tilsvarende pr. udbyder/modelpar.
    • maks. tæller ræsonnement og synligt output sammen.
    • daily_deep_reasoning_spend pr. lejer eller forhandlerkunde.
    • deep_reasoning_requests_per_hour for højvolumenendepunkter.
    • reasoning_tokenly_ratio_th advarsler.

    Budgettjekket bør ske inden afsendelse. Afregningstrinnet bør derefter afstemme faktisk brug, efter at udbyderens svar ankommer. Hvis udbyderen rapporterer tænke-tokens separat, skal du opbevare dem separat. Hvis den kun rapporterer samlede output-tokens, skal du gemme de bedst tilgængelige normaliserede felter og markere konfidensniveauet.

    Ledger Fields for Reasoning Use

    Analytics skal vise forskellen mellem synlig svarlængde og betalt ræsonnement. En nyttig hovedbogsrække skal indeholde:

Fortsæt med at læse

Relaterede artikler

Se alle artikler →

Kontrolplan-revisionsspor for AI API-gateways: Rekonstruer nøgle-, lejer- og forbrugsændringer under hændelser

Kørselslogfiler forklarer modelkald, men hændelsesrespons afhænger ofte af administratorhistorik: hvem der har oprettet en nøgle, ændret en forbrugsgrænse, promoveret en routingprofil eller tilbagekaldt adgang. Byg et revisionsspor, der kun kan tilføjes, og som forbinder gateway-, Partner API-, identitets-, udbyder- og brugsbegivenheder uden at lagre rå prompter som standard.

Læs artiklen →