Nvidia julkaisi syyskuussa 2026 CUDA Toolkit 13.4:n, ja ensimmäistä kertaa CUDA-kehitys toimii natiivisti Windows on Arm -koneilla. Aiemmin CUDA tuki Arm-suoritinta vain Linuxin kautta, joten x86-64 oli Windows-kehittäjille ainoa reitti Nvidia-GPU:iden hyödyntämiseen. Uusi tuki on suunnattu erityisesti Nvidian N1X-läppäriekosysteemille, joka yhdistää Arm-suorittimen ja Nvidia-grafiikan samaan piiriin kannettavissa tietokoneissa.

Tässä oppaassa käydään läpi koko prosessi: laitteiston tarkistuksesta ajurin ja Toolkitin asennukseen, ensimmäisen CUDA-ohjelman kääntämiseen ja jaetun GPU:n hallintaan Multi-Process Service V3:lla. Mukana on 12 vaihetta, valmis esimerkkiprojekti ja lista yleisimmistä virheistä, joihin kehittäjät ovat törmänneet CUDA 13.4:n julkaisun jälkeen. Aikaa koko läpikäyntiin kuluu noin 90 minuuttia riippuen verkkoyhteyden nopeudesta ja siitä, kuinka moneen esimerkkiin haluat tutustua.

Opas on kirjoitettu suomalaiselle ja pohjoismaiselle kehittäjälle, joka harkitsee Windows on Arm -kannettavaa joko työkoneeksi tai kokeiluympäristöksi. Sama pätee opiskelijaan, joka rakentaa ensimmäistä GPU-kiihdytettyä projektiaan eikä halua sijoittaa tuhansia euroja pöytäkoneen näytönohjaimeen. Käydään läpi sekä tilanne, jossa laite on jo pöydällä, että tilanne, jossa kehität toistaiseksi tavallisella x86-64-kannettavalla ja siirrät valmiin sovelluksen Arm-laitteelle vasta myöhemmin.

Kirjoitimme oppaan siksi, että suomenkielistä, käytännönläheistä materiaalia CUDA 13.4:n Windows on Arm -tuesta ei ole vielä juuri saatavilla. Suurin osa julkaisuun liittyvästä keskustelusta käydään englanniksi Nvidian omilla foorumeilla ja kansainvälisillä teknologiasivustoilla, jotka eivät välttämättä huomioi pohjoismaista laitteistotarjontaa tai hintatasoa. Tämä opas täyttää sen aukon konkreettisilla, itse testattavissa olevilla komennoilla.

Miksi CUDA Windows on Arm -tuki kiinnostaa juuri nyt

Ajoitus ei ole sattumaa. Nvidian RTX 5090 maksoi lanseeraushinnaltaan 1 999 dollaria, mutta GDDR7-muistin niukkuus on nostanut jälleenmyyntihintoja rajusti vuoden 2026 aikana. Techguided.comin heinäkuun 2026 tietojen mukaan RTX 5090 maksoi tuolloin Amazonissa 4 329 dollaria, ja osa korttivalmistajien versioista ylitti 5 000 dollaria. Kun pöytäkoneen huippu-GPU on tässä hintaluokassa, moni kehittäjä ja opiskelija etsii vaihtoehtoja, jotka eivät vaadi erillistä näytönohjainta.

Windows on Arm -kannettavat, joissa on integroitu Nvidia-grafiikka, tarjoavat juuri tällaisen vaihtoehdon. Ongelmana on tähän asti ollut se, ettei CUDA-työkaluketju ole tukenut näitä laitteita suoraan Windowsissa. CUDA 13.4 korjaa tämän aukon, ja samalla se tuo mukanaan esikatselutuen tulevalle Rubin-arkkitehtuurille (laskentakyky 107) sekä uudistetun Multi-Process Service -version, joka helpottaa yhden GPU:n jakamista usean prosessin kesken. Yhdessä nämä kolme muutosta tekevät syksystä 2026 luontevan ajankohdan päivittää kehitysympäristö.

Kyseessä on kuitenkin kehittäjäesikatselu. Nvidia on itse todennut, ettei CUDA 13.4:ää pidä käyttää tuotantojärjestelmissä, sertifioinnissa, vertailutestauksessa tai liiketoimintakriittisissä ympäristöissä. Tämä opas sopii siis kehitys- ja testiympäristöön, ei vielä tuotantopalvelimelle.

Taustalla vaikuttaa laajempi muistikriisi, joka on koskenut koko PC-alaa vuonna 2026. DDR5-muistin hinnat ovat nousseet jyrkästi, ja useat valmistajat ovat joutuneet nostamaan kannettavien hintoja tästä syystä. Sama GDDR7- ja HBM-muistin niukkuus, joka ajoi RTX 5090:n hinnan pilviin, on nostanut myös tavallisten kannettavien komponenttikustannuksia. Tässä tilanteessa integroitu Arm-plus-Nvidia-ratkaisu, jossa GPU-muisti on osa samaa piiripakettia, voi osoittautua kustannustehokkaammaksi tavaksi hankkia GPU-kiihdytettyä laskentatehoa kuin erillisen näytönohjaimen ostaminen.

Mitä CUDA 13.4 tuo tullessaan

Nvidian kehittäjäblogin mukaan CUDA 13.4 ei ole pelkkä Arm-lisäys, vaan koko joukko päivityksiä ydinkirjastoihin. Multi-Process Service V3 (MPS V3) tuo skriptattavan komentorivin, nimetyt palvelininstanssit, TOML-muotoisen konfiguroinnin ja cgroup-integroidut muistirajat GPU-osioinnille. Tämä on erityisen hyödyllistä konttiympäristöissä, joissa useampi työkuorma jakaa saman fyysisen GPU:n.

CUDA Compute Fabric Transport (CFT) puolestaan tarjoaa uuden tavan siirtää dataa NVLink-kudoksen yli nimettyjen loogisten päätepisteiden kautta, mikä vähentää virtuaaliosoitepainetta suurissa monen GPU:n järjestelmissä. Sen sijaan, että jokainen etä-GPU:n muistivaraus kartoitettaisiin prosessin omaan virtuaaliosoiteavaruuteen, ohjelmisto voi kohdistaa toiminnot nimettyihin loogisiin päätepisteisiin ja käynnistää asynkronisia put-, get- ja reduktio-operaatioita suoraan GPU:lta. Tämä on suunnattu ensisijaisesti viestintäkirjastojen kehittäjille, ei tavallisille sovelluskehittäjille, mutta se kertoo suunnasta, johon Nvidia vie koko CUDA-alustaa: yhä suurempien, yhä useamman GPU:n järjestelmien hallintaan.

Python-puolella cuda.core nousee versioon 1.1.0 ja tuo mukanaan teksturointi- ja pintaohjelmoinnin, NUMA-tietoisen hallitun muistin sekä täydelliset tyyppitiedot kehitystyökaluille. CCCL 3.4 taas nostaa DeviceScan-suorituskykyä Blackwell-GPU:illa jopa 92 prosentin muistikaistan käyttöasteeseen, kun aiempi toteutus ylsi noin 50 prosenttiin. Lisäksi CUDA 13.4 tuo ohjelmoitavan pääsyn lokaalisuusalueisiin (locality domain): GPU:n osaan, joka sisältää tietyt suoritinytimet ja muistin. Kun laskenta ja sen tarvitsema muisti sijoitetaan samaan lokaalisuusalueeseen, data ei joudu matkustamaan yhtä pitkää matkaa piirin sisällä, mikä näkyy suoraan pienempänä viiveenä.

Isoin muutos tämän oppaan kannalta on silti yksinkertainen: Nvidia mainitsee ydinmatematiikkakirjastojen saavan toiminnallisen tuen Windows on Arm -ympäristölle nimenomaan N1X-läppäriekosysteemiä varten. N1X on Nvidian Arm-pohjainen alusta, joka on rakennettu yhdessä MediaTekin kanssa ja joka tähtää Windows on Arm -tekoälykannettaviin. Käytännössä tämä tarkoittaa, että sama CUDA-koodi, joka on aiemmin pyörinyt vain x86-64-koneilla tai Linux-Arm-palvelimilla, voidaan nyt kääntää ja ajaa myös näillä uusilla Arm-kannettavilla.

Julkaisu tuo mukanaan myös Nsight Python 1.0:n, joka automatisoi ydinsuorituskyvyn analysoinnin usealla eri kernel-konfiguraatiolla kerralla. Yksi dekoraattori ja yksi kontekstinhallintaolio riittävät benchmarkkauksen, arkkitehtuurikohtaisten mittareiden keräämisen ja suorituskykykuvaajien tuottamiseen ilman erillistä raportin jäsentämistä käsin. Tämä säästää aikaa varsinkin silloin, kun testaat samaa koodia sekä x86-64- että Arm64-koneella ja haluat verrata tuloksia luotettavasti.

Kokonaisuutena CUDA 13.4 on siis päivitys, joka palvelee kolmea eri yleisöä yhtä aikaa: Windows on Arm -kehittäjiä, jotka saavat pääsyn CUDA:aan ensimmäistä kertaa, suurten GPU-klustereiden ylläpitäjiä, jotka hyötyvät MPS V3:sta ja CFT:stä, ja Rubin-arkkitehtuuriin varautuvia kehittäjiä, jotka haluavat aloittaa siirtymän etukäteen. Tämä opas keskittyy ensimmäiseen ryhmään, mutta samat asennusperiaatteet pätevät riippumatta siitä, mihin näistä kolmesta ryhmästä kuulut.

Esitiedot ja järjestelmävaatimukset

Ennen kuin aloitat, varmista että sinulla on seuraavat asiat kunnossa. Osa vaatimuksista on Nvidian omasta asennusoppaasta, osa yleisiä käytännön suosituksia, jotka nopeuttavat asennusta. Suosittelemme käymään koko listan läpi ennen ensimmäistäkään latausta, sillä esimerkiksi puuttuva Visual Studio -komponentti huomataan usein vasta puolessa välissä asennusta, jolloin joudut palaamaan taaksepäin ja lataamaan lisää työkaluja kesken prosessin.

Laitteistovaatimukset

  • Arm64-suoritin, jossa on Windows on Arm -yhteensopiva Nvidia-grafiikka (esimerkiksi N1X-pohjainen kannettava)
  • Vähintään 16 Gt keskusmuistia sujuvaan kääntämiseen ja profilointiin
  • Vapaata levytilaa noin 8 Gt: CUDA Toolkit, ajurit ja esimerkkiprojektit vievät tilaa
  • Internet-yhteys asennuspakettien lataamiseen (Toolkitin asennuspaketti on useita gigatavuja)

Ohjelmistovaatimukset

  • Windows 11 Arm64, mielellään uusin saatavilla oleva päivitys
  • CUDA Toolkit 13.4 tai uudempi, Arm64-asennuspaketti
  • Nvidian uusin Windows on Arm -ajuri, ladattuna erikseen osoitteesta nvidia.com/drivers (Toolkit ei enää sisällä ajuria CUDA 13.1:stä lähtien)
  • Visual Studio 2022 Arm64-työkaluilla, jos aiot kääntää natiivisti laitteella
  • Python 3.10 tai uudempi, jos aiot käyttää cuda.core-kirjastoa
  • GCC 16 tai Clang 22, jos työskentelet ristiinkäännösympäristössä muulla alustalla
KomponenttiVähimmäisversioHuomio
KäyttöjärjestelmäWindows 11 Arm64Uusin päivitys suositeltu
CUDA Toolkit13.4 (kehittäjäesikatselu)Ei tuotantokäyttöön
Nvidia-ajuriUusin Windows on Arm -ajuriLadataan erikseen toolkitista
Visual Studio2022, Arm64-työkalutNatiiviin kääntämiseen
Python3.10+cuda.core 1.1.0 -kirjastolle
Host-kääntäjä (ristiinkäännös)GCC 16 / Clang 22Tuettu CUDA 13.4:ssä

Versionumerot kannattaa ottaa vakavasti. CUDA-työkaluketju on herkkä yhteensopivuusongelmille, ja liian vanha Visual Studio tai väärä Python-arkkitehtuuri (x86-64 Arm64-koneella) on yleisin syy siihen, että asennus näyttää onnistuneen mutta mikään ei oikeasti toimi. Jos et ole varma, mikä versio sinulla on käytössä, tarkista se ennen kuin etenet seuraavaan vaiheeseen. Tämä säästää turhaa selvittelyä myöhemmin.

Vaihe 1–3: laitteiston tarkistus, ajuri ja Toolkitin lataus

Ennen kuin lataat mitään, päätä kumpaa reittiä kuljet: onko sinulla jo fyysinen Windows on Arm -kannettava käsillä, vai kehitätkö toistaiseksi x86-64-koneella ja siirrät sovelluksen kohdelaitteelle vasta myöhemmin (katso vaihe 8). Molemmat reitit vaativat saman Toolkit-asennuksen, mutta ensimmäinen etenee suoraviivaisesti kolmen ensimmäisen vaiheen läpi, kun taas jälkimmäinen vaatii lisäksi ristiinkäännöstyökalut.

Vaihe 1: Tarkista laitteistosi yhteensopivuus. Avaa PowerShell ja tarkista ensin suoritinarkkitehtuuri ja käyttöjärjestelmän build-numero. Tämä varmistaa, että olet oikeasti Arm64-Windows-koneella eikä x86-64-emulointikerroksen takana.

Get-ComputerInfo | Select-Object OsArchitecture, WindowsProductName, OsBuildNumber
systeminfo | findstr /B /C:"System Type"

Jos tulos näyttää “ARM64-based PC”, olet oikealla alustalla. Varmista lisäksi Laitehallinnasta, että näytönohjaimesi näkyy Nvidia-nimikkeellä eikä geneerisenä Microsoft Basic Display -sovittimena, joka viittaisi puuttuvaan ajuriin. Jos suoritin tunnistuu x86-64:ksi vaikka ostit Arm-koneen, olet todennäköisesti kirjautunut sisään virtuaalikoneeseen tai etätyöpöytäistuntoon, joka emuloi eri arkkitehtuuria kuin fyysinen laite.

Vaihe 2: Asenna Nvidia-ajuri erikseen. CUDA 13.1:stä lähtien Windows-asennuspaketit eivät enää sisällä näytönohjainajuria, joten se pitää hakea erikseen osoitteesta nvidia.com/drivers. Valitse laitteesi mallin ja Windows on Arm -alustan mukainen ajuri, lataa se ja asenna ennen Toolkitin asennusta.

Vaihe 3: Lataa CUDA Toolkit 13.4 Arm64-paketti. Mene Nvidia Developerin lataussivulle ja valitse käyttöjärjestelmäksi Windows, arkkitehtuuriksi Arm64. Lataa joko verkkoasennin (kevyempi, lataa osat asennuksen aikana) tai koko paketin sisältävä asennin, jos aiot asentaa useamman koneen ilman verkkoyhteyttä. Molemmat asentimet sisältävät saman komponenttivalikoiman, joten valinta riippuu lähinnä verkkoyhteytesi nopeudesta ja siitä, kuinka moneen koneeseen asennat.

# PowerShellissä voit tarkistaa ladatun tiedoston eheyden ennen asennusta
Get-FileHash .\cuda_13.4_windows_arm64.exe -Algorithm SHA256

Vaihe 4–6: asennus, ympäristömuuttujat ja varmistus

Tässä vaiheessa itse asennuspaketti on jo levyllä ja ajuri asennettuna. Seuraavat kolme vaihetta muuttavat ladatun asennuspaketin toimivaksi kehitysympäristöksi, jossa komentorivityökalut löytyvät automaattisesti riippumatta siitä, mistä kansiosta avaat terminaalin.

Vaihe 4: Suorita asennus. Käynnistä ladattu asennuspaketti järjestelmänvalvojan oikeuksilla. Valitse mukautettu asennus, jos haluat jättää pois komponentteja kuten Nsight-visualisoinnin tai näytesovellukset levytilan säästämiseksi. Automatisoituun asennukseen, esimerkiksi useamman kehityskoneen käyttöönottoon, voit ajaa asentimen hiljaisessa tilassa. Tämä on hyödyllistä esimerkiksi silloin, kun tiimissä on useampi kehittäjä ja haluat varmistaa, että jokaisella koneella on identtinen komponenttivalikoima.

.\cuda_13.4_windows_arm64.exe -s nvcc_13.4 cudart_13.4 nsight_compute_13.4

Vaihe 5: Aseta ympäristömuuttujat. Asennin lisää yleensä CUDA_PATH-muuttujan automaattisesti, mutta kannattaa tarkistaa se ja lisätä binäärihakemisto PATH-muuttujaan, jotta nvcc toimii mistä tahansa komentorivi-ikkunasta.

[Environment]::GetEnvironmentVariable("CUDA_PATH", "Machine")
$env:Path += ";$env:CUDA_PATH\bin"
setx PATH "$env:Path" /M

Vaihe 6: Varmista asennus. Avaa uusi PowerShell-ikkuna, jotta muuttujat latautuvat, ja aja seuraavat komennot.

nvcc -V
nvidia-smi

Onnistuneen asennuksen jälkeen nvcc -V tulostaa version 13.4 ja kääntäjän build-tunnisteen, ja nvidia-smi näyttää asennetun GPU:n nimen, ajuriversion sekä käytössä olevan muistin määrän. Jos jompikumpi komento ei löydy, palaa vaiheeseen 5 ja tarkista PATH-muuttuja uudelleen. Kannattaa myös kirjata ylös tässä vaiheessa näkyvä ajuriversio ja Toolkitin build-numero, sillä niitä tarvitaan myöhemmin, jos joudut avaamaan tukipyynnön Nvidian kehittäjäfoorumille.

Vaihe 7: ensimmäinen natiivi Arm64-CUDA-ohjelma

Nyt kun työkaluketju on pystyssä, kirjoita yksinkertainen CUDA-ohjelma, joka laskee kahden taulukon summan GPU:lla. Tämä on klassinen tapa varmistaa, että kääntäjä, ajuri ja laitteisto toimivat yhdessä. Ohjelma varaa muistia sekä isäntäkoneelta (CPU) että laitteelta (GPU), kopioi syötteen laitteelle, käynnistää rinnakkaisen kernel-funktion ja kopioi tuloksen takaisin. Sama rakenne toistuu käytännössä jokaisessa CUDA-ohjelmassa monimutkaisuudesta riippumatta.

Kolmoisnuolisyntaksi <<<blocks, threads>>> on CUDA-C++:n oma laajennus, joka kertoo kääntäjälle, kuinka monta rinnakkaista säiettä kernel käynnistää ja miten ne ryhmitellään lohkoiksi. Tämä syntaksi ei muutu arkkitehtuurin mukaan: sama koodi kääntyy identtisesti sekä x86-64- että Arm64-isäntäkoneella, koska kolmoisnuolet käsittelee nvcc-kääntäjän etuosa, ei kohdearkkitehtuurista riippuva takaosa.

// vector_add.cu
#include <stdio.h>

__global__ void vectorAdd(const float *a, const float *b, float *c, int n) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    if (i < n) c[i] = a[i] + b[i];
}

int main() {
    const int n = 1 << 20;
    size_t bytes = n * sizeof(float);
    float *h_a, *h_b, *h_c, *d_a, *d_b, *d_c;

    h_a = (float*)malloc(bytes);
    h_b = (float*)malloc(bytes);
    h_c = (float*)malloc(bytes);
    for (int i = 0; i < n; i++) { h_a[i] = 1.0f; h_b[i] = 2.0f; }

    cudaMalloc(&d_a, bytes);
    cudaMalloc(&d_b, bytes);
    cudaMalloc(&d_c, bytes);
    cudaMemcpy(d_a, h_a, bytes, cudaMemcpyHostToDevice);
    cudaMemcpy(d_b, h_b, bytes, cudaMemcpyHostToDevice);

    int threads = 256;
    int blocks = (n + threads - 1) / threads;
    vectorAdd<<<blocks, threads>>>(d_a, d_b, d_c, n);

    cudaMemcpy(h_c, d_c, bytes, cudaMemcpyDeviceToHost);
    printf("c[0] = %f (odotettu 3.0)\n", h_c[0]);

    cudaFree(d_a); cudaFree(d_b); cudaFree(d_c);
    free(h_a); free(h_b); free(h_c);
    return 0;
}

Käännä ohjelma natiivisti Arm64-koneella seuraavalla komennolla ja aja se heti perään.

nvcc vector_add.cu -o vector_add.exe
.\vector_add.exe

Tulosteen pitäisi näyttää tältä:

c[0] = 3.000000 (odotettu 3.0)

Jos tuloste täsmää, GPU on suorittanut laskennan oikein eikä pelkästään palauttanut alustamatonta muistia. Jos sen sijaan näet nollia tai satunnaisia lukuja, tarkista ensin, että cudaMemcpy-kutsujen suunta (HostToDevice vai DeviceToHost) on oikein päin kummassakin kopioinnissa, sillä väärä suunta on yleisin syy tähän virheeseen aloittelevilla CUDA-kehittäjillä.

Vaihe 8: ristiinkäännös x86-64-koneelta Arm64-kohteeseen

Kaikilla ei ole vielä Arm64-Windows-konetta käsillä, mutta CUDA 13.4 tukee myös ristiinkäännöstä: sovellus rakennetaan tavallisella x86-64-Windows-koneella ja käännetty binaari siirretään ajettavaksi Arm64-laitteelle. Tämä on käytännöllinen tapa kehittää, kun kehityskone ja kohdelaite ovat eri arkkitehtuurissa. Moni tiimi jatkaa tätä reittiä pidempäänkin, koska rakennuspalvelimet ja CI-putket ovat yhä pääosin x86-64-arkkitehtuurissa, eikä niitä kannata vaihtaa vain yhden kohdealustan takia.

Asenna x86-64-koneelle CUDA Toolkitin ristiinkäännöstyökalut ja Visual Studion Arm64-kohdetyökalut. Käännä sitten sama lähdekooditiedosto kohdearkkitehtuuria varten.

# x86-64-koneella, kohteena Arm64-Windows
nvcc vector_add.cu -o vector_add_arm64.exe -ccbin "cl_arm64" --target-cpu-arch=ARM64

Siirrä syntynyt .exe-tiedosto Arm64-koneelle esimerkiksi verkkolevyn tai USB-muistin kautta ja aja se siellä normaalisti. Jos näet virheilmoituksen puuttuvasta cl_arm64-kääntäjästä, avaa Visual Studio Installer ja lisää “MSVC v143 – VS 2022 C++ Arm64 build tools” -komponentti. Testaa ristiinkäännetty binaari aina oikealla kohdelaitteella ennen kuin luotat siihen tuotannossa tai jaat sen kollegoille, sillä pelkkä onnistunut käännös ei takaa, että ohjelma toimii kohdelaitteen ajuriversion kanssa.

Vaihe 9: jaetun GPU:n hallinta Multi-Process Service V3:lla

Yksi CUDA 13.4:n merkittävimmistä lisäyksistä on MPS V3, joka antaa hienojakoisemman hallinnan siihen, miten useampi prosessi jakaa saman GPU:n. Tämä on hyödyllistä esimerkiksi silloin, kun samalla N1X-läppärillä ajetaan useampi pieni tekoälytyökuorma samanaikaisesti eikä yksikään saa varata koko GPU:ta itselleen. Kuvittele tilanne, jossa taustalla pyörii jatkuva inferenssi-palvelu ja samaan aikaan haluat testata uutta mallia: ilman GPU-osiointia uusi testi voi hidastaa tai kaataa tuotantopalvelun kokonaan.

Käynnistä MPS-ohjauspalvelin ja luo nimetty palvelininstanssi skriptattavalla komentorivillä.

nvidia-cuda-mps-control -d
nvidia-cuda-mps-control server create --name tyokuorma-1
nvidia-cuda-mps-control server set-memory-limit --name tyokuorma-1 --limit 4096MiB

Voit myös kirjoittaa asetukset TOML-tiedostoon, jolloin konfiguraatio on helppo versioida ja jakaa tiimin kesken.

# mps-config.toml
[server.tyokuorma-1]
memory_limit_mib = 4096
sm_partition_percent = 50
priority = "normal"

Cgroup-integroidut muistirajat tarkoittavat, että kunkin prosessin GPU-muistin ja laskentatehon käyttö rajataan käyttöjärjestelmätasolla, ei vain sovelluksen omalla logiikalla. Tämä estää yhtä hallitsematonta prosessia viemästä koko GPU:n resursseja muilta.

Voit seurata palvelininstanssien tilaa reaaliajassa ja tarkistaa, pitävätkö asetetut rajat todella paikkansa käytännön kuormituksessa.

nvidia-cuda-mps-control server list
nvidia-cuda-mps-control server get-memory-usage --name tyokuorma-1

Jos huomaat, että yksi palvelininstanssi ylittää asetetun muistirajan silti, tarkista ensin TOML-tiedoston syntaksi ja se, että ohjauspalvelin on käynnistetty uudelleen konfiguraation muuttamisen jälkeen. MPS V3 ei lue TOML-asetuksia automaattisesti uudelleen käynnissä olevaan istuntoon, vaan vaatii palvelininstanssin uudelleenluonnin.

Vaihe 10: Python-tuki cuda.core 1.1.0:lla

Moni tekoälykehittäjä työskentelee Pythonilla C++:n sijaan. CUDA 13.4:n mukana tullut cuda.core 1.1.0 laajentaa Pythonista käytettävää CUDA-rajapintaa NUMA-tietoisella hallitulla muistilla ja täydellisillä tyyppitiedoilla, jotka helpottavat koodieditorien autotäydennystä. Tämä on erityisen tervetullut lisäys Windows on Arm -kehittäjille, koska aiemmin Python-pohjainen CUDA-kehitys vaati käytännössä aina x86-64-konetta tai Linux-Arm-palvelinta.

pip install cuda-core==1.1.0
python -c "from cuda.core import Device; print(Device().name)"

Jälkimmäinen komento tulostaa asennetun GPU:n nimen, jos Python löytää CUDA-ajonaikaisen ympäristön oikein. Jos komento heittää ImportError-virheen, tarkista että käytät Arm64-versiota Pythonista äläkä x86-64-versiota, joka on saatettu asentaa vahingossa emulointikerroksen kautta.

Seuraava esimerkki näyttää, miten hallittua muistia voi konfiguroida ja siirtää GPU:lle etukäteishakua (prefetch) käyttäen.

from cuda.core import Device, Host, ManagedMemoryResource
from cuda.core.utils import prefetch_batch

dev = Device()
stream = dev.create_stream()
mr = ManagedMemoryResource()

weights = mr.allocate(weights_nbytes, stream=stream)
output = mr.allocate(output_nbytes, stream=stream)

weights.read_mostly = True
weights.preferred_location = dev
weights.accessed_by.add(dev)

prefetch_batch(stream, [weights, output], dev)
# Suorita GPU-työ, siirrä lopuksi tulos isäntämuistiin
output.prefetch(Host(), stream=stream)

Huomaa, että read_mostly-lippu kertoo ajonaikaiselle järjestelmälle, että dataa luetaan paljon mutta muokataan harvoin, mikä auttaa CUDA:aa optimoimaan sivujen sijoittelun muistissa. Tämä on erityisen hyödyllistä koneoppimismalleissa, joissa painot (weights) pysyvät muuttumattomina inferenssin ajan mutta niitä luetaan miljoonia kertoja sekunnissa.

Vaihe 11–12: profilointi Nsightilla ja koko projektin kokoaminen

Profilointi

Vaihe 11: Profiloi suoritus. Nsight Systems 2026.5.1 tukee CUDA 13.4:ää, Rubin-arkkitehtuurin esikatselua ja Windows on Armia. Profilointi kannattaa ajaa aina ennen optimointia, jotta tiedät mihin aika oikeasti kuluu.

nsys profile --output=vector_add_report .\vector_add.exe
nsys stats vector_add_report.nsys-rep

Raportti näyttää muun muassa kernelin suoritusajan, muistinsiirtojen keston ja GPU:n käyttöasteen aikajanalla. Jos suurin osa ajasta kuluu cudaMemcpy-kutsuihin laskennan sijaan, kannattaa harkita datan pitämistä GPU:lla pidempään tai suurempien erien käsittelyä kerralla. Tyypillinen aloittelijan virhe on kopioida dataa edestakaisin isäntäkoneen ja GPU:n välillä jokaisen pienen laskutoimituksen jälkeen, mikä syö suurimman osan hyödystä, jonka GPU-kiihdytys muuten toisi.

Koko projekti: matriisikertolasku päästä päähän

Vaihe 12: Kokoa valmis projekti. Seuraavassa on täydellinen, ajettava esimerkki, joka kertoo kaksi matriisia keskenään GPU:lla ja tarkistaa tuloksen CPU:lla laskettua verrokkia vasten. Tallenna se tiedostoon matrix_mul.cu. Matriisikertolasku valittiin esimerkiksi siksi, että se on yksinkertainen mutta silti aidosti laskentaintensiivinen tehtävä: samaa perusrakennetta käytetään neuroverkkojen kerrosten laskennassa, kuvankäsittelyssä ja tieteellisessä laskennassa, joten harjoitus ei ole vain teoreettinen vaan siirtyy suoraan todellisiin käyttötapauksiin.

// matrix_mul.cu
#include <stdio.h>
#include <stdlib.h>

#define N 512

__global__ void matMul(const float *a, const float *b, float *c, int n) {
    int row = blockIdx.y * blockDim.y + threadIdx.y;
    int col = blockIdx.x * blockDim.x + threadIdx.x;
    if (row < n && col < n) {
        float sum = 0.0f;
        for (int k = 0; k < n; k++) sum += a[row * n + k] * b[k * n + col];
        c[row * n + col] = sum;
    }
}

int main() {
    size_t bytes = N * N * sizeof(float);
    float *h_a, *h_b, *h_c, *d_a, *d_b, *d_c;

    h_a = (float*)malloc(bytes);
    h_b = (float*)malloc(bytes);
    h_c = (float*)malloc(bytes);
    for (int i = 0; i < N * N; i++) { h_a[i] = 1.0f; h_b[i] = 1.0f; }

    cudaMalloc(&d_a, bytes);
    cudaMalloc(&d_b, bytes);
    cudaMalloc(&d_c, bytes);
    cudaMemcpy(d_a, h_a, bytes, cudaMemcpyHostToDevice);
    cudaMemcpy(d_b, h_b, bytes, cudaMemcpyHostToDevice);

    dim3 threads(16, 16);
    dim3 blocks(N / threads.x, N / threads.y);
    matMul<<<blocks, threads>>>(d_a, d_b, d_c, N);

    cudaMemcpy(h_c, d_c, bytes, cudaMemcpyDeviceToHost);
    printf("c[0][0] = %f (odotettu %d.0)\n", h_c[0], N);

    cudaFree(d_a); cudaFree(d_b); cudaFree(d_c);
    free(h_a); free(h_b); free(h_c);
    return 0;
}

Käännä ja aja projekti natiivisti Arm64-koneella:

nvcc matrix_mul.cu -o matrix_mul.exe -O3
.\matrix_mul.exe

Odotettu tuloste 512×512-matriisille, jossa kaikki alkiot ovat ykkösiä, on c[0][0] = 512.000000. Jos saat tämän tuloksen, koko työkaluketju laitteistosta ajuriin ja kääntäjään toimii oikein. Tämä pieni projekti on tarkoituksella yksinkertainen, mutta samaa rakennetta (muistin varaus, kopiointi laitteelle, kernel-käynnistys, kopiointi takaisin) käytetään myös huomattavasti isommissa sovelluksissa kuten neuroverkkojen inferenssissä tai kuvankäsittelyputkissa. Kun tämä perusesimerkki toimii luotettavasti sekä natiivisti käännettynä että ristiinkäännettynä, sinulla on vankka pohja laajentaa projektia todellisiin työkuormiin.

Yleisimmät sudenkuopat

Näihin kuuteen virheeseen kehittäjät ovat törmänneet yleisimmin CUDA 13.4:n Windows on Arm -käyttöönotossa. Suurin osa niistä johtuu siitä, että totutut x86-64-työtavat eivät sellaisenaan päde uudella alustalla.

  • Ajurin ja Toolkitin asennusjärjestys väärin päin. Koska ajuri ei enää tule Toolkitin mukana, monet asentavat ensin Toolkitin ja ihmettelevät, miksi nvidia-smi ei löydä laitetta. Korjaa asentamalla aina ajuri ensin ja Toolkit vasta sen jälkeen.
  • Emulointikerroksen huomaamaton käyttö. Jos ohjelma näyttää kääntyvän mutta ajaa hitaasti, tarkista ettei Windows suorita binääriä x86-emulaation kautta natiivin Arm64-ajon sijaan. Task Managerin Tiedot-välilehti näyttää prosessin arkkitehtuurin.
  • Puuttuvat Arm64-työkalut Visual Studiossa. Oletusasennus ei sisällä Arm64-kohdetyökaluja, ne pitää lisätä erikseen Visual Studio Installerista Yksittäiset komponentit -välilehdeltä.
  • Sekaannus PATH-muuttujien kanssa moniversioympäristössä. Jos koneella on sekä x86-64- että Arm64-CUDA-asennuksia, väärä PATH-järjestys johtaa siihen, että nvcc kutsuu väärää kääntäjäversiota. Tarkista PATH-muuttujan järjestys komennolla $env:Path -split “;”.
  • Kehittäjäesikatselun käyttö tuotannossa. Koska CUDA 13.4 on esikatseluversio, sen käyttö tuotantopalvelimella tai asiakkaalle toimitettavassa sovelluksessa ei ole Nvidian suosittelemaa ennen vakaata julkaisua.
  • Vanhan dokumentaation seuraaminen. Suuri osa verkosta löytyvistä CUDA-oppaista käsittelee vain x86-64-Windowsia tai Linux-Armia. Varmista aina, että käyttämäsi ohje mainitsee nimenomaan Windows on Arm -tuen, ennen kuin luotat sen komentoihin sellaisenaan.

Yhteinen nimittäjä näissä virheissä on kiire: asennus näyttää suoraviivaiselta, ja moni ohittaa versiotarkistukset olettaen, että uusin ladattu paketti on automaattisesti oikea. Muutaman minuutin käyttö vaiheiden 1–6 tarkistuksiin säästää tyypillisesti tunteja myöhemmässä vianmäärityksessä.

Vianmääritys: yleisimmät virheet ja korjaukset

Alla oleva taulukko kokoaa kymmenen yleisintä ongelmaa, joihin törmäät todennäköisimmin asennuksen ja ensimmäisten testien aikana. Käy ne läpi järjestyksessä ylhäältä alas, sillä monet myöhemmät ongelmat ovat seurausta ensimmäisistä vaiheista.

OngelmaTodennäköinen syyKorjaus
nvcc: command not foundPATH-muuttuja ei sisällä CUDA-binäärihakemistoaLisää $env:CUDA_PATH\bin PATH-muuttujaan ja avaa uusi terminaali
nvidia-smi ei löydä laitettaAjuri asennettu vasta Toolkitin jälkeen tai puuttuu kokonaanAsenna uusin Windows on Arm -ajuri nvidia.com/drivers-sivulta ja käynnistä kone uudelleen
Käännösvirhe: unsupported host compilerVisual Studiosta puuttuu Arm64-kohdetyökalutLisää MSVC v143 Arm64 build tools Visual Studio Installerista
Ohjelma kaatuu heti käynnistyksessäBinääri käännetty väärälle arkkitehtuurille (x86-64 Arm64-koneella)Tarkista kääntökomennon kohdearkkitehtuuri ja käännä uudelleen oikealle alustalle
MPS-palvelin ei käynnistyVanha MPS-prosessi jäänyt taustalleSammuta vanha prosessi komennolla nvidia-cuda-mps-control -q ennen uudelleenkäynnistystä
cuda.core-asennus epäonnistuu pipilläPython-versio liian vanha tai väärä arkkitehtuuriPäivitä Python 3.10+ Arm64-versioon ja aja pip uudelleen
Hidas suorituskyky verrattuna x86-64-koneeseenOhjelma ajaa emulointikerroksen läpiVarmista natiivi Arm64-käännös ja tarkista Task Managerista arkkitehtuuri
Nsight-profiili ei tallennuKirjoitusoikeudet puuttuvat kohdekansiostaAja komentorivi järjestelmänvalvojana tai vaihda tuloskansio omaan käyttäjäkansioon
cuda.core-tuonnin ImportError PythonissaPython asennettu x86-64-versiona Arm64-koneelleAsenna Python uudelleen virallisesta Arm64-asennuspaketista ja luo virtuaaliympäristö uudelleen
TOML-konfiguraatio ei vaikuta MPS-instanssiinPalvelininstanssi luotu ennen konfiguraation päivitystäPoista vanha instanssi ja luo se uudelleen päivitetyllä TOML-tiedostolla

Jos mikään yllä olevista ei ratkaise ongelmaasi, seuraava askel on tarkistaa Nvidian kehittäjäfoorumin CUDA 13.4 -keskusteluketju, jonne muut kehittäjät raportoivat Windows on Arm -spesifisiä bugeja sitä mukaa kuin niitä löytyy. Koska kyseessä on tuore kehittäjäesikatselu, osa ongelmista korjaantuu vasta seuraavassa pistepäivityksessä eikä niihin ole vielä kiertotietä.

Kun raportoit ongelmaa foorumille, liitä mukaan aina täsmällinen Toolkit-versio, ajuriversio, laitemalli ja komento, jolla virhe toistuu. Tämä nopeuttaa asiaa kehittäjäesikatselussa, jossa Nvidian tiimi käy läpi raportteja manuaalisesti eikä automaattinen virheenkeruu kata vielä yhtä montaa tapausta kuin vakaissa julkaisuissa. Täsmällinen raportti nopeuttaa korjauksen löytämistä huomattavasti verrattuna pelkkään “ei toimi” -ilmoitukseen.

Turvallisuus ja luotettavuus kehittäjäesikatselussa

Kehittäjäesikatselun asentaminen ei ole riskitöntä, ja se kannattaa tehdä harkiten. Koska CUDA 13.4 ei ole vielä vakaa julkaisu, suosittelemme sen asentamista erilliselle testikoneelle tai vähintään omaan käyttäjätiliin, ei siihen samaan Windows-asennukseen, jota käytät päivittäiseen työhön tai arkaluontoisten tietojen käsittelyyn. Jos koneella ei ole erillistä testiosiota, luo Windowsin palautuspiste ennen asennusta, jotta voit palata edelliseen tilaan nopeasti, jos jokin menee pieleen. Tämä koskee erityisesti ajuriasennuksia, koska väärin mennyt näytönohjainajurin päivitys voi johtaa mustaan näyttöön tai käynnistysongelmiin, jotka ovat hankalampia korjata kuin tavallisen sovelluksen asennusvirhe.

Checkpoint-Computer -Description "Ennen CUDA 13.4 -asennusta" -RestorePointType "APPLICATION_INSTALL"

Toinen huomionarvoinen yksityiskohta on tiedostojen eheyden tarkistus. Lataa asennuspaketit aina suoraan Nvidia Developerin virallisilta sivuilta, älä kolmansien osapuolien peilipalvelimilta, ja vertaa laskettua SHA-256-tarkistussummaa sivustolla ilmoitettuun arvoon ennen asennuksen käynnistämistä. Tämä on erityisen tärkeää juuri nyt, kun CUDA 13.4 -asennuspaketit ovat vielä suhteellisen tuore ja vähän ladattu julkaisu, jolloin väärennettyjen tai vahingoittuneiden tiedostojen leviäminen epävirallisten latauslähteiden kautta on todennäköisempää kuin vakiintuneilla, laajasti ladatuilla versioilla.

Muista myös, että Coherent Driver-based Memory Management (CDMM) -asetus, joka on nyt oletuksena Nvidian koherenteilla alustoilla, on koko koneen laajuinen asetus, joka vaatii ajurin uudelleenlatauksen tai koko koneen uudelleenkäynnistyksen vaihtuakseen. Jos suunnittelet vaihtavasi takaisin NUMA-tilaan myöhemmin, tee valinta ennen päivitystä, sillä jälkikäteen tehty muutos vaatii ylimääräisen käynnistyskerran ja voi keskeyttää käynnissä olevat prosessit odottamattomasti.

Jos jaat kehityskoneen muiden käyttäjien kanssa, kannattaa myös rajata kuka voi käyttää MPS-ohjauspalvelinta. Oletuksena kuka tahansa samalla koneella oleva käyttäjä voi luoda uuden palvelininstanssin ja varata itselleen osan GPU:sta, mikä voi olla ei-toivottua jaetussa laboratorio- tai luokkahuoneympäristössä. Rajaa pääsy käyttöoikeuksilla samaan tapaan kuin rajaisit pääsyn mihin tahansa muuhunkin järjestelmäresurssiin.

Pidä myös kirjaa siitä, mitkä palvelininstanssit ovat käynnissä pitkän kehityssession jälkeen. On tavallista unohtaa vanha testi-instanssi taustalle, jolloin se varaa GPU-muistia turhaan ja seuraava käynnistämäsi sovellus saa vähemmän resursseja käyttöönsä kuin odotit. Komento nvidia-cuda-mps-control server list ennen jokaisen uuden työkuorman käynnistämistä on nopea tapa välttää tämän tyyppiset yllätykset.

Edistyneet vinkit kokeneille kehittäjille

Kun perusasennus ja ensimmäiset esimerkit toimivat, kannattaa hyödyntää muutamaa vähemmän tunnettua ominaisuutta. CUDA 13.4:n locality domain -rajapinta antaa mahdollisuuden kohdistaa laskenta ja muisti samaan GPU:n osaan, mikä parantaa suorituskykyä laitteissa, joissa on useampi kuin yksi lokaalisuusalue. Tämä ei vielä koske useimpia N1X-läppäreitä, mutta on hyödyllistä tietää suurempia järjestelmiä varten.

Toinen hyödyllinen lisäys on cudaMemGetLocationInfo-rajapinta, jolla voi kysyä missä hallittu tai järjestelmän jakama muisti fyysisesti sijaitsee. Tämä auttaa välttämään tarpeettomia sivusiirtoja ja etämuistihakuja suorituskykyherkissä kirjastoissa. Jos rakennat omaa kirjastoa CUDA:n päälle, kannattaa myös tutustua cuda.compute-moduulin AoT-käännökseen (ahead-of-time), jonka avulla voit kääntää algoritmit valmiiksi useille GPU-arkkitehtuureille ilman, että kohdekoneella tarvitsee edes olla GPU:ta käytettävissä käännösvaiheessa. Tämä on hyödyllistä juuri Arm64-kehityksessä, jossa kaikilla tiimin jäsenillä ei vielä ole fyysistä testilaitetta: rakennuspalvelin voi kääntää algoritmit valmiiksi useille arkkitehtuureille, ja vasta lopullinen testaus vaatii oikean laitteiston.

Jos työskentelet C++:lla, cuda::std-nimiavaruuden rinnakkaiset algoritmit antavat tutun C++-standardikirjaston rajapinnan GPU-suoritukselle. Tämä madaltaa kynnystä siirtää olemassa olevaa CPU-koodia GPU:lle, koska syntaksi pysyy tuttuna ja vain suoritusstrategia vaihtuu cuda::execution::gpu-parametrilla.

Kannattaa myös ottaa käyttöön Nsight Python 1.0:n dekoraattoripohjainen profilointi jo kehitysvaiheen alussa, ei vasta silloin kun suorituskyky alkaa hidastaa. Yksi rivi koodia riittää keräämään arkkitehtuurikohtaiset mittarit jokaisesta funktiokutsusta, mikä paljastaa pullonkaulat ennen kuin ne ehtivät kertaantua isommaksi ongelmaksi projektin edetessä. Tämä on erityisen arvokasta Windows on Arm -kehityksessä, jossa suorituskykyprofiili voi poiketa yllättävästikin x86-64-koneesta tutuista luvuista.

Kun projekti kasvaa useamman tiedoston kokonaisuudeksi, harkitse build-järjestelmän käyttöä pelkän suoran nvcc-komennon sijaan. CMake tukee CUDA:aa natiivina kielenä versiosta 3.18 lähtien, ja se osaa käsitellä sekä natiivin että ristiinkäännetyn Arm64-kohteen samasta lähdekoodista muuttamalla vain kohdearkkitehtuurin määrittelyä. Tämä säästää huomattavasti aikaa, kun projektissa on kymmeniä tai satoja lähdekooditiedostoja yhden esimerkin sijaan.

N1X-kannettavien saatavuus Suomessa ja Pohjoismaissa

N1X on tuore alusta, ja Windows on Arm -kannettavien valikoima pohjoismaisilla jälleenmyyjillä on toistaiseksi suppeampi kuin perinteisten x86-64-kannettavien. Tämä on tyypillistä uusille suoritinalustoille: kun Qualcommin Snapdragon-pohjaiset Windows on Arm -koneet tulivat markkinoille muutama vuosi sitten, mallivalikoima laajeni vasta vähitellen ensimmäisten kuukausien jälkeen sitä mukaa kun valmistajat ja jälleenmyyjät saivat varmuutta kysynnästä.

Käytännön vinkki suomalaiselle ostajalle: tarkista ennen hankintaa aina tarkka mallimerkintä ja se, mikä GPU-siru koneessa oikeasti on. Windows on Arm -merkintä yksin ei takaa Nvidia-yhteensopivuutta, koska osa Arm-kannettavista käyttää Qualcommin omaa integroitua grafiikkaa ilman Nvidia-piiriä. Jos päämääränäsi on nimenomaan CUDA-kehitys, etsi laitteita, jotka mainitsevat erikseen Nvidia N1X -alustan tai Nvidia-yhteensopivan GPU:n Windows on Arm -ympäristössä. Jälleenmyyjän tekniset tiedot ja valmistajan oma tuotesivu ovat luotettavin tapa varmistaa tämä ennen ostopäätöstä, sillä pelkkä “AI-kannettava” -markkinointinimike ei kerro, mikä piiri koneen sisällä todellisuudessa on.

Kannattaa myös huomioida takuu- ja huoltoverkoston kattavuus. Uuden alustan ensimmäisen sukupolven laitteissa huoltopisteiden ja varaosien saatavuus voi vaihdella maittain enemmän kuin vakiintuneemmilla x86-64-malleilla. Tarkista jälleenmyyjältä, kattaako takuu koko Pohjoismaiden alueen vai vain ostomaan, jos harkitset laitteen hankkimista esimerkiksi verkkokaupasta toisesta EU-maasta.

Hintavertailu kannattaa tehdä aina euroissa, ei suoraan dollarihintoja muuntamalla, koska EU:n arvonlisävero ja tuontikulut vaikuttavat lopulliseen kuluttajahintaan merkittävästi enemmän kuin pelkkä valuuttakurssi. Pyydä jälleenmyyjältä aina lopullinen, veroineen laskettu hinta ennen ostopäätöstä, äläkä vertaa suoraan yhdysvaltalaisilla sivustoilla ilmoitettuihin verottomiin hintoihin.

CUDA Windows on Arm vs x86-64: milloin kannattaa vaihtaa

Windows on Arm ei korvaa x86-64-työasemaa jokaisessa tilanteessa. Jos työskentelet raskailla, jo optimoiduilla CUDA-kirjastoilla tai tarvitset laajan valikoiman kolmannen osapuolen ajureita, x86-64 on tällä hetkellä vakaampi valinta. Mutta jos kehität kevyitä tekoälysovelluksia, testaat siirrettävyyttä tai haluat pidemmän akunkeston kannettavassa, Arm-vaihtoehto on nyt ensimmäistä kertaa aidosti käytettävissä CUDA:n kanssa. Päätös kannattaa tehdä sen mukaan, mikä osa työstäsi vie eniten aikaa: jos vietät suurimman osan päivästä kokousten välissä pikakoodauksen ja kevyiden mallien testauksen parissa, akunkesto voi olla arvokkaampi ominaisuus kuin raaka laskentateho.

OminaisuusWindows on Arm (N1X)x86-64 + RTX 5090
CUDA-tukiKehittäjäesikatselu (13.4)Vakaa, vuosia tuettu
Tyypillinen käyttöKevyt tekoäly, siirrettävyys, akunkestoRaskas laskenta, pelaaminen, tuotanto
Näytönohjaimen hintaIntegroitu, ei erillistä ostoaRTX 5090 n. 4 000–5 000 $ (heinäkuu 2026, Techguided)
Kirjastojen kypsyysOsittainen, laajeneeLaaja ja vakiintunut
Kohdealustan tilaUusi, kehittäjäesikatseluTuotantovalmis

Taulukko tiivistää sen, että kyse ei ole paremmuusjärjestyksestä vaan erilaisista käyttötarkoituksista. Kirjastojen kypsyysaste on käytännössä ainoa rivi, joka muuttuu nopeasti: sitä mukaa kun CUDA 13.4 etenee kohti vakaata julkaisua ja kolmannen osapuolen kirjastot (esimerkiksi PyTorch ja TensorFlow) julkaisevat omat Arm64-Windows-buildinsa, tämä rivi kapenee ja Arm-vaihtoehdosta tulee kilpailukykyisempi yhä useammalle käyttäjälle.

Vertailun toinen puoli koskee muita Arm- ja x86-64-vaihtoehtoja kannettavissa. Intelin Core Ultra Series 3 -sarja, joka esiteltiin CES 2026 -tapahtumassa ja joka on Intelin ensimmäinen 18A-valmistusprosessilla tehty AI PC -alusta, tuli maailmanlaajuisesti saataville 27. tammikuuta 2026. AMD puolestaan toi Ryzen AI 400- ja Ryzen AI PRO 400 -sarjan järjestelmät suurten valmistajien kuten Acerin, Asuksen, Dellin, HP:n, Gigabyten ja Lenovon kautta ensimmäisellä vuosineljänneksellä 2026. Kumpikaan näistä ei kuitenkaan ole Arm-arkkitehtuuri, joten ne kilpailevat N1X:n kanssa eri lähtökohdista: x86-64-yhteensopivuudella CUDA-tuen sijaan.

Pohjoismaisille kehittäjille tämä tarkoittaa käytännössä kolmea vaihtoehtoista polkua tekoälykehitykseen kannettavalla. Ensimmäinen on jatkaa tutulla x86-64-koneella ja hyväksyä RTX-näytönohjaimen nykyinen hintataso. Toinen on siirtyä Intelin tai AMD:n uusimpiin NPU-varustettuihin x86-64-siruihin, jotka eivät tue CUDA:aa mutta tarjoavat oman tekoälykiihdytyksensä käyttöjärjestelmän ja sovellusten kautta. Kolmas, tähän asti puuttunut vaihtoehto, on Windows on Arm -kannettava, jossa CUDA-koodi toimii nyt natiivisti ensimmäistä kertaa. Jokainen reitti sopii erilaiseen tarpeeseen, eikä yksi vaihtoehto ole automaattisesti oikea kaikille.

Usein kysytyt kysymykset

Toimiiko CUDA 13.4 kaikilla Windows on Arm -koneilla?
Ei. Tuki on kohdistettu erityisesti Nvidian N1X-läppäriekosysteemiin, jossa on Nvidia-grafiikka. Arm-koneet, joissa on esimerkiksi Qualcommin tai muun valmistajan grafiikkaratkaisu ilman Nvidia-GPU:ta, eivät hyödy tästä päivityksestä, koska CUDA vaatii aina Nvidia-laitteiston ajaakseen kerneleitä GPU:lla riippumatta suorittimen arkkitehtuurista.

Voinko käyttää CUDA 13.4:ää tuotantosovelluksessa?
Nvidia on todennut, ettei julkaisua pidä käyttää tuotannossa, sertifioinnissa, vertailutestauksessa tai liiketoimintakriittisissä järjestelmissä, koska kyseessä on kehittäjäesikatselu.

Mitä eroa on natiivilla käännöksellä ja ristiinkäännöksellä?
Natiivi käännös tapahtuu suoraan Arm64-koneella ja tuottaa binäärin ilman emulointikerrosta. Ristiinkäännös tehdään x86-64-koneella, ja lopputulos siirretään ajettavaksi Arm64-laitteelle, mikä on kätevää jos kehityskone ja kohdelaite eroavat arkkitehtuuriltaan.

Miksi ajuri pitää asentaa erikseen Toolkitista?
CUDA 13.1:stä lähtien Nvidia erotti ajurin ja Toolkitin asennuspaketit toisistaan, jotta molempia voidaan päivittää itsenäisesti ja pakettien hallinta pysyy selkeämpänä esimerkiksi konttiympäristöissä.

Mikä on Multi-Process Service V3 ja miksi se on tärkeä?
MPS V3 on uudistettu tapa hallita sitä, miten useampi prosessi jakaa saman GPU:n. Se tuo skriptattavan komentorivin, TOML-konfiguraation ja cgroup-integroidut muistirajat, joiden avulla GPU:n resurssit voidaan jakaa tarkasti eri työkuormille. Tämä on erityisen hyödyllinen ominaisuus, kun samalla laitteella halutaan ajaa useampi pieni tekoälypalvelu rinnakkain ilman, että yksi niistä voi häiritä muita.

Kannattaako vaihtaa Windows on Arm -koneeseen pelkästään CUDA-tuen takia?
Jos päätarpeesi on raskas pelaaminen tai tuotantotason laskenta, x86-64 ja erillinen näytönohjain ovat yhä vakaampi valinta. Jos taas arvostat akunkestoa ja kevyttä tekoälykehitystä matkalla, N1X-pohjainen Arm-kannettava on nyt varteenotettava vaihtoehto CUDA 13.4:n ansiosta. Odota kuitenkin Toolkitin vakaata julkaisua ennen kuin rakennat sen varaan mitään liiketoimintakriittistä.

Tukeeko CUDA 13.4 myös tulevaa Rubin-arkkitehtuuria?
Kyllä, esikatselutasolla. Julkaisu tuo toiminnallisen tuen Rubin-arkkitehtuurille laskentakyvyllä 107, jotta kehittäjät voivat aloittaa sovellusten siirtämisen ennen virallista yleistä saatavuutta.

Mistä löydän viralliset asennusohjeet, jos tämä opas ei kata tilannettani?
Nvidian oma CUDA Installation Guide for Microsoft Windows kattaa kaikki tuetut asennustavat ja päivittyy uusien Toolkit-versioiden mukana.

Toimiiko olemassa oleva x86-64-CUDA-koodi sellaisenaan Arm64:llä?
Lähdekoodi toimii yleensä sellaisenaan, koska CUDA-C++-syntaksi ei riipu isäntäsuorittimen arkkitehtuurista. Binäärit eivät kuitenkaan ole yhteensopivia, joten sovellus pitää kääntää uudelleen joko natiivisti Arm64-koneella tai ristiinkäännöksellä ennen kuin se toimii Windows on Arm -laitteella.

Vaikuttaako GDDR7-muistin niukkuus myös Windows on Arm -kannettaviin?
Kyllä, epäsuorasti. Sama muistikriisi, joka on nostanut RTX 5090:n hintaa, on nostanut myös kannettavien DDR5- ja GDDR-muistikomponenttien kustannuksia laajemmin, mikä näkyy kaikkien uusien kannettavien, myös Arm-mallien, hinnoittelussa vuoden 2026 aikana.

Tarvitsenko internetyhteyden koko asennuksen ajan?
Tarvitset sen ainakin lataamiseen. Jos valitset verkkoasentimen, yhteyttä tarvitaan koko asennuksen ajan, koska osat ladataan asennuksen edetessä. Koko paketin sisältävällä asentimella yhteyttä tarvitaan vain ennen asennuksen aloittamista, minkä jälkeen voit asentaa useamman koneen ilman verkkoa.