Die effiziente Grenze der LLM-Inferenz: Techniken, die Kompromisse eingehen, und solche, die die Grenze verschieben
The efficient frontier of LLM inference
In der KI-Branche wird der Begriff 'effiziente Grenze' verwendet, um Kompromisse zu beschreiben, insbesondere zwischen Kosten und Fähigkeiten von Modellen. In der Inferenztechnik geht es oft um den Trade-off zwischen Latenz und Durchsatz. Es gibt zwei Arten von Techniken: solche, die einen Trade-off eingehen, um einen Punkt auf der Grenze zu erreichen (z.B. Batch-Größe, Parallelisierungsstrategien, Quantisierung), und solche, die die gesamte Grenze verschieben (z.B. Kernel-Optimierung, spekulative Dekodierung, P/D-Disaggregation). Der Artikel erläutert, wie diese Techniken funktionieren und wie sie kombiniert werden können, um die Effizienz zu steigern.
Die effiziente Grenze ist in der Praxis sehr zerklüftet: Kleine Änderungen können große Auswirkungen haben, und diese Wendepunkte sind oft unintuitiv und müssen empirisch durch Sweeps entdeckt werden.
- kgeist
Ich versuche gerade, eine Inferenz-Engine zu schreiben, die die Vorteile von llama.cpp (ein einziges Binary für die Bereitstellung, gute Unterstützung für heterogene Nicht-Rechenzentrums-Hardware, breite Quantisierungsunterstützung) mit den Vorteilen von vLLM/SGLang (Dinge wie echtes Paged Attention für bessere VRAM-Auslastung und hohe Parallelität) kombiniert.
Rechenzentrums-Hardware ist teuer und knapp, aber llama.cpp ist langsam/unoptimiert für den gleichzeitigen Einsatz, während vLLM/SGLang bei ungewöhnlichen Setups leicht abstürzen (z.B. wenn man Pipeline-Parallelität für RTX5090+RTX4090 macht, stürzen sie zufällig mit aktiviertem RAM-Caching ab oder wählen falsche Kernel, weil sie normalerweise davon ausgehen, dass jeder Rang denselben Gerätetyp hat; sie unterstützen auch kein Q5-Q6).
Für mich ist am interessantesten, die Inferenz für den Mangel an guter Rechenzentrums-Hardware zu optimieren und wie man sie am besten optimiert. Ich habe einen KI-Server im Büro betrieben, und bisher habe ich diese Techniken als am wichtigsten für den gleichzeitigen Einsatz auf billiger Hardware empfunden: Pipeline-Parallelität (um PCIe zu berücksichtigen), RAM-Caching (um Kontexte schnell in VRAM wiederherzustellen), spekulative Dekodierung (einschließlich domänenspezifischer N-Gramme, die die Codegenerierung bereits ohne den Overhead eines Draft-Modells erheblich beschleunigen können), gute, für ein bestimmtes Gerät hochoptimierte Kernel, Unterstützung für Q5-Q6 (fast so gut wie Q8), FP8-Kontexte (mehr Kontext passt), Paged Attention (für bessere VRAM-Auslastung), Präfix-Caching, kontinuierliches Batching (das ist überall Standard).
Bisher sind die wichtigsten […]
- jumploops
> Spekulative Dekodierung ist der Prozess des Erratens, welche Token ein Modell erzeugen könnte, und dann der Validierung dieser Vermutungen.
Als Computeringenieur ist es immer interessant zu sehen, wie Optimierungen auf verschiedenen Ebenen des Stacks angewendet werden.
Spekulative Ausführung wurde in den 90ern ziemlich populär und wurde schließlich in praktisch jedem x86-Design verwendet.
Dann brachte das Speculator-Papier [0] Mitte der 2000er dieses Konzept in verteilte Systeme, woran wir immer noch arbeiten sehen [1][2].
Alles Alte ist wieder neu (:
[0]https://www.cs.princeton.edu/courses/archive/fall07/cos518/p...
[1]https://www.usenix.org/system/files/osdi25-shen-weihai.pdf
[2] https://www.microsoft.com/en-us/research/publication/distrib...
- amelius
Woher weiß man sicher, dass man auf einer effizienten Grenze bleibt, wenn man einen Parameter ändert?
Ich denke, diese Präsentation sagt mehr darüber aus, welche Stellschrauben man drehen kann und in welche Richtung sich das Ergebnis bewegen wird (es könnte schlechter sein als bei einem Konkurrenten), als dass sie etwas über Grenzen aussagt.
- armcat
Ich denke, wir können bald die „rekursive Tiefen"-Strategie einbeziehen, die Astra einsetzt und die (wie ich vermute) rekursive interne Zustandsänderungen im Transformer nutzt, anstatt des traditionellen vollständigen Forward-Passes plus Sampling, wie es bisher beim Denken/CoT der Fall war. Eine ähnliche Methode wurde hier verwendet (aber in anderem Kontext – Kodierung von Werkzeugen in den Transformer-Gewichten für schnelle Ausführung): https://www.percepta.ai/blog/can-llms-be-computers
- copperwire
Quantisierung und spekulative Dekodierung haben für unsere kleineren Modelle erhebliche Einsparungen ermöglicht. Wir jagen immer noch diesem idealen Kosten-Leistungs-Verhältnis hinterher.