Kog stawia na głębszą optymalizację GPU, aby przyspieszyć wnioskowanie AI

Kog trafił do Google News z bezpośrednim wyzwaniem rzuconym narracji o wyspecjalizowanych układach: agentowe AI nie musi koniecznie rezygnować ze standardowych GPU w centrach danych. Paryski startup twierdzi, że głębsza koordynacja między modelami, oprogramowaniem do wnioskowania i sprzętem może zapewnić responsywność wymaganą przez złożone przepływy pracy AI.

To twierdzenie uderza w rosnące założenie dotyczące infrastruktury AI. Agenci generują wiele wywołań modelu podczas planowania, korzystania z narzędzi, oceny wyników i korygowania błędów. Taki schemat może sprawić, że wolne wnioskowanie będzie zarówno kosztowne, jak i frustrujące, wzmacniając argumenty za procesorami zaprojektowanymi specjalnie do obsługi modeli AI.

Kog wybiera przeciwną drogę. Zamiast zastępować GPU, chce usunąć warstwy narzutu programowego, które uniemożliwiają tym GPU osiągnięcie pełni możliwości. Ta rywalizacja między wyspecjalizowanym sprzętem a głębszą optymalizacją GPU staje się obecnie jednym z kluczowych pytań infrastrukturalnych dla agentowego AI.

Dlaczego Kog idzie głębiej w wnioskowanie GPU

Kog wykracza poza odizolowane usprawnienia środowiska wykonawczego i traktuje model, silnik wnioskowania oraz GPU jako jeden problem optymalizacyjny.

Stanowisko firmy zyskało szerszą uwagę po raporcie z 14 sierpnia, który analizował jej próbę wydobycia większej wydajności wnioskowania ze znanego sprzętu. Artykuł o wnioskowaniu GPU przedstawił pracę Kog wokół kontrariańskiej idei. GPU nie muszą być z natury niedopasowane do zastosowań agentowych, nawet gdy takie zastosowania wymagają szybkich, wielokrotnych odpowiedzi modelu.

To rozróżnienie ma znaczenie, ponieważ wnioskowanie nie jest jednorodnym obciążeniem. Konsumencki chatbot może tolerować krótką przerwę przed wygenerowaniem długiej odpowiedzi. Agent programistyczny lub interfejs głosowy często musi jednak podjąć kilka kolejnych decyzji, zanim wykona jedno widoczne zadanie.

Każde opóźnienie może narastać w całym tym łańcuchu. Jeśli agent czeka na jedną odpowiedź modelu przed uruchomieniem kolejnego działania, poprawa opóźnienia pojedynczej odpowiedzi może skrócić cały przepływ pracy.

Odpowiedź Kog zaczyna się od silnika wnioskowania, czyli oprogramowania odpowiedzialnego za uruchamianie wytrenowanego modelu, gdy użytkownik lub aplikacja wysyła żądanie. Większość silników produkcyjnych dzieli wykonanie modelu na wiele operacji GPU nazywanych kernelami. Kernel to niskopoziomowy program wykonujący określone obliczenie na procesorze.

Uruchamianie i koordynowanie wielu kerneli wprowadza narzut. Dane mogą wymagać przenoszenia między lokalizacjami pamięci, procesory muszą się synchronizować, a system hosta wielokrotnie harmonogramuje pracę. Każde opóźnienie z osobna wydaje się niewielkie, ale skumulowany koszt staje się widoczny podczas generowania wrażliwego na opóźnienia.

Kog twierdzi, że ograniczył ten narzut, umieszczając sekwencję dekodowania w jednym trwałym kernelu. Dekodowanie to etap, na którym model językowy generuje tokeny wyjściowe jeden po drugim. Trwały kernel pozostaje aktywny na GPU zamiast zwracać kontrolę po każdej mniejszej operacji.

W majowym podglądzie technicznym Kog podał, że osiągnął ponad 3 000 tokenów wyjściowych na sekundę dla jednego żądania przy użyciu ośmiu GPU AMD MI300X. Podał również 2 100 tokenów na sekundę na ośmiu GPU Nvidia H200. Według podglądu wnioskowania Kog testy wykorzystywały model o 2 miliardach parametrów w precyzji FP16, bez dekodowania spekulatywnego.

Dekodowanie spekulatywne wykorzystuje mniejszy model do proponowania tokenów, które większy model może weryfikować grupowo. Może zwiększać szybkość generowania, ale wprowadza też dodatkową zmienną do porównań. Wykluczając tę technikę, Kog przypisuje zgłoszony wynik przede wszystkim projektowi modelu i środowiska wykonawczego.

Startup opracował również Laneformer 2B, model programistyczny o 2,3 miliarda parametrów zaprojektowany wokół dekodowania o niskim opóźnieniu. To centralna część strategii, a nie projekt poboczny. Kog optymalizuje architekturę modelu pod kątem wzorca wykonania, z którym jego silnik radzi sobie najlepiej.

Projekt obejmuje opóźniony paralelizm tensorowy, który ma na celu nakładanie komunikacji na obliczenia i przenoszenie wag. Paralelizm tensorowy dzieli obliczenia modelu między kilka GPU. Metoda zapewnia większą łączną moc obliczeniową, ale komunikacja między tymi GPU może stać się wąskim gardłem.

Podejście Kog próbuje ukryć tę komunikację za inną użyteczną pracą. Firma w istocie argumentuje, że nieefektywność GPU jest częściowo problemem harmonogramowania. Lepsze sekwencjonowanie może utrzymywać procesory w aktywności, jednocześnie ograniczając przerwy między zależnymi operacjami.

Wyniki te pozostają benchmarkami zgłaszanymi przez firmę. Nie potwierdzają równoważnej wydajności w przypadku większych modeli, dłuższych promptów, wielu równoczesnych użytkowników ani ruchu produkcyjnego. Wyjaśniają jednak, dlaczego startup idzie głębiej, zamiast po prostu dodawać kolejną warstwę obsługującą istniejące modele.

Ta praca tworzy również centralne napięcie artykułu. Jeśli Kog zdoła rozszerzyć te korzyści poza swój niewielki, współprojektowany model, wyspecjalizowany sprzęt do wnioskowania traci część swojego najsilniejszego argumentu. Jeśli korzyści silnie zależą od wąskiej konfiguracji, argument za takim sprzętem pozostaje aktualny.

Google News zwraca uwagę na debatę GPU kontra niestandardowe układy

Historia Kog ma znaczenie, ponieważ podważa przekonanie, że agenci czasu rzeczywistego wymagają nowej architektury procesora.

Firmy tworzące wyspecjalizowane układy do wnioskowania wychodzą od rozsądnej obserwacji. GPU zbudowano jako uniwersalne procesory równoległe, podczas gdy dekodowanie modeli językowych ma przewidywalne wzorce matematyczne i dostępu do pamięci. Układ zaprojektowany do konkretnego celu może usunąć funkcje sprzętowe, których dane obciążenie nie potrzebuje.

Groq, Cerebras, SambaNova i Etched realizowały własne warianty tej strategii. Ich architektury się różnią, ale wspólną obietnicą jest ściślejsza kontrola nad opóźnieniem wnioskowania, przepustowością, ruchem pamięci lub zużyciem energii.

Groq stał się znany z procesorów, które przewidywalnie harmonogramują operacje. Cerebras buduje systemy w skali wafla, umieszczające niezwykle dużą moc obliczeniową na jednym kawałku krzemu. Etched koncentruje się na układach zbudowanych specjalnie dla modeli transformerowych.

Te projekty atakują problem obciążenia na poziomie sprzętowym. Kog chce uzyskać podobne korzyści dzięki oprogramowaniu i architekturze modelu, pozostając przy GPU już dostępnych w centrach danych.

To sprawia, że obecność Kog w Google News jest bardziej znacząca niż typowe ogłoszenie benchmarku. Firma testuje, czy oprogramowanie może zmniejszyć różnicę między sprzętem ogólnego przeznaczenia a niestandardowym krzemem, zanim klienci zdecydują się na kolejny stos infrastruktury.

Zmiana sprzętu wpływa na więcej niż szybkość benchmarków. Operatorzy muszą uwzględnić dostępność, narzędzia wdrożeniowe, monitorowanie, kompatybilność modeli, kompetencje inżynieryjne i integrację z istniejącymi klastrami. Przewaga Nvidia obejmuje CUDA, platformę programową do programowania GPU, a nie tylko sam krzem.

AMD rozwija swój stos oprogramowania ROCm jako alternatywę. Zgłaszana przez Kog wydajność na sprzęcie AMD MI300X sugeruje, że inżynieria wnioskowania na niższym poziomie może również wzmocnić argumenty za GPU innymi niż Nvidia. Taki wynik miałby znaczenie dla dostawców chmurowych i przedsiębiorstw poszukujących większej elastyczności w zakresie dostawców.

Presja spada więc na kilka grup. Dostawcy wyspecjalizowanych układów muszą pokazać, że ich przewaga wydajnościowa przetrwa agresywną optymalizację GPU. Nvidia musi nadal ulepszać swoje oprogramowanie do wnioskowania, jednocześnie broniąc szerokiej kompatybilności, która czyni jej platformę atrakcyjną.

AMD stoi przed innym wyzwaniem. Musi przekształcić konkurencyjny sprzęt i pojedyncze demonstracje techniczne w niezawodne środowisko produkcyjne. Kog może wesprzeć ten argument, jeśli jego silnik będzie działał konsekwentnie między modelami i w rzeczywistych obciążeniach.

Firmy tworzące oprogramowanie do wnioskowania również znajdują się pod presją. Powszechnie używane silniki już stosują techniki takie jak ciągłe batchowanie, łączenie kerneli, kwantyzacja, cache’owanie prefiksów i dekodowanie spekulatywne. Kog musi wykazać, że jego głębsza architektura zapewnia korzyści, których te ugruntowane systemy nie mogą szybko odtworzyć.

Ciągłe batchowanie dynamicznie łączy żądania, aby GPU przetwarzał więcej pracy jednocześnie. Może to poprawić przepustowość, która mierzy całkowitą pracę ukończoną w czasie. Przepustowość nie gwarantuje jednak najniższego opóźnienia dla pojedynczego żądania.

Ta różnica jest szczególnie istotna dla agentów. Serwer o wysokiej przepustowości może wydajnie przetwarzać wiele niezależnych żądań, podczas gdy pojedynczy wieloetapowy agent nadal czeka na długą sekwencję. Kog koncentruje się na doświadczeniu tego indywidualnego przepływu pracy.

Strategia odzwierciedla szersze przejście od ekonomiki trenowania do ekonomiki wnioskowania. Trenowanie modelu jest dużym, ale ograniczonym projektem. Jego obsługa generuje bieżące koszty rosnące wraz z liczbą żądań, długością odpowiedzi i liczbą wywołań modelu ukrytych w każdym zadaniu.

Agenci wzmacniają te koszty, ponieważ jedna instrukcja użytkownika może uruchomić planowanie, wyszukiwanie, dobór narzędzi, wykonanie kodu, weryfikację i rewizję. Każdy etap może obejmować kolejne wywołanie wnioskowania. Szybsze generowanie może więc zmienić zarówno doświadczenie użytkownika, jak i model operacyjny.

Nie oznacza to, że każdy agent jest ograniczony przez GPU. Wywołania narzędzi, żądania sieciowe, bazy danych i zewnętrzne API mogą dominować nad całkowitym czasem ukończenia. Niektóre przepływy pracy spędzają więcej czasu na oczekiwaniu na systemy programowe niż na generowaniu tokenów.

Teza Kog jest najsilniejsza, gdy dekodowanie modelu znajduje się na ścieżce krytycznej. Zastosowania związane z programowaniem, głosem, symulacją i interaktywnym rozumowaniem mogą pasować do tego opisu. Zadania badawcze działające w tle asynchronicznie mogą bardziej cenić całkowity koszt i przepustowość niż natychmiastowe dostarczanie tokenów.

Wyzwanie dla wyspecjalizowanych układów jest równie zależne od obciążenia. Procesor zoptymalizowany pod wnioskowanie transformerowe może osiągać znakomite wyniki, gdy modele odpowiadają jego założeniom. Uniwersalne GPU zachowują przewagę, gdy klienci muszą uruchamiać różnorodne architektury, zadania treningowe, obciążenia multimodalne lub szybko zmieniający się kod badawczy.

Dlatego główna rywalizacja nie polega po prostu na starciu Kog z jednym producentem układów. To głębsza optymalizacja GPU kontra specjalizacja sprzętowa. Obie ścieżki dążą do szybszego i bardziej ekonomicznego wnioskowania, ale umieszczają złożoność w różnych częściach stosu.

Model i środowisko wykonawcze stają się jednym systemem

Centralne odwrócenie perspektywy Kog polega na tym, że GPU ogólnego przeznaczenia może zachowywać się bardziej jak wyspecjalizowany sprzęt do wnioskowania, gdy oprogramowanie przestaje traktować go jako ogólny cel.

Konwencjonalny rozwój modeli często oddziela badania od wdrożenia. Badacze optymalizują architekturę i trening pod kątem jakości modelu. Zespoły infrastrukturalne później dostosowują gotowy model do dostępnego środowiska obsługowego.

Taki podział pozwala zespołom działać niezależnie, ale może pozostawiać niewykorzystaną wydajność. Model może zawierać operacje, których koordynowanie między GPU jest kosztowne. Silnik obsługujący musi zachować te operacje, nawet gdy kolidują one z jego najszybszą ścieżką wykonania.

Kog stosuje współprojektowanie, czyli budowanie modelu i środowiska wykonawczego wokół wzajemnych ograniczeń. Laneformer daje firmie kontrolę nad decyzjami architektonicznymi wpływającymi na dostęp do pamięci, synchronizację i komunikację między GPU.

Firmowy model Laneformer stanowi konkretną demonstrację tej filozofii. Kog udostępnił wagi modelu i kod, umożliwiając zewnętrznym deweloperom analizę architektury oraz przetestowanie części tego twierdzenia.

Konstrukcja z trwałym kernelem działa według tej samej logiki na niższym poziomie. Tradycyjne wykonywanie może uruchamiać osobne kernelle dla normalizacji, uwagi, operacji macierzowych i innych etapów. Fuzja łączy operacje, dzięki czemu dane pozostają bliżej procesora i unika się wielokrotnego planowania zadań.

Kog rozwija tę ideę dalej, utrzymując proces dekodowania w jednym programie rezydującym na GPU. Celem jest wyeliminowanie przerw między operacjami i bardziej bezpośrednie zarządzanie sekwencją.

Przypomina to przewagę kojarzoną ze specjalizowanymi procesorami. Sprzęt projektowany do konkretnych celów często zapewnia przewidywalność dzięki ograniczeniu uniwersalności i kontrolowaniu przepływu danych. Kog próbuje narzucić porównywalną dyscyplinę za pomocą wąskiej, głęboko zoptymalizowanej ścieżki programowej.

Raportowany wynik 3 000 tokenów jest uderzający, ponieważ dotyczy generowania pojedynczego żądania. Wiele benchmarków inferencji kładzie nacisk na łączną przepustowość w dużej partii. Ten wskaźnik ma znaczenie dla dostawców, ale może ukrywać, jak długo czeka pojedyncze interaktywne żądanie.

Partia o rozmiarze jeden stwarza trudniejszy problem wykorzystania zasobów. System nie może polegać na wielu równoczesnych użytkownikach, aby utrzymać zajętość każdej jednostki GPU. Model i środowisko uruchomieniowe Kog zaprojektowano tak, aby ograniczać okresy bezczynności, które w tych warunkach stają się bardziej widoczne.

Sama szybkość nie przesądza jednak o użytecznej wydajności agentów. Możliwości modelu pozostają kluczowe. Mały model, który szybko generuje tekst, może mimo to potrzebować więcej czasu łącznie, jeśli popełnia błędy, powtarza pracę lub wymaga sprawdzenia wyniku przez mocniejszy model.

Tworzy to istotne rozróżnienie między opóźnieniem tokenów a opóźnieniem zadania. Opóźnienie tokenów mierzy, jak szybko pojawia się tekst. Opóźnienie zadania mierzy, ile czasu system potrzebuje, by zrealizować rzeczywisty cel użytkownika.

Agent, który generuje 3 000 tokenów na sekundę, lecz wybiera niewłaściwe narzędzie, nie dostarczył szybszego rozwiązania. Po prostu szybciej wygenerował niepoprawny krok pośredni. Głębszy zakład Kog musi ostatecznie wykazać korzyści na poziomie zadań.

Według materiałów technicznych startup planuje obsługiwać większe zewnętrzne modele mixture-of-experts. Model mixture-of-experts aktywuje wybrane podzbiory swoich parametrów dla każdego tokena. Może to ograniczać ilość obliczeń, ale kierowanie ruchem do tych ekspertów i ich rozdzielanie tworzy nowe wyzwania komunikacyjne.

Obsługa szeroko używanych modeli zewnętrznych uczyniłaby twierdzenia Kog bardziej istotnymi dla nabywców. Firmy rzadko wybierają infrastrukturę wokół jednego małego modelu, chyba że ten model wyjątkowo dobrze wykonuje wąskie zadanie.

Kompatybilność decyduje również o tym, czy klienci mogą wdrożyć silnik bez przeprojektowywania aplikacji. Interfejsy zgodne z OpenAI mogą uprościć integrację API, ale obsługa modeli, obserwowalność, planowanie i odzyskiwanie po awariach nadal kształtują gotowość produkcyjną.

To właśnie tutaj ugruntowane oprogramowanie GPU pozostaje groźnym konkurentem. Nvidia rozwija TensorRT-LLM i inne biblioteki optymalizujące inferencję dla własnego sprzętu. Projekty open source, takie jak vLLM i SGLang, korzystają z dużych społeczności, szerokiego wsparcia modeli i informacji zwrotnych z wdrożeń produkcyjnych.

Nvidia opisuje TensorRT jako wysokowydajny system inferencyjny zaprojektowany do optymalizacji wykonywania na jej procesorach. Jej oprogramowanie do inferencji stosuje optymalizację grafu, obniżoną precyzję i dobór kerneli w obsługiwanych modelach.

Kog konkuruje zatem z ruchomym celem. Jeśli jego techniki są ogólne i możliwe do odtworzenia, większe platformy mogą przyjąć podobne rozwiązania. Jeśli pozostaną zastrzeżone lub ściśle związane z Laneformer, Kog zyska wyróżnik, ale stanie przed mniejszym rynkiem kompatybilnym.

Najbardziej prawdopodobna szansa firmy leży pomiędzy tymi skrajnościami. Kog może zapakować trudną pracę niskopoziomową w silnik, którego dostawcy chmury lub zespoły AI nie chcą odtwarzać. Wartość wynikałaby z trwałej jakości wykonywania na kolejnych generacjach sprzętu, a nie z jednego szczytowego wyniku benchmarku.

Połączenie modelu i środowiska uruchomieniowego może również przemawiać do twórców aplikacji o rygorystycznych wymaganiach dotyczących responsywności. Systemy głosowe potrzebują niskich opóźnień, by utrzymać rytm rozmowy. Agenci programistyczni muszą wielokrotnie przechodzić przez generowanie i wykonywanie kodu. Interaktywne narzędzia kreatywne cierpią, gdy każde wywołanie modelu przerywa użytkownikowi pracę.

Agent intensywnie korzystający z wiedzy wprowadza kolejny wymiar. Może gromadzić dokumenty, łączyć kontekst i wykonywać kilka przebiegów inferencji przed przedstawieniem odpowiedzi. Zespoły budujące takie systemy powinny analizować cały przepływ pracy AI, ponieważ szybkość generowania rozwiązuje tylko jedną część łańcucha.

Argument Kog pozostaje użyteczny nawet wtedy, gdy inferencja nie jest jedynym wąskim gardłem. Zachęca zespoły do mierzenia każdego etapu zamiast uznawania GPU za nieodpowiednie na podstawie niezoptymalizowanego stosu.

Głębsza lekcja nie polega na tym, że oprogramowanie zawsze pokonuje sprzęt niestandardowy. Chodzi o to, że porównania sprzętu zależą od jakości oprogramowania działającego nad nim. Źle zaplanowany GPU nie jest dowodem na ostateczny limit GPU.

Czego benchmark Kog nie rozstrzyga

Kog przedstawił wiarygodny kierunek techniczny, ale jego publiczne wyniki nie ustanawiają jeszcze przewagi produkcyjnej w typowych agentowych obciążeniach roboczych.

Pierwszym ograniczeniem jest skala modelu. Laneformer ma 2,3 miliarda parametrów, podczas gdy wiele wymagających aplikacji agentowych wykorzystuje znacznie większe modele. Większe systemy wywierają większą presję na pojemność pamięci, komunikację i zarządzanie pamięcią podręczną.

Technika, która działa dobrze, gdy jeden węzeł mieści mały model, może zachowywać się inaczej, gdy wagi i dane pośrednie obejmują więcej urządzeń. Koszty komunikacji rosną, a silnik ma mniej okazji, by je ukryć.

Kog zapowiedział, że nadchodzi wsparcie dla dużych zewnętrznych modeli mixture-of-experts. Dopóki nie pojawią się porównywalne wyniki, najsilniejsza interpretacja pozostaje ograniczona. Firma pokazała, co jej współprojektowany stos może zrobić w konkretnym teście, a nie to, co potrafi każdy model produkcyjny.

Drugim ograniczeniem jest charakter obciążenia. Kog kładzie nacisk na jedno żądanie i niskie opóźnienie. Komercyjne usługi inferencyjne muszą również obsługiwać zmienne długości promptów, wielu użytkowników, skoki ruchu, długie konteksty, anulowania i zmieniające się limity wyjścia.

Silnik zoptymalizowany pod partię o rozmiarze jeden może napotkać kompromisy przy większej współbieżności. Istotne pytanie nabywcy nie brzmi, czy jedno żądanie może działać ekstremalnie szybko. Chodzi o to, czy system potrafi zachować użyteczne opóźnienie przy ekonomicznym wykorzystaniu klastra.

Trzecim ograniczeniem jest porównywalność benchmarków. Liczba tokenów na sekundę zmienia się wraz z architekturą modelu, słownictwem, precyzją, warunkami wyjściowymi, liczbą urządzeń i metodą pomiaru. Porównywanie dwóch raportowanych liczb bez dopasowania tych zmiennych może stworzyć fałszywe poczucie pewności.

Mały model na ośmiu GPU nie jest bezpośrednio porównywalny z większym modelem na jednym niestandardowym procesorze. Nie jest też bezpośrednio porównywalny z serwerem o wysokiej przepustowości obsługującym wiele żądań. Każda konfiguracja odpowiada na inne pytanie operacyjne.

Czwartym ograniczeniem jest jakość wyników. Współprojektowanie może zwiększać efektywność, ale architektura musi nadal spełniać wymagania aplikacji dotyczące dokładności. Modele programistyczne potrzebują niezawodnego generowania kodu i rozumowania, a nie tylko szybkiej produkcji tekstu.

Publiczne ewaluacje powinny porównywać Laneformer z modelami o podobnej wielkości w odpowiednich zadaniach programistycznych. Powinny także mierzyć, czy jego szybkość skraca czas realizacji od początku do końca, gdy agent planuje, wykonuje kod, napotyka błędy i koryguje swoje podejście.

Piątym ograniczeniem jest koszt. Kog opisuje swój silnik jako szybszy i tańszy, lecz szybkość nie determinuje automatycznie całkowitego kosztu obsługi. Osiem wysokiej klasy GPU zużywa istotną pojemność, nawet gdy jedno żądanie kończy się szybko.

Użyteczne porównanie wymaga założeń dotyczących zakupu lub wynajmu sprzętu, zużycia energii, średniego wykorzystania, współbieżności, wskaźników awarii i nakładu pracy operacyjnej. Następnie powinno przedstawiać wyniki jako koszt na ukończone zadanie, a nie wyłącznie koszt na wygenerowany token.

Szóste ograniczenie dotyczy dojrzałości produkcyjnej. Przedsiębiorstwa potrzebują uwierzytelniania, monitorowania, zarządzania pojemnością, celów poziomu usług, aktualizacji modeli, mechanizmów kontroli bezpieczeństwa i przewidywalnego zachowania podczas awarii. Zapowiedź techniczna nie obejmuje całego tego obszaru operacyjnego.

Te zastrzeżenia nie podważają architektury. Definiują dowody, które Kog musi przedstawić w następnej kolejności. Firma przeniosła debatę z poziomu twierdzenia teoretycznego do zestawu sprawdzalnych pytań inżynieryjnych.

Niezależne odtworzenie wyników zapewniłoby najsilniejszą walidację. Kog opublikował wyjaśnienia techniczne i artefakty modelu, ale zespoły zewnętrzne potrzebują wystarczającej ilości kodu i szczegółów konfiguracji, aby odtworzyć wyniki na porównywalnych systemach AMD i Nvidia.

Konkurenci również oferują użyteczne testy obciążeniowe. Groq i Cerebras mogą porównywać opóźnienie zadań, przepustowość, zużycie energii i dostępność modeli w dopasowanych warunkach. Ugruntowane silniki GPU mogą sprawdzić, czy podobna fuzja lub trwałe wykonywanie zmniejsza przewagę Kog.

Infinity reprezentuje inne podejście skoncentrowane na oprogramowaniu. Zamiast budować jeden głęboko zintegrowany stos modelu i środowiska uruchomieniowego, startup rozwija agenta, który pisze i dostraja kod niskopoziomowy dla różnych układów. Jego zautomatyzowane prace nad kernelami pokazują, jak sama AI wchodzi do pętli optymalizacji infrastruktury.

Ta droga może przyspieszyć rozpowszechnianie technik, które kiedyś wymagały rzadkiej wiedzy specjalistycznej o systemach. Oznacza to również, że przewaga Kog nie może opierać się wyłącznie na umiejętności pisania szybszych kerneli. Firma potrzebuje powtarzalnej platformy, zastrzeżonej wiedzy o wykonywaniu lub ścieżki dystrybucji, która zamieni inżynierię w trwałą wartość dla klienta.

Istnieje również ryzyko strategiczne związane z poleganiem na dostawcach sprzętu. AMD i Nvidia mogą ulepszać własne kompilatory, środowiska uruchomieniowe i silniki referencyjne. Mogą udostępniać nowe funkcje sprzętowe sprzyjające preferowanym przez siebie stosom oprogramowania.

Kog może ograniczyć to ryzyko, działając między dostawcami. Wyniki na systemach AMD MI300X i Nvidia H200 sugerują, że przenośność jest częścią planu. Mimo to wydobycie maksymalnej wydajności z każdej platformy często wymaga odmiennej pracy niskopoziomowej.

Niewielki rozmiar firmy może pomóc jej szybko się poruszać, ale ogranicza też liczbę modeli, konfiguracji i środowisk klientów, które może obsługiwać. Szeroka kompatybilność wymaga trwałej pracy inżynieryjnej, a nie jednej udanej kampanii optymalizacyjnej.

Nabywcy powinni zatem traktować benchmark jako obiecujący sygnał, a nie ostateczny werdykt zakupowy. Właściwym kolejnym krokiem jest ocena specyficzna dla obciążenia roboczego, wykorzystująca model nabywcy, rozkład promptów, współbieżność i kryteria sukcesu na poziomie zadań.

Kog kwestionuje błędne przekonanie, lecz nie udowodnił uniwersalnej tezy przeciwnej. GPU mogą być znacznie lepsze w agentowej inferencji, niż sugeruje płytki stos oprogramowania. Nie oznacza to, że przewyższą każdy wyspecjalizowany procesor przy każdym obciążeniu roboczym.

Trzy sygnały, które zdecydują o zakładzie Kog na GPU

Argumenty Kog wzmocnią się lub osłabną w ciągu najbliższych kilku miesięcy za sprawą wyników dla większych modeli, niezależnych testów produkcyjnych i wdrożeń klientów.

Pierwszym sygnałem będzie wydajność na szeroko używanym zewnętrznym modelu mixture-of-experts. Kog zapowiedział, że takie wsparcie jest częścią jego kierunku, a ten test usunąłby ochronę zapewnianą przez mały współprojektowany model.

Porównanie powinno wykorzystywać dopasowaną precyzję, długość kontekstu, długość wyjścia, sprzęt i współbieżność. Powinno raportować opóźnienie do pierwszego tokena, szybkość generowania wyjścia, całkowity czas zadania, przepustowość, zużycie pamięci i energii.

Mocne wyniki pokazałyby, że idee trwałych kerneli i opóźnionego równoleglenia uogólniają się poza Laneformer. Gwałtowny spadek wydajności sugerowałby, że obecna przewaga Kog w dużej mierze zależy od kontrolowania architektury modelu.

Drugim sygnałem będzie niezależna ocena w warunkach produkcyjnych. Dostawca chmury, korporacyjny zespół AI lub grupa benchmarkingowa powinni przetestować ten silnik przy zmiennym ruchu i długotrwałych przepływach pracy agentów.

Taka ocena powinna obejmować awarie, anulowanie żądań, buforowanie promptów, długie konteksty i mieszane obciążenia. Powinna mierzyć liczbę ukończonych zadań na jednostkę infrastruktury, zamiast skupiać się wyłącznie na maksymalnej generacji tokenów.

Dowody z wdrożeń produkcyjnych wzmocniłyby tezę Kog, że GPU nadal nadają się do obsługi interaktywnych agentów. Jeśli silnik zapewnia szybkość jedynie w kontrolowanej demonstracji, wyspecjalizowany sprzęt i sprawdzone systemy obsługi zapytań zachowują silniejsze uzasadnienie operacyjne.

Trzecim sygnałem będzie znaczące wdrożenie wykraczające poza techniczny podgląd. Wskazany z nazwy klient, wspierane środowisko chmurowe lub powtarzalny pakiet do samodzielnego hostowania sugerowałyby, że Kog potrafi przekształcić swoje prace optymalizacyjne w dostępny produkt.

Adopcja przez klientów ujawniłaby także, który rynek najbardziej ceni ten system. Dostawcy chmurowych GPU mogą wykorzystywać go do poprawy ekonomiki istniejących flot. Twórcy agentów mogą wdrażać go, aby skrócić czasy odpowiedzi. Przedsiębiorstwa mogą doceniać możliwość pozostania przy znanym sprzęcie.

Charakter tych wdrożeń ma większe znaczenie niż duże logo. Niewielka aplikacja do programowania lub obsługi głosowej z rygorystycznymi wymaganiami dotyczącymi opóźnień może dostarczyć lepszych dowodów technicznych niż szerokie partnerstwo bez zmierzonego wykorzystania.

Uwaga ze strony Google News może przedstawić tezę Kog szerszej publiczności, ale o trwałości tej idei zdecydują powtarzalne wyniki. Startup przedstawia konkretną tezę: GPU nie przestały być fundamentem inferencji agentowej, ponieważ ich stos oprogramowania wciąż można dalej ulepszać.

Deweloperzy powinni teraz zapytać, gdzie ich agenci rzeczywiście czekają. Jeśli dominuje dekodowanie, głębsza optymalizacja inferencji zasługuje na bezpośredni test. Jeśli dominują bazy danych, narzędzia lub słabe decyzje modelu, szybsze tokeny nie rozwiążą całego problemu.

Kolejny krok jest mierzalny. Porównaj nadchodzące wyniki Kog dla większych modeli z wyspecjalizowanymi układami i sprawdzonymi silnikami GPU przy tym samym obciążeniu. Następnie śledź ukończenie zadań, niezawodność i wykorzystanie infrastruktury. Te dane pokażą, czy Kog znalazł ścieżkę o szerokim zastosowaniu, czy imponujący, lecz wąski szczyt wydajności.