O czym jest ten film
- Theo testuje na żywo, bez cięć montażowych, tryb Ultrafast — inferencję z modelem Astra powyżej 300 tokenów na sekundę — na aplikacji budowanej w narzędziu Lakebed, z aktualizacjami widocznymi w czasie rzeczywistym.
- Cennik jest brutalny: tokeny wyjściowe Astry drożeją z 50 do 300 dolarów za milion (450 przy długim kontekście), a zapis do pamięci podręcznej kosztuje 75 dolarów za milion.
- Rachunki z życia wzięte: zrecenzowanie dwóch pull requestów, każdy poniżej 100 linii kodu, kosztowało 600 dolarów.
- Nawet plan za 500 dolarów miesięcznie nie ratuje sprawy — tygodniowa pula, wyceniona na około 1000 dolarów zużycia, znika w Ultrafast w całe 2,1 godziny.
- Szybkość zmienia sposób pracy: drobne korekty wysyłane „w locie”, ekran podzielony między aplikację i rozmowę z modelem, powrót stanu flow znanego z czasów ręcznego pisania kodu.
- Nowe wąskie gardło to już nie model, tylko narzędzia: gdy generowanie trwa 30 sekund, 30 sekund czekania na wywołania potrafi podwoić czas całego zadania — dlatego warto zmieniać prompt systemowy.
- Historia aplikacji Slopalytics: pierwszy działający szkic w około 90 sekund zamiast 15 minut na Opusie, ponad 50 wiadomości w jednym wątku i lepszy finalny interfejs — mimo że Astra jest obiektywnie gorsza od modeli Anthropic w designie.
- Bilans: około 550 dolarów wydane w Ultrafast oznaczałoby 90 dolarów na zwykłej Astrze i 12 dolarów na Soul 6.1 — ale Theo twierdzi, że bez tej prędkości nie zbudowałby aplikacji wcale.
- Zapowiedź: Soul 6.1 w wersji Ultrafast „wkrótce” (publiczne potwierdzenie); przy obecnym mnożniku 6x byłby około dziesięciokrotnie tańszy od Astry Ultrafast, co mogłoby odmienić opłacalność planu za 500 dolarów.
- Praktyczna rada: Ultrafast broni się głównie tuż przed wygasającym resetem limitu albo przy incydentach najwyższej wagi — nie warto kupować planu za 500 dolarów tylko pod niego.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Szybkość zmienia styl pracy: z listy poleceń na sterowanie w locie
Na czym polega: Przy ponad 300 tokenach na sekundę przestaje się wysyłać długie listy zmian i czekać na wynik. Zamiast tego rzuca się drobnymi korektami, gdy model jeszcze pracuje, i obserwuje efekt na żywo.
Jak stosować: Przy prototypowaniu ustaw aplikację i rozmowę z modelem obok siebie (podzielony ekran) i komentuj na bieżąco — dokładnie tak robił Theo, przebudowując prostą stronkę w aplikację kanban.
Na co uważać: Stary nawyk „wysyłam i wracam, jak skończy” marnuje cały sens szybkiego trybu. Z drugiej strony lawinowo rośnie liczba wiadomości — Theo wysłał ponad 50 w jednym wątku.
2.Prędkość modela odkrywa nowe wąskie gardło: wolne narzędzia
Na czym polega: Gdy generowanie schodzi z dziesięciu minut do триdziestu sekund, pół minuty czekania na komendy gita, buildy czy przeglądarkę podglądu przestaje być drobiazgiem — potrafi podwoić czas przebiegu.
Jak stosować: Pod szybkie tryby modyfikuj prompt systemowy, by model omijał czasochłonne, mało istotne akcje — np. zakaz uruchamiania przeglądarki z podglądem: ma zmieniać wyłącznie kod.
Na co uważać: To, co w starym rytmie było pomijalnym procentem czasu, teraz potrafi być jego połową — optymalizuj narzędzia, nie tylko model.
3.Zanim włączysz drogi tryb, przelicz go na dolary
Na czym polega: Review dwóch drobnych PR-ów poniżej 100 linii kodu kosztowało 600 dolarów. Mnożnik 6x na tokenach wyjściowych (300 wobec 50 dolarów za milion) boli najbardziej.
Jak stosować: Sprawdzaj licznik zużycia po każdej sesji, ustaw limity, a po fakcie poproś tańszy model o wycenę wątku — Theo kazał Soul 6.1 przeanalizować własny wątek pod kątem kosztów.
Na co uważać: Długi kontekst podnosi stawkę do 450 dolarów za milion tokenów wyjściowych — najgorsze połączenie to długi wątek plus szybki tryb.
4.Pamięć podręczna przestaje się opłacać
Na czym polega: Odczyt z cache w Ultrafast kosztuje 6 dolarów za milion — drożej niż zwykłe odczyty w innych modelach — a zapis aż 75 dolarów za milion.
Jak stosować: Przy pracy na powtarzających się, długich kontekstach policz, czy cache w ogóle się zwraca, zanim zaczniesz mnożyć wątki.
Na co uważać: Intuicja „cache zawsze oszczędza” wychodzi z wcześniejszej ery cenowej — tu może działać na niekorzyść.
5.Słabszy model w pętli wygrywa z lepszym bez pętli
Na czym polega: Astra jest obiektywnie gorsza od Opusa i Fable w projektowaniu, a finalny interfejs Slopalytics wyszedł lepiej właśnie na Astrze — bo wrażenia użytkownika dało się dopracowywać na żywo, iterując w minutowych cyklach.
Jak stosować: Do szlifowania interfejsu wybieraj szybką iterację z modelem, a nie najmocniejszy model z oczekiwaniem godzin na wynik.
Na co uważać: Wniosek nie przenosi się na zadania typu „wyślij i zapomnij” — duże refaktory czy analizy nadal lepiej robić mocniejszym modelem w zwykłym tempie.
6.Wartość szybkich trybów to nie zaoszczędzony czas, lecz projekty, które w ogóle by nie powstały
Na czym polega: Porównanie „550 dolarów zamiast 12” jest formalnie bezlitosne, ale Theodore twierdzi, że bez Ultrafast po prostu by tego nie zbudował: czekanie między krokami rozmywałoby kontekst i pomysły, więc pisałby mniejsze, ostrożniejsze polecenia.
Jak stosować: Szybki tryb traktuj jako narzędzie eksploracji — tam, gdzie sednem jest utrzymanie myśli od początku do końca.
Na co uważać: Nie uzasadniaj kosztu „szybkością”. Jedyny uczciwy argument to taki, że bez tej prędkości w ogóle nie podejmiesz tej pracy.
7.Limit i tak przepada? To jest moment na drogi tryb
Na czym polega: Niewykorzystany procent limitu przed resetem znika — więc Theo „wypala” go świadomie w Ultrafast, zamiast pozwolić mu się zmarnować.
Jak stosować: Trzymaj poważną pracę na osobnym narzędziu (u Theo: Opus), a gdy zbliża się reset, wykorzystaj resztę puli na eksperymenty w najdroższym trybie.
Na co uważać: Zapowiedziane resety notorycznie się spóźniają („będzie o 10:00” znaczy „najwcześniej w południe”) — nie planuj na nie nic krytycznego.
8.Pokrętło w produkcie to zaproszenie do przekręcenia
Na czym polega: Ultrafast dostępny jednym kliknięciem — podobnie jak maksymalny poziom rozumowania — kusi do użycia „bo jest”. ThePrimeagen spalił ponad połowę limitu w godzinę.
Jak stosować: Nowe tryby traktuj jak eksperyment: przeczytaj cennik, przetestuj na małym zadaniu, wróć do standardu.
Na co uważać: Brak ostrzeżeń przy przełączniku to problem projektowy — nie zakładaj, że produkt ochroni cię przed rachunkiem.
9.Śledź zapowiedzi tańszych szybkich trybów — zmienią kalkulację
Na czym polega: Potwierdzono publicznie, że Soul 6.1 dostanie wersję Ultrafast. Przy obecnym mnożniku 6x kosztowałby około dziesięć razy mniej niż Astra Ultrafast — czyli mniej więcej tyle, co zwykła Astra.
Jak stosować: Nie kupuj planu za 500 dolarów wyłącznie pod Ultrafast; poczekaj na premierę Soul 6.1 w tym trybie i dopiero wtedy licz opłacalność.
Na co uważać: Dziś plan za 500 dolarów daje równowartość około 1000 dolarów zużycza tygodniowo, która w Ultrafast znika w około 2,1 godziny.
10.Mierz przepustowość i koszt każdej sesji
Na czym polega: Realne pomiary Theo: około 30 tokenów na sekundę w trybie zwykłym, około 60 w szybkim i 320–340 w Ultrafast. Koszt: główny wątek 36 dolarów, dogrywka 250 — wobec 90 dolarów na zwykłej Astrze i 12 na Soul 6.1.
Jak stosować: Loguj tempo generowania i wydatki w podziale na wątki; przed decyzją o kontynuacji porównaj z tańszą alternatywą.
Na co uważać: Poczucie „kilku chwil” pracy potrafi odpowiadać setkom dolarów — subiektywny czas nie jest miarą kosztu.
Redakcyjne tłumaczenie
Wreszcie tu jest — i przepala limity szybciej, niż cokolwiek buduje
Ultrafast może nie dotarł do nas ultra szybko, ale już jest. I nie tylko potrafi absurdalnie szybko budować z modelem takim jak Astra — potrafi też przepalać limity i rachunki jeszcze szybciej, niż cokolwiek zbuduje. Korzystanie z tego wciąż wywołuje u mnie lekki zawrót głowy. Mam aplikację, którą na szybko skleiłem z Lakebedem; mówię „zrób jasny motyw i dodaj humoru” i po prostu patrzymy, jak wszystko zmienia się na żywo. Wszystko w czasie rzeczywistym. Mam nadzieję, że się nie potknę w słowach, bo nie chcę nic poprawiać w montażu i stracić efektu „na żywo”.
Chciałem właśnie zrobić zrzut ekranu strony — a tu już gotowe. Tak, znowu: w pełni na żywo. Po prostu przez to leci.
Praktycznych zastosowań jest mnóstwo: prototypowanie na gorąco, praca ramię w ramię z modelem, szybsze odhaczanie zadań, doświadczenia, które dla użytkowników wydają się znacznie bardziej bezpośrednie, a nawet używanie komputera przez model w sposób, który można obserwować i który bywa szybszy niż człowiek przy klawiaturze. Problem w jednym: za taką prędkość płaci się bardzo słono.
Przerwa na sponsora: Graptile i T-Rex
Zanim podam kwoty — szybka przerwa na dzisiejszego sponsora.
Proszę, cofnijcie się pamięcią do czasów sprzed AI; może zaboli, z góry przepraszam. Przypomnijcie sobie wyjątkowo złożony pull request, który musieliście zrecenzować. Pewnie przejrzeliście każdą linijkę, byliście przekonani, że widzieliście wszystko, co może pójść źle, zostawiliście lawinę uwag — kod wyszedł, a okazało się, że coś się posypało. Wtedy pewnie doszliście do wniosku, że najlepiej ściągnąć zmiany i wypróbować je samemu, zanim da się zielone światło. Tylko że to wolne, żmudne i irytujące. A jeśli się tego nie robi — czy w ogóle daje się realistyczną opinię? Ileż to razy kod wygląda całkowicie poprawnie, a po uruchomieniu zachowuje się nieoczekiwanie.
Dzisiejszy sponsor, Graptile, zadał sobie dokładnie to samo pytanie, patrząc, co robią ich agenci: czytają kod i znajdują problemy całkiem nieźle, ale radzą sobie o niebo lepiej, gdy dostają prawdziwy komputer, na którym ten kod można uruchomić. Stąd mój entuzjazm dla T-Rexa — rozwiązania, dzięki któremu agenci recenzujący pracują na realnej maszynie, faktycznie uruchamiają zmiany i je testują. To już nie „przejrzenie kodu i kciuk w górę, bo chyba jest okej” — kod jest naprawdę sprawdzany.
Uruchamialiśmy T-Rexa na prawdziwych bazach kodu i korzyść widać od razu. Przykład: w jednym z projektów Bena, którym zarządzamy całe nasze zaplecze na YouTube, PR wprowadziłby poważną regresję w obsłudze kluczy OAuth. Ponieważ Graptile odpalił zmiany na serio, problem wychwycił natychmiast i dołożył dowody błędów w artefaktach przebiegu. Do tego jest przejrzysty panel pokazujący, co dokładnie poszło nie tak. Nie dziwi: daj agentowi lepsze środowisko, a dostaniesz lepsze recenzje — i mniej bugów na produkcji. Więcej na soyv.link/grapile.
Sześćset dolarów za dwa drobne PR-y
Wracamy. Macie już kwotę w głowie? Widzę na czacie typy rzędu stu dolarów za sztukę. To było 600 dolarów za oba. Tak, sześćset — z dwoma zerami; czat nie wierzy, ale tak było. Cholernie dużo pieniędzy da się w ten sposób spalić.
A gdy wrócimy do cennika, wszystko robi się jasne: wyjściowe tokeny poszły z 50 do 300 dolarów za milion. Sześciokrotny wzrost to mocny cios — i to nie tylko na tokenach wyjściowych. Odczyt z pamięci podręcznej (cache) podrożał do 6 dolarów za milion, czyli drożej niż zwykłe odczyty w innych modelach, a zapis do cache za 75 dolarów za milion to poziom nie do uwierzenia.
Pięćset dolarów miesięcznie — i 2,1 godziny pracy
Powiem wam szczerze: nie sądziłem, że Ultrafast w ogóle jest dla mnie. I w dużej mierze nadal tak uważam. Moim zdaniem prawie nikt nie powinien teraz tego ruszać — zwłaszcza po stawkach API jest po prostu za drogo. Ale nawet to, co daje nowy plan za 500 dolarów miesięcznie, nie wyrabia. OpenAI mocno go subsydiuje: w ramach planu dostaje się równowartość około tysiąca dolarów zużycza tygodniowo, którą w Ultrafast spala się w całe… 2,1 godziny.
(Informacja dodatkowa: Codex, o którym mowa, to narzędzie OpenAI do pracy z kodem, dostępne w wyższych abonamentach.)
Odświeżyłem limity tuż przed przygotowaniem tego materiału. Na koncie Codex z planem za 500 dolarów miałem 38 procent do dyspozycji. Wysłałem dwa prompty: jeden — szybka budowa (38 sekund), drugi — „zrób jasny motyw i dodaj humoru” (16 sekund). Zużycie spadło z 38 do 37 procent. Jeden procent za niecałą minutę pracy.
Kanban na żywo
Poprośmy o trochę więcej. Zamiana w aplikację kanban z czatem na żywo; zmiany po kolei, żeby każda pojawiała się na serwerze deweloperskim na moich oczach. Niech też wdraża po drodze, bo Lakebed sam odświeża wdrożenie (deploy), gdy kod się zmienia — i to jest fajne. Na razie zerkniemy na wersję lokalną. Podkreślam: wszystko na żywo, bez zwykłych cięć montażowych. Przepraszam, Jeff — ty jako jedyny będziesz miał dziś łatwiej.
U góry siedzi mnóstwo zbędnego miejsca. „Usuń wszystkie niepotrzebne podpisy i informacje, porządnie wyczyść górną nawigację, żeby mniej miejsca szło na marne w pionie.” I patrzymy, jak te poprawki wchodzą na żywo. Zniknęło. Jedenaście sekund. Bardzo miło.
Z takim ustawieniem człowiek wchodzi w zupełnie inną relację roboczą. Po raz pierwszy od dawna sens ma znowu praca na podzielonym ekranie: aplikacja z jednej strony, rozmowa z modelem z drugiej. Bo teraz nie „wysyłam zadanie i zaglądam, jak skończy”, tylko siedzimy w tym razem. Jeśli męczą was te rutyny, w których wysyłacie zadanie, wątek znika, a wracacie do niego po jakimś czasie — to jest na to świetne lekarstwo. Wciąż jednak stanowczo za drogo.
Nowe wąskie gardło: narzędzia, nie model
I tu dochodzimy do pierwszej rzeczy, o której trzeba pomyśleć przy Ultrafast. Kiedy generowanie tokenów trwało dziesięć minut, a komendy gita czy buildy zajmowały mniej niż pół minuty, proporcje były tak nierówne, że optymalizowaniem reszty nie warto było sobie zawracać głowy. Teraz, gdy inferencja schodzi z dziesięciu minut do trzydziestu sekund, te trzydzieści sekund czekania na wywołania narzędzi przestaje być drobiazgiem — potrafi podwoić czas całego przebiegu. Mam wręcz ochotę używać pod Ultrafast innego promptu systemowego, żeby odciągać model od rzeczy mało ważnych, ale czasochłonnych. Na przykład kazałem mu nie ruszać przeglądarki z podglądem i zmieniać tylko kod na moje życzenie — bo nie chcę, żeby tracił sekundy na narzędzia; chcę po prostu widzieć aktualizacje w trakcie.
Sterowanie w locie i powrót stanu flow
Jeśli chcecie pracować w takiej pętli z modelem, ten rytm ma ogromny sens. A tam, gdzie robi się naprawdę szalennie, to przy modelach takich jak Astra — bo znoszą sterowanie w trakcie o wiele lepiej niż wcześniejsze generacje. Mogę wysłać „domyślnie ciemny motyw”, a moment później „nie chcę, żeby goście mogli pisać na czacie” — zmiana motywu weszła w pięć sekund. „Działanie pozorne — popraw teksty.” Wysyłam te komunikaty, gdy model robi coś innego, zmuszam go do zmiany kursu, a on ogarnia wszystko naraz. „Dobra. Można załączać obrazki? Zrób to dla nowych zgłoszeń i czatu — tylko dla zalogowanych. Nowe zadania też tylko dla zalogowanych.” Można po prostu obrzucać go spostrzeżeniami w trakcie pracy.
Efekt przypomina coś, czego dawno nie czułem przy kodowaniu: ten stan flow sprzed lat, gdy przeskakiwało się między kodem a efektem, wiedząc, co na co wpływa, i śmigało między jednym a drugim — za czasów, gdy kod pisaliśmy jeszcze sami. Tyle że teraz można tym sposobem robić dużo większe zmiany, bo to prawdziwa Astra i buduje się z nią prawdziwe rzeczy. Wszystko działa na Nvidii — ostatnio się dowiedziałem, że nie na Cerebrasie, jak myślałem.
(Informacja dodatkowa: Cerebras to firma znana z błyskawicznej inferencji na własnych, gigantycznych układach — stąd skojarzenie z rekordowymi prędkościami.)
Przy tym trybie to magia. Dołóżcie sterowanie głosem, a doświadczenie jest fundamentalnie inne. Rozumiem, czemu pracownicy OpenAI byli tak podekscytowani: przez to jedyne w swoim rodzaju uczucie żywego ping-pongu. I przez to, że rachunku nie płacą oni — bo mają nieograniczoną inferencję. No jasne, że mają; są pracownikami.
A teraz, po tej garści zmian, zerknijmy na limity. Przed tym fragmentem miałem 37 procent; wyłączyłem dwie funkcje, przełączyłem na ciemny motyw — i jestem na 34 w ramach planu za 500 dolarów. Trzy procent za kilka drobiazgów. Obłęd. Poproszę teraz Soul 6.1 na średnim poziomie wysiłku o przeanalizowanie wątku i wycenę w dolarach, a w międzyczasie łyknę piwa, bo robi mi się od tego smutno. Choć jedna ulga: podobno pracownicy OpenAI muszą teraz mieć zatwierdzenie dla każdego zadania na Ultrafast, bo nawet oni wpadają w restrykcje mocy obliczeniowej — taki to drogi. Już nie czuję tego tak bardzo jako „inferencja dla nich, nie dla nas”.
Gdy raz człowiek przyzwyczai się do Ultrafastu, wszystko inne wydaje się żółwie. I tak: przy standardowych stawkach API ta robota na Astrze kosztowałaby 7,72 dolara, a kosztowała 46,32. Z ciekawości sprawdziłem, ile wyszłoby na Soul 6.1 — około 1,10 dolara. Soul w normalnym tempie, zdolny do dokładnie tych samych rzeczy — a ja wydałem ponad czterdzieści razy tyle. Z jednej strony widać w tym, jak absurdalną wartością jest Soul 6.1; z drugiej — jak absurdalny jest koszt Ultrafastu.
Pokrętło, którego nie powinno było być
Patrzycie na te liczby i myślicie, że nie ma świata, w którym to się broni. Nie powiem, że się nie zgadzam. Wypuszczenie tego w takiej cenie uważam za szaleństwo. Nie chcę tego pokazywać, nie chcę tego promować i nie sądzę, żeby większość ludzi powinna tego używać. Nie dziwi mnie zresztą, że ktoś taki jak ThePrimeagen kupił plan za 500 dolarów, zobaczył, że jest w nim Ultrafast, postanowił spróbować — i w godzinę spalił ponad połowę limitu. Nie powinni byli robić z tego czegoś, co po prostu się klika. To ten sam problem, co z maksymalnym poziomem rozumowania: daj użytkownikom pokrętło, a oni przekręcą je do oporu. Skutkowało to masą złych decyzji — po stronie OpenAI za to, że pokrętło dali, i po stronie użytkowników, za to, że go użyli. Po prostu szkoda.
Slopalytics, czyli dlaczego mimo wszystko płacę
Gdzie więc leży wartość? Wytłumaczę to dość osobliwie, na świeżo wydanej aplikacji, którą zbudowałem: Slopalytics. Nie wiem, czy jesteście podobni do mnie, ale gdy widzę stronę i myślę „o, to naprawdę wygląda przyzwoicie: informacje podane czytelnie, nawigacja prosta, wszystko działa” — to przecież musiała powstać na modelu od Anthropic, prawda? Jasne, że Opus albo Fable. Otóż zbudowałem ją w całości na Astrze z Ultrafastem.
Co zabawniejsze, pracowałem nad tym równolegle na Opusie 5.5 i w Ultrafast. Opus potrzebował około piętnastu minut do pierwszego działającego szkicu; Ultrafast — niecałe dwie, koło minuty i pół. Tyle że to była Astra, więc domyślcie się: brzydko. Pierwsza wersja z Opusa, ta po blisko dwudziestu minutach, wyglądała wyraźnie lepiej niż ta z minuty i pół. Ale zanim zobaczyłem tę z Opusa, wersja z Astry była już lepsza — bo po tych dziewięćdziesięciu sekundach spojrzałem na nią i powiedziałem: „Oto moje zastrzeżenia do tej wersji”. A one wchodziły na żywo w przeglądarce. „Okej, to jest lepiej, ale te dwa elementy wciąż są słabe — spróbujesz inaczej?” Spróbował. „Nie podoba mi się. Cofnij i zrób w drugą stronę.” Skończyło się na tym, że wysłałem więcej wiadomości w jednym wątku niż od dawna w jakimkolwiek.
Po trochę grzebania w moim lokalnym kodzie T3 odnalazłem ten wątek i myślę, że to najlepszy sposób, żeby pokazać, dlaczego tak polubiłem tę robotę w Ultrafast. Posunąłbym się do stwierdzenia, że bez tego trybu Slopalytics mogłoby w ogóle nie powstać — budowało mi się w ten sposób o niebo przyjemniej.
Co się działo: ponieważ siedziałem w wątku, zauważyłem, że model próbuje użyć mojej umiejętności tsdev, służącej do hostowania serwerów deweloperskich przez Tailscale — a robiłem to na własnej maszynie, więc było to zbędne. I ponieważ faktycznie uważałem, poprawiłem go: „Jestem na tej maszynie, wystarczy localhost”. Trzydzieści sekund później migawka miała 688 wariantów. Widziałem jednak, że wczytywanie kuleje, bo gdy zaczynał sklejać stronę, w pewnym momencie wypluł adres — wszedłem tam i nie działało. Łącznie jakieś dwie minuty roboty — i miałem wersję lokalną z całością danych z Artificial Analysis i znośnym interfejsem.
(Informacja dodatkowa: Artificial Analysis to popularny serwis porównujący modele AI pod kątem jakości, szybkości i kosztów.)
Ale wykresy słupkowe były złe: wszystkie poziome, bez tego porównania, o które mi chodziło. „Pionowe słupki, niech się wszystko mieści na zwykłym ekranie.” Po czterdziestu jeden sekundach wyskoczył losowy błąd. „Nie do przyjęcia. Popraw ten stary problem z CSS-em.” Załatwione na żywo. „Użyj więcej logo i kolorów spójnych z laboratoriami; inspiruj się Artificial Analysis.” Minuta później — zaktualizowane. Odpowiadam niemal natychmiast; widać to po znaczkach czasu. On o 1:14, ja o 1:14. On o 1:13, ja minutę później — i to jeszcze niecałą. Byłem w środku tego procesu; wątek z Opusem, który robił to samo zadanie, przestałem w ogóle obserwować.
„Zmieniam zdanie co do sortowania. Średnie są bezużyteczne. Sortuj po najwyższej wartości. Wyrzuć linie średnich.” Te pomysły spływały mi właśnie dlatego, że sortowanie i grupowanie modeli robiły się na moich oczach. Jedna z rzeczy, które tu zrobiłem i które uważam za najfajniejsze: nie pokazuję wyłącznie poziomów maksymalnego rozumowania, żeby potem porządkować po tokenach na maksie — i to jest jedna z moich bolączek w dashboardzie Artificial Analysis. To zresztą jedno z moich ostatnich „flashbangowych” ostrzeżeń w ich kierunku, bo od teraz będę pokazywał Slopalytics. Porównajmy szybko: liczby na ich stronie głównej dotyczą Opusa 5.5 i Fable 5.1, wszystkie na maksymalnym rozumowaniu — podobnie koszty. Żadna z tych liczb nie trzyma się kupy. Gorzej w tokenach wyjściowych: Sonnet przy dwustu tysiącach, Opus przy stu dwudziestu, a Astra gdzieś daleko przy dwudziestu siedmiu. A gdy włączycie Opusa 5.5 na „high”, on się gdzieś zapodział. Widzicie go? Ja akurat wiem, dokąd zniknął — tutaj. Opus 5.5 siedzi bardzo daleko po lewej, mimo że wersja 5.5 na maksie jest tam daleko po prawej. W tym widoku nie da się dostrzec relacji między modelami z jednej rodziny. Więc u siebie pogrupowałem liczby według rodzin, a kolejność zależy od tego, który wariant ma najwyższą wartość — co daje zabaczne efekty uboczne. Gdy włączam Sonneta, jest zdecydowanie najgorszy pod względem wydajności tokenowej; ale gdy wyłączę „max” (mam przełączniki niski/średni/wysoki/maks) i zejdę na średni, Sonnet lekko się przesuwa — na maksymalnym wysiłku jest nieuzasadniony, a na średnim całkiem rozsądny; na „wysokim” spada już poniżej Opusa pod względem liczby tokenów.
Nie tylko pewnie nie poświęciłbym czasu na budowę tego bez Ultrafastu — nie wymyśliłbym tych wzorców interfejsu, bo wymagały ping-pongu: prosisz o coś, nie wygląda dobrze, prosisz o coś innego. I choć Astra jest o wiele, wiele gorsza od modeli Anthropic w designie, zaprojektowałem lepiej — właśnie dlatego, że byłem z nią w pętli. A dawno nie byłem w pętli. Wprowadziłem nawet zmianę w T3, żeby wątki w trakcie działania chowały się automatycznie, bo nie obchodzą mnie do czasu zakończenia — chyba właśnie że model pracuje ze mną i mamy te błyskawiczne wymiany.
Wracając do wątku: zauważyłem teraz, że w pewnym momencie przeszedłem na Soul 6.1 bez Ultrafast — bo dla Soul 6.1 nie ma Ultrafastu; nie mogę się doczekać, aż będzie. Zszedłem wtedy na zwykłe tempo nie z paniki przed wydatkami, ale dlatego, że jedzenie piekło mi się w piekarniku i chciałem móc wstać bez poczucia, że dużo tracę. Wróciłem z talerzem — a on wciąż pracował. Potem wróciłem do Ultrafastu i znowu leciałem.
Zobaczycie w tym wątku zupełnie inny styl pisania promptów niż mój zwykły. „Zrzut ekranu. Nie do przyjęcia. Więcej logo i kolorów spójnych z laboratoriami. Zmieniam zdanie co do sortowania. Średnie są bezużyteczne, sortuj po najwyższej. Wyrzuć wszystkie zbędne tytuły i podtytuły — jest od tego cringe.” I to wszystko leci w minutowych odstępach: 1:15, 1:16, 1:18, 1:14. Pięć promptów w cztery minuty, a każda odpowiedź poniżej minuty — niektóre po dwadzieścia sekund. Zmiana sortowania: osiemnaście sekund. Nie zdążysz się rozproszyć. Podobnie przycisk udostępniania: „To przecież zwykły adres — usuń. Domyślny widok nie musi trzymać hasha w URL-u; rób to dopiero, gdy użytkownik coś zmieni.” „Kolejność sortowania jest zła; domyślnie najwyższe na końcu.” „Czy da się narysować linię pokazującą, gdzie odcięte zostają pozostałe modele? A jak kliknę, niech się zapisze; najechanie na inne modele pokazuje różnicę w wyniku i koszcie.” To kolejny z tych szalonych pomysłów, które nigdy by mi nie przyszły do głowy bez tej wymiany.
Gdy chcę porównać dwa modele — powiedzmy Sonneta 5 na średnim poziomie z Fable 5.1 — w lewym górnym rogu wyskakuje mi panel porównania z różnicami w krotności kosztu, tokenów i wyników inteligencji. Wymyśliłem to wyłącznie dlatego, że wpatrywałem się w wykres w trakcie pracy i mogłem próbować różnych rzeczy. Przestawiałem tam sporo; nie pamiętam już pierwszej wersji — zrobiłem jej zrzut, bo jej nienawidziłem; zasłaniała wszystko. Trzy razy zmieniałem zdanie, gdzie ta karta ma wisieć, i chodziłem tam i z powrotem, aż byłem zadowolony. Nie podobało mi się, jak porządkuje panel, więc po prostu powiedziałem: „Chcę te trzy kolumny” — i zrobił. „Interfejs trochę miga przy najeżdżaniu; nie wiem, co najlepsze — może opóźnienie?” Zrobił, a ja znienawidziłem. „Zmieniam zdanie, to okropne.” Dwadzieścia pięć sekund zrobienia, dziesięć cofnięcia, i poszło kolejne. „Panel w lewym górnym, nie w prawym. Prawy górny róg to strefa zakazana — tam jest moja twarz w filmach. A tak w ogóle: można przenieść panel boczny na prawo w sposób, który nie ssie?” Po trzydziestu dwóch sekundach było. „Najechanie na nazwy na wykresie dwuwymiarowym powinno podświetlać daną linię i wyciszać pozostałe.” Rzuciłem to mimochodem przy przewijaniu — naprawione. „Dobra robota. Niestety wciąż brzydkie i wymaga porządków. Zajmij się tym; odpal kilka osobnych subagentów od brandingu.” I odpalił. Nasmarował garść nazw — wszystkie obrzydliwe. Poprosiłem inne wątki — śmietnik. Modele, jak się okazuje, wciąż nie umieją wymyślać nazw, nawet szybkie. Nazwa Slopalytics jest moja. I tak to stało się Slopalytics.
Widzicie zresztą, ile wiadomości wysłałem w tym wątku? Pięćdziesiąt i coś. Nigdy tyle nie wysyłam. Budowało się to zupełnie inaczej.
Policzyłem też realne tempo generowania w moim użyciu: zwykły tryb około 30 tokenów na sekundę (TPS), szybki około 60, Ultrafast ponad 300 — między 320 a 340. Szaleństwo. Ale policzyłem też koszt wszystkich wątków przy tej robocie: główny — 36 dolarów, a dogrywka z dodatkową pracą — 250. Gdybym zamiast Ultrafastu użył zwykłej Astr, zamiast 550 dolarów wyszłoby 90. A na Soul 6.1 — który zresztą zrobiłby tę robotę równie dobrze — 12 dolarów.
I teraz pytanie: czy oszczędność czasu jest dla was warta tych około 540 dolarów? Odpowiedź brzmi: prawdopodobnie nie. Jeśli porównujecie w ten sposób, nigdy w życiu nie powinniście używać Ultrafastu. Jest po prostu za drogi, limity przepala śmiesznie szybko, a plan za 500 dolarów czyni bez sensu. Nie powinien znajdować się w produkcie bez lawiny ostrzeżeń.
Nie „szybciej to samo”, tylko „w ogóle to zrobiłem”
Dlatego tak będzie mnie bolało go bronić — bo to, co powyżej, nie jest uczciwym porównaniem. Tam nie chodzi o to, że mogłem uzbroić się w cierpliwość i zaoszczędzić pięć stów. Chodzi o to, że po prostu bym tego nie zbudował. Gdybym miał czekać między krokami, tracilibym wątek myślenia, gubił listę rzeczy do poprawienia i składał ten kontekst od nowa po każdym zakończonym etapie. Skończyłbym przy tym pisaniem małych, ostrożnych poleceń — zamiast tego, co robię z Opusem: patrzę na wynik, spisuję dwadzieścia uwag, wysyłam i nastawiam się na od pięciu minut do dwóch godzin zwrotu. A ta praca w pętli jest znakomita do pewnych rzeczy — na przykład do szlifowania interfejsu. Głupio to brzmi, ale lepiej UI wychodzi mi na Astrze niż na Fable i Opusie. Nie dlatego, że Astra lepiej projektuje — obiektywnie jest gorsza. Tylko że design to w gruncie rzeczy sposób, w jaki użytkownik odbiera i dotyka rzeczy. A skoro mogłem więcej czasu poświęcić właśnie temu odbiorowi i siedzieć w pętli — mogłem lecieć.
Nadzieja: Soul 6.1 Ultrafast
I tu mam nadzieję — widać też, że łapie to nasz przyjaciel Bot Cooper. Jeśli mnożnik zostanie na poziomie 6x, to Soul 6.1 w Ultrafast wyjdzie wyraźnie taniej niż Astra, a dużo taniej niż Astra w trybie szybkim. Standardowe stawki: Soul 6.1 — 12,30 dolara tam, gdzie Astra — 90. W hipotetycznym świecie, w którym Soul 6.1 dostaje Ultrafast z dokładnie tym mnożnikiem, jest nie tylko dziesięć razy tańszy od Astry Ultrafast — wychodzi mniej więcej w cenie zwykłej Astr, jeśli nie taniej. Widzicie, dokąd to zmierza?
Sedno Astry Ultrafast nie jest w tym, żeby jej używać. Jest w tym, żeby na niej eksperymentować — żeby szaleńcy tacy jak ja przepalali na niej za dużo tokenów, sprawdzali, na co ją stać i jak wygląda taki rytm pracy, bo wszyscy liczymy na przyszłość, w której tę prędkość dostanie się w cenie nie wywołującej mdłości. A jeśli ta przyszłość nadejdzie — Soul 6.1 równie szybki jak Astra, za jedną dziesiątą ceny — widzę w tym swój domyślny model. Już teraz Soul 6.1 w trybie szybkim jest moim domyślnym wyborem do mnóstwa rzeczy. Otwieram nowy projekt we Fleecie, moim repo do zarządzania — a, jest przypięty do Astry. Poprawię to od razu, bo tak nie powinno być (na innych maszynach już zmieniłem). Niech będzie Soul 6.1 na wysokim poziomie wysiłku, w trybie szybkim — to moim zdaniem bardzo dobry balans prędkości, możliwości i wydajności do zadań typu zarządzanie maszynami w mojej sieci. Nie do pisania kodu, który wdrażam — ale do pracy bezpośrednio na moich systemach.
I jeszcze jedno. Tibo niedawno zaczepił „6.1 już wkrótce”. Wiele osób założyło, że chodzi o Astrę 6.1 — a to w rzeczywistości była ucięta odpowiedź właśnie o Ultrafast. To publiczne potwierdzenie, że Soul 6.1 w wersji Ultrafast nadchodzi. Moim zdaniem może to być Cerebras; nie jestem pewien — mogłyby to też być te szalone obejścia na Nvidii, którymi teraz operują. Tak czy owak: Soul 6.1 Ultrafast idzie do nas i może okazać się tym czynnikiem, który zmieni plan za 500 dolarów z przepłaconego w naprawdę niesamowitą ofertę.
Do czego w ogóle używać Ultrafastu
Zostaje nam jedno ważne pytanie: do czego tego używać? Jedyna sensowna odpowiedź to sprawy najwyższego priorytetu, które trzeba rozwiązać natychmiast — reagowanie na poważne incydenty, i to najlepiej zakładając, że pracujecie w OpenAI, bo poza nim nawet przy incydentach najwyższej wagi pieniądze raczej się nie bronią, chyba że są nieprawdziwe. Poza tym koszt jest w zasadzie niemożliwy do uzasadnienia.
Jest jednak jeszcze jeden moment, w którym da się go obronić — i dla mnie ten moment jest właśnie teraz. Mam dziewięć ręcznych resetów na koncie Ultrafast: sześć rozeszło się na evencie, reszta to te, które dostajemy wszyscy. Jeden wygasa za godzinę. Czyli mam godzinę na spalenie 34 procent limitu tego konta. Świetna pora na Ultrafast. A skoro nasz przyjaciel Tibo ogłosił dziś coś odważnego — „przez najbliższe 28 dni będziemy każdego dnia wydawać albo jedną rzecz będącą wyraźną poprawką, istotną dla większości użytkowników Codexu, albo pełny reset. Niech ulepszenia zaczną płynąć” — to okazji do przepalania będzie mnóstwo. Bo zawsze, gdy obiecą reset, on się spóźnia. Kiedy mówią „będzie o 10:00”, to najwcześniej wychodzi w południe. Więc po prostu zaczynam palić. Skoro do poważnej pracy i tak służę sobie Opusem, wyzerowane konto Codex niewiele mnie blokuje. Wyczuję tylko, że reset wieje — i zrzucam konto na deszcz. Czasem reset przychodzi, zanim dojdę do zera; czasem godzinę albo dwie po; czasem następnego dnia. Ultrafast odpalam więc wtedy, gdy konto ma i tak paść. Nie wiem, kiedy wy powinniście. Może tu i tam przy incydentach. Pracownicy OpenAI na pewno będą tego używać mnóstwo. Używajcie, gdy nie szkoda wam stracić. Nie przechodźcie na plan za 500 dolarów tylko dla tego — na razie się nie opłaca. Gdy pojawi się Soul 6.1 w Ultrafast, nagle może zacząć. Będę was na bieżąco trzymał.
A co z planem za 200 dolarów? Nie ma w nim Ultrafast, ale jest Soul 6.1, jest Astra, jest tryb szybki, jest mnóstwo innego i te wszystkie resety. Czy ten plan nadal wart jest swojej ceny? Na to potrzebuję kolejnego piwa — i kolejnego materiału, który pojawi się bardzo szybko. Subskrybujcie, jeśli jeszcze nie, żebym mógł wam to wszystko nadążać relacjonować w tym szalonym świecie AI. Teraz już wiecie, że Ultrafast warto omijać. Wkrótce dowiecie się też, czy plan za 200 dolarów wart jest używania — czy omijania. Do następnego razu. Na razie, nerdzi.