Hvordan dirigere LLM-forespørsler til riktig modell for hver oppgave

Kort svar: Rut forespørslene i applikasjonen din, og bruk deretter én CometAPI-nøkkel og den OpenAI-kompatible base-URL-en https://api.cometapi.com/v1 for å kalle den valgte modellen. Send repetitivt, lett å kontrollere arbeid til et lavkostnivå; latenssensitiv kundedialog til et raskt nivå; og tvetydig eller høy-innvirkningsarbeid til et høy-presisjonsnivå. Behold etikettene som din egen policy—ikke som en universell modellrangering—og mål hvert nivå på det samme testsettet.

Denne veiledningen bygger den tredelte ruteren med et kompakt Python-eksempel, avgrenset fallback og en kostnadsmodell som teller retrier og avviste utdata. Eksemplet bruker gjeldende modell-ID-er fra CometAPI-katalogen, men rutelogikken holdes separat slik at modeller kan byttes uten å skrive om applikasjonen.

Hva er LLM-ruting?

LLM-ruting er prosessen med å sende hver forespørsel til modellen eller tjenestenivået som best passer oppgaven, latensmålet, kvalitetskravet og budsjettet.

Hvordan bør du rute LLM-forespørsler etter oppgave?

Per 20. august 2026 var følgende modell-ID-er og katalogprisfelt tilgjengelige via den offentlige CometAPI Models API. De estimerte sluttbrukerprisene nedenfor anvender katalogens gjeldende ratio på basisprisene for input og output, i tråd med CometAPI-prisveiledningen. Bekreft endelig sats for kontoen din før produksjonsbruk.

«Rask» betyr at ruten har et latensmål; «høy presisjon» betyr at den har et strengere kvalitetsmål. Ingen av etikettene beviser at én modell alltid er raskest eller mest presis. Benchmark p50- og p95-latens, oppgavepassrate og kostnad per akseptert utdata på egen trafikk før du låser mappingen.

Hvordan setter du opp CometAPI for en LLM-router?

Du trenger en CometAPI-API-nøkkel, Python 3.10 eller nyere og OpenAI Python-pakken. Lagre nøkkelen på serversiden i stedet for i kildekoden.

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

Eksemplet bruker POST /v1/chat/completions. CometAPI dokumenterer dette som et delt grensesnitt for flere leverandører, men parameteratferd kan likevel variere mellom modeller. Sjekk gjeldende modelloppføring og Chat Completions-referansen før du legger til leverandørspesifikke felt.

Hva trenger du for å bygge en LLM-router?

• Kartlegg stabile oppgaver til tjenestenivåer. Ikke be en annen LLM om å klassifisere hver forespørsel med mindre enkle applikasjonssignaler er utilstrekkelige. En support-tag er forutsigbart arbeid for billig nivå; et live svar er latenssensitivt; en policy-gjennomgang fortjener den strengeste kvalitetsporten.

• Valider utdata. Vellykket HTTP-status betyr ikke at resultatet er brukbart. Send en oppgavespesifikk validator til ruteren. En klassifiseringsvalidator kan sjekke en tillatt etikett; en validator for kundesvar kan håndheve lengde og forbudte påstander; et strukturert arbeidsløp kan validere et JSON-skjema.

• Fallback med smalt omfang. Prøv neste godkjente rute etter timeout, 408, 429, midlertidig 5xx eller en avgrenset kvalitetsport-feil. Ikke bruk en annen modell for å skjule feilformet input, ugyldig nøkkel eller ikke-støttede parametere.

Hvordan bygger du en LLM-router i Python?

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)

Hvordan begrenser du retrier før fallback?

Hold SDK-retrier på null og pakk hvert modellkall inn i en eksplisitt grense. Hjelperen under retrier kun én gang for retriable API-feil, og kaster deretter slik at den ytre rutingen kan gå videre til neste godkjente nivå.

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))

I route() erstatter du det direkte kallet til client.chat.completions.create(...) med call_model(model, prompt). Med tre nivåer stopper én forespørsel etter maks seks leverandørkall; valideringsfeil eskalerer fortsatt én gang per nivå i stedet for å retrye samme output.

Kjør den med python3 llm_task_router.py. For å bytte leverandører eller modellgenerasjoner senere, oppdater MODELS; oppgavepolicy og responskontrakt blir værende på ett sted.

Eksemplet bruker bare parametere som deles av de valgte modellene. Legg til modellspecifikke tokenkontroller via et adapterlag etter å ha sjekket modellkompatibilitet.

Hvordan tester du en LLM-rutingspolicy?

Bekreft først at den deterministiske policyen velger ønsket primærrute. Dette er ruteforventninger, ikke leverandørytelsesresultater:

En vellykket “live smoke test” returnerer svaret pluss valgt nivå, modell-ID, tokenbruk og alle forsøk. Faktiske token- og latensverdier vil variere:

{  "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    }  ]}

For en reell sammenligning, kjør de samme merkede forespørslene gjennom alle tre modellene. Registrer oppgavepassrate, p50- og p95-latens, feilrate, input- og output-tokens, fallbacksrate og andel menneskelig gjennomgang. Metodikken som vanligvis betyr mest er kostnad per akseptert utdata, ikke kostnad per API-kall.

Hvor mye koster multimodell-ruting?

Bruk én arbeidslastform for en rettferdig sammenligning. Anta 1 million totale tokens: 800 000 input-tokens og 200 000 output-tokens. Ved bruk av katalogavledede satser kontrollert 20. august 2026:

Hvis trafikken er 60 % billig, 30 % rask og 10 % høy presisjon, er projisert blandet tokenkostnad omtrent $1.19 per 1 million totale tokens. Å sende samme miks utelukkende til høy-presisjonsruten ville være omtrent $7.20 under disse forutsetningene. Dette er en prisberegning, ikke et bevis på at den blandede policyen vil oppfylle kvalitetsmålet.

Retrier og avvisninger endrer resultatet. En engangs retry-rate på 5 % øker $1.19-anslaget til omtrent $1.25. Hvis et lavkost-utdata feiler validering og hele forespørselen gjentas på høy-presisjonsnivået, må begge kallene telles. Spor aksepterte utdata slik at en tilsynelatende billig modell ikke skjuler kostnader ved gjennomgang eller regenerering.

Hva er de vanligste feilene ved LLM-ruting?

Feil- og retry-veiledningen anbefaler å retrye ratelimiting og midlertidige plattformfeil med backoff, mens feilformede forespørsler og autentiseringsfeil bør fikses. Fallback-veiledningen holder også modellfallback ordnet og eksplisitt.

Applikasjonsruting vs. CometAPI Auto: Hva bør du bruke?

Bruk applikasjonsruting når kontroll og reproduserbarhet er viktige. Behold beslutningen i koden når oppgaver er stabile, og du trenger faste modellidentiteter, budsjetter per nivå, egendefinerte validatorer og en reviderbar fallback-rekkefølge. Denne tilnærmingen gjør det også enklere å sammenligne samme modellkart på tvers av releaser.

Bruk CometAPI Auto når reduksjon av rutingvedlikehold betyr mest. Sett model=auto for en balansert standard eller model=auto-high når kvalitet har høyere prioritet. CometAPI velger en kvalifisert modell dynamisk basert på forespørselskarakteristika og gjeldende rutingpool, så den underliggende modellen kan variere; det gjør Auto mindre egnet når hver kjøring må bruke samme modell eller modellspecifikke parametere.

Hvordan kjører du LLM-ruting i produksjon?

• Oppdater modellregisteret. Kall GET https://api.cometapi.com/api/models under utrulling eller oppstart, og feile releasen hvis en konfigurert ID eller påkrevd endepunkt mangler. Modell-ID-er, priser og kapabiliteter kan endres.

• Hold leverandørspesifikke alternativer utenfor ruteren. Et felles Chat Completions-grensesnitt gjør ikke alle parametere identiske. For eksempel kan støtte for logprobs, resonnementskontroller eller flere kandidater variere. Legg disse forskjellene i testede adaptere.

• Begrens trafikk og utdata. Begrens samtidighet før forespørsler forlater applikasjonen, bruk eksponentiell backoff med jitter for 429, og sett et tak på antall output-tokens. CometAPIs ratenivå-veiledning anbefaler de samme app-sidige kontrollene.

• Loggfør beslutningen. Registrer oppgavetype, policyversjon, valgt nivå, modell-ID, latens, tokenbruk, valideringsresultat, antall retrier, fallback-årsak og kostnadsestimat. Unngå å logge hemmeligheter eller unødvendig kundedata.

• Promoter ruter med evidens. Behold et merket evalueringssett for hver oppgave. Rull ut endringer i mapping gradvis, sammenlign dem med forrige policy og behold en rask tilbakerullingsvei.

Ofte stilte spørsmål

Bestemmer CometAPI automatisk hvilken modell som er billig, rask eller nøyaktig?

Denne veiledningen beholder den policyen i applikasjonskoden. CometAPI leverer delt nøkkel, base-URL, modellkatalog, Chat Completions-grensesnitt og dokumenterte fallback-byggesteiner. Teamet ditt definerer hva hvert nivå betyr og hvilken modell som har bestått deres tester.

Kan én CometAPI-nøkkel kalle modeller fra ulike leverandører?

Ja. For OpenAI-kompatible tekstruter, bruk https://api.cometapi.com/v1 og endre model-verdien. Gjeldende katalog bør sjekkes før utrulling.

Hvorfor ikke sende alle forespørsler til den billigste modellen?

Laveste tokenpris kan bli dyrt hvis utdata feiler validering, krever retrier eller skaper arbeid for menneskelig gjennomgang. Sammenlign kostnad per akseptert resultat, og hold oppgaver med høy innvirkning bak strengere kvalitetssperrer.

Bør kvalitetsfeil utløse fallback?

Bare når feilen kan oppdages maskinelt og eskaleringen er avgrenset. En skjemafeil, manglende obligatorisk felt eller forbudt lovnad kan rettferdiggjøre én eskalering. Vagt misnøye bør bli evalueringsdata, ikke en uendelig retry-sløyfe.

Hvor ofte bør modellkartet endres?

Endre det når gjeldende katalogdata og en repeterbar evaluering viser en bedre avveining. Ikke roter modeller bare fordi et nytt navn dukker opp i katalogen.

Kan jeg legge til en OpenAI-modell senere?

Ja. Legg til en gjeldende OpenAI-kompatibel modell-ID i MODELS, test samme forespørsels- og responskontrakt, og plasser den i rute-rekkefølgen. Klienten, nøkkelen og base-URL-en forblir uendret.

Hvordan holder du en LLM-rutingspolicy vedlikeholdbar?

Den enkleste flerleverandør-ruteren er ikke en autonom svart boks. Det er en kort, versjonert oppgavepolicy støttet av delt API-tilgang, oppdaterte modellmetadata, en kvalitetsvalidator og en smal fallback-kjede. CometAPI reduserer tilkoblingsarbeidet til én nøkkel og én OpenAI-kompatibel base-URL; applikasjonen din beholder kontroll over beslutninger om kostnad, latens og kvalitet.