Ako vytvoriť smerovanie modelu LLM s ohľadom na náklady bez obetovania kvality

Smerovanie modelu LLM s ohľadom na náklady by nemalo znamenať odoslanie každej požiadavky na najlacnejší dostupný model. To vytvára tichý režim zlyhania: faktúry sa niekoľko týždňov zlepšujú, potom produktové tímy objavia nefunkčné schémy, slabšie uvažovanie, nekonzistentný tón alebo podporné koncepty, ktoré vyžadujú viac ľudského čistenia.

Lepším vzorom je politika smerovania podporovaná eval. Klasifikujte požiadavku, definujte minimálnu prijateľnú kvalitu pre danú úlohu, odstráňte trasy, ktoré nemôžu spĺňať obmedzenia spôsobilosti alebo riadenia, odhadnite ekonomiku trasy a potom vyberte model s najnižšími nákladmi. Rozhodnutie o smerovaní sa dá vysvetliť počas kontroly nákladov, pretože je spojené s verziou pravidiel, nie s preferenciou vývojára alebo vágnym predvoleným nastavením poskytovateľa.

Čo optimalizuje smerovanie s ohľadom na náklady

Praktický smerovač sa optimalizuje pre najlacnejšiu trasu, ktorá stále spĺňa prevádzkové požiadavky úlohy. To sa líši od optimalizácie pre najlacnejší model.

Fakty: hlavní poskytovatelia modelov zverejňujú ceny tokenov so samostatnými dimenziami, ako sú vstupné tokeny, vstupné tokeny uložené vo vyrovnávacej pamäti, výstupné tokeny, rýchle ukladanie do vyrovnávacej pamäte a dávkové spracovanie. Niektorí poskytovatelia tiež odhaľujú polia použitia, ktoré hlásia správanie tokenov uložených vo vyrovnávacej pamäti. To znamená, že možnosť s najnižšou cenou sa môže zmeniť na základe tvaru výzvy, očakávanej dĺžky výstupu, vhodnosti vyrovnávacej pamäte a toho, či môže pracovné zaťaženie prebiehať asynchrónne.

Odporúčanie: považovať smerovanie za problém politiky v rámci multimodelovej brány AI API, nie ako príkaz na prepnutie na úrovni aplikácie. Brána vidí na jednom mieste záznamy o funkciách poskytovateľa, pravidlá nájomníkov, API kľúčové metadáta, cenové tabuľky, telemetriu využitia a záložné správanie.

Predpoveď: Tímy, ktoré majú logiku smerovania roztrúsenú po archívoch aplikácií, budú mať neskôr problémy s vysvetlením zmien nákladov. Stále môžu znížiť výdavky, ale budú mať slabšie dôkazy o tom, prečo daná žiadosť používala daný model.

Začnite triedami úloh, nie názvami poskytovateľov

Smerovač potrebuje označenie pracovného zaťaženia, aby mohol urobiť užitočné rozhodnutie. Jeden predvolený model nemôže predstavovať rizikový profil každej žiadosti.

Triedy užitočných úloh zahŕňajú:

• Extrakcia: konvertuje neštruktúrovaný text na polia, často s prísnym overením schémy.
• Klasifikácia: priraďte kategórie štítkov, priority, zámeru, sentimentu alebo smerovania.
• Zhrnutie: komprimovať dlhý vstup pri zachovaní kľúčových faktov a rozhodnutí.
• Koncept zákazníckej podpory: vygenerujte odpoveď, ktorú môže človek skontrolovať alebo odoslať.
• Syntéza odpovedí RAG: odpoveď z načítaného kontextu s požiadavkami na citáciu alebo uzemnenie.
• Kontrola kódu: skontrolujte rozdiely alebo zdrojové súbory z hľadiska správnosti, rizika alebo problémov so štýlom.
• Analýza dlhodobého kontextu: dôvod nad zmluvami, prepismi, protokolmi, pravidlami alebo výskumnými balíkmi.
• Podpora rozhodovania s vysokým dopadom: akýkoľvek pracovný postup, pri ktorom by zlá odpoveď mohla ovplyvniť peniaze, dodržiavanie predpisov, bezpečnosť alebo dôveru zákazníkov.

Trieda úlohy môže pochádzať z metadát explicitnej požiadavky, rozsahu kľúča API, trasy aplikácie alebo zjednodušeného klasifikátora. Explicitné metadáta sú zvyčajne lepšie ako odvodzovanie zámeru z textu výzvy, pretože vágne výzvy nútia smerovač ku konzervatívnym predvoleným nastaveniam.

Pripojte ku každej úlohe úroveň kvality

Smerovanie s ohľadom na náklady funguje iba vtedy, ak má každá úloha minimálnu úroveň kvality. Bez neho nemá smerovač žiadny zásadný spôsob, ako odmietnuť lacnejší model.

Podmienka kvality môže zahŕňať niekoľko kontrol:

• Replayable eval set: reprezentatívne príklady z vývoja a výroby, v prípade potreby zbavené citlivých údajov.
• Platnosť schémy: výstup musí analyzovať, overiť podľa kanonickej schémy a vyhnúť sa nepodporovaným poliam.
• Kritériá obsahu: odpoveď musí spĺňať pravidlá štýlu, odmietnutia, uzemnenia a úplnosti úlohy.
• Bezpečnostné kritériá: výstup nesmie prepúšťať skryté pokyny, ignorovať hranice pravidiel ani vykonávať nedôveryhodné pokyny z načítaného obsahu.
• Hodnotenie človekom: vyžaduje sa pri vysokoúčinných pracovných postupoch alebo pri propagácii novej trasy.
• Hranica regresie: kandidátska trasa musí spĺňať alebo prekročiť aktuálnu trasu v kategóriách kritických porúch, nielen priemerné skóre.

Fact: Dokumentácia poskytovateľa popisuje hodnotenia ako spôsob testovania výstupov modelu podľa špecifikovaných kritérií obsahu a štýlu. U jedného hosťovaného eval produktu je naplánované ukončenie podpory, takže smerovacie systémy by mali uchovávať množiny údajov eval neutrálne voči poskytovateľovi, očakávané výstupy, hodnotiace rubriky a výsledky, a nie závisieť od jedného eval hostovaného poskytovateľom.

Odporúčanie: ukladať výsledky eval podľa triedy úlohy, modelu, verzie adaptéra poskytovateľa, verzie výzvy, verzie schémy a verzie eval. Trasa by sa nemala stať oprávnenou jednoducho preto, že model je nový alebo lacnejší. Spĺňa podmienky, keď prejde aktuálnou bránou kvality úlohy.

Vybudovanie registra spôsobilosti poskytovateľa

Pred odhadnutím nákladov odstráňte akúkoľvek trasu, ktorá nemôže uspokojiť požiadavku. Tento krok zabráni smerovaču vybrať lacný model, ktorý nemá požadované funkcie.

Záznam spôsobilosti by mal obsahovať:

• Podporované vstupné a výstupné modality.
• Obmedzenia kontextového okna.
• Podpora štruktúrovaného výstupu a volania nástrojov.
• Podpora streamovania.
• Podpora rýchleho ukladania do vyrovnávacej pamäte a dostupnosť telemetrie vyrovnávacej pamäte.
• Podpora API dávky.
• Možnosti regionálneho spracovania.
• Podmienky uchovávania údajov a monitorovania zneužitia, ktoré sú dôležité pre vaše pravidlá.
• Dimenzie limitu sadzby a aktuálna kapacita.
• Známe rozdiely v zmluve o výstupe vo vrstve adaptéra.

Tento register by sa mal udržiavať oddelene od výziev aplikácie. Patrí do vrstvy smerovania a adaptéra poskytovateľa, kde systém môže porovnávať modely bez úniku predpokladov špecifických pre poskytovateľa do každej aplikácie.

Odhadnúť cenu trasy pred výberom

Smerovač nemôže poznať konečnú cenu pred spustením, ale dokáže dostatočne dobre odhadnúť, aby si mohol vybrať spomedzi vhodných trás. Odhad by mal zahŕňať premenné, ktoré skutočne pohybujú faktúrou.

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

Použite nedávnu telemetriu na odhadnutie výstupných tokenov podľa triedy úloh. Napríklad extrakčné úlohy môžu mať obmedzenú výstupnú dĺžku, zatiaľ čo analýza dlhého kontextu sa môže značne líšiť. Agenti používajúci nástroje môžu mať dodatočné skryté náklady na plánovanie volania nástroja, opakované pokusy a prechodné správy.

Odhad nákladov by mal zohľadňovať aj vhodnosť vyrovnávacej pamäte a dávky:

• Vhodnosť vyrovnávacej pamäte: stabilná predpona výzvy, opakovane použiteľné systémové pokyny, opakovane načítaný kontext, podporované správanie poskytovateľa a dostatočná pravdepodobnosť prístupu do vyrovnávacej pamäte.
• Vhodnosť dávky: pracovné zaťaženie môže počkať, má idempotentné spracovanie požiadaviek, trvalé sledovanie úloh a nepotrebuje interaktívne streamovanie.
• Riziko tokenu výstupu: model má tendenciu produkovať dlhšie alebo kratšie odpovede na rovnakú úlohu a skrátenie by poškodilo kvalitu.
• Riziko opätovného pokusu: poskytovateľ alebo model má pre túto úlohu zvýšenú chybovosť, mieru opravy schémy alebo zlyhania latencie.

To je miesto, kde sa smerovanie nákladov spája so širšou správou nákladov LLM. Samotná cenová tabuľka nestačí. Smerovač potrebuje metadáta požiadavky, rýchlu štruktúru, merania prístupov do vyrovnávacej pamäte a ustálené údaje o používaní, aby vedel, či sa očakávané úspory skutočne udiali.

Namiesto jednej globálnej predvolenej hodnoty použiť úrovne modelov

Viacúrovňové pravidlá sa vysvetľujú ľahšie ako veľký zoznam výnimiek špecifických pre poskytovateľov. Každá vrstva by mala obsahovať jeden alebo viacero vhodných modelov, ktoré prešli bránami špecifickými pre danú úlohu.

Nedovoľte, aby úroveň nahradila hodnoty. Model môže byť úsporný na klasifikáciu, ale nevhodný na podporu návrhu. Iný model môže byť silný na zhrnutie, ale príliš drahý na krátke deterministické značkovanie.

Postup s explicitným rozhodovaním

Smerovač zohľadňujúci náklady by mal byť dostatočne deterministický na ladenie. Presná implementácia sa líši, ale postupnosť rozhodovania by mala byť stabilná.

1. Prečítať nájomníka, kľúč API, prostredie a metadáta aplikácie.
2. Identifikujte triedu úloh z explicitných metadát alebo výstupu klasifikátora.
3. Načítať verziu pravidiel smerovania pre daného nájomníka alebo pracovný priestor.
4. Použite obmedzenia riadenia, ako je uchovávanie údajov, región, zoznam povolených modelov a obmedzenia funkcií.
5. Filtrovanie podľa požadovaných možností: dĺžka kontextu, nástroje, štruktúrovaný výstup, streamovanie, modalita a podpora dávok.
6. Filtrovať podľa minimálnej úrovne kvality zabezpečenej hodnotením pre triedu úloh.
7. Odhadnite náklady pomocou vstupných tokenov, očakávaných výstupných tokenov, vhodnosti vyrovnávacej pamäte, vhodnosti pre dávky a rizika opätovného pokusu.
8. Použiť pravidlá rozpočtu a preferencie nájomcu.
9. Vyberte prijateľnú trasu s najnižšou cenou.
10. Pripojiť záložnú trasu, časový limit, opakovať pokus a pravidlá opravy.
11. Zaznamenajte rozhodnutie pomocou stabilného kódu dôvodu.

V pseudokóde by mal smerovač vyzerať skôr ako hodnotenie pravidiel než pevne zakódovaná preferencia poskytovateľa:

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)

Zaznamenať každé rozhodnutie o smerovaní

Ak sa financie pýtajú, prečo bol použitý prémiový model, alebo sa inžinieri pýtajú, prečo klesla kvalita, smerovač by mal odpovedať z denníkov. Nespoliehajte sa na rekonštrukciu zámeru z dodatočných výziev.

Pre každú požiadavku zapíšte tieto polia:

• ID požiadavky, ID nájomníka, API ID kľúča, ID aplikácie a prostredie.
• Výsledok a spoľahlivosť klasifikátora úloh.
• Verzia pravidiel smerovania.
• Použitá verzia množiny údajov a brána kvality.
• Vhodné modely a odmietnuté modely.
• Dôvod, prečo bol každý odmietnutý model vylúčený.
• Odhadovaný vstup, vstupné a výstupné tokeny uložené vo vyrovnávacej pamäti.
• Odhadované náklady na trasu a konečné zúčtované náklady, ak sú k dispozícii.
• Vybraný poskytovateľ, model, verzia adaptéra a úroveň.
• Zásady záložného smerovania a opakovania.
• Uložte do vyrovnávacej pamäte telemetriu o nájdení alebo zlyhaní, ak je k dispozícii.
• Dávkový verzus synchrónny režim spúšťania.
• Overenie schémy, pokusy o opravu, stav odmietnutia a bezpečnostné príznaky.

Tieto denníky tiež podporujú LLM API pripisovanie nákladov, pretože výber modelu je len jednou časťou výdavkov. Tímy stále musia prideľovať náklady podľa nájomníka, pracovného priestoru, kľúča, produktu, pracovného postupu alebo zákazníka.

Pridajte ovládacie prvky posunu skôr, ako začnete propagovať lacnejšie trasy

Správanie modelu, ceny, výzvy a mix pracovného zaťaženia sa menia. Trasa, ktorá bola minulý mesiac bezpečná, sa môže po rýchlej revízii alebo aktualizácii modelu oslabiť.

Základná slučka riadenia driftu by mala zahŕňať:

• Ukážka nedávnych produkčných požiadaviek podľa triedy úloh.
• Odstráňte alebo transformujte citlivé údaje v súlade s pravidlami.
• Prehrajte si ukážky cez aktuálne a kandidátske trasy.
• Porovnajte kvalitu, platnosť schémy, správanie pri odmietnutí, náklady a latenciu.
• Skontrolujte zlyhania podľa kategórie, nielen súhrnného skóre.
• Propagujte lacnejšiu trasu iba vtedy, ak spĺňa požiadavky na kvalitu a prevádzkové obmedzenia.
• Nová trasa Canary pre malé percento premávky.
• Automaticky vrátiť späť pri zlyhaní schémy, prekročení nákladov, porušení latencie alebo eskalácii kontroly človekom.

Odporúčanie: urobte z propagácie trasy udalosť riadenia zmien. Zaznamenajte si, kto ju schválil, aká hodnotiaca sada prešla, aké percento návštevnosti ovplyvňuje, kedy vyprší jej platnosť alebo kedy je potrebné ju skontrolovať a ako funguje vrátenie.

Týmom poskytnite prepisy, ale nechajte ich vypršať

Existujú legitímne dôvody na prepísanie smerovania: incident poskytovateľa, núdzový stav rozpočtu, kontrola súladu, eskalácia zákazníka alebo regresia modelu. Problém nie je v prepise. Problémom je prepísanie, ktoré sa stáva trvalou neviditeľnou politikou.

Každé prepísanie by malo obsahovať:

• Rozsah: nájomník, aplikácia, kľúč API, trieda úlohy, model, poskytovateľ alebo región.
• Dôvod: incident, rozpočet, kvalita, súlad, latencia alebo požiadavka zákazníka.
• Schvaľovateľ.
• Čas začiatku a čas vypršania platnosti.
• Očakávaný vplyv na cenu, latenciu a kvalitu.
• Stav vrátenia späť.

Prepísania s uplynutou platnosťou by sa nemali zatvoriť podľa bežných pravidiel smerovania alebo by si mali vyžadovať obnovenie. To zabráni tomu, aby sa núdzové rozhodnutia nestali skrytými rizikami nákladov alebo kvality.

Odstupy, ktoré budú explicitné

Smerovanie s ohľadom na náklady má skutočné prevádzkové náklady. Stále sa to oplatí robiť, keď sú výdavky LLM podstatné, ale kompromisy by mali byť viditeľné.

• Závislosť od metadát: kvalita smerovania závisí od presných označení úloh a metadát pracovného zaťaženia. Chýbajúce štítky posúvajú návštevnosť ku konzervatívnym predvoleným hodnotám.
• Údržba hodnotenia: hodnotenia úloh potrebujú aktualizácie, pretože sa menia výzvy, produkty a správanie používateľov.
• Zložitosť poskytovateľa: Zľavy vo vyrovnávacej pamäti a dávkové zľavy môžu zlepšiť ekonomiku, no urobiť logiku smerovania zložitejšou.
• Riziko prenosnosti: Funkcie špecifické pre poskytovateľa by mali existovať v adaptéroch a záznamoch funkcií, nie v kóde produktu.
• Neistota odhadu: konečná dĺžka výstupu, volania nástrojov, opakované pokusy a prístupy do vyrovnávacej pamäte nie sú pred spustením úplne známe.
• Zaťaženie vysvetliteľnosti: agresívna optimalizácia môže sťažiť vysvetlenie správania produktu, pokiaľ sa každé rozhodnutie nezaprotokoluje s verziou pravidiel a kódmi dôvodov.

Kontrolný zoznam implementácie

• Definujte triedy úloh pre najlepšie pracovné postupy LLM podľa výdavkov a obchodného vplyvu.
• Vytvárajte hodnotové sady a úrovne kvality pre každú triedu úloh.
• Vybudujte register schopností poskytovateľa a modelu.
• Uchovávajte aktuálne cenové tabuľky a modifikátory cien podľa poskytovateľa, modelu a režimu realizácie.
• Odhadnite vstupné tokeny, očakávané výstupné tokeny, vhodnosť vyrovnávacej pamäte, vhodnosť pre dávky a riziko opätovného pokusu.
• Pred optimalizáciou nákladov filtrujte kandidátov podľa obmedzení správy.
• Vyberajte model s najnižšou cenou až po prekonaní brán schopností a kvality.
• Zaznamenajte vybrané a odmietnuté trasy pomocou kódov príčiny.
• Porovnajte odhadované náklady s vyúčtovanou spotrebou a údajmi z faktúr.
• Pred propagáciou lacnejších trás spúšťajte pravidelné hodnotenia prehrávania.
• Zmeny trasy Canary a definovanie spúšťačov vrátenia.
• Vyžadovať dátumy vypršania platnosti pre manuálne prepísania.

Záver

Praktickým cieľom nie je smerovať každú požiadavku na lacnejší model. Cieľom je prestať platiť za rutinnú prácu a zároveň chrániť kvalitu, zmluvy, pravidlá riadenia a vysvetliteľnosť.

Postavte smerovač na základe tried úloh, úrovní kvality, možností poskytovateľa, odhadov nákladov a denníkov pravidiel. Potom vyberte cestu s najnižšou cenou. Toto jediné slovo, vhodné, oddeľuje nákladovo orientované smerovanie od smerovania najlacnejšieho modelu.

Súvisiace čítanie

• limity výdavkov na úrovni brány