Atvirojo kodo DI modelių „forkų“ sprogimas ir kas laukia toliau

Per pastaruosius dvejus metus atvirojo kodo dirbtinio intelekto (DI) modeliai patyrė tikrą „forkų“ sprogimą. Kiekvienas naujas bazinis modelis – „Llama“, „Mistral“, „Gemma“, „Qwen“, „Phi“ ir kt. – per kelias savaites išsišakoja į dešimtis ar net šimtus modifikuotų versijų, pritaikytų siauresnėms užduotims, mažesniems resursams ar konkrečioms kalboms.

2026 m. viduryje tai jau nebe nišinis reiškinys, o viena svarbiausių technologijų tendencijų. Ji keičia DI inovacijų tempą, rinkos galių balansą tarp didžiųjų korporacijų ir bendruomenės bei tai, kaip DI integruojamas į produktus ir paslaugas – nuo „startuolių“ iki viešojo sektoriaus.

Kas yra „forkas“ DI kontekste ir kuo jis skiriasi nuo „fine-tune“?

Programinės įrangos pasaulyje „forkas“ – tai projekto atšaka: nukopijuoji kodą, vystai toliau savo kryptimi, neprivalai sinchronizuotis su originalu. DI pasaulyje sąvoka panaši, bet turi savų niuansų.

Forkas – kai pasiimi atvirojo kodo modelį (svorius, kodą, treniravimo konfigūraciją) ir sukuri naują liniją: pakeiti architektūrą, treniravimo duomenis, licenciją, pridėti naujų galimybių. Tai ne tik „uždėti sluoksnį“, o realiai pratęsti ar keisti modelio vystymą.
Fine-tune – kai tą patį bazinį modelį papildomai apmokinėji konkrečiai užduočiai: klientų aptarnavimo botui, medicininiams tekstams, programavimui ir pan. Dažnai tai daroma nekeičiant architektūros, tik koreguojant svorius.

Praktikoje riba plonytė: daugelis „forkų“ prasideda kaip paprastas „fine-tune“, bet vėliau įgauna savarankišką gyvenimą – atsiranda nauji vardai, atskiri „Hugging Face“ ar „GitHub“ repozitoriumai, kita bendruomenė.

Kodėl įvyko atvirojo kodo DI „forkų“ sprogimas?

Yra keli kertiniai veiksniai, kurie kartu sukūrė tobulą audrą.

1. Galingi atviri baziniai modeliai tapo standartu

2023–2025 m. laikotarpiu pasirodė keli kartai itin pajėgių atvirų arba pusiau atvirų modelių:

Meta „Llama“ šeima – viena pirmųjų, kuri realiai priartėjo prie komercinių uždarų modelių kokybės ir leido bendruomenei kurti šimtus atšakų.
Mistral – itin efektyvūs, kompaktiški modeliai, puikiai tinkantys „edge“ ir serveriams su ribotais resursais.
Google „Gemma“ – atviresnė alternatyva „Gemini“ ekosistemoje, greitai sulaukusi daug kalbinių ir programavimo orientuotų „forkų“.
Qwen, Phi, DeepSeek ir kt. – ypač Azijos rinkoje, kur atvirumas dažnai naudojamas kaip atsvara Vakarų uždariems modeliams.

Kai bazė tokia stipri, „forkinti“ tampa prasminga: galima specializuoti modelį neišradinėjant visko nuo nulio.

2. Infrastruktūra ir įrankiai supaprastino „forkinimą“

Iki 2022 m. DI modelių kūrimas reikalavo milžiniškų resursų ir retų kompetencijų. Dabar:

„Hugging Face“ suteikia centralizuotą vietą modeliams, duomenų rinkiniams ir treniravimo scenarijams – vienu mygtuku gali „forkinti“ ir publikuoti savo versiją.
„Lightning“, „Colab“, „Kaggle“, „RunPod“, „Modal“ ir kiti leidžia pigiai ar net nemokamai pasibandyti treniravimą.
LoRA, QLoRA, PEFT ir kiti metodai leidžia „fine-tuninti“ didelius modelius su vienu ar keliais GPU, užuot investavus šimtus tūkstančių į klasterius.
Quantizacija (pvz., 4-bit, 8-bit) leidžia paleisti modelius ant paprastesnių serverių ar net galingesnių asmeninių kompiuterių.

Rezultatas – „forkas“ iš sudėtingo mokslinio projekto tapo savaitgalio eksperimentu entuziastams ir realia strategija startuoliams.

3. Verslo poreikis personalizuotam DI

Įmonėms nepakanka „bendro“ DI, kuris „viską moka vidutiniškai“. Reikia:

modelių, išmanančių konkrečią industriją (teisė, medicina, logistika, gamyba);
modelių, prisitaikančių prie įmonės tono ir terminijos;
modelių, kurie gali veikti lokaliai, be duomenų siuntimo į išorę (privatumas, atitiktis reglamentams);
modelių, optimizuotų konkrečiai kalbai ar regionui (pvz., Baltijos šalims).

Atvirojo kodo „forkai“ leidžia tai pasiekti greitai ir pigiau nei kuriant nuo nulio ar mokant už kiekvieną API užklausą uždariems modeliams.

4. Licencijų ir reguliavimo spaudimas

ES DI aktas, privatumo reikalavimai (GDPR) ir nacionaliniai teisės aktai skatina organizacijas labiau kontroliuoti, kokie modeliai naudojami ir ant kokių duomenų jie mokomi. Atviras kodas ir „forkai“ suteikia:

skaidrumą – aiškiau matyti, kas ir kaip buvo daryta;
kontrolę – galima audituoti kodą, treniravimo procesą, keisti komponentus;
teisinį lankstumą – pasirinkti licencijas, suderintas su įmonės politika ir rizikos apetitu.

Populiariausi atvirojo kodo DI „forkų“ tipai

Ne visi „forkai“ vienodi. Išryškėjo kelios aiškios kategorijos.

1. Kalbiniai ir regioniniai „forkai“

Šie modeliai pritaikomi konkrečioms kalboms ar regionams. Pavyzdžiai:

modeliai, stipriai apmokyti vokiečių, prancūzų, ispanų kalboms, kad pasiektų ar viršytų anglų kalbos kokybę;
regioniniai modeliai, orientuoti į Skandinaviją, Baltijos šalis, CEE rinkas;
„forkai“, kurie integruoja vietinius teisinius, mokesčių, medicininius šaltinius.

Lietuvos ir Baltijos kontekste tai ypač aktualu: bendruomenės projektai kuria lietuvių kalbai draugiškesnes LLM versijas, nes globalūs modeliai dažnai rodo prastesnius rezultatus mažesnėms kalboms.

2. Domeno specifiniai „forkai“

Šie modeliai giliai specializuojasi konkrečioje srityje:

Code LLM – modeliai, optimizuoti programavimui, „debugginimui“, kodo generavimui ir testų rašymui;
Mediciniai modeliai – skirti klinikiniams tekstams, tyrimų santraukai, sprendimų palaikymui (su griežtais saugumo filtrais);
Teisiniai modeliai – orientuoti į sutarčių analizę, teisės aktų paiešką, dokumentų rengimą;
Finansiniai modeliai – ataskaitoms, rinkos analizei, rizikos vertinimui.

Dažnai tokie „forkai“ turi papildomus saugumo, faktų tikrinimo ir atsakomybės apribojimus, nes dirba su aukštos rizikos informacija.

3. Lengvieji ir „edge“ įrenginiams skirti „forkai“

Didelis modelis nėra visada geras modelis. Sparčiai auga:

mobilieji modeliai, kuriuos galima paleisti telefone ar planšetėje;
„on-premise“ versijos, veikiančios įmonės serveriuose be ryšio su išoriniu debesimi;
„edge“ modeliai, skirti IoT, gamybos linijoms, robotams.

Tokie „forkai“ dažnai stipriai kvantuojami, apkarpyti, turi mažiau parametrų, bet yra pakankamai geri konkrečioms užduotims, kaip teksto klasifikavimas, paprasti dialogai ar santraukos.

4. Eksperimentiniai ir moksliniai „forkai“

Mokslininkai ir entuziastai naudoja „forkus“ kaip laboratoriją:

bando naujas architektūras (mišrūs ekspertai, ilgalaikė atmintis, multimodalumas);
eksperimentuoja su instrukcijų derinimu, RAG, reinforcement learning iš žmogaus grįžtamojo ryšio (RLHF);
tiria šališkumą, saugumą, paaiškinamumą ir kuria metodus jiems mažinti.

Šie „forkai“ dažnai netampa komerciniais produktais, bet idėjos iš jų greitai persikelia į verslo pasaulį.

Nauda kūrėjams, verslui ir visuomenei

Greitesnė inovacija ir mažesnės kliūtys startuoliams

Atvirojo kodo DI „forkai“ drastiškai sumažino įėjimo barjerą:

startuoliai gali kurti produktus ant egzistuojančių modelių, investuodami į nišinius patobulinimus;
mažos komandos gali pasiekti anksčiau tik „Big Tech“ įmonėms prieinamą DI lygį;
mokslininkai ir universitetai gali eksperimentuoti su realaus masto modeliais be milžiniškų biudžetų.

Skaidrumas ir pasitikėjimas

Atviras kodas ir „forkai“ leidžia:

audituoti modelių elgesį, treniravimo procedūras, duomenų šaltinius (kai jie atskleidžiami);
įvertinti rizikas – nuo šališkumo iki dezinformacijos generavimo;
kurti pasitikėjimu grįstus sprendimus, ypač viešajame sektoriuje ir kritinėse srityse.

Technologinė nepriklausomybė ir lokalizacija

Valstybės ir regionai vis labiau supranta, kad priklausomybė nuo kelių uždarų globalių tiekėjų kelia rizikų. Atvirojo kodo „forkai“ padeda:

kurti lokalius modelius, atitinkančius kalbą, kultūrą ir teisės aktus;
užtikrinti duomenų suverenitetą – jautrūs duomenys nelieka už šalies ribų;
skatinti vietinį inovacijų ekosistemų augimą.

Rizikos ir iššūkiai: kai „forkų“ būna per daug

„Forkų“ sprogimas turi ir tamsiąją pusę. Ne viskas, kas atvira ir gausu, automatiškai yra gerai.

Fragmentacija ir kokybės chaosas

Šiandien „Hugging Face“ ir kitos platformos pilnos tūkstančių modelių. Problemos:

sunku atsirinkti – daugelis modelių prastai dokumentuoti, be aiškių benchmarkų;
dubliavimasis – dešimtys labai panašių „forkų“, kurie realiai neprideda naujos vertės;
palaikymo trūkumas – dalis projektų greitai apleidžiami, negauna saugumo pataisų.

Verslui tai reiškia didesnes pasirinkimo ir integracijos sąnaudas – reikia DI ekspertų vien tam, kad nuspręstų, kurį modelį naudoti.

Saugumas, dezinformacija ir piktavališkas naudojimas

Atviri „forkai“ leidžia:

apeiti saugumo filtrus, pašalinti apsaugas, kurios riboja žalingo turinio generavimą;
specializuoti modelius dezinformacijai, phishingui, socialinei inžinerijai ir pan.;
kurti giliai personalizuotas manipuliacijas, derinant DI su viešai prieinamais duomenimis.

Reguliuotojai ir platformos bando atsakyti gairėmis, „atsakingo atvirojo kodo“ iniciatyvomis, bet balansas tarp inovacijų ir saugumo išlieka sudėtingas.

Licencijų spąstai ir teisinis neapibrėžtumas

Ne visi „forkai“ yra tikrai „laisvi“. Dažnos situacijos:

bazinis modelis turi ribojančią licenciją (pvz., draudžiama naudoti konkurenciniams produktams prieš kūrėją), o „forkai“ tai ignoruoja;
neaišku, kaip elgtis su autorių teisėmis į treniravimo duomenis ir jų paveldėjimu;
įmonės naudoja „forkus“ nežinodamos, kad pažeidžia licencijos sąlygas ir rizikuoja teisiniais ginčais.

Prieš diegiant atvirojo kodo DI modelį į komercinę aplinką, būtina bent bazinė teisinė analizė ir licencijos peržiūra.

Kaip protingai pasirinkti ir naudoti DI „forkus“?

Norint išnaudoti „forkų“ bumą, bet nesudegti, verta laikytis kelių principų.

1. Aiškiai apibrėžkite tikslą

Prieš renkantis modelį atsakykite:

Kokia užduotis? (dialogas, santraukos, kodas, klasifikavimas, analizė)
Kokios kalbos? (ar būtinas aukštas lietuvių kalbos lygis?)
Kokie resursai? (GPU, atmintis, ar galima naudoti debesį?)
Kokie saugumo reikalavimai? (ar tai sveikatos, finansų, vaikų duomenys?)

Tik tada verta eiti į modelių katalogus ir ieškoti „forkų“.

2. Vertinkite ne tik benchmarkus, bet ir bendruomenę

Renkantis modelį, svarbu:

ar modelis turi aktyvią bendruomenę ir palaikymą;
ar yra aiški dokumentacija, naudojimo pavyzdžiai;
ar pateikiami skaidrūs benchmarkai su aprašytais testais;
ar modelis reguliariai atnaujinamas (bugfix, saugumo pataisos).

Kartais geriau rinktis šiek tiek „silpnesnį“, bet aktyviai palaikomą „forką“, nei įspūdingus skaičius turintį, bet apleistą modelį.

3. Pradėkite nuo „proof-of-concept“ ir stebėkite elgesį

Net geriausias „forkas“ laboratorijoje gali elgtis kitaip realiame pasaulyje. Rekomenduojama:

sukurti ribotą pilotinį projektą (maža vartotojų grupė, ribotos funkcijos);
rinkti vartotojų grįžtamąjį ryšį ir pavyzdžius, kur modelis klysta;
naudoti papildomus filtrus (moderavimą, faktų tikrinimą, RAG su patikimais šaltiniais);
apibrėžti aiškias ribas, ką modelis gali ir ko negali daryti (pvz., nepriima galutinių medicininių sprendimų).

Ko tikėtis 2026–2028 m.: konsolidacija ar dar didesnis sprogimas?

DI ekosistema juda greitai, bet kelios tendencijos atrodo gana aiškios.

Standartizacija ir „modelių kilmės“ (angl. provenance) sekimas

Didėjant „forkų“ skaičiui, atsiras:

standartizuoti metaduomenys – aiškūs laukai, nurodantys, nuo ko modelis „forkintas“, kokie duomenys naudoti, kokios licencijos;
„modelių genealogijos“ įrankiai, leidžiantys atsekti, kaip vienas „forkas“ gimė iš kito;
reguliuotojų reikalavimai deklaruoti modelių kilmę aukštos rizikos srityse.

„Modeliai kaip platformos“ ir ekosistemų kova

Jau dabar matyti, kaip aplink tam tikras bazines šeimas („Llama“, „Mistral“, „Gemma“, „Qwen“) formuojasi savos ekosistemos. Tikėtina, kad:

kelios dominuojančios šeimos pritrauks daugumą „forkų“ ir įrankių;
atsiras „pluginai modeliams“ – standartizuoti moduliai atminčiai, RAG, saugumui;
verslas rinksis ne tik modelį, bet ir visą ekosistemą aplink jį.

Didesnis dėmesys energijos sąnaudoms ir tvarumui

Dideli modeliai – didelės sąnaudos. Artimiausiais metais:

„forkai“ bus vertinami ir pagal energetinį efektyvumą;
populiarės mažesni, bet protingesni modeliai, kuriuos galima derinti tarpusavyje;
atsiras tvarumo sertifikatai DI projektams, ypač viešajame sektoriuje.

Išvados: kaip šiandien nepraleisti DI „forkų“ revoliucijos?

Atvirojo kodo DI modelių „forkų“ sprogimas – ne laikina mada, o struktūrinis pokytis, kuris:

atveria DI galimybes mažesnėms komandoms ir šalims;
leidžia kurti giliai lokalizuotus ir personalizuotus sprendimus;
kartu kelia naujų saugumo, teisinių ir kokybės iššūkių.

Jei dirbate technologijų, verslo, viešojo sektoriaus ar akademinėje aplinkoje, prasminga jau dabar:

sukurti vidinę DI strategiją, apimančią atvirojo kodo modelius ir „forkus“;
investuoti į kompetencijas – nuo inžinierių iki teisininkų, suprantančių DI licencijas;
eksperimentuoti kontroliuotoje aplinkoje, kad suprastumėte, kas veikia jūsų kontekste.

Kas šiandien atrodo kaip chaotiškas „forkų“ miškas, rytoj taps nauja DI infrastruktūros norma. Klausimas nebe „ar naudoti atvirojo kodo DI“, o „kaip tai daryti atsakingai ir strategiškai“.

DUK: dažniausiai užduodami klausimai apie DI „forkus“

Ar atvirojo kodo DI „forkai“ gali prilygti uždariems modeliams?

Daugelyje užduočių – taip. Naujausi atviri modeliai (ypač specializuoti „forkai“) jau konkuruoja su komerciniais API sprendimais teksto generavimo, kodo rašymo, analizės srityse. Vis dėlto, pačios pažangiausios funkcijos (pvz., giliai integruotas multimodalumas, labai ilgas kontekstas) dažnai pirmiausia pasirodo uždaruose modeliuose. Optimalus kelias – derinti atvirus ir uždarus sprendimus pagal poreikį.

Ar saugu naudoti atvirojo kodo DI modelį versle?

Saugu tiek, kiek gerai suvaldote rizikas. Reikia įvertinti licenciją, duomenų srautus (ar nėra nutekėjimo į išorę), modelio elgesį jautriose situacijose, papildomas apsaugas (moderavimą, auditą). Daug įmonių sėkmingai naudoja „on-premise“ atvirus modelius, ypač ten, kur svarbus privatumas ir kaštų kontrolė, bet tai turi būti sąmoningai suplanuota, o ne „pasidaryk pats“ eksperimentas produkcinėje aplinkoje.

Kada geriau „forkinti“ egzistuojantį modelį, o kada kurti nuo nulio?

„Forkinti“ verta beveik visada, kai jūsų užduotis bent iš dalies panaši į tai, ką jau moka baziniai modeliai – bendras tekstas, dialogai, kodas, analizė. Kurti nuo nulio prasminga tik labai specifiniais atvejais: kai reikia ekstremalaus efektyvumo ant specialios įrangos, kai licenciniai ar saugumo reikalavimai neleidžia naudoti esamų modelių, arba kai siekiate mokslinio proveržio naujoje architektūroje. Daugumai verslo ir net mokslinių projektų „forkas + fine-tune“ yra racionaliausia strategija.