Neues aus der Inference-Engineering-Praxis — Philip Kiely, Baseten

AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00Ich bin hier, um darüber zu sprechen, was es Neues im Bereich Inference Engineering gibt. Hallo, ich bin Philip und ich bin hier, weil
00:00:19ich ein Buch geschrieben habe. Ich bin das dritte Jahr in Folge auf der AI Engineer World's Fair. Das ist meine absolute
00:00:24Lieblingskonferenz auf der ganzen Welt. Sie ist jedes Jahr das Highlight in meinem Kalender. Meine Anfänge
00:00:29als Redner und Ingenieur hatte ich genau hier im Jahr 2024. 2025 bin ich zurückgekommen und habe eine Menge gemacht.
00:00:36Jetzt bin ich wieder hier. Ich liebe es einfach und bin den Organisatoren sehr dankbar, dass sie mich immer wieder einladen. Ich habe dieses
00:00:44Buch namens "Inference Engineering" geschrieben. Wir haben es vor drei oder vier Monaten veröffentlicht und ich bin einfach
00:00:49überwältigt von der Resonanz. Wir haben seit dem Erscheinen am 23. Februar bereits enorm viel erreicht.
00:00:57Wir haben über 11.000 gedruckte Exemplare verkauft, nähern uns den 30.000 digitalen Ausgaben und haben 24 Millionen
00:01:04Menschen weltweit beziehungsweise 24 Millionen Twitter-Accounts erreicht – wir werden sehen, wie viele Personen das am Ende tatsächlich
00:01:09sind –, die etwas über Inference Engineering gesehen haben. Und bei all diesem großartigen Feedback gab es
00:01:17eine Frage, die mir die Leute immer wieder gestellt haben: Warum um alles in der Welt machst du so etwas? Warum schreibt man
00:01:23ein Buch über ein Thema, das sich so rasend schnell verändert? Nun, ich glaube, dass viele
00:01:29Prinzipien des Inference Engineering mittlerweile recht gefestigt sind und es vieles gibt, das wir
00:01:34über Modellgenerationen hinweg lernen und wiederholen können. Aber heute bin ich hier, um darüber zu sprechen,
00:01:42was es Neues im Inference Engineering gibt. Das ist der erste öffentliche Nachtrag mit allen neuen Erkenntnissen seit dem Erscheinen des Buches.
00:01:48Wir werden die Prinzipien des Inference Engineering kurz wiederholen und dann über all die Dinge sprechen,
00:01:54die seit dem 23. Februar 2026 in der Welt der Inferenz passiert sind. Wir sprechen darüber,
00:02:00was mit TurboQuant passiert ist, gehen kurz auf KV-Kompaktierung ein und widmen viel
00:02:05Zeit d-Flash sowie anderen spannenden Entwicklungen beim Spekulativem Dekodieren. Und zum Schluss werde ich
00:02:12ein wenig Prognostik betreiben und einen Ausblick darauf geben, was meines Erachtens im Bereich
00:02:17der Inferenz ansteht und worauf ich mich schon freue – worüber ich hoffentlich beim nächsten Mal sprechen kann,
00:02:23wenn ihr mich hier oben seht. Super, legen wir also los! Eine Sache, die ich mittlerweile
00:02:30aus zahllosen Gesprächen über Inferenz herausgearbeitet habe, sind einige gemeinsame Grundprinzipien. Und eines
00:02:38der wesentlichen – ich war neulich in diesem Podcast mit Sarah, wo wir über Inferenz gesprochen haben –,
00:02:44ist, dass sich im Grunde zwei Arten von Inference Engineering herausgebildet haben: Da ist zum einen die lokale Inferenz,
00:02:48bei der die vorherrschende Strategie schlicht lautet: Hauptsache, es läuft irgendwie auf der vorhandenen Hardware, indem man
00:02:56das Modell durch Quantisierung, Destillation oder Pruning schrumpft, wie auch immer man kann, und es auf die
00:03:02GPUs aufteilt, die man gerade zu Hause hat. Zuerst sorgt man dafür, dass es läuft, und dann macht man es weniger dumm – man behebt
00:03:09die katastrophalen Einbußen, die durch die ganze Modellkompression entstanden sind, und versucht,
00:03:15wieder auf die ursprüngliche Basis-Intelligenz bei einer Batch-Größe von 1 zu kommen. Und dann gibt es meine
00:03:20Welt: die Welt der Batch-Größen und Rechenzentren. Hier heißt die Devise: Am ersten Tag wird der
00:03:27vLLM-Build aufgesetzt, um es zum Laufen zu bringen, und danach macht man es weniger langsam. Man nutzt Dinge wie KV-aware Routing, Spekulation
00:03:33oder Disaggregation. Ich glaube, dass diese beiden Welten extrem viel voneinander lernen können.
00:03:40In diesem Vortrag werde ich mich auf Fortschritte im rechenzentrumsorientierten Inference Engineering konzentrieren,
00:03:46weil das mein Fachgebiet ist. Aber auch in der Welt der lokalen Inferenz passieren unglaublich coole Dinge.
00:03:52In meinem Buch bin ich im Allgemeinen davon ausgegangen, dass die Gewichte ein fertiges Produkt sind, und ich
00:03:58halte die Übergabe vom Training zur Inferenz weiterhin für einen wichtigen Aspekt, der den
00:04:03Rahmen gut abgrenzt. In letzter Zeit stelle ich jedoch immer häufiger fest, dass viele
00:04:10Inferenz-Optimierungen aus einem dedizierten Trainingsprozess hervorgehen. Die Grenzen zwischen Training
00:04:17und Inferenz verschwimmen also immer mehr, was eine sehr interessante Entwicklung ist.
00:04:22Wir beobachten einen Kreislauf: Eine schnellere Inferenz liefert mehr Daten, mit denen man ein
00:04:28besseres Modell trainiert, was wiederum zu schnellerer Inferenz und noch mehr Daten führt. Und diesen Kreislauf
00:04:33setzt man einfach fort, bis man reich ist. Beim Thema "Training für die Inferenz" gibt es eine Reihe
00:04:39neuer Techniken bei den – wie ich sie gerne nenne – "Großen Drei". Wir sprechen heute über
00:04:45Neuerungen bei der Quantisierung, beim Caching – speziell dem KV-Cache-Mechanismus – und
00:04:52beim spekulativen Dekodieren. Es gibt zwar viele andere Themen in der Inferenzwelt,
00:04:57auf die ich am Ende noch eingehen werde, aber wenn es um die tägliche Praxis geht – also die Frage,
00:05:02wie man ein bestimmtes Modell schneller macht –, greift man meist zu genau diesen drei Methoden.
00:05:09Gut, die Ausgangslage: Ich veröffentliche mein Buch im Februar und fühle mich großartig. Ich denke:
00:05:16"Wahnsinn, alles, was man über Inferenz wissen muss, auf einen Blick!" Und dann gab es Neuigkeiten in der
00:05:23Welt der Quantisierung. Zur kurzen Wiederholung: Quantisierung bedeutet, dass wir ein kleineres, weniger präzises Zahlenformat nutzen,
00:05:32um Bandbreite und Rechenleistung zu sparen, TTFT und TPS zu verbessern. Es ist meist
00:05:39hardwarespezifisch, bringt Kosteneinsparungen, kann aber die Modellqualität leicht beeinträchtigen.
00:05:45Wer übrigens meine ausführliche Meinung zur Quantisierung hören möchte: Ich habe letzten Monat auf der AI Engineer
00:05:51in Miami einen Vortrag darüber gehalten, dass Quantisierung gar nicht so schlecht ist, wie es klingt, und dass
00:05:57man viele Möglichkeiten hat, die Qualität dabei zu erhalten. Ich war also stolz auf mein Kapitel über Quantisierung,
00:06:04und dann sahen 20 Millionen Menschen TurboQuant. Es hat sogar den Speicheraktien-Markt kurzzeitig
00:06:12einbrechen lassen, weil alle dachten: "Speicher wird jetzt so viel effizienter,
00:06:16wir brauchen gar keinen Flash-Speicher mehr!" Was natürlich falsch war, aber es war eben dieser neue
00:06:23Quantisierungsansatz, der im März dieses Jahres bekannt wurde. Er nutzt Polarkoordinaten für die
00:06:29Quantisierung und ermöglicht es, den KV-Cache auf 4 Bit zu reduzieren. Es war der absolute Hype, und ich dachte mir:
00:06:36"Mensch, da habe ich was Wichtiges ausgelassen. Wie wird sich das jetzt entwickeln?"
00:06:43Unser Team hat das gründlich untersucht – Grüße gehen raus an den Waterloo-Intern
00:06:50auf Twitter, Ali aus unserem Modell-Performance-Team; ich weiß gar nicht, ob er noch Praktikant ist,
00:06:57aber er kommt jedenfalls von der Uni Waterloo. Er hat einen hervorragenden Beitrag über die Mathematik hinter TurboQuant verfasst.
00:07:04Der Vorteil von TurboQuant liegt darin, dass man den KV-Cache mit 4 statt 8 Bit darstellen kann.
00:07:09Das spart die Hälfte an Speicherplatz sowie Bandbreite und verdoppelt effektiv die Geschwindigkeit,
00:07:14mit der der KV-Cache im Arbeitsspeicher bewegt wird. Allerdings ist der Nachteil beträchtlich:
00:07:21Bei TurboQuant muss während des Vorwärtsdurchlaufs beim Dekodieren zusätzliche Rechenleistung aufgewendet werden,
00:07:25was die TPS um mehr als die Hälfte reduziert. Das ist für viele Produktionsanwendungen ein inakzeptabler Kompromiss.
00:07:32Wir haben uns TurboQuant also genau angesehen, nutzen es aber für echte Workloads nicht.
00:07:38Stattdessen setzen wir weiterhin auf die herkömmliche NVFP4-Quantisierung. Nichtsdestotrotz
00:07:44ist es eine großartige Methode für den Bereich der lokalen Inferenz. Wenn man ein Modell –
00:07:51insbesondere ein Sprachmodell mit langem Kontext – auf dem eigenen Rechner oder auf GPUs im Keller ausführt,
00:07:58steht nur sehr wenig Speicher zur Verfügung, was den Hauptflaschenhals darstellt. Alles, was Arbeitsspeicher
00:08:04beim KV-Cache einspart und es erlaubt, längere Sequenzen zu verarbeiten, ist dort extrem wertvoll,
00:08:09während der zusätzliche Rechenaufwand weniger ins Gewicht fällt. TurboQuant bleibt
00:08:16eine fantastische wissenschaftliche Arbeit und eine tolle Technik, die sich für Inferenz in Rechenzentren
00:08:22nur eben als weniger anwendbar erwies, als es zunächst schien. Wir konzentrieren uns stattdessen
00:08:28auf NVFP4 mit dem Schwerpunkt auf der Quantisierung der Gewichte statt des KV-Caches. Wir versuchen,
00:08:36Schwachstellen in den quantisierten Gewichten zu finden und sicherzustellen, dass Wahrscheinlichkeitsverteilungen
00:08:41nicht verflacht werden. Beim KV-Cache selbst fokussieren wir uns auf KV-aware Routing, Offloading und Sharing.
00:08:49Wir nutzen Werkzeuge wie NCCL oder NVIDIA Dynamo, um den KV-Cache im System
00:08:55zu verschieben und gegebenenfalls auf den regulären CPU-Speicher auszulagern, statt ihn mit TurboQuant
00:09:04zu komprimieren. Zudem arbeiten wir an der modalitätsübergreifenden Quantisierung und überlegen,
00:09:11wie wir die Vorteile von NVFP4 nicht nur auf Sprachmodelle, sondern auch auf Bild- und Videomodelle
00:09:17übertragen können. Ali hat dazu ebenfalls hervorragende Beiträge auf Twitter veröffentlicht, die ihr euch ansehen solltet.
00:09:23Trotz alledem bleibt der KV-Cache enorm wichtig. Sprechen wir also über KV-Kompaktierung.
00:09:29Kurze Wiederholung: Wenn man denselben Prompt mit demselben Präfix eingibt, kann man die Tokens wiederverwenden,
00:09:35die beim letzten Mal in der Pre-Fill-Phase berechnet wurden. Das macht das gesamte System schneller und effizienter.
00:09:42Allgemein betrachtet ist der KV-Cache verlustfreier Speicher. In Inferenzsystemen gibt es nur wenige
00:09:48Quellen für verlustfreien Speicher: den Inhalt des Prompts, den Kontext und eben den KV-Cache.
00:09:55Dieser skaliert linear mit der Menge der eingegebenen Daten. Und wenn man an Sequenzlängen
00:09:59von einer Million Tokens denkt, wird das extrem umfangreich. Viele machen sich daher Gedanken darüber,
00:10:05wie man Speicher und Kontext komprimiert. Agenten-Systeme reduzieren den Kontext, RAG-Suchen
00:10:11und all diese seit Jahren genutzten Techniken sind im Grunde eine Form der Komprimierung eines
00:10:17größeren Kontextes auf ein Maß, das dem Modell übergeben oder in Dateien geschrieben werden kann.
00:10:22All diese Methoden skalieren sublinear zur Datenmenge. Was aber, wenn es einen Mittelweg gäbe?
00:10:28Eine Möglichkeit, die gespeicherten Daten stark zu komprimieren und dabei nahezu alle Informationen zu behalten?
00:10:34Es gibt verschiedene Ansätze für die Entscheidung, was im Cache verbleiben soll. Neue
00:10:41Kompaktierungsmethoden zeigen, dass wir den Cache durch einen viel kürzeren ersetzen können.
00:10:47kürzeren ersetzen können. Es gibt Arbeiten wie Attention Matching und Cartridges, die wirklich vielversprechende Ergebnisse
00:10:53mit hohen Kompressionsraten geliefert haben. Aber beide laufen zur Inferenzzeit. Eine der Techniken,
00:11:00über die ich sprechen möchte – oder eines der Themen –, ist das Training für die Inferenz. In diesem Fall
00:11:05möchte ich etwas namens STILL vom Base10-Forschungsteam vorstellen, bei dem die Synthese auf dem Cache,
00:11:12wo wir eine gelernte Repräsentation der Informationen behalten anstatt der Informationen selbst
00:11:17oder einer deterministischen Teilmenge davon, durch Training amortisiert wird. Charlie und Mudith aus
00:11:25unserem Post-Training-Team haben vor Kurzem bei CoSA Compile einen fantastischen Chalk Talk gehalten. Er ist auf YouTube verfügbar,
00:11:31und ich empfehle Ihnen dringend, ihn sich anzusehen, wenn Sie mehr über KV-Kompaktierung erfahren möchten. Ich habe
00:11:37leider weder die Zeit noch das Genie, das hier oben alles im Detail zu erklären, aber der grundlegende Mechanismus
00:11:46ist, dass STILL ein Perceiver-Bottleneck ist, das eine feste Menge gelernter Query-Vektoren nimmt,
00:11:53sie mit dem gesamten KV-Cache mittels Cross-Attention verknüpft und eine Menge kompakter Keys und Values
00:11:59in einem einzigen Forward-Pass erzeugt. Das schafft einen schnellen, differenzierbaren, komprimierten Speicher,
00:12:05auf den das LLM wie auf echten Kontext zugreifen kann. Wenn Sie sich für KV-Kompaktierung interessieren,
00:12:09schauen Sie sich unbedingt die Arbeit von Charlie und Mudith an. Es war wirklich fantastisch, das zu lernen.
00:12:16Das waren zwei der Techniken: Wir haben über Quantisierung gesprochen, wir haben über Caching gesprochen. Die letzte
00:12:21ist Spekulation, und hier gab es viele Veränderungen. Zur Erinnerung: Bei der spekulativen Dekodierung
00:12:29nutzen wir Entwurfstokens, verifizieren sie während des Forward-Passes und erzeugen so
00:12:34mehr als ein Token pro Forward-Pass. Das hilft enorm bei den Tokens pro Sekunde und ist eine völlig verlustfreie
00:12:40Optimierung, was großartig ist, da wir uns keinerlei Sorgen um die Qualität machen müssen. In der Geschichte
00:12:46der Spekulation haben wir mit der spekulativen Dekodierung begonnen – all diese stehen im Buch. Man hat SpecDec,
00:12:52wo man ein kleines Modell aus derselben Familie nutzt, um Entwurfstokens zu erzeugen. Es stellte sich heraus, dass kleine Modelle
00:12:58nicht besonders gut darin sind; sie sind großartig als kleine Modelle. Also haben wir als Branche eine Reihe neuer Methoden erfunden,
00:13:04wie Medusa, wo man dem Modell einfach Dekodierköpfe hinzufügt, und schließlich EAGLE-3,
00:13:09wo die Idee war: Was wäre, wenn wir statt eines winzigen Modells aus derselben Familie ein Modell mit einer Milliarde Parametern
00:13:15auf den verborgenen Zuständen des Zielmodells trainieren, um Entwurfstokens zu erzeugen? Das hat tatsächlich sehr gut funktioniert,
00:13:21und so war EAGLE-3 bis etwa Februar letzten oder dieses Jahres die beste Methode
00:13:27in der Spekulation. Jetzt haben wir dFlash. dFlash ist noch besser: Es ist Diffusion für Spekulation. dFlash erzeugt
00:13:36eine Sequenz von Entwurfstokens statt eines einzelnen Tokens. Das Modell ist also ein Diffusions-Sprachmodell,
00:13:43was bedeutet, dass es eine ganze Sequenz von Tokens erzeugt – ähnlich wie bei einer Video- oder Bildgenerierung,
00:13:49die eine Sequenz von Einzelbildern oder Pixeln erstellt und darüber iteriert, anstatt eine autoregressive
00:13:55Token-Generierung durchzuführen. dFlash-Modelle laufen zwar zwei- bis viermal langsamer, aber sie sagen 8
00:14:01oder 16 Tokens auf einmal in diesem Fenster voraus, während EAGLE nur eines nach dem anderen generiert. Ein einzelner
00:14:08dFlash-Forward-Pass ist schneller als die gesamte EAGLE-Entwurfsphase und sagt mehr Tokens voraus. Diese Tokens können
00:14:14mittels Cross-Attention aufeinander zugreifen und erzeugen generell eine höhere Akzeptanzrate, denn bei der Spekulation
00:14:21ist die Akzeptanzrate alles. In der Praxis sehen wir mit dFlash eine mehr als dreifache Verbesserung. Gemessen wurde dies
00:14:30mit einer einzelnen B200 und Qwen3-8B, und im Vergleich zu EAGLE sieht man eine erhebliche Verbesserung bei den Tokens – sowohl
00:14:40bei der Akzeptanzrate als auch bei den Tokens pro Sekunde. Diese dFlash-Modelle werden mit einer Attention-Maske für
00:14:47bidirektionales Entwerfen trainiert. Das Zielmodell liefert also den Kontext, und innerhalb jedes Blocks
00:14:54haben wir eine Teilmenge sauberer Tokens, die gesampelt werden, und die Attention-Maske erzwingt
00:14:59kausale Konsistenz. Sie erlaubt dennoch bidirektionale Attention, wo man in einem
00:15:06traditionellen autoregressiven Modell die Tokens nur in eine Richtung betrachtet. Deshalb können wir uns
00:15:13diese diffusionsbasierte Architektur zunutze machen. Und als ich dachte, ich wäre
00:15:19fertig, kam vor ein paar Tagen dSpark heraus. dFlash haben wir bereits in der Produktion im Einsatz,
00:15:25dSpark ist noch neue Forschung. Dazu kann ich im Grunde nur sagen: Hey, es existiert, es ist cool, wir
00:15:31schauen es uns an. Der Unterschied zu dFlash ist, dass es zwar immer noch dieses Diffusionsmodell nutzt, es aber zusätzlich
00:15:38mit einem sequenziellen Modell kombiniert. Die Idee ist, die Akzeptanzraten zu verbessern, indem diese beiden
00:15:45Modelle zusammenarbeiten, anstatt nur den iterativen Spekulator, nur den Diffusions-Spekulator
00:15:51oder nur den autoregressiven Spekulator zu haben. dSpark ist also sehr spannend, aber wir haben noch keine
00:15:57Produktionsergebnisse dazu, die wir teilen könnten. Hoffentlich haben wir die beim nächsten Mal.
00:16:03Wozu wir allerdings Produktionsergebnisse haben, ist das kontinuierliche Retraining des Spekulators. Hier sind wir
00:16:09wieder bei dFlash. Es geht um den Ansatz, dass die spekulative Dekodierung stark vom
00:16:15tatsächlichen Inhalt der Prompts und Antworten abhängt, die in Ihrem System verarbeitet werden. Wenn Sie also
00:16:21kontinuierlich auf diesen Prompts und Antworten in Ihrem Live-System nachtrainieren, können Sie eine Verbesserung der Token-Akzeptanzraten
00:16:29um 20 % oder sogar um das Zweifache feststellen. Das ist tatsächlich extrem schwer umzusetzen, erfordert viel
00:16:36Speicherplatz, und Sie müssen sicherstellen, dass Sie die Erlaubnis haben, die Daten auf diese Weise zu nutzen.
00:16:40Es erfordert eine enorme Rechenleistung, und Sie müssen all diese Informationen hin- und herbewegen. Wenn Sie
00:16:46das zugrunde liegende Modell ändern, müssen Sie auch das Spekulator-Modell anpassen. Aber wenn ich in die Zukunft
00:16:51blicke, glaube ich fest daran, dass kontinuierliche Spekulation für sehr große Systeme eine lohnende
00:16:58Optimierung sein wird. Was kommt also als Nächstes bei der Inferenz? Das Folgende ist meine persönliche Meinung, Spekulation
00:17:06und öffentliche Information. Wenn ich etwas wüsste, das tatsächlich demnächst erscheint, dürfte ich nicht darüber
00:17:11sprechen. Das ist also nur meine Einschätzung der Dinge. Ich habe bereits
00:17:17drei Hardware-Zyklen miterlebt: den Ampere-Release, den Hopper-Release und den Blackwell-Release. Es dauert immer
00:17:23seine Zeit von der Auslieferung dieser Chips über die Installation in den Rechenzentren bis hin dazu,
00:17:30dass der gesamte Software-Stack ihre Fähigkeiten wirklich ausnutzen kann. Einige Dinge, auf die ich mich
00:17:36freue: Bei Rubin sieht es so aus, als würde die NVFP4-Leistung fantastisch werden.
00:17:44Je mehr wir also Techniken von der lokalen Inferenz übernehmen und Erfahrung beim Ausführen
00:17:49von Modellen in diesem NVFP4-Datenformat sammeln, desto besser werden wir die großartige
00:17:54Leistung der kommenden Rubin-Systeme nutzen können. Ich denke, dass Disaggregation und systemweite
00:18:00Kommunikation immer wichtiger werden. Wir sehen bereits hervorragende erste Erfolge durch PD-Disaggregation,
00:18:05und die Fähigkeit, Informationen wie KV-Cache-Daten im System zu bewegen, wird
00:18:12immer entscheidender werden. Und wie gesagt, das Thema Training für die Inferenz wird
00:18:17auch in Zukunft einen großen Einfluss auf die Branche haben. Vielen Dank an Sie alle
00:18:25für Ihr Kommen. Ich bin auf Twitter und LinkedIn zu finden und verteile kostenlose Bücher.
00:18:32Sie können sich über den QR-Code ein PDF herunterladen oder mit mir zum Base10-Stand kommen, um sich Ihr kostenloses Exemplar von
00:18:37Inference Engineering zu holen. Wir haben eine Menge dort – vielleicht genug für alle, und wenn nicht, lassen wir
00:18:43noch welche aus dem Büro nachholen. Ich bin also unten am Base10-Stand. Vielen Dank an alle
00:18:48und einen schönen Tag!

핵심 요약

Inference Engineering im Rechenzentrum verlagert den Schwerpunkt von rein nachträglicher Hardware-Anpassung hin zu dedizierten Trainingsmethoden für die Inferenz wie dFlash-Diffusionsspekulation, STILL-KV-Kompaktierung und NVFP4-Quantisierung.

하이라이트

  • Das Buch “Inference Engineering” erreichte seit dem Erscheinen am 23. Februar 2026 über 11.000 gedruckte Verkäufe, knapp 30.000 digitale Ausgaben und 24 Millionen Twitter-Accounts.

  • Lokale Inferenz schrumpft Modelle für gegebene Hardware und zielt auf Batch-Größe 1 ab, während Inferenz in Rechenzentren vLLM nutzt und Geschwindigkeiten über KV-aware Routing, Spekulation und Disaggregation optimiert.

  • Das 4-Bit-Quantisierungsverfahren TurboQuant halbiert den Speicherbedarf des KV-Caches, reduziert jedoch die Verarbeitungsgeschwindigkeit (TPS) im Vorwärtsdurchlauf um mehr als die Hälfte.

  • Die KV-Kompaktierungsmethode STILL nutzt ein Perceiver-Bottleneck, um mit gelernten Query-Vektoren über Cross-Attention einen komprimierten Speicher in einem einzigen Forward-Pass zu erzeugen.

  • Das Diffusions-Modell dFlash sagt 8 bis 16 Tokens gleichzeitig voraus und erzielt auf einer B200-GPU mit Qwen3-8B eine mehr als dreifache Leistungssteigerung gegenüber EAGLE-3.

  • Kontinuierliches Nachtrainieren des Spekulations-Modells auf Produktionsdaten steigert die Token-Akzeptanzrate um 20 % bis 100 %.

타임라인

Entwicklung und Kennzahlen des Inference Engineering

  • Das Fachbuch zum Thema Inference Engineering verzeichnete innerhalb von vier Monaten über 41.000 verkaufte Exemplare über gedruckte und digitale Kanäle.
  • Der Bereich Inferenz gliedert sich prinzipiell in ressourcenbeschränkte lokale Ausführung und skalierte Rechenzentrums-Systeme.
  • Grundlegende Prinzipien der Inferenz bleiben über verschiedene Modellgenerationen hinweg stabil.

Die Veröffentlichung des Buches am 23. Februar 2026 erreichte Millionen von Social-Media-Accounts und bestätigte das hohe Interesse an der systematischen Optimierung von Sprachmodellen. Während die lokale Inferenz darauf abzielt, komprimierte Modelle auf vorhandener Hardware mit einer Batch-Größe von 1 zum Laufen zu bringen, fokussiert sich die Inferenz in Rechenzentren auf die Reduzierung von Latenzen bei großen Batch-Größen. Neue Erkenntnisse seit Februar 2026 ergänzen das theoretische Fundament um praxisnahe Ansätze zur Leistungssteigerung.

Anwendungsbereiche und Grenzen von TurboQuant und NVFP4

  • TurboQuant reduziert den KV-Cache mithilfe von Polarkoordinaten auf 4 Bit und halbiert den Speicherbedarf.
  • Der zusätzliche Rechenaufwand von TurboQuant halbiert die Ausgabegeschwindigkeit (TPS) im Vorwärtsdurchlauf.
  • In Rechenzentren bleibt die NVFP4-Quantisierung der Gewichte in Kombination mit KV-aware Routing der bevorzugte Standard.

TurboQuant löste kurzzeitig Spekulationen am Speichermarkt aus, da die Reduzierung des KV-Caches auf 4 Bit massive Einsparungen beim Arbeitsspeicher ermöglicht. Die Auswertung zeigt jedoch, dass die verringerte Token-Generierungsrate pro Sekunde den Einsatz in Rechenzentren unrentabel macht. Für lokale Systeme mit strikten Speichergrenzen bietet TurboQuant Vorteile. Im Rechenzentrum liegt der Schwerpunkt stattdessen auf NVFP4-Gewichtsquantisierung sowie der dynamischen Auslagerung des KV-Caches auf CPU-Speicher via NCCL oder NVIDIA Dynamo.

Differenzierbare KV-Cache-Kompaktierung durch STILL

  • Der KV-Cache skaliert als verlustfreier Speicher linear mit der Eingabesequenz und wird bei langen Kontexten zum Engpass.
  • STILL komprimiert den KV-Cache mithilfe gelernten Wissens direkt während des Post-Trainings.
  • Ein Perceiver-Bottleneck verknüpft gelerne Query-Vektoren per Cross-Attention mit dem KV-Cache zu einer kompakten Repräsentation.

Klassische Methoden wie Agenten-Kontextreduktion oder RAG-Suchen komprimieren Kontext sublinear, arbeiten jedoch oft verlustbehaftet oder erfordern Laufzeit-Verarbeitungen. STILL begegnet dem linearen Wachstum des KV-Caches durch ein speziell trainiertes Perceiver-Bottleneck. Dieser Ansatz erzeugt in einem einzigen Forward-Pass differenzierbare, komprimierte Keys und Values, auf die Sprachmodelle wie auf regulären Kontext zugreifen können.

Fortschritte beim spekulativen Dekodieren mit dFlash und dSpark

  • dFlash ersetzt autoregressive Entwurfsmodelle durch ein Diffusions-Sprachmodell für die Vorhersage ganzer Token-Sequenzen.
  • Die parallele Block-Generierung von 8 bis 16 Tokens steigert die Verarbeitungsgeschwindigkeit auf einer B200-GPU um das Dreifache gegenüber EAGLE-3.
  • Das neue Verfahren dSpark kombiniert Diffusionsmodelle mit sequenziellen Entwurfsmodellen zur weiteren Erhöhung der Akzeptanzrate.

Frühere Methoden der spekulativen Dekodierung wie Medusa oder EAGLE-3 nutzten zusätzliche Dekodierköpfe oder autoregressive Milliarden-Parameter-Modelle für einzelne Entwurfstokens. dFlash verwendet eine Attention-Maske für bidirektionales Entwerfen, wodurch innerhalb eines Blocks mehrere Tokens gleichzeitig über Cross-Attention generiert und evaluiert werden. Dies führt zu höheren Akzeptanzraten im Zielmodell und beschleunigt die Inferenz in Produktionsumgebungen signifikant.

Kontinuierliches Training und zukünftige Inferenz-Architekturen

  • Kontinuierliches Nachtrainieren des Spekulations-Modells auf realen System-Prompts steigert die Token-Akzeptanz um bis zu 100 %.
  • Kommende Hardware-Architekturen wie Rubin verstärken den Nutzen von NVFP4-Formaten.
  • Prompt-Prefill- und Decode-Disaggregation (PD-Disaggregation) gewinnen für systemweite KV-Cache-Übertragungen an Bedeutung.

Die Anpassung des Spekulations-Modells an den laufenden Datenstrom erhöht die Vorhersagegenauigkeit der Entwurfstokens erheblich, erfordert jedoch hohe Rechenleistung und striktes Datenmanagement. Für zukünftige Hardware-Generationen gewinnt das Zusammenspiel aus optimierten Datenformaten wie NVFP4, der physischen Entkopplung von Prefill- und Decode-Phasen sowie trainingsbasierter Inferenz-Vorbereitung weiter an Relevanz.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기