MacBook Pro M4 Max a lokalna AI – gdzie leży prawda?

Kupiłeś nowego MacBooka Pro z M4 Max i 128 GB zunifikowanej pamięci? Prawdopodobnie wizja szybkiego lokalnego asystenta kodowania wydawała się w zasięgu ręki. W końcu 128 GB unified memory to spora paleta mocy obliczeniowej, prawda?

Rzeczywistość, jak się okazuje, jest znacznie bardziej skomplikowana. Pewien deweloper przeszedł przez całą trasę: custom Metal inference engines, agresywne optymalizacje, różne architektury modeli. Efekt? Frustrujący sufit wydajności oscylujący wokół 80-150 tokenów na sekundę przy rozsądnych rozmiarach modeli.

Co obiecuje hardware, a co dostajemy

Apple Silicon wprowadził prawdziwą innowację z architekturą zunifikowanej pamięci. Koniec z przerzucaniem danych między CPU a GPU – wszystko żyje razem, teoretycznie umożliwiając szybsze przetwarzanie obciążeń AI. Dla wielu zadań to faktycznie działa.

Ale przy serwowaniu dużych modeli językowych do pomocy w kodowaniu? Liczby mówią co innego. Nawet przy agresywnie zoptymalizowanych silnikach inference zbudowanych specjalnie pod Metal, wydajność zatrzymuje się na przewidywalnych poziomach:

• Llama.cpp Q4_0: Około 70.9 tokenów/sekundę
• MLX 4-bit: W przybliżeniu 80.6 tokenów/sekundę
• Custom optimized Qwen3-Coder-Next: Mniej więcej 120 tokenów/sekundę
• Custom optimized Qwen3.6-35B przy 4-bit: W granicach 85 tokenów/sekundę

Wzorzec jest jasny: kiedy operujesz na „użytecznych" rozmiarach modeli (generalnie 7B+ do zadań kodowych), uderzasz w ścianę niezależnie od stopnia optymalizacji.

Dlaczego tak się dzieje?

Deweloper przeprowadzający testy podejrzewa, że winowajcą jest пропускная способность памяти (przepustowość pamięci), nie sama moc obliczeniowa. To ma sens, jeśli zastanowisz się, jak działają transformery.

Każda generacja tokena wymaga odczytania sporej części wag modelu z pamięci. Nawet przy imponującej przepustowości M4 Max, ostatecznie jesteś ograniczony tym, jak szybko możesz przenosić dane. Mnożenia macierzy mogą być szybkie, ale działają tylko tak szybko, jak dane które je zasilają.

Dlatego mniejsze modele wypadają dramatycznie lepiej – po prostu jest mniej danych do przenoszenia. Model 0.1B parametrów może osiągnąć 1000 tokenów/sekundę, ale przejdź na 1.5B i spadasz do około 140 tokenów/sekundę. Skalowanie nie jest liniowe – jest brutalne.

Jakie masz opcje?

Jeśli szukasz pomocy w kodowaniu przy 200+ tokenach/sekundę z zachowaniem możliwości rozumowania i tool-callingu, krajobraz się znacznie zawęża:

Rozwiązania chmurowe

Hostowane modele od providerów takich jak Anthropic (Claude), OpenAI czy DeepSeek oferują ogromną moc obliczeniową, ale kosztują – od $20 do $200+ miesięcznie przy poważnym użytkowaniu. Są niezawodne i szybkie, ale zależysz od zewnętrznych usług i ich dostępności.

Specjalizowany hardware

Cerebras oferuje naprawdę imponujące prędkości inference (ich model GPT-oss-120b działa z prędkością 1000+ tokenów/sekundę), ale wycena wyklucza to dla większości indywidualnych deweloperów i wielu zespołów.

Lokalne modele z dostosowanymi oczekiwaniami

Jeśli potrzebujesz lokalnego inference, rozważ czy możesz zaakceptować nieco wolniejsze tempo. Modele typu Qwen3.5-32B czy podobne architektury przy kwantyzacji 4-8 bitów mogą zapewnić przyzwoitą pomoc w kodowaniu przy 80-120 tokenach/sekundę – wystarczająco do produktywnej pracy, jeśli Twój workflow toleruje odrobinę większe opóźnienia.

Prawdziwe pytanie: lokalnie czy w chmurze?

Ta debata ostatecznie sprowadza się do Twoich konkretnych potrzeb:

• Wybierz lokalnie jeśli masz surowe wymagania dotyczące prywatności danych, sporadyczny dostęp do internetu lub chcesz eksperymentować bez bieżących kosztów
• Wybierz chmurę jeśli konsekwentna szybkość jest ważniejsza niż posiadanie, potrzebujesz absolutnie najlepszych możliwości modelu lub Twój budżet computingu pozwala na subskrypcje

Dla wielu deweloperów hybrydowe podejście ma najwięcej sensu – lokalne modele do eksperymentowania i szybkich zadań, chmura do obciążeń produkcyjnych, gdzie szybkość i możliwości są krytyczne.

Konkluzja

Apple Silicon jest naprawdę imponujący przy wielu zadaniach AI, ale szybkie lokalne inference z zdolnymi modelami do kodowania pozostaje wyzwaniem. Hardware po prostu nie był projektowany z myślą o tym konkretnym obciążeniu, a żadna ilość optymalizacji Metal nie pokona fundamentalnych ograniczeń architektonicznych.

Jeśli budujesz workflow wspomagany AI, najlepszym rozwiązaniem jest dopasowanie infrastruktury do faktycznych potrzeb – i uczciwe przyznanie się, czy podejście „local first" Ci służy, czy Cię hamuje.

A Twoje doświadczenia z lokalnym AI inference? Znalazłeś konfiguracje, które przełamują te bariery wydajności?