Aleph Alpha zeigt am Beispiel von Kolibri, wie Architekturentscheidungen die Kosten von LLMs bestimmen
Aleph Alpha hat einen Forschungsblogbeitrag veröffentlicht, der herleitet, wie zentrale Architekturentscheidungen bei autoregressiven Sprachmodellen die Kosten für Training und Betrieb bestimmen. Der Beitrag von Pit Neitemeier und Alessio Serra enthält zudem ein interaktives Tool, mit dem sich ein Modell konfigurieren und mit aktuellen Open-Weight-Modellen vergleichen lässt.
- Aleph Alpha leitet her, wie Architekturentscheidungen bei MoE-Modellen Gesamtparameter, FLOPs pro Token und Sequence-Mixer-State festlegen.
- Die Engpässe im Betrieb variieren: Gewichtszugriffe beim Decoding mit kleinen Batches, Rechenleistung beim Prefill, State-Zugriffe beim Decoding mit langem Kontext.
- Ein interaktiver Explorer erlaubt es, ein Modell zu konfigurieren und mit aktuellen Open-Weight-Modellen zu vergleichen.
- Laut der Tabelle im Beitrag hat Kolibri 78,1 Mrd. Gesamtparameter und 3,5 Mrd. aktive Parameter und wurde nach Angaben von Aleph Alpha kürzlich unter Apache 2.0 veröffentlicht.
Drei Größen bestimmen die Kosten
Laut Aleph Alpha muss die Wirkung einer Architekturentscheidung auf die Qualität empirisch gemessen werden, die Kosten ergeben sich dagegen unmittelbar aus der Konfiguration. Der Beitrag konzentriert sich auf drei Größen. Die Gesamtzahl der Parameter legt den Speicherbedarf für die Gewichte fest und damit die Mindestanforderungen an die Hardware für den Betrieb eines Modells. Die FLOPs pro Token bestimmen, multipliziert mit dem Trainings-Token-Horizont, den Rechenaufwand beim Training und dienen zugleich als Näherung für die Kosten des Prefills, der in der Regel rechenlimitiert ist. Der Sequence-Mixer-State, etwa der Key-Value-Cache (KV-Cache) in einem Attention-basierten Modell, bestimmt, wie viele Sequenzen und wie viel Kontext in einen Decode-Batch passen und wie viele Bytes jeder Decode-Schritt lesen muss.
Welche dieser Größen im Betrieb zum Engpass wird, hängt laut den Autoren von der Arbeitslast ab. Decoding mit kleinen Batches und kurzem Kontext wird durch das Lesen der Gewichte begrenzt. Prefill und Decoding kurzer Anfragen mit großen Batches sind rechenlimitiert. Beim Decoding mit langem Kontext begrenzt das Lesen des Sequence-Mixer-State.
Parameterverteilung in MoE-Modellen
Der Beitrag leitet jede dieser Größen für Mixture-of-Experts-Decoder (MoE) her und vergleicht aktuelle Open-Weight-Modelle. Er untersucht, wie sich die aktiven Parameter auf das Feed-Forward-Netzwerk (FFN), den Sequence-Mixer und den Language-Modelling-Head verteilen, wie die FLOPs pro Token aufgeteilt sind und mit der Sequenzlänge skalieren und wie viel State jede Sequenz belegt.
Aleph Alpha weist darauf hin, dass sich Gesamtzahl und aktive Parameter bei MoE-Architekturen um eine Größenordnung unterscheiden können. Die Gesamtzahl der Parameter wirkt sich vor allem auf den Speicherbedarf aus, während die aktiven Parameter in der Regel den größten Teil der FLOPs bei Training und Prefill ausmachen. Bei kleinen Batchgrößen bestimmen sie auch weitgehend, wie viele Gewichts-Bytes jeder Decode-Schritt liest.
Die Herleitungen sind konkret. Ein SwiGLU-Experte hat drei lineare Projektionen (Gate, Up und Down), also 3 × d × d_e Parameter pro Experte. Die aktiven gerouteten Parameter ergeben sich, indem die Zahl der Experten durch die tatsächlich genutzten Top-k-Experten ersetzt wird. Mehrere Shared Experts entsprechen einem einzelnen Shared Expert mit größerer Breite, da sie immer aktiv sind. Der Router, der den Residual Stream auf einen Logit pro Experten abbildet, macht nur einen sehr kleinen Teil der Gesamtparameter aus. Für die Attention gibt der Beitrag die Projektionsparameter mit 2 × L_attn × d × (d_q + d_kv) an, wobei Multi-Head-Attention und Multi-Query-Attention die beiden Grenzfälle der Grouped-Query-Attention sind. Außerdem behandelt er Normalisierungsschichten sowie Embedding und LM-Head.
Kolibri im Vergleich mit anderen Open-Weight-Modellen
Der interaktive Explorer ist nach Angaben von Aleph Alpha eine vereinfachte Teilmenge eines internen Tools, das das Unternehmen beim Entwurf von Architekturen einsetzt, um Zielkonflikte zu beziffern, bevor man sich auf eine Konfiguration festlegt. Er ist von Sebastian Raschkas LLM Architecture Gallery inspiriert und startet mit zwei Modellen von Aleph Alpha, Kolibri Origin und Kolibri. Kolibri wurde nach Angaben des Unternehmens kürzlich unter der Apache-2.0-Lizenz veröffentlicht. Nutzer können Schieberegler verstellen oder eine eigene Konfiguration hinzufügen.
Eine Tabelle im Beitrag listet Gesamtzahl und aktive Parameter pro Token auf. Kolibri kommt auf 78,1 Mrd. Gesamtparameter und 3,5 Mrd. aktive Parameter, das entspricht 4,4 % aktiven Parametern. Kolibri Origin hat 30,6 Mrd. Gesamtparameter und 3,3 Mrd. aktive, also 10,7 %. Weitere Einträge sind Nemotron 3 Nano (31,6 Mrd. gesamt, 3,2 Mrd. aktiv), GPT-OSS 120B (116,8 Mrd. gesamt, 5,1 Mrd. aktiv) und GPT-OSS 20B (20,9 Mrd. gesamt, 3,6 Mrd. aktiv). Am oberen Ende stehen DeepSeek V4-Pro mit 1,57 Bio. Gesamtparametern und 48,8 Mrd. aktiven sowie Kimi K3 mit 2,78 Bio. gesamt und 104,2 Mrd. aktiv.
Die Tabelle zählt jedes gespeicherte Gewicht des Text-Decoders zur Gesamtzahl. Die aktiven Parameter schließen das Input-Embedding aus, weil es sich dabei um einen Lookup und nicht um eine Matrixmultiplikation handelt.
Was das für Modellentwickler bedeutet
Der Beitrag richtet sich an Fachleute, die Sprachmodelle entwerfen oder bewerten. Er zeigt, dass sich Hardwarebedarf im Betrieb, Trainingsaufwand und Grenzen beim Serving mit langem Kontext schon vor einem Trainingslauf aus der Konfiguration abschätzen lassen. Die Vergleichstabelle macht außerdem deutlich, wie stark der Anteil aktiver Parameter bei aktuellen Open-Weight-Modellen schwankt, von 2,9 % bei DeepSeek V4.1-Flash bis 17,3 % bei GPT-OSS 20B. Die Auswirkungen auf die Qualität müssen laut den Autoren weiterhin empirisch gemessen werden.
