Ali kako iz sveže nameščenega Windowsa narediti AI-laboratorij, ne da bi pri tem izgubil živce, podatke ali vero v človeštvo.

Obstajata dve vrsti ljudi. Prvi kupijo računalnik, ga prižgejo, namestijo nekaj programov in ga uporabljajo. Drugi kupijo računalnik, ga prižgejo, ugotovijo, da bi lahko deloval še nekoliko bolje, in naslednje tri večere preživijo v BIOS-u, terminalu ter na GitHubu.

Sam spadam v drugo skupino.

Po letih eksperimentiranja z različnimi programi, gonilniki, lokalnimi jezikovnimi modeli in nastavitvami je moj Windows počasi začel spominjati na garažo človeka, ki nikoli ničesar ne zavrže, ker »bo mogoče nekoč še prav prišlo«.

Tri različne namestitve Pythona, nekaj ostankov ROCm eksperimentov, več različic razvojnih knjižnic, kakšna okoljska spremenljivka skrivnostnega izvora in mapa Downloads, ki je že zdavnaj izgubila vsakršno povezavo z besedo organizacija.

Računalnik je sicer deloval. Ampak jaz sem vedel, da je tam spodaj nekje še vedno zakopan kakšen star DLL, ki samo čaka na priložnost, da pokvari petkov večer.

Zato sem se odločil za čisto namestitev Windows 11.

Naivno sem si predstavljal, da bo to razmeroma preprosto opravilo.

Windows na novo, gonilniki, nekaj programov in končano.

Seveda.

1. Pacient: Beast AI

Najprej nekaj o računalniku, ki je bil deležen tega digitalnega pomlajevanja.

Moja trenutna konfiguracija:

• Procesor: AMD Ryzen 9 5950X, 16 jeder in 32 niti
• Matična plošča: Gigabyte X570 Aorus PRO
• Delovni pomnilnik: 128 GB DDR4, 3200 MHz
• Grafični kartici: 2 × AMD Radeon RX 7900 XTX, vsaka s 24 GB VRAM
• Shramba: 2 × NVMe SSD
• Napajalnik: 2000 W
• Hlajenje: vodno
• Operacijska sistema: Windows 11 in Ubuntu Linux

Zakaj dve grafični kartici?

Ker ena očitno ni bila dovolj za moje zanimanje za lokalno umetno inteligenco.

Vsaka ima 24 GB grafičnega pomnilnika, skupaj torej 48 GB VRAM. Toda tukaj velja opozorilo: dve kartici ne ustvarita čudežno enega samega 48-gigabajtnega pomnilniškega prostora. Programska oprema mora znati razporediti model in izračune med obe.

Na papirju imam torej dovolj računalniške moči za precej resno eksperimentiranje.

V praksi pa je treba najprej prepričati Windows, gonilnike in programsko opremo, naj se vsi obnašajo kot odrasli.

Kar je, kot bomo videli, svojevrsten projekt.

2. Čista namestitev – poslovilna zabava za stare DLL-je

Pred ponovno namestitvijo Windowsa sem si postavil tri pravila:

1. Najprej varnostna kopija, potem pogum.
2. Ne nameščam stvari, za katere ne vem, zakaj jih potrebujem.
3. Ne popravljam delujočih nastavitev samo zato, ker je nekdo na YouTubu obljubil 37 % višji FPS.

Tretje pravilo je bilo daleč najtežje.

Priprava namestitvenega USB-ja

Uporabil sem uradno namestitveno pot prek Microsoftovega Windows 11 Media Creation Tool.

Postopek je preprost:

• Pripravimo prazen USB-ključek z vsaj 8 GB prostora.
• Ustvarimo zagonski namestitveni medij.
• Preverimo, da imamo varnostne kopije in potrebne podatke za aktivacijo.
• Računalnik zaženemo v načinu UEFI.
• Windows namestimo na izbrani sistemski pogon.

Ker imam na računalniku tudi Linux (o tem bo ločena objava), je bila najpomembnejša optimizacija zelo preprosta: ne formatiraj napačnega diska.

Pri dveh NVMe pogonih in dveh operacijskih sistemih zna en napačen klik poskrbeti za precej intenzivnejši vikend, kot sem ga načrtoval.

Pred posegom je zato smiselno preveriti razporeditev particij, EFI zagonske vnose in ključ za obnovitev BitLockerja, če je šifriranje omogočeno. Če je mogoče, med namestitvijo odklopimo pogone, ki jih ne želimo spreminjati.

Po namestitvi sem najprej uredil Windows Update in opravil potrebne ponovne zagone.

Šele potem sem začel nameščati gonilnike in ostalo programsko opremo.

3. Gonilniki – vrstni red je pomembnejši, kot se zdi

Windows zna danes sam namestiti ogromno gonilnikov.

Kar je odlično, dokler se ne odloči, da za tvojo grafično kartico najbolje ve on.

Zato sem se držal naslednjega vrstnega reda.

Najprej AMD X570 chipset

Za kombinacijo Ryzen 9 5950X in X570 sem uporabil uradne AMD chipset gonilnike.

Ti skrbijo za pravilno delovanje različnih komponent platforme, ne samo za tisto, kar vidimo na zaslonu.

Po namestitvi sledi ponovni zagon.

Nato pridejo na vrsto morebitni manjkajoči gonilniki za omrežje, zvok in druge naprave, po potrebi s podporne strani Gigabyte.

Nato Radeon Adrenalin

Za obe RX 7900 XTX sem poiskal uradni paket AMD Software: Adrenalin Edition.

Nisem iskal nekega čudežnega gonilnika, s katerim naj bi kartici delovali dvakrat hitreje.

Želel sem predvsem stabilnost, pravilno zaznavanje obeh kartic in delujočo GPU-pospešeno programsko opremo.

Po namestitvi sem preveril, ali Windows dejansko vidi obe kartici.

V PowerShellu lahko to preverimo z:

Get-CimInstance Win32_VideoController |
    Select-Object Name, DriverVersion

Pričakovan rezultat sta dve zaznani kartici Radeon RX 7900 XTX. Podobno se vidi tudi v grafičnem vmesniku “Upravitelj naprav”…

Če bi se pojavila samo ena, nadaljevanje z nameščanjem vseh mogočih AI-orodij ne bi imelo prav veliko smisla.

Majhen trik: na povsem sveži namestitvi praviloma ne potrebujemo DDU ali AMD Cleanup Utility. Ti orodji sta uporabni predvsem pri odpravljanju težav s prejšnjimi gnilniki. Brisanje nečesa, česar še nismo namestili, je nekoliko pretirana oblika optimizacije. Pride pa prav na že nameščenih sistemih, kjer je bilo po možnosti celo nameščenih več gonilnikov in za “clean driver state”.

4. BIOS – kraj, kjer lahko računalnik pohitriš ali si pokvariš soboto

Naslednja postaja je bil BIOS.

Tu se običajno začne nevaren del.

V BIOS-u namreč obstaja ogromno nastavitev, ki imajo zelo prepričljiva imena. Performance Boost. Precision Boost. Extreme Memory. Ultra Fast.

Človek dobi občutek, da je proizvajalec privzeto nastavil računalnik na »počasi in premišljeno«, vse dobre stvari pa skril v podmenije.

Sam sem se osredotočil na nekaj preverljivih nastavitev.

Pomnilnik: preveril sem XMP oziroma ustrezen pomnilniški profil, da 128 GB DDR4 dejansko deluje pri predvidenih 3200 MHz. Pri štirih pomnilniških modulih stabilnosti ni pametno jemati za samoumevno.

PCIe: preveril sem konfiguracijo rež in hitrost povezav obeh GPU-jev. Pri več karticah je razdelitev PCIe pasov odvisna od matične plošče, procesorja in uporabljenih rež.

Above 4G Decoding in Re-Size BAR: preveril sem razpoložljivost in združljivost teh možnosti, ne pa jih slepo vklapljal po internetnih receptih.

PBO in navijanje: pustil sem ju pri miru, dokler nisem imel potrjene stabilne osnove.

Pri lokalnem AI mi namreč veliko več pomeni zanesljiv 40-minutni preizkus kot pet odstotkov boljši rezultat, ki se po 38 minutah konča z zamrznjenim zaslonom.

Vodno hlajenje je sicer odlična stvar, vendar žal ne hladi tudi uporabnikovih napačnih odločitev.

5. Debloat Windowsa – manj navlake, manj presenečenj

Ko sem končal z gonilniki, sem se lotil samega Windowsa.

Microsoft je prijazen in nam že ob namestitvi ponudi kup funkcij, storitev in predlogov. Kar je lepo.

Toda za računalnik, namenjen programiranju in lokalnim jezikovnim modelom, res ne potrebujem vsega.

Moj cilj ni bil ustvariti nekega skrivnostnega »Windows Ultra Lite AI Gaming Edition 9000«.

Želel sem normalen, posodobljen in varen Windows z manj nepotrebnega hrupa.

Kaj sem uredil?

Zagonski programi

Odprl sem Task Manager → Startup apps in onemogočil nepotrebne samodejne zagone.

Če se program uporablja enkrat na mesec, ni nujno, da mora v pomnilniku čakati od šestih zjutraj.

Nepotrebne aplikacije

Odstranil sem programe, za katere sem vedel, da jih ne bom uporabljal.

Ne pa sistemskih komponent na slepo.

Napajanje

Preveril sem nastavitve napajanja in spanja. Med daljšimi lokalnimi AI opravili računalnik ne sme nepričakovano zaspati, ko se nekaj obdeluje.

Načrt porabe energije z najvišjo zmogljivostjo pa ni avtomatično optimalna izbira za vsakodnevno delo. Smiselno je najprej izmeriti razliko.

Windows Security

Defender, požarni zid in varnostne posodobitve sem obdržal.

Varnost ni navlaka.

Tudi če kakšen spletni vodič trdi, da z izklopom vseh zaščit pridobiš neverjetno zmogljivost. Verjetno je res hitreje, ko računalnika nič več ne varuje pred lastnikom.

Pagefile

Navidezni pomnilnik sem prepustil sistemskemu upravljanju.

Tudi pri 128 GB RAM je lahko potreben. Njegova popolna odstranitev praviloma ni pametna optimizacija.

Fast Startup

Ker uporabljam tudi Linux, sem preveril možnost hitrega zagona Windows. Ta lahko pri dvojni namestitvi povzroča težave pri dostopu do skupnih datotečnih sistemov ali pri določenih postopkih zagona. Po potrebi jo je smiselno izklopiti.

Moj recept za dober debloat?

Odstrani tisto, česar ne uporabljaš. Ne odstranjuj tistega, česar ne razumeš.

Manj dramatično od agresivnih optimizacijskih skript, vendar precej bolj uporabno.

6. Osnovno orodje: PowerShell, Git, Python in ‘pritekline’

Ko je Windows končno začel delovati kot operacijski sistem in ne kot reklamni pano, sem pripravil razvojno okolje.

Prvi pomočnik je bil Windows Package Manager oziroma winget.

Namesto klikanja po desetih spletnih straneh lahko precej osnovnih orodij namestimo neposredno iz terminala:

winget install Microsoft.PowerShell Git.Git
winget install Microsoft.VisualStudioCode 7zip.7zip
winget install Kitware.CMake Ninja-build.Ninja

S tem dobimo sodobni PowerShell, Git, VS Code, 7-Zip, CMake in Ninja.

Za gradnjo programov iz izvorne kode sem pripravil tudi Visual Studio z ustreznimi C++ razvojnimi orodji.

Python sem namestil posebej, pri čemer sem se odločil, da različnih projektov ne bom več silil v isto globalno okolje.

Za posamezen projekt uporabljam izolirana virtualna okolja:

py -3.12 -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip

Primer uporablja Python 3.12, ki ga je treba predhodno namestiti. Za projekte, ki podpirajo novejše različice, lahko seveda uporabimo drugo.

Zakaj virtualna okolja?

Ker sem se že naučil, kaj se zgodi, ko en projekt potrebuje določeno različico knjižnice, drugi novejšo, tretji pa oboje in še nekaj, kar je nekdo objavil pred štirimi urami.

Na koncu pip install postane oblika športne stave.

7. AMD ROCm: ko umetna inteligenca sreča Radeon

Pri lokalnem AI se skoraj vsak pogovor o grafičnih karticah slej ko prej dotakne NVIDIA CUDA.

Jaz pa imam AMD.

In ne samo ene kartice. Dve.

Kar pomeni, da se precej hitro znajdeš v svetu kratic ROCm, HIP, Vulkan, gfx1100 in kompatibilnostnih tabel.

Dobra novica je, da RX 7900 XTX spada med podprte kartice za AMD HIP SDK na Windows.

Njena arhitekturna oznaka je gfx1100.

Manj dobra novica je, da Windows HIP SDK ni enakovreden celotni programski zbirki ROCm na Linuxu.

To je pomembna razlika.

Kaj sem potreboval?

Za običajno uporabo lokalnih modelov sem najprej uredil delujoče grafične gonilnike in ustrezno podporo izbranega programa.

Za razvoj in gradnjo ROCm/HIP različic sem pripravil še AMD HIP SDK za Windows.

Ta je namenjen razvijalcem in ni nujen za vsako uporabo LM Studia.

Pri HIP SDK je pomembno preveriti skladnost različic gonilnika, razvojnih orodij in programa, ki ga želimo zgraditi.

Pravilo, ki sem ga hitro osvojil:

Če na spletni strani piše »supports AMD«, to še ne pomeni »podpira mojo kartico, moj Windows, mojo različico knjižnice in moj trenutni poskus ob 23.47«.

Zato sem se odločil za dva načina uporabe.

Na Windows uporabljam priročna orodja za lokalno inferenco in programiranje. Za zahtevnejše poskuse s celotnim ROCm ekosistemom pa imam na voljo Ubuntu.

8. LM Studio – končno nekaj, kar deluje tudi brez doktorata iz odvisnosti

Prva res uporabna postaja je bil LM Studio. Sicer sem pred njim poizkusil ComflyUI (ki ga AMD priporoča), vendar se nisem preveč ubadal s kreiranjem workflow-ov in si zadeve poenostavil..

Torej LM Studio je program, ki precej poenostavi iskanje, prenos in uporabo lokalnih jezikovnih modelov.

Namestiš program, poiščeš model, ga preneseš, naložiš v pomnilnik in začneš uporabljati.

Skoraj sumljivo enostavno.

Pri svoji konfiguraciji sem se posvetil predvsem nastavitvam, ki odločajo, ali bosta grafični kartici dejansko opravljali delo.

Moje izhodiščne nastavitve

Runtime: preverim razpoložljive in združljive izvedbe llama.cpp, predvsem možnosti za AMD GPU.

GPU offload: poskusim čim več plasti modela prenesti na GPU, če je dovolj prostega VRAM.

Context length: začnem z 8192 ali 16384 tokeni. Šele potem postopno povečujem kontekst, če model in pomnilnik to omogočata.

Flash Attention: uporabim, če ga konkretni model in izbrani runtime podpirata.

Shranjevanje modelov: modele hranim v namenski mapi, ne pomešanih med dokumenti in naključnimi prenosi.

Primer moje priporočene organizacije:

D:\AI\
    Models\
    Benchmarks\
    Logs\
    Projects\
    Tools\

Posebno pozornost namenim tudi temu, ali program uporablja eno kartico ali obe. Sam podatek, da imam skupaj 48 GB VRAM, še ni dokaz, da je model pravilno razdeljen.

LM Studio tudi iz terminala

Poleg grafičnega vmesnika ima LM Studio tudi CLI.

Uporabne ukaze lahko preizkusimo v PowerShellu:

lms ls
lms ps
lms load

Prvi izpiše lokalne modele, drugi trenutno naložene modele, tretji pa omogoča nalaganje modela.

Za konkreten model lahko preverimo tudi predvideno porabo pomnilnika:

lms load --estimate-only <model_key>

Ko je model naložen, lahko lokalni API strežnik zaženemo na primer z:

lms server start --port 1234

In preverimo API:

Invoke-RestMethod http://127.0.0.1:1234/v1/models

Tako lahko lokalni model uporabljam tudi iz lastnih aplikacij ali razvojnih orodij.

Seveda API ni avtomatično inteligentnejši zato, ker teče na mojem računalniku. Ima pa eno zelo lepo lastnost: za lokalno sklepanje ni treba pošiljati vsakega vprašanja na oddaljen strežnik.

9. llama.cpp – ko želiš pogledati pod pokrov motorja

LM Studio je zelo priročen.

Toda jaz imam rad tudi trenutke, ko odprem pokrov motorja, pogledam noter in si rečem:

»Aha, zdaj razumem. No, skoraj.«

Zato sem se lotil še llama.cpp.

To je odprtokodni projekt, ki omogoča izvajanje jezikovnih modelov, pogosto v formatu GGUF, z različnimi procesorskimi in grafičnimi zaledji.

Na AMD karticah sem eksperimentiral z Vulkanom in HIP/ROCm izvedbami.

Gradnja Vulkan različice na Windows

Za takšno gradnjo potrebujemo ustrezno C++ razvojno okolje, CMake in Vulkan SDK.

V pripravljenem terminalu lahko začnemo z:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

cmake -S . -B build-vulkan -DGGML_VULKAN=ON
cmake --build build-vulkan --config Release -j 8

Po uspešni gradnji poiščemo llama-server.exe.

Njegova lokacija je odvisna od uporabljenega CMake generatorja.

Nato najprej preverimo zaznane GPU naprave:

.\build-vulkan\bin\Release\llama-server.exe --list-devices

Zgornja pot je primer za običajno Windows Release gradnjo. Če je izvršljiva datoteka drugje, pot ustrezno prilagodimo.

Za osnovni preizkus lahko strežnik zaženemo takole:

.\build-vulkan\bin\Release\llama-server.exe `
  -m "D:\AI\Models\model.gguf" `
  -c 8192 `
  -ngl 99 `
  --split-mode layer `
  --host 127.0.0.1 `
  --port 8080

Ime datoteke seveda zamenjamo z dejansko potjo do združljivega GGUF modela.

-ngl 99 omogoča poskus prenosa velikega števila plasti na GPU. --split-mode layer pa je eden od načinov razdelitve modela med več grafičnih kartic.

Ali bo model dejansko uporabljal obe kartici, preverimo v izpisu strežnika in spremljanju porabe VRAM.

Pomembno: enako zmogljivi kartici še ne zagotavljata dvakratne hitrosti. Pri več GPU-jih lahko na rezultat vplivajo model, razporeditev plasti, pomnilnik, PCIe komunikacija in programski backend.

Zato je najboljša optimizacija pogosto preprosto merjenje.

Ne ugibanje.

In potem se je pojavil GGUF type 102

Eden zanimivejših zapletov pri mojih poskusih je bila napaka pri nalaganju modela:

tensor 'output.weight' has invalid ggml type 102

Na prvi pogled bi človek pomislil, da je zmanjkalo pomnilnika.

Ni.

Težava je bila v nepodprtem tipu kvantizacije v uporabljeni gradnji llama.cpp.

Model je torej obstajal. Grafični kartici sta obstajali. Pomnilnika je bilo dovolj.

Manjkala je samo medsebojna kompatibilnost.

Kot bi imel avtomobil, gorivo in ključ, vendar bi ključ pripadal sosedovemu avtomobilu.

Rešitev ni bila nakup tretje grafične kartice. Čeprav priznam, da je takšna misel precej privlačna.

Preveriti je bilo treba vrsto GGUF kvantizacije, zahteve izdajatelja modela in podporo v konkretni različici llama.cpp.

Včasih pomaga novejša ustrezna gradnja. Drugič druga kvantizacija. Pri nekaterih modelih pa je potreben poseben fork.

Nauk: več VRAM ne popravi nepodprtega formata.

10. Unsloth – tukaj postane zgodba nekoliko bolj akademska

Ko lokalni model že zna odgovarjati, se pojavi naslednje vprašanje.

Kaj pa, če bi ga želel tudi prilagajati?

Tu pride v igro Unsloth.

Unsloth je namenjen predvsem učinkovitemu učenju oziroma prilagajanju jezikovnih modelov, ne zgolj njihovemu poganjanju v pogovornem oknu.

Na prvi pogled je vse lepo.

Unsloth podpira različne sisteme, med drugim tudi AMD GPU-je.

Toda tu je pomembno prebrati še drobni tisk.

Uradni Windows vodič za Unsloth je osredotočen predvsem na CUDA/NVIDIA okolje. Za AMD obstaja poseben postopek z ROCm, ki temelji na Linuxu.

Zato se na svoji konfiguraciji nisem odločil mešati vsega v eno samo Windows Python okolje.

Za AMD eksperimentiranje je smiselnejša ločena Linux namestitev z ustreznim ROCm in PyTorch.

Osnovna priprava izoliranega okolja v Ubuntu:

sudo apt update
sudo apt install python3-venv python3-pip git -y

python3 -m venv ~/unsloth-env
source ~/unsloth-env/bin/activate

python -m pip install --upgrade pip

Nato je treba namestiti različico PyTorcha za ustrezno podprt ROCm in slediti posebnim navodilom Unsloth za AMD.

Tu namenoma ne priporočam univerzalnega ukaza, ki bi brez preverjanja nameščal poljubne kombinacije PyTorcha, Tritona in ROCm.

To je odličen način za izdelavo zbirke sporočil o napakah, precej slabši pa za izdelavo delujočega AI okolja.

Pravilno zaporedje je:

1. Preveri, da Linux zazna obe grafični kartici.
2. Namesti združljiv ROCm.
3. Namesti in preveri ustrezno različico PyTorcha.
4. Ustvari izolirano Python okolje.
5. Namesti Unsloth po AMD navodilih.
6. Najprej preizkusi manjši model, šele nato se loti večjih eksperimentov.

Windows mi tako služi kot priročno delovno okolje za razvoj in uporabo modelov, Ubuntu pa kot drugi del laboratorija za tiste trenutke, ko želim nekoliko bolj neposredno delati s programskim skladom AMD.

Dva operacijska sistema.

Dve grafični kartici.

In še vedno samo ena tipkovnica.

11. Triki, ki so mi pomembnejši od sintetičnih rekordov

Sčasoma sem ugotovil, da lokalni AI ni samo vprašanje moči grafičnih kartic.

Precej pomembnejša je celotna konfiguracija.

Ne začni takoj s 128K kontekstom

Velik kontekst je privlačen.

Kdo si ne bi želel modelu naenkrat predložiti polovice projekta in ga prositi, naj najde tisto eno napako?

Toda večji kontekst pomeni dodatno porabo pomnilnika in pogosto več dela pri obdelavi pozivov.

Zato najprej preizkusim 8K ali 16K, nato 32K in več, če model ter aplikacija to smiselno podpirata.

Kvantizacija ni samo velikost datoteke

Q4, Q5, Q8 in druge oblike kvantizacije predstavljajo različne kompromise med porabo pomnilnika, kakovostjo in hitrostjo.

Manjša datoteka ni nujno najboljša rešitev.

Prav tako večja datoteka ne zagotavlja boljšega rezultata v konkretni nalogi.

Zato modele preizkušam na dejanskih programerskih nalogah, ne zgolj z vprašanjem, koliko je dva plus dva.

Ne primerjaj samo tokenov na sekundo

Hitrost generiranja je zanimiva metrika.

Vendar ni edina.

Pomembni so tudi čas do prvega tokena, hitrost obdelave vhodnega besedila, poraba VRAM, stabilnost in seveda kakovost odgovora.

Model, ki napiše napačno kodo s 150 tokeni na sekundo, je lahko precej manj uporaben od počasnejšega modela, ki nalogo pravilno reši.

Ne nameščaj vseh modelov naenkrat

To je predvsem nasvet samemu sebi.

Ko začneš brskati po Hugging Face, hitro dobiš občutek, da potrebuješ vsak drugi model.

Tega pa ne potrebujem.

Potrebujem manjši nabor modelov, za katere vem, kaj znajo, koliko pomnilnika porabijo in za katere naloge so uporabni.

Vse ostalo je zbirateljstvo.

Kar je sicer lep hobi, vendar NVMe SSD-ji o tem običajno nimajo prav lepega mnenja.

Zapisuj delujoče kombinacije

Za vsak stabilen preizkus si je vredno zapisati:

• različico gonilnika in runtime okolja,
• model ter njegovo kvantizacijo,
• nastavljeno velikost konteksta,
• uporabljeni GPU oziroma način razdelitve,
• porabo pomnilnika in dosežene zmogljivosti,
• posebne nastavitve in morebitne napake.

To mi omogoča, da lahko naslednji teden ponovim uspešen poskus, namesto da ob polnoči razmišljam, kaj sem prejšnji petek naredil drugače.

12. Moj recept za zdrav Windows AI-laboratorij

Če bi danes celotno pripravo ponavljal od začetka, bi se držal tega zaporedja:

1. Varnostna kopija in preverjanje diskov ter zagonskih particij.
2. Čista namestitev Windows 11.
3. Windows Update in ponovni zagoni.
4. AMD X570 chipset in potrebni gonilniki matične plošče.
5. AMD Adrenalin in preverjanje obeh RX 7900 XTX.
6. Preverjanje BIOS, RAM in PCIe konfiguracije.
7. Odstranitev nepotrebnih aplikacij in ureditev zagona.
8. Namestitev PowerShell, Git, Python, VS Code in razvojnih orodij.
9. Namestitev LM Studio in prvi stabilen preizkus manjšega modela.
10. Priprava Vulkan oziroma HIP okolja za llama.cpp.
11. Preizkus lokalnega API in več-GPU izvajanja.
12. Ločena priprava Linux/ROCm okolja za Unsloth.
13. Merjenje, dokumentiranje in šele nato dodatne optimizacije.

Na koncu je bistveno, da imam računalnik, ki ga razumem, ne pa nekakšne zbirke programov, za katere upam, da se bodo po vsakem ponovnem zagonu še vedno razumeli med seboj.

13. In kaj sem na koncu pridobil?

Predvsem bolj urejeno osnovo.

Windows je namenjen vsakodnevnemu delu, razvoju, uporabi lokalnih modelov in preizkušanju različnih programskih orodij.

Grafični kartici nista več samo zmogljivi komponenti v računalniku, temveč del precej zanimivega domačega laboratorija.

V njem lahko preizkušam različne jezikovne modele, njihovo izvajanje, optimizacije, API-je in uporabo v lastnih programskih projektih.

Ali je lokalni AI vedno boljši od oblačnih storitev?

Ne.

Ali je vedno cenejši?

Tudi ne.

Ali je vedno hitrejši?

Niti približno.

Je pa nekaj, kar me pri vsej stvari še posebej privlači: možnost, da stvari razumem od začetka do konca.

Od strojne opreme, gonilnikov in operacijskega sistema do modela, njegovega pomnilnika in odgovora, ki se pojavi na zaslonu.

Seveda vse skupaj pomeni tudi nekaj več dela.

In nekaj več elektrike.

In občasno precej več guglanja, kot bi si človek želel.

Toda ko se lokalni model končno naloži, obe grafični kartici začneta delati in na zaslonu steče prvi odgovor, je občutek prav poseben.

Takrat za trenutek pozabim na vse napake, neuspešne gradnje in iskanje kompatibilnih knjižnic.

Za trenutek.

Potem pa se običajno pojavi nova različica llama.cpp.

In človek pomisli:

»Samo še to posodobim, potem pa res ne bom več ničesar spreminjal.«

Ja. Seveda.

---

Beast AI je moj domači računalniški laboratorij za raziskovanje lokalnih jezikovnih modelov, programiranje in preizkušanje tehnologij. To ni univerzalen recept za najhitrejši računalnik, temveč opis pristopa, pri katerem imajo stabilnost, razumljivost in ponovljivost prednost pred slepim lovljenjem benchmarkov.