O czym jest ten film
- Autor testuje nowy model OpenAI GPT 5.6 Sol i uznaje go za nową klasę AI, na poziomie Fable 5.
- Nie interesują go benchmarki ani demonstracje — liczy się to, czy model rozwiązuje realne problemy w pracy.
- Praktyczny test: uruchomienie na Linuksie teleprompteru Elgato, z którym nie poradziły sobie modele lokalne.
- GPT 5.6 Sol nie tylko rozpoznał sprzęt, ale sam napisał działające oprogramowanie do teleprompteru.
- Wniosek warsztatowy: dużego modelu używaj do architektury i pierwszego szkicu, a poprawki deleguj do modelu lokalnego.
- Analiza kosztów: przy sporadycznym użyciu wystarczy API płatne za akcję, przy codziennym — subskrypcja za 20 dolarów.
- Kluczowy zarzut: OpenAI po cichu obniżyło jakość GPT 5.5/Sol po premierze — model „spadł poniżej progu”.
- Model lokalny jest stały i przewidywalny — nie zmieni się bez Twojej wiedzy, co jest krytyczne dla biznesu.
- Nowa strategia hybrydowa: maksimum na tym, co kontrolujesz, delegowanie na krótko do większych modeli.
- Dwa różne komputery do AI: jeden szybki (RTX 1590), drugi z dużą pamięcią (odpowiednik DGX Spark) — do „roju” agentów.
Redakcyjne tłumaczenie
Nowy model i po co w ogóle o nim mówić
GPT 5.6 Sol jest już dostępny i zmienił sposób, w jaki korzystam z AI. Ten kanał nie jest o szumie medialnym — chodzi w nim o znalezienie najlepszego sposobu wykorzystania AI, tak by wzmacniać i poszerzać Twoje możliwości. Używam tego modelu dopiero od kilku dni, ale jest w nim coś niezwykłego. Jeśli spojrzeć na cały krajobraz, to model na podobnym poziomie co Fable 5. Nie ma znaczenia, który z nich wolisz — jasne jest, że oba reprezentują nowy poziom, nową klasę AI. Czegoś takiego nie mamy w środowisku open source. Wcześniejsze modele miały w takim czy innym sensie odpowiedniki w modelach otwartych, ale te robią coś nowego.
Nie zależy mi specjalnie na benchmarkach — to tylko liczby — ani na testach, które pokazują skrawek tego, do czego model jest zdolny. Prawdziwa zmiana ujawnia się tam, gdzie stosujesz te modele w rzeczywistej pracy: czy robią różnicę, czy nie. Z mojego doświadczenia najczęściej można sobie poradzić modelami open source bez większych problemów. Dopiero w specyficznych sytuacjach widać, że potrzebny jest naprawdę bardzo duży model.
Test na realnym problemie: teleprompter na Linuksie
Oto co zrobiłem. Kupiłem nowy komputer z kartą Nvidia RTX 1590, właśnie po to, by uruchamiać na niej modele lokalnie. Ale jeśli mnie znasz, wiesz, że nie wybrałbym Windowsa — postawiłem na Linuksa.
Przejście z macOS na Linuksa to wyzwanie, wcale nie takie oczywiste. O samym sprzęcie, modelach i doświadczeniach z Linuksem opowiem w przyszłym materiale. Jednym z problemów było jednak sprawienie, by nowy komputer rozpoznał sprzęt, który już mam. Używam dwóch urządzeń Elgato: Stream Decka, którym steruję systemem, oraz teleprompteru Elgato. Wiedziałem, że ten sprzęt nie jest oficjalnie wspierany na Linuksie — ani sprzętowo, ani programowo. W trakcie poszukiwań odkryłem jednak, że są ludzie, którym udaje się uruchomić go pod Linuksem.
Teleprompter jest dla mnie dość istotny, bo widzę na nim poziom mikrofonu, to, czy nagrywam, a także mogę wybrać, jaki ekran udostępniam — dzięki temu wiem, co pokazuję w nagraniu. Ważne jest więc, żebym miał go przed sobą. Podłączyłem go do nowego komputera i poprosiłem lokalny model — Qwen 3.6 27B — żeby to ogarnął i uruchomił.
(Informacja dodatkowa: transkrypcja podaje „when 3.6 27 billion” — chodzi najpewniej o model Qwen w wersji 27 miliardów parametrów.)
Nie dał rady. Zupełnie. Urządzenie się włączało — zasilanie było, system działał — ale komputer go nie rozpoznawał. Wtedy przekazałem zadanie modelowi Minimax M3. Ten sam wynik, nie znalazł rozwiązania. Potem GLM 5.2 — tego dnia również nie znalazł rozwiązania.
Na szczęście pojawił się GPT 5.6 Sol od OpenAI. Powiedziałem sobie: to jest moment, żeby sprawdzić, czy naprawdę potrafi zrobić coś niezwykłego. Dałem mu to wyzwanie — i naprawił. Zobaczyłem, że monitor się włącza, widzę obraz, komputer rozpoznał urządzenie. Ale model nie przestał pracować. Zastanawiałem się, co jeszcze robi. A kiedy skończył, oznajmił: „Stworzyłem oprogramowanie do teleprompteru i umieściłem ikonę na Twoim pulpicie”. Miałem więc działający teleprompter razem z oprogramowaniem. Tego się nie spodziewałem.
Otworzyłem ten program — był naprawdę dobry. Dostałem oprogramowanie do teleprompteru, którego, co prawda, nie zamierzałem używać, ale model rozwiązał cały problem, a nie tylko jego część. Przyjrzałem się bliżej i faktycznie było bardzo dobre, w pełni używalne, brakowało jednak dwóch rzeczy. Po pierwsze, można było ukryć ustawienia, ale nie było jasnego sposobu, żeby je z powrotem przywołać — poprosiłem więc o dodanie ikony włączającej i wyłączającej ustawienia. Po drugie, brakowało możliwości zmiany szerokości tekstu. Przy pracy z teleprompterem chodzi o to, żeby tekst mieścił się w szerokości obiektywu. W interfejsie były już suwaki do pewnych regulacji — wystarczyło dodać jeden nowy suwak z tą funkcją.
Podział pracy: duży model do architektury, lokalny do poprawek
Wróciłem do zadania, ale poprawek nie zleciłem już GPT 5.6 Sol. Poprosiłem o nie model Qwen 3.6 27B — i zrobił to. To właśnie lekcja: taki duży model jest dobry do rozwiązywania problemów wysokiego poziomu, do zaprojektowania struktury oprogramowania, do nadania pierwszego, mocnego odcisku. A potem możesz już delegować resztę.
Jeśli myślisz w tych kategoriach, nie potrzebujesz nawet subskrypcji OpenAI — chyba że korzystasz z tego naprawdę często. Najczęściej potrzebujesz jednorazowej akcji, która naprawi Twój system. Jeśli nie używasz AI zbyt intensywnie, jeśli nie jesteś power userem, wystarczy Ci API: w chwili, gdy trzeba rozwiązać problem nie do przejścia dostępnymi narzędziami, prosisz model, żeby go naprawił, i pracujesz dalej. Jeśli jesteś power userem i takie wyzwania trafiają się niemal raz czy dwa razy dziennie, wtedy wystarczy nawet subskrypcja za 20 dolarów. Pomyśl o tym: masz świetnego, naprawdę dobrego starszego inżyniera za 20 dolarów miesięcznie. To bardzo dobry układ.
Dlaczego mimo to nie warto iść w 100% w chmurę
Dlaczego więc nie postawić w całości na OpenAI czy Anthropic? Bo jest pewne wyzwanie, którego nie można zignorować. To nie drobiazg — to poważny problem.
Nie wiem, czy używałeś GPT 5.5 w ostatnich tygodniach. Przez jakieś dziesięć dni czy dwa tygodnie zauważyłem, że model przestał być dobry. Nagle stał się jak idiota — nie żeby wcześniej był geniuszem, ale nie działał tak jak przedtem. Przeszedłem na GLM 5.2 i tam wszystko śmigało wyśmienicie; naprawdę lubię ten model. Irytujące było jednak to pogorszenie modelu — niektórzy już mówią, że OpenAI zmieniło pewne ustawienia. Ten model Sol nie jest więc tak mocny, jak w momencie premiery, i to jest przygnębiające. Masz system, na którym polegasz i wokół którego budujesz, a potem ktoś zmienia parametry i nagle przestaje on działać tak, jak działał.
Gdy przeanalizujesz to porządnie, wyzwanie polega na tym: gdy budujesz system, masz próg, według którego dobierasz model. Czy ten model utrzyma się powyżej progu? Czy jest wystarczająco inteligentny, czy odpowiada w sposób przewidywalny, na tyle, bym mógł mu zaufać w tym zadaniu? Bo jeśli spada poniżej progu, to go nie potrzebuję — nie jest wystarczająco dobry. W moim przypadku zobaczyłem, jak GPT 5.5 przesuwa się z góry progu na dół, a oni mi o tym nie powiedzieli. To jest problem.
Kiedy natomiast uruchamiasz coś lokalnie, wiesz, że model jest stały. Jeśli jest powyżej progu, pozostanie powyżej progu — nie zmieni się. To jest ogromnie ważne. Gdy prowadzisz biznes, optymalizujesz pod dany model. Chcesz zagwarantować klientom, dla których pracujesz, że Twój wynik jest przewidywalny w określonej jakości — i że koszt również jest przewidywalny.
Wiemy już, że ceny tych modeli rosną, że te tokeny są nam dziś subsydiowane. W pewnym momencie ceny muszą pójść w górę. Cała ta konstrukcja jest kompletnie niestabilna. Jeśli prowadzisz biznes, znacznie lepiej mieć biznesplan, w którym rozpisujesz koszt sprzętu i wiesz, kiedy Ci się zwróci, a przy tym masz model, który zmieniasz dokładnie wtedy, gdy sam tego chcesz. Optymalizujesz pod niego i prawdopodobnie utrzymasz go przez miesiące.
Dlaczego mówię „przez miesiące”, a nie „przez lata”? Bo AI rozwija się tak szybko, że w pewnym momencie i tak opłaci Ci się zmienić model — ale na Twoich warunkach, po tym, jak go przetestujesz i upewnisz się, że pozostaje powyżej progu. Tak właśnie trzeba pracować. OpenAI, Anthropic, Google — wszyscy pokazują nam, że nie możemy im w tej sprawie zaufać. Nie są tu dla nas. Nie zależy im wystarczająco na tym, co budujemy na tych modelach. Dla nich to biznes, biorą od nas rzeczy: pieniądze, wiedzę i tak dalej. Nie budują systemu na tyle stabilnego, byśmy mogli oprzeć na nim własny biznes. I to jest problem.
Nowa strategia hybrydowa
Nowa strategia jest bardzo prosta. Rób maksymalnie dużo na czymś, co posiadasz, co kontrolujesz i czego zachowanie potrafisz przewidzieć. A w tych momentach, gdy Twoje modele nie dają rady, deleguj na krótko coś większego. Koszt jest krótki, zależność krótka — dostajesz wynik i się wycofujesz. Ten hybrydowy sposób pracy staje się coraz wyraźniej istotny: warto stworzyć świadome przechylenie, celowe nastawienie w stronę tego, co kontrolujesz.
Dwa różne komputery do AI
Podzielę się jeszcze tym, jak korzystam z lokalnego modelu. Mam obecnie dwa różne zestawy sprzętowe do AI. Pierwszy to odpowiednik DGX Spark — 128 GB pamięci zunifikowanej, czyli sporo pamięci, żeby uruchamiać wiele różnych modeli. Ma jednak mniejszą przepustowość, przez co generuje tokeny wolniej. Drugi, nowy sprzęt z RTX 1590, ma mniej pamięci — 32 GB — więc załadujesz tylko kilka dobrych, ale niewielkich modeli. Za to ma ogromną przepustowość, jakieś sześć razy większą: tamten ma około 270-czegoś, a ten około 1700-czegoś. Prędkość generowania tokenów jest niewiarygodna.
(Informacja dodatkowa: mowa o przepustowości pamięci wyrażanej w GB/s — to ona w dużej mierze decyduje o szybkości generowania tokenów przez model lokalny.)
W przyszłości wyjaśnię, która maszyna sprawdza się lepiej do jakiego typu modelu — to dwa różne rodzaje maszyn i oba są dobre. Zatrzymuję obie, i to z konkretnego powodu, o którym opowiem: niestety staniemy się kolekcjonerami różnego sprzętu. Mówię to wprost. Na RTX 1590 mogę uruchomić jeden model i jedną instancję — czyli jednego agenta. A ja potrzebuję roju agentów, i to jest wyzwanie. Możesz mieć jednego, wyjątkowo szybkiego agenta pracującego dla Ciebie — i do tego służy ta maszyna. Ale potrzebuję też w tle wielu mniejszych albo po prostu różnych agentów działających równolegle — i do tego idealna jest druga maszyna. Taką mam strategię i będę ją testował.
Jeśli chcesz wiedzieć więcej, obserwuj ten kanał. Jest już społeczność blisko dwóch tysięcy osób, z którymi budujemy to razem, uczymy się od siebie i dzielimy naszymi architekturami. Jeśli interesują Cię takie rozmowy, mamy spotkania każdego dnia tygodnia. Jeśli podoba Ci się ta treść — zostaw łapkę, subskrybuj, obejrzyj następny film i do zobaczenia na Discordzie. Cześć.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Wartość modelu mierz realną pracą, nie benchmarkami
Na czym polega: Autor ocenia nowy model nie po wynikach testów, lecz po tym, czy rozwiązuje konkretny, dotąd nierozwiązywalny problem (uruchomienie sprzętu Elgato na Linuksie).
Jak stosować: Testuj każdy nowy model na własnym, realnym zadaniu, które wcześniej sprawiało kłopot — to lepszy wskaźnik przydatności niż tabela benchmarków.
Na co uważać: Pojedynczy udany test to za mało, by uznać model za niezawodny; sprawdź powtarzalność na kilku różnych zadaniach ze swojego warsztatu.
2.Dziel pracę: duży model do architektury, lokalny do poprawek
Na czym polega: Duży model chmurowy nadaje strukturę i tworzy pierwszy szkic rozwiązania; drobne poprawki można potem delegować do tańszego modelu lokalnego.
Jak stosować: Do „pierwszego mocnego odcisku” (projekt, szkielet, trudny problem) sięgnij po najmocniejszy model, a iteracje i dopieszczanie zlecaj modelowi, który masz pod ręką.
Na co uważać: Model lokalny musi być realnie zdolny do poprawek — jeśli nie utrzyma jakości, oszczędność zamieni się w frustrujące przeróbki.
3.Dobierz plan płatności do intensywności użycia
Na czym polega: Przy sporadycznych problemach wystarcza płatne API rozliczane za akcję; przy codziennych wyzwaniach opłaca się subskrypcja rzędu 20 dolarów miesięcznie.
Jak stosować: Oszacuj, jak często faktycznie potrzebujesz dużego modelu. Rzadko — płać za pojedyncze wywołania API; codziennie — weź tanią subskrypcję zamiast płacić za każde użycie.
Na co uważać: Autor sam zaznacza, że subsydiowane dziś ceny tokenów będą rosnąć — nie planuj budżetu w oparciu o dzisiejsze stawki na dłużej.
4.Modele chmurowe potrafią cicho stracić na jakości
Na czym polega: Autor twierdzi, że GPT 5.5/Sol wyraźnie pogorszył się po premierze, prawdopodobnie przez zmianę ustawień po stronie dostawcy — bez informowania użytkowników.
Jak stosować: Nie traktuj jakości modelu chmurowego jako stałej. Zapisuj wzorcowe wyniki i okresowo porównuj, by wychwycić ciche pogorszenie.
Na co uważać: To relacja subiektywna, oparta na wrażeniu i głosach społeczności, a nie na twardych danych — traktuj jako sygnał ostrzegawczy, nie dowód.
5.Myśl w kategoriach „progu” niezawodności
Na czym polega: Dobierając model do zadania, ustalasz próg inteligencji i przewidywalności; model użyteczny to taki, który trwale utrzymuje się powyżej tego progu.
Jak stosować: Zdefiniuj dla swojego zastosowania konkretne kryteria „wystarczająco dobry” i regularnie weryfikuj, czy model wciąż je spełnia.
Na co uważać: U dostawcy chmurowego próg może zostać przekroczony w dół bez ostrzeżenia — dlatego sam pomiar progu nie wystarczy bez stałego monitoringu.
6.Model lokalny daje stabilność krytyczną dla biznesu
Na czym polega: Uruchamiany lokalnie model się nie zmienia — jeśli był powyżej progu, tam pozostaje, co pozwala gwarantować klientom przewidywalną jakość i koszt.
Jak stosować: Jeśli budujesz produkt lub usługę na AI, rozważ oparcie rdzenia na modelu, który sam hostujesz i kontrolujesz.
Na co uważać: Przewidywalność kosztuje z góry — sprzęt, konfiguracja, utrzymanie; policz, kiedy inwestycja się zwróci, zanim zrezygnujesz z chmury.
7.Przyjmij strategię hybrydową z przechyleniem ku temu, co kontrolujesz
Na czym polega: Rób maksimum na własnym, przewidywalnym modelu, a do większych modeli sięgaj tylko doraźnie, gdy lokalny nie daje rady — krótka zależność, szybkie wyjście.
Jak stosować: Zbuduj domyślny przepływ na modelu lokalnym i traktuj chmurę jako „koło ratunkowe” do konkretnych, jednorazowych trudności.
Na co uważać: Utrzymanie dwóch ścieżek to dodatkowa złożoność; upewnij się, że oszczędność i stabilność przewyższają koszt zarządzania obiema.
8.Różny sprzęt służy różnym celom — szybkość kontra pojemność
Na czym polega: RTX 1590 (32 GB, ogromna przepustowość) daje jednego bardzo szybkiego agenta; maszyna z 128 GB pamięci zunifikowanej jest wolniejsza, ale pomieści wiele modeli równolegle.
Jak stosować: Dobierz sprzęt do zadania: pojedynczy szybki agent — karta o wysokiej przepustowości; rój mniejszych agentów w tle — dużo pamięci kosztem szybkości.
Na co uważać: Żadna pojedyncza maszyna nie robi obu rzeczy naraz — autor wprost mówi, że skończysz jako „kolekcjoner sprzętu”, co oznacza realny koszt i złożoność.
9.Przepustowość pamięci decyduje o szybkości generowania tokenów
Na czym polega: Autor podkreśla, że to nie sama ilość pamięci, lecz jej przepustowość (rzędu 270 vs. 1700) przekłada się na prędkość, z jaką model produkuje tokeny.
Jak stosować: Wybierając sprzęt pod modele lokalne, patrz na przepustowość pamięci, a nie tylko na jej pojemność, jeśli zależy Ci na szybkości odpowiedzi.
Na co uważać: Wysoka przepustowość zwykle idzie w parze z mniejszą pojemnością — musisz świadomie wybrać kompromis między szybkością a liczbą i wielkością modeli.
10.Ucz się w społeczności budujących lokalne AI
Na czym polega: Autor prowadzi kanał i społeczność blisko dwóch tysięcy osób, które dzielą się architekturami i codziennie się spotykają, by wspólnie testować podejścia hybrydowe.
Jak stosować: Przy tak szybko zmieniającej się dziedzinie warto dołączyć do społeczności praktyków, którzy dzielą się realnymi konfiguracjami sprzętu i modeli.
Na co uważać: Materiał jest jednocześnie zaproszeniem na kanał autora — oddzielaj praktyczną wiedzę od elementu promocyjnego i weryfikuj rekomendacje własnym testem.