Kako izgraditi troškovno svjestan LLM model usmjeravanja bez žrtvovanja kvalitete

Usmjeravanje LLM modela s obzirom na troškove ne bi trebalo značiti slanje svakog zahtjeva najjeftinijem dostupnom modelu. To stvara tihi način kvara: fakture se poboljšavaju nekoliko tjedana, a zatim proizvodni timovi otkrivaju pokvarene sheme, slabije obrazloženje, nedosljedan ton ili podržavaju skice koje zahtijevaju više ljudskog čišćenja.

Bolji obrazac je politika usmjeravanja podržana vrijednostima. Klasificirajte zahtjev, definirajte minimalnu prihvatljivu kvalitetu za taj zadatak, uklonite rute koje ne mogu zadovoljiti ograničenja sposobnosti ili upravljanja, procijenite ekonomičnost rute, a zatim odaberite prihvatljivi model s najnižom cijenom. Odluka o usmjeravanju postaje objašnjiva tijekom pregleda troškova jer je povezana s verzijom pravila, a ne s preferencijama programera ili nejasnim zadanim postavkama pružatelja usluga.

Koje troškovno usmjeravanje optimizira

Praktični usmjerivač optimizira za najjeftiniju rutu koja još uvijek zadovoljava radne zahtjeve zadatka. To se razlikuje od optimizacije za najjeftiniji model.

Činjenice: glavni dobavljači modela objavljuju cijene tokena s odvojenim dimenzijama kao što su ulazni tokeni, predmemorirani ulazni tokeni, izlazni tokeni, brzo predmemoriranje i skupna obrada. Neki pružatelji također izlažu polja upotrebe koja izvješćuju o ponašanju predmemoriranih tokena. To znači da se opcija s najnižom cijenom može promijeniti na temelju oblika upita, očekivane duljine izlaza, podobnosti predmemorije i može li se radno opterećenje izvoditi asinkrono.

Preporuka: tretirajte usmjeravanje kao problem pravila unutar višemodelnog AI API pristupnika, a ne kao izjavu o prebacivanju na razini aplikacije. Pristupnik na jednom mjestu vidi zapise o mogućnostima pružatelja usluga, pravila zakupca, API ključne metapodatke, tablice cijena, telemetriju upotrebe i rezervno ponašanje.

Predviđanje: timovi koji drže logiku usmjeravanja razbacanu po spremištima aplikacija teško će kasnije objasniti promjene troškova. I dalje mogu smanjiti potrošnju, ali će imati slabije dokaze zašto je određeni zahtjev koristio određeni model.

Počnite s klasama zadataka, a ne s imenima dobavljača

Usmjerivač treba oznaku radnog opterećenja prije nego što može donijeti korisnu odluku. Jedan zadani model ne može predstavljati profil rizika svakog zahtjeva.

Korisne klase zadataka uključuju:

• Izdvajanje: pretvaranje nestrukturiranog teksta u polja, često uz strogu provjeru valjanosti sheme.
• Klasifikacija: dodjeljivanje oznaka, prioriteta, namjere, osjećaja ili kategorija usmjeravanja.
• Sažetak: sažimanje dugog unosa uz očuvanje ključnih činjenica i odluka.
• Izrada korisničke podrške: generirajte odgovor koji osoba može pregledati ili poslati.
• RAG sinteza odgovora: odgovor iz dohvaćenog konteksta sa zahtjevima za citiranje ili utemeljenje.
• Pregled koda: pregledajte razlike ili izvorne datoteke radi problema s ispravnošću, rizikom ili stilom.
• Analiza dugog konteksta: razlog zbog ugovora, prijepisa, zapisa, pravila ili paketa istraživanja.
• Podrška pri donošenju odluka s velikim utjecajem: bilo koji tijek rada u kojem bi loš odgovor mogao utjecati na novac, usklađenost, sigurnost ili povjerenje korisnika.

Klasa zadatka može proizaći iz eksplicitnih metapodataka zahtjeva, API opsega ključa, rute aplikacije ili laganog klasifikatora. Eksplicitni metapodaci obično su bolji od zaključivanja namjere iz teksta upita jer nejasni upiti prisiljavaju usmjerivač na konzervativne zadane postavke.

Pričvrstite kvalitetnu podnicu svakom zadatku

Usmjeravanje s obzirom na troškove funkcionira samo ako svaki zadatak ima donju razinu kvalitete. Bez njega, usmjerivač nema načelan način da odbije jeftiniji model.

Kvalitetan pod može uključivati nekoliko provjera:

• Skup vrijednosti za ponovnu reprodukciju: reprezentativni primjeri iz razvoja i proizvodnje, bez osjetljivih podataka gdje je potrebno.
• Valjanost sheme: izlaz mora analizirati, provjeriti valjanost prema kanonskoj shemi i izbjegavati nepodržana polja.
• Kriterij sadržaja: odgovor mora slijediti pravila za stil, odbijanje, utemeljenost i potpunost zadatka.
• Sigurnosni kriteriji: izlaz ne smije propuštati skrivene upute, ignorirati ograničenja pravila ili izvršavati nepouzdane upute iz dohvaćenog sadržaja.
• Ljudski pregled: potreban za tijekove rada s velikim utjecajem ili za promociju nove rute.
• Prag regresije: kandidatska ruta mora zadovoljiti ili premašiti trenutnu rutu u kritičnim kategorijama kvarova, a ne samo u prosječnom rezultatu.

Činjenica: dokumentacija pružatelja usluga opisuje evaluacije kao način testiranja izlaza modela prema određenim kriterijima sadržaja i stila. Jedan hostirani eval proizvod predviđen je za obustavu, tako da bi sustavi usmjeravanja trebali pohranjivati skupove podataka eval neutralne prema davatelju, očekivane rezultate, rubrike ocjenjivanja i rezultate, a ne ovisiti o eval površini koju hostira davatelj.

Preporuka: pohranite eval rezultate prema klasi zadatka, modelu, verziji adaptera pružatelja usluga, verziji upita, verziji sheme i verziji eval. Ruta ne bi trebala postati prihvatljiva samo zato što je model nov ili jeftiniji. Postaje prihvatljiv kada prođe trenutna vrata kvalitete zadatka.

Izradite registar mogućnosti pružatelja usluga

Prije procjene troškova, uklonite sve rute koje ne mogu zadovoljiti zahtjev. Ovaj korak sprječava usmjerivač da odabere jeftini model koji nema potrebne mogućnosti.

Zapis o sposobnosti treba uključivati:

• Podržani modaliteti unosa i izlaza.
• Ograničenja prozora konteksta.
• Strukturirani izlaz i podrška za pozivanje alata.
• Podrška za strujanje.
• Podrška za brzo predmemoriranje i dostupnost telemetrije u predmemoriji.
• Podrška za seriju API.
• Regionalne opcije obrade.
• Uvjeti zadržavanja podataka i praćenja zlouporabe koji su važni za vaša pravila.
• Dimenzije ograničenja brzine i trenutni kapacitet.
• Poznate razlike izlaznih ugovora u vašem prilagodnom sloju.

Ovaj registar treba održavati odvojeno od upita aplikacije. Pripada sloju prilagodnika usmjeravanja i pružatelja usluga, gdje sustav može usporediti modele bez curenja specifičnih pretpostavki pružatelja usluga u svaku aplikaciju.

Procjena cijene rute prije odabira

Usmjerivač ne može znati konačni trošak prije izvršenja, ali može dovoljno dobro procijeniti da odabere među prihvatljivim rutama. Procjena bi trebala uključivati varijable koje zapravo pomiču fakturu.

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

Koristite nedavnu telemetriju za procjenu izlaznih tokena prema klasi zadatka. Na primjer, zadaci ekstrakcije mogu imati ograničenu dužinu izlaza, dok analiza dugog konteksta može jako varirati. Agenti koji koriste alat mogu imati dodatne skrivene troškove zbog planiranja poziva alata, ponovnih pokušaja i međuporuka.

Procjena troškova također treba uzeti u obzir podobnost predmemorije i serije:

• Podobnost predmemorije: stabilni prefiks upita, sistemske upute za višekratnu upotrebu, opetovano dohvaćeni kontekst, podržano ponašanje pružatelja usluga i dovoljna vjerojatnost pogotka predmemorije.
• Podobnost serije: radno opterećenje može čekati, ima idempotentno rukovanje zahtjevima, ima trajno praćenje poslova i ne treba interaktivno strujanje.
• Rizik izlaznog tokena: model ima tendenciju proizvesti duže ili kraće odgovore za isti zadatak, a skraćivanje bi štetilo kvaliteti.
• Rizik ponovnog pokušaja: pružatelj ili model ima povećanu stopu pogrešaka, stopu popravka sheme ili kvarove latencije za ovaj zadatak.

Ovdje se usmjeravanje troškova povezuje sa širim upravljanjem troškova LLM-a. Sama tablica cijena nije dovoljna. Usmjerivač treba metapodatke zahtjeva, strukturu upita, mjerenja pogodaka u predmemoriju i podatke o utvrđenoj upotrebi kako bi znao jesu li doista ostvarene očekivane uštede.

Koristite razine modela umjesto jedne globalne zadane

Razinska pravila lakše je objasniti nego veliki popis iznimaka specifičnih za pružatelja usluga. Svaka razina treba sadržavati jedan ili više prihvatljivih modela koji su prošli ograničenja specifična za zadatak.

Ne dopustite da razina zamijeni vrijednosti. Model može biti ekonomičan za klasifikaciju, ali neprikladan za izradu potpore. Drugi model može biti jak za sažimanje, ali preskup za kratko determinističko označavanje.

Ruta s izričitim nizom odluka

Usmjerivač s obzirom na cijenu trebao bi biti dovoljno determinističan za otklanjanje pogrešaka. Točna implementacija varira, ali slijed odluka trebao bi biti stabilan.

1. Pročitaj zakupca, API ključ, okruženje i metapodatke aplikacije.
2. Identificirajte klasu zadatka iz eksplicitnih metapodataka ili rezultata klasifikatora.
3. Učitaj verziju pravila usmjeravanja za tog stanara ili radni prostor.
4. Primijenite ograničenja upravljanja kao što su zadržavanje podataka, regija, popis dopuštenih modela i ograničenja značajki.
5. Filtrirajte prema potrebnim mogućnostima: duljini konteksta, alatima, strukturiranom izlazu, strujanju, modalitetu i paketnoj podršci.
6. Filtrirajte prema donjoj razini kvalitete koju podržava Eval za klasu zadatka.
7. Procijenite trošak koristeći ulazne tokene, očekivane izlazne tokene, podobnost predmemorije, skupinsku podobnost i rizik ponovnog pokušaja.
8. Primijenite politiku proračuna i postavke stanara.
9. Odaberite prihvatljivu rutu s najnižom cijenom.
10. Priloži rezervnu rutu, istek vremena, ponovni pokušaj i pravilo popravka.
11. Zabilježite odluku sa stabilnim kodom razloga.

U pseudokodiranju, usmjerivač bi trebao izgledati više kao procjena pravila nego kao tvrdo kodirana postavka pružatelja:

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)

Zabilježi svaku odluku o usmjeravanju

Ako financije pitaju zašto je korišten vrhunski model ili inženjering pita zašto je pala kvaliteta, usmjerivač bi trebao odgovoriti iz zapisa. Nemojte se oslanjati na rekonstrukciju namjere iz upita nakon događaja.

Zabilježite ova polja za svaki zahtjev:

• ID zahtjeva, ID stanara, API ID ključa, ID aplikacije i okruženje.
• Rezultat i pouzdanost klasifikatora zadataka.
• Verzija pravila usmjeravanja.
• Upotrijebljena verzija skupa podataka Eval i izlaz kvalitete.
• Prihvatljivi modeli i odbijeni modeli.
• Razlog da je svaki odbijeni model isključen.
• Procijenjeni ulazni, predmemorirani ulazni i izlazni tokeni.
• Procijenjeni trošak rute i konačni podmireni trošak kada su dostupni.
• Odabrani davatelj, model, verzija adaptera i razina.
• Pravila zamjenske rute i ponovnog pokušaja.
• Pripremi telemetriju pogodaka ili promašaja ako je dostupna.
• Skupni u odnosu na sinkroni način izvršavanja.
• Provjera valjanosti sheme, pokušaji popravka, status odbijanja i sigurnosne oznake.

Ovi zapisnici također podržavaju LLM API dodjeljivanje troškova, jer je odabir modela samo jedan dio potrošnje. Timovi i dalje moraju raspodijeliti troškove prema zakupcu, radnom prostoru, ključu, proizvodu, tijeku rada ili kupcu.

Dodajte kontrole zanošenja prije nego što promovirate jeftinije rute

Promjena ponašanja modela, cijena, upita i kombinacije radnog opterećenja. Ruta koja je bila sigurna prošli mjesec može postati slaba nakon brze revizije ili ažuriranja modela.

Osnovna petlja kontrole drifta trebala bi uključivati:

• Uzorak nedavnih zahtjeva za proizvodnju prema klasi zadatka.
• Uklonite ili transformirajte osjetljive podatke u skladu s pravilima.
• Reprodukcija uzoraka kroz trenutne i potencijalne rute.
• Usporedite kvalitetu, valjanost sheme, ponašanje odbijanja, cijenu i kašnjenje.
• Pregledajte neuspjehe po kategoriji, a ne samo ukupni rezultat.
• Promovirajte jeftiniju rutu samo ako zadovoljava donju razinu kvalitete i operativna ograničenja.
• Canary nova ruta za mali postotak prometa.
• Automatsko vraćanje unatrag u slučaju kvara sheme, prekoračenja troškova, kršenja latencije ili eskalacije ljudskog pregleda.

Preporuka: neka promocija rute bude događaj za upravljanje promjenama. Zabilježite tko ga je odobrio, koji je skup procjena prošao, na koji postotak prometa utječe, kada ističe ili mu je potreban pregled i kako funkcionira vraćanje.

Dajte timovima nadjačavanja, ali neka isteknu

Postoje opravdani razlozi za nadjačavanje usmjeravanja: incident kod pružatelja usluga, hitan proračun, pregled sukladnosti, eskalacija korisnika ili regresija modela. Problem nije nadjačavanje. Problem je nadjačavanje koje trajno postaje nevidljivo.

Svako nadjačavanje treba uključivati:

• Opseg: stanar, aplikacija, API ključ, klasa zadatka, model, pružatelj ili regija.
• Razlog: incident, proračun, kvaliteta, usklađenost, latencija ili zahtjev korisnika.
• Odobravatelj.
• Vrijeme početka i vrijeme isteka.
• Očekivani utjecaj na cijenu, kašnjenje i kvalitetu.
• Uvjet vraćanja.

Istekla nadjačavanja ne bi trebala biti zatvorena prema normalnoj politici usmjeravanja ili zahtijevati obnovu. Time se sprječava da hitne odluke postanu skriveni troškovi ili rizici kvalitete.

Kompromisi da budu eksplicitni

Usmjeravanje s obzirom na troškove ima stvarne operativne troškove. I dalje se isplati raditi kada je potrošnja na LLM značajna, ali kompromisi bi trebali biti vidljivi.

• Ovisnost o metapodacima: kvaliteta usmjeravanja ovisi o točnim oznakama zadataka i metapodacima o radnom opterećenju. Oznake koje nedostaju guraju promet prema konzervativnim zadanim postavkama.
• Održavanje Eval-a: Eval-ovi zadataka trebaju ažuriranja kako se mijenjaju upiti, proizvodi i ponašanje korisnika.
• Složenost pružatelja: predmemorija i skupni popusti mogu poboljšati ekonomiju, ali logiku usmjeravanja učiniti složenijom.
• Rizik prenosivosti: značajke specifične za pružatelja usluga trebaju postojati u adapterima i zapisima o mogućnostima, a ne u kodu proizvoda.
• Nesigurnost procjene: konačna duljina izlaza, pozivi alata, ponovni pokušaji i pogoci predmemorije nisu u potpunosti poznati prije izvršenja.
• Teret objašnjenja: agresivna optimizacija može otežati objašnjenje ponašanja proizvoda osim ako se svaka odluka ne bilježi s verzijom pravila i šiframa razloga.

Kontrolni popis za implementaciju

• Definirajte klase zadataka za najbolje LLM tijekove rada prema potrošnji i poslovnom utjecaju.
• Stvorite eval setove i kvalitete za svaku klasu zadataka.
• Izradite registar mogućnosti pružatelja usluga i modela.
• Pohranjujte trenutne tablice cijena i modifikatore cijena po pružatelju, modelu i načinu izvršenja.
• Procijenite ulazne tokene, očekivane izlazne tokene, podobnost predmemorije, skupinsku podobnost i rizik ponovnog pokušaja.
• Filtrirajte kandidate prema ograničenjima upravljanja prije optimizacije troškova.
• Odaberite model s najnižom cijenom tek nakon što prođu granice sposobnosti i kvalitete.
• Zabilježite odabrane i odbijene rute s kodovima razloga.
• Usporedite procijenjeni trošak s podmirenom potrošnjom i podacima o fakturama.
• Pokrenite povremene ponovne procjene prije promoviranja jeftinijih ruta.
• Promjene rute Canary i definiranje okidača vraćanja.
• Zahtijevaj datume isteka za ručna nadjačavanja.

Zaključak

Praktični cilj nije usmjeriti svaki zahtjev na jeftiniji model. Cilj je zaustaviti preplaćivanje za rutinski rad uz zaštitu kvalitete, ugovora, pravila upravljanja i objašnjivosti.

Izgradite usmjerivač oko klasa zadataka, minimalnih razina kvalitete, mogućnosti pružatelja usluga, procjena troškova i zapisa pravila. Zatim odaberite prihvatljivu rutu s najnižom cijenom. Ta jedna riječ, prihvatljivo, ono je što razdvaja usmjeravanje s obzirom na troškove od usmjeravanja najjeftinijeg modela.

Povezano čitanje

• ograničenja potrošnje na razini pristupnika