Ինչպես տեղադրել տեղական կոդի գործակալ macOS-ում Gemma 4-ով և llama.cpp-ով

Ինչու՞ գործարկել կոդի գործակալը տեղում

Քայլ Հաուելսը մի քանի անգամ մնաց առանց ինտերնետի և առանց կոդի գործակալի, ուստի երբ տեսավ «Gemma 4-ն այժմ MTP-ով 2 անգամ ավելի արագ է աշխատում» թարմացումը Multi-Token Prediction-ի մասին, որոշեց գործակալը գործարկել սեփական Mac-ում։

Պահանջները գործնական էին. բավականաչափ արագություն իրական աշխատանքի համար. OpenAI-ի հետ համատեղելի API, որ այլ գործիքները նույնպես կարողանան միանալ. և հնարավորության դեպքում պատկերների աջակցություն։

Ինչ փաթեթի վրա կանգնեց

Վերջնական կազմը. llama.cpp՝ Metal-ով կառուցված macOS-ում. Gemma 4 26B-A4B GGUF ձևաչափով. Q8 MTP սևագիր մոդել սպեկուլյատիվ վերծանման համար. Gemma 4-ի մուլտիմոդալ պրոյեկտորը. և Pi-ն՝ որպես տերմինալի կոդի գործակալ։ Փորձարկումը կատարվել է Apple M1 Max-ում՝ 64 ԳԲ միասնական հիշողությամբ և macOS 15.7.7-ով։

Հիմնական մոդելը gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf-ն է Unsloth-ի Hugging Face պահոցից՝ մոտ 16 ԳԲ. սևագիր մոդելի ու պրոյեկտորի հետ պանակը հասնում է մոտ 17 ԳԲ-ի։ Բենչմարկում օգտագործվել է մեկ հարցում՝ կոմպակտ Python ֆունկցիա, որը վերլուծում է unified diff. յուրաքանչյուր գործարկում գեներացնում էր մոտ 128 թոքեն։

MTP-ն գեներացիան արագացնում է ~24%-ով

Բազային llama.cpp-ն Metal արագացմամբ հասնում էր վայրկյանում 298.0 հարցման թոքենի և 58.2 գեներացիայի թոքենի՝ օգտագործելի, բայց դանդաղ գործակալի համար, որը շատ գործիքային կանչեր է անում։ Q8 MTP սևագիր մոդելի ավելացումը գեներացիան բարձրացրեց վայրկյանում 72.2 թոքենի։ Հաուելսը ստուգեց սևագրի երկարությունը 1-ից 6. ամենաարագը 3-ն էր (72.2), 2-ը գրեթե նույնն էր (72.0), իսկ ավելի մեծ արժեքները իջան 63.7-ի և 61.2-ի։ Հարցման մշակումը գրեթե չփոխվեց՝ մոտ 296 թոքեն/վայրկյան, ընդհանուր արագացումը՝ 1.24x։

Նա համեմատեց նաև MLX-LM-ը՝ սպասելով, որ Mac-ի սարքաշարում հենց այն կհաղթի. MLX-ի լավագույն գործարկումը հասավ վայրկյանում 45.8 թոքենի, իսկ համայնքային 4-բիթ տարբերակները ավելի դանդաղ էին՝ 43.9 և 38.1։ gemma-4-swift-mlx-ի միջոցով MTP-ի փորձը ձախողվեց, քանի որ 26B 4-բիթ MLX չեքփոյնթերը չէին համապատասխանում բեռնիչի սպասած կշիռների բանալիներին։

Պատկերներ, տեղադրում և Qwen այլընտրանքը

Սքրինշոթների համար llama.cpp սերվերին պետք է Gemma 4-ի մուլտիմոդալ պրոյեկտորը, քանի որ միայն 12B մոդելն է ի սկզբանե մուլտիմոդալ. պրոյեկտորը բեռնելուց հետո սերվերը հայտարարում է մուլտիմոդալ աջակցություն, և Pi-ն կարող է պատկերներ ուղարկել։ Pi-ի մոդելի գրառման մեջ նույնպես պետք է նշվեն և՛ տեքստը, և՛ պատկերը, հակառակ դեպքում պատկերով գործիքի արդյունքը մոդելին չէր հասնի։ Պրոյեկտորով տեքստային բենչմարկի կրկնակի գործարկումը դանդաղում չցուցաբերեց։

Կառուցումը ստանդարտ է. Homebrew-ով տեղադրեք cmake, git, tmux և Python 3.11, կոմպիլյացրեք llama.cpp-ն Metal-ով և Accelerate-ով, ներբեռնեք մոդելը, MTP սևագիրը և mmproj-BF16.gguf-ը, ապա գործարկեք llama-server-ը 127.0.0.1:8080 հասցեում --spec-type draft-mtp, --spec-draft-n-max 3 պարամետրերով և 65 536 թոքենի կոնտեքստով։ Այդպես ստացվում է OpenAI-ի հետ համատեղելի /v1 endpoint, որին Pi-ն հղում է իր models.json-ում։

Եզրակացությունը. MTP սևագիր մոդելը արժե օգտագործել. այն Gemma 4-ը բարձրացնում է վայրկյանում 58.2-ից 72.2 թոքենի և կազմաձևը թողնում է պարզ։ Նա նշում է Qwen3.6 35B-A3B-ին անցնելու խորհուրդը. բենչմարկները ցույց են տալիս, որ Qwen-ը ավելի լավ կոդի գործակալ է, բայց ավելի դանդաղ՝ մոտ 55 թոքեն/վայրկյան՝ Gemma 4-ի 72-ի դիմաց։