Czym jest DeepInfer? Silnik wnioskowania DeepSeek i części, których nie dostarczono

DeepInfer to framework inferencyjny opublikowany przez DeepSeek 16 października 2026 na licencji Apache-2.0 i obsługuje dokładnie jeden model: DeepSeek-V4.1-Flash, z DeepSeek-V4.1-Flash-1017 jako domyślnym checkpointem. Ten zakres jednego modelu to pierwsza rzecz, którą trzeba zrozumieć, ponieważ wyjaśnia niemal wszystko inne w repozytorium. To nie jest ogólny framework serwujący, który przypadkiem zawiera konfigurację DeepSeek. To ścieżka kodu, którą DeepSeek uruchamia w produkcji, zredukowana do części, które się uogólniają, i otwarcie przyznaje, co zostało wycięte: sama lista w README tego, czego potrzebuje kompletna usługa inferencyjna, a czego to wydanie nie zawiera, wymienia system pamięci podręcznej KV, rozdzielenie VE/Prefill/Decode oraz równoważenie obciążenia między replikami równoległymi względem danych. Otrzymujesz ścieżkę obliczeniową — jądra, równoległość, dekodowanie spekulatywne, harmonogramowanie, ustrukturyzowane wyjście. Nie otrzymujesz warstwy przechowywania i routingu, która sprawia, że ścieżka obliczeniowa jest tania w eksploatacji na skalę. DeepSeek mówi dlaczego: te komponenty są ściśle powiązane z wewnętrzną infrastrukturą, więc projekt opisano w opublikowanym dokumencie, podczas gdy kod pozostaje wewnątrz firmy.

Co tak naprawdę znajduje się w repozytorium

Opublikowana lista funkcji czyta się jak przegląd wąskich gardeł w obsłudze dużego modelu typu mixture-of-experts. Są tam udostępnione wcześniej przez DeepSeek biblioteki jąder — FlashMLA do uwagi, DeepGEMM do mnożeń macierzy, DeepEP do komunikacji expert-parallel, a także TileKernels i DeepSelect. Jest schemat równoległości: uwaga działa jako równoległość danych ze zrównoważoną równoległością kontekstu, część MoE działa jako równoległość ekspertów z modułem równoważenia obciążenia expert-parallel. Jest DSpark, stos dekodowania spekulatywnego, z długościami weryfikacji planowanymi, a nie ustalonymi na stałe. Jest SWA bounded replay, mechanizm, który sprawia, że pamięć podręczna uwagi z przesuwnym oknem nie wymusza pełnego ponownego obliczenia przy każdym chybieniu pamięci podręcznej. Jest asynchroniczne planowanie partii, wnioskowanie niezmienne względem partii z deterministycznym próbkowaniem oraz ustrukturyzowane wyjście ograniczane przez wyrażenia regularne, schemat JSON lub EBNF.

Punkt wejścia jest celowo niewielki. Po ustawieniu DEEPINFER_ACCELERATOR na nvidia lub odpowiednik Ascend i uruchomieniu build.sh, repozytorium dostarcza examples/offline_inference.py, który uruchamia domyślny checkpoint od początku do końca. DEEPINFER_HF_MODEL_DIR wskazuje mu inny katalog wag. Opublikowane benchmarki zmierzono na czterech GPU SM100 dla prefill i 64 GPU SM100 dla decode, co odpowiada kształtowi wdrożenia, dla którego napisano ten silnik, a nie demonstracji w formie laptopowej.

README podaje również, skąd pochodzi kod, co warto wiedzieć przed jego przeczytaniem. Silnik pierwotnie zbudowano głównie na vLLM, czerpiąc inspirację projektową z SGLang i TensorRT-LLM. To pochodzenie widać w strukturze — scheduler, interfejs paged attention i ścieżka próbkowania będą znajome każdemu, kto czytał te projekty — i wyjaśnia, dlaczego wydanie jest forkiem stosu serwowania, a nie architekturą napisaną od zera. To, co dodał DeepSeek, jest częścią specyficzną dla jego własnego modelu: rozdzielone wdrożenie, szeroka równoległość ekspertów wraz z jej balanserem, odtwarzanie w oknie przesuwnym i DSpark.

Czego nie zawiera i dlaczego ma to większe znaczenie

Trzy brakujące elementy nie są drobnymi pominięciami. Każdy z nich to system, który musi istnieć, zanim silnik obsłuży ruch produkcyjny, a każdy jest kosztowny na inny sposób.

• System pamięci podręcznej KV.Ponowne wykorzystanie prefiksów to miejsce, w którym w obciążeniu czatu kryje się większość oszczędności, ponieważ trafienie w pamięć podręczną zastępuje prefill. Bez magazynu pamięci podręcznej każde żądanie ponownie przelicza swój prompt. Własny opis DeepSeek przedstawia magazyn, którego używa: dedykowany klaster 3FS zamiast lokalnej pamięci hosta — właśnie po to, aby każda maszyna prefill mogła trafić w dowolny prefiks, a pojemność pamięci podręcznej można było skalować niezależnie od mocy obliczeniowej.

• Dysagregacja VE/Prefill/Decode. W README zauważono, że większość funkcjonalności po stronie silnika już istnieje w wydaniu; brakuje wdrożenia. Rozdzielenie enkodera wizji, prefill i decode pozwala dobrać rozmiar każdego etapu do jego własnego wąskiego gardła i kontrolować czas do pierwszego tokenu niezależnie od czasu między tokenami. To decyzja infrastrukturalna, a nie flaga.

• Równoważenie obciążenia między replikami z równoległością danych. DeepSeek uruchamia cztery balansery — prefill, decode, vision encoder i expert-parallel — i opisuje wszystkie cztery w artykule. Żadna część logiki routingu nie jest udostępniana. Bez niej flota replik jest tylko tak dobra, jak router, który przed nią postawisz, a naiwny router round-robin zniszczy współczynnik trafień pamięci podręcznej, który ten magazyn miał chronić.

Czytane razem, to pominięcie mówi, z jakim rodzajem artefaktu mamy do czynienia. DeepInfer to referencyjna implementacja ścieżki obliczeniowej, opublikowana po to, aby prace nad jądrami i szeregowaniem można było przejrzeć i ponownie wykorzystać, a nie dystrybucja, którą się instaluje i na którą kieruje się ruch.

Bramka sprzętowa jest prawdziwym filtrem

DeepInfer jest ukierunkowany na NVIDIA SM100 i Huawei Ascend 950. Nie ma ścieżki dla Ampere ani ścieżki dla Hopper, co wyklucza większość GPU w większości dzisiejszych klastrów. Reszta zestawu narzędzi jest równie konkretna: wyłącznie Linux, GCC 13 lub nowszy, Python 3.12, CUDA 13 dla NVIDIA lub CANN 9.2 dla Ascend. A wydań nie ma w ogóle — repozytorium miało zero opublikowanych wydań, gdy je czytano 21 października 2026 r., więc nie ma nic do pobrania i nic do przypięcia. Klonujesz je i budujesz względem własnego zestawu narzędzi.

Taka kombinacja jest nietypowa jak na wydanie open-source o tak dużym rozgłoszeniu i najlepiej odczytywać ją jako rzetelne określenie zakresu, a nie przeoczenie. Kernele w repozytorium są napisane pod konkretny zestaw instrukcji i konkretny interkonekt; liczby w README pochodzą z tego sprzętu. Przeniesienie ścieżki obliczeniowej o generację wstecz to dokładnie ten rodzaj pracy, który społeczność wykonuje szybko, a organizacja inżynierska nie może go obiecać. W ciągu kilku dni od wydania na GitHubie pojawił się port strony trzeciej przygotowany z myślą o starszych układach NVIDIA, co jest użytecznym sygnałem popytu i zupełnie żadnym sygnałem co do tego, czy opublikowane wartości przepustowości przetrwają ten port.

Architektura wdrożenia, na której faktycznie działa DeepSeek

Opis architektury to miejsce, w którym założenia repozytorium stają się czytelne. System jest zdezagregowany na enkoder wizji, prefill i decode oraz dedykowane węzły pamięci masowej. Prefill wykorzystuje paralelizm ekspertów od 2 do 8 wraz z dopasowanym paralelizmem danych, wybierając najmniejszą konfigurację, na jaką pozwala HBM. Decode działa odwrotnie: paralelizm ekspertów i paralelizm danych od 64 do 128, co DeepSeek nazywa Wide-EP, przy użyciu największej konfiguracji, na jaką pozwalają dostępne GPU. Paralelizm tensorowy i paralelizm kontekstu nie są w ogóle używane. Enkoder wizji działa na jednym GPU na instancję, przy czym zalecane są tańsze GPU, ponieważ to nie enkoder jest miejscem, w które idą pieniądze.

Najmniejsze wdrożenie, które ma sens, wynika z tych liczb. Będzie działać jeden GPU do prefillu i jeden GPU do dekodowania, a w praktyce stosunek między tymi dwiema pulami wynosi mniej więcej jeden do jednego. Ponieważ jednak dekodowanie wymaga 64 GPU lub więcej, aby uzyskać korzyść z równoległości ekspertów, najmniejszą wydajną jednostką jest 64 GPU do prefillu plus 64 GPU do dekodowania. To jest liczba, o której należy pamiętać, czytając jakiekolwiek twierdzenia o wydajności DeepInfer: liczby opisują wdrożenie na 128 GPU, a połowa z tego to jeden etap.

Rozdzielenie faz prefill i decode między centrami danych jest technicznie możliwe, ponieważ DeepSeek-V4.1-Flash znacząco kompresuje swoją pamięć podręczną KV, a własne wdrożenie DeepSeek faktycznie umieszcza węzły inferencyjne w różnych, ale sąsiadujących centrach danych. Budżet to około 400 Gb/s przepustowości połączeń międzysystemowych na osiem GPU, a opracowanie otwarcie mówi o koszcie niezawodności — światłowód między budynkami łatwo przeciąć.

Dlaczego decode jest tak szeroko rozpowszechniony?

Szeroka równoległość ekspertów to najdonioślejszy pojedynczy wybór w projekcie i łatwo ją błędnie odczytać jako sztuczkę skalowania. W warstwie mieszaniny ekspertów każdy token trafia do niewielkiej liczby ekspertów, więc koszt kroku dekodowania zdominowany jest przez przemieszczanie wag ekspertów i aktywacji, a nie przez intensywność arytmetyczną. Rozproszenie ekspertów na 64 lub 128 GPU zmniejsza ruch pamięciowy na krok wnoszony przez każdy GPU, co zwiększa liczbę tokenów na sekundę, jeśli — i to jest warunek — obciążenie ekspertów pozostaje równomierne. Do tego właśnie służy moduł równoważenia obciążenia w równoległości ekspertów.

Ustawienia DeepSeek są wystarczająco konkretne, by można je było skopiować. W przypadku prefill każda karta GPU przechowuje czterech nadmiarowych ekspertów poza tymi, które posiada; statystyki są zbierane w 100-krokowym oknie, a eksperci są przypisywani ponownie co 1000 kroków, przy czym wagi są tasowane w obrębie grupy za pośrednictwem współdzielonej pamięci NVLink. Zmierzona nierównowaga — najwolniejsza ranga podzielona przez średnią — wyniosła 1,074 w konfiguracji EP4/DP4 i 1,045 w konfiguracji EP2/DP2. W przypadku decode ustawienia są bardziej rozciągnięte: jeden nadmiarowy ekspert na kartę GPU, 1000-krokowe okno statystyk, ponowne przypisanie co 10 000 kroków oraz zmierzona nierównowaga na poziomie 1,090. Różnica między tymi dwoma przypadkami jest tu sednem. Prefill ma do czynienia z pracą skokową i niejednorodną i wymaga szybkiego równoważenia obciążenia; decode ma do czynienia ze stałym strumieniem i może pozwolić sobie na długie okno, więc rzadko równoważy obciążenie i prawie nic za ten przywilej nie płaci.

Strona routingu ma ten sam charakter. Żądania prefill są grupowane według łącznej długości kontekstu na cztery poziomy — poniżej 16K, od 16 do 64K, od 64 do 256K oraz 256K i więcej — a silniki są przypisywane do poziomów zgodnie z udziałem każdego poziomu w zapotrzebowaniu na moc obliczeniową w poprzedniej rundzie. W obrębie jednego GPU rozmiar fragmentu dla każdego kroku prefill nie jest stały: dopasowany kwadratowy model kosztów przewiduje, ile czasu zajmie krok przy danej liczbie tokenów sekwencji i już obliczonym prefiksie, a scheduler wylicza największy fragment, który mieści się w budżecie 32 768 tokenów w pozostałym czasie. Balanser dekodowania równoważy jednocześnie dwa wymiary: liczbę żądań i łączną długość KV cache, kierując krótkie żądania do GPU o niskiej współbieżności i długim cache, a długie żądania do GPU o małym cache. Podsumowanie samego DeepSeek dotyczące tego, ile to wszystko daje: około 80 procent idealnie zrównoważonego benchmarku offline.

Pamięć podręczna i kwestia trzech dni

Pamięć podręczna KV znajduje się w dedykowanym klastrze 3FS, a nie w lokalnej pamięci hosta, i ta decyzja kształtuje resztę projektu pamięci masowej. Dane są przechowywane z kodowaniem nadmiarowym 10+2, więc każda grupa kodowania przetrwa jednoczesną awarię dwóch węzłów; odczyt wysyła żądania do wszystkich 11 węzłów w grupie, a dowolne 10 odpowiedzi wystarcza do zdekodowania. Proces odśmiecania działa na każdym węźle pamięci masowej i usuwa wpisy zgodnie z LRU po przekroczeniu progu. Zalecany serwer ma 20 dysków SSD o pojemności 30,73 TB każdy i utrzymuje przepustowość co najmniej 40 GB/s odczytu i 5 GB/s zapisu, a jego pojemność pozwala przechować około 24 godzin danych na serwer. W praktyce klaster działa z około 14,4 TB logicznej pamięci podręcznej na każde aktywne GPU, przy czym pojemność fizyczna jest większa.

To właśnie w kwestii rezydencji uwidacznia się kompromis. Po stronie pamięci podręcznej nie ma logiki wygasania; TTL jest ustawiany po stronie pamięci masowej — na trzy dni dla ruchu agentów i siedem dni dla ruchu chatbotów — w klastrze mieszczącym około 100 petabajtów pamięci półprzewodnikowej. Podział ten wynika z faktu, że ruch chatbotów ma znacznie cięższy długi ogon trafień — niewielka część pamięci podręcznej jest odczytywana wielokrotnie, więc jej utrata kosztuje więcej ogólnego współczynnika trafień, niż sugerowałby wolumen. Zmierzony przez DeepSeek koszt skrócenia retencji chatbotów do trzech dni to 0,5–1 procent współczynnika trafień pamięci podręcznej. To niewielka liczba, która w rzeczywistości odpowiada dużej ilości ponownie obliczonego prefillu.

Uwaga z przesuwnym oknem ma osobny cache z innymi regułami. Cache SWA nie trafia do bloków stronicowanych; każda sekwencja zajmuje jedno miejsce o stałym rozmiarze w pamięci hosta, a w przypadku DeepSeek-V4.1-Flash przechowywane warstwy to pierwsze 20. Trwa tylko ten obszar — 20 warstw × 134 tokeny × 528 bajtów, co daje 1 415 040 bajtów na sekwencję w formacie MXFP8. Nic nie trafia do klastra pamięci masowej; pozostaje w pamięci maszyny, która to wygenerowała, a katalog w pamięci rejestruje, która maszyna co przechowuje, a trafienie między maszynami pobiera to z powrotem przez sieć VLAN 400 Gb/s.

Dwa mechanizmy, które generują kluczowe liczby

Ograniczone odtwarzanie jest bardziej interesujące z tych dwóch, ponieważ zamienia nieograniczony koszt w stały. Normalnie brak trafienia w pamięć podręczną okna przesuwnego oznacza ponowne obliczenie okna od początku, a koszt rośnie wraz z długością kontekstu i liczbą warstw. DeepSeek zamiast tego oblicza ponownie tylko ostatnie 128 tokenów i obcina okno uwagi do tego segmentu, tworząc przybliżoną pamięć podręczną SWA przy stałym koszcie. Po stronie enkodera całkowicie uniezależnia to długość trafienia w pamięć podręczną prefiksu od pamięci podręcznej SWA: jeśli brakuje pamięci podręcznej SWA, następuje odtworzenie ostatnich 128 tokenów trafionego prefiksu, podczas gdy pamięć podręczna bloków jest ponownie wykorzystywana bez zmian.

Strona dekodera jest miejscem, w którym oszczędność jest duża. W tej architekturze pamięć podręczna bloków warstw dekodera jest rzutowana ze stanu ukrytego ostatniej warstwy enkodera, więc tylko pamięć podręczna SWA dekodera musi być obliczana dla każdej warstwy — a dokładne jej odtworzenie oznaczałoby przepuszczenie ostatnich 2560 tokenów przez 20 warstw dekodera przy każdym prefillu. Odtworzenie zamiast tego 128 tokenów i użycie wyniku tylko do dekodowania, zamiast pozwolenia mu wejść do pamięci podręcznej prefiksu, niemal o połowę zmniejsza całkowite obliczenia prefillu. Ta pojedyncza zmiana jest warta więcej niż większość optymalizacji jąder, a do tego może ją wprowadzić tylko zespół, który jest właścicielem architektury modelu.

Wkład DSpark jest mniejszy i bardziej konwencjonalny. Tokeny robocze mają różne prawdopodobieństwa akceptacji w zależności od żądania i pozycji, więc weryfikowanie stałych pięciu wersji roboczych na krok marnuje moc obliczeniową na tokeny, które zostaną odrzucone. Głowica pewności przewiduje wskaźnik akceptacji każdego tokenu roboczego, a scheduler sortuje wersje robocze według oczekiwanego zwrotu i weryfikuje tylko prefiks, który maksymalizuje przepustowość. W środowisku produkcyjnym model roboczy nadal generuje pięć tokenów na krok; liczba weryfikowanych spada z 5,00 do od 3,2 do 4,4, czyli o około 30 procent, podczas gdy akceptowana długość prawie się nie zmienia — 3,29 wobec 3,20. Odczytane z danych benchmarku EP64/DP64 daje to o 4 do 7 procent większą przepustowość przy około 60 równoczesnych sekwencjach na rank. Przy dokładnie 60 przepustowość na rank wzrasta z 13 730 do 14 466 tokenów na sekundę. Poniżej około 16 równoczesnych sekwencji technika przynosi niewielką stratę netto, co warto wiedzieć przed jej wdrożeniem w przypadku wdrożenia o małym ruchu.

Co oznacza liczba 155 bilionów

Najczęściej cytowaną liczbą związaną z tym wydaniem jest pojedynczy klaster obsługujący 155 bilionów tokenów dziennie przy łącznym przychodzie wynoszącym 38 dolarów amerykańskich za godzinę GPU przy stawkach valley pricing. Obie części są raportowane przez dostawcę i żadna nie jest benchmarkiem, który można odtworzyć, co nie czyni ich nieinteresującymi — przychód na godzinę GPU to zasadniczo inny rodzaj twierdzenia niż liczba przepustowości, ponieważ łączy wykorzystanie, ceny i współczynnik trafień pamięci podręcznej w jednej linii. Jest to również liczba, którą najprawdopodobniej przytoczy się bez jej zastrzeżeń, dlatego zastrzeżenia warto zapisać: jeden klaster, stawki valley pricing, przychód, a nie koszt, oraz wartość zagregowana obejmująca prefill, decode i enkoder wizyjny.

Dwa mniejsze ujawnienia są bardziej bezpośrednio przydatne. W publicznym repozytorium w jądrze dekodowania FlashMLA brakuje jednej ręcznie dostrojonej optymalizacji asemblera, którą ma wersja wewnętrzna, co w izolacji czyni je o 5 do 10 procent wolniejszym; DeepSeek twierdzi, że różnica w wydajności end-to-end wynosi co najwyżej 5 procent. A wewnętrzny model roboczy do dekodowania spekulatywnego jest nowszy niż opublikowany, a różnicę w wydajności opisano jako niewielką. Oba stwierdzenia określają oczekiwania co do tego, jak dużą część opublikowanej wydajności strona trzecia może osiągnąć, kopiując kod, a odpowiedź brzmi: większość, pod warunkiem że sprzęt jest zgodny.

Repozytorium w obecnym stanie

Powyższy zrzut ekranu wykonano 21 października 2026 r. i pokazuje on stronę z liczbą 16,3 tys. gwiazdek. Odpytywane tego samego dnia GitHub API zwróciło 16 590 gwiazdek, 1649 forków i 176 otwartych zgłoszeń, przy czym zgłoszenia były wyłączone, a dyskusje przekierowano do GitHub Discussions. Liczba gwiazdek od tego czasu stale rosła, więc każdą podaną tu liczbę należy czytać jako znacznik czasu, a nie właściwość kodu. Ruch o takiej skali w ciągu niespełna tygodnia mówi więcej o zainteresowaniu stosem serwującym DeepSeek niż o gotowości kodu, a resztę dopowiada zerowa liczba wydań.

Jeśli zastanawiasz się nad uruchomieniem tego samodzielnie

Szczera konkluzja jest taka, że DeepInfer warto uważnie przeczytać, ale trudno go obsługiwać. Cztery pytania pozwolą ustalić, czy to rozwiązanie dla Ciebie.

• Czy masz SM100 lub Ascend 950? Wszystko inne w łańcuchu narzędzi wynika z tego jednego. Bez odpowiedniego akceleratora publikowane liczby nie przenoszą się, a porty społecznościowe są niezweryfikowane w skali produkcyjnej.

• Czy można uruchomić 64 GPU do dekodowania w jednej domenie komunikacji? Szeroki parallelizm ekspertów to nie optymalizacja, którą można pominąć; to konfiguracja, wokół której zaprojektowano ścieżkę dekodowania. Poniżej tej skali uruchamiasz inny system o tej samej nazwie.

• Czy masz już pamięć podręczną prefiksów? Jeśli nie, porównujesz ścieżkę obliczeniową DeepInfer z konkurencyjnym stosem, który zawiera taką pamięć, a porównanie wypadnie gorzej, niż na to zasługuje projekt.

• Czy stać Cię na napisanie warstwy routingu? Grupowanie prefill, równoważenie dekodowania i ponowne przydzielanie ekspertów są opisane wystarczająco dobrze, by można je było ponownie zaimplementować, a ponowna implementacja to tygodnie pracy, których repozytorium nie wykona za Ciebie.

Jeśli wolisz nie posiadać żadnego z powyższych

Dla większości zespołów praktycznym pytaniem nie jest, jak wdrożyć DeepSeek-V4.1-Flash, lecz gdzie go wywołać. Model jest dostępny przez kompatybilne API bez budowania klastra 128 GPU ani ponownego implementowania balansera obciążenia, i jest to ten sam model, którego architekturę opisuje ten artykuł — z tą samą obsługą kontekstu, tym samym zachowaniem w zakresie strukturyzowanych wyników, bez prac związanych z disagregacją.

Porównanie, którego należy dokonać, nie polega na tym, który silnik jest szybszy w abstrakcji, ponieważ publikowane liczby to dane deklarowane przez dostawców, zmierzone na sprzęcie, którego większość czytelników nie posiada. Chodzi raczej o to, czy obciążenie jest takie, że 3-dniowy TTL pamięci podręcznej i pula dekodowania 64 GPU zmieniają cenę, czy takie, w którym żądanie co kilka sekund przez API jest po prostu tańsze niż którakolwiek z opisanych powyżej operacji. W drugim przypadku — czyli w większości przypadków — właściwa ilość DeepInfer do użycia to zero, a właściwa ilość do przeczytania to całość. Zacznij od strony modelu DeepSeek V4.1 Flash, jeśli chcesz poznać endpoint; zacznij od README repozytorium, jeśli chcesz wiedzieć, co ten endpoint robi.