Model routing LLM: 6 reguł, które tną rachunek za AI o 60–80%

Większość zespołów AI płaci 5–30× za dużo, bo wysyła każdy prompt do flagowego modelu. Streszczenie e-maila kosztuje tyle samo co analiza umowy. Model routing to warstwa decyzyjna, która przydziela zadanie do najtańszego modelu, który jeszcze daje wymaganą jakość. Sześć reguł poniżej to konkret oparty na wdrożeniach produkcyjnych — z liczbami, kodem i konkretnym stosem narzędzi.

Dlaczego routing modeli LLM to teraz dźwignia #1 w FinOps dla AI

Trzy liczby, które oddają skalę problemu w 2026:

• 30× — różnica w cenie input tokena między flagowym modelem (Claude Opus 4.7, GPT-flagship) a modelem klasy „mini / haiku / flash” tego samego producenta.
• 70–85% — udział wywołań w typowym SaaS-ie B2B z LLM-em pod maską, które nie wymagają flagowego modelu (klasyfikacja, ekstrakcja, prosty rewrite, summarization < 4k tokenów).
• 60–80% — typowa redukcja rachunku po wdrożeniu prostego, dwupoziomowego routera bez mierzalnego pogorszenia metryk jakości.

Te liczby to mediana z audytów floomi, które robimy u klientów. Pełną metodologię opisaliśmy w audycie kosztów AI — tu skupiamy się na samej warstwie routingu.

Problem jest strukturalny: zespoły inżynierskie wybierają model raz — przy MVP — i zostają na nim, bo „działa”. Działa, ale 80% obciążenia to zadania, w których model dwie półki niżej dałby identyczny wynik za ułamek ceny. To nie optymalizacja „potem” — to zostawione na stole pieniądze, które rosną liniowo z ruchem.

Reguła 1 — Klasyfikuj zadania według wymaganego „IQ”, nie nazwy feature'a

Nie istnieje coś takiego jak „model dla naszego asystenta”. Asystent obsługuje 10–40 różnych typów zadań, każde z innym profilem wymagań.

Praktyczny framework — trzy klasy złożoności:

Konkret wdrożeniowy: zacznij od listy 20 najczęstszych call-paths w twoim systemie, przypisz każdej klasę i przelicz koszt aktualny vs. koszt po-routingu. Z naszych audytów: ~70% pozycji okazuje się L1, ~20% L2, tylko 5–10% to faktyczny L3 — a płacisz za flagship dla 100%.

Reguła 2 — Cheap-first cascade z eskalacją na fail

Najprostszy router, który działa, to kaskada: najpierw najtańszy model, eskalacja tylko gdy odpowiedź zawiedzie walidację.

# Pseudokod — cheap-first cascade
def route(prompt, schema):
    for model in ["haiku", "sonnet", "opus"]:
        response = llm_call(model, prompt)
        if validate(response, schema):
            return response, model
    raise EscalationFailed

Kluczowy element to deterministyczna walidacja — schema JSON, regex na strukturę, sprawdzenie czy klasa należy do skończonego zbioru, długość, hash/checksum. Bez walidacji kaskada nie ma jak rozpoznać porażki.

Reguła 3 — Routuj po długości i typie kontekstu, nie po nazwie modelu

Drugi co do wagi predyktor kosztu to długość kontekstu — i tu większość zespołów płaci podwójnie.

1. Twarda granica context size w routerze. Promtu poniżej 4k tokenów nie wysyłaj do modelu z oknem 200k, nawet jeśli jest to „ten sam Claude”. Mini-warianty są tańsze i równie skuteczne dla krótkich promptów.
2. Modele „long context-native” tylko gdy musisz. Gemini z 1M oknem ma sens dla pełnej analizy kodu, nie dla 30-stronicowego PDF — ten zmieści się w 32k.
3. Sprawdź, czy model rozliczany jest progowo. Niektórzy dostawcy (Anthropic, Google) mają wyższy bracket cenowy powyżej pewnego progu (np. 200k tokens) — przekroczenie progu o 1 token podnosi cenę całego promptu o ~2×.

Reguła kciuka: jeśli mediana promptu w danym call-path < 8k tokens, model z oknem ≤ 32k jest właściwym wyborem. Płacenie premium za „okno na zapas” to klasyczna pułapka.

Reguła 4 — Semantyczny klasyfikator zamiast prompta-routera

Pokusa: „użyję LLM-a do wybierania, do którego LLM-a wysłać prompt”. Nie rób tego. Każde wywołanie routera-LLM dodaje 200–800 ms latencji i 0,001–0,005 USD per request — przy skali zjada większość oszczędności.

Lepiej: klasyfikator oparty na embeddings.

# Tani, szybki, deterministyczny router
embedding = embed(prompt)                  # ~$0.00002, < 50ms
class_probs = classifier.predict(embedding)  # lokalny sklearn / xgboost
target_model = ROUTING_TABLE[class_probs.argmax()]

• Embedding model:text-embedding-3-small, voyage-3-lite, lub open-source bge-small. Koszt: rząd 0,01–0,02 USD za 1M tokens.
• Klasyfikator: logistic regression / XGBoost wytrenowany na 500–2000 oznaczonych promptach. Trening na laptopie, < 1 godziny.
• Routing table: statyczny dict mapujący klasy → modele.

Czas decyzji routingu: 40–80 ms, koszt: ~10× niższy niż prompt-router. Dodatkowo całkowicie deterministyczny — łatwo testowalny i debugowalny. Dla projektów bez zbioru treningowego: start z prostym keyword/regex routerem, zbieraj logi przez 2 tygodnie, potem dotrenuj embeddings-classifier.

Reguła 5 — Prompt caching jako mnożnik routingu

Routing i caching to dwie ortogonalne osie. Połączone dają efekt multiplikatywny — ale tylko jeśli prompty mają stabilną strukturę.

Co cache'ować:

• System prompt (zwykle 500–4000 tokens, identyczny dla wszystkich wywołań) — cache hit obniża jego koszt o ~90%.
• Stały kontekst RAG-owy — dokumentacja, instrukcje, schematy.
• Few-shot examples — szczególnie gdy używasz tych samych 5–10 przykładów dla całej kategorii zadań.

Anthropic prompt caching: 5-minutowe TTL, cena cache write ~25% więcej niż normalny input, cache read ~10% ceny inputu. Break-even już przy 2 wywołaniach w oknie 5 min.

OpenAI automatic caching: włącza się gdy prompt > 1024 tokens i prefiks się powtarza. Discount ~50% na cached portion. Brak akcji wymaganej, ale kolejność elementów w promptcie ma znaczenie — zmienne dane muszą iść na końcu.

Kombinacja routing + caching w praktyce:

Bez nic:            100% × $1.00 = $1.00 / 1M req
Sam routing:        20% × $1.00 + 80% × $0.05 = $0.24 / 1M req
Routing + caching:  20% × ($0.30 cached + $0.70 fresh) + 80% × $0.05 = $0.12 / 1M req

To 8× mniej od baseline, bez zmiany w żadnym prompcie. Same dwie warstwy infrastruktury.

Reguła 6 — Mierz koszt per useful output, nie koszt per token

Najpoważniejszy błąd FinOps dla AI: metryka $/1M tokens. Sama w sobie nic nie mówi. Właściwa metryka: koszt per useful output (CPUO).

CPUO = (suma kosztu LLM dla zadania) / (liczba zadań zakończonych sukcesem biznesowym)

Co to znaczy „sukces biznesowy” zależy od feature'a:

• Klasyfikacja → prawidłowa klasa zatwierdzona przez walidator.
• Generacja maila sprzedażowego → mail wysłany (nie odrzucony przez review).
• Analiza umowy → raport zaakceptowany przez prawnika bez przeróbek.
• Asystent kodowania → kod zmergeowany do mastera.

Dlaczego to ważne: tani model, który halucynuje w 30% przypadków, jest droższy niż drogi model z 2% błędu — jeśli wliczysz koszt retry, eskalacji do człowieka i opportunity cost złej decyzji biznesowej.

Konkretny przykład — pricing assistant w hurtowni:

Cascade wygrywa nie tylko cenowo, ale daje też najlepszy CPUO — niższy niż czysty mini (mimo wyższego kosztu per call), bo nie generuje zwrotów z błędnej rekomendacji ceny.

Mapa modeli — czym zastąpić GPT-4o w 2026

Tabela orientacyjna (sprawdź aktualne ceny — zmieniają się co kwartał):

Reguła kciuka cenowa (2026): flagship modele kosztują rzędu $3–15 / 1M input tokens, mid-tier $0.50–3, najtańsze $0.05–0.30. Różnica 30–100× — w skali milion requestów dziennie to różnica między $1k a $100k miesięcznie.

Stack do wdrożenia routingu — co wybrać

Trzy realne opcje, w kolejności rosnącej kontroli:

1. OpenRouter — najszybszy start

• Agreguje 200+ modeli pod jednym API kompatybilnym z OpenAI SDK.
• Routing ręczny (ty wybierasz model) + automatyczny fallback gdy provider down.
• Markup ~5% nad ceną providera — czasem tańszy niż direct (lepsze rate cards).
• Brak własnego klasyfikatora — musisz dorobić warstwę decyzji.

Kiedy: prototyp, mały zespół, chcesz testować różne modele bez pisania integracji.

2. LiteLLM — open-source, self-hosted proxy

• Proxy server kompatybilny z OpenAI API.
• Wbudowany router: cost-based, latency-based, load-balancing, fallback chains.
• Cache (Redis), rate limiting per klucz, observability (Langfuse, OpenTelemetry).
• Plik konfiguracyjny YAML — wszystko deklaratywnie.

Kiedy: masz zespół DevOps, chcesz pełną kontrolę nad routingiem i logami, nie chcesz oddawać metadanych zewnętrznej platformie.

3. Portkey / Helicone / Vellum — managed gateway

• LiteLLM jako SaaS, z UI, A/B testami modeli, prompt versioning, guardrails.
• Płacisz za convenience i visibility — typowo $0.001–0.01 per request.
• Najlepsze do zespołów product/non-tech, które chcą zmieniać routing bez deploya.

Kiedy: dojrzały produkt, dużo eksperymentów na modelach, potrzeba audytu i compliance.

Najczęstsze błędy przy wdrażaniu routingu modeli

1. Routing bez walidacji wyjścia. Cheap-first cascade działa tylko gdy umiesz zidentyfikować porażkę. Bez tego degradujesz jakość po cichu.
2. Routing LLM-em. „Niech GPT-4o zdecyduje, którego modelu użyć” — dodaje koszt i latencję, niedeterministyczne. Embeddings + klasyfikator zawsze wygrywa.
3. Brak per-feature accounting. Jeden wspólny budżet na „AI” zaciemnia widoczność. Każdy feature / endpoint powinien mieć osobny cost center w logach.
4. Optymalizacja na rachunku, nie na CPUO. Tani model z 40% błędem nie jest tańszy — jest droższy w ukryciu (retry, support tickety, churn).
5. Routing bez observability. Bez logowania {model_used, tokens_in, tokens_out, latency, validation_result} per request nie da się tuningować. Langfuse, Helicone, OpenTelemetry — wybierz cokolwiek, ale loguj.
6. Pomijanie cachingu. Routing daje 5–10× redukcji, caching kolejne 2–5×. Razem to 10–50×. Robienie tylko jednego z dwóch zostawia pieniądze na stole.
7. Zostawienie routingu jako „TODO”. Wdrożenie to 1–2 dni pracy, ROI w pierwszym tygodniu. Każdy dzień zwłoki to spalone pieniądze proporcjonalne do ruchu.

FAQ

Czy routing modeli LLM działa też dla małych projektów?

Tak — break-even jest niski. Przy wydatku rzędu 200–500 USD/mies. na LLM-y wdrożenie podstawowego routera Haiku → Sonnet zwraca się w pierwszym tygodniu. Im większy ruch, tym większy bezwzględny zysk, ale procentowo zysk jest podobny niezależnie od skali.

Czy fine-tuning małego modelu open-source nie jest lepszy niż routing?

To komplementarne podejścia, nie konkurencyjne. Fine-tuned Llama 8B / Mistral 7B na specyficznym zadaniu bywa lepszy i tańszy niż każdy model komercyjny dla tego konkretnego zadania. Sensowne jako dodatek do routera: dla wąskiej, wysokowolumenowej klasy zadań fine-tunuj własny model, dla reszty używaj kaskady komercyjnej.

Czy routing nie zwiększa ryzyka utraty jakości?

Tylko jeśli wdrożony bez metryk. Z poprawną walidacją + monitorowaniem CPUO routing poprawia jakość — bo widzisz, które klasy zadań faktycznie wymagają flagshipa, a które nie. Większość zespołów odkrywa, że na flagship'ie też mieli błędy, których nie mierzyli.

Ile czasu zajmuje wdrożenie routera w produkcji?

Wersja MVP — LiteLLM proxy + statyczna tabela routingu po endpoincie — 1–2 dni roboczo dla jednego inżyniera. Dojrzała wersja z embeddings classifier, cachingiem i pełną observability — 1–2 tygodnie. ROI typowo w pierwszym miesiącu.

Czy mogę zacząć od jednego providera (np. tylko Anthropic) zamiast multi-vendor?

Tak — i często to dobry start. Sama kaskada Haiku 4.5 → Sonnet 4.6 → Opus 4.7 w obrębie Anthropic daje 70–80% z całkowitej oszczędności możliwej do uzyskania. Multi-vendor dodaje kolejne ~10–20% i odporność na outage, ale komplikuje compliance i logging.

Jak rozpoznać, że nasz zespół już ma problem z kosztami AI?

Trzy sygnały: (1) rachunek od OpenAI / Anthropic / Google rośnie szybciej niż ruch, (2) > 60% wywołań idzie do jednego flagowego modelu, (3) nikt w zespole nie potrafi z pamięci powiedzieć, jaki jest koszt jednego zadania end-user. Jeśli masz dwa z trzech — routing zwróci się błyskawicznie.

Podsumowanie

Model routing to nie mikro-optymalizacja — to architektoniczna decyzja, która w 2026 odróżnia firmy AI z marżą od firm, które subsydiują OpenAI z własnej runway. Sześć reguł z tego artykułu:

1. Klasyfikuj zadania (L1/L2/L3), nie feature'y.
2. Kaskada cheap-first z walidacją eskalacji.
3. Routuj po długości kontekstu, znaj progi cenowe providerów.
4. Klasyfikator na embeddings, nie router-LLM.
5. Caching jako mnożnik — Anthropic 90% rabat, OpenAI auto 50%.
6. Mierz koszt per useful output, nie per token.

Każda z nich osobno daje 20–40% oszczędności. Razem — 60–80%. Wdrożenie: dni, nie miesiące. Stack: LiteLLM + embeddings classifier + Langfuse. Vendor lock-in: zero.

Następny krok: wypisz 20 najczęstszych wywołań LLM w swoim systemie, przypisz klasę złożoności i porównaj koszt aktualny vs. koszt po routingu. Jeśli chcesz, żebyśmy zrobili to z tobą — umów audyt kosztów AI. Pierwsza rozmowa diagnostyczna jest bezpłatna; raport z konkretnymi liczbami i planem wdrożenia dostajesz w 2 tygodnie.

— Andrzej Datta, floomi. Pytania, komentarze, własne case'y: hello@usefloomi.com.