Splash: dlaczego silnik pisany pod konkretny model generuje szybciej i co tracisz w zamian

Przez ostatnie dwa lata lokalne uruchamianie modeli językowych wyglądało podobnie niezależnie od narzędzia. Bierzesz uniwersalny silnik, taki jak llama.cpp, Ollama czy MLX, pobierasz plik z wagami i możesz zacząć pracę. Ta wymienność była zaletą: jeden program, setki modeli.

W połowie września 2026 roku firma Inco AI wydała Splash, silnik, który odwraca tę logikę. Zamiast obsługiwać wszystko, skupia się na kilku wybranych modelach. Dla każdego z nich ma osobno przygotowane kernele GPU, plan pamięci i specjalnie wytrenowany drafter, czyli mały model przyspieszający generowanie. Według producenta taki zestaw generuje odpowiedzi od 1,7 do 5,3 raza szybciej niż konkurencja, w zależności od tego, z czym jest porównywany.

Czym jest Splash?

Splash to silnik inferencji open source, czyli program, który wykorzystuje już wytrenowany model i generuje odpowiedzi. Działa wyłącznie na komputerach Apple z procesorami M3 (lub nowszymi) i systemami macOS 26.4 (lub nowszymi). Kod jest dostępny na GitHubie na licencji Apache 2.0. Silnik uruchamia lokalny serwer zgodny z API OpenAI i Anthropic, więc podłączysz do niego narzędzia takie jak Claude Code czy Codex bez przepisywania integracji. Można też wybrać go jako eksperymentalny backend w LM Studio.

Pierwsze wydanie obsługiwało dwa modele: gęsty Qwen3.8-27B, w którym przy każdym tokenie pracują wszystkie parametry, oraz Qwen3.6-35B-A3B typu mixture of experts, w którym z 35 miliardów parametrów aktywnych jest tylko około 3 miliardów naraz. Obecna wersja 1.4.1 z 26 października obsługuje sześć rodzin modeli, ale zasada się nie zmieniła: każdy z nich dostaje własny zestaw optymalizacji, a żadnego spoza listy po prostu nie uruchomisz.

Dlaczego generowanie czeka na pamięć, a nie na obliczenia?

Model tworzy odpowiedź z kolejnych tokenów, czyli słów lub ich fragmentów. Przy generowaniu każdego z nich procesor graficzny musi odczytać z pamięci praktycznie wszystkie wagi, które w przypadku 4-bitowego Qwen3.8-27B zajmują około 15 GiB. Same obliczenia są stosunkowo tanie. Najdłużej trwa przesyłanie gigabajtów z pamięci do rdzeni, więc przez większość czasu GPU po prostu czeka na dane.

Mówi się wtedy, że dekodowanie jest ograniczone przepustowością pamięci. Wynika z tego prosta reguła: szybciej generuje ten silnik, który z jednego odczytu wag uzyska więcej tokenów albo przy każdym tokenie przeniesie mniej bajtów. Pierwszą z tych zasad realizuje dekodowanie spekulatywne. Z kolei na drugiej opiera się kwantyzacja, czyli zapisywanie wag z mniejszą precyzją. Splash idzie obiema drogami naraz, tyle że każdy element dopasowuje do konkretnego modelu.

Trzy rzeczy, które Splash robi pod konkretny model

Kernele GPU. To małe programy wykonywane na GPU, które mnożą macierze i wykonują obliczenia związane z mechanizmem uwagi. Uniwersalny silnik potrzebuje kerneli działających dla dowolnych rozmiarów macierzy, więc nie może założyć z góry, jak wyglądają dane. Splash zna dokładne kształty tensorów, czyli wymiary tablic liczb, z których składa się każdy obsługiwany model. Dlatego może łączyć kilka operacji w jeden kernel i nie zapisywać wyników pośrednich do pamięci.

Plan pamięci. Przy starcie silnik uwzględnia limit pamięci zalecany przez Metal, odejmuje stały koszt wag i draftera, a resztę przeznacza na cache rozmowy. Dla Qwen3.8-27B jest to odpowiednio 15 GiB wag i 1,2 GiB draftera. Silnik wie zatem z góry, ile równoległych zapytań obsłuży i jak długi kontekst zmieści.

Drafter. To element, który najwyraźniej odróżnia Splash od uniwersalnych silników.

Drafter wytrenowany pod jednego partnera

Dekodowanie spekulatywne polega na tym, że mały, szybki drafter proponuje kilka kolejnych tokenów, a duży model sprawdza je wszystkie w jednym przebiegu. Ponieważ duży model i tak musi odczytać wszystkie wagi, sprawdzenie siedmiu tokenów kosztuje niewiele więcej niż wygenerowanie jednego. Jeśli propozycja jest trafna, dostajesz kilka tokenów w cenie jednego odczytu. Jeśli nie, duży model odrzuca błędną część i tracisz tylko trochę czasu. Jak to wygląda w praktyce na MLX i kiedy potrafi zaszkodzić przy długich rozmowach, opisaliśmy w benchmarku inferencji na M4 Max.

Cały zysk zależy od tego, jak często propozycje draftera zostają przyjęte. Uniwersalny drafter zgaduje gorzej, bo nie zna nawyków konkretnego modelu, któremu pomaga. Splash używa techniki DFlash 2, rozwinięcia metody DFlash opisanej przez badaczy z zespołu z-lab. Drafter dla Qwen3.8-27B ma pięć warstw, zajmuje 1,2 GiB i czyta wewnętrzne stany modelu docelowego, a nie tylko gotowy tekst. W każdym kroku proponuje 7 tokenów. Według karty modelu duży model weryfikuje każdy z nich, więc spekulacja ma wpływać na szybkość, a nie na treść odpowiedzi.

Spekulacja pomaga najbardziej wtedy, gdy GPU ma wolne moce, czyli przy jednym użytkowniku. Pomiary DFlash 2 na karcie NVIDIA H200, które serwis Ground Truth przytacza za kartą modelu, pokazują, jak szybko zysk topnieje wraz z liczbą równoległych zapytań:

Przy 32 równoległych zapytaniach zysk w zwykłej rozmowie praktycznie znika, bo GPU nie ma już bezczynnego czasu do zagospodarowania.

Co pokazują liczby producenta?

Inco opublikowało porównanie z jednego komputera: M5 Pro z 48 GB pamięci i 16-rdzeniowym GPU. Splash zestawiono z silnikami oMLX, Lily i Ollama, a przy modelu 27B także z uzu, na zadaniach programistycznych z zestawu SPEED-Bench, z limitem 1024 tokenów odpowiedzi. Wszystkie poniższe liczby pochodzą od producenta, który sam wybrał konkurentów i warunki. Niezależnego benchmarku Splash na razie nie ma. Wykres pokazuje medianę szybkości generowania dla jednego zapytania przy krótkim prompcie i 32 tysiącach tokenów.

Najczęściej cytowane 210 tokenów na sekundę dotyczy modelu mixture of experts, który przy każdym tokenie czyta tylko niewielką część wag. Gęsty Qwen3.8-27B na tym samym sprzęcie osiąga 74 tokeny na sekundę. Przewaga nad najszybszym konkurentem przy krótkim prompcie wynosi według producenta 1,7 raza dla modelu 35B i 2 razy dla 27B. Wyższe mnożniki, od 2,5 do 5,3 raza, pochodzą z osobnego porównania z llama.cpp na identycznych plikach GGUF, gdzie llama.cpp nie ma wytrenowanego draftera.

Nie wszędzie różnica jest duża. Przy przetwarzaniu długiego promptu w modelu 27B karta modelu podaje przewagę zaledwie 1,2 raza nad silnikiem uzu. Ciekawiej wygląda ponowne użycie cache: przy powtórzonym prompcie o długości 32 tysięcy tokenów pierwszy token pojawia się po 282 ms, a w oMLX po ponad 2 sekundach. To dokładnie ta słabość, przez którą w naszych testach druga tura rozmowy była dwunastokrotnie wolniejsza. Producent uczciwie zaznacza, że próba powtarza identyczny prompt, więc pomija nowe tokeny, które dochodzą w prawdziwej rozmowie.

Jakie ograniczenia ma Splash?

Silnik pisany pod konkretne modele wymaga dodatkowej pracy przy przygotowaniu i utrzymaniu, żeby działać szybciej. Przed wyborem warto znać następujące ograniczenia:

• Krótka lista modeli. Splash nie wczyta pełnych modeli w BF16, F16 i F32, a obsługa własnych lub dostrojonych wersji jest dostępna „na zamówienie”.

• Przywiązanie do wersji. Według karty modelu paczka przygotowana dla Splash nie działa w innych silnikach. Wersja 1.3.1 zmieniła format i wcześniejsze paczki przestały się wczytywać.

• Nowy model to nowy drafter. Gdy wychodzi kolejna wersja modelu, ktoś musi wytrenować dla niej drafter i dopasować kernele. Dopiero wtedy można ją uruchomić w Splash.

• Jedna platforma. Tylko Apple Silicon od M3 wzwyż i macOS 26.4 lub nowszy. Bez Linuksa, Windowsa i kart NVIDIA.

• Mniejszy zysk pod obciążeniem. Gdy z silnika korzysta wiele osób jednocześnie, spekulacja daje mniej korzyści, a dobre wyniki Splash przy równoległych zapytaniach są w dużej mierze efektem zarządzania pamięcią i ich grupowania.

• Brak uwierzytelnienia domyślnie. Serwer nasłuchuje tylko na samym Macu, ale domyślnie nie wymaga żadnego klucza. Zanim udostępnisz go w sieci, ustaw zmienną SPLASH_API_KEY.

Żadne z tych ograniczeń nie dyskwalifikuje Splash. To po prostu inny rodzaj narzędzia: zamiast elastycznego warsztatu do testowania modeli dostajesz zestrojony zestaw do pracy z jednym z nich.

Co to oznacza dla firmy, która chce uruchamiać AI u siebie

Lokalny model ma dwie główne zalety: przetwarzane informacje nie opuszczają Twojej infrastruktury, a koszt nie rośnie z każdym zapytaniem. Dla firm, które pracują z umowami, dokumentacją techniczną albo danymi klientów, pierwszy argument często przesądza sprawę. Słabym punktem bywała wydajność, bo wolnego asystenta nikt nie chce używać. Splash pokazuje, że pojedynczy Mac może obsłużyć agenta programistycznego w tempie, które nie irytuje.

Wymagania sprzętowe są konkretne. Gęsty model 27B w wersji 4-bitowej potrzebuje co najmniej 36 GB pamięci zunifikowanej, a producent zaleca 48 GB lub więcej. Mniejsze warianty GGUF działają na Macach z 24 GB, kosztem jakości.

Krótko mówiąc, czym kierować się przy wyborze?

• Splash ma sens, gdy wiesz, jakiego modelu chcesz używać i jest on obsługiwany, a Twój sprzęt to Mac z procesorem M3 lub nowszym.

• Uniwersalny silnik jest lepszy, gdy często zmieniasz modele, korzystasz z modeli dostrojonych na własnych danych albo potrzebujesz serwera na Linuksie z kartami NVIDIA.

• Pomiar na własnych promptach jest potrzebny w obu przypadkach. Benchmark producenta na zadaniach programistycznych nie powie Ci, jak silnik zachowa się przy długich dokumentach albo przy dziesięciu osobach pracujących jednocześnie.

Szerszy trend jest wyraźny. Do tej pory uniwersalne silniki wygrywały, bo nowe modele pojawiały się co tydzień i nikt nie chciał czekać na optymalizacje. Teraz, gdy kilka otwartych modeli stało się standardem w zastosowaniach biznesowych, opłaca się dopasować oprogramowanie do jednego z nich. Ceną jest mniejsza swoboda wyboru.

W ZanReal projektujemy i utrzymujemy lokalne środowiska AI dla firm: od doboru modelu i sprzętu, przez pomiary na rzeczywistych danych, po integrację z narzędziami, których Twój zespół już używa. Rozważasz takie wdrożenie? Napisz do nas. Pomożemy ocenić, czy ma to sens w Twoim przypadku i od czego zacząć.