Enrutament d'esforç de raonament en una passarel·la de l'API d'IA: controleu els testimonis de pensament, la latència i el cost entre els proveïdors

La profunditat de raonament ja no és una opció de model senzilla. Alguns proveïdors exposen nivells d'esforç d'estil enumeració. Altres exposen pressupostos simbòlics, pensament dinàmic o famílies model on el pensament no es pot desactivar completament. La resposta visible pot ser curta mentre el raonament ocult consumeix fitxes de sortida facturables. Si cada equip d'aplicacions estableix aquests controls directament, el cost, la latència i la qualitat es tornen difícils d'explicar.

La resposta pràctica és traslladar el control de raonament i esforç a la passarel·la de l'API. La passarel·la hauria de classificar la càrrega de treball, mapejar-la a un control de raonament específic del proveïdor, fer complir els pressupostos dels inquilins, registrar l'ús real del raonament i fer que les decisions de rebaixa siguin visibles a l'anàlisi. L'identificador de model, el nivell de servei, la producció màxima i la profunditat del raonament haurien de ser dimensions de política separades.

Problema del lector: les sol·licituds senzilles paguen per un raonament profund

Els equips que adopten models capaços de raonament solen començar amb un objectiu raonable: millorar la qualitat de les tasques difícils. El problema apareix més tard, quan es reutilitzen els mateixos valors per defecte per a l'extracció, resums breus, format i classificació. Aquestes sol·licituds no necessiten costosos càlculs de temps de prova, però encara poden desencadenar-lo.

Això crea tres errors operatius:

• Opacitat del cost: l'usuari veu una resposta breu, però el llibre major conté fitxes de raonament ocults o equivalents específics del proveïdor.
• La interacció esdevé un flux de treball lent:
• . perquè l'esforç de raonament va augmentar darrere del mateix àlies de model.
• Fragmentació de la política: cada equip de producte aprèn diferents paràmetres de proveïdor i aplica límits diferents.

Una política de raonament a nivell de passarel·la resol el problema de control abans que es converteixi en un problema de facturació.

Fets: els controls de raonament del proveïdor no són equivalents a la realitat

{
  "workload_policies": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "cap",
      "max_reasoning_profile": "baix",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "cap",
      "max_reasoning_profile": "baix",
      "max_output_tokens": 300
    },
    "draft_customer_reply": {
      "default_reasoning_profile": "baix",
      "max_reasoning_profile": "estàndard",
      "max_output_tokens": 1200
    },
    "code_review": {
      "default_reasoning_profile": "estàndard",
      "max_reasoning_profile": "profund",
      "max_output_tokens": 4000
    },
    "security_review": {
      "default_reasoning_profile": "profund",
      "max_reasoning_profile": "capped-deep",
      "max_output_tokens": 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "estàndard",
      "max_reasoning_profile": "profund",
      "max_output_tokens": 5000
    }
  }
}

{
  "proveïdors": {
    "proveïdor_a": {
      "model_family_x": {
        "supports_reasoning": cert,
        "control_type": "effort_enum",
        "allowed_values": ["cap", "mínim", "baix", "mitjà", "alt", "xalt"],
        "can_disable": cert,
        "reports_reasoning_tokens": cert
      }
    },
    "proveïdor_b": {
      "model_family_y": {
        "supports_reasoning": cert,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_disable": fals,
        "reports_reasoning_tokens": cert
      }
    },
    "proveïdor_c": {
      "model_family_z": {
        "supports_reasoning": cert,
        "control_type": "nivell_pensament",
        "allowed_values": ["mínim", "baix", "mitjà", "alt"],
        "can_disable": fals,
        "reports_reasoning_tokens": cert
      }
    }
  }
}

{
  "reasoning_profile_mappings": {
    "cap": {
      "effort_enum": "cap",
      "budget_tokens": 0,
      "thinking_level": "mínim"
    },
    "baix": {
      "effort_enum": "baix",
      "budget_tokens": 2048,
      "thinking_level": "baix"
    },
    "estàndard": {
      "effort_enum": "mitjà",
      "budget_tokens": 8192,"thinking_level": "mitjà"
    },
    "profund": {
      "effort_enum": "alt",
      "budget_tokens": 20000,
      "thinking_level": "alt"
    },
    "capped-deep": {
      "effort_enum": "alt",
      "budget_tokens": 12000,
      "thinking_level": "alt"
    }
  }
}

{
  "request_id": "req_123",
  "tenant_id": "tenant_42",
  "api_key_id": "key_abc",
  "workflow": "code_review",
  "requested_reasoning_profile": "profund",
  "applied_reasoning_profile": "estàndard",
  "decision": "rebaixat",
  "decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "proveïdor_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "esforç": "mitjà"
  }
}

• max_reasoning_profile per inquilí, clau d'API i flux de treball.
• max_thinking_budget o equivalent per parell de proveïdor/model.
>per generar un total de màx. el proveïdor compta el raonament i la sortida visible junts.
• daily_deep_reasoning_spend per llogater o client distribuïdor.
• deep_reasoning_requests_per_hour per a punts finals de gran volum.
• reasoning_token_reasoning_spend.
• comprovar el pressupost de raonament. hauria de passar abans de l'enviament. El pas de liquidació hauria de conciliar l'ús real després que arribi la resposta del proveïdor. Si el proveïdor informa de fitxes de pensament per separat, emmagatzemeu-les per separat. Si només informa dels testimonis de sortida totals, emmagatzemeu els millors camps normalitzats disponibles i marqueu el nivell de confiança.

  Camps del llibre major per a raonar l'ús

  L'anàlisi ha de mostrar la diferència entre la longitud de resposta visible i l'esforç de raonament pagat. Una fila de registre útil hauria d'incloure:

  • tenant_id, api_key_id, end_user_id i workflow.
  • requested_model, served_model, proveïdor i model àlies.
  • requested_reasoning_profile i applied_reasoning_profile.
  • provider_reasoning_param, emmagatzemats com a JSON estructurat.
  • input_tokens, visible_coderesoning_tokens_or_equivalent, cached_tokens i total_billable_tokens.
  • max_output_tokens i qualsevol pressupost de pensament específic del proveïdor.
  • latency_to_first_token>, ms_token>_>m_codes estat de finalització del flux.
  • estimated_cost_before_dispatch, reserved_budget, settled_cost i reconciliation_status.
  • policy_decision, com ara permesos, rebaixats, rebutjats, rebutjats, rebaixats, rebutjats >

    reconciliats cadena de pensament per defecte. Per a la majoria de treballs de govern i FinOps, els recomptes i les decisions polítiques són suficients. L'emmagatzematge de text de raonament sensible pot crear problemes de privadesa, de compliment i de retenció evitables.

    Flux d'implementació

    Una passarel·la de producció pot implementar l'encaminament de l'esforç de raonament com a canal de sol·licitud determinista.

    1. Autentiqueu la sol·licitud. Resoldre l'arrendatari, la clau API, l'usuari, l'equip i el flux de treball.Classificar el flux de treball. camp de client explícit quan sigui possible.Per als punts finals coneguts, enllaceu la classe de càrrega de treball a la configuració de la ruta.
    2. Política de càrrega. Combina les restriccions globals, d'inquilí, de clau i de flux de treball.
    3. Seleccioneu els models candidats. Utilitzeu l'àlies de model existent o la política de selecció de models abans de resoldre els controls de raonament.
    4. Resol el perfil de raonament predeterminat sol·licitat i, a continuació, apliqueu el perfil de raonament sol·licitat. màxims.
    5. Comproveu la compatibilitat. Confirmeu que el parell proveïdor/model admet el perfil seleccionat de manera segura.
    6. Estimeu el cost i el pressupost de reserva. Incloeu l'ús de raonament probable, no només la sortida visible.
    7. Enviament amb paràmetres natius del proveïdor. Envieu l'esforç d'enumeració, el nivell de control del pressupost, o els testimonis sense raonament o sense raonament. adaptador.
    8. Normalitzeu l'ús a la resposta. Separeu l'entrada, la sortida visible, el raonament, la memòria cau, l'eina i els testimonis totals sempre que sigui possible.
    9. Ajusteu i alerta. Reconcilieu el cost reservat i real, actualitzeu les quotes i emeteu senyals d'anomalia.

    Aquesta canalització de control es manté raonable. També ofereix als equips de la plataforma un lloc únic per canviar els valors predeterminats quan evolucionen les API del proveïdor.

    Avaluació abans de canviar els valors predeterminats

    No promogueu un esforç de raonament més elevat basat només en uns quants exemples impressionants. Executeu avaluacions abans de canviar els valors predeterminats d'una classe de càrrega de treball.

    Mesureu almenys quatre resultats:

    • Qualitat de la tasca: precisió, acceptació del revisor, validesa de l'esquema o èxit de la trucada d'eines.
    • Latència: temps fins al primer testimoni i temps total de finalització.
    • Cost per sol·licitud acceptada:
    • Cost per sol·licitud. resposta.
    • Modes d'error: truncament, denegació, sortida amb format incorrecte, trucades excessives a l'eina o temps d'espera.

    La mètrica clau no és "tokens per sol·licitud". Una resposta de testimoni més baix que falla la validació pot ser més cara després de reintents. Una resposta més raonada pot estar justificada per a la revisió de seguretat, però és un malbaratament per etiquetar entrades. Avaluar per flux de treball.

    Compartiments

    El raonament de la governança afegeix control, però no és gratuït.

    • Portabilitat versus característiques del proveïdor: els perfils interns mantenen el codi de l'aplicació portàtil, però els equips avançats poden necessitar una escotilla d'escapament aprovada per als controls específics del proveïdor.
    • protegeixen la qualitat contra la qualitat.
    • . de la despesa descontrolada, però els límits massa ajustats poden truncar les respostes útils després de gastar-se els testimonis de raonament.
    • Pensament dinàmic versus predictibilitat: els controls dinàmics dels proveïdors poden millorar la comoditat, però debiliten les estimacions de costos prèvies a l'enviament tret que la passarel·la enregistri l'ús real i faci complir els límits de la liquidació: limitació de disponibilitat. Rebaixar el raonament durant la pressió pressupostària preserva la disponibilitat, però la resposta s'ha d'etiquetar a la telemetria i incloure-la a l'avaluació de la qualitat.
    • Anàlisi versus privadesa: les mètriques de testimoni de raonament són útils, però els rastres de raonament en brut no s'han d'emmagatzemar tret que hi hagi una política de retenció deliberada i aprovada.

    Política de Predicció: Reasoning. Control

    Aquesta és una predicció, no un fet verificat: l'esforç de raonament es convertirà en un control de producció normal juntament amb l'encaminament del model, els límits de tarifes, els nivells de servei i els pressupostos de testimonis. A mesura que els proveïdors continuïn exposant diferents controls de pensament, els equips d'aplicacions tindran menys ganes de codificar aquestes diferències al codi del producte.

    Les passarel·les que tracten el raonament com una dimensió de temps d'execució governada tindran una facturació més clara dels inquilins, una portabilitat més neta i un millor control de la latència.Les passarel·les que el tracten com un paràmetre de model incident tindran dificultats per explicar per què les respostes curtes de vegades costen més que les llargues.

    Llista de verificació accionable

    • Definiu perfils interns: cap, low, estàndard, deep i deep i deepa màxim. perfils a cada classe de càrrega de treball.
    • Creeu una matriu de compatibilitat de proveïdors/models per als controls de raonament.
    • Tradueix els perfils a paràmetres natius del proveïdor a la capa d'adaptador.
    • Error tancat quan un perfil sol·licitat no es pot assignar de manera segura.
    • Reserveu el pressupost abans de l'enviament utilitzant el perfil de raonament, els paràmetres aplicats, els paràmetres sol·licitats, la sol·licitud de registre, la sol·licitud de paràmetres. ús, sortida visible, latència i cost.
    • Afegiu alertes d'anomalia per a altes proporcions de testimonis de raonament i raonament profund en fluxos de treball senzills de gran volum.
    • Executeu avaluacions a nivell de flux de treball abans de canviar l'esforç predeterminat.
    • Eviteu registrar el text de raonament en brut de manera predeterminada; En lloc d'això, emmagatzemen els recomptes i les decisions polítiques.

    Conclusió

    Els models amb capacitat de raonament són útils perquè poden gastar més càlcul en problemes difícils. Aquesta mateixa capacitat es fa cara quan s'aplica indistintament. La passarel·la ha de decidir quan es permet un raonament més profund, com s'assigna a cada proveïdor, quant pressupost pot consumir i com es mesura el resultat.

    El patró durador és separar l'esforç de raonament de l'identificador del model. Ruta per càrrega de treball, política de límit per inquilí, adapta per proveïdor i estableix l'ús real al llibre major. Això converteix el raonament d'una variable de cost oculta en una superfície de control explícita per al control de costos de l'API de l'IA.

    Lectura relacionada

    • Llibre de facturació que es reserva i es reserva
    href="https://model-gate.com/en/blog/internal-model-aliases-ai-api-gateway-pin-provider-versions-21/">àlies de model intern i contractes de capacitat