Bielik przyspiesza nawet pięciokrotnie. DFlash zmienia ekonomikę inferencji polskiego modelu

Przez ostatnie lata rywalizacja na rynku sztucznej inteligencji koncentrowała się przede wszystkim na skali. Twórcy zwiększali liczbę parametrów, rozbudowywali zbiory treningowe i porównywali wyniki modeli w kolejnych benchmarkach.

Upowszechnienie produkcyjnych wdrożeń AI stopniowo zmienia jednak priorytety.

Dla przedsiębiorstwa nie liczy się już wyłącznie to, czy model potrafi poprawnie odpowiedzieć na pytanie. Znaczenie mają również czas generowania, liczba jednocześnie obsługiwanych użytkowników, zapotrzebowanie na pamięć GPU oraz koszt przetworzenia każdego zapytania.

Właśnie zwiększeniu szybkości inferencji i efektywności wykorzystania infrastruktury służy rozwiązanie opracowane przez Fundację SpeakLeash, rozwijającą rodzinę polskich modeli Bielik.AI, oraz Akademickie Centrum Komputerowe Cyfronet AGH.

Zespoły stworzyły dwa modele draftowe: Bielik-11B-v3.0-DFlash oraz Bielik-Minitron-7B-v3.0-DFlash. Są to pierwsze w Polsce rozwiązania tego rodzaju wykorzystujące technologię DFlash.

Nie działają one samodzielnie. Współpracują z głównymi modelami Bielik i przygotowują dla nich fragmenty potencjalnych odpowiedzi. Model docelowy sprawdza następnie te propozycje i zatwierdza tokeny, które pokrywają się z wynikiem jego własnych obliczeń.

W zależności od zadania rozwiązanie może kilkukrotnie zwiększyć szybkość generowania odpowiedzi.

– W zależności od zadania można uzyskać przyspieszenie od 2 do nawet 5 razy. Średnio to będzie zwykle przyspieszenie około 2-3 razy względem wyłączonego speculative decodingu. Dużo zależy od samego zadania, poziomu trudności, długości odpowiedzi. Dla prostych zadań, strukturalnych czy długich odpowiedzi, zwykle uzyskamy większe przyspieszenie – mówi w rozmowie z tek.info.pl Krzysztof Ociepa, Head of Model Training w Bielik.AI.

Największe korzyści pojawiają się więc tam, gdzie model draftowy może trafnie przewidzieć dłuższy fragment wypowiedzi. Dotyczy to między innymi odpowiedzi o powtarzalnej strukturze, prostszych poleceń oraz długich generacji.

W takich scenariuszach główny model nie musi osobno przeprowadzać pełnego procesu generowania każdego kolejnego tokenu.

DFlash zamiast bardziej rozpowszechnionego EAGLE3

DFlash należy do metod speculative decoding, czyli dekodowania spekulatywnego. Ich zadaniem jest przyspieszenie inferencji bez zmiany odpowiedzi zwracanej przez model docelowy.

W klasycznym podejściu model językowy generuje odpowiedź token po tokenie. Każdy nowy element wymaga kolejnego kroku obliczeniowego.

Speculative decoding wprowadza do procesu mniejszy model pomocniczy. Przygotowuje on propozycje kolejnych tokenów, które większy model może sprawdzić równolegle.

Twórcy Bielika zdecydowali się na DFlash zamiast szerzej wykorzystywanego rozwiązania EAGLE3. O wyborze przesądziła przede wszystkim wydajność technologii.

– W momencie publikacji informacji prasowej o modelach draftowych była to najbardziej wydajna i efektywna metoda speculative decodingu, dlatego wybraliśmy właśnie ją, zamiast dużo powszechniejszej metody EAGLE3 – wyjaśnia Krzysztof Ociepa.

Wybór nowej metody oznaczał jednocześnie konieczność zmierzenia się z brakiem dojrzałych narzędzi treningowych.

DFlash nie jest jeszcze technologią rozwijaną przez szeroki ekosystem gotowych frameworków. Zespół Bielik.AI musiał więc opracować własny sposób trenowania modeli draftowych.

Podstawą prac stał się framework ALLaMo, którego twórcą jest Krzysztof Ociepa. Narzędzie było już wcześniej wykorzystywane do trenowania modeli z rodziny Bielik.

– Metoda DFlash jest dość nowa, dlatego brakuje dobrych, sprawdzonych sposobów oraz frameworków do trenowania przy jej pomocy modeli draftowych. Z tego powodu opracowaliśmy własną metodę treningu, popartą dużą liczbą badań i testów. Skrócenie czasu generowania odpowiedzi za sprawą modeli DFlash było możliwe właśnie dzięki własnemu, autorskiemu frameworkowi ALLaMo, do którego sprawnie dopisaliśmy potrzebny kawałek kodu. Łatwość modyfikacji kodu treningowego pozwoliła nam efektywnie prowadzić badania i testować różne podejścia. Ze względu na to, że nasze modele trenujemy na frameworku ALLaMo, jego użycie do stworzenia draft modelu było dla nas naturalnym wyborem – mówi Head of Model Training w Bielik.AI.

Możliwość modyfikacji własnego kodu miała w tym przypadku kluczowe znaczenie. Zespół nie musiał dostosowywać prac do ograniczeń zewnętrznego narzędzia. Mógł szybko testować kolejne podejścia i wprowadzić do frameworka elementy potrzebne do obsługi nowej metody.

Projekt pokazuje tym samym szerszą zmianę zachodzącą w polskim ekosystemie AI.

Krajowe zespoły nie ograniczają się już wyłącznie do dostosowywania istniejących modeli lub budowania ich polskojęzycznych wersji. Coraz częściej rozwijają również własne narzędzia treningowe i technologie potrzebne do późniejszego uruchamiania modeli w środowiskach produkcyjnych.

Przyspieszenie nie zmienia odpowiedzi modelu głównego

Jedną z najważniejszych kwestii przy optymalizacji modeli językowych pozostaje wpływ przyspieszenia na jakość generowanych treści.

DFlash nie polega jednak na zastąpieniu większego Bielika mniejszym, mniej dokładnym modelem. Lekki model pełni wyłącznie funkcję pomocniczą. Przygotowuje draft, ale nie decyduje o końcowym kształcie odpowiedzi.

Każdy wygenerowany przez niego fragment trafia do modelu docelowego.

– Metoda DFlash, polegająca na połączeniu pracy dwóch modeli – lekkiego modelu draftowego i modelu docelowego, gwarantuje uzyskanie tej samej odpowiedzi, co w przypadku wykorzystania samego głównego modelu. Po wygenerowaniu draftu przez pierwszy model odpowiedź trafia do modelu głównego, który za jednym przebiegiem sprawdza wszystkie draftowe tokeny – nie weryfikuje pojedynczych słów, tylko całe fragmenty wypowiedzi. Podaje też, jakie tokeny sam by wygenerował oraz wskazuje ich miejsce. Model docelowy nie tworzy więc odpowiedzi od podstaw, tylko sprawdza draft przygotowany przez lekki model, co istotnie przyspiesza działanie Bielika. Jeśli w przypadku któregoś tokenu pojawi się niezgodność, draft zostaje odrzucony, począwszy od miejsca jej wystąpienia. Dzięki temu mechanizmowi mamy gwarancje, że zwracane tokeny są właśnie tymi, które wygenerował główny model. Średnio około 5 pierwszych tokenów draftowych jest zwykle akceptowanych, co podaje właśnie przyspieszenie na poziomie 2-3 razy – tłumaczy Krzysztof Ociepa.

Mechanizm akceptacji tokenów decyduje o tym, że wzrost prędkości nie wymaga kompromisu w jakości.

Jeśli propozycja modelu draftowego odpowiada temu, co wygenerowałby główny Bielik, system zatwierdza ją bez konieczności osobnego generowania każdego tokenu. Gdy pojawia się rozbieżność, odrzuca niezgodną część fragmentu.

Model docelowy przez cały czas zachowuje więc kontrolę nad odpowiedzią.

Średnio akceptowanych jest około pięciu pierwszych tokenów przygotowanych przez lekki model. To wystarcza, aby w typowych zadaniach uzyskać dwu- lub trzykrotny wzrost szybkości.

Około 3 GB VRAM zamiast kolejnych serwerów

Z punktu widzenia przedsiębiorstw kluczowe znaczenie ma nie sam mechanizm DFlash, lecz jego przełożenie na ekonomię wdrożenia.

Systemy AI działające w środowiskach produkcyjnych muszą często obsługiwać tysiące zapytań. Nawet niewielkie skrócenie czasu inferencji może więc ograniczyć kolejki, zwiększyć liczbę użytkowników obsługiwanych równolegle albo zmniejszyć zapotrzebowanie na kolejne akceleratory.

W przypadku modeli Bielik koszt uruchomienia dodatkowego modelu draftowego pozostaje stosunkowo niewielki.

– Wykorzystanie modelu draftowego nie wiąże się praktycznie z żadnym dodatkowym nakładem. Trzeba jedynie zaalokować dodatkowo około 3GB pamięci VRAM na karcie. W efekcie dostajemy średnio 2-3 razy szybsze odpowiedzi przy tym samym zużyciu zasobów, co oznacza, że efektywnie usprawniliśmy proces i obniżyliśmy koszty generowania odpowiedzi właśnie te 2-3 razy, lub więcej dla niektórych zadań. Można też na to spojrzeć z punktu widzenia wydajności, czyli wykorzystując te same zasoby obliczeniowe, możemy teraz wygenerować/przetworzyć 2-3 razy więcej danych – wskazuje Krzysztof Ociepa.

Dodatkowe około 3 GB pamięci VRAM może zatem przełożyć się na kilkukrotny wzrost przepustowości całego systemu.

Przedsiębiorstwo może wykorzystać tę przewagę na dwa sposoby.

Pierwszy to skrócenie czasu oczekiwania użytkownika na odpowiedź. Ma to znaczenie szczególnie w chatbotach, asystentach głosowych, narzędziach wspierających pracowników oraz aplikacjach czasu rzeczywistego.

Drugi wariant polega na obsłudze większej liczby zapytań bez rozbudowy infrastruktury.

W tym przypadku wzrost szybkości pojedynczej generacji przekształca się bezpośrednio w większą przepustowość. Ten sam sprzęt może przetworzyć dwu- lub trzykrotnie więcej danych.

Dla dużych wdrożeń właśnie ten efekt może być ważniejszy niż skrócenie odpowiedzi o kilka sekund. Oznacza bowiem możliwość obsługi większej liczby klientów bez zakupu kolejnych kart GPU i zwiększania kosztów centrum danych.

Integracja sprowadza się do dodatkowego argumentu

Technologia optymalizacyjna ma wartość biznesową tylko wtedy, gdy można ją wdrożyć bez długiej i kosztownej przebudowy istniejącego środowiska.

Modele draftowe Bielika współpracują z vLLM i SGLang. Są to silniki inferencji wykorzystywane do uruchamiania i obsługi modeli językowych.

Według zespołu integracja DFlash nie wymaga zasadniczych zmian po stronie klienta.

– Integracja z istniejącymi środowiskami opartymi na vLLM lub SGLang jest bardzo prosta. W zasadzie jedynym wymaganiem jest posiadanie względnie nowych wersji tych silników inferencji - vLLM (wersja > 0.20.0) i SGLang (wersja > 0.5.6). Samo uruchomienie modelu draftowego to kwestia dodania dodatkowego argumentu przy uruchomieniu. Przykład uruchomienia opisaliśmy na kartach naszych modeli draftowych w serwisie HuggingFace – mówi Ociepa.

Modele Bielik-11B-v3.0-DFlash i Bielik-Minitron-7B-v3.0-DFlash nie są przeznaczone do samodzielnego generowania treści. Działają jako adaptery wspierające odpowiadające im modele docelowe.

Praktyczna integracja wymaga więc dobrania właściwego modelu draftowego do głównego Bielika oraz uruchomienia obu elementów w kompatybilnym środowisku inferencyjnym.

Niski próg wdrożenia może mieć duże znaczenie dla firm, które korzystają już z vLLM lub SGLang. Nie muszą zmieniać całej architektury. Mogą dodać model pomocniczy do istniejącego stosu technologicznego.

Duże modele nie znikną. Muszą jednak działać wydajniej

Rozwój technologii takich jak DFlash wpisuje się w szerszą dyskusję o przyszłości modeli językowych.

Pierwsza faza rozwoju generatywnej AI była zdominowana przez skalowanie. Większe modele, trenowane na większych zbiorach danych i przy użyciu coraz większej mocy obliczeniowej, osiągały lepsze wyniki w coraz szerszym zakresie zadań.

Jednocześnie rosły jednak koszty treningu oraz późniejszego uruchamiania modeli.

Rynek nie rezygnuje dziś z dużych systemów. Zaczyna jednak poświęcać znacznie więcej uwagi ich efektywności.

– Oba kierunki rozwoju są bardzo ważne. Duże modele językowe często potrafią więcej i nadają się do wykorzystania w większej liczbie zadań. Małe, specjalizowane modele są też bardzo ważne, ale zwykle tworzy się je w oparciu o większy model, który musi najpierw powstać. Technologie takie jak DFlash pozwalają nam optymalizować etap inferencji, czyli generowania odpowiedzi na zapytania użytkownika. Dzięki nim możemy na słabszym sprzęcie uzyskać większą przepustowość (szybkość generowania). Jest to szczególnie istotne dla urządzeń typu DGX Spark czy innych mobilnych sprzętów, w przypadku których prędkość generowania jest zwykle dość niska, a dzięki DFlash możemy ją znacząco zwiększyć – ocenia Krzysztof Ociepa.

DFlash nie zastępuje więc prac nad rozwojem możliwości samych modeli. Optymalizuje etap, w którym wytrenowany system trafia do użytkownika.

Ma to szczególne znaczenie dla lokalnych wdrożeń AI.

Bielik.AI został zaprojektowany między innymi z myślą o uruchamianiu na własnej infrastrukturze przedsiębiorstw i instytucji publicznych. Takie podejście pozwala zachować kontrolę nad danymi, ale przenosi jednocześnie odpowiedzialność za wydajność na właściciela infrastruktury.

Firmy nie korzystają wówczas z praktycznie nieograniczonych zasobów globalnego dostawcy chmurowego. Muszą dopasować model do własnych serwerów, kart GPU lub urządzeń brzegowych.

Właśnie w takich środowiskach optymalizacja inferencji może przesądzić o opłacalności wdrożenia.

Zespół wskazuje między innymi urządzenia klasy DGX Spark i mobilne platformy AI. Na słabszym sprzęcie różnica między standardowym generowaniem a wykorzystaniem DFlash może zdecydować, czy system zapewni użytkownikowi akceptowalny czas odpowiedzi.

Kolejna technologia Bielika jeszcze latem

Publikacja modeli draftowych nie kończy prac zespołu SpeakLeash.

Twórcy Bielika śledzą rozwój nowych technik treningu i inferencji, ale równolegle pracują nad własnymi rozwiązaniami. Jedno z nich ma zostać pokazane jeszcze latem 2026 roku.

– Śledzimy i czytamy, co nowego pojawia się w obszarze modeli językowych. Sami też pracujemy nad własnymi rozwiązaniami. Mamy nadzieję, że kilka ciekawych rzeczy uda nam się w tym roku pokazać, a jedną z nich planujemy zaprezentować jeszcze latem. Na razie nie chcemy zdradzać więcej szczegółów, ale działamy zgodnie z planem i mogę wszystkich zapewnić, że Bielik.AI jeszcze nie raz mile zaskoczy obecnych oraz nowych użytkowników – zapowiada Krzysztof Ociepa.

Zapowiedź pokazuje, że zespół nie zamierza ograniczać rozwoju Bielika do kolejnych wersji modelu bazowego.

Coraz ważniejszym elementem ekosystemu stają się narzędzia i technologie otaczające sam model. Obejmują one sposób treningu, optymalizację działania, obsługę infrastruktury oraz mechanizmy pozwalające efektywniej wykorzystywać dostępne zasoby obliczeniowe.

To właśnie ten stos technologiczny może decydować o praktycznej wartości krajowego modelu językowego.

Od polskiego modelu do polskiego stosu AI

Pierwsza polska implementacja modeli draftowych wykorzystujących DFlash ma znaczenie wykraczające poza sam projekt Bielik.AI.

Pokazuje, że krajowy ekosystem zaczyna rozwijać technologie potrzebne na etapie produkcyjnego wykorzystania modeli. Nie chodzi już wyłącznie o stworzenie systemu, który dobrze wypada w testach lub obsługuje język polski.

Model musi również działać szybko, stabilnie i ekonomicznie.

– Uważamy, że modele draftowe są kluczowe dla produkcyjnych wdrożeń, ponieważ pozwalają na znaczne optymalizacje bez dodatkowych nakładów i kosztów. Mamy nadzieję, że nasze nowe modele pozwoliły empirycznie pokazać, jak duża jest to przewaga i staną się inspiracją oraz impulsem do dalszego rozwoju dla twórców innych modeli językowych – podkreśla Krzysztof Ociepa.

DFlash może więc pełnić podwójną rolę.

Z jednej strony poprawia parametry działania konkretnych modeli Bielik. Z drugiej pokazuje innym zespołom, że optymalizacja inferencji może przynieść większe korzyści produkcyjne niż kolejny niewielki wzrost wyniku w benchmarku.

Rynek modeli językowych wchodzi dziś w etap, w którym jakość odpowiedzi przestaje być jedynym kryterium przewagi.

Dla przedsiębiorstw liczy się również czas oczekiwania użytkownika, liczba obsługiwanych zapytań, zajętość pamięci VRAM i koszt infrastruktury. Model, którego nie można ekonomicznie skalować, pozostanie demonstratorem technologii. Nawet jeśli osiąga bardzo dobre wyniki w testach.

Bielik.AI próbuje odpowiedzieć właśnie na ten problem.

Dodatkowe około 3 GB pamięci VRAM ma pozwolić średnio dwu- lub trzykrotnie zwiększyć przepustowość, a w niektórych zadaniach nawet pięciokrotnie skrócić generowanie. Bez zmiany odpowiedzi głównego modelu i bez konieczności przebudowy całego środowiska.

To może być jeden z ważniejszych kierunków rozwoju lokalnych modeli AI. Nie wystarczy już bowiem stworzyć model, który potrafi odpowiadać. Trzeba jeszcze sprawić, aby robił to dostatecznie szybko i tanio, by przedsiębiorstwa mogły wykorzystać go na dużą skalę.