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ämä artikkeli esittää työskentelevän arkkitehdin näkemyksen vuoden 2026 LLM-pinosta: mitä kuhunkin kerrokseen kuuluu, millaisia kompromisseja teet ja mihin ala on menossa. Olisimme itse toivoneet saavamme lukea tällaisen artikkelin ennen kaikkien vältettävissä olleiden virheiden tekemistä.

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.

Lippulaivatason päättelymallit. Nykyisten lippulaivojen ajattelutilat — GPT-5.5 päättelyllä, Claude Opus 4.8 mukautuvalla ajattelulla ja Gemini 3.1 Pro thinking — sekä DeepSeek R1:n kaltaiset erilliset päättelymallit. Ne suoriutuvat erinomaisesti monivaiheisista ongelmista, matematiikasta, ohjelmoinnista ja vaativasta analyysistä. Ne ovat kalliita ($3-30 miljoonaa syötetokenia kohden ja huomattavasti kalliimpia tuotostokeneissa) ja hitaampia (5-60 sekuntia). Käytä niitä, kun päättelyn laatu on pullonkaula.

Yleiskäyttöiset lippulaivamallit. GPT-5.5, Claude Sonnet 5, sekä Gemini 3.1 Pro. Ne suoriutuvat erinomaisesti useimmista tietotyötehtävistä, ovat nopeita (2-5 sekuntia) ja kohtalaisen kalliita ($2-5 miljoonaa syötetokenia kohden). Ne ovat oletusvalinta laadukkaisiin käyttäjälle näkyviin vastauksiin.

Keskitason mallit. Claude Haiku 4.5, Gemini 3.5 Flash ja OpenAI:n keskitaso. Ne soveltuvat hyvin yksinkertaisiin ja kohtalaisen vaativiin tehtäviin, ovat nopeita (1-2 sekuntia) ja edullisia ($1-2.50 miljoonaa syötetokenia kohden). Niitä käytetään tuotannossa paljon luokitteluun, tietojen poimintaan ja yksinkertaiseen generointiin.

Pienet ja edulliset mallit. Palveluntarjoajien nykyisten valikoimien pienimmät mallit, kuten Gemini 3 Flash Preview, sekä pienet avoimen lähdekoodin mallit. Ne riittävät tarkasti rajattuihin, rakenteisiin tehtäviin. Ne ovat erittäin edullisia ($0.50-1 miljoonaa syötetokenia kohden) ja erittäin nopeita (<1 sekunti). Käytä niitä reititykseen, pisteytykseen ja eräkäsittelyyn.

(Listahinnat tarkistettiin 2026-07-07 palveluntarjoajien hinnastosivuilta. Tasot muuttuvat, joten tarkista hinnat uudelleen ennen niiden ilmoittamista.)

Erikoistuneet mallit. Upotus-, uudelleenjärjestely-, kuva-, ääni- ja ohjelmointiin erikoistuneet mallit. Ne ovat omissa tehtävissään yleismalleja edullisempia ja yleensä parempia. Harkitse niitä aina soveltuvaan tehtävään.

Avoimen lähdekoodin kärkimallit. Llama 4, DeepSeek V3 / R2, Qwen 3, sekä Mistral Large. Niitä voi käyttää inferenssipalveluntarjoajien, kuten Groqin, Togetherin ja Fireworksin, kautta tai itse ylläpidettyinä. Hinta ja laatu kilpailevat monissa tehtävissä suljettujen kärkimallien kanssa, mutta joissakin tehtävissä, etenkin pitkän aikajänteen päättelyssä, ne jäävät jälkeen.

Tästä seuraa:

• Yksi malli ei sovi järjestelmäsi kaikkiin kutsuihin. Reititys on kustannusten hallinnan kannalta välttämätöntä (katso Kerros 1).
• 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. Mittakaavassa pienin tokenikohtainen kustannus mutta suurin operatiivinen monimutkaisuus. Sitä kannattaa yleensä harkita vasta, kun inferenssikulut ovat useita tuhansia euroja kuukaudessa ja lähestyvät kymmentätuhatta euroa (katso kannattavuuslaskelma itse ylläpidettyä ja palveluna tarjottua inferenssiä vertailevasta artikkelista).

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ä.
• Vaatimustenmukaisuudella on merkitystä: GDPR, HIPAA ja SOC 2 määräävät usein, mitä palveluntarjoajia ja alueita voi käyttää.
• 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, jonka Anthropic esitteli ja jonka muun muassa OpenAI, Cursor ja muut ovat sittemmin ottaneet laajasti käyttöön työkalupalvelimia varten. MCP-palvelin tarjoaa työkalut, ja MCP-asiakas eli LLM-agentti yhdistää palvelimeen ja käyttää niitä. Näin työkalun toteutus ei ole sidoksissa tiettyyn malliin.

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.

Vuoden 2026 suunta on selvä: MCP on voittamassa standardin aseman. Useimmat uudet työkalut kannattaa toteuttaa MCP:tä varten. Suorat integraatiot ovat edelleen hyödyllisiä suorituskykykriittisillä poluilla.

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 tarkkuuden parantamiseksi. Tämä parantaa haun laatua yleensä 2-3x.

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ö. 1M-tokenin konteksti-ikkunat ovat nykyisissä lippulaivamalleissa vakiovaruste (Claude, GPT-5.5, sekä Gemini). Ne toimivat, mutta kontekstin rapautuminen on todellinen ilmiö: pitkien syötteiden laatu heikkenee, vaikka malli teknisesti tukisi niitä. Käytä pitkää kontekstia harkiten. Älä vie kaikkea kontekstiin vain siksi, että se on mahdollista.

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. Erityisen vahvoja RAG-painotteisissa työnkuluissa.

OpenAI Agents SDK. Yksinkertaisempi ja ohjaavampi, optimoitu OpenAI:n malleille.

Anthropic Claude SDK. Vastaava ratkaisu, joka on optimoitu Claudelle.

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.

Vuoden 2026 yleinen malli on tehdä prototyyppi kehyksellä ja kirjoittaa se tuotantoa varten uudelleen omana koodina. Kehys auttaa löytämään sopivat mallit. Kun ne tunnetaan, suora koodi on yksinkertaisempaa ja luotettavampaa.

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äsittelimme tätä yksityiskohtaisesti keskitason artikkelissa.)

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

Tämä on perustavanlaatuinen kolmio. Yleensä voit optimoida kaksi ominaisuutta, jolloin kolmas heikkenee.

• 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

Vuoden 2026 tosiasia on, että avoimen lähdekoodin mallit ovat kilpailukykyisiä monissa tehtävissä. Joissakin tehtävissä ne ovat parempia eli nopeampia ja edullisempia. Toisissa tehtävissä, kuten pitkän aikajänteen päättelyssä, suljetut kärkimallit johtavat edelleen.

Päätökseen vaikuttavat:

• Laatuvaatimukset. Minkä tahansa tehtävän ehdottomassa kärjessä suljetut mallit voittavat edelleen.
• Kustannus mittakaavassa. Itse ylläpidetty avoimen lähdekoodin malli on suurella volyymilla edullinen.
• Tietosuoja ja vaatimustenmukaisuus. Arkaluonteiset tiedot edellyttävät usein itse ylläpidettyä mallia omassa infrastruktuurissa.
• Mukautettavuus. Hienosäätö ja mukautettu opetus edellyttävät avointa lähdekoodia.
• Operatiivinen kapasiteetti. Suljettujen mallien API:t ovat operatiivisesti helppoja, mutta itse ylläpitäminen vaatii huomattavasti työtä.

Useimmat vuoden 2026 tuotantojärjestelmät ovat hybridejä: osa kutsuista tehdään suljetuilla ja osa avoimilla malleilla kutsukohtaisen laskelman perusteella.

Viive ja päättelyn syvyys

Päättelytasot, kuten GPT-5.5 thinking ja Claude mukautuvalla ajattelulla, vaihtavat viivettä vaikeiden ongelmien parempaan laatuun. Joskus se kannattaa, mutta joskus käyttäjä ei voi odottaa 30 sekuntia.

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: yksinkertaisempi eikä vaadi hakuinfrastruktuuria, mutta jokainen kutsu on kallis ja kontekstin rapautuminen on todellista.
• RAG: kutsukohtaisesti edullisempi, mutta vaatii enemmän käyttöönottoa ja haun laatu on oma tekninen ongelmansa.

Kypsä vastaus vuonna 2026 on käyttää tuotannossa yleensä RAG-järjestelmää ja pitkää kontekstia prototyypeissä, yksittäisissä erityistehtävissä tai silloin, kun haun laatu on niin huono, että se pilaa tuloksen.

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: a mid-tier model (Claude Haiku 4.5 class)
    ├→ Standard tasks: Claude Sonnet 5 or GPT-5.5
    ├→ Hard tasks: Claude Opus 4.8 or a reasoning tier
    └→ 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)

Kustannus aktiivista käyttäjää kohden kuukaudessa: tyypillisesti €1-10 käytön intensiteetistä riippuen. Kokeneen tiimin rakennustyö: 6-12 viikkoa. Operatiiviset kustannukset: liikenteestä riippuen pienet tai kohtalaiset.

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 keskitason malleissa käytännössä saman hintatason viimeistään vuoden puolivälissä 2027. EU:n suvereniteettivaatimukset täyttävää kapasiteettia otetaan nopeasti käyttöön, ja lisähinta Yhdysvaltojen alueiden päätepisteisiin verrattuna on pienentynyt. Jos hinnat tasoittuvat, GDPR-arkaluonteisten työkuormien oletussuosituksemme muuttuu mallista ”hybridi ja tietojen peittäminen” malliin ”oletuksena EU:ssa ylläpidetty”. Luottamus: kohtalainen.

2. Kehyskerros jatkaa keskittymistään, mutta protokollakerros jatkaa voittokulkuaan. Viimeisten 18 kuukauden aikana Microsoft yhdisti kaksi agenttikehystään ja OpenAI yhdisti itsenäisen selainagenttituotteensa takaisin ChatGPT:hen, kun taas MCP eteni julkaisusta eri toimittajien yhteiseksi oletukseksi. Kohdistamme integraatiotyön protokolliin (MCP, rakenteiset tuotokset) ja pidämme orkestrointikehyksen 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.