Reflection AI przedstawiła Beam, model z otwartymi wagami przeznaczony do programowania agentowego i długotrwałych zadań. Artykuł AWS wymienia utrzymanie i modyfikowanie kodu, rozwiązywanie problemów z oprogramowaniem, wywoływanie narzędzi, interpretowanie wyników pośrednich i realizację wieloetapowych procesów. W momencie premiery Beam jest dostępny w Amazon SageMaker JumpStart w regionach US East (N. Virginia) i US East (Ohio).

Skala modelu i dostęp do wag

Beam wykorzystuje rzadką architekturę mixture-of-experts: ma 501 miliardów parametrów ogółem i 23 miliardy aktywnych. Reflection deklaruje efektywną długość kontekstu wynoszącą milion tokenów; dostarczone materiały nie zawierają niezależnej weryfikacji. Łączna liczba parametrów wpływa na przechowywanie checkpointu, pamięć wag, ich podział i równoległość. Parametry aktywne wpływają na obliczenia na token. Mniejsza liczba aktywnych parametrów nie zastępuje więc planowania pamięci dla wszystkich wag.

Reflection udostępnia wagi Beam 1.0 na Hugging Face na licencji Apache 2.0. Warianty BF16, FP8 i NVFP4 różnią się zapotrzebowaniem na pamięć oraz zgodnością sprzętową. Firma wiąże otwarte wagi, publikowane badania i oprogramowanie open source ze swoją misją zapewnienia otwartej i dostępnej inteligencji. Dostęp do wag daje programistom kontrolę nad środowiskiem uruchomieniowym, wdrożeniem i dostosowaniem modelu.

Trzy ścieżki wdrożenia

• Endpoint JumpStart czasu rzeczywistego: zarządzana obsługa bez prowadzenia środowiska Kubernetes.
• JumpStart na HyperPod Inference: klaster zarządzany przez Amazon EKS z kontenerem i konfiguracją modelu zarządzanymi przez AWS.
• SGLang lub vLLM na HyperPod Inference: kontrola nad obrazami do obsługi modelu, argumentami runtime, kwantyzacją i wykonaniem rozproszonym.

Przykład endpointu JumpStart obsługuje wszystkie trzy warianty, domyślnie NVFP4. Pokazane polecenie FP8 wdraża endpoint, wysyła krótkie żądanie, wyświetla odpowiedź i usuwa endpoint. README zawiera również funkcje Pythona pozwalające pozostawić go w działaniu. Przykład z automatycznym sprzątaniem zasobów należy zatem odróżnić od trwałego wdrożenia.

Zasoby i wymagania

Artykuł wymienia konto AWS z uprawnieniami do SageMaker, IAM, sieci i pamięci masowej, dostęp do modelu i akceptację jego warunków, AWS CLI, Python 3.11 lub nowszy oraz odpowiednie limity i dostępność GPU. HyperPod wymaga dodatkowo dostępu przez kubectl do klastra EKS, HyperPod Inference Operator i dodatków, konfiguracji sieci oraz dostępu do artefaktów. Buforowanie modelu wymaga także lokalnej pojemności NVMe.

Beam potrzebuje wielu GPU; dla BF16 artykuł zaleca zaplanowanie konfiguracji wielowęzłowej. Dla FP8 wskazuje ml.p5.48xlarge z H100 albo ml.p5e.48xlarge i ml.p5en.48xlarge z H200. Dla NVFP4 wymienia ml.p6-b200.48xlarge z B200. Dobór zależy od zgodności checkpointu, runtime i układu wykonania równoległego. Plan powinien uwzględniać wagi, pamięć KV cache, narzut runtime, regionalną dostępność typów instancji, limity i testy obciążeniowe. Można wykorzystać zasoby na żądanie albo plan treningowy SageMaker.

Artefakty, sprawdzanie wdrożenia i pomiary

HyperPod może pobierać Beam przez JumpStart, Hugging Face Hub lub opcjonalną kopię w S3. AWS zaleca przypięte rewizje podczas prac rozwojowych oraz kopiowanie checkpointów do S3 lub FSx na potrzeby produkcji i buforowania. HyperPod może wcześniej załadować wagi do lokalnego NVMe i pobrać obrazy. Inference Gateway udostępnia interfejs zgodny z OpenAI oraz kieruje żądania między replikami. Obsługiwane są też zarządzane wielopoziomowe buforowanie KV i inteligentny routing.

Wdrożenie odbywa się przez katalog JumpStart w SageMaker Studio albo przykładowe konfiguracje i manifesty. Artykuł zaleca niezmienne wydania modelu, rewizje checkpointów i skróty obrazów. Narzędzia pomocnicze sprawdzają konfiguracje i stosują manifesty bez zapisywania uzupełnionych wartości wydania na dysku. Narzędzie dla własnego runtime ma stały limit czasu i diagnostykę błędów. Podstawowy test SGLang/vLLM wybiera gotowy worker, tymczasowo przekierowuje port, sprawdza stan, wysyła żądanie i zamyka połączenie.

AWS zaleca powtarzane, reprezentatywne testy programowania i użycia narzędzi przy oczekiwanej współbieżności oraz zapis konfiguracji modelu i runtime. Pomiary obejmują skuteczność żądań, p50/p95 czasu do pierwszego tokenu, czas na token wyjściowy, całkowite opóźnienie i łączną liczbę tokenów wyjściowych na sekundę. Wyniki powinny kierować zmianami grupowania żądań, KV cache, replik, autoskalowania i buforowania. Po zmianie precyzji lub kwantyzacji należy ponownie ocenić jakość odpowiedzi. Materiały nie zawierają zmierzonych benchmarków, kosztów ani porównań modeli. Zasoby testowe i nieużywane artefakty należy usuwać, aby uniknąć dalszych opłat.