Fireworks AI rozszerzyło swoją platformę wnioskowania o nowe poziomy usług, dłuższe buforowanie podpowiedzi, integrację komputerów stacjonarnych i elementy sterujące ładem korporacyjnym. Ogłoszone na firmowym wydarzeniu Forge 3 listopada, nowe wersje traktują opóźnienia, pilność obciążenia i lokalizację wdrożenia jako osobne opcje operacyjne, a nie stałe właściwości punktu końcowego modelu.

Najbardziej konsekwentną zmianą dla programistów może być tryb tła, w którym ceny kwalifikujących się obciążeń z możliwością odroczenia w czasie są o połowę niższe. W programie Fireworks wprowadzono także ultraszybką warstwę wnioskowania w publicznej wersji zapoznawczej, działającą na infrastrukturze NVIDIA Blackwell i ogólnie udostępniono wyższe limity szybkości transmisji bezserwerowej.

W sumie te dodatki tworzą wyraźniejszy kompromis pomiędzy szybkością i kosztem. Aplikacje mogą rezerwować szybszą infrastrukturę na potrzeby interaktywnych żądań podczas przenoszenia ocen, przetwarzania dokumentów, wzbogacania danych i innych zadań odpornych na opóźnienia do tańszej kolejki. To rozróżnienie istnieje od dawna w wewnętrznych systemach zadań, ale Fireworks obecnie ujawnia je jako funkcję wnioskowania komercyjnego.

Opóźnienie staje się płatnym wyborem usługi

Fireworks twierdzi, że jego ultraszybki poziom może osiągnąć do 1500 tokenów na sekundę i przytacza obciążenie pracą związane z kodowaniem, w którym 30-turowe zadanie spadło z około jednej minuty do ośmiu sekund. Dane te pochodzą z własnych testów firmy i nie należy ich traktować jako uniwersalnych gwarancji wydajności. Rzeczywiste wyniki będą zależeć od modelu, kształtu żądania, współbieżności i otaczającej aplikacji.

Implikacje architektoniczne są trwalsze niż jakikolwiek indywidualny test porównawczy. Brama nie może już zakładać, że tożsamość modelu i liczba tokenów wystarczą do wyjaśnienia opłaty. Może być także konieczne rejestrowanie, czy żądanie korzystało z warstwy interaktywnej, ultraszybkiej czy działającej w tle, wraz z czasem oczekiwania i wszelkimi ograniczeniami kwalifikowalności.

Zwiększa to wartość ujednoliconej sztucznej inteligencji API billing, która zachowuje metadane warstwy usług. Bez tych szczegółów klienci mogą mieć trudności ze sprawdzeniem, dlaczego dwa połączenia z tym samym modelem miały różną cenę. Sprzedawcy będą również potrzebować wersjonowanych arkuszy stawek, zanim będą mogli przekazać klientom rabat w tle lub zachować jego część jako marżę.

Buforowanie podpowiedzi i routing na komputerze poszerzają platformę

W programie Fireworks wprowadzono także wielodniowe buforowanie podpowiedzi. Długotrwałe pamięci podręczne mogą ograniczyć powtarzalne przetwarzanie danych wejściowych dla agentów kodujących, systemów badawczych i aplikacji, które ponownie wykorzystują duże konteksty instrukcji lub dokumentów. Wynik finansowy będzie zależał od cen zapisu w pamięci podręcznej, zasad przechowywania i współczynników trafień, więc programiści powinni mierzyć oszczędności w oparciu o własny ruch, zamiast zakładać, że dłuższe przechowywanie automatycznie obniża koszty.

Nexus Desktop rozszerza routing modeli Fireworks na aplikacje Codex, Claude Desktop i OpenCode. Dzięki temu wybór modelu i widoczność wydatków są bliżej narzędzi, przy których pracują programiści. Stawia to także program Fireworks w bardziej bezpośredniej konkurencji z niezależnymi bramami i routerami na poziomie IDE, które oferują jedną warstwę dostępu dla różnych dostawców.

W przypadku organizacji inżynierskich integracja komputerów stacjonarnych rodzi znane pytania dotyczące płaszczyzny kontrolnej: jakie modele mogą wybierać użytkownicy, jakie referencje przechowuje złącze, w jaki sposób przypisane jest użycie i czy aktywność narzędzi lokalnych pojawia się w centralnych rejestrach audytu. Wspólna AI API płaszczyzna kontroli dla zespołów programistów staje się bardziej użyteczna, gdy dostęp do modelu jest rozdzielony pomiędzy redaktorów, agentów komputerowych i zautomatyzowane zadania.

Postępuje zarządzanie i niezależne wdrażanie

Fireworks udostępnił ogólnie swoje funkcje zarządzania modelami, kontrolę wydatków i dzienniki audytu z możliwością eksportu. Te możliwości dają administratorom przedsiębiorstwa możliwość zarządzania dostępem i sprawdzania aktywności bez konieczności budowania każdej warstwy zasad wokół wniosków API.

Firma umieściła także program Fireworks Sovereign w wersji prywatnej.Ta oferta ma na celu uruchomienie silnika wnioskowania Fireworks w infrastrukturze kontrolowanej przez klienta i jest skierowana do organizacji o bardziej rygorystycznych wymaganiach dotyczących lokalizacji danych, własności operacyjnej lub izolowanych środowisk. Dostępność pozostaje ograniczona, a program Fireworks nie udostępnił publicznie wystarczającej ilości szczegółów, aby ocenić wysiłek wdrożeniowy lub całkowity koszt w różnych środowiskach.

W przypadku bram i platform sprzedawców te wydania podwyższają oczekiwany poziom bazowy. Klienci coraz częściej oczekują limitów wydatków LLMAPI według klucza, możliwych do wyeksportowania ścieżek audytu i egzekwowania zasad wdrażania wraz z routingiem modelu. Model Gate i podobne usługi będą również musiały rozróżniać żądania w tle i przyspieszone w rejestrach użytkowania, jeśli ujawniają warstwy usług dostawcy za pośrednictwem ujednoliconego punktu końcowego.

Co pozostaje niejasne

Fireworks twierdzi, że jego infrastruktura może podwoić tokeny na dolara GPU i że zarządza ponad 25 000 procesorów graficznych klientów. Obie wartości pochodzą od dostawców. Konieczne będą niezależne porównania, aby ustalić, jak nowe warstwy radzą sobie z ciągłą współbieżnością, różnymi modelami i obciążeniami rzeczywistych agentów.

Tryb w tle również wymaga dokładniejszej analizy. Fireworks opisuje ją jako dostępną dla kwalifikujących się obciążeń z możliwością odroczenia, ale kwalifikowalność, opóźnienie kolejki i pokrycie modelu mogą się różnić. Przed przeniesieniem zadań produkcyjnych zespoły powinny potwierdzić sposób anulowania, limity czasu, obserwowalność oraz to, czy praca w kolejce ma takie same warunki obsługi danych jak zwykłe wnioskowanie.

Ogłoszenia Forge nie ograniczają zakupu wnioskowania do prostej decyzji „szybko kontra tanio”. Dodają do tego więcej wymiarów. Programiści muszą teraz zdecydować nie tylko, który model powinien obsłużyć żądanie, ale także jak pilnie powinno ono zostać uruchomione, jak długo jego kontekst powinien pozostać w pamięci podręcznej i gdzie powinien działać silnik wnioskowania. Bramy, które mogą zachować te decyzje w zasadach, dziennikach i fakturach, będą lepiej umiejscowione niż systemy, które reprezentują każde żądanie jako niezróżnicowaną opłatę za token.