Cum să construiți un model de rutare LLM în funcție de costuri fără a sacrifica calitatea

Dirijarea modelului LLM în funcție de costuri nu ar trebui să însemne trimiterea fiecărei solicitări către cel mai ieftin model disponibil. Acest lucru creează un mod de eșec liniștit: facturile se îmbunătățesc timp de câteva săptămâni, apoi echipele de produse descoperă scheme rupte, raționament mai slab, ton inconsecvent sau schițe de sprijin care necesită mai multă curățare umană.

Modelul mai bun este o politică de rutare susținută de eval. Clasificați cererea, definiți calitatea minimă acceptabilă pentru acea sarcină, eliminați rutele care nu pot satisface constrângerile de capacitate sau de guvernare, estimați economia rutei și apoi alegeți modelul eligibil cu cel mai mic cost. Decizia de rutare devine explicabilă în timpul unei analize a costurilor, deoarece este legată de o versiune de politică, nu de preferința dezvoltatorului sau de o vagă prestație a furnizorului.

Ce optimizează rutarea bazată pe costuri

Un router practic se optimizează pentru cea mai ieftină rută care încă îndeplinește cerințele de operare ale sarcinii. Aceasta este diferită de optimizarea pentru cel mai ieftin model.

Fapt: furnizorii importanți de modele publică prețuri pentru token-uri cu dimensiuni separate, cum ar fi indicative de intrare, indicative de intrare stocate în cache, indicative de ieșire, memorarea promptă în cache și procesarea în lot. Unii furnizori expun, de asemenea, câmpuri de utilizare care raportează comportamentul token-ului în cache. Aceasta înseamnă că opțiunea cu cel mai mic cost se poate modifica în funcție de forma promptului, lungimea așteptată a ieșirii, eligibilitatea cache-ului și dacă volumul de lucru poate rula asincron.

Recomandare: tratați rutarea ca o problemă de politică în interiorul unei gateway AI multi-model API, nu ca pe o declarație de comutare la nivel de aplicație. Gateway-ul vede înregistrările privind capacitatea furnizorului, regulile chiriașilor, API metadatele cheie, tabelele de prețuri, telemetria de utilizare și comportamentul alternativ într-un singur loc.

Predicție: echipele care păstrează logica de rutare împrăștiată în depozitele de aplicații se vor strădui să explice mai târziu modificările costurilor. Ei pot reduce în continuare cheltuielile, dar vor avea dovezi mai slabe pentru ce o anumită solicitare a folosit un anumit model.

Începeți cu clase de activități, nu cu numele furnizorilor

Routerul are nevoie de o etichetă de sarcină de lucru înainte de a putea lua o decizie utilă. Un singur model implicit nu poate reprezenta profilul de risc al fiecărei solicitări.

Clasele de sarcini utile includ:

• Extragere: convertiți textul nestructurat în câmpuri, adesea cu o validare strictă a schemei.
• Clasificare: atribuiți etichete, prioritate, intenție, sentiment sau categorii de rutare.
• Rezumat: comprimați introducerea lungă, păstrând în același timp faptele și deciziile cheie.
• Elaborare de asistență pentru clienți: generează un răspuns pe care un om îl poate examina sau trimite.
• Sinteza răspunsurilor RAG: răspuns din contextul preluat cu cerințe de citare sau de fundamentare.
• Examinare cod: inspectați diferențele sau fișierele sursă pentru corectitudine, risc sau probleme de stil.
• Analiză în context lung: motive privind contractele, transcrierile, jurnalele, politicile sau pachetele de cercetare.
• Asistență pentru decizii cu impact mare: orice flux de lucru în care un răspuns prost ar putea afecta banii, conformitatea, siguranța sau încrederea clienților.

Clasa de sarcini poate proveni din metadate de solicitare explicită, o sferă de cheie API, o rută de aplicație sau un clasificator ușor. Metadatele explicite sunt de obicei mai bune decât deducerea intenției din textul promptului, deoarece solicitările vagi forțează routerul spre valori implicite conservatoare.

Atașați un nivel de calitate la fiecare sarcină

Rutarea în funcție de costuri funcționează numai dacă fiecare sarcină are un nivel de calitate. Fără unul, routerul nu are o modalitate de a respinge un model mai ieftin.

Un etaj de calitate poate include mai multe verificări:

• Set de evaluare rejudabilă: exemple reprezentative din dezvoltare și producție, fără date sensibile acolo unde este necesar.
• Validitatea schemei: ieșirea trebuie să analizeze, să se valideze în raport cu schema canonică și să evite câmpurile neacceptate.
• Criterii de conținut: răspunsul trebuie să respecte regulile de stil, refuz, fundamentare și exhaustivitate pentru sarcină.
• Criterii de siguranță: ieșirea nu trebuie să scurgă instrucțiuni ascunse, să ignore limitele politicii sau să execute instrucțiuni care nu sunt de încredere din conținutul preluat.
• Evaluare umană: necesară pentru fluxuri de lucru cu impact ridicat sau pentru promovarea unui nou traseu.
• Pragul de regresie: traseul candidat trebuie să îndeplinească sau să depășească traseul curent pentru categoriile critice de eșec, nu doar scor mediu.

Realitate: documentația furnizorului descrie evaluările ca o modalitate de a testa rezultatele modelului în funcție de conținutul și criteriile de stil specificate. Un produs de evaluare găzduit este programat pentru depreciere, astfel încât sistemele de rutare ar trebui să stocheze seturi de date de evaluare neutre pentru furnizor, rezultate așteptate, rubrici de evaluare și rezultate, în loc să depindă de o suprafață de evaluare găzduită de furnizor.

Recomandare: stocați rezultatele evaluării în funcție de clasa de activitate, model, versiunea adaptorului furnizorului, versiunea promptă, versiunea schemei și versiunea de evaluare. O rută nu ar trebui să devină eligibilă doar pentru că un model este nou sau mai ieftin. Devine eligibil atunci când depășește poarta actuală de calitate a sarcinii.

Construiți un registru al capacității furnizorului

Înainte de a estima costul, eliminați orice rută care nu poate satisface solicitarea. Acest pas împiedică routerul să aleagă un model ieftin care nu are capabilitățile necesare.

O înregistrare a capacității trebuie să includă:

• Modalități de intrare și de ieșire acceptate.
• Limite ferestrelor de context.
• Ieșire structurată și asistență pentru apelarea instrumentelor.
• Asistență pentru streaming.
• Asistență promptă pentru stocarea în cache și disponibilitatea telemetriei în cache.
• Asistență pentru lotul API.
• Opțiuni de procesare regională.
• Termenii privind păstrarea datelor și monitorizarea abuzului care contează pentru politica dvs.
• Dimensiunile limitei ratei și capacitatea actuală.
• Diferențe de contract de ieșire cunoscute în stratul adaptorului.

Acest registru trebuie menținut separat de solicitările aplicației. Acesta aparține nivelului de rutare și adaptor al furnizorului, unde sistemul poate compara modele fără a introduce ipoteze specifice furnizorului în fiecare aplicație.

Estimați costul rutei înainte de selecție

Routerul nu poate cunoaște costul final înainte de execuție, dar poate estima suficient de bine pentru a alege dintre rutele eligibile. Estimarea ar trebui să includă variabilele care mută de fapt factura.

estimated_cost =
  input_tokens * input_token_price
  + cached_input_tokens * cached_input_token_price
  + output_tokens_expected * output_token_price
  + tool_call_overhead_expected
  + retry_allowance_expected
  - batch_discount_if_eligible

Utilizați telemetria recentă pentru a estima jetoanele de ieșire în funcție de clasa de activitate. De exemplu, sarcinile de extracție pot avea o lungime de ieșire limitată, în timp ce analiza contextului lung poate varia foarte mult. Agenții care utilizează instrumente pot avea costuri ascunse suplimentare din planificarea apelurilor instrumentelor, reîncercări și mesaje intermediare.

Estimarea costurilor ar trebui să țină cont și de eligibilitatea memoriei cache și a loturilor:

• Eligibilitatea memoriei cache: prefix de prompter stabil, instrucțiuni de sistem reutilizabile, context preluat repetat, comportament acceptat al furnizorului și probabilitate suficientă de accesare a memoriei cache.
• Eligibilitatea lotului: volumul de lucru poate aștepta, are o gestionare a cererilor idempotent, are urmărire durabilă a joburilor și nu are nevoie de streaming interactiv.
• Risc cu simbolul de ieșire: modelul tinde să producă răspunsuri mai lungi sau mai scurte pentru aceeași sarcină, iar trunchierea ar dăuna calității.
• Risc de reîncercare: furnizorul sau modelul are rate ridicate de eroare, rate de reparare a schemei sau eșecuri de latență pentru această sarcină.

Aici este locul în care rutarea costurilor se conectează la gestionarea costurilor LLM mai amplă. Numai tabelul de prețuri nu este suficient. Routerul are nevoie de metadate de solicitare, structură promptă, măsurători ale accesului în cache și date de utilizare stabilite pentru a ști dacă economiile așteptate au avut loc într-adevăr.

Folosiți niveluri de model în loc de o valoare globală implicită

O politică pe niveluri este mai ușor de explicat decât o listă mare de excepții specifice furnizorului. Fiecare nivel trebuie să conțină unul sau mai multe modele eligibile care au depășit porți specifice sarcinii.

Nu lăsați nivelul să înlocuiască evalurile. Un model poate fi economic pentru clasificare, dar nepotrivit pentru redactarea suport. Un alt model poate fi puternic pentru rezumat, dar prea scump pentru etichetarea deterministă scurtă.

Rută cu o secvență de decizie explicită

Un router care ține seama de costuri ar trebui să fie suficient de determinist pentru a putea depana. Implementarea exactă variază, dar secvența de decizie ar trebui să fie stabilă.

1. Citiți metadatele locatarului, API cheii, mediului și aplicației.
2. Identificați clasa de sarcini din metadatele explicite sau din rezultatul clasificatorului.
3. Încărcați versiunea politicii de rutare pentru acel locatar sau spațiu de lucru.
4. Aplicați constrângeri de guvernare, cum ar fi păstrarea datelor, regiune, lista de modele permise și restricții pentru funcții.
5. Filtrați după capabilitățile necesare: lungimea contextului, instrumente, ieșire structurată, streaming, modalitate și compatibilitate cu lot.
6. Filtrați după nivelul de calitate susținut de eval pentru clasa de activități.
7. Estimați costul utilizând indicative de intrare, indicative de ieșire așteptate, eligibilitatea pentru cache, eligibilitatea lotului și riscul de reîncercare.
8. Aplicați politica bugetară și preferințele chiriașilor.
9. Selectați ruta eligibilă cu cel mai mic cost.
10. Atașați rută de rezervă, timeout, reîncercați și politica de reparare.
11. Înregistrați decizia cu un cod motiv stabil.

În pseudocod, routerul ar trebui să arate mai mult ca o evaluare a politicii decât cu o preferință codificată a furnizorului:

function selectRoute(request):
  context = buildRoutingContext(request)
  task = classifyTask(context)
  policy = loadPolicy(context.tenant_id, task)

  candidates = modelRegistry.models
    .filter(model => policy.allows(model))
    .filter(model => model.supports(context.required_capabilities))
    .filter(model => evalStore.passes(task, model, policy.quality_floor))

  priced = candidates.map(model => ({
    model,
    estimated_cost: estimateCost(model, context),
    expected_latency: estimateLatency(model, context),
    risk_flags: estimateRisk(model, context)
  }))

  eligible = priced.filter(route => route.risk_flags.noneBlocking())
  return minBy(eligible, route => route.estimated_cost)

Înregistrați fiecare decizie de rutare

Dacă finanțele întreabă de ce a fost folosit un model premium sau dacă ingineria întreabă de ce a scăzut calitatea, routerul ar trebui să răspundă din jurnale. Nu vă bazați pe reconstruirea intenției din solicitări după fapt.

Înregistrați aceste câmpuri pentru fiecare solicitare:

• ID cerere, ID chiriaș, API ID cheie, ID aplicație și mediu.
• Rezultatul și încrederea clasificatorului de sarcini.
• Versiunea politicii de rutare.
• Versiunea setului de date de evaluare și poarta de calitate utilizate.
• Modele eligibile și modele respinse.
• Motivul pentru care fiecare model respins a fost exclus.
• Intrare estimată, introducere în cache și indicative de ieșire.
• Costul estimat al rutei și costul final decontat atunci când sunt disponibile.
• Furnizorul, modelul, versiunea adaptorului și nivelul selectat.
• Politica privind traseul alternativ și reîncercarea.
• Telemetria de accesare sau ratare în cache atunci când este disponibilă.
• Mod de execuție lot versus sincron.
• Validarea schemei, încercările de reparare, starea refuzului și semnalizatoarele de siguranță.

Aceste jurnaluri acceptă, de asemenea, LLM API atribuirea costurilor, deoarece selecția modelului este doar o parte din cheltuieli. Echipele trebuie în continuare să aloce costurile în funcție de chiriaș, spațiu de lucru, cheie, produs, flux de lucru sau client.

Adăugați comenzi de deriva înainte de a promova rute mai ieftine

Se modifică comportamentul modelului, prețurile, solicitările și mixul volumului de lucru. O rută care a fost sigură luna trecută poate deveni slabă după o revizuire rapidă sau o actualizare a modelului.

O buclă de control de bază a derivei ar trebui să includă:

• Eșantion de cereri de producție recente în funcție de clasa de activități.
• Eliminați sau transformați datele sensibile conform politicii.
• Redați mostre prin rutele actuale și candidate.
• Comparați calitatea, validitatea schemei, comportamentul de refuz, costul și latența.
• Examinați eșecurile în funcție de categorie, nu doar scorul agregat.
• Promovați ruta mai ieftină numai dacă îndeplinește limita de calitate și constrângerile operaționale.
• Canary noua rută pentru un procent mic din trafic.
• Revenire automat la eșecul schemei, depășirea costurilor, încălcarea latenței sau escaladarea analizei umane.

Recomandare: faceți din promovarea rutei un eveniment de gestionare a schimbării. Înregistrați cine l-a aprobat, ce setare de evaluare a trecut, ce procent de trafic afectează, când expiră sau trebuie revizuit și cum funcționează rollback.

Oferiți echipelor înlocuiri, dar faceți-le să expire

Există motive legitime pentru a anula rutarea: incident de furnizor, urgență bugetară, evaluarea conformității, escaladarea clienților sau regresia unui model. Problema nu este anularea. Problema este o modificare care devine o politică permanentă invizibilă.

Fiecare înlocuire ar trebui să includă:

• Domeniu: chiriaș, aplicație, API cheie, clasă de activități, model, furnizor sau regiune.
• Motiv: incident, buget, calitate, conformitate, latență sau cererea clientului.
• Aprobator.
• Ora de începere și ora de expirare.
• Impactul așteptat asupra costului, latenței și calității.
• Condiție de retragere.

Închiderile expirate ar trebui să eșueze în conformitate cu politica normală de rutare sau să necesite reînnoire. Acest lucru împiedică deciziile de urgență să devină riscuri ascunse de cost sau calitate.

Compartimente de făcut explicit

Rutarea în funcție de costuri are costuri operaționale reale. Încă merită făcut atunci când cheltuielile LLM sunt semnificative, dar compromisurile ar trebui să fie vizibile.

• Dependența de metadate: calitatea rutei depinde de etichetele precise ale sarcinilor și de metadatele sarcinii de lucru. Etichetele lipsă împing traficul către valori implicite conservatoare.
• Întreținerea evaluării: evaluările sarcinilor necesită actualizări pe măsură ce solicitările, produsele și comportamentul utilizatorului se modifică.
• Complexitatea furnizorului: reducerile în cache și în loturi pot îmbunătăți economia, dar fac logica de rutare mai complexă.
• Risc de portabilitate: caracteristicile specifice furnizorului ar trebui să apară în adaptoare și înregistrările de capabilități, nu în codul produsului.
• Incertitudinea estimării: lungimea finală a ieșirii, apelurile de instrumente, reîncercările și accesările în cache nu sunt pe deplin cunoscute înainte de execuție.
• Povara de explicabilitate: optimizarea agresivă poate face comportamentul produsului greu de explicat, cu excepția cazului în care fiecare decizie este înregistrată cu versiunea politicii și codurile motiv.

Lista de verificare pentru implementare

• Definiți clasele de activități pentru cele mai importante fluxuri de lucru LLM în funcție de cheltuieli și impactul asupra afacerii.
• Creați seturi de evaluare și etaje de calitate pentru fiecare clasă de activități.
• Construiți un registru de capabilități de furnizor și model.
• Stocați tabelele de prețuri actuale și modificatorii de prețuri în funcție de furnizor, model și modul de execuție.
• Estimați indicativele de intrare, indicativele de ieșire așteptate, eligibilitatea pentru cache, eligibilitatea lotului și riscul de reîncercare.
• Filtrați candidații după constrângerile de guvernare înainte de optimizarea costurilor.
• Selectați modelul cu cel mai mic cost numai după ce trec porțile de capacitate și calitate.
• Înregistrați rutele selectate și respinse cu coduri motiv.
• Comparați costul estimat cu datele de utilizare și facturi stabilite.
• Executați evaluări periodice de reluare înainte de a promova rute mai ieftine.
• Modificări ale traseului Canary și definiți declanșatoarele de retragere.
• Solicită date de expirare pentru anulări manuale.

Concluzie

Obiectivul practic nu este direcționarea fiecărei solicitări către un model mai ieftin. Scopul este de a nu mai plăti în exces pentru munca de rutină, protejând în același timp calitatea, contractele, regulile de guvernare și explicabilitatea.

Construiți routerul în funcție de clase de activități, niveluri de calitate, capabilități ale furnizorului, estimări ale costurilor și jurnalele de politici. Apoi alegeți ruta eligibilă cu cel mai mic cost. Acel singur cuvânt, eligibil, este cel care separă rutarea în funcție de costuri de rutarea modelului cel mai ieftin.

Lectură asociată

• limitele de cheltuieli la nivel de gateway