Monen mallin orkestrointi: reititys kustannuksen, viiveen ja laadun perusteella

Yhden mallin käyttäminen kaikkiin kutsuihin voi tulla tarpeettoman kalliiksi. Reititys ei kuitenkaan automaattisesti paranna järjestelmää.

Tiimi voi havaita, että luokittelu, tiedon poiminta, luonnostelu ja vaativa päättely edellyttävät erilaista laatua ja viivettä. Reititys voi hyödyntää näitä eroja. Samalla se voi lisätä luokitinkutsun, palveluntarjoajakohtaisia virhetilanteita, epäjohdonmukaista turvallisuuskäyttäytymistä ja arviointityötä. Ainoa perusteltavissa oleva säästöväite lasketaan omista mitatuista tokenimääristä, ajantasaisista hinnoista ja laatukynnyksistä.

Tätä kutsutaan monen mallin orkestroinniksi: määritellylle kutsutyypille valitaan malli tai erikoistunut palvelu nimenomaisten laatu-, viive-, tietosuoja- ja kustannusrajojen puitteissa.

Tässä artikkelissa käsitellään orkestroinnin toimintamallit, reitityslogiikka, kompromissit ja vaiheittainen toteutus.

Miksi yksi malli ei aina ole paras ratkaisu

Palveluntarjoajien mallivalikoimat muuttuvat usein, mutta työkuormalle voidaan silti määritellä toiminnallisia tasoja:

Vaativan päättelyn taso: vaikean suunnittelun tai analyysin ehdokasmallit. Arvioi omilla tapauksillasi tarkkuutta, työkalujen käyttöä, viivejakauman häntäpäätä ja tuotettujen päättelytokenien kokonaismäärää.

Yleistaso: käyttäjille näkyvän tekstin luonnosteluun ja vaihtelevaan tietotyöhön sopivat ehdokkaat, joissa laatu on tärkeää mutta laajennettu päättely ei välttämättä ole tarpeen.

Pienen viiveen taso: rajattuun luokitteluun, tiedon poimintaan ja uudelleenmuotoiluun sopivat ehdokkaat. Pienempi malli ei takaa riittävää tarkkuutta tai lyhyempää kokonaisviivettä.

Paikallisten tai pienten mallien taso: ehdokkaat tilanteisiin, joissa tiedon sijainti, verkkoyhteydetön käyttö tai suorituskohtainen rajakustannus on tärkeä. Sisällytä vertailuun laitteisto, ylläpito, energiankulutus, rinnakkaisuus ja kvantisoinnin vaikutukset.

Erikoistuneet palvelut (upotukset, uudelleenjärjestys, konenäkö ja puhe): vertaa niitä yleismalleihin täsmälleen samassa tehtävässä. Erikoistuminen ei yksin osoita parempaa laatua tai pienempiä kokonaiskustannuksia.

Tarkista päätöshetkellä ajantasaiset malli- ja hinnoittelusivut: OpenAI-mallit ja hinnoittelu, Anthropic-mallit ja hinnoittelu sekä Google-mallit ja hinnoittelu. Älä tee pitkäikäistä arkkitehtuuripäätöstä olettaen, että saatavuus tai hinnat pysyvät ennallaan.

Tyypillinen tekoälysovellus tekee monenlaisia LLM-kutsuja, joilla kullakin on omat vaatimuksensa:

• Käyttäjän tarkoituksen luokittelu: vertaa pienen viiveen ehdokasta merkittyyn aineistoon, jossa on myös monitulkintaisia ja rajauksen ulkopuolisia tapauksia.
• Rakenteisen tiedon poiminta: mittaa kenttäkohtaista tarkkuutta ja rakenteen kelvollisuutta, älä mallin kokoa.
• Käyttäjälle näkyvän vastauksen tuottaminen: mittaa tosiasioiden paikkansapitävyyttä, toimintaperiaatteiden noudattamista ja viiveen häntäpäätä.
• Aiemman keskustelun tiivistäminen: testaa, jäävätkö päätökset, nimet, rajoitukset tai kiellot pois.
• Eräajo taustalla: mittaa läpimenoa, uudelleenyritysten kustannusta ja valmistumista määräaikaan mennessä.

Älä oleta, että halvin vaihtoehto riittää tai että kallein on paras. Arvioi jokaisen reitin ehdokkaat samalla testiaineistolla.

Laske säästöt telemetriasta

Kerää jokaisesta kutsutyypistä:

• kutsujen kuukausittainen määrä
• syöte-, välimuistisyöte- ja tulostokenien jakaumat
• uudelleenyritysten ja varareiteille siirtymisen osuus
• työkalu-, haku-, eräajo- ja käyttöympäristökulut
• viiveen prosenttipisteet
• reitin julkaisuun käytetyn arvioinnin läpäisyaste.

Laske jokainen ehdokasreitti ajantasaisilla hinnoilla:

monthly route cost = calls × (
  input_tokens × input_price
  + cached_tokens × cached_price
  + output_tokens × output_price
) + tool_charges + hosting + expected_retry_cost

Vertaa tulosta lähtötasoon vain niiden ehdokkaiden osalta, jotka täyttävät samat laadun ja turvallisuuden julkaisukriteerit. Ilmoita laskelman oletukset tuloksen yhteydessä. Tokenikuluja säästävä reitti voi tulla kokonaisuutena kalliimmaksi, jos se lisää käsin tehtäviä korjauksia, häiriöitä tai viivettä.

Jos telemetriaa ei vielä ole, tee ensin varjoarviointi. Älä julkaise säästöprosenttia yleisen liikennejaon perusteella.

Orkestroinnin perusmallit

Seuraavat toimintamallit toistuvat tuotantokäytössä olevissa monen mallin järjestelmissä.

Malli 1: Tehtäväkohtainen reititys

Eri tehtävätyypit ohjataan eri malleille. Tämä on yksinkertaisin malli.

# 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

Kutsuva ohjelmakoodi luokittelee tehtävän, koska se tietää, mitä on pyytämässä. Reititys on deterministinen ja helposti selvitettävissä virhetilanteissa.

Malli 2: Vaativuuteen perustuva reititys

Järjestelmä arvioi jokaisen pyynnön vaativuuden ja valitsee reitin sen perusteella.

def route_by_complexity(request):
    complexity = estimate_complexity(request)
    if complexity < 3:
        return "small"
    elif complexity < 7:
        return "mid"
    else:
        return "flagship"

Vaativuusarvio voi perustua heuristiikkaan, kuten pyynnön pituuteen tai avainsanoihin, tai malliin, jossa edullinen luokitin pisteyttää pyynnön. Tämä malli sopii tilanteisiin, joissa saman tehtävätyypin vaikeus vaihtelee.

Malli 3: Porrastettu reititys

Kokeile ensin edullista mallia. Jos tulos hyväksytään, käytä sitä. Muussa tapauksessa siirrä pyyntö suorituskykyisemmälle ja kalliimmalle mallille.

def cascade(request):
    cheap_response = call_model("small", request)
    if is_acceptable(cheap_response):
        return cheap_response
    return call_model("flagship", request)

Tämä toimii vain, jos hyväksyttävyys voidaan havaita luotettavasti esimerkiksi luottamusarvolla, deterministisellä tarkistimella tai erillisellä laatua arvioivalla LLM:llä. Yksinkertaiset pyynnöt voidaan hoitaa edullisella mallilla ja vaikeat siirtää kalliimmalle, mutta toimivuus on osoitettava mittaamalla.

Malli 4: Erikoistumiseen perustuva reititys

Käytä erikoistuneita malleja niitä vastaaviin tehtäviin:

• Upotukset: käytä erillistä upotusmallia sen sijaan, että loisit upotukset keskustelumallilla.
• Uudelleenjärjestys: käytä tähän tarkoitettua uudelleenjärjestysmallia.
• Konenäkö: käytä kuvien analysointiin konenäköön soveltuvaa mallia.
• Puhe: käytä puhemallia litterointiin tai puhesynteesiin.
• Koodi: käytä kooditehtäviin siihen soveltuvaa mallia.

Erikoistunut tai pienempi malli voi olla rajatussa tehtävässä nopeampi, edullisempi tai parempi, mutta nimike ei vielä osoita mitään näistä eduista. Vertaa juuri kyseistä mallia, palveluntarjoajaa, kehotetta, kieltä, viiveen prosenttipistettä, hintaa ja arviointiaineistoa.

Malli 5: Palveluntarjoajakohtainen reititys

Useiden palveluntarjoajien malleja voidaan käyttää vikasietoisuuden ja hinnoitteluvaihtoehtojen vuoksi.

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)

Tämä voi parantaa häiriönsietoa yksittäisen palveluntarjoajan käyttökatkon tai pyyntörajoituksen aikana. Se antaa myös mahdollisuuden reagoida hintamuutoksiin, mutta liikennettä ei pidä siirtää ilman uuden reitin laatu-, turvallisuus- ja tietosuojatarkistuksia.

Käytännön esimerkki: tekoäly asiakaspalvelussa

Seuraava esimerkki havainnollistaa, miten asiakaspalvelun tekoäly voisi käyttää monen mallin orkestrointia.

Järjestelmä käsittelee jokaisen tukipyynnön näissä vaiheissa:

Vaihe 1: Luokittele tarkoitus. Mitä asiakas kysyy?

Reittiehdokas: pienen viiveen malli, joka läpäisee merkityn tarkoitusluokitteluaineiston.

Vaihe 2: Arvioi kiireellisyys ja sävy. Onko asiakas turhautunut? Onko asia kiireellinen?

Reittiehdokas: sama malli vain, jos kiireellisten tapausten väärät negatiiviset tulokset pysyvät erikseen määritellyn turvallisuuskynnyksen sisällä. Sävy ei ole luotettava kiireellisyyden korvike.

Vaihe 3: Hae olennainen tieto.

Reittiehdokas: upotushaku ja uudelleenjärjestysmalli, jotka on arvioitu tukipyyntöjä edustavalla hakuaineistolla.

Vaihe 4: Päätä, voiko tekoäly vastata vai tarvitaanko ihminen.

Reittiehdokas: malli, jota on arvioitu nimenomaan ihmiskäsittelyyn ohjaamisen herkkyyden perusteella. Sääntöjen on pakotettava ohjaus ihmiselle käyttäjätilin käyttöön, turvallisuuteen, oikeudellisiin tai taloudellisiin kysymyksiin sekä muihin toimintaperiaatteissa määriteltyihin tapauksiin.

Vaihe 5 (jos tekoäly voi vastata): Laadi asiakkaalle vastaus.

Reittiehdokas: laadukas yleismalli. Pidä vastaus luonnoksena, kunnes tosiasiat, toimintaperiaatteiden noudattaminen, tietosuoja ja sävy täyttävät julkaisukriteerit.

Vaihe 6 (jos tekoäly ei voi vastata): Laadi yhteenveto asiakaspalvelijalle.

Reittiehdokas: edullisempi malli, jonka yhteenveto säilyttää ongelman, aineiston, jo kokeillut toimet, asiakkaan rajoitukset ja epävarmuudet.

Vaihe 7: Tarkista laatu. Täyttääkö vastaus vaatimukset?

Reittiehdokas: deterministiset tarkistukset ja kalibroitu arviointimalli. Arviointimalli ei anna riippumatonta takuuta, joten ihmisten on tarkastettava otos sen päätöksistä.

Instrumentoi jokainen vaihe. Täytä sitten edellä esitetty kustannuskaava mitatuilla tokenijakaumilla, ajantasaisilla hinnoilla, ihmiselle ohjattujen tapausten osuudella, uudelleenyritysten osuudella ja ihmistyön kustannuksella. Esimerkki ei tarkoituksella sisällä yleistä säästöarviota, koska tulos riippuu tukipyyntöjen jakaumasta ja hyväksymiskynnyksistä.

Reitityslogiikan toteutus

Reititys voidaan toteuttaa usealla tavalla.

Tapa 1: Kiinteä reitti tehtävätyypin mukaan

Yksinkertaisimmassa ratkaisussa kutsuva koodi tuntee tehtävätyypin ja valitsee mallin.

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}"}]
    )

Hyödyt: läpinäkyvä, helppo selvittää ja helppo muuttaa. Haitat: ei mukaudu tehtävätyypin sisäiseen vaativuuden vaihteluun.

Tapa 2: Reititinmalli

Pieni malli luokittelee jokaisen pyynnön ja valitsee reitin.

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]

Hyödyt: mukautuu luokan sisäisiin vaativuuseroihin. Haitat: lisää reititinkutsun viiveen ja yhden virhepisteen sekä vaatii säätämistä.

Tapa 3: Upotuksiin perustuva reititin

Tunnettuihin malleihin sopivat pyynnöt voidaan reitittää vertaamalla upotuksia aiempiin esimerkkeihin.

def route(request):
    embedding = embed(request)
    closest = find_nearest_example(embedding)
    return closest.suggested_model

Hyödyt: nopea vektorihaku ja mahdollisuus hyödyntää kasvavaa esimerkkiaineistoa. Haitat: edellyttää merkittyjen esimerkkien aineistoa.

Tapa 4: Porrastus

Kokeile ensin edullista mallia ja siirry kalliimpaan vain tarvittaessa.

def cascade(request):
    cheap = small_model_call(request)
    if validates(cheap):
        return cheap
    return flagship_call(request)

Hyödyt: mukautuva reitti ja mahdollisesti pieni keskimääräinen kustannus. Haitat: kalliimpaa mallia tarvitsevat tapaukset ovat hitaita kahden kutsun vuoksi, ja ratkaisu edellyttää luotettavaa tarkistusta.

Monissa tuotantojärjestelmissä käytetään näiden yhdistelmää: tärkeimmille tehtävätyypeille määritellään kiinteät reitit ja voimakkaasti vaihteleville alatyypeille porrastus.

Sudenkuopat

Vältä erityisesti seuraavia virheitä.

Sudenkuoppa 1: Kustannusten pienentäminen laadun kustannuksella

Kaiken liikenteen voi helposti reitittää pienille malleille ja nähdä kustannusten laskevan. Samanaikaista laadun heikkenemistä on vaikeampi havaita. Yhdistä jokainen reititysmuutos laadun seurantaan.

Hyvä käytäntö on varjotesti tai A/B-testi, jota jatketaan, kunnes otos kattaa tärkeät syöteluokat ja virhetilanteet. Pelkkä kiinteä viikon testijakso ei ole näyttöä. Älä julkaise muutosta, elleivät etukäteen määritellyt laatu- ja turvallisuuskriteerit täyty.

Sudenkuoppa 2: Liian monimutkainen reititin

Lukuisia tehtävätyyppejä ja läpinäkymätöntä logiikkaa sisältävä reititin voi olla vaikeampi ylläpitää kuin reititys, jonka sen oli tarkoitus korvata. Aloita pienimmästä mittausten perustelemasta reittimäärästä.

Lisää reitti vain, jos se muuttaa toiminnallista päätöstä ja parantaa mitattua ominaisuutta niin paljon, että omistajuus, testit ja varareitti ovat perusteltuja.

Sudenkuoppa 3: Viiveen sivuuttaminen

Edullisempi malli ei välttämättä ole nopeampi. Mittaa viive ja laatu erikseen. Porrastus lisää varareitille siirtyvissä tapauksissa vähintään yhden ylimääräisen yrityksen ja voi kasvattaa käyttäjälle näkyvien työnkulkujen viivejakauman häntäpäätä olennaisesti.

Vertaa viiveherkässä käyttäjätoiminnossa suoraa reittiä porrastukseen sekä läpäisyasteen että viiveen häntäpään perusteella. Porrastus voi olla helpompi hyväksyä eräajossa tai asynkronisessa työssä, mutta oikea valinta riippuu työkuormasta.

Sudenkuoppa 4: Palveluntarjoajien häiriöiden sivuuttaminen

Useat mallit tuovat useita virhetapoja. Tehokkain malli voi olla poissa käytöstä, pyyntöraja voi täyttyä tai API-avain voi vanhentua. Reitityslogiikka tarvitsee varatoiminnan.

Määritä toiminta pyyntörajojen, aikakatkaisujen ja palveluntarjoajan virheiden varalta. Toisen palveluntarjoajan varareitti sopii vain, jos sen tietojenkäsittelyehdot, alueellinen reitti, työkalu- ja rakennesopimus sekä arviointitulokset ovat hyväksyttäviä. Muussa tapauksessa keskeytä turvallisesti, aseta pyyntö jonoon tai siirrä se ihmiselle. Olennaisesti heikomman vastauksen palauttaminen ei tarkoita hyvää saatavuutta.

Sudenkuoppa 5: Reittikohtaisen laadun jättäminen mittaamatta

Sinun on tiedettävä, mikä reitti toimii ja mikä ei. Tämä edellyttää arviointia, mieluiten osittain automatisoituna.

Kirjaa jokaisesta tuotantokutsusta käytetty malli, pyyntö, vastaus ja mahdollisuuksien mukaan laatusignaali, kuten käyttäjäpalaute, jatkovaiheen mittari tai automaattinen arviointi. Kokoa mittarit reiteittäin ja tunnista laadun heikkeneminen ennen käyttäjiä.

Tarkista muuttuvat riippuvuudet uudelleen

Mallitunnukset, poistumispäivät, kontekstirajat, hinnat, pyyntörajat, alueellinen käsittely sekä rakenteisten tulosten ja työkalujen toiminta voivat muuttua toisistaan riippumatta. Tarkista palveluntarjoajan ajantasainen dokumentaatio ja aja reitin arvioinnit uudelleen ennen aliaksen vaihtamista. OpenAI-yhteensopiva siirtotapa ei takaa samanlaisia rakenteita, työkalujen toimintaa, tokenlaskentaa, turvallisuusperiaatteita tai tietojenkäsittelyä.

Aloitustarkistuslista

Jos rakennat monen mallin järjestelmää alusta tai siirryt yhden mallin ratkaisusta, etene näin:

1. Kartoita tehtävät. Millaisia LLM-kutsuja sovellus tekee, kuinka usein ja millä kustannuksella?

2. Luokittele vaativuus. Arvioi jokaisen tehtävätyypin vaativuus ja yhdistä se sopivaan mallitasoon.

3. Rakenna reititin. Aloita kiinteästä tehtäväkohtaisesta reitityksestä. Älä tee ratkaisusta tarpeettoman monimutkaista.

4. Määritä virhetilanteiden toiminta. Valitse seurauksen ja tietosuojakäytännön perusteella testattu varareitti, jonotus, turvallinen keskeytys tai siirto ihmiselle.

5. Mittaa laatu jokaisella reitillä. Ota käyttöön lokitus ja perusarviointi. Sinun on tiedettävä, säilyykö laatu.

6. Kehitä mittausten perusteella. Siirrä tehtävä edullisemmalle mallille, jos laatu säilyy, ja takaisin kalliimmalle, jos se heikkenee.

7. Jatka arviointia. Mallit ja hinnat muuttuvat. Toukokuussa 2026 sopivin reititys voi olla marraskuussa 2026 jo huonompi vaihtoehto.

Reititä vain näytön perusteella

Monen mallin orkestrointi voi vähentää kustannuksia tai viivettä, jos kutsutyypit todella eroavat ja jokainen reitti on arvioitu. Se voi myös kasvattaa käyttökustannuksia ja heikentää johdonmukaisuutta. Julkaise yleisen säästöväitteen sijaan mitattu lähtötaso, reititetty tulos, laatukynnykset ja otosjakso.

Reititysehto voi olla lyhyt. Tuotantokelpoisuus edellyttää silti asetusten hallintaa, arviointia, havainnoitavuutta, tietosuojan tarkistamista, uudelleenyritysten määrittelyä ja varareittejä.

Kartoita tehtävät, vertaa mahdollisia malleja, reititä vain näytön perusteella ja jatka mittaamista julkaisun jälkeen.