BLUF — ein Draft-Modell rechtfertigt seinen Platz in einer produktiven Inferenzplattform erst, wenn Vorschlagserzeugung und Verifikation weniger Aufwand verursachen als die direkte Erzeugung derselben verbindlich übernommenen Tokens. Entscheidend ist die tatsächlich angebotene Last Ihres Dienstes. Die Akzeptanzrate allein belegt keinen Break-even. Vergleichen Sie eine Baseline ohne Spekulation mit geeigneten Draft-Modellen bei unveränderter Zielmodellkonfiguration. Messen Sie übernommene Tokens je Prüfzyklus und verlangen Sie niedrigere Kosten je akzeptierter, SLO-konformer Antwort, ohne Qualität oder Kapazität zu verschlechtern.
Dieser Beitrag liefert ein Rechenmodell und einen reproduzierbaren Versuchsplan, keine gemessene GPU-Beschleunigung. Die Entscheidung betrifft einen zusätzlichen Vorschlagsmechanismus während der Inferenz. Anders als bei der Knowledge Distillation ersetzen Sie das große Modell nicht durch einen kleineren Student: Das Zielmodell bleibt in jedem spekulativen Prüfzyklus beteiligt.
Was das Zielmodell tatsächlich prüft
Gewöhnliches autoregressives Decoding erzeugt jeweils das nächste Token. Beim Speculative Decoding schlägt ein günstigeres Modell mehrere Tokens vor. Das Zielmodell bewertet diese Fortsetzung in einem parallelen Verifikationsdurchlauf. Ein korrekter Sampler übernimmt einen akzeptierten Präfix, behandelt die erste Ablehnung mit der vorgesehenen Korrektur, verwirft den verbleibenden spekulativen Suffix und setzt am verbindlich übernommenen Kontext fort. Werden alle Vorschläge akzeptiert, kann der Standardalgorithmus zusätzlich ein vom Zielmodell gesampeltes Token übernehmen.
Die Originalarbeit zu Speculative Decoding leitet ein verteilungserhaltendes Rejection Sampling her. Beim Sampling bedeutet Prüfung nicht einfach: „Alles behalten, was dem Argmax des Zielmodells entspricht.“ Maßgeblich sind Ziel- und Vorschlagswahrscheinlichkeiten; bei einer Ablehnung liefert die Residualverteilung den Ersatz. Greedy Decoding ist ein anderer, einfacherer Fall. Implementieren Sie keinen eigenen Annahme-/Ablehnungsmechanismus aus einem konzeptionellen Schaubild und unterstellen Sie anschließend korrekte Sampling-Semantik.
Das Schaubild zeigt einen konzeptionellen Ablauf: Der Proposer schlägt A, B, C und D vor; die Prüfung akzeptiert A und B, lehnt C ab und verwirft D. Der Sampler liefert Ersatz X. Der nächste Vorschlag beginnt nach A, B, X. Die Buchstaben sind illustrative Tokenbezeichnungen, keine Modellausgabe. X ist nicht zwangsläufig das Argmax des Zielmodells. Die Zielverteilung hängt jeweils vom relevanten Präfix ab. Bei Sequenzende oder erreichtem Ausgabelimit endet die Erzeugung; ein Bonustoken ist dann nicht erforderlich.
„Verlustfrei“ ersetzt keine Produktionsprüfung
Die vLLM-Dokumentation zu Speculative Decoding unterscheidet theoretische Verteilungserhaltung, Tests des Rejection Samplers und der Greedy-Gleichheit sowie numerische Instabilität. Gleitkommaoperationen und veränderte Batchformen können unterschiedliche Ausgaben verursachen. Derselbe Zufallsseed macht aus Verteilungsgleichheit keine Zusage byteidentischer Antworten über verschiedene Konfigurationen hinweg.
Halten Sie Zielmodellrevision, Tokenizer, Chat-Template, Präzision, Samplingparameter, Logit-Verarbeitung und Abbruchregeln konstant. Prüfen Sie Structured Output, Adapter, Parallelisierung und Modellfamilie für die festgelegte Engine-Version. Die Unterstützung eines Features bei einer Methode gilt nicht automatisch für jeden Proposer. Synthetische Akzeptanzeinstellungen belegen keine reale Leistung: Sie modellieren ein angenommenes Akzeptanzmuster, messen aber nicht die Übereinstimmung Ihres Draft-Modells mit dem Zielmodell.
Aktuelle Dokumentation verändert sich. Archivieren Sie installierte Version, Container-Digest und exakte Konfiguration. Der Transformers-Leitfaden für Version 4.57.1 beschreibt Assisted Generation, Prompt Lookup, Selbstspekulation und Tokenizer-Konvertierung samt versionsbezogener Einschränkungen. Er hilft, die Verfahren zu unterscheiden. Er beweist nicht, dass APIs und Einschränkungen unverändert für eine neuere Transformers- oder vLLM-Version gelten.
Eine Break-even-Rechnung mit sichtbarem Zusatzaufwand
Für ein homogenes Lastsegment sei T die gemessene Decode-Zeit der Baseline je verbindlich übernommenem Ausgabetoken. D(k) bezeichnet die Draft-Zeit für k Vorschlagstokens, V(k) die Verifikation durch das Zielmodell und H(k) zusätzlichen Aufwand für Scheduling, Sampling und Zustandsverwaltung. M(k) ist die erwartete Anzahl neu übernommener Tokens je Zyklus. Als erste Abschätzung gilt: spekulative Zeit je übernommenem Token = [D(k) + V(k) + H(k)] / M(k). Der lokale Decode-Break-even liegt bei D(k) + V(k) + H(k) < M(k) × T.
Rechnen Sie nur mit nicht überlappenden Zeitanteilen auf dem kritischen Pfad. Überlappt die Implementierung Drafting, Prüfung oder Scheduling, messen Sie die verstrichene Zykluszeit, statt überlappende Profiler-Spannen zu addieren. Das Modell dient der Vorauswahl innerhalb eines Segments. Es prognostiziert weder Warteschlangenlatenz noch Flottendurchsatz unter Continuous Batching. Verwenden Sie gesamte Zykluszeit geteilt durch sämtliche übernommenen Tokens, nicht einen ungewichteten Mittelwert einzelner Zyklusquotienten.
Unter der vereinfachenden Annahme der Originalarbeit — unabhängige, konstante Akzeptanzwahrscheinlichkeit α je Position — gilt bei k Vorschlagstokens und verfügbarem Korrektur- oder Bonustoken: M(k) = 1 + α + α² + … + αᵏ. Die Formel zählt, wie weit ein akzeptierter Präfix reicht. Der Gesamtquotient akzeptierte/vorgeschlagene Tokens schätzt α bei variabler Vorschlagslänge oder wechselnden Kontexten nicht automatisch korrekt. Erfassen Sie im Betrieb akzeptierte Präfixlängen und übernommene Tokens je Zyklus direkt. Sequenzende, Ausgabelimits, adaptive Tiefe und andere Algorithmen verändern die Rechnung.
Nur illustrative Arithmetik: T = 10 ms, k = 4 und α = 0,7 ergeben M = 2,7731 Tokens. Bei D = 4 ms, V = 12 ms und H = 2 ms beträgt die geschätzte Decode-Zeit 18 / 2,7731 = 6,49 ms je übernommenem Token. Steigt die Draft-Zeit stattdessen auf 16 ms, ergeben sich 30 / 2,7731 = 10,82 ms. Trotz identischer Akzeptanzannahme verliert die zweite Konfiguration gegen die Baseline. Diese Eingaben sind erfundene Rechenbeispiele, keine Benchmarkmessungen, Preisangaben oder Produktionsprognosen.
Latenz-Break-even ist nicht finanzieller Break-even. Bei reservierten GPUs sinkt die Rechnung häufig erst, wenn Sie Kapazität tatsächlich abbauen oder vermeiden. Berechnen Sie die Gesamtkosten des Dienstes je akzeptierter, SLO-konformer Antwort im gleichen Zeitfenster. Berücksichtigen Sie Draft-Ressourcen, Leerlauf, Retries, abgewiesene Anfragen, Aufwärmphase und Wartung. Fehlgeschlagene Arbeit gehört in den Kostenzähler, nicht in den Nenner nützlicher Antworten. Addieren Sie keinen separaten GPU-Zuschlag, wenn er bereits in den Flottenkosten enthalten ist.
Benchmark-Raster: Die Baseline bleibt ein vollwertiger Kandidat
Fixieren Sie eine bereinigte Ankunftsspur und segmentieren Sie nach Eingabelänge, tatsächlicher Ausgabelänge, Sprache, Aufgabe und Samplingverfahren. Halten Sie Hardware und Zielmodellbereitstellung für den ersten Vergleich konstant. Benötigt ein Proposer weitere Hardware, behandeln Sie ihn als separate Ressourcenkonfiguration einschließlich ihrer Kosten. Fixieren Sie Prefix-Cache-Einstellungen und Cache-Aufwärmung separat: Verbesserter Prefill darf nicht als schnelleres Decoding erscheinen. Die Kostenbetrachtung zu Prefix Caching beschreibt diese eigenständige Entscheidung.
| Testzelle | Konfiguration | Erfassung | Entscheidungsfrage |
|---|---|---|---|
| Baseline | Spekulation aus; identisches Zielmodell und Lastprofil | Phasenlatenz, Speicher, nützliche Antworten/s, Kosten/Antwort | Was muss der Proposer übertreffen? |
| Kurzer Draft | Kompatibles kleines Modell; kurze Vorschlagsfolge | Zykluszeit, übernommene Tokens, Akzeptanz je Position | Reicht geringer Draft-Aufwand für einen Gewinn? |
| Längerer Draft | Gleiches Draft-Modell; größere Vorschlagstiefe | Gleiche Metriken plus verworfene Suffix-Arbeit | Werden zusätzliche Kandidaten weit genug akzeptiert? |
| Alternativer Draft | Anderer kompatibler Proposer; gleiche Tiefe | Draft-Zeit, Speicher, Akzeptanz je Aufgabe | Rechtfertigt bessere Übereinstimmung die Ressourcen? |
| Spitzenlast | Alle Kandidaten bei höchster angebotener Last | Wartezeit, p95/p99-Latenz, Fehler und Goodput | Überlebt der Vorteil die Ressourcenkonkurrenz? |
| Neustart und Rückfall | Kalter Prozess; danach Baseline wiederherstellen | Bereitschaftszeit, Speicherspitzen, verlorene Arbeit | Ist die Änderung betrieblich reversibel? |
Dieses Raster ist noch nicht mit Messwerten gefüllt. Tragen Sie keine prognostizierten Beschleunigungen als Ergebnisse ein. Prüfen Sie niedrige, normale und Spitzenlast. Die Ankunftszeitpunkte dürfen nicht von der Fertigstellung vorheriger Anfragen abhängen, sonst reduziert ein langsamerer Server unbemerkt die angebotene Last. Begrenzen Sie die Zulassung und erfassen Sie Abbrüche sowie Timeouts. Wiederholen Sie Läufe in wechselnder Reihenfolge und berichten Sie Streuung zusätzlich zu Mittelwerten. Trennen Sie kaltes Modellladen vom aufgewärmten Serving-Versuch.
Erfassen Sie je Testzelle TTFT, anfragebezogene Decode-Zeit, sichtbare Streamingpausen, Ende-zu-Ende-Latenz, Ausgabedurchsatz, Spitzenspeicherbedarf, verfügbare KV-Kapazität und gegebenenfalls Preemption. Spekulatives Serving kann Tokens schubweise ausgeben. Nahezu verschwindende Abstände innerhalb eines Schubs verschönern tokenbezogene Mittelwerte, während Nutzer zwischen den Schüben warten. Prüfen Sie p95/p99-Pausen und Fertigstellungszeiten pro Anfrage, nicht nur eine mittlere Inter-Token-Latenz.
Prüfen Sie das Metrikschema der installierten Engine, bevor Sie konkrete Counternamen verwenden. Dokumentieren Sie Zähler und Nenner: akzeptierte Draft-Tokens / vorgeschlagene Tokens, Verteilung akzeptierter Präfixlängen, übernommene Tokens / Zyklus und erfolgreiche SLO-konforme Antworten / Zeitfenster. Halten Sie Metriklabels niedrig-kardinal; Prompts und Kundenidentitäten gehören nicht hinein. Der SLO-Leitfaden für selbst betriebene Inferenz liefert die servicebezogene Messgrenze und Phaseninstrumentierung.
Entscheidungstabelle: Beibehalten, anpassen oder deaktivieren
| Beobachtung | Entscheidung | Risiko vor Freigabe prüfen |
|---|---|---|
| Decode schneller; Goodput und Qualität erfüllen Grenzen | Gemessene Konfiguration als Canary testen | Lastverschiebung kann den Break-even verändern |
| Akzeptanz höher, aber Kosten/Antwort schlechter | Günstigeren Draft oder Baseline bevorzugen | Größerer Proposer verbraucht Speicher und Zeit |
| Vorteil bei niedriger Last; mehr Wartezeit bei Spitzenlast | Auf nachgewiesenen Lastbereich begrenzen | Schwellwertpendeln und Routenkapazität |
| Viele Ablehnungen in einer Sprache oder Aufgabe | Baseline für dieses Segment behalten | Gesamtakzeptanz verdeckt Segmentverluste |
| TTFT dominiert bei kurzen Antworten | Prefill oder Warteschlange priorisieren | Schnelleres Decode verändert die Antwortzeit kaum |
| Feature inkompatibel oder Sampler-Semantik ungeprüft | Diese Kombination nicht aktivieren | Stille Inkompatibilität kann Ausgaben verfälschen |
Eine lastabhängige Richtlinie braucht Hysterese, ein Mindestbeobachtungsfenster und einen getesteten Konfigurationswechsel. Unterstellen Sie nicht, dass die Engine ein beliebiges Draft-Modell pro Anfrage umschaltet oder dessen Speicher sofort freigibt. Unterstützt die installierte Version nur eine Auswahl beim Start, benötigen Sie separat bereitgestellte Routen oder ein Deployment-Rollback. Rechnen Sie deren Kapazitätskosten ein. Eine einfache Baseline kann betrieblich überlegen sein, obwohl eine komplexe Richtlinie eine einzelne Laborzelle gewinnt.
Freigabecheckliste und Rollback-Vertrag
Vor dem Versuch: Fixieren Sie Ziel- und Draft-Revisionen, Tokenizer-Kompatibilität, Engine-Image, Hardware, Parallelisierung, Sampler und Abbruchregeln. Prüfen Sie die Unterstützungsmatrix der konkreten Methode. Genehmigen Sie den Umgang mit Benchmarkdaten und archivieren Sie Konfigurationsherkunft, ohne vertrauliche Prompts unnötig aufzubewahren.
Vor dem Canary: Verlangen Sie für Baseline und Kandidat denselben Qualitätsvertrag, geschützte Aufgaben- und Sprachgrenzen, dasselbe Fehlerbudget und dieselbe Kostengrenze. Vergleichen Sie Greedy-Ausgaben, wo sinnvoll. Beim Sampling prüfen Sie Implementierungskorrektheit und repräsentative Qualität, ohne identische Stichproben zu verlangen. Verwerfen Sie vermeintliche Einsparungen, die nur durch kürzere, abgeschnittene oder fehlerhaft formatierte Antworten entstehen.
Vor der breiten Freigabe: Testen Sie Spitzenankünfte, Neustart, Abbruch und lange Kontexte. Halten Sie Rollback-Reserve vor: Ohne Proposer kann mehr Decode-Arbeit beim Zielmodell anfallen; beim Laden des Proposers kann der Speicherbedarf vorübergehend steigen. Bewahren Sie vorheriges Image und Konfiguration einsatzbereit auf. Rollen Sie zurück, wenn eine geschützte Qualitätsgrenze verletzt wird, p95/p99-Latenz das vereinbarte Budget überschreitet, Fehler zunehmen oder Kosten je nützlicher Antwort den zusätzlichen Betriebsaufwand nicht mehr rechtfertigen.
Aus Spekulation eine Kapazitätsentscheidung machen
Bringen Sie einen Zielendpunkt, ein bereinigtes Lastprofil und Ihre bestehenden SLO- und Kostengrenzen in eine Inferenz-Architekturprüfung ein. Ich unterstütze Sie dabei, Kandidatenvergleich, Messvertrag und reversiblen Rollout festzulegen. Das Ergebnis sollte eine getestete Entscheidung über Draft-Aufwand und eingesparte Tokenarbeit sein, kein Screenshot einer Akzeptanzrate. Besteht kein Kandidat die Servicegrenzen, lassen Sie Spekulation deaktiviert und optimieren Sie den Engpass, den die Baseline tatsächlich zeigt.
