BLUF — verwenden Sie für den hier getesteten Decoder-only-Generierungspfad von Transformers linkes Padding, übergeben Sie die tatsächliche Attention-Maske und extrahieren Sie neue Tokens hinter der gemeinsamen gepaddeten Eingabebreite. Eine Attention-Maske macht aus der letzten Padding-Spalte nicht die letzte echte Tokenposition. Prüfen Sie das Tokenverhalten, bevor Sie Batching als Leistungsverbesserung bewerten.
Ein kleiner, revisionsgebundener GPT-2-Test auf CPU reproduzierte diese Grenze: Korrektes linkes Padding erhielt alle vier Einzelausgaben mit jeweils acht neuen Tokens. Rechtes Padding veränderte eine Ausgabe; eine absichtlich auf Einsen gesetzte Maske beim linken Padding ebenfalls. Eine falsche Suffixextraktion übernahm bei drei Ergebnissen Eingabepositionen. Das sind lokale Beobachtungen zum Programmablauf, kein Benchmark eines Produktionsmodells und keine Durchsatzmessung.
Fixieren Sie den Vertrag, nicht nur den Zufallsstartwert
Die technische Entscheidung lautet: Erhält die Batchumstellung den bestehenden Generierungsvertrag? Halten Sie Modellgewichte, Tokenizerrevision, Promptformat, Sondertokens, Ausgabebudget, Dekodierungsstrategie, Datentyp, Attention-Implementierung und Cachekonfiguration konstant. Führen Sie Anfrage-IDs bei jeder Sortierung mit und stellen Sie die erwartete Ergebnisreihenfolge wieder her. Ändern Sie nicht gleichzeitig Trunkierung oder Chat-Template.
Der Textgenerierungsleitfaden von Hugging Face empfiehlt ausdrücklich linkes Padding für Decoder-only-Generierung. Die Padding-Dokumentation unterscheidet hinzugefügte Füllpositionen von abgeschnittenen Eingaben. Ein schnellerer Lauf, der unbemerkt das Dokumentende entfernt, belegt keine bessere Batchstrategie.
Das unterscheidet sich von Batch-Budgets für Embeddings: Ein Encoder aggregiert häufig die berücksichtigten Hidden States. Ein kausaler Decoder muss dagegen das nächste Token aus einer bestimmten Sequenzposition auswählen. Die rechte Padding-Konvention eines Encoders kann in einem Generierungswrapper diese Entscheidung verändern. Serving-Engines mit gepackten Sequenzen oder eigener Positionsauswahl benötigen gesonderte Tests; nicht jedes Backend verwendet denselben Vertrag für rechteckige Tensoren.
Warum eine korrekte Attention-Maske nicht genügt
Die installierte Greedy-/Sampling-Implementierung von Transformers 4.57.1 liest für das nächste Token outputs.logits[:, -1, :]. Das Testprogramm prüfte diesen Ausdruck im installierten Quelltext von GenerationMixin._sample. Bei unterschiedlich langen, rechts gepaddeten Prompts liegt in der letzten Spalte einer kürzeren Zeile eine Füllposition. Padding als Attention-Schlüssel auszublenden weist diese Schleife nicht an, pro Zeile die letzte echte Queryposition auszuwählen.
Linkes Padding setzt das letzte echte Token in jeder Zeile in die letzte Tensorspalte. Im getesteten GPT-2-Pfad leitet prepare_inputs_for_generation die Positions-IDs aus der Attention-Maske ab. Dadurch erhalten echte Tokens passende logische Positionen trotz verschobener Tensorspalten. Beliebige Positions-IDs, eine fehlende Maske oder ein Cache aus einem anderen Layout können diese Beziehung verletzen. Prüfen Sie den konkreten Modelladapter, statt eine universelle Positionsformel vorauszusetzen.
| Anfrage | Eingabe; Breite 5 | Neues Suffix |
|---|---|---|
| Kurz | P P P A B | G … |
| Lang | C D E F H | G … |
Die Darstellung ist eine Illustration, kein Tokenizerdump. P steht für Padding, Buchstaben für echte Eingabetokens. Beide Zeilen haben die Breite fünf; G ist das erste neue Token und gehört nicht zur Eingabebreite. Die Extraktionsgrenze liegt für beide Anfragen bei Spalte fünf, nicht bei ihrer jeweiligen Anzahl berücksichtigter Tokens. Rechtes Padding würde P rechts hinter den kurzen Prompt verschieben, ohne die Auswahl der letzten Spalte in der Generierungsschleife zu ändern.
Ausgeführter Test und seine Grenzen
Ausgeführt wurde sshleifer/tiny-gpt2 in dieser unveränderlichen Revision. Modell und Tokenizer verwendeten denselben Commit. Es handelt sich um ein winziges GPT-2-Testmodell mit zweidimensionalen Einbettungen, nicht um einen industriellen Assistenten. Wiederholende Fortsetzungen sind zu erwarten und belegen keine Antwortqualität. Der Nutzen liegt darin, die Wrappermechanik mit tatsächlicher Modellausführung zu prüfen.
Das Manifest enthält Python 3.12.13, PyTorch 2.15.0+cpu, Transformers 4.57.1, CPU float32, einen PyTorch-Thread, Eager-Attention und Evaluierungsmodus. Ein Chat-Template wurde nicht verwendet; die Eingaben waren Klartext. Generiert wurde mit do_sample=False, num_beams=1, max_new_tokens=8 und use_cache=True. Pad- und EOS-ID waren jeweils 50256. Explizite Attention-Masken unterschieden Füllpositionen von berücksichtigtem Inhalt.
Die vier Prompts lauteten „Hello“, „The industrial pump requires inspection because the bearing temperature is“, „1, 2, 3,“ und „A reliable system must“. Ihre Tokenlängen betrugen 1, 10, 6 und 4. Jeder Prompt lief einzeln, anschließend liefen alle gemeinsam mit gepaddeter Breite zehn. Derselbe Batch wurde rechts gepaddet sowie links gepaddet mit absichtlich falscher Einsenmaske ausgeführt. Kundentexte wurden nicht verwendet.
| Variante | Tokengleichheit zum Einzellauf | Bedeutung |
|---|---|---|
| Links; echte Maske | 4 von 4 | Korrekte Baseline in diesem Test |
| Rechts; echte Maske | 3 von 4 | Eine veränderte Fortsetzung |
| Links; Einsenmaske | 3 von 4 | Eine veränderte Fortsetzung |
| Schnitt an Tokenanzahl | 1 von 4 sauberen Suffixen | Drei enthalten Eingabepositionen |
Für den vierten Prompt erzeugten Einzellauf und korrekt links gepaddeter Batch achtmal die Token-ID 5087. Beide Mutationen erzeugten stattdessen achtmal 16046. Bei den übrigen drei Prompts blieben die Tokenfolgen trotz der Mutationen gleich. Das zeigt die Grenze einfacher Stichproben: Ein bestandener Einzelfall beweist keine korrekte Paddingstrategie.
Auch korrektes linkes Padding verursachte beim ersten Prompt eine maximale absolute Logitabweichung im ersten Schritt von ungefähr 7,45e-9; die erzeugten Token-IDs blieben gleich. Bei den übrigen drei Prompts betrug diese Abweichung im Lauf null. Beim vierten Prompt lag die Abweichung mit rechtem Padding bei ungefähr 0,250236, mit Einsenmaske bei ungefähr 0,249780. Verglichen wurde der erste Forward-Schritt, nicht jeder nachfolgende Logittensor.
Vergleichen Sie ausgegebene Token-IDs exakt und definieren Sie für numerische Tensordiagnosen eine gesonderte Toleranz. 1e-6 absolut und 1e-5 relativ können ein Ausgangspunkt für diese float32-Testkonfiguration sein; das ist eine vorgeschlagene Einstellung, keine universelle Freigabegrenze. Fast gleich hohe Logits können trotz kleiner numerischer Differenzen einen anderen Argmax ergeben. Greedy-Dekodierung entfernt Zufallssampling, garantiert aber keine bitweise Gleichheit zwischen Hardware, Präzisionen, Kernels oder Batchformen.
Extrahieren Sie das Suffix hinter der rechteckigen Eingabe
Bei dieser Decoder-only-generate-API enthalten zurückgegebene Sequenzen zunächst den Eingabetensor und danach das generierte Suffix. Der Implementierungskern lautet: inputs = tokenizer(prompts, padding=True, return_tensors="pt"); width = inputs["input_ids"].shape[1]; outputs = model.generate(**inputs, do_sample=False, num_beams=1, max_new_tokens=8); suffix = outputs[:, width:]. Konfigurieren Sie zuvor tokenizer.padding_side="left" und ein geeignetes Pad-Token. Geben Sie Pad-/EOS-Einstellungen für reproduzierbare Tests ausdrücklich an.
Ersetzen Sie width nicht durch attention_mask.sum(). Im getesteten Batch mit Breite zehn begann die Extraktion anhand der individuellen Tokenanzahl für Prompt eins, drei und vier zu früh. Sie übernahm Padding und/oder Prompttokens. Das ist ein Fehler der Ergebnismontage, selbst wenn das Modell korrekt fortgesetzt hat. Vergleichen Sie Tokenarrays vor der Textdekodierung: skip_special_tokens=True kann Paddingreste verdecken, ohne übernommene echte Prompttokens zu entfernen.
Berücksichtigen Sie bei unterschiedlichen EOS-Zeitpunkten das erzeugte EOS und nachfolgendes Ausgabepadding gemäß Ihrem Antwortvertrag. Die Verwendung der EOS-ID als Eingabepad bedeutet für sich genommen nicht, dass links gepaddete Eingaben die Generierung sofort beenden. Masken und Stoppbehandlung müssen dennoch explizit sein. Dieser Test erzeugte in allen Fällen acht neue Tokens. Frühes EOS, Streaming, Beam Search und Abbruch wurden nicht ausgeführt; sie bleiben offene Freigabetests.
Begrenzen Sie leere und grenznahe Eingaben
Die getestete Zulassungsregel lehnte einen Prompt mit null Tokens ab, statt eine BOS-Regel zu erfinden. Sie reservierte acht Ausgabepositionen innerhalb des Modelllimits von 1.024 Positionen. Wiederholtes „ hello“ ergab eine zugelassene Eingabe mit 1.016 Tokens; sie wurde ausgeführt und erzeugte acht neue Tokens. Die Variante mit 1.017 Tokens wurde durch das Zulassungsprädikat vor der Modellausführung abgelehnt. Das belegt eine lokale Schutzprüfung, keinen HTTP-Fehlerpfad.
Zählen Sie im Chatdienst den vollständig formatierten Prompt einschließlich Template und Sondertokens. Reservieren Sie Kapazität anhand der wirksamen Modell- und Serving-Limits; berücksichtigen Sie gegebenenfalls Padding auf bestimmte Vielfache. Schneiden Sie Belege nicht unbemerkt ab, um Eingaben passend zu machen. Dokumentieren Sie, ob eine leere Nutzernachricht innerhalb eines ansonsten nichtleeren Chat-Templates erlaubt ist. Das ist nicht dasselbe wie eine Modelleingabe mit null Tokens.
Entscheidungstabelle: Finden Sie die fehlerhafte Grenze
| Beobachteter Fehler | Zuerst prüfen | Nächste Maßnahme |
|---|---|---|
| Nur kürzere Zeilen ändern sich | Paddingseite und letzte Spalte | Links padden; Baseline wiederholen |
| Linkes Padding verändert Ausgabe | Maske, Positionen, Datentyp, Cache | Jeweils eine Mutation isolieren |
| Prompt erscheint in Antwort | Suffixgrenze | An gemeinsamer Eingabebreite schneiden |
| Gleiche Tokens; kleine Logitdrift | Argmax-Abstand und Toleranz | Keine bitweise Gleichheit behaupten |
| Grenznahe Eingabe scheitert | Formatierte Länge plus Ausgabereserve | Explizit ablehnen; nicht still kürzen |
| Ergebnisse vertauscht | Anfrageidentität nach Sortierung | Über stabile Anfrage-ID zuordnen |
Erst nach bestandener Korrektheitsprüfung sollten Sie Scheduling, Speicher und Latenz auf der Zielhardware messen. Chunked Prefill bei gemischter Last behandelt die getrennte Schedulingentscheidung. Ein korrekt links gepaddeter Batch kann weiterhin viele Füllpositionen enthalten oder kurze Anfragen auf weitere Teilnehmer warten lassen. Längengruppierung tauscht weniger Padding gegen Sammelwartezeit und zusätzliche Betriebslogik.
Freigabecheckliste und nächster Schritt
Prüfung 1 — speichern Sie ein versioniertes Manifest mit unveränderlichen Modell-/Tokenizerrevisionen, Promptformat-Hash, exakten Abhängigkeiten, Datentyp, Gerät, Attention-Backend, Masken-/Positionsregel, Cacheeinstellungen, EOS-/Pad-IDs und vollständigen Generierungsoptionen. Behalten Sie eine unveränderte Einzelbaseline und stabile Anfrage-IDs.
Prüfung 2 — vergleichen Sie gemischte Längen, umgekehrte Reihenfolge, wiederholte Prompts und mehrere Batchzusammensetzungen. Nehmen Sie absichtliches rechtes Padding und Maskenmutationen auf, damit der Test Fehler tatsächlich erkennen kann. Vergleichen Sie Eingabe-IDs, Masken, Positionen, Suffix-IDs und Stoppgründe. Speichern Sie nur freigegebene synthetische oder bereinigte Eingaben; Token-IDs können den Originaltext offenlegen und sind keine Anonymisierung.
Prüfung 3 — testen Sie leere Eingaben, maximale formatierte Kontexte, Überlaufablehnung, frühes EOS, Abbruch, Ergebnisreihenfolge und Cachewiederverwendung. Trennen Sie ausgeführte Fälle von fehlender Abdeckung. Tokengleichheit belegt noch keine nützlichen Antworten. Prüfen Sie den Vertrag für strukturierte Ausgaben und fachliche Validierung gesondert.
Prüfung 4 — messen Sie Ende-zu-Ende-Latenz und vollständig gültige Antworten bei vereinbarter angebotener Last. Dieser Test hat weder Durchsatz noch Beschleunigung gemessen. Behalten Sie die einfachere Strategie, wenn zusätzliche Batchlogik keinen wiederholbaren Betriebsvorteil liefert. Rollen Sie zurück, sobald eine akzeptierte Anfrage das Suffix einer anderen erhält.
Bringen Sie für eine Prüfung des Generierungspfads das fixierte Serving-Manifest, einen bereinigten Korpus mit gemischten Längen und Ihren aktuellen Ausgabevertrag mit. Eine Implementierungsanalyse kann daraus einen reproduzierbaren Freigabe- oder Rollbacktest entwickeln. Das Ergebnis ist ein Nachweis, dass Batching die Entscheidungsgrenze erhält, keine Vermutung über Vorteile höherer Parallelität.
Die Referenz der Generierungs-API dokumentiert Ausgabe- und Dekodierungsoptionen. Die aktuelle Dokumentation kann eine neuere Version beschreiben als dieser bewusst fixierte Test. Prüfen Sie Optionen gegen die eingesetzte Version, bevor Sie sie übernehmen.
