Lokalne wymagania DeepSeek: kompletny przewodnik

Zrozumienie wymagań DeepSeek

Czym są wymagania lokalne. Wymagania lokalne to miejsce na dysku, pamięć, system operacyjny i runtime, których potrzebuje jeden konkretny plik z wagami, zanim odpowie na prompt na twojej maszynie. Należą do pliku, nie do marki. DeepSeek publikuje otwarte wagi na licencji MIT w rozpiętości od jednobitowego builda V4-Flash o rozmiarze 82,5 GB po ośmiobitowego V4-Pro o rozmiarze 873 GB, i jedno, i drugie to DeepSeek.

Ta rozpiętość jest powodem, dla którego większość stron odpowiadających na to pytanie myli się już na starcie. Biorą jeden model, zwykle R1 z początku 2025, i podają progi VRAM bez nazwy kwantyzacji i bez rozmiaru pliku. Poradnik Jana o uruchamianiu R1 lokalnie to przykład podręcznikowy: sześć rozmiarów distillów, przy każdym liczba VRAM, bez nazwy builda i bez daty gdziekolwiek na stronie. Distill 14B i 32B dostają tam to samo "16 GB lub więcej", podczas gdy biblioteka Ollamy pokazuje tag 14B jako pobranie 9,0 GB, a 32B jako 20 GB. To dwa różne zakupy. Zacznij więc od ustalenia, o którym modelu mówimy, i zauważ, że dla lokalnych wdrożeń najciekawszą zmianą jest V4-Flash, pierwszy DeepSeek z rodziny flagowej mieszczący się w pamięci jednej maszyny.

Jeden przypis, zanim postawisz na V3.2-Speciale: karta modelu mówi, że jest on "designed exclusively for deep reasoning tasks and does not support the tool-calling functionality", co wyklucza go z pracy agentowej niezależnie od sprzętu pod spodem.

Dlaczego spełnienie wymagań systemowych ma znaczenie. Jeśli nie trafisz w liczbę, zwykle nie dostaniesz błędu, tylko wolną maszynę. Unsloth pisze o rodzinie 671B, że gdy pamięci brakuje, "hard drive / SSD offloading will work with llama.cpp, just inference will be slower." To "wolniej" zostało zmierzone: jeden token na sekundę dla R1-0528 w IQ1_S na 64 GB RAM bez GPU. Instalacja działa i jednocześnie nie nadaje się do użytku.

Dwie rzeczy mnożą wymaganie już po tym, jak je policzysz. Pierwsza to współbieżność. FAQ Ollamy mówi wprost, że równoległa obsługa żądań zwiększa rozmiar kontekstu o liczbę równoległych żądań, więc RAM skaluje się jako OLLAMA_NUM_PARALLEL razy OLLAMA_CONTEXT_LENGTH, a "for GPU inference, models must fit entirely in VRAM for concurrent loads". Setup, który działa dla jednej osoby, potrafi się wywrócić przy drugiej.

Druga to jakość kwantyzacji. Unsloth mierzy swoje buildy DeepSeek V4 dywergencją KL względem pełnej precyzji: UD-Q8_K_XL wychodzi około zera, UD-Q4_K_XL na 0,0102. Poniżej Q2_K_XL obraz się zmienia, a ich rekomendacja to unikać kwantyzacji jednobitowej w zastosowaniach agentowych, gdzie raportują "excessive looping, empty responses, and broken tool-calling". Jeśli w planie jest czterdziestokrokowa pętla narzędziowa, a nie okno czatu, warto to zmierzyć na własnych promptach.

Warto też wycenić alternatywę, zanim cokolwiek kupisz. Własne API DeepSeeka podaje dla v4-flash $0.22 za milion tokenów wejściowych przy cache miss poza szczytem i $0.66 za milion tokenów wyjściowych, przy czym poza szczytem to rabat 50%, a godziny szczytu to 01:00-04:00 i 06:00-10:00 UTC od poniedziałku do piątku. Hosting lokalny wygrywa tam, gdzie dane nie mogą opuścić firmy, czyli w praktyce przy RODO i umowach powierzenia. Nie wygrywa automatycznie na koszcie, a rachunek budowa kontra zakup zasługuje na osobną godzinę.

Wymagania sprzętowe

Minimalne wymagania sprzętowe. Wymagania sprzętowe DeepSeek dzielą się na dwie części, a to, w której jesteś, zależy od tego, czy chcesz prawdziwy model, czy jego distill. Dla rodziny flagowej Unsloth podaje 64 GB RAM dla R1-0528 w IQ1_S i mierzy to na jednym tokenie na sekundę, bez udziału GPU. To działa. Czy warto tego używać, to osobna decyzja.

Distille to drugi próg i to je w praktyce opisuje większość poradników "uruchom DeepSeek lokalnie". R1-0528-Qwen3-8B mieści się w systemach z 20 GB RAM lub więcej, a jego buildy GGUF idą od 2,27 GB w UD-IQ1_S do 8,71 GB w Q8_0. Tagi R1 w Ollamie zaczynają się od 1,1 GB przy 1.5b i kończą na 20 GB przy 32b oraz 43 GB przy 70b. To modele Qwen i Llama dostrojone na wyjściu R1, co karta modelu R1 mówi wprost, więc odpowiadają na łatwiejsze pytanie niż to z tytułu.

Po stronie oprogramowania jedyne minimum warte cytowania pochodzi od LM Studio: rekomendowane 16 GB RAM i co najmniej 4 GB dedykowanego VRAM na Windows. Ollama nie publikuje w dokumentacji żadnego minimum RAM, dysku ani CPU, cokolwiek twierdzą przepisywane w kółko zestawienia.

Rekomendowana specyfikacja sprzętowa. Tu liczby robią się użyteczne, bo Unsloth publikuje zmierzone pary, a nie okrągłe wartości. Dla 5 lub więcej tokenów na sekundę podaje 180 GB pamięci zunifikowanej albo łącznego RAM plus VRAM dla R1-0528 i 226 GB dla V3.1. Odpowiednik dla V4-Flash jest wyraźnie niższy: 110 GB RAM uciągnie build trzybitowy, a 169 GB pokrywa bezstratny ośmiobitowy. Kto wymiaruje maszynę na 2026 rok według strony o V3.1, przepłaca o jakieś 60 GB RAM bez żadnego zysku.

Mac Studio jest najprostszą odpowiedzią w jednej obudowie, bo pamięć zunifikowana liczy się w całości do tej sumy. M5 Max startuje z 36 GB i konfiguruje się do 48, 64 albo 128 GB; M5 Ultra startuje z 96 GB i idzie do 256 albo 512 GB, z przepustowością 1,2 TB/s w każdej konfiguracji. Sufit to zwykła arytmetyka: maksymalny M5 Ultra z 512 GB pomieści V4-Flash w 8 bitach z dużym zapasem i całą drabinkę V3.1 oraz R1 aż do UD-Q5_K_XL przy 481 GB, ale nie pomieści V4-Pro w 4 bitach, czyli 850 GB jeszcze przed kontekstem.

Wymagania sprzętowe DeepSeek V3. Rodzina 671B, czyli V3.x i R1, wciąż stoi za większością lokalnych wdrożeń i to o nią zwykle chodzi we frazie lokalne wymagania DeepSeek V3. Wagi V3.1 w pełnej precyzji zajmują 715 GB dysku. Kwanty dynamiczne Unsloth ściągają to do 170 GB na dole drabinki i dopiero tam zaczyna się realna rozmowa o wymaganiach DeepSeek V3.

Obie drabinki są opublikowane plik po pliku, dla V4-Flash i dla V4-Pro, a dwie osobliwości w nich wymagają wyjaśnienia. TQ1_0 figuruje jako 170 GB na stronie V3.1 i jako 162 GB na stronie R1-0528 przy tej samej nazwie kwantu, więc traktuj to jako zakres. A na V4 wersja czterobitowa jest ledwie mniejsza od ośmiobitowej, 155,1 GB wobec 162 GB, bo checkpointy V4 już wychodzą jako mieszanka FP4 i FP8, z wagami ekspertów w FP4. Dalsza kwantyzacja dotyka głównie tensorów spoza ekspertów, a to niewielki wycinek modelu MoE. Ten sam wzorzec na V4-Pro: 850 GB wobec 873 GB.

Kluczowe wymagania GPU i VRAM. Pytanie o wymagania GPU DeepSeek ma niewygodną odpowiedź po stronie sprzętu konsumenckiego: nic, co da się kupić, nie pomieści builda z rodziny flagowej. Linia GeForce kończy się na 32 GB w RTX 5090, z 16 GB w 5080, 5070 Ti i 5060 Ti oraz 12 GB w 5070. Przy pliku ważącym 155 GB to nie jest luka, którą domykasz drugą kartą.

Rola GPU zmienia się więc całkowicie. Zamiast trzymać model, trzyma gęste tensory i cache KV, podczas gdy wagi mieszanki ekspertów siedzą w RAM systemowym i stamtąd są strumieniowane. Unsloth zmierzył to na około 5 tokenach na sekundę dla dwubitowego kwantu V3.1 na pojedynczym GPU 24 GB ze 128 GB RAM, a ich build TQ1_0 w 1,66 bita celuje w ten sam kształt maszyny. Co przeformułowuje wymagania VRAM DeepSeek: pytanie brzmi, ile ścieżki gęstej utrzymasz rezydentnie, a nie czy zmieszczą się wagi.

Minima sterowników są konkretne i warto je sprawdzić, zanim obwinisz sprzęt. Ollama wymaga NVIDIA compute capability 5.0 lub wyżej ze sterownikiem 550 lub nowszym, 570 lub nowszym dla compute capability 5.0-6.2, oraz sterownika AMD ROCm v7 na Linuksie. vLLM wymaga compute capability 7.5 lub wyżej, a na układach Blackwell, jak B200 i GB200, minimum to CUDA 12.8.

Jeśli pytanie brzmi, na jakim sprzęcie DeepSeek faktycznie chodzi, gdy przestaniemy udawać, że to model na biurko, odpowiadają przepisy vLLM. V4-Flash jest zwalidowany na H200 w konfiguracji 8x192 GB, MI300X 8x192 GB, MI325X 1x256 GB, MI355X 4x288 GB, a także na B200, B300, GB200 i RTX PRO 6000 8x96 GB, serwując z checkpointu FP8 o rozmiarze 148,66 GiB. V4-Pro chce ośmiu GPU w węźle B300 albo H200 z równoległością danych i ekspertów, a na H200 kontekst trzeba przyciąć flagą --max-model-len 800000 zamiast puszczać pełny milion.

Wymagania systemowe

Zgodność z systemem operacyjnym. Wymagania systemowe DeepSeek to w praktyce wymagania runtime'u, bo DeepSeek dostarcza wagi i nic poza tym. Nie ma instalatora DeepSeeka. Instalujesz llama.cpp, Ollamę, LM Studio albo vLLM, a one różnią się w jednym miejscu, które regularnie zaskakuje.

Pułapką jest vLLM. To najszybsza droga do serwowanego endpointu DeepSeek, to pod niego pisane są oficjalne przepisy i nie uruchomisz go natywnie na Windowsie. LM Studio na macOS wspiera wyłącznie Apple Silicon od macOS 14.0, więc Mac na Intelu odpada niezależnie od ilości RAM.

Wymagane zależności programowe. vLLM chce Pythona od 3.10 do 3.13 i dostarcza binaria kompilowane domyślnie pod CUDA 12.9, z opcjami 12.8, 13.0 i 13.1. llama.cpp ma najszerszą listę backendów, obejmującą między innymi CUDA, Metal, HIP dla AMD, Vulkan, SYCL dla Intela i zwykły CPU, oraz wspiera kwantyzację całkowitoliczbową od 1,5 bita do 8 bitów, dzięki czemu każda drabinka GGUF w tym tekście w ogóle istnieje. Ollama dokłada Vulkan na Windowsie i Linuksie oraz Metal na sprzęcie Apple.

Konfiguracja i kroki instalacji. Pięć kroków w kolejności, która oszczędza pobieranie 155 GB dwa razy.

1. Zainstaluj runtime. Na Linuksie Ollama to jedna linia: curl -fsSL https://ollama.com/install.sh | sh, potem ollama serve i ollama -v dla potwierdzenia. llama.cpp też idzie już przez menedżery pakietów: brew install llama.cpp, winget install llama.cpp albo conda install -c conda-forge llama.cpp, a conda-forge niesie gotowe warianty CUDA, Vulkan i Metal. Buduj ze źródeł tylko dla backendu spoza pakietów: cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON, potem cmake --build llama.cpp/build --config Release -j, a na sprzęcie Apple ustaw -DGGML_CUDA=OFF, bo Metal jest włączony domyślnie.

2. Wybieraj build, nie model. Składnia referencji to nazwa repozytorium, dwukropek, wariant kwantyzacji: llama serve -hf unsloth/DeepSeek-V4-Pro-0813-GGUF:UD-Q4_K_XL. Aktualny szybki start llama.cpp to llama cli -hf <repo> i llama serve -hf <repo>; poradniki pokazujące llama-cli i llama-server opisują starszy interfejs, co jest przyzwoitym testem świeżości całej strony.

3. Sprawdź, czy runtime naprawdę ma wagi. Oba tagi w wpisie `deepseek-v4-flash` w bibliotece Ollamy to tagi chmurowe, z podanym oknem kontekstu 1M i bez rozmiaru pobrania, sprawdzone 31 sierpnia 2026. ollama run deepseek-v4-flash wysyła twój prompt do API, co jest w porządku świadomie i złe przypadkiem, zwłaszcza jeśli powodem pójścia lokalnie było to, że dane nie mogą opuścić firmy. Lokalna droga do V4 to dziś GGUF przez llama.cpp albo LM Studio, albo safetensors przez vLLM.

4. Dobierz sampler do generacji. V3.x i R1 chcą --temp 0.6 --top-p 0.95 --min-p 0.01. V4 chce --temp 1.0 --top-p 1.0, ze zejściem top_p do 0.95 przy zadaniach agentowych. Przeniesienie ustawień z V3 na builda V4 to jeden z cichszych sposobów, żeby dobre pobranie wyglądało na zepsute. W V4 rozumowaniem sterujesz przez szablon czatu, a nie flagę: --chat-template-kwargs '{"enable_thinking":false}' wyłącza myślenie, a '{"reasoning_effort":"max"}' podkręca je.

5. Scal podzielone pliki GGUF, jeśli runtime tego wymaga. Wszystko powyżej mniej więcej 162 GB przychodzi w numerowanych częściach. ./llama.cpp/llama-gguf-split --merge DeepSeek-V3.1-Terminus-UD-Q2_K_XL-00001-of-00006.gguf merged_file.gguf składa je z powrotem. Zaplanuj miejsce na dysku na obie kopie w trakcie scalania.

Wymagania dotyczące pamięci

Wymagania pamięciowe DeepSeek. Niemal całe pytanie o lokalne wymagania DeepSeek sprowadza się do jednej reguły, którą Unsloth podaje bez asekuracji: "For the best performance, have your VRAM + RAM combined = to the size of the quant you're downloading." Dokumentacja V4 powtarza to jako pamięć całkowitą, RAM plus VRAM albo zunifikowaną, przewyższającą rozmiar skwantyzowanego pliku. Zwróć uwagę, czego reguła nie mówi. Nie interesuje jej, po której stronie podziału leży pamięć, i dlatego Mac Studio oraz stacja robocza z jedną średnią kartą i kompletem kości RAM lądują w tym samym miejscu.

Ich własne liczby pokazują, co znaczy "przewyższającą". Czterobitowy plik V4-Flash o rozmiarze 155,1 GB jest opisany jako wymagający 162 GB, a bezstratny ośmiobitowy o rozmiarze 162 GB jako wymagający co najmniej 169 GB. Około 7 GB zapasu ponad plik, zanim doliczysz kontekst. Dekodowanie spekulatywne z drafterem DSpark dokłada do tego jakieś 10 GB, a sam drafter to osobne pobranie 10,9 GB w Q8_0.

Wpływ pamięci na wydajność. Punktów pomiarowych jest niewiele, ale układają się spójnie. R1-0528 w IQ1_S na 64 GB RAM bez GPU daje 1 token na sekundę. Dwubitowy kwant V3.1 na jednym GPU 24 GB ze 128 GB RAM daje około 5. R1-0528 przy 180 GB pamięci łącznej daje 5 lub więcej, a V3.1 potrzebuje 226 GB, żeby dojść w to samo miejsce. Krzywa nie jest gładka. Jest urwisko w punkcie, w którym wagi przestają być czytane z dysku przy każdym tokenie.

Na drugim końcu pamięć kupuje co innego. Unsloth zmierzył V4-Flash na B200 na 120 tokenach na sekundę z dekodowaniem spekulatywnym DSpark wobec 60 bez niego, i tam właśnie te dodatkowe 10 GB zapasu na draftera się zwraca. Nikt nie publikuje porównywalnych liczb tokenów na sekundę dla DeepSeeka na kartach konsumenckich ani na Macach z serii M, a te krążące po blogach nie mają podanych warunków pomiaru, więc ich tutaj nie powtórzymy.

Wskazówki optymalizacji zużycia pamięci. Cztery dźwignie, mniej więcej w kolejności próbowania, przy czym pierwsza robi większość roboty.

Przenoś ekspertów, nie całe warstwy. W modelu mieszanki ekspertów to wagi ekspertów są masą i są dotykane rzadko, więc zepchnięcie ich do RAM systemowego przy ścieżce gęstej zostawionej na GPU to najtańszy dostępny kompromis. Aktualna flaga to --n-cpu-moe N. Starsza forma z regexem, wciąż pokazywana na stronie V3.1, daje trzy szczeble: -ot ".ffn_.*_exps.=CPU" przenosi wszystko i zużywa najmniej VRAM, -ot ".ffn_(up|down)_exps.=CPU" przenosi projekcje up i down, -ot ".ffn_(up)_exps.=CPU" przenosi wyłącznie projekcje up. Schodź w dół listy, aż zabraknie VRAM, potem cofnij o szczebel.

Kwantyzacja cache KV jest następna. --cache-type-k q4_0 i pokrewne tną cache zamiast wag, co przy kontekście 128K znaczy nieporównanie więcej niż przy 8K. Unsloth zaleca warianty _1 dla lepszej dokładności kosztem niewielkiego spowolnienia, a Ollama wystawia to samo jako OLLAMA_KV_CACHE_TYPE z wartościami f16, q8_0 i q4_0.

Potem ustaw kontekst, którego naprawdę używasz. Ollama domyślnie daje 4096 tokenów, co zwykle jest za mało, a build llama.cpp ładujący model V4 chętnie zarezerwuje okno, którego nigdy nie zapełnisz. Rekomendowany przez Unsloth --ctx-size dla rodziny 671B to 16384, i jest to wartość flagi, a nie limit modelu, bo samo R1 ma 128K.

Na koniec przestań kopiować przestarzałe porady. --no-mmap i --mlock są w aktualnym README serwera llama.cpp, skąd pochodzą też opisy flag z tabeli wyżej, oznaczone jako DEPRECATED na rzecz --load-mode, a niemal każdy poradnik o DeepSeeku wciąż zaczyna od nich. Drobiazg, ale dobrze mówi, ile lat ma reszta strony.

Rozwiązywanie typowych problemów

Rozpoznawanie problemów ze zgodnością sprzętu. Zacznij od tego, gdzie model faktycznie siedzi, a nie od logów. ollama ps pokazuje, czy model chodzi na 100% GPU, 100% CPU, czy w podziale, i ta jedna linia odpowiada na większość pytań "dlaczego to tak wolno działa", zanim otworzysz cokolwiek innego.

Potem logi, a te leżą gdzie indziej na każdej platformie: ~/.ollama/logs/server.log na Macu, journalctl -u ollama --no-pager --follow --pager-end na Linuksie, %LOCALAPPDATA%\Ollama\server.log na Windowsie i docker logs <container-name> w kontenerze.

Dla NVIDII strona troubleshootingu Ollamy podaje sekwencję: docker run --gpus all ubuntu nvidia-smi sprawdza, czy runtime kontenera widzi kartę, sudo nvidia-modprobe -u, a następnie sudo rmmod nvidia_uvm i sudo modprobe nvidia_uvm przeładowują moduł sterownika, sudo dmesg | grep -i nvidia wyciąga skargi z jądra, a CUDA_ERROR_LEVEL=50 włącza pełniejszą diagnostykę. Jedną udokumentowaną osobliwość warto zapamiętać: na Linuksie po cyklu uśpienia i wybudzenia Ollama czasem przestaje wykrywać GPU NVIDII i po cichu wraca na CPU. Jeśli maszyna wczoraj była szybka, dziś jest wolna i nic się nie zmieniło, sprawdź to najpierw.

AMD ma osobną listę. Potwierdź przynależność do grup na /dev/kfd i /dev/dri, potem uruchom z AMD_LOG_LEVEL=3 i OLLAMA_DEBUG=1 i poszukaj w logu "failure during GPU discovery". Ollama dowozi ROCm 7, więc maszyna na sterowniku ROCm 6.x daje timeouty zamiast sensownego błędu, a lekarstwem jest amdgpu-install i restart. Konfiguracje wielu kart AMD generujące bełkot to znany problem, który dokumentacja odsyła do poradnika AMD, zamiast go rozwiązać. Jedna osobliwość windowsowa przy okazji: śmieci ze znaków sterujących w terminalu to problem Windows 10 21H1, naprawiany przejściem na 22H1 lub nowszy.

Rozwiązania przy niewystarczających zasobach systemowych. Kiedy pamięci po prostu nie ma, część poprawek nic nie kosztuje, a część kosztuje jakość.

Najpierw zejdź o szczebel na drabince kwantów, bo to jedyna dźwignia zmieniająca plik, a nie maszynę. Na rodzinie 671B to realny zakres, od 481 GB w UD-Q5_K_XL do 251 GB w UD-Q2_K_XL. Zatrzymaj się na Q2_K_XL, jeśli robisz cokolwiek agentowego. Na V4 drabinka jest ściśnięta, więc użytecznym ruchem jest zejście ze 162 GB do 103 GB, a nie drobne kroki, na które pozwala starsza rodzina.

Zepchnięcie ekspertów na CPU flagą --n-cpu-moe albo --cpu-moe dopiero czyni kartę 24 GB użyteczną przy modelu ważącym 200 GB. Dalej przytnij kontekst: OLLAMA_CONTEXT_LENGTH=8192 ollama serve, /set parameter num_ctx 4096 w CLI albo "num_ctx": 4096 w opcjach API. I serwuj po jednym żądaniu naraz, bo OLLAMA_NUM_PARALLEL domyślnie wynosi 1, a jego podniesienie to najszybsza droga do zamiany działającego setupu w out of memory.

Jeśli wąskim gardłem jest dysk, a nie pamięć, OLLAMA_MODELS przenosi magazyn modeli tam, gdzie jest miejsce, a OLLAMA_KEEP_ALIVE steruje tym, jak długo model zostaje w pamięci ponad domyślne 5 minut. Ustawianie tych zmiennych wygląda inaczej na każdej platformie: launchctl setenv i restart aplikacji na macOS, systemctl edit ollama.service z linią Environment= w sekcji [Service] na Linuksie, oraz okno Ustawień i restart z menu Start na Windowsie.

A jeśli nic z tego nie wystarczy, offload z dysku jest podłogą, a nie awarią. Działa, jest wolny i przy 1 tokenie na sekundę to maszyna do nocnych zadań wsadowych, nie do okna czatu.

Lista kontrolna na dwadzieścia minut przed startem. Przejdź ją przed pobraniem, nie po.

1. Nazwij dokładny checkpoint i dokładny build, nie rodzinę. "DeepSeek V3" nie jest rozmiarem; DeepSeek-V3.1-UD-Q2_K_XL jest.

2. Weź rozmiar pliku, dodaj około 7 GB zapasu, dodaj swój kontekst i dodaj 10 GB, jeśli planujesz dekodowanie spekulatywne. Porównaj sumę z RAM plus VRAM w maszynie, którą naprawdę masz.

3. Potwierdź, że twój runtime hostuje wagi lokalnie. Poszukaj na liście tagów rozmiaru pobrania; jeśli jest tam tylko okno kontekstu, to tag chmurowy.

4. Sprawdź system pod kątem runtime'u, zwłaszcza jeśli w planie jest vLLM na Windowsie.

5. Sprawdź sterownik wobec minimum producenta, a nie wobec tego, że "działało przy innym modelu".

6. Przetestuj dokładnie ten build, który chcesz wdrożyć, na 100 własnych promptach przy realnej długości kontekstu. Publikowane liczby dywergencji trzymają się w agregacie, nie na twoim workloadzie.

Pytanie o lokalne wymagania DeepSeek kończy się jednym porównaniem, więc zrób w tym tygodniu właśnie to: otwórz listing plików builda, który planujesz uruchomić, zapisz rozmiar i postaw go obok pamięci całkowitej maszyny, na której chcesz go uruchomić. Jeśli druga liczba jest mniejsza, cała reszta planu jest teoretyczna. A jeśli wolisz, żeby ktoś zwymiarował to pod realny workload, zanim pójdzie zamówienie na sprzęt, od tego jest bezpłatny audyt.

FAQ