Uruchamianie lokalnych dużych modeli językowych często zmusza do ograniczeń sprzętowych. Użytkownicy NVIDIA żyją w ekosystemie CUDA. Deweloperzy Apple wybierają Metal. Wszyscy inni mają nadzieję, że ich GPU obsługuje OpenCL lub po prostu przełączają się na CPU. Ta fragmentacja sprawia, że dostarczanie aplikacji AI na komputery stacjonarne jest trudniejsze, niż powinno być. TensorSharp właśnie powalczył z tym problemem, dodając backend Vulkan, co daje silnikowi wiarygodną ścieżkę obsługi różnych procesorów graficznych od różnych producentów.

Dlaczego Vulkan zmienia zasady gry

Vulkan jest zazwyczaj omawiany w kręgach gamingowych, ale jako niskonakładowe, międzyplatformowe API obliczeniowe, ma równie duże znaczenie dla wnioskowania (inference). Dociera do sprzętu, który CUDA ignoruje: zintegrowanych układów Intel UHD i Iris Xe, starszych kart dedykowanych oraz budżetowych laptopów z systemem Windows bez naklejki NVIDIA. Dla lokalnego silnika wnioskowania ten zasięg to praktyczna moc. Deweloper może dostarczyć pojedynczą ścieżkę binarną, która zadziała na znacznie większej liczbie maszyn, niż kiedykolwiek mogłoby to zrobić rozwiązanie oparte wyłącznie na CUDA.

Wsparcie dla Vulkan w TensorSharp zadebiutowało za pośrednictwem projektu GGML. Ta integracja jest obecnie funkcjonalna, choć autor planuje w przyszłości zbudować natywny backend Vulkan. Wykorzystanie GGML jako mostu było właściwym ruchem przygotowawczym. Waliduje to architekturę i natychmiast oddaje sprzęt w ręce testerów. Następnie pojawi się natywny backend, aby wyeliminować narzut abstrakcji i zapewnić silnikowi skoncentrowanemu na C# precyzyjniejszą kontrolę nad buforami poleceń (command buffers) i barierami pamięci (memory barriers).

Jak wygląda dotychczasowa powierzchnia testowa

Walidacja obejmuje już dwie bardzo różne konfiguracje systemu Windows. Deweloper przeprowadził testy na laptopowym GPU NVIDIA GeForce RTX 3080 oraz na zwykłej grafice Intel UHD. Oba działały dobrze. Ten zakres jest wart odnotowania. Dedykowane, wysokowydajne układy i podstawowa grafika zintegrowana rzadko tak łatwo tworzą wspólną, stabilną platformę testową w świecie wnioskowania. Jeśli korzystasz z lekkiego laptopa bez dedykowanego GPU, TensorSharp oferuje teraz realną ścieżkę akceleracji, która nie zależy od sterowników NVIDIA.

Luką w macierzy jest AMD. Żaden sprzęt Radeon nie został jeszcze przetestowany. Jeśli posiadasz GPU AMD, projekt potrzebuje Twojej opinii. Walidacja społeczności na kartach z serii RX 6000 lub 7000 to to, co zmienia eksperymentalny backend w rozwiązanie gotowe do użytku produkcyjnego. Zgłoś błąd (issue), jeśli coś nie działa. Zgłoś go, jeśli działa świetnie. Każdy wynik pcha projekt naprzód.

TensorSharp to nie jest wrapper

Ten punkt zasługuje na podkreślenie. TensorSharp nie jest bindingiem C# dla llama.cpp. Deweloper zbudował cały silnik od podstaw. Backend CPU to czysty C#. Gdy uruchamiasz wnioskowanie bez GPU, wykonujesz kod zarządzany (managed code), zamiast przesyłać dane przez interfejs funkcji obcych (FFI) do binarnego pliku C++. Projekt utrzymuje również dedykowane backendy dla CUDA, Apple MLX oraz GGML. Mimo tej niezależności architektonicznej, wydajność dorównuje llama.cpp, które pozostaje punktem odniesienia, do którego dążą większość lokalnych projektów wnioskowania. Ta równorzędność została ciężko wypracowana. Oznacza to, że układ pamięci, dyspozycja kerneli (kernel dispatch) i operacje na tensorach wytrzymują rzeczywiste obciążenie.

Obsługa modeli obejmuje Gemma4, DiffusionGemma oraz Qwen3.6. Runtime obsługuje również zadania multimodalne. Potoki (pipelines) wizji, audio i rozumowania działają w tym samym silniku. Jeśli prototypujesz asystenta stacjonarnego, który odczytuje zrzuty ekranu i przyjmuje komendy głosowe, nie musisz łączyć trzech oddzielnych runtime'ów i modlić się, aby ich zużycie pamięci zmieściło się w Twojej maszynie.

Elastyczność platformy i API

TensorSharp działa na systemach Windows, macOS i Linux. Nowy backend Vulkan idealnie wpisuje się w tę macierz obok istniejących ścieżek CUDA i Metal. Silnik oferuje również kompatybilność z API OpenAI oraz Ollama. Ten wybór eliminuje trudności z integracją. Możesz skierować istniejący kod klienta na lokalny serwer TensorSharp bez konieczności przepisywania szablonów promptów czy analizowania nowego formatu odpowiedzi. Dla zespołów, które już korzystają wewnętrznie z Ollama lub budują rozwiązania w oparciu o interfejs REST OpenAI, przejście na lokalną instancję TensorSharp sprowadza się głównie do zmiany adresu URL podstawowego (base URL).

Zapożyczone optymalizacje, które działają

Wydajność to nie tylko kwestia tego, które API komunikuje się z GPU. TensorSharp integruje kilka optymalizacji sprawdzonych w innych środowiskach produkcyjnych.

Paged KV cache, zapożyczony z vLLM, zapobiega gwałtownemu wzrostowi zużycia pamięci podczas długich konwersacji. Zamiast rezerwować jeden ciągły obszar roboczy (scratchpad) dla każdej sekwencji, silnik przydziela strony o stałym rozmiarze i mapuje je na żądanie. Możesz utrzymywać otwarte okna kontekstowe przez dłuższy czas, nie obserwując gwałtownych skoków zużycia pamięci RAM.

Continuous batching, również pochodzący z vLLM, zwiększa przepustowość. Silnik może wsuwać nowe zapytania do aktywnych partii zamiast czekać na zakończenie bieżącej grupy. Jeśli prompt jednego użytkownika ma dziesięć tokenów, a drugiego dwieście, sprzęt pozostaje bardziej obciążony, a średnie opóźnienie spada.

W przypadku modeli Mixture-of-Experts, TensorSharp implementuje strategię buforowania opartą na dyskach SSD, zaczerpniętą z oMLX. Często używane wagi ekspertów znajdują się na szybkim magazynie danych, zamiast rywalizować o pamięć RAM systemu. Na maszynach z ograniczoną pamięcią, ale przyzwoitymi dyskami NVMe, pozwala to na korzystanie z architektur MoE.

Kwantyzacja jest zgodna ze standardem GGUF ustalonym przez llama.cpp. Twoje skwantyzowane modele 4-bitowe i 5-bitowe ładują się bezpośrednio, bez konieczności etapu konwersji.

Najważniejsze wnioski

Wsparcie dla Vulkan zmienia TensorSharp z ciekawego eksperymentu w C# w praktyczną opcję wnioskowania (inference) dla heterogenicznego sprzętu. Mapa drogowa jest jasna: walidacja na dedykowanych układach AMD i Intel, a następnie dopracowanie implementacji dzięki natywnemu backendowi Vulkan. Jeśli masz kartę AMD w swojej stacji roboczej lub laptopie, uruchom build i podziel się wynikami. Taka pętla informacji zwrotnej sprawia, że eksperymentalny kod staje się czymś, co można udostępnić.

Szczegóły wydania znajdziesz w artykule dewelopera. Jeśli projekt oszczędzi Ci żonglowania zestawami narzędzi CUDA lub walki z blokadami wersji macOS, zostaw gwiazdkę w repozytorium. Aby wziąć udział w bieżących dyskusjach i wątkach testowych społeczności, grupa na Telegramie pozostaje otwarta.