Gewinne:
- Kann erklären, was Streaming ist, welche Veranstaltungstypen es gibt und warum es benötigt wird.
- max_tokens erfasst Timeout und eine 128K lange Ausgabebeziehung
- Kann je nach Arbeitslast die richtige Wahl zwischen Streaming- und Nicht-Streaming-Anfragen treffen
Sie haben vielleicht bemerkt, dass in einer Chat-Oberfläche die Antwort Wort für Wort „eingetippt“ wird. Dies ist kein visueller Schnörkel; Es ist das Ergebnis einer Technik namens Streaming und ist häufig für die LLM-Integration in Produktionsqualität zwingend erforderlich. In dieser Einheit erfahren Sie, was Flow ist, aus welchen Ereignissen er besteht, welche Beziehung er zu langer Ausgabe und Zeitüberschreitung hat und wann Sie Flow verwenden sollten und wann nicht. Wir werden das Thema anhand der realen Aufgaben eines Profis behandeln – Live-Assistent, Erstellung langer Berichte, Stapelverarbeitung.
Was ist Flow?
Bei einer Nicht-Streaming-Anfrage (synchron) warten Sie, bis das Modell die gesamte Antwort erzeugt. Wenn die Antwort fertig ist, kommt sie in einem Stück an. Bei einer Streaming-Anfrage sendet der Server die Antwort Stück für Stück, während das Modell generiert. Technisch gesehen geschieht dies mit vom Server gesendeten Ereignissen (SSE – Server-Sent Events, eine Methode, bei der der Server nacheinander kleine Ereignisse über eine offene Verbindung sendet).
Der Unterschied wird im Benutzererlebnis deutlich: Bei einer Antwort, die 8 Sekunden dauert, starrt der Nicht-Stream-Benutzer 8 Sekunden lang auf einen leeren Bildschirm; Der Streaming-Benutzer sieht die ersten Wörter in etwa 0,5 Sekunden und der Text beginnt zu fließen. Die wahrgenommene Latenz – die Wartezeit, die der Benutzer empfindet – wird erheblich reduziert, während die Gesamtzeit unverändert bleibt.
Ereignistypen des Flusses
Flow ist eine Abfolge von Ereignissen. Konzeptionell sieht ein typischer Ablauf so aus:
Vorfall
Bedeutung
message_start
Die Reaktion begann; Header-Informationen wie Modell und ID sind eingetroffen.
content_block_start
Ein Inhaltsblock (z. B. Text) wurde gestartet
content_block_delta
Ein kleines Textstück (Delta) ist angekommen; Sie sammeln diese
content_block_stop
Block abgeschlossen
message_delta
Aktualisierte Endinformationen wie stop_reason und Nutzung
message_stop
Antwort vorbei
Ihr Code kombiniert nacheinander Textteile in content_block_delta-Ereignissen. Sie erhalten am Ende genau denselben Text wie die nicht gestreamte Antwort. Die Nutzung (Token-Nummern) ist normalerweise am Ende des Flusses klar – Sie behalten den Überblick über die Kosten, sobald der Fluss beendet ist.
Tipp: Die meisten offiziellen SDKs (Software Development Kit – vorgefertigte Bibliothek des Anbieters) bieten einen Helfer, der den Stream für Sie sammelt (z. B. stream.get_final_message()). Sie müssen nicht alle Titel manuell verwalten; Verwenden Sie diesen Helfer, wenn Sie den Volltext benötigen, einzelne Ereignisse verarbeiten, aber live ausdrucken möchten.
Lange Antworten, max_tokens und Timeout
Die zweite und eher technische Ursache für Streaming ist die Zeitüberschreitung. Wenn eine HTTP-Anfrage nicht innerhalb einer bestimmten Zeitspanne abgeschlossen wird, bricht der Client die Verbindung ab. Wenn Sie eine große Ausgabe vom Modell anfordern (z. B. einen Bericht über 40.000 Token), kann der Non-Flow-Aufruf dieses Limit überschreiten und eine Zeitüberschreitung verursachen – die Anfrage schlägt fehl und Sie müssen für die generierten Token bezahlen.
Moderne Modelle können bis zu 128.000 Token in einer einzigen Anfrage ausgeben. Aber die Faustregel ist klar: Verwenden Sie Streams, wenn der „max_tokens“-Wert hoch ist (ungefähr über 16.000). Streaming hält die Verbindung aufrecht und verhindert Zeitüberschreitungen; Außerdem sehen Sie den Fortschritt sofort.
- „max_tokens“: Maximale Ausgabetokens, die das Modell produzieren kann; eine harte Decke. Wenn ein Interrupt auftritt, wird stop_reason max_tokens zurückgegeben.
- Kontextfenster: Das Fenster, in das die Summe aus Eingabe + Ausgabe passen muss. max_tokens ist die Obergrenze der Ausgabe; Vermischen Sie beides nicht.
Achtung: Das Auslösen von Non-Flow-Anfragen mit großen max_tokens ist ein klassischer Fehler in der Produktion. Ohne eine Antwort wird die Verbindung unterbrochen, der Benutzer sieht einen Fehler und die Token-Kosten werden verschwendet. Lange Ausgabe = Stream.
Wann sollte man fließen und wann nicht?
Status
Präferenz
Warum
Live-Chat / Assistent
fließen
Wahrgenommene Latenzrückgänge, Benutzer sieht Fortschritt
Erstellung langer Berichte/Dokumente
fließen
Verhindert Zeitüberschreitungen und überträgt große Ausgaben sicher
Kurze Klassifizierung (z. B. Einzelwort-Tag)
kein Fluss
Der Output ist bereits gering; zusätzliche Komplexität unnötig
Stapelverarbeitung
flusslos/chargenweise
Ergebnisse werden nicht sofort angezeigt; Siehe Einheit 7
Automatisierungsschritt (im Hintergrund)
Normalerweise kein Fluss
Sie geben das Ergebnis an den nächsten Schritt weiter, keine Live-Anzeige
Kopierbare Eingabeaufforderung/Vorlagen
Der Stream selbst ist keine Eingabeaufforderung, aber Eingabeaufforderungen sind für die Verwaltung der vom Stream erzeugten Ausgabe von entscheidender Bedeutung. Bei langen und fließenden Produktionen erhöht das Aufzwingen der Struktur von vorne sowohl die Qualität als auch die Nachverfolgbarkeit.
# Teilen Sie den langen Bericht in Abschnitte auf (so dass der Fortschritt im Ablauf sichtbar ist). Schreiben Sie den Bericht mit den folgenden Überschriften in genau dieser Reihenfolge. Beginnen Sie jede Überschrift mit „##“:## Zusammenfassung## Ergebnisse## Empfehlungen## Nächste Schritte
# Geben Sie die Ziellänge an, um eine Kürzung bei langen Produktionen zu vermeiden. Der Gesamttext wird etwa 800 Wörter umfassen. Halten Sie die Portionen im Gleichgewicht; Lassen Sie am Ende keinen halben Satz stehen.
# Geben Sie den ersten Satz sofort für den Streaming-Assistenten ein. Geben Sie zunächst eine direkte Antwort in einem Satz und gehen Sie dann ins Detail. So sieht der Benutzer beim Warten sofort ein Ergebnis.
# Halten Sie die lange Ausgabe strukturiert (damit sie später analysiert werden kann). Geben Sie die Ausgabe in diesen Abschnitten aus und markieren Sie jeden Abschnitt mit einem separaten „###“-Header, damit ich sie programmgesteuert analysieren kann: ### EINFÜHRUNG ### BODY ### SOURCES
Schwache Eingabeaufforderung / Starke Eingabeaufforderung (lange Produktion)
# SCHWACHSchreiben Sie einen langen und ausführlichen Bericht zu diesem Thema.
# STARKSchreiben Sie einen Bericht mit etwa 900 Wörtern zu diesem Thema. Überschriften: ## Zusammenfassung, ## Analyse, ## Risiken, ## Empfehlungen. Jede Überschrift sollte maximal 3 Absätze umfassen. Lassen Sie am Ende keinen halben Satz stehen.
Leistungsstarke Version; Es legt Länge, Struktur und Verarbeitungsqualität im Voraus fest. Wenn Abschnitte in den Fluss kommen, sieht der Benutzer den Fortschritt deutlich und verwaltet die Länge selbst, um das Risiko einer Modellunterbrechung zu vermeiden.
Drei Mini-Hüllen
Fall 1 – Beschwerde wegen leerem Bildschirm. Der Kundenassistent eines Beratungsteams reagierte unauffällig; Die durchschnittliche Antwort dauert 7 Sekunden. Benutzer fragen: „Friert es ein?“ er beschwerte sich. Sobald ich in den Fluss kam, kam das erste Wort in etwa 0,6 Sekunden; Die Gesamtdauer blieb gleich, die „langsamen“ Beschwerden verschwanden jedoch nahezu.
Fall 2 – Veralteter Bericht. Ein Finanzteam ließ einen 30-seitigen Quartalsbericht erstellen; Bei max_tokens: 30000 bliebe die No-Flow-Anfrage in einem Client-Timeout von 60 Sekunden hängen, die Anfrage würde fehlschlagen – und die generierten Token würden auf die Rechnung geschrieben. Sie gingen mit dem Strom; Die Verbindung blieb bestehen, der Bericht wurde vollständig geliefert und unnötige Kosten wurden vermieden.
Fall 3 – Unnötiger Fluss. Ein Betriebsteam kennzeichnete eingehende E-Mails als „dringend/regelmäßig“; Die Ausgabe war ein Wort, aber sie verwendeten gewöhnlich „Flow“. Der Ablauf bot bei der Ein-Wort-Antwort keinen Vorteil, wodurch der Code unnötig komplex wurde. Als ich zu Flowless wechselte, vereinfachte sich der Code und das Verhalten blieb gleich. Lektion: Streaming ist bei Long/Live-Ausgaben nicht überall wertvoll.
Häufige Fehler
- Keine Verwendung von Streams in einer langen Ausgabe: Zeitüberschreitung und verschwendete Token-Kosten.
- Verwendung von Streaming in Kurzausgaben: Unnötige Komplexität, null Nutzen.
- „stop_reason“ am Ende des Streams wird nicht überprüft: Die gekürzte Antwort mit max_tokens gilt als abgeschlossen.
- Falsches Zusammenführen von Deltas: Die manuelle Summierung mit dem SDK-Helfer führt zu einem Fehler in der Reihenfolge/fehlenden Teilen.
- Versuch, „Nutzung“ mitten im Stream zu lesen: Token-Nummern werden normalerweise am Ende klar; Behalten Sie am Ende den Überblick über die Kosten.
- Verwechselung von Streaming mit Kostensenkung: Streaming verbessert das Erlebnis und die Ausdauer; Der Token-Preis ändert sich dadurch nicht.
Tiefer: Flow Breaks und Resilienz
Streaming ist eine Live-Verbindung; Das ist sowohl seine Stärke als auch seine Verletzlichkeit. Wenn die Verbindung mittendrin abbricht (Netzwerkschwankung, Client-Timeout), bleibt der bisher gesammelte Text erhalten, die Antwort ist jedoch unvollständig. Ein Streaming-Client in Produktionsqualität sollte darauf vorbereitet sein: Er sollte den Teiltext nicht als „abgeschlossene Antwort“ behandeln und die Antwort auch nicht als abgeschlossen betrachten, bis er das Ereignis „message_stop“ sieht.
Die zweite Feinheit besteht darin, dass der Durchfluss die Kosten nicht verändert. Ob Sie eine Antwort mit oder ohne Streaming erhalten, hat keinen Einfluss auf den Token-Preis; Flow verbessert nur das Erlebnis und die Ausdauer. Also: „Wenn wir auf Streaming umsteigen, werden sie dann billiger sein?“ Die Antwort auf die Frage lautet „Nein“ – schauen Sie sich für die Kosten die 5. und 6. Einheit an (Modellauswahl, Cache).
Der dritte Punkt besteht darin, eine praktische Balance zu finden: Bei Live-Assistenten ist die schnelle Ankunft des ersten Wortes (wahrgenommene Verzögerung) sehr wichtig; Daher vervielfacht die Aufforderung an das Modell, die Antwort direkt einzugeben und zunächst ein kurzes Ergebnis zu liefern (über die Systemeingabeaufforderung in der 4. Einheit), den Nutzen des Flusses. Wenn der Benutzer in der ersten Sekunde etwas Sinnvolles sieht, wartet er geduldig auf die folgenden Details. Andererseits leistet der Flow keinen Beitrag zu den Jobs, die im Hintergrund ausgeführt werden und deren Ausgabe an den nächsten Automatisierungsschritt weitergeleitet wird. Das einzige Kriterium ist dort die ordnungsgemäße und vollständige Erledigung der Arbeiten.
Zusammenfassend
Streaming ruft die Antwort Stück für Stück ab, reduziert die wahrgenommene Latenz und verhindert Zeitüberschreitungen bei großen Durchsätzen. Fast obligatorisch für Live-Assistenten und die Produktion langer Dokumente; Für Kurz-/Hintergrundarbeiten ist es nicht erforderlich. Bei langen Produktionen erhöht die zeitnahe Vorgabe von Struktur und Länge von vorne sowohl die Qualität als auch die Rückverfolgbarkeit; Wenn der Fluss beendet ist, werden stop_reason und Usage definitiv überprüft.
Anwendungsaufgabe
Wählen Sie zwei Szenarien: ein Live/Lang-Szenario (z. B. Bericht an den Kunden), ein Kurz-/Hintergrundszenario (z. B. Markieren). (1) Entscheiden Sie und begründen Sie, ob Sie für jeden Flow verwenden möchten. (2) Schreiben Sie eine Eingabeaufforderung, die die Struktur für das lange Skript vorgibt (Überschriften + Ziellänge). (3) Bestimmen Sie die max_tokens-Werte. (4) Listen Sie auf, welche Prüfungen Sie mit „stop_reason“ und „use“ am Ende des Ablaufs durchführen werden.
Checkliste
- [ ] Ich kann erklären, was Streaming ist und wie es die wahrgenommene Latenz reduziert.
- [ ] Ich habe die grundlegenden Ereignistypen des Stream- und Delta-Joins verstanden.
- [ ] Ich weiß um die Notwendigkeit, mit großen max_tokens zu streamen, und um die Timeout-Beziehung.
- [ ] Ich kann entscheiden, bei welchem Workload ich Streaming nutzen werde und bei welchem nicht.
- [ ] Ich kann stop_reason und die Nutzung am Ende des Streams überprüfen.