Halvering af LLM-API-omkostninger: En guide til modelrouting for produktionsarbejdsbelastninger i 2026

Omkostningsproblemet, der gemmer sig i din regning

Se på modelparameteren i din produktionskode. For de fleste teams, der kører en LLM-arbejdsbelastning, som er gået fra prototype til reel trafik, bliver den parameter sat én gang (typisk til den stærkeste model, teamet havde adgang til ved lancering) og aldrig genbesøgt. Hver forespørgsel, uanset kompleksitet, sendes til den samme model. Og det er her, den skjulte omkostningsoverskridelse bor.

I enhver ikke-triviel produktionsarbejdsbelastning er forespørgsler ikke ensartet svære. En kundesupportassistent kan se, at 80 % af forespørgslerne er simple opslag, klassifikationer eller korte opfølgninger, og 20 % reelt kræver avanceret ræsonnement. En kodeassistent kan håndtere en jævn strøm af små refaktoreringer og en lang hale af arkitektoniske ændringer på tværs af filer. En indholdspipeline kan behandle hundreder af opsummeringsopgaver for hver enkelt, der kræver struktureret kreativ skrivning. Arbejdets form er ujævn, men routingen til modellen er det ikke.

Hvis du i dag kører 100M tokens om måneden på GPT-5.5, og 70 % af de forespørgsler ville blive besvaret lige så godt af en billigere model, betaler du cirka $600 om måneden for kapabilitet, du ikke bruger. Ved højere volumener forstærkes det samme mønster lineært: for hver 1B tokens er forskellen mellem en ikke-routet opsætning og en routet på adskillige tusinde dollars per måned.

Routing er det ingeniørmæssige svar på den asymmetri. Princippet er enkelt: send hver forespørgsel til den billigste model, der kan håndtere den, og eskaler kun til en mere kapabel model, når det er nødvendigt. Implementeringerne er der, hvor de interessante kompromiser lever, og de fleste publicerede vejledninger håndterer dem dårligt. Denne artikel dækker de tre mønstre, der faktisk virker i produktion, omkostningsregnestykket der underbygger sagen, fejltilstandene der fanger dig, og en migrationsplan for at gå fra en enkelt-model-opsætning til en routet uden at omskrive din applikation.

Prisdataene, denne artikel bygger på, kommer fra ledsagerstykket (2026 LLM API-prissammenligning), som fastlægger de modelvise priser, der refereres til gennemgående. Hvor denne guide citerer et omkostningstal, er det hentet fra de data.

De tre routingmønstre, der virker i produktion

Der er tre etablerede mønstre til routing af LLM-trafik. De adskiller sig i implementeringskompleksitet, latenstillæg og de typer besparelser, de åbner for. De fleste produktionssystemer ender med at bruge en kombination af alle tre; at forstå styrkerne ved hvert hjælper dig med at sekvensere arbejdet.

Mønster 1: Statiske regler

Det enkleste mønster. Du skriver regler, der ruter forespørgsler til forskellige modeller baseret på observerbare egenskaber ved anmodningen: inputlængde, brugerniveau, forespørgselstype (hvis du allerede har en klassifikator), API-endpoint eller forretningslogik. Korte forespørgsler går til en billig model; lange forespørgsler går til en stærkere. Brugere på gratisniveau får en billigere model end betalende brugere. Kodegenereringsanmodninger går til en kode-tunet model; alt andet går til en generalistmodel.

Statisk routing er forudsigelig, let at fejlfinde og tilføjer stort set intet latenstillæg: routingbeslutningen er nogle få linjer kode, der kører lokalt. Loftet er også lavere: du ruter på egenskaber, du kan observere, før modellen kører, hvilket betyder, at du ikke kan rute på “hvor svær forespørgslen faktisk er”, fordi du ikke ved det endnu. For arbejdsbelastninger, hvor inputegenskaber korrelerer godt med sværhedsgrad (lange dokumenter er som regel sværere; kode er typisk anderledes end prosa; betalende brugere har ofte mere krævende forespørgsler), kan statiske regler indfange 30–50 % af de tilgængelige besparelser med meget lidt engineering-indsats.

Mønster 2: Kaskade

Det mest bredt anvendelige mønster. Du sender først forespørgslen til en billig model; hvis svaret opfylder en kvalitetstærskel, returnerer du det; hvis ikke, eskalerer du til en mere kapabel model og bruger i stedet det svar. Besparelsen kommer af, at du for de forespørgsler, den billige model kan håndtere, kun betaler den billige models pris.

Kaskademønstrets kendetegn er, at routingbeslutningen er informeret af modellens output, ikke kun input: du lader den billige model forsøge arbejdet og vurderer derefter, om forsøget var godt nok. Vurderingen kan implementeres på flere måder: konfidensscore fra selve modellen, validering af struktureret output (parser svaret som det forventede skema?), selvevalueringsprompter (spørge en lille model, om svaret besvarer spørgsmålet), eller nedstrøms adfærdssignaler (accepterede brugeren svaret, eller omformulerede og forsøgte igen?).

Kaskaden er det mønster, de fleste produktionssystemer til sidst vedtager, fordi det indfanger besparelser, som statiske regler ikke kan. Kompromiset er, at du for forespørgsler, der eskalerer, betaler for både den billige models kald og flagskibets kald, så besparelsen afhænger af, hvilken andel af forespørgslerne der lykkes på billigmodel-niveauet. Det er dette mønster, vi gennemgår i detaljer senere i artiklen.

Mønster 3: Klassifikator-baseret routing

Det højeste loft og den største engineering-investering. En lille, hurtig model (ofte en fintunet version af en sub-frontier-model eller en dedikeret klassifikator) ser på hver indkommende forespørgsel og forudsiger, hvilken downstream-model der skal håndtere den. Klassifikatoren kan beslutte baseret på forespørgselstype (“det ligner en kodegenereringsopgave; ruter til den kode-tunede model”), sværhedsestimat (“det ligner en svær ræsonneringsopgave; ruter til GPT-5.5”) eller en lært routingpolitik trænet på historisk trafik og udfald.

Klassifikator-baseret routing kan overgå kaskaden, fordi routingbeslutningen træffes, før nogen dyr model kører, så du betaler ikke billigmodel-skatten på forespørgsler, som uanset hvad ville have krævet flagskibet. Omkostningen er engineeringarbejdet til at bygge, træne og vedligeholde selve klassifikatoren plus det lille latenstillæg ved routingkaldet. For meget højvolumen-arbejdsbelastninger betaler dette kompromis sig; for mindre arbejdsbelastninger gør det som regel ikke.

Hvilket mønster man starter med: Statiske regler først, hvis din arbejdsbelastning har åbenlyse routing-signaler (inputlængde, brugerniveau, endpoint). Kaskade, hvis den ikke har, eller når du har udtømt de åbenlyse statiske regler. Klassifikator-baseret kun efter både statiske regler og kaskade er på plads, og volumenet retfærdiggør engineeringinvesteringen. At springe direkte til klassifikator-baseret er en klassisk over-engineering-fælde, som de fleste teams fortryder.

Hvad du skal måle, før du begynder at route

Du kan ikke optimere, hvad du ikke måler. Før du introducerer nogen routinglogik i et produktionssystem, instrumentér den nuværende enkelt-model-arbejdsbelastning, så du har en baseline at sammenligne med. Instrumenteringen behøver ikke at være omfattende: en grundlæggende log af hver anmodning med et lille sæt felter er nok til at starte.

Den mindste nyttige instrumentering:

• Per forespørgsel: anvendt model, antal inputtokens, antal outputtokens, omkostning (beregnet ud fra tokenantal og prisliste), end-to-end-latens, svarestilstand (succes / fejl / delvis), og en forespørgselstype-etiket, hvis du har en.
• Per samtale eller per bruger: sessionslængde, antal retries (signalerer, at brugeren ikke accepterede første svar), opfølgningsrate (signalerer, at svaret krævede afklaring).
• Et tilbageholdt evalueringssæt: 100–500 repræsentative forespørgsler, som du kan genkøre på enhver model, med referenceoutputs, du stoler på. Dette er, hvordan du måler, om en kandidat-billigere model producerer acceptabel kvalitet på din arbejdsbelastning. Uden det er hver routingbeslutning gætværk.

Evalueringssættet er der, hvor de fleste teams underinvesterer, og det er det enkelt højeste gearstykke af infrastruktur for ethvert routingprojekt. Letvægtsværktøjer som Promptfoo eller Helicone evals kan få det op at stå hurtigt; for arbejdsbelastninger i tidlig fase er et håndkurateret sæt på 50 forespørgsler med manuelt bedømte outputs rigeligt til at begynde.

Når instrumenteret, kør arbejdsbelastningen, som den er, i mindst en uge for at etablere baseline. Formen på dataene (hvor skæv er din inputlængdefordeling, hvilken andel af forespørgslerne er korte og simple, hvilken andel ser svær ud) fortæller dig, hvilket routingmønster du skal starte med.

Kaskademønsteret i detaljer, med omkostningsregnestykke

Kaskademønsteret fortjener mest plads, fordi det er det mest bredt anvendelige og det, de fleste teams vil implementere som det første eller andet. Matematikken er også der, hvor sagen for routing bliver konkret.

Overvej en repræsentativ produktionsarbejdsbelastning, der i dag kører på Claude Sonnet 4.6: 100 millioner tokens om måneden, 80 % input og 20 % output, $475 månedlig regning til listepris. Antag, vi introducerer en kaskade foran den: forespørgsler rammer først Claude Haiku 4.5 og eskalerer kun til Sonnet 4.6, hvis Haikus svar fejler en kvalitetskontrol. Haiku 4.5 listes til $1.00 input og $5.00 output per million tokens, en tredjedel af Sonnets sats.

Omkostningsregnestykket afhænger af to parametre: hvor stor en procentdel af forespørgslerne der lykkes på Haiku-niveauet (vi kalder dette succesraten), og hvordan forholdet mellem input/output adskiller sig mellem succesfulde og eskalerede forespørgsler. For enkelhedens skyld antager vi, at input/output-forholdet er det samme for begge, og at succesraten er 70 %, hvilket betyder, at Haikus svar er godt nok på 70 % af forespørgslerne, og 30 % eskalerer til Sonnet.

Hvad dette fortæller dig. Selv ved en moderat succesrate på 70 % (dvs. Haiku får det rigtigt 7 ud af 10 gange) halverer kaskaden regningen. Årsagen er, at det billige modelkald er så meget billigere end flagskibets kald, at det at betale for begge på de 30 % af forespørgslerne, der eskalerer, stadig er meget mindre end at betale for flagskibet på hver forespørgsel. Break-even-punktet (hvor kaskaden svarer til enkelt-model-omkostningen) er omtrent en succesrate på 33 %. Under det er det bedre at gå direkte; over det vinder kaskaden.

Minimum viable kaskade-implementering

Nedenfor er den enkleste version af mønsteret, udtrykt i Python med den OpenAI-kompatible klient (som virker mod enhver udbyder, der eksponerer et OpenAI-kompatibelt endpoint, inklusive Claude via Anthropics kompatibilitetslag, Gemini og CometAPI's samlede endpoint). Strukturen er bevidst enkel; produktionsimplementeringer tilføjer observabilitet, fejlhåndtering og mere sofistikerede kvalitetschecks.

from openai import OpenAI
import json

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.cometapi.com/v1",  # eller din foretrukne udbyder
)

CHEAP_MODEL = "claude-haiku-4-5"
FLAGSHIP_MODEL = "claude-sonnet-4-6"


def cascade(messages, output_schema=None):
    """
    Kør en forespørgsel gennem en kaskade.
    Returnerer (response, model_used, escalated).
    """

    # Trin 1: prøv den billige model
    cheap_response = client.chat.completions.create(
        model=CHEAP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    cheap_text = cheap_response.choices[0].message.content

    # Trin 2: vurder om det billige svar er godt nok
    if is_acceptable(cheap_text, output_schema):
        return cheap_text, CHEAP_MODEL, False

    # Trin 3: eskaler til flagskibet
    flagship_response = client.chat.completions.create(
        model=FLAGSHIP_MODEL,
        messages=messages,
        response_format=output_schema,
    )

    flagship_text = flagship_response.choices[0].message.content

    return flagship_text, FLAGSHIP_MODEL, True


def is_acceptable(response_text, output_schema=None):
    """
    Kvalitetskontrol.
    Returnerer True, hvis den billige models output er godt nok.
    """

    if not response_text or len(response_text.strip()) < 10:
        return False

    if output_schema:
        # Struktureret output: det skal kunne parses mod skemaet
        try:
            parsed = json.loads(response_text)
            return validate_schema(parsed, output_schema)

        except (json.JSONDecodeError, ValueError):
            return False

    # For fritekstsvar, indsæt din egen kvalitetssignal:
    # - konfidensscore fra modellen
    # - selvevalueringsprompt til en lille model
    # - regelbaserede checks (længde, format, afvisningsmønstre)

    return True

Dette er et udgangspunkt, ikke en færdig implementering. Tre ting, du ville tilføje til produktion:

• En reel kvalitetskontrol. Funktionen is_acceptable ovenfor er bevidst minimal. I praksis er kontrollen det vigtigste stykke af kaskaden: for lempelig, og du sender svar af lav kvalitet; for streng, og du eskalerer for ofte og mister besparelsen. De fleste produktionskaskader bruger en kombination af validering af struktureret output, afvisningsdetektion (den billige model siger “jeg kan ikke besvare dette”) og selvevaluering af en lille model, der promptes til at bedømme svaret.
• Observabilitet per forespørgsel. Log hvilken model der blev brugt, om anmodningen eskalerede, latenstid på hvert niveau og omkostningen. Det er dette, der fortæller dig, efter en uges kørsel af kaskaden, om succesraten er, hvad du antog, den var.
• En canary-sti til evaluering. Send en lille procentdel af trafikken (sige 5 %) gennem flagskibet, selv når kaskaden lykkes på det billige niveau. Sammenlign svarene på en tilbageholdt bedømmelsesopgave. Dette er, hvordan du fanger snigende kvalitetsforringelse; se næste afsnit.

Hvor routing bryder sammen

Ovenstående omkostningsregnestykke er reelt, men det er også det optimistiske tilfælde. Tre fejltilstande fanger teams, og at navngive dem ærligt er det, der adskiller en routingimplementering, der forøger værdi, fra en der stille forringer produktet.

Latenstillæg ved eskalerede forespørgsler

Når en forespørgsel eskalerer, betaler du for det billige modelkald, før flagskibsmodellen begynder. Hvis den billige model tager 800 ms, og flagskibet tager 1,5 s, tager den eskalerede forespørgsel 2,3 s end-to-end. For latenstfølsomme arbejdsbelastninger betyder det noget. Modtrækkene er at vælge en hurtig billig model (Haiku 4.5 og Gemini 3 Flash er designet til dette), at sætte aggressive tidsgrænser på det billige modelkald og at overveje parallelle kald for de forespørgsler, du mistænker, mest sandsynligt vil eskalere. Nogle teams accepterer latenstomkostningen, fordi dollarbesparelsen er stor; andre bruger statiske regler til at undgå at sende åbenlyst svære forespørgsler gennem kaskaden overhovedet.

Snigende kvalitetsforringelse

Den mest lumsk fejltilstand. Den billige model producerer svar, der passerer din kvalitetskontrol, men som er subtilt dårligere end flagskibets svar: en anelse mindre præcise, en anelse mindre hjælpsomme, en anelse mere tilbøjelige til at misse hjørnetilfælde. Brugere klager ikke med det samme; metrikken, du overvåger (svartid, fejlrater, kontrolens passrate) ser alle fine ud; men nedstrøms metrikker (brugerfastholdelse, konverteringsrate, support-eskalationer) glider. Når du opdager det, har du leveret uger med forringet kvalitet.

Forsvaret er den nævnte canary-sti: en tilbageholdt procentdel af trafikken, der kører gennem flagskibet parallelt med kaskaden, hvor begge svar bedømmes mod en evalueringsrubrik. Bedømmelsen kan udføres af en model selv (LLM-as-judge) eller ved udtaget menneskelig gennemgang. Pointen er at opretholde et kontinuerligt kvalitetssignal, der er uafhængigt af kaskadens egen kontrol, så forringelse kommer til syne som drift i det signal i stedet for som en nedstrøms overraskelse.

Kompleksitetsomkostning i kode og observabilitet

Hver ekstra model i routing-grafen er endnu en model at evaluere, overvåge og opdatere, når dens udbyder udgiver en ny version. En to-niveaus kaskade er håndterbar; en fem-modellers, klassifikator-baseret router med separate stier for kode, RAG, chat, agenter og hjørnetilfælde er meningsfuldt mere kompleks end enkelt-model-opsætningen, den erstattede. Kompleksiteten er det værd, når arbejdsbelastningsvolumenet retfærdiggør det; under den volumen kan den engineeringtid, der bruges på at vedligeholde routinglaget, overstige de besparelser, det producerer. Vær ærlig om din volumengrænse.

Hvordan aggregatorer hjælper (og hvor de ikke gør)

LLM-aggregatorer (tjenester, der eksponerer flere modeller bag et enkelt OpenAI-kompatibelt API) interagerer med routing på to forskellige måder. Begge er værd at forstå, fordi svaret på “vil jeg have en aggregator i mit routinglag?” afhænger af, hvilken interaktion du bekymrer dig om.

Den reelle hjælp: at fjerne integrationsomkostningen

At bygge en kaskade eller klassifikator-baseret router på direkte udbyder-API'er betyder at håndtere flere SDK'er, flere autentifikationsnøgler, flere faktureringsflader og flere sæt udbyderspecifikke særheder (timeout-adfærd, fejlformater, rate-limit-semantik). For en multimodel-routingopsætning er denne overhead reel. En aggregator som CometAPI eksponerer alle modeller bag et enkelt OpenAI-kompatibelt endpoint, hvilket betyder, at kodeændringen for routing blot er at ændre model-parameteren, uden udbyderskift, uden separate nøgler, uden separat observabilitetslag. For teams, hvis primære hinder for routing er integrationsomkostningen snarere end kvalitetsvurderingsomkostningen, er dette afgørende.

Det, man skal være forsigtig med: indbyggede routing-lag

Nogle aggregatorer tilbyder en “smart routing” eller “model optimizer”-funktion, der vælger modellen for dig baseret på forespørgslen. Dette kan være nyttigt til prototyper, men er generelt det forkerte udgangspunkt til produktion. Årsagen er, at routingbeslutningen er en af de mest arbejdsbelastningsspecifikke ting i din stack: hvad der tæller som “svær nok til at eskalere” afhænger af dine evalueringskriterier, dit latenstbudget, din kvalitetsbarre og dit omkostningsloft. Et generisk routinglag kan ikke kende nogen af disse. De fleste produktionssystemer er bedre tjent med en tynd, transparent aggregator (en der eksponerer de samme modeller, du ville tilgå direkte, med én credential og én regning) plus deres egen routinglogik ovenpå, end med et black-box-routinglag, de ikke kan tune.

Migrationsplanen

En sikker, trin-for-trin vej fra en enkelt-model produktionsarbejdsbelastning til en routet. Princippet hele vejen er at foretage ændringer, der hver især er reversible, og at måle effekten af hver ændring, før den næste foretages.

• Instrumentér den nuværende arbejdsbelastning. Log hver anmodning med model, input/output-tokens, omkostning, latenstid og en forespørgselstype-etiket. Kør i minimum en uge for at etablere en baseline. Uden dette er hvert efterfølgende trin gætværk.
• Byg evalueringssættet. Kuratér 100–500 repræsentative forespørgsler med referenceoutputs, du stoler på. Dette er det tilbageholdte sæt, du vil bruge til at sammenligne kaskaden med enkelt-model-baselinen ved hvert trin.
• Identificér den højest-volumen forespørgselstype. Find i instrumenteringsdataene den forespørgselskategori, der står for mest trafik. Det er her, du vil pilotere kaskaden. Det behøver ikke være den letteste kategori, blot den med højest volumen, for det er her, besparelserne koncentreres.
• Byg en kaskadeprototype for netop den ene forespørgselstype. To niveauer: billig model først, flagskib hvis den fejler kvalitetskontrollen. Kør den først på evalueringssættet. Sammenlign omkostning og kvalitet mod enkelt-model-baselinen. Hvis kvaliteten holder og omkostningen falder, gå videre; hvis kvaliteten falder, skærp kontrollen og prøv igen.
• Rul ud på en procentdel af trafikken. Start med 5–10 % af produktionstrafikken for den valgte forespørgselstype. Kør i mindst en uge. Overvåg kaskadens eskaleringsrate, omkostning per forespørgsel, latenstid på hvert niveau og canary-stiens kvalitets­sammenligning. Hvis metrikkerne matcher prototypens forudsigelse, udvid til 25 %, derefter 50 %, derefter 100 %.
• Gentag for næste forespørgselstype. Når den første kategori er fuldt migreret, og besparelsen er realiseret, gå videre til den næsthøjeste volumen-kategori. Hver kaskade er en separat beslutning; antag ikke, at et mønster, der virkede for én kategori, virker for en anden.
• Tilføj en kontinuerlig kvalitets-canary. Når flere forespørgselstyper kører på kaskader, sæt den tilbageholdte canary-sti op permanent, med 5 % af trafikken, der kører gennem flagskibet til bedømmelse. Dette er dit tidligvarslingssystem for snigende forringelse, og det er det, der holder routinglaget troværdigt, efterhånden som modeller opdateres.

Når routing ikke kan betale sig

Ærlig erkendelse. Der er arbejdsbelastninger, hvor engineeringinvesteringen i routing ikke betaler sig, og at erkende dem på forhånd sparer tid:

• Enkelt-model arbejdsbelastninger, hvor én model reelt er det rigtige svar til alt. Hvis dit evalueringssæt viser et meningsfuldt kvalitetstab på billigmodel-niveauet på tværs af hele arbejdsbelastningen, har kaskaden intet at arbejde med. En kodegenereringsarbejdsbelastning, hvor flaskehalsen er ræsonneringsevne, er ét eksempel: Haiku vil fejle kvalitetskontrollen for ofte til, at kaskaden giver besparelser.
• Meget lavvolumen-arbejdsbelastninger. Under cirka $200/måned i LLM-forbrug overstiger tiden brugt på at bygge og vedligeholde routinglaget typisk besparelserne. Tærsklen er arbejdsbelastningsspecifik, men den er reel. Vær ærlig om, hvor højt dit forbrug er, og om det retfærdiggør arbejdet.
• Regulerede miljøer, hvor leverandør-af-record betyder noget. Hvis din compliance-profil kræver, at al produktionstrafik går gennem ét specifikt udbyderforhold, komplicerer multimodel-routing den samtale. Der kan stadig være routingmuligheder inden for samme udbyder (Sonnet → Opus hos Anthropic; GPT-5 nano → GPT-5.5 hos OpenAI), men cross-provider-routing er sværere at retfærdiggøre.

Den ærlige indramning: routing betaler sig, når din arbejdsbelastning er højvolumen, dine forespørgsler ikke er ensartet svære, og du har evalueringsinfrastrukturen til at vide, hvornår kaskaden producerer acceptabel kvalitet. De fleste produktionsarbejdsbelastninger i en meningsfuld skala matcher denne beskrivelse; nogle gør ikke og leverer hurtigere ved at holde sig til en enkelt model. Begge valg er forsvarlige.

Hvor du går hen herfra: Hvis du ikke allerede har arbejdet dig gennem den modelvise prisliste, som denne artikel bygger på, er ledsagerstykket, The 2026 LLM API Pricing Comparison: GPT-5.5, Claude Sonnet 4.6, Gemini 3.5 Flash and DeepSeek V4, fundamentet. Prisdataene dér er det, der gør omkostningsregnestykket i denne guide konkret for din specifikke arbejdsbelastning.