Paikallisesti ajettava tekoäly on siirtynyt harrastelijoiden kokeiluista tuotantokäyttöön vuoden 2026 aikana. Syynä on yksinkertainen yhtälö: pilvipalveluiden token-hinnat nousevat, GPU-muistista on maailmanlaajuinen pula ja moni suomalainen yritys haluaa pitää dokumentit, koodin ja asiakastiedot omalla koneellaan sen sijaan, että ne kulkevat ulkomaisen palveluntarjoajan palvelimien kautta. Ollama on noussut suosituimmaksi työkaluksi tähän tarpeeseen, ja jos koneessasi on Nvidian RTX-sarjan näytönohjain, pääset käyntiin ilman kalliita pilvilaskuja tai monimutkaista palvelinkonfigurointia. Tässä oppaassa käyt läpi koko polun ajurien tarkistuksesta valmiiseen, selainpohjaiseen tekoälysovellukseen 12 vaiheessa.

Opas on kirjoitettu sekä Windows- että Linux-käyttäjille, ja jokainen komento on testattu RTX 4070–5090-luokan korteilla. Aikaa koko prosessiin kuluu noin 45–60 minuuttia, riippuen ladattavan mallin koosta ja verkkoyhteyden nopeudesta. Lopputuloksena sinulla on paikallinen tekoälyjärjestelmä, joka toimii sekä komentoriviltä että selaimesta, ja jonka päälle voit rakentaa oman sovelluksen tämän oppaan viimeisessä vaiheessa esitellyllä Python-koodilla.

Miksi ajaa tekoälyä paikallisesti omalla näytönohjaimella

Kolme syytä nousee ylitse muiden. Ensinnäkin tietosuoja: kun kielimalli pyörii omalla koneella, mikään kysely tai dokumentti ei poistu talosta. Tämä on ratkaiseva tekijä esimerkiksi lakitoimistoille, terveydenhuollon toimijoille ja julkishallinnolle, joita GDPR sitoo tiukasti. Kun asiakastietoja, sopimusluonnoksia tai potilastietoja käsittelevä kysely lähtee pilvi-API:in, se saattaa kulkea useamman maan kautta ja tallentua lokeihin, joita et hallitse. Paikallinen malli poistaa tämän riskin kokonaan, koska verkkoliikennettä ulos ei tarvita ollenkaan keskustelun aikana.

Toiseksi kustannukset: pilvi-API:t laskuttavat jokaisesta tokenista, ja jatkuvassa käytössä lasku kasvaa nopeasti satoihin tai jopa tuhansiin euroihin kuukaudessa, jos käyttäjiä on useita. Paikallinen malli maksaa vain sähkön ja laitteiston hankintahinnan, ja kun laitteisto on kertaalleen hankittu, rajakustannus jokaiselle lisäkyselylle on käytännössä nolla. Kolmanneksi viive: kun malli vastaa suoraan näytönohjaimen muistista, vasteaika on usein nopeampi kuin pilvi-API:n kautta, koska verkkoliikennettä ei tarvita eikä palvelu jaa laskentatehoa tuhansien muiden käyttäjien kanssa samaan aikaan.

Nvidia julkaisi elokuussa 2026 päivitetyn ohjeistuksen paikallisten tekoälymallien rakentamiseen GeForce RTX -korteilla. Ohjeistuksen mukaan 6–32 gigatavun VRAM-muistilla varustetuilla korteilla voi kehittää ja testata pieniä ja keskikokoisia malleja, ja oikealla kvantisoinnilla käytössä voi olla jopa 60 miljardin parametrin malleja. Käytännössä tavallinen pelikone riittää nykyään moneen tehtävään, joka aiemmin vaati kalliin palvelinsalin tai jatkuvan pilvitilauksen. Nvidian dokumentaatio suosittelee kolmivaiheista mallinvalintaprosessia: ensin määritetään VRAM- ja suorituskykyvaatimukset, sitten valitaan malliehdokkaat julkisten vertailuarvojen perusteella, ja lopuksi ehdokkaat testataan omalla datalla ennen lopullista valintaa.

Ollama vai pilvi-API: milloin kumpikin kannattaa

Paikallinen ajo ei ole aina oikea valinta, joten kannattaa arvioida rehellisesti, kumpi malli sopii omaan tilanteeseen. Pilvi-API on parempi valinta silloin, kun tarvitset satunnaisesti erittäin suuren, huippuluokan mallin laskentatehoa ilman että haluat sitoa pääomaa kalliiseen näytönohjaimeen. Se sopii myös tiimeille, joiden käyttö vaihtelee voimakkaasti: pilvipalvelu skaalautuu automaattisesti ruuhkahuippuihin, kun taas oma laitteisto on aina kiinteän kokoinen.

Paikallinen Ollama-asennus puolestaan voittaa tilanteissa, joissa käyttö on tasaista ja jatkuvaa, data on arkaluontoista tai kysely-määrä on niin suuri, että token-pohjainen laskutus kasvaisi merkittäväksi kuluksi. Moni kehitystiimi päätyy hybridimalliin: raskaimmat, harvinaiset erikoistehtävät hoidetaan pilvi-API:lla, kun taas jatkuva, arkinen käyttö kuten koodin täydennys, sisäinen dokumenttihaku tai asiakaspalvelun ensimmäinen vastauskierros ajetaan paikallisesti Ollamalla. Tämä opas keskittyy jälkimmäiseen tapaukseen, koska se on juuri se skenaario, jossa oma RTX-näytönohjain tuottaa suorimman hyödyn.

Mikä Ollama on ja miten se hyödyntää RTX-näytönohjainta

Ollama on avoimen lähdekoodin työkalu, joka pakkaa kielimallin ajamisen yhden komennon taakse. Se hoitaa mallin lataamisen, kvantisoinnin, muistinhallinnan ja GPU-kiihdytyksen automaattisesti, joten käyttäjän ei tarvitse itse säätää CUDA-kirjastoja tai kääntää mitään lähdekoodista käsin. Taustalla Ollama käyttää llama.cpp-moottoria, joka tukee Nvidian GPU-kiihdytystä CUDA-rajapinnan kautta ja osaa hyödyntää myös uudempia FP4-laskentayksiköitä RTX 50 -sarjan korteilla.

Kun ajat komennon, Ollama tarkistaa ensin käytettävissä olevan VRAM-määrän ja jakaa mallin kerrokset GPU:n ja tarvittaessa suorittimen välille. Jos malli mahtuu kokonaan näytönohjaimen muistiin, koko laskenta tapahtuu GPU:lla ja vastausnopeus on parhaimmillaan kymmeniä tokeneita sekunnissa. Jos VRAM ei riitä, Ollama siirtää osan kerroksista järjestelmämuistiin, mikä hidastaa vastausta merkittävästi, koska PCIe-väylän kaistanleveys on murto-osa näytönohjaimen sisäisestä muistikaistasta. Tästä syystä oikean mallikoon valinta on koko oppaan tärkein yksittäinen päätös, ja käsittelemme sitä tarkemmin vaiheessa kuusi.

Ollama eroaa raa’asta llama.cpp-asennuksesta siinä, että se tarjoaa keskitetyn mallikirjaston, automaattisen version hallinnan ja valmiin REST-rajapinnan. Käytännössä tämä tarkoittaa, että kun kirjoitat yhden komennon, taustalla tapahtuu mallin lataus, tarkistussumman varmennus, muistin varaus ja GPU:n alustus ilman että sinun tarvitsee tuntea mitään näistä vaiheista yksityiskohtaisesti.

Esivaatimukset: laitteisto ja ohjelmistot

Ennen kuin aloitat, tarkista että koneesi täyttää seuraavat vähimmäisvaatimukset. Ollama toimii teknisesti myös ilman erillistä näytönohjainta, mutta tässä oppaassa keskitytään nimenomaan Nvidia RTX -kiihdytettyyn ajoon, koska se on tällä hetkellä nopein ja parhaiten tuettu tapa saada käyttökelpoinen vasteaika kuluttajalaitteistolla.

KomponenttiVähimmäisvaatimusSuositeltuEsimerkki-GPU
Näytönohjain8 GB VRAM16–32 GB VRAMRTX 4070 Ti / RTX 5080
KäyttöjärjestelmäWindows 11 tai Ubuntu 22.04Windows 11 24H2 tai Ubuntu 24.04–
AjuritNvidia Game Ready tai Studio, tuore versioUusin vakaa versio–
Järjestelmämuisti (RAM)16 GB32–64 GB–
Levytila20 GB vapaana100 GB+ (usealle mallille)–
Docker (valinnainen)Docker Desktop tai Docker EngineUusin vakaa versio–

Huomaa erityisesti VRAM-sarake. Kortin muistimäärä ratkaisee, kuinka suuren mallin voit ajaa täydellä nopeudella. 8 gigatavun kortti riittää 7–8 miljardin parametrin malleihin kvantisoituna, kun taas 24 gigatavun RTX 4090 tai 32 gigatavun RTX 5090 avaa oven jo 30–70 miljardin parametrin malleihin, kunhan kvantisointi on valittu järkevästi. Järjestelmämuistin (RAM) merkitys kasvaa, jos joudut siirtämään osan mallista suorittimelle: tällöin RAM toimii hitaana varastona VRAM:in loputtua.

Virtalähteen mitoitus kannattaa myös tarkistaa etukäteen, vaikka se unohtuu usein ohjelmistokeskeisissä oppaissa. Esimerkiksi RTX 5090 -kortin virrankulutuksen yläraja on 575 wattia, kuten näet myös aiemman nvidia-smi-tulosteen Pwr:Usage/Cap-sarakkeesta. Kun lasket mukaan suorittimen ja muun järjestelmän kulutuksen, vähintään 1000 watin virtalähde on käytännössä minimi täyden tehon RTX 5090 -kokoonpanolle pitkäkestoisessa tekoälykäytössä. Jäähdytyksen osalta jatkuva LLM-inferenssi kuormittaa GPU:ta tasaisemmin kuin vaihteleva pelikuorma, joten kotelon ilmavirtaukseen kannattaa kiinnittää huomiota, jos aiot pitää mallia ladattuna tunteja kerrallaan.

Vaihe 1: Tarkista Nvidia-ajurit ja CUDA-tuki

Ennen asennusta varmista, että käyttöjärjestelmä näkee näytönohjaimen oikein. Avaa terminaali (Windowsissa PowerShell, Linuxissa bash) ja aja seuraava komento.

nvidia-smi

Onnistuneen ajon tulisi näyttää tällaista tietoa, mukaan lukien ajurin versio, CUDA-version tunniste ja GPU:n muistin käyttöaste:

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 560.94    Driver Version: 560.94    CUDA Version: 12.6           |
|-------------------------------+----------------------+----------------------+
| GPU  Name            TCC/WDDM | Bus-Id        Disp.A  | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|           Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  NVIDIA GeForce RTX 5090   |  00000000:01:00.0  On |                  N/A |
|  30%   42C    P8    18W / 575W|    412MiB / 32768MiB   |      2%      Default |
+-------------------------------+----------------------+----------------------+

Jos komento ei löydy tai palauttaa virheen, ajurit puuttuvat tai ovat vanhentuneet. Lataa uusin ajuripaketti Nvidian sivustolta, asenna se ja käynnistä kone uudelleen ennen kuin jatkat. Ilman toimivaa nvidia-smi-tulostetta Ollama ei osaa hyödyntää GPU-kiihdytystä, vaan koko laskenta putoaa suorittimelle ja vastausajat moninkertaistuvat, usein 5–10-kertaisiksi verrattuna GPU-kiihdytettyyn ajoon. Kannattaa myös tarkistaa CUDA-version numero tulosteen oikeasta yläkulmasta, sillä osa uusimmista kirjastoista vaatii vähintään CUDA 12 -sarjan tuen.

Vaiheet 2–3: Asenna Ollama Windowsille ja Linuxille

Ollaman asennus eroaa hieman käyttöjärjestelmän mukaan, mutta molemmat reitit vievät alle viisi minuuttia eivätkä vaadi käsin tehtävää CUDA-kirjastojen asennusta.

Windows-asennus

Lataa asennuspaketti osoitteesta ollama.com/download ja aja se normaalina Windows-asennusohjelmana. Asennus lisää Ollaman järjestelmän palveluksi, joka käynnistyy automaattisesti taustalle joka kerta, kun kirjaudut sisään, joten sinun ei tarvitse käynnistää sitä manuaalisesti jatkossa. Voit tarkistaa, että palvelu on käynnissä, avaamalla PowerShellin ja ajamalla:

ollama --version

Jos komento tulostaa versionumeron, asennus onnistui. Ollama näkyy myös Windowsin ilmaisinalueella pienenä kuvakkeena, josta pääset käsiksi asetuksiin ja lokitiedostoihin.

Linux-asennus

Linuxilla asennus hoituu yhdellä skriptillä, joka tunnistaa jakelun automaattisesti ja asentaa tarvittavat riippuvuudet:

curl -fsSL https://ollama.com/install.sh | sh

Skripti tunnistaa Nvidia-ajurit automaattisesti ja ottaa GPU-kiihdytyksen käyttöön ilman erillisiä lippuja. Asennuksen jälkeen Ollama käynnistyy systemd-palveluna, ja voit varmistaa tilan komennolla systemctl status ollama. Jos käytät Debiania tai muuta jakelua ilman systemdiä, Ollaman voi käynnistää myös manuaalisesti komennolla ollama serve, jolloin palvelu jää käyntiin siihen terminaali-ikkunaan.

Vaiheet 4–5: Lataa ja aja ensimmäinen kielimalli

Kun asennus on valmis, seuraava askel on ladata ja käynnistää ensimmäinen malli. Ollama hakee mallin automaattisesti omasta kirjastostaan, jos sitä ei vielä ole koneella, joten erillistä latauskomentoa ei tarvita. Aja terminaalissa:

ollama run llama3.1:8b

Ensimmäisellä kerralla komento lataa mallin, joka on kvantisoituna noin 4,7 gigatavua. Latausnopeus riippuu verkkoyhteydestäsi, mutta tyypillisellä suomalaisella kuituliittymällä lataus kestää muutamasta minuutista noin kymmeneen minuuttiin. Latauksen jälkeen näet interaktiivisen kehotteen, johon voit kirjoittaa kysymyksiä suoraan:

pulling manifest
pulling 8eeb52dfb3bb... 100% ▕████████████████▏ 4.7 GB
pulling 73b313b5552d... 100% ▕████████████████▏  1.5 KB
verifying sha256 digest
writing manifest
success

>>> Selitä lyhyesti, mitä kvantisointi tarkoittaa kielimalleissa
Kvantisointi pienentää mallin painojen tarkkuutta (esim. 16-bittisestä
4-bittiseksi), mikä vähentää muistintarvetta ja nopeuttaa laskentaa
laadun kärsimättä merkittävästi pienillä ja keskisuurilla malleilla.

Jos vastaus tulee lähes välittömästi ja nvidia-smi näyttää GPU-käytön nousevan ajon aikana toisessa terminaalissa, kiihdytys toimii oikein. Jos taas ensimmäinen sana ilmestyy vasta useiden sekuntien viiveellä eikä GPU-käyttöaste nouse lainkaan, malli ajautuu todennäköisesti suorittimelle, ja kannattaa palata vaiheeseen yksi tarkistamaan ajurit. Poistu keskustelusta komennolla /bye.

Vaihe 6: Valitse malli ja kvantisointitaso oikein

Mallin ja kvantisoinnin valinta on koko prosessin tärkein päätös, koska se ratkaisee sekä vastausten laadun että nopeuden. Nvidian elokuun 2026 ohjeistus suosittelee llama.cpp-pohjaisille työkuormille Q4_K_M-kvantisointia oletusarvoisena tasapainona suorituskyvyn ja laadun välillä. PyTorch- ja vLLM-pohjaisissa ajoissa Nvidia puolestaan suosittaa NVFP4-kvantisoituja tarkistuspisteitä, jotka tarjoavat paremman suorituskyvyn GeForce-korteilla laadun juuri kärsimättä.

KvantisointiTarkkuusSuhteellinen kokoSopii parhaiten
FP16Täysi100 %Palvelinkortit, ei tavalliselle pelikoneelle
Q8_0Erittäin korkea~53 %Kun VRAM-muistia on runsaasti (24 GB+)
Q4_K_MHyvä, Nvidian suosittelema oletus llama.cpp:lle~30 %Yleiskäyttö kuluttaja-GPU:illa
NVFP4Optimoitu GeForce-korteille~28 %PyTorch/vLLM-työkuormat RTX-korteilla
Q2_KMatala, laatu kärsii selvästi~18 %Vain kun VRAM on erittäin rajallinen

Käytännössä: jos GPU:ssasi on 8–12 GB VRAM-muistia, pysy 7–8 miljardin parametrin malleissa Q4_K_M-kvantisoinnilla. 16–24 GB avaa 13–30 miljardin parametrin mallit. 32 GB:n RTX 5090 -kortilla voit kokeilla jopa 70 miljardin parametrin malleja, kunhan kvantisointi on riittävän tiukka. Voit vaihtaa mallia milloin tahansa komennolla ollama run ja uuden mallin nimellä, esimerkiksi ollama run llama3.1:70b. Jos et ole varma, kumpaa kvantisointitasoa käyttää, aloita aina Q4_K_M:stä ja siirry tarkempaan vasta, jos VRAM-tilaa jää selvästi yli.

Suositut mallit vertailussa: mikä sopii mihinkin käyttöön

Ollaman mallikirjastosta löytyy kymmeniä avoimen lähdekoodin malleja, mutta käytännössä uusien käyttäjien kannattaa aloittaa muutamasta tunnetusta perheestä. Seuraava taulukko auttaa valitsemaan mallin käyttötarkoituksen ja käytettävissä olevan VRAM-muistin mukaan.

MalliParametritVRAM (Q4)Parhaiten sopiva käyttö
Llama 3.1 8B8 mrd.~6 GBYleiskäyttö, nopea vastausaika
Gemma 2 9B9 mrd.~7 GBTiivis tekstinkäsittely ja tiivistäminen
Mistral 7B7 mrd.~5 GBNopea koodiavustin kevyellä laitteistolla
Qwen 2.5 14B14 mrd.~10 GBMonikielinen käyttö, hyvä laadun ja koon suhde
Llama 3.1 70B70 mrd.~40–45 GBVaativat päättelytehtävät, edellyttää tehokkaan GPU:n

Nyrkkisääntönä kannattaa aloittaa pienemmästä mallista ja testata, riittääkö laatu käyttötarkoitukseesi. Moni käyttäjä yllättyy siitä, kuinka pätevä 8–14 miljardin parametrin malli on tavallisissa tekstinkäsittely-, tiivistämis- ja koodausapu-tehtävissä. Suurempaan 70 miljardin parametrin malliin kannattaa siirtyä vasta, jos huomaat pienemmän mallin vastausten jäävän pinnallisiksi monimutkaisemmissa päättelytehtävissä.

Llama 3.1 8B toimii oppaan oletusesimerkkinä siksi, että se on hyvä yleismalli lähes mille tahansa 8 gigatavun VRAM-muistilla varustetulle kortille, ja se vastaa nopeasti myös suomenkielisiin kysymyksiin, vaikka koulutusdata onkin painottunut englantiin. Gemma 2 9B taas erottuu erityisesti tiiviissä tiivistämistehtävissä, kuten pitkän raportin pääkohtien poimimisessa. Mistral 7B on kevyin vaihtoehto listalla ja sopii hyvin kannettaviin tietokoneisiin, joissa VRAM on niukka. Qwen 2.5 14B taas on hyvä kompromissi, jos tarvitset parempaa monikielistä tukea ja sinulla on hieman enemmän muistia käytössä kuin peruspaketissa. Llama 3.1 70B kannattaa varata tilanteisiin, joissa vastauksen pitää käsitellä useita toisiinsa liittyviä lähteitä samanaikaisesti, esimerkiksi laajaa sopimuskokonaisuutta analysoitaessa.

Vaiheet 7–9: Asenna Open WebUI Dockerilla selainkäyttöliittymäksi

Terminaali riittää testaukseen, mutta päivittäiseen käyttöön kannattaa asentaa selainpohjainen käyttöliittymä, joka muistuttaa ulkoasultaan tavallista chat-sovellusta. Open WebUI on suosituin vaihtoehto, ja se asennetaan Docker-kontissa, jolloin se pysyy erillään muusta järjestelmästä eikä sotke asennettuja Python-kirjastoja.

Docker Compose -määrittely

Luo tiedosto nimeltä docker-compose.yml seuraavalla sisällöllä:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://host.docker.internal:11434
    volumes:
      - open-webui:/app/backend/data
    restart: unless-stopped
    extra_hosts:
      - "host.docker.internal:host-gateway"

volumes:
  open-webui:

Käynnistä pino komennolla docker compose up -d. Portti 3000 avautuu selaimeen osoitteessa http://localhost:3000, ja ensimmäisellä kerralla sinua pyydetään luomaan paikallinen käyttäjätili. Kaikki mallit, jotka olet jo ladannut Ollamalla, ilmestyvät automaattisesti valikkoon ilman erillistä konfigurointia. Voit myös kutsua uusia malleja suoraan selaimen kautta, jolloin Open WebUI välittää latauspyynnön Ollaman taustapalvelulle.

NVIDIA Container Toolkit GPU-tukea varten

Jos haluat ajaa myös itse Ollaman kontissa (eikä vain Open WebUI:ta), Docker tarvitsee erillisen ajurisillan nähdäkseen GPU:n, koska kontit eivät oletusarvoisesti näe isäntäkoneen laitteistoa. Asenna NVIDIA Container Toolkit ja ota se käyttöön:

sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Tämän jälkeen voit lisätä kontin käynnistykseen lipun --gpus=all, jolloin myös konttiin asennettu Ollama pääsee käsiksi näytönohjaimeen. Ilman tätä vaihetta kontissa ajettava malli putoaa hitaalle CPU-polulle, vaikka isäntäkoneella olisi tehokas RTX-kortti. Voit varmistaa, että kontti näkee GPU:n, ajamalla docker exec -it ollama nvidia-smi ja tarkistamalla, että tuloste vastaa isäntäkoneella nähtyä.

Vaiheet 10–11: Optimoi suorituskyky ja muistinkäyttö

Kun perusasennus toimii, viimeistele suorituskyky säätämällä muutamaa ympäristömuuttujaa. Kontekstin pituus (kuinka pitkän keskusteluhistorian malli muistaa) on suurin yksittäinen muistinkuluttaja pitkissä keskusteluissa. Voit rajoittaa sitä Modelfile-tiedostolla:

FROM llama3.1:8b
PARAMETER num_ctx 8192
PARAMETER num_gpu 999
PARAMETER temperature 0.7

Tallenna tämä tiedostoksi Modelfile ja luo siitä oma versio komennolla ollama create oma-malli -f Modelfile. Parametri num_gpu 999 pakottaa Ollaman yrittämään ajaa kaikki kerrokset GPU:lla, mikä on turvallista niin kauan kuin VRAM riittää. Jos huomaat komennolla nvidia-smi dmon seurattuna, että muisti täyttyy ja järjestelmä alkaa vaihtaa levylle, pienennä num_ctx-arvoa tai siirry tiukempaan kvantisointiin. Parametri temperature puolestaan säätää vastausten satunnaisuutta: pienempi arvo tuottaa johdonmukaisempia mutta ennalta-arvattavampia vastauksia.

Toinen käytännön vinkki: aseta ympäristömuuttuja OLLAMA_KEEP_ALIVE=30m, jolloin malli pysyy GPU-muistissa puoli tuntia viimeisimmän kyselyn jälkeen sen sijaan, että se ladattaisiin uudelleen joka kerta. Tämä lyhentää toisen ja kolmannen kyselyn vasteaikaa merkittävästi, koska mallin lataus VRAM-muistiin on huomattavasti hitaampi operaatio kuin itse tekstin tuottaminen. Windowsissa muuttuja asetetaan järjestelmän ympäristömuuttujien kautta, Linuxissa se lisätään systemd-palvelun määrittelytiedostoon.

Vaihe 12: Rakenna oma Python-sovellus Ollama API:n päälle

Viimeisenä vaiheena kytket Ollaman omaan sovellukseesi. Ollama tarjoaa REST-rajapinnan porttiin 11434, joten mikä tahansa ohjelmointikieli, joka osaa tehdä HTTP-pyyntöjä, voi keskustella mallin kanssa. Alla on täydellinen, toimiva Python-esimerkki komentorivichatbotista, joka säilyttää keskusteluhistorian ja striimaa vastaukset reaaliajassa sitä mukaa kuin malli tuottaa niitä.

import json
import requests

OLLAMA_URL = "http://localhost:11434/api/chat"
MODEL = "llama3.1:8b"

def chat_loop():
    history = []
    print("Paikallinen tekoälyavustaja käynnissä. Kirjoita 'lopeta' poistuaksesi.\n")

    while True:
        user_input = input("Sinä: ")
        if user_input.strip().lower() == "lopeta":
            break

        history.append({"role": "user", "content": user_input})

        response = requests.post(
            OLLAMA_URL,
            json={"model": MODEL, "messages": history, "stream": True},
            stream=True,
        )

        print("Avustaja: ", end="", flush=True)
        full_reply = ""
        for line in response.iter_lines():
            if not line:
                continue
            chunk = json.loads(line)
            token = chunk.get("message", {}).get("content", "")
            print(token, end="", flush=True)
            full_reply += token
            if chunk.get("done"):
                break

        print("\n")
        history.append({"role": "assistant", "content": full_reply})

if __name__ == "__main__":
    chat_loop()

Tallenna koodi tiedostoksi chat.py, asenna riippuvuus komennolla pip install requests ja käynnistä sovellus komennolla python chat.py. Tämä on täysin toimiva pohja, jonka päälle voi rakentaa esimerkiksi asiakaspalvelubotin, sisäisen dokumenttihaun tai koodiavustimen. Koska kaikki pyynnöt kulkevat vain paikallisen verkon kautta, mikään keskustelu ei koskaan poistu koneelta. Voit laajentaa koodia lisäämällä tiedostojen lukemisen, jolloin mallille voi syöttää esimerkiksi PDF-dokumentin sisällön kontekstiksi ennen kysymystä.

Suorituskykyvertailu: RTX 4090 vs RTX 5090 paikallisessa tekoälyssä

Moni kysyy, kannattaako RTX 5090 -kortin hankinta pelkästään paikallista tekoälyä varten. Suorat token-per-sekunti-vertailut vaihtelevat mallin ja kvantisoinnin mukaan, mutta yleistä laskentatehoa voi arvioida julkisten 3DMark-vertailujen kautta, koska ne heijastavat samaa raaka laskentakapasiteettia, jota myös LLM-inferenssi lopulta hyödyntää.

MittariRTX 4090RTX 5090Ero
VRAM24 GB32 GB+33 %
3DMark Fire Strike (1080p)Perustaso101 767 pistettä~30–46 % korkeampi
3DMark Fire Strike Extreme (1440p)Perustaso60 778 pistettäKeskimäärin 36–42 % korkeampi
3DMark Fire Strike Ultra (4K)Perustaso33 114 pistettäSuurin ero 1080p-testeissä, n. 39,6 %
Suurin mallikoko käytännössä (Q4)~30–40 mrd. parametria~70 mrd. parametriaIsompi VRAM sallii isomman mallin

Julkiset leikkiluvut osoittavat, että synteettisissä testeissä RTX 5090 on keskimäärin 36–42 % nopeampi kuin RTX 4090, mutta samat lähteet muistuttavat, että pelikäytössä todellinen hyöty jää usein lähemmäs 20 %:a, kun DLSS-tekniikan vaikutus vähennetään laskuista. Sama logiikka pätee LLM-inferenssiin: suurempi VRAM avaa suuremmat mallit, mutta raa’an laskentatehon hyöty riippuu lopulta muistin kaistanleveydestä ja käytetystä kvantisointitasosta, ei pelkästä ydinmäärästä. Käytännön suositus on suoraviivainen. Jos ajat enintään 30 miljardin parametrin malleja, RTX 4090 riittää hyvin. Jos tavoitteena on 70 miljardin parametrin luokka ilman voimakasta laadun tinkimistä, 32 gigatavun VRAM-muisti tekee RTX 5090:stä perustellun valinnan, etenkin jos samaa konetta käytetään myös peleihin tai sisällöntuotantoon.

Jos budjetti on tiukka, kannattaa muistaa, että myös vanhempi, käytetty RTX 3090 -kortti pärjää tässä käytössä yllättävän hyvin, koska sen 24 gigatavun VRAM-muisti riittää samoihin mallikokoihin kuin RTX 4090:llä, vaikka raaka laskentateho onkin selvästi pienempi. Paikallisessa tekoälyssä VRAM-määrä ratkaisee usein enemmän kuin ydinmäärä, joten muistin koko kannattaa asettaa hankintapäätöksessä etusijalle pelkän suorituskykypisteytyksen sijaan.

Miten mitata oma suorituskyky: token-nopeuden testaus

Sen sijaan, että luottaisit pelkkiin yleisiin vertailulukuihin, kannattaa mitata oman koneen todellinen token-nopeus. Ollama tulostaa tarkat suoritustilastot, kun lisäät komentoon --verbose-lipun:

ollama run llama3.1:8b --verbose "Kirjoita kolme lausetta suomalaisesta talvesta"

Tuloste näyttää muun muassa eval rate -arvon, joka kertoo kuinka monta tokenia malli tuottaa sekunnissa. Tämä on käytännössä paras yksittäinen mittari, jolla voit verrata omaa asennustasi eri kvantisointitasoilla tai eri malleilla. Hyvänä nyrkkisääntönä 20–40 tokenia sekunnissa tuntuu käyttäjästä sujuvalta, reaaliaikaiselta keskustelulta, kun taas alle 10 tokenia sekunnissa alkaa tuntua takkuisalta erityisesti pidemmissä vastauksissa.

Jos eval rate on selvästi odotettua matalampi, tarkista järjestyksessä kolme asiaa: onko GPU-käyttöaste noussut ajon aikana (nvidia-smi), onko malli kokonaan VRAM-muistissa vai osittain järjestelmämuistissa (ollama ps näyttää tämän “100% GPU” tai prosenttiosuutena), ja onko taustalla muita raskaita ohjelmia, jotka varaavat samaa näytönohjainta. Näiden kolmen tarkistuksen jälkeen suurin osa suorituskykyongelmista selviää ilman lisäasennuksia.

Tietoturva paikallisessa tekoälyssä

Paikallinen ajo poistaa yhden riskin, mutta ei kaikkia. Vaikka data ei enää kulje ulkopuoliselle palvelimelle, itse koneesta tulee entistäkin houkuttelevampi kohde, koska sillä saattaa olla pääsy arkaluontoisiin dokumentteihin ja sisäisiin järjestelmiin. Pidä Ollaman ja Docker-kontin ohjelmistoversiot ajan tasalla, koska molemmat saavat säännöllisesti tietoturvapäivityksiä. Jos avaat Ollaman REST-rajapinnan koko lähiverkkoon, rajaa pääsy palomuurisäännöillä vain niille laitteille, jotka oikeasti tarvitsevat sitä.

Vältä myös lataamasta malleja tuntemattomista lähteistä. Ollaman virallinen kirjasto tarkistaa mallien tarkistussummat automaattisesti, mutta jos tuot mallitiedoston manuaalisesti kolmannen osapuolen sivustolta, et voi olla varma sen alkuperästä. Jos rakennat Ollaman päälle sovelluksen, jota käyttävät useat henkilöt, lisää sovellustasolle oma kirjautuminen ja lokitus, sillä Ollaman oma REST-rajapinta ei sisällä sisäänrakennettua käyttäjähallintaa.

Ollaman tärkeimmät komennot: pikaopas

Kun olet asentanut Ollaman ja ajanut ensimmäisen mallin, kannattaa tutustua muutamaan hallintakomentoon, joita tarvitset lähes päivittäin. Näiden avulla hallitset ladattuja malleja, seuraat käynnissä olevia prosesseja ja vapautat levytilaa, kun kokeilet useita eri malleja peräkkäin.

KomentoToiminto
ollama listNäyttää kaikki koneelle ladatut mallit ja niiden koon
ollama psNäyttää parhaillaan GPU-muistissa olevat, aktiiviset mallit
ollama rm mallin-nimiPoistaa ladatun mallin ja vapauttaa levytilan
ollama cp lahde kohdeKopioi olemassa olevan mallin uudella nimellä, esimerkiksi muokattua Modelfileä varten
ollama show mallin-nimiNäyttää mallin tekniset tiedot, kuten kontekstin pituuden ja kvantisoinnin
ollama stop mallin-nimiVapauttaa mallin GPU-muistista välittömästi ilman odotusaikaa

Erityisesti ollama list ja ollama rm ovat hyödyllisiä, kun kokeilet useita malleja peräkkäin. Kvantisoidut mallit vievät silti useita gigatavuja levytilaa kappaleelta, joten ne kannattaa siivota säännöllisesti, jos levytila on rajallinen. Komento ollama ps puolestaan auttaa tunnistamaan, onko edellinen malli edelleen ladattuna VRAM-muistissa, mikä selittää usein miksi seuraava malli ei enää mahdu mukaan.

Yleisimmät sudenkuopat ja miten vältät ne

  • Liian suuri malli suhteessa VRAM-muistiin. Kun malli ei mahdu kokonaan näytönohjaimen muistiin, Ollama siirtää osan kerroksista järjestelmämuistiin. Vastausnopeus voi pudota murto-osaan alkuperäisestä, koska PCIe-väylä on paljon hitaampi kuin näytönohjaimen sisäinen muisti. Tarkista aina mallin koko ennen latausta ja vertaa sitä käytettävissä olevaan VRAM-määrään.
  • Vanhentuneet Nvidia-ajurit. Ilman tuoretta ajuria CUDA-kiihdytys ei aktivoidu, ja koko laskenta putoaa hitaalle CPU-polulle ilman selkeää virheilmoitusta. Tämä on yleisin syy siihen, miksi vastaukset tuntuvat yllättävän hitailta uudella asennuksella.
  • Docker-kontti ei näe GPU:ta. Jos unohdat asentaa NVIDIA Container Toolkitin tai lisätä --gpus=all-lipun, konttiin asennettu malli ajautuu suorittimelle vaikka isäntäkoneella olisi tehokas kortti. Tarkista aina konttien GPU-näkyvyys erikseen ennen kuin oletat kiihdytyksen toimivan.
  • Väärä kvantisointitaso. Liian tiukka kvantisointi (esimerkiksi Q2_K) säästää muistia mutta heikentää vastausten laatua havaittavasti, erityisesti pidemmissä päättelyketjuissa. Aloita aina Q4_K_M-tasosta ja tiukenna vain tarpeen mukaan.
  • Portti 11434 tai 3000 on jo varattu. Toinen sovellus, kuten aiempi Docker-kontti tai kehityspalvelin, voi varata saman portin. Tarkista varatut portit ennen käynnistystä komennolla netstat -ano (Windows) tai ss -tulpn (Linux).
  • Liian pitkä konteksti-ikkuna. Jos nostat num_ctx-arvon liian korkeaksi suhteessa VRAM-muistiin, pitkä keskustelu voi kaataa mallin kesken vastauksen tai pakottaa sen levylle vaihtamiseen, mikä näkyy äkillisenä hidastumisena.
  • Palomuuri estää selainkäyttöliittymän. Jos Open WebUI ei aukea toiselta laitteelta samassa verkossa, tarkista että Windowsin tai Linuxin palomuuri sallii liikenteen valitulle portille.
  • Levytila loppuu kesken kokeilujen. Jokainen kvantisoitu malli vie useita gigatavuja, ja monta mallia rinnakkain kokeiltaessa levytila täyttyy yllättävän nopeasti. Siivoa käyttämättömät mallit säännöllisesti komennolla ollama rm, äläkä lataa kaikkia kiinnostavia malleja kerralla.

Vianmääritys: yleisimmät ongelmat ja ratkaisut

OngelmaTodennäköinen syyRatkaisu
nvidia-smi ei löydä GPU:taAjurit puuttuvat tai ovat rikkiAsenna uusin Game Ready tai Studio -ajuri ja käynnistä kone uudelleen
Ollama käyttää vain suoritintaCUDA-kiihdytys ei aktivoitunut asennuksessaAsenna Ollama uudelleen asennusskriptillä ajurien päivityksen jälkeen
“CUDA out of memory” -virheMalli tai kontekstin pituus ylittää VRAM-kapasiteetinVaihda tiukempaan kvantisointiin tai pienennä num_ctx-arvoa
Ollama-palvelu ei käynnistyPortti 11434 on jo varattuSulje varaava prosessi tai vaihda porttia ympäristömuuttujalla OLLAMA_HOST
Docker-kontti ei löydä OllamaaVäärä OLLAMA_BASE_URL-osoiteKäytä host.docker.internal-osoitetta ja tarkista extra_hosts-asetus
Malli vastaa hitaasti latauksen jälkeenkinOsa kerroksista on siirtynyt järjestelmämuistiinPienennä mallia tai vapauta VRAM-muistia sulkemalla muut GPU-ohjelmat
Open WebUI ei näytä ladattuja mallejaYhteys Ollaman taustapalveluun katkennutTarkista, että Ollama-palvelu on käynnissä ja portti 11434 vastaa
WSL2 rajoittaa suorituskykyä WindowsissaWSL2:n muistiraja on oletuksena liian tiukkaKasvata muistirajaa .wslconfig-tiedostossa tai aja Ollama natiivisti Windowsissa
Resizable BAR ei ole käytössäAsetus on pois päältä BIOS:issaOta Resizable BAR ja Above 4G Decoding käyttöön emolevyn BIOS-asetuksista

Kolme yllä olevista ongelmista kannattaa nostaa erikseen esiin, koska ne aiheuttavat suurimman osan tukipyynnöistä. “CUDA out of memory” -virhe ilmestyy tyypillisesti silloin, kun käyttäjä yrittää ajaa liian suurta mallia liian väljällä kontekstilla samaan aikaan. Ratkaisu on lähes aina joko tiukempi kvantisointi tai pienempi num_ctx-arvo, ei uuden näytönohjaimen ostaminen. WSL2:n muistiraja puolestaan yllättää monet Windows-käyttäjät, koska Linux-alijärjestelmä varaa oletuksena vain puolet koneen RAM-muistista, mikä voi tuntua riittämättömältä suurempien mallien kanssa. Kolmas yleinen sudenkuoppa on Docker-verkon osoitteisto: localhost kontin sisällä viittaa konttiin itseensä, ei isäntäkoneeseen, minkä vuoksi host.docker.internal-osoite on pakollinen.

Jos mikään näistä ratkaisuista ei auta, kannattaa tarkistaa Ollaman lokit yksityiskohtaisempaa virheilmoitusta varten. Linuxilla lokit löytyvät komennolla journalctl -u ollama --no-pager -n 50, joka näyttää viimeisimmät viisikymmentä riviä palvelun lokista. Windowsissa vastaavat lokit löytyvät Ollaman asennuskansiosta, ja ne kannattaa käydä läpi ennen kuin oletat vian olevan laitteistossa, koska suurin osa käynnistysongelmista johtuu asetustiedostojen ristiriidoista, ei viallisesta näytönohjaimesta.

Edistyneet vinkit kokeneille käyttäjille

Kun perusasennus on hallussa, seuraavat vinkit auttavat viilaamaan viimeisetkin tehot irti järjestelmästä ja skaalaamaan käyttöä useammalle henkilölle. Moni näistä vinkeistä tulee tarpeeseen vasta, kun paikallinen tekoälyjärjestelmä siirtyy yksittäisen kokeilun tasolta osaksi tiimin päivittäistä työkalupakkia.

  • Useamman GPU:n jakaminen. Jos koneessa on useampi Nvidia-kortti, Ollama jakaa suuret mallit automaattisesti korttien kesken. Voit ohjata jakoa ympäristömuuttujalla CUDA_VISIBLE_DEVICES, jos haluat rajata ajon vain tiettyihin kortteihin.
  • GPU-käytön reaaliaikainen seuranta. Komento nvidia-smi dmon -s u näyttää GPU:n käyttöasteen ja muistin kulutuksen sekunnin välein, mikä auttaa tunnistamaan pullonkaulat ajon aikana ilman erillisiä valvontatyökaluja.
  • Automaattinen käynnistys systemd-palveluna. Linuxilla Ollama rekisteröityy automaattisesti systemd-palveluksi, mutta voit lisätä oman Environment=-rivin /etc/systemd/system/ollama.service.d/override.conf-tiedostoon säätääksesi muistirajoja pysyvästi ilman että asetukset katoavat päivityksen yhteydessä.
  • Integraatio kehitysympäristöön. Ollaman REST-rajapinta on yhteensopiva monien VS Code -laajennusten ja LangChain-kaltaisten kehysten kanssa, joten sama paikallinen malli voi toimia sekä chatbotina että koodiavustimena samanaikaisesti.
  • Eräajot ja rinnakkaiset pyynnöt. Ympäristömuuttujalla OLLAMA_NUM_PARALLEL voit sallia useamman pyynnön käsittelyn samanaikaisesti, mikä on hyödyllistä, jos rakennat useamman käyttäjän sisäistä palvelua tiimin käyttöön.
  • Mukautetut järjestelmäkehotteet. Modelfile-tiedostoon voi lisätä SYSTEM-rivin, joka määrittää mallin roolin pysyvästi, esimerkiksi “Vastaa aina suomeksi ja pidä vastaukset lyhyinä”, jolloin jokaista kyselyä ei tarvitse muotoilla uudelleen.

Kun nämä optimoinnit on tehty kertaalleen, koko järjestelmä vaatii käytännössä vain satunnaista ylläpitoa: ajurien päivitystä muutaman kuukauden välein, Docker-kuvien päivitystä ja levytilan siivousta vanhoista malliversioista. Suurin osa käyttäjistä huomaa, että alkuasennuksen jälkeinen ylläpitotaakka on selvästi kevyempi kuin he etukäteen odottivat.

Usein kysytyt kysymykset

Tarvitsenko internetyhteyden Ollaman käyttöön asennuksen jälkeen?
Et. Kun malli on kertaalleen ladattu, koko keskustelu tapahtuu paikallisesti ilman verkkoyhteyttä. Internetiä tarvitaan vain uusien mallien lataamiseen ja Ollaman itsensä päivittämiseen.

Kuinka paljon VRAM-muistia tarvitsen 70 miljardin parametrin malliin?
Q4-kvantisoinnilla laske noin 40–45 gigatavua VRAM-muistia. Käytännössä tämä vaatii joko useamman näytönohjaimen tai voimakkaan kvantisoinnin yhdellä 32 gigatavun RTX 5090 -kortilla.

Toimiiko Ollama myös AMD-näytönohjaimilla?
Kyllä, Ollama tukee myös AMD:n ROCm-kiihdytystä tuetuilla korteilla, mutta tämä opas keskittyy Nvidia RTX -ympäristöön, koska sen ajurituki ja yhteisö ovat tällä hetkellä laajimmat kuluttajakorteille.

Onko paikallinen tekoäly turvallisempi kuin pilvipalvelut?
Tietoturvan näkökulmasta paikallinen ajo poistaa riskin, että kysely tai dokumentti kulkeutuu kolmannen osapuolen palvelimelle. Vastuu palvelimen ja käyttöjärjestelmän päivityksistä jää kuitenkin käyttäjälle itselleen, joten turvallisuus ei ole automaattinen etu vaan vaatii omaa ylläpitoa.

Voiko Ollamaa käyttää kaupallisesti?
Ollama-työkalu itsessään on avointa lähdekoodia, mutta jokaisen ladattavan mallin lisenssi kannattaa tarkistaa erikseen, sillä lisenssiehdot vaihtelevat mallin julkaisijan mukaan ja saattavat rajoittaa kaupallista käyttöä.

Mikä on ero Ollaman ja LM Studion välillä?
Molemmat ajavat paikallisia malleja, mutta Ollama on komentorivi- ja API-keskeinen ja sopii paremmin kehittäjille, kun taas LM Studio tarjoaa valmiin graafisen käyttöliittymän ilman erillistä Docker-asennusta.

Kuinka päivitän Ollaman uusimpaan versioon?
Windowsissa asennusohjelma tarkistaa päivitykset automaattisesti. Linuxilla riittää, että ajat asennusskriptin uudelleen: curl -fsSL https://ollama.com/install.sh | sh.

Voinko ajaa useita malleja samanaikaisesti?
Kyllä, mikäli VRAM riittää molemmille. Ollama lataa ja pitää muistissa useamman mallin rinnakkain, kunhan yhteenlaskettu muistintarve ei ylitä näytönohjaimen kapasiteettia.

Miksi vastaus on hitaampi ensimmäisellä kerralla kuin toisella?
Ensimmäinen kysely sisältää mallin latauksen VRAM-muistiin, mikä vie useita sekunteja mallin koosta riippuen. Seuraavat kyselyt ovat nopeampia, koska malli pysyy muistissa OLLAMA_KEEP_ALIVE-asetuksen mukaisen ajan.

Sopiiko kannettava RTX-näytönohjain samaan tarkoitukseen kuin pöytäkoneen kortti?
Kyllä periaatteessa, mutta kannettavien RTX-korttien VRAM-määrä on tyypillisesti pienempi kuin vastaavan pöytäkoneversion, joten mallin kokoa joudutaan usein rajoittamaan enemmän.

Voiko Ollamaa käyttää yhdessä muiden kehitystyökalujen kanssa, kuten VS Codessa?
Kyllä. Koska Ollama tarjoaa tavallisen REST-rajapinnan, useat VS Code -laajennukset ja komentorivityökalut osaavat käyttää sitä suoraan taustamoottorina ilman erillisiä pilvitilauksia.

Täydellinen projektikooste: mitä sait aikaan

Kun kaikki 12 vaihetta on käyty läpi, koneellasi pyörii kokonainen paikallinen tekoälyjärjestelmä ilman yhtäkään riippuvuutta ulkoiseen pilveen. Kokonaisuus koostuu neljästä osasta, jotka toimivat yhdessä: Ollama-taustapalvelu hoitaa mallin lataamisen ja GPU-kiihdytyksen, valittu Modelfile määrittää kontekstin pituuden ja lämpötilan, Open WebUI Docker-kontissa tarjoaa selainkäyttöliittymän kaikille kotiverkon laitteille, ja lopuksi oma chat.py-sovellus näyttää, miten samaa taustapalvelua voi ohjata suoraan koodista.

Käytännön tarkistuslista ennen kuin julistat asennuksen valmiiksi: nvidia-smi näyttää GPU:n tunnistettuna, ollama list näyttää vähintään yhden ladatun mallin, docker compose ps näyttää Open WebUI -kontin tilassa “running”, ja selaimessa osoitteessa http://localhost:3000 aukeaa toimiva keskusteluikkuna. Jos kaikki neljä kohtaa täyttyvät, järjestelmä on tuotantovalmis kevyeen sisäiseen käyttöön. Seuraava luonnollinen laajennusaskel on liittää järjestelmään oma dokumenttikanta hakua varten (RAG), mutta se on jo oman, laajemman oppaan aihe.