Att använda samma modell för varje anrop kan vara onödigt dyrt, men routning är inte automatiskt en förbättring.
Ett team kan upptäcka att klassificering, extraktion, utkast och avancerat resonemang har olika krav på kvalitet och svarstid. Routning kan utnyttja skillnaderna. Den kan också medföra ett extra anrop till en klassificerare, fler fellägen hos leverantörer, inkonsekvent säkerhetsbeteende och mer utvärderingsarbete. Ett påstående om besparingar är försvarbart endast om det bygger på den uppmätta tokenmängden, aktuella leverantörspriser och kvalitetsgränser.
Detta är flermodellsorkestrering: att välja en modell eller specialiserad tjänst för en definierad typ av anrop under tydliga begränsningar för kvalitet, latens, integritet och kostnad.
Artikeln beskriver mönstren, routningslogiken, avvägningarna och en stegvis guide till implementeringen.
Varför en modell inte är optimal
Leverantörskataloger ändras ofta, men en arbetsbelastning kan fortfarande definiera funktionella nivåer:
Nivå för högkapabla modeller: kandidater för svår planering eller analys. Utvärdera noggrannhet, verktygsbeteende, svarstidens höga percentiler och det totala antalet token som genereras under resonemanget i egna fall.
Allmän nivå: kandidater för användarriktade utkast och blandat kunskapsarbete där kvaliteten är viktig men utökat resonemang inte alltid behövs.
Nivå med låg latens: kandidater för avgränsad klassificering, extraktion och omskrivning. En mindre modell garanterar varken tillräcklig noggrannhet eller lägre total latens.
Nivå för lokala eller små modeller: kandidater när datalokalitet, drift utan internetanslutning eller marginell inferenskostnad spelar roll. Ta med hårdvara, drift, energi, samtidighet och kvantiseringseffekter i jämförelsen.
Specialiserade tjänster (inbäddning, omrangordning, bildbehandling, tal): jämför dem med allmänna modeller för exakt samma uppgift; specialisering är inte bevis för bättre kvalitet eller lägre total ägandekostnad.
Använd aktuella modell- och prissidor när du fattar beslut: OpenAI-modeller och prissättning, Anthropic-modeller och prissättning samt Google-modeller och prissättning. Cachelagra varken tillgänglighet eller priser i ett långlivat arkitekturbeslut.
En typisk AI-app gör många olika typer av anrop till LLM:er. Varje anrop har sina egna krav:
- Klassificera användarens avsikt: utvärdera en kandidat med låg latens mot en märkt datauppsättning som även innehåller tvetydiga fall och fall utanför omfattningen.
- Extrahera strukturerade data: mät noggrannheten på fältnivå och schemats giltighet, inte modellstorleken.
- Skapa ett användarvänligt svar: mät faktamässig korrekthet, efterlevnad av policyn och latensens höga percentiler.
- Sammanfatta tidigare konversationer: kontrollera om beslut, namn, begränsningar eller nekationer utelämnas.
- Batchbearbeta i bakgrunden: mät genomströmning, kostnad för omförsök och om arbetet slutförs inom tidsfristen.
Anta inte att den billigaste kandidaten är tillräcklig eller att den dyraste kandidaten är bäst. Fastställ detta med samma utvärderingsuppsättning för varje väg.
Beräkna besparingar från telemetri
För varje anropstyp, samla in:
- månatligt antal anrop;
- fördelning av token för indata, cachelagrade indata och utdata;
- frekvens för omförsök och kaskader;
- avgifter för verktyg, sökning, batchbearbetning eller drift;
- latenspercentiler; och
- andel godkända fall i ruttens utvärdering inför driftsättning.
Beräkna kostnaden för varje kandidatrutt med aktuella priser:
monthly route cost = calls × (
input_tokens × input_price
+ cached_tokens × cached_price
+ output_tokens × output_price
) + tool_charges + hosting + expected_retry_cost
Jämför det med baslinjen endast för kandidater som uppfyller samma kvalitets- och säkerhetskrav före driftsättning. Ange antagandena bredvid resultatet. En rutt som sparar tokenkostnad men ökar manuell korrigering, incidenter eller latens kan kosta mer i slutändan.
Om telemetri saknas ska du först köra en skuggutvärdering. Publicera ingen besparingsprocent utifrån en generell trafikfördelning.
De grundläggande routningsmönstren
Ett par mönster återkommer i produktionsmiljöer med flera modeller:
Mönster 1: Uppgiftsbaserad routning
Olika typer av uppgifter skickas till olika modeller. Detta är det enklaste mönstret.
# 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
Uppgifterna klassificeras av anropskoden, som vet vad den begär. Routningen är deterministisk och enkel att felsöka.
Mönster 2: Komplexitetsbaserad routning
Systemet uppskattar komplexiteten i varje begäran och routar trafiken därefter.
def route_by_complexity(request):
complexity = estimate_complexity(request)
if complexity < 3:
return "small"
elif complexity < 7:
return "mid"
else:
return "flagship"
Komplexitetsuppskattningen kan vara heuristisk (begärandelängd, nyckelordsigenkänning) eller modellbaserad (en billig klassificerare poängsätter begäran). Detta mönster hanterar fall där samma uppgiftstyp varierar i svårighetsgrad.
Mönster 3: Kaskadroutning
Prova en billig modell först. Om resultatet är bra använder du den. Annars eskalerar du till en dyrare modell.
def cascade(request):
cheap_response = call_model("small", request)
if is_acceptable(cheap_response):
return cheap_response
return call_model("flagship", request)
Detta fungerar när ett godtagbart resultat kan identifieras med konfidensvärden, validerare eller en separat LLM för kvalitetskontroll. De flesta enkla förfrågningar kan då besvaras av den billigare modellen, medan bara de svåra når den dyrare.
Mönster 4: Specialiserad routning
Använd specialiserade modeller för specialiserade uppgifter:
- Inbäddningar: använd en särskild inbäddningsmodell (ofta mycket billigare än att använda en chattmodell för inbäddningar).
- Omrangordning: använd en särskild omrangordnare.
- Bildanalys: använd en specialiserad modell för bilder.
- Röst: använd en röstmodell för transkription och syntes.
- Kod: använd en kodspecialiserad modell för koduppgifter.
Specialiserade eller mindre modeller kan vara snabbare, billigare eller bättre på en smal uppgift, men ingen av dessa fördelar följer direkt av etiketten i sig. Utvärdera den exakta modellen, leverantören, prompten, språket, latenspercentilen, prislistan och utvärderingsunderlaget.
Mönster 5: Leverantörsroutning
Använd modeller från flera leverantörer för redundans och prisfördelar.
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)
Detta ger motståndskraft mot driftavbrott och hastighetsbegränsningar hos en enskild leverantör. Det gör det också möjligt att dra nytta av prisförändringar genom att flytta mer trafik när en leverantör sänker priserna.
Ett realistiskt exempel: kundsupport-AI
Som ett konkret exempel visar vi hur ett AI-system för kundsupport kan använda flermodellsorkestrering.
Systemet har följande steg per ärende:
Steg 1: Klassificera avsikt. Vad frågar kunden om?
Routningskandidat: en modell med låg latens som klarar den märkta testuppsättningen för avsiktsklassificering.
Steg 2: Bedöm brådskan och känsloläge. Är kunden frustrerad? Är detta akut?
Routningskandidat: samma modell endast om andelen missade brådskande fall uppfyller den separat definierade säkerhetströskeln; känslolägen är inte en tillförlitlig ersättning för bedömd brådska.
Steg 3: Hämta relevant kunskap.
Routningskandidat: inbäddningsbaserad hämtning tillsammans med en omrangordnare, utvärderad på en ärendespecifik testuppsättning för hämtning.
Steg 4: Avgör om AI:n kan svara eller om ärendet ska lämnas över till en människa.
Routningskandidat: en modell som utvärderats specifikt för att hitta eskaleringsfall med tillräcklig täckning. Regler bör tvinga fram eskalering till en människa vid kontoåtkomst, säkerhetsfrågor, juridiska eller ekonomiska frågor och andra policydefinierade fall.
Steg 5 (om AI:n kan svara): Generera ett kundvänligt svar.
Routningskandidat: en allmän modell med högre kvalitet. Låt svaret förbli ett utkast tills faktamässighet, policy, integritet och ton uppfyller kraven för publicering.
Steg 6 (om AI:n inte kan svara): Generera en sammanfattning för den mänskliga agenten.
Routningskandidat: en modell med lägre kostnad vars sammanfattningar bevarar problemet, underlaget, försökta steg, kundens begränsningar och osäkerheten.
Steg 7: Kvalitetskontroll. Uppfyllde svaret våra krav?
Routningskandidat: deterministiska kontroller tillsammans med en kalibrerad bedömningsmodell. En sådan modell är ingen oberoende garanti; låt mänskliga granskare kontrollera ett urval av dess beslut.
Instrumentera varje steg och fyll sedan i kostnadsformeln ovan med uppmätta tokenfördelningar, aktuella priser, eskaleringsandel, andel omförsök och kostnad för mänsklig granskning. Exemplet innehåller avsiktligt ingen generell besparingsuppskattning: ärendeblandningen och acceptanströsklarna avgör resultatet.
Routningslogiken
Ett par tillvägagångssätt för att implementera routning:
Metod 1: Hårdkodat efter uppgiftstyp
Enklast. Du vet vilken uppgift du anropar och väljer 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}"}]
)
Fördelar: Transparent, enkel att felsöka och enkel att ändra. Nackdelar: Anpassar sig inte till begärans komplexitet inom en uppgiftstyp.
Metod 2: Modellbaserad router
En liten modell klassificerar varje begäran och styr dess vidare hantering.
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]
Fördelar: Anpassar sig till komplexitet inom en kategori. Nackdelar: Tillför latens genom routeranropet, skapar ytterligare en felpunkt och kräver finjustering.
Metod 3: Inbäddningsbaserad router
För begäranden som ryms inom kända mönster kan du använda likhet mellan inbäddningar och tidigare exempel.
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
Fördelar: Snabbt (endast en vektoruppslagning) och kan förbättras med fler märkta exempel. Nackdelar: Kräver att man bygger ett märkt urval av exempel.
Metod 4: Kaskad
Prova billiga alternativ först; eskalera vid behov.
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
Fördelar: Anpassningsbar och låg genomsnittlig kostnad. Nackdelar: Långsamt för fall som kräver eskalering (två anrop), kräver tillförlitlig validering.
I praktiken använder många produktionssystem en hybrid: hårdkodad routning för de huvudsakliga uppgiftstyperna och kaskader för vissa undertyper med stor variation.
Fällorna
Ett par misstag att undvika:
Fälla 1: Att optimera för kostnad på bekostnad av kvalitet
Det är lätt att routa allt till små modeller och se kostnaderna sjunka. Det är svårare att notera att kvaliteten också har minskat. Följ alltid upp ändringar i routningen med kvalitetsövervakning.
En användbar disciplin är att skuggtesta eller A/B-testa en billigare väg tills urvalet täcker viktiga indataklasser och fellägen. En fast testvecka är inget bevis i sig. Lansera inte ändringen om inte de fördefinierade kvalitets- och säkerhetskriterierna är uppfyllda.
Fälla 2: Att göra routern onödigt komplicerad
En router med många uppgiftstyper och svårgenomtränglig logik kan vara svårare att underhålla än den routning som den ersätter. Börja med det minsta antal rutter som mätningarna motiverar.
Lägg bara till en rutt när den ändrar ett operativt beslut och ger en tillräckligt stor, uppmätt förbättring av en begränsande faktor för att motivera ansvar, tester och en reservväg.
Fälla 3: Att ignorera latens
Billigare modeller är inte nödvändigtvis snabbare. Mät latens och kvalitet separat. En kaskad som först provar en modell och sedan går över till en reservmodell lägger till minst ett extra försök i reservfallen och kan öka latensen i användarriktade flödens långsammaste del avsevärt.
För ett användarriktat och svarstidskänsligt svar ska du jämföra en direkt väg med en kaskad både för andelen godkända fall och för latensens höga percentiler. Kaskader är ofta lättare att tolerera i batchbearbetning eller asynkront arbete, men rätt väg beror på arbetsbelastningen.
Fälla 4: Att inte hantera leverantörsfel
När du är beroende av flera modeller finns det också fler sätt att misslyckas. En flaggskeppsmodell kan få driftavbrott, en hastighetsgräns kan slå till eller en API-nyckel kan löpa ut. Routningslogiken behöver testade reservmekanismer.
Definiera ett tydligt beteende för hastighetsgränser, tidsgränser och leverantörsfel. En övergång till en annan leverantör är bara lämplig om dess villkor för databehandling, regionala dataväg, verktygs- och schemakontrakt samt utvärderingsresultat är godtagbara. Låt annars anropet avbrytas på ett säkert sätt, köa det eller eskalera det; att returnera ett väsentligt sämre svar är inte detsamma som tillgänglighet.
Fälla 5: Att inte mäta kvaliteten per rutt
Du behöver veta vilken väg som fungerar bra och vilken som inte gör det. Det innebär utvärdering, helst automatiserad.
En användbar uppställning: för varje produktionsanrop, logga vilken modell som använts, begäran, svaret och (där det är möjligt) en kvalitetsindikator (användarfeedback, mått senare i processen, automatisk utvärdering). Sammanfatta mätetal per rutt. Fånga upp kvalitetsförändringar innan användarna klagar.
Validera föränderliga beroenden på nytt
Modell-ID:n, avvecklingsdatum, kontextgränser, priser, hastighetsgränser, regional behandling och semantiken för strukturerade utdata och verktyg kan ändras oberoende av varandra. Granska leverantörens aktuella dokumentation och kör om ruttutvärderingarna innan du ändrar ett alias. En OpenAI-kompatibel transport garanterar inte likvärdiga scheman, verktygsbeteenden, tokenredovisning, säkerhetspolicyer eller datahantering.
En startchecklista
Om du bygger ett flermodellssystem från grunden eller migrerar från en enda modell:
-
Kartlägg dina uppgifter. Vilka typer av LLM-anrop gör din applikation? Ungefär hur ofta? Ungefär hur dyrt?
-
Klassificera efter komplexitet. För varje uppgiftstyp, avgör: trivial, måttlig eller komplex. Matcha mot modellnivå.
-
Bygg en router. Börja med hårdkodad uppgiftsbaserad routning. Gör inte lösningen onödigt komplicerad.
-
Definiera felhanteringen. Använd en testad reservväg, kö, ett säkert avbrytande eller eskalering till mänsklig granskning utifrån konsekvenserna och datapolicyn.
-
Mät kvaliteten per rutt. Konfigurera loggning och grundläggande utvärdering. Du måste veta om kvaliteten håller.
-
Iterera. Flytta uppgifter till billigare modeller där kvaliteten håller. Flytta tillbaka uppgifter till dyrare modeller där kvaliteten brister. Justera över tid.
-
Fortsätt justera. Modeller förändras, nya lanseras och priser ändras. En routningslösning som är optimal i maj 2026 kan vara sämre i november 2026.
Routa bara där underlaget stödjer det
Flermodellsorkestrering kan sänka kostnader eller latens när anropstyperna verkligen skiljer sig åt och varje rutt utvärderas. Den kan också öka driftskostnaden och minska enhetligheten. Publicera den uppmätta baslinjen, det routade resultatet, kvalitetsgränserna och provperioden i stället för ett generellt påstående om besparingar.
Routningsvillkoret kan vara kortfattat; produktionsarbetet handlar om konfigurationskontroll, utvärdering, observerbarhet, integritetsbedömning, semantik vid omförsök och reservvägar.
Kartlägg uppgifterna, jämför lämpliga kandidater, routa bara där underlaget motiverar det och fortsätt mäta efter lanseringen.
