Miért éri meg lokálisan futtatni az AI-asszisztenst?

Volt már úgy, hogy éppen belemelegedtél a kódolásba, aztán jött a hideg zuhany: lehalt az internet. A felhőalapú AI-asszisztensed instant használhatatlanná vált, és ott álltál a kóddal, fogalmad sem volt, mihez kezdj.

Nálam is megtörtént nemrég, és pont ez késztetett arra, hogy végre komolyan megvizsgáljam: vajon lehet-e teljes értékű AI kódolóasszisztenst futtatni teljesen lokálisan? Amit találtam, az meglepett: a megfelelő konfigurációval az Apple Siliconon meglepően jól teljesítő rendszer építhető, gyakran jobban, mint a Mac-re optimalizált megoldások.

A működő konfiguráció

Sok tesztelés és benchmarking után íme az a beállítás, ami a 64GB memóriás M1 Maxomon a legjobb eredményt hozta:

Alapvető stack:

• llama.cpp Metal gyorsítással
• Gemma 4 26B-A4B GGUF formátumban (Q4 kvantálás)
• Multi-Token Prediction (MTP) draft modell spekulatív dekódoláshoz
• Gemma 4 multimodális projektor képernyőképek kezeléséhez
• Pi terminál-alapú kódoló ügynökként

Ez nem a legbrutálisabb felállás, amit elméletileg ki lehetne hozni, viszont ez az, ami tényleg használható. Másodpercenkénti tokenekben mérjük a sebességet, nem percekben.

A számok, amik számítanak

Ugyanazt a promptot használtam minden konfigurációnál:

"Írj egy kompakt Python függvényt, ami egy unified diff-et dolgoz fel és visszaadja a módosított fájlok elérési útjait. Magyarázd el két edge case-t."

Mindegyik teszt körülbelül 128 tokent generált, így tisztességesen összehasonlítható volt a generálási sebesség.

Alap Teljesítmény:

Gemma 4 közvetlenül llama.cpp-n Metal-lal: 58.2 token/másodperc. Használható, de őszintén szólva? Kódolás közben, ahol többször hívsz eszközöket és vársz a válaszra, elég lomhának érezted.

Az MTP varázsa:

Itt jön a érdekes rész. A Multi-Token Prediction lehetővé teszi a modell számára, hogy több tokent "tippeljen" előre, elfogadja a helyes tippeket, és visszagörget, ha hibázott. Q8 MTP draft modellel: 72.2 token/másodperc — 24%-os javulás, minden más változatlan.

A prompt feldolgozási sebesség gyakorlatilag ugyanaz maradt (297-299 token/másodperc körül), de a generálási sebesség az, ami számít az ügynök-munkafolyamatoknál. Nem folyamatosan küldesz új promptokat — vársz, amíg a modell válaszol, döntéseket hoz, eszközöket használ.

1-6 draft token között teszteltem, és az M1 Maxomon a 3 draft token volt az optimális. 4 felett már lassulni kezdett — logikus, több spekuláció több elpazarolt munkát jelent, amikor a tippek rosszak.

llama.cpp kontra MLX: a meglepő győztes

Ami igazán meglepett: azt vártam, hogy az MLX (az Apple natív ML keretrendszere) dominál, hiszen kifejezetten az Apple Siliconra van optimalizálva. A valóság más volt.

| Runtime | Generálási tok/s | |---------|------------------| | llama.cpp Metal + MTP | 72.2 | | llama.cpp Metal | 58.2 | | MLX-LM (Unsloth 4-bit) | 45.8 | | MLX-LM (standard 4-bit) | 43.9 | | MLX-LM (OptiQ 4-bit) | 38.1 |

Llama.cpp MTP-vel ~58%-kal gyorsabb volt, mint a legjobb MLX konfiguráció. Az éveknyi optimalizálási munka, ami a llama.cpp-be került, kifizetődött — kiválóan fut macOS-en is, annak ellenére, hogy cross-platform projekt.

Képességek képességek: látás is kell

Egy rendes kódoló ügynökhöz kell a képernyőképek küldése. Talán látni akarod, mit épített, vagy ellenőrizni egy UI változtatást.

A bökkenő? Csak a Gemma 4 12B multimodális natívan. A 26B modell, amit használunk, mellé kell a külső multimodális projektor.

Amikor hozzáadtam a --mmproj projektort a llama.cpp-hez, az megfelelően hirdette a multimodális képességeket a Pi felé, és az image tool outputok helyesen kezdtek áramlani. Ami a legjobb: ez semmilyen mérhető lassulást nem okozott — a generálási sebesség maradt 72.2 token/másodperc.

A valós tapasztalat

Ehhez a beállításhoz nagyjából 17GB modell fájlra van szükség (16GB a fő modell, plusz az MTP fej és a projektor). Valakinek 64GB-os unified memory-val ez teljesen vállalható.

A Pi mint ügynök egy tiszta terminálos felületet biztosít, ami az OpenAI-kompatibilis API-hoz kapcsolódik, amit a llama.cpp server mode exponál. Ez azt jelenti, hogy bármilyen eszközzel használhatod, ami támogatja az OpenAI API formátumot — rugalmasság, nincs lock-in.

A legnagyobb előny? Amikor leáll az internet — és le fog, a lehető legrosszabb pillanatban — folytatod a kódolást. Az ügynök talán picit lassabb a felhős alternatíváknál, de elég reszponzív ahhoz, hogy ne akadjon meg a munkafolyamatod.

Hogyan kezdj neki?

Llama.cpp-t kell buildelni Metal támogatással. A projekt remek dokumentációval rendelkezik macOS buildeléshez, és ha megvan a fordítás, a server mode megadja az OpenAI-kompatibilis endpointot.

Modellek tekintetében az Unsloth GGUF kvantálásai a Hugging Face-en jól optimalizáltak. A fő modellhez Q4_K_XL kvantálást, a hozzá illő Q8 MTP draft modellt érdemes választani.

Hangold a --spec-draft-n-max értéket — 3-ról indulj, teszteld 1-től 6-ig, mi működik a te hardvereden. Különböző Apple Silicon konfigurációknál eltérő lehet az optimális érték.

Megéri?

Ha rendszeresen kódsz AI asszisztensekkel, és megvan a hardware (minimum 16GB, 32GB+ ajánlott), abszolút igen. Az internetfüggetlenség már önmagában sokat ér, és az MTP-vel a generálási sebesség olyan szintre jött, ami tényleg használható — meglepően kiforrott élményt nyújt.

Nem fogsz GPT-4 szintű intelligenciát kapni ezekből a nyílt modellekből, de kódkiegészítésre, refactoringra, debuggolási segítségre és általános kódoló ügynök feladatokra? Sokkal képesebb, mint amire sokan számítanak — és a tiéd, lokálisan fut, privátan, késleltetési spikes és szolgáltatás-kimaradások nélkül.

Az eszközök jelentősen érettebbek lettek. Ha korábban próbáltál lokális modelleket és csalódott voltál a sebesség miatt, adj egy esélyt ennek a konfigurációnak. Az MTP alapvetően megváltoztatja az egyenletet.