OpenAI i Cerebras: 750 MW dla inference AI

14 stycznia 2026 roku OpenAI ogłosiło partnerstwo z Cerebras, które ma dodać do platformy 750 MW niskolatencyjnej mocy obliczeniowej AI. Pojemność ma trafiać online etapami do 2028 roku. Firma określiła ją jako część portfela inference, w którym różne systemy są dopasowywane do różnych obciążeń.

To zapowiedź infrastruktury i planowanej mocy, nie informacja, że 750 MW działało w dniu publikacji. Parametr elektryczny nie przekłada się też bezpośrednio na liczbę użytkowników, tokenów ani konkretny koszt. Zależy to od modelu, wykorzystania, chłodzenia, niezawodności i efektywności całego data center.

Dlaczego architektura wafer-scale może zmniejszać opóźnienie

Cerebras integruje wiele obliczeń, pamięci i przepustowości na jednym bardzo dużym układzie. W klasycznym klastrze warstwy modelu są rozłożone między akceleratory, a token generowany sekwencyjnie musi czekać na komunikację. Mniej granic między chipami może zmniejszać czas przesyłu i zwiększać tempo długiej odpowiedzi. To opis architektoniczny; realny wynik należy mierzyć end-to-end, a nie tylko tokens/s w laboratorium.

Użytkownik odczuwa trzy różne opóźnienia: czas do pierwszego tokenu, tempo kolejnych tokenów i czas całego zadania z narzędziami. Agent może generować tekst błyskawicznie, lecz nadal czekać na bazę, przeglądarkę lub API. Dlatego zakup szybkiego inference ma największy sens dla interaktywnego kodowania, głosu, wieloetapowych agentów i długich odpowiedzi, nie dla każdej pracy batchowej.

Miks sprzętu zamiast jednego zwycięzcy

OpenAI wyraźnie mówi o portfelu. Trening, prefill dużego promptu, decode i embeddingi mają inne profile pamięci oraz komunikacji. Architektura świetna w sekwencyjnym decode może być mniej ekonomiczna dla krótkich, wysoko batchowanych zapytań. Router infrastrukturalny może kierować zadanie do GPU, własnego układu lub systemu wafer-scale według latency, kosztu i dostępności.

Dla zespołu kupującego API ważniejsze od nazwy chipu są SLO:

• p50/p95 czasu do pierwszego tokenu,
• p95 inter-token latency przy realnej długości promptu,
• stabilność pod obciążeniem i limitami,
• koszt zakończonego zadania, nie miliona tokenów,
• region przetwarzania i ścieżka awaryjna.

Szybsza odpowiedź może zwiększyć liczbę działań agenta, a z nią ryzyko. Limity narzędzi, budżet kroków i pełny tracing muszą rosnąć razem z przepustowością. Architektury kontroli opisujemy w bezpieczeństwie agentów AI.

Partnerstwo OpenAI–Cerebras pokazuje, że konkurencja przechodzi z „czy model umie” do „czy umie wystarczająco szybko i przewidywalnie”. Przy wdrożeniu warto testować latency, koszt i kontrolę narzędzi na jednym realistycznym workflow.

Jak zbudować uczciwy benchmark latency

Ustal stały model, temperaturę, długość promptu i oczekiwanej odpowiedzi. Wykonaj warm-up, a potem mierz serię w różnych porach dnia oraz przy równoległości odpowiadającej produkcji. Raportuj percentyle, nie najlepszy przebieg. Osobno pokazuj czas sieci, kolejki, first token i decode.

Streaming może poprawić odczucie szybkości, choć całe zadanie trwa tyle samo. Z kolei spekulatywne dekodowanie może zwiększyć tempo, ale efekt zależy od zgodności draft modelu. Porównanie ma obejmować identyczny wynik jakościowy; przyspieszenie uzyskane przez krótszą lub gorszą odpowiedź nie jest równoważne.

Niezawodność i routing między backendami

Portfel akceleratorów wymaga routera świadomego możliwości. Model lub jego wariant kwantyzowany może nie działać identycznie na każdym backendzie. Fallback powinien zachować limity, politykę danych i format narzędzi. Jeżeli awaria szybkiego backendu kieruje ruch do wolniejszego, kolejka może wywołać lawinę retry.

Stosuj deadline całego zadania, bounded retry z jitterem i load shedding. Dla agentów ważniejszy jest czas zakończenia celu niż czas pojedynczego wywołania. Śledź, ile kroków i tokenów powstało przed błędem oraz czy ponowienie nie powtarza skutku ubocznego.

Energia jako część SLO

750 MW jest liczbą mocy infrastrukturalnej, nie zużyciem pojedynczej odpowiedzi. Aby ocenić efektywność, potrzebne są zadania na kWh, PUE obiektu i udział wykorzystanego akceleratora. Bezczynna rezerwa poprawia latency i niezawodność, ale pogarsza efektywność.

Czy więcej tokens/s zawsze oznacza lepszy UX? Nie. Dla krótkiej odpowiedzi dominuje first-token latency, a dla agenta — czas narzędzi i liczba kroków. Optymalizuj metrykę użytkownika.

Decyzja architektoniczna

Nie wiąż aplikacji z obietnicą jednego backendu. Warstwa dostępu powinna pozwalać zmienić region lub klasę inference, zachować ewaluacje i porównać koszt. Dla krytycznego workflow ustal maksymalny dopuszczalny czas, tryb kolejki i odpowiedź awaryjną. Szybki model bez kontrolowanego fallbacku może mieć gorszą dostępność niż wolniejszy, ale przewidywalny system.

---

Źródło pierwotne: OpenAI — OpenAI partners with Cerebras.