Vuoden 2026 LLM-pino: mallit, inferenssi, työkalut ja kompromissit

Jos rakennat todellisia tekoälytuotteita vuonna 2026, et enää kysy, pitäisikö käyttää OpenAI:ta vai Anthropicia. Tällainen kysymyksenasettelu on kaksi vuotta vanhentunut. Teet kymmeniä päätöksiä kerroksittaisen pinon eri osissa, ja useimmilla niistä on merkitystä.

Tässä on käytännön arkkitehtuurikartta: mitä kuhunkin kerrokseen kuuluu, mitkä kompromissit on mitattava ja mitkä nopeasti muuttuvat valinnat on pidettävä vaihdettavissa. Jäljempänä mainitut tuotenimet tarkistettiin palveluntarjoajien dokumentaatiosta 4. elokuuta 2026. Ne ovat esimerkkejä, eivät paremmuusjärjestys tai suositus työkuormaan, jota emme ole arvioineet.

Mallikerroksen ajantasaiset ensisijaiset lähteet ovat OpenAI:n malliluettelo, Anthropicin mallikatsaus, Googlen Gemini-malliluettelo ja DeepSeekin malli- ja hintasivu.

Kerrokset

Pino näyttää pääpiirteissään tältä:

┌────────────────────────────────────┐
│       Application Layer            │  Your product / agent / workflow
├────────────────────────────────────┤
│   Orchestration / Frameworks       │  LangGraph, CrewAI, custom, direct
├────────────────────────────────────┤
│   Prompt + Context Management      │  Prompt templates, context engineering
├────────────────────────────────────┤
│   Retrieval / Memory               │  RAG, vector stores, structured memory
├────────────────────────────────────┤
│   Tool / MCP Layer                 │  Tool calling, MCP servers, function APIs
├────────────────────────────────────┤
│   Model Layer                      │  Specific model selection, routing
├────────────────────────────────────┤
│   Inference Layer                  │  Hosted APIs, self-hosted, edge
├────────────────────────────────────┤
│   Observability / Evals            │  Logging, tracing, eval suites
└────────────────────────────────────┘

Jokaisessa kerroksessa on useita käyttökelpoisia vaihtoehtoja. Yhden kerroksen valinta rajaa muiden kerrosten vaihtoehtoja. Varhaisiin päätöksiin on vaikea tehdä muutoksia: mallin valinta vaikuttaa inferenssin valintaan, joka puolestaan vaikuttaa orkestroinnin valintaan.

Käymme seuraavaksi läpi kaikki kerrokset.

Kerros 1: mallikerros

Vuonna 2026 mallit jakautuvat karkeisiin tasoihin. Sopivan tason valinta on järjestelmän yksittäisen kutsun kannalta merkittävin päätös.

Suorituskykyä painottavat tasot. Nykyisiä esimerkkejä ovat OpenAI GPT-5.6 Sol, Claude Fable 5 / Opus 5, Gemini 3.1 Pro Preview ja DeepSeek-V4-Pro. Niiden päättelyasetukset, työkalutuki, viiveet ja hinnat eroavat toisistaan. Älä oleta, että kalleimman listahinnan malli on paras tehtävässäsi, vaan vertaa lukittuja versioita edustavalla arviointiaineistolla.

Tasapainotetut tasot. Nykyisiä esimerkkejä ovat GPT-5.6 Terra, Claude Sonnet 5 ja Gemini 3.5 Flash. Ne ovat ehdokkaita yleiseen tuotantoliikenteeseen, eivät yleispäteviä oletusvalintoja. Mittaa tehtävän onnistuminen, aika ensimmäiseen tokeniin, kokonaisviive ja kustannukset oman syöte- ja tuotosjakaumasi perusteella.

Tehokkuutta painottavat tasot. Nykyisiä esimerkkejä ovat GPT-5.6 Luna, Claude Haiku 4.5, Gemini 3.5 Flash-Lite ja DeepSeek-V4-Flash. Ne sopivat luokitteluun, tietojen poimintaan, reititykseen ja suurten määrien generointiin, kun arviointi osoittaa edullisemman mallin ylittävän hyväksymisrajan.

Pienet ja laitteessa ajettavat mallit. Pienet avoimilla painoilla julkaistut mallit voivat toimia hyvin tarkasti rajatuissa rakenteisissa tehtävissä ja yksityisyyttä vaativassa paikallisessa käsittelyssä. Nopeus riippuu laitteistosta, kvantisoinnista, sekvenssin pituudesta ja rinnakkaisuudesta. Mittaa se äläkä julkaise yleispätevää viiveväitettä.

(Saatavuus ja nimet tarkistettiin 4.8.2026. Hintoja ei tarkoituksella kopioida tähän yleiskatsaukseen. Käytä päivätyssä kustannusmallissa OpenAI:n, Anthropicin, Googlen ja DeepSeekin hintasivuja.)

Erikoistuneet mallit. Upotus-, uudelleenjärjestely-, kuva-, ääni- ja ohjelmointiin erikoistuneet mallit voivat tarjota tarkasti rajattuun toimintoon paremman kustannuksen, viiveen tai laadun. Vertaa niitä yleismalliin juuri siinä toiminnossa. Erikoistuminen tai alempi listahinta ei yksin todista parempaa järjestelmätulosta.

Avoimilla painoilla julkaistut kärkimallit. DeepSeek V4, Qwen 3, Llama-perheen mallit ja Mistralin mallit voidaan ajaa palveluntarjoajan kautta tai omassa infrastruktuurissa kunkin mallin lisenssiehtojen mukaisesti. ”Avoin lähdekoodi” ei ole tässä turvallinen yleisnimitys: mallipainojen, opetuskoodin ja aineistojen avoimuus sekä kaupalliset ehdot vaihtelevat.

Tästä seuraa:

• Yksi malli ei sovi järjestelmäsi kaikkiin kutsuihin. Reititys kannattaa vain, jos mitatut säästöt ylittävät reititysvirheistä ja operatiivisesta monimutkaisuudesta aiheutuvat haitat.
• Kärki muuttuu neljännesvuosittain. Rakenna järjestelmä niin, että malleja voi vaihtaa, äläkä lukitse sitä yhteen malliin.
• Avoin lähdekoodi on nykyään aidosti käyttökelpoinen monissa tuotantotapauksissa, ei vain kokeiluissa.

Kerros 2: inferenssikerros

Missä mallisi käytännössä suoritetaan?

Suljetut API-palveluntarjoajat — OpenAI, Anthropic ja Google. Nopein tapa päästä alkuun, parhaat mallit ja luotettavin palvelu. Maksat lisähintaa ja hyväksyt palveluntarjoajan data- ja tietoturvamallin.

Avoimen lähdekoodin inferenssipalveluntarjoajat — Groq, Together AI, Fireworks ja Replicate. Ne ajavat avoimia malleja erilaisilla optimoinneilla. Usein huomattavasti itse ylläpitämistä nopeampia ja hinnaltaan kilpailukykyisiä. (Markkina keskittyy nopeasti: useita vuoden 2024 palveluntarjoajia ei enää ole. Tarkista palveluntarjoajan tilanne ennen sitoutumista.)

Pilvinatiivit palvelut — AWS Bedrock, Azure OpenAI ja Google Vertex. Ne tarjoavat suljettuja ja avoimia malleja oman pilviympäristösi tunnistautumisen, laskutuksen ja vaatimustenmukaisuuden kautta. Monissa yritysympäristöissä tämä on välttämätöntä.

Itse ylläpidetty inferenssi: vLLM, TGI, SGLang ja LMDeploy omilla grafiikkasuorittimillasi. Jatkuvalla korkealla käyttöasteella rajakustannus voi olla pienempi, mutta operatiivinen monimutkaisuus on huomattavasti suurempi. Laske kannattavuusraja oman liikenneprofiilin, laitteiston tai vuokran, käyttöasteen, henkilöstön ja saatavuusvaatimusten perusteella. Yleispätevää kuukausikustannusrajaa ei ole.

Reuna- ja laitekohtainen inferenssi — Apple Intelligence, MediaPipe, ONNX sekä GGUF-mallit Ollaman tai llama.cpp:n kautta. Kutsukohtaisesti maksuton, mutta mallin kyvykkyys on rajallinen. Yhä käyttökelpoisempi tarkasti rajatuissa käyttötapauksissa.

Keskeiset kompromissit:

• Viiveellä on merkitystä: puheagentit ja keskustelukäyttöliittymät tarvitsevat ensimmäisen tokenin nopeasti. Groq, Cerebras ja laitteella suoritettavat mallit ovat tässä vahvoja.
• Suorituskyvyllä on merkitystä eräkäsittelyssä: miljoonia tietueita käsiteltäessä tarvitaan suurta läpimenoa, ei pientä viivettä.
• Lakisääteisillä ja sopimusperusteisilla vaatimuksilla on merkitystä: GDPR:n roolit ja siirtosäännöt, säänneltyä tietoa koskevat velvoitteet, asiakassopimukset ja tietojen sijaintia koskevat sitoumukset voivat rajata palveluntarjoajia ja alueita. SOC 2 -raportti on varmennusaineistoa, ei laki tai automaattinen lupa käsitellä tietoja.
• Toimittajariskillä on merkitystä: riippuvuus yhdestä palveluntarjoajasta muodostaa yksittäisen vikaantumispisteen. Usean palveluntarjoajan malli on hyvää riskienhallintaa.

Vuonna 2026 yleinen malli on käyttää suljettuja palveluna tarjottuja malleja korkeinta laatua vaativiin käyttäjälle näkyviin pyyntöihin, palveluna tarjottuja avoimen lähdekoodin malleja edullisempaan suuren volyymin työhön ja laitekohtaisia malleja rajattuihin, viiveherkkiin ominaisuuksiin. Itse ylläpitämiseen kannattaa siirtyä vasta, kun mittakaava ja talous perustelevat operatiivisen kuorman.

Kerros 3: työkalut ja MCP

LLM-mallit eivät yksinään pysty paljoon. Niistä tulee hyödyllisiä, kun ne voivat kutsua työkaluja eli määrittämiäsi funktioita, joiden kautta ne pääsevät käsiksi tietoihin, rajapintoihin ja toimintoihin.

Natiivi funktiokutsu. Kaikki merkittävät mallit tukevat rakenteista funktiokutsurajapintaa. Määrität funktiot JSON-skeemoilla, malli päättää, milloin niitä kutsutaan, suoritat kutsun ja palautat tulokset.

MCP (Model Context Protocol). Standardoitu protokolla, jolla asiakkaat yhdistyvät työkalu- ja kontekstipalvelimiin. Se voi vähentää toimittajasidonnaisuutta protokollarajalla, mutta tunnistautuminen, valtuutus, käyttöönotto ja asiakaskohtainen toiminta on silti testattava. Aloita MCP:n ajantasaisesta määrittelystä, älä kopioidusta oppaasta.

Suorat integraatiot. Suuren volyymin tarkasti rajatuissa käyttötapauksissa, kuten tietyn CRM-järjestelmän tai tietokannan yhteydessä, suoran sovittimen kirjoittaminen on usein yleiskäyttöistä MCP-palvelinta helpompaa.

MCP on laajasti käytössä eri palveluntarjoajien keskuudessa, mutta ”käytä MCP:tä joka integraatioon” ei ole tekninen sääntö. Valitse se, kun useat asiakkaat tarvitsevat samaa kyvykkyyttä tai siirrettävyys protokollatasolla on tärkeää. Suora tyypitetty sovitin voi olla yksinkertaisempi yhdellä suuren volyymin sisäisellä polulla.

Muutama käytännön havainto:

• Työkalujen kuvauksilla on valtava merkitys. Huonosti kuvattua työkalua ei käytetä oikein. Työkalujen docstring-kuvaukset kannattaa kirjoittaa kehotteiden tavoin.
• Työkalujen määrällä on merkitystä. Mallit suoriutuvat heikommin, kun käytettävissä on 50+ työkalua, kuin silloin, kun tarjolla on 5-10 olennaista työkalua. Rajaa valikoimaa määrätietoisesti.
• Virheenkäsittelyllä on merkitystä. Työkalujen virheet on välitettävä mallille rakenteisessa muodossa, jotta se voi mukautua.
• Valtuutus on vaikeaa. Monen käyttäjän järjestelmä, jossa LLM:llä on eri käyttäjille erilaiset oikeudet, ei ole yksinkertainen toteuttaa. Älä anna LLM:n tehdä valtuutuspäätöksiä, vaan tee ne työkalun rajapintakerroksessa.

Kerros 4: haku ja muisti

LLM-mallit tarvitsevat tietoja, joita ei ollut niiden opetusaineistossa. Niistä vastaa hakukerros.

Vektoritietokannat. Pinecone, Weaviate, Qdrant, Chroma, pgvector-laajennuksella varustettu PostgreSQL ja Turbopuffer. Ne tallentavat upotuksia ja palvelevat lähimpien naapureiden hakuja. Kypsä ja hyvin ymmärretty ratkaisu sekä semanttisen haun oletusvalinta.

Hybridihaku. Yhdistää vektorihaun perinteiseen BM25-avainsanahakuun ja löytää sekä semanttiset että sanastolliset osumat. Yhdistä tulokset Reciprocal Rank Fusion -menetelmällä. Työkaluja ovat Elasticsearch, OpenSearch ja Vespa.

Tietämysgraafit. Neo4j, Memgraph ja mukautetut kolmikantatietovarastot. Ne soveltuvat tietoon, jossa on runsaasti suhteita, ja niitä käytetään graph RAG -arkkitehtuureissa. Rakentaminen vaatii enemmän työtä, mutta suhteita painottavilla aloilla laatu on usein parempi.

Erikoistuneet RAG-alustat. LlamaIndex, joka on nykyään kypsä, LangChainin RAG-abstraktiot ja Haystack. Ne tarjoavat yleisiin malleihin korkeamman tason kehykset.

Uudelleenjärjestely. Cohere Rerank, Voyage ja mukautetut ristiinkooderit. Alustavan haun jälkeen parhaat ehdokkaat järjestetään uudelleen kalliimmalla mallilla. Vaikutus riippuu ensimmäisen vaiheen hakijasta, ehdokkaiden määrästä, korpuksesta ja mittarista. Pidä uudelleenjärjestely mukana vain, jos arviointiaineisto osoittaa hyödyllisen laatuhyödyn.

Muisti. Agenttien ja keskustelujen rakenteiset muistikerrokset, kuten Mem0, Letta (entinen MemGPT) tai mukautettu ratkaisu. Erota lyhytaikainen muisti (nykyinen keskustelu), keskipitkä muisti (viimeaikaiset aiheet) ja pitkäaikainen muisti (pysyvät käyttäjää tai tiliä koskevat tiedot).

Arkkitehtuurikysymys kuuluu: missä tämä kerros sijaitsee?

• Sovelluksessa: LLM-kutsun ympärille rakennetaan tiimisi kirjoittama hakulogiikka.
• MCP-kerroksessa: haku tarjotaan työkaluina.
• Palveluna: sovellukset kutsuvat erillistä hakupalvelua.

Yhden tuotteen monoliittisissa järjestelmissä sovelluksen sisäinen ratkaisu on riittävä. Usean tuotteen organisaatioissa haku kannattaa toteuttaa palveluna, jolla on yhdenmukainen laatu ja käytännöt.

Kerros 5: kehote- ja kontekstisuunnittelu

Vuonna 2026 kehotesuunnittelu tarkoittaa useimmiten samaa kuin kontekstisuunnittelu: sitä, mitä kunkin kutsun konteksti-ikkunaan viedään.

Osat ovat:

Kehotteet. Usein muuttujia sisältäviä mallipohjia. Ne tallennetaan versionhallintaan, testataan arviointikokonaisuuksilla ja niitä käsitellään kuten koodia.

Kehotteiden hallinta. Työkaluina esimerkiksi Promptfoo, Langfuse, PromptLayer tai organisaation omat järjestelmät. Versiointi, A/B-testaus ja palautus aiempaan versioon. (Helicone ja vastaavat LLM-välityspalvelimet kuuluvat jäljempänä käsiteltävään havainnoitavuuskerrokseen, eivät tähän. Nämä kaksi luokkaa sekoittuvat helposti.)

Kontekstistrategia. Päätökset siitä, mitä kuhunkin kutsuun sisällytetään:

• Järjestelmäkehote (vakaa, määrittää toiminnan).
• Haettu tieto (dynaaminen, peräisin RAG-järjestelmästä).
• Keskusteluhistoria (hallittu ja pitkissä keskusteluissa usein tiivistetty).
• Few-shot-esimerkit (valitaan dynaamisesti kyselyn perusteella).
• Työkalukuvaukset (suodatetaan vain olennaisiin työkaluihin).
• Käyttäjän nykyinen kysely.

Kontekstin tiivistäminen. Mallin suorituskyky heikkenee kontekstin kasvaessa pitkäksi. Strategioita ovat vanhojen vuorojen tiivistäminen, avaintietojen poimiminen rakenteiseen muistiin ja epäolennaisen sisällön karsiminen. Aihe on aktiivisen tutkimuksen kohteena.

Pitkän kontekstin käyttö. Useat nykyiset lippulaivamalliperheet, kuten GPT-5.6, nykyiset Claude-lippulaivat ja Gemini-mallit, tarjoavat noin miljoonan tokenin konteksti-ikkunoita. Kapasiteetti ei kuitenkaan tarkoita hyvää tiedonhakua. Pitkän kontekstin tutkimus, kuten Lost in the Middle, osoittaa, että olennaisen tiedon hyödyntäminen voi vaihdella sen sijainnin mukaan ja että tulokset riippuvat mallista ja tehtävästä. Arvioi juuri se malli, kehote, asiakirjajärjestys ja kontekstin pituus, jotka aiot julkaista.

Kerros 6: orkestrointi

Miten monivaiheisia LLM-työnkulkuja ja agentteja koordinoidaan?

Suora API. Kirjoita silmukka itse Pythonilla tai TypeScriptillä. Paras vaihtoehto yksinkertaisiin tapauksiin ja tapahtumien todellisen kulun ymmärtämiseen.

LangChain / LangGraph. Laajasti käytetty. Agenttien tilakoneena toimiva LangGraph on kypsynyt huomattavasti. Raskaat abstraktiot ja oppimiskynnys, mutta paljon tehoa.

CrewAI. Roolipohjaisiin agentteihin keskittyvä moniagenttikehys. LangGraphia helpompi ottaa käyttöön mutta vähemmän joustava.

LlamaIndex-agentit. Yksi vaihtoehto, jos tiimi käyttää jo sen data- ja hakuabstraktioita. Tarkista ajantasaiset rajapinnat ja vertaa sitä pienempään suoraan toteutukseen.

OpenAI Agents SDK. OpenAI-painotteinen orkestrointivaihtoehto. Vertaa sitä suoraan Responses API -silmukkaan ennen kehysriippuvuuden hyväksymistä.

Claude Agent SDK. Anthropicin agenttiajoympäristö Claude-painotteisiin ohjelmointi- ja työkalutyönkulkuihin. Se ei ole yleisnimitys Claude API:lle.

Mukautettu ratkaisu. Tuotantoagentteja julkaisevat kypsät tiimit käyttävät usein omaa orkestrointia. Kehykset aiheuttavat kustannuksia, kuten abstraktioveroa, vaikeampaa virheenkorjausta ja versiovaihtelua, jotka voivat ylittää niiden hyödyt.

Kaikkia kehyksellä tehtyjä prototyyppejä ei ole näyttöön perustuvaa syytä kirjoittaa uudelleen. Aloita pienimmällä työnkulun ilmaisevalla abstraktiolla, instrumentoi se ja siirry muuhun ratkaisuun vasta, kun kehyksen rajoitukset tai operatiiviset kustannukset on mitattu.

Kerros 7: havainnoitavuus

Vakavasti otettavia LLM-sovelluksia ei voi julkaista ilman havainnoitavuutta. Jokainen tuotantojärjestelmä tarvitsee:

Jäljityksen. Jokainen LLM-kutsu tallennetaan: aikaleima, malli, syöte, tuotos, viive, kustannus ja onnistuminen tai epäonnistuminen. Monivaiheiset jäljitykset esitetään puina.

Kustannusseurannan. Kutsu-, ominaisuus- ja käyttäjäkohtaisesti. Kustannukset ovat suuria eikä niillä ole luontaista ylärajaa. Ilman seurantaa saat tietää tilanteen vasta kuukauden lopussa.

Laadunvalvonnan. Tuotantoliikenteen otokselle tehtävät automaattiset laatutarkistukset ja hälytykset laadun heikkenemisestä.

Käyttäjäpalautteen keräämisen. Peukku ylös tai alas, suora palaute ja epäsuorat signaalit, kuten uudelleenyritysten määrä ja keskeyttäminen.

Virheenkorjauksen. Kun jokin rikkoutuu, koko kutsuketjun on oltava nähtävissä. Epäonnistuneessa agenttiajossa voi olla useita vikapisteitä.

Työkaluja ovat LangSmith, Helicone, Arize, Phoenix, Braintrust, Weights & Biases ja Datadog LLM Observability. Niillä on erilaiset vahvuudet. Valitse yksi aikaisin ja pitäydy siinä.

Pienille tiimeille jopa yksinkertainen Postgres-taulu, jossa on yksi rivi LLM-kutsua kohden, tarjoaa 80 % tarvittavasta. Siirry erilliseen työkaluun, kun mittakaava tai ominaisuustarpeet perustelevat sen.

Kerros 8: arvioinnit

Vakavassa tuotantotyössä tämä on tärkein yksittäinen kerros.

Offline-arvioinnit. Määritetty aineisto, odotetut tuotokset ja pisteytys. Ajetaan ennen muutosten käyttöönottoa ja havaitaan regressiot. (Käytännönläheinen johdanto: arvioinnit muille kuin insinööreille; syvemmät mallit: regressioita havaitsevat arvioinnit.)

Online-arvioinnit. Tuotantoliikenteen otos pisteytetään automaattisesti (LLM-as-judge) tai käyttäjien signaalien perusteella. Näin havaitaan ajautuminen.

Käyttöönottoa edeltävät arvioinnit. Arviointikokonaisuus ajetaan ja tarkistetaan ennen minkään kehote- tai mallimuutoksen viemistä tuotantoon. Siitä tulee osa CI:tä.

Arviointien luokittelu. Eri huolenaiheisiin käytetään eri arviointeja:

• Käyttäytyminen: tekeekö järjestelmä odotetut asiat?
• Turvallisuus: kieltäytyykö se asioista, joista sen halutaan kieltäytyvän?
• Laatu: kuinka hyvä tuotos on?
• Robustisuus: miten se käsittelee vihamielisiä syötteitä?
• Kustannus ja viive: pysytäänkö budjetissa?

Työkaluja ovat Promptfoo, Braintrust, LangSmith ja mukautetut kokonaisuudet. Kaikille on paikkansa, mutta Promptfoo on helpoin tapa aloittaa.

Kerros 9: sovelluskerros

Tässä kerroksessa varsinainen tuotteesi sijaitsee. Päätettäviä asioita ovat:

Agentti vai työnkulku. Agentit eli työkaluja käyttävässä silmukassa toimivat LLM:t ovat tehokkaita mutta vaikeampia tehdä luotettaviksi. Kiinteästä LLM-kutsujen sarjasta koostuvat työnkulut ovat helpompia ja usein riittäviä. Suosi oletuksena työnkulkuja ja käytä agentteja vain silloin, kun niitä todella tarvitaan.

Synkroninen vai asynkroninen. Onko toiminto käyttäjälle näkyvä ja reaaliaikainen, taustalla ajettava erätyö vai suoratoistettu? Tämä vaikuttaa malliin, infrastruktuuriin ja käyttökokemukseen.

Yhden asiakkaan vai usean asiakkaan ympäristö. Asiakaskohtaiset tietojen eristysvaatimukset ohjaavat merkittäviä arkkitehtuuripäätöksiä.

Paikallinen ympäristö vai pilvi. Vaatimustenmukaisuus, tietoturva tai kustannukset voivat edellyttää paikallista ympäristöä. Operatiivinen monimutkaisuus on huomattavasti suurempi.

Reunatapaukset. Hallusinaatiot, kehoteinjektiot ja väärinkäyttö. Tuotantojärjestelmät tarvitsevat suojakaiteita. Älä julkaise ilman niitä.

Merkitykselliset kompromissit

Muutama kompromissi, joista kannattaa päättää tietoisesti:

Laatu, kustannus ja viive

Nämä tavoitteet ovat usein ristiriidassa, mutta kyse ei ole kiinteästä ”valitse kaksi” -laista. Piirrä arvioiduille vaihtoehdoille tehtävän onnistuminen, jakauman häntäpään viive ja kokonaiskustannus, ja valitse ratkaisu selvien rajoitteiden perusteella.

• Korkea laatu + pieni viive = kallis.
• Pieni kustannus + pieni viive = heikompi laatu.
• Korkea laatu + pieni kustannus = suuri viive (eräkäsittely tai päättelymallit).

Valitse tehtäväkohtaiset painotukset. Älä yritä optimoida kaikkia kolmea, sillä silloin kaikki jäävät keskinkertaisiksi.

Rakenna vai osta

Jokaisen kerroksen voi rakentaa tai ostaa.

• Rakenna: enemmän hallintaa, ylläpitoa ja kustannuksia (insinöörityöaikaa) sekä erottavia kyvykkyyksiä.
• Osta: nopeampi aloitus, vähemmän hallintaa, jatkuva toimittajariski ja erottamattomien kyvykkyyksien ulkoistaminen.

Hyvä nyrkkisääntö on ostaa yleiset peruskerrokset, kuten vektoritallennus ja havainnoitavuuden perusteet, mutta rakentaa erottavat kerrokset, kuten oma orkestrointi, kehotteet ja arvioinnit. Päinvastainen ratkaisu — erottavien osien ostaminen ja yleisen perusinfrastruktuurin rakentaminen — on yleinen virhe.

Avoin vai suljettu lähdekoodi

Avoimilla painoilla julkaistut mallit ovat varteenotettavia vaihtoehtoja moniin tehtäviin, etenkin kun käyttöönoton hallinta on tärkeää. Se, onko malli nopeampi, edullisempi tai riittävän kyvykäs, riippuu tarkasta mallista, ajoympäristöstä, laitteistosta, rinnakkaisuudesta ja tehtäväkohtaisesta arvioinnista. Sitä ei voi päätellä lisenssiluokasta.

Päätökseen vaikuttavat:

• Laatuvaatimukset. Vertaa lukittuja ehdokkaita tehtävässä ja kriittisissä osajoukoissa. Lisenssi- tai käyttömalli ei ratkaise laatua.
• Kustannus mittakaavassa. Vertaa nykyisiä API-laskuja ennustetun kuormaprofiilin perusteella mitattuun, saatavuuden huomioivaan ylläpidon kokonaiskustannukseen.
• Tietosuoja ja vaatimustenmukaisuus. Valitse käyttöönottoraja tietoluokituksen, sopimusten, arkkitehtuurin ja pätevän arvioinnin perusteella. Itse ylläpitäminen ei automaattisesti takaa vaatimustenmukaisuutta.
• Mukautettavuus. Varmista, että ehdokkaan lisenssi ja palveluntarjoaja tukevat tarvittavia sovittimia, koulutusta, rajoitettuja tuotoksia, työkaluja tai ajoympäristön muutoksia.
• Operatiivinen kapasiteetti. Hallituilla API-palveluilla ja itse ylläpidetyillä ratkaisuilla on erilaiset tietoturva-, saatavuus-, siirtymä-, häiriö- ja toimittajariippuvuusriskit. Kumpikaan ei ole joka työkuormassa vaivaton.

Hybridireititys on yksi vaihtoehto, kun useat malli- tai käyttöönottopolut tuottavat mitatun hyödyn, joka ylittää reititysvirheet, käytäntöjen monimutkaisuuden ja operatiiviset kustannukset. Tässä artikkelissa ei ole edustavaa käyttöönottotutkimusta, joka osoittaisi sen olevan yleisin malli.

Viive ja päättelyn syvyys

Päättelyasetukset ja mallitasot voivat muuttaa tehtävän laatua, viivettä ja laskutettavaa käyttöä. Vertaa nykyisiä lukittuja rajapintoja ja mittaa koko viivejakauma. ”Päättelymalli” ei itsessään todista parempaa tulosta vaikeissa tapauksissasi.

Yleinen malli on reitittää yksinkertaiset kyselyt nopeille malleille ja vaikeat kyselyt päättelymalleille. Päätä reititys reitittimellä, joka voi olla pieni malli tai heuristiikka.

Pitkä konteksti vai RAG

Voit täyttää mallin kontekstin miljoonan tokenin ikkunalla tai hakea olennaiset osat RAG-järjestelmällä.

• Pitkä konteksti: ei vaadi hakuindeksiä, mutta tarvitsee silti asiakirjojen järjestyksen, käyttöoikeuksien, token- ja kustannusrajojen sekä sijainti- ja häiriötekijöiden arviointia.
• RAG: lisää aineiston tuonnin ja haun infrastruktuuria ja voi pienentää mallille annettavaa kontekstia. Laatu ja kokonaiskustannus on mitattava.

Puolustettava valinta syntyy vertailusta: pitkän kontekstin vertailutaso, haun vertailutaso ja tarvittaessa hybridi. Arvioi samalla työkuormalla vastausten oikeellisuus, näytön löytyminen, viittausten laatu, viive, kustannus, käyttöoikeuksien toteutuminen ja tietojen tuoreus.

Agentit vai työnkulut

Kuten edellä todettiin: suosi oletuksena työnkulkuja ja käytä agentteja vain silloin, kun joustavuudelle on aito tarve. Monet näkemämme ”agenttijärjestelmät” pitäisi toteuttaa työnkulkuina.

Vuoden 2026 viitearkkitehtuuri

Tehdään kokonaisuudesta konkreettinen. Tyypillinen tuotantojärjestelmä, joka tarjoaa tekoälyominaisuuksia keskikokoisessa SaaS-tuotteessa, näyttää tältä:

User → Application (React/Next.js)
    ↓
API gateway / auth
    ↓
LLM Service (your wrapper)
    ↓
  Router (small model or heuristic)
    ├→ Simple tasks: an evaluated efficiency-tier model
    ├→ Standard tasks: an evaluated balanced-tier model
    ├→ Hard tasks: a pinned capability-tier model
    └→ Special: vision/voice/embedding specialists
    ↓
Tool layer (MCP servers + direct integrations)
    ↓
Retrieval layer (Pinecone + hybrid + reranker)
    ↓
Observability (Helicone or LangSmith)
    ↓
Eval suite (Promptfoo, runs in CI)

Laske tämän viitearkkitehtuurin kustannus valmistunutta työnkulkua kohden jäljitettyjen tokenien, työkalu- ja hakukutsujen, välimuistin tilan, uudelleenyritysten, infrastruktuurin ja ihmiskatselmoinnin perusteella. Arvioi suunnittelu- ja ylläpitotyö rajatusta tehtäväjonosta ja tiimin todellisesta toimitusnopeudesta. Tässä ei esitetä yleispätevää käyttäjäkohtaista hintaa tai toimitusaikaa.

Tavallisimmat ongelmat

Tuotantokäytön LLM-pinoissa toistuvat seuraavat virhemallit:

Malli 1: yksi malli kaikkeen. Kustannukset ylittyvät ja laatu kärsii. Korjaus: reititys.

Malli 2: ei havainnoitavuutta. Virheitä ei voi selvittää, toimintaa mitata eikä järjestelmää parantaa. Korjaus: lisää instrumentointi aikaisin.

Malli 3: ei arviointeja. Laatu ajautuu huomaamatta. Korjaus: ota arvioinnit käyttöön ensimmäisestä päivästä lähtien.

Malli 4: lukittuminen kehykseen. LangChainin tai CrewAI:n virheenkorjauksesta tulee kokopäivätyö. Korjaus: älä käytä kehyksiä, elleivät ne säästä kustannuksiaan enemmän. Kirjoita ratkaisu suorana koodina uudelleen, kun mallit ovat selviä.

Malli 5: ostettavaksi sopivan infrastruktuurin rakentaminen. Oma vektoritietokanta? Todennäköisesti hukkaan heitettyä aikaa. Oma havainnoitavuus? Todennäköisesti hukkaan heitettyä aikaa. Osta yleiset peruskerrokset.

Malli 6: rakennettavaksi sopivan infrastruktuurin ostaminen. Kehotteiden ulkoistaminen kolmannelle osapuolelle. Arviointien ulkoistaminen. Nämä muodostavat kilpailuetusi, joten pidä ne omassa hallinnassasi.

Malli 7: kehoteinjektion sivuuttaminen. Tuotantojärjestelmässä ei puhdisteta käyttäjän toimittamaa sisältöä. Riski on suuri, joten lievennä sitä varhain.

Malli 8: agentteihin luottaminen suuren riskin prosesseissa. LangGraph-agentti hyväksyy hyvityksiä ilman ihmisen tarkistusta. Tämä menee ennen pitkää väärin. Lisää seurauksellisiin toimintoihin ihminen osaksi työnkulkua.

Malli 9: väärän asian optimointi. Inferenssikustannuksia optimoidaan, vaikka insinöörityö muodostaa suurimman osan kokonaiskustannuksista. Tai viivettä optimoidaan, vaikka käyttäjät eivät huomaa eroa. Mittaa sitä, millä on todellista merkitystä.

Malli 10: ei usean palveluntarjoajan suunnitelmaa. Kun ensisijaisella palveluntarjoajalla on käyttökatko — kyse ei ole siitä tapahtuuko se vaan milloin — järjestelmäsi ei toimi. Määritä varajärjestely.

Kolme päivättyä vetoa (tarkista tilanne uudelleen vuoden 2027 puolivälissä)

Ennustuksia on helppo tehdä, mutta päivättyjä ja kumottavissa olevia ennustuksia ei. Olemme valmiita olemaan julkisesti väärässä näistä kolmesta:

1. EU:ssa ylläpidetty inferenssi saavuttaa käytännön hintapariteetin määritellyssä keskitason työkuormassa vuoden 2027 puoliväliin mennessä. ”Pariteetti” tarkoittaa enintään 10 prosentin lisähintaa samasta lukitusta mallista, läpimenosta, saatavuustavoitteesta ja tukitasosta. Jos tämä toteutuu, EU-alueella tapahtuvasta käsittelystä tulee oletusarvoinen vaihtoehto soveltuviin työkuormiin. Oikeudellinen soveltuvuus riippuu silti koko käsittelyjärjestelystä. Luottamus: kohtalainen.

2. Kehyskerros jatkaa yhdistymistä samalla kun protokollarajat säilyvät vakaampina. Katsomme ennusteen saaneen tukea, jos vähintään kaksi merkittävää agenttikehystä yhdistyy tai poistuu käytöstä vuoden 2027 puoliväliin mennessä ja MCP säilyy useiden toisistaan riippumattomien asiakasohjelmistojen toteuttamana. Siksi pidämme työkalusopimukset siirrettävinä ja orkestroinnin vaihdettavana. Luottamus: korkea.

3. Pienillä malleilla tehtävä reititys lakkaa olemasta optimointi ja muuttuu oletusarkkitehtuuriksi. Jos lippulaivojen hinnat pysyvät ennallaan samalla kun pienet tasot paranevat, ajatus ”lippulaiva kaikkeen” kuulostaa samalta kuin ”fyysinen palvelin kaikkeen” pilvi-insinöörin korvaan. Luottamus: korkea kustannustietoisissa pk-yrityksissä.

Emme tarkoituksella ennusta mallien paremmuusjärjestystä. Mikä tahansa tähän painettu täsmällinen järjestys olisi vanhentunut jo ennen sivun seuraavaa tarkistuspäivää.

Rakenna arkkitehtuuri oikein

Vuoden 2026 LLM-pino on todellinen ja kerroksittainen, ja valinnoilla on merkitystä. Menestyvät tiimit:

• ymmärtävät koko pinon eivätkä vain itse käsittelemiään osia,
• tekevät kutsukohtaiset kompromissit laadun, kustannusten ja viiveen välillä tietoisesti,
• rakentavat erottavat osat ja ostavat muut,
• lisäävät instrumentoinnin ensimmäisestä päivästä alkaen (havainnoitavuus ja arvioinnit),
• säilyttävät ketteryyden (mallien siirrettävyys ja useat palveluntarjoajat).

Häviäjät valitsivat yhden toimittajan, kovakoodasivat sen API:n, eivät lisänneet instrumentointia eivätkä koskaan mitanneet toimintaa. Nyt heidän järjestelmänsä on kallis, hauras ja mahdoton parantaa.

Rakenna arkkitehtuuri oikein. Kaikki muu helpottuu.