Ühe mudeli kasutamine iga päringu puhul võib olla tarbetult kallis, kuid suunamine ei ole automaatselt paranemine.
Tiim võib avastada, et klassifitseerimine, tuletamine, mustandi koostamise ja keeruline järelduste tegemine nõuavad erinevat kvaliteeti ja latentsust. Suunamine saab neid erinevusi ära kasutada. See võib aga lisada klassifikaatori kõne, pakettide rikete režiimid, järjekindluse puudumise turvakäitumises ja rohkem hindamistööd. Ainus kaitstava kokkuhoidu väide on see, mis on arvutatud sinu mõõdetud tokenite, praeguste pakkujate hindade ja kvaliteedikünniste põhjal.
See on mitme mudeli koordineerimine: määratletud kõnetüübi jaoks mudeli või eriteenuse valimine selgete kvaliteedi, latentsuse, privaatsuse ja kulu piirangute alusel.
See artikkel käsitleb mustreid, marsruutimise loogikat, kompromisse ja annab samm-sammult juhise selle rakendamiseks.
Miks üks mudel ei ole optimaalne
Pakkujate kataloogid muutuvad sageli, kuid töökoormus võib siiski määrata funktsionaalsed tasandid:
Kõrge võimekusega arutlustasand: sobilikud mudelid keerulise planeerimise või analüüsi jaoks. Hinda oma juhtumite põhjal täpsust, tööriistade käitumist, sabalatentsust ja genereeritud arutlustokenite koguarvu.
Üldtasand: sobilikud mudelid kasutajale suunatud mustandite koostamiseks ja segatüüpi teadmustööks, kus kvaliteet on oluline, kuid pikendatud arutlus ei pruugi olla vajalik.
Madala latentsusega tasand: sobilikud mudelid piiratud ulatusega klassifitseerimise, väljavõtmise ja ümberkirjutamise jaoks. Väiksem mudel ei taga piisavat täpsust ega lühemat terviklatentsust.
Kohalik või väikese mudeli tasand: sobilikud mudelid siis, kui on oluline andmete kohapeal hoidmine, võrguühenduseta töö või mudeli teenindamise piirkulu. Võrdluses arvesta riistvara, käitustöö, energiakulu, paralleelsuse ja kvantiseerimise mõjuga.
Spetsialiseeritud teenused (embedding, ümberreastamine, pildi- ja kõnetöötlus): võrdle neid täpselt sama toimingut täitvate üldmudelitega; spetsialiseeritus üksi ei tõenda paremat kvaliteeti ega väiksemat kogukulu.
Kasuta otsuse tegemise ajal kehtivaid mudeli- ja hinnalehti: OpenAI mudelid ja hinnakiri, Anthropicu mudelid ja hinnakiri ning Google’i mudelid ja hinnakiri. Ära kinnista saadavust ega hindu pika elueaga arhitektuuriotsusesse.
Tüüpiline AI-rakendus teeb palju erinevat tüüpi LLM-kõnesid. Igal kõnel on oma nõuded:
- Kasutaja kavatsuse klassifitseerimine: hinnata madala latentsusega kandidaati märgistatud hulga põhjal, sealhulgas kahtlased ja väljaspool ulatust jäävad juhtumid.
- Struktureeritud andmete eraldamine: mõõta väljapõhist täpsust ja skeemi kehtivsust, mitte mudeli suurust.
- Kasutajale suunatud vastuse koostamine: mõõda faktitäpsust, poliitika järgimist ja sabalatentsust.
- Eelmise vestluse kokkuvõtte tegemine: testida otsuste, nimede, piirangute ja eituste vahelejätmist.
- Pakktöötlus taustal: mõõda läbilaskevõimet, taaskatsekulu ja tähtaja täitmist.
Ära eelda, et odavaim kandidaat on piisav või et kalleim kandidaat on parim. Kasuta iga marsruu jaoks sama hindamishulka.
Arvuta sääst telemetria põhjal
Koguge iga kõnetüübi kohta:
- kuine kõnede arv;
- sisend-, vahemälu-sisendi- ja väljundtokenite jaotus;
- taaskatse- ja kaskaadimäär;
- tööriistade, otsingu, pakktöötluse või majutuse tasud;
- latentsuse protsentiilid; ning
- läbimise määr marsruudi väljaandehindamisel.
Arvuta igale kandidaatmarsruudile kulu praeguste hindade põhjal:
kuine marsruudi kulu = kõned × (
sisendtokenid × sisendihind
+ vahemälu tokenid × vahemäluhind
+ väljundtokenid × väljundihind
) + tööriista tasud + majutus + oodatav taaskatsekulu
Võrdle seda lähtetasemega ainult kandidaatide puhul, mis läbivad samad kvaliteedi ja ohutuse väljalase kriteeriumid. Kirjuta eeldused tulemuse kõrvale. Marsruut, mis säästab tokenikulu, kuid suurendab käsitsi paranduste arvu, sündmuste või latentsust, võib kokkuvõttes kallim olla.
Kui telemetriat ei ole, käivita esmalt varjutatud hindamine. Ära avalda säästu protsenti üldise liikluse jaotuse põhjal.
Põhilised orkestreerimise mustrid
Tootmises olevates mitme mudeli süsteemides korduvad mõned mustrid:
Muster 1: Ülesandepõhine marsruutimine
Erinevat tüüpi ülesanded lähevad erinevatesse mudelitesse. See on kõige lihtsam muster.
# 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
Ülesanded klassifitseerib kutsuv kood (ta teab, mida ta küsib). Marsruutimine on deterministlik ja lihtne silumiseks.
Muster 2: Keerukusepõhine marsruutimine
Süsteem hindab iga päringu keerukust ja marsruudib selle vastavalt.
def route_by_complexity(request):
complexity = estimate_complexity(request)
if complexity < 3:
return "small"
elif complexity < 7:
return "mid"
else:
return "flagship"
Keerukuse hinnang võib olla heuristiline (päringu pikkus, märksõnade tuvastamine) või mudelipõhine (odav klassifikaator hindab päringu). See muster lahendab juhtumeid, kus sama ülesandetüüp varieerub raskusastmelt.
Muster 3: Kaskaadmarsruutimine
Proovi kõigepealt odavat mudelit. Kui väljund on hea, kasuta seda. Kui mitte, eskaleeri kallima mudelini.
def cascade(request):
cheap_response = call_model("small", request)
if is_acceptable(cheap_response):
return cheap_response
return call_model("flagship", request)
See toimib siis, kui „vastuvõetav” on tuvastatav — kindlustunde skooride, valideerijate või eraldiseisva kvaliteedikontrolli-LLM-i abil. See on võimas: enamikule lihtsatele päringutele vastab odav mudel; ainult rasked jõuavad kalli mudelini.
Muster 4: Spetsialiseeritud marsruutimine
Kasuta spetsialiseeritud mudeleid spetsialiseeritud ülesannete jaoks:
- Embedding’ud: kasuta selleks mõeldud embedding-mudelit (palju odavam kui chat-mudel, mida kasutatakse embedimiseks).
- Ümberreastamine: kasuta selleks mõeldud ümberreastajat.
- Nägemine: kasuta nägemisele spetsialiseeritud mudelit pilditöötluseks.
- Hääl: kasuta häälemudelit transkribeerimiseks/sünteesiks.
- Kood: kasuta koodile spetsialiseeritud mudelit kooditöödeks.
Spetsialiseeritud või väiksemad mudelid võivad olla kitsamas ülesandes kiiremad, odavamad või paremad, kuid ükski neist eelistest ei jutu sellest, et mudel on märgistatud nii. Silt ei garanteeri ühtegi eelist. Testi konkreetset mudelit, pakkujat, prompti, keelt, latentsuse protsentiili, hinnakirja ja hindamisandmestikku.
Muster 5: Pakkuja-marsruutimine
Kasuta mudeleid mitmelt pakkujalt liiasuse ja hindade võimenduse jaoks.
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)
See annab vastupidavuse ühe pakkuja tõrgete ja päringupiirangute vastu. Samuti võimaldab see ära kasutada hinnamuutusi — kui pakkuja langetab hindu, suuna sinna rohkem liiklust.
Realistlik näide: klienditoe AI
Et asja konkreetseks teha, vaatame, kuidas klienditoe AI võiks mitme mudeli orkestreerimist kasutada.
Süsteemil on igale piletile järgmised sammud:
Samm 1: Klassifitseeri kavatsus. Mille kohta klient küsib?
Marsruudikandidaat: madala latentsusega mudel, mis töötleb märgistatud kavatsuste komplekti.
Samm 2: Määra kiireloomulisus ja sentiment. Kas klient on pahane? Kas see on kiireloomuline?
Marsruudikandidaat: sama mudel ainult siis, kui kiireloomuliste väärklassifitseerimiste arv (false negatives) vastab eraldi määratletud ohutuslävele; meeleolu ei ole kiireloomulisuse usaldusväärne indikaator.
Samm 3: Otsi asjakohaseid teadmisi.
Marsruudikandidaat: sisemudeli otsing ja ümberjärjestaja, mida hinnatakse piletispetsiifilise otsingukogumi põhjal.
Samm 4: Otsusta, kas AI saab sellele vastata või on vaja inimene appi tuua.
Marsruudikandidaat: mudel, mida on spetsiaalselt hinnatud täieliku tabamissageduse (recall) osas. Reeglid peaksid sundima inimlikku sekkumist konto ligipääsu, ohutuse, õiguslike küsimuste, rahaliste või muude poliitikaga määratletud olukordade puhul.
Samm 5 (kui AI saab vastata): Genereeri kliendile suunatud vastus.
Marsruutimise kandidaat: kõrgema kvaliteediga üldmudel. Hoia see mustandina, kuni faktipädevus, poliitika, privaatsus ja toon läbivad väljalaskmise kriteeriumid.
Samm 6 (kui AI ei saa vastata): Genereeri kokkuvõte inimagendile.
Marsruutimise kandidaat: madalama hinnaga mudel, mille kokkuvõtted säilitavad probleemi, tõendid, proovitud sammud, kliendi piirangud ja ebakindluse.
Samm 7: Kvaliteedikontroll. Kas vastus vastas meie standarditele?
Marsruutimise kandidaat: deterministlikud kontrollid koos kalibreeritud kohtunikuga. Kohtuniku mudel ei ole sõltumatu garantii; proovi selle otsuseid koos inimestega.
Seira iga sammu, seejärel sisesta ülaltoodud kuluvalemisse mõõdetud tokenijaotused, kehtivad hinnad, eskaleerimise ja korduskatsete osakaal ning inimeste tehtava läbivaatuse kulu. Näide ei anna teadlikult üldist säästuprognoosi: tulemuse määravad juhtumite koosseis ja vastuvõtukriteeriumid.
Marsruutimise loogika
Mõned lähenemised marsruutimise rakendamiseks:
Lähenemine 1: Kõvasti kodeeritud ülesandetüübi järgi
Kõige lihtsam. Sa tead, mis ülesannet kutsud, sa valid mudeli.
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}"}]
)
Plussid: läbipaistev, kerge siluda, kerge muuta. Miinused: ei kohandu päringu keerukusega ülesandetüübi sees.
Lähenemine 2: Marsruuter-mudel
Väike mudel klassifitseerib iga päringu ja marsruudib selle.
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]
Plussid: kohandub kategooria sisesele keerukusele. Miinused: lisab latentsust (marsruuteri kõne), lisab tõrkepunkti, vajab häälestamist.
Lähenemine 3: Embedding-põhine marsruuter
Päringute puhul, mis kuuluvad tuntud mustritesse, kasuta embedding-sarnasust varasemate näidetega.
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
Plussid: kiire (lihtsalt vektorotsing), läheb andmetega targemaks. Miinused: nõuab märgistatud näidiste komplekti ülesehitamist.
Lähenemine 4: Kaskaad
Proovi kõigepealt odavat; eskaleeri vajadusel.
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
Plussid: kohanev, madal keskmine kulu. Miinused: aeglane juhtumitele, mis vajavad eskaleerimist (kaks kõnet), nõuab usaldusväärset valideerimist.
Praktikas kasutavad paljud tootmissüsteemid hübriidi: kõvasti kodeeritud marsruutimine peamiste ülesandetüüpide jaoks, koos kaskaadidega konkreetsete suure varieeruvusega alatüüpide jaoks.
Lõksud
Mõned vead, mida vältida:
Lõks 1: Kulude optimeerimine kvaliteedi halvenemise hinnaga
On lihtne suunata kõik väikestesse mudelitesse ja vaadata, kuidas kulu langeb. On raskem märgata, et kvaliteet langes ka. Pari marsruutimismuudatused alati kvaliteedi jälgimisega.
Kasulik distsipliin: varjuta või tee A/B-testi odavamat marsruuti, kuni proov hõlmab olulisi sisuklasse ja ebaõnnestumise mudeleid. Üks kindel nädal ei ole iseenesest tõend. Ära tee muudatust tootmiskeskkonda, kui eelnevalt deklareeritud kvaliteedi- ja ohutusnõuded ei täitu.
Lõks 2: Marsruuteri üledisain
Marsruuter, millel on palju ülesandetüüpe ja läbipaistmatu loogika, võib olla raskem hooldada kui marsruutimine, mille see asendab. Alusta minimaalse arvuga marsruute, mida sinu mõõtmised õigustavad.
Lisa marsruut ainult siis, kui see muudab operatiivset otsust ja parandab mõõdetavat piirangut piisavalt, et õigustada omandi, testide ja varutee.
Lõks 3: Latentsuse ignoreerimine
Odavamad mudelid ei ole tingimata kiiremad. Mõõda latentsust ja kvaliteeti eraldi. Kaskaad (proovi üht mudelit, siis lange tagasi) lisab varujuhtumite jaoks vähemalt ühe täiendava katse ja võib kasutajale suunatud voogudes oluliselt suurendada sabalatentsust.
Kasutajale suunatud latentsustundliku vastuse puhul võrdle otseühendust kaskaadiga nii läbilaskevõime kui ka sabalatentsuse alusel. Kaskaadid on sageli paremini talutavad pakett- või asünkroontöös, kuid õige lahendus sõltub töökoormusest.
Lõks 4: Pakkujate tõrgete eiramine
Kui sõltud mitmest mudelist, on sul mitu võimalust ebaõnnestumiseks. Lipulaeva mudel läheb maha, päringupiirang lööb sisse, API-võti aegub. Sinu marsruutimise loogika vajab varuvariante.
Määra selge käitumine määrapiirangute, ajalõpud ja pakkuja vead. Ristpakkuja varuvariant on sobilik ainult siis, kui selle andmetöötlustingimused, piirkondlik trass, tööriista/skeemi leping ja hindamistulemused on aktsepteeritavad. Vastasel juhul lülita välja, pane järjekorda või eskaleeri; oluliselt halvem vastuse tagastamine ei ole saadavus.
Lõks 5: Marsruudi-põhise kvaliteedi mittemõõtmine
Sa pead teadma, milline marsruut töötab hästi ja milline mitte. See tähendab hindamist, ideaalis automatiseeritud.
Kasulik seadistus: iga tootmiskõne kohta logi kasutatud mudel, päring, vastus ja (kui võimalik) mingi kvaliteedisignaal (kasutaja tagasiside, järgneva etapi mõõdikud, automaatne hindamine). Tee marsruudipõhised mõõdikud kokkuvõttena. Püüa kvaliteedi triivimine kinni enne, kui kasutajad kurdavad.
Revalideeri elusad sõltuvused
Mudeli ID-d, väljalaske lõppemise kuupäevad, konteksti piirid, hinnad, sageduspiirangud, regioonipõhine töötlemine ja struktureeritud väljundi/tööriista semantika võivad muutuda sõltumatult. Vaata läbi pakkujate reaalajas uuenduv dokumentatsioon ja jälle jooksuta marsruudi hinnangud enne aliase muutmist. OpenAI-ga ühilduv transpordikiht ei garanteeri samaväärseid skeeme, tööriista käitumist, tokenite arvestust, turvapolitiikat ega andmete käsitlemist.
Algajatele mõeldud kontrollnimekiri
Kui ehitad mitme mudeli süsteemi nullist või migreerid ühe mudeli süsteemist:
-
Kaardista oma ülesanded. Mis tüüpi LLM-kõnesid sinu rakendus teeb? Umbes kui sageli? Umbes kui kallid?
-
Kategoriseeri keerukuse järgi. Iga ülesandetüübi puhul otsusta: triviaalne, mõõdukas või keeruline. Vasta mudelite tasanditele.
-
Ehita marsruuter. Alusta kõvasti kodeeritud ülesandepõhisest marsruutimisest. Ära üledisaini.
-
Määra veakäitumine. Kasuta testitud varuvarianti, järjekorda, fail-closed vastust või inimesele edastamist vastavalt tagajärje tõsidusele ja andmepoliitikale.
-
Mõõda kvaliteeti marsruudi kaupa. Sea üles logimine ja põhihindamine. Sa pead teadma, kas kvaliteet püsib.
-
Itereeri. Vii ülesandeid odavamatesse mudelitesse, kus kvaliteet püsib. Vii ülesandeid tagasi kallimatesse mudelitesse, kus kvaliteet murdub. Kohanda aja jooksul.
-
Ära lõpeta häälestamist. Mudelid muutuvad. Tulevad uued. Hinnad nihkuvad. Marsruutimisseadistus, mis on mais 2026 optimaalne, võib olla novembris 2026 ebaoptimaalne.
Marsruteeri ainult seal, kus tõendid seda toetavad
Mitme mudeli orkestreerimine võib vähendada kulusid või latentsust, kui päringutüübid erinevad oluliselt ja iga marsruut on hinnatud. See võib samuti suurendada operatiivkulusid ja alandada järjepidevust. Avalda mõõdetud lähtetase, marsruuteeritud tulemus, kvaliteedikünnised ja näidisperiood selle asemel, et teha üldist kokkuhoiuväidet.
Marsruutimise tingimus võib olla lühike; tootmise töö on konfiguratsiooni kontroll, hindamine, jälgitavus, privaatsuse läbivaatamine, taaskatse semantika ja varuvariandid.
Kaardista oma ülesanded, võrdle sobivaid kandidaate, marsruteeri ainult seal, kus tõendid seda õigustavad, ja jätka mõõtmist pärast väljalaset.
