At bruge én model til hvert kald kan være unødigt dyrt, men routing er ikke automatisk en forbedring.
Et team kan opdage, at klassificering, udtrækning, udarbejdelse af udkast og kompleks ræsonnering stiller forskellige krav til kvalitet og latenstid. Routing kan udnytte disse forskelle. Den kan dog også medføre et ekstra klassifikationskald, flere fejltilstande hos leverandører, uensartet sikkerhedsadfærd og mere evalueringsarbejde. Den eneste forsvarlige påstand om besparelser er den, der beregnes ud fra dine målte tokenmængder, aktuelle leverandørpriser og kvalitetskrav.
Dette er orkestrering af flere modeller: Valg af en model eller specialiseret tjeneste til en bestemt type kald inden for udtrykkelige krav til kvalitet, svartid, databeskyttelse og omkostninger.
Denne artikel dækker mønstrene, routinglogikken, afvejningerne og en trin-for-trin-guide til implementering.
Hvorfor én model ikke er optimal
Leverandørkataloger ændrer sig ofte, men en arbejdsbelastning kan stadig definere funktionelle niveauer:
Niveau med høj ræsonneringskapacitet: kandidatmodeller til vanskelig planlægning eller analyse. Evaluér nøjagtighed, værktøjsadfærd, latenstid i den langsomme ende af fordelingen og det samlede antal genererede ræsonneringstokens på dine egne eksempler.
Generelt niveau: kandidater til brugerorienteret udarbejdelse og blandet vidensarbejde, hvor kvalitet er afgørende, men udvidet ræsonnement måske ikke er nødvendigt.
Niveau med lav latenstid: kandidater til afgrænset klassificering, udtrækning og omskrivning. En mindre model garanterer hverken tilstrækkelig nøjagtighed eller lavere samlet latenstid.
Lokalt niveau eller niveau med små modeller: kandidater, når lokal databehandling, offline drift eller marginale driftsomkostninger er afgørende. Medtag hardware, drift, energi, samtidige brugere og effekten af kvantisering i sammenligningen.
Specialiserede tjenester til embeddings, omrangering, billedforståelse eller tale: Sammenlign dem med generelle modeller på præcis den samme opgave. Specialisering er ikke i sig selv bevis for bedre kvalitet eller lavere samlede omkostninger.
Brug de aktuelle model- og prissider, når beslutningen træffes: OpenAI-modeller og priser, Anthropic-modeller og priser samt Google-modeller og priser. Fastlås hverken tilgængelighed eller priser i en langsigtet arkitekturbeslutning.
En typisk AI-app foretager mange forskellige typer af anmodninger til en stor sprogmodel (LLM). Hver anmodning har sine egne krav:
- Klassificering af brugerens hensigt: Evaluér en kandidat med lav latenstid på et mærket datasæt, der også indeholder tvetydige tilfælde og input uden for opgavens omfang.
- Udtrækning af strukturerede data: Mål nøjagtigheden på feltniveau og skemaets gyldighed, ikke modellens størrelse.
- Udarbejdelse af et brugervendt svar: Mål faktuel korrekthed, overholdelse af politikker og latenstid i den langsomme ende af fordelingen.
- Opsummering af tidligere samtale: test udeladelse af beslutninger, navne, begrænsninger og negation.
- Baggrundsbehandling i batches: Mål gennemstrømning, omkostninger ved genforsøg og overholdelse af tidsfrister.
Antag ikke, at den billigste kandidat er tilstrækkelig, eller at den dyreste kandidat er bedst. Fastslå dette ved hjælp af samme evalueringssæt for hver rute.
Beregn besparelser fra telemetri
For hver opkaldstype skal du indsamle:
- antal kald pr. måned;
- fordelingen af input-, cachelagrede input- og outputtokens;
- andelen af genforsøg og kaskader;
- omkostninger til værktøjer, søgning, batchbehandling eller hosting;
- percentiler for latenstid; og
- beståelsesprocenten på ruttens udgivelsesevaluering.
Beregn hver kandidatrute med de aktuelle priser:
månedlig ruteomkostning = opkald × (
input_tokens × inputpris
+ cached_tokens × cachepris
+ output_tokens × outputpris
) + værktøjsgebyrer + hosting + forventet omkostning ved genforsøg
Sammenlign kun med udgangspunktet for de kandidater, der består de samme kvalitets- og sikkerhedskriterier ved udgivelse. Angiv antagelserne sammen med resultatet. En rute, der sparer tokenomkostninger, men øger behovet for manuel rettelse, antallet af hændelser eller latenstiden, kan samlet set blive dyrere.
Hvis telemetri ikke er tilgængelig, skal du først køre en skyggeevaluering. Offentliggør ikke en besparelsesprocent baseret på en generisk trafikfordeling.
De grundlæggende orkestreringsmønstre
Nogle mønstre gentager sig i produktionsmiljøer med flere modeller:
Mønster 1: Opgavebaseret routing
Forskellige opgavetyper sendes til forskellige modeller. Det er det enkleste mønster.
# Resolve these aliases from reviewed configuration; provider IDs change.
def route_request(task_type):
if task_type == "classification":
return SMALL_TIER
elif task_type == "extraction":
return EXTRACTION_TIER
elif task_type == "summarization":
return SUMMARY_TIER
elif task_type == "user-facing-response":
return RESPONSE_TIER
elif task_type == "complex-reasoning":
return REASONING_TIER
Opgaver klassificeres af den kaldende kode (den ved, hvad den spørger om). Routingen er deterministisk og let at fejlsøge.
Mønster 2: Kompleksitetsbaseret routing
Systemet estimerer kompleksiteten af hver forespørgsel og videresender den herefter.
def route_by_complexity(request):
complexity = estimate_complexity(request)
if complexity < 3:
return "small"
elif complexity < 7:
return "mid"
else:
return "flagship"
Kompleksiteten kan vurderes heuristisk ud fra for eksempel anmodningens længde og nøgleord eller med en model, hvor en billig klassifikator vurderer anmodningen. Mønstret håndterer tilfælde, hvor den samme opgavetype varierer i sværhedsgrad.
Mønster 3: Kaskaderet routing
Prøv først en billig model. Brug resultatet, hvis det opfylder acceptkriterierne. Ellers sendes opgaven videre til en dyrere model.
def cascade(request):
cheap_response = call_model("small", request)
if is_acceptable(cheap_response):
return cheap_response
return call_model("flagship", request)
Dette fungerer, når et acceptabelt resultat kan identificeres ved hjælp af for eksempel valideringsregler, kalibrerede sikkerhedsmål eller en separat model til kvalitetskontrol. En kontrolmodel er dog ikke en uafhængig garanti. Mønstret kan lade en billig model håndtere enkle anmodninger og kun sende vanskeligere tilfælde videre, hvis evalueringerne understøtter det.
Mønster 4: Specialiseret routing
Brug specialiserede modeller til specialiserede opgaver:
- Embeddings: Brug en dedikeret embeddingmodel, hvis den klarer opgaven bedre samlet set end en generel model.
- Omrangering: Brug en dedikeret model til omrangering.
- Billedforståelse: Brug en model, der er evalueret til billedanalyse.
- Stemme: brug en stemmemodel til transskription og syntese.
- Kode: Brug en kode-specialiseret model til opgaver inden for kodning.
Specialiserede eller mindre modeller kan være hurtigere, billigere eller bedre til en snæver opgave, men ingen af disse fordele følger alene af etiketten. Benchmarktest den konkrete model, udbyder, prompt, sprog, latenspercentil, prisoversigt og evalueringsdatasæt.
Mønster 5: Udbyder-routing
Brug modeller fra flere udbydere, når redundans, krav til databehandling eller prisforskelle retfærdiggør den ekstra kompleksitet.
providers = ["openai", "anthropic", "google"]
preferred = "anthropic" # primary
fallback = "openai" # fallback
def call_with_failover(request):
try:
return call(preferred, request)
except (RateLimit, ProviderError):
return call(fallback, request)
Det kan øge robustheden over for nedbrud og hastighedsbegrænsninger hos en enkelt leverandør. Det kan også gøre det muligt at reagere på prisændringer, men trafik bør kun flyttes, når den nye rute stadig opfylder kravene til kvalitet, sikkerhed, databehandling og tilgængelighed.
Et realistisk eksempel: kundesupport-AI
Som konkret eksempel ser vi på, hvordan et AI-system til kundesupport kan orkestrere flere modeller.
Systemet har disse trin for hver supportsag:
Trin 1: Klassificér hensigt. Hvad spørger kunden om?
Kandidat til ruten: En model med lav latenstid, der består det mærkede datasæt for hensigter.
Trin 2: Vurder hastegrad og stemning. Er kunden frustreret? Er dette akut?
Kandidat til ruten: Den samme model kun, hvis andelen af oversete hastesager ligger inden for den særskilt definerede sikkerhedstærskel. Følelsesudtryk er ikke en pålidelig stedfortræder for hastegrad.
Trin 3: Hent den relevante viden.
Kandidat til ruten: Søgning med embeddings kombineret med omrangering, evalueret på et søgedatasæt, der repræsenterer de faktiske supportsager.
Trin 4: Afgør, om AI’en kan svare på dette, eller om der skal eskaleres til en menneskelig sagsbehandler.
Routingkandidat: en model evalueret specifikt med henblik på genkendelse af eskaleringer. Regler bør tvinge menneskelig eskalering ved adgang til konti, sikkerhedsmæssige forhold, juridiske spørgsmål, økonomiske anliggender eller andre tilfælde defineret i politikken.
Trin 5 (hvis AI kan svare): Generér det kundevendte svar.
Routingkandidat: en generel model med højere kvalitet. Hold den kun som udkast, indtil faktualitet, politikker, databeskyttelse og tone består udgivelseskriterierne.
Trin 6 (hvis AI ikke kan svare): Generer et resumé til den menneskelige agent.
Kandidat til ruten: En billigere model, hvis sammendrag bevarer problemstillingen, dokumentationen, de forsøgte trin, kundens begrænsninger og usikkerheden.
Trin 7: Kvalitetskontrol. Opfyldte svaret vores standarder?
Kandidat til ruten: Deterministiske kontroller kombineret med en kalibreret vurderingsmodel. En vurderingsmodel er ikke en uafhængig garanti. Kontrollér et repræsentativt udsnit af dens beslutninger med mennesker.
Instrumentér hvert trin, og udfyld derefter omkostningsformlen ovenfor med målte tokenfordelinger, aktuelle priser, andelen af eskaleringer og genforsøg samt omkostningerne ved menneskelig gennemgang. Eksemplet angiver bevidst ikke en generel besparelse. Sammensætningen af supportsager og acceptgrænserne afgør resultatet.
Routinglogikken
Nogle metoder til at implementere routing:
Tilgang 1: Hårdkodet efter opgavetype
Den enkleste tilgang. Den kaldende kode kender opgaven og vælger modellen.
def classify(text):
return openai_client.chat.completions.create(
model=SMALL_TIER, # your provider's current small model
messages=[{"role": "user", "content": f"Classify: {text}"}],
)
def respond(context, query):
return claude_client.messages.create(
model=RESPONSE_TIER, # reviewed config alias, not a frozen provider ID
max_tokens=1024,
messages=[{"role": "user", "content": f"Context: {context}\n\nQuery: {query}"}]
)
Fordele: Gennemsigtig, nem at fejlsøge og let at ændre. Ulemper: Tilpasser sig ikke til anmodningens kompleksitet inden for en opgavetype.
Tilgang 2: Routingmodel
En lille model klassificerer hver anmodning og vælger ruten.
ROUTER_PROMPT = """
Classify this request as: trivial, moderate, or complex.
Output one word.
Request: {request}
"""
def route(request):
classification = small_model_call(ROUTER_PROMPT.format(request=request))
return MODEL_BY_COMPLEXITY[classification]
Fordele: Tilpasser sig kompleksiteten inden for en kategori. Ulemper: Øger latenstiden med routingkaldet, tilføjer et fejlpunkt og kræver kalibrering.
Tilgang 3: Routing med embeddings
Ved anmodninger, der følger kendte mønstre, kan du bruge ligheden mellem embeddings og tidligere eksempler.
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
Fordele: Hurtig, fordi den kun kræver et vektoropslag, og kan forbedres med flere mærkede eksempler. Ulemper: Kræver et mærket sæt af repræsentative eksempler.
Tilgang 4: Kaskade
Prøv først den billige løsning; eskaler, hvis det er nødvendigt.
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
Fordele: Tilpasser sig opgaven og kan give en lav gennemsnitlig omkostning. Ulemper: Langsommere i tilfælde, der kræver eskalering, fordi der foretages to kald, og afhængig af pålidelig validering.
I praksis kan en hybrid være passende: hårdkodet routing til de primære opgavetyper og kaskader til bestemte undertyper med stor variation. Sammenlign den med en enklere løsning, før den tages i brug.
Faldgruberne
Et par fejl, du skal undgå:
Faldgrube 1: Optimering af omkostninger på bekostning af kvalitet
Det er nemt at dirigere alt til små modeller og se omkostningerne falde. Det er sværere at lægge mærke til, at kvaliteten også faldt. Par altid ændringer i routing med overvågning af kvalitet.
En nyttig fremgangsmåde er at skyggekøre eller A/B-teste en billigere rute, indtil stikprøven dækker vigtige inputklasser og fejltilstande. En fast uge er ikke dokumentation i sig selv. Udgiv ikke ændringen, medmindre de på forhånd fastsatte kvalitets- og sikkerhedskrav er opfyldt.
Faldgrube 2: Overdesign af routinglogikken
En router med mange opgavetyper og uigennemsigtig logik kan være sværere at vedligeholde end den routing, den erstatter. Begynd med det mindste antal ruter, som dine målinger retfærdiggør.
Tilføj kun en rute, når den ændrer en driftsmæssig beslutning og forbedrer et målt krav nok til at retfærdiggøre ansvar, test og en reserveløsning.
Faldgrube 3: At ignorere latens
Billigere modeller er ikke nødvendigvis hurtigere. Mål latenstid og kvalitet hver for sig. En kaskade tilføjer mindst ét ekstra forsøg i tilfælde, der sendes videre, og kan øge latenstiden i den langsomme ende betydeligt i brugervendte forløb.
Ved et brugervendt svar med stramme krav til latenstid skal du sammenligne en direkte rute med en kaskade på både beståelsesprocent og latenstid i den langsomme ende. Kaskader kan være lettere at acceptere i batchbehandling eller asynkrone arbejdsgange, men den rigtige rute afhænger af arbejdsbelastningen.
Faldgrube 4: Ikke at håndtere leverandørens fejl
Når du er afhængig af flere modeller, har du også flere mulige fejlkilder. En avanceret model kan blive utilgængelig, en hastighedsgrænse kan træde i kraft, eller en API-nøgle kan udløbe. Routinglogikken skal have eksplicit fejlhåndtering.
Definér eksplicit adfærd ved hastighedsgrænser, tidsudløb og leverandørfejl. En reserveløsning hos en anden leverandør er kun passende, hvis dens vilkår for databehandling, regionale datavej, værktøjs- og skemakontrakt samt evalueringsresultater er acceptable. Ellers skal løsningen stoppe sikkert, sætte opgaven i kø eller eskalere. At returnere et væsentligt dårligere svar er ikke reel tilgængelighed.
Faldgrube 5: Ikke at måle kvaliteten pr. rute
Du skal vide, hvilke ruter der klarer sig godt, og hvilke der ikke gør. Det kræver evaluering, helst automatiseret.
En nyttig opsætning er at registrere den anvendte model, anmodningen, svaret og, hvor det er muligt, et kvalitetssignal ved hvert produktionskald. Det kan være brugerfeedback, mål fra efterfølgende led eller en automatisk evaluering. Sammenfat målingerne pr. rute, så kvalitetsændringer kan opdages tidligt.
Genvalider levende afhængigheder
Model-id’er, udfasningsdatoer, kontekstgrænser, priser, hastighedsgrænser, regional behandling samt semantik for strukturerede resultater og værktøjer kan ændre sig uafhængigt af hinanden. Gennemgå leverandørens aktuelle dokumentation, og kør evalueringerne igen, før du ændrer et alias. En OpenAI-kompatibel transport garanterer ikke ens skemaer, værktøjsadfærd, tokenberegning, sikkerhedspolitik eller databehandling.
En starttjekliste
Hvis du bygger et system med flere modeller fra bunden eller migrerer fra én model:
-
Kortlæg dine opgaver. Hvilke typer LLM-kald foretager din applikation? Ca. hvor ofte? Ca. hvad koster det?
-
Kategoriser efter kompleksitet. Afgør for hver opgavetype, om den er triviel, moderat eller kompleks. Tilpas til modellens niveau.
-
Byg en router. Begynd med hårdkodet opgavebaseret routing. Undgå at overdesigne det.
-
Definér fejladfærd. Brug en testet reserveløsning, kø, fail-closed-svar eller menneskelig eskalering afhængigt af konsekvens og datapolitik.
-
Mål kvaliteten pr. rute. Opsæt logning og grundlæggende evaluering. Du skal vide, om kvaliteten holder.
-
Tilpas løbende. Flyt opgaver til billigere modeller, hvor kvaliteten holder, og tilbage til dyrere modeller, hvor den svigter.
-
Stop ikke med at finjustere. Modeller ændrer sig. Nye lanceres. Priser svinger. En routingkonfiguration, der er optimeret i maj 2026 kan være underoptimal i november 2026.
Rout kun der, hvor evidensen understøtter det
Orkestrering af flere modeller kan reducere omkostninger eller latenstid, når kaldtyperne reelt er forskellige, og hver rute evalueres. Den kan også øge driftsomkostningerne og mindske ensartetheden. Offentliggør det målte udgangspunkt, resultatet efter routing, kvalitetsgrænserne og testperioden i stedet for en universel påstand om besparelser.
Rutebetingelsen kan være kort; produktionsarbejdet består i konfigurationsstyring, evaluering, observerbarhed, databeskyttelsesgennemgang, semantik for gentagelser og reserveløsninger.
Kortlæg dine opgaver, benchmarktest de mest lovende kandidater, og send kun arbejdet til en anden rute, hvor dokumentationen retfærdiggør det. Fortsæt med at måle efter udgivelsen.
