Jak przekierowywać żądania LLM do właściwego modelu dla każdego zadania

Krótka odpowiedź: kieruj żądania w aplikacji, a następnie użyj jednego klucza CometAPI i zgodnego z OpenAI bazowego adresu URL https://api.cometapi.com/v1, aby wywołać wybrany model. Przekazuj powtarzalne, łatwe do weryfikacji zadania do niskokosztowego poziomu; interakcje z klientem wrażliwe na opóźnienia do szybkiego poziomu; a niejednoznaczne lub wysokowpływowe zadania do poziomu o wysokiej dokładności. Traktuj etykiety jako własną politykę — nie jako uniwersalny ranking modeli — i mierz każdy poziom tym samym zestawem testowym.

Ten przewodnik buduje router trzech poziomów z kompaktowym przykładem w Pythonie, ograniczonym fallbackiem i modelem kosztów, który liczy ponowne próby i odrzucone wyniki. Przykład używa aktualnych identyfikatorów modeli z katalogu CometAPI, ale logika routingu pozostaje oddzielona, więc modele można wymieniać bez przerabiania aplikacji.

Czym jest routowanie LLM?

Routowanie LLM to proces wysyłania każdego żądania do modelu lub poziomu usług, który najlepiej pasuje do jego zadania, celu opóźnienia, wymogu jakości i budżetu.

Jak routować żądania LLM według zadań?

Na dzień 20 sierpnia 2026 r. następujące identyfikatory modeli i pola cenowe katalogu były dostępne przez publiczne CometAPI Models API. Poniższe szacowane stawki konsumenckie stosują bieżącą wartość ratio katalogu do bazowych cen wejścia i wyjścia, zgodnie z przewodnikiem cenowym CometAPI. Przed użyciem produkcyjnym potwierdź finalną stawkę widoczną dla Twojego konta.

„Szybki” oznacza, że trasa ma cel opóźnienia; „wysoka dokładność” oznacza bardziej rygorystyczny cel jakości. Żadna etykieta nie dowodzi, że jeden model jest zawsze najszybszy lub najdokładniejszy. Zmierz p50 i p95 opóźnienia, odsetek zaliczonych zadań oraz koszt na zaakceptowany wynik na własnym ruchu, zanim utrwalisz mapowanie.

Jak skonfigurować CometAPI dla routera LLM?

Potrzebujesz klucza CometAPI, Pythona 3.10 lub nowszego oraz pakietu OpenAI dla Pythona. Przechowuj klucz po stronie serwera, a nie w kodzie źródłowym.

pip install openaiexport COMETAPI_KEY="your-key-here"

Przykład używa POST /v1/chat/completions. CometAPI dokumentuje to jako współdzielony interfejs dla wielu dostawców, ale zachowanie parametrów może się różnić w zależności od modelu. Sprawdź bieżący wpis modelu i referencję Chat Completions przed dodaniem pól specyficznych dla dostawców.

Czego potrzebujesz, aby zbudować router LLM?

Mapuj stabilne zadania na poziomy usług. Nie proś innego LLM o klasyfikację każdego żądania, chyba że proste sygnały aplikacji są niewystarczające. Znacznik wsparcia to przewidywalnie zadanie niskokosztowe; odpowiedź na żywo jest wrażliwa na opóźnienia; przegląd polityk zasługuje na najsurowszą bramkę jakości.

Waliduj wynik. Sukces HTTP nie oznacza, że wynik jest użyteczny. Przekaż do routera walidator specyficzny dla zadania. Walidator klasyfikacji może sprawdzać dozwoloną etykietę; walidator odpowiedzi do klienta może egzekwować długość i zakazane twierdzenia; ustrukturyzowany przepływ może walidować schemat JSON.

Zawężaj fallback. Wypróbuj następną zatwierdzoną trasę po przekroczeniu czasu, 408, 429, tymczasowym 5xx lub ograniczonej porażce bramki jakości. Nie używaj innego modelu, by ukryć nieprawidłowe dane wejściowe, nieważny klucz lub nieobsługiwane parametry.

Jak zbudować router LLM w Pythonie?

import osimport time​from openai import APIError, OpenAI​client = OpenAI(    api_key=os.environ["COMETAPI_KEY"],    base_url="https://api.cometapi.com/v1",    max_retries=0,    timeout=20,)​MODELS = {    "cheap": "deepseek-v4-flash",    "fast": "gemini-3.7-flash",    "accurate": "claude-opus-5",}​# Put the preferred tier first; later tiers are fallbacks.ROUTES = {    "tag": ["cheap", "fast", "accurate"],    "reply": ["fast", "cheap", "accurate"],    "policy_review": ["accurate", "fast", "cheap"],}​​def retryable(error):    status = getattr(error, "status_code", None)    return status is None or status in {408, 429} or (status and status >= 500)​​def route(task, prompt, validate=lambda text: True):    attempts = []    for tier in ROUTES.get(task, ROUTES["reply"]):        model = MODELS[tier]        started = time.perf_counter()        try:            response = client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )            text = response.choices[0].message.content or ""            attempts.append({                "tier": tier,                "model": model,                "latency_ms": round((time.perf_counter() - started) * 1000),                "accepted": validate(text),            })            if attempts[-1]["accepted"]:                return {                    "text": text,                    "route": tier,                    "model": model,                    "usage": response.usage.model_dump() if response.usage else None,                    "attempts": attempts,                }        except APIError as error:            attempts.append({"tier": tier, "model": model, "status": error.status_code})            if not retryable(error):                raise​    raise RuntimeError(f"No route passed: {attempts}")​​if __name__ == "__main__":    result = route(        "reply",        "Reply to a customer asking when their refund will arrive. Do not promise a date.",        validate=lambda text: 30 <= len(text) <= 600 and "guarantee" not in text.lower(),    )    print(result)

Jak ograniczyć liczbę ponownych prób przed fallbackiem?

Utrzymuj ponowne próby SDK na zerze i obejmij każde wywołanie modelu explicite limitem. Poniższy pomocnik ponawia tylko raz błędy API kwalifikujące się do retry, po czym podnosi wyjątek, aby zewnętrzna trasa mogła przejść do następnego zatwierdzonego poziomu.

MAX_ATTEMPTS_PER_MODEL = 2​def call_model(model, prompt):    for attempt in range(1, MAX_ATTEMPTS_PER_MODEL + 1):        try:            return client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )        except APIError as error:            if not retryable(error) or attempt == MAX_ATTEMPTS_PER_MODEL:                raise            time.sleep(min(0.5 * (2 ** (attempt - 1)), 2.0))

W route() zastąp bezpośrednie wywołanie client.chat.completions.create(...) przez call_model(model, prompt). Przy trzech poziomach jedno żądanie zatrzyma się po maksymalnie sześciu wywołaniach dostawców; porażki walidacji wciąż eskalują raz na poziom zamiast ponawiać ten sam wynik.

Uruchom za pomocą python3 llm_task_router.py. Aby później zmienić dostawców lub generacje modeli, zaktualizuj MODELS; polityka zadań i kontrakt odpowiedzi pozostają w jednym miejscu.

Przykład używa tylko parametrów współdzielonych przez wybrane modele. Dodaj sterowanie tokenami specyficzne dla modelu przez warstwę adaptera po sprawdzeniu kompatybilności modelu.

Jak testować politykę routingu LLM?

Najpierw zweryfikuj, że deterministyczna polityka wybiera zamierzony podstawowy poziom. To są oczekiwania routingu, a nie wyniki wydajności dostawców:

Udany test dymny na żywo zwraca odpowiedź oraz wybraną trasę, ID modelu, użycie tokenów i każdą próbę. Rzeczywiste wartości tokenów i opóźnień będą się różnić:

{  "text": "...",  "route": "fast",  "model": "gemini-3.7-flash",  "usage": {    "prompt_tokens": "measured value",    "completion_tokens": "measured value"  },  "attempts": [    {      "tier": "fast",      "model": "gemini-3.7-flash",      "latency_ms": "measured value",      "accepted": true    }  ]}

Dla realnego porównania uruchom te same oznaczone żądania przez wszystkie trzy modele. Rejestruj odsetek zaliczonych zadań, p50 i p95 opóźnienia, odsetek błędów, tokeny wejściowe i wyjściowe, wskaźnik fallbacków oraz wskaźnik przeglądu przez człowieka. Najczęściej kluczową metryką jest koszt na zaakceptowany wynik, a nie koszt na wywołanie API.

Ile kosztuje routowanie wielomodelowe?

Użyj jednego kształtu obciążenia dla uczciwego porównania. Załóż 1 milion łącznych tokenów: 800 000 tokenów wejściowych i 200 000 wyjściowych. Używając stawek pochodzących z katalogu sprawdzonych 20 sierpnia 2026 r.:

Jeśli ruch to 60% tani, 30% szybki i 10% wysoka dokładność, prognozowany łączny koszt tokenów wynosi około $1.19 na 1 milion łącznych tokenów. Wysłanie tej samej mieszanki w całości do trasy o wysokiej dokładności kosztowałoby około $7.20 przy tych założeniach. To obliczenie cenowe, a nie dowód, że mieszana polityka spełni cel jakości.

Ponowne próby i odrzucenia zmieniają wynik. Jednorazowy wskaźnik ponownych prób 5% podnosi prognozę $1.19 do około $1.25. Jeśli niskokosztowy wynik nie przejdzie walidacji i całe żądanie zostanie powtórzone na poziomie wysokiej dokładności, licz oba wywołania. Śledź zaakceptowane wyniki, aby pozornie tani model nie ukrywał kosztów przeglądu lub regeneracji.

Jakie są najczęstsze porażki routingu LLM?

Przewodnik dotyczący błędów i ponownych prób zaleca ponawianie limitów szybkości i tymczasowych awarii platformy z backoffem, podczas gdy nieprawidłowe żądania i błędy uwierzytelnienia należy naprawić. Przewodnik fallbacku podobnie utrzymuje fallback modeli uporządkowany i jawny.

Routing aplikacyjny vs. CometAPI Auto: którego użyć?

Używaj routingu aplikacyjnego, gdy liczy się kontrola i powtarzalność. Zachowaj decyzję w kodzie, gdy zadania są stabilne i potrzebujesz stałych tożsamości modeli, budżetów per poziom, niestandardowych walidatorów i audytowalnego porządku fallbacku. Takie podejście ułatwia też porównanie tej samej mapy modeli między wydaniami.

Używaj CometAPI Auto gdy ważniejsze jest ograniczenie utrzymania routingu. Ustaw model=auto dla zbalansowanego domyślnego wyboru lub model=auto-high, gdy priorytetem jest jakość. CometAPI wybiera dynamicznie kwalifikujący się model na podstawie charakterystyki żądania i bieżącej puli routingu, więc podstawowy model może się zmieniać; czyni to Auto mniej odpowiednim tam, gdzie każde uruchomienie musi używać tego samego modelu lub parametrów specyficznych dla modelu.

Jak uruchamiać routing LLM w produkcji?

Odśwież rejestr modeli. Wywołuj GET https://api.cometapi.com/api/models podczas wdrożenia lub startu i przerwij wydanie, jeśli brakuje skonfigurowanego ID lub wymaganego endpointu. Identyfikatory modeli, ceny i możliwości mogą się zmieniać.

Trzymaj opcje specyficzne dla dostawców poza routerem. Wspólny interfejs Chat Completions nie czyni każdego parametru identycznym. Na przykład wsparcie dla logprobs, sterowania rozumowaniem czy wielu kandydatów może się różnić. Umieść te różnice w przetestowanych adapterach.

Ogranicz ruch i wyjścia. Ogranicz współbieżność zanim żądania opuszczą aplikację, używaj wykładniczego backoffu z jitterem dla 429 i ustaw limit tokenów wyjściowych. Przewodnik limitów szybkości CometAPI zaleca te same kontrolki po stronie aplikacji.

Loguj decyzję. Rejestruj typ zadania, wersję polityki, wybrany poziom, ID modelu, opóźnienie, użycie tokenów, wynik walidacji, liczbę ponownych prób, powód fallbacku i szacowany koszt. Unikaj logowania sekretów lub niepotrzebnych treści klientów.

Promuj trasy na podstawie dowodów. Utrzymuj oznaczony zestaw ewaluacyjny dla każdego zadania. Wprowadzaj zmiany mapowania stopniowo, porównuj je z poprzednią polityką i zachowuj szybką ścieżkę rollbacku.

Często zadawane pytania

Czy CometAPI automatycznie decyduje, który model jest tani, szybki lub dokładny?

Ten tutorial utrzymuje tę politykę w kodzie aplikacji. CometAPI dostarcza wspólny klucz, bazowy adres URL, katalog modeli, interfejs Chat Completions i udokumentowane elementy budujące fallback. Twój zespół definiuje, co oznacza każdy poziom i który model przeszedł testy.

Czy jeden klucz CometAPI może wywoływać modele od różnych dostawców?

Tak. Dla tras tekstowych zgodnych z OpenAI użyj https://api.cometapi.com/v1 i zmień wartość model. Przed wdrożeniem należy sprawdzić bieżący katalog.

Dlaczego nie wysłać każdego żądania do najtańszego modelu?

Najniższa stawka za token może stać się kosztowna, jeśli wyniki nie przechodzą walidacji, wymagają ponownych prób lub generują pracę przeglądową przez ludzi. Porównuj koszt na zaakceptowany wynik i utrzymuj zadania wysokowpływowe za bardziej rygorystycznymi bramkami jakości.

Czy porażka jakości powinna wyzwolić fallback?

Tylko gdy porażka jest wykrywalna maszynowo i eskalacja jest ograniczona. Błąd schematu, brak wymaganego pola czy zabroniona obietnica mogą uzasadniać jedną eskalację. Niejasne niezadowolenie powinno stać się danymi ewaluacyjnymi, a nie nieograniczoną pętlą ponownych prób.

Jak często powinna zmieniać się mapa modeli?

Zmieniaj ją, gdy bieżące dane katalogowe i powtarzalna ewaluacja pokazują lepszy kompromis. Nie rotuj modeli tylko dlatego, że w katalogu pojawiła się nowa nazwa.

Czy mogę później dodać model OpenAI?

Tak. Dodaj aktualny identyfikator modelu zgodnego z OpenAI do MODELS, przetestuj ten sam kontrakt żądanie–odpowiedź i ustaw go w kolejności tras. Klient, klucz i bazowy adres URL pozostają bez zmian.

Jak utrzymać politykę routingu LLM w dobrej kondycji?

Najprostszy router wielodostawcy nie jest autonomicznym czarnym pudełkiem. To krótka, wersjonowana polityka zadań wsparta wspólnym dostępem do API, bieżącymi metadanymi modeli, walidatorem jakości i wąskim łańcuchem fallbacku. CometAPI redukuje pracę integracyjną do jednego klucza i jednego bazowego adresu URL zgodnego z OpenAI; Twoja aplikacja zachowuje kontrolę nad decyzjami kosztu, opóźnienia i jakości.