MLX Apple Siliconilla: 12 Vaihetta, 90 Min [2026]

Ollama ja LM Studio ovat tuttuja jo Nvidia- ja AMD-käyttäjille, mutta Mac-käyttäjillä on käytössään väline, jota kumpikaan kilpailijaleiri ei pysty täysin jäljittelemään: Applen oma MLX-kehys. Se on rakennettu alusta asti hyödyntämään Apple Siliconin yhtenäistä muistiarkkitehtuuria, eikä sen ajamiseen tarvita erillistä näytönohjainta, ajureita tai CUDA-asennusta. Syyskuussa 2026 ilmestynyt MLX-versio 0.32.2 ja tuoreet M5-sarjan sirut tekevät paikallisesta kielimallien ajamisesta Macilla nopeampaa kuin koskaan aiemmin, ja tässä oppaassa käydään läpi koko polku asennuksesta omaan, toimivaan projektiin asti.

Opas on kirjoitettu M5-, M5 Pro- ja M5 Max -siruilla varustetuille Maceille, mutta samat komennot toimivat myös vanhemmilla M1-M4-siruilla, joskin hitaammin. Käymme läpi Python-ympäristön pystytyksen, MLX:n ja MLX LM:n asennuksen, mallien lataamisen ja ajamisen sekä komentoriviltä että omasta koodista, kvantisoinnin, paikallisen OpenAI-yhteensopivan palvelimen pystytyksen, striimauksen, upotusmallit semanttista hakua varten, LoRA-hienosäädön ja lopuksi kokonaisen esimerkkiprojektin, jossa rakennetaan yksinkertainen dokumenttihaku paikallisella mallilla. Kaikki versiot ja komennot on tarkistettu 11. syyskuuta 2026.

Miksi tämä on ajankohtaista juuri nyt? MLX ei ole uusi projekti, mutta sen kehitystahti on kiihtynyt selvästi vuoden 2026 aikana samaan tahtiin kuin M5-sarjan sirujen julkaisut. Kehys sai version 0.32.0 heinäkuussa ja 0.32.2 elokuun lopussa, ja Applen omat WWDC 2026 -esitykset osoittavat, että yhtiö itse pitää paikallista tekoälyä yhtenä Mac-alustan keskeisimmistä myyntivalteista, ei enää harrastelijaprojektina.

Jos olet aiemmin lukenut laitteistokategoriamme vastaavia oppaita Nvidia- tai AMD-puolelta, huomaat nopeasti, että MLX:n asennus on huomattavasti kevyempi prosessi. Ei ajurikonflikteja, ei kernel-moduuleja, ei erillistä ROCm- tai CUDA-pinoa. Tämä on samalla oppaan suurin opetus: Apple Siliconin yhtenäinen muisti poistaa kokonaisen ongelmaluokan, joka vaivaa erillisillä näytönohjaimilla varustettuja koneita.

Mikä MLX on ja miksi se on tärkeä Apple Siliconille

MLX on Applen koneoppimistutkimustiimin kehittämä avoimen lähdekoodin taulukkokehys, joka on suunniteltu nimenomaan Apple Siliconin yhtenäistä muistiarkkitehtuuria varten. Applen oma MLX-projektisivu kuvaa kehyksen nimenomaan Apple Siliconin yhtenäiselle muistiarkkitehtuurille optimoiduksi, ja sen NumPy-tyylinen rajapinta tekee siitä tutun kaikille, jotka ovat käyttäneet Pythonin tieteellisen laskennan kirjastoja aiemmin.

Yhtenäinen muisti tarkoittaa käytännössä sitä, että suoritin, näytönohjainydin (GPU) ja neuraaliprosessori (NPU) jakavat saman fyysisen muistialueen. Perinteisessä PC-arkkitehtuurissa malli pitää ensin kopioida järjestelmämuistista erillisen näytönohjaimen omaan VRAM-muistiin ennen laskentaa, mikä syö sekä aikaa että kaksinkertaistaa muistitarpeen. Apple Siliconilla tätä kopiointivaihetta ei ole: malli ladataan kerran, ja CPU, GPU ja NPU voivat kaikki käsitellä samaa muistialuetta ilman siirtoja. Applen WWDC 2026 -esityksessä “Run local agentic AI on the Mac using MLX” kehystä kuvattiin pohjimmiltaan avoimen lähdekoodin taulukkokehykseksi, joka on rakennettu juuri Apple Siliconia varten.

MLX LM on tämän päälle rakennettu erillinen Python-paketti, joka tuo mukanaan komentorivityökalut ja valmiin Python-rajapinnan kielimallien ajamiseen ilman, että käyttäjän tarvitsee kirjoittaa matalan tason MLX-koodia itse. WWDC 2026 -session “Explore distributed inference and training with MLX” mukaan MLX LM tarjoaa juuri tämän: komentorivityökalut ja Python-rajapinnan kielimallien paikalliseen ajamiseen Apple Siliconilla. Käytännössä tämä tarkoittaa, että voit ladata mallin ja saada ensimmäisen vastauksen terminaalista alle minuutissa, ilman yhtään riviä omaa koodia.

Applen omat esittelyt korostavat myös vastenopeutta. WWDC 2025 -session “Explore large language models on Apple silicon with MLX” mukaan MLX mahdollistaa sujuvan reaaliaikaisen vuorovaikutuksen ja lukunopeutta nopeamman tekstin tuottamisen, jopa satojen miljardien parametrien malleilla, kaiken pyöriessä paikallisesti suoraan Mac-pöytäkoneella. Tämä ei tarkoita, että jokainen Mac pystyisi ajamaan jättimäisiä malleja sujuvasti, mutta se kertoo suunnasta, johon Apple on kehystä optimoinut.

Miksi paikallinen tekoäly kannattaa juuri nyt Suomessa

Paikallisen mallin ajamisessa on kolme käytännön etua, jotka korostuvat erityisesti Pohjoismaissa. Ensimmäinen on tietosuoja. Kun malli pyörii omalla koneella, mikään kehotteesi tai dokumenttisi sisältö ei kulje ulkopuolisen palvelimen kautta, mikä on merkittävä ero verrattuna pilvipohjaisiin chatbotteihin. Tämä on tärkeää etenkin, jos käsittelet työssäsi asiakastietoja, lääketieteellisiä tietoja tai muuta materiaalia, jonka siirtäminen kolmannen osapuolen palvelimelle voi olla GDPR:n näkökulmasta ongelmallista.

Toinen etu on kustannus pitkällä aikavälillä. Pilvipalveluiden kielimallirajapinnat laskuttavat tyypillisesti käytetyn tokenimäärän mukaan, ja kustannukset kasvavat suoraan käytön mukana. Paikallinen malli maksaa vain laitteiston hankintahinnan ja sähkön, minkä jälkeen käyttö on käytännössä ilmaista riippumatta siitä, kuinka monta kertaa päivässä sitä käytät. Tämä tekee paikallisesta ratkaisusta houkuttelevan erityisesti kehittäjille ja pienyrityksille, jotka käyttävät kielimallia toistuvasti osana työprosessiaan.

Kolmas etu liittyy luotettavuuteen ja saatavuuteen. Paikallinen malli toimii myös silloin, kun internetyhteys pätkii tai on kokonaan poikki, mikä voi olla arvokasta esimerkiksi kesämökillä tai matkalla junassa. Se ei myöskään ole riippuvainen pilvipalvelun käyttökatkoista, joita on nähty säännöllisesti myös suurilla toimijoilla viime vuosina. Näiden kolmen edun yhdistelmä selittää, miksi paikallisen tekoälyn suosio on kasvanut tasaisesti myös tavallisten kuluttajien ja pienyritysten keskuudessa, ei pelkästään tutkijoiden ja kehittäjien parissa.

Esivaatimukset: laitteisto ja ohjelmistoversiot

Ennen kuin aloitat, tarkista seuraavat asiat. Osa vaatimuksista on ehdottomia (esimerkiksi käyttöjärjestelmän arkkitehtuuri), osa taas käytännön nyrkkisääntöjä, jotka perustuvat testattuihin muistimääriin eri mallikoilla.

• Laite: mikä tahansa Apple Silicon -Mac (M1-M5-sarja), suositellaan M5-, M5 Pro- tai M5 Max -sirua parhaaseen suorituskykyyn
• Käyttöjärjestelmä: macOS Sequoia tai uudempi, MLX vaatii arm64-arkkitehtuurin eikä toimi Intel-Maceilla
• Python: versio 3.9 tai uudempi, suositellaan 3.11 tai 3.12 Homebrew’n kautta asennettuna
• MLX-versio: 0.32.2 (julkaistu 25.8.2026, viimeisin GitHub-julkaisu)
• MLX LM: uusin PyPI-julkaisu, asentuu samalla pip-komennolla kuin ydinkirjasto
• Yhtenäinen muisti: vähintään 16 Gt pieniin 7-9 miljardin parametrin malleihin, 64 Gt tai enemmän isompiin 30-70 miljardin parametrin malleihin
• Levytila: vähintään 20-100 Gt vapaana riippuen ladattavien mallien määrästä ja koosta
• Xcode Command Line Tools asennettuna kääntämistä varten
• Toimiva internetyhteys mallien lataamiseen Hugging Facesta asennuksen aikana

Muistimäärä on käytännössä tärkein yksittäinen tekijä, joka ratkaisee minkä kokoisia malleja voit ajaa sujuvasti. Koska Apple Silicon jakaa muistin CPU:n, GPU:n ja NPU:n kesken, käyttöjärjestelmä ja avoinna olevat sovellukset syövät osan samasta muistipoolista kuin kielimalli. Jos koneessasi on 16 gigatavua yhtenäistä muistia, kannattaa varautua siihen, että käytännössä käytettävissä on ehkä 10-12 gigatavua mallille, kun selain, sähköposti ja muut taustasovellukset ovat auki.

Taulukko alla kokoaa yhteen, minkä kokoinen Apple Silicon -kokoonpano sopii minkäkin kokoiselle mallille käytännössä, kun mallia ajetaan yleisimmällä Q4-kvantisoinnilla.

Mallin koko	Suositeltu yhtenäinen muisti	Sopiva siru	Käyttötarkoitus
1-3 miljardia parametria	8-16 Gt	M1-M5 (perus)	Nopeat kokeilut, mobiilisovellusten taustalogiikka
7-9 miljardia parametria	16-32 Gt	M5, M5 Pro	Yleiskäyttö, chatbotit, koodiavustajat
13-14 miljardia parametria	32-64 Gt	M5 Pro, M5 Max	Tarkempi päättely, pidempi konteksti
30-32 miljardia parametria	64 Gt	M5 Max (64 Gt)	Vaativammat tehtävät, agenttityö
70 miljardia parametria	128 Gt	M5 Max (128 Gt)	Tutkimuskäyttö, laadukkain paikallinen päättely

Vaihe 1: Homebrew’n ja Pythonin asennus

Jos koneellasi ei vielä ole Homebrew’ta, asenna se ensin. Homebrew hoitaa Pythonin ja muiden riippuvuuksien asennuksen huomattavasti siistimmin kuin järjestelmän oma Python, jota ei kannata koskaan käyttää projektien pohjana macOS:llä.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install [email protected]
python3 --version

Varmista, että komento python3 --version palauttaa version 3.11 tai uudemman. Jos koneellasi on useita Python-asennuksia (esimerkiksi järjestelmän oma versio ja Homebrew’n asentama versio), kannattaa käyttää virtuaaliympäristöä, jotta MLX:n riippuvuudet eivät sotke muita projektejasi.

Vaihe 2: Luo erillinen virtuaaliympäristö

Virtuaaliympäristö eristää MLX:n ja sen riippuvuudet muusta järjestelmästäsi. Tämä on erityisen hyödyllistä, jos aiot myöhemmin kokeilla useita eri projekteja, joissa on ristiriitaisia pakettivaatimuksia.

mkdir ~/mlx-projekti && cd ~/mlx-projekti
python3 -m venv .venv
source .venv/bin/activate

Kun ympäristö on aktivoitu, terminaalin kehotteen alkuun ilmestyy (.venv)-merkintä. Tästä eteenpäin kaikki pip install -komennot asentavat paketit vain tähän ympäristöön, eivät koko järjestelmään.

Vaihe 3: MLX:n ja MLX LM:n asennus

Itse asennus on yksi komento. Toisin kuin CUDA- tai ROCm-pohjaiset asennukset, MLX ei vaadi erillisten ajurien, kernel-moduulien tai järjestelmätason kirjastojen asentamista, koska se nojaa suoraan macOS:n omaan Metal-rajapintaan GPU-kiihdytykseen.

pip install --upgrade pip
pip install mlx mlx-lm
python3 -c "import mlx.core as mx; print(mx.default_device())"

Viimeinen rivi tulostaa oletuslaitteen, jonka pitäisi näyttää GPU-kiihdytetty Metal-laite. Jos komento epäonnistuu ilmoituksella arkkitehtuurista, olet todennäköisesti käyttämässä Intel-pohjaista Python-asennusta Rosetta-tilassa, mikä ei tue MLX:ää. Tähän palataan tarkemmin vianmääritysosiossa.

Vaihe 4: Ensimmäisen mallin lataus ja ajo komentoriviltä

MLX LM tuo mukanaan mlx_lm.generate-komennon, joka lataa mallin Hugging Facesta, ajaa annetun kehotteen ja tulostaa vastauksen suoraan terminaaliin. Applen oman WWDC-esityksen sanoin kyseessä on komentorivityökalu, jolla voi tuottaa tekstiä kielimallilla suoraan terminaalista ilman koodia. Se lataa mallin tarvittaessa, ajaa kehotteen sen läpi ja tulostaa tuotetun vastauksen.

mlx_lm.generate --model mlx-community/Llama-3.1-8B-Instruct-4bit \
  --prompt "Selitä lyhyesti, mitä yhtenäinen muisti tarkoittaa Apple Siliconissa."

Ensimmäisellä ajokerralla komento lataa mallin painot Hugging Facesta ja tallentaa ne paikalliseen välimuistiin (~/.cache/huggingface), joten ensimmäinen suoritus kestää mallin koosta ja verkkoyhteydestäsi riippuen muutamasta minuutista kymmeneen. Seuraavilla kerroilla malli ladataan suoraan levyltä, jolloin käynnistys kestää vain muutaman sekunnin.

Esimerkkituloste M5 Pro -Macilla 64 gigatavun yhtenäisellä muistilla näyttää tältä:

==========
Yhtenäinen muisti Apple Siliconissa tarkoittaa, että suoritin, näytönohjainydin
ja neuraaliprosessori jakavat saman fyysisen muistialueen sen sijaan, että
kullakin olisi oma erillinen muistinsa...
==========
Prompt: 18 tokens, 412.3 tokens-per-sec
Generation: 187 tokens, 38.6 tokens-per-sec
Peak memory: 5.912 GB

Tulosteen lopussa näkyvät kehotteen käsittelynopeus, varsinaisen tekstin tuottonopeus tokeneina sekunnissa sekä muistin huippukäyttö. Näitä lukuja kannattaa seurata, kun vertailet eri mallikokoja ja kvantisointitasoja myöhemmin.

Vaihe 5: Python-rajapinnan käyttö omissa skripteissä

Komentorivi riittää nopeaan kokeiluun, mutta useimmat sovellukset tarvitsevat mallin osaksi omaa Python-koodia. MLX LM:n Python-rajapinta on tähän suunniteltu, ja se koostuu käytännössä kahdesta funktiosta: load lataa mallin ja tokenisaattorin, generate tuottaa vastauksen.

from mlx_lm import load, generate

model, tokenizer = load("mlx-community/Llama-3.1-8B-Instruct-4bit")

kehote = tokenizer.apply_chat_template(
    [{"role": "user", "content": "Kirjoita kolme etua paikallisen tekoälymallin ajamisesta."}],
    add_generation_prompt=True,
)

vastaus = generate(model, tokenizer, prompt=kehote, verbose=True, max_tokens=300)
print(vastaus)

apply_chat_template-funktio muotoilee viestin mallin odottamaan keskustelumuotoon, mikä on tärkeää erityisesti Instruct-tyyppisillä malleilla, jotka on hienosäädetty tiettyyn keskustelurakenteeseen. Jos ohitat tämän ja syötät mallille pelkän raakatekstin, vastaukset ovat usein epäjohdonmukaisia tai malli jatkaa kehotetta sen sijaan, että vastaisi siihen.

Vaihe 6: Kvantisointi ja muistinhallinta

Kvantisointi tarkoittaa mallin painojen tarkkuuden pienentämistä, mikä pienentää sekä tiedostokokoa että muistintarvetta laadun kustannuksella. MLX-yhteisö julkaisee Hugging Facessa valmiiksi kvantisoituja malleja mlx-community-organisaation alla, mutta voit myös kvantisoida minkä tahansa yhteensopivan mallin itse.

mlx_lm.convert --hf-path meta-llama/Llama-3.1-8B-Instruct \
  --mlx-path ./llama-3.1-8b-4bit \
  --quantize --q-bits 4

--q-bits 4 tarkoittaa 4-bittistä kvantisointia, joka on yleisin kompromissi koon ja laadun välillä. Arvo 8 säilyttää enemmän tarkkuutta mutta tuplaa suunnilleen muistintarpeen, kun taas arvot alle 4 pienentävät kokoa entisestään mutta heikentävät vastausten laatua havaittavasti, erityisesti pidemmissä ja monimutkaisemmissa tehtävissä.

Kannattaa huomata, että MLX:n oma kvantisointimuoto ei ole sama asia kuin GGUF, jota llama.cpp ja Ollama käyttävät. Näitä kahta muotoa ei voi sekoittaa keskenään, joten jos sinulla on jo valmiiksi ladattuja GGUF-tiedostoja Ollaman käytöstä, niitä ei voi suoraan ladata MLX LM:llä. Hyvä uutinen on, että suurin osa suosituista malleista löytyy valmiiksi käännettynä molempiin muotoihin Hugging Facesta, joten harvoin joudut itse muuntamaan mallia manuaalisesti, ellei kyseessä ole hyvin tuore tai harvinainen malli.

Kvantisointitaso	Suhteellinen koko (8B-malli)	Muistin tarve	Sopii parhaiten
FP16 (kvantisoimaton)	~16 Gt	20+ Gt	Maksimaalinen tarkkuus, tutkimuskäyttö
8-bit	~8 Gt	10-12 Gt	Laadukas päättely, kohtuullinen muisti
4-bit (Q4)	~4-5 Gt	6-8 Gt	Yleiskäyttö, paras kompromissi
3-bit	~3 Gt	5-6 Gt	Tiukka muistibudjetti, yksinkertaiset tehtävät

Vaihe 7: Paikallisen OpenAI-yhteensopivan palvelimen pystytys

Moni sovellus ja työkalu osaa jo puhua OpenAI:n rajapintaformaattia. MLX LM sisältää valmiin palvelinkomennon, joka avaa saman rajapinnan paikallisesti, jolloin voit korvata pilvipalvelun paikallisella mallilla vaihtamalla vain osoitteen.

mlx_lm.server --model mlx-community/Llama-3.1-8B-Instruct-4bit --port 8080

Kun palvelin on käynnissä, voit lähettää sille pyyntöjä tavallisella curl-komennolla tai millä tahansa OpenAI-yhteensopivalla kirjastolla.

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [{"role": "user", "content": "Mikä on MLX?"}],
    "max_tokens": 200
  }'

Koska palvelin kuuntelee oletuksena vain paikallista konetta (127.0.0.1), se ei ole muiden verkossa olevien laitteiden saatavilla ilman erillistä porttiohjausta. Jos haluat käyttää palvelinta esimerkiksi kotiverkkosi muilta laitteilta, tarkista macOS:n palomuuriasetukset ja rajaa pääsy vain luotettuihin IP-osoitteisiin, sillä oletuksena palvelimessa ei ole todennusta.

Vaihe 8: Suorituskyvyn mittaus omalla laitteistolla

Ennen kuin luotat mihinkään yleisiin vertailulukuihin, kannattaa mitata suorituskyky juuri omalla koneellasi, koska taustalla ajossa olevat sovellukset, lämpötila ja akkukäyttö (verrattuna verkkovirtaan) vaikuttavat kaikki tuloksiin. mlx_lm.generate-komennon --verbose-lippu tulostaa automaattisesti sekä kehotteen käsittelynopeuden että generointinopeuden.

mlx_lm.generate --model mlx-community/Llama-3.1-8B-Instruct-4bit \
  --prompt "Kirjoita 200 sanan essee tekoälyn tulevaisuudesta." \
  --max-tokens 300 --verbose

Julkaistujen mittausten mukaan Llama 3.1 8B -mallilla (Q4_K_M-kvantisointi) suorituskyky vaihtelee siru- ja muistikokoonpanon mukaan huomattavasti. Alla oleva taulukko kokoaa yhteen julkaistuja mittaustuloksia eri Apple Silicon -kokoonpanoilla sekä vertailukohtana yhden yleisen erillisen näytönohjaimen luvut.

Laitteisto	Llama 3.1 8B (Q4), tok/s	Llama 3.3 70B (Q4), tok/s	Muisti
M5 Pro, 32 Gt	25-30	Ei mahdu muistiin	32 Gt
M5 Pro, 64 Gt	35-45	4-6	64 Gt
M5 Max, 64 Gt	50-65	8-12	64 Gt
M5 Max, 128 Gt	60-75	12-18	128 Gt
Nvidia RTX 4090 (vertailu)	90-120	6-10 (osittain ulkoistettu)	24 Gt VRAM

Luvuista huomaa selvästi kaksi asiaa. Pienemmillä malleilla erillinen näytönohjain kuten RTX 4090 on nopeampi raakana tokeninopeutena, koska sen VRAM-kaistanleveys on suurempi kuin Apple Siliconin yhtenäisen muistin kaistanleveys. Isommilla 70 miljardin parametrin malleilla tilanne kuitenkin kääntyy, koska 24 gigatavun VRAM ei riitä koko malliin, jolloin osa painoista pitää ulkoistaa hitaammalle järjestelmämuistille. M5 Max 128 Gt taas mahtuu ajamaan koko 70B-mallin suoraan yhtenäisessä muistissa ilman ulkoistamista, mikä selittää sen kilpailukykyisen suorituskyvyn isoilla malleilla.

Vaihe 9: LoRA-hienosäätö omalla datalla

MLX LM tukee myös kevyttä hienosäätöä LoRA-menetelmällä (Low-Rank Adaptation), jonka avulla voit mukauttaa valmiin mallin vastaustyyliä tai erikoisosaamista ilman koko mallin uudelleenkouluttamista. Tämä on käytännössä ainoa hienosäätötapa, joka on realistinen tavallisella kuluttaja-Macilla, koska täysi hienosäätö vaatisi moninkertaisen muistimäärän.

mlx_lm.lora --model mlx-community/Llama-3.1-8B-Instruct-4bit \
  --train \
  --data ./oma_data \
  --iters 600 \
  --batch-size 4

Kansio ./oma_data odottaa JSONL-tiedostoja nimillä train.jsonl ja valid.jsonl, joissa jokainen rivi sisältää yhden esimerkkikeskustelun samassa muodossa kuin mallin oma keskustelumalline. Iteraatioiden määrä ja eräkoko (batch size) kannattaa aloittaa pienestä ja kasvattaa vähitellen, sillä liian suuri eräkoko voi johtaa muistin loppumiseen kesken koulutuksen erityisesti alle 32 gigatavun koneilla.

Vaihe 10: Kolmannen osapuolen työkalut – LM Studio ja Rapid-MLX

Jos komentorivi ei ole mieleinen, LM Studio tukee MLX-taustajärjestelmää natiivisti graafisella käyttöliittymällä Apple Silicon -Maceilla, samaan tapaan kuin se tukee ROCm:ää AMD-korteilla ja CUDA:a Nvidia-korteilla. Mallien lataaminen ja ajaminen onnistuu hiiren klikkauksilla, ja sovellus näyttää generointinopeuden ja muistinkäytön reaaliaikaisesti käyttöliittymässä.

Vaihtoehtoisesti yhteisöprojekti Rapid-MLX, joka markkinoi itseään nopeimpana paikallisena tekoälymoottorina Apple Siliconille, julkaisi version 0.14.1 11.9.2026. Se on suunnattu erityisesti käyttäjille, jotka haluavat puristaa viimeisenkin suorituskyvyn irti MLX-pohjaisesta päättelystä ilman graafisen käyttöliittymän yleiskuluja. Kummankin työkalun etu komentorivin sijaan on se, että mallien vaihtaminen ja useamman keskustelun hallinta onnistuu ilman terminaalikomentoja, mikä sopii paremmin päivittäiseen käyttöön.

Graafisen käyttöliittymän ja komentorivin välillä ei tarvitse valita vain toista, sillä molemmat voivat käyttää samoja paikallisesti tallennettuja malleja. Jos olet jo ladannut mallin komentorivin kautta MLX LM:llä, LM Studio löytää usein saman malliversion uudelleenkäytettäväksi, jolloin et joudu lataamaan samaa muutaman gigatavun tiedostoa kahteen kertaan. Tämä kannattaa tarkistaa LM Studion asetuksista ennen kuin lataat mallin uudelleen graafisen käyttöliittymän kautta.

Vaihe 11: Striimaus ja pidempi konteksti pitkissä keskusteluissa

Kun rakennat omaa sovellusta MLX LM:n päälle, vastauksen odottaminen kokonaisuudessaan ennen tulostusta tuntuu usein hitaalta, vaikka malli tuottaisikin tekstiä kohtuullisella nopeudella. Ratkaisu on striimaus, jossa tokenit tulostetaan yksi kerrallaan heti kun ne valmistuvat, samaan tapaan kuin useimmat pilvipohjaiset chatbotit toimivat. MLX LM:n Python-rajapinta tukee tätä stream_generate-funktiolla.

from mlx_lm import load, stream_generate

model, tokenizer = load("mlx-community/Llama-3.1-8B-Instruct-4bit")
kehote = tokenizer.apply_chat_template(
    [{"role": "user", "content": "Listaa viisi vinkkiä sähkönkulutuksen ajoittamiseen."}],
    add_generation_prompt=True,
)

for pala in stream_generate(model, tokenizer, prompt=kehote, max_tokens=300):
    print(pala.text, end="", flush=True)

Kontekstin pituus kannattaa myös ottaa huomioon jo mallia valitessa. Pidempi konteksti tarkoittaa, että malli pystyy pitämään mielessä enemmän aiempaa keskustelua tai pidemmän dokumentin kerralla, mutta se myös kasvattaa muistintarvetta, koska jokainen kontekstissa oleva tokeni vie oman osansa muistista niin sanotun avain-arvo-välimuistin (KV cache) muodossa. Jos huomaat muistin loppuvan kesken pitkässä keskustelussa vaikka itse malli mahtuisi hyvin muistiin, syy on usein juuri kasvanut KV-välimuisti, ei itse mallin koko.

MLX LM vai Ollama: kumpi kannattaa valita Macilla

Moni on jo tuttu Ollaman kanssa, koska se on suosittu valinta sekä Nvidia- että AMD-koneilla. Ollama toimii myös Macilla, mutta sen taustalla on llama.cpp, joka on alustariippumaton moottori eikä hyödynnä Apple Siliconin erityispiirteitä yhtä tarkasti kuin MLX, joka on rakennettu alusta asti juuri tätä arkkitehtuuria varten. Käytännön erot näkyvät kolmella tavalla.

Ensinnäkin käyttöönoton helppous puhuu Ollaman puolesta: yksi asennuskomento ja mallien lataus onnistuu yhdellä rivillä ilman Python-ympäristön pystyttämistä lainkaan. MLX LM taas vaatii Python-ympäristön, mutta tarjoaa vastineeksi paljon suoremman pääsyn mallin sisäisiin osiin, mikä on tärkeää juuri tässä oppaassa käsitellyssä LoRA-hienosäädössä ja omien Python-sovellusten rakentamisessa. Toiseksi, MLX:n natiivi Metal-integraatio antaa sille usein pienen etulyöntiaseman tuoreimmilla M5-siruilla, koska Apple optimoi kehystä suoraan uusien siru-sukupolvien mukana, kun taas llama.cpp:n Apple Silicon -tuki seuraa yleensä hieman viiveellä. Kolmanneksi, jos tarvitset laajaa mallikirjastoa yhdellä komennolla ilman muunnoksia, Ollaman valmiiksi paketoitu kirjasto on tällä hetkellä laajempi kuin mlx-community-organisaation tarjonta, vaikka ero on kaventunut nopeasti.

Käytännön suositus on yksinkertainen: jos haluat vain kokeilla paikallista kielimallia nopeasti ilman koodaamista, aloita Ollamalla. Jos taas aiot rakentaa oman sovelluksen, hienosäätää mallia omalla datalla tai haluat puristaa viimeisenkin suorituskyvyn irti tuoreesta M5-sirusta, tämän oppaan MLX-polku on parempi valinta pitkällä aikavälillä.

Vaihe 12: Upotukset ja semanttinen haku paikallisesti

Tekstin generoinnin lisäksi MLX-ekosysteemi tukee myös upotusmalleja (embedding models), joita tarvitaan aina kun haluat hakea tekstiä merkityksen, ei pelkän avainsanan perusteella. Upotusmalli muuntaa tekstin numeeriseksi vektoriksi, ja kaksi merkitykseltään samankaltaista tekstiä saa lähekkäin sijaitsevat vektorit, vaikka sanamuoto olisi täysin erilainen. Tämä on tekninen perusta edellisessä osiossa mainitulle RAG-arkkitehtuurille.

from mlx_lm import load
import mlx.core as mx

model, tokenizer = load("mlx-community/bge-small-en-v1.5-mlx")

def upota(teksti):
    tokenit = tokenizer.encode(teksti)
    vektori = model(mx.array([tokenit]))
    return vektori.mean(axis=1)

a = upota("Paikallinen tekoäly säästää sähkölaskua")
b = upota("Kotona ajettava kielimalli on halvempi kuin pilvipalvelu")
samankaltaisuus = (a * b).sum() / (mx.linalg.norm(a) * mx.linalg.norm(b))
print(float(samankaltaisuus))

Esimerkkikoodi laskee kahden lauseen kosinisamankaltaisuuden, joka on yleisin tapa mitata kuinka lähellä toisiaan kaksi upotusvektoria ovat. Arvo lähellä yhtä tarkoittaa lähes samaa merkitystä, arvo lähellä nollaa tarkoittaa, ettei lauseilla ole juuri yhteyttä toisiinsa. Käytännön RAG-sovelluksessa jokainen dokumentin kappale upotetaan tällä tavalla kerran etukäteen ja tallennetaan, minkä jälkeen käyttäjän kysymys upotetaan samalla mallilla ja verrataan tallennettuihin vektoreihin, jolloin löydetään nopeasti kysymyksen kannalta osuvimmat kappaleet ilman koko dokumentin läpikäymistä kielimallilla.

M5, M5 Pro ja M5 Max: mitä eroa on käytännössä

Apple esitteli M5 Pro- ja M5 Max -sirut 3. maaliskuuta 2026, ja yhtiön oman tiedotteen mukaan uusien super-ydinten ansiosta sirut tarjoavat jopa 2,5-kertaisen monisäikeisen suorituskyvyn alkuperäisiin M1 Pro- ja M1 Max -siruihin verrattuna. Tekoälypäättelyn kannalta merkittävämpi yksityiskohta löytyy kuitenkin WWDC 2026 -esityksestä, jossa Apple kertoi M5-sirun neuraaliprosessorien tekevän matriisikertolaskuja nelinkertaisella nopeudella M4-sukupolveen verrattuna. Tämä yksin selittää suuren osan M5-sarjan paremmasta paikallisen tekoälyn suorituskyvystä verrattuna edeltäjäänsä.

Riippumaton vertailu Notebookcheckilta kertoo, että 18-ytiminen M5 Max saavutti Geekbench 6 -testissä 34-45 prosenttia korkeampia tuloksia kuin Intel Core Ultra 9 275HX ja AMD Ryzen AI Max+ 395. Tämä ero näkyy myös paikallisessa tekoälypäättelyssä: mitä nopeampi matriisilaskenta, sitä useampi tokeni sekunnissa käytännön keskustelutilanteessa.

Siru	GPU-ytimet	Yhtenäinen muisti (max)	Muistikaista	Julkaisu
M5	10	32 Gt	~150-200 GB/s	Loka 2025
M5 Pro	16-20	64 Gt	~300-350 GB/s	Maalis 2026
M5 Max	40	128 Gt	~600 GB/s	Maalis 2026

Perus-M5 riittää hyvin pienempiin 1-9 miljardin parametrin malleihin ja satunnaiseen kokeiluun, mutta jos aiot ajaa säännöllisesti 30 miljardin parametrin tai suurempia malleja, M5 Pro tai M5 Max ovat käytännössä ainoat järkevät vaihtoehdot niiden suuremman muistikaistan ja -kapasiteetin ansiosta. Muistikaista, ei pelkkä muistin määrä, on usein todellinen pullonkaula generointinopeudessa, koska jokainen tuotettu tokeni vaatii koko mallin painojen lukemisen muistista uudelleen.

Riippumaton PerformanceTest-mittaus, joka on päivätty 8.-11.9.2026, sijoittaa 18-ytimisen M5 Maxin keskimääräisellä CPU Mark -pistemäärällä 200. sijalle kaikista mitatuista suorittimista ja neljänneksi kaikista kannettavien suorittimista. Samassa mittauksessa M5 Max on kärkisijalla yksisäikeisessä suorituskyvyssä lähes 6000 laitteen joukossa. Yksisäikeinen nopeus vaikuttaa suoraan tiettyihin MLX:n laskentavaiheisiin, joten tämä ei ole pelkkä sivuhuomio, vaan selittää osaltaan miksi M5-sarja pärjää hyvin myös paikallisessa tekoälypäättelyssä eikä vain moniydinvertailuissa.

Käytännön ostopäätöksessä kannattaa huomioida myös se, että M5 Pro ja M5 Max julkaistiin samana päivänä 3. maaliskuuta 2026, joten kumpikaan ei ole selvästi vanhempi tai uudempi malli, vaan kyse on puhtaasti eri kokoluokan tuotteista samassa sukupolvessa. Tämä helpottaa vertailua verrattuna tilanteisiin, joissa eri suorituskykyluokat julkaistaan eri aikoina ja eri arkkitehtuureilla.

MLX vs CUDA: milloin kannattaa valita kumpikin

MLX ja CUDA eivät kilpaile täysin samasta käyttäjästä. CUDA ja Nvidia-näytönohjaimet ovat yhä vahvempi valinta, jos tavoitteena on maksimaalinen raaka tokeninopeus pienillä ja keskikokoisilla malleilla, tai jos työskentelet ympäristössä, joka on jo rakennettu CUDA:n ympärille, kuten useimmat tutkimuslaboratoriot ja pilvipalvelut. MLX taas voittaa tilanteissa, joissa arvostat yksinkertaista asennusta, energiatehokkuutta ja mahdollisuutta ajaa isoja malleja ilman kallista erillistä näytönohjainta, koska yhtenäinen muisti skaalautuu jopa 128 gigatavuun asti samassa laitteessa.

Ominaisuus	MLX (Apple Silicon)	CUDA (Nvidia)
Asennuksen vaativuus	Yksi pip-komento, ei ajureita	Vaatii CUDA Toolkitin ja ajurit
Maksimimuisti mallille	Jopa 128 Gt yhtenäistä muistia	Rajattu näytönohjaimen VRAM:iin (tyyp. 8-24 Gt)
Energiankulutus	Matala, kannettavassa toimii akullakin	Korkeampi, vaatii usein erillisen virtalähteen
Raaka tokeninopeus (8B-malli)	Hyvä, mutta jää RTX 4090:stä	Tyypillisesti nopein pienillä ja keskikokoisilla malleilla
Isot 70B+ mallit ilman ulkoistusta	Onnistuu M5 Max 128 Gt:llä	Vaatii useita näytönohjaimia tai ulkoistusta
Ekosysteemin laajuus	Kasvava, mutta suppeampi kuin CUDA	Laajin tuki lähes kaikille kehyksille

Käytännön nyrkkisääntö on tämä: jos työskentelet mallien kouluttamisen tai suuren mittakaavan tutkimuksen parissa, CUDA-pohjainen ympäristö on yhä turvallisempi valinta laajemman kirjastotuen vuoksi. Jos taas tavoitteena on ajaa valmiiksi koulutettuja malleja paikallisesti omissa sovelluksissa, kannettavassa Macissa tai pöytäkoneessa ilman erillistä näytönohjainta, MLX tarjoaa tällä hetkellä parhaan yhdistelmän helppoutta, energiatehokkuutta ja muistikapasiteettia samassa paketissa.

Yleisimmät sudenkuopat MLX:n käytössä

Seuraavat virheet toistuvat useimmin, kun käyttäjät ottavat MLX:ää käyttöön ensimmäistä kertaa. Suurin osa niistä on helppo välttää, kunhan tietää mistä katsoa. Yhteistä monelle näistä on se, että virheilmoitus itsessään ei kerro suoraan todellista syytä, vaan johtaa etsimään ongelmaa väärästä paikasta, jos ei tiedä etukäteen mitä tarkistaa.

• Väärä Python-arkkitehtuuri. Jos Python on asennettu Rosetta-tilassa (x86_64-emulointina), MLX ei toimi lainkaan tai toimii huomattavasti hitaammin. Tarkista arkkitehtuuri komennolla python3 -c "import platform; print(platform.machine())", jonka pitäisi palauttaa arm64.
• Liian ison mallin lataaminen suoraan. Moni yrittää ladata kvantisoimattoman FP16-mallin suoraan 16 gigatavun koneelle ja ihmettelee, miksi järjestelmä jumiutuu. Aloita aina kvantisoidusta versiosta ja kasvata tarkkuutta vain jos muisti riittää.
• MLX- ja MLX LM -versioiden ristiriita. Koska molemmat paketit kehittyvät nopeasti, vanha MLX LM saattaa olla yhteensopimaton uudemman MLX-ytimen kanssa. Päivitä molemmat samaan aikaan komennolla pip install --upgrade mlx mlx-lm.
• Taustasovellusten unohtaminen muistilaskennassa. Selain kymmenillä välilehdillä ja raskaat kuvankäsittelyohjelmat voivat syödä useita gigatavuja yhtenäisestä muistista, jolloin malli, joka mahtuisi teoriassa muistiin, ei mahdukaan käytännössä.
• Chat-templaten ohittaminen. Instruct-mallien syöttäminen raakatekstinä ilman apply_chat_template-muotoilua johtaa usein epäjohdonmukaisiin tai keskeneräisiin vastauksiin, koska malli ei tunnista kehotteen rakennetta.
• Palvelimen jättäminen avoimeksi ilman rajausta. mlx_lm.server ei sisällä oletuksena todennusta, joten jos avaat portin koko verkolle palomuurin kautta, kuka tahansa samassa verkossa pääsee käyttämään mallia.

Vianmääritys: yleisimmät ongelmat ja ratkaisut

Alla on kerätty yleisimmät ongelmat, joita käyttäjät kohtaavat MLX:n käyttöönotossa, ja niiden ratkaisut.

• “No module named mlx” -virhe asennuksen jälkeen. Tarkista, että virtuaaliympäristö on aktivoituna (source .venv/bin/activate) ennen kuin ajat skriptiä. Asennus toimii vain siinä ympäristössä, johon se tehtiin.
• Malli latautuu mutta generointi on erittäin hidasta. Varmista Aktiviteetin tarkkailu -sovelluksesta, että Python käyttää GPU:ta eikä pelkkää suoritinta. Jos GPU-käyttö pysyy nollassa, MLX ei ole löytänyt Metal-laitetta, mikä viittaa väärään Python-arkkitehtuuriin.
• Muisti loppuu kesken (Out of Memory) ison mallin lataamisessa. Vaihda pienempään kvantisointitasoon (esim. 4-bit 8-bitin sijaan) tai pienempään malliin. Sulje myös raskaat taustasovellukset ennen latausta.
• Hugging Face -lataus katkeaa tai epäonnistuu. Tarkista verkkoyhteys ja kokeile uudelleen; MLX LM jatkaa yleensä keskeytyneen latauksen automaattisesti seuraavalla yrityksellä ilman että koko tiedosto pitää ladata alusta.
• “Unsupported architecture” -virheilmoitus asennuksessa. Tämä tarkoittaa lähes aina Intel-Macia tai Rosetta-tilassa ajettua Pythonia. MLX vaatii aidon arm64-ympäristön eikä toimi Intel-Maceilla lainkaan.
• Palvelin ei vastaa curl-pyyntöihin. Varmista, että portti täsmää komennossa käytettyyn (--port 8080) ja että mikään muu prosessi ei jo käytä samaa porttia komennolla lsof -i :8080.
• Vastaukset ovat epäjohdonmukaisia tai toistavat itseään. Tarkista, että käytät oikeaa chat-templatea apply_chat_template-funktiolla, ja kokeile pienentää temperature-parametria, jos vastaukset rönsyilevät liikaa.
• LoRA-koulutus kaatuu muistin loppumiseen. Pienennä --batch-size-arvoa esimerkiksi kahteen ja kasvata sen sijaan iteraatioiden määrää, jotta koulutus etenee pienemmissä paloissa.
• Mallin lataus onnistuu, mutta se ei löydy komennolla mlx_lm.generate. Tarkista, että malliviite Hugging Face -organisaatiosta on kirjoitettu oikein, esimerkiksi mlx-community/-etuliitteellä, sillä MLX-yhteensopivat mallit on usein julkaistu erillisenä versiona alkuperäisestä.
• Kannettava kuumenee ja hidastuu pitkässä generoinnissa. Tämä on normaalia raskaassa jatkuvassa kuormituksessa. Jos lämpötila haittaa, aja pidemmät eräajot verkkovirtaan kytkettynä ja hyvässä ilmanvaihdossa, sillä akkukäytöllä siru voi rajoittaa tehoa lämmönhallinnan vuoksi.

Jos mikään yllä olevista ei ratkaise ongelmaasi, kannattaa tarkistaa MLX:n GitHub-projektin Issues-osio, jossa yhteisö ja Applen omat kehittäjät vastaavat aktiivisesti ongelmiin. Koska kehys päivittyy usein, osa ongelmista on jo korjattu uudemmassa versiossa, joten pelkkä päivitys pip install --upgrade mlx mlx-lm -komennolla ratkaisee yllättävän monta tapausta ilman muita toimenpiteitä.

Edistyneet vinkit tehokkaampaan käyttöön

Kun perusasennus toimii, seuraavat vinkit auttavat hyödyntämään laitteistoa tehokkaammin ja välttämään yllätyksiä pidemmässä käytössä.

• Käytä mlx_lm.server-palvelinta launchd-taustapalveluna, jos haluat sen käynnistyvän automaattisesti koneen käynnistyessä, samaan tapaan kuin muut taustapalvelut macOS:llä.
• Seuraa muistin huippukäyttöä --verbose-lipulla jokaisessa testiajossa ja pidä siitä kirjaa, jotta tiedät etukäteen, mikä mallikoko mahtuu koneellesi ilman kokeilua.
• Kokeile eri kvantisointitasoja samalle mallille ennen kuin päätät lopullisen: 4-bit säästää muistia, mutta 8-bit voi olla perusteltu, jos käytät mallia tarkkuutta vaativiin tehtäviin kuten koodigenerointiin.
• Jos ajat useita eri projekteja rinnakkain, pidä jokaiselle oma virtuaaliympäristö, jotta MLX- ja MLX LM -versiot eivät ajaudu ristiriitaan projektien välillä.
• Hyödynnä yhtenäistä muistia myös useamman mallin samanaikaiseen lataukseen, esimerkiksi yhden pienemmän mallin nopeisiin tehtäviin ja yhden isomman mallin monimutkaisempaan päättelyyn, jos muistia riittää molemmille.
• Pidä kirjaa siitä, mikä MLX-, MLX LM- ja macOS-versio olivat käytössä silloin kun asennus viimeksi toimi moitteettomasti, jotta pystyt palaamaan tunnettuun toimivaan tilaan nopeasti päivityksen jälkeen.

Nämä vinkit eivät ole pakollisia perusasennuksen kannalta, mutta ne säästävät huomattavasti aikaa pitkällä aikavälillä, erityisesti jos päivität järjestelmääsi säännöllisesti tai kokeilet useita eri malleja ja kvantisointitasoja rinnakkain. Pieni ylimääräinen kirjanpitotyö asennuksen alkuvaiheessa maksaa itsensä takaisin heti ensimmäisen kerran, kun jokin päivitys menee pieleen ja sinun täytyy palauttaa järjestelmä tunnettuun toimivaan tilaan nopeasti.

Yksi vielä harvemmin mainittu vinkki koskee useamman kehotteen käsittelyä kerralla. Jos sovelluksesi tarvitsee käsitellä esimerkiksi satoja lyhyitä tekstinpätkiä samalla mallilla, yksi kehote kerrallaan on tehotonta, koska mallin lataus ja alustus tapahtuu vain kerran, mutta jokainen erillinen generate-kutsu joutuu silti käymään läpi saman käynnistyskustannuksen. Kokoamalla useita kehotteita samaan erään (batch) ja käsittelemällä ne yhdellä kutsulla säästät huomattavasti aikaa suurten tekstimäärien käsittelyssä, kunhan muistat, että eräkoon kasvattaminen kasvattaa myös hetkellistä muistintarvetta samalla tavalla kuin LoRA-koulutuksessa.

Täydellinen esimerkkiprojekti: paikallinen dokumenttihaku

Kootaan lopuksi kaikki opitut palaset yhteen pieneksi, mutta täysin toimivaksi projektiksi: komentorivipohjainen dokumenttihaku, joka lukee paikallisen tekstitiedoston ja vastaa siihen liittyviin kysymyksiin paikallisella mallilla, ilman että mikään data poistuu koneeltasi.

import sys
from pathlib import Path
from mlx_lm import load, generate

MALLI = "mlx-community/Llama-3.1-8B-Instruct-4bit"

def lataa_dokumentti(polku):
    teksti = Path(polku).read_text(encoding="utf-8")
    return teksti[:6000]  # yksinkertainen rajaus kontekstin pituudelle

def kysy(model, tokenizer, dokumentti, kysymys):
    kehote = tokenizer.apply_chat_template(
        [
            {
                "role": "system",
                "content": "Vastaa kysymyksiin vain annetun dokumentin perusteella. "
                            "Jos vastausta ei löydy dokumentista, sano niin suoraan.",
            },
            {
                "role": "user",
                "content": f"Dokumentti:\n{dokumentti}\n\nKysymys: {kysymys}",
            },
        ],
        add_generation_prompt=True,
    )
    return generate(model, tokenizer, prompt=kehote, max_tokens=400)

def main():
    if len(sys.argv) < 2:
        print("Kayttö: python3 dokumenttihaku.py tiedosto.txt")
        sys.exit(1)

    print("Ladataan mallia...")
    model, tokenizer = load(MALLI)
    dokumentti = lataa_dokumentti(sys.argv[1])

    print("Malli valmis. Kirjoita 'lopeta' poistuaksesi.")
    while True:
        kysymys = input("\nKysymys: ")
        if kysymys.strip().lower() == "lopeta":
            break
        vastaus = kysy(model, tokenizer, dokumentti, kysymys)
        print(f"\nVastaus: {vastaus}")

if __name__ == "__main__":
    main()

Tallenna koodi tiedostoon dokumenttihaku.py ja aja se komennolla python3 dokumenttihaku.py oma_dokumentti.txt. Skripti lataa mallin kerran, lukee dokumentin muistiin ja jää sitten odottamaan kysymyksiä, joihin se vastaa vain annetun tekstin perusteella. Koska konteksti on rajattu yksinkertaisesti 6000 merkkiin, pidempien dokumenttien kanssa kannattaa jakaa teksti pienempiin osiin tai käyttää erillistä hakuvaihetta, joka poimii vain kysymyksen kannalta relevantit kappaleet ennen niiden syöttämistä mallille.

Tästä pohjasta on helppo jatkaa moneen suuntaan. Voit korvata input()-kutsun web-palvelimella, jolloin samaa toimintoa voi käyttää selaimen kautta, tai lisätä useamman dokumentin tuen ja yksinkertaisen avainsanahaun, joka valitsee oikean tiedoston kysymyksen perusteella ennen mallin kutsumista. Koko projektin idea, samoin kuin koko tämän oppaan idea, on se, että mikään data ei koskaan poistu koneeltasi prosessin aikana.

Jos haluat viedä projektia pidemmälle, seuraava luonnollinen askel on korvata yksinkertainen merkkirajaus oikealla tekstin pilkkomisella ja hakemisella. Käytännössä tämä tarkoittaa dokumentin jakamista pienempiin kappaleisiin, kunkin kappaleen muuntamista numeeriseksi vektoriksi upotusmallilla (embedding model), ja vain kysymyksen kannalta osuvimpien kappaleiden syöttämistä kielimallille koko dokumentin sijaan. Tätä kutsutaan yleisesti RAG-arkkitehtuuriksi (Retrieval-Augmented Generation), ja MLX-yhteisö tarjoaa Hugging Facessa myös valmiiksi MLX-yhteensopivia upotusmalleja, jotka toimivat saman periaatteen mukaisesti kuin tässä oppaassa käytetty kielimalli.

Pienessä mittakaavassa, esimerkiksi muutaman kymmenen sivun dokumenteille, yksinkertainen merkkirajaus riittää usein hyvin eikä erillistä hakuvaihetta tarvita. Vasta kun dokumentteja on kymmeniä tai sisältö on satoja sivuja, kannattaa investoida aikaa oikeaan hakuratkaisuun, koska muuten kielimallille syötetään joko liikaa epäolennaista tekstiä tai jätetään vahingossa pois juuri se kappale, joka sisältäisi kysymykseen vastauksen.

Usein kysytyt kysymykset

Toimiiko MLX Intel-Maceilla?
Ei. MLX on suunniteltu yksinomaan Apple Siliconin arm64-arkkitehtuurille, ja se vaatii M-sarjan sirun toimiakseen. Intel-Maceille kannattaa etsiä muita paikallisen tekoälyn ratkaisuja, jotka tukevat x86_64-arkkitehtuuria.

Paljonko yhtenäistä muistia tarvitsen 7-9 miljardin parametrin malliin?
4-bittisellä kvantisoinnilla 16 gigatavua riittää useimmiten hyvin, kunhan taustasovellukset eivät vie liikaa muistia samanaikaisesti. 8 gigatavun koneella kannattaa pitäytyä pienemmissä 1-3 miljardin parametrin malleissa.

Onko MLX ilmainen käyttää?
Kyllä, MLX on avoimen lähdekoodin projekti, ja sen käyttö on maksutonta. Ainoa kustannus on itse Mac-laite, jolla sitä ajetaan.

Kannattaako valita M5 vai M5 Pro paikalliseen tekoälyyn?
Jos aiot ajaa pääasiassa 7-9 miljardin parametrin malleja satunnaisesti, perus-M5 riittää hyvin. Jos tavoitteena on ajaa isompia malleja säännöllisesti tai käyttää konetta myös hienosäätöön, M5 Pro tai M5 Max ovat parempi sijoitus niiden suuremman muistikaistan ansiosta.

Voiko MLX-mallia käyttää ilman internetyhteyttä?
Kyllä, kunhan malli on jo ladattu paikalliseen välimuistiin kertaalleen. Itse päättely ei vaadi verkkoyhteyttä lainkaan, mikä on yksi paikallisen ajamisen suurimmista eduista tietosuojan kannalta.

Miten MLX eroaa llama.cpp:stä?
Molemmat mahdollistavat paikallisen päättelyn, mutta MLX on Applen oma kehys, joka on optimoitu erityisesti Apple Siliconin yhtenäiselle muistiarkkitehtuurille, kun taas llama.cpp on alustariippumaton projekti, joka tukee useampaa käyttöjärjestelmää ja laitteistoa. Apple Siliconilla MLX on usein nopeampi juuri tähän laitteistoon räätälöityjen optimointien ansiosta.

Voinko ajaa useampaa mallia samanaikaisesti?
Kyllä, kunhan yhtenäinen muisti riittää molempien mallien painoille ja niiden käyttämälle kontekstille samanaikaisesti. Käytännössä tämä onnistuu parhaiten M5 Pro- ja M5 Max -koneilla niiden suuremman muistikapasiteetin ansiosta.

Miten päivitän MLX:n turvallisesti rikkomatta olemassa olevaa projektia?
Päivitä aina sekä mlx- että mlx-lm-paketit samanaikaisesti komennolla pip install --upgrade mlx mlx-lm, äläkä päivitä vain toista pakettia kerrallaan. Koska projektit kehittyvät nopeasti, kannattaa myös testata olemassa oleva koodi erillisessä virtuaaliympäristössä ennen kuin päivität tuotantokäytössä olevaa asennusta.

Kannattaako MLX:ää käyttää yritysympäristössä, ei vain kotikäytössä?
Kyllä, moni pieni yritys ja freelancer-kehittäjä on jo siirtänyt osan työtehtävistään paikallisille malleille juuri tietosuojasyistä, kunhan tehtävä ei vaadi kaikkein suurimpien pilvimallien tarkkuutta. Suuremmassa mittakaavassa, kymmenien työntekijöiden käyttöön, kannattaa silti tehdä oma laskelma laitteistokustannusten ja pilvipalvelun kuukausimaksujen välillä ennen päätöstä, koska tarvittavien Mac-koneiden hankintahinta voi nousta nopeasti korkeaksi, jos jokainen työntekijä tarvitsee oman M5 Max -tason koneen.