Ermöglichung von Modellen mit Billionen von Parametern auf AWS EFA

Bei Perplexity verwenden wir die besten Modelle für unser Produkt, unsere APIs und unsere Forschungsteams. Große Open-Source-Mixture-of-Experts-Modelle wie Kimi-K2 stellen besondere Herausforderungen dar, da die größten Inferrenzknoten mit 8x NVIDIA H200 GPUs diese nicht effizient aufnehmen können, was Bereitstellungen über mehrere Knoten erforderlich macht. Wir präsentieren eine Reihe von Kernels für Expertenparallelität, die auf ConnectX-7 modernste Latenzzeiten erreichen und die Leistung von DeepEP übertreffen. Dieselben Kernels sind zudem die ersten, die auf dem AWS Elastic Fabric Adapter (EFA) praktikable Latenzzeiten erreichen und damit die Bereitstellung von Modellen mit Billionen von Parametern ermöglichen.

Testen Sie unsere Kernels auf GitHub und lesen Sie das vollständige Forschungspapier auf arXiv.

Einführung

Mixture-of-Experts (MoE) hat sich als Standardarchitektur für die Skalierung auf Hunderte von Milliarden oder Billionen von Parametern etabliert und bietet gleichzeitig eine vertretbare Latenz zur Inferenzzeit. MoE-Modelle ersetzen die dichte Schicht eines Transformers durch eine Reihe von Experten und eine kleine lineare Routing-Schicht, die entscheidet, mit welchem Experten ein Token multipliziert werden soll. Durch die Gruppierung der Tokens, die demselben Experten zugeordnet sind, wird das Problem spärlich und trivial parallelisierbar, da verschiedene Experten nun auf unterschiedlichen GPUs gehostet werden können, die über mehrere Knoten verteilt sind.

Im Gegensatz zu anderen Formen der Parallelität, wie Tensor-Parallelität (TP) und Daten-Parallelität (DP), die einfach mithilfe von kollektiven Kommunikationsbibliotheken wie torch.distributed und NCCL implementiert werden können, erfordert MoE-Routing eine spärliche Peer-to-Peer-Kommunikation. Ein Dispatch-Kernel muss die Menge der eingehenden Tokens aufteilen und an die Ränge senden, auf denen die Experten gehostet werden, während sein Gegenstück, der Combine-Kernel, die verarbeiteten Gegenstücke empfangen und deren gewichteten Durchschnitt berechnen muss. Diese Transfers lassen sich nicht auf Kollektive abbilden und erfordern angepasste Kernels, um eine niedrige Latenz zu erreichen.

Bei Perplexity entwickeln wir sowohl portable Inter-Node-Kernels als auch spezialisierte Intra-Node-Kernels und stellen unsere Arbeit in einem früheren Artikel über MoE-Kommunikation ausführlicher dar. Wir haben zudem in einem weiteren Blogbeitrag gezeigt, dass eine Multi-Node-Bereitstellung für große MoE-Modelle eine geringere Latenz und einen höheren Durchsatz bieten kann.

In diesem Artikel gehen wir detailliert auf die Implementierung unserer neuen Inter-Node-Kernels ein, die die Leistung unserer früheren NVSHMEM-basierten Arbeit erheblich verbessert. Neben der Präsentation von State-of-the-Art-Ergebnissen auf ConnectX-7 zeigen wir auch, dass die Kernels innerhalb unserer Inferenz-Runtime effektiv genutzt werden können, um die größten Open-Source-Modelle zu bedienen.

Inferenz über InfiniBand

Tensor-Parallelität und Experten-Parallelität können effektiv innerhalb eines einzelnen Knotens skalieren, da NVLink einen hohen Durchsatz (900 GB/s) bei Mikrosekunden-Latenz bietet. Während NVIDIA GB200- und GB300-Systeme über ausreichend Speicher verfügen, um die Gewichte und KV-Caches von Modellen mit Billionen von Parametern zu speichern, sind Bereitstellungen auf AWS-p5en-Instanzen mit bis zu 8 H200 GPUs auf 1120 GB HBM begrenzt, der sowohl für Modellgewichte als auch für KV-Caches aufgeteilt werden muss. Folglich erfordern bestimmte Modelle Inter-Node-Bereitstellungen über InfiniBand.

Obwohl InfiniBand immer noch extrem schnell ist, bietet es nur einen Durchsatz von 400 Gbit/s (50 GB/s), was die Latenz für MoE-Routing um zehn bis Hunderte von Mikrosekunden erhöht. Glücklicherweise können die zusätzlichen Latenzen durch den Einsatz von gemeinsamen Experten, Micro-Batching und das Überlappen von Berechnung und Kommunikation verborgen werden, um einen praktikablen Durchsatz zu wettbewerbsfähigen Kosten zu liefern. DeepSeek leistete Pionierarbeit bei diesen Techniken über DeepSeek-R1, das auf Clustern von H800-GPUs und NVIDIA ConnectX-7 InfiniBand-Adaptern bereitgestellt wurde.

Auf AWS-Clustern ist die Situation aufgrund der Verwendung ihrer benutzerdefinierten Elastic Fabric Adapters (EFA) anders. Obwohl diese bei den in Trainings-Workloads üblicherweise verwendeten Kollektiven einen Spitzendurchsatz von 400 Gbit/s liefern, bleiben sie bei den während des MoE-Dispatch und -Combine ausgetauschten Nachrichtengrößen leicht hinter ConnectX-7 zurück. Zudem unterstützt EFA kein GPUDirect Async, was einen CPU-Proxy-Thread erfordert, der die GPU mit der NIC verbindet, um Transfers zu initiieren. Neben der erhöhten Komplexität fügen die zusätzlichen PCIe-Transaktionen allen Transfers einen Overhead von Mikrosekunden hinzu. Frameworks wie NVSHMEM ermöglichen es Kernel-Entwicklern, geräteunabhängige Implementierungen bereitzustellen, jedoch verursachen die generischen APIs Overheads, die Bereitstellungen in Bezug auf Kosten und Latenz ineffektiv machen.

NVSHMEM-basierte pplx-Kernels

Unsere früheren Kernels abstrahierten die zugrunde liegende Transportimplementierung durch NVSHMEM. Sie stützten sich auf nvshmemx_putmem_signal_nbi_warp , um Tokens einzeln zu übertragen, wobei atomare Zähler verwendet wurden, um Peers zu synchronisieren. Während dies auf ConnectX-7-NICs mit IBGDA eine angemessene Leistung bot, war die proxybasierte ConnectX-7-IBRC-Implementierung signifikant langsamer, während die EFA-Implementierung keine Latenzzeiten unter einer Millisekunde lieferte.

Wir nutzten die Kernels als Testumgebung für die zugrunde liegende Hardware und ermittelten gleichzeitig die am besten geeignete Schnittstelle zur Bereitstellung für unsere Modelle. Wir stellten die Hypothese auf, dass die häufigen Transfers und Interaktionen zwischen den Kernels und den NICs oder den Proxy-Threads die Leistung beeinträchtigten. Zudem stützte sich unsere Implementierung auf keinerlei Garantien der Hardware außer der Zuverlässigkeit, was darauf hindeutete, dass wir die Geschwindigkeit durch die Reduzierung des Overheads von Synchronisationsprimitiven erhöhen könnten.

Nach diesen Beobachtungen entwickelten wir unsere EFA-basierten Kernels, die dieselbe Schnittstelle exponieren und die Interaktionen zwischen Geräte-Kernel und Host-Proxy im Hintergrund für maximale Leistung optimieren.

MoE All-to-All über EFA

Vergrößern

Die neuen Kernels folgen einer hybriden CPU-GPU-Architektur, bei der GPU-Kernels mit dem Modell auf dem Gerät interagieren und ein Proxy-Thread auf der Host-CPU die Interaktionen mit der NIC handhabt. Die neuen Kernels verwenden wieder den gleichen TransferEngine, den wir für KV-Cache-Transfers gebaut haben.

MoE-Routing wird von einem Dispatch-Kernel durchgeführt, der die Tokens und die pro Token zu routenden Experten vom Modell empfängt und diese über das Netzwerk an die Ränge sendet, die die Experten hosten. Nachdem die gruppierten GEMM-Kernels die Tokens mit den Expertengewichten multipliziert haben, überträgt der Combine-Kernel die Tokens an ihre Quellränge und berechnet deren gewichteten Durchschnitt, bevor sie an das Modell zurückgegeben werden.

Sowohl der Dispatch- als auch der Combine-Kernel sind in eine Sender- und eine Empfängerhälfte aufgeteilt, um Überlappungen und Micro-Batching zu erleichtern. Der Sender mischt die Tokens in Sendepuffer, damit sie über eine einzige RDMA-Schreiboperation an Peers geschrieben werden können. Nach der Ausführung des Senders kann die GPU andere Aufgaben (wie die Multiplikation gemeinsamer Experten) ausführen, während die Transfers über das Netzwerk im Hintergrund anstehen. Die Empfänger-Kernels blockieren, bis alle Transfers empfangen wurden. Im Hintergrund handhabt ein hostseitiger Worker-Thread die Transfers: Er wird von der GPU signalisiert, wenn die Sendepuffer gefüllt wurden, woraufhin er die RDMA-Schreibvorgänge auslöst. Sobald die NIC den Abschluss signalisiert, gibt sie den Empfänger frei, der die Tokens an das Modell zurückgibt.

Die Kernels sind eng mit dem Host gekoppelt und kommunizieren miteinander sowohl über den vereinheitlichten Speicher als auch über GDRCopy. CUDA Unified Memory ermöglicht es, den Gerätespeicher oder den Hostspeicher in die Adressräume beider abzubilden, wodurch die Kommunikation via PCIe transparent abgewickelt wird.

Während der vereinheitlichte Speicher für Massentransfers geeignet ist, erfolgt das Low-Latency-Polling über GDRCopy. GDRCopy verwendet GPUDirect RDMA, um bei Mikrosekunden-Latenz aus dem GPU-Speicher zu lesen und in diesen zu schreiben.

Zusätzlich zu RDMA nutzen die Kernels innerhalb eines Knotens auch NVLink zum Austausch von Tokens. Dies kann einen signifikanten Anteil des Datenverkehrs auslagern, bis zu einem Viertel für EP32 und bis zu einem Achtel für EP64, wodurch insgesamt niedrigere Latenzzeiten erreicht werden.

Sende- und Empfangspuffer

Das Design der Sendepuffer für den Dispatch-Kernel ist entscheidend, um mit dem Host-Proxy vertretbare Latenzen zu erreichen. Wenn es N Ränge gibt, die jeweils T Tokens dispatchen, von denen jeder an R Experten aus E gesendet wird, kann ein Rang im schlimmstmöglichen Fall bis zu N * T * max(R, E / N) Tokens empfangen, wenn alle an ihn gerichtet sind. Darüber hinaus kann diese Mindestgrenze nur erreicht werden, wenn die Sender ihre Schreibvorgänge zusammenhängend anordnen, da private Empfangspuffer zu viel Speicher verbrauchen würden. Damit Sender ihre Schreibvorgänge ohne Konflikte nacheinander anordnen können, muss jede Ranginstanz vollständig über die Routing-Informationen informiert sein. Folglich tauschen unsere Dispatch-Kernel zunächst die Token-Anzahlen pro Experte aus; anschließend kann jede von ihnen bestimmen, wohin ihre Schreibvorgänge gehen und welchen Offset sie von jedem Rang aus für die Token-Empfang erhält.

Der bloße Austausch von Routing-Informationen würde zu unnötig hohen Latenzzeiten führen, da jeder Rang warten müsste, bis die Schreibvorgänge eintreffen, bevor er selbst Schreibvorgänge auslöst. Stattdessen reservieren wir auf jedem Empfängerrang eine kleine Menge an privatem Speicher pro Sender und verteilen einige der Tokens zusammen mit den Schreibvorgängen der Routing-Informationen. Dies stellt eine vollständige Bandbreitenauslastung während des Großteils des Dispatch-Prozesses sicher. Nachdem die Routen ausgetauscht wurden, werden die verbleibenden Tokens über einen einzigen Schreibvorgang pro Remote-Peer übertragen. Der Austausch der Routing-Informationen und die Puffer mit fester Größe sowie die Transfers, die sie füllen, werden in der Abbildung unten veranschaulicht.

Vergrößern

Die Combine-Kernels sind wesentlich einfacher, da Routing-Informationen für sie bereits aus der Dispatch-Stufe verfügbar sind. Sie können die Tokens in einem einzigen Schreibvorgang pro Peer kopieren, wonach sie aus dem Empfangspuffer lesen, um den gewichteten Durchschnitt der Tokens in die Ausgabetensoren zu berechnen.

Für NVLink werden die Sende- und Empfangspuffer innerhalb eines Knotens in die Peers abgebildet, damit diese Tokens direkt von benachbarten Rängen übertragen oder abrufen können.

Dispatch und Combine

Die folgenden Abbildungen zeigen die zeitlichen Abläufe und die Interaktionen zwischen GPU, CPU und NIC und zeigen eine Iteration von Dispatch und Combine, die mit den Kernels des Modells verschachtelt ist.

Die Arbeit beginnt beim Dispatch-Versand, wobei der Kernel die Routing-Informationen aggregiert und die Token-Anzahlen pro Experte durch atomare Akkumulation im gemeinsam genutzten Speicher innerhalb eines einzelnen Blocks berechnet. Sobald die Token-Anzahlen verfügbar sind, werden sie in den Hostspeicher kopiert und der Proxy sofort benachrichtigt, mit der Verteilung der Routing-Informationen an alle anderen Peer-Ränge zu beginnen. Parallel dazu berechnet der Dispatch weiter die kumulative Summe der Token-Anzahlen und identifiziert die Offsets, die zum Packen der Tokens in zusammenhängende Sendepuffer pro Peer erforderlich sind. Sobald die Offsets verfügbar sind, werden alle über EFA zu sendenden Tokens in die Sendepuffer gepackt. Der Proxy wird benachrichtigt, die Schreibvorgänge in die Sendepuffer der Inter-Node-Peers zu posten. Innerhalb des Knotens pushen die Kernels die Tokens zudem sofort über NVLink in private Puffer innerhalb desselben Knotens.

Vergrößern

Vergrößern

Sobald ein Rang Routing-Informationen von allen Peers empfängt, zentralisiert er diese und berechnet verschiedene Offsets, die zur Identifizierung von Tokens für Dispatch und Combine erforderlich sind. Diese Arbeit erfolgt auf der CPU, während Transfers bereits ausstehen, ist also nicht latenzkritisch. Sobald alle Offsets bekannt sind, werden die Schreibvorgänge für die restlichen Tokens, die die Kapazität des privaten Puffers überschreiten, gepostet und die Sendephase des Dispatch ist abgeschlossen.

Auf der Empfängerseite ruft der Kernel zuerst Tokens aus demselben Knoten ab, die über die Kapazität privater Puffer hinausgehen, mittels NVLink. Als Nächstes blockiert er, bis der Host-Proxy den Abschluss aller Transfers signalisiert. Sobald das Signal empfangen wurde, werden Tokens von den Empfangspuffern in den Ausgabetensor verschoben, der an die Gruppen-GEMM übergeben wird. Da Puffer zwischen Dispatch und Combine wiederverwendet werden, stellen sowohl NVLink- als auch RDMA-Barrieren sicher, dass die Empfängerpuffer gelesen wurden, bevor der nächste Kernel diese überschreiben darf.

Die Combine-Kernels folgen einem ungefähr ähnlichen Muster: Mischen von Tokens, Signalisieren des Proxys und Warten auf den Abschluss. Da die Metadaten für das Posten ihrer Schreibvorgänge jedoch bereits verfügbar sind und alle Remote-Offsets bekannt sind, werden alle innerhalb eines Knotens übertragenen Tokens über NVLink an die Empfänger gepusht und die Inter-Node-Tokens über einen einzigen Schreibvorgang übertragen. Vor der Rückgabe der Ergebnisse akkumuliert der Kernel die Tokens aus den Empfängerpuffern und schreibt sie in die Ausgabetensoren.

TransferEngine für MoE-Routing

Um unsere Implementierung zu prototypisieren, haben wir anfangs die für das disaggregierte Prefill und Decode gebaute TransferEngine wiederverwendet, um RDMA-Schreibvorgänge auszugeben und zu verfolgen. Im Gegensatz zum disaggregierten Decodieren, bei dem jeder Knoten eine große Anzahl von Schreibvorgängen an denselben Peer postet, postet der MoE-Dispatch jedoch kleine Transfers an alle Peers in einer einzigen Operation. Die Leistung war sofort nicht optimal und unsere Implementierung lag auf ConnectX-7 um etwa 20 µs hinter DeepEP zurück. Folglich haben wir die TransferEngine darauf spezialisiert, zwei Operationen zu unterstützen: Scatter und Barrier, um die Interaktionen mit einer großen Anzahl von Peers zu optimieren.

Sowohl Scatter- als auch Barrier-Operationen exponieren Peer-Gruppen, die vorregistriert werden können, um die Datenstrukturen vorzupopulieren, die von der zugrunde liegenden Transportimplementierung (Work Request (WR) Templating) verwendet werden. Scatter kopiert verschiedene Slices aus demselben Quellpuffer an verschiedene Offsets auf allen Mitgliedern einer Peer-Gruppe. Barrier signalisiert alle Peers durch einen Immediate-Wert. Das Enqueuing und Handhaben dieser Operationen in großen Mengen spart wertvolle Mikrosekunden auf dem kritischen Pfad. Auf EFA, wo zwei 200-Gbit/s-NICs zu einer Bandbreite von 400 Gbit/s aggregieren, sharden wir Gruppen-Peers über die beiden NICs, anstatt die Bytes jedes Transfers zu sharden.

Obwohl wir die TransferEngine anfangs ausschließlich auf EFA unter Verwendung von libfabric entwickelten, funktionieren die MoE-Kernels auf ConnectX-7, ohne eine einzige Codezeile zu ändern, nachdem wir die ConnectX-7-Unterstützung in der TransferEngine unter Verwendung von libibverbs hinzugefügt haben. Im Vergleich zu EFA auf Basis von Scalable Reliable Datagram (SRD) erfordert ConnectX-7 zusätzliche Arbeit für Verbindungsaufbau und Peer-Management. Wir verwenden ein Unreliable Datagram (UD) Queue Pair zum Bootstrapping von Reliable Connection (RC). Wir erstellen zwei Queue Pairs für jeden Remote-Peer, eines für zweiseitiges SEND/RECV und eines für einseitiges WRITE_IMM, da sowohl RECV als auch WRITE_IMM die RECV-Operation in der Reihenfolge verbrauchen, während die beiden Operationen unterschiedliche Puffergrößen erfordern. Zudem lockern wir die PCIe-Transaktionsreihenfolge zwischen ConnectX-7 und GPU-Speicher. Ähnlich wie bei EFA implementieren wir die WR-Templating-Optimierung. Wenn wir zudem mehrere kleine Nachrichten an denselben Peer senden, verwenden wir WR-Chaining, um die Nachrichtenrate zu verbessern.

Da die arbeitseitige GPU-Arbeit über beide Adapter hinweg identisch ist, haben wir die zugrunde liegende Transportimplementierung an ihre Grenzen getrieben, um die Leistung von DeepEP zu übertreffen und hervorzuheben, dass die Lücke zwischen EFA- und ConnectX-7-MoE-Routing durch die Fähigkeiten der zugrunde liegenden Hardware bestimmt wird.

Bewertung

Dispatch/Combine-Latenz

Wir haben Dispatch- und Combine-Latenzzeiten auf H200-Systemen bewertet, die mit ConnectX-7- und EFA-Adaptern ausgestattet sind, in der Standardkonfiguration von DeepSeek-V3 und Kimi-K2 mit einer verborgenen Dimension von 7168, blockskaliertem fp8-Dispatch und bf16-Combine. Wir betrachten eine Batch-Größe von 128 für Dispatch und 4096 für Combine. Auf ConnectX-7 vergleichen wir mit DeepEP und unseren früheren NVSHMEM-basierten pplx-Kernels unter Verwendung von sowohl GPUDirect Async (IBGDA) als auch einem Host-Proxy (IBRC). Wir erreichen kombinierte Latenzzeiten von 459 µs, 582 µs und 692 µs bei EP16, EP32 bzw. EP64. Wir übertreffen andere EFA-basierte Kernels, die sich auf generische Proxys stützen, wie UCCL-EP, die 519 µs, 966 µs und 1159 µs erreichen.

Vergrößern

Beim Decodieren erreichen wir trotz unserer um einige Mikrosekunden langsameren Kernels als DeepEP insgesamt niedrigere Latenzzeiten, da unsere Combine-Kernels wesentlich schneller sind. Obwohl wir einen Host-Proxy verwenden, übertreffen wir aufgrund unserer Massentransfers die Leistung aller IBGDA-basierten proxylosen Implementierungen. Wir zeigen auch, dass die Proxy-Implementierung wichtig ist, da unser hochspezialisierter Proxy eine Größenordnung schneller ist als die generische NVSHMEM-Implementierung. Obwohl EFA beim Übertragen von 256-KB-Paketen, die nahe an der typischen, vom MoE-Routing ausgetauschten Paketgröße liegen, doppelt so langsam ist wie ConnectX-7, ist die Lücke zwischen den beiden Adaptern insgesamt weniger substanziell.

Vergrößern

Auch wenn unsere für das Decodieren optimierten Kernels ohne weitere Anpassungen auf Prefill-Batch-Größen skalieren können, liegt die Leistung hinter DeepEP zurück. Dies liegt primär daran, dass wir Tokens nur auf der Empfängerseite von Combine akkumulieren, während DeepEP im Sender akkumuliert, um die Menge der übertragenen Daten zu reduzieren. Diese Optimierung kann jedoch Auswirkungen auf die Genauigkeit haben. Da die Kernels zudem Daten in einem Schreibvorgang übertragen, nutzen wir mehr Speicher für Sende- und Empfangspuffer.

Durchsatz von Kimi-K2 / DeepSeek-V3

Um die Praktikabilität unserer Kernels zu beweisen, benchmarken wir die End-to-End-Leistung unserer hausinternen Inferenz-Engine beim Bedienen von DeepSeek-V3 (671 Mrd. Parameter) und Kimi-K2 (1 T-Parameter) auf mehreren p5en-Instanzen, die mit Elastic Fabric Adapters (EFA) und H200-GPUs ausgestattet sind. Wir führen das Modell im Draft-Verification-Modus aus und berichten die Latenz unter Annahme einer Akzeptanzrate von 80 % unter Verwendung einer einzelnen MTP-Schicht.

Bei DeepSeek-V3 vergleichen wir mit einer EP=8 Intranode-Baseline, die effiziente, reine NVLink-Dispatch- und Combine-Kernels ausführt. Inter-Node-Bereitstellungen erreichen oder übertreffen insgesamt die Leistung der Single-Node-Bereitstellung, insbesondere bei mittelgroßen Batches, was zeigt, dass eine Skalierung über Knoten hinweg tatsächlich Verbesserungen des Gesamtdurchsatzes bringt.

Auf Kimi-K2 ermöglichen die Kernels das Bedienen. Aufgrund seiner Größe passt das Modell nicht in denselben Knoten unter Verwendung von Data-Parallelism (DP) auf einem H200-Knoten, daher ist eine Inter-Node-Bereitstellung erforderlich, um das Modell zu bedienen. Da das Modell über weniger Aufmerksamkeits-Heads verfügt, erreichen wir bessere Latenzzeiten als bei DeepSeek-V3 und können das Modell auf EFA mit einer praktikablen Latenz bedienen.

Vergrößern

Vergrößern

Wir haben auch Micro-Batching in Betracht gezogen, obwohl es die Latenzzeiten nur bei sehr hohen Batch-Größen oder bei Verwendung von mehr als einem Draft-Token verbesserte. Um vom Aufteilen gruppierter GEMM-Probleme in zwei zu profitieren, müssen Token-Batch-Größen ausreichend dicht sein. Der Großteil der Zeit wird immer noch für MoE-Dispatch und -Combine aufgewendet, was darauf hindeutet, dass jegliche weiteren Verbesserungen an den Kernels folglich die Latenzzeiten verbessern und Micro-Batching erleichtern werden.

Zukünftige Arbeit

Wir arbeiten eng mit AWS-Ingenieuren zusammen, um die Leistung auf EFA zu verbessern. Unsererseits werden wir Updates für libfabric verfolgen, die den Overhead der Datenebene reduzieren werden. Zudem werden wir mit efa-direct experimentieren, um den Userspace-Overhead weiter zu reduzieren und direkt mit der Hardware zu interagieren.

Referenzen

Technischer Bericht zu DeepSeek R1

Technischer Bericht zu Kimi K2

DeepEP

UCCL-EP

Verbesserung der Netzwerkleistung von HPC-Systemen mittels NVIDIA Magnum IO NVSHMEM und GPUDirect Async

Zitieren

@online{perplexity2025EnablingTrillionParameterModelsOnAwsEfa,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Vladimir Zaytsev and Lequn Chen},
  title = {{Enabling trillion-parameter models on AWS EFA}},
  date = {2025-11-04},
  url = {https://www.perplexity.ai/hub/blog/enabling-trillion-parameter-models-on-aws-efa}
}