Reflection AI hat Beam vorgestellt, ein Modell mit offenen Gewichten für agentisches Programmieren und länger laufende Aufgaben. Der AWS-Beitrag nennt die Pflege und Änderung von Code, die Behebung von Softwareproblemen, Werkzeugaufrufe, die Auswertung von Zwischenergebnissen und mehrstufige Abläufe. Zum Start ist Beam in Amazon SageMaker JumpStart in US East (N. Virginia) und US East (Ohio) verfügbar.

Modellgröße und offene Gewichte

Beam nutzt eine Sparse-Mixture-of-Experts-Architektur mit insgesamt 501 Milliarden und 23 Milliarden aktiven Parametern. Reflection nennt eine effektive Kontextlänge von einer Million Tokens; eine unabhängige Bestätigung liefern die vorliegenden Unterlagen nicht. Die Gesamtzahl beeinflusst Checkpoint-Speicher, Gewichtsspeicher, Sharding und Parallelisierung. Die aktiven Parameter beeinflussen den Rechenaufwand je Token. Ihre geringere Zahl ersetzt daher keine Speicherplanung für sämtliche Gewichte.

Reflection veröffentlicht die Gewichte von Beam 1.0 auf Hugging Face unter Apache 2.0. Die Checkpoints BF16, FP8 und NVFP4 unterscheiden sich beim Speicherbedarf und bei der Hardwarekompatibilität. Offene Gewichte, veröffentlichte Forschung und Open-Source-Software gehören laut Reflection zum Ziel, Intelligenz offen und zugänglich zu machen. Die Gewichte geben Entwicklern Kontrolle über Laufzeitumgebung, Bereitstellung und Anpassungen.

Drei Wege zur Bereitstellung

• JumpStart-Echtzeit-Endpunkt: verwalteter Betrieb ohne eigenen Kubernetes-Betrieb.
• JumpStart auf HyperPod Inference: ein von Amazon EKS orchestrierter Cluster mit AWS-verwaltetem Container und entsprechender Modellkonfiguration.
• SGLang oder vLLM auf HyperPod Inference: Kontrolle über Serving-Images, Laufzeitargumente, Quantisierung und verteilte Ausführung.

Das JumpStart-Endpunktbeispiel unterstützt alle drei Varianten und verwendet standardmäßig NVFP4. Der gezeigte FP8-Befehl erstellt einen Endpunkt, sendet eine kurze Anfrage, gibt die Antwort aus und entfernt den Endpunkt anschließend. Die README enthält auch Python-Funktionen, um einen Endpunkt weiterzubetreiben. Das Beispiel mit anschließender Bereinigung ist damit von einer dauerhaften Bereitstellung zu unterscheiden.

Kapazität und Voraussetzungen

Benötigt werden laut Beitrag ein AWS-Konto mit passenden SageMaker-, IAM-, Netzwerk- und Speicherberechtigungen, Modellzugriff samt Annahme der Bedingungen, AWS CLI, Python ab Version 3.11 sowie GPU-Kontingente und Kapazität. HyperPod setzt zusätzlich kubectl-Zugriff auf einen EKS-Cluster, den HyperPod Inference Operator und Erweiterungen, Netzwerkkonfiguration und Artefaktzugriff voraus. Modell-Caching benötigt außerdem lokalen NVMe-Speicher.

Beam benötigt mehrere GPUs; für BF16 empfiehlt der Beitrag eine Planung mit mehreren Knoten. Für FP8 nennt er ml.p5.48xlarge mit H100 sowie ml.p5e.48xlarge und ml.p5en.48xlarge mit H200. Für NVFP4 nennt er ml.p6-b200.48xlarge mit B200. Die Eignung hängt von Checkpoint, Laufzeitumgebung und Parallelisierung ab. Einzuplanen sind Gewichte, KV-Cache, Laufzeit-Overhead, regionale Instanzunterstützung, Kontingente und Lasttests. Möglich sind On-Demand-Kapazität oder ein SageMaker-Trainingsplan.

Artefakte, Prüfungen und Messwerte

HyperPod kann Beam aus JumpStart, dem Hugging Face Hub oder einem optionalen S3-Spiegel beziehen. AWS empfiehlt festgelegte Revisionen für die Entwicklung und Checkpoint-Kopien in S3 oder FSx für Produktion und Caching. Gewichte lassen sich auf lokalen NVMe-Speicher vorladen, Serving-Images vorab herunterladen. Das Inference Gateway bietet eine OpenAI-kompatible Schnittstelle und verteilt Anfragen auf Replikate. HyperPod unterstützt auch verwaltetes mehrstufiges KV-Caching und intelligentes Routing.

Die Bereitstellung erfolgt über den JumpStart-Katalog in SageMaker Studio oder Beispielkonfigurationen und Manifeste. Empfohlen werden unveränderliche Modellversionen, Checkpoint-Revisionen und Image-Digests. Hilfsprogramme prüfen Konfigurationen und wenden Manifeste an, ohne eingesetzte Release-Werte auf Datenträger zu schreiben. Das Hilfsprogramm für eigene Laufzeitumgebungen verwendet ein festes Zeitlimit und Fehlerdiagnosen. Der SGLang/vLLM-Funktionstest wählt einen bereiten Worker, leitet vorübergehend einen Port weiter, prüft den Zustand, sendet eine Anfrage und schließt die Verbindung.

AWS empfiehlt wiederholte repräsentative Programmier- und Werkzeugtests bei erwarteter Parallelität sowie die Dokumentation der Modell- und Laufzeitkonfiguration. Zu messen sind Anfrageerfolg, p50/p95 der Zeit bis zum ersten Token, Zeit je Ausgabetoken, Gesamtlatenz und gesamte Ausgabetokens pro Sekunde. Die Ergebnisse sollen Batching, KV-Cache, Replikate, Autoskalierung und Caching steuern. Nach Präzisions- oder Quantisierungsänderungen ist die Ausgabequalität erneut zu prüfen. Die Unterlagen enthalten keine gemessenen Benchmarks, Kosten oder Modellvergleiche. Testressourcen und ungenutzte Artefakte sollen entfernt werden, um weitere Gebühren zu vermeiden.