O czym jest ten film
- Otwarte modele odstają dziś od czołowych laboratoriów tylko o trzy do sześciu miesięcy i właśnie przeszły swój moment „agentowy” — skok, który u modeli zamkniętych nastąpił pod koniec poprzedniego roku.
- DeepSeek R1 zdemokratyzował rozumowanie, pokazując łańcuch myślenia; nowa fala (Kimi, DeepSeek V4) przenosi te zdolności na długie, autonomiczne zadania — za ułamek wcześniejszych kosztów.
- Materiał partnerski: Appadex Frontier Agent — otwarty framework agentowy z modelem 35B, który planuje, pisze i uruchamia kod w pełni offline na MacBooku.
- Największa wartość otwartych wag to specjalizacja: przyszłość należy do tysięcy wyspecjalizowanych modeli, a nie jednego dominującego. Do tego kontrola — „nie masz wag, nie masz modelu”.
- Głównym motorem dostrajania modeli jest jakość: przejście z ok. 90% do ok. 95% docelowego doświadczenia użytkownika, przy okazji nawet dziesięciokrotna oszczędność kosztów.
- Punktem zwrotnym są ewaluacje, nie sam trening; dziś jakość danych przeważa nad ilością — sto świetnych przebiegów jest więcej warta niż dziesięć tysięcy przeciętnych.
- Przewaga konkurencyjna przesuwa się z wykonania (już taniego) na unikalne dane i znajomość branży; programowanie to najbardziej oczywisty pion — Cursor i konkurencja trenują własne modele.
- Pretrening od zera pozostaje zarezerwowany dla garstki (lekcja Bloomberga GPT); otwarte wagi pozwalają rozłożyć koszt wiedzy ogólnej na wiele branż.
- W hiperrozwoju (wycena z 4 do niemal 18 mld dolarów w 7 miesięcy) komunikację ratują agenci: baza wiedzy, streszczenia spotkań, automatyzacja konfiguracji wdrożeń.
- Agenci programistyczni przechodzą do chmury — lokalny sprzęt wykłada się już przy ok. 30 równoległych agentach; rola inżyniera zmierza w stronę tech leada setki agentów.
Redakcyjne tłumaczenie
(Informacja dodatkowa: transkrypt wygenerowano automatycznie i mocno zniekształca on nazwy własne — modeli, firm i produktów. Tam, gdzie rekonstrukcja jest niepewna, pozostawiamy nazwy ogólne. Rozmówca, przedstawiony jako Dmytro, to współzałożyciel i dyrektor techniczny Fireworks AI — platformy do serwowania i dostrajania modeli o otwartych wagach; wcześniej spędził około dekady w Mecie, w zespie PyTorch.)
Otwarte modele dopadają czołówkę
David Ondrej: Dobrze, Dmytro — jesteś współzałożycielem i CTO Fireworks AI i chcę poznać Twoje zdanie o tym, co dzieje się z open sourcem w ostatnich miesiącach. Niedawno te modele wyraźnie odstawały od czołówki, a dziś są niemal na froncie postępu. Jak je oceniasz?
Dmytro: Otwarte modele naprawdę nabrały rozpędu. Zapanowała chyba zgoda, że — zależnie od tego, jak mierzymy benchmarki — są od trzech do sześciu miesięcy za wiodącymi laboratoriami. A to, co widzieliśmy ostatnio, od najnowszych premier mocniejszych modeli, przez lżejsze warianty, po nowego DeepSeeka w wersji Flash, to skok w zdolnościach agentowych. U modeli czołowych taki przeskok nastąpił chyba w listopadzie albo grudniu zeszłego roku: wszyscy przeszli od kopiowania fragmentów kodu z okna agenta i drobnych zadań do prawdziwych agentów, subagentów, długotrwałych operacji, pętli programistycznych, wyznaczania celów. Ten poziom możliwości właśnie skutecznie dotarł do modeli otwartych — i dlatego w tej przestrzeni jest teraz tyle emocji.
David Ondrej: Pierwszym prawdziwym momentem open source’u był chyba jednoznacznie DeepSeek R1, potem V3. Wygląda na to, że nowy Kimi to drugi wielki sukces, a dosłownie dwa tygodnie później dostaliśmy DeepSeeka V4. Które z nich uważasz za większe wydarzenie — Kimi czy V4 Flash?
Dmytro: Raczej Kimi. Można chyba wrzucić do jednego worka Kimi, DeepSeeka i warianty „Flash” — chodzi o to samo: znacznie lepsze radzenie sobie z pracą agentową. To przeskok podobnej skali jak premiera jednego z czołowych modeli w zeszłym roku — jak on się tam nazywał. Co do DeepSeeka V3 i R1 — ich premiery zdemokratyzowały rozumowanie. Pamiętam czasy, gdy otwarte modele, typu Llama, były po prostu prostymi chatbotami. Cała seria O1 od OpenAI była owiana tajemnicą — nie pokazywała ścieżki myślenia. I to, co półtora roku temu robiło największe wrażenie, to moment, gdy klienci, a nawet zwykli użytkownicy, pierwszy raz zobaczyli łańcuch rozumowania modelu. Bo skoro R1 był otwarty i dostępny, można było zajrzeć do środka i zobaczyć, jak on tak naprawdę myśli — i to było naprawdę świetne. Bardzo duży skok możliwości. Obecny bierze się ze skali, z fundamentu ogólnego rozumowania i ze znacznie lepszego uczenia ze wzmocnieniem (RL) przy zadaniach rozciągniętych w czasie. Efekt: można powierzyć modelowi znacznie większe zadania niż poprzednio — mówimy o programowaniu albo innej pracy merytorycznej — i to za ułamek kosztów. A otwarte wagi pozwalają dodatkowo dopasować model do konkretnej aplikacji.
[Materiał partnerski] Agent na własnym laptopie — Frontier Agent od Appadexu
David Ondrej: Chciałem mieć porządnego lokalnego agenta, który działa na moim sprzęcie i wykonuje prawdziwą robotę. Dlatego gdy Appadex otworzył źródła Frontier Agenta, musiałem go na poważnie przetestować. Frontier Agent to framework do uruchamiania agentów; pracuje na ich modelu o otwartych wagach, liczącym 35 miliardów parametrów, który bez problemu mieści się na moim MacBooku. Agent planuje zadanie, pisze kod, go uruchamia i oddaje finalny wynik. Wszystko to działa w stu procentach offline, z pełną prywatnością — a jeśli komuś brakuje mocy obliczeniowej, sam system może odpalać przez wersję webową Appadexu. Chciałem sprawdzić, co to naprawdę potrafi, więc zadałem mu takie pytanie: jak szybko nowy otwarty model dostaje wersję skwantyzowaną, którą da się uruchomić w domu? Przygotuj wykres typowego opóźnienia z dwóch ostatnich lat. Ruszyła grupa agentów, znalazła dane na Hugging Face, a potem inna grupa wszystko zweryfikowała. Na koniec powstał wykres, został dokładnie sprawdzony i dostałem wynik — kompletny, z podaniem źródeł i potwierdzeniem każdego stwierdzenia. Jeśli poważnie podchodzisz do AI, daj Frontier Agentowi gwiazdkę na GitHubie i pobierz model 35B z Hugging Face. A jeśli nie masz mocnego komputera — wejdź na appadex.ai; nowi użytkownicy dostają darmowe kredyty po rejestracji. To pierwszy link pod filmem. Dziękujemy Appadexowi za sponsoring.
Co to zmienia dla rynku
David Ondrej: Jakie są tego konsekwencje dla rynku i całego krajobrazu AI? Czy czeka nas wielka migracja w stronę modeli otwartych? Więcej hostingu na własnym sprzęcie, więcej dostrajania? Jak widzisz całą dziedzinę?
Dmytro: Jest tu kilka czynników. Po pierwsze, gdy pojawia się ogólna presja cenowa — a widzimy ją od czasu, gdy niektóre czołowe laboratoria ostatnio obniżyły ceny — to moim zdaniem dobra wiadomość dla wszystkich. Dla mnie najważniejsza zaleta otwartych wag to możliwość dostosowania i specjalizacji; na tym zresztą zbudowaliśmy Fireworks. Robimy mnóstwo fine-tuningu, ale tak naprawdę pozycjonujemy się jako firma od specjalizacji w AI. Chodzi o to, że budowanie jednego modelu, który ma być najlepszy we wszystkim, nie leży w naturze czołowych laboratoriów. Do ogólnej — czy jak kto woli nadludzkiej — inteligencji można się zbliżać inaczej: wykorzystując unikalne dane i wnioski płynące z każdego komercyjnego przypadku użycia, obniżając kompromis między kosztem a jakością i mocno wierząc w specjalizację, czyli dostrajanie i RL w każdym konkretnym zastosowaniu. Ta dziedzina w ostatnim półroczu zrobiła ogromne postępy. Widzimy wielu ludzi, których produkty nabierają tempa: zbierają dane, dostrajają modele pod siebie i zbierają zarówno poprawę jakości, jak i sporą oszczędność. Najbardziej ekscytuje mnie w tym ekosystemie — poza gotowością do użycia od razu — właśnie możliwość specjalizacji. I wizja przyszłości, w której nie jeden czy dwa modele rządzą wszystkim, tylko istnieją tysiące czy miliony wyspecjalizowanych modeli dla każdej dziedziny i zastosowania. Jest jeszcze, jak wspomniałeś, kąt kontrolny — powiedzmy: niezawodności. Sporo się działo wokół tego, że niektóre czołowe laboratoria praktykują śledzenie danych, odmowy odpowiedzi i ciche zmienianie modeli.
David Ondrej: No tak.
Dmytro: Stąd mentalność: „jeśli nie masz wag, to nie masz modelu”. Z jednej strony dostarczamy po prostu API. Ale ponieważ wagi są otwarte, możesz model pobrać i uruchomić gdziekolwiek indziej — jako firma czy klient zachowujesz kontrolę nad tym, co faktycznie działa. To bardzo istotny czynnik. I wreszcie zastosowania lokalne, na urządzeniu — laptop albo telefon.
Po co firmy dostrajają modele
David Ondrej: Kiedy ludzie zaczynają dostrajać własne modele, co jest głównym motorem? Jakość? Koszty? Co się zdarza najczęściej?
Dmytro: Zwykle jakość, ale jakość może pochodzić z dwóch stron. Weźmy przykład: mam startup, który zaczął jako nakładka na GPT albo Claude’a. Mam już interakcje, spory ruch, unikalne spostrzeżenia o tym, jak zachowują się użytkownicy i jak poprawić doświadczenie. Może wycisnąłem już sporo jakości z ulepszeń operacyjnych, inżynierii promptów i tym podobnych — powiedzmy, że jestem blisko 90% idealnego doświadczenia, które mam w głowie. Teraz mam dane i realny sposób mierzenia, co jest dobre, a co nie. I właśnie fine-tuning pozwala przeskoczyć z tych 80–90% na około 95% — bo nie poprawiam już tylko promptów i połączeń między komponentami, tylko doszlifowuję cały system własnymi danymi, rzeczywistymi wzorcami użycia i wnioskami. Część tego mogę wprost wtopić w wagi modelu, pobić modele czołowe w konkretnych zastosowaniach, a przy okazji zaoszczędzić na kosztach — a to zawsze się liczy. Zwykle to mieszanka obu rzeczy. Jedni mówią: gotowy model nie dowozi tego, czego potrzebuję; chcę najpierw podbić jakość, koszt jest wtórny. Inni mówią: płacę za model czołowy jak za zboże, a może wcale nie potrzebuję modelu ogólnego do prowadzenia produktu. Próbuję czegoś otwartego, może GLM-a czy podobnego — jest wystarczająco dobry, choć odrobinę gorszy od czołówki. Po porządnym promptowaniu, dopięciu integracji i odrobinie dostrajania robi się lepiej i nagle mam dziesięciokrotną oszczędność. Kolejność — najpierw jakość czy najpierw koszt — różni się więc zależnie od klienta.
Fireworks założona miesiąc przed premierą ChatGPT
David Ondrej: Skąd ta wizja, żeby zakładać Fireworks dokładnie miesiąc przed premierą ChatGPT? Bo potem było już w miarę oczywiste, że to będzie następna wielka rzecz, ogromny rynek i potężne bodźce do zakładania startupów. Ale Wy zaczęliście miesiąc wcześniej. Jaka była główna wizja?
Dmytro: To faktycznie ciekawa historia. Ja i kilku moich współzałożycieli pracowaliśmy wcześniej nad PyTorchem — frameworkiem, w którym implementuje się dziś zdecydowaną większość modeli głębokiego uczenia. Robiliśmy to mniej więcej od jego narodzin w 2016 aż do 2022 roku i przeszliśmy przez całą tę drogę: wchłanianie badań, ciągły rozwój deep learningu. To były czasy przed modelami fundamentowymi — przed generatywnym AI. Były może pretrenowane transformery typu BERT, ale każdy i tak wymagał mocnego dostrojenia pod konkretny przypadek, a ludzie często trenowali modele od zera — na przykład wizję komputerową dla autonomicznej jazdy. Widzieliśmy siłę budowania AI pod różne zastosowania: jak skalowanie danych i infrastruktury pozwala trenować znacznie lepsze modele i tworzyć magiczne produkty. Pierwotna motywacja Fireworks była więc taka: jest mnóstwo firm, które nie korzystają z deep learningu ani AI — zbudujemy platformę, która im w tym pomoże. Teza o specjalizacji i budowaniu wyspecjalizowanej inteligencji istniała od początku, ale ponieważ była to era przed dużymi modelami generatywnymi, fokus leżał bardziej w klasycznym deep learningu i platformie wokół PyTorcha. Tak zaczęliśmy — mieliśmy nawet już płacących klientów, szło dobrze. A potem, dwa miesiące po starcie, wypuszczono ChatGPT, a w ślad za nim zaczęły się pojawiać otwarte modele fundamentowe. Wszystko było w powijakach — jeszcze przed Llamą 1; wczesne modele nie były jakoś specjalnie inteligentne, ale jak na tamte czasy robiły wrażenie. Robiło się jasne, że kierunek „weź model fundamentowy, lekko go dostosuj do dziedziny albo użyj bezpośrednio” będzie miał znacznie większą nośność — jest prostszy i lepiej pozwala budować na już istniejącej inteligencji. I okazało się, że ten kierunek będzie dużo większy niż trenowanie od zera. Ambicja została ta sama: pomagać każdej firmie i każdemu deweloperowi budować wyspecjalizowaną inteligencję. Przesunięcia technologiczne zmieniły tylko sposób — dziś zajmujemy się niemal wyłącznie dużymi modelami językowymi.
Zanim zaczniesz dostrajać: ewaluacje
David Ondrej: Co dziś ludziom przeszkadza? Bo każdy chciałby mieć własny, dostrojony model — czy to dla szpanu, czy dlatego, że ma dane i chce sprawniejszy model pod konkretne zastosowanie. Co powstrzymuje większość przed sprawnym fine-tuningiem? Wciąż powtarzam, że to problem nierozwiązany.
Dmytro: Na pewno jest trudniejszy niż pisanie promptów. I od razu zastrzegę: przy całym tym rozwojowi LLM-ów to nie jest punkt startowy dla dewelopera budującego prototyp startupu. Zdecydowanie zacznijcie od gotowego modelu. Jeśli produkt łapie trakcję, zbieracie dane i zaczynacie skalować — wtedy dostrajanie zaczyna mieć sens. A punktem zwrotnym są ewaluacje: po prostu umiejętność rozpoznania, na dużą skalę, co w produkcie jest dobre, a co złe. Świetne startupy wyróżniają się właśnie tym, że stawiają ewaluacje na pierwszym miejscu. Bo nawet jeśli nie tunujecie modeli, chcecie wiedzieć, których modeli używać i jak poprawiać wyniki. Zaczynanie od ewaluacji spina się z konkretami: czy na pewno dobrze mierzycie wyniki w swoim produkcie? Czy wiecie, z czym użytkownicy naprawdę mają do czynienia? Potraficie to zasymulować odpowiednimi metrykami i zbiorami offline? I stale to doskonalicie w miarę rozwoju AI, żeby wyłapywać ciekawe porażki i miejsca, w których model sobie nie radzi? To jest kluczowe — i szczerze mówiąc, na tym właśnie ludzie w firmach AI spędzają większość czasu pracy nad jakością. Gdy to macie, można tym podnieść warstwę interfejsu, ale można też przenieść to na etap dostrajania: wpiąć same modele w budowanie zbiorów danych albo wykorzystać w RL. Fundamentalne kryterium sukcesu brzmi więc: czy zebraliście właściwe dane pod swoje zastosowanie? Umiecie odróżnić dobre od złego i sformułować funkcję straty? Co robi wrażenie w przejściu na RL i fine-tuning — na tle klasycznego deep learningu — to to, że jakość znaczy dziś dużo więcej niż rozmiar zbioru. Przy pretreningu od zera potrzeba milionów, miliardów czy bilionów tokenów albo obrazów: trening modelu wizji to miliony zdjęć. A namacalny postęp można dziś osiągnąć na zbiorach wysokiej jakości dla precyzyjnych środowisk — liczących setki przykładów, a nawet mniej. To bardzo ważne, bo modele mają już dość inteligencji w podstawie; uczycie je naprawdę czegoś wąsko określonego. Dlatego znacznie łatwiej skalować jakość: woleję sto dobrze przygotowanych środowisk i świetnych przebiegów (tzw. rolloutów, czyli pełnych wykonań zadania) niż dziesięć tysięcy wątpliwej jakości.
[Wtrącenie prowadzącego] Zaproszenie na Discorda
David Ondrej: Przy okazji: jeśli chcecie rozmawiać z ludźmi z samego czoła AI, dołączcie do nowego serwera Discord, który właśnie odpaliłem. Jest całkowicie darmowy — to miejsce do dyskusji z ludźmi, którym na AI naprawdę zależy i którzy podchodzą do tego poważnie, a przy okazji dowiecie się tam o moich projektach i startupach wcześniej niż ktokolwiek inny. Link jest pod filmem. Wbijajcie i napiszcie „dzień dobry” na kanale ogólnym.
Fosa w czasach taniego kodu
David Ondrej: Czy to jedna z podstawowych dróg? Gdyby dziś budować firmę w obecnych warunkach — czy tak tworzy się fosę konkurencyjną? Chcesz powiedzieć: zbierać dane wysokiej jakości, których inni nie mają, i stroić własne modele? A jakie inne sposoby wchodzą w grę? Bo skoro software jest dziś taki łatwy do zbudowania, to pojęcie przewagi sprzed pięciu lat, a nawet dwóch, się zmieniło.
Dmytro: Dokładnie. Samo wykonanie software’u staniało. Ale budowanie produktów wysokiej jakości wciąż ma swoją premię. Ludzie nazywają to smakiem, wyczuciem czy jakkolwiek — w gruncie rzeczy to umiejętność rozumienia użytkowników i szybkiego iterowania. Cykl rozwoju jest krótszy, bo pisanie interfejsów przestało być wąskim gardłem. Ale kod to tylko mała część pętli rozwojowej. Budowa świetnego produktu przyspieszyła — jednak nie bezgranicznie i wciąż wymaga sporo wnikliwości i smaku. Największą przewagą w świecie, w którym wykonanie tanieje, są unikalne spostrzeżenia o swojej dziedzinie. Produkt konsumencki — czy rozumiesz konsumentów, masz dane o użyciu i wiesz, co znaczy „dobry produkt”? Aplikacja branżowa — czy dobrze znasz tę branżę i potrafisz wykorzystać dane albo wnioski, których inni nie mają? W takich przypadkach wykonanie staniało, ale ono i tak było małą częścią procesu. Za to posiadanie spostrzeżeń, danych i barier wejścia ma dziś ogromną wartość, bo pozwala najpierw zbudować dobry prototyp, a potem nakręcać samonapędzającą się pętlę danych. Widać to w wielu startupach AI. Programowanie to chyba najbardziej oczywisty pion, prawda?
David Ondrej: Tak.
Dmytro: Oczywiście — odniosły ogromny sukces i miały gigantyczny wzrost użycia. Zaczynały od świetnego doświadczenia użytkownika wokół modeli czołowych i coraz mocniej idą w specjalizację. Od zeszłego roku czołowe firmy kodujące trenują własne modele na otwartych wagach, bo mają realne dane i unikalne wzorce w tych danych. Dane już istnieją — i w większości są to lepsze dane kodowe niż te, którymi dysponowały w tamtym momencie laboratoria czołowe. To pozwala im budować lepsze modele: sięgać wyżej z jakością w niektórych przypadkach albo uzyskać korzystniejszy stosunek jakości do kosztów, bo mogą się specjalizować w coraz precyzyjniejszych zadaniach programistycznych. To samo widać u wielu klientów w innych dziedzinach. Niektórzy robią to jawnie — Perplexity, Genspark, aplikacje konsumenckie czy Harvey, który specjalizuje się w branży prawnej. Wszyscy przechodzą od bycia zwykłą nakładką do zbierania wniosków z danych i użycia oraz budowania przewagi przez dopasowanie całego stosu — od funkcji po wydajność.
Czy wielcy klienci odejdą do własnego pretrainingu?
David Ondrej: Wspomniałeś o Cursorze. Z tego, co pamiętam — nie jestem pewien, czy to informacja dokładna — w pewnym momencie generowali ponad połowę Waszych przychodów. To prawda?
Dmytro: Tak było u praktycznie każdego dostawcy inferencji na modelach otwartych — u nas i u konkurencji w zeszłym roku. Dziś już nie, bo rynek mocno się zdywersyfikował. Ta koncentracja minęła. To naturalne w rynku z tak zaawansowanymi możliwościami: kto jest na froncie, ten zwykle rośnie wykładniczo, a potem pojawiają się analogiczne produkty w różnych dziedzinach i skalują się równie mocno.
David Ondrej: Tak, ale moje pytanie było odrobinę inne. Brzmiało: „Czy nie martwi Was, że gdy firma zbierze dane i zacznie dostrajać modele, to przy ich wystarczającej ilości — jak Cursor — będzie mogła trenować własne modele od zera?”. Co się stanie, jeśli część Waszych największych klientów przejdzie od uruchamiania dostrojonych modeli do własnego pretrainingu?
Dmytro: Po pierwsze, możemy im pomóc również w skalowaniu pretrainingu. Ale tych, którzy pójdą w pełny pretrening, będzie garstka — dla bardzo wąskiej grupy ma to sens, bo w praktyce oznacza: zostaję całkiem nowym laboratorium. A to —
David Ondrej: Ekstremalnie trudne.
Dmytro: Ekstremalnie trudne i bardzo drogie. Specjalizacja przychodzi stopniowo. Zaczyna się od post-treningu, potem skaluje się post-trening, potem mid-training, żeby wstrzyknąć więcej wiedzy podstawowej z danej dziedziny, a nie tylko poprawiać jakość. A na końcu ktoś mówi: „zbiorę miliard dolarów, kupię mnóstwo sprzętu i może spróbuję własnej architektury”. Ten ostatni krok jest naprawdę bardzo drogi. I jeśli już, to grono osób, które to robią, raczej się kurczy. Bo pamiętasz pierwszą falę LLM-ów — mówimy o 2022, a w szerszym obrazie 2023 roku, kiedy fokus leżał na pretreningu. MosaicML przejęły Databricks, było to bardzo na topie i wielu klientów próbowało trenować LLM-y od zera. Symbolem tamtej fazy był chyba Bloomberg GPT — modele finansowe na danych Bloomberga, które szybko zostały wyprzedzone przez ogólne modele pretrenowane. Właśnie dlatego, że pretrening to w dużej mierze kompresja ogólnej ludzkiej wiedzy — trudna, droga i mocno korzystająca z efektu skali, co oznacza, że osób, które realnie mogą to robić i pozostać na froncie, z czasem przybywa nie, ale ubywa. Ekscytujące w otwartych wagach jest to, że pozwalają ten koszt rozłożyć: pretrenować i skompresować model raz, a potem specjalizować go przez post-trening pod wiele różnych branż. To znacznie stabilniejszy punkt równowagi. Oczywiście znajdą się tacy, którzy przejdą do pretrainingu własnych modeli, ale będzie ich bardzo mało. Osób, które wejdą w tę przestrzeń i będą budować w granicach swojej specjalności — nie dochodząc nigdy do skali, przy której pretrening ma sens — będzie około stukrotnie więcej.
Dlaczego nie hardware
David Ondrej: Dlaczego zdecydowaliście się nie wchodzić w sprzęt i skupić na warstwie optymalizacji software’owej?
Dmytro: Dobre pytanie. Patrzymy na to przez pryzmat misji: jak najszybciej doprowadzić do świata, w którym każdy ma własną, wyspecjalizowaną pod siebie inteligencję. To jest rdzeń firmy. Wielką wartość widzimy w platformie, w rozwijaniu funkcji inferencji i treningu, w dbaniu o to, żeby były dobrze zaprojektowane, spójne i realnie rozwiązywały problemy klientów. Po stronie mocy obliczeniowej jest mnóstwo podmiotów skupionych wyłącznie na skalowaniu computu — nowych chmur nie brakuje. Duża wartość tkwi w agregowaniu i ujmowaniu tego computu w abstrakcję, bo jest bardzo zróżnicowany i niejednorodny. Nazywamy to u nas wirtualną chmurą: działamy na dziesiątkach nowych chmur i tradycyjnych dostawców i przykrywamy to wszystko warstwą abstrakcji, żeby nikt nie musiał się zastanawiać, gdzie fizycznie stoją GPU czy inne akceleratory. Z perspektywy klienta: nie musicie załatwiać computu ani whole tego zamieszania. Czy ma natomiast sens schodzić niżej — do zarządzania centrami danych, energią i tym podobnych? Na tym etapie, u nas: nie. Orkiestracja computu, platforma deweloperska i skupienie na przypadkach użycia same w sobie są gigantycznym przedsięwzięciem, a startup powinien trzymać się swojego głównego wyróżnika i nie rozpraszać się. Krótko mówiąc — nie wykluczam czegoś takiego w przyszłości, ale fokus pozostaje przy orkiestracji i platformie. Współpracujemy z naprawdę dobrymi dostawcami, którzy zajmują się energią, skalowaniem i centrami danych. To zresztą też bardzo trudna robota.
Firma AI w drugiej połowie 2026 roku
David Ondrej: Wspomniałeś, że fokus i świadomość istoty własnego zakładu to jeden z kluczy do sukcesu. Co jeszcze doradziłbyś komuś, kto chce założyć firmę AI w drugiej połowie 2026? Jakie pomysły wziąłbyś pod uwagę? Jak byś do tego podszedł? Jak wyglądałyby pierwsze czterdzieści dni?
Dmytro: Wracając do myśli o taniejącym wykonaniu: gdy koszt dąży do zera, ogromną wartość nabierają przemyślenia i pomysły. U nas, jako firmy B2B, perspektywa jest inna — skupiamy się na klientach i skalowaniu. Moim zdaniem wiele ciekawych firm można założyć w obszarze wprowadzania AI do konkretnych branż. Widzimy to i zobaczymy więcej ludzi z dziedzin takich jak produkcja czy transport — z biznesów o bardziej tradycyjnym charakterze. Jest potencjał, żeby przynieść tam AI, a jeśli głęboko rozumiesz jakąś dziedzinę, wiesz, jak z pomocą AI robić rzeczy inaczej — możesz zbudować firmę i zyskać przewagę pierwszeństwa. To jeden z kluczowych czynników. Po stronie konsumenckiej trudno cokolwiek stwierdzić — sukces produktów konsumenckich jest zwykle trudny do przewidzenia. Na pewno zobaczymy więcej ekscytujących aplikacji, bo koszt wykonania spada. Ale naprawdę trudno założyć się, co tam zadziała.
Hiperwzrost od środka
David Ondrej: Rosniecie w zawrotnym tempie. Wycena wzrosła czterokrotnie w jakieś siedem miesięcy — z 4 do niemal 18 miliardów dolarów. Jak to wygląda od środka? Co zaczyna piszczeć pod naporem wzrostu? Co się zmienia? Opisz nam doświadczenie takiego skalowania.
Dmytro: Jako współzałożyciel wiem, że im większa firma, tym częściej trzeba zmieniać i stroić procesy. To bardzo ekscytujące. Chyba właśnie przekroczyliśmy „liczbę Dunbara” — punkt, w którym człowiek nie jest w stanie zapamiętać więcej niż stu pięćdziesięciu twarzy. Kamień milowy ekscytujący i trochę przerażający. Przy skali komunikacja po prostu się rozpada. Widziałem to wcześniej przez dziesięć lat w Mecie — od etapu bliskiego startupowi aż po gigantyczną organizację. Duże firmy działają zwykle mniej sprawnie niż startupy właśnie dlatego, że więzi wewnętrznych jest mniej. Można temu częściowo zaradzić. Po pierwsze — ogromnie pomaga organizowanie procesów wewnętrznych za pomocą AI. W tradycyjnych organizacjach mnóstwo wysiłku przepada na składaniu i przekazywaniu informacji. Na przykład: mam zespół, w którym czyjaś praca to dosłownie podsumowywanie celów i postępów i przekazywanie ich innemu zespołowi, który robi to samo, a potem omawianie rozjazdów. Spora część takiej wymiany da się zautomatyzować. Dlatego oczywiście korzystamy z wielu wewnętrznych agentów. Kiedyś, gdy Slack się zapychał, trzeba było porządkować to ludzkimi procesami — dziś można to zlecić agentom.
Przykład agenta, który warto wdrożyć
David Ondrej: Możesz podać jeden przykład? Niekoniecznie najlepszy — taki, który Twoim zdaniem firmy powinny wdrożyć. Konkretnego agenta, który oszczędza Wam dużo czasu wewnętrznie.
Dmytro: Może to być coś oczywistego, ale fundamentem jest baza wiedzy — to, żeby informacje o tym, jak firma działa, były dostępne dla agentów. Może to być coś tak prozaicznego jak przeładowanie ważnych informacji do plików i wstawienie ich do repozytorium. I zadbaniu o to, żeby gdy chcesz coś dodać, móc poprosić sprytnego agenta o wpisanie we właściwe miejsce. Bardzo wiele osób nagrywa też wszystkie spotkania i potrafi je przetwarzać i streszczać — to też absolutne podstawy. Z perspektywy skalowania ekscytuje mnie to, że można robić więcej, produktywniej i bliżej rzeczywistości — dużą część tej pracy da się zautomatyzować. Prowadzimy na przykład mnóstwo wyspecjalizowanych wdrożeń pod różne zastosowania. Czasem model nie jest nawet dostrojony, a czasem jest, ale konfiguracja wdrożenia jest specyficzna dla przypadku: wychodzą różne ustawienia, zależnie od tego, czy celujesz w konkretne czasy reakcji, czy optymalizujesz koszt i przepustowość kosztem prędkości. Kiedyś wymagało to ludzkich inżynierów wydajności przy każdym przypadku. Dziś można to skalować agentami: ludzie skupiają się na ustawieniu właściwych pomiarów i środowiska oraz na tym, jak zautomatyzować mierzenie, a samo wykonywanie i rozciąganie na kolejne przypadki, modele czy typy sprzętu przejmuje comput. Bo najważniejsze jest to, co mierzysz — i to wymaga człowieka; samo wykonanie skaluje się już mocą obliczeniową, nie głowami. To pozwala trzymać zespoły szczupłe i unikać całego narzutu, który idzie z powiększaniem organizacji ludzkimi siłami. Dziś jest to oczywiście łatwiejsze po stronie inżynierskiej. Po stronie sprzedażowej i marketingowej jest mnóstwo okazji do namnażania — dystrybucji informacji, jej agregacji, wyciągania wniosków biznesowych — ale interakcje międzyludzkie wciąż zjadają większą część czasu. Ta strona będzie więc wymagała większego skalowania, mniej więcej proporcjonalnego do liczby klientów, w odróżnieniu od strony inżynierskiej. Co do samej porady: jeśli nie używacie nawet prostych rzeczy — jeśli nie macie agentów AI na Slacku i nie korzysta z nich cała firma — to już jesteście w tyle. I bardzo ważne jest danie agentom właściwych narzędzi. Na pewno warto wydzielić w firmie ludzi, którzy poważnie pomyślą o infrastrukturze agentów — na zewnętrznych usługach czy budując coś od zera. Sam wybór narzędzia jest zresztą z czasem mniej istotny. Ważne, żeby ludzie faktycznie zadawali pytanie: „W procesach mojej firmy — czy AI może wziąć na siebie kawałek? Ma odpowiednie dane wejściowe? Mam sposób monitorowania, co działa, a co nie?”. Widzieliśmy to wielokrotnie: gdy tylko to się ustawi, ludzie chętnie z tego korzystają i przyjmują to wszyscy — techniczni i nietechniczni — bo to po prostu podnosi produktywność. Ludzie wolą zajmować się kreatywnymi wnioskami, ekscytującymi problemami skalowania czy projektowaniem procesów niż przenoszeniem informacji z jednego kanału Slacka do drugiego, do dokumentu czy prezentacji. To jest naprawdę ekscytujące.
Inżynieria inferencji: kompromisy bez złotego środka
David Ondrej: Porozmawiajmy chwilę o inferencji. Co jest potrzebne, żeby serwować ogromny model — taki jak Kimi — z bardzo wysoką liczbą tokenów na sekundę? Co ludzie zwykle pomijają?
Dmytro: Sedno jest takie: jeśli poprosisz AI o wymienienie technik przyspieszania inferencji, dostaniesz pewnie dwadzieścia–trzydzieści punktów, w większości trafnych. Trudne jest to, żeby wszystko faktycznie działało razem — jak to zaprogramować i zaprojektować w realnej implementacji: od sprzętu i organizacji kerneli GPU, przez podział modelu na wiele procesorów i innych akceleratorów, po organizację ruchu danych i kierowanie żądań we właściwe miejsca. Wszystkie te warstwy muszą się zgrać, żeby inferencja była szybka i niezawodna — i to właśnie czyni pracę nad nią fajną. Właśnie dlatego mówiłem o specjalizacji nie tylko modeli, ale i ich wdrożeń: kompromisy będą różne. Jeśli chcesz serwować Kimi z naciskiem na prędkość, zapłacisz pewnie więcej i serwery ustawią się inaczej niż przy serwowaniu pod ogólną przepustowość. Przy prędkości zainwestujesz znacznie więcej w dekodowanie spekulatywne, żeby odpowiedź przychodziła szybciej, i raczej nie obciążysz serwerów mocno — małe partie, czyli batche, żeby przetwarzanie śmigało. Ma to konsekwencje dla podziału modelu między GPU, rozmiaru replik i tak dalej. Bardzo ważne jest też, żeby nadchodzące żądania nie utykały w kolejkach — więc optymalizujesz balansowanie ruchu pod ekstremalnie niski czas do pierwszego tokena. Z drugiej strony: jeśli po prostu tniesz koszty i odpalasz agentów w tle, w zupełności wystarczy Ci dziesięć–dwadzieścia tokenów na sekundę. Wtedy wszystko wygląda inaczej: ładujesz wdrożenia do maksimum, z ogromnymi batchami, żeby odczyty pamięci rozkładały się na GPU. Wdrożenie jest pewnie rozproszone na wielu procesorach, żeby obsłużyć wielkie warstwy mieszanki ekspertów (mixture-of-experts) przy bardzo dużym batchu, a routing nastawiasz na to, żeby wszystko było wypełnione po kres i tokeny płynęły najtaniej, jak się da. To tylko trzy przykłady konfiguracji — a nawet zanim przejdziemy do specjalizacji samych modeli, jest mnóstwo rzeczy wokół kwantyzacji czy trenowania własnych modeli do dekodowania spekulatywnego, którymi można dopasować się do zastosowania, nie ruszając modelu. Twoja dziedzina ma pewnie charakterystyczne wzorce danych i możesz pod nie wytrenować lepszy model spekulatywny. Część tego robimy na naszej platformie automatycznie.
Agenci: laptop czy chmura?
David Ondrej: Wspomniałeś przy okazji o agentach działających w tle. Czy uważasz, że uruchamianie agentów będzie się coraz bardziej przenosić do chmury — tak jak firmy przed erą AWS trzymały własne serwery, a potem, gdy zabrakło mocy, przeniosły się do chmury? Czy widzisz ten sam trend teraz?
Dmytro: To zależy od przypadku. Kiedy mówię o silnikach agentowych, mam głównie na myśli zastosowania, w których człowiek nie siedzi przed wyjściem agenta — więc opóźnień nie ma na czym usidłać, po prostu nie grają większej roli. W takim świecie piaskownica może działać po stronie klienta, a model gdzie indziej. W agentach pojedyncze wywołanie narzędzia trwa zwykle kilkaset milisekund i synchronizacja między wywołaniami kolejne kilkaset — więc opóźnienie sieci nie jest wielkim czynnikiem. Nawet jeśli model działa w chmurze, a narzędzia lokalnie, albo odwrotnie — różnicy wydajnościowej nie ma wielkiej. Mówię o typowych przypadkach. A co do wdrożeń: większość produktów faktycznie uruchamia agentów w chmurze.
David Ondrej: Mam na myśli rozwój software’u. Sam development.
Dmytro: Tak, o to chodzi.
David Ondrej: Przy programowaniu — tak, to ma sens; widać w tej przestrzeni mnóstwo produktów, które tak robią. Np. Cursor.
Dmytro: Tak.
David Ondrej: Mocno pchają agentów chmurowych. My też widzimy to u siebie — rozwijając pod GPU, nie będziesz trzymał procesora klasy centrum danych pod biurkiem, to mało praktyczne. Nawet w erze przedagentowej wszyscy rozwijali software na zdalnych maszynach, łącząc się z VS Code po SSH albo przez kontenery. Więc bardzo naturalne jest: mam zdalne środowisko, to po prostu dodaję agentów w tym samym kontenerze Dockera, bez spinki z czymkolwiek specjalnym. To przejście było dużo łatwiejsze. Z każdym miesiącem ma to sens dla większej liczby zastosowań, bo jeśli nie potrzebujesz człowieka przed laptopem, możesz po prostu skalować poziomo. Są nawet takie śmieszne symptomy tej zmiany — ludzie kombinowali kiedyś, jak zablokować usypianie ekranu laptopa w drodze do pracy. Przeniesienie środowiska deweloperskiego do chmury to z naszej perspektywy od lat norma: rozwój pod GPU zawsze tak wyglądał, a i przed erą agentów wszystkie narzędzia były dostępne dla pracy zdalnej. Można odpalać dziesiątki, setki, tysiące równoległych procesów deweloperskich. Idealne interfejsy dziś to moim zdaniem agent na Slacku — wirtualny kolega napędzany AI, jakkolwiek to nazwać: prosisz go o poprawienie czegoś, on odpala środowiska i przysyła podglad tego, co działa, albo sensowny raport. Kod może przeglądasz, a może nie — zależnie od kompromisów Twojej aplikacji — ale podstawowa interakcja staje się asynchroniczna i wbudowana tam, gdzie pracujesz. Widzimy to dużo w programowaniu, ale i w innych zadaniach. Jedną z pierwszych rzeczy, które zrobiliśmy, było spięcie ewaluacji modeli: prowadzimy mnóstwo benchmarków, więc po prostu to podłączyliśmy i ustawiliśmy środowisko testowe, co pozwoliło skalować się na więcej GPU. Sporo osób korzysta z tego wewnętrznie i działa znakomicie.
David Ondrej: Tak, to ma dla mnie całkowity sens — i podchodzę do tego czysto praktycznie. Jeśli odpalasz lokalnie dwóch agentów, jest OK. Mówię o aktywnym rozwojowi na poziomie software’u, nie o budowaniu aplikacji wyżej. Ale jeśli pomyśleć od pierwszych zasad — a chyba wszyscy wierzymy, że będziemy uruchamiać coraz więcej agentów — to istnieje liczba, której żaden domowy komputer nie udźwignie. Nawet najnowszy MacBook ze 128 GB RAM nie porwadzi tysięcy czy dziesiątków tysięcy agentów. Greg Brockman niedawno tweetował, że agenci będą potrzebować więcej — każdy z nich żre coraz więcej zasobów. Kolejne generacje modeli — czy to wielkie testy na bazach danych, obsługa komputera, czy po prostu dużo większe obliczenia — będą wymagać zasobów, których domowy stacjonarny pecet czy laptop nie pomieści. Z tej logiki wynika, że nawet w pracy na żywo będziesz mieć swojego głównego agenta, z którym rozmawiasz — ale jeśli wierzysz w przyszłość, w której produktywnie używamy setek czy tysięcy agentów przy żywym kodowaniu, to musi się to dziać w chmurze. Dla mnie największe olśnienie przyszło, gdy interfejs graficzny Cursora zaczął mi się wywalać przy około trzydziestu równoległych agentach, każdy na innej gałęzi roboczej. Wtedy powiedziałem sobie: „dobra, to musi się przenieść do chmury” — bo nawet na najlepszym MacBooku system się sypał. Przeszedłem na lżejszą konfigurację w terminalu — jest lepiej, bo znacznie mniej waży — ale wiem, że i ona wkrótce zwolni. W końcu będę musiał trzymać wiele maszyn wirtualnych albo sięgnąć po jeden z zarządzanych produktów, typu Cognition czy Cursor, które oferują agentów chmurowych i mocno je promują. Tak się zastanawiam — jakie jest Twoje obecne ustawienie AI do programowania i jak widzisz jego rozwój w najbliższych miesiącach?
Dmytro: Jak mówiłem — to już rzeczywistość. Dla mnie osobiście i dla dużej części zespołu, jeśli pracujesz ze specjalistycznym sprzętem, to w pewnym sensie od zawsze byliśmy w tym świecie. Nie odpala się dwudziestu agentów lokalnie — odpalało się już wcześniej dwadzieścia różnych kontenerów Dockera na GPU, a zmiana polegała właściwie tylko na przejściu od okna terminala połączonego do rozłączonego. To przejście było więc z jednej strony łatwe i w większości już za nami, a przy okazji odblokowuje mnóstwo innych rzeczy. Choćby taką prostą: na tym etapie nie powinieneś już nigdy sam naprawiać swojego CI. Owszem, bywa, że przeglądasz jakiś kod — bo jest bardziej złożony, agenci nie dają rady, a nie da się tego odseparować — ale proste rzeczy, jak CI, sypać się nie powinny. Jeśli coś padnie w agencie od pull requestów, po prostu wskakujesz do chmury i idziesz to naprawić. Mamy to u siebie wewnętrznie i okazało się bardzo przydatne, choć podobne produkty oferuje dziś sporo startupów. Ta migracja trwa, a dla wielu firm jest bliska końca. I ma sens: im bardziej jesteś odcięty od lokalnej maszyny, tym mniejsza wartość uruchamiania czegokolwiek lokalnie, a tym większa — poziomego skalowania w chmurze. I znowu: największą dźwignię daje zadbane środowisko, CI i wszystko, co podlega ewaluacji. Wracając do Twojego pytania o wzorzec dla startupów — odpowiedziałem wtedy: ewaluacje i wiedza, jak wygląda „dobrze”. W programowaniu jest tak samo. Kod staniał, ale zielony CI, dobre testy i możliwość automatycznego powiedzenia, czy baza kodu zmierza we właściwym kierunku, są bezcenne. Bo wyślesz tam setki agentów — i jeśli nie masz właściwej infrastruktury, możliwości skalowania, odpalania właściwego środowiska, testowania zmian i budowania tej całej bazy, to baza kodu i proces rozwoju po prostu się zawalą. Nie różni się to specjalnie od skalowania klasycznego wytwarzania software’u: w dużych firmach najbardziej doświadczeni i najskuteczniejsi inżynierowie często zajęci są CI — dbają o testy i przewodniki stylu. Teraz, gdy wszyscy dostali agentów kodujących, wszyscy przechodzą z inżynierów „przy klawiaturze” w tech leadów prowadzących większy zespół. Stąd ten sam wzorzec myślowy: pisanie kodu nie jest najbardziej wpływową aktywnością — nią jest ustawienie właściwego środowiska, właściwych testów i właściwych wytycznych. Sprawienie, by Twoi „pracownicy-AI”, których formalnie prowadzisz, szli we właściwym kierunku — to jest najwyższa dźwignia. I myślę, że model mentalny „każdy z nas został liderem stu agentów AI” jest użyteczny do wybierania procesów i obszarów, w które warto inwestować.
Ile dziś zajmuje samo pisanie kodu
David Ondrej: Na taką skalę — jaki procent dnia spędzasz jeszcze na budowaniu czegokolwiek? I jakich narzędzi używasz przy programowaniu?
Dmytro: W firmie używamy wszystkiego: Cursora, Codexa, Codeium, Claude’a Opusa i innych. Do tego agenci, których zbudowaliśmy sami, na przykład do ewaluacji i optymalizacji wydajności. Ale jeśli chodzi o samo pisanie kodu — ręczne klepanie — jest już śladowe albo wręcz żadne. Przegląd kodu — wysokopoziomowy albo z agentami, gdzie człowiek sprawdza pull request napisany przez agenta w imieniu autora — wciąż zdarza się dużo i moim zdaniem pozostaje bardzo ważny, zależnie od typu produktu. Jeśli masz coś zamkniętego i jasno określonego, dającego się opisać jak dokument wymagań, to dobry przykład produktu, przy którym nie musisz już patrzeć na kod. U nas byłyby to różne narzędzia wewnętrzne: „chcę taką funkcję, nie obchodzi mnie, jak działa; łatwo sprawdzić, co ma robić — działa”. Tam, gdzie agenci na tym etapie zawodzą, kod trzeba jeszcze oglądać. To te bardziej złożone, ściśle powiązane systemy. Jak pracuję nad silnikiem inferencji dla LLM-ów i puszczę agentów na luz, narobią mnóstwo złożoności. Napiszą dużo kodu, poskładają go byle jak — może akurat zadziała — ale własna złożoność bazy wzrośnie. Więc wciąż widzę wielką wartość w ludzkim wkładzie, który tę złożoność tłumi, i w wysokopoziomowym przeglądzie wszystkich pull requestów. To dziś większa część pracy rozwojowej. Chcesz zaimplementować funkcję w złożonym systemie tak, żeby można jej było realnie ufać? Wypróbujesz różne podejścia, może odpalisz kilku agentów i zobaczysz, co jest najwydajniejsze, najspójniejsze i najmniej złożone — i pewnie powtórzysz to kilka razy. Tak mniej więcej wygląda codzienna praca naszego zespołu przy systemach, silnikach inferencji czy infrastrukturze treningu. Gdy modele będą inteligentniejsze, da się zautomatyzować więcej — ale jeszcze nie doszliśmy do tego momentu.
Gdzie pójść dalej
David Ondrej: Chcę tu zakończyć. Dziękuję za Twój czas, naprawdę doceniam. Gdzie ludzie powinni się wybrać?
Dmytro: Na fireworks.ai. Jeśli jesteś deweloperem i chcesz spróbować modeli otwartych, sięgnij po nasze bezserwerowe API — jest w pełni kompatybilne z interfejsami OpenAI, więc podłączysz je bezpośrednio do każdego ulubionego narzędzia. Możesz testować wszystkie najnowsze i najgorętsze modele, zwykle dostępne w dniu premiery — Gemini, GLM, DeepSeek i kolejne. Mamy też nowy produkt, Fireworks Nexus, oparty na pomyśle inteligentnego rozdzielania zadań między modele: podmieniasz punkt końcowy w swoim systemie — chmurowym albo nie — a zadania merytoryczne trafiają do modeli otwartowagowych, a pozostałe przypadki do modeli czołowych. To kolejna rzecz do wypróbowania. No i jeśli budujesz firmę — koniecznie przetestuj otwarte wagi, które zrobiły ogromny postęp, jak rozmawialiśmy. Może wystarczą Ci od razu; a gdy produkt osiągnie pewną skalę i zbierzesz ewaluacje plus dane, spróbuj dostrajania. Mamy wielopoziomową platformę treningową: możesz zacząć od wysokopoziomowego „oto moja funkcja nagrody, ten przycisk to start” i my bierzemy na siebie resztę, ale jeśli chcesz eksperymentować i wdrożyć swój ulubiony algorytm RL — i na to pozwalamy. Masz też niższy poziom kontroli, z niskim opóźnieniem, gdzie sam definiujesz funkcję straty, dane i wszystkie szczegóły, jeśli chcesz robić bardziej badawczą robotę.
David Ondrej: Świetnie. Linki do wszystkich produktów i Twoich kont w mediach społecznościowych włożę do opisu poniżej. Jeszcze raz dziękuję, Dmytro, za Twój czas — i miłego dnia!
Dmytro: Dzięki wielkie za zaproszenie. Wzajemnie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zaczynaj od gotowego modelu, dostrajaj dopiero przy realnym ruchu
Na czym polega: Fine-tuning jest trudniejszy niż promptowanie i nie jest punktem startowym prototypu. O przejściu na trening decyduje nie rozmiar firmy, lecz posiadanie ewaluacji i danych z użycia.
Jak stosować: Prototypuj na gotowych modelach. Równolegle od pierwszego dnia buduj ewaluacje — metryki i zbiory offline symulujące realne zachowania użytkowników. Dopiero gdy masz pomiar i dane, przechodź do dostrajania.
Na co uważać: Ewaluacje zrobione „na szybko” mierzą co innego niż produkt. Bez wiarygodnego pomiaru fine-tuning poprawia liczby na benchmarku, a nie doświadczenie użytkownika.
2.Setka świetnych przykładów bije dziesięć tysięcy przeciętnych
Na czym polega: W erze dostrajania i RL jakość danych przeważa nad ilością. Modele mają już inteligencję bazową — uczysz je tylko wąskiej umiejętności, a to wymaga małych, starannie przygotowanych zbiorów.
Jak stosować: Buduj zbiory z pełnych przebiegów zadań (rolloutów), realnych dialogów i typowych przypadków z produktu. Iteruj po kilkadziesiąt–kilkaset przykładów i mierz efekt ewaluacjami po każdej iteracji.
Na co uważać: W małym zbiorze jeden źle oznaczony przykład waży nieproporcjonalnie dużo; błędne dane utrwalają błędy modelu zamiast je usuwać.
3.Fine-tuning to przeskok z ok. 90 na ok. 95% docelowego doświadczenia
Na czym polega: Promptami i integracją wyciągniesz 80–90% potencjału; reszta siedzi w wagach i wymaga treningu na własnych wzorcach użycia. Efekt uboczny bywa spektakularny: nawet dziesięciokrotna obniżka kosztów.
Jak stosować: Zbieraj dane o realnym zachowaniu użytkowników, zamień je na zbiór treningowy i porównuj dostrojony model z dotychczasowym na tych samych ewaluacjach.
Na co uważać: Ustal kolejność motywacji — gonisz jakość (start od czołowych modeli) czy koszt (start od otwartych wag, np. GLM, plus dostrajanie). Od tego zależy wybór modelu bazowego.
4.Fosę budują dane i znajomość branży, nie kod
Na czym polega: Wykonywanie software’u staniało, więc przewaga przesunęła się ku unikalnym danym, wnioskom z użycia i głębokiemu rozumieniu wertykału.
Jak stosować: Wybierz dziedzinę, którą znasz od podszewki (produkcja, transport, prawo), i zaprojektuj pętlę zbierania danych od pierwszego użytkownika — prototyp ma ją wprawiać w ruch, a nie być celem samym w sobie.
Na co uważać: „Tanie wykonanie” nie znaczy „tani dobry produkt” — zmysł produktowy i szybkie iteracje wciąż decydują. Nakładka bez pętli danych fosy nie buduje.
5.Pretrening od zera to pułapka — startuj z otwartych wag
Na czym polega: Pełny pretrening kompresuje ogólną ludzką wiedzę — jest skrajnie drogi i korzysta z efektu skali. Lekcja Bloomberga GPT: model ogólny szybko wyprzedza model wertykalny trenowany od zera.
Jak stosować: Specjalizuj przez post-trening (a w razie potrzeby mid-training) na bazie otwartych wag — koszt wiedzy ogólnej ponosi ktoś inny, Ty dopłacasz tylko swoją domenę.
Na co uważać: Decyzja o własnym pretreningu to de facto decyzja o zostaniu nowym laboratorium — realna dla garstki, okupiona utratą fokusu.
6.Otwarte wagi to polisa na zmienność dostawców
Na czym polega: Zamknięte API bywa modyfikowane po cichu, a polityki odmów i przetwarzania danych zależą od dostawcy. Z otwartymi wagami możesz pobrać model i uruchomić go gdziekolwiek.
Jak stosować: Testuj modele na stałych, zamrożonych ewaluacjach, by wykrywać ciche zmiany jakości. Trzymaj możliwość przeniesienia inferencji na inny dostawcę albo własny sprzęt.
Na co uważać: Realna kontrola wymaga faktycznej zdolności do self-hostingu — utrzymanie inferencji to osobna kompetencja i koszt, który trzeba wliczyć.
7.Baza wiedzy dla agentów to absolutne minimum
Na czym polega: Największy wewnętrzny zysk w Fireworks dają proste wdrożenia: dokumentacja dostępna dla agentów, nagrywanie i streszczanie spotkań, agenci na Slacku. Firma bez tego już odstaje.
Jak stosować: Przeładuj wiedzę o procesach do plików w repozytorium, dodaj agenta, który umie ją aktualizować we właściwych miejscach, i podłącz boty do komunikatora z dostępem dla całej firmy.
Na co uważać: Agent bez narzędzi i bez monitoringu (co działa, a co nie) stanie się gadającą zabawką. Wyznacz kogoś odpowiedzialnego za infrastrukturę agentów.
8.To samo wdrożenie, dwa cele: szybkość albo koszt
Na czym polega: Ten sam model serwuje się inaczej pod niskie opóźnienia (małe batche, dekodowanie spekulatywne, krótki czas do pierwszego tokena) i pod tanią przepustowość (maksymalne obciążenie, wielkie batche).
Jak stosować: Rozdzielaj wdrożenia per zastosowanie: interfejs z człowiekiem w pętli — optymalizacja czasu do pierwszego tokena; agenci w tle — optymalizacja kosztu tokena i przepustowości.
Na co uważać: Jedna konfiguracja „na wszystko” przepłaca po jednej ze stron. Zanim zaczniesz optymalizować, ustal, co faktycznie mierzysz: opóźnienie, koszt czy przepustowość.
9.Agentów programistycznych przenoś do chmury — lokalnie jest limit
Na czym polega: Laptop udźwignie pojedynczych agentów, ale przy około trzydziestu równoległych (na różnych gałęziach roboczych) interfejs graficzny Cursora się wykłada, a kolejne generacje modeli będą jeszcze głodniejsze zasobów.
Jak stosować: Trzymaj środowisko deweloperskie w chmurze (kontenery, dostęp przez VS Code po SSH lub terminal) i odpalaj agentów w tych samych kontenerach. Przy większej skali sięgaj po zarządzane produkty z agentami chmurowymi.
Na co uważać: Tryb terminala jest lżejszy od interfejsu graficznego, ale tylko odsuwa limit w czasie — zaplanuj z góry maszyny wirtualne i monitoring kosztów chmurowych.
10.Myśl jak tech lead stu agentów: środowisko, testy, CI
Na czym polega: Gdy kod piszą agenci, największą dźwignią staje się zielony CI, testy i wytyczne — automatyczny sygnał, że baza kodu zmierza we właściwą stronę. Bez niego setki agentów zawalą projekt.
Jak stosować: Zanim puścisz agentów samodzielnie, zbuduj pipeline: testy, ewaluacje, przewonik stylu, izolowane środowiska. Ludzi angażuj w wysokopoziomowy przegląd pull requestów i redukcję złożoności.
Na co uważać: Przy ściśle powiązanych systemach (np. silnikach inferencji) agenci potrafią „załatwić” pojedynczy przypadek, podnosząc przy tym złożoność całej bazy — tam ludzki przegląd pozostaje bezcenny.