- Große Frontier-Modelle waren in der Regel durch Geschwindigkeit und Latenz begrenzt, aber Cerebras Inference erreichte bei Kunden-Workloads mit Llama 3.1 405B 969 ausgegebene Token pro Sekunde
- Bei einem Prompt mit 1.000 Token war das Ergebnis 8-mal schneller als SambaNova, 12-mal schneller als die schnellste GPU-Cloud und 75-mal schneller als AWS
- Bei einer Eingabe von 100.000 Token lieferten nur 6 Anbieter Ergebnisse zurück, und Cerebras schloss den Benchmark als einziger Nicht-GPU-Anbieter ab und erreichte 539 Token pro Sekunde
- Die Zeit bis zum ersten Token betrug 240 ms, und Kunden, die von GPT-4 gewechselt sind, berichteten von 75 % geringerer Gesamtlatenz
- Cerebras Inference für Llama 3.1 405B ist derzeit als Kundenvorschau verfügbar; die allgemeine Verfügbarkeit ist für das 1. Quartal 2025 geplant, bei einem Preis von 6 $/M Eingabe- und 12 $/M Ausgabetoken
Leistungsrekord für Llama 3.1 405B
- Cerebras Inference erreichte bei der Ausführung von Llama 3.1 405B 969 output tokens/s
- Das Ergebnis basiert auf einem Prompt mit 1.000 Token
- Laut Messungen von Artificial Analysis wurden Rekorde bei Ausgabegeschwindigkeit, Long-Context-Leistung und Zeit bis zum ersten Token aufgestellt
- Im selben Vergleich wird Llama 3.1 405B auf Cerebras als 12-mal schneller als GPT-4o und 18-mal schneller als Claude 3.5 Sonnet beschrieben
- Cerebras erklärt, dass das Unternehmen in diesem Jahr Llama 3.1 8B und 70B auf mehr als 2.000 tokens/s gebracht hat, während Frontier-Modelle wie GPT-4o, Claude 3.5 Sonnet und Llama 3.1 405B auf GPU, ASIC oder in der Cloud nirgendwo 200 tokens/s überschritten hätten
- Der Vergleich auf Basis eines Prompts mit 1.000 Token sieht wie folgt aus
- 8-mal schneller als SambaNova
- 12-mal schneller als die schnellste GPU-Cloud
- 75-mal schneller als AWS
- Bei einem Eingabe-Prompt mit 100.000 Token wurden 539 tokens/s erreicht
- Nur 6 Anbieter lieferten Ergebnisse zurück
- Cerebras war der einzige Nicht-GPU-Anbieter, der den Benchmark abschloss
- 11-mal schneller als Fireworks und 44-mal schneller als AWS
Latenz, Verfügbarkeit und Preis
- Cerebras Inference für Llama 3.1 405B erreichte 240 ms Zeit bis zum ersten Token
- Die Zeit bis zum ersten Token ist ein zentraler Latenzindikator, den Nutzer in realen Anwendungen direkt wahrnehmen
- Bei GPU-basierten Lösungen kann sich die anfängliche Reaktionszeit auf mehrere Sekunden ausdehnen
- Kunden, die von GPT-4 zu Cerebras Inference gewechselt sind, berichteten von einer um 75 % reduzierten Gesamtlatenz
- Das führt zu einer besseren Nutzererfahrung bei Anwendungsfällen, in denen Echtzeitinteraktion wichtig ist, etwa bei Sprach- und Video-KI-Anwendungen
- Cerebras Inference für Llama 3.1 405B ist derzeit als Kundenvorschau verfügbar
- Die allgemeine Verfügbarkeit ist für das 1. Quartal 2025 geplant
- Der Preis beträgt 6 $ pro 1 Million Eingabetoken und 12 $ pro 1 Million Ausgabetoken
- Der Preis für Ausgabetoken liegt 20 % unter AWS, Azure und GCP
- Es wird erklärt, dass die Kombination aus Metas offenem Ansatz und der Inferenztechnologie von Cerebras Llama 3.1 405B mehr als 10-mal schneller als geschlossene Frontier-Modelle ausführt
- Vorgestellt wird dies als geeignete Grundlage für Sprach-, Video- und Inferenzanwendungen, bei denen geringe Latenz und viele Inferenzschritte wichtig sind
1 Kommentare
Meinungen auf Hacker News
Wirklich erstaunlich schnell. Selbst eine selbst betriebene Llama 3.1 70B-Implementierung auf einem 8x-H100-Cluster kommt kaum über 100 Tokens/s; ich frage mich, wie sie das machen.
Mit üblichen Techniken wie Speculative Decoding oder FlashAttention allein dürfte man nicht einmal in die Nähe kommen; mindestens so etwas wie Multi-Node-Inferenz oder Sparse Attention scheint nötig zu sein.
Es ist auch möglich, dass ein großer Teil eher über CPU-Cache als über HBM läuft. Wer das Chipdesign verstehen will, dem empfehle ich die YouTube-Videos von TechTechPotato zu Cerebras.
https://cerebras.ai/product-chip/
Der On-Chip-Speicher ist begrenzt und vollständig SRAM; wie hoch die HBM-Bandbreite pro Wafer ist, ist nicht klar. Das ist ein völlig anderes Optimierungsproblem als der Betrieb auf einem GPU-Cluster.
Das ist tatsächlich der Hauptgrund, warum er so schnell ist. Groq erreicht aus demselben Grund seine Geschwindigkeit.
Ich bin nicht sicher, ob die Latenz hier wirklich unter gleichen Bedingungen verglichen wird. Latenz lässt sich grob in drei Teile zerlegen: Kontext-/Prompt-Durchsatz, Wartezeit in der Queue auf Hardwarezugriff und allgemeiner API-Overhead wie Netzwerk.
Nach meinem Verständnis beruhen mehrere, vielleicht alle Vergleichsdienste nicht auf reservierter Kapazität, sodass die Messwerte Queue-Zeit enthalten. Bei LLMs kann diese Zeit beträchtlich sein. Die Cerebras-Zahlen wurden dagegen wahrscheinlich mit garantiertem Hardwarezugriff erhoben, sodass praktisch keine unbegrenzt wachsende Queue-Zeit enthalten ist.
Der Durchsatz selbst ist beeindruckend, aber um diesen Durchsatz Endnutzern mit niedriger Latenz bereitzustellen, braucht man Overprovisioning, und wie sich Queues darauf auswirken, ist unklar. Außerdem frage ich mich, ob die Werte für Maschinen gelten, auf denen das Modell bereits geladen ist, oder ob bei Bedarf auch die Modell-Ladezeit einbezogen wird. Bei Fine-Tuning-Modellen müsste man ebenfalls sehen, ob sich die Latenz ändert.
Für Batch-Jobs, die eine Cerebras-Maschine zu 100 % auslasten und kontinuierlich 1.000 Tokens/s herausholen können, scheint das eindeutig vorteilhaft zu sein.
Wenn man sieht, was sich mit Modellen der aktuellen Generation plus RAG, Multi-Agenten und Code Interpreter machen lässt, liegt die Grenze inzwischen eher bei der Modelllatenz als bei der Genauigkeit.
Wenn man bei Modellen der 405B-Klasse diesen Token-Durchsatz erreicht, werden sehr viele interaktive Erlebnisse möglich.
Deshalb muss man jedes Mal in den Code oder den kürzlich deployten Code eintauchen und Korrelationen mit Betriebsmetriken betrachten. Oder ist mit diesem Regelbuch einfach ein Rollback-Verfahren gemeint?
Zur Klarstellung: Ein einzelner Cerebras-Chip nutzt einen ganzen Wafer, hat darauf aber nur 44 GB SRAM. Um ein 405B-Modell in bf16-Präzision unterzubringen, bräuchte man selbst ohne KV-Cache und Aktivierungsspeicher 19 solcher „Chips“.
Mit zunehmender Sequenzlänge steigt der Bedarf wegen des KV-Caches weiter. Wenn man nachschaut, passen etwa 60–80 H100-Chips auf einen Wafer; gemessen an den Wafer-Herstellungskosten entspricht das also ungefähr dem Einsatz von über 1.500 H100.
Wirklich beeindruckende Leistung. Ich halte es für ziemlich wahrscheinlich, dass Nvidia versuchen wird, Cerebras zu übernehmen.
Um die API auszuprobieren, muss man auf eine Warteliste. Wenn ein Unternehmen solche Behauptungen aufstellt, den Dienst aber nicht kaufbar anbietet, sollte man eine gewisse Skepsis bewahren.
Unter den AI-Chip-Startups ist Cerebras wahrscheinlich der echte Deal.
Keine Erwähnung des direkten Konkurrenten Groq?
Groq hat den Vorteil, auch zahlende Kunden unterhalb von Enterprise zu akzeptieren und nicht so stark selektiv anzubieten wie Cerebras, sondern eine breite Modellpalette bereitzustellen. Aber bei reiner Geschwindigkeit und den allergrößten Modellen ist Groq schwer vergleichbar.
[0]: https://sambanova.ai/
[1]: https://en.wikipedia.org/wiki/Kunle_Olukotun
Ich frage mich, wie viel es kostet, einen Dienst mit dieser Latenz zu betreiben. Aus Kundensicht hängen die Fixkosten je nach Preisstrategie ab, aber am Ende entscheidet der Preis darüber, wie weit sich diese Technik verbreiten kann.
Entscheidend ist, ob sie nur für Geschäftsmodelle passt, die Latenz wirklich brauchen, oder ob sie allgemein deploybar ist.
Wie viele SRAM-Hersteller gibt es? Oder muss das zwingend vollständig in den Chip integriert sein?
Wenn mit neuer Hardware solche Leistungssteigerungen möglich sind, frage ich mich, wie viel sich auch die Trainingsleistung noch durch Hardware steigern lässt.
Mehr Rechenleistung ist der offensichtlichste Weg zu höherer Geschwindigkeit, aber bei einem bestimmten Prozessknoten und einer bestimmten Datentyp-Präzision scheint man den physikalischen Grenzen schon ziemlich nahe zu sein. Ein strenger Beweis ist schwierig, aber es gibt einige Hinweise. Matrixmultiplikation, die Grundoperation von LLMs, ist im Gegensatz zu CPU-Workloads sehr einfach, sodass Teile wie Control-Flow-Logik stark minimiert sind. Der größte Teil der Energie fließt in die Matrixmultiplikation selbst, und Matrixmultiplikation ist tatsächlich leistungslimitiert[1]. Durch eine andere Präzision könnte man gewinnen, aber das ist schwierig, und schon heute nutzt man sehr niedrige Präzision wie fp8; fp8 kann nicht einmal 17 darstellen. Auch aktuelle Forschung zeigt Grenzen auf.
Die Trainingseffizienz von LLMs wird mit dem sehr strengen Maß „Model FLOPS Utilization (MFU)“ gemessen. Dabei teilt man die theoretischen FLOPS, die die Hardware liefern kann, durch die theoretischen FLOPS, die zur Implementierung der mathematischen Operationen nötig sind. Schon mit FSDP kommt man leicht auf 30 %, und 50–60 % sind weder unmöglich noch beispiellos. Ineffizienzen entstehen vor allem, weil 1) die Hardware aus verschiedenen Gründen die angegebenen FLOPS in der Praxis nicht liefert und 2) zwischen zehntausenden Maschinen Daten im Terabyte-Bereich synchronisiert werden müssen. Die theoretische Grenze liegt bei Faktor 2, aber praktisch gibt es nicht mehr viel herauszuholen.
Künftige Gewinne werden sich überwiegend auf TPUs zur Reduzierung von Nvidia-Margen, Prozessknoten-Verbesserungen, kleinere Datentypen wie bei B100 oder größere Chips zur Verringerung teurer Chip-zu-Chip-Kommunikation konzentrieren. Bei gleicher Präzision und gleichem Prozessknoten sehe ich keinen Spielraum für 10x.
[1]: https://www.thonking.ai/p/strangely-matrix-multiplications
Die Leistung würde wohl um etwa den Faktor 10 steigen, aber es wäre eine sehr teure Lösung.