Jak zbudować oszczędny model routingu LLM bez utraty jakości

Routing w modelu LLM uwzględniający koszty nie powinien oznaczać wysyłania każdego żądania do najtańszego dostępnego modelu. Prowadzi to do cichej awarii: faktury poprawiają się przez kilka tygodni, następnie zespoły ds. produktu odkrywają zepsute schematy, słabsze rozumowanie, niespójny ton lub obsługujące wersje robocze wymagające większej uwagi ze strony człowieka.

Lepszym wzorcem jest polityka routingu oparta na ewaluacji. Sklasyfikuj żądanie, zdefiniuj minimalną akceptowalną jakość dla tego zadania, usuń trasy, które nie są w stanie spełnić ograniczeń w zakresie możliwości lub zarządzania, oszacuj ekonomikę trasy, a następnie wybierz kwalifikujący się model o najniższym koszcie. Decyzję o routingu można wyjaśnić podczas przeglądu kosztów, ponieważ jest ona powiązana z wersją zasad, a nie z preferencjami programisty lub niejasnymi domyślnymi ustawieniami dostawcy.

Jakie routing uwzględniający koszty optymalizuje

Praktyczny router optymalizuje trasę pod kątem najtańszej trasy, która nadal spełnia wymagania operacyjne zadania. Różni się to od optymalizacji pod kątem najtańszego modelu.

Fakty: główni dostawcy modeli publikują ceny tokenów z oddzielnymi wymiarami, takimi jak tokeny wejściowe, tokeny wejściowe w pamięci podręcznej, tokeny wyjściowe, buforowanie podpowiedzi i przetwarzanie wsadowe. Niektórzy dostawcy udostępniają również pola użytkowania, które raportują zachowanie tokenu w pamięci podręcznej. Oznacza to, że najtańsza opcja może się zmieniać w zależności od kształtu podpowiedzi, oczekiwanej długości danych wyjściowych, kwalifikowalności pamięci podręcznej i tego, czy obciążenie może działać asynchronicznie.

Zalecenie: traktuj routing jako problem związany z zasadami w bramie APIwielomodelowej sztucznej inteligencji, a nie jako instrukcję przełączania na poziomie aplikacji. Brama widzi w jednym miejscu rekordy możliwości dostawcy, reguły dzierżawy, API kluczowe metadane, tabele cen, dane telemetryczne dotyczące użycia i zachowania awaryjne.

Przewidywanie: zespoły, które przechowują logikę routingu rozproszoną po repozytoriach aplikacji, będą miały później trudności z wyjaśnieniem zmian kosztów. Mogą nadal ograniczać wydatki, ale będą mieli słabsze dowody na to, dlaczego w danym żądaniu użyto danego modelu.

Zacznij od klas zadań, a nie nazw dostawców

Router potrzebuje etykiety obciążenia, zanim będzie mógł podjąć użyteczną decyzję. Pojedynczy model domyślny nie może reprezentować profilu ryzyka każdego żądania.

Przydatne klasy zadań obejmują:

• Wyodrębnianie: konwertowanie nieustrukturyzowanego tekstu na pola, często przy ścisłej weryfikacji schematu.
• Klasyfikacja: przypisz etykiety, priorytety, zamiary, opinie lub kategorie routingu.
• Podsumowanie: kompresuj długie dane wejściowe, zachowując kluczowe fakty i decyzje.
• Opracowanie projektu wsparcia klienta: wygeneruj odpowiedź, którą może przejrzeć lub wysłać człowiek.
• Synteza odpowiedzi RAG: odpowiedź na podstawie odzyskanego kontekstu z wymaganiami dotyczącymi cytatu lub podstaw.
• Przegląd kodu: sprawdź pliki różnicowe lub pliki źródłowe pod kątem poprawności, ryzyka lub problemów ze stylem.
• Analiza długiego kontekstu: uzasadnienie umów, transkrypcji, dzienników, zasad lub pakietów badawczych.
• Wspomaganie podejmowania decyzji o dużym wpływie: dowolny przepływ pracy, w którym zła odpowiedź może mieć wpływ na pieniądze, zgodność, bezpieczeństwo lub zaufanie klientów.

Klasa zadania może pochodzić z jawnych metadanych żądania, zakresu klucza API, trasy aplikacji lub lekkiego klasyfikatora. Jawne metadane są zwykle lepsze niż wnioskowanie o zamiarze na podstawie tekstu zachęty, ponieważ niejasne podpowiedzi zmuszają router do stosowania konserwatywnych ustawień domyślnych.

Dołącz poziom jakości do każdego zadania

Routing uwzględniający koszty działa tylko wtedy, gdy każde zadanie ma minimalny poziom jakości. Bez niego router nie ma żadnego sposobu na odrzucenie tańszego modelu.

Podstawowa jakość może obejmować kilka kontroli:

• Odtwarzalny zestaw ewaluacyjny: reprezentatywne przykłady z rozwoju i produkcji, w razie potrzeby pozbawione wrażliwych danych.
• Ważność schematu: dane wyjściowe muszą być analizowane, sprawdzane pod kątem schematu kanonicznego i unikać nieobsługiwanych pól.
• Kryteria treści: odpowiedź musi być zgodna z zasadami stylu, odmowy, podstaw i kompletności zadania.
• Kryteria bezpieczeństwa: dane wyjściowe nie mogą powodować wycieku ukrytych instrukcji, ignorować granic zasad ani wykonywać niezaufanych instrukcji z pobranej zawartości.
• Weryfikacja manualna: wymagana w przypadku przepływów pracy o dużym wpływie lub w celu promocji nowej trasy.
• Próg regresji: trasa kandydująca musi odpowiadać bieżącej trasie lub ją przekraczać w przypadku kategorii awarii krytycznych, a nie tylko średniego wyniku.

Fakt: dokumentacja dostawcy opisuje oceny jako sposób testowania wyników modelu pod kątem określonych kryteriów treści i stylu. Jeden hostowany produkt ewaluacyjny ma zostać wycofany, dlatego systemy routingu powinny przechowywać neutralne dla dostawcy zbiory danych ewaluacyjnych, oczekiwane dane wyjściowe, rubryki oceniania i wyniki, a nie zależeć od jednej powierzchni ewaluacyjnej hostowanej przez dostawcę.

Zalecenie: przechowuj wyniki eval według klasy zadania, modelu, wersji adaptera dostawcy, wersji podpowiedzi, wersji schematu i wersji eval. Trasa nie powinna kwalifikować się do objęcia programem tylko dlatego, że model jest nowy lub tańszy. Staje się kwalifikowalny, gdy przejdzie aktualną bramkę jakości zadania.

Utwórz rejestr możliwości dostawcy

Przed oszacowaniem kosztów usuń wszelkie trasy, które nie spełniają żądania. Ten krok uniemożliwia routerowi wybranie taniego modelu, który nie ma wymaganych funkcji.

Rekord możliwości powinien zawierać:

• Obsługiwane tryby wejścia i wyjścia.
• Ograniczenia okna kontekstowego.
• Ustrukturyzowane dane wyjściowe i obsługa wywoływania narzędzi.
• Obsługa transmisji strumieniowej.
• Szybka obsługa buforowania i dostępność telemetrii pamięci podręcznej.
• Wsparcie partii API.
• Opcje przetwarzania regionalnego.
• Warunki przechowywania danych i monitorowania nadużyć istotne dla Twoich zasad.
• Wymiary limitów prędkości i aktualna pojemność.
• Znane różnice w kontraktach wyjściowych w warstwie adaptera.

Ten rejestr powinien być utrzymywany oddzielnie od monitów aplikacji. Należy do warstwy routingu i adaptera dostawcy, gdzie system może porównywać modele bez wyciekania założeń specyficznych dla dostawcy do każdej aplikacji.

Oszacuj koszt trasy przed wyborem

Router nie może znać ostatecznego kosztu przed wykonaniem, ale może oszacować go na tyle dobrze, aby wybrać jedną z kwalifikujących się tras. Szacunek powinien uwzględniać zmienne, które faktycznie wpływają na fakturę.

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

Użyj najnowszej telemetrii, aby oszacować tokeny wyjściowe według klasy zadania. Na przykład zadania ekstrakcji mogą mieć ograniczoną długość wyników, podczas gdy analiza długiego kontekstu może się znacznie różnić. Agenci korzystający z narzędzi mogą wiązać się z dodatkowymi ukrytymi kosztami wynikającymi z planowania wywołań narzędzi, ponownych prób i komunikatów pośrednich.

Oszacowanie kosztów powinno również uwzględniać kwalifikowalność pamięci podręcznej i partii:

• Kwalifikowalność pamięci podręcznej: stabilny przedrostek podpowiedzi, instrukcje systemowe do wielokrotnego użytku, wielokrotnie pobierany kontekst, obsługiwane zachowanie dostawcy i wystarczające prawdopodobieństwo trafienia w pamięć podręczną.
• Kwalifikowalność partii: obciążenie może poczekać, obsługuje idempotentne żądania, umożliwia trwałe śledzenie zadań i nie wymaga interaktywnego przesyłania strumieniowego.
• Ryzyko tokena wyjściowego: model ma tendencję do generowania dłuższych lub krótszych odpowiedzi dla tego samego zadania, a obcięcie zaszkodziłoby jakości.
• Ryzyko ponownej próby: dostawca lub model ma podwyższoną liczbę błędów, liczbę napraw schematu lub błędy związane z opóźnieniami w przypadku tego zadania.

W tym miejscu routing kosztów łączy się z szerszym zarządzaniem kosztami LLM. Sama tabela cen nie wystarczy. Router potrzebuje metadanych żądań, struktury podpowiedzi, pomiarów trafień w pamięci podręcznej i ustalonych danych dotyczących użytkowania, aby wiedzieć, czy rzeczywiście nastąpiły oczekiwane oszczędności.

Użyj warstw modelu zamiast jednej globalnej wartości domyślnej

Wielopoziomowe zasady są łatwiejsze do wyjaśnienia niż duża lista wyjątków specyficznych dla dostawcy. Każdy poziom powinien zawierać jeden lub więcej kwalifikujących się modeli, które przeszły bramy specyficzne dla zadania.

Nie pozwól, aby poziom zastępował evals. Model może być ekonomiczny w klasyfikacji, ale nieodpowiedni do opracowywania pomocniczego. Inny model może nadawać się do podsumowań, ale jest zbyt kosztowny w przypadku krótkiego, deterministycznego tagowania.

Trasa z wyraźną sekwencją decyzyjną

Router uwzględniający koszty powinien być wystarczająco deterministyczny, aby umożliwić debugowanie. Dokładna implementacja jest różna, ale sekwencja decyzji powinna być stabilna.

1. Przeczytaj dzierżawcę, klucz API, środowisko i metadane aplikacji.
2. Zidentyfikuj klasę zadania na podstawie jawnych metadanych lub wyników klasyfikatora.
3. Załaduj wersję zasad routingu dla tego dzierżawcy lub obszaru roboczego.
4. Zastosuj ograniczenia zarządzania, takie jak przechowywanie danych, region, lista dozwolonych modeli i ograniczenia funkcji.
5. Filtruj według wymaganych możliwości: długości kontekstu, narzędzi, uporządkowanych danych wyjściowych, przesyłania strumieniowego, modalności i obsługi wsadowej.
6. Filtruj według minimalnej wartości jakości dla klasy zadania.
7. Oszacuj koszt na podstawie tokenów wejściowych, oczekiwanych tokenów wyjściowych, kwalifikowalności pamięci podręcznej, kwalifikowalności partii i ryzyka ponownych prób.
8. Zastosuj politykę budżetową i preferencje najemcy.
9. Wybierz kwalifikującą się trasę o najniższym koszcie.
10. Dołącz trasę zastępczą, limit czasu, ponawianie prób i zasady naprawy.
11. Zapisz decyzję, podając stabilny kod przyczyny.

W pseudokodzie router powinien bardziej przypominać ocenę zasad niż zakodowaną na stałe preferencję dostawcy:

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)

Rejestruj każdą decyzję dotyczącą routingu

Jeśli dział finansów zapyta, dlaczego użyto modelu premium, lub inżynieria zapyta, dlaczego jakość spadła, router powinien odpowiedzieć na podstawie dzienników. Nie polegaj na rekonstruowaniu intencji na podstawie podpowiedzi po fakcie.

Zaloguj te pola dla każdego żądania:

• Identyfikator żądania, identyfikator dzierżawcy, API identyfikator klucza, identyfikator aplikacji i środowisko.
• Wynik i pewność klasyfikatora zadań.
• Wersja zasad routingu.
• Wykorzystano wersję zbioru danych Eval i bramkę jakości.
• Modele kwalifikujące się i modele odrzucone.
• Powód wykluczenia każdego odrzuconego modelu.
• Szacowane tokeny wejściowe, buforowane dane wejściowe i dane wyjściowe.
• Szacowany koszt trasy i ostateczny rozliczony koszt, jeśli jest dostępny.
• Wybrany dostawca, model, wersja adaptera i warstwa.
• Zasady dotyczące trasy awaryjnej i ponawiania prób.
• Przechowuj telemetrię trafień lub braków w pamięci podręcznej, jeśli jest dostępna.
• Tryb wykonywania wsadowego a tryb wykonywania synchronicznego.
• Weryfikacja schematu, próby naprawy, status odmowy i flagi bezpieczeństwa.

Te dzienniki obsługują także LLM API atrybucję kosztów, ponieważ wybór modelu to tylko jedna część wydatków. Zespoły nadal muszą alokować koszty według najemcy, obszaru roboczego, klucza, produktu, przepływu pracy lub klienta.

Dodaj kontrolę znoszenia, zanim zaczniesz promować tańsze trasy

Zmiana zachowania modelu, cen, podpowiedzi i obciążenia pracą. Trasa, która była bezpieczna w zeszłym miesiącu, może stać się słaba po szybkiej rewizji lub aktualizacji modelu.

Podstawowa pętla kontroli znoszenia powinna obejmować:

• Przykładowe ostatnie zlecenia produkcyjne według klasy zadania.
• Usuń lub przekształć wrażliwe dane zgodnie z zasadami.
• Odtwórz próbki na trasach bieżących i potencjalnych.
• Porównaj jakość, ważność schematu, zachowania związane z odmową, koszt i opóźnienia.
• Przeglądaj niepowodzenia według kategorii, a nie tylko wyniku zbiorczego.
• Promuj tańszą trasę tylko wtedy, gdy spełnia ona wymogi dotyczące minimalnej jakości i ograniczenia operacyjne.
• Wyznacz nową trasę dla niewielkiego odsetka ruchu.
• Automatyczne przywracanie w przypadku awarii schematu, przekroczenia kosztów, naruszenia opóźnień lub eskalacji w wyniku weryfikacji ręcznej.

Zalecenie: uczyń promocję trasy wydarzeniem mającym na celu zarządzanie zmianami. Zapisz, kto go zatwierdził, jaki zestaw ewaluacji przeszedł, na jaki procent ruchu wpływa, kiedy wygasa lub wymaga sprawdzenia, i jak działa wycofywanie.

Daj zespołom zastąpienia, ale spraw, by wygasły

Istnieją uzasadnione powody, aby zastąpić routing: incydent u dostawcy, nadzwyczajna sytuacja budżetowa, kontrola zgodności, eskalacja klienta lub regresja modelu. Problemem nie jest przesterowanie. Problemem jest zastąpienie, które staje się niewidoczną, trwałą polityką.

Każde zastąpienie powinno zawierać:

• Zakres: najemca, aplikacja, API klucz, klasa zadania, model, dostawca lub region.
• Powód: incydent, budżet, jakość, zgodność, opóźnienie lub żądanie klienta.
• Osoba zatwierdzająca.
• Godzina rozpoczęcia i godzina wygaśnięcia.
• Oczekiwany wpływ na koszty, opóźnienia i jakość.
• Warunek wycofania.

Wygasłe zastąpienia powinny zakończyć się niepowodzeniem w normalnych zasadach routingu lub wymagać odnowienia. Dzięki temu decyzje awaryjne nie staną się ukrytym ryzykiem związanym z kosztami lub jakością.

Kompromisy w sposób wyraźny

Routing uwzględniający koszty wiąże się z rzeczywistymi kosztami operacyjnymi. Nadal warto to zrobić, gdy wydatki na LLM są znaczne, ale kompromisy powinny być widoczne.

• Zależność metadanych: jakość routingu zależy od dokładnych etykiet zadań i metadanych obciążenia. Brakujące etykiety kierują ruch w stronę konserwatywnych ustawień domyślnych.
• Konserwacja ewaluacji: ewaluacja zadań wymaga aktualizacji w miarę zmiany podpowiedzi, produktów i zachowań użytkowników.
• Złożoność dostawcy: rabaty na pamięć podręczną i partie mogą poprawić ekonomię, ale komplikują logikę routingu.
• Zagrożenie przenośnością: funkcje specyficzne dla dostawcy powinny znajdować się w kartach i zapisach możliwości, a nie w kodzie produktu.
• Niepewność oszacowania: ostateczna długość wyniku, wywołania narzędzi, ponowne próby i trafienia w pamięć podręczną nie są w pełni znane przed wykonaniem.
• Wyjaśnialność: agresywna optymalizacja może sprawić, że zachowanie produktu będzie trudne do wyjaśnienia, chyba że każda decyzja zostanie zarejestrowana wraz z wersją zasad i kodami przyczyny.

Lista kontrolna wdrożenia

• Definiuj klasy zadań dla najważniejszych przepływów pracy LLM według wydatków i wpływu biznesowego.
• Utwórz zestawy ewaluacyjne i minimalne wartości dla każdej klasy zadań.
• Utwórz rejestr możliwości dostawców i modeli.
• Przechowuj aktualne tabele cen i modyfikatory cen według dostawcy, modelu i trybu wykonania.
• Oszacuj tokeny wejściowe, oczekiwane tokeny wyjściowe, kwalifikowalność pamięci podręcznej, kwalifikowalność partii i ryzyko ponownych prób.
• Przed optymalizacją kosztów filtruj kandydatów według ograniczeń związanych z zarządzaniem.
• Wybierz najtańszy model dopiero po przekroczeniu progów dotyczących możliwości i jakości.
• Zapisuj wybrane i odrzucone trasy z kodami przyczyny.
• Porównaj szacowany koszt z ustalonym użytkowaniem i danymi na fakturze.
• Przed promowaniem tańszych tras przeprowadzaj okresowe powtórki.
• Zmiana trasy na Wyspach Kanaryjskich i zdefiniowanie wyzwalaczy wycofywania.
• Wymagaj dat wygaśnięcia ręcznych zastąpień.

Wniosek

Praktycznym celem nie jest kierowanie każdego żądania do tańszego modelu. Celem jest zaprzestanie przepłacania za rutynową pracę, przy jednoczesnej ochronie jakości, umów, zasad zarządzania i przejrzystości.

Zbuduj router w oparciu o klasy zadań, minimalne poziomy jakości, możliwości dostawcy, szacunki kosztów i dzienniki zasad. Następnie wybierz kwalifikującą się trasę o najniższym koszcie. To jedno słowo „odpowiedni” odróżnia routing uwzględniający koszty od routingu najtańszego modelu.

Powiązana lektura

• limity wydatków na poziomie bramy