Skip to main content

​
Übersicht

Slowdown lässt ein Modell langsamer antworten, als sein Provider es tut. GoModel misst, wie lange der Upstream-Aufruf gedauert hat, und wartet einen zusätzlichen Anteil dieser Zeit, bevor es die Response zurückgibt. Die Einstellung ist ein Faktor für zusätzliche Zeit: Nutzen Sie es, um Client-Timeouts, Ladezustände und Retry-Logik zu testen oder um zu sehen, wie sich eine App mit einem langsameren Modell anfühlt, ohne den Provider zu wechseln. Lassen Sie es im Produktivbetrieb ungesetzt, wo es keinen Zweck erfüllt. Slowdown ist standardmäßig aus.

​
Slowdown konfigurieren

Setzen Sie Slowdown für ein konkretes Modell oder einen Redirect (Alias). Aktive Faktoren reichen von 0.1 bis 10. 0 deaktiviert Slowdown explizit, auch einen vom Zielmodell geerbten. Ein leerer Wert lässt die Einstellung unbestimmt.

​
Dashboard

Öffnen Sie Models, bearbeiten Sie ein Modell oder virtuelles Modell und füllen Sie Slowdown (extra inference time) aus. Modelle mit aktivem Slowdown zeigen ihn in ihrer Zeile an.

​
config.yaml

​
Umgebungsvariable

​
Admin-API

Ein Wert außerhalb des aktiven Bereichs liefert 400. Slowdown braucht ein Modell: ein providerweiter Selektor wie openai/* wird abgelehnt.

​
Vorrang

  • Das eigene Slowdown eines Alias gewinnt gegenüber dem Slowdown seines Zielmodells.
  • Ein Alias ohne Wert erbt das Slowdown des Zielmodells, zu dem er aufgelöst wird. Setzen Sie den Alias auf 0, um das abzuschalten.
  • Bei einem per Load Balancing verteilten virtuellen Modell richtet sich die Vererbung nach dem für diesen Request gewählten Ziel.
  • Das Slowdown eines Modells lässt sich exakt (openai/gpt-4o) oder modellweit (gpt-4o, bei jedem Provider) setzen; der exakte Wert gewinnt. Ein spezifischerer Eintrag, der Slowdown leer lässt oder dessen user_paths den Aufrufer ausschließen, verdeckt keinen allgemeineren Wert. Eine providerweite Zugriffsregel schaltet das Slowdown eines Modells also nie ab.
  • In einer Verkettung gilt nur das Slowdown des äußeren virtuellen Modells.
  • Ein Slowdown auf einem Modell mit user_paths gilt nur für Requests aus diesen User-Paths.

​
Was verlangsamt wird

Fehlgeschlagene Upstream-Aufrufe kehren ohne Verzögerung zurück. Verzögerungen berücksichtigen den Abbruch von Requests: ein Client, der die Verbindung trennt, wartet sofort nicht mehr. Passthrough-Requests, Batches und Realtime-WebSocket-Sessions werden nicht verlangsamt.

​
Streaming und Arbeitsspeicher

Bei einer gestreamten Response liest GoModel den Upstream im Hintergrund und gibt jeden Chunk zu seiner skalierten Ankunftszeit frei. Ein Chunk, der 2 Sekunden nach Stream-Beginn eintraf, erreicht den Client bei Faktor 0.5 nach 3 Sekunden; das relative Chunk-Timing des Providers bleibt so erhalten. Chunks, die auf ihre Freigabe warten, werden im Arbeitsspeicher gehalten. Ein großer Faktor bei einem langen oder umfangreichen Stream oder bei einer großen Audio-Response kann erheblichen Speicher belegen.
Zuletzt geändert am 3. November 2026