Sådan ruter du LLM-forespørgsler til den rette model for hver opgave

Kort svar: Rout forespørgsler i din applikation, og brug derefter én CometAPI-nøgle og den OpenAI-kompatible base-URL https://api.cometapi.com/v1 til at kalde den valgte model. Send gentagne, let-kontrollerbare opgaver til et lavprisniveau; latensfølsomme kundeinteraktioner til et hurtigt niveau; og tvetydige eller højrisiko-opgaver til et høj-nøjagtigheds-niveau. Bevar etiketterne som jeres egen politik—ikke som en universel modelrangering—og mål alle niveauer på det samme testdatasæt.

Denne vejledning bygger den tre-niveaus router med et kompakt Python-eksempel, begrænset fallback og en omkostningsmodel, der tæller retries og afviste outputs. Eksemplet bruger aktuelle model-ID’er fra CometAPI-kataloget, men routing-logikken holdes adskilt, så modeller kan udskiftes uden at omskrive applikationen.

Hvad er LLM-routing?

LLM-routing er processen med at sende hver forespørgsel til den model eller det serviceniveau, der passer bedst til dens opgave, latensmål, kvalitetskrav og budget.

Hvordan bør du route LLM-forespørgsler efter opgave?

Pr. 20. august 2026 var følgende model-ID’er og katalogprisfelter tilgængelige via den offentlige CometAPI Models API. De estimerede forbrugerpriser nedenfor anvender katalogets aktuelle "ratio"-værdi på baseline-priser for input og output i henhold til CometAPI pricing guide. Bekræft den endelige sats, der vises for din konto, før produktionsbrug.

"Hurtig" betyder, at routen har et latensmål; "høj nøjagtighed" betyder, at den har et strengere kvalitetsmål. Ingen af etiketterne beviser, at én model altid er hurtigst eller mest præcis. Benchmark p50- og p95-latens, opgave-beståelsesrate og omkostning pr. accepteret output på din egen trafik, før du gør mappingen permanent.

Hvordan sætter du CometAPI op til en LLM-router?

Du skal bruge en CometAPI API-nøgle, Python 3.10 eller nyere og OpenAI Pythonpakken. Opbevar nøglen på serversiden i stedet for i kildekoden.

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

Eksemplet bruger POST /v1/chat/completions. CometAPI dokumenterer dette som et delt interface for flere udbydere, men parameteradfærd kan stadig variere efter model. Tjek den aktuelle modelelementpost og Chat Completions-reference, før du tilføjer udbyderspecifikke felter.

Hvad behøver du for at bygge en LLM-router?

• Kortlæg stabile opgaver til serviceniveauer. Bed ikke en anden LLM om at klassificere hver forespørgsel, medmindre simple applikationssignaler er utilstrækkelige. Et supports-tag er forudsigeligt lavprisarbejde; et live-svar er latensfølsomt; en politikgennemgang fortjener den strengeste kvalitetsport.
• Valider outputtet. En vellykket HTTP-status betyder ikke, at resultatet er brugbart. Giv routeren en opgavespecifik valideringsfunktion. En klassifikationsvalidator kan tjekke en tilladt etiket; en kundesvarsvalidator kan håndhæve længde og forbudte udsagn; et struktureret workflow kan validere et JSON-skema.
• Begræns fallback. Prøv den næste godkendte route efter en timeout, 408, 429, midlertidig 5xx eller en begrænset kvalitetsport-fejl. Brug ikke en anden model til at skjule misdannet input, en ugyldig nøgle eller ikke-understøttede parametre.

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 begrænser du retries før fallback?

Hold SDK-retries på nul, og omslut hvert modelkald med en eksplicit grænse. Hjælperen nedenfor retrier kun retrybare API-fejl én gang og rejser derefter en fejl, så den ydre route kan gå videre til næste godkendte niveau.

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() skal du erstatte det direkte client.chat.completions.create(...) kald med call_model(model, prompt). Med tre niveauer stopper én forespørgsel efter højst seks udbyderkald; valideringsfejl eskalerer stadig én gang pr. niveau i stedet for at retrye det samme output.

Kør det med python3 llm_task_router.py. For at skifte udbydere eller modelgenerationer senere, opdater MODELS; opgavepolitikken og responskontrakten forbliver samlet ét sted.

Eksemplet bruger kun parametre, der deles af de valgte modeller. Tilføj modelspecifikke token-kontroller via et adapterlag efter at have tjekket modelkompatibilitet.

Hvordan tester du en LLM-routingpolitik?

Verificer først, at den deterministiske politik vælger det tilsigtede primære niveau. Dette er routingforventninger, ikke udbyderpræstationsresultater:

En vellykket live-smoketest returnerer svaret plus det valgte niveau, model-ID, tokenforbrug og alle forsøg. Faktiske token- og latensværdier 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 reel sammenligning, kør de samme mærkede forespørgsler gennem alle tre modeller. Registrer opgave-beståelsesrate, p50- og p95-latens, fejlraten, input- og outputtokens, fallback-rate og menneskelig gennemgangsrate. Den vigtigste metrik er som regel omkostning pr. accepteret output, ikke omkostning pr. API-kald.

Hvor meget koster multi-model routing?

Brug én arbejdsprofil for en fair sammenligning. Antag 1 million samlede tokens: 800.000 inputtokens og 200.000 outputtokens. Ved brug af de katalogafledte satser kontrolleret den 20. august 2026:

Hvis trafikken er 60% billig, 30% hurtig og 10% høj nøjagtighed, er den projicerede blandede tokenomkostning cirka $1.19 per 1 million samlede tokens. At sende den samme blanding helt til høj-nøjagtigheds-routen ville være cirka $7.20 under disse antagelser. Dette er en prisberegning, ikke et bevis på, at den blandede politik vil opfylde dit kvalitetsmål.

Retries og afvisninger ændrer resultatet. En engangs retry-rate på 5% hæver $1.19-projektionen til cirka $1.25. Hvis et lavpris-output fejler validering, og hele forespørgslen gentages på høj-nøjagtigheds-niveauet, så medregn begge kald. Spor accepterede outputs, så en tilsyneladende billig model ikke skjuler omkostninger til review eller regeneration.

Hvad er de mest almindelige fejl ved LLM-routing?

Error and retry guide anbefaler at retrye ratelimits og midlertidige platformfejl med backoff, mens misdannede forespørgsler og autentificeringsfejl bør rettes. Fallback guide holder tilsvarende modelfallback ordnet og eksplicit.

Applikationsrouting vs. CometAPI Auto: Hvad bør du bruge?

Brug applikationsrouting, når kontrol og reproducerbarhed er vigtige. Bevar beslutningen i din kode, når opgaver er stabile, og du har brug for faste modelidentiteter, per-niveau-budgetter, brugerdefinerede validatorer og en reviderbar fallback-rækkefølge. Denne tilgang gør det også lettere at sammenligne den samme modelmapping på tværs af releases.

Brug CometAPI Auto, når reduktion af routingvedligeholdelse er vigtigere. Sæt model=auto for en balanceret standard eller model=auto-high, når kvalitet har højere prioritet. CometAPI vælger en egnet model dynamisk ud fra forespørgselskarakteristika og den aktuelle routing-pulje, så den underliggende model kan variere; det gør Auto mindre egnet, når hvert run skal bruge den samme model eller modelspecifikke parametre.

Hvordan kører du LLM-routing i produktion?

• Opdater modelregistret. Kald GET https://api.cometapi.com/api/models under deployment eller opstart, og afbryd releaset, hvis et konfigureret ID eller et krævet endpoint mangler. Model-ID’er, priser og kapaciteter kan ændre sig.
• Hold udbyderspecifikke indstillinger ude af routeren. En fælles Chat Completions-overflade gør ikke alle parametre identiske. For eksempel kan support for logprobs, reasoning-kontroller eller flere kandidater variere. Placér disse forskelle i testede adaptere.
• Begræns trafik og output. Begræns samtidighed, før forespørgsler forlader applikationen, brug eksponentiel backoff med jitter ved 429, og sæt et output-tokenloft. CometAPI’s rate-limit guide anbefaler de samme applikationssidekontroller.
• Log beslutningen. Registrer opgavetype, politikversion, valgt niveau, model-ID, latens, tokenforbrug, valideringsresultat, retry-antal, fallback-årsag og omkostningsestimat. Undgå at logge hemmeligheder eller unødvendigt kundeinhold.
• Promovér routes med evidens. Bevar et mærket evalueringssæt for hver opgave. Udrul mappingændringer gradvist, sammenlign dem med den forrige politik, og bevar en hurtig rollback-vej.

Ofte stillede spørgsmål

Bestemmer CometAPI automatisk, hvilken model der er billig, hurtig eller præcis?

Denne tutorial holder politikken i applikationskoden. CometAPI leverer den delte nøgle, base-URL, modelkatalog, Chat Completions-interface og dokumenterede fallback-byggesten. Jeres team definerer, hvad hvert niveau betyder, og hvilken model der har bestået jeres tests.

Kan én CometAPI-nøgle kalde modeller fra forskellige udbydere?

Ja. For OpenAI-kompatible tekstruter bruges https://api.cometapi.com/v1, og du ændrer model-værdien. Det aktuelle katalog bør tjekkes før deployment.

Hvorfor ikke sende hver forespørgsel til den billigste model?

Den laveste tokenpris kan blive dyr, hvis outputs fejler validering, kræver retries eller skaber arbejde til menneskelig gennemgang. Sammenlign omkostning pr. accepteret resultat, og hold højrisiko-opgaver bag strengere kvalitetsporte.

Bør kvalitetsfejl udløse fallback?

Kun når fejlen er maskin-detekterbar, og eskaleringen er begrænset. En skemafejl, et manglende påkrævet felt eller et forbudt løfte kan retfærdiggøre én eskalering. Vagt utilfredshed bør blive evalueringsdata i stedet for en ubegrænset retry-løkke.

Hvor ofte bør modelmappet ændre sig?

Ændr det, når aktuelle katalogdata og en gentagelig evaluering viser en bedre afvejning. Rotér ikke modeller blot fordi et nyt navn optræder i kataloget.

Kan jeg tilføje en OpenAI-model senere?

Ja. Tilføj et aktuelt OpenAI-kompatibelt model-ID til MODELS, test den samme request- og responskontrakt, og placer den i route-rækkefølgen. Klient, nøgle og base-URL forbliver uændret.

Hvordan holder du en LLM-routingpolitik vedligeholdelig?

Den nemmeste multiprovider-router er ikke en autonom sort boks. Det er en kort, versioneret opgavepolitik understøttet af delt API-adgang, aktuelle modelmetadata, en kvalitetsvalidator og en snæver fallback-kæde. CometAPI reducerer forbindelsesarbejdet til én nøgle og én OpenAI-kompatibel base-URL; din applikation bevarer kontrollen over beslutninger om omkostning, latens og kvalitet.