Tak, mały model lokalny może kierować żądania do większych modeli z wystarczającą niezawodnością, by było to przydatne, ale nie na tyle dużą, by mógł być jedynym mechanizmem bezpieczeństwa. Routing modeli sprawdza się najlepiej, gdy lokalny router rozwiązuje problem optymalizacyjny: które żądania prawdopodobnie są na tyle łatwe, by obsłużył je tańszy lub mniejszy model? W przypadku zadań o dużej wadze, niejednoznacznych, wymagających długiego kontekstu lub intensywnego użycia narzędzi należy nadal stosować deterministyczne reguły eskalacji.
Celem nie jest idealne przewidywanie „inteligencji”. Chodzi o ograniczenie zbędnych, kosztownych wywołań modeli przy zachowaniu kosztu błędów routingu w określonych granicach.
O czym tak naprawdę decyduje lokalny router modeli?
Przychodzące żądanie
|
v
Mały lokalny router
|
+-- łatwe / rutynowe ----> mały model lokalny
|
+-- trudne / niepewne --> większy model lokalny
|
+-- wymagany model frontier ---> model w chmurze
Router może być klasyfikatorem, systemem podobieństwa opartym na osadzeniach, małym LLM-em, modelem preferencji wyuczonym na danych lub połączeniem reguł i wyuczonych ocen.
Projekty takie jak RouteLLM pokazują ten schemat: generują wynik, który wraz z progiem służy do wyboru między słabym a mocnym modelem.
Dlaczego próg jest ważniejszy niż etykieta routera
Router, który oznacza żądanie jako „łatwe” lub „trudne”, ukrywa właściwą decyzję operacyjną. Wynik i próg pozwalają wybrać kompromis między kosztem a jakością.
wynik routera: oszacowana potrzeba użycia mocnego modelu
0.0 -------------------------- 1.0
łatwe trudne
próg = 0.35
wynik >= 0.35 -> eskaluj
Dokumentacja RouteLLM zaleca dostosowanie progu na podstawie zapytań przypominających rzeczywiste obciążenie, ponieważ odsetek żądań kierowanych do mocnego modelu zmienia się wraz z rozkładem żądań. To ostrzeżenie jest szczególnie istotne w domu: zestaw poleceń Home Assistant, pytań o kodowanie, prywatnych zapytań RAG, wyszukiwań rodzinnych i zadań wymagających dłuższego rozumowania zupełnie nie przypomina ogólnego benchmarku.
Ustal twarde reguły eskalacji przed wdrożeniem routingu opartego na uczeniu
Niektóre żądania powinny całkowicie omijać mały router.
| Typ żądania | Zalecana ścieżka | Dlaczego |
|---|---|---|
| Prosta klasyfikacja / formatowanie | Mały lokalny model | Niska złożoność i łatwa weryfikacja |
| Znana intencja sterowania domem | Deterministyczny / mały lokalny model | Szybkie i ograniczone |
| Debugowanie dużej bazy kodu | Duży model | Długi kontekst + rozumowanie |
| Decyzja o dużej wadze | Duży model + weryfikacja | Wysoki koszt błędu |
| Nieznane żądanie użycia narzędzia | Eskaluj lub wymagaj zatwierdzenia | Ryzyko związane z uprawnieniami |
| Pewność routera bliska progowi | Duży model | Konserwatywna ścieżka awaryjna |
Pozwala to zapobiec sytuacji, w której błędy routingu przeradzają się w błędy bezpieczeństwa. Warto zapoznać się z przewodnikiem ZimaSpace po granicach zaufania przy wykonywaniu narzędzi: wybór modelu i przyznanie uprawnień do wykonania działania niepożądanego to odrębne decyzje.
Co oznacza „niezawodny” w przypadku routera?
Mierz błędy, na których naprawdę Ci zależy. Router może wyglądać na ogólnie dokładny, a mimo to kierować najgorsze możliwe prompty do słabego modelu.
Śledź co najmniej:
- wskaźnik pominięć mocnego modelu: prompty wymagające eskalacji, które pozostały przy małym modelu;
- wskaźnik niepotrzebnych eskalacji: łatwe prompty przekazane do kosztownego modelu;
- powodzenie całego zadania: czy końcowy proces zakończył się poprawnie?
- opóźnienie: czy routing spowodował większe opóźnienie, niż udało mu się zaoszczędzić?
- koszt lub zużycie energii: ile kosztownych wywołań modelu udało się uniknąć?
W wielu systemach domowych błędy mocnego modelu powinny mieć większą wagę niż niepotrzebne eskalacje. Dodatkowe wywołanie modelu jest zwykle tańsze niż ciche zwrócenie błędnej komendy tworzenia kopii zapasowej lub nieprawidłowego planu automatyzacji.
Przeprowadź okresową ewaluację w trybie cienia
Zanim pozwolisz routerowi wybierać modele produkcyjne, uruchom go w trybie cienia:
- wysyłaj każde żądanie przez obecnie zaufaną ścieżkę;
- zapisuj, który model wybrałby router;
- porównuj offline odpowiedzi małego i dużego modelu;
- oznaczaj błędy według kategorii żądań;
- wybierz próg na podstawie akceptowalnej liczby pominięć;
- dopiero wtedy włącz automatyczne kierowanie.
Kilkaset reprezentatywnych próśb domowych jest zwykle bardziej przydatne niż pogoń za wynikiem w publicznym rankingu, który mierzy inną dziedzinę.
Rozmowy wieloturowe są trudniejsze niż pojedyncze prompty
Skierowanie pojedynczego pytania, takiego jak „przekonwertuj tę datę”, jest łatwiejsze niż skierowanie piątej tury rozmowy, w której ważny kontekst znajduje się we wcześniejszych wiadomościach.
Obecna implementacja kontrolera RouteLLM wyraźnie zaznacza, że jego routery trenowano na danych z pierwszych tur rozmowy, a kierowanie w rozmowach wieloturowych wymaga dalszych badań. To dobre ogólne ostrzeżenie: router oceniający wyłącznie ostatnie zdanie użytkownika może zobaczyć „tak, zrób to” i nie mieć pojęcia, że „to” oznacza złożoną migrację infrastruktury.
Dostępne opcje:
- kieruj zapytania na podstawie zwięzłego podsumowania rozmowy i ostatniej wypowiedzi;
- przypisz jeden model na cały czas trwania zadania;
- automatycznie przekazuj zadanie dalej po użyciu narzędzia lub rozpoczęciu pracy z długim kontekstem;
- niech mocniejszy model przejmie zadanie, gdy mały model poprosi o pomoc.
Czy mały model potrafi stwierdzić, że nie jest pewien?
Pewność deklarowana przez model jest przydatnym sygnałem, ale nie daje gwarancji. Modele mogą z przekonaniem podawać błędne odpowiedzi.
Bezpieczniejszy router łączy sygnały:
wynik routingu =
wyuczona trudność
+ długość kontekstu
+ wymaganie dotyczące narzędzia
+ reguła domenowa
+ ważność dla użytkownika
+ kategoria wcześniejszej porażki
Na przykład model 3B może zaklasyfikować „streść tę notatkę składającą się z dwóch akapitów” jako bezpieczne zadanie lokalne, podczas gdy deterministyczna reguła przekazuje dalej każde żądanie zawierające plan zmian w infrastrukturze, operację na kluczu szyfrującym lub instrukcję finansową/prawną.
Wykorzystaj weryfikację, by wykrywać zadania wymagające eskalacji, które jej nie otrzymały
Niektóre zadania małego modelu można łatwo zweryfikować. JSON można sprawdzić pod kątem zgodności ze schematem. Kod można przetestować. Przenoszenie plików można najpierw przeprowadzić w trybie próbnym. Odpowiedzi oparte na wyszukanych informacjach można uzależnić od podania cytowań. Można też sprawdzić, czy klasyfikator wybiera tylko dozwolone etykiety.
Jeśli walidacja się nie powiedzie, przekaż to samo zadanie większemu modelowi wraz z pierwotnym kontekstem i błędem walidacji.
wynik małego modelu
|
v
walidator
| |
zaliczone niezaliczone
| |
gotowe v
duży model
Dzięki temu routing staje się systemem adaptacyjnym zamiast jednorazowego zgadywania.
Dlaczego routing sprawdza się na domowym serwerze AI
Domowy serwer często ma do dyspozycji tani model działający przez cały czas, ale jego możliwości uruchamiania większego modelu lokalnego są ograniczone. Może mieć też dostęp do zaawansowanego API, które obsłuży trudne zadania. Routing pozwala systemowi domowemu wykonywać rutynowe zadania prywatnie i tanio, a eskalować tylko wybrane.
To uzupełnienie szerszego modelu kosztów lokalnej, API i hybrydowej AI: system hybrydowy nie musi obsługiwać każdego promptu na tym samym poziomie mocy obliczeniowej.
Zachowawcza polityka routingu do użytku domowego
- Domyślnie używaj małego modelu do powtarzalnego wyodrębniania danych, tagowania i formatowania.
- Eskaluj zapytania przekraczające przetestowany próg złożoności.
- Zawsze eskaluj zadania z kategorii wysokiego ryzyka, niezależnie od wyniku.
- Eskaluj zadania, gdy walidacja się nie powiedzie.
- Eskaluj niejednoznaczne zadania obejmujące wiele tur rozmowy.
- Zapisuj decyzje routingu i ich wyniki.
- Przeprowadzaj ponowną kalibrację, gdy zmieniają się modele, prompty lub rodzaj przetwarzanych zadań.
- Zachowaj ręczne ustawienie „użyj najmocniejszego modelu”.
FAQ
Czy sam router musi być LLM-em?
Nie. Mały klasyfikator, model podobieństwa oparty na embeddingach, silnik reguł lub router preferencji uczony maszynowo mogą działać szybciej i być łatwiejsze do skalibrowania.
Czy routing może zagwarantować taką samą jakość jak korzystanie zawsze z największego modelu?
Nie. Routing wiąże się z kompromisami. Można ograniczyć liczbę pominiętych eskalacji, stosując zachowawcze progi, sztywne zasady eskalacji i mechanizmy walidacji, ale zawsze istnieje ryzyko zmiany rozkładu danych i błędów klasyfikacji.
Czy router powinien wybierać zarówno narzędzia, jak i modele?
Może pomagać w klasyfikowaniu intencji, ale autoryzacja narzędzi powinna pozostać w osobnej warstwie polityk. Wybór modelu to decyzja optymalizacyjna, a uprawnienia do wykonywania uprzywilejowanych operacji to kwestia bezpieczeństwa.
Ostateczny werdykt
Niewielki model lokalny może pełnić rolę routera, jeśli ustawisz go zachowawczo, zadbasz o mierzalność i możliwość jego wymiany. Kalibruj go na rzeczywistych zapytaniach, określaj kategorie, które zawsze wymagają eskalacji, weryfikuj wyniki tańszego modelu i monitoruj błędy większego modelu. Zadaniem routera nie jest udowodnienie, że mały model jest wystarczająco dobry. Ma zdecydować, kiedy warto użyć większej mocy obliczeniowej, by zmniejszyć ryzyko.
Centrum technologii i AI
Więcej do przeczytania

Qwen3.8-27B z DSpine: Jak modele robocze przyspieszają wnioskowanie
Poznaj wstępny model DSpine firmy Tencent dla Qwen3.8-27B, zinterpretuj akceptację szkiców i zaprojektuj kompleksowe porównanie w SGLang.

Eksperyment Linum za 21 tys. dolarów z generowaniem obrazów z tekstu: co potrafi wygenerować model o 2 mld parametrów
Sprawdź, co pokazuje publikacja badawcza Linum o 2B P-JiT, jak kompresuje tokeny obrazu oraz które twierdzenia dotyczące wyników i kosztów treningu wymagają kontekstu.

Czy 64 GB pamięci RAM naprawdę wystarczy, żeby uruchomić DeepSeek V4 Flash 284B bez karty graficznej?
Przeanalizuj opisywane uruchomienie DeepSeek V4 Flash z 64 GB pamięci RAM, wykorzystujące wyłącznie CPU, w tym niestandardową kwantyzację, budżet pamięci, szybkość dekodowania i ograniczenia...



