Jak vytvořit směrování modelu LLM s ohledem na náklady bez obětování kvality

Směrování modelu LLM s ohledem na náklady by nemělo znamenat odeslání každé žádosti na nejlevnější dostupný model. To vytváří tichý režim selhání: faktury se několik týdnů zlepšují, pak produktové týmy objeví nefunkční schémata, slabší uvažování, nekonzistentní tón nebo návrhy podpory, které vyžadují větší lidské čištění.

Lepším vzorem je zásada směrování podporovaná eval. Klasifikujte požadavek, definujte minimální přijatelnou kvalitu pro daný úkol, odstraňte trasy, které nesplňují omezení schopností nebo řízení, odhadněte ekonomiku trasy a poté vyberte vhodný model s nejnižšími náklady. Rozhodnutí o směrování lze vysvětlit během kontroly nákladů, protože je vázáno na verzi zásad, nikoli na preference vývojáře nebo nejasné výchozí nastavení poskytovatele.

Co optimalizuje směrování s ohledem na náklady

Praktický router se optimalizuje pro nejlevnější trasu, která stále splňuje provozní požadavky úkolu. To se liší od optimalizace pro nejlevnější model.

Fakta: Hlavní poskytovatelé modelů zveřejňují ceny tokenů se samostatnými dimenzemi, jako jsou vstupní tokeny, vstupní tokeny uložené v mezipaměti, výstupní tokeny, rychlé ukládání do mezipaměti a dávkové zpracování. Někteří poskytovatelé také vystavují pole použití, která hlásí chování tokenu uloženého v mezipaměti. To znamená, že nejlevnější varianta se může změnit na základě tvaru výzvy, očekávané délky výstupu, vhodnosti mezipaměti a toho, zda může zátěž běžet asynchronně.

Doporučení: považovat směrování za problém se zásadami uvnitř brány AI API pro více modelů, nikoli za příkaz přepínače na úrovni aplikace. Brána vidí na jednom místě záznamy o schopnostech poskytovatele, pravidla tenantů, API klíčová metadata, cenové tabulky, telemetrii využití a záložní chování.

Prediction: Týmy, které udržují logiku směrování rozptýlenou po úložištích aplikací, budou mít později potíže s vysvětlením změn nákladů. Stále mohou snížit výdaje, ale budou mít slabší důkazy o tom, proč daná žádost používala daný model.

Začněte třídami úkolů, nikoli jmény poskytovatelů

Směrovač potřebuje označení pracovní zátěže, než může učinit užitečné rozhodnutí. Jediný výchozí model nemůže představovat rizikový profil každého požadavku.

Třídy užitečných úkolů zahrnují:

• Extrakce: převést nestrukturovaný text na pole, často s přísným ověřením schématu.
• Klasifikace: přiřaďte kategorie štítků, priority, záměru, sentimentu nebo směrování.
• Shrnutí: komprimovat dlouhý vstup při zachování klíčových faktů a rozhodnutí.
• Koncept zákaznické podpory: vygenerovat odpověď, kterou může člověk zkontrolovat nebo odeslat.
• Syntéza odpovědí RAG: odpověď z načteného kontextu s požadavky na citaci nebo základy.
• Kontrola kódu: zkontrolujte rozdíly nebo zdrojové soubory, zda neobsahují problémy se správností, rizikem nebo stylem.
• Dlouhodobá kontextová analýza: zdůvodnění smluv, přepisů, protokolů, zásad nebo výzkumných balíčků.
• Podpora rozhodování s velkým dopadem: jakýkoli pracovní postup, kde by špatná odpověď mohla ovlivnit peníze, dodržování předpisů, bezpečnost nebo důvěru zákazníků.

Třída úkolu může pocházet z metadat explicitního požadavku, rozsahu klíče API, trasy aplikace nebo odlehčeného klasifikátoru. Explicitní metadata jsou obvykle lepší než vyvozování záměru z textu výzvy, protože vágní výzvy nutí router ke konzervativním výchozím nastavením.

Každému úkolu přiřaďte úroveň kvality

Směrování s ohledem na náklady funguje pouze v případě, že každý úkol má minimální úroveň kvality. Bez něj nemá router žádný principiální způsob, jak odmítnout levnější model.

Podlaha kvality může zahrnovat několik kontrol:

• Replayable eval set: Reprezentativní příklady z vývoje a výroby, v případě potřeby zbavené citlivých dat.
• Platnost schématu: výstup musí analyzovat, ověřit podle kanonického schématu a vyhnout se nepodporovaným polím.
• Kritéria obsahu: odpověď musí odpovídat pravidlům stylu, odmítnutí, uzemnění a úplnosti úkolu.
• Bezpečnostní kritéria: výstup nesmí prosakovat skryté pokyny, ignorovat hranice zásad ani provádět nedůvěryhodné pokyny z načteného obsahu.
• Hodnocení člověkem: je vyžadováno pro vysoce účinné pracovní postupy nebo pro propagaci nové trasy.
• Práh regrese: kandidátská trasa musí splňovat nebo překračovat aktuální trasu v kategoriích kritických selhání, nejen průměrné skóre.

Fact: Dokumentace poskytovatele popisuje hodnocení jako způsob testování výstupů modelu podle zadaných kritérií obsahu a stylu. U jednoho hostovaného eval produktu je naplánováno ukončení podpory, takže směrovací systémy by měly ukládat datové sady eval neutrální vůči poskytovateli, očekávané výstupy, hodnotící rubriky a výsledky, spíše než záviset na jednom poskytovatelem hostovaném eval povrchu.

Doporučení: ukládat výsledky eval podle třídy úlohy, modelu, verze adaptéru poskytovatele, verze výzvy, verze schématu a verze eval. Trasa by se neměla stát způsobilou jednoduše proto, že je model nový nebo levnější. Stane se způsobilým, když projde aktuální bránou kvality úkolu.

Vytvoření registru schopností poskytovatele

Před odhadem nákladů odstraňte všechny trasy, které nemohou vyhovět požadavku. Tento krok zabrání routeru vybrat levný model, který postrádá požadované funkce.

Záznam schopností by měl obsahovat:

• Podporované vstupní a výstupní modality.
• Limity kontextového okna.
• Podpora strukturovaného výstupu a volání nástrojů.
• Podpora streamování.
• Podpora rychlého ukládání do mezipaměti a dostupnost telemetrie mezipaměti.
• Podpora API dávky.
• Možnosti regionálního zpracování.
• Podmínky sledování uchovávání dat a zneužití, které jsou důležité pro vaše zásady.
• Omezení sazby a aktuální kapacita.
• Známé rozdíly výstupních kontraktů ve vrstvě adaptéru.

Tento registr by měl být udržován odděleně od výzev aplikace. Patří k vrstvě směrování a adaptéru poskytovatele, kde může systém porovnávat modely, aniž by do každé aplikace unikal předpoklady specifické pro poskytovatele.

Odhadněte cenu trasy před výběrem

Směrovač nemůže znát konečnou cenu před spuštěním, ale dokáže dostatečně dobře odhadnout, aby si mohl vybrat mezi vhodnými trasami. Odhad by měl zahrnovat proměnné, které skutečně pohybují fakturou.

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žijte nedávnou telemetrii k odhadu výstupních tokenů podle třídy úkolu. Například extrakční úlohy mohou mít omezenou výstupní délku, zatímco analýza dlouhého kontextu se může značně lišit. Zástupci používající nástroje mohou mít dodatečné skryté náklady za plánování volání nástroje, opakování a zprostředkování zpráv.

Odhad nákladů by měl také zohledňovat způsobilost mezipaměti a dávky:

• Vhodnost mezipaměti: stabilní předpona výzvy, opakovaně použitelné systémové pokyny, opakovaně načítaný kontext, podporované chování poskytovatele a dostatečná pravděpodobnost zásahu do mezipaměti.
• Vhodnost pro dávky: pracovní zátěž může počkat, má idempotentní zpracování požadavků, trvalé sledování úloh a nepotřebuje interaktivní streamování.
• Riziko výstupu-tokenu: model má tendenci produkovat delší nebo kratší odpovědi na stejný úkol a zkrácení by poškodilo kvalitu.
• Riziko opakování: poskytovatel nebo model má pro tento úkol zvýšenou míru chyb, míru oprav schématu nebo selhání latence.

Tady se směrování nákladů propojuje s širší správou nákladů LLM. Samotná cenová tabulka nestačí. Směrovač potřebuje metadata požadavku, promptní strukturu, měření přístupů do mezipaměti a ustálená data o využití, aby věděl, zda skutečně došlo k očekávaným úsporám.

Použít úrovně modelů namísto jednoho globálního výchozího nastavení

Odstupňované zásady se vysvětlují snadněji než velký seznam výjimek pro konkrétní poskytovatele. Každá úroveň by měla obsahovat jeden nebo více vhodných modelů, které prošly branami pro konkrétní úkol.

Nedovolte, aby úroveň nahradila hodnocení. Model může být ekonomický pro klasifikaci, ale nevhodný pro podpůrné navrhování. Jiný model může být silný pro shrnutí, ale příliš drahý pro krátké deterministické značkování.

Postup s explicitní rozhodovací sekvencí

Směrovač s ohledem na náklady by měl být dostatečně deterministický, aby se dal ladit. Přesná implementace se liší, ale rozhodovací sekvence by měla být stabilní.

1. Přečíst tenanta, klíč API, prostředí a metadata aplikace.
2. Identifikujte třídu úkolu z explicitních metadat nebo výstupu klasifikátoru.
3. Načtěte verzi zásad směrování pro daného tenanta nebo pracovní prostor.
4. Použijte omezení správy, jako je uchovávání dat, region, seznam povolených modelů a omezení funkcí.
5. Filtrování podle požadovaných funkcí: délka kontextu, nástroje, strukturovaný výstup, streamování, modalita a podpora dávek.
6. Filtrovat podle nejnižší úrovně kvality s podporou hodnocení pro třídu úkolů.
7. Odhadněte náklady pomocí vstupních tokenů, očekávaných výstupních tokenů, vhodnosti mezipaměti, vhodnosti pro dávky a rizika opakování.
8. Použít zásady rozpočtu a preference nájemce.
9. Vyberte cestu s nejnižšími náklady.
10. Připojit záložní trasu, časový limit, opakovat pokus a zásady opravy.
11. Zaznamenejte rozhodnutí pomocí stabilního kódu důvodu.

V pseudokódu by měl směrovač vypadat spíše jako vyhodnocení zásad než jako pevně zakódovaná preference poskytovatele:

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)

Protokolovat každé rozhodnutí o směrování

Pokud se finance zeptají, proč byl použit prémiový model, nebo se inženýrství zeptá, proč klesla kvalita, měl by router odpovědět z protokolů. Nespoléhejte na rekonstrukci záměru z následných výzev.

Pro každý požadavek zapište tato pole:

• ID požadavku, ID tenanta, API ID klíče, ID aplikace a prostředí.
• Výsledek a spolehlivost klasifikátoru úkolů.
• Verze zásad směrování.
• Použitá verze datové sady a brána kvality.
• Vhodné modely a odmítnuté modely.
• Důvod, proč byl každý odmítnutý model vyloučen.
• Odhadovaný vstup, vstupní a výstupní tokeny uložené v mezipaměti.
• Odhadované náklady na trasu a konečné zúčtované náklady, pokud jsou k dispozici.
• Vybraný poskytovatel, model, verze adaptéru a úroveň.
• Zásady záložní cesty a opakování.
• Uložte do mezipaměti telemetrii zásahů nebo chyb, pokud je k dispozici.
• Dávkový versus synchronní režim spuštění.
• Ověření schématu, pokusy o opravu, stav odmítnutí a bezpečnostní příznaky.

Tyto protokoly také podporují LLM API připisování nákladů, protože výběr modelu je pouze jednou částí výdajů. Týmy stále musí alokovat náklady podle tenanta, pracovního prostoru, klíče, produktu, pracovního postupu nebo zákazníka.

Než začnete propagovat levnější trasy, přidejte ovládací prvky snášení

Změní se chování modelu, ceny, výzvy a pracovní zátěž. Trasa, která byla minulý měsíc bezpečná, se může po rychlé revizi nebo aktualizaci modelu oslabit.

Základní regulační smyčka snosu by měla zahrnovat:

• Ukázka nedávných požadavků na produkci podle třídy úkolu.
• Odstraňte nebo transformujte citlivá data v souladu se zásadami.
• Přehrajte si ukázky aktuálními a kandidátskými cestami.
• Porovnejte kvalitu, platnost schématu, chování při odmítnutí, cenu a latenci.
• Neúspěchy zkontrolujte podle kategorií, nejen podle souhrnného skóre.
• Propagujte levnější trasu, pouze pokud splňuje minimální kvalitu a provozní omezení.
• Nová trasa Canary pro malé procento provozu.
• Automaticky vrátit zpět při selhání schématu, překročení nákladů, porušení latence nebo eskalaci kontroly člověkem.

Doporučení: udělejte z propagace trasy událost řízení změn. Zaznamenejte si, kdo ji schválil, jakou sadu hodnocení prošel, jaké procento návštěvnosti ovlivňuje, kdy vyprší platnost nebo je třeba ji zkontrolovat a jak funguje vrácení.

Dejte týmům přepisy, ale nechte je vypršet

Existují legitimní důvody pro přepsání směrování: incident poskytovatele, nouzový stav rozpočtu, kontrola souladu, eskalace zákazníka nebo regrese modelu. Problém není v přepisování. Problémem je přepsání, které se stane trvalou neviditelnou zásadou.

Každé přepsání by mělo obsahovat:

• Rozsah: tenant, aplikace, API klíč, třída úkolu, model, poskytovatel nebo region.
• Důvod: incident, rozpočet, kvalita, soulad, latence nebo požadavek zákazníka.
• Schvalovatel.
• Čas zahájení a čas vypršení platnosti.
• Očekávaný dopad na cenu, latenci a kvalitu.
• Podmínka vrácení.

Přepsání s vypršenou platností by se nemělo podařit uzavřít běžným zásadám směrování nebo vyžadovat obnovení. Tím se zabrání tomu, aby se nouzová rozhodnutí nestala skrytými riziky nákladů nebo kvality.

Výmluvy, které budou explicitní

Směrování s ohledem na náklady má skutečné provozní náklady. Stále se to vyplatí, když jsou výdaje LLM podstatné, ale kompromisy by měly být viditelné.

• Závislost na metadatech: kvalita směrování závisí na přesných štítcích úkolů a metadatech pracovního zatížení. Chybějící štítky posouvají provoz ke konzervativním výchozím hodnotám.
• Údržba hodnocení: Hodnoty úkolů potřebují aktualizace, protože se mění výzvy, produkty a chování uživatelů.
• Složitost poskytovatele: Slevy mezipaměti a hromadné slevy mohou zlepšit ekonomiku, ale učinit logiku směrování složitější.
• Riziko přenositelnosti: Funkce specifické pro poskytovatele by měly existovat v adaptérech a záznamech funkcí, nikoli v kódu produktu.
• Nejistota odhadu: konečná délka výstupu, volání nástrojů, opakované pokusy a přístupy do mezipaměti nejsou před provedením plně známy.
• Zatížení vysvětlitelností: Agresivní optimalizace může ztěžovat vysvětlení chování produktu, pokud není každé rozhodnutí zaprotokolováno s verzí zásad a kódy důvodů.

Kontrolní seznam implementace

• Definujte třídy úkolů pro nejlepší pracovní postupy LLM podle výdajů a dopadu na podnikání.
• Vytvořte sady hodnocení a úrovně kvality pro každou třídu úkolů.
• Vytvoření registru schopností poskytovatele a modelu.
• Ukládání aktuálních cenových tabulek a modifikátorů cen podle poskytovatele, modelu a režimu provedení.
• Odhadněte vstupní tokeny, očekávané výstupní tokeny, vhodnost mezipaměti, vhodnost pro dávky a riziko opakování.
• Před optimalizací nákladů filtrujte kandidáty podle omezení správy.
• Nejnižší model vybírejte až poté, co projdou hranice schopností a kvality.
• Protokolovat vybrané a odmítnuté trasy pomocí kódů příčiny.
• Porovnejte odhadované náklady s vyúčtovaným využitím a fakturačními údaji.
• Před propagací levnějších tras spouštějte periodická hodnocení přehrávání.
• Změny trasy Canary a definování spouštěčů vrácení.
• Vyžadovat data vypršení platnosti pro ruční přepsání.

Závěr

Praktickým cílem není přesměrovat každý požadavek na levnější model. Cílem je přestat platit za rutinní práci a zároveň chránit kvalitu, smlouvy, pravidla řízení a vysvětlitelnost.

Postavte směrovač na základě tříd úkolů, úrovní kvality, možností poskytovatele, odhadů nákladů a protokolů zásad. Poté vyberte cestu s nejnižšími náklady. Toto jediné slovo, způsobilé, odděluje nákladově orientované směrování od směrování nejlevnějšího modelu.

Související čtení

• limity výdajů na úrovni brány