O czym jest ten film
- Nie jesteś już jedynym użytkownikiem własnego komputera — agenty potrafią korzystać z niego częściej niż ty, a zakup mocniejszego sprzętu nie zatrzyma narastania tego obciążenia.
- Zanim kupisz cokolwiek, zrób przegląd: wykres ciśnienia pamięci w Monitorze aktywności i zużycie dysku w ustawieniach systemu pokażą, czy problem leży w sprzęcie, czy w „resztkach” po agentach.
- Nawet gdy model liczy w chmurze, lokalnie wciąż działają serwery deweloperskie, przeglądarki i narzędzia kompilacji — i to one pałaszują pamięć operacyjną.
- Oprogramowanie agentowe bywa bugowate: w publicznych zgłoszeniach opisywano ponad 50 GB raportów awarii, ponad 100 GB obiektów Gita z checkpointów oraz ok. 37 TB zapisów na SSD w 21 dni (przypadek nadmiernego logowania w Codexie).
- Autor wyprowadza cztery zasady: wiedz, gdzie wykonuje się praca; dawaj agentom znak stopu i miejsce na wyniki; panuj nad pracą równoległą; prowadź stały plan konserwacji.
- Agenty potrafią same diagnozować i profilować obciążenie maszyny — wystarczy odpowiedni prompt; autor udostępnia trzy (audyt, sprzątanie za twoją zgodą, regularny przegląd) w przewodniku na Substacku.
- Rekomendacje zakupowe: 24–32 GB RAM (16 GB da się wyżyć, ale wymaga pilnowania), pół terabajta dysku na start, terabajt przy dużych plikach i wideo.
- Konkrety Apple: Mac mini z M6 od 899 dolarów (16 GB/256 GB, konfigurowalny do 32 GB), Mac mini M5 Pro od 1699 dolarów do 64 GB; autor tłumaczy też, dlaczego mówi o Macach, a nie o Windows.
- NPU nie jest panaceum — optymalizujesz cały system (pamięć, dysk, procesor); wybór między Maciem, Nvidią i AMD to de facto wybór poziomu techniczności, jak „automat albo manual”.
- Stary komputer plus Tailscale to najtańsza droga do dodatkowej mocy dla agentów; Raspberry Pi nadają się do drobnych lokalnych usług.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Audyt zanim cokolwiek kupisz
Na czym polega: Wysokie zużycie RAM nie oznacza, że potrzebujesz nowego komputera — oznacza, że musisz się przyjrzeć systemowi. Diagnozę można zlecić agentowi jednym promptem: „Zbadaj mój komputer. Niczego nie zmieniaj. Wskaż największych konsumentów pamięci i odpowiednie katalogi, wyjaśnij, do czego należą, i zaproponuj poprawki, które pomogą mi w mojej prawdziwej pracy”.
Jak stosować: Odpal audyt podczas normalnej pracy z agentami. W Monitorze aktywności (zakładka „Pamięć”) patrz na ciśnienie pamięci — zielony kolor znaczy „daje radę”, żółty i czerwony, że maszyna się dławi. Zużycie dysku sprawdzisz w Ustawieniach systemowych → Ogólne → Pamięć masowa.
Na co uważać: Sam fakt, że folder jest używany, nie znaczy, że jest używany użytecznie. Audyt ma być trybem „oglądamy, nie ruszamy” — decyzje o usuwaniu podejmujesz dopiero ty.
2.Nie kupisz sobie rozwiązania tego problemu
Na czym polega: Więcej pamięci i szybszy chip dają zapas, ale agenty będą coraz zdolniejsze i obciążenie wróci. Producenti łatają pojedyncze punkty (np. Tibo z OpenAI zmniejszył zużycie pamięci przez Codexa), ale to nie wystarcza, gdy pracujesz na kilku narzędziach naraz.
Jak stosować: Traktuj zakup sprzętu jako ostatni krok, po audycie i zmapowaniu obciążenia — wtedy faktycznie wiesz, czego ci brakuje: rdzeni, RAM czy dysku.
Na co uważać: Złudzenie, że jedna karta graficzna załatwi sprawę „na punkt”. Im mocniej stawiasz na agenty, tym szybciej wracasz do punktu wyjścia.
3.Patrz na lokalne narzędzia, nie tylko na model
Na czym polega: Model może odpowiadać z centrum danych, ale serwer deweloperski, przeglądarka testująca efekt i narzędzia kompilacji działają na twojej maszynie. Dwa agenty przy dwóch projektach potrafią po prostu zjeść całą pamięć.
Jak stosować: Przy ostrzeżeniach o pamięci włącz lokalne procesy do diagnozy — i zakładaj, że to ich wyłączenie będzie główną drogą do ulgi. W konfiguracji mieszanej naucz się rozróżniać, kiedy pamięć dobiera się do niej Qwen, a kiedy Codex czy Claude.
Na co uważać: Obciążenie z wielu miejsc sumuje się niezauważalnie: Claude w Chromie, druga przeglądarka z pamięcią roboczą, transkrypcje, kolejny agent — każde „trochę” składa się w ciśnienie pamięci.
4.Każdy agent potrzebuje znaku stopu i miejsca na wyniki
Na czym polega: Jeśli nie zdefiniujesz warunku zakończenia, agent nie skończy — te modele trenowano uczeniem ze wzmocnieniem tak, by ciągnąć zadanie dalej. Otwarte karty, czaty z działającym serwerem i zawieszone procesy to „niedokończone” zadania, które trzymają zasoby.
Jak stosować: W każdym poleceniu określ, co ma być momentem „koniec roboty” i w którym katalogu agent odłoży wyniki. Po zakończeniu projektu świadomie zamykaj serwery i przeglądarki.
Na co uważać: Większa pojemność pamięci nie naprawia braku dyscypliny — agenty bez mety będą podjadać maszynę bez końca.
5.Kolejkuj ciężkie zadania i profiluj obciążenie
Na czym polega: Liczba rdzeni nie przekłada się wprost na liczbę agentów: dwa agenty czekające na odpowiedź z chmury nie robią lokalnie prawie nic, a dwa młcące kompilację lub renderujące wideo zjedzą każdy dostępny rdzeń.
Jak stosować: Poproś agenta, by dopasował tempo do twojej maszyny: start od jednego aktywnego zadania, potem dwa, z kontrolą pamięci po każdym kroku. Duże lokalne kompilacje przepuszczaj z kolejki pojedynczo, a agentom badającym i planującym pozwól działać równolegle.
Na co uważać: Jeśli dołożenie zadania wyraźnie wszystko spowalnia, właśnie odkryłeś sufit swojego sprzętu — czas cofnąć się o pół kroku, a nie sięgać po kartę kredytową.
6.Sprzątaj resztki i tnij zbędną pracę
Na czym polega: Po skończonym projekcie zostają zależności, pliki kompilacji i uruchomione procesy. Do tego dochodzą bugi: folder raportów awarii urósł u kogoś do ponad 50 GB, checkpointy Gita do ponad 100 GB, a bug logowania w Codexie wygenerował ok. 37 TB zapisów na SSD w 21 dni.
Jak stosować: Zanim cokolwiek „pingniesz”, ustal, co dany serwer obsługuje. Jeśli projekt skończony lub to był eksperyment — zamknij go i zobacz, czy ciśnienie pamięci i dysku spada. Ustal, co da się odtworzyć od zera, i dopiero wtedy sprzątaj. Niech agent obejży istniejący projekt, zanim postawi szkielet nowego środowiska, i użyje ponownie przeglądarki, gdzie się da.
Na co uważać: Nie kasuj w ciemno — najpierw ustal, które procesy mają zostać. Trzymaj wyniki w przewidywalnej strukturze katalogów i zapisuj wnioski w wytycznych projektu do ponownego użycia.
7.Ustawienia lokalnych narzędzi to połowa sukcesu
Na czym polega: Docker Desktop ma limity swojej maszyny wirtualnej i tryb oszczędzania zasobów w bezczynności; serwery modeli (Ollama, LM Studio) pozwalają sterować kontekstem, równoległymi zapytaniami i czasem trzymania modelu w pamięci.
Jak stosować: Dobierz z agentem kompromisy do swojego stylu pracy: trzymanie modelu cały czas w RAM skraca opóźnienia, ale między zadaniami podjada pamięć; większy kontekst zje więcej; kilka zapytań naraz się sumuje.
Na co uważać: Nie ma jednej słusznej konfiguracji — to zawsze wymiana jednych korzyści na inne, zależna od tego, czy ciągniesz lokalne modele, czy tylko narzędzia chmurowe.
8.Kupuj pamięć i dysk pod siebie, nie pod narzędzie
Na czym polega: Rozsądny standard na dziś to 24–32 GB RAM — tyle, by zwykłe aplikacje i narzędzia agentowe mogły być otwarte równocześnie. 16 GB da się wyżyć, ale wymaga aktywniejszego pilnowania. Dysk: 0,5 TB na start, 1 TB przy dużym wideo i plikach.
Jak stosować: Niech o pojemności zdecydują twoje rzeczywiste nawyki pracy. Kupuj sprzęt „dla siebie” i zakładaj, że narzędzia (harnessy) będą się z czasem zmieniać.
Na co uważać: NPU w nowych chipach to nie panaceum — optymalizujesz cały system, nie jeden „magiczny” układ. Pamięć potrzebna do trzymania lokalnego modelu to wymaganie dodatkowe: duża maszyna ma sens, gdy prowadzisz dużo modeli chmurowych korzystających z lokalnych plików albo duży model lokalny.
9.Drugie życie starego sprzętu przez Tailscale
Na czym polega: Prawdopodobnie masz w domu zakurzony komputer — stary Mac mini, stary laptop. Podpięty do Tailscale (prywatna sieć do bezpiecznego zarządzania maszynami z dowolnego miejsca) może stać się „komputerem agentowym”, na który zrzucisz wolniejsze zadania.
Jak stosować: Zostaw stary sprzęt włączony, podepnij pod Tailscale i oddaj agentom. Przy podróżach możesz nim zdalnie zarządzać z MacBooka, a i tak pamiętać, że „maszyna przede mną musi obsłużyć pracę przede mną”.
Na co uważać: Maszyna pracująca w tle wymaga innego planu konserwacji niż ta, przy której siedzisz — i to tej drugiej zawsze daje się pierwszeństwo. Raspberry Pi pełnią mniejszą rolę: e-ink, drobne lokalne usługi.
10.Uczyń higienę cyklicznym zadaniem agenta
Na czym polega: Jednorazowe sprzątanie nic nie da, bo balagan wraca. Rozwiązanie: stałe, regularne zadanie dla agenta — pilnowanie zdrowia maszyny, śledzenie katalogów, sygnalizowanie zmian wartych uwagi i ochrona aktywnej pracy. Autor tak utrzymuje swoją instalację Linuksa: ma dedykowanego agenta, który „obsesyjnie” o nią dba.
Jak stosować: Zdefiniuj agentowi priorytet: najpierw człowiek, agenty w tle. Profiluj pracę, czyli układaj ją w sekwencję, żeby nie wszystko spadało naraz i nie gasiło maszyny.
Na co uważać: Nawet z automatem zdarzają się wpadki — autor złapał awarię pamięci, bo otworzył jeden nowy program. Bywają rzadziej, jeśli po prostu nie przeciążamy.
Redakcyjne tłumaczenie
Nie jesteś już jedynym użytkownikiem swojego komputera
Powiedzmy to wprost: nie jesteś już jedynym użytkownikiem swojego komputera. Jeśli agenty pracują u ciebie cały dzień, to zapewne korzystają z tej maszyny częściej niż ty. Wiem, co myślisz: „mój Mac się starzeje, potrzebuję mocniejszego”. Może właśnie porównujesz ceny Maca mini i Maca Studio, a może przyglądasz się maszynie z Nvidii. Problem w tym, że szybszy procesor i więcej pamięci nie zatrzymają narastania obciążenia, które sam generujesz. Agenty otwierają przeglądarki, uruchamiają usługi, zapisują pliki — i po skończonej robocie zostawiają większość tych rzeczy na komputerze. Krótko mówiąc: masz bałaganiarskiego współlokatora i nikt nie ustalił zasad wspólnego mieszkania. Czas je ustalić — i to razem.
Spokojnie, ten regulamin spisałem za ciebie. Na Substackie, razem z tym filmem, czeka przewodnik z trzema promptami, które możesz wręczyć agentowi bez przerabiania: pierwszy pozwala ustalić, co pożera twoją maszynę; drugi sprząta wyłącznie to, na co dasz zgodę; trzeci wdraża regularny przegląd, żeby ciśnienie pamięci i wszystko, co spowalnia komputer, nie wracało po cichu. Link jest w opisie filmu, a jeśli masz podpięte MCP Nate’a, agent może pobrać te prompty prosto z biblioteki i od razu zabrać się do roboty — bez wchodzenia na Substacka.
(Informacja dodatkowa: MCP — Model Context Protocol — to standard łączenia modeli językowych z zewnętrznymi narzędziami i danymi; autor prowadzi własny serwer MCP z biblioteką promptów.)
Po tym materiale będziesz wiedzieć, jaki komputer pasuje do twoich zadań agentowych, jak wycisnąć więcej z maszyny stojącej na biurku, i jak zadbać, żeby układ człowiek–agenty działał niezawodnie także wtedy, gdy zadań przybędzie. Spinać to wszystko będą cztery zasady.
Zacznij od badań kontrolnych maszyny
Zacznijmy od przeglądu lekarskiego twojego Maka. Otwórz Monitor aktywności, zakładkę „Pamięć” — i patrz na wykres ciśnienia pamięci wtedy, gdy pracujesz z agentami. Kolory mówią same za siebie: zielony znaczy, że system daje radę; żółty i czerwony, że maszyna się dławi. Szczerze mówiąc, u mnie często bywa żółto i czerwono. Zobacz też, które aplikacje zużywają pamięć. Wysoki wynik w kolumnie zużycia RAM sam w sobie nie przesądza, że potrzebujesz innego komputera — przesądza, że musisz się przyjrzeć systemowi.
Kolejny etap przeglądu to dysk: Ustawienia systemowe → Ogólne → Pamięć masowa. RAM to przestrzeń robocza tego, co robisz właśnie teraz; dysk trzyma pliki i programy. macOS potrafi używać dysku jako pamięci wymiany (swap), tymczasowo przenosząc tam zawartość RAM — trochę jak blokada środków na karcie płatniczej: nie kasuje obciążenia, tylko odsuwa je na bok. Sedno w tym, żeby nie budować swojej pracy na „blokadach” pozostawionych przez agenty w wielu środowiskach naraz. A tak właśnie wygląda rzeczywistość wielu z nas: Claude działa w Chromie, w drugiej przeglądarce (u mnie to Zen) siedzi kolejny kawał pamięci roboczej, do tego Codex, Claude, jakieś narzędzie do transkrypcji… Wszystko się sumuje — i wychodzi z tego ciśnienie pamięci.
Laboratoria to zauważyły. Tibo z OpenAI niedawno wypuścił poprawkę Codexa zmniejszającą jego zużycie pamięci, bo to naprawdę bolało. Ale takie punktowe łatanie nie wystarcza, zwłaszcza gdy — jak większość z nas — prowadzisz kilka środowisk agentowych równolegle. Wiem, że sporo osób w tej społeczności odpala lokalnie Qwena, pracuje z Claude’em i z Codexem. Potrzebujemy systemu, który obsłuży je wszystkie — i o tym jest ten film.
Zasada 1. Wiedz, gdzie naprawdę wykonuje się praca
Załóżmy, że prosisz Codexa albo Claude Code o zbudowanie małej strony internetowej — klasyczne zlecenie. Model może odpowiadać z centrum danych, ale to nie znaczy, że twój sprzęt odetchnie. Lokalnie wciąż działają: serwer deweloperski, przeglądarka sprawdzająca efekt, narzędzia kompilacji. Całość obciąża twój komputer — i czujesz to na własnej skórze. Jeśli równolegle dasz drugiemu agentowi inny projekt, on uruchomi swój zestaw narzędzi i znowu wszystko spadnie na lokalną maszynę. Znalazłem to na sobie, gdy Claude renderował filmy w Blenderze, a jednocześnie Codex robił coś zupełnie innego — takie połączenie po prostu pałaszuje pamięć.
Skoro dostajesz ostrzeżenia o pamięci, uwzględnij w diagnozie lokalne narzędzia — i zakładaj, że to one będą główną drogą do rozwiązania. Nie chodzi o to, żeby przestać pracować z agentami. Chodzi o to, jak to robić; trzeba zejść do szczegółów. I nie licz, że nowa karta graficzna rozwiąże wszystko jednym strzałem. Powtarzam: możesz dokupić pojemność, ale nie kupisz rozwiązania problemu, bo agenty będą coraz zdolniejsze. Traktuj więc kwestię pamięci jako sprawę lokalną, do ogarnięcia z twoimi agentami — zanim dołożysz kolejne obciążenia.
Jeśli prowadzisz model lokalnie, przelicz jego wymagania obliczeniowe. Jeśli — co w praktyce dotyczy chyba większości — pracujesz na mixie, naucz się w ustawieniach, które opisałem, rozróżniać, co i kiedy dobiera się do pamięci: kiedy Qwen, a kiedy Codex i Claude. Powinieneś to umieć zobaczyć.
Wróćmy do strony internetowej. Wyobraź sobie, że agent kończy robotę, ty przechodzisz dalej — a serwer deweloperski i przeglądarka wciąż wiszą otwarte w tle. Twoja uwaga już odpłynęła, ale narzędzia trzymają zasoby, choć nikt z nich nie korzysta: wciąż mają „blokadę” na twojej pamięci. Projekt ciągnie za sobą zależności, pliki kompilacji zajmują dysk. Żeby to puścić, trzeba naprawdę wszystko wyłączyć.
I uwaga: nie wszystko bierze się z samych agentów — część to zwykłe bugi oprogramowania agentowego. W jednym z publicznych zgłoszeń Codexa użytkownik opisał folder raportów awarii, który urósł do ponad 50 GB — samych opisów crashy. Inny doniósł o ponad 100 GB obiektów Gita związanych z checkpointami zadań. To konkretne, nieszablonowe przypadki; nie twierdzę, że to twój problem. Twierdzę, że warto znać szczegóły własnej maszyny i własnej konfiguracji. Dlatego kładę nacisk na audyt najpierw, strategię naprawczą z agentem — potem. To zresztą idealne zadanie dla agenta.
Krótka wersja promptu diagnostycznego wygląda tak: „Zbadaj mój komputer. Niczego nie zmieniaj. Wskaż największych konsumentów pamięci i odpowiednie katalogi. Wyjaśnij, do czego każdy z nich należy, i zaproponuj konkretne poprawki, które pomogą mi w mojej prawdziwej pracy.” Pełny prompt i szczegółowy przewodnik — bo to w gruncie rzeczy kompletny program higieny — masz na Substackie. Ale zacznij od takiego raportu, bo sam fakt, że folder jest używany, nie mówi jeszcze, czy jest używany użytecznie. Trzeba zajrzeć do środka.
Przykład: audyt pokazuje kilka serwerów deweloperskich działających naraz. No proszę — sam tak miałem przy kilku projektach pobocznych. Zanim cokolwiek sprawdzisz, ustal, co dany serwer obsługuje. Jeśli projekt skończony albo to był eksperyment — zamknij go i zobacz, czy ciśnienie pamięci oraz dysku spada. Ustal, co da się odtworzyć od zera, i dopiero wtedy wybierz metodę sprzątania. Brzmi nudno? Mam wiadomość: żyliśmy z ograniczeniami obliczeniowymi od lat 80., a teraz do tego stanu wróciliśmy — bo agenty zamieszkały razem z nami i musimy po prostu nauczyć się być dobrymi współlokatorami.
Inne miejsce, gdzie warto zajrzeć, to dysk SSD. Dyski półprzewodnikowe błyskawicznie zapisują i nadpisują dane, a wcześniej w tym roku Codex miał problem z nadmiernym logowaniem — jeden z użytkowników zmierzył około 37 terabajtów zapisów na SSD w 21 dni. To dużo. Poprawki logowania wyszły w czerwcu, a późniejsza wersja dodała odzyskiwanie nieużywanej przestrzeni bazy logów. To postęp, ale sama ta historia przypomina — i powinna przypomnieć tobie — że to oprogramowanie wciąż ewoluuje i warto uważnie śledzić, jak obchodzi się z fizycznymi częściami naszych maszyn.
Do tego dochodzi wzrost wynikający z tego, że agenty po prostu potrafią więcej. Przyjrzyj się, jak od stycznia rozrosły się agenty programistyczne: drzewa robocze, osobne katalogi pracy, a każdy z nich może mieć własne zależności i pamięci podręczne kompilacji. Codex ma ustawienia do zarządzania tymi środowiskami. Zanim cokolwiek wybierzesz, przemyśl, jak i gdzie chcesz realizować projekt.
Zasada 2. Postaw każdemu agentowi znak stopu
Tu krótka dygresja o chmurze kontra lokalnie. Odsłonię karty: trzymam się lokalnie, jak długo się da, bo lokalnie błyskawicznie przełączam się między środowiskami i narzędziami AI — wskazuję katalog i mówię „działaj”. Ale z tego dylematu nie ma wyjścia, niezależnie od wyboru strony. Moja reguła praktyczna: każdemu agentowi postaw znak stopu — coś, co jednoznacznie oznacza „koniec roboty” — i wyznacz miejsce, gdzie odłoży wyniki. Zazwyczaj bowiem zaczynamy rzeczy i zostawiamy je w połowie: otwarta karta z projektem, otwarty czat z działającym serwerem deweloperskim. Jeśli nie ma powodu, by skończyć, agent nie skończy — te modele były trenowane uczeniem ze wzmocnieniem tak, by ciągnąć dalej. I będą podjadać twoją lokalną maszynę. Więcej pojemności daje więcej miejsca, ale tego problemu nie rozwiązuje. Tym razem trzeba go rozwiązać głową.
Zasada 3. Panuj nad tym, co dzieje się jednocześnie
Trzecia zasada: opanuj równoległość. Masz tuzin dokumentów do przerobienia, więc wrzucasz do kolejki 12 zadań — całkiem realistyczny scenariusz, sam tak robię — ale uruchamiasz jeden lub dwa ciężkie kroki naraz. Agent potrafi sam przeanalizować to obciążenie i zaplanować całe zadanie bez odpalania wszystkich przeglądarek, konwerterów i lokalnych modeli w tej samej chwili. Umie to i powinien to robić — wystarczy poprosić. Powiedz mu: „Dopasuj się do mojej maszyny. Zacznij od jednego aktywnego zadania, potem ewentualnie dwóch; sprawdzaj, jak praca dochodzi do końca, i pilnuj wymagań pamięciowych”. Agent jest tu znakomitym partnerem — infrastruktura obliczeniowa to jego żywioł i sam potrafi zmierzyć zużycie. Jeśli dołożenie zadania wyraźnie wszystko spowalnia, właśnie się dowiedziałeś, że wyczerpałeś możliwości obecnego sprzętu i trzeba odpuścić pół kroku.
Właśnie dlatego liczba rdzeni CPU nie przekłada się wprost na liczbę agentów. Nie ma tu prostej odpowiedzi. Dwa agenty czekające na odpowiedź z chmury mogą lokalnie nie robić prawie nic, a dwa młcące dużą kompilację albo renderujące wideo zjedzą każdy dostępny rdzeń. Więcej rdzeni pomaga, gdy oprogramowanie potrafi z nich korzystać; więcej pamięci pomaga, gdy aktywna praca potrzebuje miejsca. Ale nie kupuj pod samą liczbę, nie myśląc o obciążeniu, pod które faktycznie używasz maszyny.
Jeśli inwestujesz w mocny sprzęt, ten sam proces wyciśnie z niego więcej. Rozdziel etapy zadania: kilku agentów bada i planuje, podczas gdy duża lokalna kompilacja przechodzi z kolejki pojedynczo. Dopasowujesz wtedy harmonogram do zasobów, zamiast zmuszać każde zadanie do walki o nie w tym samym momencie. I tak, możesz zlecić agentom zarządzanie tym — właśnie dlatego buduję te prompty, bo ogarnięcie tego ręcznie przerasta jednego człowieka.
Potem zajrzyj w pracę, która w ogóle nie musi się wydarzyć. Niech agent obejrzy istniejący projekt, zanim postawi szkielet kolejnego środowiska. Użyj ponownie przeglądarki, gdzie to możliwe. Trzymaj wyniki w przewidywalnej strukturze katalogów zrozumiałej dla ciebie i dla agenta. Poproś o wskazanie procesów, które mają pozostać uruchomione po zakończeniu. I zapisuj wnioski w wytycznych projektu, żeby wykorzystać je ponownie.
Przy lokalnych modelach ustawienia programów robią się kluczowe. Docker Desktop ma limity swojej maszyny wirtualnej i tryb oszczędzania zasobów w bezczynności. Serwery modeli pozwalają sterować kontekstem, równoległymi zapytaniami i tym, jak długo model pozostaje w pamięci. Wszystko to przekłada się na nacisk na twoją maszynę. W przewodniku wchodzę w Ollamę, LM Studio i Dockera, bo — jak pewnie zgadliście — pasjonuje mnie wyciskanie z maszyny wszystkiego, co się da. I niespodzianka: przy modelach lokalnych wciąż musisz porządkować wielkość zapytań i radzić sobie z pracą równoległą. Większy kontekst zje więcej pamięci. Kilka zapytań naraz się sumuje. Trzymanie modelu cały czas w pamięci skraca opóźnienia przy kolejnym zapytaniu, ale między zadaniami podjada RAM. Wspólnie z agentem dobierz kompromis do swojego stylu pracy.
Zakup sprzętu — ale dopiero po audycie
I tak dochodzimy do rozmowy o sprzęcie. Dokupowanie ma sens wtedy, gdy maszyna jest wyciśnięta do granic, audyt zrobiony, a obciążenie zmapowane. Warto odbyć sam ze sobą rozmowę o zwrocie z inwestycji — albo kupić z impulsu; ja wybieram rozmowę, bo te maszyny są drogie. Jedna rada od razu: jeśli kupujesz nowy komputer, nie pozbywaj się starego. Zostaw go włączonego i oddaj agentom — wykona wolniejsze zadania i zdejmie z nowej maszyny sporą część obliczeń. Świetnie nadaje się do tego Tailscale, o którym za chwilę.
Zanim przejdziemy do marek — liczby. Moje założenie wyjściowe, chyba że jesteś bardzo ciężkim użytkownikiem, to dziś 24–32 GB pamięci. Szesnaście da się wyżyć, ale będziesz musiał pilnować systemu znacznie aktywniej. Wyższy przedział daje zapas na zwykłe aplikacje i narzędzia agentowe otwarte równocześnie. Nie powiem, że to konfiguracja pieszczotliwie dostrojona pod Codexa albo Claude’a — ale tak w ogóle nie kupuję dziś sprzętu. Kupuję go dla siebie i zakładam, że narzędzia z czasem się zmienią.
Dysk: pół terabajta na start, terabajt, gdy pracuję z dużym wideo i dużymi plikami. Jeśli budujesz strony albo generujesz dużo materiałów filmowych, niech o pojemności zdecydują twoje rzeczywiste nawyki, nie specyfikacja dla samej specyfikacji.
Przy okazji: dlaczego mówię o Macach, a nie o Windows? Powiem szczerze, jak zawsze: rewolucja AI jest na Macach o sześć–osiem miesięcy przed Windows. Tam też dotrze, ale wolniej — po części dlatego, że ludzie z laboratoriów pracują na Macach, po części dlatego, że chipy Apple są lepiej zoptymalizowane pod AI. Wskazówki, które daję, zastosujesz w każdym środowisku, ale najboleśniej odczuwają to użytkownicy Maców — bo to oni najmocniej stawiają na agenty i wręczają im najwięcej pracy. Stąd konkrety o Apple.
Bazowy Mac mini z M6 kosztuje u Apple 899 dolarów i ma dokładnie te 16 GB pamięci oraz ćwierć terabajta (256 GB) dysku — konfiguracja szczupła jak na powyższe wytyczne, ale da się z nią funkcjonować. Ten sam model doczekał konfiguracji do 32 GB, a Mac mini M5 Pro startuje od 1699 dolarów i sięga 64 GB. Z Pro musisz jednak naprawdę chcieć: deklarujesz więcej aktywnej pamięci, trwałą pracę lokalną, prawdopodobnie z lokalnymi modelami. Przemyśl to.
Nagrałem kiedyś film o Macach i zdałem sobie sprawę, że mówiłem o nich jak o przedmiotach zakupu — rzeczyach, które się kupuje — z małym dodatkiem o obciążeniach AI. Nagrywam ten materiał teraz, ponieważ im mocniej wchodzimy w agenty, tym bardziej splątana staje się ta relacja: żeby dobrze kupić, muszę rozumieć, co robią moje agenty.
Jeśli dużo podróżujesz, MacBook ma sens — wsuwasz go do plecaka i jedziesz, gdzie chcesz. Zadbaj tylko, żeby nie krępował cię w drodze. I tu znów Tailscale: możesz nim zdalnie zarządzać stacjonarnym Maciem mini albo starym laptopem, mając przy sobie maszynę roboczą. Ale nawet wtedy rządzi zasada: komputer przede mną musi obsłużyć pracę przede mną.
NPU i wybór ekosystemu
Producenci chipów, Apple włącznie, robią wielkie oczy na temat NPU — jednostek przetwarzania neuronowego — jakby to była odpowiedź na całe AI. Powiem wprost: wykorzystasz je w swojej pracy, ale to nie jest panaceum. Kupujesz sprzęt, żeby wykonać pracę, i musisz ocenić, czy ją wykona. Optymalizujesz cały system — pamięć, dysk, procesor — a nie jeden zachwycający chip i koniec. Nie daj się nabrać na magiczne funkcje. Porządny audyt — wracam do tego jak bumerang — pomoże ci mądrze ocenić, czy brakuje ci rdzeni, pamięci czy dysku.
Jeśli celem są lokalne modele — a wiem, że dla wielu z was to sprawa serca — kluczem będzie pamięć dostępna dla akceleratora i oprogramowanie, które ją obsługuje. Mocniejszy Mac Studio, system z Nvidii, może maszyna z ujednoliconą pamięcią AMD: pomyśl, jak różne układy pamięci pozwalają prowadzić różne obciążenia. I najpoważniej: porozmawiaj o tym ze swoimi agentami. Przejdź z nimi przez szczegóły techniczne — co i jak zjada pamięć, co podgryza rdzenie — a potem zasymuluj to na różnych konfiguracjach. Wtedy zobaczysz, gdzie dostaniesz najwięcej za wydane pieniądze.
Konkrety ekosystemów. Jeśli Mac: mocniejszy pamięciowo Apple Silicon pozwoli prowadzić lokalne modele i natywne aplikacje macowe. W świecie Nvidii karty GeForce RTX są bardzo mocne — wprost zaprojektowane pod lokalne modele — ale zakładają CUDA, obliczeniową platformę Nvidii. Jeśli twoja praca opiera się na narzędziach GPU, optymalizacji i dostrajaniu modeli, będzie świetnie — wiem, że takich entuzjastów tu nie brakuje. W środowisku AMD — anegdotycznie niewielu was tam jest — warto poskładać konfigurację z bardzo dużą pamięcią, żeby zwykły pecet z Windows lub Linuksem działał dobrze. Są też użytkownicy Omakuba i to działa znakomicie; nagrywałem cały film o tym, jak Omakub jest przystosowany do agentów. Nvidia DGX Spark ma z kolei własne wymagania programowe. Mógłbym tak wymieniać dalej, ale cel jest inny: ustal, ile utrzymania maszyny jesteś gotów wykonać i ile profilowania chcesz robić. Im więcej zapasu, tym luźniej możesz podchodzić do dozowania obciążenia i tym swobodniej pracować na komputerze równocześnie z agentami. Ogólnie: najmniej technicznym wyborem jest Mac, dalej robi się coraz techniczniej — a przy Nvidii, AMD i instalowaniu Ubuntu wchodzisz w tryb „skrzynia manualna zamiast automatu”. Jeśli czujesz się budowniczym, będzie wspaniale: dostaniesz mnóstwo kontroli.
(Informacja dodatkowa: Omakub — darmowy, oparty na Ubuntu zestaw, który spina gotowe środowisko programistyczne dla Linuksa.)
Głębsze rozważania o zakupie pod lokalne modele zostawiłem w przewodniku na Substackie. Najważniejsze rozróżnienie: pamięć potrzebna do trzymania lokalnego modelu to wymaganie dodatkowe. Kupujesz dużą pamięć tylko z dobrego powodu — albo prowadzisz dużo modeli chmurowych, które intensywnie używają lokalnych plików i narzędzi, albo prowadzisz duży model lokalnie.
Ostatecznie masz trzy wyjścia, a większość ludzi realnie dwa: zostajesz przy obecnej maszynie (opcja zawsze dostępna, choć wymaga aktywniejszego pilnowania), próbujesz ją podrasować (coraz częściej zablokowane — na Macach szczególnie) albo kupujesz nową, a starą przeznaczasz na agentowe zadania. Wybierz świadomie, patrząc z wyprzedzeniem na to, dokąd zmierzają agenty.
Zasada 4. Stały plan konserwacji
Czwarta zasada — ta, na którą czekaliście — to plan ciągłej konserwacji. Maszyna, przy której pracujesz interaktywnie, musi zwracać twoją uwagę, gdy się dławi. Maszyna zostawiona w tle pod Tailscale może po prostu spokojnie przerabiać zadania jedno za drugim — i ma zupełnie inne wymagania co do opieki. Zarządzanie tym w dłuższej perspektywie to dla mnie jedna sprawa: daj agentowi regularne zadanie dbania o zdrowie komputera. Dotyczy to także agentów na maszynach wirtualnych — mam u siebie całego agenta poświęconego wyłącznie utrzymaniu w zdrowiu mojego bota Groka działającego na Linuksie; tamten agent wręcz obsesyjnie pilnuje tej instalacji. Przepisz ten pomysł na swoją lokalną maszynę: niech agent śledzi katalogi i sygnalizuje, gdy coś zmienia się na tyle, by zająć twoją uwagę; niech chroni aktywną pracę; niech stawia człowieka ponad agentami i trzyma pracę agentów w tle. Możesz odwrócić te priorytety — ja wolę jednak móc pracować na własnym komputerze. A robić to wszystko można z dużą pewnością, bo agenty świetnie znają się na maszynach, na których pracują. I to jest jedna z większych zmian ostatniego roku, prawda? Duże modele mamy od czasów ChatGPT, ale pewności, że są dość rozumne, by skutecznie pomagać nam zarządzać obciążeniem, nie mieliśmy. Teraz mamy.
Tailscale i drugie życie starego sprzętu
Kilka razy padło Tailscale — wyjaśniam, o co chodzi. To sposób zarządzania maszynami przez prywatną sieć: bezpieczne połączenie z twoim komputerem z dowolnego miejsca na świecie. Wiele osób trzyma w domu maszynę lokalną i — z każdego zakątka globu — posyła jej polecenia dla agentów. Konfiguracja nie jest trudna.
I to prowadzi do jednego z najtańszych sposobów na naprawdę duże oszczędności na mocy obliczeniowej: prawdopodobnie masz gdzieś stary komputer. Stary Mac mini, stary laptop z Windows, stary MacBook — cokolwiek. Podłącz go, podepnij pod Tailscale, uczyń „komputerem agentowym” — i pozwól agentom po prostu tam pracować dla ciebie. To dużo tańsze niż zakup nowej maszyny. A jeśli jesteś sprzętowym pasjonatem: Raspberry Pi, te malutkie płytki, od lat pełnią podobną, mniejszą rolę. U mnie w domu napędzają wyświetlacze e-ink i wystawiają drobne lokalne usługi, gdy laptop jest gdzie indziej — znów przydaje się Tailscale.
Zakończenie: kto zmywa naczynia w erze AI
Ostatecznie to twoja decyzja, ile mocy przeznaczysz. Część mojej motywacji jest prozaiczna: chcę uchronić cię przed wydatkami. Jeśli wykorzystujesz komputer do granic, rzadziej będziesz potrzebować nowego — a gdy już kupisz, zrobisz to mądrzej. Pomyśl o tym tak: próbujemy jak najlepiej ułożyć współżycie z agentami-współlokatorami. Dom mamy taki, jaki mamy, i pokoje takie, jakie mamy — i zanim (w metaforze) kupimy nowy dom, wyciskamy maksimum z obecnego. A jeśli w ogródku stoi nieużywana szopa — moja ulubiona metafora zakurzonego komputera pod biurkiem — włączamy i ją w przestrzeń mieszkalną, zanim pobiegniemy do sklepu. Wszyscy lubimy rozpakowywać prezenty pod choinką, ale nie znoszę marnować pieniędzy.
Jeśli chcesz wejść głębiej, niż pozwala film — szczegółów jest znacznie więcej — sięgnij po przewodnik na Substackie. Możesz go wręcznie wręczyć agentowi i pozwolić mu działać: obejmuje wszystkie narzędzia, o których mówiłem, i audyt krok po kroku. A jeśli twoja maszyna się dławi, tak jak moja niedawno, odpal kontrolę diagnostyczną. Zrozum zużycie pamięci i dysku, nacisk na rdzenie CPU — i to, co za nimi stoi. Naucz się profilować pracę. Profilowanie brzmi groźnie, a chodzi o prozaiczne ustawienie zadań w sekwencję, żeby obciążenie nie biło wszystkim naraz i nie gasiło maszyny. Wczoraj w nocy sam złapałem awarię pamięci, bo otworzyłem jako człowiek jeden nowy program — wcześniej wszystko działało. Takie rzeczy się zdarzają, ale rzadziej, jeśli po prostu nie przeciążamy.
Następnym razem, gdy usiądziesz przy komputerze, pomyśl: mam współlokatorów. Wielu. I musimy się dogadać co do warunków mieszkania — kto zajmuje miejsce, kto i jak korzysta z domu, żeby to wszystko było produktywne. To w gruncie rzeczy pytanie, kto zmywa naczynia w układzie AI–człowiek. Nikt nie lubi rozmawiać o zmywaniu — to nudna część — ale bez tego dom nie działa. Moim celem było, żebyś zrozumiał podstawy: pamięć, procesor, dysk; jak korzystają z nich agenty i jak ty; i żebyś miał plan lepszego ich wykorzystania — albo mądrego zakupu na przyszłość. Powodzenia!
(Informacja dodatkowa: oryginał kończy się okrzykiem „Go Hawks!” — kibicowskim pozdrowieniem, którym autor tradycyjnie żegna się w swoich nagraniach.)